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 <[email protected]> Sent by: [email protected] 04/04/2009 09:57 AM Please respond to E4 Project developer mailing list <[email protected]> To E4 Project developer mailing list <[email protected]> cc Subject Re: [e4-dev] SWT Styling/Theming On Fri, Apr 3, 2009 at 9:24 AM, Toedter, Kai <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
