No dynamic groups in PackageKit : Solved
Richard Hughes
hughsient at gmail.com
Wed Oct 8 08:12:45 UTC 2008
On Wed, 2008-10-08 at 07:32 +0200, Thorsten Leemhuis wrote:
> On 07.10.2008 17:09, Richard Hughes wrote:
> > I really can't believe how rude some people are on this list.
> And communicating by mail makes things a whole lot more complicated and
> worse afaics, as that form of communication sometimes simply doesn't
> work well -- especially if people are not very careful (and all of us
> sometimes are not careful enough afaics).
Sure, I totally agree. When writing an email my rule of thumb is to read
the sentence aloud and think "would I say this to someone on the phone"?
-- It's very easy to call software a piece of crap on a mailing list,
but not so easy when you're talking to the author in person :-)
> Looks great. BTW, is this targeted for 0.3.x or 0.4.x?.
0.3.7, should be in rawhide on Monday.
> But nevertheless please allow me to ask one thing: You said "Tri-state
> checkboxes are a disaster" last month on this list. I don't doubt that.
> But nevertheless they in Pirut make something possible that is (afaics
> from the screenshot; it was not obvious where that code lives, otherwise
> I#d taken a closer look myself) not possible with PK: get a whole bunch
> of apps (e.g. get KDE with one click if you installed the Gnome spin)
> installed or uninstalled by (de)selecting just one checkbox.
Sure, I still think tri-state checkboxes are a disaster.
> It IMHO would be nice to have such kind of function in PK as well. Is
> that still there somewhere? Maybe something like the additional "Package
> Collections" ( http://www.packagekit.org/img/gpk-application-search.png
> ; second entry on the left side) could still work together with the new
> scheme?
Yes, good idea. Collections should be installable for both menu types.
> Then users can select the default set of a group there; most
> will not even notive that the collection names are the same as the
> names for the package group.
Right.
Thanks for the feedback,
Richard.
More information about the fedora-devel-list
mailing list