[Libreoffice] MS-Windows : about dictionaries installation
Hi all, Many MS-Windows users are surprised that LibreOffice default installation contains all dictionaries although they have the UI only in their locale and English. I think that default installation should contain only dictionaries in the same languages as the UI. Is it a bug or a feature ? ;-) If it a bug I will file a bug report. If it is a feature, please explain the rationale. Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] In need of windows packaging team...
Changing the installer will invalidate the digital signature so it also is not an option. I won't sign a third party package with my own cert... I can only say, the OpenOffice.org(tm) team did it until 3.3. There aren't many releases of the package considering the huge amount of work involved in every upgrade so they MAY chose to do it once for every language. All I do here is ask... I'm also thinking practically, if neither OpenOffice.org(tm) or LibreOffice(tm) is able or willing to create such a setup, I will evade towards another free text processing package. I'm not a fanboy. :) The goal is to provide students with a FREE CD with FREE software allowing them to study without worrying for the cost. The goal is not provide a CD with OO.o or provide a CD with LO. In the very end everything will work out for the students. ~ms -Original Message- From: Tor Lillqvist [mailto:tlillqv...@novell.com] Sent: Saturday, January 29, 2011 8:24 PM To: Markus Stenzel; libreoffice@lists.freedesktop.org Subject: Re: [Libreoffice] In need of windows packaging team... I am not on the Windows packaging team (but some of my colleagues are), and I can't reply for them. I think some hairy political issues are involved, my personal opinions below... I think a problem here is that if the packaging team would agree to provide you with such a German-only build, people using all other languages would have the same right to ask for one too. And such requests would drop in, one after one, for more or less similar reasons as you cite. Having a multi-lingual installer frees us from building and distributing a complete set of single-language installers, which would take significantly more mirror disk space, longer time to upload and propagate to mirrors, etc. So probably you will need to find some volunteer (or paid consultant) to do such a build for you... It might even be relatively simple to manipulate our multi-lingual installer: remove unneeded files from the CAB file and modify the MSI database file accordingly, and this way construct a single-language installer? Somebody with the necessary skills could do just that and not have to actually build LibreOffice. The binaries would be identical to what we ship, which would be a plus. Or should we have some policy that we do provide such single-language installers, but not to random individuals who ask for them, and not on the web (mirrors), but only on request to bona fide mass re-distributors? Where should we then draw the limit, how many copies does one have to be re-distributing to count as a such? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] In need of windows packaging team...
Changing the installer will invalidate the digital signature so it also is not an option. What digital signature? We don't use any (yet). I won't sign a third party package with my own cert... Oh well, your choice. I can only say, the OpenOffice.org(tm) team did it until 3.3. Yes, but we are not them. I'm also thinking practically, if neither OpenOffice.org(tm) or LibreOffice(tm) is able or willing to create such a setup, I will evade towards another free text processing package. Are you threatening us with not using what we provide for free? How scary. Threats isn't the best way to make people take you seriously and, in many cases, help you on their own spare time. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] In need of windows packaging team...
Threatening? You're kidding right? -Original Message- From: Tor Lillqvist [mailto:tlillqv...@novell.com] Sent: Sunday, January 30, 2011 10:33 AM To: Markus Stenzel; libreoffice@lists.freedesktop.org Subject: RE: [Libreoffice] In need of windows packaging team... Changing the installer will invalidate the digital signature so it also is not an option. What digital signature? We don't use any (yet). I won't sign a third party package with my own cert... Oh well, your choice. I can only say, the OpenOffice.org(tm) team did it until 3.3. Yes, but we are not them. I'm also thinking practically, if neither OpenOffice.org(tm) or LibreOffice(tm) is able or willing to create such a setup, I will evade towards another free text processing package. Are you threatening us with not using what we provide for free? How scary. Threats isn't the best way to make people take you seriously and, in many cases, help you on their own spare time. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
Is it a bug or a feature ? It is a feature until somebody provides working code to do otherwise, and explains why it is better. It is an useful feature, even. See below. Are you suggesting that we should automatically in a de-select the writing aids for languages that don't get the UI installed? That might sounds sensible at first, but is actually rather naïve. These scenarios are very common, I think: 1) People use the UI in English because localisation to their own language sounds just weird to them, or is downright buggy, but still want to edit documents written in their own language, and that language is one that has a dictionary included in the installer. 2) People use the UI in their own language but still want to edit documents in a foreign language they are learning, or use in their work, and that language is one that has a dictionary included in the installer. I would guess that this is a very common scenario. I think what you are seeing is just people expecting nothing to change from how OpenOffice.org did it. But if nothing would change, what would be the point with LibreOffice? To many people in the above scenarios it should be seen as a *useful feature* that they don't have to separately download writing aids for each language they want to write in. (Assuming that language is one of the ones that have bundled writing aids.) After all, in other cases people are complaining loudly that they have to do a separate download and install of local on-disk help. So in that case separate downloads/installers for additional functionality is bad, but in the dictionary case good? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Need of review
Hello good people, could someone review and cherry-pick for libreoffice-3-3 branch with -s option this commit http://cgit.freedesktop.org/libreoffice/filters/commit/?id=c90c5d503543a960a05b43752a5dff9ccf4bcd30 ? It basically silences warnings of casts from double to float since libwpd's API does not use float, but double since 0.9.0 Cheers F. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
On Sun, Jan 30, 2011 at 9:19 AM, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: Hi all, Many MS-Windows users are surprised that LibreOffice default installation contains all dictionaries although they have the UI only in their locale and English. I think that default installation should contain only dictionaries in the same languages as the UI. Is it a bug or a feature ? ;-) If it a bug I will file a bug report. If it is a feature, please explain the rationale. Doesn't work in places where you have more than one official language. You need dictionaries in several languages, not only the one of your UI. Cheers, -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] In need of windows packaging team...
Threatening? You're kidding right? That's how it sounded to me. If you don't do this, I won't use your software, neener neener --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Should the Thesaurus/mythes use a precomputed index (installer file size)
Hi Michael,
On 29 January 2011 21:45, Steve Butler sebut...@gmail.com wrote:
I thought I would discuss your idea about not using the index at all
to see what reception it gets, but I think you may also have been
suggesting a similar thing:
are the index files even useful on modern gear?
I can populate the en_US index in memory from the .dat file with the
C++ code in 0.287 s after dropping all cache, and 0.188s when the
cache is hot.
I do admit that my desktop is pretty quick though, with 4 cores, SATA
II drives etc.
I have plugged the idxdict.cpp code (modified) into the mythes index
loader and made it load from the .dat file directly. The index file
is no longer touched.
Here's some comparison timings on the above system (measured with
gettimeofday either side of the call in swriter).
Using an INDEX FILE:
US Thesaurus - cold OS cache
2011/01/30 04:21:37.887449: Loaded in 0.097378 seconds.
US Thesaurus - hot OS cache
2011/01/30 04:22:37.338682: Loaded in 0.044813 seconds.
USING NO INDEX FILE:
US Thesaurus - cold OS cache
2011/01/30 10:07:42.186452: Loaded in 0.253337 seconds.
US Thesaurus - hot OS cache
2011/01/30 10:08:01.737888: Loaded in 0.130883 seconds.
As can be seen from these numbers, it is around 3x slower for the US
thesaurus regardless of hot/cold cache.
BTW, if I did that I'd probably do some major surgery on mythes and
just use STL because it basically is doing C style memory management
and processing and I think I would screw it up if I started messing
with it. The only problem with simplifying it with STL constructs is
that I would want to change the interface (string vs char *), maybe
use STL vectors for the list of synonyms, etc.
I've kept the public interface of mythes the same with my changes (but
the index file name in the constructor is ignored), apart from this
one:
const char* get_th_encoding();
I didn't change the mentry struct or code dealing with reading an
entry from the dat file at all. The offset is loaded straight from
the std::map by word lookup but then falls back to the mythes C style
code.
It might be possible to make the index creation run quicker by
avoiding use of so many std::strings but I probably wouldn't do this
as it will make it harder to understand.
I did remove some private member functions that were no longer needed,
and some private data is now using std::string and std::map (as
per idxdict).
Now, assuming anyone thinks this is a good idea and the tradeoff of
initial lookup speed vs installation size is appropriate, I would
appreciate pointers as to how we would go about packaging up such a
change when it is completely isolated to messing about with 3rd party
source. Naturally if this approach was selected then building the
.idx files and adding them to the language pack zips would need to be
removed. A further option could be to have it use idx files if they
exist, but fallback to using only the .dat files.
Changes are LGPLv3+,MPL licensed. I've attached the two altered files
here in case anyone wants to have a look and provide feedback on the
approach.
As this is simply proof of concept for the timing, I haven't tested
against memory leaks or corruption of data yet.
I'm also not sure how to format it as the original code is not well formatted.
Regards,
Steven Butler
#ifndef _MYTHES_HXX_
#define _MYTHES_HXX_
// some maximum sizes for buffers
#define MAX_WD_LEN 200
#define MAX_LN_LEN 16384
// a meaning with definition, count of synonyms and synonym list
struct mentry {
char* defn;
int count;
char** psyns;
};
#include iostream
#include fstream
#include string
#include map
typedef std::mapstd::string, long WordLocationMap;
class MyThes
{
std::string encoding; /* stores text encoding; */
WordLocationMap wordList;
FILE *pdfile;
// disallow copy-constructor and assignment-operator for now
MyThes();
MyThes(const MyThes );
MyThes operator = (const MyThes );
public:
MyThes(const char* idxpath, const char* datpath);
~MyThes();
// lookup text in index and return number of meanings
// each meaning entry has a defintion, synonym count and pointer
// when complete return the *original* meaning entry and count via
// CleanUpAfterLookup to properly handle memory deallocation
int Lookup(const char * pText, int len, mentry** pme);
void CleanUpAfterLookup(mentry** pme, int nmean);
const char* get_th_encoding();
private:
// Open index and dat files and load list array
int thInitialize (const char* indxpath, const char* datpath);
// internal close and cleanup dat and idx files
int thCleanup ();
/*
// read a text line (\n terminated) stripping off line terminator
int readLine(FILE * pf, char * buf, int nc);
// binary search on null terminated character strings
int binsearch(char * wrd, char* list[], int nlst);
*/
};
#endif
#include COPYING
#include stdio.h
Re: [Libreoffice] MS-Windows : about dictionaries installation
Yes, but why ~20 dictionaries ? Do you know peoples who need and are able to write twenty different languages ? Why not? What does it hurt? (It is always possible to do a custom installation and deselect those dictionaries one doesn't want.) Can you come up with an algorithm for de-selecting some dictionaries that would work well enough to be useful? De-selecting every dictionary except those for the UI languages being installed is not good, as I tried to show in my two scenarios. So, maybe something like OK, so everybody needs English, right. And French, the language of Diplomacy, surely. And all the languages spoken in their country. And languages typically taught in school there. And the languages of their neighbouring countries, except of course for politically sensitive cases, I probably don't need to bring up concrete examples. ? You honestly think such a heuristic would be possible to implement reliably without causing a lot of hurt national pride, claims of cultural imperialism, etc? It is better to in a typical installation just install all the included dictionaries included without any guesswork. Otherwise some users would no doubt get offended by us hinting that they need a dictionary for a language they don't want, but don't need one they do want... Sounds like a sure way to get flamed and perhaps even banned in some countries... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Should the Thesaurus/mythes use a precomputed index (installer file size)
On Sun, Jan 30, 2011 at 4:32 AM, Steve Butler sebut...@gmail.com wrote: Hi Michael, On 29 January 2011 21:45, Steve Butler sebut...@gmail.com wrote: Here's some comparison timings on the above system (measured with gettimeofday either side of the call in swriter). Using an INDEX FILE: US Thesaurus - cold OS cache 2011/01/30 04:21:37.887449: Loaded in 0.097378 seconds. US Thesaurus - hot OS cache 2011/01/30 04:22:37.338682: Loaded in 0.044813 seconds. USING NO INDEX FILE: US Thesaurus - cold OS cache 2011/01/30 10:07:42.186452: Loaded in 0.253337 seconds. US Thesaurus - hot OS cache 2011/01/30 10:08:01.737888: Loaded in 0.130883 seconds. As can be seen from these numbers, it is around 3x slower for the US thesaurus regardless of hot/cold cache. [...] Now, assuming anyone thinks this is a good idea and the tradeoff of initial lookup speed vs installation size is appropriate, I would appreciate pointers as to how we would go about packaging up such a change when it is completely isolated to messing about with 3rd party source. Naturally if this approach was selected then building the .idx files and adding them to the language pack zips would need to be removed. A further option could be to have it use idx files if they exist, but fallback to using only the .dat files. I have only skimmed this thread, so forgive me if i missed the mark but: why not generate the index at install time ? that will still achieve the goal of reducing the size of the installer, without the performance hit at runtime no? Norbert Regards, Steven Butler ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Should the Thesaurus/mythes use a precomputed index (installer file size)
Hi Norbert, I have only skimmed this thread, so forgive me if i missed the mark but: why not generate the index at install time ? that will still achieve the goal of reducing the size of the installer, without the performance hit at runtime no? The option to build the index at install time was also discussed and was the original goal, and has definitely not been ruled out. My understanding Michael was not keen to do this on Linux, but keen to try it in the Windows Installer. From my perspective it was a lot easier to patch some code into something I could test (mythes) than something I could not (the windows installer), so I thought I'd start with an easier option. It is important to keep in mind that the performance hit is once off per instance of swriter, and happens the first time you right click on a word in a specific language. With this implementation, once this is done, the whole index is cached in an STL map so performance should be around the same as before (lookup a word in an STL Rbtree vs a binary search on a char ** structure). It would also be possible to generate a dictionary index on first use, but of course that would mean having to generate an index per user so I'm not entertaining that idea seriously. Regards, Steven Butler ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
Le 30/01/2011 10:49, Tor Lillqvist a écrit : Is it a bug or a feature ? It is a feature until somebody provides working code to do otherwise, and explains why it is better. Which software is used to do the MS-Windows installer ? It is an useful feature, even. See below. Are you suggesting that we should automatically in a de-select the writing aids for languages that don't get the UI installed? That might sounds sensible at first, but is actually rather naïve. These scenarios are very common, I think: 1) People use the UI in English because localisation to their own language sounds just weird to them, or is downright buggy, but still want to edit documents written in their own language, and that language is one that has a dictionary included in the installer. 2) People use the UI in their own language but still want to edit documents in a foreign language they are learning, or use in their work, and that language is one that has a dictionary included in the installer. I would guess that this is a very common scenario. Yes I agree. But the scenario where the user need only one or two dictionaries, is certainly far more common. I think what you are seeing is just people expecting nothing to change from how OpenOffice.org did it. But if nothing would change, what would be the point with LibreOffice? Probably, but we need reassure the users who think to switch from OOo to LibO. To many people in the above scenarios it should be seen as a *useful feature* that they don't have to separately download writing aids for each language they want to write in. (Assuming that language is one of the ones that have bundled writing aids.) After all, in other cases people are complaining loudly that they have to do a separate download and install of local on-disk help. So in that case separate downloads/installers for additional functionality is bad, but in the dictionary case good? Yes because installation of new dictionaries as extensions is, as far as can see on forums and lists, a well known procedure. Adding the fact that LibO migrate OOo profiles to LibO, the user who switch from OOo to LibO has already its own dictionaries. Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
Le 30/01/2011 12:29, Tor Lillqvist a écrit : Yes, but why ~20 dictionaries ? Do you know peoples who need and are able to write twenty different languages ? Why not? What does it hurt? (It is always possible to do a custom installation and deselect those dictionaries one doesn't want.) Can you come up with an algorithm for de-selecting some dictionaries that would work well enough to be useful? De-selecting every dictionary except those for the UI languages being installed is not good, as I tried to show in my two scenarios. No, no need for an algorithm. No need to remove a dictionary from the installer. Only ask the user what he want to have on his computer. Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
On Sun, Jan 30, 2011 at 6:03 AM, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: In my message, the problem is not the size of the installer, it is about the number of dictionaries the MS-Win end-user has on his PC. Many of these dictionaries being not useful for him. Is there a severe disk-shortage issue on MS-windows, that make a few MB of dictionary a problem ? Considering that a naked w7-pro install is already in the 15-20GB range I find it hard to believe. if not then this boils down to: make the install longer, more complex and bug everybody with yet-another-panel of questions and maybe save few MB of footprint or keep it simple and possibly 'waste' as a little of disk. I favor the later. Norbert Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
No, no need for an algorithm. No need to remove a dictionary from the installer. Only ask the user what he want to have on his computer. Try clicking the custom installation button. But note that it is a fallacy to think that just because *some* features (like dictionaries for individual languages) have been split out as individually selectable in the installer, the user would really have the full choice of what he wants on his computer... What about all the functionality of LibreOffice that I never use. Like, say, sending a document as email directly from LibreOffice. I never use that. Still it is always there on my computer! Should I complain that nobody asked me if I want that on my computer? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] MS-Windows : about dictionaries installation
Le 30/01/2011 13:34, Norbert Thiebaud a écrit : On Sun, Jan 30, 2011 at 6:03 AM, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: In my message, the problem is not the size of the installer, it is about the number of dictionaries the MS-Win end-user has on his PC. Many of these dictionaries being not useful for him. Is there a severe disk-shortage issue on MS-windows, that make a few MB of dictionary a problem ? Considering that a naked w7-pro install is already in the 15-20GB range I find it hard to believe. No the problem is not there. It is in the long list of useless extensions / dictionaries in the Extensions Manager. Many users are afraid when they see this list. End-user want to have the choice. But, he does not want to look a little beyond the default installation. In fact, very often, he does not read what is written on his screen. But he want have all administrative rights on his computer. It is not an adult behaviour but it is a fact. :-( if not then this boils down to: make the install longer, more complex and bug everybody with yet-another-panel of questions and maybe save few MB of footprint or keep it simple and possibly 'waste' as a little of disk. I favor the later. I agree (I always do a custom installation ;-) ), but how to make the end-user understand that? JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] Fix wrong collation for Catalan language
Hello good people and others, Could someone please review and cherry-pick for libreoffice-3-3 branch this commit: http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=affa15b894b66b3d12d00ab1ad3c567ade88800e It basically fixes the collation for Catalan language, so it's important :) Cheers, -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] A file to show 8192 discontinuities crashes Calc
On 29/01/2011 04:10, r_ouellette wrote: I checked with LO 3.3 final version (RC4) and the problem remains... It is a regression from previous OpenOffice.org (before LO) where the file was correctly calculated. Using your test file from OOo bug, i've seen it doesn't hang but it's terrible slow. Also, i've seen other problem with the filter, so i've decided to file a bug: https://bugs.freedesktop.org/show_bug.cgi?id=33720 Ciao. Cesare. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] refactoring gendict
On Sun, Jan 30, 2011 at 7:35 AM, Kenneth Venken kenneth.ven...@gmail.com wrote: what's the point passing cont as a parameter if you are going to override it's value right away ? (note: ok so, patch 0005 actually fix that...) these patches should be viewed as a wholel. The refactoring was a process. But you're wright. Well you broke down the refactoring into multiple step, which is very good since it make reviewing so much easier, but then I reviewed them one a the time not as a whole. In a perfect world (and in reality - in the linux kernel world) each sucessive patch should yield a build-able and functional code. You almost did that with this patch series :-) luckily this is not possible since utf16 characters in the range D800-DBFF are not supported/valid see http://en.wikipedia.org/wiki/UTF-16/UCS-2 for a reason why. so you will have, at least, 4 ranges without any hit. So It is not possible to encode these code points in UTF-16. The Unicode standard permanently reserves these values for UTF-16 encoding only, so a single 16-bit code unit in the range 0xD800 to 0xDFFF never represents a character in Plane 0. But since we are using the UTF-16 encoding, it could be possible that a sal_Unicode value (a unicode code unit) is in this range. See section about Code points U+1..U+10 in the link you sent me. Yeah, but the truth is that we do not _really_ support utf16, for instance the length of an OUString is the number of 16bits values not the number of 'characters' iow, a surrogate pair is 1 character but would have a length of 2 in OUString. all that being said, yes the case you mentioned it is a bug that should probably be fixed. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Upgrade packages for windows
Hi This might be the correct list to post this: A microsoft fanboy/employee complains on a norwegian discussion site that you have to download the whole openoffice to upgrade or to fix problems (guess this applies to libreoffice too) That is, he's complaining that to go from 3.2 to 3.2.1 he had to download the whole installer and run it. Someone pointed out that on linux, the distribution is (can be) package-based, so that he would avoid that. Now, is it possible/interesting to have such a feature, that people can download fixes (Microsoft would call them hotfixes) to Libreoffice? To me it looks a bit ugly, but it could be just a question of replacing the binaries/files that differ from last version. I don't know enough about this to say if it's a Good Idea or a Bad Idea (tm) [The microsoft guy didn't mention whether you need to download the whole thing when you upgrade office, nor if you have to pay, nor the MS office installer size: some 500M just for the student edition] just a few of my cents, best Arno signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
On Sun, Jan 30, 2011 at 10:44 PM, Arno Teigseth arnot...@gmail.com wrote:
A microsoft fanboy/employee complains on a norwegian discussion site
that you have to download the whole openoffice to upgrade or to fix
problems
+1
I agree that the idea making small patch / bug fix / enhancement and a
service pack
is more convenient for the users.
--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng )
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
Now, is it possible/interesting to have such a feature, that people can download fixes (Microsoft would call them hotfixes) to Libreoffice? hotfixes are a completely different technology, not suitable for upgrades of large complex software libe OOo or LibreOffice at all. What exists, and could in theory be used, is Windows Installer patches (.msp files). But, they are so horribly hard to produce and get to work reliably (trust, me, I have been there, done that, got the t-shirt) that we don't want to. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
On Sun, 2011-01-30 at 09:25 -0700, Tor Lillqvist wrote: Now, is it possible/interesting to have such a feature, that people can download fixes (Microsoft would call them hotfixes) to Libreoffice? hotfixes are a completely different technology, not suitable for upgrades of large complex software libe OOo or LibreOffice at all. What exists, and could in theory be used, is Windows Installer patches (.msp files). But, they are so horribly hard to produce and get to work yea? reliably oh. Yes that would be an issue ;) I had the same feeling from just looking at my cow-orkers' windows computers, with updates failing and breaking everything, leaving you worse off than before. I guess it would be different if the whole windows system was set up with packages, with version controls and this-package-depends-on stuff. And real super-user privileges that normal lusers could not take on... best Arno signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Error with some dokuments under Windows
Hey, I have found a strange bug. I don't know where there is the right place, so I put it here. I have an document written in MS Office 2007 (docx) witch can't be opened in SOME cases: - Opening it in LibreOffice 3.3 (or OO.org 3.3 RC 9) under Linux = works well - Opening it in OpenOffice 3.2 under Windows = works well - Opening it in LibreOffice 3.3 under Windows, the window beeing maximized = Empty Document, LibreOffice behaves strange - Opening it in LibreOffice 3.3 under Windows, not maximised = Document is showed right, when maximizing the window LibreOffice crashes Opening it in Libre/OpenOffice under Linux and saving it as .doc or as ODF don't change anything. The error still occurs. Opening it in MS Office 2007 and exporting it to ODF or .doc, also didn't change anything. I've testet it with two different windows-computers. (plus 1 linux PC) The one PC has Windows XP, the other Windows 7. Both have LibreOffice 3.3 german. I think this bug is quite strange and annoying. Hope it can be fixed. I don't want to upload or mail around the file but I'd give it to a developer. Best regards, Michael Schönitzer -- Michael F. Schönitzer Mail: michael ät schoenitzer.de Homepage: http://www.schoenitzer.de Jabber: schoenit...@jabber.piratenpartei.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] cpp cleanliness: fixed some memleaks binfilter
On 01/29/11 14:35, Kenneth Venken wrote: 2011/1/28 Michael Meeks michael.me...@novell.com Hi there, On Thu, 2011-01-27 at 20:55 +0100, Kenneth Venken wrote: these patches remove some comments from ./filters/binfilter/bf_svx/source/editeng/svx_editobj.cxx and I've pushed these two. fixes two memleaks. But this third one looks more problematic to me (at least on the surface) :-) We allocate pC and then store its pointer in aContents (cf. CreateAndInsertContent) - right ? surely they are freed by DeleteContents called from the destructor ? your right. I guess this is a cppcheck false positive. Thanks though, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Kenneth, Please report this false positive to cppcheck's upstream bug db, so it will be fixed for them and for us. :) Thanks, Jesse Adelman Senior Linux Systems Administrator, ilikelinux Consulting (http://www.ilikelinux.com/) Bold and Busted LLC (http://www.boldandbusted.com/) Brisbane, CA ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Error in en_us readme file ?
Hi, Received a message from a user today regarding the install instructions within the en_US readme file covering Mandriva: 'Doing commands like su urpmi *.rpm won't work; it either has to be sudo urpmi *.rpm or su -c urpmi *.rpm' I have never used Mandriva so don't know and thought I'd ask before just opening a bug report for him. Thanks Drew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error in en_us readme file ?
2011.01.30. 19:53 keltezéssel, drew írta: Hi, Received a message from a user today regarding the install instructions within the en_US readme file covering Mandriva: 'Doing commands like su urpmi *.rpm won't work; it either has to be sudo urpmi *.rpm or su -c urpmi *.rpm' su urpmi is definitely wrong. What would be better on Mandriva, sudo or su -c? BTW please notify me when you fix this, because all localizations should be updated. Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] git submodule
Hi, is there a reason why you don't use git submodule for managing the other repos in the build repo? Greetings Tobias ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kicking off 3rdparty packages
On Sat, 2011-01-29 at 14:00 +0100, Enrico Weigelt wrote: Hi folks, one of the things which always unnverved me most in OO is the fact that it ships own copies of dozens of standard 3rd-party packages, often very outdated and patched-to-death. For a distro build configuring with --with-system-libs will generally do-the-right-thing. For a universal Linux build that has to run everywhere we can probably at this stage definitely default to --with-system zlib, jpeg and some other ones where the ABI have been stable for yonks and are ubiquitous. The clone dirs are split into libs-extern and libs-extern-sys, I imagine the thinking at the moment is that one ones in libs-extern-sys are the ones that would reasonably be expected to be preinstalled these days, though f.e. a) hunspell sometimes changes its ABI to an Libo build against one version of it may not be able to run against another. b) major version of icu always change their ABI, so a Libo build against one e.g. icu 4.4 will not work if deployed against 4.2 etc. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: cppcheck clean ups
On Sat, 2011-01-29 at 18:03 +, Andy Holder wrote: More simple cpp check clean ups. All looks good, thanks for these, pushed. The methods whose return values were taken but unused don't seem to have any other side effects so appears that removing them, rather than just not taking their return val, is the right course of action in this case alright. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Easy hacks: removed double line spacing (and some dead code)
On Sat, 2011-01-29 at 22:30 +0100, Christina Roßmanith wrote: Hi, I'll strike out the files I've fixed on the list. Pushed, thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kicking off 3rdparty packages
* Tor Lillqvist tlillqv...@novell.com schrieb: Please, are you talking about third-party source code included in the LibreOffice source code (git repositories), source code downloaded as part of the build process (unless one tells it to use a system library), or binaries from either of those included in a binary package? Or all of these? *All* source packages. Binariy packages are an entirely different issue, as they're always generated for a specific platform (eg. for old legacy platforms w/o proper package management, it's easy to set up an minimal solution that pulls together everything into a superbig selfcontained binpkg). Up-to-date software can also be used on old Unixes / Linux systems without too much pain. Sure, as long as you know what you are doing and packages from various 3rd-party repositories (or self-built) are in sync with what LibreOffice expects. It's all about proper interfaces. Just always sit on the recent stable interfaces and install missing packages when necessary. But I do think that somebody running some random old Unix box would prefer to get an all-inclusing LibreOffice package. As said above: code some little glue scripts which create some prefix installation image. Instead of complex advice like additionally you should install foolib from this site, but be careful not to let it overwrite the binary incompatible build of foolib from this other site that you might have already No, simply state the depencies and let the distros handle the rest. For old legacy systems, simply create an own micro-distro. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kicking off 3rdparty packages
* Francois Tigeot ftig...@wolfpond.org schrieb: Should LO be including 3rd party software to facilitate the work of people who don't know what they are doing ? At the cost of everybody else ? (from devs through package/dist maintainers to end users who all have to waste lots of their resources) But I do think that somebody running some random old Unix box would prefer to get an all-inclusing LibreOffice package. Who are these people ? Do they really exist ? Yes, where do they live ? In some deep caves or on high mointains ? I'd really like to know some of these guys ... ;-o All live platforms have to be proactive in managing software; if you decide to freeze some old version of a third-party library or program and include it in LO, this software will suffer from bit-rot, accumulate uncorrected bugs and security issues. You may try to patch it yourself, but this will increase your work and become unsustainable after a while. In the end, LibreOffice will become a worse product. That's exactly one of the _major_ problems that made OO so bad and kept possible devs (including myself) away. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED, partial] Re: [PATCH] removed lots of commented #defines, N's and ?'s
On Sat, 2011-01-29 at 22:44 +0100, Christina Roßmanith wrote: ... forgot to attach the patch in my previous posting. Pushed the removal of unused headers. I'm sort of wary, against the removal of the admittedly odd /*N*/, /*?*/ lines in binfilter because a) there are *so* many of them b) there have some vague meaning in that the /*?*/ lines indicate code that might be removed, while /*N*/ suggest it can't be removed. This hideous binfilter is an old snapshot of the major apps theoretically clipped down the bits needed to import and export the old = StarOffice 5.X binary file formats. Its really all dead code :-), there's some work underway to remove the export functionality entirely. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Problem in module bean
On Sat, 2011-01-29 at 22:49 +, Wols Lists wrote: Just done a ./g pull -r followed by make, and I'm getting the following :-( do a export VERBOSE=true and follow the build how-to at the end of the message and post that data what this suggests is that the dir with libjawt.so in it is not in your SOLARLIB list set in Linux*.Set.sh created from set_soenv from set_soenv.in It *might* help to force re-running configure, etc. In a clean shell try touch configure.in make and see if that makes a difference. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Easy hacks: removed double line spacing
Hi,
lines already striked out in the list.
Christina
From c81b66bcbbb4179d64815ecdcc744267c8e999af Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Sun, 30 Jan 2011 22:23:57 +0100
Subject: [PATCH] Easy hacks: removed double line spacing
---
.../source/config/svt_extendedsecurityoptions.cxx | 16 -
.../bf_svtools/source/config/svt_moduleoptions.cxx | 21 +---
.../source/config/svt_securityoptions.cxx | 34 +++-
.../bf_svtools/source/config/svt_viewoptions.cxx | 11 --
.../filter/source/bf_migrate/bf_migratefilter.cxx | 13 +---
5 files changed, 15 insertions(+), 80 deletions(-)
diff --git a/binfilter/bf_svtools/source/config/svt_extendedsecurityoptions.cxx b/binfilter/bf_svtools/source/config/svt_extendedsecurityoptions.cxx
index d0f40f0..54ff579 100644
--- a/binfilter/bf_svtools/source/config/svt_extendedsecurityoptions.cxx
+++ b/binfilter/bf_svtools/source/config/svt_extendedsecurityoptions.cxx
@@ -34,27 +34,16 @@
//_
#include bf_svtools/extendedsecurityoptions.hxx
-
#include unotools/configmgr.hxx
-
#include unotools/configitem.hxx
-
#include tools/debug.hxx
-
#include com/sun/star/uno/Any.hxx
-
#include com/sun/star/uno/Sequence.hxx
-
#include tools/urlobj.hxx
-
#include tools/wldcrd.hxx
-
#include rtl/ustrbuf.hxx
-
#include bf_svtools/pathoptions.hxx
-
#include hash_map
-
#include rtl/logfile.hxx
#include itemholder1.hxx
@@ -75,14 +64,10 @@ namespace binfilter
//_
#define ROOTNODE_SECURITYOUString(RTL_CONSTASCII_USTRINGPARAM(Office.Security))
-
#define SECURE_EXTENSIONS_SET OUString(RTL_CONSTASCII_USTRINGPARAM(SecureExtensions))
#define EXTENSION_PROPNAMEOUString(RTL_CONSTASCII_USTRINGPARAM(/Extension))
-
#define PROPERTYNAME_HYPERLINKS_OPEN OUString(RTL_CONSTASCII_USTRINGPARAM(Hyperlinks/Open))
-
#define PROPERTYHANDLE_HYPERLINKS_OPEN 0
-
#define PROPERTYCOUNT 1
//_
@@ -201,7 +186,6 @@ class SvtExtendedSecurityOptions_Impl : public ConfigItem
private:
OUString m_aSecureExtensionsSetName;
OUString m_aExtensionPropName;
-
SvtExtendedSecurityOptions::OpenHyperlinkMode m_eOpenHyperlinkMode;
sal_Boolm_bROOpenHyperlinkMode;
ExtensionHashMapm_aExtensionHashMap;
diff --git a/binfilter/bf_svtools/source/config/svt_moduleoptions.cxx b/binfilter/bf_svtools/source/config/svt_moduleoptions.cxx
index 9fbcf51..1b450c2 100644
--- a/binfilter/bf_svtools/source/config/svt_moduleoptions.cxx
+++ b/binfilter/bf_svtools/source/config/svt_moduleoptions.cxx
@@ -28,42 +28,26 @@
// MARKER(update_precomp.py): autogen include statement, do not remove
-//_
+//___
// includes
-//_
+//___
#include bf_svtools/moduleoptions.hxx
-
#include comphelper/sequenceashashmap.hxx
-
#include unotools/configmgr.hxx
-
#include unotools/configitem.hxx
-
#include unotools/processfactory.hxx
-
#include osl/diagnose.h
-
#include rtl/ustrbuf.hxx
-
#include rtl/logfile.hxx
-
#include com/sun/star/uno/Any.hxx
-
#include com/sun/star/uno/Sequence.hxx
-
#include com/sun/star/beans/PropertyValue.hpp
-
#include com/sun/star/container/XNameAccess.hpp
-
#include com/sun/star/lang/XMultiServiceFactory.hpp
-
#include com/sun/star/lang/XServiceInfo.hpp
-
#include com/sun/star/document/XTypeDetection.hpp
-
#include com/sun/star/util/XStringSubstitution.hpp
-
#include itemholder1.hxx
//_
@@ -76,7 +60,6 @@ namespace css = ::com::sun::star;
namespace binfilter
{
-
//_
// const
//_
diff --git a/binfilter/bf_svtools/source/config/svt_securityoptions.cxx b/binfilter/bf_svtools/source/config/svt_securityoptions.cxx
index 478c7b5..7dc325e 100644
--- a/binfilter/bf_svtools/source/config/svt_securityoptions.cxx
+++ b/binfilter/bf_svtools/source/config/svt_securityoptions.cxx
@@ -33,25 +33,15 @@
[Libreoffice] [PUSHED] Re: [PATCH] Cpp Cleanliness: unread variable
On Sun, 2011-01-30 at 01:11 +0100, Kenneth Venken wrote: hi, this removes unread variable pTargetPage from ./impress/sd/source/core/drawdoc2.cxx It does, but do we know for a fact that it should be -pTargetPage = GetSdPage(nPage, PK_STANDARD); and not -pTargetPage = GetSdPage(nPage, PK_STANDARD); +GetSdPage(nPage, PK_STANDARD); i.e. it might be that GetSdPage has some vital side-effects and that the call should remain, and only the return value should be discarded. Anyway reading through it, SdDrawDocument::GetSdPage is defined as a const method, so it *claims* to have no side-effects, though it calls into some stuff that creates the page on demand apparently, though there's already another call in the ::MovePages function being changed that goes through the same on-demand loader, so yeah, the patch *surely* is the right one :-) Thanks for this, now pushed. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kicking off 3rdparty packages
* Caolán McNamara caol...@redhat.com schrieb: For a distro build configuring with --with-system-libs will generally do-the-right-thing. What happens when the software depends on some ancient, long solved bug that's maybe still in the old bundled version ? You'll have to support both the ancient bundled and the current deps, which over time increases maintenance overhead exponentially. For a universal Linux build that has to run everywhere we can probably at this stage definitely default to --with-system zlib, jpeg and some other ones where the ABI have been stable for yonks and are ubiquitous. Is there any reason to have to still carry around ancient buggy bundled zlib ? Look, the generic case is a system which already has the required libs installed (or allows to install them trivially). Old legacy platforms are the specific cases. For those cases you can add some script that does a prefix build/install of the missing packages before building LO itself, and then creates a selfcontained blob package. The clone dirs are split into libs-extern and libs-extern-sys, I imagine the thinking at the moment is that one ones in libs-extern-sys are the ones that would reasonably be expected to be preinstalled these days, though f.e. Seems so. For example, openssl can be expected to exist on any sane system in our scope. And here it is *IMPORTANT* to use an up-to-date version. As an enterprise operator, I'd *NEVER* install any package that brings it's own (outdated) openssl copy, for essential security reasons. a) hunspell sometimes changes its ABI to an Libo build against one version of it may not be able to run against another. Always rebuild on the individual target distro's latest stable line. Modern distros support MVCC installations for such cases or have other mechanisms for solving such problems. b) major version of icu always change their ABI, so a Libo build against one e.g. icu 4.4 will not work if deployed against 4.2 etc. Exactly the case for an MVCC installation. Quite common, boring topic. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH: 2] Cpp Cleanliness: unread variable
On Sun, 2011-01-30 at 01:35 +0100, Kenneth Venken wrote: Hi, this removes the unreadVariable lame_frame_size in ./filters/filter/source/flash/swfwriter.cxx lame_get_framesize seems to have no side-effects, so can be removed entirely rather than just discard its unused return value. Yup, thanks for this, pushed. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need of review
On Sun, 2011-01-30 at 10:51 +0100, Fridrich Strba wrote: Hello good people, could someone review and cherry-pick done. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
* Arno Teigseth arnot...@gmail.com schrieb: I guess it would be different if the whole windows system was set up with packages, with version controls and this-package-depends-on stuff. And real super-user privileges that normal lusers could not take on... I really wonder why Windows still has no proper package management. There has to be a dawn hard reason, or is it just collective insanity ? ;-o cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
* Arno Teigseth arnot...@gmail.com schrieb: Someone pointed out that on linux, the distribution is (can be) package-based, so that he would avoid that. ACK. But that still requires some refactoring of the whole build process. See the thread on removing 3rdparty packages as a first start. For old legacy platforms like Windows, prefix distros frameworks like cygwin could be used. Now, is it possible/interesting to have such a feature, that people can download fixes (Microsoft would call them hotfixes) to Libreoffice? To me it looks a bit ugly, but it could be just a question of replacing the binaries/files that differ from last version. I don't know enough about this to say if it's a Good Idea or a Bad Idea (tm) Inherently unreliable. The only thing you *could* do is to compare the generated files and only ship those which did. But I really doubt that even the exact source code will produce bit-equal binaries. So you'd need some check whether certain files/modules are functionally equavent (sorting out which changed in in interface or semantics). Ends up in turing-weight complexity ... ;-o cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Fwd: [PATCH] Easy hacks: remove double line spacing]
Can someone explain me why my patch has not been pushed ?
If I were wrong somewhere, I don't want to make the same mistake twice.
It was my first (really easy/small) patch, to learn how to procede fine.
---BeginMessage---
Hi, I removed some empty lines in few files for my first patch.
I'll continue if it's ok.
Regards
Guillaume
From b4a7a9c01d535e6e0ab0c8324458494bcd757409 Mon Sep 17 00:00:00 2001
From: Guillaume Fillol guillaume.fil...@lello.fr
Date: Sat, 29 Jan 2011 00:14:19 +0100
Subject: [PATCH] Easy hacks: remove double line spacing
---
binfilter/bf_xmloff/source/draw/ximpshap.hxx | 11 +-
.../bf_xmloff/source/draw/xmloff_sdpropls.cxx | 39 +---
.../bf_xmloff/source/draw/xmloff_sdxmlimp.cxx | 21 ---
.../text/xmloff_XMLTrackedChangesImportContext.cxx | 10 -
4 files changed, 2 insertions(+), 79 deletions(-)
diff --git a/binfilter/bf_xmloff/source/draw/ximpshap.hxx b/binfilter/bf_xmloff/source/draw/ximpshap.hxx
index 6001284..d5b5079 100644
--- a/binfilter/bf_xmloff/source/draw/ximpshap.hxx
+++ b/binfilter/bf_xmloff/source/draw/ximpshap.hxx
@@ -30,26 +30,17 @@
#define _XIMPSHAPE_HXX
#include com/sun/star/io/XOutputStream.hpp
-
#include com/sun/star/document/XActionLockable.hpp
-
#include com/sun/star/container/XIdentifierContainer.hpp
-
#include xmlictxt.hxx
-
#include sdxmlimp_impl.hxx
-
#include nmspmap.hxx
-
#include com/sun/star/drawing/XShapes.hpp
-
#include com/sun/star/text/XTextCursor.hpp
-
#include com/sun/star/awt/Point.hpp
-
#include tools/rtti.hxx
-
#include xexptran.hxx
+
namespace binfilter {
//
diff --git a/binfilter/bf_xmloff/source/draw/xmloff_sdpropls.cxx b/binfilter/bf_xmloff/source/draw/xmloff_sdpropls.cxx
index 2df127d..6987079 100644
--- a/binfilter/bf_xmloff/source/draw/xmloff_sdpropls.cxx
+++ b/binfilter/bf_xmloff/source/draw/xmloff_sdpropls.cxx
@@ -31,81 +31,44 @@
#endif
#include com/sun/star/ucb/XAnyCompareFactory.hpp
-
#include com/sun/star/container/XIndexReplace.hpp
-
#include com/sun/star/drawing/LineStyle.hpp
-
#include com/sun/star/drawing/LineJoint.hpp
-
#include com/sun/star/drawing/FillStyle.hpp
-
#include com/sun/star/presentation/AnimationSpeed.hpp
-
#include com/sun/star/presentation/FadeEffect.hpp
-
#include com/sun/star/drawing/ConnectorType.hpp
-
#include com/sun/star/drawing/RectanglePoint.hpp
-
#include com/sun/star/drawing/CircleKind.hpp
-
#include com/sun/star/drawing/BitmapMode.hpp
-
#include com/sun/star/text/WritingMode.hpp
-
#include EnumPropertyHdl.hxx
-
#include NamedBoolPropertyHdl.hxx
-
#include numithdl.hxx
-
#include XMLBitmapRepeatOffsetPropertyHandler.hxx
-
#include XMLFillBitmapSizePropertyHandler.hxx
-
#include XMLBitmapLogicalSizePropertyHandler.hxx
-
#include com/sun/star/drawing/TextAnimationKind.hpp
-
#include com/sun/star/drawing/TextAnimationDirection.hpp
-
#include com/sun/star/drawing/TextHorizontalAdjust.hpp
-
#include com/sun/star/drawing/TextVerticalAdjust.hpp
-
#include com/sun/star/drawing/TextFitToSizeType.hpp
-
#include com/sun/star/drawing/MeasureTextHorzPos.hpp
-
#include com/sun/star/drawing/MeasureTextVertPos.hpp
-
#include ControlBorderHandler.hxx
-
-
#include sdpropls.hxx
-
#include propimp0.hxx
-
#include xmlexp.hxx
-
#include xmlnmspe.hxx
-
#include com/sun/star/drawing/NormalsKind.hpp
-
#include com/sun/star/drawing/TextureProjectionMode.hpp
-
#include com/sun/star/drawing/TextureKind.hpp
-
#include com/sun/star/drawing/TextureMode.hpp
-
#include txtprmap.hxx
-
#include XMLClipPropertyHandler.hxx
-
#include XMLIsPercentagePropertyHandler.hxx
-
#include XMLPercentOrMeasurePropertyHandler.hxx
+
namespace binfilter {
using namespace ::rtl;
diff --git a/binfilter/bf_xmloff/source/draw/xmloff_sdxmlimp.cxx b/binfilter/bf_xmloff/source/draw/xmloff_sdxmlimp.cxx
index 783940c..b44cc6d 100644
--- a/binfilter/bf_xmloff/source/draw/xmloff_sdxmlimp.cxx
+++ b/binfilter/bf_xmloff/source/draw/xmloff_sdxmlimp.cxx
@@ -31,38 +31,19 @@
#endif
#include xmlscripti.hxx
-
-
-
#include ximpbody.hxx
-
#include xmlmetai.hxx
-
#include ximpstyl.hxx
-
#include xmlnmspe.hxx
-
-
#include xmluconv.hxx
-
#include DocumentSettingsContext.hxx
-
#include com/sun/star/form/XFormsSupplier.hpp
-
#include com/sun/star/document/XDocumentInfoSupplier.hpp
-
-
#include com/sun/star/style/XStyleFamiliesSupplier.hpp
-
#include com/sun/star/drawing/XMasterPagesSupplier.hpp
-
#include com/sun/star/drawing/XDrawPagesSupplier.hpp
-
-
-
#include xmlerror.hxx
-
namespace binfilter {
using namespace ::rtl;
@@ -956,7 +937,6 @@ OUString SAL_CALL SdXMLImport::getImplementationName() throw( uno::RuntimeExcept
if( IsDraw())
{
// Draw
-
switch( getImportFlags())
{
case IMPORT_ALL:
@@ -976,7 +956,6 @@ OUString SAL_CALL SdXMLImport::getImplementationName() throw( uno::RuntimeExcept
else
{
//
Re: [Libreoffice] Kicking off 3rdparty packages
On Sun, 2011-01-30 at 22:26 +0100, Enrico Weigelt wrote: * Caolán McNamara caol...@redhat.com schrieb: For a distro build configuring with --with-system-libs will generally do-the-right-thing. What happens when the software depends on some ancient, long solved bug that's maybe still in the old bundled version ? You'll have to support both the ancient bundled and the current deps, which over time increases maintenance overhead exponentially. That's the argument in favour for using --with-system-libs and its definitely the right choice for distros. Little bit trickier when putting on a ISV hat and trying to target all Linux distros For a universal Linux build that has to run everywhere we can probably at this stage definitely default to --with-system zlib, jpeg and some other ones where the ABI have been stable for yonks and are ubiquitous. Is there any reason to have to still carry around ancient buggy bundled zlib ? Windows. For Linux, yeah zlib and jpeg and a few others are definitely indefensible. Seems so. For example, openssl can be expected to exist on any sane system in our scope. Sure, and the xpdf thing is a bit of a disaster as well. a) hunspell sometimes changes its ABI to an Libo build against one version of it may not be able to run against another. Always rebuild on the individual target distro's latest stable line. What's the target distro that the universal build on e.g. the website download site should pick. Hard choice. That's the catch. Pick e.g. RHEL-6 and the packages can't work on RHEL-5 seeing as they have different icu versions and so on. We should nail the easy ones anyway, but I don't think we can nail *all* of them. We also definitely need to update to the latest stable versions of all the libs-extern/libs-extern-sys that we do have. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Fwd: [PATCH] Easy hacks: remove double line spacing]
On 30.01.2011 22:51, Guillaume wrote: Can someone explain me why my patch has not been pushed ? If I were wrong somewhere, I don't want to make the same mistake twice. It was my first (really easy/small) patch, to learn how to procede fine. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Just wait a bit longer. It can take more than one day until a patch is pushed. Don't forget that it's Sunday. You will receive an answer on this list whether your patch is pushed or not. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
For old legacy platforms like Windows, prefix distros frameworks like cygwin could be used. Hopefully you are not serious, just uninformed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How do I update my download?
On 28/01/11 17:14, Norbert Thiebaud wrote: On Thu, Jan 27, 2011 at 9:56 PM, Ron Houserho...@smartchat.net.au wrote: Hi, sorry for a beginner's question, but I downloaded the libreoffice code base from git about a month ago, and I want to update it to be the same as the recently released version 3.3 without having to download it all again. Can anyone help out? I think, but am not sure, that the version I have is what in cvs is called the head - not sure about git terminology. If it is too hard to convert to version 3.3, then how do I simply update the version I have from the current git repositories? Normally it should as simple as refreshing your git repositories and switching branch... the problem is that since then the main branch has known some important change in the way we build things... so I suggest you do this: ./bin/g fetch ./bin/g checkout libreoffice-3.3.0 origin/libreoffice-3.3.0 and then build the way you did last time (autogen etc...) Norbert Note that your branch 'master' won't be updated. this was on purpose (./bin/g fetch instead of the more tradition - for us - ./bin/g pull -r) to allow you to switch to the libreoffcie-3.3.0 branch without too many manual tweaking Hi Norbert, I have tried this but ran into some problems: ./bin/g - no such command, so I used git-fetch instead. That command worked and said: remote: Counting objects: 2442, done. remote: Compressing objects: 100% (1001/1001), done. remote: Total 2113 (delta 1613), reused 1426 (delta 1102) Receiving objects: 100% (2113/2113), 370.47 KiB | 57 KiB/s, done. Resolving deltas: 100% (1613/1613), completed with 129 local objects. From git://anongit.freedesktop.org/libreoffice/bootstrap * [new branch] feature/gnumake2.1 - origin/feature/gnumake2.1 672fafb..44f0576 feature/helppack - origin/feature/helppack ec64258..afbf70e feature/layout - origin/feature/layout 977dc85..3bbb389 libreoffice-3-3 - origin/libreoffice-3-3 * [new branch] libreoffice-3-3-0 - origin/libreoffice-3-3-0 d9f0a7c..b303988 master - origin/master * [new tag] libreoffice-3.3.0.4 - libreoffice-3.3.0.4 From git://anongit.freedesktop.org/libreoffice/bootstrap * [new tag] libreoffice-3.3.0.3 - libreoffice-3.3.0.3 * [new tag] ooo/OOO330_m19 - ooo/OOO330_m19 I assume that's about right. But: git-checkout libreoffice-3.3.0 origin/libreoffice-3.3.0 Said: error: pathspec 'libreoffice-3.3.0' did not match any file(s) known to git. error: pathspec 'origin/libreoffice-3.3.0' did not match any file(s) known to git. Since, despite reading the man pages, I don't really understand git (and would prefer not to have to, if I can get to editing the code without it), I don't understand what we are trying to do here and so I am not sure what the fix should be. I am a bit paranoid and don't want to experiment with something that needs so much downloading in case I mess things up well and truly. Am I making some obvious mistake? Thanks, Ron -- Ron House Building Peace: http://peacelegacy.org Australian Birds: http://wingedhearts.org Principle of Goodness academic site: http://principleofgoodness.net ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
* Tor Lillqvist tlillqv...@novell.com schrieb: For old legacy platforms like Windows, prefix distros frameworks like cygwin could be used. Hopefully you are not serious, just uninformed. Actually, I'm think I'm quite well informed, and I'm really *serious* about this. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How do I update my download?
On Sun, Jan 30, 2011 at 6:23 PM, Ron House rho...@smartchat.net.au wrote: On 28/01/11 17:14, Norbert Thiebaud wrote: [...] I assume that's about right. But: git-checkout libreoffice-3.3.0 origin/libreoffice-3.3.0 Said: error: pathspec 'libreoffice-3.3.0' did not match any file(s) known to git. error: pathspec 'origin/libreoffice-3.3.0' did not match any file(s) known to git. Yep, my mistake, it is missing a -b after checkout Since, despite reading the man pages, I don't really understand git (and would prefer not to have to, if I can get to editing the code without it), I don't understand what we are trying to do here and so I am not sure what the fix should be. I am a bit paranoid and don't want to experiment with something that needs so much downloading in case I mess things up well and truly. Am I making some obvious mistake? Thanks, Ron -- Ron House Building Peace: http://peacelegacy.org Australian Birds: http://wingedhearts.org Principle of Goodness academic site: http://principleofgoodness.net ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
On Mon, Jan 31, 2011 at 1:24 AM, Enrico Weigelt weig...@metux.de wrote: * Tor Lillqvist tlillqv...@novell.com schrieb: For old legacy platforms like Windows, prefix distros frameworks like cygwin could be used. Hopefully you are not serious, just uninformed. Actually, I'm think I'm quite well informed, and I'm really *serious* about this. Windows is not an old legacy platform. -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
* Jesús Corrius je...@softcatala.org schrieb: Actually, I'm think I'm quite well informed, and I'm really *serious* about this. Windows is not an old legacy platform. It is. Look at their concepts which are outdated for decades. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kicking off 3rdparty packages
* Caolán McNamara caol...@redhat.com schrieb: That's the argument in favour for using --with-system-libs and its definitely the right choice for distros. The right choice for everybody who's not completely lobotomized ;-P Little bit trickier when putting on a ISV hat and trying to target all Linux distros One binpkg for all distros ?! The whole idea of this is stupid. Some of my customers didn't listen to me and tried that at any cost, they failed miserably. I haven't the slightest bit if pity ;-o Is there any reason to have to still carry around ancient buggy bundled zlib ? Windows. Why can't zlib simply be expected to be installed in some proper place before building the actual application, as done on every sane platform ? Sure, and the xpdf thing is a bit of a disaster as well. ? What's the target distro that the universal build on e.g. the website download site should pick. Trivial: your own microdistro. (prefix build approach, etc). We also definitely need to update to the latest stable versions of all the libs-extern/libs-extern-sys that we do have. You really like to burn your resources for that all the time ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
* Enrico Weigelt weig...@metux.de schrieb: * Jesús Corrius je...@softcatala.org schrieb: Actually, I'm think I'm quite well informed, and I'm really *serious* about this. Windows is not an old legacy platform. It is. Look at their concepts which are outdated for decades. And look at their development tools, including and their own papers about them (eg. TFS) - they show their whole way of thinking. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
On Mon, Jan 31, 2011 at 1:37 AM, Enrico Weigelt weig...@metux.de wrote: * Enrico Weigelt weig...@metux.de schrieb: * Jesús Corrius je...@softcatala.org schrieb: Actually, I'm think I'm quite well informed, and I'm really *serious* about this. Windows is not an old legacy platform. It is. Look at their concepts which are outdated for decades. And look at their development tools, including and their own papers about them (eg. TFS) - they show their whole way of thinking. I am afraid all platforms have their own problems. -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How do I update my download?
On 31/01/11 10:32, Norbert Thiebaud wrote: On Sun, Jan 30, 2011 at 6:23 PM, Ron Houserho...@smartchat.net.au wrote: On 28/01/11 17:14, Norbert Thiebaud wrote: [...] I assume that's about right. But: git-checkout libreoffice-3.3.0 origin/libreoffice-3.3.0 Said: error: pathspec 'libreoffice-3.3.0' did not match any file(s) known to git. error: pathspec 'origin/libreoffice-3.3.0' did not match any file(s) known to git. Yep, my mistake, it is missing a -b after checkout Thanks Norbert, that got me on the right track. I also found I had to replace 3.3.0 with 3-3-0, but it seems to be going now. -- Ron House Building Peace: http://peacelegacy.org Australian Birds: http://wingedhearts.org Principle of Goodness academic site: http://principleofgoodness.net ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Upgrade packages for windows
On Sun, 2011-01-30 at 22:36 +0100, Enrico Weigelt wrote: To me it looks a bit ugly, but it could be just a question of replacing the binaries/files that differ from last version. I don't know enough about this to say if it's a Good Idea or a Bad Idea (tm) Inherently unreliable. The only thing you *could* do is to compare the generated files and only ship those which did. It seems to end up with the problem being Windows lacking a system-wide package management system, and - no one wants to make such a system just for libreoffice - it's more work figuring out the problems that probably will arise from an upgrade package than actually just installing the newer version of openoffice. These would probably be good reasons to give if anyone asks? #1 answer also puts the responsibility for building a package management system to where it belongs: the system owners, Microsoft. Arno signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice on FreeBSD
Hi! Is there any possibility to build the LibreOffice under the FreeBSD? Now I get this error: Config: --disable-binfilter --disable-crashdump --with-lang= --disable-fetch-external --with-vba-package-format=builtin --disable-epm --with-openldap --with-build-version=tag libreoffice-3.3.0.4 --without-fonts --with-system-jpeg --with-system-libxml --with-system-mozilla --with-system-openssl --with-system-python --with-system-stdlibs --with-system-zlib --with-system-poppler --with-unix-wrapper=ooffice3.3 --enable-evolution2 --enable-dbus --with-alloc=system --enable-cairo=yes --enable-gtk --enable-kde --enable-kde4 --with-vendor=The Document Foundation --disable-dbus --enable-kde4 --enable-cairo --without-system-cairo --enable-gstreamer --enable-odk --disable-binfilter --enable-gnome-vfs --enable-hids --enable-lockdown --enable-opengl --with-java-target-version=1.5 --with-jdk-home=$JAVA_HOME --without-myspell-dicts --disable-kde --without-system-mozilla --without-system-jpeg --without-system-libxml --without-system-libxslt --with-system-python --without-system-zlib --without-system-jars --without-system-stdlibs --disable-crypt-link --disable-pam-link --disable-xrender-link --disable-randr-link --without-openldap --without-system-mesa-headers --without-unix-wrapper --with-fonts --enable-minimizer --enable-presenter-console --enable-pdfimport --without-system-poppler --enable-wiki-publisher --enable-report-builder --with-extension-integration --with-ant-home=$BUILDDIR/$APACHE_ANT --with-system-dicts --with-external-dict-dir=/usr/share/hunspell --with-external-hyph-dir=/usr/share/hyphen --with-external-thes-dir=/usr/share/mythes --with-dict=ALL --without-system-openssl --disable-epm --enable-broffice ccache: no icecream: no distcc: no Looks like proc isn't mounted - this means almost certain Java related weird build failure: please check /proc gmake: *** [stamp/build] Error 1 -- View this message in context: http://nabble.documentfoundation.org/LibreOffice-on-FreeBSD-tp2387805p2387805.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice and (La)Tex
On Fri, Jan 28, 2011 at 02:52:24AM +0300, Alexander wrote: When user insert formula, LO can be use LaTeX and make vector graphics (SVG ? Or may be EPS), keep LaTeX source, put vector graphics in ODx and display it. This does system-independent. In ODx can keep preamble and user can edit it. And may be add possibility separate preamble and for each formula. There is an extension that does that: http://ooolatex.sourceforge.net/ . Disclaimer: It's been a long time since I last tried it, so it's possible it doesn't even work with LibreOffice :) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error in en_us readme file ?
On Sun, 2011-01-30 at 16:38 -0500, drew wrote: On Sun, 2011-01-30 at 20:40 +0100, Andras Timar wrote: Updated readme file attached. Well, sorry for the static noise on that - in pulling files together for a distribution disc (as it seemed to be the day for everyone to do that) I see now that it is not so easy as just attaching the text file here. - Will get it routed to the right place, just as soon as I figure out who/where that is :-/ drew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] cleanup on writer
-// OD 09.01.2003 #i6467# - adjust view shell option to the same as for print +// adjust view shell option to the same as for print We generally want to leave the #iX#-style comments around, as they point to the publicly accessible OpenOffice.org issue tracker. OTOH, the #X# or b#X or Bug X ones point to private Sun bug tracker and there is absolutely no value in having them. I also removed some really useless comments. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
