"file chooser portal'

KitchM · 2021-02-22 18:42:43

I have had a lot of trouble with the environment not using my default file manager. Various software applications often open up a file by displaying some sort of file manager window that is unfamiliar to me and seems to bypass Thunar. There was some talk that it was a problem with the application itself or with the XORG or with the toolkit used. I have gone around this problem from different sides, and it appears to boil down to the particular dialog set up for such purposes by the desktop environment. In my case it appears to be Xfce.

I say this because of a discussion at https://gitlab.freedesktop.org/xdg/xdg- … ote_813040 There appears some direction here as to where the problem originates.

Perhaps someone is interesting in this discussion and if a change can be made in Xfce to solve this confusing situation.

KitchM · 2021-04-14 20:52:15

I have found new information about the issue. I have tried and removed Files, Nautilus and Thunar, among others. Even though Files and Nautilus are removed, when a program tries to open a file, a simple version of Files/Nautilus is displayed. How do I get that changed so that a program uses my file manager?

ToZ · 2021-04-14 20:56:54

Thats not a file manager window, but a FileChooserDialog. It is baked into GTK and most apps just call that. QT has its own filechooser dialog as well. There really is no way to replace it, if the app calls it directly.

KitchM · 2021-04-14 22:23:17

You mean they may all use the same one? Also, this looks like a file manager on its own. There must be a way to substitute another interface for that one.?.?

ToZ · 2021-04-14 23:31:22

Not without changing each application's source code. Or patching and running your own version of GTK.

Misko_2083 · 2021-04-15 07:20:08

ToZ wrote:

Not without changing each application's source code. Or patching and running your own version of GTK.

I wonder how that would look like. big_smile

ToZ · 2021-04-15 11:30:46

big_smile

alcornoqui · 2021-04-15 15:05:03

Send the patch, Misko! LO-really-L

KitchM · 2021-04-15 15:25:36

Oo, kool!

Thanks ToZ, for the good info. It appears I am therefore looking for a configuration GUI for customizing the GTK FileChooserDialog. Is there such a thing?

Of course, there is Qt. I wonder what it's version looks like.

CwF · 2021-04-15 15:44:25

KitchM wrote:

I am therefore looking for a configuration GUI for customizing the GTK FileChooserDialog. Is there such a thing?

Could it be done with Glade?

KitchM · 2021-04-15 15:48:10

Glade would be a separate programming environment for new interfaces. It would not tie in directly with the existing UI, would it?

I would think that it would have to do with a utility that ties directly into the Settings of Xfce, sort of like the Appearance or Desktop areas do.

Also, think about the existing dialog window. There is no way to customize it for easier use.

Last edited by KitchM (2021-04-15 15:49:46)

alcornoqui · 2021-04-15 15:57:01

I think Thunar's maintainer is tracking it in this issue: Support for File Chooser Dialog in File Manager DBus Interface.

KitchM · 2021-04-15 20:06:47

I'm having a little trouble telling if that will fix my problem. It occurs to me that there are various possibilities.

In one, the default chooser window will change to Thunar with its default layout. In another, the Thunar layout defaults to the basic chooser display. In another, the default chooser layout is adapted by the user to the user's preferences.

CwF · 2021-04-16 17:35:06

To many ways to do it! I'd like thunar to stay out of it, but it does seem a 'per program' choice. I'd think a common focus on greater flexibility in the gtk component would be best, but what do I know! Some programs benefit from custom file-choosers with specs/previews.etc that would weigh down thunar, and are more extensive than the default gtk-chooser, so fix the gtk component?

KitchM · 2021-04-18 15:08:41

I kind of agree with you. I think that the chooser for Gtk or Qt should simple default to the user's preferred file manager. If they do not want to program their choosers to do that, then they must program them to be customizable.

KitchM · 2021-04-18 15:20:22

