[Paste] Interest in optional urwid UI for paste create?

[Rob Lanphier]

Hi folks,

I recently wrote a demo of the Urwid text user interface library (http://excess.org/urwid ) for purposes of giving the most basic of introductions to the library at a local conference (LinuxFest Northwest).  My demo was about providing a nicer UI for the 'paster create' command.  The source code for that demo is here:

http://bitbucket.org/robla/urwid-demo/

I decided to take a look at the paste script source code to see how tough it would be to integrate.  Here are some initial thoughts and assumptions:

Assumptions:

*  Urwid support would need to be optional, and gracefully degrade back to the current behavior if urwid isn't installed.

*  The API can't break backwards compatibility, since there are projects that use paste script as a library for template creation.  In particular, the behavior of Command.challenge() would need to remain, and return the user-supplied value immediately

Thoughts:

*  Create a new UserInterface class type, and two new implementations of that base class (BasicUI and UrwidUI)

*  Instantiate a UserInterface in Command.run(), and save the instance as a property of Command

*  Pass through calls to Command.challenge() to UserInterface.challenge().  This always synchronously returns the result of the challenge.

*  Implement a new Command.queue_challenge() method.

*  Implement Command.present_challenge_queue(), which returns the list of responses from the queued challenges.  This would be implemented in BasicUI by merely calling UserInterface.challenge() on everything in the queue, but would be implemented in UrwidUI by presenting the list of questions in a single form.

*  Modify Template.check_vars() to call queue_challenge and present_challenge_queue rather than calling challenge.

That last step would have the effect of presenting a screen somewhat like what I'm showing in the attached screenshot when used with basic_package.  One nice thing about Urwid is that it's very good at multi-line forms, inserting rows as necessary to accommodate longer text, and providing scrolling when the form size exceeds the given screen real estate.

I may tackle this if there's interest in incorporating the code, if I end up having the time, and if it appears that I'm on the right track.  If someone else wanted to take my idea and run with it, I'd be quite happy with that, and provide whatever help you'd need.

Thoughts?

Rob

--
You received this message because you are subscribed to the Google Groups "Paste Users" group.
To post to this group, send email to paste...@googlegroups.com.
To unsubscribe from this group, send email to paste-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/paste-users?hl=en.

[Ian Bicking]

Ideally you could look at all the defined variables and then process them kind of as a group.  I guess urwid would ask them in order(?) similar to the current querying, but... well, no need to stick with that, and other frontends often want to ask all questions at once.  So long as all variables are filled, nothing will get asked.

Ideally the Template classes wouldn't be implementing the question-asking, it was kind of an expediency that got into the code at some point.  Really it'd be best to inspect the class from outside, as that keeps the code for questions more separate from the code for the templates themselves.

--
Ian Bicking  |  http://blog.ianbicking.org

[Rob Lanphier]

Hi Ian,

Thanks for the response.  I started to reply yesterday, and then I figured I might as well start writing some code and trying some things out.  I started up a patch queue on bitbucket which you can see here:

http://bitbucket.org/robla/paster-urwid/overview

I'm still working on it now, so it may change some more before I'm done.  Also, this is my first time using Bitbucket's patch queue feature, which I'm sensing is still a work in progress for them.

I think I'm heading more in the direction you're hoping I would go as I understood from your mail, but probably not as far as you'd like.

Here's what I've got so far, and how it's different/same than what I initially proposed.:

*  (same) Create a new UserInterface class type, and two new implementations of that base class (BasicUI and UrwidUI)

*  (same) Instantiate UserInterface in Command.run(), and save the instance as a property of Command

*  (same) Pass through calls to Command.challenge() to UserInterface.challenge().  This always synchronously returns the result of the challenge (for backwards compatibility)

*  (different) Implement a new Command.challenge_set() method, and encourage others to use challenge_set in place of challenge where appropriate.   This is still implemented in BasicUI by merely calling UserInterface.challenge() on everything in the set, but is UrwidUI by presenting the list of questions in a single form.

*  (different)  Modify Template.check_vars() to call challenge_set rather than calling challenge.

*  (different) Move var and NoDefault definition into a new "pastevars.py" file to avoid an import cycle

The thing I'm not planning on doing (which I think you might be suggesting (?)) is moving all of the substantial check_vars logic out of Template.  It looks like there's potential for productively shifting that code elsewhere, but looks like it could be done independently of this work, and I don't think anything I'm doing makes that harder.  In fact, creating pastevars.py seems to make it easier.

I'm planning on messing around with this a little while longer and see how far I get before other obligations impose themselves.

Rob

[Rob Lanphier]

Hi Ian/all,

All done (for now).  I've simplified it down to two patches, which are in my patch queue:
http://bitbucket.org/robla/paster-urwid/src

Here's direct links to the patches:
1.  01-add-basicui-abstraction.patch
Moved many user interface elements into new 'ui'/BasicUI submodule
http://bitbucket.org/robla/paster-urwid/src/tip/01-add-basicui-abstraction.patch

2.  02-add-pasteurwid-ui.patch
Added new Urwid text user interface
http://bitbucket.org/robla/paster-urwid/src/tip/02-add-pasteurwid-ui.patch

As written, the Urwid UI is off by default.  A new "--gui" command line switch is added to enable it.  While "gui" is perhaps a misnomer in this case, the idea is that eventually there could be several different GUIs (e.g. PyObjC, Gtk, Qt, WxPython, WSGI+browser), and the switch would indicate a desire for paster to pick the most appropriate one based on available libraries or explicit preference.  Eventually, one would expect the switch to be on by default, but I figured it'd be better to put the first version out in the wild off by default.

Let me know what you think.

Rob