-
simonh
TKInter is a desktop GUI module that accepts mouse input, while the iPhone is a touch based UI. This means there are some interactions and gestures that don't map across between them. For example the phone interface has no analogue of right-click or click-and-drag. Similarly the desktop interaction model has no analogue of a long-press or swipe.
You can arbitrarily try and assign mappings between some of these, so you could say long press equals right-click, but that might work fine in one application but poorly in another in which long-click might need to be used for another gesture such as to select something for drag-and-drop. No one mapping will work for every application, but at the framework level to make something portable you'd need to have fixed mappings.
Then you have the issue that the phone doesn't have a concept of floating windows, re-sizable windows, overlapping windows, floating dialogs and menus, scroll bars and many others. How do you do shift-click or control-click on a phone? Conversely on the phone you have conventions like swiping from the edge of the screen and multi-touch gestures. There are very good reasons why even Apple's own OSX GUI framework was not ported directly to iOS.
It is possible to write UI toolkits from scratch that are designed to map across between touch and desktop paradigms. The way to do this is to identify a subset of gestures and interactions in both models and creating strict mappings between them at the toolkit level. This gives you the portability, but at a cost of sacrificing the ability to use interactions that can't be deterministic-ally mapped to the other platforms. Unfortunately TKInter wasn't designed in terms of sacrificing desktop GUI capabilities in order to make the subset portable to phones, so it has a lot of GUI paradigm interactions and display widgets included that don't port over.
-
simonh
@omz I've been thinking about picking up Working Copy but not sure how well it works with Pythonista. If it had really solid integration I'd be perfectly happy for you to hand off the details of the git client implementation to them and keep your focus on actual Pythonista feature development and core platform service support such as iCloud sync. That's a perfectly reasonable line to take IMHO.
-
simonh
Direct GitHub synchronisation? That would be a real game changer for Pythonista.
-
-
simonh
Just as a precaution, I regularly use the export function to mail myself a zip archive of my working folder. I've never needed to use it yet, but it gives me peace of mind.
-
simonh
Are there any plans to implement this? I'm writing a mapping utility for a science fiction game and this would be a very valuable feature.
-
simonh
Heres a code sample. If you comment out the three lines creating and adding the label the view looks fine. I need to add subviews because I'm trying to create a grid-style table of labels and values.
import ui class MyTableViewDataSource (object): def tableview_number_of_sections(self, tableview): # Return the number of sections (defaults to 1) return 1 def tableview_number_of_rows(self, tableview, section): # Return the number of rows in the section return 3 def tableview_cell_for_row(self, tableview, section, row): # Create and return a cell for the given section/row cell = ui.TableViewCell() #cell.text_label.text = 'Foo Bar' # uncomment to switch behaviours label = ui.Label() # comment out to switch behaviour label.text = 'mylabel' # comment out to switch behaviour cell.add_subview(label) # comment out to switch behaviour return cell data_source = MyTableViewDataSource() tv = ui.TableView() tv.data_source = data_source mv = ui.View() mv.add_subview(tv) mv.present()
-
simonh
That does the trick in the example. I can't use it directly in the real code because I'm putting several labels into the cell, but it should just be a matter of calculating the required frame geometries for the labels. Thanks!
- update. The workaround works fine for my use case. I set the label frame to the cell bounds, then offset .x and .width as required. Looks perfect!