I would like to propose and discuss about a new graphical user interface for the next major releases. Nowadays, most of the RAD tools use a docked interface(MonoDevelop, Delphi, VS), and in some cases they are stylish(like the recent Visual Studio versions). I think that a better-looking IDE would not just make the programming task more pleasant, but also could attract more people to Pascal.

I know about the existence of AnchorDocking package for a docked IDE, but I think that if such feature were built-in, the IDE could be improved with appropriated features for a docked app - and since the forms would be still undockable, the user could switch back to the "Delphi7-like" interface.

My propose is ask if you guys would mind if I work on some projects with a different interface and made in Lazarus(of course) to you evaluate. I'm good at create components and customize to give them a stylish appearance like in the case of VS. But I would like to know from you guys first.

*- Felipe*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/973ee256/attachment.html>

As long as you can completely undo it, I don't see why not.

Not everyone is comfortable with the so-called docked interface. Tastes in what is considered a 'modern gui' change every so-and-so years. It's not because an interface has been around for a while that it is less good.

I work with Delphi XE, and reverted completely to the D7 look, including the 'old' component palette. Even my windows 7 has the 'classic' look.

Michael.

I agree with Michael. I tried AnchorDocking and it did not work for me. I need to be able to change values in the Property Editor and see the Form at the same time. I could not do that with Docking.

I prefer the multiwindow approach too, although i mostly align the windows in tiles that could theoretically be done in a docked window.

I tried the dock manager (AnchorDocking i think) but i found two problems that made me not stick to it:

1. The form designer wasn't part of the docked window which was obscuring it. With the multiwindow approach i leave the a big hole at the center for the form designer and the code editor (which is the default basically).

2. The titles had some hideous big fat bevels made of extreme ugliness which looked bad even in the "classic" Win9x theme, let alone the Aero, Aqua and whatever Ubuntu uses. I'm a visual person and this stuff bothers me a lot :-P. Since no widgetset (AFAIK) provides styling features for such things i think the only solution would be to make these styleable by the user.

Keep in mind that it has been a while since i tried it though so things might have changed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/942d038f/attachment.html>

Il 04/12/2012 06:59, Felipe Ferreira da Silva ha scritto:

I use Lazarus every now and then, generally I work on Eclipse or Visual Studio.

FYI, I deeply hate the "stylish" VS 2010 interface, because:
1) it hides and/or changes position to many things I use
2) eats up too much screen surface (same for Eclipse, I work on 1650x1050 display)

Generally speaking, I think that programs like Lazarus (complex, lots and lots of commands & options) need much work on usability and consistency, i.e. rationale under menu & dialog structure must be always the same, use same names for same things in every place and such. Preferences in Lazarus are particularly messy, probably because there are ten thousand of them :-D

Things like dockable windows, skins or other bells & whistles are not really important to me, and probably to many developers. I never tried if Laz supports multi-monitor displays, but that would be a really nice feature.
Configurable menus would be even nicer: the ability to put first what you do really use a lot would be invaluable.

OK stop ranting :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/2a94546f/attachment.html>

One thing to consider for diminishing the number of windows in Lazarus would be by default merging the messages into the Source Editor. That would make 1 less window and most people always keeps it under the source editor anyway.

Felipe Monteiro de Carvalho hat am 4.
Dezember 2012 um 11:39 geschrieben:

One thing to consider for diminishing the number of windows in Lazarus would be by default merging the messages into the Source Editor. That would make 1 less window and most people always keeps it under the source editor anyway.

Which source editor?

Mattias

Felipe Monteiro de Carvalho wrote

One thing to consider for diminishing the number of windows in Lazarus would be by default merging the messages into the Source Editor. That would make 1 less window and most people always keeps it under the source editor anyway.

That sounds like a good idea!

Mattias Gaertner wrote

Which source editor?

The default install comes with 1 source editor. If someone sets up multiple then he is not using the defaults.

The non-docked ui look really old fashioned to me. I like everything to be in its own place always so there is no reason for me personally to want to be able to move windows around.

Fully supported.

- Anders

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/75bb0a1f/attachment.html>

Today, it can be done via AnchorDocking. Just dock only the message Window on Source Window and disable those bevels used as drag surface...

2012/12/4 Felipe Monteiro de Carvalho

