On Thu, 2012-07-26 at 16:08 -0400, Martin Sivak wrote: > > I don't think it is possible to make the whole hub/spoke abstract and > just switch the rendering library because the screen structure will > very probably have to be different. > > I was thinking just about abstracting the logic pieces we have there - > code to get/enable ntp, get current keyboard, check repositories.. and > then using those pieces to create separate TUI specific hub & spoke > code. > > Can you elaborate of your approach a bit more? So I can think about it > too? > > Because from what I saw in the GUI code, we cannot use the Gtk main > loop, screen management is different and the only common piece of API > there is are the status and completed methods. The rest is already too > GUI specific (glade stuff, widget and gtk data manipulation...). 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... 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. 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. -- Jesse Keating Fedora -- Freedom² is a feature! _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list