Hi,

Playing around with debugging from inside the IDE (anybody that knows me will know this is very unusual <smile>) I immediately noticed something regarding the UI of the IDE.

Using all the various debugging windows available very quickly clutters up the desktop. I just can't find a easy way of showing all windows and still seeing my source code. I'm using a 1440x900 resolution LCD monitor.

I guess this is where docking windows within the IDE will be very useful. Alternatively and maybe even better, is to rather use a tabbed window approach. Instead of having multiple "loose" windows, have one Debug window with various tabs.

See attached (animated) screenshot showing a mock-up of that idea.

So what's your thoughts on this? Yes/No... Good/Bad...

Regards,
- Graeme -

El 25/02/2010 10:12, Graeme Geldenhuys escribi?:

Looks perfect for me :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100225/692fb9ce/attachment.html>

Asm listings are usually very long. It's pain to use them in such narrow window.

thanks,
dmitry

Zitat von Graeme Geldenhuys :

Yes, that is the goal of DoDis Docking.

So what's your thoughts on this? Yes/No... Good/Bad...

Good, when done properly. Bad if implemented with fixed layout (without proper docking manager).

Mattias

dmitry boyarintsev wrote

Asm listings are usually very long. It's pain to use them in such narrow window.

The window itself will be resizeable - so that should be a screenshot I posted was just a random size window I worked with to create the mock-up.

Regards,
- Graeme -

Mattias G?rtner wrote

Zitat von Graeme Geldenhuys :

[..]

> So what's your thoughts on this? Yes/No... Good/Bad... Good, when done properly. Bad if implemented with fixed layout (without proper docking manager).

+1 (since I want locals and watches separated from the others)

Marc

Juha Manninen wrote

BTW, nice mockup. You actually created a program with page control using Lazarus, right?

This looks like fpgui to me.

Henry

At the moment the only choice I know of is to use fixed layout because docking doesn't exist in the IDE yet. One window with various TFrames embedded in a PageControl. So I guess then the idea is bad for you and a patch will not be accepted?

What is the progress on docking support inside the IDE? Sorry, I haven't followed all message threads in the mailing list.

If docking support is not even near completion, I would still suggest the tabbed window idea, until such time when the IDE has docking support. Then we can simply move each TFrame back onto a separate dockable window.

BTW:
Will the IDE support docking in the centre of another window, creating Tabs at runtime? Delphi 7 used to have that. You can doc certain windows on each of the four sides, or in the centre. The latter created ,
- Graeme -

Hi,

Yes, Good!

I guess tabbed windows is one option when docking windows. At least it should be. It allows to still keep the windows separate when needed.

BTW, nice mockup. You actually created a program with page control using Lazarus, right?

Regards,
Juha

But I don't know the state of docking support in the IDE. If docking support is still months or years away, then I would still suggest merging all debug windows into a single tabbed window.

The current debug windows could be changed to live inside a TFrame, and placed inside a PageControl. Then when docking support actually arrives, we can simply move each TFrame back into a dockable window so users can decide their desired layout.

But currently the multiple loose windows is a nightmare. Debug windows keep being hidden under other windows.

BTW, nice mockup. You actually created a program with page control using Lazarus, right?

Oops no. It's my fpGUI version of Lazarus IDE. ;-)

Regards,
- Graeme -

Henry Vermaak wrote

This looks like fpgui to me.

The window icon should have given it away. :-)

Regards,
- Graeme -

Hi,

But I don't know the state of docking support in the IDE. If docking support is still months or years away, then I would still suggest merging all debug windows into a single tabbed window.

Yes, it would be good as a temporary solution, and as an alternative to separate windows. I would need it, too.

> BTW, nice mockup. You actually created a program with page control using > Lazarus, right? Oops no. It's my fpGUI version of Lazarus IDE. ;-)

Ah yes, now I noticed the window icon.

Juha

Marc Weustink wrote

+1 (since I want locals and watches separated from the others)

Is it possible to get debugger's TForms from IDE in anyway?

thanks,
dmitry

???

Marc

I guess this is where docking windows within the IDE will be very useful. Alternatively and maybe even better, is to rather use a tabbed window approach. Instead of having multiple "loose" windows, have one Debug window with various tabs.

Notebook-docking is included in the EasyDock manager. I use it with Delphi, to overlay the designtime and runtime windows in different tabs.

See attached (animated) screenshot showing a mock-up of that idea. So what's your thoughts on this? Yes/No... Good/Bad...

It's all a matter of the IDE window management. Currently only a few windows can be made dockable at all, the other ones refuse any attempt to make them dockable. Mattias?

DoDi

Marc Weustink wrote

> Is it possible to get debugger's TForms from IDE in anyway? ???

If debugger forms would be available as classes for IDE extensions (via IDEIntf, for example), i could add them to the Manual Docker, as well :)

thanks,
dmitry

Zitat von Hans-Peter Diettrich :

[...] It's all a matter of the IDE window management. Currently only a few windows can be made dockable at all, the other ones refuse any attempt to make them dockable. Mattias?

All non modal windows should be dockable.

Mattias

2010/2/25 Mattias G?rtner :

BTW, is there any intentation to make the form editor be a page like is later Delphis? I not exactly a fan of it, but I must admit it fits better in some situations...

Best regards,
Fl?vio

This is very good. Perfect!

Notice how hard it is to work with many windows scattered:

http://imagebin.org/86466

Graeme, if you have any updates please send a copy to me in PVT.

Should be, but they are not. Even if I try on Win32, where entire forms are dockable, only a few forms really can be docked.

I just noticed that I missed to supply my mini patch for IDE docking. The big IDE fix doesn't work any more, for unknown reasons. When I've managed to supply the mini patch, you can see yourself what's wrong or missing.

DoDi

BTW, is there any intentation to make the form editor be a page like is later Delphis? I not exactly a fan of it, but I must admit it fits better in some situations...

I badly miss a "hide designer windows on Run" option.

DoDi

Well, AFAICS most of them lack DragKind=dkDock and DragMode=dmAutomatic?

Best regards,
Fl?vio

Well, AFAICS most of them lack DragKind=dkDock and DragMode=dmAutomatic?

Setting these properties in code seems not to help. But I'm not sure where to place that code, so that it would configure *all* IDE forms.

DoDi

I was/am trying to work on IDE docking (as you might know ;-) I'm sure we should add code to make all IDE forms dockable automatically. If that's the case we could add some property or event to TApplication.
My main development platform is Linux/gtk2, so I can't really say about Windows. I am playing with the idea of using WMMove events with some conditionals to trigger the drag/dock start, but for starters the "reason" parameter isn't "interface" in all situations I expected...

-Fl?vio

+1

John Sunderland

I was/am trying to work on IDE docking (as you might know ;-) I'm sure we should add code to make all IDE forms dockable automatically. If that's the case we could add some property or event to TApplication.

My options for dockable forms:
1a) use a handle in the client area (affects form layout) 1b) use a handle in the title bar (added button)
1c) add popup menu entry (as AnchorDocking does)
1d) move window + some key (CTRL?)

Perhaps you can make work 1b or 1d?

My main development platform is Linux/gtk2, so I can't really say about Windows. I am playing with the idea of using WMMove events with some conditionals to trigger the drag/dock start, but for starters the "reason" parameter isn't "interface" in all situations I expected...

See option 1d - added for you.

For dragging purposes the IDE forms can be put (docked) into special container forms, that allow to (un)dock their client forms, and also allow to dock multiple forms into the container.

See the dockmanager/elasticsite demo and package/uMakeSite.pas for further features.

Mattias has to provide some means to
2a) create the IDE forms by name or class-name, for reloading a layout, 2b) storage and loading of a layout itself, and for 2c) configuring the forms as docksites (SynEdit, perhaps MainBar) or 2d) as dockable clients (all other non-modal forms).
3) a base class for the IDE layout manager, independent from anchor docking (the anchor docking implementation still does not work).

WRT 2c/d: A classic ("undocked") Delphi layout requires that the editor forms become docksites. Furthermore multiple full-fledged editor forms should be made work, with dedicated code explorers. The new (SDI) layout requires that the MainBar becomes a docksite and the editor form becomes a dockable client, just like all the other forms.

DoDi

Silvio Clecio wrote

Notice how hard it is to work with many windows scattered: http://imagebin.org/86466

