GTK 3.0 is now widely used in major Linux distributions. (ubuntu, mint) But the support in Lazarus for GTK 3 is still in alpha state.

Do we need GTK 3 in Lazarus? Or is GTK 2 good enough? Will Lazarus and applications build with Lazarus look better under GTK 3? (HiDPI support)

Is someone working on the LCL implementation of GTK 3? How difficult is it to implement GTK 3?

Regards, Erwin

Erwin van den Bosch wrote

Do we need GTK 3 in Lazarus? Or is GTK 2 good enough?

GTK 3 binding is needed.

Is someone working on the LCL implementation of GTK 3?

Currently not. We need more contributions.

How difficult is it to implement GTK 3?

Should be easier than GTK 2. The binding's design is better. Zeljko can answer detailed questions if you plan to improve it.

Juha

Sadly the GTK+ devs do not seem to care much about backwards compatibility and love to break stuff every other version.

Check this blog post which summarizes the issues
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/

IMO GTK+ 2 is the last good GTK+ version and hopefully someone (maybe the MATE devs) will fork it and add support for the needed stuff. GTK+ 3.0+ is not reliable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160712/d9a47627/attachment.html>

I knew about it (not about exact blog, but about abi/api mess) and that's main reason why I do not have enough faith to work on gtk3 bindings. Even gtk2 had ridiculous code in some cases (besides this ABI/API gtk3 changes). Just one simple example of gtk philosophy - look at GtkEntry class and ability to add icon into GtkEntry (gtk_entry_set_icon_xxxx since 2.16). eg. in Qt/WinAPI you can add any handle inside text editor (eg. QPushButton under Qt), but under gtk you're stucked to gdkpixbuf.
I really don't know what kind of drugs gtk devels are using.

zeljko

Op 12-7-2016 om 4:11 schreef Kostas Michalopoulos:

I have read enough! Forget GTK3 (and GTK4).

Quote: "Meanwhile, Gtk 4.0 will not be the final stable API of what we would call “Gtk 4”. Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it."

I was considering helping to implement the GTK 3 widget set in Lazarus but after some studies and reading I think we might better put our energy in the QT 5 implementation.

After 32 years of graphical desktops on Unix we still have no stable widget set! :-(

Erwin van den Bosch wrote

After 32 years of graphical desktops on Unix we still have no stable widget set! :-(

Yes we have. Qt.

zeljko

Erwin van den Bosch wrote

I have read enough! Forget GTK3 (and GTK4).

Yes, I also think they plan to break it too often. However I believe it makes the API better.
Honestly, GTK 2 is not a very good API.
This is about balance between keeping things stable and improving things. In Lazarus POW it is irrelevant because the bindings are needed anyway.

I was considering helping to implement the GTK 3 widget set in Lazarus but after some studies and reading I think we might better put our energy in the QT 5 implementation.

Yes, QT 5 bindings also need contributions.
Especially the C++ > C-library bindings (used by Pascal) issue must be solved. The earlier library was made manually and its author will not continue it.
A new solution should use one of the existing binding generators. Please subscribe to qt-lazarus mailing list if you are interested.

After 32 years of graphical desktops on Unix we still have no stable widget set! :-(

Xlib API is stable. The other widgetsets are also stable enough. Think of it, both Xlib and Win32 APIs have been stable for a long time. Which do you prefer:
1. Nice modern object oriented API which breaks sometimes to keep it clean.
2. Xlib and Win32 stable APIs for eternity.

I choose option number 1.

Juha

It is relevant: it costs time, better spent on other things.

Then why does Microsoft choose 2 ?
They could have elected to throw out Win32 when they came with .NET.

Luckily they did not, many companies would be forced to stay with Windows 95 or NT 4 or somesuch if they hadn't.

Stability of your API is of the utmost importance.

As an example:
The web APIs of some of Microsoft's online platforms have changed 3 times in the last 2 years. Each is slightly different from the next, and requires you to rework a lot of your code, for little gain. People have better things to do than keeping up with changing APIs.

Michael.

Erwin van den Bosch wrote

After 32 years of graphical desktops on Unix we still have no stable widget set! :-(

Yes we have, fpGUI.

And because fpGUI is 100% custom drawn, if a full featured LCL interface was implemented (an Alpha version already exists), you have full control over both. No need to wait for the next GTK2 or Qt4 release to receive a fix for the underlying widgetset that LCL uses.

Regards,
Graeme

Apple selects both. macOS / iOS frameworks keep evolving, While Carbon framework is still out there. I always keep my breath (and my fingers cross) with very next OSX release to see if Carbon is still available.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160712/3feadbfc/attachment-0001.html>

Juha Manninen wrote

1. Nice modern object oriented API which breaks sometimes to keep it clean. 2. Xlib and Win32 stable APIs for eternity. I choose option number 1.

I choose 1 also, me and everybody. Supporting backward compatiblity is a burden and sometimes you have to leave it behind to evolve. The discussion is what means "sometimes", once each 20 years? Software for Win95 still works in Win10, or once each 6 months? Like GTK.

In the link it's said that themes for Gtk 3.18 don't work properly in 3.20. Not even a mayor version. And it is not an bug, but a feature. That's crazy.

And now, Gtk developers promise six months incompatibility and a dozen of versions running up and down. The work like if they were maintaining a final software, like LibreOffice, not Library. That's crazy, I would like to see them programming if XWindows were protocol that changed each six months.

Let me put it this way, until they reach a stable version for a long time (5-10 years), this is will be a mess and people (and so distros) will stick on old versions. If they plan to never reach a stable version, people will stick on very old versions, and eventually they will move to another more modern tool, and that more modern tool won't be that week's GTK version. (People is already talking about QT)

Well said!

Hi Graeme and All,

And because fpGUI is 100% custom drawn, if a full featured LCL interface was implemented (an Alpha version already exists), you have full control over both.

How can I try it?

After many circles in the past I chose Qt for Linux because look more robust than GTK. But nowadays the distributions switching to Qt5 and Lazarus have Qt4 compability only.

Which is the good direction for concentrate the available resources (manpower) Qt5 or fpGUI. Graeme certainly say fpGUI. :D Others?

Foundation project for Qt5 binding or fpGUI LCL interface?

How big is the user base of Lazarus-Qt?

Gabor

Gabor Boros wrote

How can I try it?

The following wiki page should explain it well:

http://wiki.freepascal.org/fpGUI_Interface

Create a new LCL application. Drop a TButton and TEdit on the form. Go to Project Options -> Compiler Options. Then depending on your version of Lazarus IDE, look in “Additions and Overrides” and set the LCLWidgetType to “fpgui”.

WARNING:
Don't drop a TLabel on the test application, that will cause it to AV at runtime. TLabel might look simple, but according to LCL it is quite complex to implement and is not yet done for LCL-fpGUI.

Which is the good direction for concentrate the available resources (manpower) Qt5 or fpGUI. Graeme certainly say fpGUI. :D Others?

My theory was always that LCL-fpGUI (or any other custom drawn toolkit) should become the reference implementation for LCL. Why? Because it is 100% cross-platform, custom drawn and implemented in Object Pascal - it can support any LCL feature on all target OSes. Whereas with other LCL widgetsets, there are plenty of platform specific limitations. See the "Restricted" tab in the Object Inspector to see what I mean. I think there are others listed on the wiki too.

fpGUI is also the least resource intensive GUI toolkit that LCL supports, and with no extra [huge] libraries needed. This makes compiling, linking and deployment the least painful of the bunch. For example… just take a look at all the GTK2 and Qt *.so files and then include whatever 3rd party libraries they depend on. The list is massive!

Regards,
Graeme

On Wed, Jul 13, 2016 at 12:13 PM, Graeme Geldenhuys <

How does it handle an OS specific limitations?
For example:
* drawing outside of the paint event? Where some (Carbon, Cocoa) widgetset forbid that.
* platform specific mouse behavior. OSX ctrl+mouseclick should trigger popup menu (= right click)

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160713/19e69928/attachment.html>

Dmitry Boyarintsev wrote

How does it handle an OS specific limitations?

Because I'm in full control of what fpGUI can do, I can implement anything that is missing. The same can't easily be done with GTK2/3, Qt4/5, OSX etc.

For example: * drawing outside of the paint event? Where some (Carbon, Cocoa) widgetset forbid that.

fpGUI’s ‘develop’ branch allows that without problems because internally it uses AggPas to do rendering to a image buffer. The ‘develop’ branch also switched to a single-handle-per-form design, so the image buffer represents the whole form. The actual Paint event simply bitblt’s the image buffer to the actual OS window.

* platform specific mouse behavior. OSX ctrl+mouseclick should trigger popup menu (= right click)

Like I mentioned in the first paragraph - such functionality can be implemented because fpGUI is under our full control and is in the same language as what LCL is written.

It has taken me years, but fpGUI is very consistent across platforms now. I can (and have) develop any new widgets [or applications] no matter how complex (think Ribbon widget complex) under a single platform, and I know 100% it will look and behave the same on all other supported fpGUI platforms. No IFDEF’s code anywhere in the widgets or applications. This will help LCL consistency across platforms too.

Regards,
Graeme

On Wed, Jul 13, 2016 at 2:45 PM, Graeme Geldenhuys <

So what's more important - to be consistent and act 100% exactly the same across platform
- or feel more towards the native platform?

If I create a control that does something special with Ctrl+Left click, should it retain this functionality for OSX?
What typically happens: Cmd+Left click is used in OSX applications (where ctrl+click would be used for Windows or Linux).

Is it up to a control (to distinguish between Ctrl+Left click on Linux and OSX) or are there fpGUI APIs to control the system specific behavior?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160713/5648da52/attachment.html>

Dmitry Boyarintsev wrote

So what's more important - to be consistent and act 100% exactly the same across platform - or feel more towards the native platform?

That as always been the big difference [design goal] between LCL and [pure] fpGUI.

LCL believes “native” is better, but sacrifices consistency between LCL widgetsets - often leading to IFDEF’d code in LCL and in your application. It’s been like that 10 years ago when I first started using Lazarus, and is still the case today.

fpGUI believes "consistency" is better - producing cleaner code with no commercial environments it also makes cross-platform training much easier, and Windows and Linux systems can run side-by-side with no visual difference or behaviour using the same application.

With that, my argument [for the fpGUI design] is also that people use the web as a new platform. There is NO “native look and feel” for the web, yet nobody has any problems using web apps (Gmail, Office 365 and the millions of others). So why can people use the web (with no native L&F) just fine, but suddenly can’t manage with similar desktop applications. End-users are not as helpless (stupid or incompetent) as many claim. As long as a button acts like a button, a menu acts like a menu etc, end-users can use them just fine. fpGUI also has excellent theming support to simulate native L&F to acceptable standards. It includes about 8 themes
[http://geldenhuys.co.uk/~graemeg/themes/start.html], and creating new ones are a very quick and easy process.

On a side note:
There is NO “native” widget toolkit under Linux, FreeBSD, Solaris etc - XLib doesn’t supply a GUI toolkit. So native has no bearing on such platforms.

I can also throw in the argument that not even Microsoft or Apple adhere to their own Human Interface Guidelines - so why must we be that strict?

Pros or Cons, I still think having a fully implemented LCL-fpGUI widgetset would be very beneficial to the Lazarus project.

Regards,
Graeme

On Wed, Jul 13, 2016 at 7:24 PM, Graeme Geldenhuys <

Ok. What is the approach to Mobile platforms, where inputs are different from desktops?
Should there be a consistency with Desktop as well?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160713/ff27bd61/attachment.html>

Dmitry Boyarintsev wrote

What is the approach to Mobile platforms

fpGUI works on WinCE devices and other Linux Embedded devices. As for mobile phones - I don't believe fpGUI or LCL is appropriate for them. I would rather use the native mobile phone toolkits in that case.

Embarcadero's FireMonkey toolkit shows that customdrawn toolkits can be used to target multiple mobile phone OSes, but based on the people I spoke to, it is not ideal. So again, I would rather opt for using the native development tools and toolkits of each mobile phone OS.

Regards,
Graeme

I just took a quick look at your fpGUI Toolkit and I have to say I like it. At the first glance it seems to work very nicely. I especially like the idea that you have 100% control of the application.

I wasn't able to run fpgcanvas (runtime exception), nanoedit (didn't compile) and agg_canvas_test (runtime exception) demos but docedit and helloword worked.

How do you handle high-DPI displays in fpGUI?

Ondrej

Hello Graeme,
I just want to say I absolutly agree with you.
Thanks,
Sam

Von: Graeme Geldenhuys
An:
Gesendet: 1:24 Donnerstag, 14.Juli 2016
Betreff: Re: [Lazarus] GTK 3.0

Dmitry Boyarintsev wrote

So what's more important - to be consistent and act 100% exactly the same across platform - or feel more towards the native platform?

That as always been the big difference [design goal] between LCL and [pure] fpGUI.

LCL believes “native” is better, but sacrifices consistency between LCL widgetsets - often leading to IFDEF’d code in LCL and in your application. It’s been like that 10 years ago when I first started using Lazarus, and is still the case today.

fpGUI believes "consistency" is better - producing cleaner code with no commercial environments it also makes cross-platform training much easier, and Windows and Linux systems can run side-by-side with no visual difference or behaviour using the same application.

With that, my argument [for the fpGUI design] is also that people use the web as a new platform. There is NO “native look and feel” for the web, yet nobody has any problems using web apps (Gmail, Office 365 and the millions of others). So why can people use the web (with no native L&F) just fine, but suddenly can’t manage with similar desktop applications. End-users are not as helpless (stupid or incompetent) as many claim. As long as a button acts like a button, a menu acts like a menu etc, end-users can use them just fine. fpGUI also has excellent theming support to simulate native L&F to acceptable standards. It includes about 8 themes
[http://geldenhuys.co.uk/~graemeg/themes/start.html], and creating new ones are a very quick and easy process.

On a side note:
  There is NO “native” widget toolkit under Linux, FreeBSD, Solaris   etc - XLib doesn’t supply a GUI toolkit. So native has no bearing   on such platforms.

I can also throw in the argument that not even Microsoft or Apple adhere to their own Human Interface Guidelines - so why must we be that strict?

Pros or Cons, I still think having a fully implemented LCL-fpGUI widgetset would be very beneficial to the Lazarus project.

Regards,
  Graeme

Thanks for feedback.

Ondrej Pokorny wrote

I wasn't able to run fpgcanvas (runtime exception)

That works here. Tonight I’ll do some more testing. Which platform, fpGUI branch and FPC version did you test with? The “develop” branch is in flux at the moment as some large branches have been merged recently and I’m working on stabilizing the code for the v2.0 release.

If you want stability right now, then the “maint” branch would be your best bet.

, nanoedit (didn't compile)

Fixed, and the repository has been updated.

and agg_canvas_test (runtime exception)

As the demo’s unit header comment mentions, you need to explicitly enable the “AggCanvas” compiler define. At the moment AggPas is not the default 2D renderer yet.

How do you handle high-DPI displays in fpGUI?

It works just fine. Text, windows and widget size scale as needed. For graphics I recommend using SVG images with the “develop” branch. At the moment high-DPI support requires manually adding an extra unit to your uses clause, but the branch that automates all than (and improves high-DPI support even more) is almost ready to be merged into "develop".

Here are some screenshot samples of the same executable running under Windows 8 with various Windows DPI values set.

http://geldenhuys.co.uk/~graemeg/temp/Win8_96dpi.png http://geldenhuys.co.uk/~graemeg/temp/Win8_120dpi.png http://geldenhuys.co.uk/~graemeg/temp/Win8_144dpi.png http://geldenhuys.co.uk/~graemeg/temp/Win8_192dpi.png

Regards,
Graeme

MSEgui, most likely used with MSEide without LCL overhead.

Martin

For MSEgui:

The signature of the widget paint procedure is
"
procedure twidget.paint(const canvas: tcanvas);
"
Where "canvas" can be a window, bitmap or printer canvas. If twidget.paint() is called by twindow.update() - normally automatically when the main thread event queue gets idle - an intermediate bitmap canvas of the size of the updateregion is created for paint() which will be copied to the window handle at the end. This eliminates flicker in a platform neutral way. Calling paint() without a canvas is not supported.

* platform specific mouse behavior. OSX ctrl+mouseclick should trigger popup menu (= right click)

MSEgui does not support OSX directly currently but I am sure that I'll find an elegant and configurable way to show the popup menu by Ctrl+LeftClick instead of RightClick if necessary. ;-)

Currently the code is:
"
procedure tactionwidget.clientmouseevent(var info: mouseeventinfoty);
var
 dummy: tpopupmenu;
 po1: pointty;
begin
 if canevent(tmethod(fonclientmouseevent)) then begin
  fonclientmouseevent(self,info);
 end;
 inherited;
 with info do begin
  if (eventkind = ek_buttonrelease) and (ws_rclicked in fwidgetstate) and
             not (csdesigning in componentstate) and
             (eventstate * [es_processed,es_child] = []) and
             (button = mb_right) then begin
   dummy:= nil;
   po1:= info.pos;
   dopopup(dummy,info);
   info.pos:= po1; //no mousemove by change of popup pos
  end;
 end;
end;
"

Martin

On Thu, Jul 14, 2016 at 1:09 AM, Graeme Geldenhuys <

That seems a little bit odd to me.

It sounds like fpGUI (or any custom-drawn interface) is a good replacement for Qt5 in desktop Linux.
But for Ubuntu Phone, one should be using Qt5 instead.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160714/dd3de9db/attachment.html>

Op 12-07-16 om 09:18 schreef zeljko:

I think they are recovering from their drug-addiction right now.

Seems that some gtk-developers where on a hackathon where they discussed the instability-issues. And the fact that they don't like the situation that most gtk-applications still use gtk-2. (Gimp, Inkscape, Geany, etc, etc) So they came with a proposal and posted it online...

But - maybe - they had a little bit too much beer when they wrote it, with the result that no-one understood what they really meant. The blog above being one of the reactions.

But it is still a proposal, in the mean time discussed and improved a lot.

As it looks now, they will define 3.26 stable. Not 'just-a-little-bit' stable, but really stable. To be able to move forward, they will release 4.0. This version won't be stable until it reaches (by approximation) version 4.6. Then this will be the stable version (alongside 3.26) and they will start working on version 5.0...

This way you can choose as a developer to use the stable versions (3.26 -> 4.6 -> 5.X) or you can use the unstable versions, which could break compatibility every half year.

So for Lazarus it seems like we can finally do some serious work on the gtk3-port targeting 3.26 which will be stable for at least a few years.

More info, see among others:
https://wiki.gnome.org/Projects/GTK%2B/Lifecycle

Regards,

Joost.

16.07.2016 12:20, Joost van der Sluis пишет:

Op 12-07-16 om 09:18 schreef zeljko: > I really don't know what kind of drugs gtk devels are using. I think they are recovering from their drug-addiction right now.

It seems they just changed supplier. ;)

And stable releases will break every 2 years. ;) Stable API? Forget about it (nobody made any promises).

This is just an example of how premature blog posts about half-baked proposals made a PR disaster out of nothing.

Personally I hope that everything will be good. We need GTK3 widgetset.

Op 16-07-16 om 13:00 schreef Maxim Ganetsky:

Not exactly. They will introduce a new stable release every two years.

But you can keep using the older stable releases if you want. All major releases can be used parallel to each other. Like now is done with 2 and three, in the future also 4 and 5.
They think they will support a stable release for about 5 years, but could be longer, like they do now with gtk2.

Regards,

Joost.

People will stick on GTK2. And maybe after a some years in GTK3. People doesn't want to re-write their application. I don't think Gimp will be re-written for GTK3, and if it's re-written for GTK3 someday, it won't be re-written for GTK4 and latter for GTK5.

They are killing Gnome and GTK.

As I said in other message, What would GTK boys do if Xlib would rewrite its specification? They would have to dump GTK2, GTK3 and write quickly a new version. What if Xlib changed its specifications each two years?.

They are developers doing what they like, writing software once and once again to reach perfection, paying attention to nothing else. But that's not a program, that's a Library. What they are purposing is to let specifications in a permanent alpha state. And the result will be that no one will use it.

Yeah, personally i do not see a reason to move off GTK+ 2. If anything, in my system GTK+ 2 programs look and behave better than GTK+ 3 programs (which also tend to have a ton of visual glitches with broken themes). I just hope that someone will fork GTK+ 2 to introduce new features for working with the desktop environments and window systems (e.g. Wayland, HiDPI, etc).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160716/1e2fc02d/attachment.html>

16.07.2016 14:11, Joost van der Sluis пишет:

This statement is not supported by info from your link AFAICS.

Anyway, as I wrote:

"This is just an example of how premature blog posts about half-baked proposals made a PR disaster out of nothing.

Personally I hope that everything will be good. We need GTK3 widgetset."

Santiago A. wrote

People doesn't want to re-write their application. I don't think Gimp will be re-written for GTK3,

Indeed, and just shows the sad state of GTK3. Their primary application (the reason GTK was created in the first place - The Gimp) doesn't want to upgrade. That says it all.

Regards,
Graeme

On Mon, Jul 18, 2016 at 5:43 PM, Graeme Geldenhuys <

​Um...

The GIMP roadmap (http://wiki.gimp.org/wiki/Roadmap) shows a port to GTK3 ​

​being "work in progress" for GIMP 3.0​

This is either good or bad news - your choice!

Slainte
Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160718/4c83157f/attachment-0001.html>

Odds are that It will be ready when GTK 4.0 is out. So GTK 3 development will be almost frozen won't add new features of GTK 4, so Gimp won't be able to take advantage of GTK 4.0 new features, so it will have to be ported again to GTK 4.0.

GTK cycle is insane.

Il 13/07/2016 18:13, Graeme Geldenhuys ha scritto:

Create a new LCL application. Drop a TButton and TEdit on the form. Go to Project Options -> Compiler Options. Then depending on your version of Lazarus IDE, look in “Additions and Overrides” and set the LCLWidgetType to “fpgui”.

Following the instructions, I've tested. Lazarus = 1.6 Fpc=3.0.0 platform linux.
A blank form compiles and runs ok. The form shows the FPGUI icon. Adding a TButton, it fails with: "Class TButton not found" Adding a TEdit, it fails with "Class TEdit not found" Suggestions?

Giuliano