Why does the MDI implementation not use the DockManager interface?

A DockManager has all functionality, required to implement MDI hosts and clients, so that only the properties (and menu) must be implemented.

DoDi

Hans-Peter Diettrich wrote

Why does the MDI implementation not use the DockManager interface? A DockManager has all functionality, required to implement MDI hosts and clients, so that only the properties (and menu) must be implemented.

Maybe because lazarus goal is to implement things as much native as possible?

And since qt and win32 have native MDI lazarus must use them.

Best regards,
Paul Ishenin.

Hans-Peter Diettrich wrote

Why does the MDI implementation not use the DockManager interface?

Because it uses native MDI where it's supported ?

A DockManager has all functionality, required to implement MDI hosts and clients, so that only the properties (and menu) must be implemented.

I don't know yet how to implement MDI via dockmanager for other targets than qt and win32 ... I've maded an mdiemulator which works but still has problems with positions inside mdi area.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111116/704f24ba/attachment.html>

This reminds me on "native" CommCtrls, which don't exist on non-Win32 widgetsets. When all these controls come in a *portable* and a *Win32* flavor, the implementation would be simplified a lot.

The implementation is independent from any widgetset.

... I've maded an mdiemulator which works but still

has problems with positions inside mdi area.

This should be feasable - can you provide your source code?

DoDi

qt mdi implementation works on all targets (win32,mac, linux, wince,android ...whatever).

zeljko

Yes, but must find it first :)

zeljko

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

Hans-Peter Diettrich wrote

This reminds me on "native" CommCtrls, which don't exist on non-Win32 widgetsets. When all these controls come in a *portable* and a *Win32* flavor, the implementation would be simplified a lot.

I am writing the custom drawn equivalents of CommCtrls and I don't remember meeting Windowsims. There do are lots and lots of features in each control, but that other widgetsets don't support them in itself is not a windowism. The vast majority of features in CommCtrls are very generic. The problem of widgetsets having different capabilities is very natural, you can't expect sets of controls written by unrelated people to be 100% equivalent in all features. They are not, and never will be. The people which write those controls don't claim that they are compatible with anything else, so why should we expect them to be? The more exotic the widgetset the worse.

Of course all of this generates reliability issues and a burdain on people maintaining/porting the LCL, but that is not an unsolvable problem. It is your choice to use a native widgetset and native widgets, if you don't like them you should be using the custom drawn widgets and work in the customdrawn widgetset:

http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls#Controls_which_imitate_the_Common_Controls_Palette

zeljko wrote

qt mdi implementation works on all targets (win32,mac, linux, wince,android ...whatever).

Yes, because they don't use OS supplied MDI, they implemented their own cross-platform version. So why LCL doesn't want to do the same, beats me. But if you guys like struggling, that's your prerogative.

What are you talking about ?

