Re: Re: about your concept

On Sunday 18 July 2004 2:55 pm, JP Dinger wrote:

> 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.

With Y, the application doesn't "draw" anything. The server does. As stated in 
Mark's Theses (IIRC) the process of reattaching would simply be sending the 
server what widgets you have among other things. The server does all the 
drawing as well as buffering. It's easy to forget that.

In its most simplistic fassion, Y is this:
The application tells Y server to draw a button and notify the application if 
anyone clicks it.

Granted there are much more subtle details to this, all the graphics happen in 
the server.

> I'd say you get the ability to squeeze in that stub as a freebie with
> the protocol design (as I understand it, anyway).

Yeah, that's in Mark's Thesis too how that will work.

> > > > 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.)

Stealing drivers would be as simple as calling the right functions in the 
drivers and providing the propper methods for drawing everything.

With Y's modularness it shouldn't be hard to provide a proxy driver that 
simply wraps around to other calls, although even a simple wrapper driver 
might slow things down.

> > 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.

You don't really need to know how to talk X, you need to know how to talk X 
drivers. The drivers really just draw crap on screens, they don't worry about 
the protocol at all. Unless the drivers are really that bloated :p

> 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.

Haha, you noticed that too :) I think we just need a few people to lead 
everyone into development than have everyone telling everyone else how bad 
their idea is. I'm guilty of it too, but I don't have much time for anything. 
I have a lot of other things to worry about in my life. Y is on the back 
burner for now...

-- 
James Harr <[email protected]>
http://www.grickle.org/