Re: [dev] Buggy insertDocumentFromURL

2005-10-28 Thread Christoph Lutz
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

2005-10-28 Thread Mathias Bauer
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

2005-10-28 Thread Mathias Bauer
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

2005-10-28 Thread Philipp Lohmann - Sun Germany

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

2005-10-28 Thread Carsten Driesner

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

2005-10-28 Thread Mechtilde

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

2005-10-28 Thread Christian Junker
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

2005-10-28 Thread Jürgen Schmidt

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

2005-10-28 Thread Christian Junker
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

2005-10-28 Thread Joerg Barfurth

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

2005-10-28 Thread David Fraser

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

2005-10-28 Thread Andrew Jensen



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]