Just a idea. Widgets/controls for Pythonista
@JonB, that sounds great. But how do I pick my custom class in the ui builder ?
dgelessus last edited by
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.
JonB last edited by
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?
ccc last edited by
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
dgelessus last edited by
An open-to-contributions documentation sounds like a great idea, but a GitHub repo would probably be better than a wiki, because:
- 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.
- 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.
- 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.
ccc last edited by
@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).
omz last edited by
Is there a more straightforward way to find the Pythonista app path?
import os app_path = os.path.abspath(os.path.join(os.__file__, '../..'))
Gerzer last edited by
@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. :)