Forum Archive

I am currently trying to make a calendar for a hotel booking system. I have started out by just focusing on a creating a single cell that represents a day. I did this with a class that inherits from ui.View. In that cell, I create multiple subviews for indicators in the top right of the cell as well as indicators in the bottom of the cell cell. Then writing methods in the class to manipulate the contents of the various cell/view. Also some animations within the cell also. The goal being that another class would create as many of these objects as required and position them appropriately to form something that looks like a calendar. Long intro to my main point...
Writing this small custom class, it occurs to me, how hard would be for @omz to be able to load a custom class that inherits ui.View into the ui builder, and at minimum render it and provide graphical positioning. One step further could be to offer a property page if the class had decorated properties for example. I am sure it could go further. But even the simplest implementation could lead to some nice controls/widgets being created for Pythonista in my ui.View.
I hope this is useful feedback.

https://www.dropbox.com/sh/7ueokz1zxofj2bs/AAAgeDb-paugPEpbbvEifx9Xa?preview=File+22-06-2015+18+15+06.png

https://www.dropbox.com/sh/7ueokz1zxofj2bs/AAAgeDb-paugPEpbbvEifx9Xa?raw=1

you can insert custom views in the ui builder. you can position it, and set the basic View type properties, but it is just rendered as a box.

@JonB, that sounds great. But how do I pick my custom class in the ui builder ?

Insert a normal view and set the Custom View Class in the attributes panel.

@JonB, I just see where you can do it. I feel a little embarrassed, I didn't see that before. But I think the documentation is really lacking. I Know documentation is very difficult to control and keep updated. Many years ago, Xerox charged us around 10,000usd just for our help file per language. Nothing about the content, was just the translation. But it seems to me we should have some web tools to report these things To omz. Another Example, if you look up ui.Button in the help, there are no params, but title is a param to that method. So nothing against omz, would like to report in a way that is helpful.

I wonder how many people really know what you have pointed out here. I think it's really powerful.
Thanks again.

I missed that for a long time too.

I was thinking of suggesting that omz place the source docs on github so that people can contribute -- various folks have found minor documentation shortcomings which could be easily fixed by the community (obviously the pull requests would ultimately get approved by omz).

Actually, all the docs do exist in the app -- in both html and sphinx sources. (you can find the pylib folder from os.file. I then created a hardlink to the folder to make it easier to get there from stash). Though I think the sphinx configuration files are needed to compile to html (haven't tried yet).

@JonB, is it possible to pass params to the custom class's init() function from in the ui?

omz place the source docs on github so that people can contribute

If omz is willing to do so, this would be a great idea. Wiki is perhaps a better paradigm that raw GitHub for collaborative editing of web docs but either way would be a nice improvement.

@ccc I think sounds great. Especially Wiki. Those pages end up being very rich with info, examples etc. as well as taking some of the burden out of it from omz. I still can't believe such a great and complete product for a tiny price.

@JonB, I don't know those tools you speak of. I am guessing like in the tools in C that would rip out all your function prototypes for documentation purposes. This is one thing untyped languages don't help with I guess. I have briefly looked at the testing modules. So, I am guessing that funcs/classes that contained some testing code, could be run and types expected could be examined and collected during the running of those test suites to form some semi automatic documentation for the prototypes. Whilst args and *kwargs are really nice, not so nice to document I guess. Again, I am not sure. Maybe there are some wiz bang tools out there. Just my thoughts really

An open-to-contributions documentation sounds like a great idea, but a GitHub repo would probably be better than a wiki, because:

1. I'm not aware of any wiki software that uses reStructured Text as its markup format, which AFAIK is what the Python documentation uses. DokuWiki uses Markdown stored in plain text files (instead of a database like e. g. MediaWiki does), that could be an acceptable solution.
2. Wikis quickly become inconsistent, because pages are edited independently and changes are usually not approved in any way. An advantage of GitHub and PRs is that related changes can be done in a single PR, and they can be discussed before being merged by omz.
3. Wikis are a popular target of bored kids (or possibly also non-kids). This might be less of an issue in this case though, because the docs wiki would not have much exposure.

@JonB, it took me a bit of time to unpack your statement:

you can find the pylib folder from os.file.

I finally did find the location of embedded docs (at least the HTML versions).

https://github.com/cclauss/Ten-lines-or-less/blob/master/pythonista_docs.py

Is there a more straightforward way to find the Pythonista app path?

import os
app_path = os.path.abspath(os.path.join(os.__file__, '../..'))

@omz: If you were to make the Pythonista (and perhaps Editorial) docs collaborative, I would gladly help out. I don't know how hard it would be for you to do this, though. If it isn't possible or you don't want to enable collaboration on the official docs, I would like to ask you permission to make a clearly unofficial, expanded version based off of the official stuff.

@ccc: If @omz does give his consent, maybe we could include said unofficial docs on the Pythonista Tools website? It is already one of the (I think...) most popular unofficial Pythonista resources, so, at least in my mind, it would make sense to host it there. Speaking of which, I completely agree with @dgelessus on the repo vs. wiki debate. I see no reason to be redundant and reiterate his points here: they are already well-formulated. :)