GTK has a new website
gtk.org
gtk.org
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.
[1] https://www.bleepingcomputer.com/news/security/kali-linux-ad...
[2] https://www.kali.org/wp-content/uploads/2019/11/kali-underco...
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.
Do you really want your app to look Windows-native? I can't think of any large app doing it precisely because the standard widgets are ugly.
Meanwhile I've seen GTK apps on Windows just using Adwaita, which I think looks very refreshing on there. You could use any other GTK theme as well.
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.
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.
Just grab the source for the settings app to see how it's done.
I don't think the core gnome/gtk folks have historically made use of glade, though maybe that's changing.
https://wiki.gnome.org/Projects/GTK/Inspector
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'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.
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.
I think it's pretty strange that the code example widget defaults to showing JavaScript code, considering that C is GTK's native language.
* this disclaimer because yes I know that gtk was a originally a quick hack to avoid Motif.. that definitely changed by 2.0.
I don't really think that C being the native language has any significance in this case.
It's simply something that works everywhere and can easily have performant and ergonomic bindings for $your-favorite-language.
https://developer.gnome.org/gnome-devel-demos/stable/js.html...
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.
;)
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.
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.
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.
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.
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".
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 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.
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.
someButton.signal_clicked().connect (mem_fun (*this, &Handler::method);
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.
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.
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.
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/
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.
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).
1. It's a huge framework, not just a GUI toolkit. 2. It uses the not-really-C++ mechanism of signals and slots and a "meta-object compiler".
Thus, for example, wxWidgets - written in C++ - has bindings in Lua, Python, Ruby, Rust, Java, Javascript, etc.
By definition, not really. I can't be not-using GObjects if I _am_ using GObject introspection.
> Very few languages offer C++ interop.
bu they do offer Glib interop? I don't mind having a C API (for a C or C++ library), and modern C++ inside.
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.
Up front and center code examples are nice, and IMO works well.
The Rust-example would have been a running application on my machine, had I not already been in bed and reading it on my phone.
Good job!
I hope wxRust will catchup some day.
These are trending presentation libraries in iOS. Most of these have 500+ stars on github, and few have more than 2 K stars.
Feel free to contact me via sudeep at agicent dot com.
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.
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).
I hate to be dismissive, but did you rtfm?
Shouldn't there be some continuity between the examples provided on the webpage and tfm?
There doesn't need to be any further instructions on the landing page, though. Again, that's what the docs are for.
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.
PPS. Seems like I can reply again.
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.
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.