Re: [e4-dev] Declarative UI in E4

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

I see Tom Shindl has also posted to
this thread.

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

Correct, the current approach is to
use whatever APIs SWT gives us.  To do more would in effect be creating
a special styling API across platforms only available to CSS.

At present that's quite limited though.
 We can effectively provide margins through the use of composites
but that's awkward and as noted by Gorkem doesn't get to play in computeSize.
 Tom mentioned padding which is even more advanced and obviously only
something the widget could provide since it draws it's own border.  But
I don't know how that would work cross platform.  We can get even
fancier if we (SWT) were prepared to draw our own borders and do rounded,
or some of the fancier ones in CSS3.  

One approach may be a set of styling
oriented APIs that are best effort.  If the platform can provide then
great, if not then it fails gracefully through use of defaults.  So
if the platform is "the web" then it all works, but maybe your
request for round corners on Win32 still just gives you square.  I
think this approach would let us take advantage of more advanced platforms
without being stuck with current lowest common denominator.  A more
advanced API would allow you to query the set of styling capabilities the
platform supports, which maybe we could map to @media rules in CSS (that's
just off the cuff, need to think more about it).

In any case we're beholding to SWT.
 In the end, all we can do is call SWT API.

Kevin

Steve Northover/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

01/28/2009 01:53 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

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?

Gorkem Ercan <gercan@xxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

01/28/2009 08:33 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

IMHO the super minor example is not that minor. It is a major use case
that CSS can be used in coord with layout managers to layout the UI.

I think I have voiced these before in this list but here it goes
again, I am in favor of supporting for CSS properties in SWT widget
level. I think we need Control level awareness of the CSS properties.
For instance in this case computeSize implementations of the Controls
could add the margin values to the preferred sizes so that it would
work with the layout managers. Other than margins there is also the
other size related CSS properties min-width, min-height, height,
width... those also needs to be addressed in computeSize
implementations. Since Qt's support for stylesheets is mentioned, one
of the elements in Qt CSS support is, it is possible to style
sub-elements in a Control (for instance the down arrow on a CheckBox).
Again that level of control is not possible without SWT level support
for CSS styling.
--
Gorkem


2009/1/28 Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>:
>
> My impression was that XWT and Hallvard's model were modelling at
two
> different levels. At least, that's the interesting part to me (and
less so,
> it's representation as an EMF model or XML).  I admit I've not
looked
> closely at either due to lack of time (sigh), but at a broad level,
I
> believe that Yves approach maps more closely to the widgets but is
not a
> direct representation of them (close but not 1:1), while as Hallvard's
is a
> more abstract approach which could facilitate higher level UI expressions,
> eventually generated down to widgets (even less 1:1).
>
> I'm not sure I've characterized them accurately and if not apologies.
>
> I think both approaches are interested and valid.  A close mapping
to the
> widget structure allows for GUI builders, serialization/deserialization,
> testers, etc. A more abstract model might allow you raise the level
of
> _expression_ of the UI to more functional needs ("I need a list
of
> directories" vs. "I need a list widget whose content provider
gives me
> directories").
>
> As a super-minor example, in CSS you can set margins.  Our SWT
widgets don't
> have equivalent API for margins.  The way to implement it in
SWT is with a
> Composite and layout.  But my declarative UI likely won't have
that
> composite.  Ideally the widget generation would be in cohoots
with CSS and
> gen the right composites with layout values.  So not 1:1.
>
> Kevin
>
>
>
> David Orme <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
> 01/27/2009 03:03 PM
>
> Please respond to
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> To
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, andy@xxxxxxxxxx
> cc
> Subject
> [e4-dev] Declarative UI in E4
>
>
>
>
> Two things, by way of moving the discussion forward while the IP machine
> grinds along:
>
> (The impatient or overworked can read just the boldfaced text and
get the
> gist of what I'm saying. ;-)
>
>
> Thing #1:)
>
> My understanding is that our status is that Hallvard's code is making
its
> way through the IP Review process and onto the E4 server.
>
> In the meantime, I had an idea that might unify the two current proposals.
>
> (If I mis-characterize any of this, please correct me, but here is
my
> understanding of our current state:)
>
> 1) Hallvard's proposal is an XML layer on top of an EMF model that
is
> connected to the UI.
>
> 2) Yyves's proposal is to map XAML 1:1 to the SWT API.  He calls
the
> resulting API XWT.
>
> Here's what I was wondering:  Yyves, would it be possible/desirable
to make
> XWT map 1:1 to Hallvard's EMF model rather than straight to SWT?  This
seems
> like it might be a sensible approach to unifying both proposals.
>
> If the answer is "yes", I'd very much like to play with
that and see what
> the resulting code looks/feels like.
>
>
> Thing #2:)
>
> I've been thinking about the ways we have discussed for abstracting
and
> simplifying UI creation.  So far, we have only focused on XML
> representation, but I recalled that Andy Maleh created (and proposed)
> Glimmer, a JRuby-based UI DSL project.  And I've been interested
in
> translating Glimmer's ideas into Scala.
>
> (I noticed that Boris invited Andy to participate over here, and
> regrettably, he has not materialized yet.  Since I know Andy
personally,
> I'll reach out to him and invite him to join the conversation.)
>
> In any case, I want to make sure that whatever we do does not preclude
> Glimmer-like things in alternate JVM languages, whether JRuby, Scala,
> _javascript_, etc.
>
> In the abstract, it seems like it ought to be possible to map Glimmer(.JRuby
> | .Scala) to EMF just like Hallvard maps XML to EMF.
>
> Which brings me to my
>
>
> Conclusion:)
>
> Hallvard: Any ETA on when we will get to see your code at Eclipse.org?
>
> I'd really like to get my hands on both of these proposals and play
with
> them. :-)
>
>
> Best regards,
>
> Dave Orme
>
> PS: Andy: I've CC'd you on this mailing list message.  If you're
interested,
> please add yourself to the list so you can take part in the ongoing
> conversation.  You know you're welcome here. ;-)
>
> _______________________________________________
> 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