Captain's Log Supplemental

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 !

Spent most of the night working on the port searching code and options module. I think the options module is now almost like what I originally envisioned of it. Aside from being integrated into the not yet written settings dialog and no read/write accessor methods wrapping around the configuration dictionary keys.

So far across the various prototypes, tests, and mock ups I’ve written over 3,000 lines of code (wc -l *.py for each directory gives sums adding to >3700L). The way I work I guess is a bit heavy on files but it tests the hell out of things 🙂

So far the current working system is almost 700 lines of Python code. Aside from not being very feature complete yet (for my tastes) I think it is coming along quite nicely and maybe should be marked higher then the pre-alpha status I set on sourceforge… But I guess I have higher expectations of my own work then I do others lol. The > 700 lines of code in the SVN now represents the work done in R&D by the previous coding. One thing I like about SVN and CVS as opposed to manually backing things up with cp/tar is there is no fear about ‘accidentally’ deleting files permanently before they serve their use hehe.

I’m hoping to soon have enough files for a quick snapshot that can handle the basic pkg_* commands and searching the local ports tree. I have tried to keep both the quality of the code and the programs design as high as possible at every phase but I don’t really consider myself a good programmer. Just someone that knows what he wants and can wrap his head around it piece by piece until it all falls into place.

Hmm, why do I feel more like a Japanese Beaver then a Spider right now? Haha/

A quick list of standing to do’s so I can be sure I don’t miss things, I really should look at using the tracker service on Source Forge for this hehe. But I’d rather spend my time writing the solutions 😉

In no particular order:

