Re: Re: about your concept
JP Dinger <[email protected]>
| Newsgroups | gmane.comp.graphics.y.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jul 18, 2004 at 06:50:09PM +0100, [email protected] wrote: > I don't usually play the part of Billy-goat Gruff, but anyway... > > Quoting Jost Boekemeier <[email protected]>: [snippety] > > > > Build all the regular desktop apps (file manager, > > > > You cannot start designing apps when even the basics are not > > implemented. > > That's a CGSM*. How do you know what you need if you don't have use cases? > It's a lot easier to build your apps with stub calls so you know what kind of > API is going to be useful *before* you invest a lot of time implementing. One thing is that you need a clear view of the field to know what generic use cases will pop up. But after 20+ years of /clickibunti/ programs there should be /some/ of that available. > > > Suspend/resume of entire Y sessions > > > > Not possible. > > Prove it. Mathematically. > > A truer statement would be "Very Hard". True suspend/resume, probably. Now that I think a bit about it, for starters something like screen does woulnd't be too hard to do. In the most simplistic form all you really need to do is have some stub keep state: when in detached mode, act as /dev/null, otherwise pass on the stream to whoever wants to see it. Oh, and the stub needs to signal a massive repaint-everything at reattach. That or keep a shadow image and send that as primer on reattach. Probably some detail I've missed, but one doesn't have to cross every bridge before reaching the first one. I'd say you get the ability to squeeze in that stub as a freebie with the protocol design (as I understand it, anyway). > > > XFree86/X.Org driver stealing. > > > > Huh!? What do you want to steal? (I am starting to think that this is > > a fake post, but anyway) Oh don't be so negative. Your not-understanding doesn't have much to do with Phil's post being fake or not. (I'm not saying I understand everything, or even anything, but at least I'm not pouting.) > If Y can talk enough like X that the accelerated X drivers can't tell the > difference, we get a massive amount of hardware coverage, without having to > worm the specs of card out of manufacturers. One of the things is that you really need to know how to talk X, and apart from the view that it's baroque, not many people do. I for one don't. If you do, great. How bloated /is/ the accelerated X driver protocol, anyway? Don't answer, I don't really want to know. I can't do a thing with the knowledge ATM anyway. [snip] > * See "Yes Minister" Series 1. One of the great things I yet have to see. I've seen some parts, but not all, so not enough. :-) Anyway, I'd say welcome and well met to you phil, but that doesn't justify the morose silence on the list at large. You sound like you've got at least half a clue and some fresh ideas. Good. Now you'd better grow a very thick hide very quickly or you end up sour and silent like the rest of us. Don't get me wrong, I do appreciate your effort and ideas, but be wary that while the foundations are utterly cool, there does unfortunately not seem to be much of an environment to nurture and grow the ideas in. -- j p d (at) d s b (dot) t u d e l f t (dot) n l .