> - Not sure where exactly does this belong, IMO it should be normal spoke, > perhaps accessible directly from some places (repo setup, network storage). We've talked about two different places: First, there's off the first hub (where it's a NormalSpoke). Second, we'd talked about putting it as a StandaloneSpoke before you even get to the first hub. However, I don't remember how we decided that should work with also attempting to get a DHCP lease in the background as soon as anaconda starts up. > - Needs some cleaning, e.g. moving signal connection to populate() and glade > file, using _grabObjects Note that you won't be able to add signals in glade if the handler takes extra data, due to a bug in glade. _grabObjects is not strictly required. I don't define it in the base class and only use it in one or two places. I simply got tired of adding things to the __init__ method. > - Written using NetworkManager gi (libnm-glib), due to some errors also > still requires NM dbus api at some places. Apparently gi haven't been used > much yet, moslty by sugar AFAIK. (I filed some NM bugs). Writing access point > selection combobox as C anaconda-widget could be considered. Good. No one should hesitate to file bugs on this kind of stuff. If people are positioning their code as what the system should be using, we're doing the right thing by filing bugs as we come across them. If you point me at the WAP combo, I can take a look and see if we really want it as a custom widget. > - 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). Yeah we definitely don't want to write our own. We should have dbus and ConsoleKit in the image already, though. I'll comment on stuff in the patches in a few minutes. One thing I'm a little concerned about here is that it's a good bit of code imported from elsewhere and we are going to drift away from that initial source as time goes on. That could be bad, in that slight behavioral discrepancies will creep in. It could also be good in that we could use this as a basis for a modified anaconda-specific config tool. Also, do we need to think about attribution and licensing here, given that someone else wrote so much of the UI stuff? - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
