Re: [Lazarus] Drag, Dock and Layout
Vincent Snijders schrieb: >> Can somebody meet me in #lazarus-ide, to verify that it all works? >> > > I saw you, and you left after oliebol talked to you. Sorry, I had to go offline for a while :-( Now I'll stay online till about midnight. Just seeing a message from smace, but he seemed to have gone auto-away. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
2008/12/17 Hans-Peter Diettrich : > Vincent Snijders schrieb: > >> If you have trouble setting up an IRC client, maybe you can try a webclient: >> http://www.mibbit.com/chat/?server=irc.freenode.net&channel=%23lazarus-ide,%23fpc&nick=DoDi > > Thanks, that seems to work in my Windows VM for mail&news, connected me > to both channels :-) > > Can somebody meet me in #lazarus-ide, to verify that it all works? > I saw you, and you left after oliebol talked to you. http://www.hu.freepascal.org/fpcircbot/cgifpcbot?channel=lazarus-ide&fromdate=2008-12-17&todate=2008-12-17&linecount=50&fromtime=14%3A13&totime=14%3A24&sender=&msg= Vincent aka fpcfan ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Vincent Snijders schrieb: > If you have trouble setting up an IRC client, maybe you can try a webclient: > http://www.mibbit.com/chat/?server=irc.freenode.net&channel=%23lazarus-ide,%23fpc&nick=DoDi Thanks, that seems to work in my Windows VM for mail&news, connected me to both channels :-) Can somebody meet me in #lazarus-ide, to verify that it all works? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Paul Ishenin schrieb: >>> Launch pidgin, create an irc account for the irc server >>> irc.freenode.org, then join a room #lazarus-ide. >> Now I've installed pidgin, and tried to get online last weekend. >> Unfortunately I don't know what's going on, at least my tries seem to be >> canceld after some time. Do I have to create an official user account >> (where?), and what's the suggested protocol (AIM?). > > Sorry, maybe I explained wrong. You need to connect to irc server - so > you need to create an irc account :) I did so, locally in pidgin. Is that all? > Irc server where our conference is > placed is irc.freenode.org This is the server for my account, port 5190 (default). Attempts to connect run until: (13:44:58) oscar: connected to FLAP server of type 0x0017 followed by several dbus and connection errors, ending in "disconnected" and "signed off" :-( > and lazarus room is called #lazarus-ide. This is what I tried with "enter chat". The "#" part of the room name, I assume? > Fpc team is sitting on #fpc channel on the same irc channel. Okay, I'll try that room, too. As soon as I can connect... DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Paul Ishenin schreef: > Hans-Peter Diettrich пишет: >> Paul Ishenin schrieb: >> >>> Launch pidgin, create an irc account for the irc server >>> irc.freenode.org, then join a room #lazarus-ide. >> Now I've installed pidgin, and tried to get online last weekend. >> Unfortunately I don't know what's going on, at least my tries seem to be >> canceld after some time. Do I have to create an official user account >> (where?), and what's the suggested protocol (AIM?). > > Sorry, maybe I explained wrong. You need to connect to irc server - so > you need to create an irc account :) Irc server where our conference is > placed is irc.freenode.org and lazarus room is called #lazarus-ide. Fpc > team is sitting on #fpc channel on the same irc channel. If you have trouble setting up an IRC client, maybe you can try a webclient: http://www.mibbit.com/chat/?server=irc.freenode.net&channel=%23lazarus-ide,%23fpc&nick=DoDi Vincent ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Hans-Peter Diettrich пишет: > Paul Ishenin schrieb: > >> Launch pidgin, create an irc account for the irc server >> irc.freenode.org, then join a room #lazarus-ide. > > Now I've installed pidgin, and tried to get online last weekend. > Unfortunately I don't know what's going on, at least my tries seem to be > canceld after some time. Do I have to create an official user account > (where?), and what's the suggested protocol (AIM?). Sorry, maybe I explained wrong. You need to connect to irc server - so you need to create an irc account :) Irc server where our conference is placed is irc.freenode.org and lazarus room is called #lazarus-ide. Fpc team is sitting on #fpc channel on the same irc channel. Best regards, Paul Ishenin. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Paul Ishenin schrieb: > Launch pidgin, create an irc account for the irc server > irc.freenode.org, then join a room #lazarus-ide. Now I've installed pidgin, and tried to get online last weekend. Unfortunately I don't know what's going on, at least my tries seem to be canceld after some time. Do I have to create an official user account (where?), and what's the suggested protocol (AIM?). Do we have to meet at a fixed time? How to wait for somebody else creating or entering the room? DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Hans-Peter Diettrich wrote: > In my docking experiments with Lazarus I found no way to undock a docked > form again :-( > > Also I couldn't make properly work docking of multiple forms into a > single dock site. Does there exist a working demo project for drag-dock? > I'd be interested in a program that allows to create and drag-dock forms > into the main form, and then allows to undock the forms again. If > somebody already made that work, then there's not much left to do for me :-) > [If you have Delphi at hand, try to make the Demo\Docking sample work > with Lazarus, somehow. Then you'll see yourself what remains to do :-] > I will try to create drag-dock example and place it to lazarus svn. Then I will notify you. > Thanks for this hint, normally I prefer to compose and translate my > ideas offline. But IRC would be nice when I'm stuck on a specific > problem. I only never used IRC yet, can you give me hints on how to > start? (on Linux) > Launch pidgin, create an irc account for the irc server irc.freenode.org, then join a room #lazarus-ide. Best regards, Paul Ishenin. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Drag, Dock and Layout
Paul Ishenin schrieb: Thanks for your hints on the platforms :-) > It is a problem to understand your idea at first :) Right, I'm just what is possible, and how it could be done without restriction to my only well known platform (Windows). >> 3. Dock zones >> - > ... >> 3.1 Dock sites >> IMO dock sites could be implemented in dedicated container controls, >> which react on docking events at all. These controls also can implement >> support for floating themselves, e.g. as detachable frames or toolbars. >> Delphi compatibility will not be affected, but a choice of ready-to-use >> docking components can simplify the design of new Lazarus applications. > > Mattias already tried to do this with anchor-docking? To some degree (no drag-dock...), and I do not yet like that layout model, because it looks too irregular to me. From my experience with layouts (and Oberon) I prefer strict horz/vert arrangement with a transparent management with regards to resizing etc. I also don't understand why every TWinControl should have docking capabilites, and prefer a strict separation of dedicated container controls (forms, panels...) from other controls. But okay, if somebody has other ideas, I'll not block additional implementations... >> 3.2 Dockable components >> IMO the docking of simple components is useful only at design time, when >> components are dropped from the toolbar onto a form. Docking at runtime >> can be restricted to forms and other floatable components, like toolbars >> or frames. Undocking of docked components requires that the structure of >> the docked components stays intact, i.e. forms or frames must be >> undocked in their original composition and framing. This forbids >> unpacking the components of a form, when the form is docked. When a form >> or frame instead is docked entirely, including a (small) title bar as in >> Delphi, every docked item can be restored exactly into it's previous >> appearance and behaviour, what currently simply is impossible. > > When the form is docked - it stay as form but loses titlebar and has > parent - nothing else happen with it. On different platforms this > achieved using different means. Dont understand what is currently imposible. In my docking experiments with Lazarus I found no way to undock a docked form again :-( Also I couldn't make properly work docking of multiple forms into a single dock site. Does there exist a working demo project for drag-dock? I'd be interested in a program that allows to create and drag-dock forms into the main form, and then allows to undock the forms again. If somebody already made that work, then there's not much left to do for me :-) [If you have Delphi at hand, try to make the Demo\Docking sample work with Lazarus, somehow. Then you'll see yourself what remains to do :-] >> 3.3 Determination of the docking position. >> I'll not go into details here, it's mostly a matter of implementation of >> the an docking manager. The default (tree) docking manager >> implementation lacks many docking features which can hardly be added, or >> even be made work, without a deep redesign of all related classes and >> other data types. > > What does it miss? Have you seen TLazDockTree class? Yes, and it looks like overkill to me and, if you look into the source code, it is not really used at all :-( I'd use a list of docking planes (or levels), where the planes have alternating horizontal (alLeft/alRight) and vertical (alTop/alBottom) arrangement. Or the site contains only one docked client without an arrangement (alClient), or it is/contains a tabbed control or other layout (alCustom), like anchored docking. Every plane is represented by an according container control (e.g. TPanel), which already implements what currently should go into the DockTree. I also feel a need for centralized handling of drag operations. A static singleton would perfectly fit all requirements, since only one drag operation (mouse capture...) can be active at any time. All mouse messages could be routed through that singleton, when it signals a drag operation in progress. Such an implementation should make Lazarus and the applications much more stable... >> Therefore I'd suggest a separation of any but the abstract TDockManager >> from the Controls unit, eliminating the need for a rebuild of the IDE >> after every change to the Controls unit. It also will show up the >> undocumented dependencies between controls, messages, and the code that >> implements the details of dragging and docking. I'm willing to perform >> that separation myself, if no official developer is willing to do so - >> but I'm not willing to spend much time when afterwards the new structure >> doesn't become part of the trunk. > > Dont see why it will not be commited if you improve current code and > break nothing? Lazarus and LCL is always open for improvements. (Not) breaking existing code is one of my problems,
Re: [Lazarus] Drag, Dock and Layout
Hans-Peter Diettrich wrote: > In my attempt to understand the drag/dock implementation of Lazarus, I > came across some general questions. Is there a developer who is familiar > with the current implementation of these things? Current implementation has been done by Marius, Mattias and me. > 1. Model > ... > position, to adjust the drag image appropriately. Depending on DragKind, > the target should have UseDockManager=True or react on DockOver for > dkDock, or it should react on DragOver for dkDrag. The search for a It is not UseDockManager = True but DockSite = True . > 2. Platform support > --- > > 2.1 Determination of the component at the mouse position. > This feature should be available on every platform, since the system > itself must know which target window has to be notified of mouse events. > Using this feature should allow to easily fill the white spots in the > current determination of the dock site. Yes, this is available on all platforms. LCL gives apropriate functions to determine Control/WinControl at mouse position: - FindControlAtPosition - FindLCLWindow - FindLCLControl ... > 2.2 Mouse capture > Every platform should support kind of mouse capture, i.e. sending > messages to a dedicated capture window, instead of informing the window > under the mouse position. Information about active capturing and > dragging should be stored in a dedicated place (Application object?), so > that it can canceld easily and properly, whenever required. I dunno > about the synchronization between the IDE and a debugger and debugged > application, but I assume that there exists according communication, > which should allow to properly cancel unrecoverable actions. This is available on win32, wince, gtk1, gtk2 and qt. Dont know about carbon but suspect that too. > 2.3 Visual feedback > Every platform should at least support mouse pointer shapes, for visual > feedback about the actual target of a drag action. This primitive kind > of feedback also requires no special management of temporary images on > the screen, or in design state. More elaborated feedback can be added > for platforms with better support for dragging operations (drag images > etc.). Question is: how to deal with platform specific features in the LCL? Yes, every platform (except wince iirc) support different mouse pointers. This is already implemented. Also if you look at lcl\interfaces code you will find that DragImageList is implemented on most platforms (though not working perfectly on evert platform) and DrawDefaultDockImage is done on most platforms too. LCL uses DrawDefaultDockImage to draw dock frame. > Another kind of standard support could use the hint-window mechanism, > and drag around such a temporary window. Then the target of a dock > operation only had to supply the dock zone (RECT), so that the dragged > window can be properly resized and repositioned. This solution is really > useful only with transparent windows, which do not hide the possible > dock targets, both from the sight of the user, nor from the sight of the > system in the determination of the drag target. Perhaps not a good idea? It is a problem to understand your idea at first :) > 3. Dock zones > - ... > 3.1 Dock sites > IMO dock sites could be implemented in dedicated container controls, > which react on docking events at all. These controls also can implement > support for floating themselves, e.g. as detachable frames or toolbars. > Delphi compatibility will not be affected, but a choice of ready-to-use > docking components can simplify the design of new Lazarus applications. Mattias already tried to do this with anchor-docking? > 3.2 Dockable components > IMO the docking of simple components is useful only at design time, when > components are dropped from the toolbar onto a form. Docking at runtime > can be restricted to forms and other floatable components, like toolbars > or frames. Undocking of docked components requires that the structure of > the docked components stays intact, i.e. forms or frames must be > undocked in their original composition and framing. This forbids > unpacking the components of a form, when the form is docked. When a form > or frame instead is docked entirely, including a (small) title bar as in > Delphi, every docked item can be restored exactly into it's previous > appearance and behaviour, what currently simply is impossible. When the form is docked - it stay as form but loses titlebar and has parent - nothing else happen with it. On different platforms this achieved using different means. Dont understand what is currently imposible. > 3.3 Determination of the docking position. > I'll not go into details here, it's mostly a matter of implementation of > the an docking manager. The default (tree) docking manager > implementation lacks many docking features which can hardly be added, or > even be made work, without a deep re
[Lazarus] Drag, Dock and Layout
In my attempt to understand the drag/dock implementation of Lazarus, I came across some general questions. Is there a developer who is familiar with the current implementation of these things? 1. Model IMO a separation into drag/dock execution and dock site layout manager is suggested. The drag/dock part only has to deal with the implementation of the graphical user feedback, based on the dock source properties DragMode and DragKind. It interacts with a drag/dock target at the current mouse position, to adjust the drag image appropriately. Depending on DragKind, the target should have UseDockManager=True or react on DockOver for dkDock, or it should react on DragOver for dkDrag. The search for a possible target continues into the parents of the control, until an accepting target is found, or the parent is Nil. This part of drag/dock execution IMO should be feasable for every platform, somehow. For testing purposes or on poorly equipped platforms it would be sufficient to change the drag image (or mouse pointer) according to the response of the target control. The layout manager(s) are responsible for inserting and removing components, and can be shared with the layout managers of the form designers, and the handling of client/container size changes at runtime. Java-style and other layout managers could be added freely. The anchordocking sample demonstrates an layout manager with no docking capabilities (yet). Dock-aware layout managers provide additional means to determine the parameters for visual feedback and a later DockDrop action. They also are responsible for starting an undock action at runtime, or for a rearrangement of components at design time. 2. Platform support --- I don't know what features are provided by the currently supported platforms, and nobody can know the features of future platforms. That's why I would restrict the expected support for drag/drop operations to very few features: 2.1 Determination of the component at the mouse position. This feature should be available on every platform, since the system itself must know which target window has to be notified of mouse events. Using this feature should allow to easily fill the white spots in the current determination of the dock site. 2.2 Mouse capture Every platform should support kind of mouse capture, i.e. sending messages to a dedicated capture window, instead of informing the window under the mouse position. Information about active capturing and dragging should be stored in a dedicated place (Application object?), so that it can canceld easily and properly, whenever required. I dunno about the synchronization between the IDE and a debugger and debugged application, but I assume that there exists according communication, which should allow to properly cancel unrecoverable actions. 2.3 Visual feedback Every platform should at least support mouse pointer shapes, for visual feedback about the actual target of a drag action. This primitive kind of feedback also requires no special management of temporary images on the screen, or in design state. More elaborated feedback can be added for platforms with better support for dragging operations (drag images etc.). Question is: how to deal with platform specific features in the LCL? Another kind of standard support could use the hint-window mechanism, and drag around such a temporary window. Then the target of a dock operation only had to supply the dock zone (RECT), so that the dragged window can be properly resized and repositioned. This solution is really useful only with transparent windows, which do not hide the possible dock targets, both from the sight of the user, nor from the sight of the system in the determination of the drag target. Perhaps not a good idea? 3. Dock zones - IMO the current integration of drag/dock support bloats the TWinControl class too much. Much could be moved into the DockManager, except for the event handlers, UseDockManager and the DockManager itself. Even the information about the undocked size of docked components could be stored in the dock manager. While the data bloat may be acceptable, the code bloat hinders a proper (re-)design of the buggy or still missing parts of the drag/dock code. 3.1 Dock sites IMO dock sites could be implemented in dedicated container controls, which react on docking events at all. These controls also can implement support for floating themselves, e.g. as detachable frames or toolbars. Delphi compatibility will not be affected, but a choice of ready-to-use docking components can simplify the design of new Lazarus applications. 3.2 Dockable components IMO the docking of simple components is useful only at design time, when components are dropped from the toolbar onto a form. Docking at runtime can be restricted to forms and other floatable components, like toolbars or frames. Undocking of docked components requires that the