My taskbar looks the same - totally useless. :-( I'm normally a big fan of SDI layouts, but when it comes to Lazarus IDE, there are just to many forms. Maybe I need one of those 2x2 rack mount LCD monitor setups - so I can use 4 desktops to layout my IDE windows. ;-)

Other simple things that could help is automatically hide windows when not needed. eg: When you compile your project, show the Messages window. If no compiler errors, auto hide the window. If errors occur, keep showing the window. If you wanted to see what hints or warnings occurred during compiling and after a successful compile, simply go "View -> Messages".

Graeme, if you have any updates please send a copy to me in PVT. From the other replies by Mattias, Flavio and Hans-Peter, it seems docking

support in Lazarus IDE is still far into the future. So yes, I'll continue and make the modification for now. If anybody wants to use the patch, I'll post it in Mantis.

Regards,
- Graeme -

Hans-Peter Diettrich wrote

I badly miss a "hide designer windows on Run" option.

Isn't that the same as....

"Environment > Options > Environment > Windows > 'Hide IDE windows on run'" checkbox..???

Regards,
- Graeme -

Silvio Clecio wrote

Notice how hard it is to work with many windows scattered: http://imagebin.org/86466

By the way, do you know about the following option?

"Environment > Options > Environment > Windows > 'IDE title starts with project name'"

So if you have slightly less windows open, it will be easier to spot the Main form in the taskbar.

Regards,
- Graeme -

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100226/9705c555/attachment.html>

When docking has been made work, you can put the "views" into tabs on a notebook. I don't like too many automatisms, except for hiding the designer windows on Run.

>From the other replies by Mattias, Flavio and Hans-Peter, it seems docking support in Lazarus IDE is still far into the future.

Not so far, I hope. Some windows can be docked already.

DoDi

No. Form designer windows should be hidden on Run, because on a breakpoint the IDE (editor) becomes active again, and then the designer windows hide the runtime forms.

Optionally we can have different layouts, for "normal" and "debug" operation.

DoDi

Hans-Peter Diettrich wrote

Not so far, I hope. Some windows can be docked already.

What do I need to install to try this out. And where do I get the patches for this?

[sorry, I haven't been following Docking conversations]

Regards,
- Graeme -

Graeme Geldenhuys wrote

My taskbar looks the same - totally useless. :-( I'm normally a big fan of SDI layouts, but when it comes to Lazarus IDE, there are just to many forms. Maybe I need one of those 2x2 rack mount LCD monitor setups - so I can use 4 desktops to layout my IDE windows. ;-)

I did it, but not much has changed.

That would be interesting. There is this option in Lazarus-0.9.29 (FPC-2.2.4-3)?

>From the other replies by Mattias, Flavio and Hans-Peter, it seems docking support in Lazarus IDE is still far into the future. So yes, I'll continue and make the modification for now. If anybody wants to use the patch, I'll post it in Mantis.

Please, what is the link for me to follow the changes?

Regards, - Graeme -

[]'s

Silvio Cl?cio

Yes :) Now I did it, but what I wanted was a unique button, and the other options would be in a tab (perhaps not needed of tabs).

Here's how I wanted to do:

http://imagebin.org/86641

Is it only I like unique button(of the lazarus) in the task bar? D:

Thanks Graeme ;)

Regards, - Graeme -

Silvio Clecio wrote

http://imagebin.org/86641 Is it only I like unique button(of the lazarus) in the task bar? D:

I would like that too. In Windows (and I think I saw it in some Linux apps) it is possible to have SDI windows layout and a single button in the taskbar. This make a lot more sense than having 10-15 buttons in the taskbar for a single application.

With MSEide, if you dock windows together, it reduces the taskbar buttons - I sure hope Lazarus IDE does the same when docking is implemented.

LCL is already capable of this. I've just sent a patch in mantis which makes this a little better:
http://bugs.freepascal.org/file_download.php?file_id=10889&type=bug Issue: http://bugs.freepascal.org/view.php?id=15055 However, there are some issues to deal with yet, like activating the application (bring the other windows to front) and moving between desktops. Actually it's much easier than I thought, I must have done something wrong ;-)

All this docking talk is nice and everything, but sometimes I ask if shouldn't just go SDI for Lazarus IDE. I found it odd at the beginning, but after using several other SDI IDEs now I can't find reasoning in Delphi-old MDI...

BTW, back to the "drag windows in gtk2" part of the discussion, I've just realized gtk has explicit calls for it, it most certainly have some events/notifications/callbacks too?

Best regards,
Fl?vio

2010/2/27 Fl?vio Etrusco :

All this docking talk is nice and everything, but sometimes I ask if shouldn't just go SDI for Lazarus IDE. I found it odd at the beginning, but after using several other SDI IDEs now I can't find reasoning in Delphi-old MDI...

I think you meant other way round. :-) Old Delphi 7 and earlier used SDI interface by default. MDI (multi-document interface) is one big outer window with multiple other windows embedded inside that parent window. Most IDE's seem to go the MDI route. My problem with MDI is the form designer. In such IDE's you can only see the code, or only the Form Designer - not both. :-( For this single reason I prefer SDI layout, but then the IDE must support some form of docking to minimize the amount of windows the developer needs to manage - and reduce the taskbar item count.

Thanks again Graeme, but I want to do in my Lazarus. Let's see if this it's possible ... :/

Thanks Fl?vio, worked perfectly \o/... See:

http://imagebin.org/86665

The windows are minimizing with MainWindow, except Form1 and OI, it's possible other windows minimize too (OI, Form1, LeakView...)?

See:

http://imagebin.org/86668

Please don't notice my bad english :P

> Not so far, I hope. Some windows can be docked already. What do I need to install to try this out. And where do I get the patches for this?

See feature request 15242.

I couldn't supply new patches yet, my system still suffers from several problems :-(

DoDi

I would like that too. In Windows (and I think I saw it in some Linux apps) it is possible to have SDI windows layout and a single button in the taskbar. This make a lot more sense than having 10-15 buttons in the taskbar for a single application.

See issue 13919, 15055 (with patches). On Linux an application seems not to receive a message when the main form is minimized.

DoDi

No, that's neither MDI nor SDI.

MDI (multi-document interface) is one big outer window with multiple other windows embedded inside that parent window. Most IDE's seem to go the MDI route.

That's called SDI, not MDI. A single window contains frames, filling the entire window. It's like everything docked into a single application window, and some IDEs actually allows to undock some frames.

DoDi

Does your desktop not offer a "Group similar tasks" option? On KDE one can set it to "Always" which groups windows of the same application into one taskbar button. Another possibility is to use virtual desktops.

Martin

Graeme Geldenhuys wrote

With MSEide, if you dock windows together, it reduces the taskbar buttons - I sure hope Lazarus IDE does the same when docking is implemented.

An screenshot of such a MSEide dock panel is here: http://developer.berlios.de/dbimage.php?id=4661

Martin

Notice that DoDi is probably talking about uminirestore.pas. I've put some patches there yesterday; it was not my intention to steal the mantis issue but... seems like I did it :-$

Best regards,
Fl?vio

DoDi-

You have that exactly backwards. One big window with child windows all contained inside it is MDI. An program with several seemingly independent windows that act in a coordinated way while appearing separate from each other is SDI.

On Sat, 27 Feb 2010 06:18:09 +0100, Hans-Peter Diettrich wrote about Re: [Lazarus] debug windows layout:

Actually, Graeme is correct.

Each of the discrete windows contains a single "document", so it is called a Single Document Interface.

Again, Graeme is correct.

The outer container window contains multiple documents, each managed by an inner window -- hence Multiple Document Interface. Each inner window is called an "MDI child", and the container window is the "MDI parent". The MDI children can be maximized (within the MDI parent) and minimized independently; they can also be either tiled or cascaded. Your term "docked" seems to be a reference to tiled MDI children.

If you have a copy of Visual BASIC 6 handy, you can switch that IDE between MDI and SDI to see this effect. [Earlier versions of VB were SDI only for the IDE, but could easily produce MDI or SDI apps.]

Back in the late 1980s, when IBM and Microsoft were both involved with OS/2 development, both companies came to the conclusion that MDI sucked. This was because one cannot get through to one's desktop without minimizing, or at least shrinking, the MDI parent, thus losing display of all documents simultaneously. More than 20 years on, this problem remains with MDI, but software companies still produce MDI applications. Plus ?a change, plus c'est la m?me chose. ... :-(

The problem you mention exists with SDI in a worse form. Now I must click away N windows before I get to the desktop. Which is why most task-panels have a button 'Show the desktop'...

So I think this is largely a matter of preference. I much prefer MDI over SDI.

I use a database product. One day it switched from MDI to SDI, using a tabbed window approach as in browsers: "a more modern look". The product simply became unusable. And the whole company here feels like that.

So I wrote my own.

Michael.

Perhaps we should distinguish between windows and applications. When an application opens multiple windows, every window can be SDI or MDI.

At the *window* (technology) level we can determine whether MDI client windows exist. So far Delphi or Lazarus *never* have been MDI applications.

At the *application* level IMO SDI indicates one single application window, like implemented by most IDE's (RS, VS...). An IDE can contain multiple projects (solutions...), and a project can consist of multiple source files, but only one of them is accessible at the same time.

If you have a copy of Visual BASIC 6 handy, you can switch that IDE between MDI and SDI to see this effect. [Earlier versions of VB were SDI only for the IDE, but could easily produce MDI or SDI apps.]

AFAIR that was like RadStudio now can be switched between new "standard" and "classic undocked" views, and the new (monolithic) view is called "SDI".

You seem to associate MDI with a single application window. IMO this view neglects both the "document" and "interface" aspects.

DoDi

On Sat, 27 Feb 2010 14:32:57 +0100 (CET), Michael Van Canneyt wrote about Re: [Lazarus] debug windows layout:

On Sat, 27 Feb 2010, David W Noon wrote:

[snip]

If your SDI windows are organized properly, you should only need to minimize one of them to get to the part of the desktop you want. This dates back to the time when programs were launched from desktop icons (in the manner of OS/2 and PROGMAN.EXE): provided you know where your desired icon is, you can get to it losing sight of only one document.

The world of GUI desktops has moved on. Programs are now launched from pop-up panels, etc., mostly based on the design of the Lotus SmartBar. This makes the desktop itself simply a platform for decoration.

Perhaps they should have offered a switchable option.

Hans-Peter Diettrich wrote

> I think you meant other way round. :-) Old Delphi 7 and earlier used > SDI interface by default. No, that's neither MDI nor SDI.

Nope, it's SDI. :-)

SDI and MDI have nothing to do with docking. Both can support docking, but my major difference is how the main form manages the child forms. In a MDI interface, the child forms are encapsulated into a mini "virtual desktop" environment. They can move around only in this virtual desktop, can be iconified, minimized, maximized.

SDI interfaces, the main form and the child forms are completely separated and when iconified, it is iconified to the OS desktop or taskbar, NOT to the main form.

The following ASCII art requires a mono font to view correctly.

----------------------------------------------------

MDI interface
+-------------------------------+
| Main window |
| |
| +-----------+ |
| | window 1 | |
| | +-----------+ |
| +---| window 2 | |
| | +-----------+ |
| +----| window 3 | |
| | | |
| +-----------+ |
| +4-+ |
| +--+ |
+-------------------------------+

SDI interface
+-------------------------------+
| Main window |
+-------------------------------+

+-----------+ +-----+
| window 1 | | 4 |
| +-----------+ +-----+
+---| window 2 | | |
| +-----------+ | 5 |
+----| window 3 | | |
| | +-----+
+-----------+

----------------------------------------------------

In the MDI interface above, Window 4 is iconified, but the icon is still inside the Main Form.

In the SDI interface, Window 4 and Window 5 are docked. Also all child windows are separate (outside) from the Main Window.

example of MDI applications: Adobe Photoshop, MS Access

examples of SDI applications: Lazarus IDE, Delphi 7 IDE, GIMP

Martin Schreiber wrote

> Does your desktop not offer a "Group similar tasks" option? On KDE one can set it to "Always" which groups windows of the same application into one taskbar button. Another possibility is to use virtual desktops.

Yes, Gnome's taskbar can group icons, but it simply stacks then in a submenu of a single button on the taskbar. When you click that taskbar button, it shows a "popup" window listing each window related to that task. Still useless.

Exactly. And all those separate windows now docked together, now only have one button in the taskbar. Very important.

TDI interface

+-------------------------------------------+
| Main window |
+-------------------------------------------+
| window 1 [x]| window 2 [x]| window 3[x]| |
+-------------------------------------------+
| |
| |
| window 1 |
| |
| |
+-------------------------------------------+

[x] = Close button;

The pattern with TDI is also very good ;)