I think a good way to solve that is selecting a default dock manager (Easy Dock Manager or AnchorDocking) and make it installed as default for new instalations. But today, I agree that we have some more important issues to think about (ex.: Dynamic component loading)

Felipe, se voc? tiver alguma poposta compilavel, envie para a lista que muitos ir?o realizar os devidos testes....

2012/12/4 Felipe Ferreira da Silva

Manual Docker is enough for my taste:
http://wiki.freepascal.org/Manual_Docker

Avishai wrote

I agree with Michael. I tried AnchorDocking and it did not work for me. I need to be able to change values in the Property Editor and see the Form at the same time. I could not do that with Docking.

You must remember AnchorDocking is not yet complete, it is under construction. It will eventually do that (at least last time I checked, that was the plan).

Docking of designer forms must be implemented either way. And it makes probably little diff, if that is in a package, or the IDE. Some people said different in the past, but that is afaik not proven yet. Even if, it would only mean to add the proper API entries to IDEIntf.

So in terms of designer form docking, it is not relevant where (IDE vs package) it is done. It needs doing either way.

While I personally use the floating approach, I am all for getting a finished, and excellent docking solution.

Not that I have a problem, if it has to go into the IDE, I find the package based approach more desirable. (e.g. I have actually plans to move existing stuff, like the debugger, out of the IDE into a package). Packages mean code separation (even more than units), and therefore better maintainability, and test-ability (if automated tests are written / automated test on the IDE itself, are a constant source of pain, I know, I maintain one).

Moving it to a package, does not necessary mean to do it, without changes in the IDE. The necessary methods can always be added to IDEIntf.

Anyway, "improved with appropriated features": Which ones do you think can not be done in a package? (Assuming that all needed methods and hooks, are added to IDEIntf)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/695cac3d/attachment.html>

I like very much this IDE view. To Lazarus team: please don't change this view. Or if change please make option to choose this IDE view and new one. Felipe Ferreira da Silva,

why not try CodeTyphon view? I don't like his view because of possibilities which you describe.

??: Felipe Ferreira da Silva
???????: [Lazarus] New user interface for future major releases of Lazarus ??:
????????? ??: ???????, 2012, ???????? 4 07:59:53 EET

I would like to propose and discuss about a new graphical user interface for the next major releases. Nowadays, most of the RAD tools use a docked interface(MonoDevelop, Delphi, VS), and in some cases they are stylish(like the recent Visual Studio versions). I think that a better-looking IDE would not just make the programming task more pleasant, but also could attract more people to Pascal.

I know about the existence of AnchorDocking package for a docked IDE, but I think that if such feature were built-in, the IDE could be improved with appropriated features for a docked app - and since the forms would be still undockable, the user could switch back to the "Delphi7-like" interface.

My propose is ask if you guys would mind if I work on some projects with a different interface and made in Lazarus(of course) to you evaluate. I'm good at create components and customize to give them a stylish appearance like in the case of VS. But I would like to know from you guys first.

- Felipe

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

Well, the good thing is to give the two modes of GUI, the classic with floating-forms and the docked. So the user could make the choice.

About the AnchorDocking. I am planing to use it, but I will modify. I have made some modifications already (the title bars of the dockable forms is nice now - not like that win 9X look). Also, when I tried to use the AnchorDocking, I get back to the classic GUI because the designer form still was separated. One of the advantages of make the docking feature built-in is that could be possible to "attatch" the designer form too, like in Delphi(docked versions) with a dashed border around it.

Of course, I'm not mentioning that everything will be done from scratch. The important codes will be held.

*It is the first time I'm using this mailing list, so I don't know if I will do anything wrong :)
- Felipe Ferreira da Silva

Well, the good thing is to give the two modes of GUI, the classic with floating-forms and the docked. So the user could make the choice.

About the AnchorDocking. I am planing to use it, but I will modify. I have made some modifications already (the title bars of the dockable forms is nice now - not like that win 9X look). Also, when I tried to use the AnchorDocking, I get back to the classic GUI because the designer form still was separated. One of the advantages of make the docking feature built-in is that could be possible to "attach" the designer form too, like in Delphi(docked versions) with a dashed border around it.

Of course, I'm not mentioning that everything will be done from scratch. The important codes will be held.

