Contact me at :
19 September 99
Fear not faithful readers, I have not departed yet again for realms unknown for long spans of time ... sorry, guess I've been reading "Thor" for too long <g> Anyway, sorry about the absence once again but this time it was due to my computer conking out. As you may remember, I told you in one of my last Journal entries that I was setting up my new computer. Well, I switched the hard disk, CD-ROM and floppy from my old Compaq on the 15th after I got back from work and the computer wouldn't even POST (Power On Self-Test). I removed all the components and reinserted them but still no luck. As I didn't have two of everything (motherboard, processor etc.) there was no way for me to find out what was faulty. So I took it into a shop for diagnosing on Thursday and I didn't get the machine back till yesterday evening.
Turns out that the processor was gone, kaput, burnt out :-) I'd bought it off the Net as it was cheap but it had been acting weird since I got it. So I bought a Pentium III 450 (it was only about $50 more than what I'd paid for the original Pentium II 450) and got that installed at the shop where I got my machine diagnosed. Then I brought it home and since then have been busy installing Windows 98 SE and all the other software I use on a day to day basis. Things are still sort of "under construction" and so you probably won't see a full posting by me till at least tomorrow but I thought I'd just let you all know what was happening ...
(Oh yeah, I also discovered that there was a naming problem with the new graphic that Lowspirit had done and that the page was still displaying the old header. That should be fixed now ...)
14 September 99
So another day has come by and is almost gone and what
a day it has been so far :-) I didn't get to try out my new machine much last
night as there are quite a few things hanging by a thread (or rather a screw
- though a screw does have threads
During the day, I got some more responses to The Developer
Journal coming back to life ... and from such old stalwarts like Christopher
Spera and Majestic One who've
always written whenever there was something worth commenting. I spent most of
the day brushing up the source code that I'd already worked on as I want the
code to be extensible for the future and to be compilable for single byte, multibyte
or Unicode. I then wrote wrapper functions for the config file reading function
so that it could read in a string value and then convert it to int, boolean
or string (for completeness' sake
Anyway, I think it is time to tell you more in detail as to what I intend to achieve with this particular shell and the direction I'm proceeding with it. A very pertinent question to this matter was asked by Jorge Eduardo Argollo, who e-mailed me in the afternoon where among other matters he asked: "Did I get you wrong or you believe there is a necessary and unavoidable antagonism between user-oriented and themer-oriented shells? Why so?" Now that is perhaps the very heart of the matter because that is where the idea for this shell was germinated. It all started when I left the LS Dev team - there was a debate raging at that time about theming standards and ideas were flying all over the place. I'd been paying attention to this debate and when I was thinking of doing a port of LS to Be or QNX, I began thinking about how I could improve theming in my new project so that it would avoid the pitfalls present in LS currently.
My first idea was to split all module functionality over two config files - call them Step.Rc and Theme.Rc. The Step.Rc file would have user specified values defining what the user wants on his system while the Theme.Rc would have the look-and-feel components that would define the look that a particular user wanted. I realized that while most existing modules could do this safely with a bit of recoding, the biggest problems would be stuff like Shortcuts and Tickers. Let me explain with an example config which would split a few normal Shortcut and Ticker setup lines over the two proposed files:
PaintShop=10 20 C:\PaintShop\PaintShop.Exe
Word=10 50 C:\MS Office\Word.exe
1=50 10 100 %c %t
2=50 100 20 %@
Word=.extract C:\MS Office\Word.exe,0
1=5 5 led1.bmp
2=8 5 led2.bmp
That was my original proposal to TinOmen and MorpheusX where the Theme.Rc (and hence the themer) would have control of the look of the user's desktop. But after much debating, the above was modified to where even the positioning was at the themer's control because this was supposed to be a themer's shell (and that is where the whole conflict comes in ... but more on that later ...) So the new files looked like:
PaintShop=10 20 Paint.bmp
Word=10 50 .extract C:\MS Office\Word.exe,0
1=50 10 100 5 5 led1.bmp
2=50 100 20 8 5 led2.bmp
Now you might wonder why am I still struggling with the existing config format? Why don't I come up with a new format? Because the whole point of the new project I started was to work with existing LiteStep themes and modules with a little bit of tweaking provided via the new API where any calls to LSAPI to get Step.Rc file info would be intercepted, the relevant information retrieved from the split Step.Rc and Theme.Rc and sent back to the requesting module as a single line. But then I realized that there were two definite problems (in addition to any other indefinite problems I might not have thougt of <g>) with this whole concept: 1) While the split file concept looks good when it is a couple of simple shortcuts, it isn't going to be so simple to edit shortcuts when you have a whole heap of them as most of the newer themes do unless you have a GUI configurator 2) How are you going to match the themer's concept of shortcuts with the users? For example, if the user has 2 shortcuts and 3 tickers defined in the Step.Rc and the new theme that he installed has got 20 shortcuts and no tickers defined in the Theme.Rc, what do you do?
At this juncture, I was almost thinking of duplicating the whole Shortcut and Ticker entries in both the Step.Rc and the Theme.Rc - the Step.Rc would define the user's shortcuts specification while the Theme.Rc would define the ones that the themer envisioned and when the module looked for config information, if it found any information in the Theme.Rc, that would get implemented and the Step.Rc information wouldn't get implemented at all. That way, the themer's vision would always be executed and if the user doesn't like that and wants his own vision back, he simply has to remove the specific items from the Theme.Rc. This is what I meant by calling my shell a themer oriented shell.
But there is a problem there too. I cannot at this point think of a way to intercept the RC file reading code for all modules in a standard manner to achieve what I'd described in the last paragraph. So it looks as if this can only be done if new modules are written for my shell specifically to implement theme oriented config. But my ideas have moved on from a simple Step.Rc and Theme.Rc to a more complicated setup implementing basically the same concept since then. But I think this entry is reaching novel proportions (or at least that of a short story <g>) by now and so will explain the rest of it in another journal entry ...
13 September 99
OK, OK I have been proved wrong not once, not twice but many times over :-) I said that maybe nobody read what I wrote here and what do I find in my e-mail around mid-morning? An e-mail from Rob Davenport who told me that he does read my web page. During the course of his e-mail he referred to this site as "the page formerly known as 'The Litestep Developer's Journal'" <g> and I found that pretty funny. He also talked about my "New Shell" and I told him that maybe I should start calling it LiteStep NS following the path already well travelled by Microsoft and Windows NT and this is what he had to say about that:
"ROTFL! I like that one. Or LiteStep: The Next Generation... hmm... nah. LiteStep, Part Deux... nope. "Begat" - as in "And then LiteStep begat ...." Son of LiteStep? Or continuing an the theme: The Shell (formerly known as LiteStep) - though "inspired by" would be better. Oh heck I could go on at this forever... "
Then I heard from Ryan L who also wanted to let me know that he still read the drivel that I wrote (actually he didn't say that <g> but I couldn't resist that ...) Makes me feel all warm and tingly inside with all this happening in one day :-) But that is not even the end of it ...
I came home and found that all the components I'd ordered about a week ago to build a new computer had finally arrived and so spent the whole evening setting up my new machine (Pentium II 450, 128MB RAM, ATI Xpert98 AGP 8MB RAM and a 5GB HDD very kindly donated by Jacob Hochstetler) and didn't have the time to check my e-mail. When I finally did get around to checking my e-mail, I found two more e-mails. One from Lowspirit with a new header graphic because he'd seen that I'd updated my site and didn't want me to have to struggle with the whole "the site formerly known as The LiteStep Developer Journal" thing (darn, there goes a good gag <vbg>). Thanks dude!
The other one was from demigod - whom I've known for quite some time - with an offer from Rza at ChunkyMunky to host ... (oh darn, now I can't say "the site formerly known as The LiteStep Developer Journal" <g>) The Developer Journal. I was really touched by all of this as all of this gives you that warm tingly feeling inside that makes you feel so happy :-) Thanks guys! All of you have collectively made my day!!! :-) Of course I still haven't tried out my new computer and if I blow out the motherboard things are bound to go rapidly downhill ... <g>
12 September 99
Well ... it's been exactly a month to the day since my last posting and guess who's back? :-) I don't think there is anybody in the LiteStep community who doesn't know by now that I am out of the LiteStep Dev team and so, it is not really appropriate to call this The LiteStep Developer Journal. It is probably more appropriate to call this simply a "Developer Journal" but as I don't have the time (or the inclination <g>) to do a site redesign at the moment, I guess things will have to remain as they are at least for a while ... but as for the future, who knows? (Actually, I do know ... my plans at least, not God's plans for me <vbg> but I'm not telling ....)
So what have I been upto and why am I updating these pages after all this time? I don't even know why I'm writing this as I don't think there probably is anybody who checks these pages anymore ... but then again, I might be mistaken. So let me do my bit and we'll see what we'll see :-)
Without going into all the rigmarole about why I left the LiteStep Dev team etc. etc. ad infinitum let me tell you where I went on from there. When I left LS development, I wasn't planning on completely bidding good-bye to LiteStep. But I was fed up with development on the Windows platform and was actually thinking of doing development on a different platform. I had two prospective platforms in mind - BeOS and QNX RTOS. I own a copy of BeOS and am pretty impressed with it and I had heard quite a bit about how easy it was to code for Be because the API was such a wonderful piece of work. And then on the other hand, I had been talking to the QNX people for a while about porting LS to their OS because I was very impressed with their OS too. If you were to visit the QNX site, you'd find a demo of their OS there which fits on a single diskette. With that one diskette, you get an OS, a GUI, a browser and a few other utilities you can use simply by booting with that diskette. I am impressed!!!
Anyway, I couldn't develop for QNX as I didn't have a copy of the OS or the SDK and my talk with the QNX people was just that - talk. There was nothing happening at that time. I decided to go for Be but as luck would have it, my new machine which had been giving me trouble all the way, decided that it didn't like BeOS. Try as I might, I couldn't get BeOS to install on my desktop though I'd got it to install on my notebook without a hitch at the first try.
In the meantime, I'd been planning a lot of things for my new port (or rather rewrite) of LS to BeOS. There was a heavy discussion going on about theming at the same time and I got input from some of the major proponents in this debate because I wanted my new project to avoid the pitfalls that LS had encountered. I got a lot of ideas and I had a lot of stuff that I really wanted to try out but there was nothing I could do in the way of code as Be wouldn't install.
So what was I to do? I then had the idea of going back to the Windows platform and doing a new shell! Original, huh? <vbg> Well ... that is what I started to do anyway ... I decided that I would try to do a new shell that would be a themer's shell instead of a user's shell by giving themers all the space for improvisation they needed. To further this, I discussed my ideas with TinOmen and MorpheusX, the people whom I considered to be the foremost in the field. To the mix was added input by jorje who has such a vast knowledge of all the modules and the module commands out there that it simply staggers me :-)
Armed with all the information, I started out to write a shell. Only thing was, the further I progressed with my code the further I seemed to fall away from some of the ideals I'd started off with :-) But then again, I also found new ideas that seemed to actually make sense. So I don't really know where I am at the moment ... especially as the preliminary coding is done but I still haven't tested it out - instead, I decided to take the time off to write this update to the Journal.
The heart of the shell is the same as LiteStep - it consists of a traffic handler for interprocess messages. I should be grateful to Bryan for this code as I am basically using the same code that he used for LiteStep with his permission. I've simply cleaned it up a bit and adapted it to my own purposes. But I've also integrated quite a few of the functions that the desktop.dll used to handle into the shell because I believe that these functions should be handled by the shell. These includes stuff such as keeping track of the active Windows list, passing on shell messages to processese that have registered to receive these messages and a few other things that I am still in the process of adding.
I also wrote a new config file reading and writing (actually the writing part is still to be written <vbg>) method which while retaining the old Step.Rc format, also changes it slightly. It is a combination of Step.Rc and INI file formats that allows me to have a lot more flexibility but retains compatibility with LiteStep. Now why is that you may ask? Well that's because the point of the new shell is to provide LiteStep users a new alternative - a completely new shell that is compatible with existing themes and modules for LiteStep with a few minor changes.
Only thing is - while the basic code is in place and it does actually compile <g> I don't know how well it performs or whether it performs at all. So I guess you'll have to be content with this description while I go back to coding, testing and debugging in order to bring you the shell named ..... ? :-)