Re: [e4-dev] Proposal to replace the 'visible' flag

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Tom, it was never the intent that the
TBR / Visible flags to be part of the rendering life cycle (which seems
to be what you infer below). Rather the 'visible' flag was introduced initially
to specifically address the need for the minimized stack's MToolControl
to take ownership of the stack's widget. 

It's this confusion that I'm trying
to eliminate...

Given that the parent is rendered then
setting the TBR to true should render the element through the 'createGui'
method, after which the 'widget' and 'renderer' should be non-null and
the resulting widget should be wherever it's parent's renderer decides
(through the 'getUIContainer' call). Conversely, setting it to false should
result in a call to 'removeGui', after which the 'widget' and 'renderer'
fields will be null.

The intent of the 'visible' flag was
to allow some part of the UI (in my case the minimize handler) to 'hijack'
the stack's widget by setting its 'visible' flag to null. This results
in a 'hideChild' call to the parent's renderer (to remove the element from
the UI presentation) and to re-parent the control to shell that is not
visible (because SWT widgets have to be under some parent). The term 'visible'
has always been mis-leading...for example when you click on an icon for
a minimized stack it shows up in the UI even though the 'visible' flag
is false...

Use of the current 'visible' flag has
no bearing on managing an element's visibility within the
regular presentation (i.e. none of the code for the normal presentation
should ever modify this flag), it's a 'special case' flag used to modify
the regular presentation's display of the element so that
it can be used elsewhere. Note that it's the code that wants to hijack
the element that sets the 'visible' state, it's not part of the standard
behavior at all.

The proposal was generated once I realized
that what I was doing in the code to handle shared elements ('curSharedElement')
 matched up so well with what needed for those cases in which I currently
use the 'visible' flag...

Eric

From:	Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	10/21/2010 11:19 AM
Subject:	Re: [e4-dev] Proposal to replace the 'visible' flag
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Why not merging toBeRendered and visible into one
field using an Enum
but frankly I have not 100% understood yet the whole thing.

Probably I'm heading in completely the wrong direction but isn't the
flow of this attribute:

visibility = NONE      (no widget)
visibility = TO_RENDER (widget created but not shown)
visibility = VISIBLE   (widget made visible)

So when we e.g. have a UIElement whose visibility attribute changes from
VISIBLE => NONE this means for us to dispose it, going from VISIBLE
=>
TO_RENDER means Control#setVisible(false)

Tom

Am 21.10.10 17:08, schrieb Eric Moffatt:
> 
> Can you give me a scenario where the TBR flag is not sufficient ?
I was
> expecting Menus/TBs to be simple; TBR true to show, TBR false to not
> show...
> 
> Eric
> 
> 
> 
> From:                
 Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
> To:                
 E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> Date:                
 10/21/2010 09:57 AM
> Subject:              
   Re: [e4-dev] Proposal to replace the 'visible' flag
> Sent by:              
   e4-dev-bounces@xxxxxxxxxxx
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> On Thu, Oct 21, 2010 at 9:43 AM, Eric Moffatt <emoffatt@xxxxxxxxxx>
wrote:
>>
>> After spending some time with Lars yesterday explaining the difference
>> between the 'toBeRendered' flag and the 'visible' flag (again!)
I
> think that
>> I've come up with a way to eliminate it altogether...
> 
> I can't comment on the use of it in shared parts, but in menus and
> toolbars I need a different flag that contols visibility vs TBR (which
> means under control of the renderer).  But if it's not useful
in other
> rendering contexts, it could be moved up to the MMenuElement level.
> 
> Also, I'll give you this 3.x scenario to consider.  You can currently
> hide an editor.  It has the properties that the editor tab is
no
> longer visible in the editor area.  But as it works against the
> EditorReference, it has no effect on the "restored" state
of the
> editor.  i.e. if there's an EditorPart it is left alone, not
disposed.
> 
> PW
> 
> 
> -- 
> Paul Webster
> Hi floor.  Make me a sammich! - GIR
> _______________________________________________
> 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


-- 
B e s t S o l u t i o n . a t            
           EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                  
                     geschaeftsfuehrer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5/1    A-6020 innsbruck      phone
   ++43 512 935834
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev