Recent

Author Topic: Proposing new widgetset: dwindows  (Read 9469 times)


dbannon

  • Hero Member
  • *****
  • Posts: 2796
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Proposing new widgetset: dwindows
« Reply #31 on: December 12, 2022, 01:01:23 pm »
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 :D

I do have the dev files present. The problem is the Install option to make does not know the correct place to put its library in, I found it in /usr/local/lib which may, or may not be usable. In a clean install its 'not'.  Sym linking to /usr/lib and building dwtest.c with the make file does work however.   

Cannot be too many users if I am the first to pick that one up ....

Does not look, as Alexy would say, 'nice'. Alignments off, colors. I guess its a test not a demo so maybe not a lot of effort put into presentation but on what I see there, I don't think so. I think the author has done a very difficult job, reasonably well. But well enough yet for me to gamble on him.

There would need to be a lot of coding done to support the rich set of widgets that are LCL from the basic ones offered, at this stage from dwindows.

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6686
Re: Proposing new widgetset: dwindows
« Reply #32 on: December 12, 2022, 01:18:29 pm »
Does not look, as Alexy would say, 'nice'. Alignments off, colors. I guess its a test not a demo so maybe not a lot of effort put into presentation but on what I see there, I don't think so. I think the author has done a very difficult job, reasonably well. But well enough yet for me to gamble on him.

I appreciate that OP is now saying that's it's really only for "live" versions, i.e. GTK3/4, but he certainly gave the impression at the start of the thread that it was a general solution that could be applied to- and was already maintained for- any underlying library.

I'm not criticising him for that. If anybody deserves criticism it's the Gnome/GTK developers, who have in the past justified their willingness to massacre their /published/ GTK API by the fact that Linux has made fairly drastic changes to its /internal/ APIs.

Which leaves one wondering whether GTK is worth taking seriously, if its developers only regard it as one component of the GNOME desktop, with no public API, and have no interest in anybody using it independently.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PierceNg

  • Sr. Member
  • ****
  • Posts: 374
    • SamadhiWeb
Re: Proposing new widgetset: dwindows
« Reply #33 on: December 12, 2022, 01:51:49 pm »
I appreciate that OP is now saying that's it's really only for "live" versions, i.e. GTK3/4, but he certainly gave the impression at the start of the thread that it was a general solution that could be applied to- and was already maintained for- any underlying library.

I spent an hour or so looking at dwindows and the interface builder. My understanding is that the dwindows dw_xxx APIs started out mirroring GTK1 APIs and are thin wrappers over them, e.g., dw_draw_rect() calls gd_draw_rect(). Over time, dw_xxx got generalized to cover other widget sets, so dw_draw_rect() on Android invokes JNI to call the Android native draw-rect routine, and on iOS is implemented in Obj-C to call the Cocoa draw-rect routine, and so on.

Assuming that GTK1 is effectively dead, i.e., API frozen, and that the dw_xxx GTK1 wrappers have not been touched since they were last actually usable with GTK1, then, on a suitably old computer with GTK1, the current dwindows, if it builds, should continue to work on said GTK1 computer.
 
I'm not criticising him for that. If anybody deserves criticism it's the Gnome/GTK developers, who have in the past justified their willingness to massacre their /published/ GTK API by the fact that Linux has made fairly drastic changes to its /internal/ APIs.

Which leaves one wondering whether GTK is worth taking seriously, if its developers only regard it as one component of the GNOME desktop, with no public API, and have no interest in anybody using it independently.

For LCL, given that LCL-Qt5/Qt6 works well enough on Linux, personally I don't care about LCL-GTK3.

I am interested to see whether dwindows allows programming Android and iOS mobile apps in Pascal relatively comfortably.
« Last Edit: December 12, 2022, 01:53:22 pm by PierceNg »

zeljko

  • Hero Member
  • *****
  • Posts: 1596
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Proposing new widgetset: dwindows
« Reply #34 on: December 12, 2022, 02:31:18 pm »
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.

