Re: Sugestions for AfterStep

Jeroen Asselman (j.asselman@writeme.com)
Mon, 10 May 1999 19:17:57 +0000


Sasha_Vasko@osca.state.mo.us 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.
> Anyway if you have a desire to improve this - feel free to do so, the file you
> are looking for is
> asimagelib/stepgfx.c.
>
> >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.
>
> >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.
>
> >Clean up the todo list ... It looks like some things are already
> >finished and still on the todo list.
>
> yep, last time we did that was in December ;)
>
> >I would of course like to add these options myself if I could. However,
> >I don't know if the devellopers would like these extra thingies... And
>
> we sure are wellcoming any help. If you are ready to submit a patch -
> read doc/code/patch file on detail about how to make one. We generally
> use the following scheme :
>
> 1) you should have 2 source trees:
>      AfterStep-current - with original code
>      AfterStep-devel     - with code modifyed by you
> 2)  Add entries to ChangeLog
> 3)  run tools/makeasversion  from the devel source tree
> 4)  run make config to update configure
> 5)  run tools/makeaspatch
> 6)  submit patch to David Mihm, by uploading it to ftp.afterstep.org.
> that's it :)
>
> >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.
>
> >wanted to make some modifications to the Animate module, and it took me
> >some hours before I finally could add the option I wanted ....). I
> >myself always try to add comments for at least every function and if
> >possible every line I program so someone who has never seen the program
> >should be able to read my comments to see what happens. I don't want to
> >learn the devellopers a lesson. (Ok, this is probably wasn't correct
> >English) I just want to make my point.
>
> /me agrees
>
> >+--   Greetings, Jeroen            --+--  ICQ UIN : 4331855       --+
>
> Sasha
>
> --
>    WWW:   http://www.afterstep.org/
>    FTP:   ftp://ftp.afterstep.org/
>    MAIL:  http://www.calderasystems.com/linuxcenter/forums/afterstep.html

--
+--   Greetings, Jeroen            --+--  ICQ UIN : 4331855       --+
| E-mail: Jeroen.Asselman@pemail.net | etv.hshaarlem.nl/~jeroena    |
+-                                 --+--                           -+
  +--    Have a nice LinuX, currently running kernel 2.2.6      --+




--
   WWW:   http://www.afterstep.org/
   FTP:   ftp://ftp.afterstep.org/
   MAIL:  http://www.calderasystems.com/linuxcenter/forums/afterstep.html