Projects/Neo Ports Manager

Sat down and started working on NPM again, this is my first commit in a few weeks… Mainly because the last few weeks have been a living pain in the ass rather then a codeathon.

Terry@dixie$ svn log -r HEAD                                               8:55
------------------------------------------------------------------------
r53 | sas_spidey01 | 2008-02-20 08:54:55 +0000 (Wed, 20 Feb 2008) | 23 lines

optionsinterface.py added

        A thin wrapper around a dictionary of options (to be kept private)
        that exposes a getter and setter method for each key:value pair.
        For which is intended to be used as a slot from the GUI or a call back
        of sorts from a slot in the GUI to the options interface.

        A simple 'flush' method is provided to update saved config (not
        finished). NPM_OptionsInterface is to be integrated with NPM_Options
        in some suitable manor that removes as much as possible of the system 
        from the 'middle' of code that needs to get / set options values.

        The question of using Qt's settings subsystem or the existing one
        remains to be decided.

npmwidgets.py modified, gaining an extra slot for NPM_SpinBox -> man I wish Python had Cs Preprocessor some times.

settingspages.py -> checkboxes, spinboxes, and the override server prompt connected to the NPM_OptionsInterface provided.


More to be changed in the future design wise (for the better).. When I've got more sleep to think about it.


------------------------------------------------------------------------
Terry@dixie$                                                               8:5

If I didn’t have work in the next city tomorrow I’d be working on this for another two hours nut alas it’s already approaching 0400R / 0900Z rapidly… And I’m to tired to comment much more.

I do know this, I want to be able to get / set options as necessary through slots. Without having to have any understanding of how the config file is handled else wheres. At the moment I’ve basically started a switch from NPM_Options::config to NPM_OptionsInterface::config for storing the options in memory. The difference being at the moment NPM_Options is only able to read the configuration files using Pythons INI parsing classes for our needs. And it exposes a dictionary of option=settings. The difference between obj.config[‘optionKey’] = value and obj.getOptionKey(value) is negiable for me.

The thing of it is, what if we need to do more then just assign a value to keep things in order ? At least with a set of methods around the problem the rest of the program can be insulated from any major changes in that part of the system. I also know that I have very little interest in extending pythons dictionary class just for the occasion lol.

sleep….

Well, got some work done.

Completed the change over (mostly) from a single hard-coded dialog for handling the output of processes to being a subclass of a display builder like parent class. Python doesn’t support abstract classes as far as I know or even private members for that matter (but has a nifty name mangling like thing for a making a naming __convention).

The original reason I wanted to do this is I figured that A.) The class was cluttered with code common to any ol’dialog window and B.) The rest of it was just specialized for the task of running a process and nabbing it’s output.

So I moved the common code into the NPM_AbstractDisplayDialog class and wrote a NPM_ProcessDisplayDialog subclass of it to replace the original NPM_DisplayDialog which also will allow me to use a similar dialog for other tasks without having to duplicate the code they would share if I was to implement another like-wise class in parallel. Because for example the NPM_DisplayDialog class was setup to ensure the process was neutralized before completing it’s termination I setup NPM_AbstractDisplayDialog::aboutToDie() as a signal to connect a slot from my subclass(es) to be called to do clean up, basically an advisory destructor you could say. And I connected it to the button to call QWidget::close() to this slot so aboutToDie() is sent when the dialog is about ready to be terminated.

I also found a fixed a small error in the pkg_info parsing, things like that is some thing that most concerns me.. lol.

Now the remaining problem is I’m starving and it’s 0746 Zulu (that’s 0246 local morning)… Must find food, then I guess I should get some sleep :

It’s been a bit of a busy night, took a little time to work on the NPM_PortConfig class but I’m still not really happy with it. The main thing that concerns me at the moment is dealing with saved config’s. Namely how to handle a situation where the Makefile has more options in it then the saved options from last time the system was built. Because other then that, it is really just as simple as check for a saved config,parse it if found and the makefile if not then and move on..

