Pirut: Edit -> Repositories mock-up -- Part 3.

[Debarshi 'Rishi' Ray]

>> Maybe add a protocol combo box to baseurl & mirror list to select
>> 'http://','ftp://','file://','media://' etc. and only show the file
>> dialog button if 'file://' is selected.

> The problem is that this ends up making it so that you can't just cut
> and paste URLs, etc.

Not really. If the user selects a protocol we simply put the protocol
prefix (say ftp://) in the text input box. The user is free to ignore
the protocol dropdown and directly copy-paste a string into the text
box, since we finally treat the contents of the text box as the
canonical input immaterial of whether the protocol box was used or
not. That way the user may not even use the FileChooserButton but
copy-paste something like file:///path/to/repo in the text box.

> Remember, this is
> for *end users*.  End users aren't going off and creating repos with
> createrepo locally; they're pointing at repos they find on the web.

That is too simplistic. Imagine a case where you distribute a snapshot
of the Fedora repositories on offline media to network starved end
users. They do not need to run createrepo since that part is already
done by the person who distributed the snapshots. But the end user
still has to add the custom repository on his system. A protocol
selector, a FileChooserButton can come helpful in those cases.

Recently I am coming across a growing number of such use cases-- end
users who are having to add custom repositories distributed by more
experienced and fortunate people.

> Rather than hiding entries (and thus having dialogs changing size), it's
> probably better to group the similar things together.  eg, (bad ascii
> art alert :)
>
>    [ ] GPG Check  [_____________]
>
> And then you can just desensitize the text entry if the checkbox isn't
> selected

Good idea. We can do the same thing with the mirror list too, isn't it?

>> Maybe a radio button to select between baseurl or mirrorlist, it is
>> not the common case to use both at the same time.

> Yeah, this is probably the better idea for mirrorlist handling.

My initial idea was to input and use the mirror list _only_ if the
mirror list checkbox was chosen and otherwise use the baseurl. However
this does not consider the case where the .repo file looks like:

[fedora]
...
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7.90/Everything/i386/os/
#mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-7.90&arch=i386
...

For the occasional case where you want to comment out the mirrorlist
and use the baseurl, and yet not lose the mirrorlist, the user can use
the Edit Repository dialog to turn off the mirrorlist. The program
would ensure that the mirror list line is not deleted but commented
out.

The reasoning is that when you are creating a repository, and you know
there is a mirrorlist, you usually want to use the mirrorlist. You
want to turn off the mirrorlist only when the mirrors are temporarily
unavailable (say they are syncing), but that is usually a one-off
situation possibly best handled by editing repository after it has
been added.

What do you think?

>> Maybe crete a Notebook with the basic stuff on one page and the
>> advanced on another page.

> Given that we're not talking about a lot of things (gpg key is the only
> one right now afaik), an expander is probably better.  And really, with
> just one, it may be better just to always show it.

GPG keys and mirrorlists are all advanced. When a end-user adds a new
repo manually (ie., not through a RPM package or a pre-written .repo
file), he would want to enter the minimum amount of information
possible. Also if there is a repository which does not have a mirror
list or gpg checking facility, and we directly expose those fields,
the newbie may get confused.

Regards,
Debarshi
-- 
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu