Contact me at : FahimF@email.com

ContentZone

Boy who ever said that adult life was an easy thing? <g> I have spent most of the weekend doing yard work, shopping or puttering around the house and didn't have much time for coding till today. I did receive e-mails from SynTruth, Peter Walker and BaT who all kindly volunteered to do logos for the new shell. I am eagerly awaiting their handiwork to see what marvellous images of artistic creativity that they come up with. In the meantime, Majestic One sent me an e-mail in which he said that he was beginning to feel like a Dev team member and had quite a few suggestions for the new shell. Which brings up a very important point, I do consider all of you to be members of the Dev team because coding isn't all that the Dev team does - ideas are a very important part as well and as I've mentioned before in the past, I'm always eager to hear your suggestions and comments - it's only nagging demands that make me see red :-) So come on all of you other Dev team mebers, get to work! <vbg>

Before I get completely side-tracked, this is what Majestic One had to suggest:

1. Saw a mention of #Include's and remembered some idea I had long ago. If #Include's would be used and there is parm that get set 2 or more times make the last one count. Then if I put the theamers file at the top my settings will always count and if I put it at the bottom his settings will count.
2. Is it possible to make all graphic handling by a .dll? Like jpg.dll, bmp.dll would make it easy for people who want to include png support and such.
3. Command line parameter for which main rc to use shell.exe -config C:\MyLittleDir\test.rc. Maybe no default rc file which would make the user tell what file to use and what name.
4. Loading of dll should not be done on the name or placement. Example shell.exe read the config and finds LoadModule C:\Dir\Systemv2\hook.dll. This way when testing a new update I can easily fall back.

I haven't had a chance to reply to him directly on this yet but I guess this is as good a time as any <g> Especially as this way everybody else (who is interested that is ...) can also find out about this stuff. About #includes, I am not implementing them exactly as #includes but rather as sectional module config files as explained in a previous entry. So for example, the desktop module will have a config file included in the [Themes] section under desktop= but that will be the only entry and there shouldn't be duplicates. So the question of duplicates shouldn't (hopefully) ever come up ...

On point two, I hadn't even considered graphics handling yet because I am trying to piggy-back on LS modules currently and that means that I won't have to handle graphics in my API yet. But when I do, I may want to take a look at putting in support for other image formats so as to make the shell more rounded out.

Point three - this is already there! I had put in support for a command-line parameter of "-nostartup" and one giving the path to .Rc file. This could be a special theme oriented Step.Rc or even a file with another name with just the .Rc extension. If such a file is specified, the shell will take that file to be the default config file even if a file named Step.Rc exists in the directory from which the shell was launched. If no file is specified in the command-line, the shell assumes that the config file will be one named Step.Rc in the shell's executable directory.

I am not really certain what he meant by point four. If he meant that core DLL's like hook and bangs should be loaded via Step.Rc in LoadModule lines instead of it being automatic, this really won't right - at least not the way I'm envisioning things. But if he means that not all modules should be loaded automatically, I agree with that. Only the core DLL's necessary for the shell to function as a shell are loaded automatically and even these don't have to be a specific version as you could switch between any versions unless one version has a specific function needed by the shell that isn't there in the other.

He did raise some very interesting questions and they have led to me doing some rethinking in certain areas. Thanks Majestic One! I would like the rest of you to write in with your ideas, opinions and suggestions too if you feel the necessity because a piece of software (even if unreleased <g>) is nothing without the input from the users :-)

Now on the subject of the software itself, I finally got to try it out today and after some initial bugs and problems, got it to run sucessfully! Yayyyyy!!! The splash screen works great and the config file reading works like a charm. I can't believe how bug free most of the code was <vbg> Only thing is, as I think I mentioned earlier, the shell is currently simply a skeleton and all I have is an empty desktop after the spalsh screen disappears. I did try loading the default LS desktop module but there seem to be problems there. So I guess I will have to debug the LiteStep module compatibility before I can release a beta. So have patience ...

I forgot that tonight's "Friends" and "Frasier" night. As it's the start of a brand new season of two of my favourite shows, I guess I'll have to put off testing the shell till the weekend. (Tomorrow's no good because it's Sci-Fi channel night There's "FarScape", "Sliders" and "First Wave" to be watched ...)

Anyway, during the day I managed to go through the LSAPI wrapper code and fix a few more places where wrapping was needed and remove a few more functions from the old LSAPI which aren't needed anymore under the new scenario. I also added a new !Bang command to my shell called !Splash and as the name implies, it is for a Splash Screen :-) Of course, it is called automatically when the shell is loaded if NoSplashScreen isn't specified in the Step.Rc but now you can call it anytime you want (if you want to have the pleasure of looking at the splash screen ). All that remains for me is to get a logo made for the new shell. I was hoping MorpheusX would do it but he seems to have fallen off the face of the earth So if any other graphics wizard would like to volunteer, I'd take that as mighty kind of him/her :-)

Now for the promised walk-through on the architecture of the new shell and my reasons for doing certain things the way I did them (other than for the fact that I'm plain ornery and just like to do them like that ). When I started coding this shell, I wanted to keep things modular and also to make this a truly stand-alone shell. So basically, you can run this shell with just the executable and the core DLLs (which incidentally don't have to be loaded via LoadModule lines in the Step.Rc) and it would work - it wouldn't do anything and you wouldn't have anything except a blank desktop but it would still work.

The shell is designed to do quite a few things that the Desktop.Dll did in LiteStep that I didn't think really belonged in the Desktop.Dll. The managing of windows and the windows list is one such thing. This one keeps track of creation of new windows and destroying of existing ones via a shell hook (good old Hook.Dll) and it even passes on these shell messages to modules that register with the shell to receive these messages. It also keeps a Windows list running (for compatibility with older modules that expect this) and sends back the windows list or the size of the windows list when queried by a module. Incidentally, the LiteStep windows list had a static size and was limited to a maximum number of windows and a query to get the window list size would result in the maximum number and not the true size of the list. The list used in this shell sizes itself dynamically and always returns the correct number of currently open windows when queried. This should make things a lot easier for people who still would want to use the old fashioned windows list But you could actually do a lot more with the shell hook message registering. For instance, I think it was Majestic One who suggested a task manager which would show only the tasks in the current VWM pane to me ... This could probably be done quite easily by using the shell hook message registration - though it might not be as easy as I think it might be :-)

The shell also takes care of hiding minimized applications instead of leaving those messay little rectangular things at the bottom of your screen :-) This way, if you were to use jugg's jDesk with this shell for instance, you wouldn't have to hunt for another module to hide the minimized tasks.

The reason behind having Hook.Dll as a separate module is apparent because it gets loaded into the address space of each and every app and you have to keep the size small but why did I create a separate Bang.Dll? This was because I felt that the regular !Bang commands like !Recycle, !Quit and !Logoff had no reason being in the API because they really aren't API functions to be called by external modules unlike the functions to add, delete or execute a !Bang command. So I moved all the built-in !Bang commands to a module of it's own and made the shell register these commands on start up. Ideally, I'd like to take out module specific !Bang commands like !Popup and the !VWM* stuff and put them in the appropriate module and have the module register them but currently I guess I'll have to have them in order to facilitate existing LiteStep modules.

So that brings the DLL count in the shell to three - Hook, API and Bangs. So what else is left? The LSAPI wrapper. This is basically there so that I can run LS modules and they'll have a familiar place to find functions that they call regularly. But all the LSAPI really does is call corresponding functions in my API. Unless it is a function like LoadLSImage or TransparentBltLS which is there in it's original form because I haven't written a corresponding function seeing as the shell itself doesn't have any graphic functionalit that needs them. In the same vein, I've left the original LSExecute and LSExecuteEx in too.

That's basically it as far as architecture and functionality goes. None of this is written in stone and is subject to change depending on how things go when it comes to actually getting things to work - as happened with dropping Theme.Rc support. But then again, as I am looking at a sort of a #include (without actually calling it such) via the proposed [Themes] section (about which I made an entry a few days ago ...), the Theme.Rc does become kind of superfluous for most things. But enough keyboard thumping, I'm off to watch TV :-)

Guess what? I finally got a chance to sit down and compile all the changes I'd been making to the sources to my new shell. It is only when I started doing that that I found that I had to do even more coding than I'd thought at the beginning! As I'd said here before this, I was planning to use an LSAPI.DLL that was to be a wrapper for my API by calling the functions in my API when a module called a LiteStep LSAPI function. But what I'd forgotten was how many functions I'd really have to replace. Fortunately, as the new LSAPI is to be a wrapper, all I mostly had to do was delete all the code in the old call and put in a call to my functions.

In the process, I discovered that I had a complication as far as the current Theme.Rc file goes - I had rewritten the whole config file reading format for my shell but my scheme was based on reading the info straight from the disk while LiteStep reads the info into a memory buffer and uses that from then on. Now the reason I decided to read from file was twofold: a) I wanted to see how fast (or slow <g>) a diskbased config system would work b) I wanted to see how much of a difference the new scheme would make as far as resource usage goes. The problem here was, that while I could provide an analogue set of Step.Rc file reading functions for all LiteStep modules to use, I hadn't planned on Theme.Rc support and so didn't have a set of functions for that.

I couldn't very well use the functionality present in the LiteStep API because I had no memory based config caching system. A dilemma indeed. I got out of the problem the simplest way possible <g> by deciding not to have Theme.Rc support for the moment :-) As my current theming plans diverge from the LiteStep method anyway, I guess this is not a great problem - unless you use the Theme.Rc as a matter of course :-) Oh well ....

Anyway, I got the shell executable and the core DLLs (hook, bangs, API and LSAPI wrapper) all compiled after quite a bit of bug fixing. But it is now pretty late in the evening (it's only about 8:30PM <g> but as I goto bed around 9 o'clock, this is late for me ...) and as I'm trying to download DirectX 7.0 at the same time, I don't want my computer crashing because I tried to test a very buggy shell :-) So I guess testing will have to wait till tomorrow ... or the weekend, whichever turns out to be more convenient. But in the meantime, I'll probably try to do another writeup maybe tomorrow describing the reasons (and the architecture) behind the way the shell is split into an executable and several core DLLs. Till then ....

Well ... my computer woes aren't completely behind me yet but I am more or less back. At least, I have enough applications up and running to qualify as being back :-) First, the personal stuff - I ran into GeekMaster on IRC today and he invited me to join him, Floach and Sammy for a little chat. They wanted me to bring The Journal over to FPN as they'd like to bring the shell community closer together and while I was once more touched by the camaraderie in the community, I had to regretfully refuse their kind offer.

But Floach mentioned how the shell community seems to be very fragmented at the moment and closer reflection shows that this is indeed so. Around the beginning of the year there were so many new shells coming out, being developed etc that the shell development for the Windows platform was beginning to look like a mini-industry. But now there seems to be very little activity except in a few areas. What has happened? Some of the shells seem to have died out, others have gone underground to do development and a few have even gone (semi-)commercial. Oh well ...

To continue the discussion I was having last week about config file formats and theming (before I was interrupted by the near demise of my machine ), let me take you on to the next step in the evolutionary process of the theming config file that I arrived at. Actually, this is the standard I have determined to use for my project if nothing better occurrs to me before final implementation.

As I mentioned in my previous discussion, the current options for theming LiteStep that I'd discussed with TinOmen and MorpheusX finally boiled down to using a Step.Rc and a Theme.Rc with perhaps a lot of the commands being duplicated in both files - the Step.Rc containing the user's preferred setting while the Theme.Rc would have overriding preferences set by the themer. This could lead to a lot of duplication and two pretty huge config files...

So my next idea was, why don't I split the Theme.Rc into sections and specify them as and when necessary? This would have the added advantage of being modular in design so that a user could enable one component defined by the themer while using his own settings for the rest. Let me hasten to clarify with an example. My new design was to have a section in the Step.Rc something like this:

[Themes]
Shortcuts=C:\LiteStep\ShortCut.Rc
Popups=C:\LiteStep\Themes\MyTheme\Popup.Rc

That way, the user could specify the theme components that s/he wants to be used or comment out the ones that s/he doesn't want used. This would also make the writing of a theme installer pretty easy because all the installer had to do was install the stuff to a directory and add/replace the necessary lines in the [Themes] section. I was initially thinking of having the default configuration for each of the items above (Shortcuts, Popups etc.) in the Step.Rc itself under it's own section and was envisioning the modules checking the [Themes] section first and if it didn't find a relevant entry, checking its own section in the Step.Rc ... but I see that this could also be done a bit differently.

You could have the user settings in the [Themes] section as well and simply replace the user settings with the themer settings when a theme is installed ... as the files would (hopefully) have different names and/or be in different directories, the user can switch between their config and any theme config.

Only trouble to the above scheme is that again it will necessitate the recoding of all existing modules to work in this manner. This seems to be the best alternative to me at the moment though and I will probably be proceeding in this direction as far as theming is concerned. Perhaps tomorrow we can discuss another aspect of my new shell ...

On the coding front, I had most of the code completed last week and was planning to compile the source and try out the first ever version of my new shell but the problems with my computer put an end to that. So today I decided to go back and recode some sections. I had originally planned to have wrapper functions that would intercept the GetRC* commands in the LSAPI and use my own API calls to read the config file ... but as I didn't go with a split config file scheme as I'd originally intended, I then decided that there was no need to do this and was going to let modules do LSAPI calls to read the config file.

But I'd been trying out a straight file access method instead of a memory based file access to read the config file and I realized that in order to use direct LSAPI calls, I'd have to load the config file to memory. As the main reason for reading the config info direct from file was to conserve memory, this basically just took me back to square one as far as resource usage went. So I decided to rewrite portions of the LSAPI to provide a wrapper for my config file reading functions after all. I worked on that today as well as completed the as yet incomplete Color value reading function.

This basically completes all the stuff I had hoped to do for the initial release. Now it only remains for me to compile, debug and come up with a stable release. On the way, if I discover that file based reading of config info is too slow, I might go back to a memory based scheme but that remains to be seen ...

Receive email when this page changes • Powered by NetMind • Click Here