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 .
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.