Proposing new widgetset: dwindows

[MarkMLl]

To have only one Developer (or a very small team) can be dangerous. (we can see whats happen with MSE)

Particularly one who apparently still thinks that OS/2 is a thing.

I'm a little unclear what's being suggested here. On the one hand is "dwindows is a layer on top of GTK", and on the other is "dwindows is a clone of GTK". The first of those is particularly problematic since that's what the LCL is, and for every interposed layer there will be additional problems because it misses out some facility that everybody else expects.

Besides which, if it doesn't already have committed support for GTK3 etc. then that isn't going to happen magically: the LCL's having enough problems getting that to work, with multiple experienced developers.

MarkMLl

[theo]

If you provide a patch or Gitlab fork that implements it and promise to maintain it, I believe it could be added.
If you only ask other people to implement it, there is a very slim chance for it to happen.

Exactiy.
I don't see it as a GTK replacement in the first place, but it could become an LCL interface and then we'll see what works and what doesn't.

[s6nonqxt]

Edit: Ditto on my macOS Catalina. Dark mode, embeds WebKit. The demo has no app menu, just a clickable menu a la menubar app.

Don't worry. The author is a macOS user. dwindows 3.4 is still in development. Btw, I proposed dwindows as the compatibility layer for GTK. Lazarus already has native Cocoa and Qt widgetset on macOS so dwindows on macOS is not really important

[s6nonqxt]

Not on a clean Ubuntu 22.04, the configure script complains it cannot find gtk-config which was apparently a gtk(1) thing. Pierce, I guess you don't have GTK installed ?

I tried forcing something newer with --with-gtk2 and --with-gtk4 but same result.

Davo

You didn't have development files for GTK installed. For GTK2, it's libgtk2.0-dev. For GTK3, it's libgtk-3-dev. I don't know about GTK1 and GTK4 as I don't use them or any apps required them

[marcov]

Most of these over-gtk widget set only work very roughly for very sparsely populated dialogues that hardly resize (but add scrollbars if necessary).

The LCL however requires nearly pixel exact behaviour and dynamic resizing, which is why the current GTK versions are such a big problem.

They only support gnome, which have very widely spaced dialogues with lots of scrollbars.

The chances that some small project suddenly makes GTK exact, and then even over GTK versions is next to zero.

[s6nonqxt]

AFAICT, I have GTK2 and GTK3, no GTK1 nor GTK4. There is no gtk-config program on my system.

gtk-config seems to be obsolete. It functionality is now provided by pkg-config

https://docs.gtk.org/gtk3/compiling.html

[MarkMLl]

You didn't have development files for GTK installed. For GTK2, it's libgtk2.0-dev. For GTK3, it's libgtk-3-dev. I don't know about GTK1 and GTK4 as I don't use them or any apps required them

For GTK1 (nee GTK) it would be something like libgtk1.2-dev plus possibly libgdk-pixbuf-dev (on a Debian system). However it's a long time since those were shipped, and I suspect that one would have to go back to something like Debian "Lenny" to find them.

MarkMLl

[s6nonqxt]

To have only one Developer (or a very small team) can be dangerous. (we can see whats happen with MSE)

Particularly one who apparently still thinks that OS/2 is a thing.

I'm a little unclear what's being suggested here. On the one hand is "dwindows is a layer on top of GTK", and on the other is "dwindows is a clone of GTK". The first of those is particularly problematic since that's what the LCL is, and for every interposed layer there will be additional problems because it misses out some facility that everybody else expects.

Besides which, if it doesn't already have committed support for GTK3 etc. then that isn't going to happen magically: the LCL's having enough problems getting that to work, with multiple experienced developers.

MarkMLl

What's wrong with OS/2? There is still OS/2 clones available and active developed