example of TDI applications: Firefox, NetBeans, Aptana, Eclipse, KDESvn.

Yes, Gnome's taskbar can group icons, but it simply stacks then in a submenu of a single button on the taskbar. When you click that taskbar button, it shows a "popup" window listing each window related to that task. Still useless.

The same for KDE :-(

BTW, Delphi uses a dedicated and invisible application window, in addition to the application main window, that shows up in the Windows task bar. It may be a matter of window classes or styles, so that all user-defined forms are treated as child windows of the application window, and as such never go into the taskbar. Other application windows are minimized to the screen, not to the taskbar, like MDI child windows.

I'd assume that other window managers offer similar features. For KDE it's sufficient to *hide* all forms (but the main form), when the application is minimized. When only the main form really is *minimized*, also only this form appears in the KDE taskbar.

DoDi

If only there was a taskbar implementation that offered the feature to just group windows of the same process. I tried virtually every taskbar/dock implementation in existence and not a single one offer this.

On a - now - side note, this whole SDI vs MDI discussion is useless. If you read articles about MDI vs SDI vs TDI (TDI? what a silly name differentiation!) they are very confusing/confused regarding the criterion that characterize them.
BTW I've certainly seem some Borland dev call the old Delphi IDE a MDI.

-Fl?vio

If only there was a taskbar implementation that offered the feature to just group windows of the same process. I tried virtually every taskbar/dock implementation in existence and not a single one offer this.

As already noted, I suspect that the application windows should have the proper attributes (main/child). A *task*bar should deal with tasks, not with windows.

On a - now - side note, this whole SDI vs MDI discussion is useless.

Right. But I found it interesting to hear the opinions of others.

If you read articles about MDI vs SDI vs TDI (TDI? what a silly name differentiation!) they are very confusing/confused regarding the criterion that characterize them.

Right. While TDI IMO correctly describes the handling of *documents*, it also only applies to a specific window, not necessarily to an application itself.

BTW I've certainly seem some Borland dev call the old Delphi IDE a MDI.

This was my impression, too. The old (undocked) IDE allowed to view *multiple* documents (units) in multiple editor windows *at the same time*, while the new IDE only allows to view a *single* unit at the same time.

DoDi

:-)
Delphi 7 IDE is a mixed bag, but still SDI. It's not only about being able to view multiple units in a same window, it's how those embedded documents are managed too, and how the end-user can interact with those documents.

