Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-06

IDEDialogLayoutList.ApplyLayout() is flawed

18 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

As per a recent message by Mattias about using IDEDialogLayoutList to position add-on packages dialogs...I thought I would take a look at an old problem. This as been something that bugged me for ages in the "File Browser" add-on. Size (width and height) is restored, but the position (top and left) is NOT.

This is very annoying. I thought maybe I am using it wrong in the "File Browser" add-on, so had a look at the ide/addtoprojectdlg.pas unit and it has the same problem. Position (top and left) is NOT restored.

Looking at the saved settings in the environmentoptions.xml file I can clearly see that only Width and Height is saved for any dialogs (ones that are not registered in the Environment > Options > Environment > Windows dialog).

Shouldn't the following call apply all four properties? Width, Height, Top and Left?

  IDEDialogLayoutList.ApplyLayout();
Regards, - Graeme - _______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gärtner
to Graeme Geldenhuys

Zitat von Graeme Geldenhuys :

Show quoted text 19 lines
Hi, As per a recent message by Mattias about using IDEDialogLayoutList to position add-on packages dialogs...I thought I would take a look at an old problem. This as been something that bugged me for ages in the "File Browser" add-on. Size (width and height) is restored, but the position (top and left) is NOT. This is very annoying. I thought maybe I am using it wrong in the "File Browser" add-on, so had a look at the ide/addtoprojectdlg.pas unit and it has the same problem. Position (top and left) is NOT restored. Looking at the saved settings in the environmentoptions.xml file I can clearly see that only Width and Height is saved for any dialogs (ones that are not registered in the Environment > Options > Environment > Windows dialog). Shouldn't the following call apply all four properties? Width, Height, Top and Left?

No. IDEDialogLayoutList is for modal dialogs only. They should not store their position.

Windows that can stay open together with other IDE windows use at the moment the EnvironmentOptions.IDEWindowLayoutList. But there is no IDE interface for this, because this should be replaced by the docking manager.

For example the idea of the anchor docking manager is, that every window has a TLazControlDocker (just put one onto a form in the designer). The rest is done by the docking manager. But I had not the time to complete the restore algorithm and the recent changes probably broke some parts.

Maybe DoDi can outline what his docking manager requires. Maybe we can then create an IDE interface for IDE windows.

Mattias

Powered by NetMail

Reply by email

Graeme Geldenhuys
to Mattias Gärtner
Mattias G?rtner wrote
No. IDEDialogLayoutList is for modal dialogs only. They should not store their position.

Why can't you store position information for modal dialogs? I do this all the time in my own applications.

Windows that can stay open together with other IDE windows use at the moment the EnvironmentOptions.IDEWindowLayoutList. But there is no IDE interface for this,

And due to the lack of such an interface for optional add-on packages, I manually implemented saving and restoring of position information for the File Browser add-on. Plus the splitter position bug is now fixed.

Patch is attached in the following mantis bug report.

http://bugs.freepascal.org/view.php?id=13952

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Hans-Peter Diettrich
to Graeme Geldenhuys: As per a recent message by Mattias about using IDEDialogLayoutList to position add-on…
Show quoted text 5 lines
As per a recent message by Mattias about using IDEDialogLayoutList to position add-on packages dialogs...I thought I would take a look at an old problem. This as been something that bugged me for ages in the "File Browser" add-on. Size (width and height) is restored, but the position (top and left) is NOT.

The same for the debugger window. Even if I move it to the bottom right of the screen, it comes up every now and then (without obvious reasons), and again in it's designed position. Even in the same Lazarus session :-(

This is very annoying.