• extend QLineEdit — done a different way (for now)
• do concept drawings of settings dialog
• integrate logger and options module
• remove dependency on psearch — it really is that simple a program!
• fill in stubs for various port actions; install/upgrade/delete and prepair for various capabilities that need further development *wink* — mostly done and evolving
• ability to select items by means not tied to the mouse pointer location
• consider a better name then port_viewer.py — renamed pkgviwer.py
• begin work on the ground work to begin the German translation
• performance tests of our background process handling
• mock up of NPM_MainWindow in style number 2 — done, minor changes to go (mostly educational advancements
• gui for cvsup/csup/portsnap operations
• replace search box and refresh button with tool bar in mock up layout
• tabbed about dialog, kde-style

S’all I can think of right now. I know I really need to look deeper into Qt’s layout handling and widget geometry related facilities not to mention the coordinate system.

Spent most of the night watching Simpsons but I started work after awhile.

Worked on a compromise between the pkg_info/pkg_delete display needing to pass on the software packages name to be operated on to the appropriate slot and my own code minded need to place the actual implementations of those slots in its own file along side other port-related actions. I also removed the hidden column since I realized I already had a method to cram the spitted name and version back together and store it in an instance variable for passing on.

The internal QAction object for each entry in the context menu has it’s connect() signal connected to a python slot. Since we need to know what was activated (and I am not a genius with context menus in QT3) when the action is activated the slot calls an external function (the real slot if you like) with the name of the selected package.

So right clicking the package in the list brings up the context menu, which saves a reference to the item selected; suitable for running the pkg_delete/info commands on directly. When selecting the action to perform from the context menu, it causes the activated() signal to be sent to the wrapper slots for that action. Which intern call the implementations from another file with the item/package name that was set by displaying the context menu.

There might be a better way of doing it but I ain’t found it yet. And personally I am one that prefers to try the simplest solutions to a problem first and see if they work before complicating things. And this way of doing it is quite simple, at least to my brain cells.

I also skipped using the poor looking mockup of a display area I wrote to pack the output of running a command, such as make into a window for display. The mockup was based on a translation to Python I did of a C++ Example from QT3. It worked but did not look very nice and although I prefer to hand-code things when it’s not to major because it normally ends with me knowing WTF is going on. I fired up QT Designer and used it to create a simple Dialog with buttons I can edit into what I want and spend time getting it to do what I want rather then look nice.

Generated the python version of an ui.h file from it and wrote a subclass of it that modifies it (for testing at this point) and extends it with the extra functionality we want, being able to run the requested process and display it’s output. So far I am enjoying this and because the .ui files created by QT Designer is just a custom XML format, it is easy to edit by hand as well as through Designer (A GUI for making a GUI the easy way). Later on the subclass from the ui.py file might get replaced with a handwritten equivalent but I’ll worry about that later.

Some standing issues are:

0/ Define usage style for the Display Dialog while it ‘runs’ including changes to the options sub-system as needed.

1/ Set up the pkg_delete / pkg_info handlers to use it for displaying their output.

2/ (later) figure out how we can get the Dialog to display properly when resized, namely having the buttons and display widget resize with the window !

The above 3 items are what I would be doing tonight, if tonight was not really this morning because it is after 0500 in the local morning !!!!!!!!!!!!!!!!

The sad thing is I am hungry and wide awake but not sleepy in the least. I guess programming for a couple hours has that effect =/

Man, I love to code…

Made a bombing run across the code for wrapping pkg_info, the stuff to right click a program and delete it is still mock-up. But I’ve fixed the display of programs. Before when I had initially written it back in December I used a mish-mash of operations on links and arrays to rip off the version # and description from pkg_info’s output because I didn’t have time to learn Pythons Regular Expressions. Which of course I had to learn the regular expressions module like 2 weeks later but I never had time to revisit that.

I converted it to use regular expressions so it can solve the known issue that some of the entries displayed in the names and versions columns would be ‘cut’ wrongly. An exception handler was there to report any ones that failed the operation (and would display wrong). Because of the change to regular expressions that’s fixed and the exception handlers are mostly there to catch any errors I might make before the file grows more mature.

I’ve also tried to adjusted it so that a non displayed column is used to hold a complete reference to the programs name-version suitable to use plg_delete on. For the sake of those that don’t know what prog-foo installed does I should add a column between it and the versions that will display the short descriptions given by pkg_info; minor change.

I imported about 1/3 to 2/4 of my most stable files into the SVN Repository. And I think I can import most of the others in the testing/alpha2 directory. Before starting t his move to SVN. What I did was create stubs in my ~/code/Python/src/neo directory. And make a testing directory there for scratch tests and things because I still had many modules in Pythons standard library to learn and knew zilch about Qt programming.

The Alpha1 directory was made as a place to start compiling code that could begin to form the basis of an Alpha release. The Alpha2 directory was forked off from the Alpha1 directory to build more quality to it and iron out more ideas. I still personally consider NPM as pre-alpha because it has yet to be made a full program beyond the near complete mockup in the Alpha1 directory.

For the SVN Repository, code is being taken from the Alpha2 directory on the laptop and imported into the trunk. My intention is to make use of the branching/tagging features to prepare an alpha release from the current code when it is ready. So there is no need to use the directory structure I was using before SVN, because this is Subversion versioning system 😉

Ma kindly reminded me that it was after 0500 in tbe morning so I didn’t take time to finish work on the file before commit, it is still improving though. The only thing that pisses me off is I spent about 10 hours yesterday working on NPM after getting home from work. Between the website and the program code the first 5 hours were almost a washout, the 2nd 5 hours were like 20 * more productive then the first — Oh what difference there is between starting at 1500 and starting at 2400 here…

NPM now has a website set up. It is pretty basic and 2 files plus a stylesheet but gets the job done for now.

I want to see what I can do with the server side scripting so I could move the links menu, header, and footer into their own files to be inserted into the target page. I considered setting up a bare-bones install of a content management system since there is a MySQL database and 100mb storage allowed.

I ruled it out throuhg because the majority of it would just sit unused and that is at least 50MB of files for most CMS’s I’ve bumped into. While I do have experience with the software we use on [SAS] that does not mena I like it, I don’t think there is a CMS that I would want to use unless there was going to be enough volume of work to warrent it. I tried several demos of various PHP based CMS systems online, Drupal, Typo, Joomla, Xaraya, eZ Publish, e.t.c. I didn’t partictually like any of them but Xarya and Ez Publish looked quite nice but still overkill for this.

I also began checking in some of the more complete modules from NPM into the code repository on source forge.

As far as the web site goes, the only major additions I have planned for the near future is a planned features page, contact form, adding a link to my blog from page 2, and a note on fetching the sources from the svn. I also would like to get a mailing list setup.

My only complanit so far, it took me 6 hours to create the website — most of it done when my family was finally ‘out of the house’ for awhile, and all in all the job should have taken less then 45 minutes for me… That is how much damage constant interuptions, dogs barking, birds screaming like hell, fetch this and thats, phones ringing, peoples TV’s blasting my ear drums away, and the other general commotion going on in this rat-hole causes… Trying to work here is like pulling a fat man through the eye of a needle unless everyone here but me is sound asleep…

*sighs* is it any wonder I’m awake until I pass out from lack of sleep when I’ve got ‘work’ todo?