On 10/20/2010 05:56 PM, David Cantrell wrote:
This is probably the most often complaint I hear from users. I know
the UI is
still needing some work, but keep in mind that we need to be able to
handle
any number of NICs on this screen. A list box with a treeview will most
likely be necessary because I do not see any other way to do it.
Yep, I'm aware of it.
Configuration + wifi:
http://rvykydal.fedorapeople.org/wifi.png
This probably needs more work, but I question the value. There is a
lot more
to wifi settings than just the access point. Plus, if we expose the
access
point list here, we will definitely be asked to expose many other
settings.
This is because without ESSID specified in ifcfg file, nm-c-e doesn't
find/show any connections. I asked Dan Williams why in email.
I guess that on desktop it works because there is also another configuration
source than ifcfg file.
3) If we had any step-persistent piece of UI (like systray in desktop)
we could
have icon there.
It does sound like a crazy idea, but why not run a panel that can hold
nm-applet? Not necessarily gnome-panel, but something like fbpanel or
another
small applet-holding program.
I think it's worth investigation.
* "activate on boot" checkbox:
It deals with bug https://bugzilla.redhat.com/show_bug.cgi?id=498207 -
Device
is not activated automatically after reboot for media installs. I
added another
checkbox "activate on boot" for it. Although there is "Connect
Automatically"
checkbox in nm-c-e to achieve this by setting ONBOOT ifcfg value, we
can't use
it reasonably in installer (as opposed to desktop) because here ONBOOT
is used
to bring devices up/down (and checking the nm-c-e checkbox can bring
the device
up as a side effect). Also with the new "activate on boot" checkbox on
network
screen it is clear what our default is (currently it is quite unloved
"no").
'activate on boot' should mirror the ONBOOT setting for the device.
This is
what we used to do before we moved to NetworkManager.
As I said, with NetworkManager ONBOOT has a side-effect, per Dan Williams:
<cite>
4) NM_CONTROLLED=yes + ONBOOT=yes : NM manages device, and whenever the
device is available (ie, has carrier/link) NM will activate it using the
connection details from the ifcfg
</cite>
Also we used to have complete control over the ONBOOT setting, but with
nm-c-e we've lost it.
Having the setting stored elsewhere, we can set ONBOOT value
of ifcfg files of target system at the end of instllation
without the side-effect of activating the devices, which we can't
do with nm-c-e's "Connect Automatically" checkbox. Also using
"Connect Automatically" would need to be documented, whereas
the new checkbox is just visible. (Additionally we can ask
at the end of installation if we detect all devices having
ONBOOT=no).
As for mirroring of 'activate on boot' and ONBOOT, I'm for the:
ONBOOT (which means active in installer) => 'activate on boot',
but I don't want to require the opposite:
'activate on boot' => ONBOOT (= active).
For users doing non-network installs, the complaint we hear a lot is
that the
network is not configured once they reboot. Another option might be
to check
for an active link for non-network install methods and encourage users to
configure the network interface before completing installation (e.g.,
"I see
you have an active network link, would you like to configure it?").
The devices should be always configured to a default which is
ipv4 dhcp (there were a bug for minimal install, fixed in F14).
I think the complaints were because of almost invisible
[Configure Network] button, but with proposed network screen
users won't miss their opportunity to configure the network and
I don't think any encouragement is needed. It can be seen as another
useless bothering dialog. And if we encourage, we should probably
do it right on the network screen.
Also I am wondering how we would know whether a device was configured
by user (global flag? :/ ... what if it was configured in stage 1?
examine ifcfg file? :/ ... dirty and fragile)
Thanks for your comments.
Radek
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
