>> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
