Hi Brian,
> > - Why do we use that complex X font structure which will also cause
> > problems for depths below 8, when we could just convert it once and
> > for all in misc.c to a bitmap format of our own?
> The X font structure is used so that the backbuffer can be updated
> to mirror the front-buffer even though the front-buffer is drawn
> with the XPutString primitive and the back-buffer is drawn directly.
Yeah. But all we need for it, if a Bitmap of the Font. We can then
just build a ggi_color array with fg and bgcolor and PutBox it.
That will work regardless of depth etc. and not require that strange
bitshuffling that - as you already say - will only work in specific
cases when operating below 8bpp.
> Unfortunately there's no way to call XPutString on a RAM buffer.
> In order to do it the other way and still use XPutString, we would have
> to somehow install our bitmap font into the X server.
No - what I mean is: Do exactly as you did, but don't grab the font into
that xfont-struct, but into a simple bitmap of our own design.
As this is a run-once thing, it doesn't matter to have a little more
work to do there.
That would simplify blitting the font to the backbuffer to something
along the lines of
for(y=0;y<h;y++) {
for(x=0;x<w;x++) {
colarray[x+y*w]=(font[c][y][x]) ? fgcolor : bgcolor;
}
}
ggiPackColors(...);
ggiPutBox(...);
> I seem to have either accidentally deleted or never received your original
> bug report... could you send another copy so I can investigate it and see
> if I can replicate it?
You already fixed it, but I'll send it along anyway in PM.
> > - Input events now only come from inside the displayable area. This is
> > disturbing for me in 2 cases:
> > a) I cannot move the cursor to a border to have it out of the way and
> > still send keys to the app.
> > b) When using libggiwmh to make the window resizeable, the newly
> > created area will not accept events until the window is resized
> > with a setmode.
>
> I think this is a WM problem, but that of course doesn't get us off the
> hook for fixing it.
Not really I think. Old LibGGI X target behaved fine with that. I suppose it
is due to the use of an inner "clipping window".
> I haven't looked intpo it deeply enough to propose a solution... I thought
> I had improved it a while back by changing the window from which events
> are received to be the parent window,
Yes. At least that is what I suspect to be the difference.
> but I'll have to check the CVS logs to verify if that ever got committed.
Please do. I'm pretty confident, that this might fix it. The window
does just as it should: it clips.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
