GNOME Bugzilla – Bug 120421
No obvious way to reach fonts:/// or themes:///
Last modified: 2008-05-18 15:31:47 UTC
Aside from menu entries which are tucked away in very obscure places, it should be easier for the user to find these facilities. For example, they could appear under the start-here:/// hierarchy, the same root as for smb:/// and applications:///.
Created attachment 19448 [details] This might be a nice way to make these new features more obvious to the user
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 102721 ***
Sorry, I've modified the wrong bug, I'm reopening this one ...
the same could be said for printers:///
Maybe placing them under Places (burn:/// is there already)
is there any need to get this in the nautilus menus/UI ? This place are open by buttons on the fonts/theme capplets, that should be enough.
*** Bug 164004 has been marked as a duplicate of this bug. ***
Bug 164004 asks the same thing but suggests to add the missing ones to the Places / Go menu (possibly under a Specials submenu).
" is there any need to get this in the nautilus menus/UI ? This place are open by buttons on the fonts/theme capplets, that should be enough. " What if we already have nautilus open? :) Its accessed through nautilus in the first place, so it should be visible in nautilus at all times. I like the "Places" idea.
fonts:/// - Applications->Preferences->Fonts->Details->View font folder Seems a bit out or reach yeah themes:/// - Applications->Preferences->Themes->Details->View theme folder Same here, and this only opens the user's theme folder, not the systemwide one burn:/// - can't be reached AFAICS... I'm not fond of overloading the "Places" menu with anything we can think of, but as long as we're going to keep them they might as well be first class citizens?
burn:/// can be reached through the "Places" menu. Changing summary.
Ubuntu bug about that: https://launchpad.net/products/nautilus/+bug/35371
still valid.
Using or knowing about fonts:///, ~/fonts or fc-cache shouldn't be necessary. I agree that accesss to fonts:/// should be made more prevalent in GNOME, but I don't think it should be required to install new fonts. When a user downloads a new font fron the web or otherwise get a font file onto his GNOME desktop, he should be able to just right- or double-click it and choose "Install font". He should of course be able to view and uninstall the same font from fonts:/// later if he chooses, but I think that having to use fonts:/// to install a font in the first place is a bit sideways of how it can and should be implemented.
(In reply to comment #14) > When a user downloads a > new font fron the web or otherwise get a font file onto his GNOME desktop, he > should be able to just right- or double-click it and choose "Install font". Agreed. Not that I think such comparison is necessary or duplication always a valid goal, but here is how this is implemented on Mac OS X: http://www.ucs.ed.ac.uk/usd/cts/ol/os/mac_osx/Panther/images/fontbook_preview.gif
Since the fonts:// and themes:// backends are deprecated in GVFS/GNOME 2.22, I'm closing this as obsolete; IMO the correct thing to do for fonts is to fix bug 495510 and/or bug 128400 (as a nautilus-extension that would ship with g-c-c). Themes could get similar treatment, or be entirely managed by the Appearance capplet.