Also been playing around with the ol’C++ tonight. So farI’ve been reminded of why I hate C++ and why I love Qt and the GNU Compiler Collection at the same time lol. It does feel kind of weird to be working on some thing in C++ again, it was my first language but I have not used it in ages.. used C yeah sure but not C++ :

Lead some Planning & Leading training on TG#1 today. I was a little disapointed that Chester was the only one that showed up… But I think it whent quite good. Chester continues to show he’s worth our time in training. And the best part, we got to sneak past a ton of tango’s right under their noses hehe xD

Still early here, 0320R (local) but it’s hard to keep my mind on the code…

*sighs* women… lol.

Well, last night I got an alpha grade (imho) release set up on source forge and today I got it posted on forums.pcbsd.org.

It is some what ahead and behind schedule in the same regard, I originally planned to release a mock-up (non functional but ‘looks’) around the new year. Instead I’ve taken a few weeks to push on a head to some thing that actually works.

I had also road mapped a beta with a few more features then are currently ready to be released between Jan 2008 and June 2008 but it’s more likely that I’ll hit a 1.0 by June… hehe. So I’m both behind and ahead of my time goals. Software Schedules are not really some thing I believe in setting in stone, so much as setting a point on the calendar some where between when I expect to be done by and when I think it should be done by.

Since making use of SVN was not in my original plans I do have a bit to consider now.

I want to continue coding so I can keep the pace of development going. But I need to consider the chances of bugs being found in any one that actually tries the snapshot I released. And I do not want to muck with merging branches later if that happens… The stuff I released is not complete but it should be fairly stable, or I wouldn’t have let it hit SVN >_>.

What I am thinking is to limit my self to continuing things in the trunk that need to be done without effecting the released code much. Which is copied to the tags directory so it’s saved in SVN. Then after about a weak or so, go back to un-restrained work. So I can deal with things like redoing the NPM_DisplayDialog the way I would like to redo it.

Before I am willing to bump status to Beta, I want to have NPM able to update the ports tree (portsnap/cvsup/csup) and configure ports. I tested the config gui awhile back before taking the code to sourceforge but I never got it fully working. I need to figure out just how I am going to get a connection between checkboxes and options that I can parse back out of the GUI.

I should also make it look for stored configurations rather then just in the makefile.^[0]. Those two things are really what I am interested in coding feature wise. I also want to remove the dependancy on psearch because it really is a simple app and we might get a slight performance boost.

I also want to fix the translation systems up a bit, work on another prototype of the NPM_MainWindow user interface style and do some concept art for NPM’s configuration dialog. I don’t expect a GUI way of changing NPM’s settings to be released until RC status though.

I was a little disatisified with the phase 0 results. What I had done was checkout a copy of the sources onto the test machine end removed the diagnostic messages of echoing the command and arguments to be run in the background. A few oversites later namely a missing equals sign and the lack of –verbose switches (as can be seen in the video’s uninstall segment) I basically got it working but not quite happy with it.

Sat down tonight after watching a movie and set to work on getting her working smoothly out of the source tree. After that was done and with a little poking at portupgrade later…. I ran a group of live tests to check for the ‘it actually works’ factor with the core things and got no show stoppers. The only bad things I can say is I don’t care much for the port{upgrade,install} output dots and the occasional lag in updating the QTextEdit widget but it’s probably no slower then doing it from my shell.

here is a copy of the last commit message from editing source code:

CODE PASSES FOLLOWING TEST CASES:

update package listing (right listview)
view pkg_info for selected package (xevil)
remove selected package (xevil)
search ports tree (for xevil)
install port (xevil)

xevil was selected because it is one of the ports I have installed that is a suitable test case (small, fast/easy to install/deinstall) and one of the time wasters I have setup that I can live without if I frag it on there install.

I’m going to upgrade the development status on source forge to Alpha shortly and tomorrow I hope to have a file release ready op, Most of what remains is logistics really, before the Alpha Release the following needs to be compelete:

