On 07/26/2012 02:11 AM, Martin Sivak wrote:
Hi,
Lets move this to devel list so others can comment too.
That's fair. I really don't know how many of those spokes we can
actually do in text mode given the constraints though.
So the current info I got from David is that we are required to have
full featured text mode. We can do spokes which consist of more
linear screens though to make up for the lack of screen space.
Yeah, I somehow glossed over that in the initial email about it. Whoops.
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/.
I agree and we should be able to separate the UI agnostic parts to
some kind of common/ abstract classes and then inherit from those for
GUI and TUI cases.
that's what I'm working on now, getting the hub/spoke framework in place
so that you can plug in the presentation part.
I agree that columns are a bad idea. Particularly when you start
throwing translated strings into those.
Well not really, this might still work, try the example code I did
yesterday (I am attaching it again, since you probably missed it on
devel list). I do not plan on adding much more widgets now, but what
is there can actually do columns pretty easily and it will work even
on dot matrix printer with translations in place :)
Ok, I'll trust you on that :)
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().
That is the idea behind App and UIScreen classes. I am reading input
using raw_input so no single keypresses at the moment, but that might
be easily changed.
There is one more issue coming up, how do handle textual/numeric
input? Can we use readline on s390? Or maybe use readline only where
it is supported? Does anybody know how does that work on those dumb
terminals?
Not a clue.
--
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
