On 01/09/2012 05:43 PM, Máirín Duffy wrote:
On Mon, 2012-01-09 at 17:20 +0100, Radek Vykydal wrote:
- Not sure where exactly does this belong, IMO it should be normal spoke,
perhaps accessible directly from some places (repo setup, network storage).
I think if we don't automagically grab an IP from DHCP without prompting
the user after the very first (language selection) screen, then the
network screen should pop up there, but should also be accessible later
for tweaking in the main hub (hub #1 / pre-install hub.)
This sounds good to me. I was thinking about easy flow in those
cases:
- no network -> adding repository -> need network configuration
- no network -> adding network storage -> need network configuration
but it should be doable easily, nothing I need to know now (be it going
back to hub with assumption of obligatory pre-hub pop-up of the spoke,
or shortcut to network spoke from sw source spoke or advanced storage
spoke or whatever we'll find the best).
- UI (xml) is taken from gnome-control-center in this first shot.
I can work on getting close to Mo's mockups, but
1) I'd prefer the UI to look the same as the system,
What do you mean? System = desktop version of it?
I mean gnome-control-center (I'm not aware of many other GUIs
for network configuration, this seemed like most common/used)
You put it better in a recent email, to qoute you:
So the background of the before mockup is that it is a direct copy of
the GNOME control center keyboard layout dialog. For a lot of the
screens in the UI redo, there's a lot of copying of the GNOME control
center dialogs because we have a theory that having consistent pre- and
post-install configuration will make it more usable, rather than having
users learn a different interface for pre- and post-install.
2) we (rhel) will need functionality of NM Connection Editor (Configure button)
additionaly to basic ipv4 ipv6 config from the mockups (e.g.
Routes... -> Use this connection only for resources on its network, vlan configuration,
802.1 X Security configuration, ...)
3) we'll keep more code (nm-c-e) shared this way.
Okay this is a good point. Are these something you get for "free" by
using the shared code?
Yes, the GUI configuration of stuff from 2) is (or will be? - vlan
support is
feature that has been added recently to NM) in nm-c-e. By using the shared
code I mean running nm-c-e which is run by [Configure] button in the
spoke I sent.
The difference is that we used to run complete nm-c-e with list of all
connections/devices,
here the nm-c-e is run for specific connection (selected in the device
and ap list)
so only the specific part of nm-c-e UI appears.
I can imagine adding gobject introspection to nm-c-e so that we
don't have to call the standalone nm-c-e app, but calling it is exactly
how g-c-c does it and it seems to be working quite good.
- Wireless configuration requires nm-applet as Security Agent (or writing our own)
Adding nm-applet to image is not easy - I tried it some months ago and it requires
quite a lot additional stuff - dbus, console kit... I could try to find my notes on
it if needed but I'd prefer using nm-applet atm (again - shared code).
- I am thinking about adding Proxy configuration in similar way as in g-c-c.
Proxy is weird because you potentially have two different ones? (Is that
right?) A proxy to connect to the system that has the installation
content vs a proxy the system will use post-installation to have a full
internet connection? (Those could be two different networks, right?)
I am not sure myself, I need to look at it but yes, it seems like global
proxy setting (gnome-thing?, environment variable setting?) and setting
for yum (per-repo).
The mockups definitely don't handle proxy right but I'm not sure the
best way to do it. It does make sense to have it as an item in the
network UI though. I don't know whether or not we should pull it from
the 'installation source' screen as well?
Referring to https://bugzilla.redhat.com/show_bug.cgi?id=753953
perhaps the proxy configuration in network screen could serve as global
proxy
setting (would be feature added to anaconda) and the UI in source as
per-repo
yum setting that can override it (what we support now), so it should be
kept there.
I need to think about what would be actually affected by such a global
setting
during installation, how could it be mirrored in kickstart and boot options,
and if/how it is transferrable as configuration of installed system.
Offhand it seems that it would serve just as global value for all used repos
overridable per-repo.
So I think the proxy setting in network spoke is something that can be added
later and the proxy configuration should be kept in source spoke.
Thanks for your comments,
Radek
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
