6 ms·

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 ta

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?

severine 7y ago
https://gtk-rs.org/ https://gtk-rs.org/
simion314 7y ago
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.
- xwowsersx 7y ago
  Thanks for the reply. Why does Transmission, for example, have a Mac app and a GTK app? They wanted a more polished Mac appaand gtk doesn't cut it?
  - kn0where 7y ago
    Yes, the Mac version of Transmission has a much more Mac-like UI that can’t entirely be replicated in something like GTK.
  - solarkraft 7y ago
    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.
  - simion314 7y ago
    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 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.
- PaulDavisThe1st 7y ago
  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.
  - simion314 7y ago
    > 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.
steveklabnik 7y ago
Newest hotness with gtk and Rust is https://bodil.lol/vgtk/ https://bodil.lol/vgtk/
- tracker1 7y ago
  Definitely cool... been looking into using neon with electron myself, this might be a good alternative for something lighter.
einpoklum 7y ago
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.
- ptx 7y ago
  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/ https://gi.readthedocs.io/en/latest/
  - einpoklum 7y ago
    But the whole point is that I don't _want_ to use Glib/Gobject's. I want my own language's objects (more often than not - C++).
    - ptx 7y ago
      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.
      - lmm 7y ago
        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).

severine 7y ago

https://gtk-rs.org/ https://gtk-rs.org/

simion314 7y ago

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.

xwowsersx 7y ago
Thanks for the reply. Why does Transmission, for example, have a Mac app and a GTK app? They wanted a more polished Mac appaand gtk doesn't cut it?
- kn0where 7y ago
  Yes, the Mac version of Transmission has a much more Mac-like UI that can’t entirely be replicated in something like GTK.
- solarkraft 7y ago
  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.
- simion314 7y ago
  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 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.
PaulDavisThe1st 7y ago
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.
- simion314 7y ago
  > 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.

steveklabnik 7y ago

Newest hotness with gtk and Rust is https://bodil.lol/vgtk/ https://bodil.lol/vgtk/

tracker1 7y ago
Definitely cool... been looking into using neon with electron myself, this might be a good alternative for something lighter.

einpoklum 7y ago

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.

ptx 7y ago
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/ https://gi.readthedocs.io/en/latest/
- einpoklum 7y ago
  But the whole point is that I don't _want_ to use Glib/Gobject's. I want my own language's objects (more often than not - C++).
  - ptx 7y ago
    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.
    - lmm 7y ago
      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).