Re: Sugestions for AfterStep

Jeroen Asselman (
Mon, 10 May 1999 19:24:00 +0000 wrote:

> >Hello all...
> Hi
> >Dithering, something like windowmaker does. When using the gradient
> >option with AfterStep you can exactly see where one color goes into the
> >next color. WindowMaker uses some kind of ditering so you see one smooth
> >gradient. It just give a nicer look.
> Hmm, I run 16bpp and this sort of unpleasent thing only happen when you specify
> too short range of colors for gradient - so there are not enough colors to
> continuously
> fill the space.

Hmmm strange.. I thought all 16 bpp pallets were the same. Perhaps the XFree driver
for my card isn't doing the pallet 100 % correctly (I am pretty sure about this,
because when I make a gradient from black to white... It aren't always grey
values... Some are a little bit colored tinted). To bad, 32 bpp looks perfect
though...however than I run into another problem...

> Anyway if you have a desire to improve this - feel free to do so, the file you
> are looking for is
> asimagelib/stepgfx.c.

Ok, not sure how to solve the problem, as it looks like to me there is a function
which returns a value of a pixel...  Ok, I admit didn't take a thorough look at it

> >Modifiable borderwith of the startmenu,
> >Start module, window layout module so (a very small and stable?)
> >AfterStep only manages the modules. Adding features to differents
> >modules seems to me much easier than adding to one big file... All the
> >user input should of course be managed by AfterStep itself, and just
> >pass all the input it gots (even mouse movents (?) so we could make a
> >module to make a nicer mouse cursor) to the modules.
> IMHO this is very bad idea - AfterStep startmenu functionality also includes
> capability to execute all AfterStep functions, like "Exec" , "Wait", "Kill" etc.
> That also includes the very ability to start and stop modules :). So by moving
> all that
> into module we'll strip kernel of AfterStep to almost unusable, and greatly
> complicate
> module starting/communicating. That will sure look nice from the object-oriented
> scientific point of view, but will be very impractical.

Ok, drop it :-) ... Oh and what about the ability to set up a border with of the

> >A respawn option? If a module crashes or exists which never should exit
> >(like a startmenu module) have it restarted immediatly again.
> This is not a good idea too. If module is crashing - that is due to bug, bad
> configuration or insufficient system resources. In niether of these cases it is
> not desirable
> to respawn module automatically - you can easily  end up with your computer
> going berserk, and respawning as crazy some module that crashes right away.
> If module crashes - this is extreme situation, that needs to be reported to
> developers along with complete configuration and other details.

True, howeever for some programs a crash isn't that bad... as long as it restarts
immediatly and doesn't waste any memory.

> >second, (don't hit me) there is that little comment in most of the
> >sources I takes me a long time before I understand what happens (I once
> yep, we have inherited alot of sources written by different ppl in the span of
> many
> years - you can even find some original fvwm code in there. Most of them never
> had any comments, so yes - it takes a long time to understand what's going on,
> and how to change it. That was another reason why Alfredo Kojima started WM -
> so to start clean, without heritage of old code, that nobody knows. We try to
> add
> comments to the new code that we write as much as possible, and yes - if you dig
>  into something that is not commented - put your comments in and submit a patch.

OK, than I know something I can do ;-)

+--   Greetings, Jeroen            --+--  ICQ UIN : 4331855       --+
| E-mail: |    |
+-                                 --+--                           -+
  +--    Have a nice LinuX, currently running kernel 2.2.7      --+