Re: mime apps specification
On Wednesday, 2014-04-02, 17:06:47, David Faure wrote: > After so many years, he's finally a proposal for a unified mechanism for > selecting the default application for a given mimetype. > > The mechanism is unified, but note that it supports different defaults for > different desktop environments, if so desired. > > This is the result of a discussion with Ryan Lortie, Alex Larsson and > myself, I'm sending it here for further comments before pushing it to the > git repo. Great work guys! 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: volatile config data and XDG Base Directory spec
On Saturday, 2014-02-22, 22:14:50, Thomas Koch wrote: > On Wednesday, February 19, 2014 01:40:39 PM Simon McVittie wrote: > > On 18/02/14 23:53, Richard Hartmann wrote: > > > > the difference between DATA and STATE appears to be "STATE doesn't > > contain much data, and doesn't need to be sync'd across machines". But > > surely if it's small, it doesn't matter if it gets sync'd across > > machines unnecessarily? If an application wants to store explicitly > > per-machine state, it can use the D-Bus/systemd machine ID as a key, > > like GNOME does for display settings (I know that's config rather than > > state, but the principle is the same). > > Well, you're pinpointing it. Syncing window positions or recently opened > files across machines would lead to undesired behaviour because different > machines have different screen setups and differnt sets of files. You put > the burden on the application developer to distinguish between machines, > but that's unrealistic. The xdg-basedir-spec should rather help by > providing a directory for state information that makes sense only in the > context of this machine. Sorry, slighly offtopic, but: Window geometry is a rather bad example for a machine specific state, since it is screen setup specific. Either application developers really want the burden of handling that themselves, in which case they need to track screen configurations somehow, or they do the sensible thing and let the workspace shell/window manager handle it for them. My rather limited knowlegde around Wayland even suggests, that the latter will be the only option there anyway. 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: volatile config data and XDG Base Directory spec
On Thursday, 2014-02-20, 08:57:34, Richard Hartmann wrote:
> On Wed, Feb 19, 2014 at 6:41 PM, Kevin Krammer wrote:
> > Like the other variables there would be a specified default, so configure
> > (or whatever) could peform the check and fall back to the default or a
> > shell substitution expression could be used, etc.
>
> Those defaults are internal to programs; all a program would see in this
> case is
>
> ./foo --prefix=''
>
> as shell expansion would happen before that. I know what you meant,
> but the fact is that you can never solely rely on XDG variables in an
> interactive shell.
Sorry, probably using wrong terminology :)
I meant something like
./foo --prefix=${XDG_INSTALL_HOME:-$HOME/.local}
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: volatile config data and XDG Base Directory spec
On Wednesday, 2014-02-19, 17:42:37, Richard Hartmann wrote: > On Wed, Feb 19, 2014 at 1:40 PM, Simon McVittie > > But > > surely if it's small, it doesn't matter if it gets sync'd across > > machines unnecessarily? If an application wants to store explicitly > > per-machine state, it can use the D-Bus/systemd machine ID as a key, > > like GNOME does for display settings (I know that's config rather than > > state, but the principle is the same). > > Thanks for this; it highlights precisely why state is needed. > > This is not about storage size, it is about churn in configuration files. > > Looking at, e.g., geeqie, there's a section called in > geeqierc.xml. This contains window size, last path, and a plethora of > stuff configuration management does not care about. > > Assuming you put your configuration under proper version control, this > state information changes all the time. It is not something you want > to sync between machines for several reasons. You are synching state > information which may be invalid (lastpath), non-applicable (desktop > resolution settings on a netbook), or outright harmful (this directory > is not needed any more). Additionally, you are filling your VCS > history with random noise, making tracking the actual changes harder. > This results in broken workflows, manual rewriting/pruning of state, > or outright breakage. > > And _that_ is why Thomas, me, and others consider carrying state in > configuration such an issue. So it is mostly about developers using the same file for config and state instead of using a separete state file? If it where in a different file, even in the same location, then only the actual config file would be tracked by the VCS and the state files would not. 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: volatile config data and XDG Base Directory spec
On Wednesday, 2014-02-19, 18:16:24, Richard Hartmann wrote: > On Wed, Feb 19, 2014 at 3:17 PM, Kevin Krammer wrote: > > [1] which would have the added benefit of being something that can be > > passed to a user local software build, e.g. configure --prefix > > $XDG_INSTALL_HOME > Just to play devil's advocate: If that's unset, bad things can happen. > Yes, whatever is parsing --prefix should guard against it, but still. Yes, true, I wasn't actually suggesting that literaly :) Like the other variables there would be a specified default, so configure (or whatever) could peform the check and fall back to the default or a shell substitution expression could be used, etc. I think the usual syntax for meaning "the value of the variable or, if unset or empty, the default" is to use the name in all lower case. So confgure --prefix $xdg_install_home :) Anyway, just wanted to point out that if there is a need for a location that can host user installed extension instead of data, then the better approach might be addng a location for that instead of moving data to a new one. 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: volatile config data and XDG Base Directory spec
On Wednesday, 2014-02-19, 08:03:36, Ryan Lortie wrote: > In general, I'd like to tell people that "If your program wants to > install things like plugins|fonts|etc, put them in XDG_DATA_HOME. All > other state goes in XDG_CONFIG_HOME. This includes things like > databases and game state and save files." I think that cat is out of the bag. Applications have been using DATA_HOME for data for quite a while now. If we want to have an INSTALL_HOME [1], we should add that. Using CONFIG_HOME as the root for everything doesn't sound like a good idea, IMHO even worse then using DATA_HOME for everything. Cheers, Kevin [1] which would have the added benefit of being something that can be passed to a user local software build, e.g. configure --prefix $XDG_INSTALL_HOME -- 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: More about "intents": Several improvements to desktop files and caches
Hi, On Monday, 2014-01-06, 13:24:28, Ryan Lortie wrote: > hi, > > On Mon, Jan 6, 2014, at 10:31, Kevin Krammer wrote: > > Wouldn't it make more sense to be able to derive the object path from the > > name? > > This way an application which has multiple interfaces can implement them > > with > > different objects but could opt to just register the same object for > > multiple > > paths. > > > > Having a fixed path makes the second case easier but the first hard or > > impossible. > > This isn't really how D-Bus works. You can register multiple interfaces > at the same object path independently of each other. I know, sorry for the misunderstanding, let me try to rephrase: at least in the object oriented languages which have D-Bus bindings, it is common to have a single object instance per D-Bus object path. Such an object can, of course, implement multiple interfaces. If the intents specification declares that there is only a single object path for intents interfaces, then this is limiting the developer to exactly that choice (or using a mediator object the demultiplexes, i.e. a lot more work). If the specification has one path per interface, then developers can easily still have one object for all paths/interfaces, but also one object per path/interface. 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: More about "intents": Several improvements to desktop files and caches
On Monday, 2014-01-06, 15:37:33, Jerome Leclanche wrote: > On Mon, Jan 6, 2014 at 3:29 PM, Kevin Krammer wrote: > > On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote: > >> There's a lot TBD still. For example: Do we require apps implementing > >> an intent to support every method of the intent? I don't think it's > >> necessary due to dbus introspection letting us figure out whether a > >> method is supported. > > > > If an intent has an associated D-Bus interface, then IMHO all methods > > should be available. > > > > E.g. if I am a contact editor and have an optional feature to take a > > contact picture from the camera, then I would check the intents cache for > > xdg.intents.Camera. > > If I find one (or the preferred one if there are more than on) I expect a > > call to xdg.intents.Camera.TakePicture to be available. > > > > I don't want to have to start each camera provider to do runtime > > introspection. > > > > Cheers, > > Kevin > > -- > > Kevin Krammer, KDE developer, xdg-utils developer > > KDE user support, developer mentoring > > > > ___ > > xdg mailing list > > xdg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xdg > > You run the risk anyway though, as a new method might be officially > added later on to the intent (especially with non-freedesktop > namespaced intents). Quoting Bastien Nocera: "D-Bus-style name. This allows namespacing and versioning." I mean, what is an intent good for if a service can claim to provide it but actually not do it? 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: More about "intents": Several improvements to desktop files and caches
On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote: > There's a lot TBD still. For example: Do we require apps implementing > an intent to support every method of the intent? I don't think it's > necessary due to dbus introspection letting us figure out whether a > method is supported. If an intent has an associated D-Bus interface, then IMHO all methods should be available. E.g. if I am a contact editor and have an optional feature to take a contact picture from the camera, then I would check the intents cache for xdg.intents.Camera. If I find one (or the preferred one if there are more than on) I expect a call to xdg.intents.Camera.TakePicture to be available. I don't want to have to start each camera provider to do runtime introspection. 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: More about "intents": Several improvements to desktop files and caches
On Sunday, 2014-01-05, 21:42:47, Ryan Lortie wrote: > hi, > > On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote: > > Problem #1 > > Apps cannot enumerate other apps of a specific type. A couple of > > It is my "intent" (ha...) to raise for a while that I want to introduce > a new key to desktop files called "Implements". There is already some > discussion about that here: > https://bugzilla.gnome.org/show_bug.cgi?id=712391 > > > In terms of the desktop entry spec, such an addition would be extremely > simple: we have a new 'string list' key called "Implements" with no > particular meaning except that each entry in the list is expected to be > in D-Bus interface name style. > > This would solve your "enumerate apps of a specific type" assuming that > you have someone willing to specify, concretely, what it means to be a > given type of application. Taking your 'terminal emulator' example from > another part of this mail, we could have an > org.freedesktop.TerminalEmulator interface (that may not be an actual > D-Bus interface) that specifies what you must do if you're a terminal > emulator and what you can expect a terminal emulator to do if you find > its desktop file via a lookup on > "Implements=org.freedesktop.TerminalEmulator". > > *Often* this will imply that an application implements said interface on > the same object path as the org.freedesktop.Application interface, but > this is not a hard requirement. I suspect it would be a recommendation, > though. Wouldn't it make more sense to be able to derive the object path from the name? This way an application which has multiple interfaces can implement them with different objects but could opt to just register the same object for multiple paths. Having a fixed path makes the second case easier but the first hard or impossible. 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: Binary name in the desktop file
On Friday, 2013-12-27, 15:24:43, Jerome Leclanche wrote: > On Fri, Dec 27, 2013 at 3:01 PM, Kevin Krammer wrote: > > On Thursday, 2013-12-26, 15:34:03, Jerome Leclanche wrote: > >> I'm sorry, you're right. I should have been clearer. > >> > >> I need this functionality for intents, but I was just trying to > >> display that I'm not the only one actually needing it (and that it's > >> not just theoretical). > > > > I have to admit I didn't follow that closely enough, but wouldn't the > > program authors have to specify the invocation for intents instead of > > relying that the program without arguments is the correct one? > > Not specifically - intents don't inherently run a program any more > than the shared-mime-info spec does. They only determine which > programs should be ran. > For DBus-activatable apps this is a non-issue of course but not all > programs are like that. Ah, I see. I thought that apps might have to be aware that they are launched via intents. > >> Currently, Wine creates the sort of desktop > >> files I pasted in the original post. This causes runners (like > >> lxqt-runner) to think those programs should be displayed when you > >> start writing "env" (they are completely irrelevant and the use of > >> "env" is an implementation detail). > > > > Hmm. I guess if you type "env" you would like to have /usr/bin/env as a > > suggestion, no? > > The runner that searches $PATH would detect that already. > > > > If there is a runner that gives suggestions on .desktop file Exec lines > > then those are relevant hits as well. I would have guesses that the > > .desktop runner only checks name and description though, since the > > command line is usually hidden from the users and wouldn't tell them > > anything. > > Yup, all well and good, and the current behaviour on the runner's side > is the correct one. However you're unlikely to want nearly every Wine > app if you type in "env". Currently, /usr/bin/env is the only way to > modify the environment for the program being ran, which creates this > conflict. I would find it weird if a .desktop runner source would look into Exec lines since those are highly irrelevant to the user. So an input of "env" would only show the env binary as it is found in $PATH. > >> I guess it is too late to fix it, but my backwards-compatible proposal > >> would do the job for apps that care about it. If it's missing, we just > >> assume the app starts the same way with and without args. > > > > I don't think it is, there is always room for improving the spec. > > > > After thinking about it a bit more the name ExecNoArgs might be a bit > > confusing. The command line specified in it could very well have > > arguments, > > just no variables. > > > > Also, if present but empty, that could be treated as "cannot be launched > > without file/urls". > > Agreed on the name; I don't like it either I just needed a clear example. > I don't think it's too late to fix the spec from an implementation > point of view, but it does feel like it's too late to convince people > this is worth the modification (and I don't have time to defend tooth > and nail fixes to all my pet peeves). A specification, or an extension of one, needs to address a use case. That use case needs to be well understood, otherwise it will be hard or even impossible to write the respective spec text properly and/or unclear how it should be used or implemented. I think the use case is quite clear now [1], but got buried in the totally unrelated environment discussion. > The "present but empty" functionality has interesting potential. That is something that would have to be evaluated/discussed, otherwise we might end up needing yet another extension. Cheers, Kevin [1] A launcher, e.g. app menu, needs to be able to launch an application without providing and values for Exec line variable substitutions. Applications for which the Exec line with all variables relaced with nothing is not the appropriate launch command, need to specify a separate Exec like key named -- 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: Binary name in the desktop file
On Thursday, 2013-12-26, 15:34:03, Jerome Leclanche wrote: > I'm sorry, you're right. I should have been clearer. > > I need this functionality for intents, but I was just trying to > display that I'm not the only one actually needing it (and that it's > not just theoretical). I have to admit I didn't follow that closely enough, but wouldn't the program authors have to specify the invocation for intents instead of relying that the program without arguments is the correct one? > Currently, Wine creates the sort of desktop > files I pasted in the original post. This causes runners (like > lxqt-runner) to think those programs should be displayed when you > start writing "env" (they are completely irrelevant and the use of > "env" is an implementation detail). Hmm. I guess if you type "env" you would like to have /usr/bin/env as a suggestion, no? The runner that searches $PATH would detect that already. If there is a runner that gives suggestions on .desktop file Exec lines then those are relevant hits as well. I would have guesses that the .desktop runner only checks name and description though, since the command line is usually hidden from the users and wouldn't tell them anything. > I should probably have written two separate mails for this but this > seemed relevant. Anyway, that specific use case is fixed with an > Environment key, which would be easy enough to implement (and > backwards compatibility would be unharmed). Sure, though I am not convinced that it is necessary, mostly because it is only one of potential runtime requirements. A start script can easily deal with environment setup additional to any other setup stage, e.g. launching a service. It can even make decisions on the already existing environment, like the user as Ma Xiaojun mentioned. Anyway, not really related to the No Args use case. > More generic: > desktop files make the assertion that starting a program is inherently > the same *with* and *without* arguments. This is declaratively very > annoying, because it prevents programs from having a different command > line for args / no args. True, good point. > I guess it is too late to fix it, but my backwards-compatible proposal > would do the job for apps that care about it. If it's missing, we just > assume the app starts the same way with and without args. I don't think it is, there is always room for improving the spec. After thinking about it a bit more the name ExecNoArgs might be a bit confusing. The command line specified in it could very well have arguments, just no variables. Also, if present but empty, that could be treated as "cannot be launched without file/urls". 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: Binary name in the desktop file
On Thursday, 2013-12-26, 14:46:13, Jerome Leclanche wrote: > I'm somewhat losing track of what's actually being said here. Yes, sorry. This particual sub thread discusses why you need a special solution in the first place. For example the snippet you posted had clearly /usr/bin/env as the command, but somehow this is not the one you are expecting. This lead to the assumption that you are either expecting wine or start.exe to be the one you'd like to have. In both cases the .desktop file is using hacks or helpers to ensure the required runtime for the actual command. So we were discussing proper ways of ensure that command in the Exec line is actually the command and ensures itself that its runtime requirements are met. In both possible alternative cases, i.e. independed of whether you consider wine or start.exe to be the target command, an appropriate start script would have solved that without requiring any extra support in either spec or launchers. E.g. a wine.sh that gets start /ProgIDOpen chm.fie.%f as its arguments in the case of wine being the actual target command or start.exe.sh that gets /ProgIDOpen chm.file %f as its argument in case of start.exe being the actual target command. In other words avoiding the problem to exist in the first place instead of trying to work around it. 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: Binary name in the desktop file
On Thursday, 2013-12-26, 21:18:43, Ma Xiaojun wrote: > On Thu, Dec 26, 2013 at 8:09 PM, Kevin Krammer wrote: > > If wine cannot accept the prefix as a command line argument, then this > > should use a script that adjusts the environment accordingly before > > calling the binary. > > > > I just don't see how adding an addtional key would make people who prefer > > hacks over proper solutions magically use proper solutions. > > What are proper solutions? Well, in the case at hand a script that ensures the desired environment and then launches the program. A quite common pattern, usually called a starter script. > Every program should have command line arguments for what can be > specified in command line arguments? I am afraid I don't get that. Every command line argument should be a command line argument? Isn't that being a command line argument the definition of a command line argument? > Every program should have a wrapper script? Well, how to change > environment on per user basis? Most script languages can evaluate conditions, some have access to the environment, e.g. $USER. Anyway, how do you do that in an Exec line and how does the same mechanism allow to pass user specific settings to a binary but not to a starter script? 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: Binary name in the desktop file
On Thursday, 2013-12-26, 11:56:57, Jerome Leclanche wrote: > My point is, "env" is not what you should get for this. Wine is just > using env as a "hacky" way to give wine the WINEPREFIX variable. A "broken" .desktop file like that would very likely also have a broken ExerNoArgs entry, no? As far as the specification goes, env is the program that is being excuted, the other elements are arguments to it. If wine cannot accept the prefix as a command line argument, then this should use a script that adjusts the environment accordingly before calling the binary. I just don't see how adding an addtional key would make people who prefer hacks over proper solutions magically use proper solutions. 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: Binary name in the desktop file
On Thursday, 2013-12-26, 11:33:13, Jerome Leclanche wrote: > On Thu, Dec 26, 2013 at 11:25 AM, Kevin Krammer wrote: > > On Thursday, 2013-12-26, 10:56:11, Jerome Leclanche wrote: > >> I'd really like to be able to get the binary name from desktop files > >> (eg a way to "start without any argument"). Current implementations > >> rely on getting the first word of the Exec key OR replace %f etc by > >> nothing, but that fails for things such as these: > >> > >> Exec=env WINEPREFIX="/home/adys/.local/share/wineprefixes/default" > >> wine start /ProgIDOpen chm.file %f > > > > What do you mean when you say "fails"? > > That the command won't launch if %f is replaced by nothing or that taking > > the first string fails to see that the launched program is /usr/bin/env? > Sorry, I meant the usual way of getting the binary name (which in this > case would be "env"). Ok, thank you for clarifying. However, I don't see how the simple algorith of taking the first word could possibly fail to return 'env'. That is the most simple case: no path, no escaped or quoted whitespace, just a simple alphabetic sequence. 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: open(1) removed from Debian? (was: 'open' instead of 'xdg-open' for usability?)
On Tuesday, 2013-12-24, 17:06:08, Thomas Kluyver wrote: > On 24 December 2013 16:37, Kevin Krammer wrote: > > Well, a quick check would have revealed that it is. > > Cross platform development always requires testing on the targetted > > platforms, > > one can not simply assume things. > > But I don't go and check that simple commands like cp or grep will work on > a Mac. Depends on the arguments you provide to these commands. We all know very well that these commands can vary in capabilities, behavior and understood commandline switches a lot depending on platform. > It's easy to see how someone could have assumed that 'open' is a > similarly common command and would work on Linux systems. Of course you can > blame developers who make incorrect assumptions, but why not aim to make > the obvious assumptions correct? I am not blaming anyone for making assumptions, correct or otherwise. I am just saying that assumptions need to be verified. Either by research or by testing. Just to be clear I also do not blame the developers for not testing on Linux or not caring about supporting their software on Linux. > > Even if a tool or command with the same name exists it might have >> different capabilities, arguments or options. > > That is a valid concern - OSX's open has several options that xdg-open does > not (currently). But I think the benefit of having a similar obvious way to > load files and URLs outweighs that. Developers are also familiar with > common commands like cc and make being provided by different > implementations that may support different options. It will still need testing, so there is no magic bullet. If the software vendor does not want to use a different code path in their main software and rely on calling 'open' then they can simply ship a trivial shell script that forwards the arguments to xdg-open. Or do it the other way around and use a simple redirector on OS X, with the additional benefit of not having to know the installation path since 'xdg- open' is likely not used by anything else on the platform that is not xdg- open. 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: Binary name in the desktop file
On Thursday, 2013-12-26, 10:56:11, Jerome Leclanche wrote: > I'd really like to be able to get the binary name from desktop files > (eg a way to "start without any argument"). Current implementations > rely on getting the first word of the Exec key OR replace %f etc by > nothing, but that fails for things such as these: > > Exec=env WINEPREFIX="/home/adys/.local/share/wineprefixes/default" > wine start /ProgIDOpen chm.file %f What do you mean when you say "fails"? That the command won't launch if %f is replaced by nothing or that taking the first string fails to see that the launched program is /usr/bin/env? > 1. Add an Environment key to desktop files, like systemd's service > files. This would be neat and cleaner for such programs. That exec key > would trip up launchers that parse the command line in addition to the > name. Annoying! But it doesn't really fix my issue. > > 2. Potential solution #1: Add an ExecNoArgs (or similarly named) key. > If not found, it would be assumed to be the same as the Exec key with > %f/%F/%u/%U replaced by nothing. Clean, backwards-compatible, easy to > implement. > > 3. Potential solution #2: Add a Binary key and add a %b token for the > Exec key so that you can do something like > Binary=/usr/bin/foo > Exec=%b --files=%F > > Not backwards compatible but more potential. On the other hand, this > could be inappropriately used for things such as wine (where Binary > would be /usr/bin/wine but should never be executed without args)... Not backward compatible is a no-go IMHO. It would take years before software vendors could use the new format. 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: open(1) removed from Debian? (was: 'open' instead of 'xdg-open' for usability?)
On Tuesday, 2013-12-24, 16:26:27, Thomas Kluyver wrote: > On 24 December 2013 15:06, Kevin Krammer wrote: > > > BTW, I happen to know one breakage caused by Linux not having open(1) > > > > like > > > > > OS X. https://github.com/swaroopch/byte_of_python/issues/8 > > > > Looks like the implementors either had not thought about cross platform > > integration or had no information about things outside the platform they > > are > > working on. > > I think it would be beneficial for 'open' to work the way that people > writing scripts on OS X expect, i.e. an alias to xdg-open, because it's not > obvious that it is a platform specific thing. Well, a quick check would have revealed that it is. Cross platform development always requires testing on the targetted platforms, one can not simply assume things. Even if a tool or command with the same name exists it might have different capabilities, arguments or options. Even if it is the very same tool, which already is quite unlikely, it could come in different versions with different capabilities, etc. > Of course, you'd still need to consider cross platform compatibility for > Windows, but people are used to assuming that similar shell commands work > across posix-y platforms, while Windows is a very different ball game. Assumptions are always at risk of not turning out to be true. Even if something is specified in a standard and is compliance checked it is still necessary to test since compliance checks will often not be all encompassing. On this particular case I am not sure if the open command is part of a standard, compliance checked or not. 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: open(1) removed from Debian? (was: 'open' instead of 'xdg-open' for usability?)
On Tuesday, 2013-12-24, 12:59:13, Ma Xiaojun wrote: > Fail to see the connection. I guess xdg, if it stands for X Desktop > Group, would be obsolete soon if people move to Wayland or Mir based > desktop. I think it is more reasonable to assume it stands for cross desktop. Most xdg specification and technologies are about sharing data and/or implementations between desktops/worspaces and between applications using different technology stacks. There are a couple of X11 related specifications, such as the XDND spec, but most are not dependent on any specific technology or implementation, e.g. desktop-entry spec, mime spec, icon spec and so on. > BTW, I happen to know one breakage caused by Linux not having open(1) like > OS X. https://github.com/swaroopch/byte_of_python/issues/8 Looks like the implementors either had not thought about cross platform integration or had no information about things outside the platform they are working on. But it looks like there was some helpful comment addressing the latter, i.e. providing information about respective integration hooks on other platforms. Whether the autor(s) will address the issue then depends on whether they want cross platform support or not. If they have no use or goal to support running their software on non OSX platforms, then they are unlikely to put efforts into it. 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: Fwd: 'open' instead of 'xdg-open' for usability?
On Wednesday, 2013-12-18, 04:59:33, Robert Qualls wrote: > > I have to agree with you, but I have strong doubts about just > > "renaming" xdg-open to open (without keeping xdg-open available) > > because of lot of 3rd party applications (including proprietary one) > > have standardized on xdg-open and not having xdg-open available > > will break them, for zero added value. > > Looking back, I see how my thread title suggested renaming xdg-open. I > actually didn't mean this. I just think that the open should refer to > xdg-open or any other agnostic file opener. Other than breaking > things, it's quite possible that xdg-open will not always be the best > way to open files, especially since it assumes a desktop environment. > > Since some of the more conservative distributions are worried about > compatiblity, it might be possible for an interim script to determine > whether the call is likely to open a file or is intended for openvt. > Maybe. xdg-mime query filetype and if it's a file, use xdg-open? xdg-open can be called with URLs, etc. Speaking as one of the initiators of the xdg utils set, their goal was always just to bridge the gaps between different implementations until standards for the respective use case had been established and reached enough update to eventually make them just thin wrappers around a standard tool. That standard tool might then have different capabiltities to the wrapper and thus need a different name (or some really good compatibility mode). IMHO, even such a new name should have some namespacing. but maybe using a suffix instead (thus becoming one of the autocomplete choices). Namespace pollution is really one of the nasties diseases of shared directory infrastructure based systems. Any developer using verbs or every-day-things words for names should have all their accounts closed for some meditation period. 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: The format of Shared MIME Database magic values
On Monday, 2013-12-16, 12:45:47, Alexander Kamyshnikov wrote: > I'm confused a bit. > So, you want to say that QMimeDatabase from Qt5 can be separately used in > Qt4? > I.e. i can just include this code in mine. Not the Qt5 based code obviously. But Jerome said that there is a Qt4 port of the Qt5 code. I guess he is referring to https://github.com/pasnox/mimetypes-qt4 Cheers, Kevin > Also, i'm trying to google "qmimedatabase qt4", but find nothing > appropriate. > A more concrete search direction will be welcome. > P.S. Sorry, if i don't understand simple things. My english is not perfect > yet. > > > 2013/12/16 Kevin Krammer > > > On Monday, 2013-12-16, 11:41:34, Alexander Kamyshnikov wrote: > > > Hi Kevin. I'm glad to see KDE developer here because i'm KDE fan for > > > many > > > years :) > > > But this KDE MIME-support code hardly depend from other KDE stuff, isn't > > > > it? > > > > > I need "pure" Qt code - this is our software client requirement :/ So > > > i'm > > > wrote CMimeDatabase class. And just want to make it fully compliant with > > > freedesktop standart. > > > > Just wanted to point out that the Qt5 implementation was contributed by > > KDE > > developers, so additional to the Qt4 port of that code there is also "the > > original" Qt4 code available. > > > > But of course if you need a pure C++ implementation without Qt then > > writing a > > new one is your only choice. > > > > Cheers, > > Kevin > > > > > (see > > > > http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/kmimetype_8h_sourc > > e > > . > > > > > html - > > > KUrl, KServiceType etc.) > > > > > > > > > 2013/12/14 Kevin Krammer > > > > > > > On Friday, 2013-12-13, 20:11:34, Jerome Leclanche wrote: > > > > > There is a Qt 4 port of this. > > > > > > > > And there should also be the original Qt4 based code in the kdelibs > > > > repository. > > > > > > > > Cheers, > > > > Kevin > > > > > > > > > As for windows support... I've been down that road, trying to > > > > > provide > > > > > it. Windows' feature set doesn't even sort of come close; it only > > > > > provides real mime types for a limited set of registered extensions, > > > > > and it doesn't provide any of the very useful features such as > > > > > subclassing, etc. In the end, I gave up and am only providing > > > > > xdg-based mime types. I think Qt made an excellent choice in > > > > providing > > > > > > > the xdg database itself. But if you choose against that, good luck. > > > > > > > > > > Anyway you can have a look at my python-based mimetype lib. Magic > > > > > matches are implemented on line 192 onwards. > > > > > > > > > > https://github.com/Adys/python-xdg/blob/master/xdg/mime.py > > > > > > > > > > J. Leclanche > > > > > > > > > > > > > > > On Fri, Dec 13, 2013 at 7:56 PM, Alexander Kamyshnikov > > > > > > > > > > wrote: > > > > > > Yes, i had. But i decided to write my own implementation because: > > > > > > a) my project is forced to use Qt4 only (clients have very old > > > > > > > > versions of > > > > > > > > > > modified Red Hat with XDG_DATA_DIRS undefined); > > > > > > b) Windows support (through reading registry HKCR/.ext keys) is > > > > > > > > required; > > > > > > > > > > c) I'm very curious :) > > > > > > > > > > > > You think i'm should look deeply at the qmimedatabase.cpp however? > > > > > > > > > > > > > > > > > > 2013/12/13 Jerome Leclanche > > > > > > > > > > > >> Have you had a look at the Qt 5 mimetype module? > > > > > >> > > > > > >> http://qt-project.org/doc/qt-5.0/qtcore/qmimedatabase.html > > > > > >> J. Leclanche > > > > > >> > > > > > >> > > > > > >> On Fri, Dec 13, 2013 at 7:35 PM, Alexander Kamyshnikov > > > > > >> > > &g
Re: The format of Shared MIME Database magic values
On Monday, 2013-12-16, 11:41:34, Alexander Kamyshnikov wrote: > Hi Kevin. I'm glad to see KDE developer here because i'm KDE fan for many > years :) > But this KDE MIME-support code hardly depend from other KDE stuff, isn't it? > I need "pure" Qt code - this is our software client requirement :/ So i'm > wrote CMimeDatabase class. And just want to make it fully compliant with > freedesktop standart. Just wanted to point out that the Qt5 implementation was contributed by KDE developers, so additional to the Qt4 port of that code there is also "the original" Qt4 code available. But of course if you need a pure C++ implementation without Qt then writing a new one is your only choice. Cheers, Kevin > > (see > http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/kmimetype_8h_source. > html - > KUrl, KServiceType etc.) > > > 2013/12/14 Kevin Krammer > > > On Friday, 2013-12-13, 20:11:34, Jerome Leclanche wrote: > > > There is a Qt 4 port of this. > > > > And there should also be the original Qt4 based code in the kdelibs > > repository. > > > > Cheers, > > Kevin > > > > > As for windows support... I've been down that road, trying to provide > > > it. Windows' feature set doesn't even sort of come close; it only > > > provides real mime types for a limited set of registered extensions, > > > and it doesn't provide any of the very useful features such as > > > subclassing, etc. In the end, I gave up and am only providing > > > xdg-based mime types. I think Qt made an excellent choice in providing > > > the xdg database itself. But if you choose against that, good luck. > > > > > > Anyway you can have a look at my python-based mimetype lib. Magic > > > matches are implemented on line 192 onwards. > > > > > > https://github.com/Adys/python-xdg/blob/master/xdg/mime.py > > > > > > J. Leclanche > > > > > > > > > On Fri, Dec 13, 2013 at 7:56 PM, Alexander Kamyshnikov > > > > > > wrote: > > > > Yes, i had. But i decided to write my own implementation because: > > > > a) my project is forced to use Qt4 only (clients have very old > > > > versions of > > > > > > modified Red Hat with XDG_DATA_DIRS undefined); > > > > b) Windows support (through reading registry HKCR/.ext keys) is > > > > required; > > > > > > c) I'm very curious :) > > > > > > > > You think i'm should look deeply at the qmimedatabase.cpp however? > > > > > > > > > > > > 2013/12/13 Jerome Leclanche > > > > > > > >> Have you had a look at the Qt 5 mimetype module? > > > >> > > > >> http://qt-project.org/doc/qt-5.0/qtcore/qmimedatabase.html > > > >> J. Leclanche > > > >> > > > >> > > > >> On Fri, Dec 13, 2013 at 7:35 PM, Alexander Kamyshnikov > > > >> > > > >> wrote: > > > >> > Hi all! > > > >> > I'm developing the implementation of MIME database in C++/Qt for > > > >> > one > > > >> > commercial program (requirement managment tool, if one will be > > > >> > interested). > > > >> > So my question is: the format of magic values to compare file > > > >> > header > > > >> > data > > > >> > with is not specified exactly in the spec. I mean the > > > > magic/match/value > > > > > >> > attribute. > > > >> > What exactly mean those magic strings from > > > >> > /usr/share/mime/packages/freedesktop.org.xml from my Kubuntu? > > > >> > 1) "\1\9" > > > >> > 2) "\376\067\0\043" > > > >> > 3) "\x8AMNG\x0D\x0A\x1A\x0A" > > > >> > Second is looks like octal number in C notation, third - > > > > hexadecimal, > > > > > >> > but > > > >> > about first i'm not sure. It is just "usual" decimal value? > > > >> > What format exactly should use magic values? > > > >> > Thanks for your help. WBR, Alexander > > > > > >> > P.S. Spec i'm using living here: > > http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info > > > > > >> > -spec-latest.html#id2661973 P.S. items can be nested. But i > > > >> > can't find yet the clear way to implement their storage > > > >> > programmatically. Some kind of tree, or reverse polish notation > > > > should > > > > > >> > be used here? nevermind > > > >> > > > > >> > ___ > > > >> > xdg mailing list > > > >> > xdg@lists.freedesktop.org > > > >> > http://lists.freedesktop.org/mailman/listinfo/xdg > > > > > > ___ > > > xdg mailing list > > > xdg@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/xdg > > > > -- > > Kevin Krammer, KDE developer, xdg-utils developer > > KDE user support, developer mentoring > > > > ___ > > xdg mailing list > > xdg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xdg -- 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: The format of Shared MIME Database magic values
On Friday, 2013-12-13, 20:11:34, Jerome Leclanche wrote: > There is a Qt 4 port of this. And there should also be the original Qt4 based code in the kdelibs repository. Cheers, Kevin > As for windows support... I've been down that road, trying to provide > it. Windows' feature set doesn't even sort of come close; it only > provides real mime types for a limited set of registered extensions, > and it doesn't provide any of the very useful features such as > subclassing, etc. In the end, I gave up and am only providing > xdg-based mime types. I think Qt made an excellent choice in providing > the xdg database itself. But if you choose against that, good luck. > > Anyway you can have a look at my python-based mimetype lib. Magic > matches are implemented on line 192 onwards. > > https://github.com/Adys/python-xdg/blob/master/xdg/mime.py > > J. Leclanche > > > On Fri, Dec 13, 2013 at 7:56 PM, Alexander Kamyshnikov > > wrote: > > Yes, i had. But i decided to write my own implementation because: > > a) my project is forced to use Qt4 only (clients have very old versions of > > modified Red Hat with XDG_DATA_DIRS undefined); > > b) Windows support (through reading registry HKCR/.ext keys) is required; > > c) I'm very curious :) > > > > You think i'm should look deeply at the qmimedatabase.cpp however? > > > > > > 2013/12/13 Jerome Leclanche > > > >> Have you had a look at the Qt 5 mimetype module? > >> > >> http://qt-project.org/doc/qt-5.0/qtcore/qmimedatabase.html > >> J. Leclanche > >> > >> > >> On Fri, Dec 13, 2013 at 7:35 PM, Alexander Kamyshnikov > >> > >> wrote: > >> > Hi all! > >> > I'm developing the implementation of MIME database in C++/Qt for one > >> > commercial program (requirement managment tool, if one will be > >> > interested). > >> > So my question is: the format of magic values to compare file header > >> > data > >> > with is not specified exactly in the spec. I mean the magic/match/value > >> > attribute. > >> > What exactly mean those magic strings from > >> > /usr/share/mime/packages/freedesktop.org.xml from my Kubuntu? > >> > 1) "\1\9" > >> > 2) "\376\067\0\043" > >> > 3) "\x8AMNG\x0D\x0A\x1A\x0A" > >> > Second is looks like octal number in C notation, third - hexadecimal, > >> > but > >> > about first i'm not sure. It is just "usual" decimal value? > >> > What format exactly should use magic values? > >> > Thanks for your help. WBR, Alexander > >> > > >> > P.S. Spec i'm using living here: > >> > > >> > http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info > >> > -spec-latest.html#id2661973 P.S. items can be nested. But i > >> > can't find yet the clear way to implement their storage > >> > programmatically. Some kind of tree, or reverse polish notation should > >> > be used here? nevermind > >> > > >> > ___ > >> > xdg mailing list > >> > xdg@lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/xdg > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg -- 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: New handling for URI scheme handlers
On Monday, 2013-12-02, 15:34:34, Bastien Nocera wrote: > On Mon, 2013-12-02 at 15:16 +0100, Kevin Krammer wrote: > > On Monday, 2013-12-02, 09:40:12, Nicolas Mailhot wrote: > > > Le Lun 2 décembre 2013 00:59, David Faure a écrit : > > > > (same with any other content application that can handle HTTP urls on > > > > its > > > > own; > > > > same with other schemes that apps might support, like FTP). > > > > > > Having managed a very large proxy configuration for some years (150k+ > > > users, high-availability) I can tell you that pretty much any > > > application > > > that pretends talking http lies, and only full browsers implement > > > (mostly) > > > the complete http spec (including error handling) > > > > David obviously looks at this from a KDE perspective, where the same HTTP > > implemention is used by all applications, including the browser. > > IIRC it can even transfer a session from one application to another, e.g. > > avoiding the one-time-URL problem. > > If I use Opera, Firefox or Chrome in KDE, I'm not sure it magically uses > the same HTTP implementation. Sure, but David also mentioned that we enable users to tell our URL handling code to delegate HTTP always to a certain program/browser and was, in my interpretation, discussing the implications on the standard setup. So, within this assumed context, I was pointing out to Nicolas that the HTTP implemention in question was "browser capable". 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: New handling for URI scheme handlers
On Monday, 2013-12-02, 09:40:12, Nicolas Mailhot wrote: > Le Lun 2 décembre 2013 00:59, David Faure a écrit : > > (same with any other content application that can handle HTTP urls on its > > own; > > same with other schemes that apps might support, like FTP). > > Having managed a very large proxy configuration for some years (150k+ > users, high-availability) I can tell you that pretty much any application > that pretends talking http lies, and only full browsers implement (mostly) > the complete http spec (including error handling) David obviously looks at this from a KDE perspective, where the same HTTP implemention is used by all applications, including the browser. IIRC it can even transfer a session from one application to another, e.g. avoiding the one-time-URL problem. 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: open file in directory action
On Sunday, 2013-04-21, Hans de Goede wrote: > Let me clarify this a bit, what Vincent means here, is that we assume that > for things like the "Open containing folder" function in firefox' Download > Manager apps use the desktops preferred applications config, looking what > app to use for "text/directory". You probably meant inode/directory, text/directory is the MIME typ for contact vCards :) 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: Direct-opening a temporary file using the user's preferred application
On Wednesday, 2013-04-17, Jan Kundrát wrote: > On Friday, 12 April 2013 09:30:27 CEST, Kevin Krammer wrote: > > I guess in your case you could use $XDG_CACHE_HOME (defaults to > > $HOME/.cache) > > and an application specific subdirectory. > > I would like to expand on this a bit -- the application in question does > maintain an on-disk cache, and if a file size exceeds certain threshold, > it is saved as a regular file on disk. However, there are a couple of > reasons for not making this cache visible to the user: > > - There are no promises about the cache layout. It can change between the > application versions without any further notice. Nothing else is expected > to access it (think Akonadi's on-disk structures :) ). > > - The files are optionally compressed. > > - For technical reasons (the protocol provides hard guarantees about data > immutability), the files shall really be read-only. If the user managed to > e.g. open an office document from this private cache and saved it with > some modifications, the appliocation would have to include extra > checksumming, otherwise the next time user opens the "pristine attachment" > from the IMAP server, they will actually see the modified data, and that's > a serious bug. > > - Tiny attachments might be saved in e.g. a sqlite database, not in an > extra file. > > This means that I cannot really use the already-present private cache and > would have to come up with yet another custom location. I wasn't suggesting to use an already existing cache (I didn't even know you had one). I just mentioned the existance of a location specifically intended for cached data. Whether you copy the file from your internal cache to the location that you let the launched application see or whether you download it to that doesn't make any difference. Just like you would have done with the temporary directory, only without problem of it being on a tmpfs filesystem, potentially allowing you to reuse the file (e.g. user clicking the attachment, closing the app shortly after, and clicking again). Since it is still a cache location, you can always delete the file as you see fit, e.g. on next application start or if the file access time stamp is too old, etc. In other words you don't have to delete it as soon as possible, thus nicely avoiding the problem of not knowing when the other application has opened it. 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: Direct-opening a temporary file using the user's preferred application
On Thursday, 2013-04-11, Jan Kundrát wrote: > On Wednesday, 10 April 2013 20:15:26 CEST, Nicolas Mailhot wrote: > > When tmpfs is a ramdisk it is fast *but* limited to ram+swap size. So on > > current systems it is quite easy to saturate it with a few files in the > > hundred megs/gigabyte size. > > Do such systems point their $TMPDIR into a ramdisk-backed location? If they > do, do they also offer another place with more available space? How can > one access that place? I guess in your case you could use $XDG_CACHE_HOME (defaults to $HOME/.cache) and an application specific subdirectory. The first time a user clicks an attachment you download it to that location and remember the filename. If the users closes the launched program and clicks the attachment again, you can quickly launch the application again because the cache still contains the downloaded file. Also, since it is a cache, you decide when to clear it. You could check file access times, store meta data or clear it on shutdown or next startup. 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: about value -- file /usr/share/mime/packages/freedesktop.org.xml
application/x-ole-storage does have two magic match entries on my installation. I guess both refer to the same actual binary data, just one being given as string and the other as a number. shared-mime-info package 1.0 as far as I can tell. Cheers, Kevin On Monday, 2013-01-21, Jerome Leclanche wrote: > .msi files (application/x-msi, subclass of application/x-ole-storage) do > not have any content match. I get the feeling the issue might be deeper, > eg. an overzealous thumbnailer. > > J. Leclanche > > On Mon, Jan 21, 2013 at 6:32 PM, Kevin Krammer wrote: > > On Saturday, 2013-01-19, westlake wrote: > > > Actually this does not occur at all with lynx or mc > > > > console interfaces don't have the same requirements, e.g. they usually > > don't > > have to retrieve the same amount of meta data. > > GUI file managers nowadays are required to show different icons depending > > on > > the file's MIME type, I doubt mc needs to know the MIME type at all. > > > > > So far as any file navigator knows.. these are just local files.. > > > (I'm not using webdav/ssl via dbus/gvfs -- but have the mountpoint > > > under /etc/fstab as webdavfs) > > > > Which is of course part of the problem, since local files are assumed to > > be random, high througput and low latency access. > > Remote file access systems which have been developed with the > > requirements of > > GUI programs in mind provide a way for applications to check if a file > > can be > > considered local for optimization, but keep it aware of potential I/O > > bounds > > if it can not. > > > > > I also tried to narrowed it down, and did long ago what you may suspect > > > is the problem. But it only occurs with anything that uses mimelists.. > > > -- So I disable any thumbnail checking. > > > > > > I guess I would be able to address this on another mailing list.. since > > > it doesn't seem anybody really understands this problem I'm having.. > > > > > > I would of thought too that it's the file managers. But this happens > > > with 5 GUI file managers.. and not at all for any of the cli file > > > navigators. > > > > Which would be a good indication that the GUI file managers do something > > they > > CLI file manager don't. > > > > Since you describe the problem occuring with files that have binary > > patterns > > defined for MIME type detection. > > Do the respective file extensions have multiple file type associations? > > Or the other way around: is the file extension unqiue? > > > > If it is not unique, e.g. the same extension being associated with two > > different file types, then file managers would need to look deeper, e.g. > > content inspection. And since the file is considered local, that is OK > > and considered very fast (loading of a handful of bytes). > > > > > (Another thing, is if I use a Web browser with file:// as part of the > > > URL, the directory lists is always quick) > > > > My guess on this data point is that as soon as file managers are aware > > they are not dealing with a local file they don't consider content > > inspection a viable option during listing. > > > > > and I disable any thumbnail checking --<< It ONLY occurs with > > > .msi/.msu files.. and a rule is seldomly ever used... so it > > > definitely has something to do with the freedeskto project.. << BUT.. > > > it does not occur on a "local" storage.. > > > > > > So if I had these problematic filetypes (.msi/.msu) in ~ , I get no > > > long-long long delay.. > > > > Probably orders of magnitude faster medium, no? > > > > > ^ I tested it.. thumbnails off. A long list of files.. I then add > > > just > > > > > > "one" problematic .msi file and it nearly stalls the listing completely > > > (2+ minute delay) -- just because of ONE file. > > > > Does this also happen if you have fetched the file already? E.g. by > > cat'ing it > > to /dev/null? > > I.e. so that any further access is likely to be answered from kernel I/O > > buffers? > > > > Cheers, > > Kevin > > -- > > Kevin Krammer, KDE developer, xdg-utils developer > > KDE user support, developer mentoring > > > > ___ > > xdg mailing list > > xdg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xdg -- 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: about value -- file /usr/share/mime/packages/freedesktop.org.xml
On Saturday, 2013-01-19, westlake wrote: > Actually this does not occur at all with lynx or mc console interfaces don't have the same requirements, e.g. they usually don't have to retrieve the same amount of meta data. GUI file managers nowadays are required to show different icons depending on the file's MIME type, I doubt mc needs to know the MIME type at all. > So far as any file navigator knows.. these are just local files.. > (I'm not using webdav/ssl via dbus/gvfs -- but have the mountpoint under > /etc/fstab as webdavfs) Which is of course part of the problem, since local files are assumed to be random, high througput and low latency access. Remote file access systems which have been developed with the requirements of GUI programs in mind provide a way for applications to check if a file can be considered local for optimization, but keep it aware of potential I/O bounds if it can not. > I also tried to narrowed it down, and did long ago what you may suspect > is the problem. But it only occurs with anything that uses mimelists.. > -- So I disable any thumbnail checking. > > I guess I would be able to address this on another mailing list.. since > it doesn't seem anybody really understands this problem I'm having.. > > I would of thought too that it's the file managers. But this happens > with 5 GUI file managers.. and not at all for any of the cli file > navigators. Which would be a good indication that the GUI file managers do something they CLI file manager don't. Since you describe the problem occuring with files that have binary patterns defined for MIME type detection. Do the respective file extensions have multiple file type associations? Or the other way around: is the file extension unqiue? If it is not unique, e.g. the same extension being associated with two different file types, then file managers would need to look deeper, e.g. content inspection. And since the file is considered local, that is OK and considered very fast (loading of a handful of bytes). > (Another thing, is if I use a Web browser with file:// as part of the > URL, the directory lists is always quick) My guess on this data point is that as soon as file managers are aware they are not dealing with a local file they don't consider content inspection a viable option during listing. > and I disable any thumbnail checking --<< It ONLY occurs with .msi/.msu > files.. and a rule is seldomly ever used... so it definitely has > something to do with the freedeskto project.. << BUT.. it does not > occur on a "local" storage.. > > So if I had these problematic filetypes (.msi/.msu) in ~ , I get no > long-long long delay.. Probably orders of magnitude faster medium, no? > ^ I tested it.. thumbnails off. A long list of files.. I then add just > "one" problematic .msi file and it nearly stalls the listing completely > (2+ minute delay) -- just because of ONE file. Does this also happen if you have fetched the file already? E.g. by cat'ing it to /dev/null? I.e. so that any further access is likely to be answered from kernel I/O buffers? 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: mplayer (Message sign� : )
On Monday, 2012-12-03, Thomas Kluyver wrote: > On 3 December 2012 10:08, Kevin Krammer wrote: > > > What if tools in the program remember their configuration? Losing the > > > > > > parameter set for one tool would not make me cry, however, losing all > > > of them would. > > > > How likely is it that those two paths are on different media and one > > having a > > higher failure rate than the other? > > Most setups don't have $XDG_DATA_HOME or $XDG_CONFIG_HOME set so their > > defaults apply, meaning they are $HOME/.local/share and $HOME/.config > > respectively. > > Again, most setups have $HOME or even its parent directory on the same > > volume. > > Kevin, the discussion about losing files relates to what you back up. To > summarise the blog post: data files are a priority to back up, config may > be backed up but it's not important to do so, and cache isn't worth backing > up. Ah, I see. So totally irrelevant for the discussion at hand. I was really puzzled by that and couldn't get rid of the feeling that there was some mixup of cache-home and config-home. Thanks for clarifying. 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: mplayer (Message sign� : )
On Monday, 2012-12-03, David NeÄas wrote: > I am in a similar situation, having things that may be created/edited by > users or the program, user-installed plug-ins and scripts that may be, > in fact, user-written plug-ins and scripts, arch-dependent modules and > data, files that are essentially run-time state but the user may want to > modify them manually, etc. After reading the specs a dozen times I > still have no idea what should go where. > > This attempts to provide some guidelines > > http://ploum.net/post/207-modify-your-application-to-use-xdg-folders > > but according to it the same file belongs to different places, depending > on how the user have come to its possession: If the user wrote a script > himself, he will be crying if it is deleted. It's been a long time since I've read this, but how does it make any difference on how the file was obtained? Your plugins/scripts are not configuration, are they? So no matter if they have been manually written or downloaded they are still not configuration files. > So it must go to > XDG_DATA_HOME. But if exactly the same script is installed as an > extension it should go to XDG_CONFIG_HOME. So directories must be > duplicated between XDG_DATA_HOME and XDG_CONFIG_HOME. Which means > people will put their scripts to one or another randomly (you cannot > really stop them if both work) defeating the distinction. People will put files into the directory the application wants those files in. If your application's script directory is in XDG_DATA_HOME, then this is where people will put their script. I also fail to see how there would be any need to duplicate data. > What if the user installs an extension and, later, decides to modify it? > Does he have to move it from XDG_CONFIG_HOME to XDG_DATA_HOME because it > becomes valuable now? Why would it become more or less valuable depending on where it is stored? Are you somehow mixing the XDG_CACHE_HOME concept in here somehow? > Furthermore, if a file contains one value it is probably configuration. > If it contains a thousand it is probably data. And if it contains five > values? Six? A dozen? 16? 25? 41? 77? 118? 464? The size of the file or amount of its content will obviously have no impact on the location. If you consider a file a configuration file for your application then it is a configuration file for your application. Do you change the location or filename or your current setup when the size changes? > What if tools in the program remember their configuration? Losing the > parameter set for one tool would not make me cry, however, losing all of > them would. How likely is it that those two paths are on different media and one having a higher failure rate than the other? Most setups don't have $XDG_DATA_HOME or $XDG_CONFIG_HOME set so their defaults apply, meaning they are $HOME/.local/share and $HOME/.config respectively. Again, most setups have $HOME or even its parent directory on the same volume. Assuming you are currently storing your files somewhere below $HOME as well, why would your files become more likely to be lost? > Who am I to judge what the user will consider valuable data and what he > will consider just configuration? How do you judge that now? Or do you put all data into one single file? 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: URL and application handling/registration standard
On Sunday, 2012-09-30, Jerome Leclanche wrote: > - What happens if the uri isn't an image? It should instead be opened in a > browser. But xdg-open cannot know how to open and sniff arbitrary > protocols, so it either has to open in an http reader *first* that then > forwards it to an image viewer, or the image viewer has to understand a lot > more about the protocol than might be implemented. Confusion can arise if > the image format is not supported by the image viewer, too (but still > registered); it would forward back and forth between browser and image > viewer. Behavior will largely depend on the actual program xdg-open delegates to. E.g. on KDE the KIO subsystem knows how to determine the MIME type of a resource and will look up the application associated with it. I would guess that this is also true for GNOME and their IO framework. 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: Can *.desktop files be located in /usr/local/applications?
On Saturday, 2012-06-30, Damjan Jovanovic wrote: > On Sat, Jun 30, 2012 at 3:28 AM, jupiter wrote: > > Sorry for asking a simple quesiton, I am new to the freedesktop. I > > have read the latest spec, but still not clear if I can put > > application *.desktop to different locations such as > > /usr/local/application1/application1.desktop, > > /usr/local/application2/application2.desktop, etc.. If it can, what I > > should to do to make those applications listed in desktop based on > > user ID or group ID? Appreciate any helps. > > > > Thank you. > > > > Kind regards, > > > > Jupiter > > /usr/local/share/applications is for *.desktop files that appear in > every user's menus. > $HOME/.local/share/applications is for *.desktop files that appear > only in that particular user's menus. > Both have to have a flat structure (no further subdirectories). > No per-group-ID *.desktop files are possible. Not with default locations but of course one could have additional directories, e.g. one per group that needs differentiation, and add that directory to the XDG_DATA_DIRS variable for all users of those groups. 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: Support for localized Exec entries, please
On Friday, 2012-04-20, Ronny Standtke wrote: > I just tested it and, unfortunately, no, it doesn't work because "$LANG" > in the exec line is not substituted. At least not in GNOME where > "Exec[$e]=..." actually *breaks* the desktop entry so that it does not > show up any more. I think [$e] is a KDE specific markup, intended to be used for config files. Can you try without? Or running a wrapper script that does the URL substitution based on $LANG 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: Convention Over Configuration: A Way Forward?
On Monday, 2012-01-09, Thiago Macieira wrote: > On Sunday, 8 de January de 2012 17.49.12, Trans wrote: > > I mean that they don't use the environment variables. > > I really don't think the environment variables are an issue. > > As Kevin said: > > > Hmm. I haven't done any application with just low level APIs but > > > reading an > > > environment variable and a string comparison seems indeed rather > > > trivial to > > > me. Though I can only speak for languages I've used so far, e.g.C/C++, > > > Java, > > > Python. Might be more complicated elsewhere. > > Getting the value of an environment variable and applying a default if it's > not set is the least of the issues. They *already* have to do that for > $HOME if they want to save their configuration files in the home > directory, with fallback to values read from the password database. Right, I didn't consider that they already have to read an environment variable. But maybe they consider $HOME to be always set or only explicitly unset, i.e. always just do config_path = getenv( "HOME" ) + config_name If that would be the case specifying XDG_*_HOME should be always set would help then. > For that reason, I don't think you're addressing the source of the problem. > It's more likely that they don't know that the option exists in the first > place, that they are lazy to change their code, or they simply don't want > to change from old Unix convention. Neither of those problems will be > solved by hardcoding the path to $HOME/.config. My theory as well. Hence my original question on whether there is any evidence to the contrary. 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: Fwd: Convention Over Configuration: A Way Forward?
On Sunday, 2012-01-08, you wrote: > On Fri, Jan 6, 2012 at 8:53 AM, Kevin Krammer wrote: > > How would that improve upon any of the holdback reasons you cited above? > > > > Is there any public statement of developers in the groups "indifferent" > > or "uncertain" that they would support a fixed location but cannot be > > bothered to read a single environment variable? > > Yea, the simple fact that they don't do it. I am afraid I don't get that. What does "it" refer to? Making a public statement? I am not sure not making a public statement in favor of something can be counted as an implicit public statement in favor of something. > It might seem trivial, but > to programmers every additional adjunct is another maintenance issue. > With XDG base directory standard it means eiterh rolling my own code > or having dependency on an external library. Hmm. I haven't done any application with just low level APIs but reading an environment variable and a string comparison seems indeed rather trivial to me. Though I can only speak for languages I've used so far, e.g.C/C++, Java, Python. Might be more complicated elsewhere. > By using a fixed path, > the code need not have to worry about any of that. Thus making it much > easier to implement and support. Ok, based on the assumption that reading an environment variable could be difficult the question is why don't these application developer just hardcode $HOME/.config? That would always keep $HOME clean of "hidden" config files and additional go along XDG using applications in a majority of setup without any drawback. > > How would the proposed inconfigurability make the location more widely > > known? > > By gaining acceptance into FHS proper. FHS would have no problem > accepting fixed locations. Indeed, at this time the standard > explicitly designates the use of home dot files. Interesting thought. > And I disagree with the term "inconfigurability". It's would still be > configurable, but via the file system itself, not the environment > variables. True, though I find symlinks to be more tedious to switch and temporarily override. Anyway, I guess my main puzzlement is still whether developers currently not hardcoding $HOME/.config are not doing it because there could be systems where XDG_CONFIG_HOME points to something else. Cheers, Kevin 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: Convention Over Configuration: A Way Forward?
On Wednesday, 2012-01-04, Trans wrote: > Probably the most useful thing to me about the XDG based directories > are the HOME directories which offer a good solution to cleansing out > home directories of the overwhelming quantity of .dot files. > > Unfortunately, adoption of the XDG HOME base directories seems to be > rather marginal. Distro developers, desktop environments and a few > other are clearly on board, but the rest of developers seem > indifferent or uncertain at best, if they even know about XDG. > > I have thought about the idea that perhaps instead XDG should adopt a > "convention over configuration" approach. For instance, make > $XDG_CONFIG_HOME always and only `$HOME/.config`. That way developers > can target that specific directory without worry about looking up the > environment variable setting. Users can still customize the location > by symbolic-link to `~/.config` from whatever directory they prefer. How would that improve upon any of the holdback reasons you cited above? Is there any public statement of developers in the groups "indifferent" or "uncertain" that they would support a fixed location but cannot be bothered to read a single environment variable? How would the proposed inconfigurability make the location more widely known? 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: RFC: An app category for "adult" material?
Hi, On Tuesday, 2011-11-01, Mikkel Kamstrup Erlandsen wrote: > Hi, > > The latest tickets in what's been a recurring item for our application > search in Ubuntu is > https://bugs.launchpad.net/ubuntu/+source/unity/+bug/883800. It > basically boils down to the fact that you may not want PornView (or > other adult apps) popping up as you type a search during a > presentation (or have your kids look at it for that matter). > > I think that no one wants to get into censorship - and there are many > ramifications of this problem. For example, it might not be > appropriate if bible-related apps show up while a rabbi is giving a > talk. Make up your own examples ad lib. This all get's really complex > really fast. > > So keeping it to a problem that we can easily solve a user proposed > something that I also think the upstream app authors wouldn't mind: > Introducing a new XDG category "Adult". That way it is a sensible > upstream opt-in, and distros and app stores can handle it like they > see fit. I find this a rather problematic approach. First, as Joseph has already stated, "adult" is a rather vague concept, extremely based on cultural factors. Second, it does not address the allegded use case of something not showing up in search at all. Searching for "view" would still match the program's name, now probably even labelled as "Adult". It would still be in the application launcher, likely even having a promiment spot of a labelled section. It seems to me that what you want instead is a way to make things not show up in certain places, something conceptually a lot more like DoNotShowIn, e.g. not show in search, not show in history, not show in command completion. As for the "OMG, think of the children" problem, concerned parents should rather control which software they have installed on the computer accessible by their offspring, or even do white listing based on actually checking whether something is appropriate. 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 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 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: Showing a file in the file manager
On Friday, 2011-05-20, Stef Bon wrote: > 2011/5/20 Kevin Krammer : > > For interfaces that many applications could provide and which might > > differ on a per-user basis due to personal preferences, an alternative > > mechanism to D- Bus activation will have to be provided. > > > > For example by performing a query for preferred service similar to what > > xdg- mime can do and then launching that explicitly or by asking a > > central broker like service to launch the preferred service for a given > > interface. > > I think the best sollution here is that not the desired app is > launched, but some wrapper script. > That will read the preferences for the environment, choose the > preferred app and launch it. > That will take the decision off from dbus, to the wrapper script. > > But then we're back at where we began, a script to launch... > > Maybe another sollution: make the current scripts try to look to dbus, > if there is the configuration present for the default app for file > browser, launch that one. > > If dbus is not present, or the configuration of default apps is not > available here, do the default what now happens. This is an orthogonal problem to the file manager interface discussed in this thread. Certainly complimentary for an ideal solution and worth pursuing on its own but better kept to a different thread and maybe even different time so not to derail the topic at hand. 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 Friday, 2011-05-20, Jannis Pohlmann wrote: > On Fri, 20 May 2011 22:57:57 +0200 > > Stef Bon wrote: > > Ok, I understand. I'm not very familiar with dbus. > > > > But then still somewhere has to be defined that the app which is > > assigned to open the url. > > That depends on what. The environment? > > With D-Bus that depends on which application is installed that > implements the D-Bus interface in question. I don't really > know what happens if several such applications or services are > installed. The decision which one to start depends on D-Bus > in that case. > > Applications can hard-code which of the alternatives to use but the > entire (or at least an important) point of standardized APIs is to avoid > that. For interfaces that many applications could provide and which might differ on a per-user basis due to personal preferences, an alternative mechanism to D- Bus activation will have to be provided. For example by performing a query for preferred service similar to what xdg- mime can do and then launching that explicitly or by asking a central broker like service to launch the preferred service for a given interface. 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 Friday, 2011-05-20, François Revol wrote: > >> Ummm, which preferences? For example, xdg-open does some heuristics to > >> determine which desktop environment is running, and then it just calls > >> gnome-open, kfmclient, exo-open, etc. as appropriate. > >> > >> (Yeah, it's kind of ugly. This D-Bus stuff would indeed make things > >> much easier.) > > > > Please excuse me for being slighlty offtopic, but being one of the > > initiators of the xdg-utils scripts I have to voice my agreement with > > this assessment. > > > > These scripts where intended as a quick work around until a more > > apporpriate solution like standardzed interfaces could be provided. > > > > Unfortunately this never happened for various reasons, so any move into > > that direction is highly appreciated. > > Hmm except some OS don't have D-Bus (like Haiku), but have a shell that can > run those. (I recall sending patches to add support for BeOS/Haiku btw...) Right, but how many different workspace implementations are for these platforms? I would imagine that there might even be just one, which basically would already be the standardized interface on the respective platform. And applications built against their APIs will probably already have native options to achieve goals such as discussed in this thread. Of course there is still value in providing a command line interface (simple executable, shell script) for use in scripts or languages without direct access to the native APIs. Coming up with a agreed upon D-Bus interface for D-Bus using workspace providers would just serve as a similar "native" API shared between them and reduce the code paths in or separate implementations of command line helpers. 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 Friday, 2011-05-20, Federico Mena Quintero wrote: > Ummm, which preferences? For example, xdg-open does some heuristics to > determine which desktop environment is running, and then it just calls > gnome-open, kfmclient, exo-open, etc. as appropriate. > > (Yeah, it's kind of ugly. This D-Bus stuff would indeed make things > much easier.) Please excuse me for being slighlty offtopic, but being one of the initiators of the xdg-utils scripts I have to voice my agreement with this assessment. These scripts where intended as a quick work around until a more apporpriate solution like standardzed interfaces could be provided. Unfortunately this never happened for various reasons, so any move into that direction is highly appreciated. 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 Friday, 2011-05-20, Federico Mena Quintero wrote: > On Fri, 2011-05-20 at 12:06 +0800, PCMan wrote: > > UI operations: > > select file in window > > open folder (this can be better than using mime-type handlers for > > folders IMO) show properties of selected files > > > > Is it possible to standardize these common operations? > > We can certainly standardize on the UI operations. What should we use > for the name - org.freedesktop.FileManager1 ? (numbered for further > additions) > > I just threw this together quickly; haven't validated it or anything: > > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> > > > > > > > > > > > > > > > > > > Both signatures for the ShowFile and ShowDirectory methods are identical > - uri, parent_window_id, timestamp. Any reason why one method, e.g. ShowURI, isn't sufficient? The implementing object or whatever it delegates to is most likely able to figure out whether it is dealing with a file or directory. For two distinct methods we would have to define what would happen if you passed a file URI to the ShowDirectory method or the other way around, probably requiring specifying D-Bus errors. 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: XDG_CURRENT_DESKTOP (was: Adding Unity to OnlyShowIn allowed values)
On Saturday, 2011-03-05, Ted Gould wrote: > On Fri, 2011-03-04 at 18:37 -0500, Matthias Clasen wrote: > > On Wed, 2011-03-02 at 10:25 -0600, Ted Gould wrote: > > > I haven't seen any objection, just questions to this. Final call? > > > > I have voiced my objection to the general idea of 'desktop switch' > > behaviour changes, but that's more of a complaint against > > XDG_CURRENT_DESKTOP than against OnlyShowIn=Unity > > I'm unsure why you object. It seem to be something that's generally > useful for applications to know. For instance if they wanted to have a > configuration check box for "Show on Plasma Desktop" or "Show in > Messaging Tray" or something like that. They could make the strings > more informative if the information was available. I think Matthias' point is that in order to do exactly that you'll need to look for the respective target functionality rather than assuming a one-to-one mapping of some identifier to a specific configuration. Basically all Free Software desktop workspaces consist of a setup of multiple processes, sometimes one process per task (IIRC that's how XFCE does it), sometimes two or more tasks combined into one process (e.g. GNOME Shell, Plasma desktop). One could argue to not care about non-default setups, e.g. using xfce-panel with a Nautlius desktop in a KDE session, but what about official deviations, e.g. GNOME 3 fallback on systems without 3D acceleration? Cheers, Kevin 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: [RFC] XDG_RUNTIME_DIR
On Tuesday, 2010-11-09, Lennart Poettering wrote: > On Sun, 07.11.10 11:26, Ryan Lortie (de...@desrt.ca) wrote: > > > What if the system resumes from suspend after 12 hours and the OS job > > > to clean the directory is executed before any of the apps had a chance > > > to update mtime? > > > > Good point. We could specify 6/12 hours as measured by the monotonic > > clock except that file timestamps are in real time. This is tricky... > > Hmm, I'd suggest adding to this spec the rule that files should not be > deleted if the wallclock time was changed less than 5mins of monotonic > time ago, or the system was resumed less than 5mins of monotonic time > ago. This should fix your problem, right? I guess it depends whether common methods of sleeping are based on actual time, i.e. do select/poll/sleep return when having been given a timeout of 6h and the system was suspended during that time? > Of course, right now it is not that easy on Linux to get the necessary > information from the kernel to implement these tests. However, at last > for the wallclock time change test this will change shortly. Hmm, doesn't sound very ensuring. How about other operating system that software following freedesktop.org standards is commonly run on, e.g. *BSD, Solaris? Since you guys have put this auto delete on age feature into the list you probably have a good use case for it. Maybe you could elaborate on it so we others can also take it into our considerations. Thanks, Kevin 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: [RFC] XDG_RUNTIME_DIR
On Saturday, 2010-11-06, Lennart Poettering wrote: > Heya, > > Ryan Lortie and I have been sitting down here at the GNOME Summit and > have discussed an older proposal that was posted on the XDG ML by Ryan a > while back, regarding definition of a directory where user applications > can store runtime files and other file objects (sockets, ...) in. That > directory should be machine-local, fully-featured (i.e. not on NFS) and > its lifetime should be bound to the user actually being logged in. It is > as such something like a per-user counterpart of /var/run. Something like this sounds extremely useful. > So, here's what we propose: some kind of session manager should set > $XDG_RUNTIME_DIR for all user processes to a directory for which the > following rules apply: Maybe XDG_RUNTIME_HOME, since all other user specific directory variables in the spec are suffixed with _HOME? > - It is owned by the user and the user is the only one having write > access to it > > - The directory may be deleted (and should be deleted) after the user > fully logged off or the machine is shut down. > > - The directory is on a local file system, and not shared with other > machines. > > - The directory is fully featured, i.e. the majority of file system > features the OS provides should be supported on it. More precisely, on > Unix AF_UNIX sockets, symlinks, proper permissions, file locking, > sparse files, mmap, hard link count must be available. (It is in fact > recommended to use tmpfs or something similar as backing file system) > > - Files in the directories may be deleted by the OS if they are older > than 12h. If an app wants to make sure that files it creates shall > stay around longer it should update the mtime at least every 6h, or > alternatively set the file sticky bit on the file. What if the system resumes from suspend after 12 hours and the OS job to clean the directory is executed before any of the apps had a chance to update mtime? > - Applications making use of this feature which do not find > $XDG_RUNTIME_DIR to be set, should fall back to some other directory > providing similar capabilities, and print a warning. Is there a way to specify this "some other directory"? Otherwise the ability to discover paths safely is lost if apps use differnent procedures to come up with "some other directory". Cheers, Kevin 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: Trash specification
On Monday, 2010-10-11, François Revol wrote: > (sorry Mail.app is too stupid to handle digests as separate mails) > > > De : Wei Jiang <_weijia...@yahoo.com> > > Date : 21 juin 2010 13:49:55 HAEC > > Aw, that's old :) > > > À : xdg@lists.freedesktop.org > > Objet : Trash specification > > > > Hi All, > > > > The Trash specification is very good. It is intent for Unix, but it is > > good for Windows as well, with minor modification. > > > > I have implemented it for a cross platform (Unix and Windows) file > > manager Acelet Filer at http://www.acelet.com/desktop/filer.html. > > > > I would like to comment about the Trash specification from my experience: > > > > $XDG_DATA_HOME is difficult to implement. > > It is almost out of the capacity of trash implementer. Maybe I can modify > > .bashrc to add that environment variable, but the user may delete it > > later. I have checked Ubuntu 9.40 with Nautilus, $XDG_DATA_HOME is > > undefined. > > > > Instead, I would suggest an alternative: > > > > Call the program, which implements the Trash specification, with option > > -info homeTrashDirName to get the trash directory name. > > In Haiku just as on BeOS, we have a C/C++ API to get specific directories, > find_directory(). There is a finddir command that allows shell scripts to > use it. > http://dev.haiku-os.org/browser/haiku/trunk/src/bin/finddir.c > > I believe this way is less fragile than having to export env vars, which > can be stripped off the env when performing remote login (ssh). > > Also, this allows to return a different path depending on the > volume/filesystem and even uid. That's covered in the trash spec, AFAIK. Anyway, I was just pointing out that the user local data path is always specified, either by definition of the default or override through environment variable > Typically for trash, it's possible to return the path that correspond to > the user for the /home mountpoint, but return the NTFS-specific path for > this fs. This way files can be moved to trash without having to be moved > across mountpoints. Also covered by the trash spec. Cheers, Kevin 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: Trash specification
Hi, not sure why this showed up today, maybe it hang in some queue. On Monday, 2010-06-21, Wei Jiang wrote: > Hi All, > > The Trash specification is very good. It is intent for Unix, but it is good > for Windows as well, with minor modification. > > I have implemented it for a cross platform (Unix and Windows) file manager > Acelet Filer at http://www.acelet.com/desktop/filer.html. > > I would like to comment about the Trash specification from my experience: > > $XDG_DATA_HOME is difficult to implement. > It is almost out of the capacity of trash implementer. Maybe I can modify > .bashrc to add that environment variable, but the user may delete it > later. I have checked Ubuntu 9.40 with Nautilus, $XDG_DATA_HOME is > undefined. If undefined or set to be empty it defaults to $HOME/.local/share Thus distributions like in your case Ubuntu do not set it anywhere, they are fine with this default. Cheers, Kevin 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: [mpris] [ANN] MPRIS v2.0
On Thursday, 2010-08-12, Marc-André Lureau wrote: > - (comment) the "CanDoThat" or "HasThis" pattern could probably use > introspection instead, if DBus common usage permits having > "incomplete" interfaces. Dynamically changing an interface is not an option IMHO. First, an interface is a contract. If an application claims to implement an interface it should have all the specified methods, even if some of them raise errors/exceptions due to not being fully implemented. Second, not all languages can easily add/remove methods at runtime or at least not without making calling them awkward. Third, properties can be queried both separately as well as a whole set. Introspection (IIRC) works on nodes, so it will always deliver all interfaces of the queried node. Fourth, D-Bus properties are often mapped to the bindings' object model's property system which in turn is usually a well known concept for developers already working with the respective object model. Bindings might even have the option for poll for changes and mapping the result into property change notifications (future versions of the standard properties interface might even provide for change signalling by the service). 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: base dir spec question.
On Thursday, 2010-05-06, Julien Danjou wrote: > Patryk Zawadzki writes: > > Not really. XDG_DATA_HOME is your local /usr/share and that's not > > place for databases. I'd say currently XDG_CONFIG_HOME until we get a > > proper local version of /var. > > XDG_CONFIG_HOME is your local /etc. That's not place for databases > neither. > > So I'd say /tmp. I prefer you initial assessment. The database in this case is very likely the application's working data set, e.g. which file has been played how often, etc. Unless the contained information is also stored in the media files themselves, I'd say it qualifies as application data. If the information is also stored in the media files themselves, thus can be recovered and is only put in the DB for convenience and faster access, in which case I think XDG_CACHE_HOME would be more appropriate 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: Desktop Entry Specification - ExecuteAs proposition
On Sunday, 2010-03-07, PCMan wrote: > On Sun, Mar 7, 2010 at 8:51 PM, Dario Freddi wrote: > > I am not a big fan of this patch because (especially given what I've > > written above) I don't see a use case. > > You personally don't use it doesn't means that others don't need it or > there is no use case. > It's widely used in SuSE and it's required by some Debian/Ubuntu packages, > too. It's especially useful when you have a simple program and the part > dealing with dbus + policykit support is even bigger than the program > itself. That's the use case. > As I said previously, it's a matter of ``choice''. Developers can use > policykit if they want, but don't prevent others from using sudo > simply because you don't use it. Adding this key doesn't prevent > developers from using policykit. It only adds usefulness for those who > need it. I agree that running something as a different user is quite nice sometimes, however very often it is used as a shortcut rather than being necessary, especially when the other user is root [1]. You are of course also right that adding such an option to the spec does not prevent anyone from using more sophisticated approaches, however putting something into a spec can be interpreted of being a recommended approach. One of the contexts of this proposed additions are file actions. These often are provided through other means than distribution packages (e.g. downloads). An author of such an action could think that in order to make it work everywhere (different systems might have different security models) they would need to run the command as root. Effectively forcing all systems with more fine grained security models to reject any action asking for root, thwarting the original indent, or be dragged back to the level of less fortunate systems. If this is added to the spec it should come with a big warning for both implementors as well as users, especially in the context of using root as a sledghammer approach. Cheers, Kevin [1] like installers deciding they need to be root when installing outside of $HOME without bothering to check whether the current user has enough priviledges aready, e.g. by group membership. -- 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
On Friday, 2009-12-25, Dieter Plaetinck wrote: > I don't really understand what Kevin means. why would a distro patch > out software and strip out xdg basedir support? Right, this wasn't a good phrasing at all. What I meant is that these developers claim there are distributions which do not support the official base dir spec but deviated from it in some way. Which would imply that these distributions have to patch every application which uses base dirs to make them use their variant. Which is extremely unlikely due to the huge effort this would involve which leads to the conclusion that all distributions are using the base dir spec as intended. 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
On Friday, 2009-12-25, Bernd wrote: > Hello, > > I reported an issue on the TV-Browser issue tracker to respect the > freedesktop basedir specification: > http://tvbrowser.org:8080/jira/browse/TVB-721 > > But they closed the issue with "Won't Fix". The argument was that the > freedesktop basedir specification is distro related and not every distro > respect this specifications. > > Could someone explain me what the TV-Browser developers mean or could > someone help me to argue on the issue for TV-Browser? The basedir spec is the base of so many other specs that it is highly unlikely that any distribution with desktop related packages ha patched all of those packages to not comply with the spec. Maybe they could give an example of a distribution which patches all conforming software to use different default paths? (i.e. using something else than $HOME/.config and not having $XDG_CONFIG_HOME set to that path) 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: Fwd: Actions extensions in File Manager
On Friday, 2009-11-27, Ted Gould wrote: > On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote: > > However, these two threads refer to a 'Desktop Action' which > > was present in current 0.9.4 spec, but has disappeared from > > latest 1.1. Does this mean the 'Desktop Action' entry has been > > obsoleted ? > > More specifically, it was deleted in the 0.9.6 version as it was in > 0.9.5. I am too curious about these, as I was looking at trying > something similar for a couple messaging menu features. I'd much prefer > to use something standard. Good question, since it seems it had already been implemented by at least two file managers. Maybe there is a commit log detailing the removal reasoning? > One thing that seems to be lacking is there is not ShownIn/NotShownIn > keys for the actions. It would seem like that'd be useful for them. Wouldn't that already be covered by the respective value of the desktop file itself? I.e. if the application shows up in the launcher menu, why would its action not show up in the file manager or vice versa? Cheers, Kevin 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: Fwd: Actions extensions in File Manager
Hi Pierre, On Thursday, 2009-11-26, Pierre Wieser wrote: > Hi guys, > > I'm the Nautilus-Actions (N-A) maintainer. > N-A is an extension to Nautilus, the Gnome file manager, > which allows (advanced) users to add their own actions > in the context menu. > > This is so very similar to Konqueror Service Menus and > thunar-actions-plugin. While this might not entirely be the same thing, a quick check of my local archive of this list found two related sounding threads: http://lists.freedesktop.org/archives/xdg/2006-February/006094.html http://lists.freedesktop.org/archives/xdg/2006-June/006612.html Not sure whether this kind of action handling is deprecated or an orthogonal concept but it might make sense to at least have a look it :) 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: Desktop usability issues: some comments from the country of bears, vodka and ISO8859-5
On Thursday, 2009-09-03, Aceler wrote: > John Tapsell johnflux at gmail.com wrote at Tue Sep 1 07:00:55 PDT 2009: > >> Another issue - stealing focus. In X Window, every app that requests > >> focus, gets it. > > > > I think KWin disables focus stealing by default. Either way, you can > > turn it on focus-stealing-prevention. > > Well, if you turn the focus stealing prevention in Kwin on, it will prevent > focus stealing from all windows... including Open/Save dialogs for example. I haven't tried the most rigid setting, but I think that even then it respects transientFor, i.e. knows that it is dealing with a subwindow of the currently interactive app. At least it does on default settings. Cheers, Kevin 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: Proposed draft for the thumbnail D-Bus specification
On Friday 17 October 2008, Philip Van Hoof wrote: > The specification[1] and the prototype[2] have been adapted to this > proposal > > [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ > [1] http://live.gnome.org/ThumbnailerSpec Just a note: The description of mime_hints should probably be phrased in D-Bus terms rather than C terms: e.g. "The optional mime_hints is either empty or of the same size as the uris." instead of "The optional mime_hints is either NULL or of the same size as the uris." I wonder whether it would be cleaner to have an "overload", i.e. one Create method without MIME hints and one CreateWithHints (or better name) with a(ss) as input (array of (URI, MIME) pairs) 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: Proposed draft for the thumbnail D-Bus specification
On Tuesday 09 September 2008, Philip Van Hoof wrote: > On Tue, 2008-09-09 at 13:08 +0200, Kevin Krammer wrote: > I'm fine with adding amendments that state that cancels might be > available, but don't have to be available. IF it's clear that it's a > *might be available* not a *will be available*. > > That way it'll be a loose specification (the cancel part), but if it's > absolutely clear that it's *might be available*, then nobody will expect > any guarantees. Which is what I want for this one (you do too, so it > seems). Yes, an annotation clarifying that might help to avoid misunderstandings, though I doubt anyone with a bit of experience will ever assume always interruptable processes, at least not if they have every heard of locking or atomic operations. > In the end is a specification a contract. A contract means guarantees. True and I agree that the behavioral specification for cancel needs to be clear enough that the implementation's response time will depend on the implementation's capabilities. > I don't see the point in a specification if nobody is going to implement > it right anyway. Well, since some implementations will be done by Free Software developers who most of the times strive for technically perfect implementations, I am optimistic :) > As I *know* that a lot of implementers wont even try to get it right. True, easy-way-out is quite popular. > So your cancel will be ... > > At some point in time, it will cancel. > > Okay, then I make a cancel that cancels right after the thumbnail's > generation *is* finished. That fulfills your contract, doesn't it? Yes, it does. > But will you be happy? Since the specification does by definition not require a specific implementation, I can always look for a better implementation if the currently available ones don't make me happy. > I guarantee you implementers will do this if you specify it in such a > vague way. That's ok. Having the possibility of capable implementations is IMHO better than to guarantee that none will ever exist. > > If one delegates processing to a service, cancelling is the method of > > conveying that you are no longer interested in a result. > > But it's possible that `Ready` signals got sent already. And since your > cancel is vaguely defined as "at some point in time, it'll cancel": why > shouldn't I just keep sending the `Ready` signals until the generation > of the thumbnail *is* finished. My interpretation is that this would violate the specification for "Ready", i.e. I would strongly assume that it is not emitted during the operation, only when the thumbnail has actually been finished. Unless of course we annotate Ready to mean "I completed something, could be just reading the file". > In other words: don't implement cancel at all. True, though a sensible assumption would be that any implementation will be able to stop after finishing one uri before starting to work on the next. > That's completely correct according to your vague spec for cancel. Not very likely, but yes, it is. > So what was the point of specifying cancel in the first place then? Allowing implementors who actually care about resource usage to implement a version which provides better response times. > > I don't think it depends on an implementation detail such as thread-based > > or process-based to tell a worker to stop at the next checkpoint it > > reaches. Just because it is technically possible to hard kill a process > > doesn't mean will ever want to do that since one can easily create stale > > lock files, SHM semaphores, etc. that way. > > Checkpoints are the cancel points that I've been using in previous > E-mails. All my remarks about cancels points apply to check points too. > > Cancel (check) points are, by the way, hard. They require the entire > outside and inside API of your frameworks to cope. Yes, of course. If the API available to you takes a filename and returns an image, the best you can do is cancel after each image. If the API allows to specific a buffer, you can provide a cancel point after read. If the API allows to specify a generic I/O like a stream, you can probably cancel at ever read operation. > Like GCancellable in GIO and GVFS (I don't know what KIO has for this). Exactly! Having the cancellation as part of the API gives a hint to implementors that they ought to think about cancelling. Not having it in the API removes any hope of ever getting an implementation capable of cancelling. > Not all thumbnailers can use this. Yes, but some will. > > Since there is usually more than one way to implement a thumbnail > > algorithm, having a spec with cancel capabilities gi
Re: Proposed draft for the thumbnail D-Bus specification
On Tuesday 09 September 2008, Philip Van Hoof wrote: > I would perhaps accept an amendment to the specification mentioning the > possibility of canceling *some* of the thumbnailers's tasks. Without any > guarantees for success. Right. IMHO you focus too much on a specific and very low level interpretation of cancellation. In a lot of cases the cancel should just stop processing the queue as soon as possible. I am quite confident that nobody will assume "stop right after this machine instruction". If one delegates processing to a service, cancelling is the method of conveying that you are no longer interested in a result. I don't think it depends on an implementation detail such as thread-based or process-based to tell a worker to stop at the next checkpoint it reaches. Just because it is technically possible to hard kill a process doesn't mean will ever want to do that since one can easily create stale lock files, SHM semaphores, etc. that way. Since there is usually more than one way to implement a thumbnail algorithm, having a spec with cancel capabilities gives hint to developers of such implementations that they should probably think about where to put check points. 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: Specifying thumbnailers as a service
On Friday 29 August 2008, Philip Van Hoof wrote:
[snip]
> That, combined with Rob Taylor's proposal, brings me to this DBus API:
>
>
>
> foreach ([mime-part] in supported_mime_parts) {
>
>
I am not sure you need a separate interface name for each MIME type. Most
likely the thumbnail service will have to decide about the MIME type itself
anyway.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
What do others think about having a signal like this
I know that "Create" is annotated as async but the client might want to start
using/displaying thumbnails as the come in, e.g. in batches, and not wait
until all requested ones have been completed.
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: [TextShare] - proposal to make a desktop-wide format for text
On Friday 20 June 2008, Liam R E Quin wrote: > On Thu, 2008-06-19 at 22:21 +0200, Kevin Krammer wrote: > > [...] > > > I have to admit that I might have misunderstood the purpose of the > > thread, since some other comments indicate that other people understand > > it as looking for solutions regarding simple formatting, not HTML or word > > processor like separation of structure and style. > > I started the discussion because I want to see reliable interoperability > for copy/paste (and of course drag/drop) between applications on the > various Free desktops. According to some interoperability testing I did a couple of years ago, most problems had very little to do with available formats but rather applications advertising or checking for formats in different orders, e.g. source application starting with its native format and ending with text/plain and the destination application also starting with its native format but checking the fallbacks in a different order, ending up with a worse match than they could have accomplished. > I want something better than plain text -- GMarkup is a little too > minimal -- but we can't expect every application to support all of > ODF. The ones that do can use ODF as a clipboard format already. Hmm, I don't know enough details about ODF, but I assumed that its XML based allowed readers to skip all markup they don't know about and writers to create very minimalistic documents if they don't have much information. However, as I said before, I seem to have misinterpreted the intentions, I personally was thinking along something similar to what Windows uses (Microsoft-)RTF for, capable of transporting word processor level data. > I admit I was originally planning to propose a small, extensible XML > vocabulary that would be a superset of the markup that Gtk+ and Pango > use today, and also compatible with Qt/KDE's HTML-like markup. I am not sure that creating yet-another-format will be benefitial, because additionally to advocating it to application developers (which would also be necessary for any other option), it has to be implemented and shipped in at least the four major sofware stacks (GTK+, Qt, Mozilla, OOo). If the decision is that a document interchange format is not needed within this scope, I'd say that, given the main software stacks above, the most logical recommendation is XHTML (GTK+ and Qt have WebKit, Mozilla's main product *is* a web browser and OOo can already do at least file based I/O from/to HTML) 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: [TextShare] - proposal to make a desktop-wide format for text
On Thursday 19 June 2008, François Revol wrote: > > On Tuesday 17 June 2008, Liam R E Quin wrote: > > > For this to work, we need cross-desktop agreement on a format > > > for the text. Since most clipboard mechanisms let applications > > > give a list of available formats, this format need not be the > > > only (or even preferred) format for all applications, but it > > > should be widely supported. > > > > IMHO a suitable candidate would be OpenDocument. > > The destination program can selectively, depending on its > > capabilities, > > extract any level of details, e.g. just the content, basic > > formatting, etc. > > Well, other candidates could be possible, like PDF, but it doesn't > maintain a real logical sturcture AFAIK. I am not sure PDF would be a good format for data that is still supposed to be edited. > > Especially if one considers not only text made of words, but also > > situations > > where currently a text based exchange is used for structured data, > > e.g. > > tables formatted as CSV, or text data is mixed with non-text data, > > e.g. > > BeOS/Haiku spreadsheets can use text/x-csv or something I think... CSV is just not a good solution, since it requires a lot of "knowledge" on the receiver side, e.g. which character/string is used as a delimiter, if cells containing it are quoted or if the delimiter is escaped, how it is escaped, etc. > But it should be easy to add others. OOo format would be a little > harder until it's ported and a translator for it is written though. I don't think any application specific formats should even be considered, especially not when the application in question has already changed away from it (OOo uses ODF now). I have to admit that I might have misunderstood the purpose of the thread, since some other comments indicate that other people understand it as looking for solutions regarding simple formatting, not HTML or word processor like separation of structure and style. 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: [TextShare] - proposal to make a desktop-wide format for text
On Tuesday 17 June 2008, Liam R E Quin wrote: > For this to work, we need cross-desktop agreement on a format > for the text. Since most clipboard mechanisms let applications > give a list of available formats, this format need not be the > only (or even preferred) format for all applications, but it > should be widely supported. IMHO a suitable candidate would be OpenDocument. The destination program can selectively, depending on its capabilities, extract any level of details, e.g. just the content, basic formatting, etc. Especially if one considers not only text made of words, but also situations where currently a text based exchange is used for structured data, e.g. tables formatted as CSV, or text data is mixed with non-text data, e.g. copying a selection in a browser, including images. In any case I recommend having a documentation of best practices, e.g. in which order the source should advertise formats, or if targets should check the formats in a specific order, etc. 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: Commit notifications for specs
On Thursday 01 May 2008, Emmanuele Bassi wrote:
> On Thu, 2008-05-01 at 15:21 +0200, Kevin Krammer wrote:
> > On Wednesday 30 April 2008, Emmanuele Bassi wrote:
> > > On Wed, 2008-04-30 at 19:06 +0200, Pau Garcia i Quiles wrote:
> > > > > by the way: GIO implements various fd.o specifications - the
> > > > > thumbnailing specification, the trash spec, the shared mime info
> > > > > spec, etc. exactly like KIO does.
> > > >
> > > > KIO and GIO could have shared plugins ("slaves", in KIO slang) but
> > > > they do not. That would have been very useful.
> > >
> > > how would have this been even possible? GIO backends are implemented as
> > > GObject using the GModule API, and they are even out of tree from the
> > > GIO main library (see the gvfs module inside GNOME's SVN).
> > >
> > > it would be possible to write a GIO backend using KIO modules, and GIO
> > > wouldn't even notice that. the obvious requirement, though, would be
> > > that the backend used GObject to be implemented.
> > >
> > > good luck.
> >
> > I have to admit that I only had a quick look at the GIO architecture, but
> > as far as I understand its remote protocol handlers are, like KIO's IO
> > slaves, implemented as out-of-process helpers, thus communicating with
> > the application through a protocol.
>
> those are the backends inside gvfs and yes, they can rely on a low-level
> implementation that has nothing to do with GObject; new backends will,
> however, inherit from GvfsBackend which is a GObject.
Ah, backends was the name I was looking for.
Pau's suggestion was to look into sharing such backends, which would not
require any specific technology stack on either side since all operations are
serialized through some socket anyway.
Your implementation will obviously use shared facilities you provide in your
libraries such as GvfsBackend, but this is not an archtectural requirement,
isn't it?
> after that, we have gio - which is just the generic high-level API which
> will create an "extension" using a module which must return a GType.
If I understand this correctly, this is about in-process plugins, right?
> hence, yeah: you need GObject to create a GIO backend. you can then use
> whatever API to actually implement it - which is how, I guess, the KIO
> slave using GIO is written.
Yes, GIO/KIO bridge is written (AFAIK) as a usualy KIO slave (meaning it uses
kdelibs) and using the GIO API.
Of course it doesn't have to use any KDE code, but I guess this is faster
right now.
I am currently busy helping in the Akonadi project, but at some point I'd like
to try a "KDE stack" implementation of the GVFS protocol, mainly for
accessing GVFS backends from KDE applications but probably also for
implementing backends.
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: MPRIS 1.0
Hi, I am catching up with my huge baclog of postings on the xdg list, so sorry for the delay. On Wednesday 26 March 2008, Mirsal Ennaime wrote: > Hi, > > The Media Player Remote Interfacing Specification v1.0 was released a > little while ago without an announcement on this list. > > The spec is hosted here: http://wiki.xmms2.xmms.se/index.php/MPRIS The spec doesn't include any hints how to implement the interface's methods which are not described for either object, e.g. how to implement org.freedesktop.MediaPlayer.Quit when it is being called on the /Player object, the spec only says it should make the application exit when being received by the root object. Given that the three objects have really different scopes, it might make more sense to have three interfaces rather than having lots of dummy implementations for methods out of the object's intended scope. 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: Commit notifications for specs
On Wednesday 30 April 2008, Emmanuele Bassi wrote:
> On Wed, 2008-04-30 at 19:06 +0200, Pau Garcia i Quiles wrote:
> > > by the way: GIO implements various fd.o specifications - the
> > > thumbnailing specification, the trash spec, the shared mime info spec,
> > > etc. exactly like KIO does.
> >
> > KIO and GIO could have shared plugins ("slaves", in KIO slang) but
> > they do not. That would have been very useful.
>
> how would have this been even possible? GIO backends are implemented as
> GObject using the GModule API, and they are even out of tree from the
> GIO main library (see the gvfs module inside GNOME's SVN).
>
> it would be possible to write a GIO backend using KIO modules, and GIO
> wouldn't even notice that. the obvious requirement, though, would be
> that the backend used GObject to be implemented.
>
> good luck.
I have to admit that I only had a quick look at the GIO architecture, but as
far as I understand its remote protocol handlers are, like KIO's IO slaves,
implemented as out-of-process helpers, thus communicating with the
application through a protocol.
Why do you thing a handler for that protocol would have to be implemented
using a specific technology like GObject?
Usually any advanced enough software stack is capable of doing that, but as I
said I don't know the details of GIO, however since on the KIO side no such
restriction exists, I would be quite puzzled if the GIO protocol would.
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: Commit notifications for specs
On Wednesday 30 April 2008, Pau Garcia i Quiles wrote: > A KDE developer (his nick is 'nf2', I can't remember his name) Norbert Frese, but he is a GLib software stack developer (probably even a GNOME developer) and is only recently working on KDE code, i.e. the bridge you are referring to. > developed a GIO->KIO bridge which makes possible to use GIO plugins in > KIO. It was not accepted in KDE, I can't remember why. But this bridge > would have been unnecessary, or at least a thinner layer, had a common > spec and/or API be agreed. The bridge needs, according to Norbert, some changes to KDE libs, which at the time of adding the bridge to KDE SVN playground was frozen for 4.0 I think it is quite common to test new additions in the playground -> review -> main module cycle, so I wouldn't call that "not accepted". And I don't agree with "unnecessary" either. It provides as test bed and a potential migration path, so it is a good start at sharing VFS implementations. 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: fuse desktop integration / management library
On Freitag, 20. April 2007 +0100, nf2 wrote: [snip] > the fuse management system should consist of three parts: > > * a glib main-loop based client library (async mount/umount operations, > events) > * a dbus service (session bus) > * an (optionally linked) library used in fuse modules for authentication > callbacks and progress/logging events Designing a good library is quite hard, maybe it would be easier, especially to get something usable fast, to just implement the management service and decide later if it is necessary to split something into a reusable library. My guess is that there won't be much need for alternative daemon implementations if the original one is already good, so any effortspent for clean library design would be "wasted" if there will always be jsut the original daemon using it. On the subject of progress, I think there is an ongoing collaboration of GNOME and KDE developers to create a D-Bus interface specification for this. > i am working on a desktop independent vfs library > (http://www.scheinwelt.at/~norbertf/devel/vio/), but perhaps FUSE should > also be considered as an option to get the "layering" right - to move > VFS related stuff underneath the desktop layer... The problem of using "local file access" from GUI applications is that there needs to be mechanisms to ensure they can list directories and read/write files without blocking. They need to have a way to discover that a file is actually a remote resource. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpNLw17gFy0Q.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: proposal for extending XSETTINGS registry keys
On Wednesday 28 March 2007 21:07 +0100, Avi Alkalay wrote: > Elektra can easily be the infrastructure for storing this keys, with the > benefit of not being just desktop-oriented, but cross-system oriented. I think (could be wrong) the main idea of XSETTINGS is that they are supposed to be available through X11, thus being available to application on remote machines which connect to the client's Xserver. The location where the XSETTINGS manager stores the values is an implementation detail. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgppLRllgS8bY.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On Thursday 22 March 2007 19:25 +0100, Thiago Macieira wrote: > Kevin Krammer wrote: > >> Any library designed to be used by other languages. > > > >Hmm, I thought that the main idea in D-Bus is to always use bindings. > > True, but many projects feel they must provide a C library that wraps the > D-Bus calls. They don't bind to the application, though and don't use a > binding. I know and I admit that it is a good use case for applications where this is the only use of D-Bus. However, as someone else mentioned in this thread, such a wrapper library can then opt to cache the "ugly" dictionary in some context/handle and provide easy primitive accessors. I agree with Havoc that this issue has gotten more attention in this thread than necessary, but I was quite irritated that the use case of a convenience wrapper would have such strong influence on the actual D-Bus API. Bitfields are a low level method of implementing sets of booleans and therefore might not be a very good choice in a high level abstraction like a D-Bus interface. As a bad example see Microsoft's usage of bitfields in their XML office document format. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpnvF8XyknDS.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On Wednesday 21 March 2007 23:57 +0100, Carsten Haitzler wrote: > On Wed, 21 Mar 2007 22:05:34 +0100 Kevin Krammer <[EMAIL PROTECTED]> babbled: > > On Wednesday 21 March 2007 21:57 +0100, Richard Hughes wrote: > > > On Wed, 2007-03-21 at 15:58 -0400, Havoc Pennington wrote: > > > > As an alternative to a bitfield, one option is a dictionary of > > > > properties. This is most likely nicer than a bitfield in say python, > > > > and more annoying than a bitfield in C. > > > > > > Yes, a dictionary might be nice, but it's not trivial to access in C. > > > This stuff really needs to be *trivial* for an application to access, > > > hence why I think booleans are probably best. > > > > How likely is an application written in C not going to use the D-Bus glib > > bindings? > > > > (Assuming that these bindings support dictionaries) > > hand up in this corner for starters. I am pretty sure they do, but since I haven't used them myself yet, I thought it would be better to word it as an assumption. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgp5cDdnIF3nT.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On Thursday 22 March 2007 06:55 +0100, Thiago Macieira wrote: > Kevin Krammer wrote: > >> Yes, a dictionary might be nice, but it's not trivial to access in C. > >> This stuff really needs to be *trivial* for an application to access, > >> hence why I think booleans are probably best. > > > >How likely is an application written in C not going to use the D-Bus > > glib bindings? > > Any library designed to be used by other languages. Hmm, I thought that the main idea in D-Bus is to always use bindings. How would one deal with D-Bus APIs that already use dictionationaries? Just ignore those methods in wrappers? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpMoy0bJr2Y3.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On Wednesday 21 March 2007 21:57 +0100, Richard Hughes wrote: > On Wed, 2007-03-21 at 15:58 -0400, Havoc Pennington wrote: > > As an alternative to a bitfield, one option is a dictionary of > > properties. This is most likely nicer than a bitfield in say python, > > and more annoying than a bitfield in C. > > Yes, a dictionary might be nice, but it's not trivial to access in C. > This stuff really needs to be *trivial* for an application to access, > hence why I think booleans are probably best. How likely is an application written in C not going to use the D-Bus glib bindings? (Assuming that these bindings support dictionaries) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpa2prDnAJcO.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: org.freedesktop.PowerManagement
On Wednesday 21 March 2007 20:39 +0100, Richard Hughes wrote:
> On Wed, 2007-03-21 at 18:36 +, Rob Taylor wrote:
> > Does it need a signal for the capabilities changing? e.g. if not on an
> > active console, or permissions have changed?
>
> Ahh. Valid point.
>
> That would require signal like CanSuspendChanged and CanHibernateChanged
> unless we use your bitfield thing.
>
> > It might also make sense to just have a Capabilities bitfield rather
> > than seperate calls for Suspend, Hibernate, Reboot and Shutdown. You're
> > gonna call all of them at startup anyway, so makeing it one call reduces
> > bus round trip considerably.
>
> Sure, I appreciate that. Using a bit field does make the API more
> complex (replying on magic constants) rather than a simple boolean
> output. I'm open to doing it using a bitfield if this is common
> consensus, but I must admit I like the individual API myself.
I agree. Bitfield sounds a bit like premature optimization.
I am not sure how often this is expected to be called, but an array of items,
e.g. array of "usable" method names, might be more flexible.
Or even a list of property dicts, e.g.
{ "Capability" => "Hibernate",
"Users" => [ "root" ],
"Groups" => [ "root", "powerdev" ],
"Access" => "AtConsole" }
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
pgpDCdUE0zhkQ.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: well-known user folders, a proposal
On Monday 26 February 2007 10:15, Alexander Larsson wrote: > On Mon, 2007-02-26 at 09:22 +0100, Benjamin Meyer wrote: > > On Friday 23 February 2007 22:09, Thiago Macieira wrote: > > > Benjamin Meyer wrote: > > > >Both Windows and OS X also have a "Movies" and "Applications" > > > > directory. It would be nice to match them. Not that these two have > > > > to be created, but if they were there it would be nice to know where. > > > > > > > >-Benjamin Meyer > > > > > > Hey Ben, > > > > > > I agree with Movies, but what would we put in Applications? Installing > > > applications isn't that easy in a generic way on Linux yet. > > > > Neither is it on Windows. :D It just points to C:\Program Files if I > > recall. Not that informative. > > Movies is in the latest version, but i'm a bit about applications. What > apps would use that on unix? Third party installers maybe (usually used for games), or software installed via autopackage, klik, zeroinstall Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpXpx5ziMzax.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: well-known user folders, a proposal
On Thursday 22 February 2007 14:07, Alexander Larsson wrote: > Several people have proposed using symlinks like this. It certainly > makes it very easy to use from a shell. However, there is imho a clear > risk that such filenames (like ~/.mdk-folders/.desktop/) escape to the > user in an unresolved form and end up exposing internal implementation > details in e.g. the file chooser. Thats why I avoided them in my > version. Symlinks also have the problem of sometimes not being available. I have seen several questions asking how to use a home directory (and more specifically KDE) mounted from a remote host, where the remote host is having a broken/incomplete implementation of CIFS (usually a Windows system) and can'tdo symlinks. Sure, it is just a small percentage, but if one can avoid it, maybe one should. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpaDyrLpN7nY.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: MPRIS Media player Remote Interfacing Specification
On Thursday 08 February 2007 21:37, Mirsal ENNAIME wrote: > Here's the wiki page we'll work on: > http://wiki.xmms2.xmms.se/index.php/Media_Player_Interfaces Just a little suggestion: The wiki page says that all media player methods have to be part of the org.freedesktop.MediaPlayer interface, but it does not say which interfaces the Identity method on the root object and the methods on the /TrackList object belong to. And maybe an idea for CapabilityChange: - you'll probably also want a call to get the currently available capabilities for clients that connect later on - if every capability maps to one of the methods, you could have the method name (maybe including interface name) as the capability identifier, thus not needing to agree on a hardcoded mapping of other identifiers to available methods. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpx8jrwLEAZH.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
On Thursday 08 February 2007 22:35, Mikkel Kamstrup Erlandsen wrote:
> Yes, that was the plan, it is a small thing to define them though. Ideally
> I think we should only define the interface name and dbus had a magic
> method GetObjectForInterface("org.freedesktop.blah"), but as far as I know
> this is not possible...
An interface can be implemented multiple times.
What would you expect such a call to return if you pass the interface
org.freedesktop.DBus.Introspectable? (likely implemented by almost all object
on all connections)
However, consider there would be a specified Wasabi D-Bus name, e.g.
org.freedesktop.wasabi then the bus could start a service known to register
this name (see D-Bus activation)
This is why I thought that the specification really should specify such a
name.
> This leads me to a question I've been thinking about... Why is it not
> custom to version your dbus interfaces? XML namespaces (typically) does
> that for example. I was wondering whether to use
> org.freedesktop.wasabi.search.1 for instance, not that I expect the api to
> change. But if we ever add api we could define a .2 or something like
> that...
D-Bus interfaces is a bit like dlopen. If the method isn't present, you'll get
an respective error (assuming the service implemenation handles this
correctly)
And as you said, it is quite likely that if the interface would have to be
extended, it might even make sense to specifiy a whole new interface and keep
the old one for backwards compatability.
However, I am not sure what the "official" D-Bus take on this subject is.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
pgpTsOdkI0u1W.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
On Tuesday 06 February 2007 23:12, Mikkel Kamstrup Erlandsen wrote: > This email have been sendt to: desktop-devel-list@gnome.org, > [EMAIL PROTECTED], [EMAIL PROTECTED] , xdg@lists.freedesktop.org > > * In Short: > Wasabi is new project with the goal of creating a unified, platform > independent, specification and api for desktop search engines (and later > metadata services). We have worked together with several search-projects > and now have a proposal ready for public evaluation. In short: we need > feedback It would be nice if the specification would include object path and optimally D-Bus connection name where the interfaces are likely to be found. Otherwise a potential search client has to introspect all D-Bus names and all object paths on each of them. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpnRtq7x0mZM.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Recommendation for $HOME
On Tuesday 05 December 2006 17:27, Aaron J. Seigo wrote: > On Tuesday 05 December 2006 8:58, Thomas Güttler wrote: > > If email is stored under $HOME the path to the > > inbox directory should be $HOME/Maildir/Inbox/. > > we used to use this (well, ~/Mail) as the default but more innocent users > occasionally ended up deleting (!) their email since they didn't know what > it was. after all, they couldn't remember making it so how important could > it be? ;) > > so one may want to be very cautious about auto-creating user-visible > directories that contain data. I'd jsut like to add that having this user visible ~/Mail directory resulted in several distributors pacthing KMail to move it elsewhere. Maybe $XDG_DATA_HOME/Mail, which usually will be ~/.local/Mail Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgps1AT3Y30Fy.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: simple search api (was Re: mimetype standardisation by testsets)
On Monday 27 November 2006 12:08, Mikkel Kamstrup Erlandsen wrote: I am not a searching or indexing expert, merely wanted to input some information regarding D-Bus sync/async calls :) > I think you raise a really good question Kevin. Let me first introduce > some terminology to ease the communication. > > Page Query: All results for a given query is returned in one chunk. This > call is still *async* since it is over dbus. This is how it is sugegstedin > on the WasabiDraft wiki page. > > Async Query: Query results trickle in as the search engine picks them up. > Ie all query results are not returned in one batch. I'd rather call it "Full" and "Partial" Query or Query with "Full" or "Partial" delivery. > In the page query the client can simulate an async query by requesting > several blocking queries with the same query string, but different > page-ranges. This gives a small problem with page ordering, but nothing > that the client app could not work around. The big benefit for page queries > is that server side sorting (score, relevance, date, whatever) is a > no-brainer for the client. Just append the "sort:" switch to the > query string. How long does a search service have to cache such a query - result combination? Or is searching so fast, that the same query can be re-done on every call? > In the async query you have a sorting problem. The client cannot sort the > hits, unless each returned URI also has metadata associated with it (it > looks this stuff up with another dbus call). I see a huge benefit in > allowing the results to trickle in (and allows for canceling queries as > Kevin points out). The async query is also much more suitable for live > queries (in the sense of updating the query when the on-disk files change - > or are deleted/created). Would it be possible to associate a sorting key with each match? If so it could be part of the returned data, i.e. the result being an array of tuples of URI and key. > So what do I think? I see 2 options: > > 1) Change the Query method name to PageQuery and add another AsyncQuery > with a signature and behavior we need to think a bit about. > > 2) Don't change the org.freedesktop.search.simple interface, but create > another interface generally aimed at live queries - or maybe include this > in the "advanced" search interface when we get to defining that. A more advanced interface could be based on query objects, i.e. the client requests a remote peer object for a specific query and the service creates an handler object and returns the object path. The client can then call this object's methods and listen to this object's signals, without needing to reference it with the query string at each call or on each signal. The object path will be the reference Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpdbaXcBzn5T.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: simple search api (was Re: mimetype standardisation by testsets)
On Sunday 26 November 2006 18:17, Jean-Francois Dockes wrote: > Jos van den Oever writes: > > 2006/11/26, Jean-Francois Dockes <[EMAIL PROTECTED]>: > > > 1- A need for trivial enabling of text search in any (non-search) > > > application, with minimal fuss, (better described by Fabrice in > > > the quoted message). > > > > For this, we also need a way to search in documents that have not been > > indexed. Indexes can take up a lot of space and the user might not > > want to have an index of all her data, but still want to search that > > data now and then. > > Since searching in this way is a lot slower, there would need to be a > > more asynchroneous method of reporting the search results. > > I'm not a d-bus expert, but at least with the qt4 bindings, it seems that > you have a choice of waiting for the reply to a d-bus message, or be called > later when it arrives. There doesn't seem to be anything inherently > synchronous in d-bus, so I would imagine that other bindings or adaptors > have similar capabilities. Technically correct, this is a feature of the low-level D-Bus library. However this is a different use case. The asynchronous D-Bus call is for getting _the_ result later. The use case discussed here is slightly different (unless I am misunderstanding) it is about returning _some_ results later. Example: a user searches through a lot of emails. The program should be able to display results as soon as possible. At this point the results do not need to be complete, matches can trickle in when found. An asynchronous call would still have to wait for all results, i.e. a completed query. The user would have to wait for the slowest match. An option would be to have the initial query call return a query identifier instead of results and results would be transported by D-Bus signals using this identifier as a reference. A bonus would be to have the possibility of cancelling a query using this identifier. The user might already have found what they were looking for and cancel the search operation in their program. An ongoing searching operation would not be a problem for the program (it can just ignore any further results), but it could be hard to explain to a user why their harddisk keeps accessing files like mad. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpbZfYxlNAF0.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Hello + sound event architecture
e. Which implies that the client or client library have to know the current notification policies and be notified about changes to this policies. IMHO this sounds a lot more complex than letting a single service to it, as it is implemented now. What would be the most important advantage over centralized notification handling? > > True. But in which use case would a client program want to play a > > notification sound without doing a notification? > > See the first comment for a common usecase. Applications like Nautilus > or GNOME Panel never use notification popups as the sounds are attached > to things like "an application is launched" or "current path is > changed". Well, "an application is launched" or "current path is changed" still sound like notification events to me. I get the impression you are assuming that a notification's representation is somehow required to have a visual part. I find it quite unlikely that any of the currently used notification daemons would require this. > > Or how would you synchronize the visual and accustical part if they are > > separate method calls? In the worst case even to different daemons? > > If you need both, you let notification daemon handle both (or pass one > to an external sound daemon if needed). I am afraid I don't see the gain in bypassing the notification daemon for some subcategory of events. > See attachment for a draft. I'll leave the details to the people with icon theme spec experience, but shouldn't it be $XDG_DATA_HOME/sounds instead of $HOME/.sounds? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgp9dAbf9ww6N.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Hello + sound event architecture
On Sunday 12 November 2006 17:13, Patryk Zawadzki wrote: > Dnia 12-11-2006, nie o godzinie 16:54 +0100, Kevin Krammer napisał(a): > > On Sunday 12 November 2006 00:52, Patryk Zawadzki wrote: > > > We do have a working specification for icon themes so why not just > > > adapt a similar specification for sound events? > > > > I'd say sound themes and notifications are orthogonal things. Sound is > > just one presentation form of a notification. > > This could be further expanded to cover all areas of notification but as > the galago-project provides us with a working notification-daemon for > desktop popups, I'd like to start with a generic sound event daemon and > then we can talk about a higher-level specification that internally uses > both of these. Well, and knotify already supports popups, dialogs, sounds and ... Of course, assuming that a sound handler would be available, knotify could delegate sound playing to it, however I think it is more likely that it just continue handling the sounds itself. Given a sound theme specification it could play the same sounds solutions composed of galago and a separate sound playing daemon would use. > > Depending on the actual notification architecture, users might have > > explicit configuration for certain sounds, not just generic names. > > Could you give an example? For example instead of having one "online" sound for all users in your IM's contact list, having specific sounds for certain users or groups of users. > My proposition would allow for more customization that is possible now. More customization than deciding if a sound should be played and which paricular one for each single notification? > User could replace certain soundby providing her own versions in > her .sounds directory. IMHO sounds should be selectable from any path, requiring to copy a file into a certain location will make the usuability folks show up on your doorsteps, torches lit, rope ready and all that ;) > She can also opt to temporarily mute all sound > below a certain importance threshold for example to get a better movie > watching experience. Same could be offered by the notification daemon to > suppress the popups temporarily (and possibly offer a log to review > later). So, depending on the actual implementation, it would require two daemons to know about the current situation instead of just the notification daemon? Wouldn't it be better to allow the notification daemon to temorarily alter the notification representation? > > > The idea is to create a robust sound event handling system based on > > > DBUS that would allow an application to tell the daemon to "play > > > gaim-user-online with priority of notification," let the daemon handle > > > the event and let the app forget about it completely. > > > > So such a D-Bus service would then be used by the nofitication daemon(s) > > when the event configuration indicates a representation including a > > sound? > > Yes, it should be. But for a good start, letting applications themselves > delegate sound playback would be a huge step ahead. Hmm, sound like this would require the notification representation handling inside the client instead of inside the daemon since the application would need to know if it should play a sound and which one, and then call either both notification APIs or just the one for the visible part. Just calling a single notification API like now sound a lot easier to me. > > > To me such a daemon specification and a "sound theme" specification > > > would be a great start for even futher integration between various > > > desktop environments and between apps and their desktops as well. > > > > Well, I can see a definite value in a sound theme specification, however > > I'd rather have the notifcation daemons or, in the event of a shared > > implementation the notification daemon, do the sounds playing directly > > instead of further delegating it. > > You can combine both into a single daemon that just implements two DBUS > namespaces. True. But in which use case would a client program want to play a notification sound without doing a notification? Or how would you synchronize the visual and accustical part if they are separate method calls? In the worst case even to different daemons? > > I'd recommend concentrating on the sound theme specification. Just like > > the icon theme spec it will already be useful without a shared > > loading/caching/displaying/playing implementation. > > This should be an easy thing to do given that the icon specification > works. I propose just rewording the icon spec to talk about sounds and > sound themes and r
Re: Hello + sound event architecture
On Sunday 12 November 2006 00:52, Patryk Zawadzki wrote: > Hi all, > > I am new to the list and would like to introduce myself. My name is > Patryk Zawadzki and I am one of the PLD Linux developers. > > This said, I'd like to ask a question (hope this was not discussed here > like two days ago as my internet connection is faulty and I am unable to > search through the mailing list archives). There have been several threads about notification handling. Almost everybody agrees on doing this with a session daemon, however things like configuration (central vs. application specific) are usually debated with very little progress. > We do have a working specification for icon themes so why not just adapt > a similar specification for sound events? I'd say sound themes and notifications are orthogonal things. Sound is just one presentation form of a notification. Depending on the actual notification architecture, users might have explicit configuration for certain sounds, not just generic names. > The idea is to create a robust sound event handling system based on DBUS > that would allow an application to tell the daemon to "play > gaim-user-online with priority of notification," let the daemon handle > the event and let the app forget about it completely. So such a D-Bus service would then be used by the nofitication daemon(s) when the event configuration indicates a representation including a sound? > To me such a daemon specification and a "sound theme" specification > would be a great start for even futher integration between various > desktop environments and between apps and their desktops as well. Well, I can see a definite value in a sound theme specification, however I'd rather have the notifcation daemons or, in the event of a shared implementation the notification daemon, do the sounds playing directly instead of further delegating it. I'd recommend concentrating on the sound theme specification. Just like the icon theme spec it will already be useful without a shared loading/caching/displaying/playing implementation. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpWRffp1EBYa.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
xdg-terminal: launching the preferred terminal emulator
On request from people on xdg list I've added a first draft script for launching the preferred terminal emulator program. xdg-terminal is excluded from "make scripts" like the other experimental scripts, you can enabled it in xdg-utils/scripts/Makefile.in if you want to work on the xdg-terminal.in source Current version attached Only tested on KDE so far, using default setting and xterm as an override setting. Follow-ups preferably to the Portland list, thanks. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring xdg-terminal Description: application/shellscript pgpoQlhVWiy1I.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard for the user's default terminal
On Monday 23 October 2006 20:46, Jaap Karssenberg wrote: > Kevin Krammer wrote: > ... 8< ... > > > If somebody can find a way to GNOME and XFCE I'll write the xdg-utils > > wrapper script > > Looking at an RC for xfce 4.4 here. > > Xfce has a directory called "share/xfce4/helpers/" which contains > desktop entry files for commonly used terminals, browsers and email > apps. These entries contain extra keys like X-XFCE-Category=WebBrowser > or X-XFCE-Category=TerminalEmulator . > > Then there is a file called ".config/xfce4/helpers.rc" which in my case > looks like: > > WebBrowser=firefox > MailReader=thunderbird > > So I assume the categories are used to generate a list with applications > for the "Preferred Applications" setting dialog where you can configure > these apps and the helpers.rc file just names the desktop entries to use. > > Must say that this looks like a very good use of desktop entry files to > me. Very simple and elegant. > > I'm just an Xfce user, not a developer. Thanks, that helped to look into the right directions :) Its actually very easy on XFCE: exo-open --launch TerminalEmulator Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpgoRNJHm5th.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard for the user's default terminal
On Monday 23 October 2006 14:27, Kevin Krammer wrote: > On Monday 23 October 2006 14:18, Hongli Lai wrote: > > Kevin Krammer wrote: > > > Valid use case, I have to admit I didn't think about non-DE > > > filemanagers. > > > > > > Maybe, as a intermediate solution, start whatever $TERM points to if it > > > is set and/or offer a setting for the preferred terminal. Users wanting > > > a terminal should be able to configure this. > > > > > > Cheers, > > > Kevin > > > > Starting $TERM will often not work correctly. Both gnome-terminal and > > Konsole set $TERM to xterm. > > That's why I called it an intermediate solution. > An admin or distribution caring about this can set the $TERM in the desktop > startup, for example for KDE by adding a sourceable file to $KDEDIR/env > > But since this seems to be such an important problem I'll try to find out > how to get KDE's terminal setting later today. In KDE it could be done like this terminal=$(kreadconfig --file kdeglobals --group General \ --key TerminalApplication --default konsole) If somebody can find a way to GNOME and XFCE I'll write the xdg-utils wrapper script Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpZ1wvTIE77H.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard for the user's default terminal
On Monday 23 October 2006 14:18, Hongli Lai wrote: > Kevin Krammer wrote: > > Valid use case, I have to admit I didn't think about non-DE filemanagers. > > > > Maybe, as a intermediate solution, start whatever $TERM points to if it > > is set and/or offer a setting for the preferred terminal. Users wanting a > > terminal should be able to configure this. > > > > Cheers, > > Kevin > > Starting $TERM will often not work correctly. Both gnome-terminal and > Konsole set $TERM to xterm. That's why I called it an intermediate solution. An admin or distribution caring about this can set the $TERM in the desktop startup, for example for KDE by adding a sourceable file to $KDEDIR/env But since this seems to be such an important problem I'll try to find out how to get KDE's terminal setting later today. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpgxObDFoLuq.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: more about the standard File Manager API
On Sunday 22 October 2006 22:59, Marcos wrote: > Hello again, Kevin > Hello Fred > > Am I talking about embedding the desktop's filemanager ? > Good question! I never saw the problem at this point of view. > > My initial objective was just to add ( and modify and extend ) the context > menu from the default file manager for files and folders in my application. > The files and folder representation was being done by myself, althought the > icons come from the user's window manager. > > Since the context menu will be extended, I don't think one can call it > embedding. I though about embedding because you wrote about "implementing it _in_ an application" So you want to have the file manager running but extend its context menu with additional functionality, which at the moment boils down to writing plugins for the targeted file managers, e.g. Konqueror, Nautilus,... > > - veto the operation > > I expect to veto the operation, also to add new opens I don't think filemanagers allow this kind of changes right now, or at least not directly (it might be able to locate the "action object" and disable or disconnect it) > the default File Manager API just have to return, for each line of the > context menu: > > a) type of the operation (fixed) > b) name of the operation (which might vary according to the user's locale) > c) a pointer of the function which performs the operation > d) some extra stuff I've forgotten Hmm, customizing the context menu could be doable with a common plugin API, however this would, in the case of operation overriding, create difference between actions triggered from the context menu and actions triggered for example by keyboard shortcuts. Just extending the menu, i.e. adding actions, should be less problematic, the filemanagers already allow this to some extend. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpm8yQWhxBhK.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard File Manager API
On Monday 23 October 2006 01:53, Robert Martin wrote: > What i would like to see is a Common File Browser (dialog) so that if > im in GNOME i have a sane file browser (for some reason on my KDE > system the only tool that mounts my PPC has a Gnome file browser) That's one of the Portland integration goals. I did a wrapper script for native file dialogs, but I think the embedding is moved to the second integration stage (when we have a service API) Of course applications still have to use it, user's requesting this might be helpful ;) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpScaL7XJBlZ.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard for the user's default terminal
On Sunday 22 October 2006 22:11, Marcos wrote: > Kevin, > > It would be interesting, if in a file manager one could right click on a > folder and open the terminal windows on exactelly that folder. Although a > little bit biased, I can give you two examples for that: > > a) "Open Command Window Here" for ms windows > Source: > http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx > This PowerToy adds an "Open Command Window Here" context menu option on > file system folders, giving you a quick way to open a command window > (cmd.exe) pointing at the selected folder. I guess the unix filemanagers have extension methods like this as well. Konqueror for example has its service menu mechanism for this, but since it can have an embedded console follow all path changes, people usually use this > b) The application that I am developing: TreeSize for Unix > http://treesize.sf.net ( it currently uses xterm to open terminals ) > > This is a feature that the beginner user would never use, but the power > user would love. > > Of course I could just keep opening xterm forever, but it would be much > more confortable for the user if his prefered terminal was opened. Valid use case, I have to admit I didn't think about non-DE filemanagers. Maybe, as a intermediate solution, start whatever $TERM points to if it is set and/or offer a setting for the preferred terminal. Users wanting a terminal should be able to configure this. Cheers, Kevin -- Kevin Krammer, KDE developer KDE user support, developer mentoring pgpy0vdewa43w.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard for the user's default terminal
On Sunday 22 October 2006 18:17, Marcos wrote: > With xdg-open one can open every associated file and protocol with a mime > assosiation on the system. > Therefore one can type: > > xdg-open /tmp/sample_text.txt > xdg-open /tmp/photo.jpg > xdg-open http://blah.com > xdg-open /tmp ( it summons the file manager ) > > but... how can one open the default terminal ? > Is there a standard for this ? If not, don't we need one ? I don't think we need this. What would the use case be? Applications that really need a user to work in a terminal window can IMHO assume that such an experience user can open a terminal or work within any terminal the applications chooses to open. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgp03xPFSVz4n.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: a standard File Manager API
On Sunday 22 October 2006 20:39, Marcos wrote: > A generic File Manager API is another missing standard. > > It would be nice if, just like in MSWindows, one could implement in any > application basic file functions like "delete, rename, propreties". > > Of course it is trivial to reimplement them for each aplication, but they > they will never have the look and feel of the default file manager. I am afraid I don't understand. Are you talking about embedding the desktop's filemanager? If this is about file dialogs, we are working on that. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpVD2GsEckHx.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Opening default filemanager (was: xdg Digest, Vol 31, Issue 10)
On Tuesday 17 October 2006 23:45, Marcos wrote: > Hello! > > KDE, XFCE and GNOME, for example, are window managers which contain a file > manager. Unfortunatelly, as far as I know, there is no standard way to know > which is the users default file manager. That means > a) the user can not change his file manager without changing his window > manager (not that bad) b) no application can implement a "open folder in > default file manager" function in a standar way ( complete disaster) xdg-open /path/to/directory > A much simpler way to solve this problem is to have the default file > manager as the default program to open the inode/directory (or anything > like that). By doing so, opening a directory would be as simple as opening > any file, and any program would be able to use such feature, just by using > the xdg-mime library! Open a directory is like opening a file with xdg-open Since xdg-open calls the desktop environments commandline tool for launching the default handler application, it _does_ already use the desktop's assocation for inode/directory (at least kfmclient does for KDE, but I assume gnome-open and exo-open actually do the same) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpM3wQVSyKKL.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon / mime association..
On Monday 16 October 2006 18:46, Kustaa Nyholm wrote: > Bastian, Waldo wrote: > >This is a bit tricky. You may want to take a look at xdg-utils [1] which > >takes part of the hairy parts. Basically, once you have installed > >mimetype description(s) you can install for each mimetype (e.g. > >text/foobar) an icon with the name major_minor (e.g. "text_foobar") that > >will then be used for documents of that mimetype. > > > >See http://portland.freedesktop.org/xdg-utils-1.0/xdg-mime.html for an > >example. > > Ah, thanks for the pointer, this actually solved most of the issues I had, > very helpful, those scripts. Though it took me a while to use them > properly. BTW some worked out (and thoroughly debuged) examples on how to > use them would be very helpful as a part of the specs, but thats by the > way. There is a small example at the end of the man page If you have a better example based on your current work, we'd like to merge it into our documentation. If you're interested you can just send me plain text and I'll get it into the docbook Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring pgpYAIwAmbOdm.pgp Description: PGP signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
