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

Jeremy Katz katzj at redhat.com
Mon Aug 27 19:29:38 UTC 2007


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




More information about the fedora-devel-list mailing list