In true MDI style, each document (represented by embedded child window) can be minimized, maximized, tiled, stacked and moved around inside the parent form.

In Delphi 7 IDE it only allows viewing multiple units in a Source Editor window via a tab interface (this is what seems to confuse you guys), but you cannot move each "unit window" around inside the main form's "virtual desktop", you can't tile them, you can't iconify them etc.. That is why Delphi 7 IDE is a SDI design - MDI apps can do all those.

Also Delphi 7 IDE does allow each unit to be opened in a separate Source Editor window - NOT part of the Main Form (form with component palette). This is another tell tail sign of SDI style application - there is no "virtual desktop" managed by the Main form.

Regards,
- Graeme -

For my vote there would be no docking windows in the IDE This would result in there being a large amount of additional eye-candy code to maintain for no good purpose.
Whilst the docked Delphi IDE is better than the undocked layout, it is still a pain as windows get accidentally stuck to your mouse and undock or drag to unwanted places.

The main IDE window should have 3 principal Frames 1 Code
2 Form design
3 Debug
then such features like component palette and code explorer (converted to Frames) could be put onto the logical IDE Frame and not clutter screen space when they are not in context.

Is there any support for this idea?

In true MDI style, each document (represented by embedded child window) can be minimized, maximized, tiled, stacked and moved around inside the parent form.

