> > That's what I am saying. You _have_ to schedule VT-switching. And if you
> > already have to do that, why not just have the application acknowledge
> > the request and all is easy and smooth.
> uh? Because it's not the same thing and because it's NOT TRANSPARENT!
Why does it have to be? The app has to specify anyway what it wants to do
in case it is switched away. If the app will just be halted, if it doesn't
handle the switchaway, this will do for 90% of apps.
> The whole point of kgi/ggi is that the app doesn't _know_ where it's
> running, so tying it with a specific target is the dumbest thing to do.
Huh? Don't get you there.
> > if (have_vtswitch_request()) {
> > backstore=ggiOpen("memory",...)
> > ggiSetMode(backstore,...);
> > ggiCrossBlit(currvis => backstore,...);
> > savedvis=currvis;
> > currvis=backstore;
> > }
> > If that's too much to write, we can put it in a lib.
> > But the _app_ knows when this can be called safely.
> look there: "vtswitch_request". So, does any ggi app have to implement
> that?
If it wants other than the default behaviour of "go to sleep if switched
away, get a redraw message on switchback": IMHO yes.
> Or will there be some ggi apps that run on kgi and other that don't?
???
The app will run in any case. Eventually with an unwanted behaviour at
switchback, if it is broken. And it will in that case be broken on any
target that can sitchaway and does not compensate internally.
> > If the app wants to run in BG, it should react nicely to being asked to
> > stop using the graphics engine.
> The app _doesn't_ have to care about where it runs, I should be able to
> run it on X and on KGI without having to touch one line of code. Your
> approach defeats the whole point of ggi.
Don't tell _me_ about the point of GGI.
But tell me why the heck it would make a difference in the code?
The app won't care if it was X telling it, that it has been iconified,
oder KGI telling it, that a VT-switch is pending. Same thing to the
app. If it wants something else than being stopped when switched
away, it may as well introduce some code stating what it does want.
> > Why does that need backing store? To avoid having to store its result
> > somewhere else?
> Yes, to avoid to implement a backing store itself: why do it when there's
> such a nice feature already implemented in the framework?
? You know about the memvisual - right?
O.K. - my final words to that thread:
If you really think that should be done, go ahead, implement it in KGI,
implement it in LibGGI and be happy. As long as it doesn't mess up
anything on any platform, it's fine with me.
But don't demand from others to code something pretty complex and hard
to port. I have once coded such a mess, and won't do it again.
EOD, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
