I was playing with Glade the other day and it is quite a nice but also hard to get into. I wish there were more examples. I'm try trying to replicate some things I see in the GNOME settings app already, but I can't quite get it.
So - more Glade files as examples would be really helpful! Apperantly, most GNOME apps don't use it,not I just can't find the Glade source files for them.
But I guess the fact that the tutorial link brings you to a tutorial which doesn't work with the Glade version in the screenshot already gives away that glad might not be first priority.
You can use the GTK Inspector to look through an open program to see what widgets it uses. It should be easy to understand if you're familiar with the Chrome/Firefox debuggers.
What you'll find is that several GNOME apps use separate widget libraries like libdazzle and libhandy to get their look-and-feel. These aren't necessary, but they may save you some work to make your program feel a little bit more GNOME-like.
I used to work with Glade all day everyday for my day job in 2002-2004... I ended up doing a lot of the development in the xml files generated by the Glade UI.... Later as I was integrating Gecko into our desktop app to display help content I came to the realization that XUL and then HTML was equivalent just had more developers focused on it... So today I still view native app development from the sense that HTML is just a markup language for describing UI... and a lot of very talented engineers spend everyday from multiple organizations fixing bugs and improving the UX/UI performance and stability... making HTML the best (IMO) native app development environment... Of course, I still love exposing C++ components into my UI but the need is far less than in 2002-4...
I'll miss the old gtk.org... spent countless hours on that site... the gnome c interfaces will always be near to my heart... Love the new design though that looks great.
> I'm try trying to replicate some things I see in the GNOME settings app already
It still baffles me that System Monitor uses real-time charting that is made entirely out of DrawingArea's and there aren't any good charting components in GTK period.
Perhaps because you're using Windows, to begin with.
GTK talks of native look-and-feel, but it's very poor at Windows look or feel. I have evaluated GTK for building apps that would be primarily used on Windows, and I gave up in short order after trying quite a few themes (ones trying to be like Windows 7, 10/Win32, 10/UWP, &c.). They were uniformly woefully bad for both look and feel, on my high-DPI environment. I got the impression some of them would have been better on a low-DPI device, but every last one of them would still have been bad in various serious ways. It always started with the title bar looking and behaving completely incorrectly, so GTK apps on Windows that want to look not awful start by telling GTK to let the OS draw the title bar. Then you get your file picker modals; and things like Inkscape drop GTK on the floor there, and call the Win32 API instead, on Windows.
And all this is fairly typical if you want it to feel native.
My biggest objection to Adwaita is that it’s awfully wasteful of space, especially on its buttons. As a particularly serious example, on my effectively-1500×1000 laptop, running the Inkscape 1.0 beta with its Win32 theme instead of Adwaita roughly doubles the canvas size available, assuming one sidebar open. (For more info about this, including also the woes of Inkscape’s Win32 look and feel—and Inkscape is honestly one of the very best GTK apps for nativeness on Windows, though this 1.0 beta has various regressions—skim through https://gitlab.com/inkscape/inbox/issues/879 .)
For starters, I think you’re underreckoning how many things look platform-native on Windows. To be sure, increasingly many things forsake it, primarily software using web tech to render, but there’s still a lot out there that’s fully native look-and-feel. And then there are degrees and degrees of native appearance—and what the definition of native is has shifted a couple of times over the course of the last two decades in Windows (the first form I have in mind will look different on XP, 7 and 10 from the same code, but I’m counting all those styles as one type of native). Anything that draws its own title bar is on thin ice, it’s probably doing the wrong thing, though it can be carried off well. (Office does it well, Chrome OK, GTK apps where they draw the title bar uniformly badly.) And then there are other widgets like dropdowns (<select> in HTML parlance) where GTK ones just behave in the wrong way, file pickers that are unfamiliar and don’t work right, &c.
Oh yeah, GTK apps seem to typically be pretty bad at high-DPI on Windows. The GIMP handles its canvas scaling (i.e. the definition of “100%”) incorrectly, but has no other major issues; Inkscape has major issues (see the earlier link); EasyTAG has major issues that can be mostly worked around by overriding Windows’ treatment of it (and 2.4.3 made its appearance even worse, but fortunately (?) I had to switch back to 2.4.2 because 2.4.3 is basically completely broken (https://gitlab.gnome.org/GNOME/easytag/issues/5), and no one seems to care); those are the only three GTK apps I have at present.
I only use Windows at work, so I don't know that many apps. Today I tried out gitg, a GTK git client that has a Windows build. Damn, it feels great.It ues the Adwaita theme with a client side header bar, which looks great, saves space over all and is only marginally thicker than any other Windows title bar (it even shows the dragging cursor when dragging, why the absolute does Windows not do this).
Touchpad scrolling isn't smooth, which is a little bit sad, but generally I'm surprised by how well it works. From what I can tell scaling works perfectly and the file picker, which is not the native one, which is great, because it's less awful, seems to work well with the file system.
Over all it's one of the Windows apps I hate the least - by staying as far from the platform as possible, UI wise.
It feels a bit weird that this is coming from someone who likes to complain about GNOME.
I don't think that's strange at all. Having JS as your example has the potential to lure in a huge pool of developers who have no idea that this is even an option for GUI development in JS. On the other hand, C developers are almost certainly already aware of GTK.
I don't really think that C being the native language has any significance in this case.
No this seems appropriate. And isn’t too far off from project ideals. The somewhat retconned* argument for using C for GTK+ was that it was the most easy to produce bindings for. This was in the FAQ years ago as a mild discouragement from actually using C to produce apps. The verbiage was something akin to C is a library language not an application language. But this goes back nearly 20 years.
* this disclaimer because yes I know that gtk was a originally a quick hack to avoid Motif.. that definitely changed by 2.0.
That example lead me exploring how to build GTK app with JavaScript. Not sure how it compares to Python or Vala performance wise, but now I can quickly build simple apps with GUI for my own use.
Here are some resources, if anyone else is interested:
C is the native language because it's the lowest common denominator, not necessarily because they want everyone writing their front-end applications in C.
It's simply something that works everywhere and can easily have performant and ergonomic bindings for $your-favorite-language.
They’re trying to cater to people who would otherwise select Electron or something, assuming that it is impossible to get a cross-platform GUI written in JavaScript without bringing all of Chromium along with it.
What's going on with that app icon carousel, though? On mouse-over it shows the link cursor, but nothing happens when you click the icons.
The feature list could also use some editing. I'm not sure what "enticing features" and "superb performance" have to do with "stability", and there is some random capitalization here and there.
Nit: the blue header background took a while to load. Since there’s no `background-color` set, the white text on white background was really hard to read.
Under Apps Built with GTK, I'd like to see something more than Gnome utilities and GIMP. How about adding Inkscape and SolveSpace? I'm sure there are more large apps using it.
Maybe it's a rearranged version of "Create interfaces, users just love that". i.e.: users just love interfaces, or users just love when you create interfaces for them. If that's the meaning, I think it may be correct, but I'm not sure.
I have only ever built for mobile or web. What is the state of affairs on desktop? What are the options for building for desktop? If I wanted to build an app targeting Mac, can I use gtk? Has anyone here done a gtk app with Rust? Generally know very little about the desktop world, can someone enlighten me?
I personally very much dislike Gtk. Other than the prominent example which is the much-maligned (and justly maligned) GNOME, there is the fundamental design feature: It is based on the Glib library - a C-language object system. That's rather outdated, and IMHO makes Gtk like a piece of candy with a rotten core.
What it has going for it is that Qt, perhaps the second most popular cross-platform GUI toolkit, developed on top of C++98 and had a lot of functionality to fill in for libraries missing for the language - which by now are outdated and have standard or more-popular alternatives.
(Actually, Glib is also somewhat like that in some respects.)
Caveat: I'm the opposite of an authority on writing UI code.
The nice thing about GLib/GObject is that you can use it from any language that has C interop, which is practically every language.
And that works even better now with GObject Introspection, which provides a generic way to access any GObject-based library from any language (kind of like COM's typelibs or WinRT's projections):
https://gi.readthedocs.io/en/latest/
I write a "major" app that uses GTK (via Gtkmm, the C++ language binding). We don't use GObject for anything that isn't already a part of GTK. Put differently ... if we implement or extend a widget, it will necessarily inherit from GObject. But if we implement our own non-GUI objects, we just ignore GObject entirely.
Well, I also want to use my own language's objects, and GObject Introspection enables that.
With a library written in C++ I can't do anything from most languages. Very few languages offer C++ interop.
What language would you suggest the platform GUI library should be written in if not C? You can't use Qt's C++ objects from Java or Swing's Java objects from C++, but both can call C.
You can - and do - use Qt's C++ objects from Python in a very native way, as though they were just ordinary Python objects. I would imagine the same would be the case when using Qt from Java or any other language that offers bindings. And since C++ with its class system is a widely adopted standard (for good or ill), there is at least some appetite for offering good bindings to object-oriented C++ libraries among the wider community, and any improvements or techniques there will generally cross-pollinate to improved bindings for Qt and vice versa.
In theory GObject is intended to be a whole parallel OO ecosystem, a better way of doing objects in C-like languages that can compete with C++, and that would ultimately give rise to a whole platform of things like Vala that interop with that platform. However that whole ecosystem just hasn't caught on; outside of Gnome, no-one is using GObject, no-one is using Vala, and so no-one else is interested in working on bindings between other OO languages and GObject (which have to solve much the same problems as bindings between those languages and C++ - GObject may be "C" but it relies heavily on macros, and to bind it in a usable way that makes it feel native in an OO language you have to do a lot more work than just exposing C functions as functions).
There is a reason there aren't any close to complete bindings for other languages except python for Qt5. It takes significant effort compared to binding to Glib/Gobject especially with gir.
I don't have experience with GTK and I stopped working on Desktop apps since 4 years ago. If you target Mac users only then use the Apple tools, if you target Windows only I would use .Net (C# and WinForms or WPF) for cross platform depending of the target users I would use Qt or Java.
My choices are more on what is better for the user and not on what is cool for the developer. Also if you have a small tool that the user will use it a few minutes he will not complain about it's look the functionality is important. As an example the games Sims 3 runs on Windows and Mac(not the latest Catalina) and community made tools for cleaning save files. Most popular tool was .Net and Windows only but someone made a Java tool that was cross-platform, the users were happy/great full and not entitled to demand profesional looking GUI for such a tool.
My advice , if you need a simple UI, buttons, labels, inputs then you should use the thing that has the best support for the language and platform you target. If you need to embed a uptodate webview or a video player or you need to draw graphs, customize widgets then you need a different tool.
If you can provide what you need in details, what platforms, languages and features you need then people could help eliminate the bad choices.
I've been working with GTK for a cross-platform app for 20 years (actually cross-platform for 15 or so). I've had the opportunity to have fairly deep interactions with people who've used Qt for similar projects.
The reality is that if your app is substantive in its GUI requirements, then neither Qt nor GTK will entirely shield you from platform specifics, and both of them will fall down in some situations (a little different for each toolkit).
Historical note: I decided to use GTK and not Qt because in the 1990s, Qt, despite being written in C++, was incredibly non-C++-idiomatic. It had its own string class, and required a Qt-provided pre-processor to be run on your code to get their signals/slots mechanism to work (think "anonymous callbacks"). GTK, by contrast, had a C++ binding that fully embraced the power of the C++ of the time. At this point, this difference between them has largely gone away. Qt has far more in its toolset to help people design and build apps, but when you get down to what they can actually do at runtime, there's not a lot of difference.
My one outstanding gripe about GTK is that the initial "G" used to stand for GIMP (it was written to support the development of that application), but now stands for GNOME. This doesn't ruin GTK as a general application toolkit, but some of the design decisions (at several different levels) do reflect its status as the "GNOME Toolkit" rather than a totally platform-agnostic GUI toolkit.
> I decided to use GTK and not Qt because in the 1990s, Qt, despite being written in C++, was incredibly non-C++-idiomatic.
Yeah, but there were good reasons for Qt to do that, I think that is just a taste thing, when you want to make an application that works the fact that Qt has a sane string,vector, signals is a plus(you did not need boost or third party code) , coming from Java or .Net Qt feels right.
For GUIs I did not hit cross platform related issues. I think I had to re-arrange some menus depending on OS but not to use native code. The only time I had to use some native stuff and I had to include windows.h was because I needed to on a multi screen setup to get each screen dimensions and at that moment this was not implemented or bugged(I do not remember).
About GTK, I strongly dislike the fact they are using their own File Chooser dialog and not the native one and that you can't customize the sorting order in it, especially on GTK2. So I have a few GTK2 apps and I always find it hartd to find my files because n how them are sorted , though in GTK3 I found a config options to change it a bit.
I would still use GTK if the problem to solve would require Python and a simple GUI like ask the user for a name, to chose a file, input some text. show an image and it is a Linux tool only.
About GNOME I agree, it could be possible in future GTK won't officially support menus, tray icons and other things that GNOME does not want.
There were no reasons for Qt to do that back in the day. Its string class had just as many issues as std::string, and libsigc++ showed how to do signals without a pre-processor. They just didn't want to do the work (then) ... now they have, and it's all just fine.
I contributed some significant fixes for GTK on macOS (OS X) support, all of them based on our experience with it. What's there now still has a few fundamental issues (often caused by fundamental differences in basic concepts within Cocoa versus X), but it's in much better shape than it was in 2004. My interactions with people doing Qt-on-macOS suggest a similar level of pain there too, which is to say "not much if your app is straightforward, but irritating if it has special needs".
Was that string support cross compiler or only gcc and mingw ? AFAIK you can't do signals with standard c++ until after C++ 14 and you need to keep in mind that Qt is used in automotive industry too so they probably don't have latest features there.
Nevertheless if you use QString then you can populate QVector with it and you can then assign the collection to a QList and you got lots of benefits, the only thing is if you have to use some external library you need to convert the string or char[] to a QString. I never had a case where I was thinking "damm I would like to use the native string or I would like the moc did not exist, who is bothered by moc ? distro packagers ? some mixed projects ? some standard c/c++ project that would like to consume Qt libraries?
What I really missed in Qt is a builtin simple way to create installers for Windows and Mac and a builtin way to do self-updating for Win and Mac. File size for Mac was also a complaint the qt apps received (I do not remember exactly how I was bundling them).
At my work they disliked Qt and I had to use Adobe AIR, I hated it at first but after a while I think at that moment in time it was the right choice, it was cross platform, easy to update, no more segfaults, good stacktraces that I can log and then use to fix bugs.
I still do not know why you object to moc? If is a practical or ideological reason. I also don't like magic in my tools, code that is generated behind me but with Qt I never had issues with it(not like other tools where the magic code crashes and you have to understand what happens under the hood to figureout the problems).
I did not used GTK seriously so I don't know how it's introspection and signal/events compare with Qt, are those as safe and easy to use? Is it easy to have collections of objects/strings and then use them in list/tables/trees? Trying to find examples i see a lot of C pointers and C function calls that seem to me very unsafe and ugly, something that would work fine for a small project but a pain for larger projects.
Anyway I am not trying to sell you anything , I want to understand better what is wrong with moc in your opinions(have you used Qt in a serious project?) and we can learn from others experience.
I don't like to have adjust my build systems to run an additional pre-processor over my code when there's no actual requirement for it. I don't want to have to deal with code I did not write appearing in the middle of code I did write.
GTK is written in C. Gtkmm is written in C++. Totally different. Gtkmm's signal/slot system is better than the original one in Qt. I haven't looked at Qt's current system in quite some time.
Many variations to allow binding, argument hiding, return value hiding and all the usual stuff.
Gtkmm has several display widgets that use a model/view paradigm, and let you define your own model and then map that to the view. If you literally just have a bunch of strings, there's one specifically to handle that situation.
I haven't used Qt myself but have worked in close collaboration with people who use it a lot.
OK, so your problem is that moc is an extra build step. but is this for aesthetic reason or why?
From my Qt experience you never see the moc code when you debug your applications. The only way to avoid moc would be to use heavy templates or macros and those also generate code behind your back.
I did not heard of GTKmm so I will check it out to find out more, thanks.
Qt has a company behind so is more professional, better documentation, better cross platform support, less bugs.
This video https://www.youtube.com/watch?v=ON0A1dsQOV0 is about the reasons Subsurface (a diving app started by Linus Torvalds) changed from GTK to Qt. Things might have improved from GTK I can't tell and also for simpler GUIs GTK might be enough.
Transmission is an interesting case, since they also have a version in Qt. Another example of an almost identical app written on a completely different platform would be the Fork git client with Cocoa and WPF.
I wish someone would build a GUI markup language and "browser" based on GTK. We need an interactive markup language for GUI's and GUI-centric behavior. Forcing "the web" to act like a desktop takes way too many layers to be reliable over time.
Make desktop-like apps great again! Webatizing everything proved a mistake, unless you have deep dev pockets. Time to re-group.
Side note, GTK seems to lack a direct editable "data grid" widget with expandable columns. On a typical data grid, you can drag a column border to expand or reduce column width. It's a common need for data-centric CRUD apps. There are work-arounds, but they are awkward.
The website is working well on mobile, which makes me wonder if GTK has plans to support Android and iOS. It would be nice. GTK has been multi-platform for a while.
There was recently a forum thread where this was asked and the answer is no [0]. I don't think there is much incentive to do this either because last I heard the app stores on those platforms still have agreements that are incompatible with the LGPL [1], which means you can't use them to distribute GTK programs.
Slightly off-topic, but does anyone know if there are adaptations of GTK out there that are usable on embedded? I.e. full-screen EGL-based apps, like Qt Embedded.
Somebody nearby mentioned that if it could (optionally) use a native OS file picker, then that problem might go away or be reduced, assuming one can control the viewing mode to switch the native one to show thumbnails.
Hope you don't mind some criticism. I'm kind of a n00b...
How do I actually run the code examples that you've provided?
For example, I started a new Cargo project and pasted the Rust example provided into my main.rs. It failed compilation. Should I have added a few dependencies to my Cargo.toml first? Should I have upgraded Rust first?
I upgraded Rust, btw. And added lines to my Cargo.toml. No bueno. Now, I have to go hunting elsewhere for answers.
A few extra lines of instruction would definitely save the thousands of developers who're bound to get stuck.
The samples are only there to give one an idea of how one would access GTK from within certain languages — or maybe how easy, painless (?) it can be to use.
It is expected that one would know how to properly add dependencies — and if they did not, they should go read the documentation (from the 'Docs' link at the top of the page).
This is terrible. Even the example on the documentation page doesn't work. One has to go to the issues page on github for gtk-rs to find that the documentation in its current form is incorrect.
So, neither the example on the page nor the documentation work.
How desperate should one be to want to use GTK? Is this some kind of an initiation?
PS. I can't reply to this thread any further.
I'll concede that I may be making a mistake copying and pasting things, but I've checked a few times. If the job of the documentation is to help, then it should address situations where people get stuck.
At this stage, the new gtk webpage feels akin to putting lipstick on a pig.
We're just taking your word for this. For all I know, you're making some mistake or skipping some step and blaming it on the documentation.
I'm not sure if you're implicitly wanting us to diagnose your issue for you without providing any actual information, but seeing as I have no idea if you have GTK properly installed, the headers in the right place, or anything else like that, I can't help but be sceptical that the documentation isn't up to snuff.
Oh, I didn't realize I had to install GTK separately - that I couldn't just include the libraries in my Cargo.toml and hope the compilation would do it.
So, I went to part of the GTK Project page where it provides examples on how to install GTK for Mac (https://www.gtk.org/docs/installations/macos/) and clicked on the installation script link under Getting Started. The installation script link is broken.
So - more Glade files as examples would be really helpful! Apperantly, most GNOME apps don't use it,not I just can't find the Glade source files for them.
But I guess the fact that the tutorial link brings you to a tutorial which doesn't work with the Glade version in the screenshot already gives away that glad might not be first priority.
It's still pretty good tough.