View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019666||Lazarus||IDE||public||2011-07-01 15:24||2011-11-20 02:47|
|Reporter||Hans-Peter Diettrich||Assigned To||Martin Friebe|
|Product Version||0.9.31 (SVN)|
|Fixed in Version||0.9.31 (SVN)|
|Summary||0019666: Secondary editor window misbehaviour|
|Description||An editor page in a secondary editor window *only* can be cloned into a new window.|
Also dragging of editor tabs doesn't work, no target responds.
|Additional Information||It looks as if a secondary editor window erroneously *thinks* that it is the only editor window, and constructs the popup menu accordingly. The menu of the primary editor correctly reflects other existing editor windows.|
|Tags||No tags attached.|
|Fixed in Revision||33635|
The first part seems not to be a bug, more a GUI feedback problem.
It would be nice to only *disable* the menu entries for target windows, which already contain an instance of the file to move/clone. Currently such windows are properly detected and *removed* from the menu and, when no target is left, the submenu is removed at all. This automatism can lead to very misleading results :-(
The *behaviour* could be modified as well. It would be very nice when an attempt to move/clone into a window, where the file is already open, would simply *activate* that already existing page there. According to "also show this page in editor X", regardless of whether it has to be cloned or still was open in that editor.
An according implementation would not check for existing clones during *creation* of the Clone... menu, but only during *execution*. When *no* clone exists in the target window, create one, then activate the old or new clone there.
Similarly a move could close the moved clone, and focus an old or new clone in the target window. Here it may be undesireable to have the original clone closed, when the target window already contains another clone, because then all clone-specific attributes (position, folding...) of the originating clone will get lost. In this case above suggestion applies, targets already containing an clone should only be disabled in the Move menu, not removed from the menu.
First part: "dragging of editor tabs doesn't work, no target responds"
This works here, if the window will not accept the drag operation the mouse changes to the cursor "no drop" (a circle with diagonal line).
Please provide further details (best to do so in a different bug report / so this can be kept about the context menu only)
On review, including review of the exchange on the mailglist.
Restriction to only one tab per file in each window.
This is intended to be kept.
Showing target windows that already contain a clone as disabled in the menu
As in my mail, that is not necessarily an advantage:
- if all existing windows have already a clone, the user will need to open the sub-menu, to trigger "clone/move to new window". Currently the option is displayed in the main menu, making it quicker to reach
- Displaying one enabled target window in a list of 5 or more disabled, is not making it easier either
- Showing a disabled entry does not explain why it is disabled. It does not solve any confusion, if the user is not aware of how this feature works
Always show all target windows (potentially with different caption), but trigger different behaviour depending on existence of clone in target window.
Rather than mixing different behaviours into one sub-menu (and even within this sub-menu, into a single list of menu entries), I believe it would be better to have an additional sub-menu: "Show clone in other window".
This would list all windows that already have a clone, and allow to activate that tab.
As for close_re-open, or synchronizing locations between clones (move clone in window X to line of clone in current window), this would add to many entries to the menu. If really required, it could be added as context sensitive popup menu entry (popup on line number). If so this can be discussed, if there is an intention to create a patch.
If no further feedback is received, I intend to resolve as follows.
- not showing disabled entries (2) is the intended behaviour
- A 3rd sub-menu will be added (shown only, f clones do exist): "Show clone in [other window]"
This sub menu will only list windows that have a clone.
Hopefully the presence of this list will have a similar effect in reducing potential confusion, as this was hoped to be archived by displaying disabled entries
A menu entry "Find in other Window" has been added.
As it becomes enabled in situations such as the described, it should help clarifying the situation.
As for the dragging issue: I was not able to reproduce. If it is still present, please re-open or better create a new issue.
Please specify the exact version of Windows you have, and which mouse pointer(s) you see during dragging.
|2011-07-01 15:24||Hans-Peter Diettrich||New Issue|
|2011-07-01 15:24||Hans-Peter Diettrich||Widgetset||=> Win32/Win64|
|2011-07-01 16:10||Hans-Peter Diettrich||Note Added: 0049561|
|2011-07-01 16:45||Martin Friebe||Status||new => assigned|
|2011-07-01 16:45||Martin Friebe||Assigned To||=> Martin Friebe|
|2011-11-06 15:48||Martin Friebe||LazTarget||=> -|
|2011-11-06 15:48||Martin Friebe||Note Added: 0053846|
|2011-11-06 15:48||Martin Friebe||Status||assigned => feedback|
|2011-11-20 02:47||Martin Friebe||Fixed in Revision||=> 33635|
|2011-11-20 02:47||Martin Friebe||LazTarget||- => 0.99.0|
|2011-11-20 02:47||Martin Friebe||Status||feedback => resolved|
|2011-11-20 02:47||Martin Friebe||Fixed in Version||=> 0.9.31 (SVN)|
|2011-11-20 02:47||Martin Friebe||Resolution||open => fixed|
|2011-11-20 02:47||Martin Friebe||Note Added: 0054281|
|2011-11-20 02:47||Martin Friebe||Target Version||=> 0.99.0|