Hi,

I have a project open and some units open in the editor, I then put active focus on the main form (one containing the component palettes). If I press Ctrl+A, all text in the current editor windows is selected. Good, behaviour I expected.

Now if I press Alt+[0-9] to change the active editor tab while the main form is active, nothing happens. I have to first focus the editor window, then the Alt+[number] works.

Is this by design, or must I report it as a bug? I'm using Ubuntu and Lazarus (latest trunk) compiled with GTK2.

The goto editor commands are registered only for the source editor, so other IDE windows can use these shortcuts for their own tabs or their own commands.

With docking there are also more tabs. Maybe these shortcuts can be used for these pages too.

I'm not yet sure how to implement docked designer forms. Maybe a form editor window with tabs.

And finally:
You can write a package and move the ecGotoEditorX commands to another category. For example one of the globals.

Mattias

Mattias Gaertner wrote

And finally: You can write a package and move the ecGotoEditorX commands to another category. For example one of the globals.

Thanks for explaining, it makes sense now. Always nice to know I can easily adjust certain behaviour as well. :-)

The goto editor commands are registered only for the source editor, so other IDE windows can use these shortcuts for their own tabs or their own commands.

IMO a good idea.

With docking there are also more tabs. Maybe these shortcuts can be used for these pages too.

With caution, because when keyboard commands depend on the context (focused control...), the user can be confused by the many possible (and often unwanted) results. If ever, the scope of shortcuts should be selectable by the user, and should not be too wide by default.

I'm not yet sure how to implement docked designer forms. Maybe a form editor window with tabs.

Embedded designers require scrolling and other navigation, when not the whole form (or all currently open forms) fit into the docking area. IMO it were much more useful to have floating form designers, even in a docked environment, with a synchronization between active designer windows and the related units. The source code fits almost never entirely into the editor client area, so that the user is used to scroll through it, while forms should fit entirely at least into the screen.

DoDi

But then you could use the whole client (minus object inspector) area as designer-dock area:

+-----------------------
| Menu
| IDE - Main Bar
+----------------------
| [Notebook Tab Edit Source Dock] [Tab Edit Forms + OI] |
| "Dockable Client area"
|
+-------------------

"Dockable Client area" is tabbed:
- one etab contains:
ObjectInspector + Form Designer

- Other Tab contains Source Editor

------------------
Of course some users will want the delphi way, where each SourceEdit Tab, has sub-tabs: source / design

--------------------
Anyway, if each designer is in a tab, then you can drag each tab to where you want (even mixing them at the same level with source editors, assuming SourceEditor.pp is extended.)

Martin

Such a layout requires a window management that differs from the undocked one, it's not sufficient to only make windows dockable. When e.g. the designer and source code reside in different tabs of the same notebook, the IDE must not try to make both visible at the same time. Such specialized layout management is not (yet) implemented in the IDE, the current dockable approach is more a hack, that can conflict with many automatism implemented for the undocked layout.

That's why I try to convince Mattias to allow for full-fledged installable layout managers, not only for a DockMaster add-on. Then we can have any number of IDE layouts, like classic undocked, parts dockable, monolithic (SDI), and whatever else one may want to implement.

DoDi