This is what Delphi allows since long - except for the parent window restriction. The MDI menu is not a requirement to make an application MDI - it also is somewhat useless in a "virtual desktop", populated also with other (non-document) windows.

Also Delphi 7 IDE does allow each unit to be opened in a separate Source Editor window - NOT part of the Main Form (form with component palette). This is another tell tail sign of SDI style application - there is no "virtual desktop" managed by the Main form.

This clearly makes the IDE MDI - multiple document views managed by a single application, controlled by a single menu. An SDI application requires to start a new instance for every document view/window.

DoDi

Hans-Peter Diettrich wrote

This clearly makes the IDE MDI - multiple document views managed by a single application, controlled by a single menu. An SDI application requires to start a new instance for every document view/window.

MDI child windows MUST live inside the bounds of the Main Form! That is NOT the case with Delphi 7 IDE. The "document" (source editor) windows and all other windows are completely separated from the Main Form and lives outside the bounds of the main form - that is SDI. See my ASCII art images again.

Other than this, I think I give up trying to explain this. :-)

Regards,
- Graeme -

Hans-Peter Diettrich wrote

> Also Delphi 7 IDE does allow each unit to be opened in a separate Source > Editor window - NOT part of the Main Form (form with component palette). > This is another tell tail sign of SDI style application - there is no > "virtual desktop" managed by the Main form.

Attached is an example MDI applications. One top level window which encapsulates the WHOLE application. Yet has multiple "document" windows open, but they can ONLY live inside the bounds of the main window. There is also one "document" window iconified (bottom left).

All those document windows can be tiled vertically or horizontally. After doing that, they will still only be in the bounds of the main form. Delphi 7 IDE is *not* like that, hence SDI interface.

Regards,
- Graeme -

Zitat von Leslie Kaye :

For my vote there would be no docking windows in the IDE This would result in there being a large amount of additional eye-candy code to maintain for no good purpose.

That's why I and Marc proposed a dock manager instead of special IDE code. DoDi is working on such a docking manager.

Whilst the docked Delphi IDE is better than the undocked layout, it is still a pain as windows get accidentally stuck to your mouse and undock or drag to unwanted places.

The normal remedy is a 'lock' option .

That is 'special IDE' code. IMO a docking manager would be better.

Mattias

2010/3/1 Graeme Geldenhuys :

Graeme,
we understand what you mean, (but) we just don't think there's an authoritative definition.

Best regards,
Fl?vio

On Mon, 1 Mar 2010 12:20:05 -0300, Fl?vio Etrusco wrote about Re: [Lazarus] debug windows layout:

