71213.7 / 30 September 2017

More cohesiveness on GUI applications

I am writing this because I am genuinely confused as to why I am writing this. Not because I am just confused, haha, that would be funny, but because Mozilla refuses to do something so simple it is amazing to me.

The Problem

Unless you venture away from a GTK related DE you might not realize this, but on Linux when you try to save a file when using Firefox, or Thunderbird it opens a GTK specific file dialog. People normally would say hey, it is a GTK application, isn't that to be expected? To be fair, to non-programmers this is a solid argument and would make sense to most people. Here is the truth from some one who is a programmer and knows how this works vaguely in this regard because it isn't my focus, but I have looked at the patches submitted by non-mozilla team members to remedy the issue and they are refused.

Any way, it works like this, when an application is created a developer/team of developers decides on their language which is usually tied to a gui toolkit, but not always, and if that is the case they decide on their gui toolkit of preference for what ever reason. The gui toolkit provides a lot of additional functionality and one piece of functionality provided is the file save dialog prompt. Some languages that have specific gui toolkits that are used most often like in java/swing have their own. KDE Plasma has their own and so does Gnome Shell. The part that most non-programmers don't grasp is that this file save dialog for each user's respective DE can be called upon with either some pretty small boiler plate code, or a small utility program. Each dialog works in mostly the same way. You save a file and the application provides a byte stream, or something along those lines and to open the application requests the byte stream or what have you, obviously brushing over things, but I am sure you can get an idea of how trivial this is.

Test Case or Example

In the case of Mozilla they have been working on making Firefox cross-platform and even going so far as to have it work on a multitude of devices and good on them. I love the privacy focus and keeping users protected, but for some programmers the gtk vs non-gtk, or qt vs non-qt, etc...etc.. Is a religious war. Users just want the best experience possible. When I save a file I want to be able to click on my already saved favorites that are linked to my file manager of choice and quickly get what ever task I am doing done. What users don't want is another application that brings with it unnecessary usability complications.

Current Solution

Now some people might say, hey just compile the patch in it yourself. This is true and right now we do have a ppa for plasma users, https://launchpad.net/~plasmazilla. It works well, but the point of writing this isn't to introduce additional work for people that are annoyed it is in an attempt to add a little unity back to the conversation. This could easily be an upstream fix and this would in no way compromise Firefox in so much as it being a GTK application. This isn't a slippery slope argument where if you accept this one patch then suddenly you will also need to accept more KDE related, or other DE specific patches. Most the other things in Firefox has been made so they are cross-platform so they would as the user would expect. Saving a file, or opening one is something I think falls into this category.

I want this to be clear, I am in no way saying any file open/save picker dialog prompt, or whatever you wanna call it is better then another. Each user has their reason selecting a certain one, or maybe they don't care about the DE at all. Some applications that aren't used so widely can probably totally ignore what I am saying, but here is my general idea.

Application gui toolkit providers and application developers need to have simple ways to allow for the creation of general purpose boiler plate code and recommend using it for all of their applications. I do have some software I plan on releasing and it is built using Qt and QWidgets. I am going to make sure that if a GTK user wants to download my application and use it needs to save a file they have their default DE specific file dialog shown. After all the goal with my software is to have it so everyone can use it on Linux and it works well and looks good. I don't want to punish GTK users because I personally prefer Qt. The choice of gui toolkit was simply made for pragmatic reasons. I like several things about the work flow and design practices. I hope Firefox devs can do the same thing. It makes absolutely no sense to me personally and I hope we can just make Linux work better and have things be more polished and make EVERYONE happy if it is within our power to do so without going out of our way in the process as well. Mozilla developers are top notch and I am sure they could figure out a super elegant way to solve this problem if they were so inclined.

Here is a comparative picture while using the different versions with one using the default dialog picker for that DE and the other using the GTK specific version that doesn't include the users favorites.
example 1

For reference, how you call a file dialog :

For Qt

QFileDialog fileDialog(
    "All files (*.*)"



dialog = gtk_file_chooser_dialog_new(
    "Open File", 

res = gtk_dialog_run (GTK_DIALOG (dialog));  
    char *filename;  
    GtkFileChooser *chooser = GTK_FILE_CHOOSER (dialog);  
    filename = gtk_file_chooser_get_filename (chooser);  
    open_file (filename);  
    g_free (filename);  

gtk_widget_destroy (dialog);

Possible Solutions & Applications

Now I think the further implications of going down this road is potentially if the code can be written in such a way as to override ALL application file dialog prompts for all applications safely we could further integrate applications into ALL DE/WM's experience.  If anyone thinks this is a good idea, or bad idea please let me know.

Other relevant conversations
- https://bugzilla.mozilla.org/show_bug.cgi?id=298848
- http://blog.martin-graesslin.com/blog/2013/12/firefox-kde-integration-in-debian-testing/