Very! :-(

DoDi

Reply by email

Vincent Snijders
to Graeme Geldenhuys: Why can't you store position information for modal dialogs? I do this all the time in my…
Graeme Geldenhuys wrote 7 lines
And due to the lack of such an interface for optional add-on packages, I manually implemented saving and restoring of position information for the File Browser add-on. Plus the splitter position bug is now fixed. Patch is attached in the following mantis bug report. http://bugs.freepascal.org/view.php?id=13952

Thanks. Applied.

Vincent

Reply by email

Hans-Peter Diettrich
to Mattias Gärtner: Zitat von Graeme Geldenhuys : No. IDEDialogLayoutList is for modal dialogs only. They…
Show quoted text 8 lines
Windows that can stay open together with other IDE windows use at the moment the EnvironmentOptions.IDEWindowLayoutList. But there is no IDE interface for this, because this should be replaced by the docking manager. For example the idea of the anchor docking manager is, that every window has a TLazControlDocker (just put one onto a form in the designer). The rest is done by the docking manager. But I had not the time to complete the restore algorithm and the recent changes probably broke some parts.

I had a quick look at TLazControlDocker, but I don't understand how to use it.

Maybe DoDi can outline what his docking manager requires. Maybe we can then create an IDE interface for IDE windows.

I've not yet looked deeper into persistent layouts. IMO there should exist a global registration instance, for all dockable components. Every such component registers itself, when it's created, just like a DockSite registers itself with the DragManager. It also should provide identifying information, that can be saved by an docking manager. On rebuild of a layout the manager should be able to create all components, that do not already exist. The creation sequence may be important, so that e.g. a Code Explorer can be created for and linked to a specific editor window, as the Delphi IDE can do.

My next demo application will be an editor with multiple windows, where I can look deeper into details of saving and loading docking layouts. My docking notebook already allows to dock individual pages, so that multiple editor windows already are possible. As long as we don't have files with multiple viewers, another global manager will be required to prevent multiple concurrent edits of the same source, in multiple editor pages.

DoDi

Reply by email

Graeme Geldenhuys
to Hans-Peter Diettrich: The same for the debugger window. Even if I move it to the bottom right of the screen, it…
Hans-Peter Diettrich wrote
The same for the debugger window. Even if I move it to the bottom right of the screen, it comes up every now and then (without obvious reasons),

The problem with the "File Browser" window has now been solved and the fix is in the latest trunk revision. It only took about 5 lines of code. I simply wrote the top & left positions to one of the .xml files and read it back when the dialog is shown again.

It works fine but is not ideal, because size is handled one way, and the positioning is done in another.

I still do not understand why the IDEDialogLayoutList cannot handle both. Like I told Mattias, I store size and position in all my own applications (modal dialogs or not).

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: I had a quick look at TLazControlDocker, but I don't understand how to use it. I've not…
Show quoted text 15 lines
Mattias G?rtner schrieb: > Windows that can stay open together with other IDE windows use at > the moment the EnvironmentOptions.IDEWindowLayoutList. But there is > no IDE interface for this, because this should be replaced by the > docking manager. > > For example the idea of the anchor docking manager is, that every > window has a TLazControlDocker (just put one onto a form in the > designer). The rest is done by the docking manager. But I had not > the time to complete the restore algorithm and the recent changes > probably broke some parts. I had a quick look at TLazControlDocker, but I don't understand how to use it.

Normally you just put it onto a form.
There must be one TLazDockingManager to which all TLazControlDocker are connected. That's all. The rest is done automatically.

Show quoted text 12 lines
> Maybe DoDi can outline what his docking manager requires. Maybe we > can then create an IDE interface for IDE windows. I've not yet looked deeper into persistent layouts. IMO there should exist a global registration instance, for all dockable components. Every such component registers itself, when it's created, just like a DockSite registers itself with the DragManager. It also should provide identifying information, that can be saved by an docking manager. On rebuild of a layout the manager should be able to create all components, that do not already exist. The creation sequence may be important, so that e.g. a Code Explorer can be created for and linked to a specific editor window, as the Delphi IDE can do.

Only those should be created that were open when the IDE was closed. When a window is later opened by the user it would be nice if the docking manager would put it there where it was when it was last time opened.

Show quoted text 7 lines
My next demo application will be an editor with multiple windows, where I can look deeper into details of saving and loading docking layouts. My docking notebook already allows to dock individual pages, so that multiple editor windows already are possible. As long as we don't have files with multiple viewers, another global manager will be required to prevent multiple concurrent edits of the same source, in multiple editor pages.

Mattias

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner
Only those should be created that were open when the IDE was closed.

Right.

When a window is later opened by the user it would be nice if the docking manager would put it there where it was when it was last time opened.

This would require that every window saves its last docking information. A docking manager will not remember undocked (closed) windows, they are not part of the finally stored layout.

DoDi

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner: On Wed, 10 Jun 2009 20:52:11 +0200 Normally you just put it onto a form. There must be…
Show quoted text 6 lines
> I had a quick look at TLazControlDocker, but I don't understand how > to use it. Normally you just put it onto a form. There must be one TLazDockingManager to which all TLazControlDocker are connected. That's all. The rest is done automatically.

The TLazDocking Manager is bound to TAnchoredDockManager. Can this be changed to only TDockManager?

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: Right. This would require that every window saves its last docking information. A docking…
Show quoted text 12 lines
Mattias Gaertner schrieb: > Only those should be created that were open when the IDE was closed. Right. > When a window is later opened by the user it would be nice if the > docking manager would put it there where it was when it was last > time opened. This would require that every window saves its last docking information.

Yes.
The anchored docking manager does that.

A docking manager will not remember undocked (closed) windows, they are not part of the finally stored layout.

Why?

Mattias

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: The TLazDocking Manager is bound to TAnchoredDockManager. Can this be changed to only…
Show quoted text 11 lines
Mattias Gaertner schrieb: >> I had a quick look at TLazControlDocker, but I don't understand how >> to use it. > > Normally you just put it onto a form. > There must be one TLazDockingManager to which all TLazControlDocker > are connected. That's all. The rest is done automatically. The TLazDocking Manager is bound to TAnchoredDockManager. Can this be changed to only TDockManager?

Theoretically an even more abstract TCustomLazDockingManager could be created.
Don't forget that TCustomLazDockingManager is bound also to TCustomLazControlDocker and that TCustomLazDockingManager expects only one TDockManager for all windows.

Mattias

Reply by email

Hans-Peter Diettrich
to Mattias Gaertner: On Thu, 11 Jun 2009 10:13:38 +0200 Theoretically an even more abstract…
Show quoted text 10 lines
>> There must be one TLazDockingManager to which all TLazControlDocker >> are connected. That's all. The rest is done automatically. > The TLazDocking Manager is bound to TAnchoredDockManager. Can this be > changed to only TDockManager? Theoretically an even more abstract TCustomLazDockingManager could be created. Don't forget that TCustomLazDockingManager is bound also to TCustomLazControlDocker and that TCustomLazDockingManager expects only one TDockManager for all windows.

All these restrictions may be applicable to the Lazarus IDE, but not to other applications.

DoDi

Reply by email

Mattias Gaertner
to Hans-Peter Diettrich: Why store information about components, which are not docked to this site? DoDi
Show quoted text 9 lines
Mattias Gaertner schrieb: >> A docking manager will not remember undocked (closed) >> windows, they are not part of the finally stored layout. > > Why? Why store information about components, which are not docked to this site?

A visible control does not need to store the undocked sites. But the undocked control must store its state.
In that sense undocked (closed) windows are stored.

Mattias

Reply by email