| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #3341
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_File_Chooser has no icons under more recent distributions |
|---|
| Version: | 1.3-current |
|---|
| Created By: | chris |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | chris
22:33 Oct 14, 2016 |
| Observed with Ubuntu 14.04, Ubuntu 12.04 with the 'file_chooser' test program.
See attached screenshot 'file_chooser_missing_icons.png'
Reason is, that Fl_File_Icon2.cxx/Fl_File_Icon::load_system_icons() fails to detect system icons, but does not use default icons then.
Putting in some debug output, I see (Ubuntu 14.04) that it takes the path 'Load KDE icons...' (with kdedir='/usr', filename='/usr/share/mimelnk'), fails to detect anything and returns.
I think the whole strategy is outdated for newer systems (even if the paths are correct, the icons are now in svg format). | |
| |
| #2 | chris
22:38 Oct 14, 2016 |
| Attached screenshot 'file_chooser_with_default_icons' to show how it should (coud) look. | |
| |
| #3 | greg.ercolano
11:50 Oct 18, 2016 |
| Ew, I don't think we support the SVG image format.
That'd be a large thing I think; SVG has its own language, kinda like postscript. | |
| |
| #4 | AlbrechtS
13:19 Oct 18, 2016 |
| Hmm, I don't know what's wrong with my Ubuntu 14.04 system ;-)
... but my file chooser shows icons.
I don't have the time to check and debug right now; just wanted to point out that there must be something different with the OP's system and mine.
Please see attached file: ubuntu_14.04_with_icons.png | |
| |
| #5 | chris
22:24 Oct 18, 2016 |
| I also get this on a VM with Ubuntu 16.04. At least I seem to be consistent in screwing up my installations :)
I attach a file 'strace.log' where you can follow the track of Fl_File_Icon2.cxx/Fl_File_Icon::load_system_icons() on my Ubuntu 14.04 machine. | |
| |
| #6 | chris
22:40 Oct 18, 2016 |
| BTW: The image you uploaded looks like these are the default icons - so on your machine it somehow makes it to the 'Create the default icons...' else tree (Fl_File_Icon2.cxx line 779). | |
| |
| #7 | greg.ercolano
09:52 Oct 19, 2016 |
| @Albrecht: for what it's worth, I can confirm OPs behavior on my
Sci Linux 6.3 machine; no icons shown next to files and folders.
Since I can replicate, perhaps I can figure out why it isn't falling back
to using this.
OP: In your strace it shows all the files it's trying to access.
Where are the files on your machine that you think it should be using?
Perhaps we can use that to determine the newer desktop standards we should
be following.
But I'm pretty sure we won't be able to support SVG format icons..
would have to be png/gif/jpg/etc. SVG is an amazing format that looks great and all,
but I don't think we can support it by default; too complex of a library AFAIK.
I know we have built in icons that are I think defined in some kind
of hard coded polygon/vector format (SGI "FTI".. see Fl_File_Icon::load_fti() )
which, for example an excerpt from src/Fl_File_Icon2.cxx, looks something like:
static short plain[] = { // Plain file icon
COLOR, -1, -1, OUTLINEPOLYGON, 0, FL_GRAY,
VERTEX, 2000, 1000, VERTEX, 2000, 9000,
VERTEX, 6000, 9000, VERTEX, 8000, 7000,
VERTEX, 8000, 1000, END, OUTLINEPOLYGON, 0, FL_GRAY,
VERTEX, 6000, 9000, VERTEX, 6000, 7000,
VERTEX, 8000, 7000, END,
COLOR, 0, FL_BLACK, LINE, VERTEX, 6000, 7000,
VERTEX, 8000, 7000, VERTEX, 8000, 1000,
VERTEX, 2000, 1000, END, LINE, VERTEX, 3000, 7000,
VERTEX, 5000, 7000, END, LINE, VERTEX, 3000, 6000,
VERTEX, 5000, 6000, END, LINE, VERTEX, 3000, 5000,
VERTEX, 7000, 5000, END, LINE, VERTEX, 3000, 4000,
VERTEX, 7000, 4000, END, LINE, VERTEX, 3000, 3000,
VERTEX, 7000, 3000, END, LINE, VERTEX, 3000, 2000,
VERTEX, 7000, 2000, END,
END
}; | |
| |
| #8 | greg.ercolano
10:04 Oct 19, 2016 |
| Here's the current Free Desktop specification for icons:
https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
On my system there are indeed icons in /usr/share/icons, but there doesn't seem to
really be a 'standard' location for default icons. For instance, all icons named "folder.png"
in my /usr/share/icons:
--- snip
# find /usr/share/icons | grep /folder.png
/usr/share/icons/HighContrastLargePrintInverse/48x48/places/folder.png
/usr/share/icons/HighContrastLargePrint/48x48/places/folder.png
/usr/share/icons/Mist/32x32/places/folder.png
/usr/share/icons/Mist/24x24/places/folder.png
/usr/share/icons/Mist/16x16/places/folder.png
/usr/share/icons/Mist/256x256/places/folder.png
/usr/share/icons/Mist/22x22/places/folder.png
/usr/share/icons/Mist/48x48/places/folder.png
/usr/share/icons/Crux/32x32/places/folder.png
/usr/share/icons/Crux/24x24/places/folder.png
/usr/share/icons/Crux/16x16/places/folder.png
/usr/share/icons/Crux/22x22/places/folder.png
/usr/share/icons/gnome/32x32/places/folder.png
/usr/share/icons/gnome/24x24/places/folder.png
/usr/share/icons/gnome/16x16/places/folder.png
/usr/share/icons/gnome/22x22/places/folder.png
--- snip
I don't know how we're procedurally supposed to determine which one of those to pick.
Picking 'any' one might get you a really ugly icon. I guess we could put a preference
on gnome and kde. But all those other names I'm not familiar with (Crux, Mist), and they
probably come and go like the wind.
I don't follow this stuff, just weighing in (which probably isn't worth much).
It seems whatever 'standard' we follow will change a few years later, so perhaps
we should just stick with our built in defaults, and maybe just make them nicer looking.
Also: on linux the native file chooser might look better; that tries to use the GTK
file chooser.. I think Manolo figured that one out. OP, if you want a nice browser,
try using test/native-filechooser and see if the GTK browser comes up. It has icons and
all kinds of nice things. | |
| |
| #9 | chris
10:32 Oct 19, 2016 |
| Thank you Greg "just weighing in". I like your views...
Personally I don't bother not having my system's icons in the chooser - the default ones are good enough, so I also think it would be enough to reliably fall back to the default icons. As you say, it's not worth chasing everchanging icon locations/formats.
OFFTOPIC:
@Native Filechooser: FLTK's filechooser has one great thing, the native has not: a preview window for images and texts - therefore I prefer it.
@SVG: Do you know nanosvg? https://github.com/memononen/nanosvg
There was a thread about it last year in fltk.general. I also have saved an example of using it with FLTK. | |
| |
| #10 | AlbrechtS
14:00 Oct 19, 2016 |
| Just adding more data points (no solutions) to the discussion:
@Greg: my Ubuntu system shows with the same command:
$ find /usr/share/icons | grep /folder.png
/usr/share/icons/HighContrast/32x32/places/folder.png
/usr/share/icons/HighContrast/16x16/places/folder.png
/usr/share/icons/HighContrast/24x24/places/folder.png
/usr/share/icons/HighContrast/256x256/places/folder.png
/usr/share/icons/HighContrast/48x48/places/folder.png
/usr/share/icons/HighContrast/22x22/places/folder.png
/usr/share/icons/oxygen/32x32/places/folder.png
/usr/share/icons/oxygen/16x16/places/folder.png
/usr/share/icons/oxygen/128x128/places/folder.png
/usr/share/icons/oxygen/256x256/places/folder.png
/usr/share/icons/oxygen/48x48/places/folder.png
/usr/share/icons/oxygen/64x64/places/folder.png
/usr/share/icons/oxygen/22x22/places/folder.png
/usr/share/icons/Tango/32x32/places/folder.png
/usr/share/icons/Tango/16x16/places/folder.png
/usr/share/icons/Tango/24x24/places/folder.png
/usr/share/icons/Tango/22x22/places/folder.png
So there are different icons, there's an empty intersection with yours.
@Chris: I know you tested, but I didn't, and since we had some issues with configured X11 libs recently: how did you configure FLTK, and what does the configure summary show? Particularly the "Graphics" output that now shows the _found_ (i.e. available) libs. Here's my output:
Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender
Image Libraries are all "System".
If you use CMake and not autoconf/configure, can you please build with autoconf/configure and post the output? It's just a wild guess, but we should know if there are differences. | |
| |
| #11 | AlbrechtS
16:40 Oct 19, 2016 |
| OT, SCNR: WRT SVG format (nanosvg library): Thanks to Chris for the hint.
I could not resist and created a short demo program, please see STR #3345 for more information and source code. The library is small (~115 KB, only two header files that include the entire implementation).
Could be worth more investigation, but please don't reply here; reply to STR #3345 instead.
http://www.fltk.org/str.php?L3345 | |
| |
| #12 | chris
21:14 Oct 19, 2016 |
| @#10:
I usually just type 'make' nowadays. This is the output of the summary:
Configuration Summary
-------------------------------------------------------------------------
Directories: prefix=/usr/local
bindir=${exec_prefix}/bin
datadir=${datarootdir}
datarootdir=${prefix}/share
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${datarootdir}/man
Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender
Image Libraries: JPEG=System
PNG=System
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES | |
| |
| #13 | chris
21:17 Oct 19, 2016 |
| And here is my:
find /usr/share/icons | grep /folder.png
/usr/share/icons/HighContrast/24x24/places/folder.png
/usr/share/icons/HighContrast/16x16/places/folder.png
/usr/share/icons/HighContrast/32x32/places/folder.png
/usr/share/icons/HighContrast/48x48/places/folder.png
/usr/share/icons/HighContrast/22x22/places/folder.png
/usr/share/icons/HighContrast/256x256/places/folder.png | |
| |
| #14 | chris
21:23 Oct 19, 2016 |
| According to this post:
http://askubuntu.com/questions/132406/in-what-directorys-are-the-default-ubuntu-icons-located
icons for Ubuntu are in /usr/share/icons/Humanity.
They are soley in svg format there.
find /usr/share/icons | grep /folder.svg
/usr/share/icons/Humanity/places/48/folder.svg
/usr/share/icons/Humanity/places/24/folder.svg
/usr/share/icons/Humanity/places/32/folder.svg
/usr/share/icons/Humanity/places/16/folder.svg
/usr/share/icons/Humanity/places/22/folder.svg
/usr/share/icons/Humanity/places/64/folder.svg
/usr/share/icons/HighContrast/scalable/places/folder.svg | |
| |
| #15 | chris
06:17 Sep 21, 2017 |
| I changed Fl_File_Icon2.cxx to work with Ubuntu 12.04-17.04 - using the new SVG image support.
Despite the fact, that all the assumptions in Fl_File_Icon2.cxx about the places where icons are to be found are outdated for years and the whole logic should be re-written (or reduced to just use FLTK's default icons), I have tried to make only a minimal change to get it work with Ubuntu.
Uploading my changes as 'file_icon.diff'. Notes are to be found in the diff.
Also I attach an image with the filechooser program under Ubuntu with the patch. | |
| |
| #16 | greg.ercolano
15:07 Oct 28, 2017 |
| @chris / comment #14, I don't have a "Humanity" on my sci linux system,
but there is a HighContrast-SVG, e.g.
# find /usr/share/icons/ | grep /folder.svg
/usr/share/icons/Mist/scalable/places/folder.svg
/usr/share/icons/Mist/32x32/places/folder.svg
/usr/share/icons/Crux/scalable/places/folder.svg
/usr/share/icons/HighContrast-SVG/scalable/places/folder.svg
/usr/share/icons/gnome/scalable/places/folder.svg
Again, no intersection with either yours or Albrecht's systems.
Not sure what a good solution is, as neither a runtime recursive
dir search for folder.svg in /usr/share/icons, nor an inline
string copy of the svg file hard coded in the fltk source
is very appealing.. hrm. | |
| |
| #17 | chris
02:01 Oct 29, 2017 |
| I updated the change for Ubuntu (file #5) to fix a regression in the KDE case and to add svgz support. Uploaded as 'file_chooser2_ubuntu.diff' to file #7. See also my comment #15.
Pretty sure this will not make in into FLTK, but still it might be useful for some users.
I will post another patch that just implements the fallback to the internal FLTK icons shortly. | |
| |
| #18 | chris
02:10 Oct 29, 2017 |
| @Greg #8, #16: SciLinux is a Gnome system (as I have just learned), so the reason there are no icons seems to be the same as with Ubuntu (see my initial post #1). But SciLinux 6.3 is also pretty old (2011?), so there may be no SVG icon system, but another incompatible system to the one searched for in FLTK.
IMHO it is beyond the scope of FLTK to re-implement the Gnome icon logic. At best it could *use* the gnome libraries (dlopen()..) to determine the current theme icons for certain places and mimetypes.
Same could be possible for KDE systems. But is is worth it? And still there are other desktop types as well (Xfce...).
To put it short: it would be best to just ensure the fallback to FLTK's internal icons, which would solve this issue as well. | |
| |
| #19 | chris
02:11 Oct 29, 2017 |
| Uploded a patch 'file_icon2_fallback_default.diff' which tries to fallback to the default icons - for Ubuntu and hopefully other systems too.
I have tried to make it as minimal as possible. Also I did not change the (suboptimal) current indentation for the sake of diff readability.
The main change is, that if the KDE part fails, it falls back to the FLTK default icons. I also added svg/svgz extensions to the image icon.
@Greg: Would be good to know if this patch also falls back under SciLinux. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
