FLTK logo

STR #2904

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #2904

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:2 - Specific to an operating system
Subsystem:X11
Summary:Native file chooser isn't exactly native on linux
Version:1.3-feature
Created By:netrick
Assigned To:manolo
Fix Version:1.3.3
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 ianmacarthur
17:02 Dec 17, 2012
fnfc-gtk-patch.zip
8k
 
 
#2 ianmacarthur
16:17 Dec 19, 2012
fnfc-gtk-patch-v2.zip
11k
 
 
#3 manolo
08:08 Feb 13, 2013
Fl_Native_File_Chooser_GTK_Test.cxx
31k
 
 
#4 manolo
08:09 Feb 13, 2013
Fl_Native_File_Chooser.H
8k
 
 
#5 manolo
14:33 Feb 15, 2013
Fl_Native_File_Chooser_GTK_test.cxx
35k
 
 
#6 manolo
14:34 Feb 15, 2013
gtk.h
2k
 
 
#7 manolo
10:34 Feb 16, 2013
gtk-browser.patch
38k
 
 
#8 manolo
09:57 Feb 18, 2013
gtk-browser2.patch
56k
 
 
#9 manolo
02:08 Feb 21, 2013
gtk-browser3.patch
58k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 netrick
07:40 Dec 13, 2012
Well, there is a native file chooser class. I made a switch to fltk as I wanted that feature in my app, but it doesn't work on linux with LXDE (Lubuntu 12.10). This is how my OS native "open file" looks like (taken from PDF viewer)" http://i.imgur.com/1noQ7.png and this is how "native file chooser" looks using FLTK app: http://i.imgur.com/vAFuT.png . It just calls default FLTK file browser, seems like it doesn't recognize LXDE file manager (pcmanfm). However, every other software that I download do recognize LXDE file manager properly. LXDE is growing and getting more and more popular with every day and you should look into this, why this doesn't work. I don't want to be forced to use ultra heavy and non-intuitive wx/qt/gtk, I want to stay with FLTK but that feature is quite important for all sorts of editors. Fltk is great, please look into it! thanks  
 
#2 manolo
09:38 Dec 14, 2012
Changed to an RFE.  
 
#3 greg.ercolano
10:35 Dec 14, 2012
Linux has no single native file browser, so we have to use our own on that platform.

The problem is Gnome, KDE, and numerous others exist for linux, but none are 'standard', and all are constantly changing.

We'll look into it though; LXDE does at least have similar goals to FLTK (lightweight).

What I'd suggest to the OP for the short term is to make a small external LXDE application that simply opens a file browser, taking optional command line options indicating the default directory/file to show when the browser opens, and the app simply prints the pathname the user chooses to stdout. Then you can simply invoke this app from your FLTK application using open the LXDE file browser, and if you use popen(), you can read back the chosen filename from stdout.

Or, if you want to send us a patch that gives us a head start on adding the LXDE browser to Fl_Native_File_Chooser, that would definitely help us get the ball rolling in detecting and supporting it in the release versions of FLTK. Otherwise it's unlikely to get supported unless it somehow does evolve as a standard on all distros.
 
 
#4 netrick
12:03 Dec 14, 2012
Okay, I will look into doing some patch. I have one question though. How do GTK apps recognize default file browser? It must be stored in some config file or something like that, because I can run gtk app from the same ubuntu repo (so it's one binary file), on ubuntu with unity, lubuntu with lxde, xubuntu with xfce and kde with kubuntu and it always opens the default file browser of the desktop environment.
Could you look into it? For sure it's not hardcoded - if you download less known file manager and set it to default in desktop environment, gtk apps open that new file manager. So I think it don't need to be hard coded for lxde, but rather it can be one solution for all linuxes (file manager command must be stored somewhere).
 
 
#5 ianmacarthur
13:06 Dec 14, 2012
Is there an XDG code for this sort of thing? Does anyone know?

Re: Greg's suggestion of a stand-alone chooser; ISTR that some tool (maybe LVE or something that no longer exists...) did exactly that, and I cobbled together a basic chooser that used fltk for my system, since the default source code that distributed with it used some GUI toolkit that I did not have on that machine...

So, anyway, it is a well established idea, and maybe something to consider...
 
 
#6 netrick
00:58 Dec 15, 2012
I think I have found something! It says it is stored in  ~/.local/share/applications/defaults.list , but there are also other files mentioned. I give you two links: http://askubuntu.com/questions/211325/how-to-set-pcmanfm-as-the-default-file-manager and https://help.ubuntu.com/community/DefaultFileManager . If you could look at it you may find some clue.  
 
#7 ianmacarthur
13:25 Dec 15, 2012
No, I was mistaken about XDG, well at least xdg-open and the xdg-mime stuff does not do what is wanted, so the .../defaults.list file is not going to help: it is useful in determining what application the user wishes to use to open a given file type, but it does not appear to have a mechanism for identifying which file dialog to use for the file-open, file-save, file-save-as preferences.

Rather, at least under GTK based systems (e.g. Gnome or LXDE) that appears to be done via the GtkFileChooserDialog mechanism.

Now, in principle, it looks like we could *probably* detect the presence of the GTK mechanisms and then spawn a GtkFileChooserDialog, falling back to the fltk chooser if the GTK one was not detected.

There's a bit of work integrating that though, because, as with other platforms, pulling in bits from another GUI toolkit gets messy... Looks like it could be made to work, in much the way the Win32 one does though, I *think*... (without trying to write the necessary code of course!)

To the OP (netrick): if you want this, I suggest you take a run at it yourself and let us know how it goes - this is open source after all, and all are welcome. Otherwise, it may be some time before this gets looked at, as I doubt any of the core devs can take a run at this in the short term (too much to do...!)
 
 
#8 netrick
13:35 Dec 15, 2012
Well we can also try luck with looking into GTK source code and trying to copy-paste file chooser source, as adding gtk dependencies won't be good.  
 
#9 netrick
13:36 Dec 15, 2012
But probably this won't be easy and ending up with including half of gtk into source isn't what we want. Ill do some research.  
 
#10 ianmacarthur
01:38 Dec 16, 2012
No, perhaps you misunderstand: it is not necessary to copy/paste anything from gtk.

What we'd have to do would be something like this: (note that this is essentially what the Win32 and OSX cases do...)

- We write a (probably C language) wrapper for launching GtkFileChooserDialog programmatically from within fltk, and passing in the various options that fltk knows and converting them to the GtkFileChooserDialog equivalents. (Turns out this might be quite straightforward, I had a brief look at the GTK+ docs last night and it seems do-able!)

- At runtime, if someone wants a file-chooser, we use dlopen (or something...) to check for the presence of the required gtk/glib .so files and load them if available, then use our GtkFileChooserDialog wrapper.

- if the gtk .so are not available, we use our stock fltk file-chooser instead, as we do at present.

- Of course, on subsequent calls to the file-chooser we don't have to re-check for gtk, we already know the answer...

As I say, this is very similar to what we do on other platforms, and only one file will contain any gtk+ code, so we are not importing large chunks of another toolkit or anything, just using their public API and calling the existing libs.

Also, by loading the gtk libs via dlopen that ensures we do not need to link against those libs if we are not using them.

Well, something like that, anyway.

FWIW, I wrote a simple wrapper to test opening GtkFileChooserDialog in "Open File" and "Save As" mode, and it seemed to work and wasn't all that much code, so I think this can be made to function.

Though creating the code to map all the fltk options onto GTK options is going to be non-trivial!

Also, and this may be relevant, the GtkFileChooserDialog API seems to be more or less identical in gtk+2 and gtk+3 so there's a fair chance we could write one version of our wrapper function that would work in either case, regardless of what version of GTK the end-user had installed... Maybe...
 
 
#11 AlbrechtS
02:21 Dec 17, 2012
FWIW: doing this as Ian suggested means that the gtk development files (headers etc.) must be present on the /developer's/ machine. So we'd have to add a configure check and #if.../#endif around the corresponding gtk wrapper code. But that would be doable as well.  
 
#12 ianmacarthur
02:28 Dec 17, 2012
Indeed so - and I was not suggesting I was all that keen on that approach - only that it looks feasible!

I suppose a safe "fallback" might be to have it as an add-on, in the way the FNFC used to be, so folks could add it if they wanted it, since making fltk depend on GTK seems like an "unusual' choice...
 
 
#13 ianmacarthur
17:02 Dec 17, 2012
OK... So, despite saying I wouldn't, I had a quick stab at this.

It is *very* incomplete, and I have made no attempt to load the GTK libs via dlopen() or otherwise, so to make this work it will link in the GTK dependencies directly, which is not what we want for every day use!

Also, I never got around to implementing the filter patterns, so you get "All Files" mode all the time.

Attached is a patch against r9760 of fltk-1.3, plus one new file "src/Fl_Native_File_Chooser_GTK_Test.cxx" which needs to be dropped into the appropriate place.

I have NOT modified the configure script at all - you need to have an initialised, configured, checkout of 9760, then lay this patch on top of it.

Then it Might Just Work.

NOTES: The new file is really just src/Fl_Native_File_Chooser_FLTK.cxx hacked about; the intention is, once the dlopen() stuff is in place, that *IFF* we find usable GTK libs and so forth we use that, if not, the code falls back to doing what the stock linux FNFC does.

However, this code is just a test and incomplete; in particular, there are a lot of places where I ought to have ifdef'd out some GTK stuff, that is "always on" here. so this will not build at all if the GTK dev packages are not on your machine.

And, as noted above, a lot of the capabilities of FNFC, in particular the filter patterns, are not implemented - though the GTK widget should be able to do them, I never got around to it; it may be a fair chunk of work...

Setting the working directory probably will not work - and the GTK widget has some odd ideas about that anyway...

What works is selecting single / multiple files, single / multiple directories, file save, directory create.

Finally; this is what it is - do not assume I will *ever* do any more work on this...
 
 
#14 ianmacarthur
16:29 Dec 19, 2012
OK: revised version of previous patch.

This now loads all the GTK and GLib dependencies (of which there are many...) at run time so that we do not have to link against any GLib libs at compile time (though you DO still need the GLib/GTK headers in place to compile the code, IFF you want to use the GtkFileChooserDialog mechanism.

However, I still have not fixed the filter patterns - and to be honest, I doubt I ever will; this has been an interesting diversion thus far but I'm getting bogged down in details now and losing momentum.

I also have not fixed configure, so you need to have a configured version of r9760 of fltk-1.3, then drop in the tweaked makeinclude in the V2 patch, and the new source file.

What configure ought to do is figure out which version(s) of gtk are installed on the dev machine at compile time and adjust makeinclude accordingly. It should also set some #defines for the lib names to be used in "src/Fl_Native_File_Chooser_GTK_Test.cxx". At present, you need to adjust both files manually for the purposes of testing.

A further step might be to have "src/Fl_Native_File_Chooser_GTK_Test.cxx" probe first for gtk+-3.0 then for gtk+-2.0 then fall back to plain fltk chooser - that would be pretty easy to add, if we can be bothered...

Note also that now, if the #define _TEST_GTK_FILE_CHOOSER is not set, then "src/Fl_Native_File_Chooser_GTK_Test.cxx" reverts to being the "moral equivalent" of "src/Fl_Native_File_Chooser_FLTK.cxx" at compile time and so can build on a machine that does not have the GTK/GLib dev headers installed.

The changes here should be transparent on OSX and WinXX.

I'd be interested to her whether they actually work on any system other than the F17 test box I've been playing on - I think it should work, but who knows!?
--
Ian
 
 
#15 manolo
08:46 Dec 20, 2012
It works well here: Linux Debian 2.6 in VirtualBox with Gtk2  
 
#16 netrick
01:03 Dec 21, 2012
I will have a look at it when I have time.  
 
#17 greg.ercolano
03:11 Dec 30, 2012
FWIW, zenity(1) is a simple linux command line tool that can
    among other things bring up a native file chooser.

$ zenity --title="Select a file" --file-selection

    I noticed this is what JUCE uses for its linux file chooser.
 
 
#18 manolo
08:14 Feb 13, 2013
With today's Fl_Native_File_Chooser.H and
Fl_Native_File_Chooser_GTK_test.cxx (attached files),
the GTK widget fully supports filters.

The header file now allows a client application to compile and link
with FLTK without the need to define _TEST_GTK_FILE_CHOOSER.

I believe the implementation of the GTK-style native widget is
complete with this, except there's no support of turning
SAVEAS_CONFIRM off.
 
 
#19 sanel.z
13:56 Feb 14, 2013
Sorry guys for commenting here (or maybe 'devel' list will be fine), but adding Gtk+ dialog in form of 'native' one, makes absolutely no sense.

So, what for example if I install Kubuntu where Qt is reference toolkit and remove all Gtk+ stuff? Is it then normal to expect FLTK to show Qt dialog as 'native' one?

IMHO if user wants Gtk+-like dialog, how hard for him would be to dlopen() Gtk+/Motif/whatever...
 
 
#20 greg.ercolano
09:06 Feb 15, 2013
I believe the intention is, if gtk is unavailable, it would fall back to the FLTK browser.

If we had support for Qt the way we do now for GTK, if Qt was available, it could use that too.

I'm not sure if we intend to make this a configure option (--enable-gtk-browser?), build option (#define FL_USE_GTK_BROWSER?), or other.. but I think that's the general idea. (I suppose a Qt option, should it exist, would work for all platforms..)

I imagine adding the gtk support is a step in the right direction, but yeah, there's no such thing as a native gui anything on linux ;) Still, I suppose it might be more what people expect on linux..
 
 
#21 manolo
14:44 Feb 15, 2013
- added support for Fl_Native_File_Chooser->directory(char*)
- added a "Show hidden files" toggle button
- dlopen first searches for GTK3 and then, if not found, for GTK2
(both versions have the same API for all used functions)
- dlopen tries libgtk-3.so.0 if libgtk-3.so is not found
- fixed an issue where the GTK dialog changes the current locale

It's also possible to use a "fake" gtk/gtk.h include file
(see attached) that defines just the needed API. With it, no need
to change the FLTK configure system; it's enough to replace
Fl_Native_File_Chooser_FLTK.cxx by Fl_Native_File_Chooser_GTK_test.cxx
and Fl_Native_File_Chooser atempts to create a GTK file dialog,
and falls back on Fl_File_Chooser if libgtk2/3.so is not available.
 
 
#22 greg.ercolano
17:16 Feb 15, 2013
Thanks Manolo! Nice addition.

Would be great if you could document any gtk/linux specifics for use
of FNFC in the docs, and try to hit on:

    o How to "trigger" the GTK behavior (ie. macro names if any)
    o Any special linking instructions for the app (static+dynamic)

Assuming you already have a simple test program you've been using
to test the gtk + FNFC, might I suggest adding your test app to the
examples as perhaps: "examples/nativefilechooser-linux-gtk.cxx"

Adding examples is easy; just add the .cxx file, and make a small mod
to examples/Makefile so that it builds. No visual studio files needed. See the "examples/README.examples" for coding suggs.
 
 
#23 manolo
11:06 Feb 16, 2013
The attached gtk-browser.patch modifies the current svn repository
so that Fl_Native_File_Chooser uses the GTK dialog when libgtk2-or-3.so
is available at run time, and falls back on Fl_File_Chooser when
it's not. Most of the new code is Ian's work.

As set here, no change in the library configuration is needed,
no option needs to be turned on neither. This corresponds to the logic
"Fl_Native_File_Chooser does something different from Fl_File_Chooser
when possible".

A less drastic modification of FLTK could be to have
_TEST_GTK_FILE_CHOOSER optionally turned on at configure time.

The demo program test/native-filechooser.cxx is modified (Ian did
it, really) to exercize all file chooser dialog flavors (open,
save, directory,...) in turn.

The patch creates a new file (src/fl_gtk.h) containing all useful
type declarations from <gtk/gtk.h>. This avoids altogether
to modify the configure mechanism. I believe this unorthodox
procedure is safe because all declarations therein are part of
the gnome public API (see http://developer.gnome.org).
The patch also modifies FL/Fl_Native_File_Chooser.H somewhat
and src/Fl_Native_File_Chooser.cxx extensively.

I found this works well on Linux/Debian and Darwin/X11.
It's probably necessary to test it on other Linux distros.
 
 
#24 ianmacarthur
08:15 Feb 17, 2013
Cool tweaks: very good stuff.

But, addressing Sanel's observations: Do we want to do this?

I wrote the code more as a proof of concept in response to the STR than as an indication of intent to do this...

Sanel said:

> Sorry guys for commenting here (or maybe 'devel' list will be fine), but adding Gtk+
> dialog in form of 'native' one, makes absolutely no sense.

Yes, it is a tricky one, though I suspect for the majority of users, the gtk chooser is more familiar than our native one...

> So, what for example if I install Kubuntu where Qt is reference toolkit and remove
> all Gtk+ stuff? Is it then normal to expect FLTK to show Qt dialog as 'native' one?

Yes, in particular this is awkward - though note that this already happens to me anyway; I have often had apps I'm running open the gtk file chooser, even though I'm running some KDE-based desktop.

I assume I am not unique in this regard, so perhaps this is considered "normal" these days?

In any case, if we go this way, we have to dlopen the gtk libs or the kde libs, having somehow decided which to actually use...?

I *assume* there is some way (environment variables?) to determine what flavour of desktop the user is running?


> IMHO if user wants Gtk+-like dialog, how hard for him would be to dlopen()
> Gtk+/Motif/whatever...

Yup - this code was meant to show exactly how hard it would be, and to provide a working example... not necessarily intended to be included into fltk core.

In any case, if we did include this, it would need to ahve the ABI runtime guards around it for 1.3.3 or something?
 
 
#25 manolo
09:59 Feb 18, 2013
Uploaded gtk-browser2.patch with a somewhat cleaner implementation
that separates the FLTK and GTK browsers in two classes
and two source files.
 
 
#26 ianmacarthur
03:00 Feb 20, 2013
A thought:

Should Fl_X11_File_Chooser maybe be called Fl_Fltk_File_Chooser or some such thing?

In that, it is not really X11 specific, it is just a wrapper for the basic FLTK file chooser, so could be used on any host in principle (though in this case likely only under X11 I concede!)
 
 
#27 manolo
02:10 Feb 21, 2013
In attached gtk-browser3.patch:
- class Fl_X11_File_Chooser renamed Fl_FLTK_File_Chooser
- added support for Fl_Native_File_Chooser::USE_FILTER_EXT option
and exercize it in native-filechooser.cxx test program
 
 
#28 mdickie
04:46 May 21, 2013
I think the best would to create just a functional, better and more comfortable Fallback File Chooser. Eventually if anyones wants can link a fully native File Chooser to fltk.
Greetings,
MDickie
 
 
#29 retux
12:12 Jan 23, 2016
> I think the best would to create just a functional, better and more comfortable Fallback File Chooser

Do you have any plans to do this? I think improving the current file chooser might be a good point to enhance the usability of FLTK.
 
 
#30 manolo
22:22 Sep 05, 2016
Since FLTK 1.3.3, class Fl_Native_File_Chooser attempts to use
GTK file dialogs when they are available on the running computer,
and falls back to Fl_File_Chooser when they are not.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.