[PATCH] Text based UI framework core

Jesse Keating jkeating at redhat.com
Wed Jul 25 17:29:11 UTC 2012


On 07/25/2012 02:47 AM, Martin Sivak wrote:
> we were asked to eventually have all features of GUI also in text
> mode. I would prefer having the necessary pieces there from the
> beginning than having to rewrite half of the code to accommodate the
> complexities.

That's fair.  I really don't know how many of those spokes we can 
actually do in text mode given the constraints though.

>
> Your examples used the Hub & Spoke model and you need a way of
> returning back to the Hub when the Spoke is done. We also need linear
> progression (to move between hubs or inside Spoke screens) and two
> "dialogs" (showError and showYesNoQuestion as required by
> UserInterface base class).

This is true.  My example was just about showing the UI, not about how 
to actually code it.  As far as navigation is concerned, we certainly 
want to re-use as much of the existing ui code that's already in ui/gui/.

>
> You also used columns in your screenshots, you can do that using hand
> crafted prints, but I do not think that is something I would like to
> maintain (formatted output can break it easily) in every screen,
> especially with the stars and [ ] markers. The formatting will add to
> the complexity when you try moving stuff around (not much, but
> still..) and we might have to focus on maintaining uniform look
> more.

I agree that columns are a bad idea.  Particularly when you start 
throwing translated strings into those.

>
> This was an attempt to prepare a base classes, the UI code itself
> will be smaller thanks to it. If you drop the widgets code it is 166
> lines including comments and docs that give you mainloop with uniform
> input (and possibly error) handling and screen switching.
>
> Having this modular is some way is of course necessary, so it will
> either be a class or set of functions, because you will be repeating
> lots of code otherwise (= maintainers nightmare).

This is true.

>
> The widgets are obviously optional, but most of the code deals with
> the output limitations of dumb terminals. We can drop this part and
> use simple prints, but having a "widget" with similar API to the GUI
> hubs and spokes will probably help us refocus faster. Other teams
> will be probably writing some spokes too (ABRT, Satellite and some
> partners asked for it) so there has to be an API others can use to
> make independent screen development possible.

Agreed.

>
> Those were the requirements I was thinking about while designing this
> and I admit I am using the App/UIScreen class pair in a project of
> mine already so I am a bit biased.
>
> If you have a different ideas I am all ears.
>

I don't necessarily have something different in mind.  I am struggling 
with how to make use of this code with a real spoke.  Right now I'm 
looking at what it takes to re-use much of the code existing in ui/gui 
to setup a single text hub and single text spoke and somehow get it 
displayed.  Your code may in fact become handy there, something in place 
of Gtk.main().

-- 
Jesse Keating
Fedora -- FreedomĀ² is a feature!




More information about the anaconda-patches mailing list