How long gtk+2.0 will last? lazarus / 31-LCL ---------------------------------------------------------------------- funlw65 · 2018-12-29 02:37 I know is statically linked but how long it will still be theme-able in linux distributions (UNIX is moving slower in that regard)? This is my "drama" right now. Continuing to compile with gtk2, or switching completely to Qt5... In Qt5 looks more polished and of course, Qt is on top of the wave right now and it seems that it will stay there for a long time. ---------------------------------------------------------------------- lucamar · 2018-12-29 03:06 Seeing that there are quite a handful of well-known and widely used applications still using GTK2 (like our Lazarus), I'm inclined to say: forever! ---------------------------------------------------------------------- dsiders · 2018-12-29 05:44 Quote from: lucamar on December 29, 2018, 04:06:39 amSeeing that there are quite a handful of well-known and widely used applications still using GTK2 (like our Lazarus), I'm inclined to say: forever! I'm less optimistic. I don't think applications (even the largest of them) are keeping GTK+2 going. It is the Linux distros that refuse to move to another toolkit. Those numbers seem to be dwindling. Even some one time GTK+2 stalwarts have moved on to GTK+3 or QT5. GTK+2 is frozen at 2.24. Even maintenance releases have slowed down. The last one (now 12 months old) took 16 months to arrive. Eventually, this slower pace will drive more distros away. And the death spiral accelerates. I'm guessing the corpse gets buried in 2020. Isn't it fun playing the pundit? ---------------------------------------------------------------------- JuhaManninen · 2018-12-29 10:36 Quote from: funlw65 on December 29, 2018, 03:37:23 amContinuing to compile with gtk2, or switching completely to Qt5 You can easily compile both unless you added widgetset specific code into your application. Let the user decide which version to use. Remember, there is also GTK3, although it is not as complete as GTK2 yet. ---------------------------------------------------------------------- dubst3pp4 · 2018-12-29 13:44 I think many distributions will remove GTK2 libraries sooner or later. Unfortunately I'm not experienced with C programming - I really would like to see someone to work on the GTK3 bindings. The gir2pascal tool to generate the GTK3 bindings still works really well (see http://lazarus-dev.blogspot.com/2012/08/gtk3-gobject-introspection- and-free.html)  but I was not able to link the examples with a current installation of GTK3... Maybe we can join forces together to update the LCL binding to GTK3? Anyone willing to help? ---------------------------------------------------------------------- sash · 2018-12-29 15:44 As there are no announcements from distros about gtk2 endoflife, there's no "drama" at all, and even then simple rebuild for QT works. For emergency measures - there's a WINE  (joke ). ---------------------------------------------------------------------- funlw65 · 2018-12-29 15:57 Quote from: https://lwn.net/Articles/701876/The 3.22 release is the last development release in the GTK+ 3. series. GTK+ 3.22 will be maintained as the long-term stable version of GTK+ 3...3.22.x versions are maintenance releases without changing the ABI. It is end of line for GTK+ 3 and the translation work can start without the fear that the GTK+ developers will break the code again. And this is the problem. Only long-term stable or final releases can be translated but with securing the C sources because the time when this happens, the world has moved to another major version of the library.  Anyway, I personally prefer Qt as there is more seriousness than in GTK+ world. And it shows in the "world wide" adoption... The downside is that I have to deliver a quite big shared library alongside the executable of my application. ---------------------------------------------------------------------- VTwin · 2018-12-29 16:26 I was going to say that I wouldn't worry about it until Ubuntu was released with Qt, but: https://www.qt.io/ubuntu-built-with-qt Luckily it seems Lazaus is already Qt ready. Quote from: funlw65 on December 29, 2018, 04:57:31 pmThe downside is that I have to deliver a quite big shared library alongside the executable of my application. I assume that with linux Qt distros that will not be necessary? ---------------------------------------------------------------------- funlw65 · 2018-12-29 17:27 Quote from: VTwin on December 29, 2018, 05:26:42 pm... Quote from: funlw65 on December 29, 2018, 04:57:31 pmThe downside is that I have to deliver a quite big shared library alongside the executable of my application. I assume that with linux Qt distros that will not be necessary? It needs Qt5Pas dynamic library. Just tested in another linux version and I get this: ---------------------------------------------------------------------- zeljko · 2018-12-29 17:29 libQt4Pas is already packaged in all main distros (ubuntu,mint,fedora,suse etc), libQt5Pas is also available but I hope that they'll update libQt5Pas package to the latest one, so lazarus- qt5 can work out-of-the-box on ubuntu,fedora etc. ---------------------------------------------------------------------- funlw65 · 2018-12-29 17:51 Quote from: zeljko on December 29, 2018, 06:29:28 pmlibQt5Pas is also available but I hope that they'll update libQt5Pas package to the latest one, so lazarus-qt5 can work out-of-the-box on ubuntu,fedora etc. After compiling the sources of libQt5Pas and installing them in Ubuntu 18.04, Lazarus (2.0 rc3) compiles and works ok. Of course, I don't use the packages from the Ubuntu repository. ---------------------------------------------------------------------- funlw65 · 2018-12-29 18:03 Quote from: lucamar on December 29, 2018, 04:06:39 amSeeing that there are quite a handful of well-known and widely used applications still using GTK2 (like our Lazarus), I'm inclined to say: forever! Statically linking assure a "forever" status. Well, same when you continue to provide all shared libraries but I referred to the "look" of the application and that is crucial. When a gtk+2 theme engine won't be provided anymore by linux distros, your application will look "alien". From this angle, I pretty much applaud the Operating Systems with a standard set of GUI (OS X, Windows, Haiku OS). Or the GUI that looks pretty on all the Operating Systems (Qt). ---------------------------------------------------------------------- zeljko · 2018-12-29 18:45 Quote from: funlw65 on December 29, 2018, 07:03:09 pmFrom this angle, I pretty much applaud the Operating Systems with a standard set of GUI (OS X, Windows, Haiku OS). Or the GUI that looks pretty on all the Operating Systems (Qt). Qt looks native on all supported OS, that's most important part. ---------------------------------------------------------------------- funlw65 · 2018-12-29 21:18 This is the future of an application with GUI based on gtk+2, in a non-themeable environment (the right window). And it looks old, no matter how many colorful icons and images you embed in the interface. Qt has a couple of styles embedded and it looks ok in a "hostile" environment. ---------------------------------------------------------------------- dubst3pp4 · 2018-12-30 15:11 I don't understand why you are discussing the qt library when the original question was about GTK. GTK3 development in the last year was awesome! Gnome, elementary, Mate and Cinnamon and last but not least XFCE are only some of the desktop environments that are using GTK3. So how can you say qt is more "serious"? On Linux it would be a breath of death for Lazarus if it does not support GTK3 in the next years. At least for me, it would be more interesting to be able to use GTK3 than Pascal so I would move to C, Vala, D, Python, Ruby, Lua or whatever, which, by the way, in contrast to FreePascal have excellent GTK3 bindings since years! But instead of ranting, I would like to change the situation and again would like to call all developers who are unsatisfied with the current situation to join and to coordinate the development on the GTK3 bindings! Best regards, Marc ---------------------------------------------------------------------- funlw65 · 2018-12-31 02:53 Man, as a programmer you should be more accurate. If you refer to the title, there is exactly about gtk2. But the main "target" of my post is about the look of the application developed in Lazarus (if you analyze the text). More and more gtk2 based applications are migrating to gtk3 and there is no warranty that the gtk2 theme engine and the associated themes will continue to be distributed so, the future of the look of a gtk2 based application is uncertain. There is no fight against gtk but the support for gtk3 is still alpha and only qt comes with a guarantied modern look (regarding seriousness, I referred to the scandal generated by the gtk developers resistance to "theming" and the breaking of any custom theme with every new gtk release - well, I agree with them that there should be a consistent look as long as there is also a dark theme variation, but making them "embedable" should be preferable). If you want to plead for gtk, do it without attacking my post. And yes, I am still in doubt as compiling for gtk2 I have the certain advantage of static linking and I don't force the users to install additional shared libraries. Even more, is not easy (for the same users that maybe don't know Lazarus and Pascal in general - my project is open source) to compile for qt5 when Lazarus defaults to gtk2. P.S. Embedded Fusion style in Qt5, consistency across all operating systems: http://blog.qt.io/blog/2012/10/30/cleaning-up-styles-in- qt5-and-adding-fusion/ Modern and pretty enough for me. If Gtk3 can embed a default theme, I am sold. ---------------------------------------------------------------------- dbannon · 2018-12-31 05:39 Yes funlw65, you do have some good points. QT might be a viable alternative but why do we want/need an alternative ?   For me, the thing that makes FPC/Lazarus really great is that it produces a (usually) dependency free install. Right now, on Linux we are all using GTK2 and, honestly, mostly happy about that but we are ignoring the future. Same as we did on the Mac, we wrote for Carbon right up until Apple started waving a big stick. Cocoa is now pretty good but no where near as stable as Carbon. On Linux, we use GTK2, smug in the knowledge that Gnome will 'always' support it.  Well, anyone tried to use the Lazarus SystemTrayIcon on (eg) a recent Fedora ?  The Gnome developers decided that aspect of GTK2 was ugly (or something) and it no longer works in 'pure' gnome 3.28 or later. Ubuntu had a similar AppIndicator for Unity (remember Unity ?) and still, at present, ship it. Last time I checked, Debian was not yet up to Gnome 3.28, been awhile.... My point is "we'll always support" is up to the supporter to define. And we may not like their definition ! My research prior to this post ?  QT5 is not hard to get going using Ubuntu Repos but a form with one button idles at 100% cpu. The wki page on QT5 refers you to the readme.txt file that refers you to the wiki. GTK3 does not link, I guess there is binding library missing. The GTK3 wiki page is about 50 words long. davo ---------------------------------------------------------------------- dubst3pp4 · 2019-01-01 14:47 Quote from: funlw65 on December 31, 2018, 03:53:27 amIf you want to plead for gtk, do it without attacking my post. Sorry funlw65, it was not my intention to attack your post! I'm just wondering that everytime in this forum when someone ask about GTK, the standard response is, that qt is the "better" and "more serious" toolkit and that the "new" GTK3 api is just "crap" and "unstable". GTK3 is now exactly 8 years old and unfortunately no-one seems to be interested in creating GTK3-LCL-bindings - which makes me really sad. I would like to see the same support as many many other languages have. And I'm also willing to improve the situation - but unfortunately I don't have the time to do this alone. Maybe dbannon got it better to the point which I'm afraid of: That the GTK2 support ends like the Carbon bindings: Carbon was officially deprecated in 2012 - and now, 7 years later the Cocoa support of LCL is still not mature. This is of course no problem for the majority of Windows users, but for the macOS users of Lazarus this really hurts. And the same it hurts me as a long-time GNOME user that GTK3 support is still uncomplete. That said I don't want to get on your nerves or to disrupt your post ;-) I wish all Lazarus and Free Pascal users a happy New Year! Marc ---------------------------------------------------------------------- dbannon · 2019-01-01 21:27 Quote from: dubst3pp4 on January 01, 2019, 03:47:27 pm .....the standard response is, that qt is the "better" and "more serious" toolkit and that the "new" GTK3 api is just "crap" and "unstable". GTK3 is now exactly 8 years old and unfortunately no-one seems to be interested in creating GTK3-LCL-bindings - which makes me really sad. I would like to see the same support as many many other languages have. And I'm also willing to improve the situation - but unfortunately I don't have the time to do this alone. .... I think you have summed it up well Marc. QT is apparently pretty good, However, its use is an arcane and well kept secret.  And it introduces dependencies. If we believe the wiki, GTK3 is a long way off. People like you and me would like to help but as someone who's been poking around in the lower levels from time to time, I believe the learning curve is too steep.  There are some very hard pressed "top guns" out there, they cannot afford the time stop and write some docs or assign some apprenticeship tasks to the less skilled. Short term, its not efficient to do so. But long term .... Davo ---------------------------------------------------------------------- Thaddy · 2019-01-02 07:25 I won't take sides, but just some observations: 1. GTK was once considered as code bloat on top of X. 2. GTK2 is considered "lightweight" nowadays.... 3. GTK3 isn't. 4: Qt - any version - never was. Both GTK3+ and Qt( any version and by design)  suffer not from code rot, but resource rot. Any rot slows down your application... Both the  Qt and GTK projects have the gift of humongous breaking API changes. And Qt runs much slower than GTK2 because it is so resource intensive. As does GTK3. That limits in both cases the amount of platforms you can actually use it in any meaningful way..... The above will also mean GTK2 will be around for quite some time. It finally deserved the status of "lightweight"..... ---------------------------------------------------------------------- funlw65 · 2019-01-02 22:12 Quote from: Thaddy on January 02, 2019, 08:25:49 am... The above will also mean GTK2 will be around for quite some time. It finally deserved the status of "lightweight"..... Yeah, I can see the advantage of that, but then we have to solve the problem of theming. A way to embed two themes (light and dark) in the gtk2 and that will solve the eye candy for years to come. For both Lazarus and applications look. ---------------------------------------------------------------------- funlw65 · 2021-01-03 06:27 The only definitive solution is to rewrite the C part of gtk2 directly in freepascal. A monumental work, but having visual components is vital for Lazarus. ---------------------------------------------------------------------- PascalDragon · 2021-01-03 12:01 The right answer to that is that instead the CustomDrawn interface needs to be improved/completed. It works directly atop of X11 (and in the future should also support Wayland) and has no external dependencies. Currently it's only suitable for simple windows however as not even menus are implemented... Also there is quite some work going on in the GTK3 backend so maybe you can help out to improve that? ---------------------------------------------------------------------- ferdnyc · 2021-01-03 14:28 Quote from: PascalDragon on January 03, 2021, 01:01:17 pmAlso there is quite some work going on in the GTK3 backend so maybe you can help out to improve that? At this point, if they aren't targeting Gtk4 (as of 2020-12-16, officially released), then they're really just setting themselves (and everyone else) for a rerun of the current situation with GTK2. I mean, at this point working on GTK3 is fairly close to targeting an already- dead platform. Not quite necrophilia, but a bit morbid. By the same token, any further development involving Qt should really be focused primarily on Qt6. (Released as of 2020-12-08, though with some compatibility deficits relative to Qt5 that they're promising to shore up come 6.1 or 6.2.) Quote from: funlw65 on December 31, 2018, 03:53:27 amP.S. Embedded Fusion style in Qt5, consistency across all operating systems: http://blog.qt.io/blog/2012/10/30/cleaning-up-styles-in- qt5-and-adding-fusion/ Modern and pretty enough for me. If Gtk3 can embed a default theme, I am sold. In fairness, none of the Qt5 platform themes are "embedded". On all systems (except maybe when literally-embedded in the form of Qt for Embedded Linux, a lightweight hardware-device platform), the theming relies on Qt's plugins system, and is dynamically loaded on application launch. All theming is done using plugins, and at least one platform plugin is required to even initialize a QGuiApplication. The Qt installers have a set of default themes that they ship with, and the fusion theme (at a minimum) is bundled into Qt5 on every platform which provides some nice standardization, but it is in no way, shape, or form "embedded". ---------------------------------------------------------------------- Soner · 2021-01-03 14:45 Forget Gtk3 lets make Gtk4 bindings. Final release of Gtk4 is out and they dropped support for gtk2. https://blog.gtk.org/2020/12/16/gtk-4-0/ ---------------------------------------------------------------------- funlw65 · 2021-01-03 15:30 Quote from: PascalDragon on January 03, 2021, 01:01:17 pmThe right answer to that is that instead the CustomDrawn interface needs to be improved/completed. It works directly atop of X11 (and in the future should also support Wayland) and has no external dependencies. Currently it's only suitable for simple windows however as not even menus are implemented... Also there is quite some work going on in the GTK3 backend so maybe you can help out to improve that? Prior to posting this reply, I was reading a certain Wiki page and I completely agree with the author.  And with you. Recreating the LCL on top of an existing GUI toolkit is a huge task that never ends. So I think that indeed, the CustomDrawn interface is the only way to go. If it will come with both a light and a dark standard style. Quoting from the Wiki: QuoteThe native look is very important for many developers, but combined with the VCL compatibility necessitates many complex interfaces to the different native widget sets (Gtk,Win32,Carbon,Qt). The continuous evolution of these native widget sets (gtk1->gtk2, win32->?, qt) provokes endless catching up. I won't give a link to that Wiki, I'm not here to drive people to other tools. ---------------------------------------------------------------------- marcov · 2021-01-03 15:49 Customdrawn will face constant challenges of being non native, and as soon as development slows down will look outdated too. It is as thankless a job as adapting a new GTK. There is simply no longterm stability in the *nix GUI world. ---------------------------------------------------------------------- funlw65 · 2021-01-03 16:10 Quote from: marcov on January 03, 2021, 04:49:28 pmCustomdrawn will face constant challenges of being non native, and as soon as development slows down will look outdated too. It is as thankless a job as adapting a new GTK. There is simply no longterm stability in the *nix GUI world. If it looks like Fusion Qt style and has light and dark themes it works for me, no matter the OS and the current theme of that OS; No need to "update" it as it looks the same on all OSes (Fusion is pretty enough), just HiDPI compatible.  But if is equipped with a style engine, it can look like the whatever theme the OS has. You don't need to play "catch up". ---------------------------------------------------------------------- lainz · 2021-01-03 16:15 I think the web interfaces are good to try, now for example chrome embedded framework for linux. Or just use the OS default browser, making the application just a local server. I did that in a commercial application and works fine. No more LCL issues. ---------------------------------------------------------------------- funlw65 · 2021-01-03 16:16 It is why I said that we need to make the gtk2 our own by rewriting it in pascal (it is how you become a real Qt rival regarding GUI solutions - in that moment, Qt loses its relevance). The major problem of gtk2 sources is the C compiler that changes constantly and the sources must be  maintained for that matter. Once gtk2 is rewritten in pascal, the "catch up" play ends. It will be part of the Lazarus distro and sources. But I understand that there is CustomDrawn... ---------------------------------------------------------------------- marcov · 2021-01-03 21:11 Quote from: funlw65 on January 03, 2021, 05:10:05 pmQuote from: marcov on January 03, 2021, 04:49:28 pmCustomdrawn will face constant challenges of being non native, and as soon as development slows down will look outdated too. It is as thankless a job as adapting a new GTK. There is simply no longterm stability in the *nix GUI world. If it looks like Fusion Qt style and has light and dark themes it works for me, no matter the OS and the current theme of that OS; For people that e.g. use it for displays of machines (HMI) that is often fine. QuoteNo need to "update" it as it looks the same on all OSes (Fusion is pretty enough), just HiDPI compatible.  But if is equipped with a style engine, it can look like the whatever theme the OS has. You don't need to play "catch up". And solve all the bugs that popup doing it, and expand the style engine again for the GUI-trends du jour.  Which is exactly what I meant. Moreover most of the style engines only govern native look, not feel (reacting to keyboard and mouse events). I use pretty expensive Java software, and are constantly annoyed by their non-native file (open/save)  dialogs. Custom drawn has some aspects of being is the same trap as modularization, it just separates the hard parts out, and postpones them. As said that doesn't need to be bad if you are in a business where you don't distribute widely to users, and users might not even known on what OS they are. For that I customdraw might be a good thing, with a long term very stable GUI option. But if you have to compete with native apps, that is a delusion. ---------------------------------------------------------------------- marcov · 2021-01-03 21:38 Quote from: lainz on January 03, 2021, 05:15:13 pmI think the web interfaces are good to try, now for example chrome embedded framework for linux. Or just use the OS default browser, making the application just a local server. I did that in a commercial application and works fine. No more LCL issues. It depends on the nature of the application. It is harder to load screens full of functionality in webbrowsers. For our own apps that are somewhat HMI like in principle they are therefore a bad fit. ---------------------------------------------------------------------- lainz · 2021-01-03 22:52 I never seen an HMI application so I can't say. But I think if you do the same as in the desktop, say separate into components and determine their functionality very well, it can do the same, there is no limitation, of course it uses more memory, but the final result can be the same that in an LCL application. ---------------------------------------------------------------------- dbannon · 2021-01-03 23:50 Wow, this quite an old thread. Two years ago I was dismissing Qt5, now I am a believer.  Apparently GTK3 is officially 'stable' now meaning that we can expect to see a reduction in the things being changed as soon as we use them.  So, maybe it is time to really concentrate on getting the GTK3 interface up to scratch. Maybe. From memory, adding Qt5 to a system without it is about 50Meg, for GTK2, its about 200 Meg. I have no idea what GTK3 would require but I am guessing its heaps more than GTK2.  And, maybe, the size of the library is some indication of the size of the effort to use it effectively ? Anyway, as a confirmation that this thread is important,  I have recently been working on getting my application into the Debian repositories. They made it quite clear that they were not accepting any new GTK2 apps. So Qt5 it is folks.  It looks good but I believe the GTK2 version is just a little more 'polished' but Qt5 it is ! Davo ---------------------------------------------------------------------- Fred vS · 2021-01-04 01:03 Quote from: dbannon on January 04, 2021, 12:50:01 am...   I have recently been working on getting my application into the Debian repositories. They made it quite clear that they were not accepting any new GTK2 apps. So Qt5 it is folks.  It looks good but I believe the GTK2 version is just a little more 'polished' but Qt5 it is ! Davo Hello Davo. Do you know if Debian accept "Pure Xorg" applications, I mean applications that does not use classical widgetset and dont need to install any others dependencies? (Like fpGUI or MSEgui for example). Thanks. ---------------------------------------------------------------------- valdir.marcos · 2021-01-04 04:01 Taking advantage of this discussion, what about wxWidgets? Would it be more difficult to make Lazarus bindings to wxWidgets than to GTK4 or Qt6? Would wxWidgets be more resource (performance, RAM, disk) consuming than GTK4 and Qt6? Would wxWidgets be a viable alternative to GTK4 and Qt6? ---------------------------------------------------------------------- funlw65 · 2021-01-04 07:09 Quote from: valdir.marcos on January 04, 2021, 05:01:08 amTaking advantage of this discussion, what about wxWidgets? Would it be more difficult to make Lazarus bindings to wxWidgets than to GTK4 or Qt6? Would wxWidgets be more resource (performance, RAM, disk) consuming than GTK4 and Qt6? Would wxWidgets be a viable alternative to GTK4 and Qt6? Apart of the fact that has a unique (the same) look (Windows like) on all platforms (not a problem for me anymore)? It is not so widely used as the other two and has the same problem as those - it is written in C/C++  and this is a major problem. The gcc compiler changes from a year to another and those libraries require code maintenance (if the project lags behind then introduces delays to Lazarus LCL development). Qt5 is the most portable among OSes and is theme-able. A GUI written completely in Pascal that can look as Qt5 is the future proof solution. And no more memory leaks. LCL is better in every aspect compared to Qt5 but we need our own low-level GUI to really compete with Qt5 based solutions. I see here are people that already do that with their tools  and this is how you secure your solution. So, really serious reasons to go to pit stop... ---------------------------------------------------------------------- devEric69 · 2021-01-04 10:22 For information, the fastest and lightest desktop ("out of the box") is XLDE (a GTK+ desktop). I've tried to create a 100% Qt desktop during 2 days long, starting from LXQt desktop: I couldn't do it. I may have been bad. But, I've noticed that LXQt comes with a whole "Qt layer over GTK", and has some essential desktop management utilities that need the GTK+ layer. In addition, they install Firefox or Office suites (which use GTK) instead of Konqueror (which uses Qt). Overall, I would say that installing a 100% operational Qt desktop alone on a workstation, without GTK+ seems impossible to me. I have the feeling that the reverse is not necessarily true. I only ask to be invalidated. ---------------------------------------------------------------------- funlw65 · 2021-01-04 11:05 LXQt is an work in progress, it started from LXDE and it seems that they still have a long way to go. But this means nothing and is specific to Linux/Unix only. I do not vote for Qt, but it has the most coverage compared to gtk3. It will save resources developing only for Qt, but I vote for CustomDrawn or a similar, pascal only solution - practically, not prolonging the agony. ---------------------------------------------------------------------- marcov · 2021-01-04 11:14 Quote from: lainz on January 03, 2021, 11:52:13 pmI never seen an HMI application so I can't say. It's just a term for software to operate machines using a industrial touch panel (which necessarily are much less sensitive than phones, since it is often covered in grime etc)  Since scrolling is awkward you don't want a layout paradigm that has wide spacing and adds a scroller constantly. And while in theory you can get html to layout very tightly with css for a defined browser with defined fonts installed, that usually beats any of the (portability, longevity) arguments for html, and then it is just a more difficult solution without benefits. Specially because these apps go for maintenance for long times, but not indefinitely (*) That said, I deliver them mostly on Windows which is fairly stable GUI wise. I did have some breakage with Windows XP (with theming enabled) and Vista and later (always), that sometimes labels directly on a tform/tframe are not repainted for some reason. Putting a panel inbetween solved that. Reading this thread, I remember why again  (*) many of our own machines are not connected to the net, so don't run windows update. Occasionally for revision purposes the customer moves them to an engineering area and connects them to the internet, against our express wishes, running updates and wreaking all kinds of havoc. ---------------------------------------------------------------------- lainz · 2021-01-04 12:13 Ok, yes seems that is a good use case of a native application. ---------------------------------------------------------------------- PascalDragon · 2021-01-04 14:59 Quote from: ferdnyc on January 03, 2021, 03:28:09 pmQuote from: PascalDragon on January 03, 2021, 01:01:17 pmAlso there is quite some work going on in the GTK3 backend so maybe you can help out to improve that? At this point, if they aren't targeting Gtk4 (as of 2020-12-16, officially released), then they're really just setting themselves (and everyone else) for a rerun of the current situation with GTK2. I mean, at this point working on GTK3 is fairly close to targeting an already- dead platform. Not quite necrophilia, but a bit morbid. No, GTK3 is stable enough now, GTK4 is not. Yes, it has its first release now, but that doesn't mean that it's stable now. GIMP (originally the main driver behind GTK) is only now switching from GTK2 to GTK3. Thus GTK3 is indeed the right way to go for the GTK platform. ---------------------------------------------------------------------- valdir.marcos · 2021-01-04 16:19 Quote from: funlw65 on January 04, 2021, 08:09:42 am... It is not so widely used as the other two [GTK and QT] and has the same problem as those - it is written in C/C++  and this is a major problem. The gcc compiler changes from a year to another and those libraries require code maintenance (if the project lags behind then introduces delays to Lazarus LCL development). Qt5 is the most portable among OSes and is theme-able. A GUI written completely in Pascal that can look as Qt5 is the future proof solution. And no more memory leaks. LCL is better in every aspect compared to Qt5 but we need our own low-level GUI to really compete with Qt5 based solutions. I see here are people that already do that with their tools  and this is how you secure your solution. So, really serious reasons to go to pit stop...As far as I know, Qt development has always been backed up by Trolltech's money and took 25 years to be where it is now. How many years and how many people and how much money would be necessary to build a Pascal solution similar to Qt from ground up? ---------------------------------------------------------------------- Fred vS · 2021-01-04 16:38 Quote from: valdir.marcos on January 04, 2021, 05:19:38 pmHow many years and how many people and how much money would be necessary to build a Pascal solution similar to Qt from ground up? Hello. 0 second and 0 $ : fpc has already MSEgui that works perfectly and without any bug. Fre;D ---------------------------------------------------------------------- valdir.marcos · 2021-01-04 16:52 Quote from: funlw65 on January 04, 2021, 08:09:42 amQuote from: valdir.marcos on January 04, 2021, 05:01:08 amTaking advantage of this discussion, what about wxWidgets? Would it be more difficult to make Lazarus bindings to wxWidgets than to GTK4 or Qt6? Would wxWidgets be more resource (performance, RAM, disk) consuming than GTK4 and Qt6? Would wxWidgets be a viable alternative to GTK4 and Qt6? Apart of the fact that has a unique (the same) look (Windows like) on all platforms (not a problem for me anymore)? ...I am not defending wxWidgets, but just to be fair,  it seems it has a native look and fell to OSes: https://en.wikipedia.org/wiki/WxWidgets: "wxWidgets is best described as a native mode toolkit as it provides a thin abstraction to a platform's native widgets, contrary to emulating the display of widgets using graphic primitives. Calling a native widget on the target platform results in a more native looking interface than toolkits such as Swing (for Java), as well as offering performance and other benefits." https://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits: "Whenever possible, wxWidgets uses the native platform SDK and system provided widgets. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it will get the look and feel of a Linux program." wxWidgets is around for 29 years, Qt for 25 years and GTK for 22 years. Is there any other viable options (widget toolkits, also known as GUI frameworks) beyond GTK and Qt? https://en.wikipedia.org/wiki/List_of_widget_toolkits ---------------------------------------------------------------------- valdir.marcos · 2021-01-04 16:59 Quote from: Fred vS on January 04, 2021, 05:38:46 pmQuote from: valdir.marcos on January 04, 2021, 05:19:38 pmHow many years and how many people and how much money would be necessary to build a Pascal solution similar to Qt from ground up?Hello. 0 second and 0 $ : fpc has already MSEgui that works perfectly and without any bug. Fre;D Thanks for sharing. Is MSEgui a custom drawn widget toolkit? If so, what do you think about the following observation? Quote from: marcov on January 03, 2021, 10:11:54 pmQuote from: funlw65 on January 03, 2021, 05:10:05 pmQuote from: marcov on January 03, 2021, 04:49:28 pmCustomdrawn will face constant challenges of being non native, and as soon as development slows down will look outdated too. It is as thankless a job as adapting a new GTK. There is simply no longterm stability in the *nix GUI world. If it looks like Fusion Qt style and has light and dark themes it works for me, no matter the OS and the current theme of that OS; For people that e.g. use it for displays of machines (HMI) that is often fine. QuoteNo need to "update" it as it looks the same on all OSes (Fusion is pretty enough), just HiDPI compatible.  But if is equipped with a style engine, it can look like the whatever theme the OS has. You don't need to play "catch up". And solve all the bugs that popup doing it, and expand the style engine again for the GUI-trends du jour.  Which is exactly what I meant. Moreover most of the style engines only govern native look, not feel (reacting to keyboard and mouse events). I use pretty expensive Java software, and are constantly annoyed by their non-native file (open/save)  dialogs. Custom drawn has some aspects of being is the same trap as modularization, it just separates the hard parts out, and postpones them. As said that doesn't need to be bad if you are in a business where you don't distribute widely to users, and users might not even known on what OS they are. For that I customdraw might be a good thing, with a long term very stable GUI option. But if you have to compete with native apps, that is a delusion. ---------------------------------------------------------------------- Zoran · 2021-01-04 17:25 Quote from: valdir.marcos on January 04, 2021, 05:52:29 pmhttps://en.wikipedia.org/wiki/WxWidgets: "wxWidgets is best described as a native mode toolkit as it provides a thin abstraction to a platform's native widgets, contrary to emulating the display of widgets using graphic primitives. Calling a native widget on the target platform results in a more native looking interface than toolkits such as Swing (for Java), as well as offering performance and other benefits." https://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits: "Whenever possible, wxWidgets uses the native platform SDK and system provided widgets. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it will get the look and feel of a Linux program." wxWidgets is around for 29 years, Qt for 25 years and GTK for 22 years. Do you understand what wxWidgets library is? By using "native" platform, they actually say that wxWidgets is a high-level library which do not have its own custom-drawn widgets, but wraps Gtk on Linux and native Windows widgets on Windows. This is the same aproach which LCL has. wxWidget is a high-level cross platform gui library for C++ -- write once compile anywhere -- use "native" widgets (meaning Gtk or Win) for different operating systems. Just like LCL, but for Pascal. The difference is: - wxWidgets went a bit further with gtk3 - LCL also has Qt backend, whereas wxWidgets does not. ---------------------------------------------------------------------- Zoran · 2021-01-04 17:31 And they also say that Gtk2 backend for wxWidgets is still "more mature" than Gtk3, as can be read here. ---------------------------------------------------------------------- Fred vS · 2021-01-04 17:41 Hello Valdir. QuoteIs MSEgui a custom drawn widget toolkit? Are you talking about CustomDraw widget from LCL package? If so, no, MSEgui is a complete independent widget-set, not child of LCL. https://wiki.freepascal.org/Reference:_MSEgui If you are talking about custom draw feature, yes, MSEgui is a complete widget-set that competes (even wins) against other widget-set ténors, like GTK, QT, ... Form the mseide-msegui site: QuoteThe MSEide is a Cross Platform GUI Development System for Pascal programmers, completely written in Pascal. The MSEgui does not feature VCL compatibility. The graphics library provides an interface to win32 and X11. Quote what do you think about the following observation? Hum, difficult to talk about taste and colors. What is sure, is that, with the applications that I have done with MSEgui, I have total control. If there is a problem or a bug, I have all the fpc tools to fix it because MSEgui is 100% Pascal. Using a external widget-set (GTK or Qt), if there are problems inside the widget-set, I will not have access and I have to cry in the GTK or Qt forums to get a maybe later solution. Fre;D ---------------------------------------------------------------------- funlw65 · 2021-01-05 06:40 Quote from: Fred vS on January 04, 2021, 06:41:13 pm... What is sure, is that, with the applications that I have done with MSEgui, I have total control. If there is a problem or a bug, I have all the fpc tools to fix it because MSEgui is 100% Pascal. Using a external widget-set (GTK or Qt), if there are problems inside the widget-set, I will not have access and I have to cry in the GTK or Qt forums to get a maybe later solution. Fre;D Exactly! That is where memory leaks and crashes will go away! And even more, wee all see that we always work with a widget set that is at the end of the road and we name this (rightfully so) a stable solution. Then in time, we face the exclusion from linux distros of that widget set... every single time. With a 100% pascal solution we are not at the mercy of the linux distro packagers. ---------------------------------------------------------------------- dbannon · 2021-01-05 07:57 Quote from: Fred vS on January 04, 2021, 06:41:13 pmIf you are talking about custom draw feature, yes, MSEgui is a complete widget-set that competes (even wins) against other widget-set ténors, like GTK, QT, ... Hey Fred, MSEgui could be quite useful. All Pascal would be cool, no tracing issues back to brickwall libraries.  But where is the documentation ? I looked at https://wiki.freepascal.org/Reference:_MSEgui , MSEide MSEgui first step, https://github.com/mse-org/mseide-msegui, https://gitlab.com/mseide-msegui/mseuniverse - but everywhere, no user docs. Fred, please don't take offense, its obvious that a lot of work has gone into MSEgui, there has been nine and a half thousand commits !  But the documentation, especially the getting started just is not there.  I get very frustrated when very smart people put so much work into writing very good software and cannot find, maybe 10% of that time to document it ! If you want to get down and dirty with GTK2, GTK3, Qt5, Win32 .... you will find massive collections of docs, easy to follow getting started stuff, function by function description thats all nicely linked together.  MSEGue cannot be said to compete unless it has some effective documentation.  I know its not fun to write user docs and no one is forced to do anything in a volunteer project but if you expect a rush of users and, eventually contributors, you have to make a way for them to get in ! Davo ---------------------------------------------------------------------- Fred vS · 2021-01-05 11:55 @ funlw65 and dbannon: thanks for your constructive messages. About msegui documentation. A short description of mseide-msegui is here: https://wiki.lazarus.freepascal.org/MSEide%2BMSEgui There is some documentation for totally beginners and their first steps here: https://wiki.lazarus.freepascal.org/MSEide_MSEgui_first_step After this first steps, you may run. (msegui code is very clear and easy to understand). There are lot of demos and examples + documentation in mseuniverse: https://github.com/mse-org/mseuniverse And of course the msegui mailing-list to help everybody: http://mseide-msegui-talk.13964.n8.nabble.com/ If you would prefer a IDE compatible with msegui with more features, you may use ideU: https://github.com/fredvs/ideU/releases/tag/2.4.4 It has included the from designer of MSEide and can deal with the .prj project-files of MSEide. Fre;D ---------------------------------------------------------------------- devEric69 · 2021-01-05 13:14 Hello @Fred vS, Could you explain me \ us the link, if any, that exists between fpGUI and MSGUI? Are they complementary? If so, in what way, please? ---------------------------------------------------------------------- Fred vS · 2021-01-05 13:35 Quote from: devEric69 on January 05, 2021, 02:14:13 pmHello @Fred vS, Could you explain me \ us the link, if any, that exists between fpGUI and MSGUI? Are they complementary? If so, in what way, please? Hello Eric. fpGUI and MSEgui are widget-set written in Pascal that do not use external widget-set. Both provide an interface to win32 and X11. Each one has his own form designer, you cannot use GUI widgets from one to the other (afaik). Now about link, Martin and Graeme did communicate a lot together and shared idea and code. Personally I like both, fpGUI for his simplicity, ideal for single form applications and MSEgui for his docking feature and the huge number of great widgets. If you want to compare with "ténor" widgets, like GTK, Qt, Carbon, ..., imho, MSEgui competes with them and even wins (no memory leak, less memory needed, much faster, better GUI-synchro.) Fre;D ---------------------------------------------------------------------- devEric69 · 2021-01-05 13:56 Thank you for your answer @Fred, So, can I say, that for a single-window interface that moves all the time, with a lot of small clipped areas, to be invalidated frequently (without interactive visual controls), fpGUI "is enough" (do well the job) because it paints and manage memory there as well as MSEGUI? ---------------------------------------------------------------------- Fred vS · 2021-01-05 14:03 Quote from: devEric69 on January 05, 2021, 02:56:43 pmThank you for your answer @Fred, So, can I say, that for a single-window interface that moves all the time, with a lot of small clipped areas, to be invalidated frequently (without interactive visual controls), fpGUI "is enough" (do well the job) because it paints and manage memory there as well as MSEGUI? Yes, of course fpGUI can do this, and can deal with lot of windows, about single-window, I was thinking about no-docking forms. One great feature of fpGUI is his all-in-one-unit, no additional form- unit needed (like for LCL, Delphi and MSEgui). ---------------------------------------------------------------------- devEric69 · 2021-01-05 14:14 Understood. Thank you very much for your answers. And my deep respect for your (and Graeme's) work. ---------------------------------------------------------------------- dbannon · 2021-01-05 23:05 Quote from: Fred vS on January 05, 2021, 12:55:36 pm A short description of mseide-msegui is here: https://wiki.lazarus.freepascal.org/MSEide%2BMSEgui Thats what I was looking for, thanks Fred.  I have had a very good read.  I was looking for instructions on how to use MSEgui with Lazarus, I think I understand now that is not possible. When it says "start the ide" it means MSEide .... Am I right in saying that MSEgui is not a "plugin" (for lack of a better word) into Lazarus in the way that (Lazarus) GTK2, GTK3, Qt5, Wn32 and Cocoa is ??   I could not choose to build my Lazarus app using MSEgui in the same way I can swap between the Lazarus Widget Sets ? To use MSEgui I must use the MSEIDE ?   And, still guessing, re-write my app from scratch ?  Can MSEide read my Lazarus *.lfm files ?  The .mfm files appear to have a similar structure but use quite different keywords.  And I doubt there is a one to one relationship between individual widgets ? Thanks for you tolerance here Fred.  Davo ---------------------------------------------------------------------- Fred vS · 2021-01-06 00:06 Hello Davo.  Quote from: dbannon on January 06, 2021, 12:05:16 amI was looking for instructions on how to use MSEgui with Lazarus, I think I understand now that is not possible. You may, of course, use Lazarus IDE for MSEgui projects and use his editor and all the feature for the source but you will not be able to use the Lazarus-form-designer to edit the graphical MSEgui widgets. The same for MSEide (or ideU), you may compile and debug Lazarus-LCL projects but there is no LCL from-designer (at the moment). QuoteAm I right in saying that MSEgui is not a "plugin" (for lack of a better word) into Lazarus in the way that (Lazarus) GTK2, GTK3, Qt5, Wn32 and Cocoa is ??   I could not choose to build my Lazarus app using MSEgui in the same way I can swap between the Lazarus Widget Sets ? Yes, MSEgui is a pure widget-set that deals directly with the low level graphic interface installed. It is similar to GTK2, GTK3, Qt5, Win32 or Cocoa. (With the great difference that MSEgui dont need to install any dependencies and can work on a "Pure X" OS, without any widgetset installed.) There is, at the moment, no conversion tools LCL <> MSEgui. QuoteTo use MSEgui I must use the MSEIDE ? For all graphics stuff, it is easier to use MSEide and his form- editor, the object inspector and the components palette (same idea as Delphi or Lazarus).  Quote And, still guessing, re-write my app from scratch ?  Can MSEide read my Lazarus *.lfm files ?  The .mfm files appear to have a similar structure but use quite different keywords.  And I doubt there is a one to one relationship between individual widgets ? I fear that for all the graphic part it will be easier to do it from scratch (but once you get the MSE-trick, it goes very fast). And, of course, you may keep and import all your methods, functions and procedures. I never try to import  .lfm files, maybe it is possible, I dont know.. One great feature of MSEide is that you may run how many instances you want and copy some widgets of a form from the form-designer of one instance (Ctrl+C) and paste it (Ctrl+V) on the form of a other instance. QuoteThanks for you tolerance here Fred.  You are more than welcome and thanks to give interest to that marvelous MSE project. Fre;D ---------------------------------------------------------------------- Handoko · 2021-01-06 04:14 Quote from: funlw65 on January 03, 2021, 05:10:05 pmQuote from: marcov on January 03, 2021, 04:49:28 pmCustomdrawn will face constant challenges of being non native, and as soon as development slows down will look outdated too. It is as thankless a job as adapting a new GTK. There is simply no longterm stability in the *nix GUI world. If it looks like Fusion Qt style and has light and dark themes it works for me, no matter the OS and the current theme of that OS; I just tested CustomDrawn, it has a lot of draw styles: dsAndroid, dsExtra1..10, dsGNOME, dsKDEPlastique, dsMacOSX, dsWin2000, dsWinCE dsWindows7, dsWinXP. But I can make it works only on dsWinXP, dsMacOS and dsAndroid. And it does not have dark theme, at least I cannot find it. But the code is property written and well-organized. Adding a new style doesn't seem too hard. For example you can open the file CustomDrawn_WinXP.pas then you will know how it applies the style. Below is the same code running on Win7 and UbuntuMate. Looks pretty similar but the text is a bit larger on UbuntuMate. I used the default fonts. ---------------------------------------------------------------------- funlw65 · 2021-01-06 06:32 It looks promising! As for dark themes, I always found LinuxMint LMDE4 Cinammon dark themes to be extremely elegant. ---------------------------------------------------------------------- trev · 2021-01-06 10:30 Re: https://wiki.freepascal.org/Reference:_MSEgui#TLayouter This section needs some proper formatting - it looks like it was a cut and paste into the Wiki which went badly. I fixed a couple of tables, but as for the rest... someone who knows what it is meant to mean needs to take a look and fix the formatting mess. ---------------------------------------------------------------------- Fred vS · 2021-01-06 15:56 Quote from: trev on January 06, 2021, 11:30:15 amRe: https://wiki.freepascal.org/Reference:_MSEgui#TLayouter This section needs some proper formatting - it looks like it was a cut and paste into the Wiki which went badly. I fixed a couple of tables, but as for the rest... someone who knows what it is meant to mean needs to take a look and fix the formatting mess. Hello Trev. Hum, indeed, it is more than not clear, I will ask to msegui mailing list. Your attention is highly appreciated. Fre;D ---------------------------------------------------------------------- trev · 2021-01-07 00:06 Thanks Fred - it's now actually readable