Please have a look at examples/dockmanager/elasticsite/SiteTest project. It demonstrates how docking could work in the Lazarus IDE, and how multiple editor windows could be implemented.

The project has been tested on Win32 and Linux (gtk2), taking into account the different handling of docking. Since the Linux window managers do not (easily) allow to dock forms, all dockable items shall be dragged out of their containing form, not by dragging the forms themselves.

The presented editor notebook has extended docking capabilities:

Every file (tab) can be dragged and docked, so that any number of editor window can be created by dropping an tab onto the desktop, or into another editor window.

An entire notebook can be dragged as well, from some empty space in the tab bar. The result may be surprising, it's only a quick proof of the concept ;-)

The ElasticSite allows to dock other components, into or onto the site. The demo expands and shrinks the site automatically, when something is un/docked to the left, right or bottom of the form. This behaviour currently is available only with the primary (inital) application window, not with secondary editor windows. This is not a conceptual restriction, only a limitation of the demo project.

You may encounter some more quirks in the demo project. Please have a look at the comments in fEditorSite.pas. I dunno how to prevent the "Keep references" question when compiling the project - the references MUST be kept.

Paul has suggested another discussion of docking, I'm just collecting opinions about the intended topics and goals. Mattias?

IMO we should agree about a platform independent docking model, that works for all window managers.

We also should agree about the essential docking features, including the notebook docking, re-docking and floating of components. WRT the IDE we are not bound to the flawed Delphi docking model, that effectively is only a poor extension of the drag-drop feature. Even the Delphi IDE seems to use a slightly different drag-dock model, what doesn't prevent the current RAD Studio IDE from crashing when the user does not obey the limitations of the model and its implementation.

Currently we have three docking approaches: anchored docking and tree-based LDock and EasyDockSite managers. We should compare the available features and the pro's and con's of these models.

DoDi

Hans-Peter Diettrich wrote

Please have a look at examples/dockmanager/elasticsite/SiteTest project. It demonstrates how docking could work in the Lazarus IDE, and how multiple editor windows could be implemented.

Does not work with fpc trunk

C:\lazarus_latest\examples\dockmanager\package\felasticsite.pas(106,35) Error: Can't take the address of constant expressions

When a new FPC version imposes such restrictions, then it also should convert shortcuts like Inc and Dec into macros.

While Inc and Dec were *introduced* into the language as optimization hints, for using according machine instructions, they *nowadays* are means to eliminate duplicate code (expressions).

I know about the strange opinions of some FPC developers, which also require that Inc with an (small) negative amount should raise an overflow exception, only because an unsigned machine instruction would do so, on certain machines. Such argumentation is ridiculous, with regards to the Wirthian pragmas.

DoDi

All fine and good. But it doesn't help, unless you convince the fpc developers.
Eventually the new Version of FPC will be used, and eventually all code has to be able to be compiled with it....

For the moment though, you are right. I can not really complain if it doesn't work for me, simple because I use an unreleased fpc version. do you think it will be fixed before release?

Martin

All fine and good. But it doesn't help, unless you convince the fpc developers.

Right :-(

Eventually the new Version of FPC will be used, and eventually all code has to be able to be compiled with it....

I have several suggestions:

- apply the new rules only in $mode Delphi
- use an (global) switch to treat Inc/Dec as macros or operators
- introduce new Incr/Decr macros, to reduce required editing of legacy code

For the moment though, you are right. I can not really complain if it doesn't work for me, simple because I use an unreleased fpc version.

Can't you configure Lazarus to use the old fpc compiler?

do you think it will be fixed before release?

I'll have to get a SVN version of fpc, before I can start fixing my code... And if so, I only will replace Inc/Dec by my added Incr/Decr macros. You can do so yourself, already. Feel free to update my code accordingly :-)

DoDi

What is on that line?

Vincent

I'll have to get a SVN version of fpc, before I can start fixing my code... And if so, I only will replace Inc/Dec by my added Incr/Decr macros.

I don't think so, as the easydockmanager package does not compile with 2.5.1 either:

/home/satan/pascal/lazarus/examples/dockmanager/package/fdockbook.pas(46,5) Error: Fields cannot appear after a method or property definition, start a new visibility section first

Not a big problem, but one that has to be fixed, too. I thought that fields after method/property were disallowed since 2.4.0 but my memory must be playing tricks on me if it works for you.

I will give your example another try when/if it compiles on 2.5.1, as I am too lazy to install an old fpc.

R.

On Fri, 6 Nov 2009 08:02:30 +0100
Reimar Grabowski wrote:

Sorry for the noise, forgot to update Lazarus before trying.

R.

What is on that line?

  dec(DragTarget.Left, w);
  w: integer;
  DragTarget: TControl;

R.

Please have a look at examples/dockmanager/elasticsite/SiteTest project.

I fixed the compilation under fpc 2.5.1, the wrong unit paths and added synedit dependency. I also added the lpl file, so that the package is found on first open.

Mattias

Little chance, because they made this change on purpose: http://wiki.lazarus.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields

The reason for the change was better following the object pascal language: the use of properties should not depend on the way they are implemented. This is not a Delphi only choice.

You need to update your compiler version anyway, if you want to start implementing macros with parameters. ;-)

Vincent

FPC doesn't know parameterised macro's.

Oh, and before you judge the FPC devels, maybe try to find out if there was a problem with this construct first. Most of these limitations are added not just out of compatibility, but also because there was a bugreport about some corner case where this would break.

I'll have to get a SVN version of fpc, before I can start fixing my code... And if so, I only will replace Inc/Dec by my added Incr/Decr macros. You can do so yourself, already. Feel free to update my code accordingly :-)

That's a bit childish IMHO.

Hans-Peter Diettrich wrote

Can't you configure Lazarus to use the old fpc compiler?

this mail wasn't about my problem, but rather about giving you the info.

BTW fpc may be right about it, and even if inc/dec was a build in magical thing...

 dec(DragTarget.Left, w);

Where "DragTarget" is a property

It is explainend somewhere in the fpc release notes, but here is the essence:

- A property is meant to be treated like a function:
  property Bar: TType read FBar;
  property Bar: TType read GetBar;

By introducing the first type of property, the author reserves the right to later change it into the 2nd type (with getter function). (An alternative meaning of the property could mean the variable is to be treated read only)
If the above statement is changed all code should continue to work. "Dec(FunctionResult);" are and always have been invalid statements.

Anyway this isn't my argument.
(and I see your point that a macro could use the write/setter)

> do you think it will be fixed before release? I'll have to get a SVN version of fpc, before I can start fixing my code...

Actually my question was meant different and ironical: Your mail sounded like you blame it on fpc. So i mean "Do you think fpc will be fixed (changed back)"
Since we both know the answer to that isn't going to be yes => I did assume that the answer related to your code would be "yes"

I had no intend to imply, that there was any question if you would take care of your code....

Martin

Did you notice that the example does *not* provide a solution? For good reason, IMO, because the changed property handling results in an code bloat for no specific reason. When the compiler could determine in the past, where assignemts to e.g. fields of record properties are possible, and where they are not, it can continue to do so.

My preferred workaround for the changed Inc/Dec behaviour is a macro, that allows to preserve exactly the old behaviour, without bloating the code. I wonder where there remains anything good, when the compiler then will have to process a macro and to do CSE, where it has not been required in the past, and possibly will generate *more* code for exactly the same result :-(

>> Eventually the new Version of FPC will be used, and eventually all >> code has to be able to be compiled with it....

I'd wait at least for an official FPC release before changing the LCL code. Perhaps there will come a compatibility option, that allows to use the old behaviour even in new FPC versions.

Who defines the OPL? If compatibility with other than Delphi compilers is desired, according modes can be added.

The behavior/implementation of Inc/Dec is questionable, together with the stricter property abstraction. (see my above workaround)

Oops :-(

DoDi

Please have a look at examples/dockmanager/elasticsite/SiteTest project. It demonstrates how docking could work in the Lazarus IDE,

Gave it a try and it looks like it needs some more work.

1. Docking anything left or right of the editor is much harder than docking below. I have no idea why.

1.a) Sometimes it does not don't know what I have to do to make it work. Sometimes it works and sometimes it doesn't. Docking should be intuitive and "just work(tm)".

1.b) Undocking the editor causes an AV.

2. I don't like that I have to drag&drop/dock the contents of a window instead of the window itself but this seems to be the standard nowadays.

3. I don't like the inconsistent positioning of the 'undock X'. Sometimes it is in the upper left corner, sometimes the upper right and sometimes it is not like that tabs are inserted when docking more than one component in the same place. I don't like that the last tab is not removed if only one component is left in that place.

5. Visual feedback for docking is important but the red frames are just ugly.

I don't think that it is ready for Lazarus as it is. But with some more work it may be in the future. Hopefully any kind of docking will be available soon, as the multi window approach feels more and more cumbersome.

Btw this is on Linux with gtk2.

R.

> Can't you configure Lazarus to use the old fpc compiler? this mail wasn't about my problem, but rather about giving you the info.

Thanks, I assumed that you cannot run the program at all.

DragTarget evaluates to an object, that can be modified without barreers. The dirty part, in all situations, is the very last (here: .Left) property, that must be read AND written by Inc.

Aha!

Since we both know the answer to that isn't going to be yes => I did assume that the answer related to your code would be "yes"

Question is, what's a "release" version of a sample project. There are more important things in the code, and in the LCL, that *really* deserve updates.

So I could return the question: will the LCL be fixed before release?

When somebody acknowledges that the found issues are LCL bugs that cannot be fixed on-the-fly, I'll create according bug reports.

DoDi

Actually "left" is a property.

Wich means it is handled as a funtion result (because the getter can
chamge at anytime)
Txxx = class
  function GetLeft;
 property Left read getLeft;
end;
inc(xxx.left);

The inc in this case can not work.

release never referred to your project.

"do you think fpc will be fixed (before the fpc 2.4.0 release)" And that is not really a question: fpc will not be "fixed" (changed back)

Besides "fixed" is the wrong word to, because it is the intended behaviour, so it is not broken.

LCL code must be compilable with the latest fpc release (fpc 2.2.4), the latest fixes branch (fpc 2.3.1) and the latest trunk (fpc 2.5.1)

We are fortunate that this sources are not part of the LCL.

Quiet a percentage of the Lazarus developer use fpc 2.3.1 or 2.5.1, those developers can not try out your code easily.

Vincent

On what OS and widgetset?

1. Docking anything left or right of the editor is much harder than docking below. I have no idea why.

The bottom panel is one pixel wider than the other ones, due to problems with the arrangement of the splitter, panel and statusbar. But this should not make a difference with docking.

The InfluenceRect can be enlarged, if that helps.

1.a) Sometimes it does not don't know what I have to do to make it work. Sometimes it works and sometimes it doesn't. Docking should be intuitive and "just work(tm)".

Can you describe what exactly doesn't work?

The initial influence area is restricted to the top/left part of the panels - due to an bug in the LCL.

1.b) Undocking the editor causes an AV.

The editor should not be undocked at all - see the warning about surprising behaviour of the demo.

2. I don't like that I have to drag&drop/dock the contents of a window instead of the window itself but this seems to be the standard nowadays.

Windows can not be docked on all window managers, so that we have to pick a portable model.

3. I don't like the inconsistent positioning of the 'undock X'. Sometimes it is in the upper left corner, sometimes the upper right and sometimes it is not you provide an screenshot? It should only be at the top of a

vertical bar, or to the right of a horizontal bar.

Docking the windows from the View menu doesn't work properly right now, it will be corrected in the next version.

4. I like that tabs are inserted when docking more than one component in the same place. I don't like that the last tab is not removed if only one component is left in that place.

Would you also like to have no tab for an single file in the editor?

5. Visual feedback for docking is important but the red frames are just ugly.

That's a matter of the implementation in the widgetset. This also may be the reason for your docking problems.

Strange, I cannot reproduce most of your problems in that environment.

Thanks for your feedback :-)

DoDi

Of course it's impossible to increment a read-only property. In this case a compiler error should occur.

But TControl.Left is defined as

   property Left: Integer read FLeft write SetLeft;

and could be incremented in preceding FPC versions.

Inc() could work when expanded like a macro, and this is how it seems to have behaved in the past.

DoDi

That's the version I'm using.

Quiet a percentage of the Lazarus developer use fpc 2.3.1 or 2.5.1, those developers can not try out your code easily.

But they could make it work easily. I cannot find all places, that need modifications, without compiler messages.

DoDi

Why do I feel misquoted? Or did I leave out the "*AND*" in the rest of the sentence and you interpreted that the other fpc versions are optional.

Vincent

I wanted to point out that I cannot make my code aware of future compilers now. I also feel no need to do so, until the next version is released, and all changes and related options are known.

Nonethless I agree that my code does not compile properly, so that it deserves workarounds for the (now) known compiler bugs.

DoDi

Nonethless I agree that my code does not compile properly, so that it deserves workarounds for the (now) known compiler bugs.

Compiler bugs don't need workarounds they need bug reports. ;)

R.

I've increased the influence rectangle, so that docking should be easier now.

Also added is the option to dock a window into or onto the edit window. You'll see the according docking rectangles, inside or outside the target window, depending on the mouse position.

Some more flaws of the docking model turned out, when I wanted to make the View windows dockable to each other. Currently it's not possible to separate the docked windows :-(
Workaround: dock the window to the editor window, then undock it again to the desired position.
I'll try to find an workaround for this flaw of the docking model.

DoDi

I did some more work, and fixed almost all the flaws :-)

Please check again and report (everybody!)

1. Docking anything left or right of the editor is much harder than docking below. I have no idea why.

I've increased the InfluenceRect, should now be easier to hit. I also made the window auto-elastic, i.e. the user has the option to dock a window into or onto the editor window - watch the docking frames appear inside or outside the window, depending on the mouse position.

1.a) Sometimes it does not don't know what I have to do to make it work. Sometimes it works and sometimes it doesn't. Docking should be intuitive and "just work(tm)".

Should work now.

What still does not work is floating a docked View window - due to the bad docking model implemented in the LCL. But I'm still searching for an workaround...

1.b) Undocking the editor causes an AV.

Should not happen any more. It should no more possible to undock the editor notebook from the main window. I dunno what happens to the secondary editor windows, perhaps a racing condition while undocking?

2. I don't like that I have to drag&drop/dock the contents of a window instead of the window itself but this seems to be the standard nowadays.

This behaviour is caused by the (Linux...) window managers. We could add a docking handle to the windows' caption bars, but this will give the Lazarus windows an non-standard look and feel.

3. I don't like the inconsistent positioning of the 'undock X'. Sometimes it is in the upper left corner, sometimes the upper right and sometimes it is not changed the dockheader for the View forms, in two ways:

- The headers no shows the client names.
- The header now disappears when a floating site only has one client.

Both are options of the EasyDockSite docking manager, individually settable for each dock site.

4. I like that tabs are inserted when docking more than one component in the same place. I don't like that the last tab is not removed if only one component is left in that place.

This will be changed later. The Editor notebook should retain the tab with the filename, even for an single open file. Other notebooks should behave as mentioned above, that the header (tab bar) is shown only for multiple pages. But then we may get problems with undocking such an headerless client :-(

5. Visual feedback for docking is important but the red frames are just ugly.

Please create an bug/feature report. I dunno how docking looks and feels with other gtk applications, the docking rectangles are implemented in the LCL widgetsets.

I don't think that it is ready for Lazarus as it is. But with some more work it may be in the future. Hopefully any kind of docking will be available soon, as the multi window approach feels more and more cumbersome.

If you're pleased now by the offered docking features, despite some minor implementation details, I'll start to integrate the features into the Lazarus IDE.

This will require some more adaptation to the existing types of the IDE windows. Some of these windows eventually must become frames, that dock together nicely. And finally the persistence of the docking layout must be implemented. Perhaps I can copy some code from the current dockable IDE approach, but that code obviously was never tested, and doesn't work as it should.

DoDi

Try the following,

- open one or 2 sources in the main window (just to make sure you have some tabs)
- show object inspector (or messages...) and dock to the main window ( it must be docked to the main win, or it will not happen)

- now grab the OI at it's top left corner and start dragging

You should see the dragging rectangle for the OI. The mouse should touch (or be within pixel distance of) the corner of the rectangle Move the mouse over the remaining tabs (and keep moving / move from one tab to the other and back, possible with a simultaneous up/down move).

Because the mouse and the drag border are over the tabs at the same time, the border leaves ghost images of itslef (windows) The reason is that the tabs redraw themself if the mouse goes over (in order to show a bit of highlight indication) [ so the whole thing is theme dependent ]

Since the frame draws deletes by inverting the screen, any changes to the screen (as the redraw of the tab) causes frame-fragment to be left behind.

------------------------
I haven't looked at your code.

but the IDE does "setCapture" (same as MouseCapture := true) to the control that is going to be dragged. That way all mouse events go there, and the tabs don't get them.

Martin

Hans-Peter Diettrich wrote

Please have a look at examples/dockmanager/elasticsite/SiteTest project. It demonstrates how docking could work in the Lazarus IDE, and how multiple editor windows could be implemented.

Since the mouse is captured while dragging, no other control should react on mouse moves itself. If this will happen, it's a flaw in the widgetset or dragging model itself[1]. At least I could not get such unwanted visible component feedback on Linux/gtk2.

I admit that the tabs react on Win32, and that consequentially artefacts may be possible, even if I could not produce any.

Artefacts may come from other events, e.g. when a OnDockOver event handler updates the statusbar, and the dragging frame moves over the statusbar, but that then is a bug in the application.

Since the frame draws deletes by inverting the screen, any changes to the screen (as the redraw of the tab) causes frame-fragment to be left behind.

AFAIK Paul implemented the dragging frame on gtk2 by a transparent (top level) window, that should be clipped or repainted properly in any case. The same may be implemented for other widgetsets as well.

------------------------ I haven't looked at your code.

No need to do so. The sample application shall demonstrate *both* the possible and impossible features, feasable with the existing docking model. All bug reports and suggestions are welcome, and I'll either try to reflect them in the demo program, or leave them for the docking redesign discussion.

but the IDE does "setCapture" (same as MouseCapture := true) to the control that is going to be dragged. That way all mouse events go there, and the tabs don't get them.

That's part of the DragManager LCL logic, that cannot be changed by any application. What you see is an effect from one of the many flaws in the Delphi drag-dock model, and should be remembered for the discussion of a general docking redesign.

[1] One of my older suggestions addresses exactly the improper handling of the mouse capture, where all mouse events should be filtered immediately (TApplication.ProcessMesssages?), when a mouse capture is active. This will eliminate according tests within the further message handling, and will eliminate any chance that other components will fail to handle a mouse capture properly. Such a filter would not (adversely) affect the performance of the message handling system, when it checks for an active mouse capture first, before any filter logic (tests...) is applied.

DoDi

hi!
TShellListView and TShellTreeView not show correctly russian filenames. This patch for correct bug:

***************
*** 373,379 ****

      else ObjectData := nil;

      // AddFile identifies if the file is valid or not
!     if AddFile then AResult.AddObject(DirInfo.Name, ObjectData);
      FindResult := FindNext(DirInfo);
    end;
--- 373,383 ----
      else ObjectData := nil;
      // AddFile identifies if the file is valid or not
!     {$IFDEF Windows}
!       if AddFile then AResult.AddObject(AnsiToUTF8(DirInfo.Name), ObjectData);
!     {$else}
!       if AddFile then AResult.AddObject(DirInfo.Name, ObjectData);
!     {$endif}
      FindResult := FindNext(DirInfo);
    end;
***************
*** 581,586 ****
--- 585,594 ----
      begin
        NewItem := Items.Add;
        CurFileName := Files.Strings[i];
+       {$IFDEF Windows}
+       CurFileName := AnsiToUtf8(CurFileName);
+       {$ENDIF}
+
        CurFilePath := IncludeTrailingPathDelimiter(FRoot) + CurFileName;
        // First column - Name
        NewItem.Caption := CurFileName;

hi! TShellListView and TShellTreeView not show correctly russian filenames. This patch for correct bug:

A chose a different way, please try and test r22744.

Vincent

thanks, work