> 1. The X target seems to use a proportional font now.
I was wrong on that. However it is using a 6x13 font now. I have fixed my
app to properly check the font size now, but:
The font size cannot be determined before the mode is set, which is pretty
annoying, as I want to size a window to hold 5 Lines of text ... Code
snippet:
state.info=ggiOpen(NULL);
[...]
ggiSetFlags(state.info , GGIFLAG_ASYNC);
ggiGetCharSize(state.info,&metastate.ggifontsizex,&metastate.ggifontsizey);
fprintf(stderr,"CS: %d %d\n",metastate.ggifontsizex, metastate.ggifontsizey);
err=ggiSetSimpleMode(state.info,320,
metastate.infoheight*metastate.ggifontsizey,1,GT_AUTO);
ggiGetCharSize(state.info,&metastate.ggifontsizex,&metastate.ggifontsizey);
fprintf(stderr,"CS: %d %d\n",metastate.ggifontsizex, metastate.ggifontsizey);
This snipped says on stderr:
CS: 8 8
CS: 6 13
I suppose you get the point ...
My application recovers nicely, as it resizes and reallocs windows on the
fly anyway, but others might be less lucky.
If at all possible, it would be nice to have ggiGetCharSize information
available before mode set. And we should document if it can be called
on a visual that doesn't have a mode set.
As I can clearly see the problems with that, I would suggest that we just
clearly document, that
a) Font sizes _have_ to be queried, as we really use different fontsizes
for different targets now
b) Font sizes are only available after modeset, and that applications
will have to resize/reset modes accordingly if they want to e.g. open a
window with exactly 5 Lines of text in it.
Obviously b) might induce recursion, so we should probably warn users
about that or define a clear policy abou if and how far recursion can go.
> 2. LibWMH is totally broken for me. This seems to be a binary compatibility
> issue, as the demo runs fine.
O.K. - got that one. Library name changed from libggiwmh to libwmh.
I am usure what I prefer. However for compatibilty reasons I would suggest
to place symlinks to emulate the old name libggiwmh for some time.
> using the current LibGGI. Issues are: Setting window title does not work at
> all, as does window positioning. For some strange reason reading windowsize
> also seems to get wrong, which makes a window as big as the screen as soon
> as I check and update its size.
All solved by cleaning up the mess that rose form the name change (old
library loading and calling new targets and stuff ... ).
> 3. One of my applications doesn't correctly update its windows. It draws a
> picture and then a crosshatch above it and a small figure that can be moved
> together with the crosshatch. Moving down works fine while moving up/left
> leaves old crosshatch marks on the screen.
That seems to be a real bug. The picture is set by calling ggiPutPixel,
while the crosshatch is drawn using ggiDrawHLine and VLine.
The Fun Thing is, that when I turn off the crosshatch everything is fine.
When turning it back on, everything below the HLine stops updating - the
VLine as well as the PutPixels.
Another issue is seen when running a multithreaded part of the app:
A visual is written to by two threads, each one calling
ggiFlushRegion(state.visrender,0,y,rarg->w,1);
for each line the thread has rendered.
Funnily I test on a single-proceessor system, and I observe that only the
_SECOND_ thread I start sometimes (about 1/3rd of the lines) fails to
update the line. This isn't strictly critical, but pretty ugly.
Hmm - just looked around a bit ... can't find anything in the X target code.
Maybe too tired. Will look deeper tomorrow.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
