From: Osku Salerma <osku@iki.fi>
  To  : ggi-develop@eskimo.com
  Date: Tue, 20 Jul 1999 00:27:52 +0300 (EET DST)

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

On Mon, 19 Jul 1999, Marcus Sundberg wrote:

> Osku Salerma wrote:
> > 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. 
> 
> Sure you can. There are multihead systems, serial consoles, and
> telnet connections. This is exactly the flexibility LibGGI tries to
> make applications conform to.

I'm not sure what you mean by "serial consoles", but I don't see how
telnet connections are somehow special. Why wouldn't it work if you
telnetted to a machine, started the program, and the X window
displayed locally?

> > 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".
> 
> Even though LibGGI apps will run fine in an X window LibGGI is primarily
> a fullscreen graphics library, and this is reflected in the API.
> From the application's point of view the X window is the "full" screen.

Yeah, I've definitely noticed the full screen bias. But it just shows
how flexible GGI is that it can be used for things that it wasn't
originally meant for. I love experimenting with graphics stuff in
whatever pixel mode works best for the test program, and just using
trueemu or palemu to get it to display on my normal 32 bpp X server in
a window while I'm debugging and tuning it, and then starting a second
X server in the right bpp and setting GGI_DISPLAY=dga and seeing it in 
fullscreen once it's working.

But when's all said and done, using GGI is the easiest way by a large
factor to show some graphics in X. Especially non-speed critical
stuff, just create a memory visual in whatever format is easiest for
your app to work with and crossblit from it to the X visual.


And I agree with the someone who said this some time ago, release the
damn thing, won't you...I tried libGGI over a year ago, but it
basically didn't work. I couldn't get palemu or anything working, the
svgalib wrapper didn't work, I couldn't get any use out of it. Forgot
it. Then a while later a newer beta came out, decided to give it
another shot. Everything worked. I converted every single one of my
old svgalib apps to it with practically zero effort, and can now for
example play an old space commander clone of mine again. I hadn't been 
able to run any of those apps since svgalib doesn't support any modern 
cards.

So you're sitting on a great library, and I wish you'd properly
release it so it'd be included in distributions etc. It's certainly
been release quality stuff for everything I've used it for.

> The correct way to do this is to add a "default cursor" to the
> cursor extension, which will use the native cursor appearance when
> running in a window.

Sure. But my patch is basically one if-clause added to
display/X/mode.inc, is ready now, and works. By the very definition,
an "extension" is way more code, and while more general, provides no
benefits in this particular instance. Add in the fact that the
cursor-extension is very much vaporware, and likely to remain so for
quite some time (haven't seen much progress in the way of new features 
for libGGI lately, another indicator that it should be released since
it seems to be done).

> The reason I'm against this hack is that if people see that there
> already is a cursor they will not properly implement support for
> the application to run on any target. Programmers are lazy, and no
> docs or guidlines in the world are going to change that.
> 
> We have taken very good care to ensure that all system dependent
> weirdnesses are hidden behind a simple to use API, and to simplify
> things for the application programmer whereever we can. But in doing
> this we never sacrifice ease of use and flexibility for the end user.

Can't think of any convincing arguments here. You're right, but I
don't feel that makes me wrong. All targets are equal, some are just
more equal than the others..And if your app is targeted purely at
target foobar, nothing wrong with taking advantage of target foobar's
special features. If some end user is really pissed off because he
can't run it in his favorite target (not a problem with my app, just a 
reminder), he can write a patch and submit it to the program author.

--
Osku Salerma - osku@iki.fi - http://www.iki.fi/osku/
Save the whales. Feed the hungry. Free the mallocs.