Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167
Hi Friedrich, hi all, thanks for your reply and comments. [...] If not, You are member of a big group of people *assuming* a bug to be an easy bug. I understand every software engineer to be not amused beeing faced that assumption beeing estimated as a fact. You are right, it is an assumption. Although I think that assumptions are more often correct than wrong, I fully agree to the mode that non-coders don't enter [EasyHack]s, but instead enter [ProposedEasyHack]s. Then it does not conflict with the idea of EasyHacks. [...] As far as I got it, EasyHacks is a plain software engineer means where a bug recognized as EasyHack by the expert isn't resolved in short time but instead put to EasyHacks page waiting for a new Hacker resolving it under the eyes of this particular expert and learning the code meanwhile. [...] Yes, that's what it seems to be the case now if you refer to the EasyHacks in bugzilla. In the beginning, some people loosely started to compile easy hacks in the LibreOffice wiki. [...] Please understand: You can only propose an EasyHack if You are a developer and could fix that bug *Yourself*. [...] I don't understand this point. Do you agree or disagree that users who have the sound assumption that something might be an easy hack may enter a [ProposedEasyHack] and developers may change that tag to [EasyHack]. If you agree, that's fine. If you disagree, I would oppose. IMHO such a restriction would lead to a situation where many good ideas are missed and really easy hacks would be forgotten (please refer to my list of bugs in my previous email). Cheers, Gerald ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Reviewing EasyHacks
Hi Christoph, thanks for your ideas to improve the EasyHacks system. Below you find some additional thoughts. [...] However, the question was if additional (whiteboard) tags like UxSimplyGo or UxGetAdvice might help. These tags could be added in QA bug hunting sessions, or by a regular review of such tasks by the Design Team. In the meantime, I also got sometimes added to be the ux contact for other issues ... Might the tag solution be helpful? Or are there other ideas / proposals to make it even easier for developers to simply grab Easy Hacks? [...] Additionally to the whiteboard tags, adding standard comments to the respective bug entry might make sense and would help to avoid misunderstandings. The standard comments could be something like: In case of a easy hack proposed by a user: This is a proposed easy hack entered by a user of the LibreOffice community. So far, the enhancement request is neither verified nor approved by a LibreOffice developer in terms of easiness of its implementation. If you like the idea of this proposed easy hack, please go ahead and contact (UX and DEV list?)before you start coding In case the easy hack was entered by a developer: This is an approved easy hack. The developer team has found this bug or enhancement request as an easy entry step to start coding with LibreOffice. You are welcome to take this bug and start coding. Please contact (.) What do you think about this idea? Kind regards Gerald ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] odt-doc conversion (ODT support in Emacs/Orgmode)
I am a developer adding support for generating OpenDocument Text files from within Emacs/Orgmode [1]. My exporter generates the odt files by dumping xml directly to the various xml files (i.e, it doesn't rely on any API as such) I am running in to an issue while converting from odt to Microsoft Word 97 format. The problem is that some sections of the odt file are differently formatted in word document. I am attaching three files. 1. lists.org - A text file in Orgmode format. I am attaching this mostly for my own future reference. (Bug description can be seen here) 2. lists.odt - This file is generated by my own org-odt exporter. The bug description (which is seen only with doc file) can be seen in bold. 3. lists.doc - This file is generated by doing File-Save As-Microsoft Word 97/2000/XP(.doc). The description of the bug can be seen in bold while opening this file. IMPORTANT NOTE: It is important that you close the doc file and re-open it all over again within Libre/OpenOffice to see the problem behviour. If someone confirms this as a bug I will file a formal bug report. I would also appreciate if a temporary workaround is provided in the meanwhile. (I would prefer workaronds that don't rely on automatic styles much) (Please CC me. I am not subscirbed to this list.) Thanks for your help, Jambunathan K. Footnotes: [1] Orgmode defines a structured markup for text files (very similar to markdown or rst) #+TITLE: lists.org #+AUTHOR:Jambunathan K #+EMAIL: kjambunat...@gmail.com #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t :t #+OPTIONS: TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: * Lists ** Simple Lists *** Numbered List This is a numbered list. 1. L1N1 2. L1N2 3. L1N3 *** A Complex List 1. L1N1: *BUG?: In the odt file, numbering of this item rightly starts at 1. In the converted doc file, the numbering continues. The list style clearly states that the numbering for this level should start at 1*. 1. L2N2 2. L2N3 1. L3N3 *In the odt file, this paragraph shows up correctly as a third level list item. In the converted doc file, this paragraph is formatted as a normal paragraph and it not intended to the right level*. *One another paragraph exhibiting similar behaviour*. 2. L1N4 * L2B1 * L2B2 - L3B3 *One another paragraph that is wrongly indented in the doc file*.. - L3B4 3. L1N5 1. L2N6 1. L3N7 lists.odt Description: lists.odt lists.doc Description: lists.doc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167
Hi Christoph, hi all, thank you very much for summarizing the HybridPDF request. Below your summary I will add some thoughts. [...] * Hybrid PDFs are an important feature to him (option should be moved to the top) * The naming hybrid does not provide too much clues to the user (caption change proposed) * Identifying hybrid PDFs is close to impossible, because OS don't support that properly (file type name) * Opening hybrid PDFs for editing (again) is harder than necessary (recent files list) [...] Good summary. However, in my opinion, the first point is not really important. The second to fourth point, I think, are more important. Particularly, the third point is really important as it causes confusion and renders this feature less usable up to being counterproductive. [...] * The name Hybrid PDF is indeed a bit technical. A different short name (e.g. Combined PDF/ODF or Embed ODF source file) and revised description (advanced help) are indeed helpful -- but: for the dialog caption, please respect the text width required for translation In bug 39167 Gabor proposes to use Create LibreOffice fully editable file. This sounds short enough and really easy to understand. * I don't know if hybrid PDFs are one of the killer features, because ... * Portability: Conforming to standards like PDF/A-1a seems more important (in terms of arranging the options) * Size issue: PDFs are today used to deliver documents to mobile users (plain PDFs are still important) * Feature Set: Using hybrid PDFs removes the export page range feature Let me describe more in detail why I am sure that HybridPDF is a very crucial feature: In professsional or academic environments an everyday standard scenario is that you receive and send documents (via email or other channels). When receiving a file, im most cases you want to read it and in some cases you want to make changes or review it. When you send a file, you must get sure that your counterpart can at least perfectly read the file. However, the main problem is that you generally don't know what software the counterpart uses. As you know, the standard exchange formats are still .doc(x), .ppt(x), .xls(x), if you like it or not. The result is the typical 'negative network effect' that hinders many people using LibreOffice in professional environments. Why? If you send MS formats, you better use Microsoft Office yourself, because LibreOffice too often has only a 99% compatability with these formats. If you send OpenDocument files, the counterpart either responds that he/she cannot open the attachment or - even worse- he/she thinks that there was not meaningful attachment and drops the email at all. What is the only easily doable solution for this problem? In my opinion, HybridPDF. If this feature were properly implemented and also the filetype .od*.pdf registered with the operating system, it lead to the perfect situation that people who have LibreOffice on the computer could directly edit the file when double-clicking on it. And, people who have no LibreOffice installed on the system, would simply see the file in the default PDF viewer. The ultimate result of this would be that no user has to worry about sending ODF-files to his/her counterpart in the 'fear' that the counterpart cannot open ODF-files at all. These interoperability problems are the main hindrance for the expansion of the OpenDocument format. Of course, I understand the limitations of HybridPDFs in terms of portability, size issue and feature set, as you described it above. [...] * The current hybrid option requires the PDF import extension - being optional (although being shipped on e.g. Windows) makes it a less important option If thoroughly considered, it would make sense to have the hybridPDF-part of the extension in the default install set. * There is a major difference for the user between exporting documents (editing in LibO causes major loss in fidelity / is impossible) and saving files (runs smoothly) -- your proposals would require LibreOffice to treat hybrid PDFs similar to native file formats * Opening of a (non-hybrid/hybrid) PDF should be possible in any application. If it is a non-hybrid PDF, then inform the user that it gets imported in Draw; if its a hybrid PDF, then simply open it * Re-opening a hybrid PDF and saving it again should create an updated version of the hybrid PDF * If possible: if a hybrid PDF gets saved, then inform the user about the consequences (might look like a normal PDF, size, ...) * Side note: for the
[Libreoffice] [ANN] LibreOffice 3.3.4 RC1 available
Dear Community, The Document Foundation is happy to announce the first release candidate of LibreOffice 3.3.4. The upcoming 3.3.4 will be the fourth in a series of frequent bugfix releases for our 3.3 code line. Please be aware that LibreOffice 3.3.4 RC1 is not yet ready for production use, you should continue to use LibreOffice 3.3.3 or 3.4.2 for that. The release is available for Windows, Linux and Mac OS X from our QA builds download page at http://www.libreoffice.org/download/pre-releases/ Should you find bugs, please report them to the FreeDesktop Bugzilla: https://bugs.freedesktop.org For other ways to get involved with this exciting project - you can e.g. contribute code: https://www.libreoffice.org/get-involved/developers/ translate LibreOffice to your language: http://wiki.documentfoundation.org/Translation_for_3_3 or help with funding our foundation: http://challenge.documentfoundation.org/ A list of known issues with 3.3.4 RC1 is available from our wiki: http://wiki.documentfoundation.org/Releases/3.3.4/RC1 Please find the list of changes against LibreOffice 3.3.3 here: http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-3-release-3.3.4.1.log Let us close again with a BIG Thank You! to all of you having contributed to the LibreOffice project - this release would not have been possible without your help. Yours, The Steering Committee of The Document Foundation pgpZNCodram81.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39792: local range names are only written to the file if changes were made to the sheet
Hi Markus, On Saturday, 2011-08-06 03:51:04 +0200, Markus Mohrhard wrote: this patch invalidates the input stream if we set the local range name. Otherwise the changes to range names only get saved if we have some other action that invalidated the stream. Looks good. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpxMMWSoAApa.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167
Hi Gerald, *, Am 06.08.2011 08:09 schrieb Gerald Leppert: Friedrich Strohmaier schrieb: thanks for your reply and comments. [..] If not, You are member of a big group of people *assuming* a bug to be an easy bug. I understand every software engineer to be not amused beeing faced that assumption beeing estimated as a fact. You are right, it is an assumption. Although I think that assumptions are more often correct than wrong, How do you come to that result? Remember: EasyHacks is a developer means to attract new developers - nothing more. I fully agree to the mode that non-coders don't enter [EasyHack]s, but instead enter [ProposedEasyHack]s. Then it does not conflict with the idea of EasyHacks. Of course it does. A new Developer, interested in contributing to LibreOffice is led to that page to find a low barrier entrance. He picks one up, ask on the developer's list, how to procede, get's hints from at least the founder of the easy hack which decided to be mentor on it by publishing it. What now, if he picks a ProposedEasyHack, which is nearby?.. [...] As far as I got it, EasyHacks is a plain software engineer means where a bug recognized as EasyHack by the expert isn't resolved in short time but instead put to EasyHacks page waiting for a new Hacker resolving it under the eyes of this particular expert and learning the code meanwhile. Yes, that's what it seems to be the case now if you refer to the EasyHacks in bugzilla. No, that's not true. EasyHacks is an ecosystem to attract new developers - The wikipage is the main means of that, because they are easily visible there. In the beginning, some people loosely started to compile easy hacks in the LibreOffice wiki. .. Which was an idea and action of the development team.. [...] Please understand: You can only propose an EasyHack if You are a developer and could fix that bug *Yourself*. I don't understand this point. I sadly see, so I obviously couldn't pass the message.. Do you agree or disagree that users who have the sound assumption that something might be an easy hack may enter a [ProposedEasyHack] and developers may change that tag to [EasyHack]. Disagree, because: I can't see how this should work in respect of the EasyHacks' intention. Remember: When an EasyHack appears in that page all preparing work (investigation, estimation) already has been done. A ProposedEasyHack would need a (senior) developer to pick it up, investigate it, solve it or instead estimate it as EasyHack. I can't see the difference from just entering it as a feature request/bug in the bugtracking system. If you agree, that's fine. If you disagree, I would oppose. IMHO such a restriction would lead to a situation where many good ideas are missed and really easy hacks would be forgotten (please refer to my list of bugs in my previous email). If they will be forgotten I'd assume noone except the reporter can prevent it. ;o)) What You describe is some kind of wish machine, everyone can throw in his favorite must have feature. Even if this ever worked I doubt, it would lead to a useful product at the end. So to sum it up: For me it looks like You want to solve a problem (developers don't care users) by hijacking a feature You assume giving kind of direct access to development. From the destinated tool - the issuetracker - You assume it doesn't. While I agree with You, the Problem which gives the above *impression* (developers don't care users) is one to be solved and is one we *will* solve one day, the way You try to go, for me doesn`t seem suitable in this regard. Gruß/regards -- Friedrich Libreoffice-Box http://libreofficebox.org/ LibreOffice and more on CD/DVD images ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Replace SvULongs with vector and code clean up part 1
Hi,
I was working on SvULongs in libs-core and I decided to split my work in
several Patches.
With this patch comes some questions:
@@ -159,16 +159,10 @@ SvxNumberFormatShell::~SvxNumberFormatShell()
// Hinzugefuegte Formate sind nicht gueltig:
// = wieder entfernen:
-for ( sal_uInt16 i = 0; i aAddList.Count(); ++i )
-pFormatter-DeleteEntry( aAddList[i] );
+for ( std::vectorsal_uInt32::const_iterator it =
aAddList.begin(); it != aAddList.end(); ++it )
+pFormatter-DeleteEntry( *it );
}
-//
-// Add-/Remove-Listen leerraeumen:
-//
-aAddList.Remove( 0, aAddList.Count() );
-aDelList.Remove( 0, aAddList.Count() );
1. It is not necessary to explicitly clear vectors?
@@ -1279,21 +1272,6 @@ void
SvxNumberFormatShell::MakePrevStringFromVal(
pFormatter-GetPreviewString( rFormatStr, nValue, rPreviewStr,
rpFontColor, eCurLanguage );
}
-/*
-#* Member: GetComment4Entry Datum:30.10.97
-#*
-#*
-#* Klasse: SvxNumberFormatShell
-#*
-#* Funktion: Liefert den Kommentar fuer einen gegebenen
-#* Eintrag zurueck.
-#*
-#* Input: Nummer des Eintrags
-#*
-#* Output: Kommentar-String
-#*
-#/
-
void SvxNumberFormatShell::SetComment4Entry(short nEntry,String
aEntStr)
{
SvNumberformat *pNumEntry;
2. Is it useful to translate comments like this? and convert to actual
documentation style?
Tranlation:
Funktion: Liefert den Kommentar fuer einen gegebenen Eintrag zurueck.
- Returns a comment for given Entry
Input: Nummer des Eintrags - Number of entry
Output:Kommentar-String - Comment's string
@@ -228,9 +229,9 @@ private:
String aValStr;
double nValNum;
sal_Bool bUndoAddList;
-SvULongs aAddList;
-SvULongs aDelList;
-SvULongs aCurEntryList;
+std::vectorsal_uInt32 aAddList;
+std::vectorsal_uInt32 aDelList;
+std::vectorsal_uInt32 aCurEntryList;
3. For code formating tabs are okay? I have used spaces, but previous
there were tabs.
@@ -229,21 +224,18 @@ void SvxNumberFormatShell::FormatChanged( sal_uInt16
nFmtLbPos,
String rPreviewStr,
Color* rpFontColor )
{
-//nCurFormatKey = pCurFmtTable-GetKey( pCurFmtTable-GetObject(
nFmtLbPos ) );
-
4. If there is commented code should it be removed?
@@ -1325,7 +1288,7 @@ String SvxNumberFormatShell::GetComment4Entry(short
nEntry)
if(nEntry 0)
return String();
-if(nEntryaCurEntryList.Count())
+if(nEntry (short)aCurEntryList.size())
{
5. Should short type be replaced with sal_Int16 or more appropriate type?
Best Regards,
Maciej
From 38fff431d906bfaf39848e443709b7a957d238b2 Mon Sep 17 00:00:00 2001
From: Maciej Rumianowski maciej.rumianow...@gmail.com
Date: Sat, 6 Aug 2011 15:27:06 +0200
Subject: [PATCH] Replace SvULongs with vector and code clean up
Instead of SvULongs use std::vectorsal_uInt32
Remove unnecessary german comments
Translate some comments
replace sal_Bool with bool where variable is not interfering with return value
---
svx/inc/svx/numfmtsh.hxx |7 +-
svx/source/items/numfmtsh.cxx | 222 -
2 files changed, 66 insertions(+), 163 deletions(-)
diff --git a/svx/inc/svx/numfmtsh.hxx b/svx/inc/svx/numfmtsh.hxx
index a7c6f95..f4e7c06 100644
--- a/svx/inc/svx/numfmtsh.hxx
+++ b/svx/inc/svx/numfmtsh.hxx
@@ -46,6 +46,7 @@
#include svl/svstdarr.hxx
+#include vector
// forward ---
class Color;
@@ -228,9 +229,9 @@ private:
String aValStr;
double nValNum;
sal_Bool bUndoAddList;
-SvULongsaAddList;
-SvULongsaDelList;
-SvULongsaCurEntryList;
+std::vectorsal_uInt32 aAddList;
+std::vectorsal_uInt32 aDelList;
+std::vectorsal_uInt32 aCurEntryList;
sal_uInt32nInitFormatKey;
sal_uInt32nCurFormatKey;
short nCurCategory;
diff --git a/svx/source/items/numfmtsh.cxx b/svx/source/items/numfmtsh.cxx
index 837fdea..8ca37fe 100644
--- a/svx/source/items/numfmtsh.cxx
+++ b/svx/source/items/numfmtsh.cxx
@@ -159,16 +159,10 @@ SvxNumberFormatShell::~SvxNumberFormatShell()
// Hinzugefuegte Formate sind nicht gueltig:
// = wieder entfernen:
-for ( sal_uInt16 i = 0; i aAddList.Count(); ++i )
-pFormatter-DeleteEntry( aAddList[i] );
+for ( std::vectorsal_uInt32::const_iterator it = aAddList.begin(); it != aAddList.end(); ++it )
+pFormatter-DeleteEntry( *it );
}
-//
-//
Re: [Libreoffice] LO-3.4.2 SUSE build testing
Petr Mladek schrieb am Freitag, 5. August 2011 15:06: the first LO-3.4.2 package for SLED11-SP1, openSUSE-11.1, 11.2, 11.3, and 11.4 are available at http://download.opensuse.org/repositories/LibreOffice:/Unstable/ I'm kissing your feet... Finally, this is the first opensuse-package of open/libreoffice of version =3.3 where editing forms in base is possible again after nearly one year... Many thanks, Stefan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build problems with cppunit
I have the same problem. I tried to build LO (branch «libreoffice-3-4-2») but building fails on module xml2cmp with same error. I really don't understand how You built a stable LibreOffice 3.4.2... 31.05.2011 01:03, Regina Henschel пишет: Hi, I have started a non parallel build and now find, that the error is likely already in xml2cmp. Log is in http://pastebin.com/7cvzwtWm Any idea what is wrong? Shouldn't it be possible to build from tar sources? That worked for OOo. Kind regards Regina Regina Henschel schrieb: Hi, I have still problems building from tar source. Actual situation: All modules folders are put into one root folder. Configure finished. Make starts compiling and stops with error in cppunit: TypeInfoHelper.obj : error LNK2001: unresolved external symbol __imp___invalid_parameter_noinfo and many others of that kind. Kind regards Regina ___ 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 -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace SvULongs with vector and code clean up part 1
Hi Maciej,
On Saturday, 2011-08-06 15:32:52 +0200, Maciej Rumianowski wrote:
With this patch comes some questions:
@@ -159,16 +159,10 @@ SvxNumberFormatShell::~SvxNumberFormatShell()
// Hinzugefuegte Formate sind nicht gueltig:
// = wieder entfernen:
-for ( sal_uInt16 i = 0; i aAddList.Count(); ++i )
-pFormatter-DeleteEntry( aAddList[i] );
+for ( std::vectorsal_uInt32::const_iterator it =
aAddList.begin(); it != aAddList.end(); ++it )
+pFormatter-DeleteEntry( *it );
}
-//
-// Add-/Remove-Listen leerraeumen:
-//
-aAddList.Remove( 0, aAddList.Count() );
-aDelList.Remove( 0, aAddList.Count() );
1. It is not necessary to explicitly clear vectors?
As the vector is a member of SvxNumberFormatShell it is destroyed in
SvxNumberFormatShell's dtor anyway, no need to explicitly clear it.
Which also wasn't necessary for the array members. Sometimes the order
in which vector members are removed from different vectors is important,
but not here. The code is wrong anyway, as it uses aAddList.Count() for
both, aAddList and aDelList ...
@@ -1279,21 +1272,6 @@ void
SvxNumberFormatShell::MakePrevStringFromVal(
pFormatter-GetPreviewString( rFormatStr, nValue, rPreviewStr,
rpFontColor, eCurLanguage );
}
-/*
-#* Member: GetComment4Entry Datum:30.10.97
-#*
-#*
-#* Klasse: SvxNumberFormatShell
-#*
-#* Funktion: Liefert den Kommentar fuer einen gegebenen
-#* Eintrag zurueck.
-#*
-#* Input: Nummer des Eintrags
-#*
-#* Output: Kommentar-String
-#*
-#/
-
void SvxNumberFormatShell::SetComment4Entry(short nEntry,String
aEntStr)
{
SvNumberformat *pNumEntry;
2. Is it useful to translate comments like this? and convert to actual
documentation style?
Yes, but move the documentation to the header file instead, there it is
more useful for someone using the class. However, for reviews it is
better to separate patches into actual code changes and
translation/documentation changes.
@@ -228,9 +229,9 @@ private:
String aValStr;
double nValNum;
sal_Bool bUndoAddList;
-SvULongs aAddList;
-SvULongs aDelList;
-SvULongs aCurEntryList;
+std::vectorsal_uInt32 aAddList;
+std::vectorsal_uInt32 aDelList;
+std::vectorsal_uInt32 aCurEntryList;
3. For code formating tabs are okay? I have used spaces, but previous
there were tabs.
Spaces please.
@@ -229,21 +224,18 @@ void SvxNumberFormatShell::FormatChanged( sal_uInt16
nFmtLbPos,
String rPreviewStr,
Color* rpFontColor )
{
-//nCurFormatKey = pCurFmtTable-GetKey( pCurFmtTable-GetObject(
nFmtLbPos ) );
-
4. If there is commented code should it be removed?
Depends on. Most commented code like that are remains of old times,
sometimes they indicate what was changed and why, but most times they
are useless, as is the case here.
@@ -1325,7 +1288,7 @@ String SvxNumberFormatShell::GetComment4Entry(short
nEntry)
if(nEntry 0)
return String();
-if(nEntryaCurEntryList.Count())
+if(nEntry (short)aCurEntryList.size())
{
5. Should short type be replaced with sal_Int16 or more appropriate type?
May, but note that in that case all callers have to be adapted as well
in case on some platform sal_Int16 differs from short. Anyway, when
changing I'd go for sal_Int32 instead.
From 38fff431d906bfaf39848e443709b7a957d238b2 Mon Sep 17 00:00:00 2001
From: Maciej Rumianowski maciej.rumianow...@gmail.com
Date: Sat, 6 Aug 2011 15:27:06 +0200
Subject: [PATCH] Replace SvULongs with vector and code clean up
--- a/svx/source/items/numfmtsh.cxx
+++ b/svx/source/items/numfmtsh.cxx
@@ -177,20 +171,21 @@ SvxNumberFormatShell::~SvxNumberFormatShell()
sal_uInt32 SvxNumberFormatShell::GetUpdateDataCount() const
{
-return aDelList.Count();
+return aDelList.size();
Here change also the method's return type to size_t, also in the header
file. Make sure to change the callers accordingly.
void SvxNumberFormatShell::GetUpdateData( sal_uInt32* pDelArray, const
sal_uInt32 nSize )
{
-const sal_uInt32 nCount = aDelList.Count();
+const sal_uInt32 nListSize = aDelList.size();
Also here, please use size_t consistently for vector::size().
+std::vectorsal_uInt32::const_iterator it;
-DBG_ASSERT( pDelArray ( nSize == nCount ), Array nicht
initialisiert! );
+DBG_ASSERT( pDelArray ( nSize == nListSize ), Array is not
initialized );
-if ( pDelArray ( nSize == nCount ) )
-for ( sal_uInt16
Re: [Libreoffice] [Libreoffice-ux-advise] Fwd: [PATCH] Bug 39167
Hi Friedrich, hi all, does anyone here have a less rigid opinion on that matter than the one expressed by Friedrich? I really don't care whether you want LibreOffice to be a developers AND users community or whether you want to separate these two from each other; whether the LibreOffice community is welcoming or not. I only would like to know how users are allowed / should / can contribute to the EasyHacks-system. I am confused, because the original EasyHacks wiki page did not carry any restriction on who may contribute to it and my interactions with others on that matter had been always positive. Also, the definition of the tag [ProposedEasyHack] is defined as As task that is thought to be easy to hack, but has not been checked by a developer to not contain nasty surprises. Please advise. Best greetings, Gerald ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEWED] [PUSHED 3-4] fix for fdo#39792: local range names are only written to the file if changes were made to the sheet
On Sat, 2011-08-06 at 12:49 +0200, Eike Rathke wrote: Hi Markus, On Saturday, 2011-08-06 03:51:04 +0200, Markus Mohrhard wrote: this patch invalidates the input stream if we set the local range name. Otherwise the changes to range names only get saved if we have some other action that invalidated the stream. Looks good. I concur. Pushed to the 3-4 branch with my sign-off (plus Eike's). Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEWED] [PUSHED 3-4] proposing for 3-4: fdo#39869 Fix memory exhaustion
On Sat, 2011-08-06 at 02:23 +0200, Eike Rathke wrote: Hi, Proposing to cherry-pick to 3-4: fdo#39869 Fix memory exhaustion https://bugs.freedesktop.org/show_bug.cgi?id=39869 http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=651568afad1a585c485384ab6d7b65780fb02256 Actually the bug may occur with any cell content of STRLEN_MAX (64k) characters and also other modules that use the EditEngine. Yup, looks good. Cherry-picked to the 3-4 branch. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix for fdo#39678: don't write table:protection-key-digest-algorithm to odf 1.1 or odf 1.0
Hi Markus, On Fri, 2011-08-05 at 22:01 +0200, Markus Mohrhard wrote: Hello, this patch should ensure that we write the password algorithm only to odf 1.2 and later files. I'm not quite sure how important it is to be 100% standard compliant so I don't know if we should include it into 3-4. Well, I do know that 100% standard compliance *does* matter to some circle of users, so as long as the fix is a safe fix, I would say we should put it in. I would make one change though. Instead of if ( IsOdfVersionGreaterEqual_1_2() ) we should do if (getDefaultVersion() = SvtSaveOptions::ODFVER_012) and drop the additional method you added in your patch. Conditionalizing for the ODF version 1.2 or above is common enough that it is done in many other places, and this is how it is done there. Other than that, the patch looks good safe. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kohei.yosh...@suse.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix for fdo#34768 - no update preview
Hi all, I wrote a simple patch for resolving the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=34768 (the patch is attached therein) When selecting a template in dialogue Load Slide Design in Impress, the preview didn't get updated. I linked the already existing event handler and called it also when selecting a region. I would like to ask to apply the patch not only on master, but also on branches -3-3 and -3-4, as the changes are hazard-free IMHO. Best regards, Péter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace SvULongs with vector and code clean up part 1
Hi Eike,
Thanks for review!
Dnia 2011-08-06, sob o godzinie 17:35 +0200, Eike Rathke pisze:
{
-if ( aDelList[i] == nAddKey )
+if ( *it == nAddKey )
{
bFound = sal_True;
-nAt = i;
+nAt = it;
}
}
DBG_ASSERT( bFound, Key not found );
-aDelList.Remove( nAt );
+aDelList.erase( nAt );
Hmm.. I'd say the original code was wrong, when nAddKey was not found
in
aDelList it removed the first element anyway. That should be
if (bFound)
aDelList.erase( nAt );
instead.
There was so many questions that I forgot to ask. Should this code be
more changed? Because code in if(isRemoved_Impl()) is only entered if
there is nAddKey in aDelList. My question is why the key is double
searched? I think assertion will never be met.
Best Regards,
Maciej
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] One Git Conversion Done. new repos online
The One Git conversion is done. master is now at git clone git://anongit.freedesktop.org/libreoffice/core other than that, everything else should be pretty much the same. If you run into trouble, please shout-out in #libreoffice-dev Norbert --- http://wiki.documentfoundation.org/Development/One_Git_Conversion ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] One Git Conversion Done. new repos online
Title: Szalai Kálmán Hi! I just started to checking out with: git clone ssh://(login)@git.freedesktop.org/git/libreoffice/core libreoffice-master Looks okay! Thank you! KAMI 2011-08-06 22:38 keltezéssel, Norbert Thiebaud írta: The One Git conversion is done. master is now at git clone git://anongit.freedesktop.org/libreoffice/core other than that, everything else should be pretty much the same. If you run into trouble, please shout-out in #libreoffice-dev Norbert --- http://wiki.documentfoundation.org/Development/One_Git_Conversion ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Best regards, Kálmán „KAMI” Szalai | 神 | kami911 [at] gmail [dot] com My favorite projects: OxygenOffice Professional - office suite - for everybody | Magyarul - In Hungarian Blog | Support Follow me, if you can signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
