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

Reply via email to