Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI in E4

Steve Northover schrieb:
> 
> 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

Untyped is good enough for me and I think the CSS people agree with me.

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

Agreed we can simply start sending events!

> 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 <tom.schindl@xxxxxxxxxxxxxxx>*
> Sent by: e4-dev-bounces@xxxxxxxxxxx
> 
> 02/05/2009 05:42 AM
> Please respond to
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> 
> 
> 	
> To
> 	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> 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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev


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


Back to the top