+1. An fish eye over dwindows sources, looks promising, but to get it work as LCL WS there's still a lot of work.

s6nonqxt

  • Guest
Re: Proposing new widgetset: dwindows
« Reply #35 on: December 12, 2022, 11:59:04 pm »
Which leaves one wondering whether GTK is worth taking seriously, if its developers only regard it as one component of the GNOME desktop, with no public API, and have no interest in anybody using it independently.

MarkMLl

The GTK world is huge. It's not only GNOME but MATE, XFCE,... There are so many GTK apps. The rule of thumb is: Qt apps look odd on GTK environments and GTK apps look odd on Qt environments (KDE, LXQT,...). Skipping GTK you are pretty much skipping haft of the Linux/Unix graphical applications world.

s6nonqxt

  • Guest
Re: Proposing new widgetset: dwindows
« Reply #36 on: December 13, 2022, 12:02:02 am »
I do have the dev files present. The problem is the Install option to make does not know the correct place to put its library in, I found it in /usr/local/lib which may, or may not be usable. In a clean install its 'not'.  Sym linking to /usr/lib and building dwtest.c with the make file does work however.

Oh no don't do that. This symlink could break your system. Have a look at ldconfig :o

https://man7.org/linux/man-pages/man8/ldconfig.8.html

iahung

  • New Member
  • *
  • Posts: 22
Re: Proposing new widgetset: dwindows
« Reply #37 on: December 13, 2022, 01:09:31 am »
+1. An fish eye over dwindows sources, looks promising, but to get it work as LCL WS there's still a lot of work.

It's open source. Go to it github and talk with it developer.

https://github.com/dbsoft/dwindows

He can be reached on his forum too: https://dbsoft.org/forum/showthread.php?tid=88

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Proposing new widgetset: dwindows
« Reply #38 on: December 13, 2022, 01:14:12 am »
Which leaves one wondering whether GTK is worth taking seriously, if its developers only regard it as one component of the GNOME desktop, with no public API, and have no interest in anybody using it independently.

MarkMLl

The GTK world is huge. It's not only GNOME but MATE, XFCE,... There are so many GTK apps. The rule of thumb is: Qt apps look odd on GTK environments and GTK apps look odd on Qt environments (KDE, LXQT,...). Skipping GTK you are pretty much skipping haft of the Linux/Unix graphical applications world.

I run XFCE4. Have ran it for well over a decade.

In XFCE4 I run a lot a of Qt apps. None of them look odd. So I'm not sure where you are coming from there.

KDE apps under a non-KDE environment. Now that is a different story, I avoid them. Rarely are they a good fit outside of KDE itself. But Qt apps are not a problem.

I agree with MarkMLI. It seems GTK soles purpose is to support GNOME. Yes, I'm aware of all the non GNOME environments that use GTK.

But it seems that GTK is not interested in keeping up with a stable public API.

The API has to be be generated from their introspection. And it changes a lot within each major release.

Qt6 is mostly stable with Lazarus. While I would like to see GTK3 and GTK4 support in Lazarus, I'm not optimistic about it.

