Re: Showing a file in the file manager
On Thursday, 22 de September de 2011 19:51:31 Aleksei Lissitsin wrote: > This could be a nice approach. The D-Bus service file for FileManager1 > could then just (be installed by and) call xdg-open to start the right > file manager if none is running. D-Bus requires that the process it starts claim the name. If this process exits before the name is claimed, the message will return to sender. If another PID claims the name, it's undefined. I don't remember what happens. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, Sep 22, 2011 at 4:09 PM, Kevin Krammer wrote: > As long as none of the file managers installs a D-Bus service file for the > given interface there shouldn't be any problem. > The call will either go to an already running file manager, which we can then > savely assume to be the correct one, or fail. This could be a nice approach. The D-Bus service file for FileManager1 could then just (be installed by and) call xdg-open to start the right file manager if none is running. Of course, this might not be the expected behavior in some cases. For more controlled behavior one might need to implement FileManager1 interface by some kind of "xdg_open for D-Bus" or assume that DE-specific preferred application systems start to have control on which applications can register which interfaces (or at least control over D-Bus service files). Aleksei ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, Sep 22, 2011 at 1:42 PM, Jannis Pohlmann wrote: > On Thu, 22 Sep 2011 02:07:11 -0500 > Federico Mena Quintero wrote: > IMHO that's a bad idea. Bypassing DE-specific checks and forwarding > straight to the FileManager1 service means that, on a multi-user system > with multiple file managers installed, people may easily end up > launching file managers other than the one they expect to see. I second that opinion. It would be more trivial to propose a new MIME type, say inode/x-reveal-file, that would be resolved by xdg-open when requested to "reveal" a file in a suitable management interface. -- Patryk Zawadzki I solve problems. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: basedir-spec: machine specific config files
Hello, > Do you have a provision for handling hundreds of clients with the same > hardware? At the moment, for e.g. ~/.config/monitors.xml, the data is > keyed on monitor type (name, product ID, etc.), so it's possible to > configure your preferred resolution for e.g. all Dell 2407WFPs at once. > (Granted, in implementation this doesn't work amazingly and I've seen > people end up with monitors.xml files specifying 800x600 on all monitors > unconditionally, but that's an implementation bug, not a design flaw.) In theory, this should be a solution. But if we leave it to the application developer to come up with a solution to handle different hardware everyone will implement it in another way creating quite a mess. And I bet there will be some that do not care at all. > In your proposal, there isn't actually a good way to make changes that > appear on the same hardware. We run 400+ networked machines with more or > less identical hardware (on purpose) with shared home directories. As > rooms get reconfigured, spaces change, etc., we might add or remove > machines at any time. The best solution I can see in your proposal is to > have a script to create 400+ symlinks hard-coding each machine hash. > Meanwhile, the current setup already works fine, so this wouldn't make > things any better in networked homedirs as we implement them. That is indeed a problem. We could fall back to a default config directory if there is no available with the unique hardware id. This would work for companies, universities, ... like today but would not solve the problem when you have several hundred machines with hardware configuration 1 and another thousand with completely different configuration 2. I have no idea how to solve this at the moment, though. > Do you have a specific use case in mind? For devices with radically > different form factors, does it actually make sense to use the same home > directory (are you currently doing this)? My use case is two somewhat different desktop computers which share /home and a notebook, on which I rsync /home each time I leave / come back. All these computers run the same software, but some settings have to be different. Since KDE plasma active is supposed to run on tablets and similar touch- enabled devices, I think there might be even more problems if someone tries to share /home with it in the future. > And even if so, wouldn't it make sense for some of those devices to just > change $XDG_CONFIG_DIR to, say, ~/.config.tablet? I would not mind a solution similar to that for my use case. That is, I would change $XDG_MACHINE_DIR to some non-defalut location on login, but I'd like to keep the hardware independent config in sync. > (By the way, were you to implement this, please see if using > /var/lib/dbus/machine-id instead of your own machine hash function will > meet your needs.) Maybe, a unique machine id is not a good idea after all. What about reading a "hardware platform id" from some global configuration file that would be identical on identical hardware (e. g. in a company)? > 2) higher level: based on branches in a version control system, I can have > different stuff $XDG_CONFIG_HOME the additional benefit heres is that you can > merge from one branch to another, also with a VCS you can have a good "mix > and match" between branches with things like git submodules and > svn:externals, while maintaining full diff-ablities and not having stuff > that are not needed checked out in your home directory. With a system like > you describe I can't see a workflow that allows those 3 at the same time. You are right, that will not work. But is it really necessary to "not having stuff that are not needed checked out in your home directory"? I do not see how this will be a real problem if you are using e. g. three different hardware platforms that do not share machine-specific config? I am not sure there are many who want to use a vcs for config file management, but these who want could still use a vcs in the default config directory. I am not saying my proposal is the way to go, it is just an idea I came up with to solve my use case. I am happy if there are better proposals how to solve it. Kind regards, Ole signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thursday, 2011-09-22, Bastien Nocera wrote: > On Thu, 2011-09-22 at 15:09 +0200, Kevin Krammer wrote: > > On Thursday, 2011-09-22, Jannis Pohlmann wrote: > > > IMHO that's a bad idea. Bypassing DE-specific checks and forwarding > > > straight to the FileManager1 service means that, on a multi-user system > > > with multiple file managers installed, people may easily end up > > > launching file managers other than the one they expect to see. > > > > > > The same problem occurs if applications start using the FileManager1 > > > service for opening folders directly (and other features that we might > > > add to the interface in the future). Let's say a GNOME application does > > > that and both, Nautilus and Thunar are installed. Which one is going to > > > pop up? Is there any solution to this? > > > > As long as none of the file managers installs a D-Bus service file for > > the given interface there shouldn't be any problem. > > The call will either go to an already running file manager, which we can > > then savely assume to be the correct one, or fail. > > Which is absolutely useless for GNOME 3.x as nautilus (our file manager) > doesn't run by default. I was just addressing Jannis' concern that the wrong file manager would be started, which will not be the case. xdg-open will still need to start the fm program depending on DE, but can then delegate the opening/selecting via D-Bus. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, 2011-09-22 at 15:09 +0200, Kevin Krammer wrote: > On Thursday, 2011-09-22, Jannis Pohlmann wrote: > > > IMHO that's a bad idea. Bypassing DE-specific checks and forwarding > > straight to the FileManager1 service means that, on a multi-user system > > with multiple file managers installed, people may easily end up > > launching file managers other than the one they expect to see. > > > > The same problem occurs if applications start using the FileManager1 > > service for opening folders directly (and other features that we might > > add to the interface in the future). Let's say a GNOME application does > > that and both, Nautilus and Thunar are installed. Which one is going to > > pop up? Is there any solution to this? > > As long as none of the file managers installs a D-Bus service file for the > given interface there shouldn't be any problem. > The call will either go to an already running file manager, which we can then > savely assume to be the correct one, or fail. Which is absolutely useless for GNOME 3.x as nautilus (our file manager) doesn't run by default. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thursday, 2011-09-22, Jannis Pohlmann wrote: > IMHO that's a bad idea. Bypassing DE-specific checks and forwarding > straight to the FileManager1 service means that, on a multi-user system > with multiple file managers installed, people may easily end up > launching file managers other than the one they expect to see. > > The same problem occurs if applications start using the FileManager1 > service for opening folders directly (and other features that we might > add to the interface in the future). Let's say a GNOME application does > that and both, Nautilus and Thunar are installed. Which one is going to > pop up? Is there any solution to this? As long as none of the file managers installs a D-Bus service file for the given interface there shouldn't be any problem. The call will either go to an already running file manager, which we can then savely assume to be the correct one, or fail. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: basedir-spec: machine specific config files
On Thu, 22 Sep 2011, Niels Ole Salscheider wrote: Hello, I would like to propose to distinguish between machine specific and machine independent config files for the next basedir-spec. So machine dependent config files could be stored in e. g. $XDG_MACHINE_HOME/some_machine_hash/. This is beneficial for a home directory that is shared across several devices with different form factors. So the screen resolution, positions of desktop widgets, power settings, ... can be stored in the machine dependent directory while sharing all other settings. If you want to log from another client with the same hardware, you can still crate a symlink to some default directory. Hi Ole, Do you have a provision for handling hundreds of clients with the same hardware? At the moment, for e.g. ~/.config/monitors.xml, the data is keyed on monitor type (name, product ID, etc.), so it's possible to configure your preferred resolution for e.g. all Dell 2407WFPs at once. (Granted, in implementation this doesn't work amazingly and I've seen people end up with monitors.xml files specifying 800x600 on all monitors unconditionally, but that's an implementation bug, not a design flaw.) In your proposal, there isn't actually a good way to make changes that appear on the same hardware. We run 400+ networked machines with more or less identical hardware (on purpose) with shared home directories. As rooms get reconfigured, spaces change, etc., we might add or remove machines at any time. The best solution I can see in your proposal is to have a script to create 400+ symlinks hard-coding each machine hash. Meanwhile, the current setup already works fine, so this wouldn't make things any better in networked homedirs as we implement them. Do you have a specific use case in mind? For devices with radically different form factors, does it actually make sense to use the same home directory (are you currently doing this)? And even if so, wouldn't it make sense for some of those devices to just change $XDG_CONFIG_DIR to, say, ~/.config.tablet? (By the way, were you to implement this, please see if using /var/lib/dbus/machine-id instead of your own machine hash function will meet your needs.) -- Geoffrey Thomas geo...@mit.edu ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: basedir-spec: machine specific config files
On Thu, 22 Sep 2011 13:18:16 +0200 Niels Ole Salscheider wrote: > Hello, > > I would like to propose to distinguish between machine specific and > machine independent config files for the next basedir-spec. So > machine dependent config files could be stored in e. g. > $XDG_MACHINE_HOME/some_machine_hash/. > > This is beneficial for a home directory that is shared across several > devices with different form factors. So the screen resolution, > positions of desktop widgets, power settings, ... can be stored in > the machine dependent directory while sharing all other settings. > > If you want to log from another client with the same hardware, you > can still crate a symlink to some default directory. > > Regards, > > Ole personally I prefer something "higher-level" or more app-specific/fine-grained. Examples: 1) app-specific & fine-grained: I have a program "mde", which config file is bash-bashed, so I have a file $XDG_CONFIG_HOME/mde/config, which internally contains stuff like: if [ $(hostname) == "$somehost" ]; then ; else; ; fi. This allows finegrained control and much more flexibility to configure things how I want it. 2) higher level: based on branches in a version control system, I can have different stuff $XDG_CONFIG_HOME the additional benefit heres is that you can merge from one branch to another, also with a VCS you can have a good "mix and match" between branches with things like git submodules and svn:externals, while maintaining full diff-ablities *and* not having stuff that are not needed checked out in your home directory. With a system like you describe I can't see a workflow that allows those 3 at the same time. In short: per-machine configuration should IMHO not go into the basedir spec, as it's a poor solution. Dieter ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, 22 Sep 2011 02:07:11 -0500 Federico Mena Quintero wrote: > On Thu, 2011-09-22 at 03:06 +0300, Aleksei Lissitsin wrote: > > > Was there any update/agreement on the issue? > > Yes on the agreement. And sorry! I totally forgot to post an update > about this to the list. > > This is the tentative patchset we have for Nautilus: > https://bugzilla.gnome.org/show_bug.cgi?id=636269 > > It's still under review/discussion, but you can see the D-Bus stuff in > there. > > > Will there be added --select parameter to xdg-open or > > the users will have to use DBus directly? > > Frankly I'd prefer it if people used D-Bus directly (you can always do > "dbus-send blah blah" from the command line). > > This sounds like the right time to implement xdg-open as a D-Bus > method itself in the FileManager1 service. Then, xdg-open(1) could > try calling that method, and if it's not available, then xdg-open > would do its usual thing. (Maybe that *is* the way things work right > now; I haven't read the xdg-open sources closely.) IMHO that's a bad idea. Bypassing DE-specific checks and forwarding straight to the FileManager1 service means that, on a multi-user system with multiple file managers installed, people may easily end up launching file managers other than the one they expect to see. The same problem occurs if applications start using the FileManager1 service for opening folders directly (and other features that we might add to the interface in the future). Let's say a GNOME application does that and both, Nautilus and Thunar are installed. Which one is going to pop up? Is there any solution to this? - Jannis ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
basedir-spec: machine specific config files
Hello, I would like to propose to distinguish between machine specific and machine independent config files for the next basedir-spec. So machine dependent config files could be stored in e. g. $XDG_MACHINE_HOME/some_machine_hash/. This is beneficial for a home directory that is shared across several devices with different form factors. So the screen resolution, positions of desktop widgets, power settings, ... can be stored in the machine dependent directory while sharing all other settings. If you want to log from another client with the same hardware, you can still crate a symlink to some default directory. Regards, Ole signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Showing a file in the file manager
On Thu, 2011-09-22 at 03:06 +0300, Aleksei Lissitsin wrote: > Was there any update/agreement on the issue? Yes on the agreement. And sorry! I totally forgot to post an update about this to the list. This is the tentative patchset we have for Nautilus: https://bugzilla.gnome.org/show_bug.cgi?id=636269 It's still under review/discussion, but you can see the D-Bus stuff in there. > Will there be added --select parameter to xdg-open or > the users will have to use DBus directly? Frankly I'd prefer it if people used D-Bus directly (you can always do "dbus-send blah blah" from the command line). This sounds like the right time to implement xdg-open as a D-Bus method itself in the FileManager1 service. Then, xdg-open(1) could try calling that method, and if it's not available, then xdg-open would do its usual thing. (Maybe that *is* the way things work right now; I haven't read the xdg-open sources closely.) > Is the interface name org/freedesktop/FileManager1 > and methods names proposed by PCMan agreed upon? Yes, please see the bug mentioned above for the details. Federico ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
