Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tables documentation partial rewrite 9957 #193

Merged
merged 7 commits into from
Jan 16, 2013

Conversation

manics
Copy link
Member

@manics manics commented Dec 21, 2012

This was origingally a partial rewrite of the tables documentation including the new array columns from PR ome/openmicroscopy#538. Since it may be held back from the next release I'll split the docs PR into two, this one covers doc changes relating to the existing tables functionality:

  • Moved the tables docs out of analysis and into a new page
  • Added more API detail, especially parameter types
  • This currently appears under Analysis in the TOC.

If I don't open this now I'll probably forget after Christmas.

Added description of parameters for creating OMERO.Tables columns.
Added links to existing sample code.
Added documentation for the main OMERO.tables methods

Use :class:, :func:, :attribute: roles

USe sphinx parameter type specifications, expanded getWhereList
@joshmoore
Copy link
Member

2 primary thoughts:

  • To what extent should the class descriptions etc. by in the code itself? Or is this something we worry about later since we haven't yet worked out the epydocs migration?
  • Should the single analysis.txt function as the TOC for tables, etc?

/cc @sbesson & @rleigh-dundee

@ghost
Copy link

ghost commented Dec 28, 2012

Getting sphinx to build the documentation is trivial; I can open a PR for that almost immediately--just need to dig out the patch. The main effort is in updating the comments; since I'm not familiar with the API, this should really be done by someone familiar with the code. It probably also needs doing in openmicroscopy.git or else it will break a standalone docs build.

In general though, the API documentation should probably go in the code where possible, though there will be an initial effort to get the comments converted.

@manics
Copy link
Member Author

manics commented Jan 3, 2013

To what extent should the class descriptions etc. by in the code itself? Or is this something we worry about later since we haven't yet worked out the epydocs migration?

A lot of the docs will be in the Ice definition files- is it straightforward to include Sphinx documentation in them?

Should the single analysis.txt function as the TOC for tables, etc?

I thought I'd keep it there for now since the Tables docs are quite short, as they get expanded it can be made a top level heading.

@joshmoore
Copy link
Member

I doubt that we can get sphinxdocs into the ice definition, but we can embed doxygen. (See ./build.py release-slice2html)

@manics
Copy link
Member Author

manics commented Jan 3, 2013

So should I move the class/method docs into the Ice file and reference them in the sphinxdocs, or leave it for now?

@joshmoore
Copy link
Member

@manics, to some extent that's up to you. Long-term, much of the gory details should be in the ice file. If you think you could get something with links to the slice2html working from tables.txt, then by all means. Otherwise, we can do that later.

@manics
Copy link
Member Author

manics commented Jan 3, 2013

In that case I'd rather wait until we decide on the grand plan for the documentation.

@joshmoore
Copy link
Member

@manics, sounds good. Just waiting for @hflynn to return.

@hflynn
Copy link
Member

hflynn commented Jan 7, 2013

Looks like we need to have a chat about this at some point. I'm wondering if it is a situation like the BF developer docs where we want to reference code files in the docs but I probably need someone to talk me through this specific case.


.. class:: omero.grid.Column

The base class for column types which permit returning arrays of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be "permits" ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so ( "types" is plural).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, apologies Simon, I parsed that incorrectly and thought the class was permitting rather than the column type.

@manics
Copy link
Member Author

manics commented Jan 14, 2013

I had a go at writing a slice2rst utility:
https://github.com/manics/slice2rst
http://users.openmicroscopy.org.uk/~spli/docs/_build/html/

More a proof-of-concept at the moment, question is whether it's worth the effort of developing and integrating it.

@hflynn
Copy link
Member

hflynn commented Jan 14, 2013

I don't feel qualified to answer this. From my POV, as long as there is something in the sphinx docs to point people to the right location, I happy for this level of developer documentation to be stored wherever the actual developers think is easier.

@manics
Copy link
Member Author

manics commented Jan 14, 2013

Sorry, I should've targetted this to @joshmoore

@hflynn
Copy link
Member

hflynn commented Jan 14, 2013

It's fine, I wasn't sure whether you were asking me or not, just thought I'd clarify my position either way.

@joshmoore
Copy link
Member

Saw the proof-of-concept which is probably a good mid- or long-term solution. For the moment, I'd probably just fix your s/z's (:smile:), and we can continue the rst discussion on-list and in-meeting.

@manics
Copy link
Member Author

manics commented Jan 14, 2013

s/z fixed.

@joshmoore
Copy link
Member

👍

joshmoore added a commit that referenced this pull request Jan 16, 2013
Tables documentation partial rewrite 9957
@joshmoore joshmoore merged commit ad00526 into ome:dev_4_4 Jan 16, 2013
@manics manics deleted the tables_arraycolumns_9957 branch February 13, 2014 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants