FreeBSD

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 !

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?