Let me clarify it. dwindows is a clone of GTK1 but it doesn't a complete library like GTK1, it's a compatible layer that allowed the users to code in the GTK1 style with similar API to GTK1 and the same concept of packing widgets like GTK1 (https://www.rpi.edu/dept/acm/packages/gtk/1.2.10/gtk+-1.2.10/docs/html/gtk_tut-4.html). Underlying dwindows uses the native API of the platform, for example: Win32 API on Windows and GTK on Linux/Unix (which GTK version it should use is configured when you build the dwindows library). dwindows is a single header library, dw.h (you could forget about dwcompat.h and dwcompat.dll as they have no meanings for us). It's very simple and lightweight enough to perfectly serve as a compatibility layer for the LCL to communicate with the platform's GTK

dwindows has full support for GTK3, GTK4 is currently experimental and will be stable when dwindows 3.4 released

[s6nonqxt]

If you provide a patch or Gitlab fork that implements it and promise to maintain it, I believe it could be added.
If you only ask other people to implement it, there is a very slim chance for it to happen.

Exactiy.
I don't see it as a GTK replacement in the first place, but it could become an LCL interface and then we'll see what works and what doesn't.

It's a compatible layer. The API of it is very stable unlike GTK. Underlying it still uses GTK

[s6nonqxt]

You didn't have development files for GTK installed. For GTK2, it's libgtk2.0-dev. For GTK3, it's libgtk-3-dev. I don't know about GTK1 and GTK4 as I don't use them or any apps required them

For GTK1 (nee GTK) it would be something like libgtk1.2-dev plus possibly libgdk-pixbuf-dev (on a Debian system). However it's a long time since those were shipped, and I suspect that one would have to go back to something like Debian "Lenny" to find them.

MarkMLl

I don't understand. Why don't we jump directly into dwindows but have to make sure the current LCL-GTK1 work first? dwindows even though is very similar to GTK1 but it's not a perfect clone and it can't be used as a drop-in replacement for GTK1. People seems to expect if they could make LCL-GTK1 working then they should have it work with dwindows by just have it to link with dw.dll instead of GTK1. No, it's not work this way. LCL-GTK1 is only used as a reference for our new LCL-DW widgetset. Since the API is very similar and dwindows is simple enough the work is not as much as making something like LCL-GTK4

[MarkMLl]

What's wrong with OS/2? There is still OS/2 clones available and active developed

Where do I begin. The Warp startup, which by default played a startup sound at full volume causing intense embarrassment in a semi-openplan office? And please don't tell me that anybody who was actually interested only installed it once...

The flaky WPS, which would randomly break associations? The TCP support, which was broken as distributed requiring one to connect to IBM's support BBS for a fixpack... tricky with no network? The broken serial drivers? Rikke Helms in charge of developer support, doing for OS/2 what she did for Delphi?

And to top it all, a paid support service which was so overloaded and understaffed that one was repeatedly inflicted by Vivaldi's Four Seasons running through Spring, Summer and then restarting abruptly half-way through Autumn?

Even after all these years, I can't listen to Vivaldi without cringing.

But I would agree that it was a "Better DOS than DOS". As long as one didn't try to use a COM port in anger.

Other points noted, thanks for the clarification.

MarkMLl

[s6nonqxt]

Most of these over-gtk widget set only work very roughly for very sparsely populated dialogues that hardly resize (but add scrollbars if necessary).

The LCL however requires nearly pixel exact behaviour and dynamic resizing, which is why the current GTK versions are such a big problem.

They only support gnome, which have very widely spaced dialogues with lots of scrollbars.

The chances that some small project suddenly makes GTK exact, and then even over GTK versions is next to zero.

You should have a look at dwindows before making any statements

[MarkMLl]

I don't understand. Why don't we jump directly into dwindows but have to make sure the current LCL-GTK1 work first? dwindows even though is very similar to GTK1 but it's not a perfect clone and it can't be used as a drop-in replacement for GTK1. People seems to expect if they could make LCL-GTK1 working then they should have it work with dwindows by just have it to link with dw.dll instead of GTK1. No, it's not work this way. LCL-GTK1 is only used as a reference for our new LCL-DW widgetset. Since the API is very similar and dwindows is simple enough the work is not as much as making something like LCL-GTK4

You've already said that it has GTK etc. as an underlying layer. Hence you need the OS's GTK support packages.

MarkMLl

[marcov]

You should have a look at dwindows before making any statements

Why don't you simply point to the LCL/DWIN patch/gitlab fork?

That would actually show that you knew something about the LCL before posting an alternative project course in your first post.

[s6nonqxt]

You've already said that it has GTK etc. as an underlying layer. Hence you need the OS's GTK support packages.

MarkMLl

Yes. We will need GTK development files. But you don't have to use exactly GTK1. dwindows supports GTK2/GTK3 and has experimental support for GTK4