Hi, Emmanuel et al, On Sun, Mar 10, 2019 at 4:38 AM Emmanuele Bassi via gtk-list <gtk-list@gnome.org> wrote: > > Meta: having this discussion on gtk-list is probably the best example as to > why we need to move to Discourse. Nobody involved with the development of GTK > even reads this list, except me, so you're never going to get more than my > opinion about it.
What is "Discourse"? In the past there was a forum about GTK+ where people could come and ask questions - it is now dead. And this list is the only place that known to people. > > Meta × 2: while I am employed by the GNOME Foundation to work in GTK, this > *my* opinion, and should not be construed as anything but my opinion. > > On Sun, 10 Mar 2019 at 06:37, Miroslav Rajcic <supp...@notecasepro.com> wrote: >> >> I think the question is a valid one and there is a plenty of evidence of >> people moving to Qt due to some issues of GTK. >> >> Some notable examples: >> >> - VLC >> (https://ubuntuforums.org/showthread.php?t=316155&s=54b259f2cb2d1a30ca8dc269d0561537) >> >> - Wireshark (https://blog.wireshark.org/2013/10/switching-to-qt/) >> >> - Subsurface by Linus >> (https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-qt/) >> >> - GCompris educational software >> (https://mail.kde.org/pipermail/kde-edu/2014-February/007950.html) > > > VLC, Wireshark, Subsurface, and GCompris switched to Qt mostly because of its > support for Android and mobile platforms, something that GTK doesn't support. > Well, Subsurface moved to Qt because the original developers thought that > asking on Google Plus was the proper way to ask for help with writing GTK > applications, and had no objections when somebody else showed up and rewrote > their application using Qt. > > It's entirely justified to go through the ringer of a full rewrite if you're > thinking of expanding somewhere the GUI toolkit you use is not going to be, > and it's highly unlikely that an Android backend for GTK will ever > materialise—let alone an iOS one—so if you're thinking of targeting Android > and iOS, Qt is a perfectly valid choice. I personally would recommend using > Xamarin.Forms, and stop writing code in C/C++. > > The LXDE case is a bit different: writing desktop environments is kind of > what GTK is known for. It seems that LXDE didn't have many contributors, and > the few that were there decided to join forces with a Qt-based project in > order to increase the contributors base. It's also telling that the Qt port > of LXDE is still very much in progress, and the GTK2 code base is still being > maintained. If porting to a new major version of a toolkit is a lot of work, > porting to a whole new infrastructure is even more work. >> >> All these people have valid complaints, so someone should think about it. > > Everyone involved in GTK thought about them. We incorporated the feedback we > gleaned from the various ranting into a better stability and versioning > guarantees; better tooling, like the Inspector; a better build system, to > ensure ease of build on Windows and macOS. If the complaint is "it's not > written in C++" or "there is no paid support" then there isn't much we can do. > >> 1. GTK is not so cross-platform anymore: on Windows and macOS, you are >> supposed to build your own library binaries (gvsbuild for Windows and >> jhbuild for macOS exist, but are not foolproof). > > > There is a fundamental misconception at work, here. GTK was never a > cross-platform in the same sense as Qt is a cross-platform toolkit. GTK began > supporting Windows in the 2.0 release (2002) because GIMP first, and then > Evolution, needed to build and run on Windows. GTK is a *portable* toolkit, > but its goal has always been writing Linux (and GNOME-adjacent) applications. > > Of course it doesn't mean we shouldn't support people writing non-Linux apps > with GTK, but they are a smaller target audience. > > Plus, you seem to imply that "binary builds for Windows" somehow means > "better cross-platform support", which is nonsensical at best. Windows > support in GTK has *never* been this good. There are multiple volunteers > working on building, testing, and developing GTK on Windows. It would be > great to have as many people working on macOS, even though things are moving > once again, there. How about porting recent GTK version to OpenVMS? Thank you. >> >> "Golden age" in this regards was when Tor Lillqvist was still doing the >> Windows builds regularly on each GTK release. GTK was easy to be used on >> Windows at that time. > > Yes, things are always "easy" when somebody else is paid to do them for you. > Doesn't mean they are easy at all. > > Given that Tor stopped working on these years ago, and that Windows hasn't > stayed still in the meantime, the only reasonable course of action for GTK > developers was to offload the build of GTK on Windows to the MSYS2 package > management system—mostly like we do on macOS, with brew and macports. Of > course, we would have loved it if somebody had showed up and did the work; > somebody did, from time to time, and we even gave access to a Windows build > machine hosted in the GNOME infrastructure, but keeping things building is > hard—I do that for GNOME, and it's not fun—and people simply tire of it. > > The move to Meson for GTK4 (and possibly to GTK3, as a secondary build > system) should make building GTK and many of its dependencies easier to deal > with. Ideally, we'd like for people to be able to clone just GTK and be ready > to go; of course, that's probably the "blue sky" goal, but it should be > easier than Autotools has been. >> >> 2. QT has more complete stack, for example integrating audio/video playing >> module (Phonon). gstreamer as an alternative for such module in GTK suffers >> from "build your own binaries" (i.e. issue #1) and a more complex interface. > > GTK4 has a video and media player abstraction on top of GStreamer, and > GStreamer has a GTK3 video widget, these days. >> >> 3. for me, this one is huge: QT has much better rich text editor widget >> (QTextEdit), supporting tables, all types of bulleted lists etc.. GTK's >> default widget GtkTextView (nor GtkSourceView) is not nearly close to this >> (no tables, no bullets, no htmL export). For advanced editor you are >> supposed to embed WebKitGTK, but you must first suffer through issue #1 and >> use complex JScript solutions to implement your rich text editor features >> (formatting actions, text change notifications). > > I'd actually very much like to get rid of GtkTextView and have a simple, > multi-line text entry. Complex text editing widgets are *complex*, and > everyone has their own use case. Do you want code editing? Do you want word > processing? Do you want a multi-line text input for forms? A single widget > for all of these means that the single widget is a mess in terms of > implementation and API. I know, because GtkTextView is that single widget, > and it's a mess. > > My personal opinion is that people are much better served by having a rich > text editing widget in a separate library, targeted at their own use case. >> >> 4. API stability: jumps from GTK2 to GTK3 were painful, many APIs were >> changed, what it looks like from here, without the strong need, but just to >> make everything better organized or similar, without thinking of library >> users. I have an app that must support GTK2 (even using hildon interfaces on >> old platforms like Maemo) and GTK3 in the same code base, so it is now >> littered with many #ifdef layers > > I'm so sorry, but I don't see how this is relevant. Your decisions are your > own. Supporting Qt4 and Qt5 at the same time is going to be problematic *at > best*, for instance. If you ever decided to move to Qt, you'd have to drop > Hildon platforms anyway, for instance. > > Dropping GTK2 is perfectly reasonable, now: GTK3 was released in 2011, 8 > years ago. At this point GTK3 is almost as old as the whole GTK2 development > cycle. >> >> 5. Many other parts are unsolved or hard to implement in GTK (drag and drop >> integration using types other than the basic ones, for example) > > Drag and drop is one of the API sub-systems that was implemented as a thin > layer around X11 concepts for GTK 2.0 (back when it was standardised across > toolkits), and that has never been heavily touched. We're in the process of > rewriting both clipboard and DnD support in GTK4—using a stream-based API and > negotiation based on MIME types—so it's going to be easier to use, even with > complex data types. >> >> 6. Useful features deprecated, an example is native print preview, that >> worked in 2.16 if i remember correctly and was broken forever in next >> releases (at that time I did not want to port preview to a new mechanism, >> so i had to remove that feature in my program) > > 2.16 was released in March 2009, 10 years ago. I assume things have changed > in the meantime. Did you at least file a bug? Which platform are you > referring to? > > Deprecations happen. They are *the only* way for us to move the toolkit > forward without breaking API every 2 years. Deprecation means "this is not > going to be a maintained API going forward, so if a bug happens, you'll have > to be proactive and help us with the fix instead of just filing an issue". > We've made progress on communicating what is deprecated, these days; compiler > warnings, run-time warnings, porting documentation. We can do better, of > course. Just don't expect us to never deprecate things, because that is, > essentially, asking us to never change the toolkit. >> >> IMO, it seems that GTK does not have a coherent strategy when it comes to >> toolkit features and a cross-platform usage (i.e. lowering the effort needed >> to develop for all major OSes). Nowadays it is mostly focused on adding >> shiny things as support for shaders, animated transitions, GL rendering. > > First of all, those "shiny things" are what allows us to get more people > using GTK, and possibly contributing to GTK. We would have long since been > dead as a project if all we ever cared about was making current users of GTK > happy forever. > > Additionally, every platform has switched to using GL/Vulkan/Metal for > rendering their UIs; using a common layer for rendering is basically > necessary to remain relevant and portable. > > As I said above, we have been working on making GTK easier to use on other > platforms—even if, and it bears repeating, our goal is to ensure people can > port their code to other platforms, not target them. Yes, it would be nice if > we had 100+ engineers working on this project full time, but the current full > time complement of people working on GTK is *2*, and everyone else is either > paid part time, or completely volunteering. This means we have to prioritise > things, and making GTK work on Linux/GNOME will always be the priority > because of the sheer amount of contributors using GTK on GNOME. Want to flip > the balance? You'll have to start working on GTK. >> >> Hard-to-implement things like an advanced text editor do not seem to be an a >> table. > > They are on the table only if somebody shows up and does the work. Did you > file bugs about the shortcomings of GtkTextView? Have you prototyped what > kind of API you'd need? What kind of features you'd want? Did you write a > strawman proposal for a rich text editing widget? Or did you expect us to > come up with a new widget and present it to everyone? Because that's *never* > going to work. > > For the GTK4 cycle we "just": > > - redesigned the way GTK draws itself from the ground up > - added 3D transformations for widgets > - re-designed the input system > - rewritten the clipboard and DnD sub-systems > - we're in the process of dropping a new, responsive layout machinery > - we're going to add an animation framework usable programmatically and not > just through CSS transitions > > All things that were highly requested for years; people prototyped them out > of tree, where possible, or wrote extensive descriptions of how they should > work *first*. > > Text editing is another high priority task, but currently people are asking > for a better code editor in GTK; nobody is asking, or working on, a rich text > editor to replace TextView. >> >> This was meant as an constructive critics, it seems strange that this topic >> got just one answer so far. > > See above, re: the meta paragraphs. > > Ciao, > Emmanuele. > >> On 9.3.2019. 17:43, Paul Davis wrote: >> >> >> >> On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list <gtk-list@gnome.org> >> wrote: >>> >>> >>> 2. How does Gtk address the issue of its users moving to Qt? >> >> >> What evidence is there of this? Who are the "users" of GTK that you're >> referring to? Moving an existing GUI app between toolkits is typically >> almost equivalent to a complete rewrite, so applications (which are the real >> "users" of a toolkit) generally do not move. Developers may start new >> projects using Qt having previously used GTK, but who counts this? How would >> we judge if it is significant? >> >>> >>> 3. What makes them move to Qt? Why can't Gtk have that respective feature? >> >> >> Qt has as many issues as GTK once you start using it for complex, deep >> applications. Different issues, to be sure, but no GUI toolkit gives you a >> free ride. >> >> Qt is also developed using a different licensing/income generation model >> than GTK, which changes quite a lot. >> >> Qt mostly has distinct advantages over GTK, and to be honest if I was >> starting cross-platform development now (22 years after I actually did), I'd >> probably pick Qt for all the obvious reasons. But it's fairly pointless to >> ask "how can GTK be more like Qt?" when there's more or less no chance or >> pathway for that to happen. As it is, I don't do mobile so GTK's issues >> there don't affect me. I also have 75k lines of code that would have to be >> almost completely rewritten to use Qt, with no noticeable benefit for our >> users and only marginal benefits for our developers. >> >> Speaking of "why can't?", why can't I write a C application using Qt ? :)) >> >> >> _______________________________________________ >> gtk-list mailing list >> gtk-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-list >> >> _______________________________________________ >> gtk-list mailing list >> gtk-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-list > > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > _______________________________________________ > gtk-list mailing list > gtk-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
