Re: [dev] Release Engineering IRC chat
+1 Xiuzhi Cheng(xiuzhi) - OpenOffice.org ESC member. RedFlag Chinese2000 Software Co.Ltd. Tel:8610-51570010 ext 6177 Hi, again a reminder: We are going to have another Release Engineering QA session tomorrow. The channel will again be #re.openoffice.org, time is 10 am Hamburg time (which is GMT+2) / 4 pm Beijing time. If you have some agenda item(s), please reply to this mail to add them. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Sun is hiring a developer for OpenOffice.org Writer
Hi, we are currently looking for a developer that would like to join our Writer team in Hamburg. The successful candidate will have the following: - A degree in informatics (or a comparable qualification) - good C++ knowledge - Development experience in C++, C# or Java - Excellent team skills - Good communication skills in English The following would be advantageous: - Experience in Open Source development - Knowledge of word processing applications or text document file formats - XML knowledge - Experience in working on large projects - Communication skills in German The place of work will be Hamburg, Germany. In case you are interested, please send a mail to [EMAIL PROTECTED] (don't just reply to this mail, replies always go to the list). Best regards, Mathias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Develop macro recording as it ought t o be for all modules ASAP !? (Re: Vá: Re: [dev] Disabled Record macro menu in Impress and Draw
Hi there, the threads relating to macro recording abilities of OOo are very interesting. I have been somewhat puzzled about the conclusion that OOo should *not* have a macro facility at all and that the existing ones should be removed. The reason being that it would be too much effort for the expected benefit (see below)! Now this is puzzling for me for various reasons, especially in the context of typical end-users using OOo. Without a macro facility they have *no* chances whatsoever to be able to automate recurrent (business process) tasks on their own. They either have the choice of repeating (possibly cumbersome) over and over all the steps necessary to come up with a recurrent document, or they need to find someone who would be able to create a program for them to automate the recurrent functions they need. And here the simple truth is: there is almost no-one around who would have the *slightest* idea of how to automate/program OOo. Looking further for professionals is difficult to find ones, and if you find ones then you must be very, very lucky, if they have free resources that they sell/rent for an affordable price. Or with other words: forget it, rather repeat recurrent tasks by hand over and over again! This scenario does not look like an attractive or future safe one to me. Especially, if you compare this with Microsoft's Office (MSO) where it is extremely easy for end-users to record macros, in practice this is a no-brainer for them! As a result it is a) easy and b) cheap for MSO customers! Also, recorded macros can be adjusted quite easily, if an end-user has a coarse understanding of programming. Not seriously planning for a macro-recorder facility is a *quite* a *deadly* strategic error IMHO. MSO runs rings around OOo in a very important application segment! And MSO will be able to do that eternally, given any misisng plans to implement a macro recording facility for all modules. Rather than tackling this incredible omission immediately to fill this incredible hole, the undisputed conclusion seems to be, well we can't do it now, so we don't do it, and best, we ought to remove the existing macro recording as it was not done the way it should have been done from the beginning. Again, for an end-user perspective this is a glaring hole, making MSO truly much more attractive for their own daily work. Hence OOo *must* get macro-recording as it should be done for *all* modules as quickly as possible, if OOo should win and take over the hearts of the OOo users, especially the huge group of end-users sitting in all of these departments that should be migrated from MSO to OOo! Just my 2 cents. ---rony P.S.: If designed and done right, then macro recording should be feasible for interacting with/using any UNO service object in a language neutral manner, such that the generable macros could be created for any of the desired target languages of the users, OOo Basic, Python, Java, BeanShell, ooRexx, and the like. E.g., if I knew what the initial environment was (already there for macros) and what interactions (API invocations with used arguments) took place, then I would be able to (easily!) create from that an ooRexx program that would be able to replay all those API invocations. I am sure that Andrew would know and be able to do the same vor OOo Basic, and everyone else acquainted with UNO and another scripting language would be able to generate the appropriate code in their chosen scripting language. Mathias Bauer wrote: Andrew Douglas Pitonyak wrote: Even better, will a new and improved macro recorder be implemented? I do not remember seeing one in any road map, but I might have missed it. A new+improved macro recorder (I assume you mean a recorder that uses the real API and not the dispatach API) would be possible only by completely rewriting all glue code between the controls and the document core. This is very unlikely to happen. Why is that so? A recorder can record only API calls that are played. The only API calls that currently are played are the dispatch API calls. If you wanted other code to be recorded we would need to use (play) them in the code executed by e.g. the code that is executed when a menu or toolbar control is selected. And while we are at it: Kálmán Szalai wrote: Thank you for the information. Are you planning to reimplement this part and make it available under Draw/Impress? There are no plans to implement that. If I had the choice I never would have done it for Writer and Calc also as the current macro recorder is not what people really want and the real thing is just too much effort for the expected benefit. The resources we invested for that can be used better for more important things. Ciao, Mathias
Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disabl ed Record macro menu in Impress and Draw
Hi globally agree P.S.: If designed and done right, then macro recording should be feasible for interacting with/using any UNO service object in a language neutral manner, such that the generable macros could be created for any of the desired target languages of the users, OOo Basic, Python, Java, BeanShell, ooRexx, and the like. E.g., if I knew what the initial environment was (already there for macros) and what interactions (API invocations with used arguments) took place, then I would be able to (easily!) create from that an ooRexx program that would be able to replay all those API invocations. I am sure that Andrew would know and be able to do the same vor OOo Basic, and everyone else acquainted with UNO and another scripting language would be able to generate the appropriate code in their chosen scripting language. paolo mantovani as started some long-term work in thsi direction using python. look at http://www.paolo-mantovani.org/downloads/DispatchToApiRecorder/ and ping him if necessarry such contributions could easilly be deployed as extensions Laurent -- Laurent Godard [EMAIL PROTECTED] - Ingénierie OpenOffice.org - http://www.indesko.com Nuxeo Enterprise Content Management http://www.nuxeo.com - http://www.nuxeo.org Livre Programmation OpenOffice.org, Eyrolles 2004-2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] some questions about Addons.xcu - OfficeToolbar - Images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i have some questions about the Addons.xcu: - - Is it correct, that one can only define *one* OfficeToolBar inside an Addons.xcu ? So if one needs more OfficeToolbars, he has to deploy another extension ? OfficeToolBarMerging can not help in this case ? - - I noticed, that user defined toolbars are stored in \user\config\soffice.cfg\modules\scalc\toolbar\custom_toolbar_1.xml. All bitmaps are stored inside the \user\config\soffice.cfg\modules\scalc\images\bitmaps\sc_userimages.png file and described (url - image) in sc_imagelist.xml. My OfficeMenuBar items can take advantage from this behaviour. They use these images ... but the OfficeToolBar items do not :-( Is it a bug ? - - Is there a posibility to deploy sc_userimages.png within extensions ? I noticed only the ImageIdentifier and Images nodes within the addons.xcu... - - private:image/3216 will address an internal oo icon Where to find a list (image - id) for all possibilities ? Oliver - -- GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGztGJTiyrQM/QSkURApgaAJ9hYyIw1HM+sh6eVsuA+U+kNG4fdQCcCa/c Tw6yEd0b92uvDXq0qUJNIrI= =Uk1b -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disab led Record macro menu in Impress and Draw
Rony G. Flatscher wrote: Hi there, the threads relating to macro recording abilities of OOo are very interesting. I have been somewhat puzzled about the conclusion that OOo should *not* have a macro facility at all and that the existing ones should be removed. The reason being that it would be too much effort for the expected benefit (see below)! Of course Draw/Impress has a macro facility but not a macro recorder and nobody wants to remove this facility. I see that this is what you meant - but please let's be accurate, rumours spread faster than you can imagine and next week you can read somewhere that we are going to dump Basic macros in Draw. ;-) (snip) Just my 2 cents. I'm afraid that 2 cents won't be enough, but in case you could invest 20 million cents we could think about implementing the dispatch macro recorder in Draw/Impress and fixing the existing one in Calc and Writer. I doubt that it would be possible with less effort. There are still much more areas in OOo where this investment is placed a lot better. This is what too much effort for the expected benefit means. In the same time you can implement much more things that much more people need. But this simple recorder still isn't the real recorder that developers and development newbies want, they want a tool that teaches them the real OOo API (not the Dispatch API), not a simple automation tool. I have written a wiki page http://wiki.services.openoffice.org/wiki/MacroRecorder that describes the situation. Please everybody interested in this read it, and read it completely before you reply. If something is unclear of if you think that something is wrong please let me know it. I hope that this will make clear where the problems are and why it would be such a huge effort to provide a real API macro recorder. Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Develop macro recording as it ought to be for all modules ASAP !? (Re: Vá: Re: [dev] Disab led Record macro menu in Impress and Draw
Laurent Godard wrote: Hi globally agree P.S.: If designed and done right, then macro recording should be feasible for interacting with/using any UNO service object in a language neutral manner, such that the generable macros could be created for any of the desired target languages of the users, OOo Basic, Python, Java, BeanShell, ooRexx, and the like. E.g., if I knew what the initial environment was (already there for macros) and what interactions (API invocations with used arguments) took place, then I would be able to (easily!) create from that an ooRexx program that would be able to replay all those API invocations. I am sure that Andrew would know and be able to do the same vor OOo Basic, and everyone else acquainted with UNO and another scripting language would be able to generate the appropriate code in their chosen scripting language. paolo mantovani as started some long-term work in thsi direction using python. look at http://www.paolo-mantovani.org/downloads/DispatchToApiRecorder/ and ping him if necessarry such contributions could easilly be deployed as extensions By all respect - this approach doesn't scale. It will give nicer macros in some cases but not more. What Paolo does is the big solution, but only to a very small degree: he reimplements the glue code (please see the wiki page I linked to in another reply in this thread) minus the UI, but he doesn't do it in C++, he does it in a scripting language. Doing this in the necessary completeness will take even longer than doing it in C++ by the people in the know and in many cases it will just be impossible. Best regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
