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 Flex where the CSS attributes are non-standard too.
Kevin, does the CSS code you are playing with now support things like "font-weight"? Tom Schindl <[email protected]> Sent by: [email protected] 01/28/2009 02:03 PM 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 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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