1.MDI interface have same properties/routines as Delphi 2.Only 2 widgetsets have their MDI implementaton (win32, qt) 3.For other's I've written mdiemulator (which basically works), but have problem with left/top positions, so handle part should be rethinked, so widgetset (gtk2, carbon etc) should create form + title and take care of client rect (without title bar of mdi).
4.One day (but that's *one day in future*) we'll have lazarus custom drawn widgetset (yes, something like fpgui , but more friendly to lcl), and then we can talk about implement everything in lcl.
5.MDI support just started, so don't expect that it'll be finished next week (it could be if someone provide patches).

zeljko

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

zeljko wrote

What are you talking about ?

An earlier post (from somebody else) said that LCL MDI support is only implemented in Win32 and Qt. All other platforms are not supported because their native widgetsets don't have something like MDI built in. LCL only wants to use "native MDI". Thus LCL is a bit screwed because now you have a cross platform LCL, but not all features of LCL work on all platforms. Now the application developer is f**ked because he needs to keep checking which features work on which platforms. Oops! Totally defeating the point of a "cross platform development framework" don't you think.

And now it's really funny. I got such a lot of sh*t from many lazarus developers about my custom drawn toolkit and how wrong that it compared to Lazarus "native" toolkit. Yet now somebody is working on implementing a custom drawn widgetset backend in the LCL. How ironic!

LCL is not screwed. As I said *mdiemulator is there for other widgetsets* Look screenshoots of gtk/gtk2 mdi here:
http://wiki.lazarus.freepascal.org/Image:Mdiemulator_gtk.png http://wiki.lazarus.freepascal.org/Image:Mdiemulator_gtk2.png

win32 ?
http://wiki.lazarus.freepascal.org/Image:Mdiemulator_win32.png

So, again: What are you talking about ?

And now it's really funny. I got such a lot of sh*t from many lazarus developers about my custom drawn toolkit and how wrong that it compared to Lazarus "native" toolkit. Yet now somebody is working on implementing a custom drawn widgetset backend in the LCL. How ironic!

No, it's not ironic since fpgui works only on linux and win.Custom drawn widgetset idea comes because of problems with android and wince, and I'm pretty sure that it'll be finished in next months and support at least x3 more targets than fpgui which will be same as it was 2-3 years ago.

zeljko

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

Graeme Geldenhuys wrote

And now it's really funny. I got such a lot of sh*t from many lazarus developers about my custom drawn toolkit and how wrong that it compared to Lazarus "native" toolkit. Yet now somebody is working on implementing a custom drawn widgetset backend in the LCL. How ironic!

Well, I personally think that the LCL umbrella is big enough to fit all tastes. There is no need to fight, people that prefer one or another way are free to develop the widgetsets which they prefer. And then each person can decide what to use:

1> Only native widgets
or
2> Only custom drawn widgets (futurely)

And we have a unique feature, which I've never heard of a framework having:

3> The hability to mix native and non-native widgets, which is very powerful for my projects, for example see this:

http://wiki.lazarus.freepascal.org/fpbrowser#Screenshots

fpBrowser in Mac OS X has access to the native menus, but the native TPageControl is undesirable in a browser. fpBrowser requires a TPageControl with a reliable look and feel across platforms, so it must be custom drawn. It also requires 2 features: Close Buttons and also the Add Button for adding new tabs. The Add button is not just an extra tab, since it's look can be anything depending on the Theme and it also doesn't receive the close button. The native TPageControl in Carbon/Cocoa cannot provide the required features.

So here I optimized fpBrowser by using a mix of Lazarus controls: a native TMenu, but a non-native TPageControl.

Since quite a long time we already have the hability to mix native and non-native Canvas support, TCanvas is the native one, TLazIntfImage+TFPImageCanvas is the non-native one. I just expanded this concept more broadly.

zeljko wrote

LCL is not screwed. As I said *mdiemulator is there for other widgetsets*

Is this emulator part of LCL? Also what is this MultiDoc I see in the lazarus wiki?

I haven't created a MDI application in over a decade, so had to google it first. :-) I followed the following Delphi MDI tutorial to the letter - using latest Lazarus Trunk. I first tried that tutorial under Delphi 7 and it worked flawlessly. Then I tried Lazarus trunk.

http://delphi.about.com/od/objectpascalide/l/aa042500a.htm

I'm running under Linux, using the LCL-GTK2 widgetset. Needless to say, MDI under Linux did NOT work! All child forms are created outside the bounds of the MDI parent. Closing "mdi child" forms only work on the 3rd attempt clicking the top right X button.

http://wiki.lazarus.freepascal.org/Image:Mdiemulator_gtk.png http://wiki.lazarus.freepascal.org/Image:Mdiemulator_gtk2.png

Pretty pictures, but why doesn't it work in Lazarus trunk?

No, it's not ironic since fpgui works only on linux and win.

Correction, fpGUI works on: Linux, Windows, WinCE, Mac OS X (as an x11 style application), FreeBSD and family, OpenSolaris and Embedded arm-linux devices.

targets than fpgui which will be same as it was 2-3 years ago.

What are you talking about?

On 17/11/2011, Felipe Monteiro de Carvalho

<felipemonteiro.carvalho at g....> wrote

all tastes. There is no need to fight, people that prefer one or another way are free to develop the widgetsets which they prefer. And then each person can decide what to use:

And this I have been saying for years. The point is you simply can't create a cross-platform GUI development framework using native controls. There are just too many differences between each native toolkit, thus your cross-platform GUI framework can only at best use the common features. Seriously crippling your framework. This is why Qt (and Java Swing) implements its own widgets, but simply uses the native widget theme engine to paint on a Qt canvas. fpGUI could easily do the same in one of its themes (eg: the XP/Vista/Win7 theme - which is planned already).

And we have a unique feature, which I've never heard of a framework having: 3> The hability to mix native and non-native widgets, which is very powerful for my projects, for example see this:

Hardly unique. Delphi developers use many non-native widgets (Virtual Treeview, Raize components, DevX components etc.) in there VCL (native) applications.

Anyway, we were talking about MDI....

Graeme Geldenhuys wrote

On 17/11/2011, zeljko <zeljko at ...> wrote: > LCL is not screwed. As I said *mdiemulator is there for other widgetsets* Is this emulator part of LCL? Also what is this MultiDoc I see in the

Not yet.

lazarus wiki?

Multidoc is trying to mimic mdi, I've tried it once and I didn't like it.

MDI started few days ago, only qt fully supports MDI on all targets where it works under lazarus (mac, linux, win).
Gtk/Gtk2/Carbon isn't finished yet (depends on mdiemulator). Win32 will have native implementation (same as qt).

Because, mdiemulator isn't ready yet. I don't want to commit partial/incomplete solution.

I'm talking about fpgui :)

zeljko

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

zeljko wrote

MDI started few days ago, only qt fully supports MDI on all targets where it works under lazarus (mac, linux, win).

OK, then the ever outdated LCL Roadmap wiki page needs to be updated. It mentions than MDI would be in Lazarus 0.9.30. That version has come and gone.

http://wiki.freepascal.org/Roadmap

> What are you talking about? I'm talking about fpgui :)

That's what I thought. Next time, research the subject before you spread FUD. You clearly haven't looked at fpGUI in the last 2-3 years.

It does not mention that MDI would be in 0.9.30 . There's catch: "An MDI LCL emulator for widgetsets which does not support MDI, also native implementation of MDI for qt and win32/64.Trivial version of MDI *probably* will be included with 0.9.30. ".

but, yes, roadmap should be updated.

I did not, you're right. Mea culpa.

zeljko

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