Closed dgelessus closed 10 years ago
Im ok with this as far as changes to shellista.py that would break normal operation. I have no way to test at moment. @briarfox @jsbain? Only issue I see is that it won't get installed if the user just pastes shellista.py into pythonista (we want to keep the 1-file pasting paradigm to make starting easy). Is there any way to turn this into a plugin or bootstrap it automatically so the user can run it if desired?
Are there any breaking changes to Shellista itself? As far as I can tell the only additions are two optional parameters to Shellista.__init__()
and a small change to the starting directory determination. ShellistaUI.py
is also not a required file, it is designed to be a somewhat hackish wrapper for Shellista. In some instances it is also better to use the regular console, for instance if you need reliable auto-scrolling to bottom.
If the plan would be to make this the main method of running Shellista, the script could be written a lot differently and require less runtime changes to Shellista's inner workings.
It would probably also be possible to make the UI somehow downloadable from the command line itself.
I didnt see any breaking changes either. Would it work to merge the shellista.py changes and move the UI file to shellista-core module?
Personally I like the separate tab idea. Whether it should be the main method of execution is up to general consensus. I've done a lot of huffing and puffing about keeping shellista's ability to run on any system with Python, but if I'm in the minority I'll happily let that go. Especially considering that I haven't had any time to work on it lately.
If that is possible, sure. Maybe we can put it in this repo for now and figure out an optional download system afterwards. I'm also against making this the main method of execution, at least until the scrolling issue is solved and the prompt is worked out correctly. Cross-platform compatibility sounds like a good idea, as that would allow working on the project on a regular computer, and it should be mostly possible, as we're working with a text-only interface. Although I haven't tried it yet, the iOS module dummy replacements look like they should work fine.
Im happy to add the changes to this repo for now, as long as @jsbain and @briarfox agree. Having the extra UI file there certainly won't hurt anything.
that would allow working on the project on a regular computer
That was really the main reason - I was working on it in Linux using PyCharm
I'll try out soon. Quick question, though, shouldn't we wrap all of the do_cmds in ui_in_background
? For instance I think some git module stuff called console input commands, which break if not so wrapped. It has been a while since I looked at how Cmd works, I forget if there is an easy way to force that, maybe by overriding onecmd.
I checked, there don't seem to be any UI thread hang issues - the cursor was happily blinking while unzipping an archive. Not sure if this would be any different with commands that use raw_input()
, though I don't see why it would be.
I was thinking of the git password prompt, which is a popup and I think hangs if called from ui. I'll play around tonight=
console
popups and getpass.getpass()
do indeed hang, so far I haven't found a workaround. raw_input()
behaves strangely in commands - although it doesn't hang up the UI thread, any print
s before it will only show until after the input has been entered. This includes the input prompt, which is obviously an issue.
This doesn't impact changes made to shellista.py, though, which were minimal. @jsbain any objection to accepting the shellista.py changes and hosting the UI file here? It seems to me to be pretty innocuous.
No issue.
Sent from my iPad
On Sep 4, 2014, at 11:59 AM, transistor1 notifications@github.com wrote:
This doesn't impact changes made to shellista.py, though, which were minimal. @jsbain any objection to accepting the shellista.py changes and hosting the UI file here? It seems to me to be pretty innocuous.
— Reply to this email directly or view it on GitHub.
As discussed in issue #10