> > A caveat for other ports: Due to the change in the dynamic loader that allow
> > for static linkage by having different init-function-names for each
> > library, you got to take care, that the library-basenames are legal
> > function names in C.
> >
> > Marcus: Shouldn't we provide name-mangling as in [^a-zA-z0-9_]=>"_" ?
> I prefer restricting sublib names to those letters. There's no real
> reson to use any other characters anyway, and the fewer we allow
> the more compatible with different filesystems we get.
O.K. - valid point. So we should simply document it somewhere.
> > Resizing doesn't work anymore. I assume this is due to setting some hint
> AFAIK it never worked, due to exactly those hints.
Hmm - I'm pretty sure it did once - I wouldn't have put such extensive tests
in for that areas, if it hadn't. Of course it only reset the window frame,
nothing inside.
> > It actually is a good thing - we should rework that one to not try to
> > interact with X directly, but rather have it send a "fake" gii-resize
> > event.
> Application-requested resize is useless, as it is the same as a
> SetMode.
Yeah, but I thought it would be nice to have it work the same way as when
a change is requested form the outside. Resetting the mode is a "heavy"
operation with respect to updating quite some stuff, so I think it would
be good, if there is only one place in the application, where such a
request is actually _processed_.
> What we should provide functionality for in LibWMH to allow
> user-resizing of the window, ie remove the size hints and
> send gii-resize when the window changes size.
Yeah - o.k. I'll try to take care for that.
> I believe normal size-changing by users is the last feature missing to be
> a complete and better alternative to writing native X-programs.
Yeah ... seen quite some and most of the non-toolkit programs break in some
way when you have strange framebuffers underneath ...
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
