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
On 09/23/2010 06:09 PM, Bruno Wolff III wrote:
> On Thu, Sep 23, 2010 at 15:51:37 +0200,
>FlorianFesti 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 package
On Thu, Sep 23, 2010 at 15:51:37 +0200,
FlorianFesti 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
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 ever
On Friday, September 17, 2010 11:04 am, Richard Hughes wrote
> On 17 September 2010 08:01, FlorianFesti 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:
>
On Thu, Sep 16, 2010 at 4:01 PM, James Antill wrote:
> On Thu, 2010-09-16 at 10:57 +0200, drago01 wrote:
>> On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes wrote:
>> > On 13 September 2010 21:49, James Antill wrote:
>> >> So Seth spent half a day implementing a proof of concept:
>> >> http://sk
Le vendredi 17 septembre 2010 à 17:26 -0400, Colin Walters a écrit :
> On Fri, Sep 17, 2010 at 11:08 AM, Richard Hughes wrote:
> > On 17 September 2010 15:28, Bill Nottingham wrote:
> >> Not if it's provided in the RPM header in a way where it can be easily
> >> stuffed into the metadata or a sim
On Fri, 2010-09-17 at 18:37 +0100, Richard Hughes wrote:
> On 17 September 2010 16:39, FlorianFesti 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
On Fri, Sep 17, 2010 at 11:08 AM, Richard Hughes wrote:
> On 17 September 2010 15:28, Bill Nottingham 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
On 17 September 2010 16:39, FlorianFesti 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. Apparently the link between the
machine doing the compose and the mirror is sl
On 09/17/2010 05:05 PM, Richard Hughes wrote:
> On 17 September 2010 13:36, Arthur Pemberton 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 con
On 17 September 2010 15:28, Bill Nottingham 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 interesti
On 17 September 2010 13:36, Arthur Pemberton 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
metadat
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 h
On Fri, Sep 17, 2010 at 3:01 AM, FlorianFesti 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
On 17 September 2010 08:01, FlorianFesti 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 app
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)
On 16 September 2010 20:05, Colin Walters 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 n
On Thu, Sep 16, 2010 at 11:57 AM, Richard Hughes wrote:
n 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. gnome-shell shouldn't care what a 'pa
On Thu, Sep 16, 2010 at 7:57 AM, Richard Hughes 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 ou
On Thu, 2010-09-16 at 16:57 +0100, Richard Hughes wrote:
> On 16 September 2010 15:01, James Antill 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 fro
On 16 September 2010 15:01, James Antill 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_ abstrac
On Thu, 2010-09-16 at 10:57 +0200, drago01 wrote:
> On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes wrote:
> > On 13 September 2010 21:49, James Antill wrote:
> >> So Seth spent half a day implementing a proof of concept:
> >> http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-co
On 16 September 2010 09:57, drago01 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
On Mon, Sep 13, 2010 at 11:39 PM, Richard Hughes wrote:
> On 13 September 2010 21:49, James Antill 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-
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 int
On Wed, Sep 15, 2010 at 4:38 PM, FlorianFesti 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 update
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
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 ans
On Tue, Sep 14, 2010 at 6:28 PM, James Antill 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 histo
On Mon, 2010-09-13 at 22:39 +0100, Richard Hughes wrote:
> On 13 September 2010 21:49, James Antill 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 d
On 13 September 2010 21:49, James Antill 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,
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 Williamson wrote:
> >> First off, I think this is a great idea and very much needed, thanks for
> >> working on it.
> >
> > Cool, thanks. Some positi
On 2010-09-08, drago01 wrote:
> On Wed, Sep 8, 2010 at 7:59 PM, drago01 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
> applicatio
On 13 September 2010 08:36, Hans de Goede 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
Hi,
On 09/08/2010 02:43 PM, Richard Hughes wrote:
> On 8 September 2010 13:16, Adam Williamson 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 i
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
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 o
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
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
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 downl
On Thu, 2010-09-09 at 14:28 +0300, Nicu Buculei wrote:
> 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 c
Le Jeu 9 septembre 2010 12:03, Richard Hughes a écrit :
>
> On 9 September 2010 09:52, Nicolas Mailhot
> 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 f
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 a
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 shou
On Sep 9, 2010, Nicolas Mailhot 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
On 9 September 2010 09:52, Nicolas Mailhot 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
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
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 pai
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
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
Le mercredi 08 septembre 2010 à 09:18 -0800, Jeff Spaleta a écrit :
>
> 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 so
Le mardi 07 septembre 2010 à 22:23 +0100, Richard Hughes a écrit :
> On 7 September 2010 17:32, Matthias Clasen 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
On Wed, Sep 8, 2010 at 10:07 AM, Alex Hudson 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 un
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 no
On Wed, Sep 8, 2010 at 7:59 PM, drago01 wrote:
> On Wed, Sep 8, 2010 at 7:18 PM, Jeff Spaleta wrote:
>> On Tue, Sep 7, 2010 at 1:23 PM, Richard Hughes 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
On Wed, Sep 8, 2010 at 7:18 PM, Jeff Spaleta wrote:
> On Tue, Sep 7, 2010 at 1:23 PM, Richard Hughes 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.
>
>
>
On Tue, Sep 7, 2010 at 1:23 PM, Richard Hughes 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
On Wed, Sep 8, 2010 at 2:43 PM, Richard Hughes wrote:
> On 8 September 2010 13:16, Adam Williamson 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
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
On 8 September 2010 13:16, Adam Williamson 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
>
On Wed, Sep 8, 2010 at 8:16 AM, Adam Williamson 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, fe
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)
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
On 7 September 2010 17:32, Matthias Clasen 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 lov
On 7 September 2010 17:20, Nicolas Mailhot 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 i
On Tue, Sep 07, 2010 at 12:23:47PM -0400, James Antill wrote:
> > 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 c
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.
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
> > inst
On Tue, 2010-09-07 at 11:48 -0400, Arthur Pemberton wrote:
> On Tue, Sep 7, 2010 at 11:39 AM, James Antill wrote:
> > On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote:
> >> On 7 September 2010 15:23, James Antill wrote:
> >> > Are you having any discussions about applications like postfix
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 ado
On Tue, 2010-09-07 at 16:54 +0100, Richard Hughes wrote:
> On 7 September 2010 16:39, James Antill 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 jus
On 7 September 2010 16:39, James Antill 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 th
On Tue, Sep 7, 2010 at 11:39 AM, James Antill wrote:
> On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote:
>> On 7 September 2010 15:23, James Antill wrote:
>> > Are you having any discussions about applications like postfix, or is
>> > version 2 going to be just GUI stuff?
>>
>> Postfix is
On Tue, 2010-09-07 at 15:42 +0100, Richard Hughes wrote:
> On 7 September 2010 15:23, James Antill 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
>
On Tuesday, September 7, 2010, 10:42:54 AM, Richard wrote:
> On 7 September 2010 15:23, James Antill 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 eac
On 7 September 2010 15:23, James Antill 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 repodat
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote:
> On 7 September 2010 14:11, seth vidal 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
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 t
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 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. Fed
On 7 September 2010 14:39, seth vidal 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. Lo
On Tue, 2010-09-07 at 14:17 +0100, Richard Hughes wrote:
> On 7 September 2010 14:11, seth vidal 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
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 ins
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
On 7 September 2010 14:11, seth vidal 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
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
2010/9/7 Miloslav Trmač :
> 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.
Rich
2010/9/7 Miloslav Trmač :
> 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
>> inf
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
On 7 September 2010 12:57, Rahul Sundaram 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
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 somethin
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 d
92 matches
Mail list logo