we understand what you mean, (but) we just don't think there's an authoritative definition.

The jointly produced documentation from IBM and Microsoft, about 20 years ago, provides *THE* authoritative definition. You can probably obtain copies of this in some rather old books by Charles Petzold, on programming Windows and/or OS/2 Presentation Manager.

You might also be able to find this documentation on the MSDN Web site, BICBW.

Hans-Peter Diettrich wrote

An SDI application requires to start a new instance for every document view/window.

No it does not. One runnning application instance can manage multiple, independent SDI windows, each with a different "document" context. That's still SDI.

It seems that various hybrid implementations have caused confusion over the years. Classic Delphi IDE is one such example. Borland added logic to make the SDI model work more like the MDI one for the editing window.

The early MDI implementations in Windows were quite lame and inflexible. I think that's why MS abandoned their early MDI attempts and made Word/Excel/etc into SDI.

So, enough of this.

MDI child windows MUST live inside the bounds of the Main Form!

That's a matter of taste, and I do not expect everybody to agree with my viewpoint. MDI windows and menus are specific to the Windows platform, so that other criteria must be found for other platforms.

Other than this, I think I give up trying to explain this. :-)

You explained your viewpoint very clearly, no need to refrain :-)

My viewpoint in short:
SDI: only one document per process
TDI: multiple documents per process, accessible in different tabs MDI: multiple documents per process, accessible in different windows

We only differ in the location of the documents.
Your model requires that they reside in a dedicated MDI window, my model only requires that they are part of one process/instance of an application.

WRT Lazarus, I have to start multiple instances when I want to see multiple source units at the same time. This restriction brought me to docking first, and now (finally) to the implementation of multiple edit windows. I do not bother whether somebody calls it MDI or SDI, my only desire are multiple edit windows in one process.

DoDi

The reason is the *immediate* drag start on MouseDown, what may be a suitable default for drag-drop operations (which do not affect the layout), but there is no need and no justification that drag-dock *also* should start immediately. If the user *wants* to dock a form or control, he *must* move the mouse to the new location, that typically is far more away than only 5 pixels.

This problem results from the evolution of drag-drop into drag-dock in Delphi, with both modes sharing the same DragImmediate and DragThreshold settings.

That is 'special IDE' code. IMO a docking manager would be better.

ACK. When will we have fully functional additional editor windows? [With additional code explorers ? la Delphi...]

BTW all user actions (menus, commands...) should be routed to the currently active editor window, in MDI style manner.

DoDi

Hans-Peter Diettrich escreveu:
(...)

I just needed to remove the various buttons on the taskbar, and Flavio has shown that this is possible. IMHO, It would be also interesting a version in Delphi2006/2007/2009/2010 style, with a single Form, and the options surrounding this form. (especially for those who only use Linux, like me;))....

How far are you with multiply edit windows? Because I am (or will be) at the same thing. In order for opening the same source in multiply views ( $DEFINE SynDualView ), I need to look at multiply windows.

I am/was deferred by a lot of other things, so I can't tell exactly when I will continue with it....

Martin

FWIW: as David Noon pointed out, the definitive definitions are in the books written by IBM and M$ when they developed and documented the MDI and SDI interfaces back in the early days of OS/2 (at least) ;)

that's a fine goal and i, for one, look forward to seeing and using your work in this aspect... i feel that it will be a big improvment to Laz's IDE and will enable more productivity in the same way that multiple document capabilities helped back in the days of Borland's Turbo and Borland Pascal IDEs :)

Fl?vio Etrusco wrote

Graeme, we understand what you mean, (but) we just don't think there's an authoritative definition.

On the contrary, Waldo Kitty hit the nail on the head. IBM and Microsoft defined the definition when they invented the idea of MDI for OS/2 and early Windows. So I would say the behaviour of MDI under Windows (and as I described) would be an accurate definition of what MDI is and how it should work.

Regards,
- Graeme -

The trouble with this whole messy thread is that SDI and MDI are single / multiple DOCUMENT interfaces (not single / multiple windows). When a single file is a single document displayed in a single form(eg a word processor file) then it is all pretty straight forward, much like Graeme has described. When you try to apply it to something like a development IDE, the first thing you have to define is what the document is - is it a source file (unit) or the whole project ? And all the extra windows (inspectors, watches, messages, etc) just don't fit either model. in a normal MDI, you can open multiple documents, but it usually assumes they all open exactly the same way, eg another instance of the same class of editor. (Consider the old Delphi MDI application template).

