Its fine if there is a reason - but I don't see it. It might be much better to actually tell the user why its grayed. I still don't know. I tried linux and windows (3.6.2.2, build da8c1e6) oo ships with python.exe - so I don't see any reason why its not possible to create python scripts - because basic lacks even trivial functions such as str_replace.
Hi Marc, When you say grayed out in macro organizer dialog, are you referring to the LibreOffice application, or is there some UI in the SDK of which I am unaware ? Just so I don't go reassigning this to another module by mistake. Alex
In LO 3.6.3 rc1 Linux 32bit, I can see entries for Python, Basic, Beanshell and Javascript, and the Python scripts work. Alex
I'm talking about 1) start soffice 2) click on Tools -> Macros -> Organazie Macros -> Python Then the window appears, but I can't edit / create new modules the way it can be done with basic macros. Because it neither worked on my linux box nor on windowns I think its a bug. Running the "capitalize" python macro from that ui seems to work. So I've had big problems trying to get any custom python script to work, connecting was fine, but getCurrentComponent or such failed. I solved my task in a different way (exporting to html, parsing that) Python is important because basic does not even support str_replace like features out of the box. At least I wonder how you can get your job done efficiently using basic. Maybe I'm just not familiar enough with it.
(In reply to comment #3) Hi > I'm talking about > 1) start soffice > 2) click on Tools -> Macros -> Organazie Macros -> Python OK, so we are on the same page then, that helps :-) > > Then the window appears, but I can't edit / create new modules the way it > can be done with basic macros. Because it neither worked on my linux box nor > on windowns I think its a bug. There is no built-in python editor. It has always been this way (even with OOo before LO). If you want to create python scripts for LO, you have to create them outside of LO in your favorite editor or IDE of choice, e.g. Eric, IDLE, Geany, etc, and then save the script and copy it to the Scripts subdirectory in either your LO user configuration directory or, for the case of a multi-user install, to the Scripts subdirectory of the main installation (with the correct permissions). So, this is not a bug as such IMHO, just a lack of appropriate integration of a macro editing tool that works on all of the platforms supported by LO. Alex
>> "It has always been that way" This is not helpful to make new users like me (even if they are programmers!) understand how to run scripts. >> and then save the script and copy it to the Scripts subdirectory in either your LO user >> configuration directory or, for the case of a multi-user install, to the Scripts >> subdirectory of the main installation (with the correct permissions) Great - another thing you just have to know. Why not rename the directory "My Macros" to "$HOME/.libreoffice/...". Instantly you'll try to put .py files there then. No more need to lookup documentation at all. You have to learn a lot: 2a - connect via tcp/ip (which looked like a straight forward way to me - but I failed because I couldn't get the current document 2b - run within OO - then only XSCRIPTCONTEXT is available - which is that helpful because it has ".getDocument" I failed at 2a, I failed at 2b. I then started to use the Java way (which is horrible verbose). And then you still have to understand how to find and lookup the api - which is easy easy enough once you get it. This page can be found very easily: http://api.libreoffice.org/ Then the next thing I did was following "examples" -> "python". Its hard to understand because the page has all kind of content (python/C++/..) and then you find a complicated sample you may not be interested in - without any advice how to actually make it work. Eg there is a README: http://api.libreoffice.org/examples/python/toolpanel/readme but it does not tell you "how it should be installed". That's again the "it has always been that way" thing - either you know or you don't. Maybe this is only a "documentation" bug - but a very searious one - which has taken a lot of my time - that much that I got the feeling I would have been done in 10min using Microsoft Excel - but looking this information up (and still failing) took many hours. And that in turn causes a feeling in me that using OpenOffice for business would be a wrong choice - and I don't want to feel that way. How should it be? Don't gray the buttons, make people click them even if the action is only a message box: "This feature is not available yet. see wiki page http://.... to understand how to write and use python scripts automating libreoffice work" And the user experience will turn from "Damn - I should try other tools. This just looks so incomplete" to "hey, thanks. I know what to do to get my job done now." Maybe the page exists telling me how to use python. api.libreoffice.org looks very official to me - and didn't tell me in reasonable time. If it was me failing to click on the best link - tell me what page to open, please. That's why I think this is a serious bug preventing users from doing useful things with open source software. I agree that if you try hard enough you may find appropriate sources of knowledge. The official page should be the one telling you, though. Even searching for libre office and wiki doesn't show up something useful in time. So which is the best way to improve this? Does libreoffice already has a wiki which could be pointed to on api.libreoffice.org to make people learn about how to get started? Questions like "How does idl compare with Java API, are they all the same exactly?" should be answered on a wiki. Even if you know a bit of all: C++/Java/python you don't know how which way to get started. I hope that this message helps you understand what is hard for people who don't know yet how to use OO macros.
Marc, I am only a simple volunteer QAer who happened to come across your report and take an interest, not a developer. You might like to voice your (justified IMO) concerns on the developer mailing list. The requirement for what was OpenOffice.org, and now LibreOffice, to run on multiple OSes resulted in various kludges/tricks for getting the Python-UNO, Java-UNO, X-UNO bridges to run. Maintenance has always been a problem and a limitation with regard to the implementations that are possible. It doesn't help that the OSes themselves, apart from the various Linux distributions, were not always very Python friendly (e.g. Mac OSX, Windows). However, that is the historical reason for why things are as they are today. In addition, this won't change unless someone can be bothered to re-implement them in a way that satisfies the multi-arch/platform criteria and still lets you manipulate your objects/data/structures in the way that is coherent with current development within the project, which in itself would be no mean feat. If you are looking for Python-UNO related documentation, then you might want to look to the mothership project : http://www.openoffice.org/udk/python/python-bridge.html http://www.devshed.com/c/a/Python/Python-and-OpenOfficeorg/ http://drbacchus.com/openoffice-python-uno-interface http://www.len.ro/work/python-uno-openoffice-automatization/ Now of course, you might find these examples too limited for what you are looking to do, I don't know. What I do know is that a valuable tool for object/method introspection is the MRI extension (written in python) that you can get here : http://extensions.libreoffice.org/extension-center/mri-uno-object-inspection-tool You could also look at some of the python scripts that are already part of the code base within the LibreOffice project : http://cgit.freedesktop.org/libreoffice/core/tree/pyuno/demo or the mailmerge.py script which is used from within LibreOffice to carry out mailmerge (more or less successfully, it has to be said). Alex
Setting this report as invalid. Your questions and comments, which while valid, are more related to developer documentation, or at best a request for enhancement (feature request) with regard to the user interface (and underlying code needed to provide that functionality). If you want to open up a new bug report in that direction, please feel free to do so. Considering the effort that such an undertaking would require, this would probably not at present be considered high priority for the development team, which has much to do just squashing the bugs. Alex
Alex: Its not a problem that libreoffice has to be used in different ways on different OS regarding python. The problem is that api.libreoffice.org doesn't tell you. And that was the first trustworthy page I was redirected to many times. I didn't ask for much developer time. Adding a Message box instead of graying out a button should not take much time. Mind this please. Because I am a software developer myself I only suggest what would provide greatest value in the shortest time possible. And that would also be using a wiki so that missing information can be added and improved easily. I'm new to the libre office project. So who is in charge for deciding whether a wiki may be established at libreoffice.org ? With some luck people may stumble upon your links on this bug report page - but I think there are ways to make sure that people who are interested in python & libreoffice can't miss the links. Setting up a wiki (or pointing to a wikipedia wikibook) does not take too much time. If you think the right way to go is rewriting these topics on the dev mailinglist I'll do so. Thanks for the pointer. So I will subscribe to that mailinglist and point to this bug report and ask for advice - if nobody has time maybe I can provide a patch myself. I'll post an update about the replies or paste a link to the thread later.
*** Bug 156928 has been marked as a duplicate of this bug. ***
Setting to new, as I agree with OP in duplicate bug 156928 and Mike's comment in bug 156928 comment 4. Expectations to have Python well integrated into LO have also changed over the last 10+ years (and recent development on MSO's side). - Temporary fix would be a message removing the buttons that can't possibly be active given the current lack of IDE, and/or message to inform user. - Enhancement would be to integrate a Python IDE. (see bug 138408)