I have thought about b) for quite a while now. Ignoring the implementation details (which can be hairy depending on the platform), this solution only works for untyped listeners. Is that good enough? I don't think that a) or c) are in the cards because they break API by breaking behavior. Put another way, it we start sending events when properties are changed programatically, Eclipse will go down in flames.
I'm wondering if there is some kind of filter API that could be added that would leave all of the current behavior alone but that has the same problem as addListener(Listener, boolean) (ie. it only works for untyped listeners). Tom Schindl <[email protected]> Sent by: [email protected] 02/05/2009 05:42 AM Please respond to E4 Project developer mailing list <[email protected]> To E4 Project developer mailing list <[email protected]> cc Subject Re: [e4-dev] Declarative UI in E4 Gorkem Ercan schrieb: > I believe native device UIs are a bit ahead of the desktop UIs nowadays. > > On many of the late versions of the mobile UIs CSS or some other form > of declarative styling is supported natively. So on those platforms > the only overhead is interpreting the SWT/eSWT properties to native > properties & declarative language (if different from CSS). Since this > is also the case with web UIs, I 'd like to see CSS support on widget > level with an API like Widget.setStyle (String CSSString); > This is how I also envision that this works! As stated before I use this strategy in UFaceKit for QT and it works fantastic! The thing that still bothers me a bit for embedded devices is the huge amount of libraries we need at the level above SWT to parse CSS and interpret it appropriately and as outlined by Angelo Zerr the problem of notification about widget changes in SWT is a real problem! Some ideas to solve the problem with this programmatic notifications: a) Implement a marker interface listeners are notified in any case b) Add method addListener(int,Listener,boolean) where the boolean flag controls if the listener is called every time no matter if the change occurred because of a user interaction of programmatically by calling a method? c) Annotate the Listener with @listener(invoke="always"), @listener(invoke="user"), @listener(invoke="programmatic") I guess c) is not possible because it's Java5-Syntax and so I'd prefer b). Steve any idea from you how we could provide reaction to programmatic widget changes? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl leiter softwareentwicklung/CSO ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834 _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
