Is docking support production ready in Lazarus at this time?

I need to create a mini-IDE sub-application with helper panels in the GUI which should be able to display in the west, north, east and south position of the main work area.

I don't necessarily need to be able to drag and drop panels and dock them, the positions would be static if needs be.

I'm visualizing panels which can be "pinned" as seen in most popular IDE's.

Thanks,

?
?

Lee Jenkins hat am 7. Juli 2011 um 17:18 geschrieben:

Static works since years. Drag and drop has still some quirks.? ?
?

I'm visualizing panels which can be "pinned" as seen in most popular IDE's.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110707/c4b378f8/attachment.html>

Is docking support production ready in Lazarus at this time?

Recent changes and outstanding bugs prevent the use of drag&dock.

I can provide you an patch, that makes docking work again.

BTW: what platform?

DoDi

Hans-Peter Diettrich wrote

I can provide you an patch, that makes docking work again.

So why not apply it to Trunk?

BTW: what platform?

Isn't that irrelevant? LCL is supposed to be cross-platform.

Regards,
- Graeme -

Hans-Peter already reported those patches (or are those new ones?), but they are still waiting for application.

> BTW: what platform? Isn't that irrelevant? LCL is supposed to be cross-platform.

It is true that the LCL is cross-platform, but the implementation of functionality might not be. And as I remember Hans-Peter only works on Windows and that is why he asks.

Regards,
Sven

On 07/07/2011 08:21 PM, Hans-Peter Diettrich wrote: > I can provide you an patch, that makes docking work again. So why not apply it to Trunk?

Don't ask /me ;-)

> BTW: what platform? Isn't that irrelevant? LCL is supposed to be cross-platform.

Delphi drag&dock has some problems with window managers.

DoDi

<whine>
I see no use for providing new patches, as long as nobody cares about the older ones.

