Pirut: Edit -> Repositories mock-up.

[Kevin Kofler]

Jeremy Katz <katzj <at> redhat.com> writes:
> You're missing my point here... the idea _ISN'T_ "how does the UI mock
> up match with the use cases".  It's more "determine the set of use
> cases.  Based on them, work on the actual interface".  You _start_ with
> the use cases, not the mockup.

Except that the "mockup" is inspired by an existing UI (Synaptic) which has 
been used successfully for years, and which IMHO is one of the best (if not the 
best) package management UIs out there.

> The idea with pirut has never been to provide "the functionality of the
> CLI wrapped up in a GUI".  Rather, we want to expose the things which
> are good for the majority of users.  If you need every bit of
> functionality of the CLI, then really, you're probably a better target
> user for the CLI not pirut.

Why artificially restrict the target user base for Pirut this way? Wouldn't it 
be better if Pirut was useful for everyone? Right now it really isn't, and 
Synaptic, Yumex or smart --gui are much better options for experienced users.

> Lots of options is _not_ the answer to making a tool attractive to
> "non-newbies". 

I also disagree with the assertion. Configurability is an important feature for 
power users. This is working well for KDE, Synaptic and many other software 
packages.

Another method of dealing with the different requirements of new and 
experienced users is to do what Firefox does: present a basic UI by default, 
but make it extensible by dozens of extensions. The yum CLI also uses this 
design to some extent. I personally really dislike this though, both because 
hunting down extensions/plugins is a pain (much more than checking an option 
somewhere) and because some of the functionality provided by the extensions or 
plugins should really be on by default (and able to be disabled by experienced 
users), take yum-skip-broken as an example. But IMHO even this design would be 
an improvement over the current Pirut.

        Kevin Kofler