Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 278412

Summary: [CSS] Consider removing capturing of widget state for reset
Product: [Eclipse Project] e4 Reporter: Kevin McGuire <Kevin_McGuire>
Component: UIAssignee: Project Inbox <e4.ui-inbox>
Status: RESOLVED WORKSFORME QA Contact: Bogdan Gheorghe <gheorghe>
Severity: normal    
Priority: P3 CC: azerr, gheorghe, kai.toedter, remy.suen
Version: 0.9   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug

Description Kevin McGuire CLA 2009-05-29 11:50:08 EDT 
In a discussion in the e4 mailing list (http://dev.eclipse.org/mhonarc/lists/e4-dev/msg01051.html), we discussed the current code which attempts to capture the widget's state as a 'default' for it to be reset to.

However, because of the unpredictable interaction of declarative styling, it's believe we can not be sure we've captured the widget's programmatic default state (i.e. state after some client Java code has configured it but before it was styled).

Therefore the suggestion is that when we need to reset the widget's state, we do so to it's 'factory default' (usually by using null as the value for a setter).  We no longer attempt to record the state.
Comment 1 Kevin McGuire CLA 2009-06-23 10:14:24 EDT 
Just for sake of discussion (although you'll see me argue against it in the end):

Another possibility, which would require SWT support though, is for there to be an explicit app widget customization step.  Imagine if when you created a widget one of the args was an inner class which, when invoked, would configure the widget.  We would then have a way to capture what the application thinks the default state should be.  

That, in combination with SWT widget creation notification, would give us a life cycle like:

1. Widget instance initialized
2. Widget internal initialization/configuration
3. Call out to app to customize
4. Call out to CSS to style it

We can then always revert the widget to it's default state by reverting to factory all properties we set in (4), and then calling (3).

I'm not sure the practical value of this though since apps must rearrange their widget creation code for (3), so this doesn't come for free.  If they're making these kinds of changes, then really (3) should be empty: they shouldn't do any widget configuration, but rather rely on CSS.  This is the right architectural split.
Comment 2 Eclipse Genie CLA 2019-03-18 14:32:13 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 3 Lars Vogel CLA 2019-06-05 07:30:30 EDT 
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard.

If this bug is still valid, please reopen and remove the "stalebug" keyword.