Dev-Picayune

Well, I have gotten a little farther with the toolbar program (Nevada). I have it drawing multiple icons (I had to correct a problem in the coe to make that work — namely I had to specify an accurate size for each PictureBox control — otherwise after the first one it was drawing them with 0 sizes or something). I also have it doing the mouse over effects I wanted with the enlarging icons as well as a bevel when the icon is clicked on (essentially non-selectable buttons). Why all the manual work? Because a true toolbar can not have its buttons actually gaining focus like a regular button does.

This all seems to work pretty reliable so I am pretty happy with the results. My next order of business was getting the screen setup better for skinning. Although the screenshot doesn’t obviously show it, underneath, the window is split up into 5 different panels. Each panel as an image for a background. The icons live within the “panelMain” and are added to it dynamically. When a mouse up event is detected on an icon that has had just received a mousedown event, it actually launches the associated program. So in the example above, after releasing the mouse button on top of the notepad icon it will launch notepad. To make life a little easier, I associated the PictureBox.Tag property for each dynamically created picture box with the actual FileBarItem object that created it. Then to launch the program I just have to cast a temporary BarItem object when the UI determines the item is needing to be “executed”. Since all BarItem objects have an .ExecuteItem method, I just call that and for FileBarItems that means that it will execute the file specified. Execution for now is handled by a single line call to System.Diagnostics.Process.Start(itemfilename). Why they decided to put process in a library called “Diagnostics” is beyond me.

After having finally setup a framework of classes with inheritance (gag), I managed to hack the toolbar to an early display stage. The following screen shot shows the toolbar in its earliest form. To avoid any possible optimism, I killed off the title bar to really show the bar at its essence.

The icon was generated using the code I have tested that pulls the icon info from windows — essentially the code asks the OS what the official icon is for c:\windows\notepad.exe (windows since I run xp and not 2000 at home). The work part was making it actually utilize my classes and properties and methods to load and display the icon. There isn’t much there but at least it isn’t pure hardcode it was dynamically created at run-time.

So currently I have placed a tiny rock in a giant bucket that I still need to fill up to get this thing really working, but it’s a start. The worst is yet to come, I can tell.

Didn’t get very last night with the launching application. I did come up with a project codename for lack of a good official name for the program. I decided to call it Nevada in reference to the Vegas slots since one of my favorite features of the program (as it was back when I originally did something like this in Clarion) is the ability to quickly rotate or roll to a different bar. The toolbar will have an up and down (or left and right depending on the orientation) set of arrows that when pressed will rotate the bar to the next or previous group of icons. This allows the user to have a set of general icons, programming related icons, graphics or games related icons, etc… I have my friend and mentor Mike Ledet to thank for this design as he suggested the concept in the early days of my work on an application launcher. At this point, I am struggling a bit with my abstraction of objects. I have layed out (at least in my head) a few of the general objects. There will be a generic baritem class from which I will have several child classes — GroupBarItem (which will contain a group of icons) and a FileBarItem (which will contain a single file related item). I may also have a SpacerBarItem (which will be a blank space) as well as a AppBarItem which would be the icon that represents the bar program itself (the item you drag to when you want to add a new item to the bar or you click on to configure the bar). The only trouble I am dealing with now is related to rotating bar concept… whether I want the GroupBarItem to contain an extra property that is a bar number or ID or if I want to handle the rotating just purely programmatically, or how I will actually do it. I can see one day wanting to have sub-bars that appear when you click on the item on the main bar so I have to take that into account as well.

Last night I learned about .net’s somewhat imperfect support for PNG (Portable Network Graphics). As an interesting exercise, you can specify a semi-transparent PNG (pronounced PING) as the background image for a window. Run the program and you should see right through part of the window… which would be a really cool side effect. Unfortunately, the bit you see stays with the window as you subsequently move it. To get around this “feature”, I found by trial and error that you should not specify the background image at the window. You should create a Panel that fills the window and specify the background image for the panel and set the panel’s background color to transparent. This achieves the desired effect of having a semi-transparent image over window (thus preserving the native color set specified by the user within windows).

