Re: Linux and application installing - screen shots of UI mock up
Ok, I made some screen shots. It's a bit easier to understand if you see it actually working. They should still give you a idea. Looking at the PackageDB tags, filtering for the Office and Qt tags: http://fedorapeople.org/~ffesti/screenshots/PackageDBTags.gif Filtering for the GNOME menu tag and looking at the results found with the Audio tag. http://fedorapeople.org/~ffesti/screenshots/MenuTags.gif Still filtering for GNOME but looking at the stripped down Applications menu, showing the results in Applications-Games-Board: http://fedorapeople.org/~ffesti/screenshots/Applications.gif Searching for circuit and look at the results found in the comps groups - wondering why we found some games: http://fedorapeople.org/~ffesti/screenshots/Search.gif Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing - a second perspective
On 09/23/2010 06:09 PM, Bruno Wolff III wrote: On Thu, Sep 23, 2010 at 15:51:37 +0200, FlorianFestiffe...@redhat.com wrote: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being Games with over 300). Sorry, 100 packages in one list view doesn't work for me. Games have meta data that allows them to be further subdivided in their desktop files. This should up in the part of you app that takes that data into account. If you read on you'll see that I actually use exactly this data. When showing the packages in the Application menu tree the games are already subdivided. Try it out and see yourself! Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linux and application installing - a second perspective
Sorry, for showing up late at the party. This mail should have been part of Richard's thread with the same topic but things took a while until they were ready enough to be presented here. There is a long history of package installers in Fedora (and it's predecessors). It feels like roughly every two or three years we switched to a new application for installing, updating and removing packages - most of them introduced as the default tool way before they reached the necessary maturity and being replaced before fulfilling the promises made on introduction. I find it pretty hard to see any progress in that area over the last decade - expect the current updater; it's actually the first one that really works. What has made the situation much worse is the insane (sorry) growth of Fedora during the last years. It puts every part of the distribution dealing with packages under stress. Design decisions that might have been reasonable (or at least not too relevant) turn out to be pretty stupid or at least insufficient. This is not only true for algorithms and data structures but also for user interfaces. Splitting the distribution up into a couple of groups and list the packages belonging to each group might have been a good idea while the distribution was still only 800 packages. Right now showing a list of packages won't work reasonably for the very most cases. Nevertheless this is the best we have to offer to the user right now... But just blaming PackageKit (or any of the other package installers) for not just being better is not really helping. They can only operate on the data available. So I tried getting an overview of what we already got and to find out how it could be used. As the number of packages and applications (about 20k and 2k) is too big for manual processing it was pretty clear I had to write a little application for viewing and browsing the meta data sets and the matching packages. It was also clear that such an application would be pretty close to a new package installer and I really didn't wanted to be the next one to replace the installer of the year by it's even worse successor - especially knowing that someone else will do that in a not too distant future anyway. So I wrote a little GUI program[1] with several things intentionally unimplemented. Most other stuff is just a mock up implementation short circuiting the normal data flows through Fedora infrastructure and the repositories. So it's just above 300 lines and tries hard to look harmless. Otoh it is also a mock up of a UI for browsing packages that - while not refined enough to be used in PK (or it's successor) as is - I consider a step to gain back control over the huge number of packages and applications. IMHO the goal is to allow the user filter down the list of packages of interest to one, at most three dozen packages. Typing in the right package name does not count as a solution! Back to the application itself: You can add tags/groups to the filter by double clicking on the entries in the treeview on the left or by entering a search term into the text field on top. To remove them from the filter just press the button representing it on the row above the result list. The numbers behind the tags are the number of packages in the current result and total. Starting the first time can take a while for downloading the repo data. The meta data it currently operates are: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being Games with over 300). Sorry, 100 packages in one list view doesn't work for me. 2) PkgTags which are in the PackageDB but look like being in large parts autogenerated from the menu entry tags that are used to sort the applications into the menu entries. They look pretty outdated or incomplete, though. See [2] for a repo containing the data and the implementation in yum. You'll need the repo enabled to see those tags! PackageDB also allows to add tags by hand. Probably a good thing. Mixing them with auto generated ones - probably not. 3) Data found in the *.desktop files representing entries in the application menu. While I extracted them on my own the data set is basically the same as that used in PK. But here they are used to tag/group packages and not to make packages look more beautiful and less confusing - what seems to be the goal of the recent development in PK. There are two ways this data is used: 3.1) Attaching tags used to sort the applications into the menu to the packages. These allow different views on the packages, sorting them by different tags/aspects. Making a the tags available allows creating queries that are more narrow that the application menu itself. 3.2) Use the application menu (with additional *-menus packages) to sort the packages in. This is more easy to use but not as powerful as the tags. Every package/application is located where the user
Re: Linux and application installing - a second perspective
On Thu, Sep 23, 2010 at 15:51:37 +0200, FlorianFesti ffe...@redhat.com wrote: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being Games with over 300). Sorry, 100 packages in one list view doesn't work for me. Games have meta data that allows them to be further subdivided in their desktop files. This should up in the part of you app that takes that data into account. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le vendredi 17 septembre 2010 à 17:26 -0400, Colin Walters a écrit : On Fri, Sep 17, 2010 at 11:08 AM, Richard Hughes hughsi...@gmail.com wrote: On 17 September 2010 15:28, Bill Nottingham nott...@redhat.com wrote: Not if it's provided in the RPM header in a way where it can be easily stuffed into the metadata or a similar place. Bear in mind: 'n' applications per package, where 'n' can be a large number. This means you have to come up with an interesting way to encode binary data in a application prefixed rpm-provide. Icky. We should simply add a rule of at most one app per package. Yes, this means you, gnome-games. This is essentially what was done in fonts packaging guidelines four releases ago. And why the packages that do respect those guidelines could be presented in a font store today (except users expect image previews, and this part is still missing). -- Nicolas Mailhot signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, Sep 16, 2010 at 4:01 PM, James Antill ja...@fedoraproject.org wrote: On Thu, 2010-09-16 at 10:57 +0200, drago01 wrote: On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes hughsi...@gmail.com wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Lets say we ever want to implement this https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar feature in another upstream project) without a cross distro way to get the application data (icons, names, etc. ) it would be a maintenance nightmare. Err ... PackageKit is currently the cross distro. way to work with distro. package managers, nothing outside of that layer should ever know (or care) where the data is coming from and how it gets updated etc. For package data now, PackageKit looks in primary-*.sqlite.bz2 in Fedora and Packages.bz2 in debian. gnome-shell/whatever doesn't know or care. This should be no different. My main point was to address the why care about other distros just do it as a fedora only solution. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/16/2010 09:05 PM, Colin Walters wrote: (I don't have a strong opinion on whether the data format is RPM or repodata myself; maybe just a slight preference for the latter; the most important thing in my mind is to come to rough consensus and working code, and actually ship something) It is probably easier to add that information directly to the packages. Rpmbuild could inspect *.desktop file and produce Provides: from it or add a new tag. That way there'd be a distribution independent format and way to retrieve this data and the Fedora infrastructure doesn't have to deal with the generation on its own. Can someone please elaborate a bit what pieces of information are really needed? The .desktop files as a whole? Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 08:01, FlorianFesti ffe...@redhat.com wrote: Can someone please elaborate a bit what pieces of information are really needed? The .desktop files as a whole? Information we use in app-install: TABLE translations: STRING application_id Name of the desktop file, with no extension) STRING application_name Name in desktop file, in locale) STRING application_summary Comment in desktop file, in locale) STRING locale System locale TABLE applications: STRING application_id Name of the desktop file, with no extension STRING package_name The package name, e.g. 'nautilus' STRING categories Categories from desktop file, _not_ PK groups or PK categories STRING repo_id For adding and removal STRING icon_name Local filename with extension, e.g. totem-pl.png. This is required so that local theme can override upstream icon STRING application_name Name in desktop file STRING application_summary Comment in desktop file INTEGER rating Rating in percent. 0 is unrated, and 100% is the best application in the world. STRING screenshot_url Screenshot URL that shows exmple usage. BOOLEAN installed If the application is installed NB: you are required to run app-install-admin --refresh-installed after each package install or remove if you use this feature. So, most of the data is extracted from the desktop file, but the icons often need to be resized and converted into png format which takes a bit of time. The rating comes from [is present in] comps, but will be populated by the gnome3 application stats, and I'm thinking of pointing screenshot_url at pkgdb for now. So, you still need more data than just the desktop file. When i generate fedora-app-install I use the desktop data for 90% of the data, and then use comps to fudge a popularity score, and then manually add the pkgdb link. It's a more manual process than I would like, although you can pretty much leave the generator to do it's thing which is 90% of the work. I think it's a ton more data than you want as rpm provides. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Fri, Sep 17, 2010 at 3:01 AM, FlorianFesti ffe...@redhat.com wrote: On 09/16/2010 09:05 PM, Colin Walters wrote: (I don't have a strong opinion on whether the data format is RPM or repodata myself; maybe just a slight preference for the latter; the most important thing in my mind is to come to rough consensus and working code, and actually ship something) It is probably easier to add that information directly to the packages. Rpmbuild could inspect *.desktop file and produce Provides: from it or add a new tag. That way there'd be a distribution independent format and way to retrieve this data and the Fedora infrastructure doesn't have to deal with the generation on its own. Can someone please elaborate a bit what pieces of information are really needed? The .desktop files as a whole? Wouldn't that require the tool to download every package just to get the embedded information. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Arthur Pemberton (pem...@gmail.com) said: Can someone please elaborate a bit what pieces of information are really needed? The .desktop files as a whole? Wouldn't that require the tool to download every package just to get the embedded information. Not if it's provided in the RPM header in a way where it can be easily stuffed into the metadata or a similar place. (After all, icons used to be embedded in the package header, and they could be a lot bigger than desktop files are. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 13:36, Arthur Pemberton pem...@gmail.com wrote: Wouldn't that require the tool to download every package just to get the embedded information. Yes, that's what my generator tool does. Of course, it only downloads the packages that contain .desktop files (which we can tell from the metadata) otherwise that would take more than ages. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 15:28, Bill Nottingham nott...@redhat.com wrote: Not if it's provided in the RPM header in a way where it can be easily stuffed into the metadata or a similar place. Bear in mind: 'n' applications per package, where 'n' can be a large number. This means you have to come up with an interesting way to encode binary data in a application prefixed rpm-provide. Icky. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/17/2010 05:05 PM, Richard Hughes wrote: On 17 September 2010 13:36, Arthur Pembertonpem...@gmail.com wrote: Wouldn't that require the tool to download every package just to get the embedded information. Yes, that's what my generator tool does. Of course, it only downloads the packages that contain .desktop files (which we can tell from the metadata) otherwise that would take more than ages. That could actually even done by createrepo - just in case it runs too fast already. It has to open all the binary rpms anyway and could just sweep through the file list and then - if there are files of interest - open the payload and unpack the content of the desktop files. I have some basic support for reading the pkg content in MY generator tool. May be that can go into the rpm Python binding or some of the yum helper modules. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Fri, Sep 17, 2010 at 11:08 AM, Richard Hughes hughsi...@gmail.com wrote: On 17 September 2010 15:28, Bill Nottingham nott...@redhat.com wrote: Not if it's provided in the RPM header in a way where it can be easily stuffed into the metadata or a similar place. Bear in mind: 'n' applications per package, where 'n' can be a large number. This means you have to come up with an interesting way to encode binary data in a application prefixed rpm-provide. Icky. We should simply add a rule of at most one app per package. Yes, this means you, gnome-games. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Fri, 2010-09-17 at 18:37 +0100, Richard Hughes wrote: On 17 September 2010 16:39, FlorianFesti ffe...@redhat.com wrote: open the payload and unpack the content of the desktop files... I got told by infrastructure this would take too much bandwidth and too much time to do on each compose. It takes too much bandwidth and too much time to create the checksums for all the packages in rawhide on each compose, if you do it the simple way and just open+read every package. This is what you may have been told, the person you were speaking to probably assumed they didn't have to tell you that this just meant: You can still do it, just don't do it the simple way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/15/2010 04:38 PM, FlorianFesti wrote: [Show/Hide Details] Btw: If you do that right and save the state of this button in the user's home you can make beginners and power users happy without much UI overhead. Power users would just have to push the button once to get their beloved interface back. Beginners have the chance to push it twice to learn that they really don't care. Guess it won't get better than that... Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes hughsi...@gmail.com wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Lets say we ever want to implement this https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar feature in another upstream project) without a cross distro way to get the application data (icons, names, etc. ) it would be a maintenance nightmare. So let me add Being able to take advantage of it in other applications without worrying on the target distro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 16 September 2010 09:57, drago01 drag...@gmail.com wrote: Lets say we ever want to implement this https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar feature in another upstream project) without a cross distro way to get the application data (icons, names, etc. ) it would be a maintenance nightmare. You've hit the nail on the head. Hopefully FESCo will agree. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-16 at 10:57 +0200, drago01 wrote: On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes hughsi...@gmail.com wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Lets say we ever want to implement this https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar feature in another upstream project) without a cross distro way to get the application data (icons, names, etc. ) it would be a maintenance nightmare. Err ... PackageKit is currently the cross distro. way to work with distro. package managers, nothing outside of that layer should ever know (or care) where the data is coming from and how it gets updated etc. For package data now, PackageKit looks in primary-*.sqlite.bz2 in Fedora and Packages.bz2 in debian. gnome-shell/whatever doesn't know or care. This should be no different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-16 at 16:57 +0100, Richard Hughes wrote: On 16 September 2010 15:01, James Antill ja...@fedoraproject.org wrote: Err ... PackageKit is currently the cross distro. way to work with distro. package managers, nothing outside of that layer should ever know (or care) where the data is coming from and how it gets updated etc. PackageKit is a _package_ abstraction framework. Yum is a _package_ manager. Applications like gnome-shell and kpackagekit want to search for new applications using translated per-application strings and show icons for desktop files. Sure, in the same way they might want to display data from updateinfo and/or the patches thing OpenSuSE uses. Or they might want to access package history, to see what changed. etc. etc. PK is the current interface between the questions gnome-shell/etc. want to ask, and the answers the package managers can give. This kind of abstraction means Fedora doesn't need to run dpkg, or ship Package.bz2, or ship repodata in fail-whale.rpm. I did kind of assume most people on this list knew that, but we can repeat it again (and again, and again) if you want. There has to be a layer above the package manager that deals with applications. We've covered that, it's currently called PK. There has to be a cross-distro way to deal with the package:application mapping. It just so happens that app-install does just that. So put it in repodata, and put the APIs in PK to make sure a package is there on Ubuntu (when/if they actually use it) and make sure the repodata is current in Fedora (and, I'd assume, at least OpenSuSE). This is not difficult, nobody has demanded you rewrite PK in erlang or solve faster than light travel ... just put the repodata in the repodata, like all the other repodata. And please stop doing the equivalent of saying we have to install pacman in Fedora, to be compatible with Ubuntu. It's getting tiring. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, Sep 16, 2010 at 7:57 AM, Richard Hughes hughsi...@gmail.com wrote: It just so happens that app-install does just that. The question isnt should app-install exist. The question is does it interact with our package management system as a source of metadata information in the right way that makes sense for our release process. The point of contention is building a toolset which requires metadata about applications as a package (or set of packages) on a Fedora system. The issue is not the intent of app-install, or how its meant to present information to a user. The issue is the technical specifics of how it interacts with data resources in order to get the application metadata it needs. I've read over the bugzilla thread. I have the same concerns as expressed by Seth and James. But Rolling up application metadata as an rpm to be dropped on the system doesn't seem like a good fit for Fedora. Whereas repomd is designed to deal with metadata in an extensible way. To not use repomd as the metadata information source seems ill-advised. And more to the point because app-install requires our release team to generate the metadata as part of a Fedora release/update compose process... opinion from those quarters about how best to provide the consumable metadata source must be heeded. This isn't a simple case of content rpm like game content or fonts. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 16 September 2010 20:05, Colin Walters walt...@verbum.org wrote: Personally I'd much prefer some nice asynchronous GObject API somewhere for this, rather than parsing SQLite directly. PackageKit seems like as good a place as any for this. app-install in git master has a GObject library, although it does need to know what annotations are, and does need asynchronous versions. I'm not super keen feature creeping PackageKit into ApplicationKit... (I don't have a strong opinion on whether the data format is RPM or repodata myself; maybe just a slight preference for the latter; the most important thing in my mind is to come to rough consensus and working code, and actually ship something) Right. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
While showing the user applications instead of packages might be a good idea for several use cases I think this approach misses the point here. The questions for redesigning the Updater dialog should be: What's the user supposed to decide and what information does he need to do so? The answer in 99.9% of the cases is either Run the update now or Run the update later. Deselecting any packages for update is a rare corner case. If it would be an important case yum - or may be even rpm would/should/must support version pinning to ignore updates of given packages for ever (it's getting off topic here). So there are two things for the user to weight up: The cost of the update and how urgent it is. To decide how urgent the updates are it is probably sufficient to tell the use the most urgent level (bugfix, security fix, enhancement). Giving the number of updates and download size per level allows more fine grained decisions and whether further looking into the details might be worth. The cost is basically the time, CPU, IO and bandwidth used. It is hard to give a good estimation about that, but just giving the download size (as a sum) should be good enough for us. Additionally the connectivity is important but not so easy to find out automatically. May be the user knows how he hooked up his computer - may be we remember the connectivity we had while downloading the meta data. Another important cost is interruption of service. So you should state whether a reboot or new login is required or which (currently running) applications will require a restart. So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-15 at 16:38 +0200, FlorianFesti wrote: So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. FWIW the Mac OS X update dialog looks almost exactly like this, and shows running applications you should close before running the update. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. I've asked for this feature before too, it's actually already there but hidden in the right click menu (at least for doing security only updates). Of course it's currently broken due to the fact I have: % sudo yum updateinfo Loaded plugins: aliases, keys, noop, presto, ps, security Updates Information Summary: available 4 Security notice(s) 105 Bugfix notice(s) 23 Enhancement notice(s) ...but PK refuses to do anything but update it's own 6 packages for a minor specfile change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 15, 2010 at 4:38 PM, FlorianFesti ffe...@redhat.com wrote: While showing the user applications instead of packages might be a good idea for several use cases I think this approach misses the point here. The questions for redesigning the Updater dialog should be: It is not only about the updater but about browsing for available applications / installing them. (The rest of the mail makes sense to me but it doesn't conflict with what Richard is trying to achieve). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Mon, 2010-09-13 at 22:39 +0100, Richard Hughes wrote: On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? They were part of the half day hack PoC, but yes to expand your answer in a nice way: If/when you propose this for inclusion as repodata, will you be adding a bunch of information that wasn't in the half-day PoC ...and the answer is: Yes, there's lots of interesting data that could be added. Offline queries? What about offline queries? I assume you know you can do them just fine with yum on the current repodata, and I assume you haven't worked out a way to magically install your repodata in a package packages when it isn't installed and there is no network/CD. So, again, what are you trying to say? Co-operating with other distros? For the half-day PoC, really? But even then, Seth co-operated with Fedora rel-eng's desire that repo-metadata actually be repo-metadata. Which is the only thing anyone said is a must fix for Fedora. It's hard to see what other distros. have required as must fix with app-install, given that none are using it. Call me biased, but doing things in yum because it's the way it always used to be carries little weight when the user experience just sucks really hard. Ok, you're biased. As you've been told numerous times, putting repodata in packages is a terrible idea due to a bunch of known problems, including: 1. How do you keep it in sync. with the repo? 2. How do you deal with the reality of multiple repos? 3. How do you deal with disabling repos? Temporarily? 4. How does anadonda see it? ...this is why repodata is repodata, and we don't just ship fedora-primary.rpm etc. This is not specific to yum, and would still be the case if you finish Zif and Fedora moves to it (or apt/zypper/whatever) instead. I've been working on app-install now with other distro people for nearly two years. I'm not sure I'd be rushing to tell everyone that a half-day PoC was better than my 2 years of work, but each to his own. And, again, it begs the question ... why is no other distro. using it? But then maybe you didn't mean all those two years were spent doing something which is fundamentally impossible to put in repodata, which is the only required change I've seen from anyone in Fedora ($DEITY help us with any of the other things we just wanted). Sometimes I wonder why I should deal with Fedora and all the politics when Ubuntu and Suse just ship something that works. Ubuntu recently got high praise from LWN for Software Center in 10.10 betas. It doesn't use PackageKit at all AFAICS (no PackageKit packages are installed in my VM). It integrates tightly with apt (you know, like showing package history ... like yumex does). Also their package install/remove tool is not gpk-application, and their update tool is not gpk-update-viewer. So I'm having a hard time working out what you mean. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, Sep 14, 2010 at 6:28 PM, James Antill ja...@fedoraproject.org wrote: Ubuntu recently got high praise from LWN for Software Center in 10.10 betas. It doesn't use PackageKit at all AFAICS (no PackageKit packages are installed in my VM). It integrates tightly with apt (you know, like showing package history ... like yumex does). Also their package install/remove tool is not gpk-application, and their update tool is not gpk-update-viewer. I had mentioned earlier that Canonical is pushing their Software Center as a big feature, I don't see them replacing it with something cross-distro any time soon. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Hi, On 09/08/2010 02:43 PM, Richard Hughes wrote: On 8 September 2010 13:16, Adam Williamsonawill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... Oh, But Adam is not the only one I love this idea too! And I would like to think there are other silent admirers of this idea too! I've even considered taken the review for the app data package and approving it, but then decided that would only raise the controversy surrounding the app data part. FWIW I agree with you that for this to be truely user friendly the app data needs to be present on the system when the user first starts the app installer. Not sure if dropping it in a package is the best thing to do though. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 13 September 2010 08:36, Hans de Goede hdego...@redhat.com wrote: But Adam is not the only one I love this idea too! And I would like to think there are other silent admirers of this idea too! Cool, thanks. I've even considered taken the review for the app data package and approving it, but then decided that would only raise the controversy surrounding the app data part. Right, that bugzilla is a big mess of ego and frustration (myself included). FWIW I agree with you that for this to be truely user friendly the app data needs to be present on the system when the user first starts the app installer. Not sure if dropping it in a package is the best thing to do though. If you could comment on the bugzilla, I believe FESCo is going to handle it from now on. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 2010-09-08, drago01 drag...@gmail.com wrote: On Wed, Sep 8, 2010 at 7:59 PM, drago01 drag...@gmail.com wrote: Well ideally every app that allows font selection should have a button / option add new font that opens a font installation dialog. To be clear this dialog should not be re implemented by every application but being an app started by said applications. Well, a lot of toolkits uses fontconfig to dispatch font characteristics to font file and some of them pango to substitute missing glyphs. One could add a hook into fontconfig library. However I predict strong opposition in upstream as fontconfig does not need X11 at all: $ ldd /usr/lib64/libfontconfig.so linux-vdso.so.1 = (0x7fffa1784000) libfreetype.so.6 = /usr/lib64/libfreetype.so.6 (0x0035d7a0) libexpat.so.1 = /lib64/libexpat.so.1 (0x0035d6a0) libc.so.6 = /lib64/libc.so.6 (0x0035d0a0) /lib64/ld-linux-x86-64.so.2 (0x0035d060) Maybe some optional dbus code could be included to broadcast request for missing font. If user had running an appropriate listener (some sort of packagekit or font selector), he could get an systray alert or popup window allowing to install missing package. Other question is: should the hook block the application and retry fontconfig font selection, or should it be completely asynchronous? -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Mon, 2010-09-13 at 09:36 +0200, Hans de Goede wrote: Hi, On 09/08/2010 02:43 PM, Richard Hughes wrote: On 8 September 2010 13:16, Adam Williamsonawill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... Oh, But Adam is not the only one I love this idea too! And I would like to think there are other silent admirers of this idea too! There are a lot of non-silent admirers of this idea too! I love this idea! All the yum developers and rel-eng love this idea! I've yet to speak to anyone who doesn't love this idea! In fact this thread probably started because yum/rpm/etc. developers had recently talked about app. install again, so Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ To repeat _nobody_, that I know of, is arguing that we shouldn't do something. The problem is in rushing from there to XYZ is something. We should do XYZ. -- James Antill - ja...@fedoraproject.org I'd just like to see a realistic approach to updates via packages. -- Les Mikesell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 13 September 2010 21:49, James Antill ja...@fedoraproject.org wrote: So Seth spent half a day implementing a proof of concept: http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Formal database schema? Call me biased, but doing things in yum because it's the way it always used to be carries little weight when the user experience just sucks really hard. I've been working on app-install now with other distro people for nearly two years. It was a shame Seth couldn't reuse some of the schema without just re-implementing the basic idea in python and shipping a half-baked implementation in yum. Sometimes I wonder why I should deal with Fedora and all the politics when Ubuntu and Suse just ship something that works. Sorry to be blunt, but it's how I feel. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-08 at 22:21 +0200, Nicolas Mailhot wrote: Le mercredi 08 septembre 2010 à 19:07 +0100, Alex Hudson a écrit : The i18n situation is also pretty sad from my point of view too. If you use pretty much any design app, OO Writer and Inkscape being the ones which cause me pain, the standard set of fonts that comes with Fedora is entirely confusing and bizarre, and gets completely in the way of actually trying to design text. It's well known that the current font selectors are not good enough. [snip lots of stuff I agree with] I think that's absolutely correct, and it's not like I'm saying anything terribly new, but for me the font installation stuff has to be pretty tied into font selection. What I'd ideally want is a much better font selection system, like you've outlined in those various bugs, and then maybe just an extra button on those dialogs titled Get new fonts or similar. In an ideal world, that would bring up a GtkHtml widget or something and replicates the font selection system (or could be even integrated into it), but with web fonts so you can view them and try them out with relevant text (trying to include screenshots for each relevant language / unicode coverage area seems a bit mad to me). And then when you've found them, you should have the choice of just bringing them into your account (bypassing RPM completely) or loading them system-wide (which would then trigger PackageKit). Fonts being in RPMs and supported in PackageKit is something I totally support, but attempting to re-use a more generic software installation UI to allow users to manage fonts seems severely sub-optimal to me. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le Jeu 9 septembre 2010 09:26, Alex Hudson a écrit : Fonts being in RPMs and supported in PackageKit is something I totally support, but attempting to re-use a more generic software installation UI to allow users to manage fonts seems severely sub-optimal to me. Well, this thread is about specializing some of the package installation interface (for desktop apps, for fonts, etc). I was just outlining the requirements for fonts. It needs works both packagekit-side and font packaging side, but there is absolutely no way I'm going to expand energy on pushing the packaging changes through FPC other font packagers if there is no buy-in packagekit-side to make use of them. Unlike application desktop files, font preview has a single consumer, packagekit, so it's totally wasted work if the packagekit side is missing. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 9 September 2010 09:52, Nicolas Mailhot nicolas.mail...@laposte.net wrote: It needs works both packagekit-side and font packaging side, but there is absolutely no way I'm going to expand energy on pushing the packaging changes through FPC other font packagers if there is no buy-in packagekit-side to make use of them. Unlike application desktop files, font preview has a single consumer, packagekit, so it's totally wasted work if the packagekit side is missing. I'm interested in font installing, but I think it might be better to integrate this with app-install rather than packagekit, as app-install has a pointer to a screenshot URL we can show in the preview window. This just means we have to treat fonts either as applications (and thus need desktop files) or we can just maintain a separate datastore and merge this with the fedora-app-install data before the package is shipped. The latter is probably my preferred solution. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Linux and application installing
On Sep 9, 2010, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Jeu 9 septembre 2010 09:26, Alex Hudson a écrit : Fonts being in RPMs and supported in PackageKit is something I totally support, but attempting to re-use a more generic software installation UI to allow users to manage fonts seems severely sub-optimal to me. Well, this thread is about specializing some of the package installation interface (for desktop apps, for fonts, etc). I was just outlining the requirements for fonts. It needs works both packagekit-side and font packaging side, but there is absolutely no way I'm going to expand energy on pushing the packaging changes through FPC other font packagers if there is no buy-in packagekit-side to make use of them. Unlike application desktop files, font preview has a single consumer, packagekit, so it's totally wasted work if the packagekit side is missing. Interesting discussion. I quite agree that work is needed at the graphical level, and that such effort is rather more important than analogous work at the console level. However, I wonder whether there may be some utility in exploring graphical solutions that are not inconsistent with similar capabilities at the console, perhaps even without X running. The idea of Unicode fonts available at the console from disk, or conceivably from a system or video BIOS, would extend the potential usefulness of the console if an implementation of font handling and selection could be unified for console and graphical applications. Just a thought. Ken Marcy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-09 at 11:03 +0100, Richard Hughes wrote: I'm interested in font installing, but I think it might be better to integrate this with app-install rather than packagekit, as app-install has a pointer to a screenshot URL we can show in the preview window. I'm not sure why this should be part of either of those apps. A screenshot is marginally useful, but how do you give a good idea of how the font works in different weights, sizes, and with different text (particularly those fonts with good Unicode coverage)? I think it's sub-optimal to say the least. What you really want is a font store which has functionality like this: http://code.google.com/webfonts/preview#font-family=Cantarell Packagekit is a great way of getting the RPM which has the font and installing it on the system. I don't know if the font RPMs are of much use before then, because by the time you have a system that can allow you to put your own text in and actually see what the font looks like, you pretty much have the font already. I think this actually ought to be a web-based service on the Fedora servers. You can use the web-font stuff to do a really good font browser, and there is already the ability to click on RPMs and install them via Packagekit if you want the RPM. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/09/2010 01:24 PM, Alex Hudson wrote: A screenshot is marginally useful, but how do you give a good idea of how the font works in different weights, sizes, and with different text (particularly those fonts with good Unicode coverage)? I think it's sub-optimal to say the least. You are going way to far here... for this purpose (normal users installing fonts) a PNG with the standard The brown fox... text in normal, bold and italic is enough. Designers, who need the very last detail for a font before choosing it, can use a font store and download the TTF file in ~/.fonts What you really want is a font store which has functionality like this: http://code.google.com/webfonts/preview#font-family=Cantarell -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le Jeu 9 septembre 2010 12:24, Alex Hudson a écrit : What you really want is a font store which has functionality like this: http://code.google.com/webfonts/preview#font-family=Cantarell What you do not realize is that this kind of preview works by having the complete font file downloaded by the browser in the background, in other words it is as resource intensive as just installing the font package and playing with the font locally. The only thing this kind of preview buys you is automatic font de-installation when you close the browser. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-09 at 13:49 +0200, Nicolas Mailhot wrote: Le Jeu 9 septembre 2010 12:24, Alex Hudson a écrit : What you really want is a font store which has functionality like this: http://code.google.com/webfonts/preview#font-family=Cantarell What you do not realize is that this kind of preview works by having the complete font file downloaded by the browser in the background, in other words it is as resource intensive as just installing the font package and playing with the font locally. The only thing this kind of preview buys you is automatic font de-installation when you close the browser. Well, we seem to be descending into technicalities now, but I did realise that. I just don't think it matters. Let's examine the claim you made that it is as resource intensive as installing the font package. .TTF fonts (as an example) just aren't very big. I tried a sample font in my .fonts directory, it's 75K and five lines of varied The quick brown fox.. in PNG format comes out at 25K. If I gzip the ttf, it's 28K, and the png goes to 22K. So the data size is actually pretty close. The RPM is 115K, including 94K of preview PDF (which also has the font embedded into it.. even though we know it's on the system?!). Let's look at the application time. Loading up the page I mentioned, it takes less than two seconds to get the full font preview up (actually, it's much faster than that, but I have no way of timing it, so let's be conservative and call it five seconds). Download the font into .fonts is pretty much instantaneous, presumably because it's already cached. If I load up packagekit, the add/remove application opens in about the same time. But now, I need to search and then click the checkbox, and then apply. It takes eight seconds to download repository information, and then another five seconds to resolve dependencies. Now I'm asked for my root password. From entering that correctly, it then takes 25 seconds to complete the install. So this is pretty much 45-50 seconds, even if we're trying to be quick. Presumably if you have RPM updates outstanding as well, or PK is 'doing stuff', then the whole thing would take longer too (this system was up-to-date). So, I disagree it's as resource intensive as the RPM method. It's fundamentally much faster than installing the font locally. Seriously, just try it. It's not even in the same league. But anyway, this is all really beside the point. The mechanics of how this would work don't bother me as long as it works well. The Google page, as technical as it is, is still leagues better than flicking through screen shots. The user experience is what matters. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le Jeu 9 septembre 2010 14:29, Alex Hudson a écrit : On Thu, 2010-09-09 at 13:49 +0200, Nicolas Mailhot wrote: Le Jeu 9 septembre 2010 12:24, Alex Hudson a écrit : What you really want is a font store which has functionality like this: http://code.google.com/webfonts/preview#font-family=Cantarell What you do not realize is that this kind of preview works by having the complete font file downloaded by the browser in the background, in other words it is as resource intensive as just installing the font package and playing with the font locally. The only thing this kind of preview buys you is automatic font de-installation when you close the browser. Well, we seem to be descending into technicalities now, but I did realise that. I just don't think it matters. Let's examine the claim you made that it is as resource intensive as installing the font package. .TTF fonts (as an example) just aren't very big. I tried a sample font in my .fonts directory, it's 75K and five lines of varied The quick brown fox.. in PNG format comes out at 25K. If I gzip the ttf, it's 28K, and the png goes to 22K. So the data size is actually pretty close. The google type library is not representative as they do not propose full fonts but fonts cut down to the few hundreds of glyphs necessary for latin. The smallest the font the closest the size will be to a preview file. Typical full-featured modern fonts (even excluding cjk fonts) are a lot fatter. The RPM is 115K, including 94K of preview PDF (which also has the font embedded into it.. even though we know it's on the system?!). The rpm uses the pdf upstream provided, you can ask the packager to remove it or split it in a separate package So, I disagree it's as resource intensive as the RPM method. It's fundamentally much faster than installing the font locally. Seriously, just try it. It's not even in the same league. It's more resource-intensive server-side and the whole speed depends on your network pipe. If you have a fat network pipe you do not need a font store, just install all the font packages in Fedora and be done with it. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, 2010-09-09 at 15:05 +0200, Nicolas Mailhot wrote: Le Jeu 9 septembre 2010 14:29, Alex Hudson a écrit : .TTF fonts (as an example) just aren't very big. I tried a sample font in my .fonts directory, it's 75K and five lines of varied The quick brown fox.. in PNG format comes out at 25K. If I gzip the ttf, it's 28K, and the png goes to 22K. So the data size is actually pretty close. The google type library is not representative as they do not propose full fonts but fonts cut down to the few hundreds of glyphs necessary for latin. The smallest the font the closest the size will be to a preview file. I wasn't using the Google Type library for that comparison - I was using a system font (although one of the fonts I tested (Inconsolata) is available in Fedora as well as on Google). So this argument doesn't apply. The point stands, anyway: the preview is a cut-down set of glyphs as well. A cut-down font *is* a preview file. Doing the preview in .PNG, .PDF, or some other format is not going to be more efficient than the .TTF format, unless you have some other data to offer. So, I disagree it's as resource intensive as the RPM method. It's fundamentally much faster than installing the font locally. Seriously, just try it. It's not even in the same league. It's more resource-intensive server-side and the whole speed depends on your network pipe. How can this possibly be true? Both servers are offering files to download; one is offering JS + TTF the other is offering RPM. As I've shown, the data is essentially the same size. The server-side work is the same. What system are you proposing that would allow fonts to be previewed with significantly less data being transferred? I dispute any system based on PNG files saves measurable space for the reasons and experiments set out in this email and the last; it's easy to test. What other data format should I test? Thanks Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le Jeu 9 septembre 2010 15:32, Alex Hudson a écrit : On Thu, 2010-09-09 at 15:05 +0200, Nicolas Mailhot wrote: Le Jeu 9 septembre 2010 14:29, Alex Hudson a écrit : .TTF fonts (as an example) just aren't very big. I tried a sample font in my .fonts directory, it's 75K and five lines of varied The quick brown fox.. in PNG format comes out at 25K. If I gzip the ttf, it's 28K, and the png goes to 22K. So the data size is actually pretty close. The google type library is not representative as they do not propose full fonts but fonts cut down to the few hundreds of glyphs necessary for latin. The smallest the font the closest the size will be to a preview file. I wasn't using the Google Type library for that comparison - I was using a system font (although one of the fonts I tested (Inconsolata) is available in Fedora as well as on Google). So this argument doesn't apply. Inconsolata has even less coverage than Google Type Library fonts. The author is still working to complete all the latin blocks and has not started non-latin blocks. The completed part is very nice, but not very extensive. So, I disagree it's as resource intensive as the RPM method. It's fundamentally much faster than installing the font locally. Seriously, just try it. It's not even in the same league. It's more resource-intensive server-side and the whole speed depends on your network pipe. How can this possibly be true? Both servers are offering files to download; one is offering JS + TTF the other is offering RPM. As I've shown, the data is essentially the same size. It's only the same size for very small fonts with few glyphs. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: Sure, I understand where you're coming from. As you see from app-install schema version 1 it really was least common denominator. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. First off, I think this is a great idea and very much needed, thanks for working on it. On the cross-distro front, is Canonical / Ubuntu officially involved in this and expecting to move to it in future, or are you just working 'unofficially' with some Ubuntu community people and if anything it'll wind up being an unofficial alternative for Ubuntu users? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 8, 2010 at 8:16 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: Sure, I understand where you're coming from. As you see from app-install schema version 1 it really was least common denominator. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. First off, I think this is a great idea and very much needed, thanks for working on it. On the cross-distro front, is Canonical / Ubuntu officially involved in this and expecting to move to it in future, or are you just working 'unofficially' with some Ubuntu community people and if anything it'll wind up being an unofficial alternative for Ubuntu users? I don't follow Canonical's news, but I believe that they have their own tool for this which is a big deal feature for their next release. So I'm not sure they would ever adopt this. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 8 September 2010 13:16, Adam Williamson awill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... On the cross-distro front, is Canonical / Ubuntu officially involved in this and expecting to move to it in future, or are you just working 'unofficially' with some Ubuntu community people and if anything it'll wind up being an unofficial alternative for Ubuntu users? I'm working semi-officially with Sebastian Heinlein from Ubuntu and Roderick Greening from Suse. Sebastian is the one driving through the new changes in the Ubuntu Software Center, and works heavily with PackageKit and apt. You could say he's the right person to be working with. Of course, all the time app-install is too feature poor for them, they'll not switch from the xapian index (and this is the case with the deliberately simple v1 schema). Version 2 schema, which we're working on defining now, and is 90% complete provides enough functionality to switch away from xapian. But of course, Fedora is an early adopter and driving development. Just like normal. Just like it should be. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-08 at 13:43 +0100, Richard Hughes wrote: But of course, Fedora is an early adopter and driving development. Just like normal. Just like it should be. Sure. I just hoped they were plugged into this process in some sense so that if it does meet their needs in future they'll look at using it. It'd be cool to have everyone on the same system. Sounds like that's in hand, so...great :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 8, 2010 at 2:43 PM, Richard Hughes hughsi...@gmail.com wrote: On 8 September 2010 13:16, Adam Williamson awill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... FWIW the way we currently handle application installation is beyond bad (i.e is a major flaw in the current UX) so thanks for working on this! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, Sep 7, 2010 at 1:23 PM, Richard Hughes hughsi...@gmail.com wrote: A patch would be lovely, but some sample code that renders a ttf file to a png file The smart brown fox or whatever using cairo is probably good enough for me to get going. Just to be clear. When users want a to get a new font what is the ideal software interaction path you expect them to take to find fonts? It's not clear that app-install is what you expect them to interact with. I do sort of expect normal end-users to want additional fonts as part of day to day document preparation and I wouldn't cast the search for fonts as a power user or admin activity. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 8, 2010 at 7:18 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Sep 7, 2010 at 1:23 PM, Richard Hughes hughsi...@gmail.com wrote: A patch would be lovely, but some sample code that renders a ttf file to a png file The smart brown fox or whatever using cairo is probably good enough for me to get going. Just to be clear. When users want a to get a new font what is the ideal software interaction path you expect them to take to find fonts? It's not clear that app-install is what you expect them to interact with. I do sort of expect normal end-users to want additional fonts as part of day to day document preparation and I wouldn't cast the search for fonts as a power user or admin activity. Well ideally every app that allows font selection should have a button / option add new font that opens a font installation dialog. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, 2010-09-08 at 09:18 -0800, Jeff Spaleta wrote: Just to be clear. When users want a to get a new font what is the ideal software interaction path you expect them to take to find fonts? It's not clear that app-install is what you expect them to interact with. I do sort of expect normal end-users to want additional fonts as part of day to day document preparation and I wouldn't cast the search for fonts as a power user or admin activity. I think the font handling is still some of the worst pieces of the install story, particularly since conflating software installation and font installation are really confusing from a user point of view. What you really want as a user is a font browser where you can view the actual font, preferably with text you want to input. I guess it's vaguely like having an app store with screenshots, but I think it's a totally different use case. I know fonts come in RPMs, but tbh as a user I could really care less. The i18n situation is also pretty sad from my point of view too. If you use pretty much any design app, OO Writer and Inkscape being the ones which cause me pain, the standard set of fonts that comes with Fedora is entirely confusing and bizarre, and gets completely in the way of actually trying to design text. Using the same tool/UI for all these different cases is pretty obviously wrong in my opinion. It would rock hard if you could use the same Font Store (or whatever you call it) to install this-user-only fonts into ~/.fonts (or whichever folder it is) so that it's not something which necessarily has to use PackageKit to install stuff. Ta Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Wed, Sep 8, 2010 at 10:07 AM, Alex Hudson fed...@alexhudson.com wrote: I know fonts come in RPMs, but tbh as a user I could really care less. I'm not disagreeing. But since fonts have come up in the context of app-install.. I'd like to hear what the main PackageKit developer thinks about fonts as _packages_. I understand the automatic hooks to look for things like codecs and fonts on a media consumption basis as a use case. Open up a media file (whether it be a document or video or whatever) and the font/codec/whatever isn't embedded and the system fires off a request for PK to look for the specific piece of media software as encoded in the the package management subsystem to fill the consumption need on demand. I totally get the background query facility in the strict media consumption case. And I can sort of see how media codecs can be background queried and installed at time of media production if a user wants to render into a a/v format not currently supported by the installed software. But what I don't understand is how _users_ are meant to interact with PK to find fonts as non-executable pieces of software when doing media _production_. When my dad is working a document or presentation or doing desktop publishing tasks like a newsletter or bulletin using only desktop _applications_ as PK understands the term... what's the UI workflow to find fonts as packaged in the system's packaging repository as part of a document production process? Are we going to need a font-install parallel to app-install and additional dedicated UI that mimics the UI for apps? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le mardi 07 septembre 2010 à 22:23 +0100, Richard Hughes a écrit : On 7 September 2010 17:32, Matthias Clasen mcla...@redhat.com wrote: And BTW a request at the time was to extend it with font previews to get a font store (because for fonts, gfx preview is really relevant and not eye candy) and it never happened :( If you send a patch it might ! A patch would be lovely, but some sample code that renders a ttf file to a png file The smart brown fox or whatever using cairo is probably good enough for me to get going. As far as I know, here is the current state of the art: 1. gnome-font-viewer has the code to select a specific font file and a pangram database (short snippets of text appropriate for different locales) 2. pango-view has the code to generate a svg using cairo containing a specific text in a specific font (but it does not let you select a specific font file as far as I can see) For example: pango-view --font=Yanone Kaffeesatz 50 -t tralala --no-display -o preview.svg so by combining code from both it should be possible to create a small utility that takes as argument a font file and a locale and generates a svg (or svgz) containing the pangram text for this locale with the shapes of the selected font file. (possibly with the option to specifically pass the unicode string to render as svg instead of a local, for example for symbol fonts where it's totally uninteresting to display human text) And then we could add in our font packaging guidelines that packagers have to run this utility to install the preview svg in the rpm at a standard location for packagekit to harvest and display as preview for this package (maybe multiple preview svgs per package, if a font package includes multiple font faces or multiple interesting locales to highlight) Why? 1. As a font file is already an optimized vector library format it is not advisable to generate a preview for all the glyphs included in a font file. The result could easily be bigger than the packaged font file, or too long to be used as preview (cjk *shudder*) 2. It is not really possible to fix in stone or even autodetect the font subset which is interesting to use in preview. Different fonts have different unicode coverage, and many fonts have one core part plus uninteresting bits copied from other fonts to fill in. For example Debian has tried to run an automated preview generator on its font archive, displaying some ASCII text, and they got scores of non-latin font that all previewed the same (because their authors created the glyphs for their locale, and then copied the same ghostscript or free sans font for latin so their users could write mixed english/something else text without changing font). Therefore, the selection of the font subset to use as preview is an editorial decision the font packager is best placed to make. (otherwise I'd be more than happy to have packagekit do it all by itself without packager intervention, I don't like more work as packager too) 3. It's not really a good idea to render to a bitmap format when you don't know the pixel density of the user display. As the hardware gets more diverse, there is a high chance you'll have to scale the preview sooner or later and for that a vector format like svg is more respectful of font shapes (grid-fitting hinting matter at small sizes but font previews are usually done with big text) --- I hope this seems sane from Richard's point of view Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le mercredi 08 septembre 2010 à 19:07 +0100, Alex Hudson a écrit : The i18n situation is also pretty sad from my point of view too. If you use pretty much any design app, OO Writer and Inkscape being the ones which cause me pain, the standard set of fonts that comes with Fedora is entirely confusing and bizarre, and gets completely in the way of actually trying to design text. It's well known that the current font selectors are not good enough. They were designed for a dozen unchanging fonts with four faces at most, and the font state has grown a lot more complex since (unicode, smart font features, fonts with lots of faces, etc). Nowadays a normal desktop system can have a font library as complex as specialized design stations had a decade ago, but the standard selectors have not been raised to the level of dtp font selectors of last decade. http://qa.openoffice.org/issues/show_bug.cgi?id=79878 https://bugzilla.gnome.org/show_bug.cgi?id=597751 (you can probably find others on http://fedoraproject.org/wiki/Known_fonts_and_text_bugs) There are many designs for better selectors floating around (some of them years old). I'm pretty use that as soon as GNOME, KDE or OO.o fixes its implementation, the others will suddenly find the time to fix theirs. Right now they seem to consider it's ok to suck as long as the others suck equally. I'd love to see progress there too, but it is a different problem than the font store one. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le mercredi 08 septembre 2010 à 21:35 +0200, Nicolas Mailhot a écrit : so by combining code from both it should be possible to create a small utility that takes as argument a font file and a locale and generates a svg (or svgz) containing the pangram text for this locale with the shapes of the selected font file. Another possibility would be to write an utility that takes a text file and a font file as argument, and generates the smallest possible font file subset sufficient to display this text. And then save the text and font subset files, and use them to do the preview. This could probably be almost as space efficient as the svg, and permit higher quality previews, but I don't know of such an automatic subsetting tool, it requires deep knowledge of font file innards, so could probably only be created as a fontforge extension by fontforge people. (though I'm sure woff users would like a user-friendly subsetting tool) I'm not sure the better preview quality is worth the complexity over just copying whatever pango-view gnome-font-viewer do to generate svgs. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linux and application installing
Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. So, a solution. I've been working on app-install[3] with some people from other distros for the last few months, and last week it had it's first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I've already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available[4]. It's really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works. I've got two demo applications that use the app-install data. One is an http://people.freedesktop.org/~hughsient/temp/app-install-install.png installer and one is an http://people.freedesktop.org/~hughsient/temp/app-install-update.png updater. These are work in progress, and show dramatically the lack of my UI design skills. The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users[5]. If you know what an epoch is, it's probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn't shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the Applications menu. The updater will be an improved version of the old package updater, and anything that's not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called System infrastructure. If you update an application that depends on a package from the System infrastructure group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the System infrastructure metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump. Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn't well tested. The code may steal *all* your magazines from your bathroom. Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to http://live.gnome.org/action/edit/app-install. I'm going to ask Máirín (mizmo on IRC) to help with the design work, so please upload images I can share with her and the other design people. Thanks! Richard. [1] https://fedoraproject.org/w/uploads/1/13/Updates-pkgkit-before.png http://mairin.wordpress.com/ [2] http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ [3] http://github.com/hughsie/app-install [4] http://people.freedesktop.org/~hughsient/fedora/13/i386/ [5] http://www.packagekit.org/pk-profiles.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/07/2010 05:16 PM, Richard Hughes wrote: Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. Thoughts on making the software center less distro specific? Couldn't the UI be grafted on top of the PK api? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 12:57, Rahul Sundaram methe...@gmail.com wrote: Thoughts on making the software center less distro specific? Couldn't the UI be grafted on top of the PK api? app-install is completely distro-neutral. GNOME PackageKit and KPackageKit get the same kind of data from app-install for each distro. The reason we're not just modifying the Ubuntu Software center is just because it's so tied into the Ubuntu infrastructure. So far there is a generator for Ubuntu and Fedora. It's pretty trivial to add more. The app-install README file has answers to other common questions. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Richard Hughes píše v Út 07. 09. 2010 v 12:46 +0100: The updater will be an improved version of the old package updater, and anything that's not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called System infrastructure. If you update an application that depends on a package from the System infrastructure group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the System infrastructure metagroup. Um, do I understand this correctly that e.g. a kernel update usually won't get installed because it belongs in system infrastructure and few packages depend on kernel? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
2010/9/7 Miloslav Trmač m...@volny.cz: Richard Hughes píše v Út 07. 09. 2010 v 12:46 +0100: The updater will be an improved version of the old package updater, and anything that's not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called System infrastructure. If you update an application that depends on a package from the System infrastructure group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the System infrastructure metagroup. Um, do I understand this correctly that e.g. a kernel update usually won't get installed because it belongs in system infrastructure and few packages depend on kernel? No. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
2010/9/7 Miloslav Trmač m...@volny.cz: Um, do I understand this correctly that e.g. a kernel update usually won't get installed because it belongs in system infrastructure and few packages depend on kernel? By default, all updates will be selected, even those in the system infrastructure group. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 17:27 +0530, Rahul Sundaram wrote: On 09/07/2010 05:16 PM, Richard Hughes wrote: Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. Thoughts on making the software center less distro specific? Couldn't the UI be grafted on top of the PK api? okay - I'll bite - why do we want to make it less distro-specific? What does it get us? It means we have to deal with a bunch of Lowest-common-denominator issues and it means a looser coupling of the tools we have. It is legit to write tools for fedora that are FOR fedora. Why not do that? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 14:11, seth vidal skvi...@fedoraproject.org wrote: okay - I'll bite - why do we want to make it less distro-specific? For the same reason as pirut and pup were replaced. Fedora is *not* a big enough ecosystem to drive fully localized and feature rich user experiences. Working with other distros mean we can work as one big team and share the burden of translation, bug-fixes and writing new common code. I certainly don't want to write software for Fedora, but rather write software for Linux, and then write the small amount of Fedora interface code. What does it get us? It means we have to deal with a bunch of Lowest-common-denominator issues and it means a looser coupling of the tools we have. Sure, I understand where you're coming from. As you see from app-install schema version 1 it really was least common denominator. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. It is legit to write tools for fedora that are FOR fedora. Why not do that? Of course it's legitimate to do so. I just don't think it's a very sustainable or responsible way to write software. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 09:11 -0400, seth vidal wrote: On Tue, 2010-09-07 at 17:27 +0530, Rahul Sundaram wrote: On 09/07/2010 05:16 PM, Richard Hughes wrote: Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. Thoughts on making the software center less distro specific? Couldn't the UI be grafted on top of the PK api? okay - I'll bite - why do we want to make it less distro-specific? What does it get us? It means we have to deal with a bunch of Lowest-common-denominator issues and it means a looser coupling of the tools we have. It is legit to write tools for fedora that are FOR fedora. Why not do that? Because sharing infrastructure and tools is raising the lowest common denominator and benefits everybody ? Common good, etc... That being said, yes, doing things in less distro-specific ways does involve compromise, and I'm not very optimistic about getting any of that for the software center... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 09:19 -0400, Matthias Clasen wrote: On Tue, 2010-09-07 at 09:11 -0400, seth vidal wrote: On Tue, 2010-09-07 at 17:27 +0530, Rahul Sundaram wrote: On 09/07/2010 05:16 PM, Richard Hughes wrote: Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. Thoughts on making the software center less distro specific? Couldn't the UI be grafted on top of the PK api? okay - I'll bite - why do we want to make it less distro-specific? What does it get us? It means we have to deal with a bunch of Lowest-common-denominator issues and it means a looser coupling of the tools we have. It is legit to write tools for fedora that are FOR fedora. Why not do that? Because sharing infrastructure and tools is raising the lowest common denominator and benefits everybody ? Common good, etc... That being said, yes, doing things in less distro-specific ways does involve compromise, and I'm not very optimistic about getting any of that for the software center... yah - I have firsthand experience the pains of doing things in less distro-specific ways. The repodata was done that way and all changes require an enormous amount of discussion and frequently never happen b/c of the discussion. It is sometimes excruciating. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: On 7 September 2010 14:11, seth vidal skvi...@fedoraproject.org wrote: okay - I'll bite - why do we want to make it less distro-specific? For the same reason as pirut and pup were replaced. Fedora is *not* a big enough ecosystem to drive fully localized and feature rich user experiences. Working with other distros mean we can work as one big team and share the burden of translation, bug-fixes and writing new common code. I certainly don't want to write software for Fedora, but rather write software for Linux, and then write the small amount of Fedora interface code. Except we don't seem to do that. Over half of all commits to PK are from you. The next closest committer has 6% of commits. If I exclude the backends and translations then PK is written almost exclusively by you. So all the time you spent writing a compat layer of code for OTHER distros gets fedora what? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 14:39, seth vidal skvi...@fedoraproject.org wrote: Except we don't seem to do that. Over half of all commits to PK are from you. The next closest committer has 6% of commits. If I exclude the backends and translations then PK is written almost exclusively by you. I'm not sure I get your logic. Lots of the bugfixes (which may only be one or two commits a month) come from other distros. If I didn't make it generic, then there would be no possibility of running PackageKit on Suse, Debian, Ubuntu, Arch Linux or the other PK supported distros. So all the time you spent writing a compat layer of code for OTHER distros gets fedora what? A better, more architecturally sound design. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 09:39 -0400, seth vidal wrote: On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: On 7 September 2010 14:11, seth vidal skvi...@fedoraproject.org wrote: okay - I'll bite - why do we want to make it less distro-specific? For the same reason as pirut and pup were replaced. Fedora is *not* a big enough ecosystem to drive fully localized and feature rich user experiences. Working with other distros mean we can work as one big team and share the burden of translation, bug-fixes and writing new common code. I certainly don't want to write software for Fedora, but rather write software for Linux, and then write the small amount of Fedora interface code. Except we don't seem to do that. Over half of all commits to PK are from you. The next closest committer has 6% of commits. If I exclude the backends and translations then PK is written almost exclusively by you. So all the time you spent writing a compat layer of code for OTHER distros gets fedora what? It gets us translations that we would not otherwise have, and it gets us integration in the rest of the desktop, like automatic font or codec installation. Do you think the world would be a better place if every distribution wrote and maintained their own hooks for these things ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/07/2010 04:51 PM, Matthias Clasen wrote: On Tue, 2010-09-07 at 09:39 -0400, seth vidal wrote: So all the time you spent writing a compat layer of code for OTHER distros gets fedora what? It gets us translations that we would not otherwise have, and it gets us integration in the rest of the desktop, like automatic font or codec installation. Last time I checked Fedora had a healthy translation infrastructure. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote: On 7 September 2010 14:11, seth vidal skvi...@fedoraproject.org wrote: okay - I'll bite - why do we want to make it less distro-specific? For the same reason as pirut and pup were replaced. Fedora is *not* a big enough ecosystem to drive fully localized and feature rich user experiences. This would be a more compelling argument if PK was significantly better than pirut/yumex/etc. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? I assume you have a plan for making this repodata, but I couldn't find it, is there a URL? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. I assume you have a plan for making this repodata, but I couldn't find it, is there a URL? This isn't repodata, it's a separate data package. You /could/ push the icons.tar.gz and desktop sqlite database as repodata, although it's not going to change for the duration of each release[1] so seems like a waste of resources. From an rpm point of view, it's easier to deal with the install and removal of data as rpm scriptlets system-wide than by pushing this into yum itself (and other distros could not use this code). We also want this data installed by default, and not fetched / updated when the user tries to install something for the first time. That would ruin the user experience. Richard. [1] The data only needs to be refreshed if popular packages get split, or many translations get added. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tuesday, September 7, 2010, 10:42:54 AM, Richard wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: This isn't repodata, it's a separate data package. You /could/ push the icons.tar.gz and desktop sqlite database as repodata, although it's not going to change for the duration of each release[1] so seems like a waste of resources. From an rpm point of view, it's easier to deal with the install and removal of data as rpm scriptlets system-wide than by pushing this into yum itself (and other distros could not use this code). We also want this data installed by default, and not fetched / updated when the user tries to install something for the first time. That would ruin the user experience. Richard. [1] The data only needs to be refreshed if popular packages get split, or many translations get added. Richard, To minimize the installed footprint on minimal systems such as ARM, would it not make sense to separate the information by translation, so that only the installed translations occupy space on disk and in the sqlite database? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. This is your definition of application, and IMNSHO not a good one. You are proposing infrastructure changes so that when a user says they want to install spreadsheet then we can go from presenting the user with 13 answers (current yum search result) to presenting them with 4 (maybe 5). This is great, and will be a big help, as I think we can all agree that it's much less likely the user will want perl-Spreadsheet-ParseExcel etc. However this is very much the same problem as a user trying to find sql server and getting results like voms-mysql-plugin etc. If you intentionally ignore this problem, it just means even more work in the long term as we have to change the metadata and any/all tools to cope. You might well argue that gnome-PK's target users shouldn't see postgresql-server in any results (or anything without a desktop file). And that's _fine_, I'm not trying to tell you how to write gnome-PK. I'm just trying to make sure we don't have to do major revisions to any application metadata we produce (or worse, multiple different bits of metadata). I assume you have a plan for making this repodata, but I couldn't find it, is there a URL? This isn't repodata, it's a separate data package. You've already proposed BZ 488968, it's already been commented on. I can't believe you are just saying I don't care what anyone else thinks, I'm going to do what I feel like ... so maybe I'm parsing your response incorrectly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, Sep 7, 2010 at 11:39 AM, James Antill ja...@fedoraproject.org wrote: On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. This is your definition of application, and IMNSHO not a good one. This is goes along with the only definition of application that I am aware of. Postifx is a system service. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 16:54 +0100, Richard Hughes wrote: On 7 September 2010 16:39, James Antill ja...@fedoraproject.org wrote: However this is very much the same problem as a user trying to find sql server and getting results like voms-mysql-plugin etc. If you intentionally ignore this problem, it just means even more work in the long term as we have to change the metadata and any/all tools to cope. Users don't install SQL servers[1]. Please read the paragraph I wrote that started: You might well argue that gnome-PK's target users shouldn't see postgresql-server in any results ...if we _both_ read what the other has written, it will make discussion much easier. [1] My definition of users are 3 actual people: http://packagekit.org/pk-profiles.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le mardi 07 septembre 2010 à 09:51 -0400, Matthias Clasen a écrit : It gets us translations that we would not otherwise have, and it gets us integration in the rest of the desktop, like automatic font or codec installation. ??? This was done 100% Fedora-side (not that I mind if it were adopted by other distros) And BTW a request at the time was to extend it with font previews to get a font store (because for fonts, gfx preview is really relevant and not eye candy) and it never happened :( -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 11:48 -0400, Arthur Pemberton wrote: On Tue, Sep 7, 2010 at 11:39 AM, James Antill ja...@fedoraproject.org wrote: On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote: On 7 September 2010 15:23, James Antill ja...@fedoraproject.org wrote: Are you having any discussions about applications like postfix, or is version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. This is your definition of application, and IMNSHO not a good one. This is goes along with the only definition of application that I am aware of. Postifx is a system service. http://en.wikipedia.org/wiki/Application_software Application software, also known as an application, is computer software designed to help the user to perform singular or multiple related specific tasks. ...which matches exctly, IMO. But if it's confusing I don't mind referring to this as otherword installing, if you have a less confusing word … I'd just rather not say desktop-application+services +dbus-services+cron-services+etc. installing each time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
Le mardi 07 septembre 2010 à 18:20 +0200, Nicolas Mailhot a écrit : Le mardi 07 septembre 2010 à 09:51 -0400, Matthias Clasen a écrit : It gets us translations that we would not otherwise have, and it gets us integration in the rest of the desktop, like automatic font or codec installation. ??? This was done 100% Fedora-side (not that I mind if it were adopted by other distros) (for the fonts part I mean) And BTW a request at the time was to extend it with font previews to get a font store (because for fonts, gfx preview is really relevant and not eye candy) and it never happened :( -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tue, 2010-09-07 at 18:20 +0200, Nicolas Mailhot wrote: Le mardi 07 septembre 2010 à 09:51 -0400, Matthias Clasen a écrit : It gets us translations that we would not otherwise have, and it gets us integration in the rest of the desktop, like automatic font or codec installation. ??? This was done 100% Fedora-side (not that I mind if it were adopted by other distros) Ok, lets go with another example of integration then: file-roller can use PackageKit to install missing support for archive formats. And BTW a request at the time was to extend it with font previews to get a font store (because for fonts, gfx preview is really relevant and not eye candy) and it never happened :( If you send a patch it might ! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 17:20, Nicolas Mailhot nicolas.mail...@laposte.net wrote: ??? This was done 100% Fedora-side (not that I mind if it were adopted by other distros) Incorrect. It was done on the Fedora transifex instance, but I know from fact that a few of the translators are from other distros, who have no interest in Fedora whatsoever. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 17:32, Matthias Clasen mcla...@redhat.com wrote: And BTW a request at the time was to extend it with font previews to get a font store (because for fonts, gfx preview is really relevant and not eye candy) and it never happened :( If you send a patch it might ! A patch would be lovely, but some sample code that renders a ttf file to a png file The smart brown fox or whatever using cairo is probably good enough for me to get going. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/07/2010 07:32 PM, Matthias Clasen wrote: On Tue, 2010-09-07 at 18:20 +0200, Nicolas Mailhot wrote: ??? This was done 100% Fedora-side (not that I mind if it were adopted by other distros) Ok, lets go with another example of integration then: file-roller can use PackageKit to install missing support for archive formats. The only archive format I can think of is .rar, which can't be included in Fedora anyway, for the rest I expect them working OOTB. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
