Index: [thread] [date] [subject] [author]
  From: Osku Salerma <osku@iki.fi>
  To  : ggi-develop@eskimo.com
  Date: Mon, 19 Jul 1999 17:26:55 +0300 (EET DST)

Re: Patch for disabling ggi messing with X's cursor

> Osku Salerma wrote:
> > 
> > I have an app that uses a small 256x256 window in addition to a normal
> > xterm for displaying some data graphically, and also for getting mouse
> > clicks. However, the normal ggi behavior of setting the cursor for the
> > window to some ridiculously small dot that's almost impossible to see
> > is rather bizarre. What's wrong with keeping the normal X cursor as it
> > is?
> 
> Your question is incorrect. The correct question is "why is the cursor
> not completely invisible?". And the answer is that when starting to
> move the cursor out of the GGI window you can see it before it exits
> the window, which gives you better precission. This is the only
> reason we have a visible X cursor at this time, and the reason it is
> so small is that it shouldn't disturb the application's real cursor.
> 
> All targets don't support hardware cursors. Even when the infamous
> cursor extension is written applications will still have to implement
> a software cursor to work on targets that doesn't have a hw cursor.
> Start with the software implementation, and then when the cursor
> extension is ready you can take advantage of it if your application
> benefits from that.
> 
> Ofcourse anyone is free to mis-use LibGGI in whatever way they want.
> But it was designed to inspire portable applications that will run
> with full functionality everywhere, and no patches which contradicts
> this goal without adding substantial value will be accepted.

But the point is that my application uses the graphical window just as
a _bonus_ representation of some data, and the real program runs in
the text-console (xterm or whatever), and you can disable the graphics
altogether if you want with a command line switch. You _can't_ even
think about running the program in targets that only support
full-screen modes. So that leaves windowed environments. And I have
yet to see a windowing environment that doesn't include a mouse
cursor.

I don't see why every single ggi application should do its own
cursor-handling if there is a very simple way of telling ggi "don't mess
with the cursor, I'm happy with the default one".

Your main argument against it was, if I understood correctly, that a
program written with "-defcursor" won't work on targets without hardware
cursors. But as we saw, it won't work on them (ie. non-windowed
environments) even if I _did_ implement my own cursor handling.

I do agree that having "-defcursor" type flags around can seem a
little klunky. Perhaps a more preferable approach would be something
like:

ggiAddFlags(vis, GGI_DONT_CHANGE_CURSOR);

That would be portable across all targets, and is cleaner I agree. I
just thought of this and haven't looked at how hard it would be to
implement, so before I do, could you comment if I should bother or
does this one have no chance of getting in either?

GGI is such a great library to use for all my graphics needs that it'd 
be a shame if we can't agree on a way to let me have X's own cursor
over ggi-windows. That's hardly an unreasonable thing to ask, now is
it? Especially since it isn't even code bloat, it's the opposite
actually..

Index: [thread] [date] [subject] [author]