[PATCH] Text based UI framework core

Martin Sivak msivak at redhat.com
Wed Jul 25 09:47:56 UTC 2012


Well,

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.

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).

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.

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).

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.

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.

Martin

----- Original Message -----
> On 07/24/2012 08:47 AM, Martin Sivak wrote:
> > Hi,
> >
> > this is an attempt to implement basic line only textual
> > UI framework for us to use.
> >
> > It is condeptualy designed as stack of screens, where
> > the screen at the top is visible.
> >
> > Individual screens can be implemented using the UIScreen parent
> > class and two methods: show and input
> >
> > Active screens can (according to user input) be changed in four
> > ways:
> >
> > - new screen is put onto the stack and the old one is
> >    replaced (Next button equivalent)
> > - new screen is put onto the stack (Hub wants to show
> >    Spoke with the possibility of direct return)
> > - new screen is displayed and the call returns to the
> >    caller after it is closed (Dialog with data)
> > - screen is closed (and the next item from the stack is
> >    displayed)
> >
> > This means that the leaves (Spokes) do not have to know which
> > screen they should return back to.
> >
> > There is no global dispatcher list in this architecture. If you
> > want to setup inital list of linear progression screens, use the
> > App.schedule_screen call.
> >
> > I also included two "widgets" for us to structure the screen space
> > without using scrolling or curses. Text and Column. Widgets first
> > render to their internal buffers to determine size and the parent
> > then copies the "image" to it's own buffer space.
> >
> > You can see the very simple examples of use at the ends of
> > individual files.
> 
> Well it certainly is a lot of code.  Do we really want to maintain
> this
> much code, code that is different from the graphical UI?  The more I
> think about this, the more I feel that text mode should be the barest
> minimum to get bits put on disk and a machine booting.
> 
> Maybe this much code is needed to get stuff on screen, maybe not.
> 
> --
> Jesse Keating
> Fedora -- FreedomĀ² is a feature!
> 
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/anaconda-patches
> 


More information about the anaconda-patches mailing list