Re: RFD: Using "Type=MetaApplication" for package managers and application stores
Le Sat, 6 Aug 2011 19:45:45 -0400, Jacob Edwards a écrit : > Hello everyone. > > Over the past few years Ubuntu has been using desktop entries to fetch > applications from its repositories and display them in the software > center. All packages with a desktop file are considered applications; > they appear with their entries' Name, Icon, and Comment in the > software center, while other packages are hidden as "technical items". > > It turns out this approach is problematic. > > * Some applications have extra desktop launchers. Wesnoth, for > instance, comes with a map editor. From the perspective of an app > store, however, 'wesnoth.desktop' and 'wesnoth-1.8_editor.desktop' > are just one app. > * Some applications have no primary launcher. Wine, for instance, > comes with a notepad, a configuration launcher, a registry editor, a > program uninstaller, a help app, and a drive browser. None of these > embody "Wine" as one thing a user is interested in installing. > * Finally, at a package level, it is often advantageous to package >desktop launchers separately from the main package. So an app store >ends up installing a 'app-common' package instead of the entire >application. > > In the past we've manually maintained an entry blacklist and > package->app mapping for the software center. It's become clear that > this solution won't scale. > > There's been some discussion around a solution at the package level: > > # https://dev.launchpad.net/ArchiveIndex#Overrides > > However, I think it would be much cleaner to extend the Desktop Entry > standard to include *generic, non-executable descriptions of a user > application*. Such a file might look like this: > > [Desktop Entry] > Version=1.0 > Type=MetaApplication > Name=Foo Viewer > Comment=The best viewer for Foo objects available! > URL=http://fooview.com > Icon=fooview > MimeType=image/x-foo; > > # And perhaps. > Package=fooview > Screenshot=http://fooview.com/screenshot.jpg > Description=[Longer description of fooview here] > > Would any other parties be interested in modifications like this > landing in the Desktop Entry spec? Just wondering, would using DOAP files make sense? Cheers Adrien ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
Bastien Nocera a écrit : On Fri, 2008-08-29 at 12:14 +0200, Adrien BUSTANY wrote: Bastien Nocera a écrit : On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Well, we can have the Qt approach here : keep width and height, and add a third parameter which is PreserveRatio (actually in Qt there are three possibilities : keep ratio, don't keep ratio and extend, see http://doc.trolltech.com/4.4/qpixmap.html#scaled ). Why would you want to do that Well I don't know why I specially would like to do that, but it gives us flexibility without making the API more difficult to use (the ratio mode can be optional). Some people might want to have more control... This was just a good compromise between Philip's original idea, and the GNOME version. I don't have some real usecase behind that :-) ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specifying thumbnailers as a service
Bastien Nocera a écrit : On Fri, 2008-08-29 at 11:25 +0200, Philip Van Hoof wrote: In the libgnomeui API, you only set one of those, and aspect ratio is preserved. The size passed is the maximum width and height. Well, we can have the Qt approach here : keep width and height, and add a third parameter which is PreserveRatio (actually in Qt there are three possibilities : keep ratio, don't keep ratio and extend, see http://doc.trolltech.com/4.4/qpixmap.html#scaled ). Cheers Adrien ___ 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
Re: Specification for per directory settings
Patryk Zawadzki a écrit : On Thu, Aug 21, 2008 at 6:36 PM, Adrien BUSTANY <[EMAIL PROTECTED]> wrote: Clearly we need a lib to abstract that. We also need to make that lib totally desktop independant... And also I'd really be happy if we reach a point where the solution we choose can be defined as a standard (that was my initial point). I guess that implies that there should be more than two people participating in this discussion :-) Maybe a blog article would be a good way to get people into the discussion, but I don't have a blog :-s I think it would be enough to make gio/gvfs/kio preserve the attributes (all attributes, not only the folder related ones) when copying/moving files and directories (and to create fallback files when the need arises). High level apps can then just use the gio/kio calls to manage the attributes and the storage mechanism is abstracted away. That should be standardized and agreed upon first. I agree on that. We definitely need to start a real discussion about that. I'll be in touch with the KDE developers to see what they think about that issue. Only then we can start thinking about higher level standards like folder view-specific attributes or MIME-type storage. Of course apps not using the vfs apis will likely break the attributes but they fall out of scope of the specification (and they also break stuff on OSX). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: executable .desktop files
Hi,
I don't really understand what is the problem addressed here, could you
explain it further please ?
Best regards
Adrien Bustany
Egon Kocjan a écrit :
> Hi,
>
> Hopefully some time in the future, oss desktops will support application
> bundles. There is a somewhat working equivalent in the mean time, using
> .desktop files, perl and base64 encoding (Exec line should not be split):
>
> [Desktop Entry]
> Encoding=UTF-8
> Exec=perl -e 'use MIME::Base64
> qw(decode_base64);eval(decode_base64(q(dXNlIEZpbGU6OlRlbXA7dXNlIElPOjpGaWxlO3N1YiBydW4geyRmaWxlID0gcG9wOyRmaWxlID1+IHMsXmZpbGU6Ly8sLDskYnVmID0gJyc7JGluID0gSU86OkZpbGUtPm5ldygkZmlsZSk7d2hpbGUoPCRpbj4pIHtpZigvXlwjKC4qKSQvKSB7ICRidWYgLj0gJDE7IH19JGluLT5jbG9zZSgpOyR0bXAgPSBGaWxlOjpUZW1wLT5uZXcoVU5MSU5LPT4wKTtjaG1vZCAwNzAwLCAkdG1wO3ByaW50ICR0bXAgZGVjb2RlX2Jhc2U2NCgkYnVmKTskdG1wLT5jbG9zZSgpO2V4ZWMgeyAkdG1wLT5maWxlbmFtZSB9ICgkdG1wLT5maWxlbmFtZSk7ZGllO30g)));run(q(%k));'
> Name=My App
> Type=Application
> # ...
> # base64 encoded executable (or self extracting bundle) goes here
> # ...
>
>
> The perl block effectively expands to:
>
> use MIME::Base64;
> use File::Temp;
> use IO::File;
> sub run {
> $file = pop;
> $file =~ s,^file://,,;
> $buf = '';
> $in = IO::File->new($file);
> while(<$in>) {
> if(/^\#(.*)$/) { $buf .= $1; }
> }
> $in->close();
> $tmp = File::Temp->new(UNLINK=>0);
> chmod 0700, $tmp;
> print $tmp decode_base64($buf);
> $tmp->close();
> exec { $tmp->filename } ($tmp->filename);
> die;
> }
> run(q(/path/to/itself));
>
>
> Pros:
> - users can simply download packed applications with the web browser to
> the desktop and start them with double-click
> - it works with standard releases of gnome, kde and xfce, no need to
> install any extra software on the client side
>
> Cons:
> - some users may ignore the instructions to download the .desktop file
> and open it in text editor instead (default action in most distros)
> - download size is larger because of base64 encoding
> - not possible to set a custom application icon
> - large executables (5mb and up) "hang" nautilus (I haven't tested much
> with others)
>
>
> Maybe this will serve as an inspiration for the next iteration of fd.org
> standards ;)
>
> egon
>
> ___
> 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
Re: Specification for per directory settings
Patryk Zawadzki a écrit : On Thu, Aug 21, 2008 at 5:12 PM, Adrien BUSTANY <[EMAIL PROTECTED]> wrote: OK, let's forget the read only media for now then... The only downside I see with hidden files is the following usecase : Tom uses windows, and gives his usb key to Sally Sally plugs the usb key into her linux system, and changes some sorting properties. The file manager creates a .directory (or whatever it's called) file on the usb key. When Tom gets the usb key back, he sees lot of dot files, and doesn't know what they're about. I don't know if dot files are automatically marked as "hidden" in the FAT sense when using a FAT fs on Linux... How do we address that ? There is a hidden attribute that should be used on filesystems that support it :) Clearly we need a lib to abstract that. We also need to make that lib totally desktop independant... And also I'd really be happy if we reach a point where the solution we choose can be defined as a standard (that was my initial point). I guess that implies that there should be more than two people participating in this discussion :-) Maybe a blog article would be a good way to get people into the discussion, but I don't have a blog :-s ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
Patryk Zawadzki a écrit : On Thu, Aug 21, 2008 at 10:20 AM, Adrien BUSTANY <[EMAIL PROTECTED]> wrote: I like the extended attributes too, they're clearly the cleanest way to store that information. In the case where extended attributes are not available, we cannot always use a hidden file in the folder, I'm thinking for example of a read only volume. In that case I think Dolphin fall backs to a central setting file, though I don't know the details. Central database comes at a price of an ever-growing file hidden somewhere in your filesystem. Also what happens if I try to save some settings for a CD or DVD? Does it remember the absolute path (bad) or the mountint point and relative path (equally bad) or does it try to get a GUID for the media (but not the drive as I can put the same disc into another drive at some later point in time)? I think supporting *saving* to read-only file systems is just not worth it (and can create confusion if people start complaining that they can customize the CD but it doesn't work when moved to another machine or that they can customize the looks but moving files around does not work). Just my 0.02 zloty (PLN). OK, let's forget the read only media for now then... The only downside I see with hidden files is the following usecase : Tom uses windows, and gives his usb key to Sally Sally plugs the usb key into her linux system, and changes some sorting properties. The file manager creates a .directory (or whatever it's called) file on the usb key. When Tom gets the usb key back, he sees lot of dot files, and doesn't know what they're about. I don't know if dot files are automatically marked as "hidden" in the FAT sense when using a FAT fs on Linux... How do we address that ? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Specification for per directory settings
Patryk Zawadzki a écrit : On Thu, Aug 21, 2008 at 12:22 AM, Adrien BUSTANY <[EMAIL PROTECTED]> wrote: Hi, this is my first post to the list, so hello everyone ! I've been lately developping an extension for a file manager which uses emblems on folders to mark their relation with a project. I searched for a standard for per directory settings but didn't find one. My problem is with emblems, but the same goes for custom icons, custom sorting, or even localized names etc. I think the freedesktop world could really benefit from a standard addressing this concern, if it's well thought of course :-) This mail is hence a call for brainstorming, here are a few starting points : - For each folder that has custom settings, store a hidden file with the settings inside. That's what Dolphin, and the Finder on Mac OS X does. - Store all the custom settings in a centralized file, most likely in the home user directory (possibly in .config). I guess that what Nautilus does for emblems, although that needs confirmation. What do you guys think about that ? Do you have a better answer ? Am I posting to the right list ? :-) Store it in extended attributes and fall back to hidden file when moving to media that does not support them (archive, teh internets, fat) and reinstantiate the attributes when moving back (I believe that's what OSX does in most of the cases and as a bonus it saves you a bunch of stats). I like the extended attributes too, they're clearly the cleanest way to store that information. In the case where extended attributes are not available, we cannot always use a hidden file in the folder, I'm thinking for example of a read only volume. In that case I think Dolphin fall backs to a central setting file, though I don't know the details. Cheers Adrien ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Specification for per directory settings
Hi, this is my first post to the list, so hello everyone ! I've been lately developping an extension for a file manager which uses emblems on folders to mark their relation with a project. I searched for a standard for per directory settings but didn't find one. My problem is with emblems, but the same goes for custom icons, custom sorting, or even localized names etc. I think the freedesktop world could really benefit from a standard addressing this concern, if it's well thought of course :-) This mail is hence a call for brainstorming, here are a few starting points : - For each folder that has custom settings, store a hidden file with the settings inside. That's what Dolphin, and the Finder on Mac OS X does. - Store all the custom settings in a centralized file, most likely in the home user directory (possibly in .config). I guess that what Nautilus does for emblems, although that needs confirmation. What do you guys think about that ? Do you have a better answer ? Am I posting to the right list ? :-) Best regards Adrien Bustany ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
