[dev] conulta open office
hola no se si este es el medio para realizar consultas pero no encontre otro. tengo un problema que no puedo solucionar : me aparece el siguiente mensaje cuando quiero abrir un archivo del tipo hoja de calculo de open office la operacion solicitada requiere elevacion por que podria ser? el programa se ejecuta como administrador. agradezco la ayuda, saludos! yesica Idaberry -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: conulta open office
2011/6/6 Yesi Idaberry yesi_be...@hotmail.com hola no se si este es el medio para realizar consultas pero no encontre otro. tengo un problema que no puedo solucionar : me aparece el siguiente mensaje cuando quiero abrir un archivo del tipo hoja de calculo de open office la operacion solicitada requiere elevacion por que podria ser? el programa se ejecuta como administrador. agradezco la ayuda, saludos! yesica Idaberry replied off the list in spanish. -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi rony, On Tue, 31 May 2011 19:55:44 +0200 rony ro...@openoffice.org wrote: totally off the records for this list, indeed. but maybe nevertheless interesting/amusing: Ubuntu 11.04 replaced OOo with LibreOffice (LO). thats true. Whatever they did, they probably did what they did with their OOo installation in the past with the effect that using the Java interface from the command line does not work (using their unoinfo-output for Java) ! That has nothing to do with OOo or LibreOffice, it did not work any better with OOo. The root cause is that the bootstrap helper makes quite crazy assumptions about where to find the soffice binary. Debian (and thus Ubuntu) does quite a few changes (for example moving jars around), which the original OOo code does not handle too well. unoinfo.sh has no role in this at all -- it is not even packaged on Ubuntu. Instead one needs to deinstall LO, remove ~/.libreoffice in home, get the official LO distribution and install it, then things start to work as was the case in the past with OOo. No, you would need to bootstrap with a ClassLoader having a correct resource path. Never having seen this being reported against LibreOffice on launchpad, it was assumed as not a serious issue. Whining about it on the mailing list of a different project instead of filing a bug is kind of ridiculous still, isnt it? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] refactoring OUString
Has anyone tried refactoring OUString? - It converts iso-8859-1 letters ranging 0x00-0x7f into UCS2 even it is not necessary. - It requires malloc(), realloc(), and free() or their equivalents. - It prevents debugging efforts because of sal_Unicode buffer[1]. - It mixtures different purposes: passing/returning parameters and long-lasting data. - and else... Best regards, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: refactoring OUString
On 06.06.11 16:35, tora - Takamichi Akiyama wrote: Has anyone tried refactoring OUString? - It converts iso-8859-1 letters ranging 0x00-0x7f into UCS2 even it is not necessary. - It requires malloc(), realloc(), and free() or their equivalents. - It prevents debugging efforts because of sal_Unicode buffer[1]. - It mixtures different purposes: passing/returning parameters and long-lasting data. - and else... hi Tora, refactoring OUString has to be done carefully because it is a central part of the URE API/ABI and those must be compatible. a number of people here have come to the conclusion that it would be an improvement to use ::rtl::OString with UTF8 encoding as the standard string type, but unfortunately this would be an enormous effort to change, and it would mean breaking the backward compatibility of the C++ UNO binding, so it was never likely to actually happen. so far we haven't even got rid of the tools strings... sigh. regards, michael -- One of [the Middle Ages'] characteristics was that 'reasoning by analogy' was rampant; another characteristic was almost total intellectual stag- nation, and we now see why the two go together. [...] by developing a keen ear for unwarranted analogies, one can detect a lot of medieval thinking today. -- Edsger W. Dijkstra -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Off the records (Ubuntu's LO) ... (Re: Re: Genuine OOo in distributions ? (Re: OOo installation packages for Linux, a few (easy) questions
Hi Bjoern, On 06.06.2011 12:42, Bjoern Michaelsen wrote: Whatever they did, they probably did what they did with their OOo installation in the past with the effect that using the Java interface from the command line does not work (using their unoinfo-output for Java) ! That has nothing to do with OOo or LibreOffice, it did not work any better with OOo. The root cause is that the bootstrap helper makes quite crazy assumptions about where to find the soffice binary. Debian (and thus Ubuntu) does quite a few changes (for example moving jars around), which the original OOo code does not handle too well. Sorry to correct you: installing the genuine OOo from http://www.OpenOffice.org works. Flawlessly. unoinfo.sh has no role in this at all -- it is not even packaged on Ubuntu. That's one of these amateurish, almost crazy assumptions along the lines: I do not see any use in it, hence let us drop it, it's probably crap anyway. It is almost crazy, because quite a few projects rely on unoinfo supplying the correct CLASSPATH definition for interacting with OOo/LO (the sequence matters), which then simply won't work with the Ubuntu distros. Instead one needs to deinstall LO, remove ~/.libreoffice in home, get the official LO distribution and install it, then things start to work as was the case in the past with OOo. No, you would need to bootstrap with a ClassLoader having a correct resource path. Please, give me a break! Never having seen this being reported against LibreOffice on launchpad, it was assumed as not a serious issue. Who is it? And for what reasons would it assume as not a seriious issue? This is why I qualify such decisions to be amateurish, harming such endeavors enormeously. (Companies affected by the negative outcome of such decisions either turn away or kick out the broken installation.) Whining about it on the mailing list of a different project instead of filing a bug is kind of ridiculous still, isnt it? Whining? This was meant to point out to the OpenOffice.org list that those that have broken OOo for Ubuntu are breaking LO as well! And by the way, if you wanted to be constructive, why did you not supply a link to the place for reporting it? If it was easy to find such a place, I would have reported it (actually I even would report it still as this is a potential problem for quite a few more apps, even if the Ubuntu people are not realizing it, hoping that they are not ignorants). As for my application the workaround is simple: just install the genuine OOo (or LO for that matter) and do not use the broken Ubuntu installation. (Besides, the Ubuntu people broke the user interface with 11.04 bad times, either taking their users hostage for experiments, or having total amateurs in charge for the most important application there exists for an operating system for PC-based end users.) ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: refactoring OUString
On 2011/06/07 0:27, Michael Stahl wrote:
refactoring OUString has to be done carefully because it is a central part
of the URE API/ABI and those must be compatible.
a number of people here have come to the conclusion that it would be an
improvement to use ::rtl::OString with UTF8 encoding as the standard
string type, but unfortunately this would be an enormous effort to change,
and it would mean breaking the backward compatibility of the C++ UNO
binding, so it was never likely to actually happen.
so far we haven't even got rid of the tools strings... sigh.
I see.
This is just an idea. How about adding a new class besides OUString?
class ZString
{
sal_Char*buffer;
sal_Int32 length;
sal_uInt16 type;
rtl_TextEncodingencoding;
oslInterlockedCount refCount;
};
- Gradually shift to the new one ZString, if applicable, in place of OUString
and OString.
- type might be an ID number denoting const char* char * const sal_Unicode
*, ...
- encoding is an encoding id defined in rtl/textenc.h
- refCount, assignment, copy constructor, ... would be done in the same manner.
- No encoding conversion will be done until the conversion is really demanded.
- Use arrays as a memory pool for the fixed-sized structure ZString.
- ...
e.g
1. String literal that is treated as it is
ZString a( xyz );
buffer directly points to xyz
no memory allocation neither data copy is involved until encoding conversion
is demanded.
length is left uninitialized in this case, but will be measured and cached
upon being requested.
type denotes const char*, zero terminated
encoding might be ASCII_US or UTF-8; which might depend on the OS and
compiler.
(debugger) print a.buffer ... prints xyz
2. Receiving a result string from a callee in a storage allocated by alloca()
instead of malloc()
ZString temp( 100, RTL_ALLOCA );
func( temp );
func( ZString x )
{
x = abc;
}
In a destructor of temp above,
if a reference count is 1, nothing special would be done and the allocated
memory in the stack area will be automatically freed upon returning to the
upper frame.
if a reference count is more than 1, then memory allocation and data copy
will be involved.
Best,
Tora
On 06.06.11 16:35, tora - Takamichi Akiyama wrote:
Has anyone tried refactoring OUString?
- It converts iso-8859-1 letters ranging 0x00-0x7f into UCS2 even it is not
necessary.
- It requires malloc(), realloc(), and free() or their equivalents.
- It prevents debugging efforts because of sal_Unicode buffer[1].
- It mixtures different purposes: passing/returning parameters and
long-lasting data.
- and else...
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
[dev] Re: refactoring OUString
On 06.06.2011 18:57, tora - Takamichi Akiyama wrote: On 2011/06/07 0:27, Michael Stahl wrote: refactoring OUString has to be done carefully because it is a central part of the URE API/ABI and those must be compatible. a number of people here have come to the conclusion that it would be an improvement to use ::rtl::OString with UTF8 encoding as the standard string type, but unfortunately this would be an enormous effort to change, and it would mean breaking the backward compatibility of the C++ UNO binding, so it was never likely to actually happen. so far we haven't even got rid of the tools strings... sigh. I see. This is just an idea. How about adding a new class besides OUString? We already have enough string classes. :-) Besides that, you are right, rtl::OUString is stupid. We planned to discuss its replacement in the context of a future OOo 4.0 release, allowing for some incompatibility here. If done properly, the changes would require only recompilation of in-process C++ code. But as you know, we are faced with a completely new situation for the OOo future. So we should postpone discussing this topic until the dust has settled. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: refactoring OUString
On 06.06.2011 18:57, tora - Takamichi Akiyama wrote: This is just an idea. How about adding a new class besides OUString? On 2011/06/07 2:16, Mathias Bauer wrote: We already have enough string classes. :-) Yes, we have! :-) Besides that, you are right, rtl::OUString is stupid. We planned to discuss its replacement in the context of a future OOo 4.0 release, allowing for some incompatibility here. If done properly, the changes would require only recompilation of in-process C++ code. Sounds nice! And also, please cover the underlying memory allocation mechanism which would be another key factor for the performance improvement. One more thing. This might be controversial. But, IMHO, it would be better if a programmer takes care of the life duration of a string instance. Is it for a temporal use, or persistent use? I would like to say the new String class might offer certain ways to take care of its life duration. But as you know, we are faced with a completely new situation for the OOo future. So we should postpone discussing this topic until the dust has settled. Yep, we should postpone this exciting topic! Thank you for your time, Michael, Mathias. Best regards, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: refactoring OUString
On 06.06.2011 19:43, tora - Takamichi Akiyama wrote: And also, please cover the underlying memory allocation mechanism which would be another key factor for the performance improvement. There's an old suggestion to treat small strings differently, see http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance. Niklas -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
