Re: [e4-dev] Declarative UI in E4

[Gorkem Ercan <gercan@xxxxxxx>]

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

Also, eSWT implementations use native code to optimize when needed.
Although I have not investigated this solution, I guess on
implementations for UI toolkits where declarative styling is not
supported natively, it can be done by providing native code.
--
Gorkem


2009/2/5 David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>:
> Two thoughts:
>
> 1) What do our embedded folks say?  They are the ones who care deeply about
> bits and bytes.
> 2) Or are we only going to support this on desktop/server configurations if
> it's not already supported on a particular embedded platform?  In which
> case, I wonder how much we care since:
>
> a) On the web it's supported natively, so my understanding is that there
> would be little or no overhead (please correct me if I'm wrong, Steve)
> b) On the desktop we have gigabytes and gigabytes of RAM anyway!
> c) If we only support it on an embedded platform if it is supported by the
> platform itself, the embedded people would see very low overhead for having
> the feature (just method calls that are ignored).
>
> Actually, that point (c) still gives me pause a bit, since on embedded
> device *any* cycle wastage is cause for concern.  On the other hand, I have
> yet to see a desktop UI that could scale successfully to a tiny screen, so
> you wind up rewriting the UI for the device anyway.  In which case you could
> simply not use the APIs you know are bad.
>
> Or the APIs could help and throw a new IllegalOperationException("This API
> is not implemented on ESWT because it would waste CPU cycles on small
> devices.").  ;-)
>
>
> Dave
>
> 2009/2/4 Steve Northover <Steve_Northover@xxxxxxxxxx>
>>
>> ... which uses more memory than a field for each attribute when framework
>> code sets every field because it doesn't know that it shouldn't.  I've seen
>> both patterns before and there is no good answer.
>>
>>
>>
>> Kevin McGuire/Ottawa/IBM@IBMCA
>> Sent by: e4-dev-bounces@xxxxxxxxxxx
>>
>> 02/04/2009 02:25 PM
>>
>> 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
>>
>>
>>
>>
>>
>> Or a field, with all attributes, null value on platforms which don't
>> support.
>>
>>
>> Steve Northover/Ottawa/IBM@IBMCA
>> Sent by: e4-dev-bounces@xxxxxxxxxxx
>>
>> 02/04/2009 01:52 PM
>>
>> Please respond to
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>>
>> To
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>> cc
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
>> e4-dev-bounces@xxxxxxxxxxx
>> Subject
>> Re: [e4-dev] Declarative UI in E4
>>
>>
>>
>>
>>
>>
>>
>> > . So, Steve, you are the master of widgetry;
>>
>> There might be hack involving WM_NCPAINT on win32 but you still need
>> fields for each attribute and this increases the Java memory used for each
>> widget.
>>
>> Mike Wilson/Ottawa/IBM@IBMCA
>> Sent by: e4-dev-bounces@xxxxxxxxxxx
>>
>> 02/03/2009 09:36 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
>>
>>
>>
>>
>>
>>
>>
>>
>> Kevin's point 4) is that we *do* want to support the ability to add space
>> around things. It's not something we can give up on, just because it's
>> non-trivial to implement with the current SWT API.
>>
>> So how do we do this? Steve's, first take at a "random implementation
>> thought" fails for the reasons we have discussed. So, Steve, you are the
>> master of widgetry; how do we get this capability *without* paying the
>> double-the-os-resources penalty?
>>
>> Personally, I'd like whatever the solution is to be to provided directly
>> by SWT, so that on platforms like WPF where (I'm guessing) it's directly
>> supported, we could use the native implementation.
>>
>> McQ.
>>
>>
>> Kevin McGuire---29/01/2009 10:25:08--->Perhaps it is best if CSS engine
>> handles all that and > SWT Widgets handles the applying of the act
>> From:
>> Kevin McGuire/Ottawa/IBM@IBMCA
>> To:
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
>> Cc:
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
>> e4-dev-bounces@xxxxxxxxxxx
>> Date:
>> 29/01/2009 10:25
>> Subject:
>> Re: [e4-dev] Declarative UI in E4
>>
>>
>> ________________________________
>>
>>
>>
>> >Perhaps it is best if CSS engine handles all that and
>> > SWT Widgets handles the applying of the actual style.
>>
>> That's how I imagined it would work. We don't need SWT to parse styles (I
>> can do that part), we just need API access to realize the styling on screen
>> (I can't do that part).
>>
>> That way too, you can do something other than CSS as a format/parser (e.g.
>> XAML).
>>
>> At a very high level, to me the main issues are:
>>
>> 1) We need to modernize the look of Eclipse, and to do so we need:
>> a) externalized styling
>> b) ensure the workbench allows things to be styled (presently some hard
>> coded decisions, we're working on that)
>> c) take advantage of advanced styling on those platforms which support it.
>>
>> 2) Not all platforms support the same set of styling capabilities. SWT has
>> done a fantastic job in the past of providing parity behaviour across
>> multiple OS', but sometimes at the cost of it being lowest common
>> denominator. For styling, I think things can be looser since we're not
>> talking behavioural compatibility: an app can look different across OS'
>> provided it looks good on all, the layout works correctly, etc. So we need a
>> best effort strategy with graceful fallback under the control of the
>> application, for those willing to pay the price. To do so, we need SWT to
>> provide access to those advanced styling capabilities, and report somehow
>> when they are unavailable.
>>
>> 3) I don't want to abandon native widgets in our search for higher gloss.
>> That is, I don't want to custom draw every widget say to get CSS3 borders.
>> Personally, I'd forgo padding if necessary. However, I'd like to understand
>> better what styling capabilities are available to us on various platforms
>> and exercise those better.
>>
>> 4) We need to add space around the widgets, it's actually extremely
>> important from a styling point of view. We should be able to do so
>> declaratively, ideally from CSS. At present we cannot rely on the existance
>> of a parent composite with the right layout manager to enact that spacing.
>> I'm not sure how we solve this if SWT doesn't support it and without doing
>> something horrible like wrapping every widget in a composite, since all that
>> does is move the OS resource cost issue.
>>
>> Kevin
>>
>> e4-dev-bounces@xxxxxxxxxxx wrote on 01/29/2009 07:49:46 AM:
>>
>> > Do you mean a list of CSS properties that needs to be supported by the
>> > SWT (and eSWT) widgets?
>> >
>> > I guess we are talking about a Widget#setStyle( String styleString )
>> > API now. Do we want a similiar API function on Display? That would
>> > make SWT implementations to handle all the cascade rules and the CSS
>> > selectors etc. Perhaps it is best if CSS engine handles all that and
>> > SWT Widgets handles the applying of the actual style.
>> > --
>> > Gorkem
>> >
>> >
>> > 2009/1/28 Steve Northover <Steve_Northover@xxxxxxxxxx>:
>> > >
>> > > Then there is a mapping for some attributes and not others. We need
>> > > the list
>> > > and then decide which ones might be implemented (and the utility of
>> > > implementing them).
>> > >
>> > > Random implementation thoughts:
>> > >
>> > > To implement margins (and other attributes) for every widget would
>> > > increase
>> > > the memory usage on platforms where these attributes are not supported
>> > > natively (ie. everywhere except Dojo, Flex).  We could add one field
>> > > that
>> > > contained a pointer to the memory for all the attributes but
>> > > experience has
>> > > shown that this field always gets set and even more memory is used.  I
>> > > could
>> > > imagine an implementation of the margin code where there were multiple
>> > > operating system handles for each native widget and the real native
>> > > widget
>> > > (ie. the table or whatever) was offset.  This would effectively double
>> > > the
>> > > operating system resource usage for every widget in Eclipse, even when
>> > > no
>> > > margins etc. were set.  Doesn't sound good to me.
>> > >
>> > >
>> > >
>> > > Kevin McGuire/Ottawa/IBM@IBMCA
>> > > Sent by: e4-dev-bounces@xxxxxxxxxxx
>> > >
>> > > 01/28/2009 03:07 PM
>> > >
>> > > 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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >> Kevin, does the CSS code you are playing with now support things like
>> > >> "font-weight"?
>> > >
>> > > Yes.
>> > >
>> > >
>> > >
>> > >
>> > > Steve Northover/Ottawa/IBM@IBMCA
>> > > Sent by: e4-dev-bounces@xxxxxxxxxxx
>> > >
>> > > 01/28/2009 02:24 PM
>> > >
>> > > 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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > You bring up a point that has been danced around for a while (sorry if
>> > > it
>> > > was discussed and I missed it).  It's fine to accept and parse CSS
>> > > formats
>> > > but what are the valid attributes that we set, SWT API only?  In the
>> > > code
>> > > you typed, if the platform was Dojo, then the CSS you provided is
>> > > native and
>> > > could just be applied to the widget.  Not so on win32 or even
>> > > Flexwhere the
>> > > CSS attributes are non-standard too.
>> > >
>> > > Kevin, does the CSS code you are playing with now support things like
>> > > "font-weight"?
>> > >
>> > > Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>> > > Sent by: e4-dev-bounces@xxxxxxxxxxx
>> > >
>> > > 01/28/2009 02:03 PM
>> > >
>> > > 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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Hi Steve,
>> > >
>> > > Do you think SWT could implement interpretation of CSS-Informations
>> > > for
>> > > us (I don't speak about the much more heavy weight parsing and
>> > > CSS-Rules)?
>> > >
>> > > There are things we can't solve without an underlying support from
>> > > SWT.
>> > > One such example is padding on the Text-Widget because naturally
>> > > Component-nesting (which can be used to implement margins) is not
>> > > possible.
>> > >
>> > > If I could dream. I'd like SWT to provide an API like
>> > > Widget#setStyle()
>> > > which allows me to pass in CSS-String like this:
>> > >
>> > > Text widget = new Text(parent,SWT.BORDER);
>> > > widget.setStyle("margin-left: 5px; margin-top: 10px; padding-left:
>> > > 10px;
>> > > font-weight: bold;");
>> > >
>> > > Do you have any idea how we could implement padding with the current
>> > > SWT-API?
>> > >
>> > > Tom
>> > >
>> > > Steve Northover schrieb:
>> > >>
>> > >> I too believe that styling should be at the widget level (but this is
>> > >> no
>> > >> surprise given who I am).
>> > >>
>> > >> RE: Qt
>> > >> It seems to me that a Qt implementation could use native CSS styling
>> > >> to
>> > >> support the features you mention.  The computeSize() API would pick
>> > >> up
>> > >> these attributes (provided it is implemented natively).  All of the
>> > >> CSS
>> > >> and Declarative UI discussions I have seen so far have ignored native
>> > >> styling, probably because the only platforms of SWT that could/do
>> > >> support it are RAP, Flex and Dojo.  My current thinking is that the
>> > >> CSS
>> > >> styling in e4 will not be native (ie. it's implemenation will be in
>> > >> Java
>> > >> and portable).  Kevin?
>> > > _______________________________________________
>> > > 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
>> > > _______________________________________________
>> > > 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
>> > >
>> > >
>> > _______________________________________________
>> > 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
>>
>>
>> _______________________________________________
>> 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
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>