[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] con of server side widgets

From: weigelt
Subject: Re: [xougen] con of server side widgets
Date: Thu, 11 Sep 2003 02:05:01 +0200
User-agent: Mutt/1.3.27i

On Wed, Sep 10, 2003 at 07:24:40PM -0400, William Lahti wrote:

> > What kind of animation do you have in mind ?
> >
> > If you're talking about such things like buttons changing colors
> > when mouse moves over them - this could be handled quite good.
> No, I mean maybe throbbing widgets, or if we get fancy, buttons with 
> champagne bubbles floating up.
Do we need such things ? What rate of the relevant users / applications
would use this ?

I dont think, they're much enough for taking care of them - they can
still use the "old style".

> > BUTTON:PRESSED.button1
> > {
> >     border-decoration:      3dbox inverse;
> >     background:             solid lightgrey;
> > }
> Actually, that is in fact what goes over the network in an HTTP request. But 
> you mean in X11. Yes, I couldn't imagine any other way of doing it the way 
> you describe...

hmm, well, we're not limited to using such an text presentation. a binary
encoding of this information (perhaps heavily reduced/compressed) could make
it much faster. i.e we do not need to let all attributes be named in
cleartext, but with constant IDs (think of DNS <-> LDAP).

> > This stylesheets could be stored as resouces on the Display Server,
> > as well as other things like pixmaps. Each widget or group may
> > reference its own stylesheet.
> What is wrong with using a seperate widget server to do this stuff. 
Well, with an external server we still have the small pipe between the
widget server and the xserver, so we dont get a better performance - even
less, because it goes through one more process. It could help something
in network environments with low bandwidth (i.e. via modem line), where
the widget server sits on the same machine as the Xserver.

But also brings us another heavy problem: if we use an separate widget
server, this is the one who plays Xclient, not the client application. 
So we either have to tunnel all normal X functionality through the 
widget server or simply have to live without it.
(or is it possible to let multiple Xclients share windows ?)

> What you describe (having a lib on the client side and an impl. on the server 
> side) is much more attainable if the extraneous library is required to use 
> the widgets. Because the library can alternatively render the widgets 
> directly if a widget server is not available etc.
Yes, thats what I want.
In practise this lib would be in fact multiple libraries:

1. generic widget handling
2. client side widget handling (as xclient) -- lets call it emulation ?
3. xwidget client lib (uses ext-widget)
4. server side xwidget extension
5. libxwidget (as multiplexer to 2.+3. - will be imported by applications)

> We do not want to reimplement this stuff all over the place. So, considering 
> your ideas, the core functionality (server and client) should be in at least 
> two libraries (ie libuiserver, libuiclient or whatever).
Yes. Shared as much as possible, i.e. the rendering, stylesheet engine, ...

> If you have hosting resources that could be used to host an arch repository, 
> then I think we're good. 
What do I need for arch ? I've never used it.

> I think we should still discuss it here unless 
> someone thinks otherwise (for now).
Okay, if evrybody aggrees, we'll stay here.

> I will spread the word and look for some interested developers.
Great :)
What we now need most, ist HR ...

 Enrico Weigelt    ==   metux IT services

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     address@hidden
 cellphone: +49 174 7066481          
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]