0/ make demo video (I would write the script now if it was a quarter after 4am’ish) — couldn’t get mic working, just as well with my house…

1/ mini faq thingy uploaded to website and update the sites download page

2/ readme file generated with basic testing instructions blah blah — also included a template for a desktop icon.

3/ update trunk/src/const.py NPM_VERSION – probably will get bumped to “0.48.Xa” ore “0.48.Xpre” and clean up some of the comments

4/ read SVN handbook on tagging and branching and put it to work – I want the alpha release split off the trunk.

5/ get file release prepared — done and done!

6/ forum post typed up for forums.pcbsd.org – done

7/ get my ass back to coding — what I should be doing lots of hehe.

Hooooooaaaaahhhhhhhhhhhhh !!! Now if I can get audio working in XVidCap and enough silence to do it with my crappy mic, this gonna be a nice start.

Sadly most of this is gonna have to wait until after dark…

fucking family already has given me a headache and it’s only 1617 local..

booted my test machine

set up for video taping

svn’d a copy of npm source

edited source to prepare for test

began test.

Not 100% what I wanted but this is the first live test of install and deinstall operations.

Video Sample

I tested doing a portinstall of xgalaga, confirmed it ran, and then removed it. The pkg_delete operations output left a little bit to be desired! But hey, it did work…

I want to prep a script and get the code ready for a small battery of live tests under real world conditions. Once the code is suitably able to pass an acceptible amount of the tests… Alpha release.

Before I video the next one through I want to have a properly written out and planned script to follow for the video. I also really would like to try and get my Mic working (not tested yet) so I could use voice over and some background music wouldn’t hurt if it didn’t add more then a few megabytes to the out file.

Currently tests will take the first priority and continuing feature implementation will take secondary until the Alpha release is ready op.

I want to triple check but I think I’ll be able to host the video on the website for download and I can probably upload it to YouTube. Using rapidshare for this one was just to make it available (temporarily). The final one made for the alpha release will be much better.

My main concern though is getting NPM ready hehe.

Another night spent working on NPM…

Some of the stuff done to night

begin of internal docs

prepping files for translation (wrapping more strings, now using QKeySequence e.t.c.)

trying to get set up for translations (including the beginning of the German one).

rewriting the display dialog to remove usage of Qt Designer / pyuic generated code.

To be honest, I think I could run a live fire test tomorrow with a 2 minutes worth of changes.

Oh baby has tonight been a full head of steam. I’ve been slugging through the options systems and the subroutines for actually doing the installations. A mock up of the style #2 GUI which is one of the ones I posted back in december when I did three different concept drawings. She is almost ready for a live test, I think as soon as I correct the item selection code to work properly (not tied to mouse position) it will finally be time for that Alpha Release, two weeks later then originally planned but hey it’s still is more feature complete on the inside then previously planned for it xD

Here is a screen shot of Neo running during a test run of the mock up from the trunk.

I solved most of the layout issues and I think it will probably be playing with the spacers and splitters to finish the rest of getting it to ‘look nice’. The main window is hand written but the display dialog is an extended sub-class of a prototype made in QT Designer.

What I am thinking is to have 3 drop-in modules each implementing the NPM_MainWindow class. Where each module implements one of the user interface styles and the programs init code loads the appropriate module. The advantage being the freedom to do any thing desired with the main window, while preserving the rest of things that have been done. Technically user created UI could be allowed to be loaded. I really want to play with the dock window stuff in Qt4… lol.

I need to start setting up the documentation (internal first, then the manual), ironing out the key commands, and setting up for the german translation in addition to my remaining to do’s but all of that is non-critical as far as getting an experimental release out there. I think goal for Beta time would be getting the portsnap/csup/cvsup stuff sorted out and a settings + about + help dialog in the run. A better website design would be nice too… hahaha

I know what I can’t figure out today, I can figure out in the days to come.

Hooah !