Hi, I am a bit confused about the direction you are pursuing.. comments bellow: > The code I'm talking about re-using involves finding hub(s) to run, > and > when a hub is picked, finding the spokes that should run with that > hub, > using the same methods of getting choices out of the spoke and into > the > ksdata, etc... Yep, that is what I would do. > Using the same hub/spoke like objects as in the GUI > seems > to work, all that's really necessary is overloading some functions > and > classes to replace gtk calls and glade file loading with something > more > appropriate for text. > I have some code mostly working. I've replaced the window.show_all() > function with something that just spits text onto the screen, and > just > commented out a the Gtkmain() calls so there is no real user control > right now. It just finds the spoke(s) and displays them, along with > the > associated ksdata. Wait a minute, what is the hierarchy here? Are you inheriting the TUI classes from the GUI stuff? > I'm nearly to the point where you can call > run-hub.py with a text hub and have it do something sensible there > too. > I'll post code in a little bit, maybe next week and we can look at > all > the overloads and code duplication to see if refactoring some of the > ui/gui/ stuff makes sense. > If I got this correctly and you are using the GUI as a base for textual interface I tried to do it the other way. Creating (or improving) a common base classes for GUI and TUI to inherit from. You can see the work in progress here on the newtui branch: http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/ (once fedorapeople refreshes it) or git clone git://fedorapeople.org/~msivak/anaconda.git It is probably not working atm, but I am also getting close :) Martin _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
