Re: [e4-dev] SWT Styling/Theming

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

The only platform that does not support
setParent() is Motif.  Advanced graphics are supported on Linux and
Unix platforms that have cairo installed.

> c) I am not
sure if this is possible, but SWT could probably enhance things like menu
or table header with styling capabilities, 

This would be my vote.  We were
hoping to get to this for 3.5 but ran out of time.

Eric Moffatt/Ottawa/IBM@IBMCA
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/06/2009 09:23 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] SWT Styling/Theming

Jeremy, as far as your question on advanced graphics support goes the only
'official' thing I know is that I'm allowed to use 'setParent'. Steve,
do all the platforms that support reparenting also support advanced graphics?
Note that you can already use the advanced graphics in 3.x if you want,
you just have to be sure to 'gracefully degrade' if the support isn't available
(we use it to rotate the Progress trim element if you dock it on a side).

The styling issues are the result of various platform's attempts to enforce
consistency of L&F across all the apps that they support. There are
real advantages to this such as having 'theming' support that affects all
the apps for accessibility and such. It's interesting that the current
state of affairs on the Web is different; it's still the wild west with
each site having their own style. Perhaps folks don't have such a hard
time with this because browsers show only a single page at a time (and
so never mixes the 'orange menus' with the green ones on the same screen
? 

Onwards, 
Eric

Jeremy Dowdall <jeremyd@xxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/04/2009 09:57 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] SWT Styling/Theming

On Fri, Apr 3, 2009 at 9:24 AM, Toedter, Kai <kai.toedter@xxxxxxxxxxx>
wrote: 
a) We provide custom workbench renderers that could use internal custom
SWT widgets to get the desired effect. We don't touch SWT and use internal
custom SWT controls. These custom controls can only be used by the workbench
renderers. 

1. If these widgets cannot be used by the RCP application, wouldn't the
style across the whole UI become inconsistent?  For example, if the
workbench used a styled menu then it seems that menus within views and
dialogs should be similarly styled.
2. If these widgets are successful and people like them, there is going
to be alot of frustration in general about them being internal.
  
b) SWT could provide interfaces and a factories that return either the
current implementation or a custom implementation that might not be as
native as the first one but provides enhanced L&F customization capabilities.
These implementations could be used be the workbench renderers and by end
users. 

I thought "interface" was a dirty word in SWTland :)

My real concern here is getting into the problems that arose from CCombo
- people will use the first thing that works in their immediate environment
whether that is the intended use of the component or not.  I'd be
worried that factories would just make that happen faster.
  
c) I am not sure if this is possible, but SWT could probably enhance things
like menu or table header with styling capabilities, e.g. background-color,
gradient, and texture. The issue I see here is that operating systems might
not provide these capabilities in their native widgets. 

If possible (both code-wise and time-wise) this is always the best option.
 In covering the cases where the OS does not support something, is
there a fairly comprehensive list of what needs to be styled?

As a related question, is there a policy regarding Advanced Graphics in
the e4 Workbench (not all of e4)?  Are they assumed to be available
or is this similar to the issue of moving to Java5?_______________________________________________
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