I use CudaText-Qt5 on Linux. No issues (that don't have simple workarounds) with it being Qt running it in XFCE4. Recently CudaText-Qt6 was previewed. A few font and toolbar-icon  rendering issues at first, but fixes and workarounds were found, now the font and toolbar-icon rendering is fine.

Lack of good Gtk3 support (and no Gtk4) support in Lazarus is not the fault of the the Lazarus devs. It is the fault of GTK not caring about a stable public API.

CudaText-gtk, no way. Font rendering is unsuitable for me. (No Ligature support in gtk2, but qt5 and qt6 have full ligature support).

Gtk3 was released February of 2011. Still not stable in Lazarus (because GTK does not care about a stable public API)
Gtk4 was released December of 2020. Not even on the horizon for Lazarus, and I don't blame them, given GTK's track record.

Qt5 was released December of 2012. Very stable on Lazarus.
Qt6 was released December of 2020. A couple minor outstanding issues with Lazarus, but already is usable with CudaText and looks and feels correct.

Bottom line. Qt seems to care about a public stable API. Gtk does not.

Yes, I know the GTK world is huge. But so are the Lua and Python worlds. Some major apps have plugins and scripting in Lua, some use Python.
There is no real valid reason for them to support both.

Same goes for Qt and Gtk. They both fulfill the same same needs in the same domain. Why do both have to be supported in Lazarus, when one is very difficult to support compared to the other.
« Last Edit: December 13, 2022, 01:43:24 am by Bogen85 »

iahung

  • New Member
  • *
  • Posts: 22
Re: Proposing new widgetset: dwindows
« Reply #39 on: December 13, 2022, 01:15:40 am »
dw.h included gtk headers. See:

Code: C  [Select][+][-]
  1. #else
  2. /* GTK Specific section */
  3. #define _GNU_SOURCE
  4. #include <gtk/gtk.h>
  5. #if GTK_MAJOR_VERSION < 4
  6. #ifdef GDK_WINDOWING_X11
  7. # include <gdk/gdkx.h>
  8. #else
  9. # include <gdk/gdk.h>
  10. #endif
  11. #include <gdk/gdkprivate.h>
  12. #endif
  13. #include <gdk/gdkkeysyms.h>
  14. #include <pthread.h>
  15. #if !defined(GDK_WINDOWING_WIN32)
  16. # include <dlfcn.h>
  17. #endif

https://github.com/dbsoft/dwindows/blob/master/dw.h

This means you have to translate gtk headers in order to translate dw.h to pascal.

Very luckily gtk headers could be translated automatically by gir2pascal.

iahung

  • New Member
  • *
  • Posts: 22
Re: Proposing new widgetset: dwindows
« Reply #40 on: December 13, 2022, 01:26:10 am »
The chances that some small project suddenly makes GTK exact, and then even over GTK versions is next to zero.

This small project is called IUP: https://sourceforge.net/projects/iup/

There is another: https://github.com/frang75/nappgui_src (source) https://github.com/frang75/nappgui (bin)

The advantage of dwindows is it's small, nothing else.

If count C++, Ultimate++ is a good GTK wrapper that has a stable API: https://www.ultimatepp.org/

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Proposing new widgetset: dwindows
« Reply #41 on: December 13, 2022, 01:29:46 am »
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 :D
...
Does not look, as Alexy would say, 'nice'. Alignments off, colors. I guess its a test not a demo so maybe not a lot of effort put into presentation but on what I see there, I don't think so. I think the author has done a very difficult job, reasonably well. But well enough yet for me to gamble on him.
...

I have built CudaText-gtk3 a few times... Completely unusable as Davo pointed out...
First CudaText-qt6 preview was actually usable, although it did have some ugly font rendering that was soon fixed.
Despite the ugly font rendering it was mostly correct, unlike CudaText-gtk3 the few times I've tried it, as it is mostly incorrect...


iahung

  • New Member
  • *
  • Posts: 22
Re: Proposing new widgetset: dwindows
« Reply #42 on: December 13, 2022, 01:32:25 am »
Which leaves one wondering whether GTK is worth taking seriously, if its developers only regard it as one component of the GNOME desktop, with no public API, and have no interest in anybody using it independently.

MarkMLl

The GTK world is huge. It's not only GNOME but MATE, XFCE,... There are so many GTK apps. The rule of thumb is: Qt apps look odd on GTK environments and GTK apps look odd on Qt environments (KDE, LXQT,...). Skipping GTK you are pretty much skipping haft of the Linux/Unix graphical applications world.

I run XFCE4. Have ran it for well over a decade.

In XFCE4 I run a lot a of Qt apps. None of them look odd. So I'm not sure where you are coming from there.

KDE apps under a non-KDE environment. Now that is a different story, I avoid them. Rarely are they a good fit outside of KDE itself. But Qt apps are not a problem.

I agree with MarkMLI. It seems GTK soles purpose is to support GNOME. Yes, I'm aware of all the non GNOME environments that use GTK.

But it seems that GTK is not interested in keeping up with a stable public API.

The API has to be be generated from their introspection. And it changes a lot within each major release.

Qt6 is mostly stable with Lazarus. While I would like to see GTK3 and GTK4 support in Lazarus, I'm not optimistic about it.

I use CudaText-Qt5 on Linux. No issues (that don't have simple workarounds) with it being Qt running it in XFCE4. Recently CudaText-Qt5 was previewed. A few font and toolbar-icon  rendering issues at first, but fixes and workarounds were found, now the font and toolbar-icon rendering is fine.

Lack of good Gtk3 support (and no Gtk4) support in Lazarus is not the fault of the the Lazarus devs. It is the fault of GTK not caring about a stable public API.

CudaText-gtk, no way. Font rendering is unsuitable for me. (No Ligature support in gtk2, but qt5 and qt6 have full ligature support).

Gtk3 was released February of 2011. Still not stable in Lazarus (because GTK does not care about a stable public API)
Gtk4 was released December of 2020. Not even on the horizon for Lazarus, and I don't blame them, given GTK's track record.

Qt5 was released December of 2012. Very stable on Lazarus.
Qt6 was released December of 2020. A couple minor outstanding issues with Lazarus, but already is usable with CudaText and looks and feels correct.

Bottom line. Qt seems to care about a public stable API. Gtk does not.

Yes, I know the GTK world is huge. But so are the Lua and Python worlds. Some major apps have plugins and scripting in Lua, some use Python.
There is no real valid reason for them to support both.

Same goes for Qt and Gtk. They both fulfill the same same needs in the same domain. Why do both have to be supported in Lazarus, when one is very difficult to support compared to the other.

We used to met on github. I know you. In no way I could consider the screenshots you posted as good enough looking. The was odd is too underestimated, I would say ugly. CudaText Qt6 looks so ugly on your XFCE4:

https://github.com/Alexey-T/CudaText/issues/4595

PierceNg

  • Sr. Member
  • ****
  • Posts: 374
    • SamadhiWeb
Re: Proposing new widgetset: dwindows
« Reply #43 on: December 13, 2022, 01:34:15 am »
This means you have to translate gtk headers in order to translate dw.h to pascal.

Wrap dwindows means writing Pascal FFI definitions for dw_xxx API. The dw_xxx API already wraps the underlying widget sets, like what LCL does.

iahung

  • New Member
  • *
  • Posts: 22
Re: Proposing new widgetset: dwindows
« Reply #44 on: December 13, 2022, 01:40:26 am »
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 :D
...
Does not look, as Alexy would say, 'nice'. Alignments off, colors. I guess its a test not a demo so maybe not a lot of effort put into presentation but on what I see there, I don't think so. I think the author has done a very difficult job, reasonably well. But well enough yet for me to gamble on him.
...

I have built CudaText-gtk3 a few times... Completely unusable as Davo pointed out...
First CudaText-qt6 preview was actually usable, although it did have some ugly font rendering that was soon fixed.
Despite the ugly font rendering it was mostly correct, unlike CudaText-gtk3 the few times I've tried it, as it is mostly incorrect...

The different between Pascal gtk2 binding vs gtk3 binding is the former is coded by hand and the later is automated by gir2pascal. The former used the correct syntax for dynamic link but the later not. It's why gtk2 is much better.

https://forum.lazarus.freepascal.org/index.php/topic,61278.msg460587.html

I used many Lazarus compiled applications (cudatext, doublecmd,...). I always prefer gtk2 on Linux over any version of qt, because it looks native on my DE (desktop environment).

 

TinyPortal © 2005-2018