View Issue Details

IDProjectCategoryView StatusLast Update
0019666LazarusIDEpublic2011-11-20 02:47
ReporterHans-Peter Diettrich Assigned ToMartin Friebe  
Status resolvedResolutionfixed 
Product Version0.9.31 (SVN) 
Fixed in Version0.9.31 (SVN) 
Summary0019666: Secondary editor window misbehaviour
DescriptionAn 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 InformationIt 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.
TagsNo tags attached.
Fixed in Revision33635
Attached Files


Hans-Peter Diettrich

2011-07-01 16:10

reporter   ~0049561

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.

Martin Friebe

2011-11-06 15:48

manager   ~0053846

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

Martin Friebe

2011-11-20 02:47

manager   ~0054281

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.

Issue History

Date Modified Username Field Change
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