*It is the first time I'm using this mailing list, so I don't know if I will do anything wrong :)
- Felipe Ferreira da Silva

Hi,
I use a 13" Labtop to develop with Lazarus.? (with AnchorDocking).

And please forget about this uggly stupid Ribbon-Style (as introduced with Office2007).

Just my oppinion.

And as already mentioned in other statements:

Style "changes/ has to change" in commercial products for marketing reason. Lazarus is not commercial and should only change style for "usability" reason.?

Regards,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/c8f4a65a/attachment.html>

I think the same, and I place the windows together too. Besides, my screen is just 1024x768 and space is a privilege. For example, the title bar of each window could be replaced by a smaller header(like it is called in the AnchorDocking), the same for the title bar of the editor and its big tabcontrol(I could replace it by the TTabSet that I created). For people with a big monitor, however, it would be good to keep the undocked option.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/8faa9958/attachment.html>

Martin wrote

Anyway, "improved with appropriated features": Which ones do you think can not be done in a package? (Assuming that all needed methods and hooks, are added to IDEIntf)?

But wouldn't be easier make direct implementations on the IDE instead of make constant adaptations?

- Felipe Ferreira

1) I didn't understand this first reason, what do you mean it hide/changes?
2) I agree that the interface of VS and Eclipise(which is very ugly) is for big displays... but look at your display! It is big, mine is only 1024x768. Don't you think that the title-bar of each windows on Lazarus is a unused space?

I agree that the name of the stuffs cannot change(at least, severely), people would get lost, and a lot of the Wiki and documentation should be updated.

This multi-monitor idea is cool! But probably would work only in the "undocked mode", I don't see how I could implement a single-window application with support for a multi-monitor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/965e6301/attachment-0001.html>

My general experience says, no it would not be easier.

That is, speaking of a propper implementation, with well designed code. That may even end up cleaning some of the existing code. But it is better to clean existing code, than to add more code that need cleaning (I do NOT suggest that your code would need to)

Usually separation, such as archived by a package, helps finding design weaknesses and helps improving the design. Assuming that a good design must be archived either way, that does not add any work.

The only extra work, is to add some methods/events to the IDEIntf (and call them from within the IDE code). That should mostly be declarations, or very simple code, such as creating an OnSomethingHappened event, instead of writing code inline. That are only a few lines. And strictly spoken: 99% they would be needed for the design reasons anyway, so they should not count as extra : Such a feature will always start of with some bugs, that then will be discovered and fixed. That is normal and expected. Putting that directly into theIDE puts the old interface at risk too. Separating it into a package reduces this risk.

Felipe Ferreira da Silva hat am 4.
Dezember 2012 um 13:44 geschrieben:

What do you mean with "constant adaptions"?

Mattias

It does, I use it across 2 screens. And it does better, than many other windows app.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/ba7360a3/attachment.html>

Let me clarify:
The code would be maintained the same as the IDE. It could be installed by default. (Such as codetools, they are a package, but without them the IDE would not be what it is)

In a separate step, existing window management (positioning of the none docked windows) could also be extracted to a package. Then the IDE would always need a window-manager installed.
Then from the end users view the window manager (docked or not) would be part of the IDE. But technically its a package.

I am in full agreement with this new user interface.

I think that it can't be explained or implemented better than that :-)

Michael.

To change one thing in Lazarus is a torture

some time ago was requested to implement an option where (on Linux) the TForm stay over the Code Editor (as in Windows). Add an option for anyone who so desire. Even today, years have passed, and this option does not exist.

It sounds like a joke but it is a truth, rsrsrsrs

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

Junior wrote

To change one thing in Lazarus is a torture

Then I am officially a masochist.

Yes the learning curve is step, especially for features like that. I had ho undergo that myself some years ago. But any project that size, takes time and effort to learn.

Again same with almost all projects. Even commercial ones. Sad but true.

In this case, I guess the people who can do it, are busy with other things (bugs and features).

And the above is not really something an one wants to do, because it would only be temporary. Evetually designer forms must be able to dock. And then any code for the above will be thrown away. No one wants to write code, that will be thrown away
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/82b678a5/attachment.html>

Presumably, the lazarus team decided there are more urgent things to be done.

But you are in luck: Lazarus is open source.

Nothing stops you from trying to implement this option yourself, and to donate the solution so the community can enjoy it as well.

