Looking for PyUno Contributor(s)

users
#1

Hi All!

I am one of the members of the Quality Assurance team with LibreOffice and we are looking for a volunteer to work with myself designing (and coding) the framework to start automating our stats. It's been on my list for much too long and I just don't have the technical know how to do it. If there are are users or developers who can slowly get this accomplished it would greatly help QA as well as Marketing as our stats are done almost completely manually at this point, not only is this time consuming but it's also likely that there could be mistakes or missing data.

If there are any takers, again this would be a great help, I have a general idea of what I'd like to do, just trying to find people who are capable of implementation.

Many thanks and best regards,
Joel

#2

Several developers have told me that python and uno will be needed to
extract the data from FDO, create a spreadsheet from this data and then
create the graphs/summaries that I am hoping we can create automagically.

If I'm incorrect, please let me know what is correct - but I'm pretty sure
that someone with some PyUno skills will be needed.

Best.
Joel

#3

If I'm incorrect, please let me know what is correct - but I'm pretty
sure that someone with some PyUno skills will be needed.

I would guess that those are rare, since PyUNO is at about the best
kept secret of LO(/OO).

Sincerely,

Wolfgang

#4

+1 +1 +1

I've even attempted to make several runs at it. The documentations is a
*@(^&@*$^&@*# crime. There are silly trivial "Hello World" examples,
and there is the dump of the API. And nothing in between.

If someone implements this as a contribution to the project *PLEASE
PLEASE PLEASE* do a step-by-step BLOG article/series of it. I'll send
them a six-pack; just let me know the URL.

There really seems to be an *AMAZING* amount of power just sitting there
to be used - but it is completely obscured to anyone not aleady familiar
with UNO's syntax and vocabulary.

Especially with the introduction of CMIS support it really seems a great
time to facilitate real automation via LibreOffice.

#5

This seems to be a general consensus and it sucks for my purposes at least :-/

Another option is just going straight python and at least compiling the necessary numbers, then manually doing the charts and what not.

Anyone able to do this?

Maybe we need to get doc team involved at some point with PyUno to see if they can start getting decent documentation together.

Best,
Joel

#6

Hi :slight_smile:
The documentation team needs a LOT more people.  At the moment it barely has enough to just work on the guides (which were extremely well received at Scale btw).

If these other attempts at documentation are done through by individuals through blogs and personal spaces then when/if those individuals "run out of steam"  or if outside life takes over then the work would be lost or difficult to carry on with - or even difficult to find at all.  By joining the Documentation Team you can use centralised resources such as their ODFAuthors site to make the work more likely to be continued by others.  Other people in the team are often helpful and encouraging and are experienced at writing for non-technical end-users and can help gain consistent use of terms and phrases.  Joining the team means your work will not get wasted if unforeseen circumstances (such as suddenly gaining a shed load more clients) conspire to reduce the amount of time you can spend on the work.

People are encouraged to join in with the work they are currently doing in order to gain some experience with their process and then perhaps use that experience to get on with their original plans. 
Regards from
Tom :slight_smile:

#7

Hi :slight_smile:

If the documentation is available but needs pulling together and de-geekifying then the Docs Team are a good place to do that.  If it needs writing from scratch (scuse the pun) then some devs probably need to be involved too.

Writing code and writing documentation for technical readers is a radically different skill-set from writing so that the rest of us can understand it.

Regards from
Tom :slight_smile:

#8

Hi all,

I've even attempted to make several runs at it. The documentations is a
*@(^&@*$^&@*# crime. There are silly trivial "Hello World" examples,
and there is the dump of the API. And nothing in between.

mailmerge.py
LibreLogo.py
LightProof (dictionaries)
The new wizards (by Xisco Fauli) written in python ?
The Barcode extension
Bernard Macelly's MRI extension ?

So there are several examples around, even within the LO code itself, if
one takes the time to have a look.

There is also :
http://opendocumentfellowship.com/resources/dev_tools#python

which deals more with manipulating ODF documents.

Alex

#9

Hi :slight_smile:
Ahah, could someone add links to those on the 3rd party wiki page?
https://wiki.documentfoundation.org/Documentation/Other_Documentation_and_Resources#Programmers
Regards from
Tom :slight_smile:

#10

I agree completely - but it would help to get people off-the-ground and
using the technology. I cannot document a technology that I can't [very
easily] get up and rolling with. I'm just saying not to make the
perfect the enemy of the good [which happens terribly often in Open
Source land].

Aside: PUNO <http://www.wstech2.net/index.php?do=0a,01,05> which is an
UNO connector for PUNO is a nice bit of code; we use that to generate
documents on our website/webservice.

Various UNO getting started guides:

<http://openofficejava.blogspot.com/2009/05/openofficeorg-api.html>

<http://drbacchus.com/openoffice-python-uno-interface>

<http://tirania.org/blog/archive/2008/Jun-12.html>

<http://www.devshed.com/c/a/Python/Python-and-OpenOfficeorg/>

#11

Hi :slight_smile:
Ahh, i meant the docs team are good at supporting and helping people that want to do documentation tasks.  They are not precious about it or offended if people go off and do their own thing.

Btw those links look good.  Please can you add the links to the 3rd party wiki?
https://wiki.documentfoundation.org/Documentation/Other_Documentation_and_Resources

I'm not completely happy with the name in that url.  I would prefer something like one of these
https://wiki.documentfoundation.org/Documentation/3rdPartyGuides
https://wiki.documentfoundation.org/Documentation/UnofficialGuides
or make it a sub-page off the Publications page so something like
https://wiki.documentfoundation.org/Documentation/Publications/Unofficial
https://wiki.documentfoundation.org/Documentation/Publications/ThirdParty

Other suggestions or which would you prefer?  I tried asking on the Docs Team's list but got distracted and never got a clear answer.  Once i have a good name i can create an auto-redirect from the current page (which got named in a hurry without really thinking about it)

Regards from
Tom :slight_smile: