Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Hans-Peter Diettrich schrieb: I guess you identify forms by their name? Yes. I've added a Factory property to the DockingManager, that is responsible for ReloadDockedControl (if set). The IDE should use the docking manager like any LCL app would do. There exist some issues with form ownership. The Factory can set the owner of the forms as appropriate. Otherwise the forms will have to be owned by either the DockingManager or by Application. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
On Sun, 22 Nov 2009 01:06:48 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Mattias Gaertner schrieb: The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager. LDockCtrl describes the interface that is nailed into the IDE units and methods. Which were always in IFDEF, so no one will cry if this is changed or broken. It would be very hard to remove all that stuff, and after all it has to replaced by something similar. That's why I want to retain that interface, and only change it to use a different management internally. Have you solved the layout restore in your docking manager? I can't, as long as I don't know how the IDE windows are created and managed (owners...). There seems to exist a dedicated OwningComponent in the IDE, that holds references to some (most? all?) IDE windows. The IDE also has to iterate over all windows when the configuration is stored, it's not yet clear to me how this works (TIDEWindowLayoutList?). This depends on your docking manager. For example the anchor docking manager works like this: There is one central TLazDockingManager object and every window that should be dockable gets a TLazControlDocker with a unique name. The IDE only needs to call LoadFromConfig/SaveToConfig (and of course the default form positions). But: the anchor docking manager is not finished. The OwningComponent exists only to destroy components (and FreeNotifications). Windows that are destroyed by code don't need this. In a simplified model every persistent IDE window should register itself after creation. This could be done in an extended version of the OwningComponent, or in IDEWindowLayoutList.Apply and OnApply, which would make the added forms dockable. Afterwards the forms can be docked by the user, all related information is available in their HostDockSite. All other stuff, introduced with anchor docking (ControlDocker...), can be removed from the forms and other classes. The host sites can be managed independently, but their coordinates and layout should be stored along with the other forms' layout description. When the layout is restored after the next start, the stored information can be used in IDEWindowLayoutList.Apply, to create the dock sites and dock the forms. Maybe you can write a text and/or wiki how to use your docking manager? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Mattias Gaertner schrieb: The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager. LDockCtrl describes the interface that is nailed into the IDE units and methods. Which were always in IFDEF, so no one will cry if this is changed or broken. The unit is in the uses of many units, the types are reflected in class fields etc. I've tried to exclude the LDockCtrl stuff from the IDE, by an conditional exclude of everything inide the LDockCtrl unit, and it requires a lot of additional IFDEFs. I can provide an according patch, if you don't want to complete that yourself. Have you solved the layout restore in your docking manager? I can't, as long as I don't know how the IDE windows are created and managed (owners...). There seems to exist a dedicated OwningComponent in the IDE, that holds references to some (most? all?) IDE windows. The IDE also has to iterate over all windows when the configuration is stored, it's not yet clear to me how this works (TIDEWindowLayoutList?). This depends on your docking manager. I can design the docking manager according to any needs. Do you want me to reinvent the entire IDE form layout classes and procedures? For example the anchor docking manager works like this: There is one central TLazDockingManager object and every window that should be dockable gets a TLazControlDocker with a unique name. The TLazControlDocker is evitable, since all docking information is already stored in the DockManagers. The forms do not need to know whether they are dockable, and where they are actually docked. Their DragMode and DragKind can be changed from outside, as is done in TLazControlDocker.SetControl. Since I've introduced an dock grabber (the pin icon), this image control could replace the TLazControlDocker. I only didn't succeed in making it a new visual component, perhaps you can help me with this task? The IDE only needs to call LoadFromConfig/SaveToConfig (and of course the default form positions). That information has to be provided in a way that the IDE currently uses. That's why I intended to stay with the current config files and procedures, and only add to it the docking specific information. But: the anchor docking manager is not finished. I noticed that - restoring the docked IDE layout makes the IDE unusable :-( The OwningComponent exists only to destroy components (and FreeNotifications). Windows that are destroyed by code don't need this. In normal applications all such forms are owned by the Application object. I found a notice in the IDE code, that this results in some slowdown, but didn't understand the rationale. Maybe you can write a text and/or wiki how to use your docking manager? The usage is simple, see the MakeSite example. It's sufficient to create an TDockMaster instance, and to call DockMaster.CreateDockable for every dockable form. When Load/SaveConfig is added, it will only store the docking information. When the positions of other forms shall be handled as well, another registration method (e.g. CreateNonDockable) can be added (to be specified). When special docking to e.g. an editor form is desired, AddElasticSites does this job. Otherwise it would be sufficient to have fully featured TSynEdit descendants, that can be docked into any notebook (see the SiteTest example). The synchronization of the editor instances can be implemented independently from any docking issues. If you want to retain the current SourceEditor forms, the docking manager will not handle the pages in their notebooks - you have to restore the open file pages (tabs) yourself. With dockable SynEdit controls it would be possible to add a FileName property to the stored docking layout information, so that the docking manager can also restore the editor pages. Then the SynEdit components can register themselves in an file editor pool, that handles e.g. multiple editors for the same file - just as you are currently implementing. I'd suggest to implement something like a VirtualSynEdit component, that works with a detached instance of the editable text. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
On Sun, 22 Nov 2009 14:55:52 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Mattias Gaertner schrieb: The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager. LDockCtrl describes the interface that is nailed into the IDE units and methods. Which were always in IFDEF, so no one will cry if this is changed or broken. The unit is in the uses of many units, the types are reflected in class fields etc. Yes, it is a little bit work. I've tried to exclude the LDockCtrl stuff from the IDE, by an conditional exclude of everything inide the LDockCtrl unit, and it requires a lot of additional IFDEFs. I can provide an according patch, if you don't want to complete that yourself. Let's first get some example running. Last time I tried it did not work. Maybe you can write a text/doc how it is supposed to work. Have you solved the layout restore in your docking manager? I can't, as long as I don't know how the IDE windows are created and managed (owners...). There seems to exist a dedicated OwningComponent in the IDE, that holds references to some (most? all?) IDE windows. The IDE also has to iterate over all windows when the configuration is stored, it's not yet clear to me how this works (TIDEWindowLayoutList?). This depends on your docking manager. I can design the docking manager according to any needs. Do you want me to reinvent the entire IDE form layout classes and procedures? Do you think this is necessary? I hope not. For example the anchor docking manager works like this: There is one central TLazDockingManager object and every window that should be dockable gets a TLazControlDocker with a unique name. The TLazControlDocker is evitable, since all docking information is already stored in the DockManagers. The forms do not need to know whether they are dockable, and where they are actually docked. Their DragMode and DragKind can be changed from outside, as is done in TLazControlDocker.SetControl. ok. I guess you identify forms by their name? Since I've introduced an dock grabber (the pin icon), this image control could replace the TLazControlDocker. I only didn't succeed in making it a new visual component, perhaps you can help me with this task? TLazControlDocker is not visual. What do you want to do? The IDE only needs to call LoadFromConfig/SaveToConfig (and of course the default form positions). That information has to be provided in a way that the IDE currently uses. That's why I intended to stay with the current config files and procedures, and only add to it the docking specific information. The IDE should use the docking manager like any LCL app would do. ... Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Mattias Gaertner schrieb: Let's first get some example running. Last time I tried it did not work. Maybe you can write a text/doc how it is supposed to work. What did you try, and what didn't work? I'm continuously updating the examples and the dock manager, according to new needs. I guess you identify forms by their name? Yes. Since I've introduced an dock grabber (the pin icon), this image control could replace the TLazControlDocker. I only didn't succeed in making it a new visual component, perhaps you can help me with this task? TLazControlDocker is not visual. What do you want to do? Since forms are not dockable on all platforms, I decided to add an grip to every dockable form. It could be added to the caption bar or somewhere else, but a visual component in the client area is independent from widgetsets and other platform and window manager issues. The optical design can be improved, if somebody wants to do that... The IDE only needs to call LoadFromConfig/SaveToConfig (and of course the default form positions). That information has to be provided in a way that the IDE currently uses. That's why I intended to stay with the current config files and procedures, and only add to it the docking specific information. The IDE should use the docking manager like any LCL app would do. If you think that it's that easy, then you can already integrate uMakeSite into the IDE, and I'll only add the config persistence :-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Martin schrieb: = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking I'm just trying to hook into IDE docking, by replacing the LDockCtrl unit. Since LDockCtrl is part of the LCL package, it IMO can be overridden in a (local test) Lazarus project by a direct reference to a different implementation, with no other modifications required so far. If this approach doesn't work as expected, LDockCtrl should be splitted into an IDE specific and an implementation specific (anchor docking) part. Possibly a new package must be created, that is used in all the IDE packages. Another approach would replace the LDockCtrl unit in the (local test) LCL package, but this would influence all projects, not only the IDE. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
On Sat, 21 Nov 2009 11:30:23 +0100 Hans-Peter Diettrich drdiettri...@aol.com wrote: Martin schrieb: = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking I'm just trying to hook into IDE docking, by replacing the LDockCtrl unit. Since LDockCtrl is part of the LCL package, it IMO can be overridden in a (local test) Lazarus project by a direct reference to a different implementation, with no other modifications required so far. If this approach doesn't work as expected, LDockCtrl should be splitted into an IDE specific and an implementation specific (anchor docking) part. Possibly a new package must be created, that is used in all the IDE packages. Another approach would replace the LDockCtrl unit in the (local test) LCL package, but this would influence all projects, not only the IDE. The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager. Have you solved the layout restore in your docking manager? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Mattias Gaertner schrieb: The unit ldockctrl is only about anchordocking. You don't need to use or alter it for your docking manager. LDockCtrl describes the interface that is nailed into the IDE units and methods. It would be very hard to remove all that stuff, and after all it has to replaced by something similar. That's why I want to retain that interface, and only change it to use a different management internally. Have you solved the layout restore in your docking manager? I can't, as long as I don't know how the IDE windows are created and managed (owners...). There seems to exist a dedicated OwningComponent in the IDE, that holds references to some (most? all?) IDE windows. The IDE also has to iterate over all windows when the configuration is stored, it's not yet clear to me how this works (TIDEWindowLayoutList?). In a simplified model every persistent IDE window should register itself after creation. This could be done in an extended version of the OwningComponent, or in IDEWindowLayoutList.Apply and OnApply, which would make the added forms dockable. Afterwards the forms can be docked by the user, all related information is available in their HostDockSite. All other stuff, introduced with anchor docking (ControlDocker...), can be removed from the forms and other classes. The host sites can be managed independently, but their coordinates and layout should be stored along with the other forms' layout description. When the layout is restored after the next start, the stored information can be used in IDEWindowLayoutList.Apply, to create the dock sites and dock the forms. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Why a complete second window? Why not simply use a split-screen like what is done in many existing editors - including Visual Basic 6? In VB6 you had a little bar in the top right above the scrollbar if I remember correctly. Simply drag the bar down and you have a horizontal split-screen showing the same file. That way you can reuse the statusbar, probably keyboard shortcut handling etc too. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Paul Ishenin wrote: Martin wrote: Compiling Lazarus (SVN / Snapshot) with -dSynDualView allows you to open a 2nd window for any open source file. I compiled but I don't see the second window. How to activate it? There is an extra entry in the source-editor pop-up menu, open another view (3rd from top) Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Graeme Geldenhuys wrote: Why a complete second window? Why not simply use a split-screen like what is done in many existing editors - including Visual Basic 6? I prefer the second window, since most of my time i develop code using multiple monitors (of unequal dimentions and shifted elavation). Having a split-screen wouldn't work for me. Btw. great feature, can wait to see the full potential of this. Kind regrads, Torsten Bonde Christiansen. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Martin wrote: That's why I said: when/if there will be docking. The 2nd 2indow is just a cheap fix for the meantime. Sorry, I jumped the gun a bit with my reply. They are missing, because source-editor isn't yet ready for it. All you currently get is a plain SynEdit. (I know this is a limitation, but I only just started on it) No worries, I now understand. It's all still work in progress. ;-) I can now see that horizontal split is not idea for all cases, so your idea is better. Separate window for now, that could later be docked. A good example (even for myself) of where vertical split is the perfect choice, is in the Beyond Compare 2 product - diff viewer and copying data left or right. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Martin schrieb: Compiling Lazarus (SVN / Snapshot) with -dSynDualView allows you to open a 2nd window for any open source file. The 2nd Window can be edited, and all edits made in one window, are also done in the other window (they edit the same source). Very nice, have to try out immediately! :-) I get an error: uemOpenAnotherView not defined, in sourceeditor.pp? = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking Why wait? When we fix the details now, I know what to implement for docking. See the MasterSite example for my current suggestion: Every IDE window can become an elastic dock site, with added dock panels at the left, right and/or bottom, by calling AddElasticSites(). My plan is to make the editor windows such dock sites, but also the main bar can be configured in the same way. This is optional eye candy, can be replaced by the next option: All (other) dockable forms are wrapped into floating forms with a DockManager, from which they can be docked together or into the elastic sites of another window. Empty floating host sites (after undocking their client) destroy themselves. Dockable forms are created by TDockMaster.CreateDockable, and can be configured further by the caller. Please note that the MakeSite example is not yet finished, emptied notebook do not yet disappear - this will be cured in the next update. It would be nice to have any number of editor windows, creatable on demand (your part). Persistence of the layout has to be defined. All dock sites can be enumerated, and can store their coordinates, layouts and content. The restauration of an layout is just unclear, with regards to the recreation of the docked forms. We'll have to find a solution for multi-instance forms, like editor windows, and for re-creating the docked forms by their name and instance number, instead of their ID. My current plan is to use the form name to specify the form type (class name) to create, e.g. TMessageWindow for MessageWindow or MessageWindow1 (see TDockMaster.CreateDockable). The instance number can be removed from the form name for all single-instance forms, to distinguish them from true multi-instance forms. This will prevent the creation of new instances, when a single-instance form already has been created. Every form must know whether it's single or multi instance, and change its name accordingly when it's created. Multi-instance forms can be connected by their instance number, e.g. CodeExplorer2 will reflect the current file in SourceEditor2. The layout configuration file will have to be modified, to contain the form instance names instead of unique form IDs, with multiple instance entries. The anchor docking and its manager is no more required, and can be replaced by the TEasyDockSite and TDockMaster classes. Or the TDockMaster methods can be integrated into the existing layout manager. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Hans-Peter Diettrich wrote: Martin schrieb: Compiling Lazarus (SVN / Snapshot) with -dSynDualView allows you to open a 2nd window for any open source file. The 2nd Window can be edited, and all edits made in one window, are also done in the other window (they edit the same source). Very nice, have to try out immediately! :-) I get an error: uemOpenAnotherView not defined, in sourceeditor.pp? it is in ide\lazarusidestrconsts.pas Maybe you need to make clean all? (or tick the checkbox) = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking Why wait? When we fix the details now, I know what to implement for docking. Well first, it is not wait only. there are still bit's and pieces in SynEdit to be fixed. And sourceEditor/Notebook must be adapted too. So it simply is work in progress. After that, it can be looked into. See the MasterSite example for my current suggestion: Every IDE window can become an elastic dock site, with added dock panels at the left, right and/or bottom, by calling AddElasticSites(). My plan is to make the editor windows such dock sites, but also the main bar can be configured in the same way. This is optional eye candy, can be replaced by the next option: All (other) dockable forms are wrapped into floating forms with a DockManager, from which they can be docked together or into the elastic sites of another window. Empty floating host sites (after undocking their client) destroy themselves. Dockable forms are created by TDockMaster.CreateDockable, and can be configured further by the caller. Please note that the MakeSite example is not yet finished, emptied notebook do not yet disappear - this will be cured in the next update. It would be nice to have any number of editor windows, creatable on demand (your part). Persistence of the layout has to be defined. All dock sites can be enumerated, and can store their coordinates, layouts and content. The restauration of an layout is just unclear, with regards to the recreation of the docked forms. We'll have to find a solution for multi-instance forms, like editor windows, and for re-creating the docked forms by their name and instance number, instead of their ID. persistent layout, was one of the things I thought of, when I said waiting. It has to be seen how good window state/size/pos can be saved with the current means (because there can be any amount of edit windows) My current plan is to use the form name to specify the form type (class name) to create, e.g. TMessageWindow for MessageWindow or MessageWindow1 (see TDockMaster.CreateDockable). The instance number can be removed from the form name for all single-instance forms, to distinguish them from true multi-instance forms. This will prevent the creation of new instances, when a single-instance form already has been created. Every form must know whether it's single or multi instance, and change its name accordingly when it's created. Multi-instance forms can be connected by their instance number, e.g. CodeExplorer2 will reflect the current file in SourceEditor2. The layout configuration file will have to be modified, to contain the form instance names instead of unique form IDs, with multiple instance entries. The anchor docking and its manager is no more required, and can be replaced by the TEasyDockSite and TDockMaster classes. Or the TDockMaster methods can be integrated into the existing layout manager. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Martin schrieb: I get an error: uemOpenAnotherView not defined, in sourceeditor.pp? it is in ide\lazarusidestrconsts.pas Maybe you need to make clean all? (or tick the checkbox) That didn't help, but removing the condition around the declaration made it compile on Linux. On Windows I had no such problem. Dunno why... = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking Why wait? When we fix the details now, I know what to implement for docking. Well first, it is not wait only. there are still bit's and pieces in SynEdit to be fixed. And sourceEditor/Notebook must be adapted too. So it simply is work in progress. I hoped you had fixed everything till tomorrow - but mañana will be okay as well ;-) persistent layout, was one of the things I thought of, when I said waiting. You provide the interface, I'll provide the values. It has to be seen how good window state/size/pos can be saved with the current means (because there can be any amount of edit windows) I'll try a simple INI style format for the layout, for now. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] New experimantal beta feature - View same source in multiple Windows
Note this is a beta feature. this is experimental. The little bit that is there works. But many,many, many things have not yet been implemented. = So if you decide to test/use it, don't complain about the missing bits. Compiling Lazarus (SVN / Snapshot) with -dSynDualView allows you to open a 2nd window for any open source file. The 2nd Window can be edited, and all edits made in one window, are also done in the other window (they edit the same source). The extra Window(s) are very basic yet: (do NOT report any of those as bug) - no statusbar - no contextmenu - position and size is *not* savable (see below) - many keyboard shortcuts not working - no codetools support at all (no code completion, no jumps, no nothing) - no code templates - no search / replace / incremental-search / ... - no copy word on nothing selected - many others missing - no session, the IDE does not remember if you had any extra views open The Window however does: - show and edit a correctly highlighted version of your code. - undo works cross both views (changes made in one window, can be undone from the other = this is correct, since the changes happened in both windows) - has it's own caret position - has it's own selection, which is *not* reset by changes in the other window - has it's own folds (you can fold nodes independent of the other window) = however neither caret-pos, nor folds, nor anything else is saved in your session = it will all be lost when you close the window, or change projects (text changes are saved (of course)) - drag/drop selected text between windows. works partly, the source window starts/keeps scrolling while you are over the target win Window position/size / missing statusbar / etc = All this is not likely to be fixed soon = the idea is to wait what happens to IDE docking Therefore this feature will be beta for a considerable time Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] New experimantal beta feature - View same source in multiple Windows
Martin wrote: Compiling Lazarus (SVN / Snapshot) with -dSynDualView allows you to open a 2nd window for any open source file. I compiled but I don't see the second window. How to activate it? Best regards, Paul Ishenin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