The same is true for the docked-ide option under discussion:

The lazarus devels may decide there is enough demand and have a stab at it themselves. Or they may think that the request is not so important and leave it up to the community to develop such an option, giving support where needed.

One cannot expect more from volunteers.

Michael.

Il 04/12/2012 13:55, Felipe Ferreira da Silva ha scritto:

2) I agree that the interface of VS and Eclipise(which is very ugly) is for big displays... but look at your display! It is big, mine is only 1024x768. Don't you think that the title-bar of each windows on Lazarus is a unused space?

Well, I like to see as much code I can on screen, and vars window too, and trace variables window (with many vars), and as much info I can get in general, so I end up having a very crowded monitor.

But more important, I don't like wasted space... and yes, it would be cool to eliminate title bars, maybe using "onmouseover" popup balloons when the pointer rests near the top border for a second or two :-)

Another cool useful thing: tabbed compiler messages window. Now Lazarus (as many other IDEs) reports a lot of unimportant messages mixed with those really interesting, i.e. I'm not interested in compiler info or warnings if there are compiler errors. It would be nice to group errors, warnings and info in different tabs, so one could focus on important messages. Moreover, there would be much less need to scroll the message queue to find what I'm after at the moment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/39bd8d01/attachment.html>

In the project options, you can set what warnings you see. Putting them in tabs could be nice but I think I'd lose track of the order/sequence of events.

Having some way of hiding/filtering certain message classes on the fly (e.g. via a right-click menu) may be another solution.

... but I'm happy changing the project options.

Massimo Soricetti wrote

But more important, I don't like wasted space... and yes, it would be cool to eliminate title bars, maybe using "onmouseover" popup balloons when the pointer rests near the top border for a second or two :-)

If you use several SourceEditors, and some have only one tab: You can set the IDE to hide that tab, saving the space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121204/2e2027e8/attachment.html>

What is important for me is the height of the Editor window. I want to have as much as possible text visible in the editor. So any new interface should concentrate on putting things on de left and right site of the screen. With the editor maximised in the centre. The current Lazarus IDE does that! :-)

If you have some time and skills, you better try to integrate KZDesktop (form designer docking + automatic object inspector/code explorer switching), EasyDockManager (full layout saving) and AnchorDocking/GlassDocking (beautiful interface).

Not everyone is comfortable with the so-called docked interface.

usually I prefer non-docked, but the non-docked Lazarus interface completely sucks (at least on xfce):

- all Lazarus windows have the same icon, so you cannot jump fast with alt+tab to them
- => it takes forever to find the message window
- pressing ctrl+f8 to get to the next error message, focuses the message window and you cannot type anymore
- sometime focusing one Lazarus window, brings all Lazarus window to the front
- if you switch the desktop during the Lazarus startup, half the windows end up on the wrong one
- more I cannot remember right now

Benito

Well, thank you, guys!

Anyway, even if this is not a suitable idea and there is not so much demand for this, I'll still continue to contribute with components and with the discussion about dynamic packages... and keep working secretly on this :)

I agree with Michael. I tried AnchorDocking and it did not work for me. I need to be able to change values in the Property Editor and see the Form at the same time. I could not do that with Docking.

It should be up to the user, to dock the windows as desired.

If you are not pleased by anchor docking, try the EasyDockManager.

DoDi

leledumbo wrote

If you have some time and skills, you better try to integrate KZDesktop (form designer docking + automatic object inspector/code explorer switching), EasyDockManager (full layout saving) and AnchorDocking/GlassDocking (beautiful interface).

It is a problem to have many _almost_ good docking solutions. None of them is really good.
The potential development energy should be channeled into one of them, maybe Anchordocking.

Felipe Ferreira da Silva, you should learn the existing code now. It is always the biggest challenge with a big project. Anybody can write new code but understanding and modifying existing code is difficult. :)
The docking is a crucial feature and your help with it would be appreciated. I must say I don't know it well but Mattias will fill the gaps if you really learn it.
You wanted to add some of your components to Lazarus. First you should learn and maybe improve the existing custom drawn components to avoid duplicate effort. You could also make your own component library and publish it somewhere but then those components cannot be included in Lazarus IDE.

There are many other things to improve in Lazarus IDE of course.

Regards,
Juha

I planned to extract this off topic message but Martin was faster...

