IUP GUI interface

[funlw65]

Considering that gtk+2 is gone and we have problems in gtk3, has anyone looked at IUP GUI interface written in C language over native APIs (Windows and HaikuOS)? Under Linux uses gtk3 and under some UNIXes uses Motif.

It's API is really easy to use and learn. In HaikuOS, to have native controls is a dream come true for it's pascal programmers. And it will ease the burden for the Lazarus LCL developers having only one API to care for (well, two, considering the first class citizen that is now qt5).

Currently, at 3.30 version (the most recent header-translated version for FreeBasic is 3.27 available in forums)

https://webserver2.tecgraf.puc-rio.br/iup/

[MarkMLl]

Does this bring anything to the party that isn't already provided by either Qt or fpGUI?

Does it stand any chance of surviving the transition to Wayland?

MarkMLl

[funlw65]

It looks native on any target system. No problem with Wayland for any X-Window dependent GUI library. Ask Fred but, in Windows no Wayland, in Linux/UNIX depends on gtk3,  Motif on other Unixes, and on HaikuOS native GUI, As you see, it passes to other frameworks the Wayland problem. And provides a single API for all the targets. 

It is like WxWindows, but that one looks the same on all systems. IUP looks native on the target system.

[PascalDragon]

Considering that gtk+2 is gone and we have problems in gtk3, has anyone looked at IUP GUI interface written in C language over native APIs (Windows and HaikuOS)? Under Linux uses gtk3 and under some UNIXes uses Motif.

I don't see a sense in a library that is yet another abstraction layer on the underlying system. But hey, feel free to implement a LCL Widgetset for that.

It's API is really easy to use and learn. In HaikuOS, to have native controls is a dream come true for it's pascal programmers. And it will ease the burden for the Lazarus LCL developers having only one API to care for (well, two, considering the first class citizen that is now qt5).

Lazarus will continue to provide multiple widgetsets and that exactly is the strength of that approach as it directly interfaces with that widgetset. With another abstraction layer one might come into situations where certain things are not possible because the abstraction layer does not provide for them (just like one sometimes needs to circumvent the LCL to access widgetset specific functionality due to the LCL not providing a suitable abstraction).

[marcov]

Also note that while applications designed to UIP guidelines look fine, that doesn't automatically mean that the LCL apps using an UIP backed also would look fine.

If something is not possible with the UIP widget, it may have to be emulated by owner drawing it, and then has again consequences for the resulting look and feel.

Like Pascaldragon, I see no benefit in this.