Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Proposal to replace the 'visible' flag
I haven't worked on e4s UI model, but I've encountered the same issues in TM and Wazaabi. Styling with CSS-like rules makes this even more complicated, since small changes can become larger than you think. IMO, styling rule should be used by both the renderer, when mapping from model to toolkit, and within the toolkit. E.g. a rule could select between different SWT widgets, based on the value of a model feature. Hence, a change to the mentioned model feature may result in recreation of a whole widget, not just the update of a single widget property. 

Hallvard

On 21.10.10 20.48, David Orme wrote:



On Thu, Oct 21, 2010 at 12:52 PM, Eric Moffatt <emoffatt@xxxxxxxxxx
<mailto:emoffatt@xxxxxxxxxx>> wrote:

    - Handles multiple attribute changes to the same element (i.e.
    label, tooltip and icon) to be handled in a single sych, right now
    we set each separately causing 3 updates in the UI).
    - Allows at least the potential to optimize sets of changes by
    examining the complete list of pending changes

    The big advantage though is that it makes the rendering simpler by
    removing the necessity for each discreet renderer to create its own
    set of discreet listeners, all they would have to do is to write the
    'synchUI' merhod. Of course care should be taken in 'synchUI' to
    minimize the impact on the rendered widget (i.e. Only call 'setText'
    on the widget if it's different from what's already there...).

     From your experience do you have any hints as to whether this is
    better/worse than the current state ?


IMO, the current state is better for the simple/naive case.  It's a
simpler programming model.

But I've had to abandon it most times I am composing multiple discrete
UI controls together to get an overall effect because often I wind up with:

a) Too many UI updates.

b) Being unable to predict the order in which events will arrive on
various platforms leading to subtle, hard to find/fix cross-platform
redraw bugs.

c) Just generally being in a position where the code trying to do the UI
update doesn't have a global enough perspective to do what it needs to
do, so it has to set some flag/value, then asyncExec to something else
that actually does the update anyway.

In that case, having the code _*explicitly*_ represent the following
pipeline seems to work much better:

    * Handle some event
          o decide we have to redraw; maybe mark the relevant part
            dirty; if we haven't already posted a redraw event to the
            SWT async queue, do so.
          o capture whatever state the event contributes to the eventual
            redraw operation
    * In the async redraw event:
          o Recalculate the entire redraw operation once
                + minimize the number of UI updates
                + sometimes: optimize their order (this can be the
                  difference between keeping up with keyboard
                  auto-repeat and not)
                + sometimes: build a data structure representing the
                  pending UI update (in cases where the UI update itself
                  is very expensive)
          o Actually update the UI

Hope this makes better sense. :-)

I'm not positive how this applies to the E4 programming model, but I
expect you might.  If you'd like, feel free to call me this afternoon
(630-344-3979) and we can talk about it.


Regards,

Dave



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

Back to the top