To add more details to the discussion and to add clarity, there are links to other explanations which may help. In the Xfce case, it may have something to do with something called a "portal".

Freedesktop Forum on Chooser
Same on related topic

CwF · 2021-04-21 14:40:32

It seems to be no clear answer.

Program authors will still face a choice, and users will notice if the choices are system FM, DE default (gtk/qt) or totally custom.

So I maintain my old thought; improve the middle DE choice so it's slimmer and more focused than the systems FM and expandable to make custom dialogs unnecessary.

If Thunar tackles this then it needs to be able to configure multiple instances differently and not get mixed up. Unlike save last config, it could do that or we're chasing the ever changing FM. So Thunar needs toggles for display features that are stable - side-panel, directory styles and orders. A new instance can't simply inherit the features of the last instance. I think this has improved lately, I may not be totally up to date...

KitchM · 2021-04-21 14:49:37

These are all stop-gap measures for fixing a fundamental mistake in programming. The basic design of the window system must be redone to make any default FM the chooser for any program. In other words, the chooser must be the FM of choice.

I am still surprised every time I think about that fundamental error. Without good direction, programmers often go off the rails, and in such surprising ways.

CwF · 2021-04-21 15:31:44

KitchM wrote:

In other words, the chooser must be the FM of choice.

You're missing some use cases your 'simple fm' choice doesn't address. You assume, understandably. that there is a system FM. If you are a wayland advocate, then never mind... But if you use X features in uncommon ways, the system FM may not be appropriate since it may not be available. In advanced apps i mentioned a few things its chooser may need that should not be in any FM. Perhaps choosing to insert a block in a CAD drawing where typically a 3d view of the blocks should be in the chooser, even manipulable in the preview! Why should a non CAD user be burdened with many dependencies in the FM. Advanced file choosers are appropriate for that, and video, and music, and.....

What if another FM is more useful or preferred? Just like some have believed a system could be browser-centric, some prefer FM-centric, some program-centric. It seems you believe if no thunar = no file chooser?

I say it's the edge case viability that makes something great. The graphics toolkit should have the ability to make a file-chooser, and ultimately a FM if desired, not the other way around. So that's really what we have, a system graphical toolkit should be primary, a specific FM secondary, and the custom dialog last. I fully support Thunar filling the role, just don't support the idea it should be required.

KitchM · 2021-04-21 15:53:13

I confess that I do not understand your "uncommon ways". When I use my CAD program, all of its selection of items and shapes are internal to it and have nothing to do with a chooser or a FM.

If a program needs a file to insert into a drawing or document, the FM is entirely able to handle that function.

As to the choice of a FM, that is the whole point of it. Any user should be able to choose the FM that is the most useful, preferred and customizable for the intended environment.

Again, the graphical toolkit is to blame here; it fails to use the default FM. I see that as very fundamental.

CwF · 2021-04-21 16:20:22

I do see your point, but...

It is the program that chooses. So if the preference is the system FM, then toolkit option is what needs modified, my original point, It needs modified to have a configurable preference (your fm) or the fall back (my choice). With this solution legacy programs that call gtk's chooser are preserved.

We both think the file chooser should be improved. Me, so I can use the gtk-chooser, you to force the role of system FM. Both can happen, and the mod lies squarely in modifying the gtk-chooser.

I prefer workstation/server setups where X is used to run programs remotely. The program needs it own chooser, or a light default, not the servers Thunar, not the workstations Thunar. It's edge case like this that are squeezed out by the idea that everyone should run a wayland laptop. Improving the gtk component clears this hurdle.

KitchM · 2021-04-21 20:01:36

No, the program does not choose. They are programmed to look for a particular thing in the environment when they want to deal with a file.

That thing they look for is the common mechanism provided by the environment. As you point out gtk-chooser, and yes, the chooser should simply be modified to call the default FM. Simple.

Are you saying that Wayland solves this environmental issue?

CwF · 2021-04-21 21:02:42

