(In reply to Karl Tomlinson (:karlt) from comment #17)
> Comment on attachment 813885
> 0001-Bug-417952-Open-Containing-Folder-doesn-t-highlight-.patch
>
> Thank you for working out how to do this, Nelson. This looks like the right
> approach.
You're welcome!, and sorry for getting back to you after a couple weeks but
I've been busy lately with only some spare time on weekends.
> Putting this in the nsGIOService is fine, even though the current
> implementation doesn't use GIO, because GIO's GDBus will be the preferred
> DBus
> library once Mozilla is no longer supporting older systems, and the method is
> similar to other existing methods on nsGIOService.
>
> The interface can be simplified to just one additional method on
> nsIGIOService
> that returns NS_ERROR_NOT_AVAILABLE or similar when FileManager1 is not
> available.
Done.
> ListActivatableNames doesn't sound like what we want here. I assume that is
> looking for /usr/share/dbus-1/services/org.freedesktop.FileManager1.service,
> but the interface may be provided by a non activatable application such as a
> daemon in the desktop environment. That is in fact the appropriate way to
> support the interface because it means that different applications can be
> selected by the user [1]. What Nautilus does [2][3] is unfortunate because
> it
> means that people that don't want Nautilus used to reveal a file will have to
> uninstall nautilus from the system, removing the option of other users using
> Nautilus.
Yes you're right, although file managers are a somewhat special case of a
program
very attached to its desktop environment, but they should still play well with
other file managers. Thanks for the links.
> The simplest approach would be to use the synchronous dbus_g_proxy_call() so
> that we know whether the call succeeds. Given this particular use of DBus
> where the user is wanting to open a new application, or at least a new
> window,
> which is going to take time, the additional round trip time via the DBus
> daemon is not going to be major.
Done, using dbus_g_proxy_call() now.
> Perhaps the call could set a flag if it fails, in order to save checking the
> DBus call each time for systems without FileManager1, or perhaps there is a
Done.
> way to register for notifications when the interface becomes available, but
> that may be more trouble than it is worth. Similarly I imagine there is a
> notification when the interface is no longer available (the "destroy" signal
> maybe?) so the call would need only be synchronous the first time, but that
> can be a future optimization when necessary.
I left this out of the patch to keep it simple, but as you said it can be added
in a future update.
> Gecko file style is to use spaces for indentation, with no tabs.
>
> Call dbus_connection_set_exit_on_disconnect(dbusConnection, false) in case
> this is the first use of the connection.
Done.
> >+ char *uris[2] = { (char*)PromiseFlatCString(uri).get(), NULL };
>
> The PromiseFlatCString usage is not good because the pointer is used after
> the
> PromiseFlatCString is destroyed.
> I expect uri.get() can be used here.
>
> Please use const_cast instead of (char*), or, perhaps better, make this
> const char *uris[2].
Done.
> (In reply to Nelson Benítez León from comment #12)
> > some file managers when
> > passed a full uri would try to 'run' the file (as was thunar in xfce or
> > konqueror in kde)
>
> I was surprised by that behavior too. I think there is a KDE bug report on
> that.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/599846
Title:
firefox right click open containing folder should highlight file
Status in The Mozilla Firefox Browser:
Confirmed
Status in “firefox” package in Ubuntu:
Confirmed
Bug description:
Binary package hint: firefox
The only reason I am assuming this is a bug is because the
functionality is in Windows. Basically, if the user right clicks on a
file in the Downloads of Firefox and selects "Open Containing Folder",
Nautilus should open with the file highlighted to make the file easier
to find.
1) The release of Ubuntu you are using, via 'lsb_release -rd' or System ->
About Ubuntu.
Description: Ubuntu 10.04 LTS
Release: 10.04
2) The version of the package you are using, via 'apt-cache policy
packagename' or by checking in Synaptic.
Installed: 3.6.3+nobinonly-0ubuntu4
Candidate: 3.6.3+nobinonly-0ubuntu4
Version table:
*** 3.6.3+nobinonly-0ubuntu4 0
500 http://us.archive.ubuntu.com/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
3) What you expected to happen
I expected my file to be highlighted.
4) What happened instead
Nautilus opened, but the file was not highlighted.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Tue Jun 29 11:15:58 2010
FirefoxPackages:
firefox 3.6.3+nobinonly-0ubuntu4
firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
firefox-branding 3.6.3+nobinonly-0ubuntu4
abroswer N/A
abrowser-branding N/A
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: firefox
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/599846/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
