On Tue, 13 Sep 2005 09:18:14 -0500 Brian writes: > Jose O Gonzalez wrote: > > >On Mon, 12 Sep 2005 14:58:51 -0500 Brian writes: > > > > > >>Raster, > >> > >>I've been noticing that we often want to accept generic evas mouse > > >>events on edje objects (such as ibar icons, pager windows, pager > >>desks, > >>etc). So, we've been adding event objects and moving/resizing them > > >>along > >>with the edjes and setting cb's on those. As this becomes more > >>frequent, > >>it becomes an overwhelming duplication of code, and makes things a > > >>little tricky when stacking is involved (pager wins e.g.) > >> > >>So, I was wondering if we could wrap all this event object > business > >>up > >>in evas' smart object code so we don't have to duplicate it all > the > >>time. So, when an event cb is added to a smart object, we would > >>(unless > >>one already exists) create an event member object, and add the > >>events to > >>_that_ instead, and add the necessary hooks to keep it following > the > >> > >>rest of the object properly. > >> > >>This would make smart objects behave even more seemlessly like > >>primitive > >>evas objects, and would only add the extra object overhead in the > >>case > >>where someone has actually set a cb on the smartobj (which means > >>they > >>would be adding their own event object without these changes). > >> > >>Any objections to adding this in at the evas level and saving us > all > >>a > >>ton of work at the higher levels? > >>-- > >>rephorm > >> > >> > >> > >> > > > > This is in part one-half of the issue I tried to raise > >earlier in my email regarding "Smart Objects"... and it's the > >tougher half. > > > > One might not really 'need' to add "event objects" to > >a smart object - smart objects themselves could be made to > >"feed" events, "respond" to events, etc.. > > Right now, they do little of this since they are not > >considered to be in the list of 'event-objects' that the pointer > >lies in, even though they can be set, or not, to "pass" events.. > >a somewhat complex state of affairs. > > > > Making smart objs "own" their member objects, thus helping > >to solve some stacking-order issues, raises the other question: > >What then for event-handling? > > > > Should the current model be maintained? Or should smart > >objs attempt to have the same event model as say one sees in > >window systems? > > > > > > Jose. > > > > > I guess one possibility would be: > > When an event cb is set on a smart object: > 1) store the request callback function in the smart object > 2) set an event cb on all of the member objects with an evas > internal cb function > 3) in that internal cb function, call the callback set on the > smart obj > > That would eliminate the need for event objects, and would limit > events > to areas actually covered by a smartobj member (instead of the > entire > smartobj bounding box). > > -- > rephorm > > [BTW - recall that in general there's no constraint relating the geometry of a smart object to the visible geometrical extent of its member objects] It's a nice idea, and would likely go far to solve the problem you're facing (something like this is already done if the member objects have no callbacks set on them). But I wonder how well it will work without the smart objects also being able to "feed" events, etc.. ie, without their full support for the general event mechanisms. I believe that these kinds of issues will continue to crop up unless the underlying model around smart objects gets a clear and consistent semantics - internally, for many of the general object related functions, smart objects are functionally just 'not there'. Smart objects attempt to span a large spectrum between simple "container" or "group" like structures, and something like a full "sub-canvas" structure.. and to do so as actual canvas objects. Not an easy task. Given an evas, one can have "evas-objects", ie. an object of the given evas from which one can obtain another 'underlying' evas (one which you would not need to get/set any engine info structure) and add whatever evas primitives to that 'sub-evas', etc.. Such an evas-object will display its sub-evas on the initial given evas. But the objects of that sub-evas are not 'actually' objects of the initial given evas. By contrast, the members of smart-objects (of a given evas) 'are' objects of the given evas. I have the feeling that unless smart-objects adopt most of the semantics that is used in window systems (in dealing with the parent/child relationship), it is likely that they will continue to be 'problematic' in one sense or another, for someone or other's needs or expectations.. :( Jose.
I'm not very familiar with how evas or smart objects are currently structured,
but since you are looking for mechanisms for structured event handling
I was wondering if any of you have thought about using statecharts?
I work alot with statecharts in my workplace (mostly a GSM Car alarm) and have been very curious about
implementing statechart behavior in a GUI or graphics related stuff...
To be honest, I am rather interested in what people who actualy write a GUI think about statecharts in general...
:p
|
Rodolfo Hansen Ing. Desarrollo Aurora Wireless Ltd. Calle Plaza #23, Mirador Norte Santo Domingo, Distrito Nacional, Dominican Republic. Phone: +1 (809) 531-3166 Fax: +1 (809) 531-3550 Email: [EMAIL PROTECTED] |