If you consider the document to be a project, then Deplhi (<= 6) and lazarus are SDIs - you only have one project open at once, (unless you have multiple Delphi/Lazs open). If you think of the units as the documents, you can only relate the models to the source editor window, and it doesn't follow either model. (Is that what TDI is ? Tabbed doc interface ?)

For the record, in Deplhi 4* where I have docking, I usually have all the source files in one tabbed set, form design windows separate, and all the other stuff - inspectors, watches, messages, etc, docked into another tabbed set. If the docking problems are to do with synedit, then even if we could dock all the Lazarus windows except the source editor and design forms into a tabbed set, that would be a great step forward. But I would not like to be be FORCED to have anything as a tabbed set (as in Graeme's original proposal), as you never know when you want to look at two things at the same time.

cheers,
John Sunderland

* Last version of Delphi that I have access to that does databases.

Nicely said.
Well, back to another discussion. what about a poll (you see I like them :-P ) to make Lazarus a single-parent-window app regardless of fixing/finishing drag'n'dock?

Best regards,
Fl?vio

If you think of the units as the documents, you can only relate the models to the source editor window, and it doesn't follow either model.

Count the editor windows, that implement the user interface (access) to the documents.

(Is that what TDI is ? Tabbed doc interface ?)

Right. I also found mentioned IDE-style interface in the wikipedia. The obvious need for terms for models that are neither pure SDI nor MDI leads to more confusion than clearness.

With dockable windows every user can create his own layout, from fully undocked until monolithic (everything docked to the IDE main bar).

In my docking model the SynEdits should be dockable as well, i.e. the editor notebook is under control of the DockManager; this way one can have any number of concurrently visible documents. The IDE sends keystrokes and commands to the currently active SynEdit, and opens new files in the currently active editor notebook; code explorers also should be created for every editor notebook, when the user decided to dock one to the editor window; otherwise single global instances could be used for all source code navigation tools. These aspects IMO make the big difference between single and multiple document INTERFACEs, from the technical viewpoint.

Optionally, as a replacement or extension of the MDI window menu, different layouts can be activated for distinct IDE states (edit, debug...), with possibly further distinction between form design (using OI and component palette), and "normal" source code editing. The component palette can be presented both in classic (horizontal) or new (vertical) arrangement, possibly depending on the width/height of its dock zone.

DoDi

Well, back to another discussion. what about a poll (you see I like them :-P ) to make Lazarus a single-parent-window app regardless of fixing/finishing drag'n'dock?

I don't like it, so I won't vote for it :-]

DoDi

How far are you with multiply edit windows?

Don't ask me, I'm not familiar with the current IDE interfaces and layout management :-(

AFAIR the ElasticSite demo demonstrates the available docking features, including persistence. What remains to do is the integration of docking and persistence into the IDE.

Because I am (or will be) at the same thing. In order for opening the same source in multiply views ( $DEFINE SynDualView ), I need to look at multiply windows.

The SynDualView is nice, it only lacks the same set of features for every view.

I am/was deferred by a lot of other things, so I can't tell exactly when I will continue with it....

I'm also busy with many other things <sigh>. In the next step I'll add top-level docking to the EasyDockSite. From the user VP this is only a minor extension, but it does not fit nicely into the existing implementation.

Perhaps we should open an branch for a dockable IDE with full support of multiple editor windows. The interfaces deserve a lot of refactoring for this model, that should not affect the proper operation of the current Lazarus IDE. Also the LDockTree manager and TabView should be replaced by the new implementation.

DoDi

I've just re-read some old docs (Petzold), and found the same principles for managing multiple documents all over. The keypoint is a single *active* document, that acts upon menu and keyboard command. Whenever a document of an different type becomes active, the application menu should be updated accordingly. That flexibility is the major difference between the old SDI and new MDI technology. The presentation itself is less important to the implementation, be it in dedicated MDI child windows, in "normal" (overlapped) windows, or in the tabs of a tabsheet.

Ah, I also remember those multiple source files in the old DOS IDE, long before Windows took over.

DoDi

It sounded for a moment you started on the IDE integration. I just wanted to make sure we don't fo the same thing.

Since you are not (yet), I'll be looking at enabling multiply SourceNotebooks. This can later be combined with docking.

I know. I hadn't had much time the last 2 or 3 month... hopefully it will get better again.

It doesn't make sense when I would work on IDE code without SVN write access. The resulting patches would be huge, so that nobody will check and commit them. That's why I suggested an SVN branch for such development.

Since you are not (yet), I'll be looking at enabling multiply SourceNotebooks. This can later be combined with docking.

You started that work and I don't want to interfere, unless you ask for assistance and specify a goal.

DoDi