ToZ wrote:

Not without changing each application's source code. Or patching and running your own version of GTK.

This is my understanding, the application chooses.

If written with it's own chooser dialogs. then that's the choice = not thunar. If it is written for the toolbox's default, gtk or qt = then that is the choice, not thunar. Without breaking everything the choice is then to allow the toolkit itself to offer a choice since the already written applications CAN'T.

So point, in this case the gtk default chooser needs some new code to allow the FM to be the default chooser. If there was a global setting for this switch then fine, your solution is at hand - you check the system fm tickbox...So that's the direction I'm pointing.

I mentioned glade simply because as far as my limited skills understand, the first two choices are in there = build you own chooser dialogs or use the default. It's that default option I'm proposing you focus on since it is the one to change. I suspect once the new hooks discussed are in place an app could call thunar directly or indirectly an bypass the default toolkit choice altogether.

KitchM · 2021-04-21 21:11:53

I really do not think that can be correct. Every single programmer of an application must target the platform they expect their customers to use. If it is windows, all programs look for particular interface features to tie the program into the environment and possibly tie into other programs. The same thing works on Mac and Linux.

The common thing in each flavor of computer OS is the basic environment given to it. In the case of Linux, it gets more complex because each DE can be based upon a different toolkit. Fortunately, there are only a couple major ones to worry about.

All programs look for the Gtk or Qt hooks they will use for file functions. If that is correct, and I believe it to be, then the change does not come in each program but in the commonly-used part of the environment's toolkit. Therefore, only the toolkit's chooser code needs to be adapted. That should be trivial to change the focus to a common FM instead of a poor dialog window.

CwF · 2021-04-21 22:11:50

KitchM wrote:

Therefore, only the toolkit's chooser code needs to be adapted.

That's exactly my point, and what I've been explaining!

CwF wrote:

So point, in this case the gtk default chooser needs some new code to allow the FM to be the default chooser. If there was a global setting for this switch then fine, your solution is at hand - you check the system fm tickbox...So that's the direction I'm pointing.

Last edited by CwF (2021-04-21 22:14:43)

Xfce Forum

Sub domains

#1 2021-02-22 18:42:43

"file chooser portal'

#2 2021-04-14 20:52:15

Re: "file chooser portal'

#3 2021-04-14 20:56:54

Re: "file chooser portal'

#4 2021-04-14 22:23:17

Re: "file chooser portal'

#5 2021-04-14 23:31:22

Re: "file chooser portal'

#6 2021-04-15 07:20:08

Re: "file chooser portal'

#7 2021-04-15 11:30:46

Re: "file chooser portal'

#8 2021-04-15 15:05:03

Re: "file chooser portal'

#9 2021-04-15 15:25:36

Re: "file chooser portal'

#10 2021-04-15 15:44:25

Re: "file chooser portal'

#11 2021-04-15 15:48:10

Re: "file chooser portal'

#12 2021-04-15 15:57:01

Re: "file chooser portal'

#13 2021-04-15 20:06:47

Re: "file chooser portal'

#14 2021-04-16 17:35:06

Re: "file chooser portal'

#15 2021-04-18 15:08:41

Re: "file chooser portal'

#16 2021-04-18 15:20:22

Re: "file chooser portal'

#17 2021-04-21 14:40:32

Re: "file chooser portal'

#18 2021-04-21 14:49:37

Re: "file chooser portal'

#19 2021-04-21 15:31:44

Re: "file chooser portal'

#20 2021-04-21 15:53:13

Re: "file chooser portal'

#21 2021-04-21 16:20:22

Re: "file chooser portal'

#22 2021-04-21 20:01:36

Re: "file chooser portal'

#23 2021-04-21 21:02:42

Re: "file chooser portal'

#24 2021-04-21 21:11:53

Re: "file chooser portal'

#25 2021-04-21 22:11:50

Re: "file chooser portal'

Board footer