[Top][All Lists]

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

Re: [xougen] con of server side widgets

From: William Lahti
Subject: Re: [xougen] con of server side widgets
Date: Wed, 10 Sep 2003 19:24:40 -0400
User-agent: KMail/1.5

On Tuesday 02 September 2003 11:17 am, address@hidden wrote:
> On Mon, Sep 01, 2003 at 12:08:20PM -0400, William Lahti wrote:
> > How would we handle animated widgets on the server side?
> 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.

> For example we could define such things in similar way like CSS
> works on Websites. Such a description for a button widget could
> look like this in an text presentation (which of course is not
> necessarily that what goes over the net ...):
> BUTTON.button1
> {
>     border:           1px solid black;
>     border-decoration:        3dbox;
>     font-color:               black;
>     font-weight:      bold;
>     padding:          2px 2px 2px 2px;
>     background:               solid grey;
> }
> BUTTON:FOCUS.button1
> {
>     border:           3px solid black;
> }
> BUTTON:HOVER.button1
> {
>     background:               solid lightgrey;
> }
> {
>     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...

> 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. I do like 
the idea of having perhaps a Stylesheet resource or whatever. Perhaps because 
Im an object oriented person.

> Such an stylesheetet widget engine could be implemented on many sides,
> i.e. as server module (controlled by an appr. protocol extension),
> as an client lib (i.e. gtk-like) or as an separate application, controlled
> by another protocol (i.e. for web-widgets).
> All variants share the same idea and styling scheme.

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.

> <snip>
> > again, I don't think it would be bad if there were a dedicated widget
> > server that produced a pixmap of a widget based on a list of properties.
> This should only be _one_ variant (i.e. to enable displaying of widget-
> based applications via web but w/o java applets), but if the server
> supports this, it would be quite a benefit especially for low-resource
> environments.

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

> > Simple enough? We could begin doing this now, without any changes to the
> > X server and get a very similiar result to adding a bunch of new code to
> > it. The widget server could be distributed with Xouvert.
> ACK.
> This would be an good starting point. Someday we'll have it stable enough
> to think about a direct integration into the Xserver and perhaps creating
> an new extension of the X protocol.

Perhaps if we can find solid benefits to putting it into the X server, sure.

> > will volunteer, but is any one else interested? Im guessing you'll need
> > to know C and socket programming (as well as some X stuff for using
> > shared pixmaps if available).
> I'll be with you :)
> Since it is not really (yet) an X project, we should move out to a separate
> list and only post regulary reports to this one. I'd offer to host it,
> for me its an job of 1 minute ...
> At this point an important job would be aquiring new developers for this
> project. There are some similar projects out there, which we could ask
> to work together with us. Could you contact them ?
> cu

If you have hosting resources that could be used to host an arch repository, 
then I think we're good. I think we should still discuss it here unless 
someone thinks otherwise (for now).

I will spread the word and look for some interested developers.

William Lahti, aka xfury

$ /usr/games/fortune
The camel died quite suddenly on the second day, and Selena fretted
sullenly and, buffing her already impeccable nails -- not for the first
time since the journey begain -- pondered snidely if this would dissolve
into a vignette of minor inconveniences like all the other holidays spent
with Basil.
                -- Winning sentence, 1983 Bulwer-Lytton bad fiction contest.
$ uptime
 19:12:42  up 1 day,  2:25,  2 users,  load average: 0.02, 0.33, 0.48

reply via email to

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