On Tue, 2007-08-28 at 00:23 +0530, Debarshi 'Rishi' Ray wrote: > >> 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. That's pretty confusing, though, and not that good from a UI perspective. What does it mean if I have [ ftp ] [ http://some.site.com/path/to/foo ] It's very ambiguous. It's far better to only give one way to do it rather than two at one > > 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. Media is entirely separate from URLs -- you want to be specifying media by using the mediaid bits and not at all with the baseurl. Remember, if they set up a repo with a file:/// repo, it needs to _always_ be there. Or they're going to get into cases where their updates break. > > 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? Yep. > >> 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: Okay, this makes some sense. Although we could just have that handled under the covers and still let you just select between mirror url and a baseurl. But that would get a little weird switching between them I guess. I still think you're going to want to allow a radio button between the two. Because you can also disable the baseurl (in fact, that's the default config). Maybe we just make the baseurl and the mirror url both handled like the gpg key above. > >> 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. GPG keys I can fully see it. Given that our _default_ setup is for users to be using a mirrorlist, I really don't think that we can hide them as being "advanced". Which is why I think radio button between the two is going to work the best. Otherwise, the user will go to edit the Fedora Updates repo and see [ ] Base url [desensitized url] v Advanced or we have to expand advanced by default, which doesn't really help either. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
