[rs-users] a glimpse toward rs 0.0.5

[Mudiaga O. <ob...@us...>]

Hi folks,

NOTE: there is no new retro release. although 0.0.5 i probably
will release 0.0.5 this weekend.

i just re-subscribed to the ls ml and i though that to make up
for not having the list for some days, i'd write this...

but before i say anything, i hope you guys survived the ls ml
flu well. For me, it went ok.  I just put a procmail filter
on X-Mailer: and sent those somewhere else.
I can't imagine life without my mail going pass a shell account=20
with procmail and mailgrep, and accessing it via imap.

ok, i finally got to testing rs on some themes i got from the net.

before that i made $Litestep$ dir user difinable so that
i can leave the retro binaries in one place and just=20
tell rs to look in the right directory based=20
on the directory structure the theme wanted.=20
besides that, i can now test different builds of retro=20
on different distros without coping files arround.
i also made changes to the default step.rc so that to run=20
it with a given config, you only have to unpack the files into
the directory where step.rc is - nothing overwritten since=20
everything goes in its own dir. (ok ok... enuf.)

anyway, back to my tests of themes. Things looked strange...
so I looked into it. What did i find? compatibility bugs! lots!!
All the lsapi functions used to query step.rc values were not=20
behaving well enough like litestep.

a general problem with some functions was that they didn't
clear some memory for the caller. there as also the problem
of return values based on string length of returned data.

<sigh><sigh><sigh>

(i have to check out repungent's docs on the ls APIs someday.
i should be able to contribute some annotations to certain functions...=20
btw i think sdf would have served better than html...)

Anyway, these were bugs.  The thing I found funny was that
they were not coding errors but errors based on my not=20
implementing functions exactly as in litestep, but by
my understanding of what they where supposed to do.
Unfortunately, certain modules depend on things that
really should be undefined... =20

What's more strange: I had to find these out myself...

Another thing relating to bugs is litestep's handing of=20
exceptions (fatal errors). Until maduin's LSLog addition,
litestep would quietly ignore modules that caused fatal
errors. And as such promoted bad quality code.
I was surprised to run some themes and see retro come up
with critical error message dialogs at 200 beats per minute.

Ok. I had a problem and could not imagine someone
trying out rs for the first time and experiencing that.
Anyway, retro now does not show a dialog anymore when
a module decides to go wild. It just writes it to the log
file with the highest loglevel that doesn't show a dialog.
(that should change in the future or by step.rc option)

And about exceptions, i added some new things.

1) retro catches fatal erros in threads other=20
than the main one.
2) not crashing is good. but when something hangs,
like a module (or windows) going into infinite loop,=20
it doesn't save you. So I added a feature to recover
from when retro is not responding.

Well, these features are hopefully only going to be
needed by those hacking on modules...

About hanging, tasks.dll can be a pain when an app is
not respoding (like when outlook is working with
my imap folders over my ssh tunnel).  I'm not going
to bother fixing it because I know jugg will not
respond if i send him a patch. Besides he seems to
have enough features for his next release...

Anything else to say?
Let's look in the Change Log...

Ok, i added some new built in variables. They really
should go into litestep too.  They are the registry
entris found at=20
HKCU\\..\\Windows\\CurrentVersion\\Explorer\\Shell Folders
with a "shell." prefix.
Here's some copy and paste from the !about box (err...
make tath "Information Console")

shell.desktop :=3D 'N:\Profiles\obada\Desktop\'
shell.favorites :=3D 'N:\Profiles\obada\Favoriten\'
shell.fonts :=3D 'N:\WINNT\Fonts\'
shell.history :=3D 'N:\Profiles\obada\Lokale Einstellungen\Verlauf\'
shell.local appdata :=3D 'N:\Profiles\obada\Lokale =
Einstellungen\Anwendungsdaten\'

I think it's worth noting that there are spaces in the variable names.
In this case i though changing=20
the names found in the registry was not only a programming =
inconvinience,=20
but could cause confusion. As a good side effect, it forces=20
enclosing things in quotes which is a good thing since the=20
expansions might very well contain spaces.

One very useful thing for themes could be for example:
"$shell.appdata$Microsoft\Internet Explorer\Quick Launch"
Things like this are mostly written in stone or expected
in $LitestepDir$Shortcuts\.


What I hope to do next...
Write a very generic library to be used by modules to get
rid of redundant coding and to have a consistent way of setting=20
module properties... i'll probably call it "retro toolkit" (rtk)
or "ls module tooktik" (lmk) if i ever get to it...
Of cource this will be done along with implementing a module
i'll call "erbar". These things will not be retro specific,
but use the litestep API only. just like lscrash.dll ;-)

Other than the things above, i've been going through the
code, documenting it, cleaning up, and restructuring stuff.
so that the code is left in good state before i leave it
alone. I plan to write some docs on how the core beast of=20
works so that someone looking at the source code can
make sense of it all.

And before I myself forget this, retro.exe is very small
and it uses only one function from lsapi.dll.  The idea
is to be able write a program that can be retro and a
shell/theme switcher at the same time... all of retro=20
is really in lsapi.dll and not in retro.

Gosh, lack of ls ml seems to have left me with some will
to write. look how long this thing turned out!
Or maybe it was because I told myself i should write it
even it nobody cares.


Anyway, the next retro version should be half way to
version 0.1 so I'll try not to change the sources
as radically as i have been doing...

What? you read all that? I have to ...