On Tue, 21 Jan 2003, Andreas Beck wrote: > > > 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?
Just a design decision. The more transparent something is, the less code one has to write, and maintainability is higher. > 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. > 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? Either you use mutexes, or you save the gfx card's state (if possible at all) to restore it when the app is witched back again. So, you see, you gotta do that kind of work anyway. > > 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. 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. > > 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, on windowed systems when you switch an app away, the app is not put to sleep! That's what I mean when I talk about design decisions: the programmer doesn't have to care about target-specific issues, it should all be handled transparently. > > 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. !! It's not the app that is broken, it's the design that is broken! > And it will in that case be broken on any > target that can sitchaway and does not compensate internally. I'm not aware of any other target that puts to sleep the application when it's not visible. If such target exists, then it's really broken. > > 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. > 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. It's fine with me that you don't want to implement backing store, as long as the app gets notified that it has to refresh itself, but don't tell me that the right solution in case it doesn't understand that is to put it to sleep! > > 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? AROs takes advantage of accelerated X functions: if it has to write in a backbuffer first it couldn't take advantage of such functions. > 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. 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. Fabio Alemagna
