Vedran Ljubovic <[EMAIL PROTECTED]> writes:
> of view. However, I was slightly disappointed to find
> that "the great modifications" in RpmDrake in 9.2 RCs
Which "great modifications"? I mean, you talk about it like some
"great modifications" were advertized somehow?
> were mostly under-the-hub stuff. I'm sure that
> technical improvements were significant, but the
> interface is very much the same.
Yes. It has been already much much criticized (discussed?) ya
know. I tried to answer the points (even if I'm not the only one
who decided for them) each time (I have to admit that I ended up
a little tired to answer same thing everytime ;p).
> Personally, I expected something more radical. I
> expected that the very concept of "packages" would
> finally be abandoned. In this long(ish) mail I'll try
> to explain what I mean. I hope that someone
> (preferably RpmDrake developers ;) will actually read
> this mail and perhaps even make some comments,
I'm the so-called "rpmdrake developer". I've read your mail. Will
try to shortly answer.
[...]
> On numerous occasions I've heard users complaining how
> Linux comes on 3 CDs while Windows XP is only one.
> This shows that they don't realize that these 3 CDs
> carry hundreds of exciting software titles.
>
> The reason for this oversight is, obviously, that
> program installation tools in present Linux
> distributions are intimidating and un-friendly. I
That's not obvious to me. Packages (programs) installation has
been simplified in rpmdrake2 (ending up with, among others,
current two-different-interfaces which is so critized - even if
it's logical and drastically simplifies the GUI). Simple
categories are available, good documentation in powerpack manuals
and online (and even with a clickable "Help" button now).
If newbies don't use Packages Installation, I think it has more
to do with the fact that a computer is frightening in general -
they won't use other tools as well, outside of mozilla and
evolution and openoffice, until a trusted computer literate
friend shows them another one - probably not an administration
one.
And I'm sure many other persons use rpmdrake2 and are very happy
with it.
[...]
> My proposition
>
> Based on the above observations, I believe that the
> following should be done:
>
> - There should be a new application named "Add/Remove
> Programs"
I fail to see how merging two functionalities would end up with
an easier tool, whereas this suggestion keeps poping up. I think
people design interfaces they'd like to use, and since they are
not newbies, we end up with that suggestion.
> In no way am I suggesting that RpmDrake is to be
> replaced. It should be kept as a tool for
> professionals and sysadmins that want to have a
> complete control of their system. However, newbie
> users should be directed to this new Add/Remove
> Programs tool.
>
> - This application should feature _programs_, not
> _packages_
> This is not just about terminology. What I mean is:
> list only packages that are programs and hide
> everything else. A definition of a program is "a
> package that has one or more menu entries". E.g. if
> it's not in the menus, it's not a program and
> therefore shouldn't be listed.
> "So what do we do with those other packages", you ask?
I feel that is a good proposal. I don't know the best way to
integrate this suggestion in rpmdrake though. Maybe another
"sorting method". Maybe the default one (although the default one
is already "mandrake choices" e.g. a short selected list of
packages that are sensible to newbies).
> - system components - should be dealt with by
> corresponding system configuration tools (i.e. X
> servers should be (un)installed with XFDrake, CUPS and
> PDQ with PrinterDrake, SANE with ScannerDrake etc.)
Already the case..
> - plug-ins and add-ons - they should be installed
> through a pop-up window that appears when installing
> the corresponding program. For example: presently we
> have packages named licq, licq-kde, licq-console and
> licq-rms. Add/Remove Programs should list just Licq.
> However, clicking on Licq should pop-up a dialog with
> checkboxes labeled "KDE support", "Console support"
> and "Remote management service". Dependencies for
> these packages (such as "at least one of..." and "only
> one of...") should be embedded in the GUI, using
> tricks such as disabled checkboxes, one checkbox
> activating when the other one is (un)checked, radio
> buttons etc.
Could be nice but I don't know how we can say "Kde Support" etc:
we can use the Summary: tag of the rpm's, which is not that good,
even if it's acceptable. Also, it adds complexity by poping a
question that I don't regard as central for newbies :/.
> - Programs should be listed under their real names
> Short version: just use the Summary tag instead of
> name+version
I'm not sure it's very good. Many Summary: tags are short
explanations rather than real names ("Tetris like game" for
crack-attack for example), I don't know if that's gonna be nice
once sorted in a list.
> - These programs should be categorized
> Something along the lines of "All packages, by Group"
> in RpmDrake. However, those categories are horrible.
> Why don't we just use the same categorization as used
> in menus? That would be very intuitive for the user. I
I don't know. Between 7.0 and 7.1 times we decided for the Menu
and Rpm-Groups new architecture, which is a bit different, I
don't know why because I didn't decided for them. Warly maybe you
remember?
> - Much, much more meta-information
> Given the above observations, these are the least that
> should be added to present RPM meta-info:
> * a nice name
> * a category under "the new categorization"
> * an icon/logo
> * a screenshot
> * list of plug-ins and add-ons for use in the pop-up
> (may be achieved with what-requires?)
There would take very much diskspace, especially screenshots! And
what about the time needed to do all the screenshots, list
plugins..
[...]
> - "Sources" and "Media" mess
> The term "source" was simply horrible. The first time
> I saw it, I thought it had something to do with
> .src.rpm files. "Medium" is much better, but it has
> issues. Mostly because people associate the word
> "media" to CDs, DVDs, tapes etc. but not to Internet
> repositories. The main power of urpmi IMO lies exactly
> in its Internet capabilities. Therefore I present you
> my proposal for a new (ugh! not again ;) name for
> this: "channels".
We decided for Media on this list around 3 months ago, this was a
sort of "community decision" I'd say, so I think it's
counter-productive to change them all again, except of course if
everyone on this list would strongly agree with "channels"
instead of "media" (which I personally don't, but I may be the
only one ;p).
> - Add more sources/media/channels automatically
> I know that Mandrake will never implement this, but
> what the hell :) one can dream.
> The biggest problem with RpmDrake is that sources are
> still too complicated to configure. Therefore I
Olivier Thauvin's easy-urpmi should be integrated in the media
configuration tool, when I have time :/ however I'm not very much
in favor of pushing newbies to use external packages (at the time
cooker was easily addable graphically, so many people broke their
system by trying to install "programs ugrades").
> - There should be a clearer distinction between
> packages coming from different sources. I.e. I should
> be able to see a package coming from Cooker and the
> one from CDs and choose one of them as I please.
Current rpmdrake architecture can't make use of different media
for a single package-version-release :/.
[...]
> Thank you for reading this enormous mail :) I'm not
> very good at English so sometimes it takes me more
> words to articulate my point. Anyway I hope there are
> some useful ideas here.
Thank you for your contribution and I hope that my answer is not
too frustrating.
--
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
