gmane.linux.xdg.devel

Re: Relative paths in .desktop files

Michael Thayer — 2012-05-25T04:45:58

Actually I can quickly summarise the objections (and my answers):
* Marty thought that this overlapped with the Autostart spec; I would 
say that they are orthogonal, as this describes an application and 
Autostart says what is to be started.
* Marty thought that this didn't help existing users of .desktop files; 
I agree, though I would point out that Nautilus (didn't check other file 
managers) can use .desktop files in random locations, but requires that 
they refer to an application with absolute paths.  I think that in that 
particular case this would improve usability.
* Marty objected that this didn't support multi-architecture.  I agree, 
but would say that that is a separate issue which can be addressed 
separately if needed (an expander in a relative path?), and can be 
hacked now easily using scripts.
* PCMan thought that AppFolders would solve the problem better.  Again, 
I agree, but there is no freedesktop AppFolder specification that I am 
aware of.  In fact a relative .desktop file in a directory containing an 
application seems to me like a good way of implementing them!
* PCMan suggested embedding icons into scripts.  Unfortunately I don't 
think that there is a universally accepted way of doing this, and 
requiring a (complex) installation procedure for it to work rather 
defeats the purpose.

Is there anything else I can do or address to make this move?

Regards,

Michael

synaptics touchpad generates clicks whilst disabled

Peter Joanes — 2012-05-24T18:10:21

Hello,

I'm running xserver-xorg-input-synaptics version 1.5.99.902-0ubuntu5.1 on a 
Lenovo X300 (i.e. I recently upgraded to Xubuntu 12.04) and use the TrackPoint 
with the touchpad disabled which otherwise would generate unwanted input as my 
hand brushes it.
I have tried several different ways to disable the touchpad, which I think all 
amount to 'synclient TouchpadOff=1'. Unfortunately none of these has quite 
worked, as although the touchpad seems disabled, it still generates clicks 
when the trackpoint button is held down (i.e. whilst dragging).

Thanks,
-Peter Joanes.
<pjoanes< at >hotmail.com>

Re: Simple thumbnailers?

David Nečas — 2012-05-24T17:25:38

Well, apparently it does not exist.

So, instead, does any reference implementation/template of 
org.freedesktop.thumbnails.SpecializedThumbnailer1
exist?

Yeti

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: libxdg

David Faure — 2012-05-23T08:20:48

Ah, yes, you're right. It's shared-mime-info (the database) which is GPL.

Re: libxdg

Sanel Zukan — 2012-05-23T08:03:33

Hm... isn't xdgmime under LGPL?

Regards,
Sanel

Re: Supporting mime types in desktop actions

David Faure — 2012-05-22T16:49:00

If you mean QMimeDatabase/QMimeType, I should know, I wrote it :-)
But that's only the shared-mime-info spec, not the mime-associations spec.

BTW, you wrote earlier:

But actually there is a spec, at
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec


Ah! I understand now.
mimeapps.list *was* about desktop files without actions, but your proposal is 
to change exactly that! :-)

Now the only thing I don't understand, is in which case would xdg-open [which 
is just one of the users of mimeapps.list BTW] look for "Edit"? From your 
description, it sounds like it would just stumble upon that as being the 
preferred action...
So basically if I put image/png=myapp.desktop[Print] in mimeapps.list, every 
time I click on a PNG in a file manager it will print it...

But that's not what you wanted, is it?
You simply wanted the "Print" action to show up in the contextual menu over 
png files, even if the definition of the print action (in the root-owned desktop 
file) mentionned other mimetypes than png files.

So this is the problem I have with this suggested change for mimeapps.list:
for the desired effect of "adding a mimetype to an action", it has the side 
effect of "making it the default action for this mimetype", unless the full 
list of current associated applications is written out in mimeapps.list too, 
to ensure the added action is only at the end of the list.

I think this is mixing two things, really.

If the goal is to add a mimetype to a specific action, but without changing 
what happens when simply opening a file, then it should be done in a separate 
file, or in a separate group ([Added Action Associations]) in mimeapps.list.

Re: libxdg

David Faure — 2012-05-22T16:20:57

This starts with "This library is a fork of the official freedesktop.org library 
xdgmime". This is not the case anymore, is it? In fact, is there any code from 
xdgmime? I hope not, since it's GPL, and your code is LGPL.

I also have a number of questions about the on-disk cache:


Can you explain what these are for? Each path, in that list, is that a cache 
file or a desktop file, or a directory of desktop files?

But more generally, could we get rid of the whole idea of file watching, and 
just mandate that when someone installs a .desktop file, they must run update-
applications-cache, just like we do with mimetypes and update-mime-database?


... and sub-directories, surely.


Is it? Looking at the cache file, I see full paths rather. I think relative 
paths might be better (shorter), but I actually don't have a strong opinion 
about this at this point. In any case, the docu should match reality, or vice 
versa ;)


Ah, heh, took me a long time to understand this. OK, this is the full contents 
of the desktop file itself, as a tree. Maybe simply add a typical example here.

(I first thought that "group" was a group of applications, as in the menu spec, 
but of course this is unrelated to this stuff).


"text" is not the name of a mime type. "text/html" is. Is there any reason for 
splitting text/html into two leaves in the tree? Is this for supporting 
mimetypes like text/* or image/*? Hmm, why not. But otherwise it's a bit 
pointless and confusing.


What does this structure contain? The full contents of the desktop file, again? 
Or do I misunderstand that?
Surely there's no need to duplicate the contents again, for each mimetype 
associated with the application. Wouldn't it be enough to write in this tree, 
the name of the desktop file, in order to then look it up in the other tree if 
one wants to get more details about it?
Or is this space-optimized anyway, by pointing to the same data in the on-disk 
cache?
Please tell me more about what this tree contains, the documentation is 
confusing, my talking about structures here, but not in the first tree, but 
they seem quite similar.


?? What's Global version? The one in /usr? Why is it special? Surely desktop 
files in $XDG_DATA_HOME can mention mimetypes too.
I'm not sure what you call resolving, here, in any case.


The typical use case for all this, is "what are the apps associated with a 
given mimetype, sorted by user preference", right?
With a tree for the associations coming from desktop files, and another tree 
for the contents of defaults.list/mimeapps.list, one has to look up into 
multiple trees to be able to answer that question. Wouldn't it be faster, and 
simpler (higher level) to have a single tree, combining these two?
I.e. a simple tree with
  key = mimetype -> value = list of desktop files
("merging" .list files into the desktop files) would give an immediate result,
compared to three lookups (initial list, then added associations, then removed 
associations), all this multiplied by the number of paths in XDG_DATA_DIRS 
plus one local dir, of course.
Do you think this could be done? Or am I overlooking some difficulty here?

Thanks,

Re: libxdg

DAV — 2012-05-22T14:07:50

Hi David,

I have been using the library in my everyday work since my last message. So
far, I have found and fixed a couple bugs, but in general I think the
library is ready for the first release. I will finish documentation (not so
comprehensive as I would like it to be, though) within this week and I will
announce about the release on xdg< at >lists.freedesktop.org.

If you would like to try it right now you can get it from
https://github.com/vilkov/libxdg.
Also there is online Doxygen documentation (a bit outdated, though):
http://vilkov.github.com/libxdg.

--------------------------------
Best regards, Dmitriy.



2012/5/19 David Faure <faure< at >kde.org>

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Simple thumbnailers?

David Nečas — 2012-05-20T22:15:47

Hello,

does any standard possibility exist to register simple specialised
thumbnailers that just run a program to create the thumbnail?

E.g. something like the

[Thumbnailer Entry]
Exec=...
MimeType=...

files that appear to work in Gnome3 (but that I cannot find actually
specified anywhere)?

I have looked at the only implementation of
org.freedesktop.thumbnails.SpecializedThumbnailer1 I was able to find,
maemo-video-thumbnailer.  IMO if you let people not understanding D-Bus
and thus not knowing what they are doing (such as me) implementing this
kind of stuff it can only lead to disaster...

Thanks,

Yeti

Re: Relative paths in .desktop files

Michael Thayer — 2012-05-20T20:27:17

I had actually given up on this as no one with commit rights seemed to 
be inclined to make the change, and at least Marty Jack and PCMan didn't 
seem very keen on it.  I would certainly still be interested in seeing 
it though.

Regards,

Michael

Re: Supporting mime types in desktop actions

Jerome Leclanche — 2012-05-19T16:08:16


Heads up: There will be code in Qt in 5.0.



I'm not sure what you mean. My proposal only defines mime types an action
can be used *for*, nothing else.



Right. When looking at an image/png file, xdg-open will
see myapp.desktop[Edit], go in myapp.desktop and look for a [Desktop Action
Edit] section. If it doesn't find it, we *could* add a fallback to the
simple Desktop Entry (and a warning I guess).

How does it become "just about desktop files that define desktop actions",
though? Desktop files without DAs are still recognized as before.


_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Relative paths in .desktop files

David Faure — 2012-05-19T11:20:23

Agreed.

Did anything come out of this? Should the suggested patch for the spec be 
amended to clarify the issue above?

Any objections from main implementors to supporting "./" in Exec and Icon 
fields?

Re: suse 11.1 lxde

David Faure — 2012-05-19T11:13:18

You are emailing the wrong list, please email a LXDE-specific mailing-list 
about this.

Re: libxdg

David Faure — 2012-05-19T11:11:37

Hi Dmitriy,

Any news on this topic?

Re: Supporting mime types in desktop actions

David Faure — 2012-05-19T11:06:42

wrote:

There's no code in Qt yet, at this point it would be
kdelibs/kded/kmimeassociations.cpp
in git://anongit.kde.org/kdelibs


Yep, the KDE implementation will just output a warning saying
KMimeAssociations::parseAddedAssociations: ".../mimeapps.list" specifies 
unknown service "myapp.desktop[Edit]" in "Added Associations".

But that's for mimeapps.list. I'm not sure what the suggested change for 
application .desktop files actually is. Ah, we're not talking about changing 
the way apps are associated with mimetypes, only about "desktop actions", i.e. 
typically contextual menu stuff? I wonder how the GUI is supposed to look like, 
to distinguish Open from Edit?

I'm confused over all, because mimeapps.list is about application desktop 
files, not just about desktop files that define desktop actions. So, what should 
happen when writing image/png=myapp.desktop[Edit];
and myapp.desktop simply says Exec=gimp ? Nothing new, right?

Re: ~/.local/share/pixmaps is not in search list for icons

David Faure — 2012-05-19T10:58:14

Works in KDE 4 :-)

$ kde4-config --path xdgdata-pixmap
/home/dfaure/.local/share/pixmaps/:/usr/share/pixmaps/

And, actually, the comment in the code about this, says:
 "These are not in the icon spec, but e.g. GNOME puts some icons there 
anyway."
:-)

But maybe this isn't the case anymore?


I think so, actually. The code talks about legacy dirs.


I'm no icon theme expert, actually, but I think that was the idea yes - that 
icons should always be associated with a theme.
I would agree that it doesn't always make sense though.

Re: RFC: thumbnail: Modify to follow the XDG Basedir Spec

PCMan — 2012-05-12T03:47:21

This move increased consistency.
However for now, a symlink ~/.thumbnail pointing to
$XDG_HOME_CACHE/thumbnails might be needed to ease the migration.

On Fri, May 11, 2012 at 9:10 PM, Jerome Leclanche <adys.wh< at >gmail.com> wrote:

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Thumbnail spec in git

Trans — 2012-05-11T15:34:18

I know this is a bit far from the field, so to speak, but I've often
found it annoying that if you move a directory the thumbnails are lost
and have to be regenerated. Obviously there is nothing that can be
done about this with a shared thumbnail directory.

An ideal solution would have to be something like a directory that
"shadows" every file. This directory could hold a files thumbnails, as
well as other related information useful to different applications. It
would be a very flexible system and would totally solve the problem
--and then some. But I expect this would have to be a pretty low-level
file system thing to make sure the shadow directory is always present
and always goes where the file goes.

Re: Thumbnail spec in git

Jerome Leclanche — 2012-05-11T14:11:34

After reading it a little, one issue jumps to mind:
Why is the spec limiting itself to normal and large? Why not go with
thumbnails/128x128, thumbnails/256x256 etc and make normal/large symlinks
to 128 and 256?

(Or store normal/large settings in a config file in order to support
systems without symlinks. Or assume aliases...)

J. Leclanche


On Fri, May 11, 2012 at 1:49 PM, Vincent Untz <vuntz< at >gnome.org> wrote:

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

RFC: thumbnail: Modify to skip unreadable files

Dr. Michael J. Chudobiak — 2012-05-11T13:49:35

Hi all,

Another patch to consider for the thumbnail spec, based on a discussion 
4 years ago [1].

Basically, thumbnailers should not generated "failed" thumbnails for 
unreadable files, or they will remain un-thumbnail-able even if their 
permission are changed to make them readable.

[1] http://www.mail-archive.com/xdg< at >lists.freedesktop.org/msg04016.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=49799

Comments?

- Mike


_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

RFC: thumbnail: Modify to respect orientation tags

Dr. Michael J. Chudobiak — 2012-05-11T13:45:32

Hi all,

Here's another patch to consider for the thumbnail spec, requiring that 
thumbnailers respect the orientation tag in the image metadata, and 
encouraging the use of other image metadata (white balance, etc).

https://bugs.freedesktop.org/show_bug.cgi?id=49798

Comments?

- Mike

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg