pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: Editor transitions
Date Wed, 01 Dec 2010 17:36:00 GMT
On 1 December 2010 23:10, Greg Brown <gk_brown@verizon.net> wrote:

> > I think I might have misunderstood your reasoning about #1?  If my logic
> determines that there should be no transition when the editor is closed, and
> I choose to set the immediate flag on endEdit(), then I shouldn't be
> surprised when no transition occurs! :)
> I just meant that this solution would prevent the use of a transition in
> this case. For example, I may still want to run a transition when switching
> the editor to the next row, and I wouldn't be able to if we use an
> "immediate" flag.
I read the intent of the 'immediate' flag as 'suppressEditEffect'. ie
closing the editor without any transitions
That is why I thought we might want a complimentary immediate flag for
beginEdit() to give the user control over whether transitions run when
starting an arbitrary edit.
I could call endEdit(immediate = true) to stop an edit without running any
edit effects, and then beginEdit(immediate = false) if I wanted to start a
new edit with effects.

> However, another option occurred to me that I think might work better. In
> fact, it actually occurred to me way back when I first made the changes to
> the editor APIs, but I forgot about it.  :-)
> Using this approach, we can actually go back to simply using edit() and
> drop isEditing() and endEdit(). The idea is to leave it to the
> implementation of edit() to determine what to do when an edit is already in
> progress. For example, if I call edit() and the editor is not currently
> active, we open() the window and position it over the selected row,
> beginning the edit. Opening the window may execute a transition, which we
> want. Later, if edit() is called again while the editor is open, we simply
> reload its contents with the new data and reposition it over the new row.
> Finally, when the edit is complete, we close() and run the closing
> transition.
> This approach keeps the editor API simple but still offers the caller
> and/or editor implementor some control over how to handle this case. What do
> you think?
> G
> That behaviour is pretty much what I ended up writing to meet my own
I needed be able to initiate the edit and then navigate the editor row
around all of the selected rows in the TableView using the keyboard.
Edits are initiated with F2, ENTER or by double clicking with the mouse.
Then the row editor can be repositioned using the UP or DOWN arrows (or
optionally with the mouse).
This is why I needed to know whether the editor was open or not, and to be
able to force its closure before repositioning at a different row.

My raw requirement was to be able open the row editor at a specific row, and
also have the ability to reposition it at will.
If this can be achieved by including the logic into TableViewRowEditor to
give a lifecycle of OPEN -> (REPOSITION) -> CLOSE, then that satisfies me.
Alternatively, the REPOSITION part of the lifecycle can be achieved manually
if there are isEditing and endEdit type methods on the RowEditor interface.

Although I am personally unlikely to ever use row editor
effects/transitions, I imagine that in your scenario above, some people
might want the effects to always run.  So if the editor was already opened
when another call to edit() comes in, they might want the existing editor to
display its 'close' effect before repositioning at a new row and then
displaying its 'open' effect.

I suppose the options are
a) never show edit effects    - TableViewRowEditor.setEditEffect(null)
b) always show edit effects, even when the editor is already open and
another edit() request repositions it to a new row
c) show the initial open effect, and final close effect, but no others when
repositioning     (as you described above)
Given those limited options, having a property to toggle between the
behaviour of b) and c) (when an edit effect has been set) should satisfy
everyones demands.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message