View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0019846||Lazarus||IDE||public||2011-07-31 20:24||2012-03-10 15:21|
|Reporter||T. Kirsch||Assigned To||Juha Manninen|
|Summary||0019846: SourceEditor context menu for tabs [was: Two minor issues with the tabs of the source-editor]|
|Description||This issue was created to split the related "dual report" 0019845|
|Additional Information||Second, a somewhat related issue with the source-editor tabs:|
In Windows (don't know how it's done elsewhere), a context menu's context - if invoked by a mouse click - is usually given by the mouse position. For tabbed applications this means that you get the context menu of the tab you've clicked on (i.e. of the item that's associated with that tab - a file, a web site, whatever), not of the tab that was active before the click.
The most straightforward way to achieve this is to treat a right click as if it was preceded by a left clíck - first the clicked tab becomes the active tab, then the pop-up menu is fired. That's how it looks in UltraEdit or VisualStudio (and probably in Delphi, too - haven't worked with that in many years). Would be nice (and muchh less confusing) if Lazarus could also work this way.
Just as a reminder: Making the clicked tab the active tab is good for an editor, but may not be desirable in other applications (Firefox for instance shows the tab's context menu without activating/showing its web page beforehand), therefore it shouldn't be the general behaviour of a tab control.
|Tags||No tags attached.|
|Fixed in Revision|
I've just noticed that this bug is related to an already resolved (no change required) issue. I beg to differ with the "no change required" bit:
When it comes to the editor tabs, Lazarus does *not* follow Microsoft's guidelines (which is the closest you get to a Windows standard) for context menus:
"Use context menus only for contextual commands and options. The menu items should apply only to the selected (or clicked upon) object or window region, not the entire program."
The clicked upon object is the tab, therefore the menu items should apply to that tab (i.e. to the file identified by it) - and not to the file currently shown in the editor's window.
I'm working with Windows for more than a decade and Lazarus is the first application I came across that doesn't follow this standard/guideline. And that's highly confusing, to say the least.
The only question is how to do it: don't activate the tab but show its context menu or activate the tab first and then show the menu. The former is usually done if activation is time consuming (like showing a webpage in Firefox), the latter is done in all other cases (because it gives better visual feedback). Most editors (including Delphi) do activate the clicked upon tab before they show the context menu.
Now the question is why the tabs behave differently on Windows and GTK2?
I think there is no popup menu associated with the tabs.
GTK2 standard behavior is then to show a list of available tabs.
Windows standard behavior is to show the active editor's popup menu which is not good in this case.
I try to find where the tabs are created and change it somehow.
The behavior was not automatic, it was clearly done wrong. I don't know why the other similar issue was solved as "no change required".
I improved it in r35725 by splitting the big popup menu into 2 menus, one for the tab and one for the editor. The tab is also selected when right-clicked.
I will resolve this after getting some feedback.
I find it very inconvenient, that items like move/copy window are now limited to the tab.
While I agree with the reduced menu for tabs, I thing all items should be shown in the pop up for the editor
"Open File" > "Open File at cursor" makes more sense in the editor, than on the tab, but now is on the tab
unrelated but since we are on it. Should the "Find" entries come after the clipboard section?
On Windows, if the tab-scroll arrows are visible (more tabs than fit the screen), then right click such tabs will select the left most tab.
If the left most tab was already selected and scrolled out of view, then it is kept selected, but not scrolled into view (doesn't matter, as it should not be selected...)
To reproduce, it is important that the arrows do not overlap with the rightmost tab.
This can be archived by scrolling the right most tab into view, and closing any of the visible tabs (make sure ther are enough tabs, so the arrows remain visible), then there will be a gap between the right most tab and the arrows
(The gap correctly has no pop up, clicks on the gap go to the form)
> I find it very inconvenient, that items like move/copy window are now limited to the tab.
You are right. In r35733 I moved the menuitems dealing with editor files to the editor menu.
Now the tab's popup menu has only items that deal with tab-pages and that don't need to know anything about the files.
If you want all the items shown in the editor's menu, it is ok for me.
Then I must ask how to reuse the same TIDEMenuCommands? Or should the commands be redeclared?
> On Windows, if the tab-scroll arrows are visible (more tabs than fit the screen), then right click such tabs will select the left most tab.
What widgetset? I have tested on Windows and Linux-GTK2 and the selection works very well.
The new PageIndex is got like this:
SourceEditor.pp, line 5401.
> Then I must ask how to reuse the same TIDEMenuCommands? Or should the commands be redeclared?
Look at the debug popup
MAybe wait for others feedback. Smaller menu has advantages too.
> What widgetset?
win 32 / vista
If you try it, make sure the 2 scroll arrows (on the right of the tab) do not overlap a tab.
- Open 10 tabs (of which 5 are visible)
- go to the rightmost tab (t 10)
it may overlap with the arrows
- close tab 9
Now there us a gap between the last tab and the arrows
- right click the arrows
IMHO, the order should be adjusted
I forgot to copy the editor popup's update to the right function. I fixed it and changed the order of clipboard + other sections.
> - right click the arrows
Ok, TabIndexAtClientPos returns -1 then. I added a check for it. Now the menu works with the already-selected tab.
Yes, I like a smaller menu without duplicates. Please test and give feedback people.
I also added the list of editor files to the tab's popup menu. It replicates the old GTK2 behavior, but does it on every platform.
|2011-07-31 20:24||Martin Friebe||New Issue|
|2011-07-31 20:24||Martin Friebe||LazTarget||=> -|
|2011-07-31 20:24||Martin Friebe||Widgetset||=> Win32/Win64|
|2011-07-31 20:24||Martin Friebe||Issue generated from: 0019845|
|2011-07-31 20:24||Martin Friebe||Relationship added||related to 0019845|
|2011-07-31 20:25||Martin Friebe||Reporter||Martin Friebe => T. Kirsch|
|2011-08-15 02:44||Martin Friebe||Relationship added||related to 0001828|
|2011-08-25 19:36||T. Kirsch||Note Added: 0051124|
|2011-10-06 15:00||Vincent Snijders||Status||new => acknowledged|
|2012-03-04 22:52||Juha Manninen||Note Added: 0057274|
|2012-03-05 11:32||Juha Manninen||Status||acknowledged => assigned|
|2012-03-05 11:32||Juha Manninen||Assigned To||=> Juha Manninen|
|2012-03-05 11:37||Juha Manninen||Note Added: 0057275|
|2012-03-05 11:37||Juha Manninen||Status||assigned => feedback|
|2012-03-05 13:49||Martin Friebe||Note Added: 0057280|
|2012-03-05 13:50||Martin Friebe||Note Edited: 0057280|
|2012-03-05 14:08||Martin Friebe||Note Added: 0057282|
|2012-03-05 14:10||Martin Friebe||Note Edited: 0057280|
|2012-03-05 14:36||Juha Manninen||Note Added: 0057284|
|2012-03-05 14:38||Juha Manninen||Note Edited: 0057284|
|2012-03-05 14:46||Juha Manninen||Note Added: 0057285|
|2012-03-05 14:48||Juha Manninen||Note Edited: 0057284|
|2012-03-05 15:15||Martin Friebe||Note Added: 0057286|
|2012-03-05 15:21||Martin Friebe||Note Edited: 0057286|
|2012-03-05 16:08||Juha Manninen||Note Added: 0057288|
|2012-03-10 15:21||Juha Manninen||Status||feedback => resolved|
|2012-03-10 15:21||Juha Manninen||Resolution||open => fixed|
|2012-03-10 15:21||Juha Manninen||Note Added: 0057462|