The "anchor docking" pet of some developer(s) seems to block all other docking models and, even worse, possible damage to the Delphi-compatible docking is no more tested :-(

I agree that the Delphi docking model is not very usable on non-Windows platforms, but anchor docking is not a good replacement for it. According to my research a different model could be both simpler and platform independent. But as long as the Lazarus developers do not understand docking and layout management in general, and do not even consider models except of their own, I see no light at the end of the tunnel :-(
</whine>

Of course Paul is right, when he tells me to "not change the LCL radically", but I see many items that suffer from a poor design. Unfortunately it is not easy to replace obvious misfeatures in the LCL and IDE by other features, due to the lack of proper encapsulation. IMO Lazarus still is in the "downward spiral", with immense bloat and spaghettis here and there, that will become unmanageable in the end.

Right. On all other platforms the widgetsets sit on top of an window manager, which influences dragging and docking entire windows (forms). The current (platform independent) workaround is a dock header, added to all dockable forms. This does not only look clumsy, the implementation is fragile and asks for better LCL integration.

As the OP suggests, "pinnable" windows could be a more platform independent solution. But while I could add an according gadget to the title bar of Windows forms, I have absolutely no idea how this could be done on other platforms (window managers). If somebody can contribute an implementation of such a gadget, I'm willing to assist in the integration into the LCL. Otherwise we'll have to wait for the Delphi solution for dockable forms, and I bet that this never will come :-(

DoDi

MSEgui does the same. There probably is no other robust cross platform solution than a window manager independent dock grip. In MSEgui the dock grip is an element of the widget frame. The dock grips of children can be hidden by clicking the small circle button, see attachment.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dock1.png
Type: image/png
Size: 27669 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110709/dbcef3a1/attachment-0002.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: dock2.png
Type: image/png
Size: 27251 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110709/dbcef3a1/attachment-0003.png>

Hans-Peter Diettrich wrote

I cannot see how MSEgui handles dockable (floating) forms.

In order to dock a floating window LeftClick into the drag grip, move the mouse into the destination window, release the mouse button. The drag grip is in client area of the windows.

Martin

I cannot see how MSEgui handles dockable (floating) forms. On Windows a form can react on mouse down in the NC area, while other window managers apparently(?) do not notify a form (window) accordingly. That's the *only* problem with platform independent drag-dock, and nobody (here) seems to have a solution for it :-(

DoDi

Create a window, without border, and without title bar; and draw them yourself?
Ok, yes that's ugly, because those windows will then look and behave different (depending on how well you emulate the windowmanager (or how bad you emulate it).

I don't know if Microsoft does this, but in visual studio floating windows have a different border color, different looking icons, and no shadow....

That's not really different from my approach, of adding an dockheader to every dockable form. The problem is the modification of the form's client area, where frequently is no room left for such a gadget.

DoDi

I don't know if Microsoft does this, but in visual studio floating windows have a different border color, different looking icons, and no shadow....

Windows allows for all such stuff - problem is only all the other window managers out there.

DoDi

A window with border, with title bar and an additional drag handle in client area, see dock2.png in my previous mail.

Martin

A window with border, with title bar and an additional drag handle in client area, see dock2.png in my previous mail.

Such a feature would have to be built into the LCL, it's not feasable in user code.

DoDi

(...)

I don't know any application or widgetset that implements docking integration with X/window managers.
Maybe the default docking handler could just remove the WM decorations and implement its own... (of course optionally, programmatically, under certain conditions etc)

-Fl?vio

Fl?vio Etrusco wrote

I don't know any application or widgetset that implements docking integration with X/window managers.

Not sure if I understood you correctly... But I have seen many X11 widgetsets that implement window docking and MDI interfaces. So it is possible - as is done like Martin suggested or otherwise.

Graeme.

Hans-Peter Diettrich wrote

Windows allows for all such stuff - problem is only all the other window managers out there.

Welcome to the world of cross platform toolkit development! ;-) At least with custom drawn toolkits, things like that are a bit easier.

Yes.

But I think DoDi was referring to floating windows, that means top level windows, not child windows.
For example it would be nice, to have an event when the window title is dragged by the user. But since some window themes do not have a title, or use other other means to drag a window, I guess, this will never work every where. Of course someone might implement it at least for some common cases. Then the docking system can omit the dock drag area for floating windows on these platforms, which would be a bit nicer.

Mattias

Mattias Gaertner wrote

But I think DoDi was referring to floating windows, that means top level windows, not child windows.

I'll read the thread again to try and better understand the problem.

For example it would be nice, to have an event when the window title is dragged by the user. But since some window themes do not have a title,

Welcome to the world of X11. Sometimes it can be great, but often it can be a curse. :-/

Graeme.

In MSEgui it is managed by tgripframe which inherits from tframe which is a property of twidget.
tframe and its descendents (tcaptionframe, tscrollframe, tscrollboxframe...) manage the non client areas of a twiget.

Martin

Sorry for off-topic, but I have to join with this rant. There is a balance between backwards-compatibility and good design, and I am saddened to see that design-improving patches are rejected for fear of theoretical compatibility problems, while at the same time core developers introduce incompatibilities themselves fairly regularly.

Qt have docking windows , and we have QDockWidget in our bindings (I've played with it few months ago and it works .. .but of course there's no support in LCL for such ...). Also QDockWidget works fine on Linux, Mac and Win (and others where qt supports it).

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110710/93683bb1/attachment-0001.html>

Background information:

The LCL implements interfaces to widgetsets, which represent the *content* of windows. That's why an application only gets notifications for client-area events from the widgetset.

For dragging forms another interface, to the window manager, may be required, but this may cause trouble with the widgetsets, which already communicate with the window manager. Only Windows comes with a messaging system that handles both window (NC) and widget related messages in the same way (message queue). Here the application receives *all* messages, and has to care for sending widget-related messages to the widgets (DispatchMessage, WndProc...).

But IMO you know all that already, from your implementation of fpGui. Perhaps just you are the right person, that can figure out how the LCL can work together with every window manager, for receiving and handling notifications?

Window docking requires a notification on MouseDown in the window NC area, and then the dockmanager has to instruct the window manager that it handles subsequent mouse events himself - kind of MouseCapture.

Is this feasable, in parallel to an widgetset?

One solution might be the use of the ALT-drag interface, that allows to move windows without or invisible title bars. I assume that such moves are not intercepted by the widgetsets, so that an application could use that for docking. It would do no harm when windows can be docked from the title bar on Windows, and with other procedures on other platforms. This may mean that window docking support has to be supplied by the RTL, because it has to be independent from the choosen widgetset...

DoDi

Qt have docking windows , and we have QDockWidget in our bindings (I've played with it few months ago and it works .. .but of course there's no support in LCL for such ...). Also QDockWidget works fine on Linux, Mac and Win (and others where qt supports it).

I wonder how Delphi will implement the new cross-platform GUI. Qt may be a candidate herefore - wasn't it used already in CLX?

DoDi

updated CLX to the latest Qt 4.x, but also gave it a different name... latter probably being a marking choice to distance itself from previous bad experiences with CLX.

Qt gives Embarcadero the support for Mac OS X too. So coming back to docking support, they will simply piggyback on the docking that Qt already supplies. That's my best guess.

Hans-Peter Diettrich wrote

One solution might be the use of the ALT-drag interface, that allows to move windows without or invisible title bars.

Umm interesting idea. I'll see if I can find more information on that functionality, and exactly what events get generated.

2011/7/8 Hans-Peter Diettrich :

The "anchor docking" pet of some developer(s) seems to block all other docking models

Out of curiosity after reading this thread I just installed (again) the anchor docking in the IDE and it still seems to be completely broken? too. Is it even supposed to work at the moment (so that reporting bugs would make sense at all)?

_____
?) After having saved a layout as the default it is a game of pure luck whether the IDE will start with the same layout again or whether it will be *completely* messed up, sometimes up to a point beyond repair where I am totally unable to restore *any* usable layout at all, some forme will be closed but some others open but hidden/shrunken to zero to some place where I can't find them while others are maximized, etc.

?
?

Bernd hat am 11. Juli 2011 um 13:54 geschrieben:

What OS?
Can you send me the layout file?

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110711/6ad3ed10/attachment.html>

2011/7/11 Mattias Gaertner :

What OS? Can you send me the layout file?

Linux, GTK2

I did some more testing and this is one of the things that happen:

Open the following 4 windows: Object inspector, Code explorer, Source editor and messages.
Dock them in the following way on the left side put Object inspector and Code explorer into a "tabbed area" (don't know the exact term for this) and on the right side put source editor and messages into another "tabbed area". So the end result is on the left you can tab between two docked forms and on the right you can tab between two docked forms.

Now save it and also make it the default.

The layout works perfectly well until you close the IDE and restart it. as you can see from the attached file it did not save the complete layout, it only contains source editor and obect inspector, the other two are missing.

If I now restart the IDE then it will show me in the window menu that "messages" is open but I cannot find it anywhere. Its hidden and completely unaccessible (and also unclosable).

If I load the same layout file again from the tools menu then message is gone from the windows menu and I can open it again.

It seems as soon as I try to dock something into a tab it will not save it and the next loading of the IDE with this as the default layout will lead to some strange behavior. I have also managed to provoke exception dialogs popping up (not easily reproducible, i will write the message down as soon as I see one again) while trying to load a few different saved layouts when the IDE is already messed up. Restart of the IDE and loading one of the known working layout seems to help. Layouts without tabs seem to work but tabs would be extremely helpful..

_________
Attachment: saved layout is missing "messages" and "code explorer" which were docked inside tabs. First restart with this will lead to messages hidden, after second load IDE will be usable again.

<?xml version="1.0"?>
<CONFIG>
<MainConfig>
<Nodes ChildCount="1">
<Item1 Name="MainIDE" Type="CustomSite" ChildCount="1" WindowState="Maximized">
<Bounds Width="1024" Height="710">
<WorkArea>
<Rect Right="1024" Bottom="729"/>
</WorkArea>
</Bounds>
<Item1 Name="AnchorDockSite3" Type="Layout" ChildCount="3"> <Bounds Top="68" Width="1024" Height="619" SplitterPos="64"/> <Anchors Align="Bottom"/>
<Item1 Name="AnchorDockSplitter2" Type="SplitterVertical"> <Bounds Left="310" Width="4" Height="619"/>
</Item1>
<Item2 Name="SourceNotebook" Type="Control">
<Bounds Left="314" Width="706" Height="592"/>
<Anchors Left="AnchorDockSplitter2" Align="Client"/> </Item2>
<Item3 Name="ObjectInspectorDlg" Type="Control">
<Bounds Width="306" Height="592"/>
<Anchors Align="Client" Right="AnchorDockSplitter2"/> </Item3>
</Item1>
</Item1>
</Nodes>
</MainConfig>
</CONFIG>

?
?

Bernd hat am 11. Juli 2011 um 15:09 geschrieben:

Thanks. It seems tab docking has a bug.
Please create a bug report.?
?

[...]

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110711/f60e754c/attachment-0001.html>