Forum Archive

I would love to see tabbed editing implemented in the native pythonista editor, but in the meantime I've come up with a work-around. Tabs is a sidebar that allows you to add the current file as a tab (it will ask you to name the tab). There are probably better ways to do some of these things (I'm still learning a lot about programming), but it works. There are still some things that could be improved, so I welcome advise and tips for improvment. Feel free to improve it yourself (and share it back).

Just to note: this app will create a database file to store your tabs in. This allows you to close it and resume your session later without losing your tabs. It's meant to be in your actions list, so you can quickly reload your tabs. If you move or delete a file one of the tabs is referencing, it will throw it off. Just delete the database file and rerun it. I may try to fix this in the future.

Interesting. Nice job with the UI, the tabs look like actual tabs. A few suggestions:

1. Instead of prompting for the path when adding a tab, how about always adding the currently open file?
2. It might be easier to use a list (array) or a dict to keep the tabs, and store it using JSON. Personally I find the json module very easy to use, it provides methods to quickly encode/decode to/from JSON. As the number of tabs will probably never be very high, the performance difference between JSON and SQL should be minimal.

If you're interested, I tried making something similar a while back. It's not very fancy or anything, but you can find it here: http://github.com/dgelessus/pythonista-scripts/blob/master/wannabetabs.py

@smath, very cool!

A small suggestion: you could try to add little close buttons on each tab. It will be much easier to close them (you won't have to switch to that file to remove the tab).

P. S. Also, you should make it so newly added tab gets highlighted automatically (now you have to press it to make it orange). Sorry if explanation is not very good

I just uploaded an updated version (and the original link has bee updated).

@dgelessus - I implemented your first suggestion. I may eventually look into switching to JSON, but right now I'm more focused on functional issues.

@ShadowSlayer - Thanks for the suggestions. They've both been implemented. There can still be issues with tab coloring, but I don't know if I can get rid of them, short of running a loop to check the current open file. There's no other way for me to know if another file was opened in the main navigation bar from what I can tell. I may abandon the coloring altogether.

Update: I have worked out some more bugs since the last upload. These include:

• if you delete, rename, or move a file after creating a tab for it, and try to use the tab, you will be notified and the tab removed.
• More tab color fixes
• Other minor changes to make it act more reliably

The only other change I'd like to make before calling it complete has to do with the close button on each tab. When long file names are used it conflicts with the close button. Is there a way to give bounds to the button title to keep this from happening?

The only thing I can think of is to put the close button (just the image) at a fixed point, and use a label for the file name which you could adjust how wide you want the boundaries.

I've tried to adapt this for Editorial, but there is no editor.open_file() function I suppose. So, everything shows up, but I can't open the file of the tapped link. Any other functions I could use?

You may be able to use the custom url scheme to open a file.
http://omz-software.com/editorial/docs/ios/editorial_urlscheme.html

Wow. Can't believe I didn't think of that. Yes, a URL scheme should work just fine. Thanks JonB.

I haven't dug into the script, but is there a simple way for the tabs to remember where the "cursor" was the last time its file was "on top". Would make jumping between files to compare sections very useful.

I'm fairly certain thath there are methods like get_selection and set_selection in the editor module, those should be easy to integrate.

get/set_selection() would be good. How would you easily force the displayed screen to put the selection mid screen. Setting the selection does not "scroll" the window.

See the force_scroll method here

The key line is the last.... If you call replace_text, the editor will scroll. Calling setting the start and end offset the same, and using an empty string ensures you don't actually change anything, but the editor scrolls just the same. The part that is hard to control is where the offset ends up on the screen. I believe there is a way by scrolling twice to have a little more control, (I.e overshooting, then backing up, as it does depend on the direction you are moving)... But this code just tries to keep a little context on screen.

By the way, not sure if smath ever publicized it, but this repo is an integration with his awesome Tabs with [editmenu] (https://github.com/jsbain/editmenu) one button block comment/uncomment, block indenting, cut,copy,paste, and execute the selected block in current interpreter session). Smath also added find and replace functionality, which makes this a sweet little package.

By the way, I had considered this in the past.... While it would be easy to save/resume the position when switching from the tab itself, we don't have any way to trigger an action when opening a file from the usual pythonista browser.. I guess the main use case would be switching back and forth between two files, so maybe that's ok. An alternative would be to poll the editor's file name and line number periodically, and update the database. I'm not sure if the editor sidebar and main ui run in different threads, if not there would be some risk of freezing.

editmenu with Tabs has now been updated to include saving of last selection/cursor location, and restoring it when switching tabs!

Also, I converted Tabs over to a class to fix problems with namespace collisions in some cases.

Also, the previous editmenu/Tabs mashup didn't keep the tabs database in a fixed location, resulting in lost tabs when running from action menu.
Now it does.

As an aside, I switched over from sqllite3 to shelve, because well it is easier for me to understand! This makes future enhancements easier, also, otherwise there has to be a lot of logic to add new columns, etc.

Where should this get installed. I getting a lot of file not found errors for the components (pyui and py files)

You should download all files into one folder, but the specific location shouldn't matter... Mine sits in an editmenu folder off of the ~/Documents folder. Use GitHubGet, gitview, or your favorite git manager to download. You should run editmenu.py first, that's probably the most tested, everything else is accessible from the buttons

JonB - I just downloaded the current version from github and am getting an error:

Traceback (most recent call last):
  File "./Tabs.py", line 78, in move
    self.sv.subviews[i].y -= self.tab_width*1.05
NameError: global name 'tab_width' is not defined

I've even changed the reference to self.tab_width to be self.width, and get the exact same error.

Any ideas?

Whoops, my bad. Apparently when I tested this, I had the global tab_width still in the namespace, so the code appeared to work. I just checked in an update...

Actually, I'm a little confused by the traceback, since it implies tab width was a global, instead of an attribute of self (the fix I checked in added a self to that line where there was none before)

I checked with a fresh pull, so try again?