> On Tue, 21 Jan 2003, Andreas Beck wrote: > > > The app has to specify anyway what it wants to do > > in case it is switched away. > > Yes, and often the app might want to _continue_ working even if it's > switched away.
That's the case, _if_ the application catches the signal. > > If the app will just be halted, if it doesn't > > handle the switchaway, this will do for 90% of apps. > > Halting the app won't solve the problem anyway: how do you handle halting > when a VT switch is requested right in the middle of a piece of code which > is writing to gfx card registers? That's an issue, that can be solved within the GGI target: Catch the signal, and wait until the accel is idle or in any other interruptable state (Note, high-end graphic hardware supports context switching in hardware and thus don't need to be really idle). > What's difficult to get? The user should be able to make the app run on > whatever target is available, even > yet-to-write-ones-with-very-special-features, so having to write specific > code for specific situations which arise only with specific targets > defeats the whole point of ggi. If you are missing a graphic resource management system, then please check out http://www.ggi-project.org/xmldoc/bk01pt03ch05.html and follow the 'next' links. :) > > > 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. > > the "switch away" event is kgi-specific, No. All console based targets as svgalib (Linux), vgl (FreeBSD), aalib, vcsa (Linux) and fbdev (Linux) have this "switch away". > on windowed systems when you switch an app away, the app > is not put to sleep! ... because there's an central management system being able to obtain the drawing operations. > > > 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. > > Uhm? Sorry, but I know the point of ggi very well too. Fabio: Andreas is the GGI founder, in case you don't know... :-)) (Sorry, wouldn't blame you...) > > 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. > > Maybe I haven't been clear enough: what I don't like is the fact that the > app gets put to sleep. [...] > ... but don't tell me that the right solution in case it doesn't > understand that is to put it to sleep! This behaviour is not a mandatory. It is the default option. If you don't like it, then just catch the signal... :-) > AROs takes advantage of accelerated X functions: if it has to write in a > backbuffer first it couldn't take advantage of such functions. You can't use accelerated drawing functions, when the app is switched away, independent whether it is put to sleep or not. Yes, the X apps continue to run, when iconified. But do you really believe, that X still uses accelerated drawing functions? In particular, when there's no more onboard gfx RAM available? > I don't _demand_ anything! We were just discussing design decisions, > weren't we? GGI and KGI is yours, far from me the idea of imposing design > decisions, I just thought I'd spend my 2 cents and say something about the > topic too. well... then thanks for the flame war. :-) Can't remember, when there was such a heat discussion the last time on this list before... :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr f�r 1 ct/ Min. surfen!
