Re: [dev] Buggy insertDocumentFromURL
Hi Christian, 2005/10/27, Christian Junker [EMAIL PROTECTED]: I tested all the small examples on Mac OS X with OOo 2.0 using Starbasic and I can only reproduce Bug 1 (it's probably not a bug here). Bug 2: That's also my experience using Starbasic. In Starbasic the insertDocumentFromURL throws an corresponding exception *immediately* (a dialogbox with the error message pops up). It's the different behaviour in Java that makes me wonder. The way basic bahaves lets me come to the following guess: 1) the problem is NOT a problem of system timeouts. 2) is it possible that there is a kind of default behaviour that tries to create a message-box even with java? The message-box can't be shown because of a missing parent frame but is still there and modal so it blocks the rest of the application? I also tried to provide a different InteractionHandler in the MediaDescriptor props, but (that's the reason why I wrote the Bug 1-example) it seems that insertDocumentFromURL throws an IllegalArgumentException everytime the MediaDescriptor is not empty. best regards, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Resources debate
Daniel Kasak wrote: [EMAIL PROTECTED] wrote: There's an interesting debate going on at ZDNet about resource usage in Oo 2.0 It would be great if you guys put in your 2 cents... http://blogs.zdnet.com/Ou/?p=119 The author of this article went out of his way to create a spreadsheet that would perform badly under OOo. The reason it takes so long to load is that the XML for each cell has to be parsed by OOo. Microsoft's xls format is a binary format - loading and saving are literally just memory moving operations. That's why they can open a file in 1 second - there's no processing involved at all - the contents of the file are simply dumped into memory, and that's that. I think that your analysis correctly describes why an XML based format will always be slower than a optimized binary format. OOo has some special problems here though, even with an XML format it could be much faster. This is something that is worked on with high priority. I've heard that Microsoft's XML format also has binary elements, so they'd also be getting performance benefits over OOo in cases where the format is binary. Lastly, Excel is most likely not checking the validity of each element of the file. Excels XML may contain some binary elements (e.g. embedded Word objects). AFAIK this will change with the new Office 12 file format. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new incubator : Call for Name
Rüdiger Timm wrote: Joerg Barfurth wrote: Hi, Laurent Godard wrote: - extensions.openoffice.org (already 3 votes) -1, We already have a cvs module named 'extensions' in the 'util' project. This situation (a module in one project is named like another project) is prone to cause confusion. Unfortunately we already have at least one case of this situation (module util/tools vs. project tools), but IMHO we should proliferate it any more. Ciao, Joerg The same holds true for 'scripting', as there is a module with this very name in project 'framework'. This leaves 'addon' as the only candidate: addon.openoffice.org +1 The modules are not visible to the outside world except when you deal with cvs and getting source code from it. As far as I expect the new project is not a coding project but a documentation and content providing project so I think we can bear this name clash. OTOH addon is a bad as scripting because *both* are technical terms that just describe a single aspect of what the project is about. extensions is much better suited for the project: it is a non-technical term and it is understandable by everyone. It describes the project as something about extending OOo by everything that adds functionality to it, be it Add-Ons, Add-Ins, other UNO components or macros, templates etc. Besides that it would be nice to use a name that sounds familiar to developers outside OOo - extensions are well known from the Mozilla project. So +1 for extensions. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: reftotemp
Stephan Bergmann wrote: So, if there are no objections, I would switch off the reftotemp warning globally for all unxsol platforms. +1 -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: reftotemp
Stephan Bergmann wrote: So, if there are no objections, I would switch off the reftotemp warning globally for all unxsol platforms. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Programmierhandbuch für Basic
Hello Jürgen Schmidt schrieb: First of this is a English only mailing list Thank you for the tip. I choose the wrong adress from my Adressbook Aber nichtsdestotrotz danke für den Hinweis. Das scheint ein Übersetungsproblem zu sein und wir werden das überprüfen und korrigieren. Es gibt aber mittlererweile auch andere Bücher für Basic, eine Google-Suche sollte hier weiterhelfen. After I read the first fifty results of the google-search I only found one book for Starbasi 8.0 If you know a good one, please let me know. Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Programmierhandbuch für Basic
Hey Jürgen, 2005/10/28, Jürgen Schmidt [EMAIL PROTECTED]: Aber nichtsdestotrotz danke für den Hinweis. Das scheint ein Übersetungsproblem zu sein und wir werden das überprüfen und korrigieren. gibt es die Möglichkeit das Dokument (engl. + deutsch) umzustellen auf eine freie Lizenz? Sun könnte ja immer noch den StarOffice 8 Programmer's Guide anbieten auf ihren Servern, aber auf openoffice.org könnte man doch ein kollaboratives Dokument erstellen und es einfach OpenOffice.org 2.0 Programmer's Guide nennen, wobei ich mit dem Namen auch nicht so zufrieden bin weil es schon einen Developer's Guide gibt und durch die Tatsache, dass UNO nun so viele Sprachen unterstützt, der Interessent leicht davon ausgehen kann, dass es nicht nur um Starbasic/OpenOffice.org Basic geht. Es gibt aber mittlererweile auch andere Bücher für Basic, eine Google-Suche sollte hier weiterhelfen. Schön und gut, aber es fehlt *die Referenz*. -- Best Regards Christian Junker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Programmierhandbuch für Basic
Christian Junker wrote: Hey Jürgen, 2005/10/28, Jürgen Schmidt [EMAIL PROTECTED]: Aber nichtsdestotrotz danke für den Hinweis. Das scheint ein Übersetungsproblem zu sein und wir werden das überprüfen und korrigieren. gibt es die Möglichkeit das Dokument (engl. + deutsch) umzustellen auf eine freie Lizenz? Sun könnte ja immer noch den StarOffice 8 Programmer's Guide anbieten auf ihren Servern, aber auf openoffice.org könnte man doch ein kollaboratives Dokument erstellen und es einfach OpenOffice.org 2.0 Programmer's Guide nennen, wobei ich mit dem Namen auch nicht so zufrieden bin weil es schon einen Developer's Guide gibt und durch die Tatsache, dass UNO nun so viele Sprachen unterstützt, der Interessent leicht davon ausgehen kann, dass es nicht nur um Starbasic/OpenOffice.org Basic geht. That's the reason why the name is StarOffice XX Software Basic Programmer's Guide But related to your question, that would maybe possible but have you asked all the others who have written books and guides to contribute there stuff back to the OpenOffice project? The answer is probably not and they have probably a lot of content from the existing guides and the mailing list. People take the stuff and of course the product from OpenOffice but what is their contribution back? It's fine if people make money with support and services around the project but they should think about any contribution back to the project. See the Developer's Guide, we Sun make it available for OpenOffice but we did the work. Ok we got some minor bugfixes but where for example is the Python language binding chapter or where are the missing chapter of a specific functionality? Nervetheless I will check it. Juergen Es gibt aber mittlererweile auch andere Bücher für Basic, eine Google-Suche sollte hier weiterhelfen. Schön und gut, aber es fehlt *die Referenz*. -- Best Regards Christian Junker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] new incubator : Call for Name
my vote for extensions, as the other two words confuse newcomers because of the mentioned reasons (addon is already a certain term in the API, scripting excludes major languages like C++ and Java). 2005/10/26, Laurent Godard [EMAIL PROTECTED]: - addon.openoffice.org (already 1 vote) - extensions.openoffice.org (already 3 votes) - scripting.openoffice.org (already 0 vote) -i leave it in case -- Best Regards Christian Junker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: reftotemp
Hi, Stephan Bergmann wrote: C().doSomething(); produces a Warning, reftotemp: should not initialize a non-const reference with a temporary. [..] [Some sort of personally biased rationale for switching that warning off: For a start, I never quite understood the rationale behind forbidding passing a temporary to a function via non-const reference---C++ is generally a shoot yourself in the foot if you feel like it language, and the safety-measure installed by this error does not really fit that philosophy. The problem here are unintended/unforeseen implicit conversions. Combined with overloading this can cause code to compile in surprising, erroneous ways. The simple example would be: void inc(int val) { val++; } void inc(long val) { val++; } void inc(double val) { val++; } void inc(std::string val) { val.append(+1); } short s = 0; unsigned int u = 0; float f = 0; const char * t = 0; void inc_all() { inc(s); inc(u); inc(f); inc(s); } This would compile flawlessly, but without the expected side effects. But that argument doesn't apply when calling a member of a temporary, because implicit conversions aren't applied to the operands of a member access operator. I don't think that warning is useful (in almost all cases). So, if there are no objections, I would switch off the reftotemp warning globally for all unxsol platforms. +1 Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] openoffice.org wiki
Ian Laurenson wrote: On Thu, 2005-10-27 at 16:05 +0200, David Fraser wrote: Ian Laurenson wrote: [snip] What I'm proposing is having the files stored in Open Document Format and using Writer as the browser/editor of the information. While I don't have all the details thought through - I think it an idea worth investigating/discussing. I'd rather have something as full-featured as MediaWiki up and running as a centralized wiki for OpenOffice.org straight away than wait for a new system like this. Agreed! It may be better to then write a plugin to MediaWiki to allow Writer to edit the files and send them back but surely most OOo people have a web browser? I don't understand what makes using Writer better than using the Wiki editor Compared to the full featured editing environment that Writer provides a Wiki editor is crude. Please don't get me wrong, I like wikis and am strongly in favour of them, that is why I started the wiki on writing OOo extensions: ext.openoffice.org.nz. It is just that I see the Open Document Format as being an opportunity to dramatically improve the usability of interactive web content. I haven't investigated writing plugins for MediaWiki. I think it would would be easy to modify my DokuWiki macro to produce the somewhat crude text file format for MediaWiki: http://homepages.paradise.net.nz/hillview/OOo/ Agreed, all OOo users/developers will have a browser, and all computer users don't have OpenOffice. But, all OOo developers will have OOo and this makes it an ideal place to experiment with using the Open Document format as a standard for interactive web content for things like wikis. Sounds good David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Resources debate
Daniel Kasak wrote: [EMAIL PROTECTED] wrote: There's an interesting debate going on at ZDNet about resource usage in Oo 2.0 It would be great if you guys put in your 2 cents... http://blogs.zdnet.com/Ou/?p=119 The author of this article went out of his way to create a spreadsheet that would perform badly under OOo. The reason it takes so long to load is that the XML for each cell has to be parsed by OOo. Before you go off on that line, could I ask how you know he fudged the data to favor one application over the other. When I read the list it appeard that he just chose a log file that he normaly uses. It might be that this test does favor Excel, but saying he purposefully did so can back fire. That's my thoughts on the matter. Posting comments to the website is broken, so I'd say the M$ fanboy has done this to prevent more OOo users from questioning the validity of his claims based on this extreme test case. Obviously most documents open quite fast, and he would know this, but chose to present a case where OOo was quite slow, and made this the focus of the article. I have to point out that the one thing I did not see on ZDNet thread was anyone posting up numbers from their own test results. The truth is OO is a good package, but performance is not a strong suit, least not on my WinXP machine. I tend to think this is more a function of the compatablility layers - and after watching a presentation from the last OOConn it may also be a little deeper then this. (I would give the OO team high points for having this discussion in public, and I think it shows that the problem is being taken seriously, as it should) For my purposes I have been really hitting the Base module hard and one thing I have noticed is that when I take data from a Base table and link into a Calc sheet the amount of time for the transfer appears to be pretty bad. I haven't created precise metrics for this, so it is just perception at this point. But if I am not careful about limiting the number of rows then it can take minutes not seconds for the transfer to happen. I would imagine this is more to do with memory management then XML parsing, as there is no XML to parse as far as I know. Pretty dodgy stuff, but it's Microsoft we're dealing with here. I would not call it dodgy, at my last corporate position our customer base would send us files of many 10s of thousand of records - we offered an analysis service as part of the process of cutting them over from their old backend systems to ours. The same was done annualy for as long as they used our system, so that we could generate statistics (from all installed systems) to feed back into the system for forcasting purposes. It is not uncommon in my experience therefor to work with the size files he was talking about. It may not be an every day affair - but it is certainly not unheard of, and when it comes up there is no easy way to get around it - either the tools you have available can handle it reasonably well or they choke. Andrew Jensen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]