I remember there was even a bug report, maybe from you. I did not understand then what the problem really was and I still don't understand. Either the designer form or the source editor is active depending on which one you clicked last. You can press F12 to change the order, too.
I remember there was some difference in Z-order with GTK2 bindings when creating a new form.
So, in the worst case scenario you must press F12 _once_ after creating a new form! This is a non-issue IMO. There are ~1500 open issues in Lazarus bug tracker, most of them real bugs or feature requests. This one is just non-sense.

Yet, if you create code to change the Z-order behavior, I promise to apply your patch.
However, if you create yet another option to the Options dialog, I would reject it. There are so many options already that finding the useful ones is difficult. No need to pollute the dialog with non-sense options.

I am planning to simplify the compiler options and improve the build mode options, when I have time for it.

Juha

Do you want to only change defaults, or to allow for a user customizable IDE layout? An IDE with only one source-or-form editor window is unusable for me (and not only me) :-(

A single Message (or Search results...) window is okay, though. What's not nice is the lack of different Edit/Run layouts, where in Run mode the debug windows (call stack, variables...) could replace (show up/hide) the form designer, properties and other (component palette?) windows. A working "Hide designers on run" feature would be a great step into that direction.

DoDi

Felipe Ferreira da Silva wrote

Anyway, even if this is not a suitable idea and there is not so much demand for this, I'll still continue to contribute with components and with the discussion about dynamic packages... and keep working secretly on this :)

Are you referring to docking? There is demand for it! I think you answered a wrong thread now, see my reply on the original one.

And no need to work secretly. Good quality code always speaks for itself. Simply put : your code will be accepted to Lazarus codebase if it is good enough.

Juha

This multi-monitor idea is cool! But probably would work only in the "undocked mode", I don't see how I could implement a single-window application with support for a multi-monitor.

I'm using Lazarus across multiple monitors since years :-)

What problem do you expect with forms spanning multiple monitors, except for the frames around the screens?

There's only one problem with window positions, which are not handled properly when the screen coordinates (of top/left monitors) become negative. The IDE main form also may span multiple (left/right) monitors, what's not always desireable, and the according configuration option is flawed (using screen instead of monitor sizes).

DoDi

I think a good way to solve that is selecting a default dock manager (Easy Dock Manager or AnchorDocking) and make it installed as default for new instalations.

It's a pity that installing these packages requires to rebuild the IDE, so that a distribution can contain only one preconfigured IDE. As you've seen in the many contributions to this thread, there are hard-core users of both docked and undocked layouts. Which group should be preferred?

But one option should be feasable, to turn on/off an already installed DockMaster on the fly - similar to the Delphi Un/Docked layout option.

DoDi

IMO the first step should be the introduction of *selectable* IDE layout managers, so that all specialized code could be removed from the IDE.

But for that purpose we need an according interface in the first place, and the current (window placement...) interface is way too specific.

DoDi

When I looked at the IDE code, in implementing the EasyDockMaster, I found that code specialized for use with no or with anchor docking. It must be hell to add further layouts, regardless of the docking manager to be used :-(

Hint: Delphi allows for an CodeExplorer attached to *every* source code window. Lazarus only allows for an single CodeExplorer.

Yep. The flaws of *monolithic* IDEs are well known, such a model is only easy to *implement*, but not really nice to *use* :-(

I frequently need two or more source code windows visible at the same time, and thus have no use for a monolithic IDE.

Did you have a look at the EasyDocking sample? It includes a fully dockable sample IDE, and has provisions for any kind/style of dock headers.

DoDi

One of my monitors has negative x coordinates. I havent had an issue in a long time (with the IDE / with projects, desktopcenter has an issue)

May I recommend a third solution than fully docked/undocked? MSEide has a menu item 'View'-'Panels'-'New Panel' which creates a new empty dock container where tool windows and other panels can be placed. So one can create groups of windows which can be layered or tabbed, please see the screenshots on Sourceforge.

Martin

As Juha and others indicated: there is a lot of demand for this. There is also a lot of demand for keeping the current interface.

Therefore, I would look into using a package to provide the interface... and especially Juha's suggestion to look into merging and improving existing packages (which probably will get you a head start into the way packages work with Lazarus) together with improving the Lazarus code to properly separate the interface part from the rest.

(Yes, I know I'm posting in the wrong thread now as well; just wanted to let Felipe know his ideas are quite welcome)

The idea is suitable. There is demand for it; Just make sure it is optional. The suggestion of Martin Friebe to put it in packages, is still the way to go, I think.

I'm sure you will get fast responses to specific questions if you decide to implement it yourself.

Michael.

Is the restoring of tabbed (docked) windows in AnchorDocking working already?

Otherwise this might indeed be an interesting idea...

Regards,
Sven

2012/12/4 Hans-Peter Diettrich

This is precisely the point I was talking about! How can we think of something about it if we don't know which docking solution to work? I think our first standoff is now selecting a docking solutions to change their behavior in order to be able to create this menu "On The Fly"

sorry about any english mistakes...

Sven Barth hat am 5. Dezember 2012 um 11:19
geschrieben:

There is still a bug.

Otherwise this might indeed be an interesting idea...

Mattias

My second monitor has negative Y coordinates, is wider than the primary monitor, and I use docking. Then most windows are moved down to the primary monitor, where they can hang over the right margin (X preserved).

Since the EasyDockMaster stores the correct coordinates in his layout file, I had to modify the IDE dockmaster routines, until I got the layout work as expected. From that work I know about the problems built into the IDE layout management.

I admit that I haven't tested the 1.0.x releases, because I don't want to loose my tweaked working horse. Can I install a new version for an dedicated test user on Windows, without touching the existing installations for the default and other users?

DoDi

The IDE interface already has been tweaked for working better with AnchorDocking. But when at the same time EasyDocking doesn't work as it should, then this indicates *general* flaws in the IDE layout management
- *this* is where some more work should be spent!

More problems arise from the Delphi incompatible DragManager and DragObjects, which affect all drag-dock operations. Dunno how this is managed in an AnchorDocking IDE, because (basic) AnchorDocking has no drag-dock functionality.

DoDi

Without concrete example, this info is useless. no one can do anything about it.

Either detailed steps to reproduce,
Or the exact lines at fault (and preferable why they are, if it isn't really plain obvious.)

If I open an easydock ide, and place my source editors in 2 undocked windows, and put both on on monitor, then the will be in those positions after I restart.

This is how a dockable IDE should work, implemented e.g. in EasyDocking. Delphi implements just this docking model, without the neeed for dedicated dock sites (panels).

The Delphi terminology is misleading here, suggesting that the classic Undocked layout stands in contrast to the docked (monolithic) layout. "Undocked" IMO should be understood as "not everything docked into one big window", not as "without docking capabilities".

As I see it, Lazarus comes with these really different docking models:
- not dockable at all (default)
- dockable by glueing windows together (anchor docking)
- dockable into containers (Delphi compatible)

The last model is what you and I have in mind, and it should be fully supported by Lazarus.

DoDi

Steps to reproduce:
1. Get an narrow and an wide monitor, e.g. CRT and Flatscreen.
2. Attach both to your computer, the wide one as secondary monitor.
3. Configure the wider monitor to have negative Y coordinates.
4. Make Lazarus use the EasyDockMaster.
5. Show and move the CodeEplorer to the right of the wide monitor.
6. Save and close the IDE.
7. Reopen the IDE, check all IDE window positions. [Did I miss something?]

Or the exact lines at fault (and preferable why they are, if it isn't really plain obvious.)

I could not find out all the ways, how the desired postions of IDE windows are affected by the many involved objects and calls :-(

If I open an easydock ide, and place my source editors in 2 undocked windows, and put both on on monitor, then the will be in those positions after I restart.

A single monitor is not a problem, at least when it is the primary monitor.

DoDi

Dont know, but here is what I did:

I have 2 screens. both normally 1680x1050
- I told my system that my secondary monitor was now above the primary (A lie, but my PC did not notice). x=0..1690 y=-1050..-1
- I set the resolution on the primary to and had only 1400*1050 (all positive coords)

I guess that is the setup?

I opened lazarus. All windows (not all docked) are on the primary screen I open the code explorer, and move it all to the right of the upper screen (wider)

restarted

Still in pos

The IDE only must ignore the IDEDockMaster object, when docking is turned off. The dockmanager is not affected, it only gets nothing to do, then.

Saluz
DoDi

Great :-)

DoDi