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.
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.
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 :)
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?
Martin
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.
Hi,
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 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...).
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.
Guys? Any ideas?
Martin
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.
On Thu, 2012-07-26 at 13:45 -0700, Jesse Keating wrote:
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.
Ok, I have a video of what this looks like, code will come soon.
http://jkeating.fedorapeople.org/texthub.ogv
On 07/26/2012 04:38 PM, Jesse Keating wrote:
On Thu, 2012-07-26 at 13:45 -0700, Jesse Keating wrote:
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.
Ok, I have a video of what this looks like, code will come soon.
git://fedorapeople.org/~jkeating/anaconda.git has the code. Branch you should get from cloning that is newui-jktext
Hi,
I did take a look, but well it is a bit messy to make anything out of it right now...
And I do not like that approach much (inheriting TUI from GUI) to be honest. It doesn't make sense from logic or code point of view (or at least from my perspective), because the UI behaviour is too different. For example all the messaging stuff in GUI can be removed for TUI as we cannot change a value of anything on the screen. We simply have to print the whole screen again.
My git repo now contains refactored code which has common base classes for TUI and GUI and has the GUI working again. But for the text UI there are specialized set of classes using as much common code as possible but omitting all the stuff which does not make sense there.
I will add the documentation and some unit tests as time allows.
web: http://http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/ git: git://fedorapeople.org/~msivak/anaconda.git (newtui branch)
Martin
----- Original Message -----
On 07/26/2012 04:38 PM, Jesse Keating wrote:
On Thu, 2012-07-26 at 13:45 -0700, Jesse Keating wrote:
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.
Ok, I have a video of what this looks like, code will come soon.
git://fedorapeople.org/~jkeating/anaconda.git has the code. Branch you should get from cloning that is newui-jktext
-- Jesse Keating Fedora -- Freedom² is a feature!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 07/30/2012 05:53 AM, Martin Sivak wrote:
Hi,
I did take a look, but well it is a bit messy to make anything out of it right now...
And I do not like that approach much (inheriting TUI from GUI) to be honest. It doesn't make sense from logic or code point of view (or at least from my perspective), because the UI behaviour is too different. For example all the messaging stuff in GUI can be removed for TUI as we cannot change a value of anything on the screen. We simply have to print the whole screen again.
The point with this work wasn't to have something pretty, or even something that would resemble actual code used long term. The point was to try to re-use what code exists to show what needed to be brought up higher during refactoring. Obviously we're not going to inherit gui code into tui. But working from the direction of "what do we need" seemed logical to me, as opposed to working from the direction of "we don't know what we need".
My git repo now contains refactored code which has common base classes for TUI and GUI and has the GUI working again. But for the text UI there are specialized set of classes using as much common code as possible but omitting all the stuff which does not make sense there.
I will add the documentation and some unit tests as time allows.
web:http://http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/
I'll take a look.
On 07/30/2012 12:28 PM, Jesse Keating wrote:
I will add the documentation and some unit tests as time allows.
web:http://http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/
I'll take a look.
Can you please include a working hub/spoke so that we can see how this all interacts? that was the main goal to my work, have a hub/spoke actually working so that we can see what code was necessary. I have a text summary hub that when executed is able to find the rootpw spoke and run it, including stuffing some data into the kickstart object. I'd like to see something like that in your code set.
In my git.
Start it using make runtexthub HUB_MODULE=summary HUB_CLASS=SummaryHub
About activate method, we need to decide on when to call it. Whether everytime Spoke is closed or only if it gets closed using "back", "continue" (not there right now, but very easy to add to TUISpoke.input method).
I did password spoke as well to compare, it uses overriden prompt method to get the passwords. You would just return string from prompt() and handle the input in input() in standard NormalSpoke.
Martin
----- Original Message -----
On 07/30/2012 12:28 PM, Jesse Keating wrote:
I will add the documentation and some unit tests as time allows.
web:http://http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/
I'll take a look.
Can you please include a working hub/spoke so that we can see how this all interacts? that was the main goal to my work, have a hub/spoke actually working so that we can see what code was necessary. I have a text summary hub that when executed is able to find the rootpw spoke and run it, including stuffing some data into the kickstart object. I'd like to see something like that in your code set.
-- Jesse Keating Fedora -- Freedom² is a feature!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hi,
For everybody not wanting to test the code himself, here is the output of running the test Hub and password Spoke using our run-hub tool:
[msivak@office68 tui]$ make runtexthub HUB_MODULE=summary HUB_CLASS=SummaryHub ANACONDA_DATA=/home/msivak/Work/anaconda/tui/data \ ANACONDA_INSTALL_CLASSES=/home/msivak/Work/anaconda/tui/pyanaconda/installclasses \ PYTHONPATH=.:pyanaconda/isys/.libs:widgets/python/:widgets/src/.libs/ \ LD_LIBRARY_PATH=widgets/src/.libs \ pyanaconda/ui/tui/tools/run-hub.py summary SummaryHub dm.c: 1693: not running as root returning empty list Running hub <class 'pyanaconda.ui.tui.hubs.summary.SummaryHub'> from <module 'pyanaconda.ui.tui.hubs.summary' from '/home/msivak/Work/anaconda/tui/pyanaconda/ui/tui/hubs/summary.pyc'> Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-bluesky&arch=x86_... error was No repomd file Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-fbluesky&am... error was No repomd file ================================================================================ ================================================================================ Install hub
1 [ ] Set root password (Password is not set.) Please make your choice from above ['q' to quit]: 1 ================================================================================ ================================================================================ Set root password
Please select new root password. You will have to type it twice.
Password: Password (confirm): Passwords do not match! ================================================================================ ================================================================================ Install hub
1 [ ] Set root password (Password is not set.) Please make your choice from above ['q' to quit]: 1 ================================================================================ ================================================================================ Set root password
Please select new root password. You will have to type it twice.
Password: Password (confirm): ================================================================================ ================================================================================ Install hub
1 [x] Set root password (Password is set.) Please make your choice from above ['q' to quit]: q ================================================================================ ================================================================================ Question
Do you really want to quit?
Please respond 'yes' or 'no': no ================================================================================ ================================================================================ Install hub
1 [x] Set root password (Password is set.) Please make your choice from above ['q' to quit]: q ================================================================================ ================================================================================ Question
Do you really want to quit?
Please respond 'yes' or 'no': yes Hub kickstart fragment: #version=DEVEL # System timezone timezone # Root password rootpw --plaintext aaaaa # Installation logging level logging --level=info
Martin
----- Original Message -----
In my git.
Start it using make runtexthub HUB_MODULE=summary HUB_CLASS=SummaryHub
About activate method, we need to decide on when to call it. Whether everytime Spoke is closed or only if it gets closed using "back", "continue" (not there right now, but very easy to add to TUISpoke.input method).
I did password spoke as well to compare, it uses overriden prompt method to get the passwords. You would just return string from prompt() and handle the input in input() in standard NormalSpoke.
Martin
----- Original Message -----
On 07/30/2012 12:28 PM, Jesse Keating wrote:
I will add the documentation and some unit tests as time allows.
web:http://http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/
I'll take a look.
Can you please include a working hub/spoke so that we can see how this all interacts? that was the main goal to my work, have a hub/spoke actually working so that we can see what code was necessary. I have a text summary hub that when executed is able to find the rootpw spoke and run it, including stuffing some data into the kickstart object. I'd like to see something like that in your code set.
-- Jesse Keating Fedora -- Freedom² is a feature!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 07/31/2012 08:31 AM, Martin Sivak wrote:
Hi,
For everybody not wanting to test the code himself, here is the output of running the test Hub and password Spoke using our run-hub tool:
[msivak@office68 tui]$ make runtexthub HUB_MODULE=summary HUB_CLASS=SummaryHub ANACONDA_DATA=/home/msivak/Work/anaconda/tui/data \ ANACONDA_INSTALL_CLASSES=/home/msivak/Work/anaconda/tui/pyanaconda/installclasses \ PYTHONPATH=.:pyanaconda/isys/.libs:widgets/python/:widgets/src/.libs/ \ LD_LIBRARY_PATH=widgets/src/.libs \ pyanaconda/ui/tui/tools/run-hub.py summary SummaryHub dm.c: 1693: not running as root returning empty list Running hub <class 'pyanaconda.ui.tui.hubs.summary.SummaryHub'> from <module 'pyanaconda.ui.tui.hubs.summary' from '/home/msivak/Work/anaconda/tui/pyanaconda/ui/tui/hubs/summary.pyc'> Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-bluesky&arch=x86_... error was No repomd file Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-fbluesky&am... error was No repomd file ================================================================================ ================================================================================ Install hub
1 [ ] Set root password (Password is not set.) Please make your choice from above ['q' to quit]: 1 ================================================================================
I think what we want to do here is not have the checkbox [ ] next to the spoke. Instead underneath the spoke we'll have the status. Can quibble over what to enclose it with, but I like [] for the status. That way it can be blank and still make sense, otherwise have content.
Is q to quit something that will be translated?
Hi,
well the exact layout can obviously be changed. Spoke representation while displayed on Hub is defined in ui/tui/spokes/__init__.py in TUISpoke.render method.
About the translations, everything is text (including the input "commands"), so we can use standard gettext to do the right thing. The question is how do we handle special characters on dumb terminals?
Martin
----- Original Message -----
On 07/31/2012 08:31 AM, Martin Sivak wrote:
Hi,
For everybody not wanting to test the code himself, here is the output of running the test Hub and password Spoke using our run-hub tool:
[msivak@office68 tui]$ make runtexthub HUB_MODULE=summary HUB_CLASS=SummaryHub ANACONDA_DATA=/home/msivak/Work/anaconda/tui/data \ ANACONDA_INSTALL_CLASSES=/home/msivak/Work/anaconda/tui/pyanaconda/installclasses \ PYTHONPATH=.:pyanaconda/isys/.libs:widgets/python/:widgets/src/.libs/ \ LD_LIBRARY_PATH=widgets/src/.libs \ pyanaconda/ui/tui/tools/run-hub.py summary SummaryHub dm.c: 1693: not running as root returning empty list Running hub <class 'pyanaconda.ui.tui.hubs.summary.SummaryHub'> from <module 'pyanaconda.ui.tui.hubs.summary' from '/home/msivak/Work/anaconda/tui/pyanaconda/ui/tui/hubs/summary.pyc'> Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Loaded plugins: blacklist, langpacks, presto, refresh-packagekit, whiteout Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-bluesky&arch=x86_... error was No repomd file Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-fbluesky&am... error was No repomd file ================================================================================ ================================================================================ Install hub
1 [ ] Set root password (Password is not set.) Please make your choice from above ['q' to quit]: 1 ================================================================================
I think what we want to do here is not have the checkbox [ ] next to the spoke. Instead underneath the spoke we'll have the status. Can quibble over what to enclose it with, but I like [] for the status. That way it can be blank and still make sense, otherwise have content.
Is q to quit something that will be translated?
-- Jesse Keating Fedora -- Freedom² is a feature!
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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
On Fri, 2012-07-27 at 10:39 -0400, Martin Sivak wrote:
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?
er, no. The TUI classes mostly inherit from the GUI counterparts.
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 :)
I wanted to get something functional first to see what needed to be overloaded or replaced, and from that then decide how better to refactor the GUI classes. What I have doesn't touch anything outside of pyanaconda/ui/tui/
I'll post a repo on fedorapeople soon.
I think our work will likely combine.
anaconda-devel@lists.fedoraproject.org
-
Jesse Keating -
Martin Sivak