AppData proposal
Hi all, I've written up a specification that I would like to get feedback on. It's had a few iterations now, and soon I'd like to propose a GNOME Goal on adding the required files to at least all the apps in our core moduleset. The proposal is http://people.freedesktop.org/~hughsient/temp/appdata/ All comments welcome, thanks. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: modules that could do with a release for 3.9.90
Done. Here's the tarball: http://ftp.gnome.org/pub/GNOME/sources/gnome-dictionary/3.9/ Let me know if there's anything else I can do. On Wed, Aug 21, 2013 at 2:25 AM, Matthias Clasen matthias.cla...@gmail.comwrote: On Tue, Aug 20, 2013 at 2:00 PM, Sindhu S sind...@live.in wrote: Hi, Matthias! I previously released gnome-dictionary 3.8.1. I can do the next one as well. By when do you want the module tarball? Hey Sindhu, sometime tomorrow would be great ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, 2013-08-21 at 12:25 +0100, Richard Hughes wrote: Hi all, I've written up a specification that I would like to get feedback on. It's had a few iterations now, and soon I'd like to propose a GNOME Goal on adding the required files to at least all the apps in our core moduleset. The proposal is http://people.freedesktop.org/~hughsient/temp/appdata/ All comments welcome, thanks. How do I translate this data? If you ship an .xml.in file rather than an .xml file, you can use a tool like intltool to extract the translatable strings and generate a .xml file with all the translations in at build time. Use something like @INTLTOOL_XML_RULE@ in Makefile.am to make it all magically work. Just change a few of the to-be-translated tags to something like this: ul _liHistorical and current battery information/_li _liPrograms running on your computer using power/_li /ul If you use itstool, you don't have to mangle your input XML. Regardless, you really ought to specify at what level you expect to see translatable elements repeated. Do you really want this: description pYelp is a help viewer./p p xml:lang=deYelp ist ein Hilfe-Viewer./p pIt's really cool./p p xml:lang=deEs ist echt toll./p /description Or do you want this: description pYelp is a help viewer./p pIt's really cool./p /description description xml:lang=de pYelp ist ein Hilfe-Viewer./p pEs ist echt toll./p /description Also note that xml:lang is really supposed to take BCP 47 language tags, not the gettext locales we tend to use. Why not just use the DOAP description? This is one file per-project and is not suitable when one tarball will install several applications. It's also not translated. DOAP's concept of a project is pretty loose, and doesn't necessarily have to correspond to a tarball or a repository. There's no reason a package can't have one DOAP file for each application. Also, DOAP can be translated. It's RDF, and all RDF properties can be translated. I'm not necessarily saying you should use DOAP. One reason not to is that doing the kind of rich markup you have in the description element is a pain in RDF. Why XML and not JSON/other? AppData is a subset of the AppStream schema, which is also XML. I went to the AppStream wiki page but didn't see a schema. Do you have more info yet? Your friendly-neighborhood XML nerd, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, 2013-08-21 at 12:25 +0100, Richard Hughes wrote: Hi all, I've written up a specification that I would like to get feedback on. It's had a few iterations now, and soon I'd like to propose a GNOME Goal on adding the required files to at least all the apps in our core moduleset. I think it'd really help a lot if we had a model where we figure out how to generate some of it from a canonical source. For example, if we're now going to say that AppData is canonical, we should generate the .desktop file content from that. Having a Makefile fragment to do this would help adoption a lot. For example we'd still have to have .desktop.in with the Exec= line, or we add Exec= to AppData and entirely generate .desktop from it? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On 21 August 2013 13:47, Shaun McCance sha...@gnome.org wrote: If you use itstool, you don't have to mangle your input XML. I discounted itstool as I didn't want *all* the elements translated. Regardless, you really ought to specify at what level you expect to see translatable elements repeated. Do you really want this: description pYelp is a help viewer./p p xml:lang=deYelp ist ein Hilfe-Viewer./p pIt's really cool./p p xml:lang=deEs ist echt toll./p /description This, I guess, although I'm open for ideas. DOAP's concept of a project is pretty loose, and doesn't necessarily have to correspond to a tarball or a repository. There's no reason a package can't have one DOAP file for each application. True One reason not to is that doing the kind of rich markup you have in the description element is a pain in RDF. RIght, this is/was a major factor. I went to the AppStream wiki page but didn't see a schema. Do you have more info yet? I think this might help; http://gitorious.org/appstream/appstream-core/trees/master/docs Thanks for any help, Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, Aug 21, 2013 at 9:55 AM, Richard Hughes hughsi...@gmail.com wrote: On 21 August 2013 14:35, Colin Walters walt...@verbum.org wrote: I think it'd really help a lot if we had a model where we figure out how to generate some of it from a canonical source. For example, if we're now going to say that AppData is canonical, we should generate the .desktop file content from that. That's a good idea, but I'm not sure if AppData wants to be a superset of the desktop specification. I think it's related, but orthognal. There are cases where you'd want a different name in an software center to the search term in the shell, and other cases like that. Taking that into account, I don't think it would share much at all, and the additional dep of a tool to go from XML-desktop would probably be too much for some projects. Which case? I think any app that does that is broken. What do you feel about using an external source for long descriptions, and using desktop files for common system metadata? I also feel like the system of describing this application has to be done in a common format by one of other OS vendors. Have we looked into what Ubuntu, OS X, iOS, Android, and Windows do for this? Is it an XML-based format we can share? Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On 21 August 2013 14:35, Colin Walters walt...@verbum.org wrote: I think it'd really help a lot if we had a model where we figure out how to generate some of it from a canonical source. For example, if we're now going to say that AppData is canonical, we should generate the .desktop file content from that. That's a good idea, but I'm not sure if AppData wants to be a superset of the desktop specification. I think it's related, but orthognal. There are cases where you'd want a different name in an software center to the search term in the shell, and other cases like that. Taking that into account, I don't think it would share much at all, and the additional dep of a tool to go from XML-desktop would probably be too much for some projects. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, 2013-08-21 at 14:49 +0100, Richard Hughes wrote: On 21 August 2013 13:47, Shaun McCance sha...@gnome.org wrote: If you use itstool, you don't have to mangle your input XML. I discounted itstool as I didn't want *all* the elements translated. That's why itstool uses ITS. its:rules xmlns:its=http://www.w3.org/2005/11/its; version=1.0 its:translateRule translate=no selector=/application/ its:translateRule translate=yes selector=/application/name | /application/summary | /application/description/ /its:rules Regardless, you really ought to specify at what level you expect to see translatable elements repeated. Do you really want this: description pYelp is a help viewer./p p xml:lang=deYelp ist ein Hilfe-Viewer./p pIt's really cool./p p xml:lang=deEs ist echt toll./p /description This, I guess, although I'm open for ideas. Here's the rub: When you have an element that can occur multiple times, it becomes difficult to reliably figure out which ones to show. pParagraph 1/p p xml:lang=ptParagraph 1 in Portugese/p p xml:lang=pt-brParagraph 1 in Brazilian Portugese/p pParagraph 2/p p xml:lang=ptParagraph 2 in Portugese/p pParagraph 3 is only available in English/p p xml:lang=enParagraph 4 has xml:lang set for some reason/p pParagraph 5/p p xml:lang=pt-brParagraph 5 in Brazilian Portugese/p You first have to figure out which are the source elements, then which translated elements correspond to which source elements. It's just very unpleasant to deal with repeated translated elements when they're used in a document-like markup, as opposed to an informational markup. I went to the AppStream wiki page but didn't see a schema. Do you have more info yet? I think this might help; http://gitorious.org/appstream/appstream-core/trees/master/docs Perfect, thanks. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On 21 August 2013 15:00, Jasper St. Pierre jstpie...@mecheye.net wrote: There are cases where you'd want a different name in an software center to the search term in the shell.. Which case? I think any app that does that is broken. TrackerGUI wants to be Search in the menu, but probably ought to be Tracker in the software center. Similar for Videos - Totem. I also feel like the system of describing this application has to be done in a common format by one of other OS vendors. Have we looked into what Ubuntu, OS X, iOS, Android, and Windows do for this? Is it an XML-based format we can share? I don't think it's worth the pain of interoperability just to share 2 or 3 fields, but I'm open for ideas if anyone has any more details of something suitable. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On 21 August 2013 15:21, Shaun McCance sha...@gnome.org wrote: That's why itstool uses ITS. its:rules xmlns:its=http://www.w3.org/2005/11/its; version=1.0 its:translateRule translate=no selector=/application/ its:translateRule translate=yes selector=/application/name | /application/summary | /application/description/ /its:rules So where does that ITS snippet live? On each project or somewhere central? Here's the rub: When you have an element that can occur multiple times, it becomes difficult to reliably figure out which ones to show. Agreed. You first have to figure out which are the source elements, then which translated elements correspond to which source elements. It's just very unpleasant to deal with repeated translated elements when they're used in a document-like markup, as opposed to an informational markup. Dude, you outclass me completely when talking about XML stuff, so I'm really open for your input. It sounds like what you'd like is: * An untranslated .xml.in file * itstool with the snippet used for translations Any help welcome on what I should put in the specification document. Thanks. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, 2013-08-21 at 15:13 +0100, Richard Hughes wrote: On 21 August 2013 15:00, Jasper St. Pierre jstpie...@mecheye.net wrote: There are cases where you'd want a different name in an software center to the search term in the shell.. Which case? I think any app that does that is broken. TrackerGUI wants to be Search in the menu, but probably ought to be Tracker in the software center. Similar for Videos - Totem. But if I see ‘Videos’ in the menu on my friend’s computer and I want to install it on mine because it looks cool, surely then Totem should appear when I look for ‘Videos’ in the software centre? It would be useful if all the keywords used for launcher matching in gnome-shell were also used for search matching in software centre. I’ve spent too much time second-guessing package names and descriptions with yum when trying to install a new application. Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
On Wed, Aug 21, 2013 at 10:13 AM, Richard Hughes hughsi...@gmail.comwrote: On 21 August 2013 15:00, Jasper St. Pierre jstpie...@mecheye.net wrote: There are cases where you'd want a different name in an software center to the search term in the shell.. Which case? I think any app that does that is broken. TrackerGUI wants to be Search in the menu, but probably ought to be Tracker in the software center. Similar for Videos - Totem. I also feel like the system of describing this application has to be done in a common format by one of other OS vendors. Have we looked into what Ubuntu, OS X, iOS, Android, and Windows do for this? Is it an XML-based format we can share? I don't think it's worth the pain of interoperability just to share 2 or 3 fields, but I'm open for ideas if anyone has any more details of something suitable. I don't really care about interoperability. it's just that other people have probably solved all these problems before, and we should study their solutions. Richard -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: AppData proposal
Em Wed, 2013-08-21 às 15:13 +0100, Richard Hughes escreveu: On 21 August 2013 15:00, Jasper St. Pierre jstpie...@mecheye.net wrote: There are cases where you'd want a different name in an software center to the search term in the shell.. Which case? I think any app that does that is broken. TrackerGUI wants to be Search in the menu, but probably ought to be Tracker in the software center. Similar for Videos - Totem. The name of the app is Videos and it's a core application. It should be installed by default, and non-removable (though whether it should be hideable is something for designers to mull over). Core applications can use generic names because they live with the OS. Other applications should be qualified with their origin (so Tracker Search in your example). I also feel like the system of describing this application has to be done in a common format by one of other OS vendors. Have we looked into what Ubuntu, OS X, iOS, Android, and Windows do for this? Is it an XML-based format we can share? I don't think it's worth the pain of interoperability just to share 2 or 3 fields, but I'm open for ideas if anyone has any more details of something suitable. I think it's a good thing to look into if you want maximum buy-in from third-parties. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
