IUP – Cross platform C GUI library(tecgraf.puc-rio.br)
tecgraf.puc-rio.br
IUP – Cross platform C GUI library
https://www.tecgraf.puc-rio.br/iup/
41 comments
One big plus for IUP over wxWidgets is that API of IUP is very clean & easy to use compared to the complex C++ API of wxWidgets.
wxWidgets feels heavily inspired by Microsoft's MFC framework. That always felt clunky to me, compared to GUI toolkits like Qt and GTK.
This was indeed the case. In 1995. Since then just about everything has changed, but the idea that wxWidgets is MFC-like still refuses to die... Another common related opinion is that you have to use macros when using wxWidgets, which couldn't be further from truth since ~15 years (see
https://wxwidgets.org/blog/2023/05/are-macros-required-to-us...) but, again, old impressions linger.
Macros aren't the only thing that make wxWidgets like MFC. Things like using new but not delete on objects. The method and event names. The use of DCs in paint events. Etc.
Well, there is only so much latitude for naming the event (or message, callback, whatever) sent when a window needs to repaint itself. Qt has `paintEvent()` too and nobody calls it MFC-like AFAIK. IME people mostly think about event table macros when they say it.
I still find examples using the macros all over the place. It is unfortunate that is still the case...
Thing is, each OS has its own design language and conventions. Trying to make one UI look and feel great in all of them is doomed to fail and feel awkward in all of them.
So either make a UI for each OS or go your own way and have your own design language.
So either make a UI for each OS or go your own way and have your own design language.
What’s people’s opinion on Eclipse’s SWT? It is probably the most commonly used API that just wraps native controls.
IUP is very nice and easy to use, and it uses real native controls, which is a big plus. Compared to wxWidgets, being written in C, it is easy to create bindings. I maintain Go bindings for IUP core here https://github.com/gen2brain/iup-go.
I wish development is faster though, perhaps moving the project to GitHub could help with that. I would like to see modern tray support on Linux instead of legacy one, someone to finish Cocoa support, native table/list view control (it is on the TODO list), support for gtk+ 4, etc.
I wish development is faster though, perhaps moving the project to GitHub could help with that. I would like to see modern tray support on Linux instead of legacy one, someone to finish Cocoa support, native table/list view control (it is on the TODO list), support for gtk+ 4, etc.
It still has no support for OS-X.
I can understand the reason.
This library is made by Brazilian researchers working for an institute (very poorly) funded by the government. However, Apple machines are very, very expensive in Brazil and many other 3rd World countries, almost a luxury. Probably they're not affordable enough to many of those researchers.
However, not having a OS-X version is really a big obstacle for this library to be accepted.
I can understand the reason.
This library is made by Brazilian researchers working for an institute (very poorly) funded by the government. However, Apple machines are very, very expensive in Brazil and many other 3rd World countries, almost a luxury. Probably they're not affordable enough to many of those researchers.
However, not having a OS-X version is really a big obstacle for this library to be accepted.
I know a young programmer in Brazil who is running Linux on a 2000's laptop simply because they cant afford anything better. At the time I was ignorant of their import taxes and said I had a spare motherboard/cpu/ram combo and a laptop I could send them and they politely refused my offer stating they would go broke paying the import taxes. Sad situation.
Same problem in the USA with those Apple machines.
I love the idea, and considered using this for a side project, but ultimately went a different route.
The biggest issue for me was the somewhat constrained idea of "cross platform" it's working with. There was an attempt at a Cocoa port, but it seems even less active than the main project. https://github.com/ewmailing/IupCocoa
Ultimately, I decided that a careful addition of a minimal amount of C++ code to use wxWidgets was less kludgey than using a half-baked Cocoa port or coaxing IUP GTK to work with Mac GTK. I've been mostly happy with that decision.
The biggest issue for me was the somewhat constrained idea of "cross platform" it's working with. There was an attempt at a Cocoa port, but it seems even less active than the main project. https://github.com/ewmailing/IupCocoa
Ultimately, I decided that a careful addition of a minimal amount of C++ code to use wxWidgets was less kludgey than using a half-baked Cocoa port or coaxing IUP GTK to work with Mac GTK. I've been mostly happy with that decision.
One of my advisors studied at puc-rio. Until early 2000's they had contacts with Petrobras (giant Brazilian oil and gas company) and SGI. We had some beautiful, exotic and powerful Silicon Graphics workstations in our labs: O2's, Fuel, 230... And people developed some impressive UI's like the ones available in the tecgraf section of https://www.tecgraf.puc-rio.br/iup/en/screenshots.html .
Also there was some pressure for us to use IUP. We always had a "not as maintained as gtk or qt" feel and as much as we could, we refused it. I think nobody regrets that.
Also there was some pressure for us to use IUP. We always had a "not as maintained as gtk or qt" feel and as much as we could, we refused it. I think nobody regrets that.
IUP has been around for ages and is usually used as a lightweight alternative to wxWidgets and Qt when you want native widgets. It has a stringy interface and the fully stylable non-native widgets starting with "Flat" in the name are a bit quirky, but it's overall very stable and has proved its usefulness over time. IUP often has bindings to languages when wxWidgets has not and Qt would be too bloated.
IUP is well designed, source code is clean and easy to read and it is easy to create bindings for it.
No overusing of weird macros, no large structs to define (IUP uses void pointers) or other C-isms that can be hard to translate over language barriers.
I tested to write bindings for PHP over FFI and it was trivial.
Main drawback is that the Mac support is experimental.
No overusing of weird macros, no large structs to define (IUP uses void pointers) or other C-isms that can be hard to translate over language barriers.
I tested to write bindings for PHP over FFI and it was trivial.
Main drawback is that the Mac support is experimental.
It appears to be a requirement that all C/C++ UI libraries have old, crusty looking visuals.
It uses native GUI widgets. Some of those screenshots are ancient. But also it only binds a least common denominator subset of widgets, so applications will lack many of the niche widgets and layouts that platform-native applications often use to keep a fresh look & feel.
It's about time we rediscovered 3D UI like SGI IRIX had 30 years ago and remix it with what we've learned in information presentation since. WebGPU? I want my cyberspace and I want it now!
https://en.wikipedia.org/wiki/Fsn_(file_manager)
https://en.wikipedia.org/wiki/Fsn_(file_manager)
It's A UNIX System!
That's mostly due to them wrapping native widgets. They couldn't have known windows would effectively stop updating Win32 and reinvent the wheel like 5 times.
This sort of toolkit tends to look ok on macOS where that degree of insanity didn't happen.
This sort of toolkit tends to look ok on macOS where that degree of insanity didn't happen.
"Old" isn't necessarily bad. If you want productivity over fashion, older styles are often better. They are more mouse-friendly and easier to understand, as buttons actually look like buttons instead of faded flat stickers.
The toolkit itself is at least twelve years old, so there's that.
I've been meaning to give Motif a try for cross-platform C GUIs. Can anyone share their perspective with that, and compare with IUP?
How does this compare to GTK in terms of features?
Maybe somebody can use it to make the state-ful GUI browser that the "office" industry sorely needs so we don't have to force DOM to act like a real GUI (which it does painfully and poorly). GUI's and mice do most the real work; let's not give all the standards attention to web toys and mobile.
Maybe somebody can use it to make the state-ful GUI browser that the "office" industry sorely needs so we don't have to force DOM to act like a real GUI (which it does painfully and poorly). GUI's and mice do most the real work; let's not give all the standards attention to web toys and mobile.
PUC RIO keeps winning. Among other victories is the language Lua.
ah, yet another "cross-platform GUI lib". I've lost track of how many have been created by now, briefly became popular then accumulated warts or got abandoned. any day now we'll solve it for sure this time. haha :-)
kids, get off my lawn
(doing curses work lately because its been reasonably stable and cross-platform for 30+ years now...)
kids, get off my lawn
(doing curses work lately because its been reasonably stable and cross-platform for 30+ years now...)
Neat a canvas lib that has support for fonts, clipboard, and printing:
https://www.tecgraf.puc-rio.br/cd/
https://www.tecgraf.puc-rio.br/cd/Any pictures of what the windows will look like?
Basically the same as a standard Windows app. I only have Win 10 on my work PC, but if I compile the examples PLUS a manifest (or the #pragma to do this) it is comparable to the Microsoft apps:
https://raw.githubusercontent.com/PennRobotics/permalink/mai...
Since the same UUID in the manifest applies to Windows 11 and Windows 10, I'm willing to bet this would look a lot like the Windows 11 version of notepad.exe when compiled on a Windows 11 machine.
https://raw.githubusercontent.com/PennRobotics/permalink/mai...
Since the same UUID in the manifest applies to Windows 11 and Windows 10, I'm willing to bet this would look a lot like the Windows 11 version of notepad.exe when compiled on a Windows 11 machine.
There is a 'Screenshots' navigation on the side bar under the Product group. Here's a direct link though the page is set up to act like a single page app:
https://www.tecgraf.puc-rio.br/iup/en/screenshots.html
It looks like a hodgepodge of MS Windows look & feel from the Windows 95 to the Windows XP eras, combined with some even more basic looking controls.
https://www.tecgraf.puc-rio.br/iup/en/screenshots.html
It looks like a hodgepodge of MS Windows look & feel from the Windows 95 to the Windows XP eras, combined with some even more basic looking controls.
IUP uses native GUI widgets and has been around for decades as is evident by those screenshots, some of which clearly were taken on some rather old versions of Windows.
You can check the screenshot from Windows 10 here https://github.com/gen2brain/iup-go/blob/main/examples/sampl.... If you are not using the manifest it will not follow the system appearance and will always look like Windows XP Classic.
Looking online, it looks very 90s/2000s.
Which might be a good thing for someone.
Maybe it is from 2000s? I see they link to "sourceforge". Which is 2000s thing to do.
Which might be a good thing for someone.
Maybe it is from 2000s? I see they link to "sourceforge". Which is 2000s thing to do.
I get it, this might be cool. But, it's a UI library! And there's no screenshot on the main page or the overview tab. Guys, come on. Screenshots should be the first thing we see.
> And there's no screenshot on the main page or the overview tab
On the overview page there is a link called "Screenshots" and I clicked on it and it does really show screenshots.
On the overview page there is a link called "Screenshots" and I clicked on it and it does really show screenshots.
Why do many (G)UI libraries hide their look & feel to some obscure location? If you want to make an impact, show us what you got on the landing page!
Edit: found the pictures. Looks like another GUI toolkit emulating the 90s OS style paradigms.
Edit: found the pictures. Looks like another GUI toolkit emulating the 90s OS style paradigms.
That means that the advantage is being able to write against one API, and get cross-platform compatibility, which can be nice. It also means (typically) being limited in what you can do to the least common denominator, or you (=the toolkit author) end up having to re-implement features from one platform that you want to expose but that are missing on some supported target(s). Or, of course, have an API with non-portable parts in it.
In any case, it means the "look and feel" is not the core feature of the API since that is going to be "like the target platform" and that is the point.
Given the origin, I guess Lua support is important too, here.
[1]: https://www.wxwidgets.org/