[prev in list] [next in list] [prev in thread] [next in thread] 

List:       berlin-design
Subject:    Re: [Berlin-design] Some Ideas or better Questions
From:       Nathaniel Smith <njs () uclink4 ! berkeley ! edu>
Date:       2001-07-13 8:43:25
[Download RAW message or body]

On Fri, Jul 13, 2001 at 08:42:55AM +0200, Christoph Hinterm?ller wrote:
> Hi
> No i do not  mean the Keypress or the mousemovement it selve but rather the
> resulting callback call when talking about event propagation.
> So talking in terms of callback calls:
> Assume one event triggers multible callbacks to the same client in sequence
> OR assume two or more coinciding events activating the specified 
> callback each
> 
> 
> 
> Is ecah of the callback requests deliverd separatly to the client or is it
> possible to group the requests and sent them as one bundled request,
> which is splitup into the single requests by the client before executing 
> the callback??

No, this doesn't make much sense in Berlin's architecture.  As far as
the most of the server is concerned, there are no clients, just CORBA
objects.  (As it happens, many of these objects are controlled by the
client, or are actually running in the client's address space, but the
server doesn't know that.)  If an event triggers a callback, then the
callback (which is basically just a method the button was given when
created) is called like any other method.  (To see the details of
this, check out the Command interface in Warsaw).

> OR assume the cleint wants tor reset the state of a lot of 
> butons/toggles/tickboxes/...
> Is there each set/reset request(callback) sent separately to the server or
> can this request sent as one collective???

Again, there isn't any realy concept of a link, so there's no real way
to aggregate things before sending them down it.

> OR assume an event which cause multible changes on the server and in the 
> client like a global
> reset buton affecting the content of textboxis/the labeling of 
> buttons/and the state of toggles/...
> is this event handled as reset callback to the client which does all its 
> necessary resets
> and during them issues resets to the GUI. Or can the client tell the 
> server which gui elemnts can
> be reset to which default values without bothering the client, so that 
> on a global reset
> the server does the gui reset for the mentioned elemnts while client is 
> in the reset callback???

Well, I suppose that if Berlin ever implements a server side
"Config Entry" widget that includes a default value and a
ResetToDefault Command, one could build a server-side MacroCommand
that called all the ResetToDefault Commands in a row.  Normally,
though, the client would just change things.

Why is this sort of aggregation important?  Does it make a difference
whether you send a bunch of things in one big packet, or send a bunch
of little things in packets right next to each other?  I guess it
matters if there are latency issues, and the ability to send
asynchronous update requests (kinda like CORBA's "one-way" calls) is
a lot of what X uses to stay fast, but presumably in Berlin these
calls are so rare anyway that it makes little practical diffence.

> cu
> Christoph
> 
> 
> > I'm not sure we're calling the same thing "events".  The events under
> > discussion are input events -- things like "the user pressed the
> > letter 'a'", or "the mouse just moved .34 units to the left".  The
> > question at hand is how to represent these in a general way (so when
> > someone else later wants to say, "the 3d-glove just moved .42 units left,
> > .91 units up, and .69 units forward, while crooking the second joint
> > of the 4th finger to 34 degrees", we don't have to rewrite
> > everything).  You seem to be thinking of events as being more like
> > GTK+'s signals, which are used to do everything.  In Berlin, things
> > like button presses simple execute a callback, possibly on the client
> > side --- if this callback then decides to do some more work, it can.
> > There don't really exist change requests to _be_ propagated one by
> > one.
> > 
> > Raw GL rendering isn't something that we really know how to do yet --
> > presumably there'd be a special Graphic with an out-of-band connection
> > to the client to transmit the GL calls.  I don't know how input events
> > would work with this -- the GL Graphic would receive them like any
> > other Graphic, but it might need to do special handling (eg, taking
> > into account current viewpoint before reporting the location of a
> > mouse click).  There shouldn't be anything particularly special about
> > making this work, though.
> > 
> > -- Nathaniel
> 
> 
> -- 
> THESIS:     God is alive
> PROOVE:     Who else would have scheduled the mankind and world first
>              recommendation of research????
> CONCLUSION: Scientists do what he wants, willing or not:)
> 
> 
-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."

_______________________________________________
Berlin-design mailing list
Berlin-design@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/berlin-design

[prev in list] [next in list] [prev in thread] [next in thread]