You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Greg Brown <gk...@verizon.net> on 2010/12/01 14:38:49 UTC
Editor transitions
I can think of two possible solutions to the editor transition issue:
1) Provide a boolean "immediate" flag to endEdit(). If true, the editor should not run any transitions but should instead close immediately.
2) Provide a listener argument to endEdit() that will be called when the transition is complete (e.g. TableView.RowEditorListener#editComplete(boolean)).
I prefer #2, since #1 would preclude running any kind of transition in these cases.
Thoughts?
G
Re: Fwd: Editor transitions
Posted by lello <rb...@gmail.com>.
I would personally use Greg idea (b), an option to toggle between b) and c)
might also be helpful, but I don't know how complex it is to implement and
if anyone is ever going to use it.
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Editor-transitions-tp1998987p2001984.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Fwd: Editor transitions
Posted by Chris Bartlett <cb...@gmail.com>.
Forgot to include user list.
---------- Forwarded message ----------
From: Chris Bartlett <cb...@gmail.com>
Date: 2 December 2010 00:36
Subject: Re: Editor transitions
To: dev@pivot.apache.org
On 1 December 2010 23:10, Greg Brown <gk...@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
requirements.
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.
Chris
Re: Editor transitions
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
> Right. I'd suggest that we revert to the simpler edit() and implement (c) for now, and revisit (a) and (b) in an update release as needed.
I agree with you, probably (c) is the best option at the moment, and
see later if improve (a) and (b)
Bye
Re: Editor transitions
Posted by Greg Brown <gk...@verizon.net>.
> 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.
Right. I'd suggest that we revert to the simpler edit() and implement (c) for now, and revisit (a) and (b) in an update release as needed.
Re: Editor transitions
Posted by Chris Bartlett <cb...@gmail.com>.
On 1 December 2010 23:10, Greg Brown <gk...@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
requirements.
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.
Chris
Re: Editor transitions
Posted by Greg Brown <gk...@verizon.net>.
> 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.
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
Re: Editor transitions
Posted by Greg Brown <gk...@verizon.net>.
> 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.
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
Re: Editor transitions
Posted by Chris Bartlett <cb...@gmail.com>.
I had been thinking along the lines of #2, but #1 seems quite user friendly
to me. Although if there is an immediate flag for endEdit() then users
might expect beginEdit() to have one also.
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! :)
Chris
On 1 December 2010 20:38, Greg Brown <gk...@verizon.net> wrote:
> I can think of two possible solutions to the editor transition issue:
>
> 1) Provide a boolean "immediate" flag to endEdit(). If true, the editor
> should not run any transitions but should instead close immediately.
>
> 2) Provide a listener argument to endEdit() that will be called when the
> transition is complete (e.g.
> TableView.RowEditorListener#editComplete(boolean)).
>
> I prefer #2, since #1 would preclude running any kind of transition in
> these cases.
>
> Thoughts?
>
> G
>
>