It also appears (after reading some articles — sorry I lost the links) that Longhorn’s native API (WinFX) will natively support opacity (or transparency depending on how you look at it) setting for all controls. This would be really cool since you could then vary the opacity of objects on the window to achieve an anti-aliased effect without much effort. Also of note, Microsoft is planning on including the C# compiler with the operating system. Not just the PRO version of the operating system but ALL versions of the operating system. Definitely a UNIX like move really. All this ties back to the use of XAML to define windows and resources and events, etc… for programs. Also related, wxWindows will support the alpha-transparency information in .PNG files starting with version 2.5. Currently wxPython appears to be 2.4 based. I may need to wait for that version before doing my updated CPU monitor program. The one thing I really want though for wxWindows is a way to do opacity setting for the window as a whole. I haven’t found any code for that at all. I am sure, though that I might could do it using some win32 api calls. Finally, a chance to do something that other people have not necessarily written about.

While poking around with C# the other day, I was trying to figure out some key technical aspects to my program launching bar thing. I needed a way to get the default icon for a program or file and display it on the window. I found a related article here about ?? How would I extract high-color icons (with alpha channel)??
. Of course the answer to that question is that getting the basic icons is straight forward using the first code snippet found and I got it to work. Also, with a little image adjustment within C# I can have it do a cool enlarging effect when you mouse-over the icon. Even though it is a little rough… I am planning on doing a 32×32 and enlarging to a 48×48 on mouse over. The effect is nice and it will have the program a fancier feel to it. As I have stated earlier, I am not keen on doing skins since that deviates from applying the same look and feel to all windows but I am still toying with idea of having some type of skin support — the biggest deal is shaped windows which I have played with some in C#. As yet, I have not found a reliable image mask shape method (like wxpython has), but rather you have to specify via points, lines, circles, arcs, etc… what the shape of the window is. Yuck! So far I am not convinced I will be doing much with that. However, I am finding it hard to proceed without definitively deciding on the full scope of how the UI should work. My next goal is to define an XML structure for storing the programs to launch as well as figuring out how to use the ExtractIcon API to offer the user a choice of different icons if they want. Then I need to decide on how I am going to dynamically display and destroy the controls (something I have not done in .NET yet).

I’m still trying to figure out what roles I want my programs to play. In general, I like the idea of separate programs for everything. While Outlook is a decent program, I find I am frustrated because I am stuck with its pieces. If I don’t like the to-do list, I can’t just use a different one. If I don’t like the calendar, I can’t use a different one. Actually, not to say that I can’t but rather, I would be duplicating existing functionality that my computer is providing anytime I am running Outlook (which is “always”). So while it is neat to see folks try to make packages that do everything, it really is silly because chances are what someone really wants is just a small piece of the functionality. There are two drawbacks to this. One is that it consumes more system resources to run a bunch of separate programs. Second, it means a much less integrated environment. The great compromise here is that folks attempt to design software with Plug-Ins. This is nice, but when the plug-in you want doesn’t exist, you are stuck with finding a separate program or writing either a custom plug-in (which I have never done) or customer program (more likely for me).

Awhile back I found Xymantix Online — Sysmetrix. This is essentially a Dashboard type program that allows you monitor all sorts of things. Like a lot of the other programs I have seen, it now includes a ton of stuff. Most of the downloadable skins include things I am not interested in or can’t really use in my current environment. However, a few things of note about the program — it supports anti-aliased drawing so it looks very “tight” when combined with its skin and the skin-ability is extremely flexible yet doable for common folks like myself. When you look at the tremendous variety of skins for it you realize just how many different looks it can have. Kudos to the author (Nick Decker).

With all that in mind, I am planning on making my program launching program remain just that — a program launching program. There is not much reason to get carried away with fancy additional features so I will be focused on just effectively launching programs. As for other features, I think I will stick to separate programs. Since Sysmetrix uses about 15MB to run… I should be able to write my own (I’ve previously done my CPU monitor in Python). Another thought about some of the utils I have been looking at — the skins can often be quite nice (especially when done right) but at the same time I think it is important to realize that ultimately the OS is where most of the skinning should take place using stylexp or xp themes. That means that any program I write has got to be able to utilize the standard windows look so that it can be skinned from the OS level.