[Libreoffice-commits] .: vcl/source

[Libreoffice Gerrit user]

 vcl/source/app/dbggui.cxx |6 ++
 1 file changed, 6 insertions(+)

New commits:
commit 9b0ab09b45142bc26d51e16613d06bb415dc0d0c
Author: Tor Lillqvist 
Date:   Fri Jan 11 09:41:50 2013 +0200

No "core dumps" on Windows, and not on iOS or Android either

Change-Id: Ie5d3257d3a289856399f7a3266e3caf66831e00a

diff --git a/vcl/source/app/dbggui.cxx b/vcl/source/app/dbggui.cxx
index ee72e02..a488516 100644
--- a/vcl/source/app/dbggui.cxx
+++ b/vcl/source/app/dbggui.cxx
@@ -1662,7 +1662,13 @@ void DbgPrintMsgBox( const char* pLine )
 }
 
 strcpy( aDbgOutBuf, pLine );
+#if defined UNX && !(defined ANDROID || defined IOS)
 strcat( aDbgOutBuf, "\nAbort ? (Yes=abort / No=ignore / Cancel=core dump)" 
);
+#elif defined _WIN32
+strcat( aDbgOutBuf, "\nAbort ? (Yes=abort / No=ignore / Cancel=try to 
invoke debugger)" );
+#else
+strcat( aDbgOutBuf, "\nAbort ? (Yes=abort / No=ignore / Cancel=crash)" );
+#endif
 
 SolarMessageBoxExecutor aMessageBox( String( aDbgOutBuf, 
RTL_TEXTENCODING_UTF8 ) );
 TimeValue aTimeout; aTimeout.Seconds = 2; aTimeout.Nanosec = 0;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: replacing OUString::valueOf(static_cast) ??

[Noel Grandin]

On 2013-01-10 20:03, Lubos Lunak wrote:
That is not what I meant. What I wrote in my previous mail is that if 
these valueOf() issues are to be fixed, it's better to fix it 
completely rather than just slightly reduce the problem. And for that 
it would be better to remove the original valueOf() completely, and 
that results in all the follow-up issues that I raised. 

Ah, I see.

So you're saying that you'd rather we remove the original valueOf() 
altogether.
That seems like it would have some backwards compatibility issues, but I 
suppose we could mark them as deprecated for a time before actually 
removing them.


In that case, let's deal with your issues one at a time:

On 2013-01-10 15:55, Lubos Lunak wrote:

- There's no need for valueOfChar(). There is already OUString ctor from
sal_Unicode, so the valueOf() overload for it is just making an obvious thing
complicated. Code using it can be converted to use the ctor instead.

I've already dealt with why we can't use the constructor.
   git grep "String::valueOf.*Unicode"
says we do in fact appear to need such a method.


- It's a question if we really need 'OUString::valueOfBool( foo )' instead of
simply 'foo ? OUString( "true" ) : OUString( "false" )' (such a pity the
string literals handling doesn't allow "foo ? "true" : "false"' ). I wonder
how many places in the code really need to convert a boolean to the hardcoded
english string representation.

I have no idea how to count call sites automatically.
But at least 10 places need to use a cast to access the method, so there 
is definitely code using it.



- When more or less deprecating valueOf() this way, it has also float
overloads, so something should be created for those too.
Fair enough. We don't have many of them, but for completeness sake, it 
makes sense.




- I'm still not sold on the naming, OUString::valueInt() doesn't say much and
OUString::valueOfInt() feels cryptic. Can we please use something obvious
that doesn't need decyphering, such as , such as OUString::number() or
OUString::fromInt() (as much as I still don't like the idea of harcoding the
irrelevant type information in the name)?


I think valueOf() is fine, but then I do a lot of programming in Java :-)
But whatever, if the C++ people prefer another name, then so be it.


Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need confirmation about non-clearing of Character Styles

[David Tardon]

Hi,

On Thu, Jan 10, 2013 at 06:40:02PM +0100, Fernand Vanrie wrote:
> Michael plaese see also my reply to Caloán
> >On 10/01/13 14:25, Caolán McNamara wrote:
> >resetting the character styles should be as easy as setting "Default"
> >char style on the whole document, so i'm not sure if another option is
> >worth the additional clutter.
> if you know this work around yes
> >
> >but hyperlinks should not be touched by any "reset formatting" since
> >they are not formatting, but content entities (the reset feature also
> >doesn't convert fields to plain text).
> when you works in the printing business you "must" get rid  of this
> kind of formating
> >
> >also i'm thinking that ruby text should also not be touched by "reset
> >formatting", and this has not yet been changed (i.e. it is reset
> >currently); the reset will actually throw away the ruby text.  i'm
> >already sitting on a patch to remove ruby from the reset list...
> idem ditto

If you want to get rid of _all_ possible formatting, why don't you save
the document as plain text? :-)

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gmake: CXXFLAGS override gb_Library_add_cxxflags

[David Tardon]

Hi,

On Wed, Jan 09, 2013 at 03:41:38PM +0100, Petr Mladek wrote:
> PS: I have troubles to understand the related gbuild code. It seems that
> both CXXFLAGS and gb_Library_add_cxxflags are added to the T_CXXFLAGS
> variable, see:
> 
> --- cut solenv/gbuild/LinkTarget.mk ---
> $(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS :=
> $$(gb_LinkTarget_CXXFLAGS)
> [...]
> define gb_LinkTarget_add_cxxflags
> $(call gb_LinkTarget_get_headers_target,$(1)) \ 
> $(call gb_LinkTarget_get_target,$(1)) : T_CXXFLAGS += $(2)
> ifeq ($(gb_FULLDEPS),$(true))
> $(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS += $(2)
> endif
> endef
> --- cut ---
> 
> It looks like T_CXXFLAGS is initialized with CXXFLAGS and
> gb_LinkTarget_add_cxxflags is added at the end. Though, in reality, they
> are listed in the opposite order. So, I am lost :-)

The problem is in variable inheritance. gb_LinkTarget_add_cxxobject
contains:

$(call gb_CxxObject_get_target,$(2)) : T_CXXFLAGS += $(3)

but there is _no_ T_CXXFLAGS variable defined on the target yet,
therefore make creates a new _recursive_ variable. When it is expanded,
it uses the current T_CXXFLAGS variable visible at the expansion point,
which is the one inherited from the CxxObject's LinkTarget. This is why
T_CXXFLAGS set on LinkTarget end up _before_ the flags passed to
gb_LinkTarget_add_cxxobject (these contain $(CXXFLAGS)).

I think all that is needed is
-$(call gb_CxxObject_get_target,$(2)) : T_CXXFLAGS += $(3)
+$(call gb_CxxObject_get_target,$(2)) : T_OBJECT_CXXFLAGS := $(3)

and then use both T_CXXFLAGS and T_OBJECT_CXXFLAGS in
gb_CxxObject__command. (The same think must then be done for other types
of objects--C, ObjC etc.)

There is still a problem with this: gb_LinkTarget_add_cxxobject can be
used directly in makefiles, in which case the passed flags are specific
for one or more cxx files and should (IMHO) override the LinkTarget
flags, which would not be the case here. On the other side,
gb_LinkTarget_add_cxxobject is mainly used to avoid passing optimization
flags, so hopefully this would not cause a problem.

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 54157] LibreOffice 3.7/4.0 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=54157

Bug 54157 depends on bug 58069, which changed state.

Bug 58069 Summary: FILESAVE in different path structure destroys relative 
hyperlinks
https://bugs.freedesktop.org/show_bug.cgi?id=58069

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Change in core[libreoffice-4-0]: fdo#59084: Sync dimension members after reloading the group ...

[Markus Mohrhard (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1635

Approvals:
  Markus Mohrhard: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1635
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ibd674a97a59205e5e28efd007f8857731e8df4d3
Gerrit-PatchSet: 3
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Kohei Yoshida 
Gerrit-Reviewer: Markus Mohrhard 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: slideshow/source

[Libreoffice Gerrit user]

 slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx |2 
+-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 90ef2f1d636cc2f3397b820d0ed61f48d4b4ea36
Author: Tor Lillqvist 
Date:   Fri Jan 11 07:09:00 2013 +0200

I meant -1 of course, not -127

(As the signed char equivalent of 255.)

Change-Id: Iefb3ebdcf324f0a1925bb3e5d01d7d86e5c62482

diff --git 
a/slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx 
b/slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx
index 2dd366f..e1260d3 100644
--- a/slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx
+++ b/slideshow/source/engine/OGLTrans/generic/OGLTrans_TransitionerImpl.cxx
@@ -1242,7 +1242,7 @@ namespace
 *pColors++ = vcl::unotools::toByteColor(pIn->Red);
 *pColors++ = vcl::unotools::toByteColor(pIn->Green);
 *pColors++ = vcl::unotools::toByteColor(pIn->Blue);
-*pColors++ = -127;
+*pColors++ = -1;
 ++pIn;
 }
 return aRes;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - sc/source

[Libreoffice Gerrit user]

 sc/source/ui/docshell/dbdocfun.cxx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit cae060de53cbfc0737a75ed156aec8c383a14918
Author: Kohei Yoshida 
Date:   Thu Jan 10 23:48:17 2013 -0500

fdo#59084: Sync dimension members after reloading the group data.

Else the syncing would end up syncing to the older version of the
group data before the reload, which (as you can see in the bug report)
may lead to a crash.

Change-Id: Ibd674a97a59205e5e28efd007f8857731e8df4d3
Reviewed-on: https://gerrit.libreoffice.org/1635
Reviewed-by: Markus Mohrhard 
Tested-by: Markus Mohrhard 

diff --git a/sc/source/ui/docshell/dbdocfun.cxx 
b/sc/source/ui/docshell/dbdocfun.cxx
index 4d0d2ec..3b1db2f 100644
--- a/sc/source/ui/docshell/dbdocfun.cxx
+++ b/sc/source/ui/docshell/dbdocfun.cxx
@@ -1319,6 +1319,8 @@ bool ScDBDocFunc::DataPilotUpdate( ScDPObject* pOldObj, 
const ScDPObject* pNewOb
 if ( pDestObj )
 {
 pDestObj->ReloadGroupTableData();
+if (!pDestObj->SyncAllDimensionMembers())
+return false;
 pDestObj->InvalidateData(); // before getting the 
new output area
 
 //  make sure the table has a name (not set by dialog)
@@ -1461,8 +1463,6 @@ sal_uLong ScDBDocFunc::RefreshPivotTables(ScDPObject* 
pDPObj, bool bApi)
 for (; it != itEnd; ++it)
 {
 ScDPObject* pObj = *it;
-if (!pObj->SyncAllDimensionMembers())
-continue;
 
 // This action is intentionally not undoable since it modifies cache.
 DataPilotUpdate(pObj, pObj, false, bApi);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: sc/source

[Libreoffice Gerrit user]

 sc/source/ui/docshell/dbdocfun.cxx |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

New commits:
commit 6e0b18ddde4310f85d3d6b7c27a93f78b541d976
Author: Kohei Yoshida 
Date:   Fri Jan 11 00:04:13 2013 -0500

Makes no sense to 'continue' at the end of the block.

Change-Id: I2b02430944c5c6ecf67d2b7cd02c66bb549c93f9

diff --git a/sc/source/ui/docshell/dbdocfun.cxx 
b/sc/source/ui/docshell/dbdocfun.cxx
index 94d4f1f..3b1db2f 100644
--- a/sc/source/ui/docshell/dbdocfun.cxx
+++ b/sc/source/ui/docshell/dbdocfun.cxx
@@ -1465,8 +1465,7 @@ sal_uLong ScDBDocFunc::RefreshPivotTables(ScDPObject* 
pDPObj, bool bApi)
 ScDPObject* pObj = *it;
 
 // This action is intentionally not undoable since it modifies cache.
-if (!DataPilotUpdate(pObj, pObj, false, bApi))
-continue;
+DataPilotUpdate(pObj, pObj, false, bApi);
 }
 
 return 0;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PATCH] Change in core[libreoffice-4-0]: fdo#59084: Sync dimension members after reloading the group ...

[Kohei Yoshida (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1635

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/35/1635/1

fdo#59084: Sync dimension members after reloading the group data.

Else the syncing would end up syncing to the older version of the
group data before the reload, which (as you can see in the bug report)
may lead to a crash.

Change-Id: Ibd674a97a59205e5e28efd007f8857731e8df4d3
---
M sc/source/ui/docshell/dbdocfun.cxx
1 file changed, 4 insertions(+), 3 deletions(-)



diff --git a/sc/source/ui/docshell/dbdocfun.cxx 
b/sc/source/ui/docshell/dbdocfun.cxx
index 4d0d2ec..94d4f1f 100644
--- a/sc/source/ui/docshell/dbdocfun.cxx
+++ b/sc/source/ui/docshell/dbdocfun.cxx
@@ -1319,6 +1319,8 @@
 if ( pDestObj )
 {
 pDestObj->ReloadGroupTableData();
+if (!pDestObj->SyncAllDimensionMembers())
+return false;
 pDestObj->InvalidateData(); // before getting the 
new output area
 
 //  make sure the table has a name (not set by dialog)
@@ -1461,11 +1463,10 @@
 for (; it != itEnd; ++it)
 {
 ScDPObject* pObj = *it;
-if (!pObj->SyncAllDimensionMembers())
-continue;
 
 // This action is intentionally not undoable since it modifies cache.
-DataPilotUpdate(pObj, pObj, false, bApi);
+if (!DataPilotUpdate(pObj, pObj, false, bApi))
+continue;
 }
 
 return 0;

-- 
To view, visit https://gerrit.libreoffice.org/1635
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ibd674a97a59205e5e28efd007f8857731e8df4d3
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Change in core[libreoffice-4-0]: fdo#58069: Invalidate sheet stream cache when directory path...

[Markus Mohrhard (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1634

Approvals:
  Markus Mohrhard: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1634
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I44fdd5b0ef0a57bf4fae13f29f1ebacfe1ab19a8
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Kohei Yoshida 
Gerrit-Reviewer: Markus Mohrhard 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - sc/inc sc/source

[Libreoffice Gerrit user]

 sc/inc/document.hxx  |1 +
 sc/source/core/data/document.cxx |   11 +++
 sc/source/ui/docshell/docsh.cxx  |   38 +-
 3 files changed, 49 insertions(+), 1 deletion(-)

New commits:
commit 31664fbc882652f6b308fa5aab1eac48e9d0ad0a
Author: Kohei Yoshida 
Date:   Thu Jan 10 16:21:05 2013 -0500

fdo#58069: Invalidate sheet stream cache when directory path changes.

To properly regenerate hyperlinks (among other things) which depend on
the full path of the host document.

Change-Id: I44fdd5b0ef0a57bf4fae13f29f1ebacfe1ab19a8
Reviewed-on: https://gerrit.libreoffice.org/1634
Reviewed-by: Markus Mohrhard 
Tested-by: Markus Mohrhard 

diff --git a/sc/inc/document.hxx b/sc/inc/document.hxx
index 5b5a472..76df284 100644
--- a/sc/inc/document.hxx
+++ b/sc/inc/document.hxx
@@ -571,6 +571,7 @@ public:
 
 void AppendTabOnLoad(const rtl::OUString& rName);
 void SetTabNameOnLoad(SCTAB nTab, const rtl::OUString& rName);
+void InvalidateStreamOnSave();
 
 SC_DLLPUBLIC bool   InsertTab( SCTAB nPos, const rtl::OUString& 
rName,
 bool bExternalDocument = false );
diff --git a/sc/source/core/data/document.cxx b/sc/source/core/data/document.cxx
index 9d8a8c3..65e904f 100644
--- a/sc/source/core/data/document.cxx
+++ b/sc/source/core/data/document.cxx
@@ -402,6 +402,17 @@ void ScDocument::SetTabNameOnLoad(SCTAB nTab, const 
rtl::OUString& rName)
 maTabs[nTab]->SetName(rName);
 }
 
+void ScDocument::InvalidateStreamOnSave()
+{
+TableContainer::iterator it = maTabs.begin(), itEnd = maTabs.end();
+for (; it != itEnd; ++it)
+{
+ScTable* pTab = *it;
+if (pTab)
+pTab->SetStreamValid(false);
+}
+}
+
 bool ScDocument::InsertTab( SCTAB nPos, const rtl::OUString& rName,
 bool bExternalDocument )
 {
diff --git a/sc/source/ui/docshell/docsh.cxx b/sc/source/ui/docshell/docsh.cxx
index 291f5e0..948f622 100644
--- a/sc/source/ui/docshell/docsh.cxx
+++ b/sc/source/ui/docshell/docsh.cxx
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include "svl/urihelper.hxx"
 #include "chgtrack.hxx"
 #include "chgviset.hxx"
 #include 
@@ -1526,10 +1527,45 @@ sal_Bool ScDocShell::Save()
 return bRet;
 }
 
+namespace {
+
+/**
+ * Remove the file name from the full path, to keep only the directory path.
+ */
+void popFileName(OUString& rPath)
+{
+if (!rPath.isEmpty())
+{
+INetURLObject aURLObj(rPath);
+aURLObj.removeSegment();
+rPath = aURLObj.GetMainURL(INetURLObject::NO_DECODE);
+}
+}
+
+}
 
 sal_Bool ScDocShell::SaveAs( SfxMedium& rMedium )
 {
-RTL_LOGFILE_CONTEXT_AUTHOR ( aLog, "sc", "nn93723", "ScDocShell::SaveAs" );
+OUString aCurPath; // empty for new document that hasn't been saved.
+const SfxMedium* pCurMedium = GetMedium();
+if (pCurMedium)
+{
+aCurPath = pCurMedium->GetName();
+popFileName(aCurPath);
+}
+
+if (!aCurPath.isEmpty())
+{
+// current document has a path -> not a brand-new document.
+OUString aNewPath = rMedium.GetName();
+popFileName(aNewPath);
+OUString aRel = URIHelper::simpleNormalizedMakeRelative(aCurPath, 
aNewPath);
+if (!aRel.isEmpty())
+{
+// Directory path will change before and after the save.
+aDocument.InvalidateStreamOnSave();
+}
+}
 
 ScTabViewShell* pViewShell = GetBestViewShell();
 bool bNeedsRehash = ScPassHashHelper::needsPassHashRegen(aDocument, 
PASSHASH_SHA1);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: 2 commits - sc/source

[Libreoffice Gerrit user]

 sc/source/core/data/dpfilteredcache.cxx |   12 +++-
 sc/source/ui/docshell/dbdocfun.cxx  |7 ---
 2 files changed, 15 insertions(+), 4 deletions(-)

New commits:
commit 3db92283955741b490dc2d4f9e1782b179fee894
Author: Kohei Yoshida 
Date:   Thu Jan 10 23:48:17 2013 -0500

fdo#59084: Sync dimension members after reloading the group data.

Else the syncing would end up syncing to the older version of the
group data before the reload, which (as you can see in the bug report)
may lead to a crash.

Change-Id: Ibd674a97a59205e5e28efd007f8857731e8df4d3

diff --git a/sc/source/ui/docshell/dbdocfun.cxx 
b/sc/source/ui/docshell/dbdocfun.cxx
index 4d0d2ec..94d4f1f 100644
--- a/sc/source/ui/docshell/dbdocfun.cxx
+++ b/sc/source/ui/docshell/dbdocfun.cxx
@@ -1319,6 +1319,8 @@ bool ScDBDocFunc::DataPilotUpdate( ScDPObject* pOldObj, 
const ScDPObject* pNewOb
 if ( pDestObj )
 {
 pDestObj->ReloadGroupTableData();
+if (!pDestObj->SyncAllDimensionMembers())
+return false;
 pDestObj->InvalidateData(); // before getting the 
new output area
 
 //  make sure the table has a name (not set by dialog)
@@ -1461,11 +1463,10 @@ sal_uLong ScDBDocFunc::RefreshPivotTables(ScDPObject* 
pDPObj, bool bApi)
 for (; it != itEnd; ++it)
 {
 ScDPObject* pObj = *it;
-if (!pObj->SyncAllDimensionMembers())
-continue;
 
 // This action is intentionally not undoable since it modifies cache.
-DataPilotUpdate(pObj, pObj, false, bApi);
+if (!DataPilotUpdate(pObj, pObj, false, bApi))
+continue;
 }
 
 return 0;
commit 6fae3211507884e23b305c1f55e7b1be7951f7a9
Author: Kohei Yoshida 
Date:   Thu Jan 10 23:17:18 2013 -0500

Dump field member IDs cached in the filtered cache object.

Change-Id: Id792e9e58a2c62b742eb07b400d30c5027bbc87b

diff --git a/sc/source/core/data/dpfilteredcache.cxx 
b/sc/source/core/data/dpfilteredcache.cxx
index ff82719..e3231ce 100644
--- a/sc/source/core/data/dpfilteredcache.cxx
+++ b/sc/source/core/data/dpfilteredcache.cxx
@@ -437,7 +437,7 @@ void ScDPFilteredCache::dumpRowFlag(const RowFlagType& 
rFlag) const
 
 void ScDPFilteredCache::dump() const
 {
-cout << "--- pivot cache filter dump" << endl;
+cout << "--- pivot filtered cache dump" << endl;
 
 cout << endl;
 cout << "* show by filter" << endl;
@@ -447,6 +447,16 @@ void ScDPFilteredCache::dump() const
 cout << "* show by page dimensions" << endl;
 dumpRowFlag(maShowByPage);
 
+cout << endl;
+cout << "* field entries" << endl;
+size_t nFieldCount = maFieldEntries.size();
+for (size_t i = 0; i < nFieldCount; ++i)
+{
+const vector& rField = maFieldEntries[i];
+cout << "  * field " << i << endl;
+for (size_t j = 0, n = rField.size(); j < n; ++j)
+cout << "ID: " << rField[j] << endl;
+}
 cout << "---" << endl;
 }
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PUSHED] Change in core[libreoffice-4-0]: Resolves: fdo#58301 make sure ScrollBar OptimalSize is up to...

[Kohei Yoshida (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1630

Approvals:
  Kohei Yoshida: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1630
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I12e95c3594ffbb508c7f79bd512e07aaf44a6eab
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 
Gerrit-Reviewer: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - vcl/inc vcl/source

[Libreoffice Gerrit user]

 vcl/inc/vcl/scrbar.hxx|3 ++-
 vcl/source/control/scrbar.cxx |   11 +--
 2 files changed, 11 insertions(+), 3 deletions(-)

New commits:
commit c5c22a10d41ae79b43edbf36962245c824a32e17
Author: Caolán McNamara 
Date:   Tue Dec 4 16:16:14 2012 +

Resolves: fdo#58301 make sure ScrollBar OptimalSize is up to date

if the scrollbar sizes haven't been calculated yet then the optimalsize 
will be
wrong, so it's necessary to enforce calculating them in that case.

(cherry picked from commit f41a2804dd4a23352b7af2dd28c03df02debfb13)

Change-Id: I12e95c3594ffbb508c7f79bd512e07aaf44a6eab
Reviewed-on: https://gerrit.libreoffice.org/1630
Reviewed-by: Kohei Yoshida 
Tested-by: Kohei Yoshida 

diff --git a/vcl/inc/vcl/scrbar.hxx b/vcl/inc/vcl/scrbar.hxx
index 8dbe270..7c62d94 100644
--- a/vcl/inc/vcl/scrbar.hxx
+++ b/vcl/inc/vcl/scrbar.hxx
@@ -83,8 +83,9 @@ private:
 SAL_DLLPRIVATE long ImplDoAction( sal_Bool bCallEndScroll );
 SAL_DLLPRIVATE void ImplDoMouseAction( const Point& rPos, sal_Bool 
bCallAction = sal_True );
 SAL_DLLPRIVATE void ImplInvert();
-SAL_DLLPRIVATE sal_Bool ImplDrawNative( sal_uInt16 nDrawFlags );
+SAL_DLLPRIVATE sal_Bool ImplDrawNative( sal_uInt16 nDrawFlags );
 SAL_DLLPRIVATE void ImplDragThumb( const Point& rMousePos );
+SAL_DLLPRIVATE Size getCurrentCalcSize() const;
 DECL_DLLPRIVATE_LINK(   ImplTimerHdl, Timer* );
 DECL_DLLPRIVATE_LINK(   ImplAutoTimerHdl, void* );
 
diff --git a/vcl/source/control/scrbar.cxx b/vcl/source/control/scrbar.cxx
index 9e90362..b99ff26 100644
--- a/vcl/source/control/scrbar.cxx
+++ b/vcl/source/control/scrbar.cxx
@@ -323,7 +323,7 @@ void ScrollBar::ImplCalc( sal_Bool bUpdate )
 Rectangle& maTrackRect = mpData->maTrackRect;  // TODO: remove when 
maTrackRect is no longer in mpData
 if ( mbCalcSize )
 {
-Size aOldSize = GetOptimalSize(WINDOWSIZE_PREFERRED);
+Size aOldSize = getCurrentCalcSize();
 
 const Rectangle aControlRegion( Point(0,0), aSize );
 Rectangle aBtn1Region, aBtn2Region, aTrackRegion, aBoundingRegion;
@@ -416,7 +416,7 @@ void ScrollBar::ImplCalc( sal_Bool bUpdate )
 
 mbCalcSize = sal_False;
 
-Size aNewSize = GetOptimalSize(WINDOWSIZE_PREFERRED);
+Size aNewSize = getCurrentCalcSize();
 if (aOldSize != aNewSize)
 {
 queue_resize();
@@ -1509,6 +1509,13 @@ void ScrollBar::SetVisibleSize( long nNewSize )
 
 Size ScrollBar::GetOptimalSize(WindowSizeType) const
 {
+if (mbCalcSize)
+const_cast(this)->ImplCalc(sal_False);
+return getCurrentCalcSize();
+}
+
+Size ScrollBar::getCurrentCalcSize() const
+{
 Rectangle aCtrlRegion;
 aCtrlRegion.Union(maBtn1Rect);
 aCtrlRegion.Union(maBtn2Rect);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PUSHED] Change in core[libreoffice-4-0]: Resolves: fdo#59112 re-scroll to current entry when dialog r...

[Kohei Yoshida (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1628

Approvals:
  Kohei Yoshida: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1628
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I96486f6edad11520bf9bb43b700b1716d9b2f170
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 
Gerrit-Reviewer: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - sc/source

[Libreoffice Gerrit user]

 sc/source/ui/dbgui/sortkeydlg.cxx |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 90fe1b210025c19e885b093bf2f556d5b62f9dd4
Author: Caolán McNamara 
Date:   Thu Jan 10 13:49:20 2013 +

Resolves: fdo#59112 re-scroll to current entry when dialog resized

Change-Id: I96486f6edad11520bf9bb43b700b1716d9b2f170
(cherry picked from commit 2c403c7f36561410418ebb9f86664e46a8c1c968)
Reviewed-on: https://gerrit.libreoffice.org/1628
Reviewed-by: Kohei Yoshida 
Tested-by: Kohei Yoshida 

diff --git a/sc/source/ui/dbgui/sortkeydlg.cxx 
b/sc/source/ui/dbgui/sortkeydlg.cxx
index 45d65ca..e71a48f 100644
--- a/sc/source/ui/dbgui/sortkeydlg.cxx
+++ b/sc/source/ui/dbgui/sortkeydlg.cxx
@@ -127,6 +127,7 @@ void ScSortKeyCtrl::setScrollRange()
 sal_Int32 nVisibleItems = m_rScrolledWindow.getVisibleChildSize().Height() 
/ nScrollOffset;
 m_rVertScroll.SetPageSize( nVisibleItems - 1 );
 m_rVertScroll.SetVisibleSize( nVisibleItems );
+m_rVertScroll.Scroll();
 }
 
 // ---
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PUSHED] Change in core[libreoffice-4-0]: - fdo#46460 - Missing Circles and Ovals toolbar

[Kohei Yoshida (via Code Review)]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1627

Approvals:
  Kohei Yoshida: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1627
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 
Gerrit-Reviewer: Kohei Yoshida 
Gerrit-Reviewer: Rob Snelders 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - officecfg/registry

[Libreoffice Gerrit user]

 officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit d32d05c70bc8e6389e80b33f5a7156ff7836f6da
Author: Rob Snelders 
Date:   Thu Dec 20 21:40:22 2012 +0100

- fdo#46460 - Missing Circles and Ovals toolbar

Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Reviewed-on: https://gerrit.libreoffice.org/1456
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 
(cherry picked from commit dcd974c3ca70065ba1d984ad6bd5514848cd58a9)
Reviewed-on: https://gerrit.libreoffice.org/1627
Reviewed-by: Kohei Yoshida 
Tested-by: Kohei Yoshida 

diff --git 
a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu 
b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
index b035510..42358d2d 100644
--- a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
+++ b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
@@ -252,7 +252,7 @@
 false
 
 
-true
+false
 
 
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: Crash on Right-click on misspelled word

[Terrence Enger]

On Wed, 2013-01-09 at 11:37 +0100, Samuel Mehrbrodt wrote:
> In my build (Jan 7th, I755ea5b2ec7b6357a7fd2c86ec8479737696042b) I have 
> a crash in Writer when I right-click on a misspelled word.
> Do I need to update or is this a bug that is still there?
> 

Samuel,

Well, my latest build is master as of 8 days ago and I have an unusual
configuration, and I am running on a particular platform, and my
installation is English, so it does not mean much that I do not see a
crash.

Meanwhile, I suggest that you file a bug report through the Bug
Submission Assistant .
That is the natural place to collect information about platforms and
versions and configurations of LibreOffice which are or are not
afflicted with the problem.  A very important part of the report is a
description of what you do to get to the crash; please do not skimp
here.  Similarly, a description of your environment will be necessary.

Feel free to add me, lo_b...@iseries-guru.com to the cc field of the
bug report if you think I may be able to help further.

HTH,
Terry.

> Samuel


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Mesa/README

[Libreoffice Gerrit user]

 Mesa/README |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

New commits:
commit c5ade001383bf6fd0c339b73a5d29634de5e4062
Author: Tor Lillqvist 
Date:   Fri Jan 11 00:04:02 2013 +0200

Update, not all of this is from "Mesa"

Change-Id: I7696b6ab6b8c9a4dea99a47f091aefd643b9829b

diff --git a/Mesa/README b/Mesa/README
index 4623d60..568d314 100644
--- a/Mesa/README
+++ b/Mesa/README
@@ -1 +1,2 @@
-A copy of OpenGL headers from Mesa, needed on older Linux distros
+A copy of OpenGL headers from Mesa and Khronos. Needed on older Linux
+distros and for Windows.
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: slideshow/source

[Libreoffice Gerrit user]

 slideshow/source/engine/OGLTrans/generic/OGLTrans_Shaders.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 294ec42e765ae478c00b3a2051e04224c30f47a4
Author: Tor Lillqvist 
Date:   Fri Jan 11 00:03:34 2013 +0200

Copy/paste error

Change-Id: I9e4ba84eb1cc3dff8c39369a9da32dd49839ecef

diff --git a/slideshow/source/engine/OGLTrans/generic/OGLTrans_Shaders.cxx 
b/slideshow/source/engine/OGLTrans/generic/OGLTrans_Shaders.cxx
index e2f1a58..ea8bdb6 100644
--- a/slideshow/source/engine/OGLTrans/generic/OGLTrans_Shaders.cxx
+++ b/slideshow/source/engine/OGLTrans/generic/OGLTrans_Shaders.cxx
@@ -93,7 +93,7 @@ bool OGLShaders::Initialize()
 cbInitialized = true;
 #elif defined(MACOSX)
 #else
-glActiveTexture = (PFNGLCREATESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glActiveTexture" );
+glActiveTexture = (PFNGLACTIVETEXTUREPROC) unx::glXGetProcAddress( 
(unsigned char *) "glActiveTexture" );
 glCreateShader = (PFNGLCREATESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glCreateShader" );
 glShaderSource = (PFNGLSHADERSOURCEPROC) unx::glXGetProcAddress( 
(unsigned char *) "glShaderSource" );
 glCompileShader = (PFNGLCOMPILESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glCompileShader" );
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: slideshow/source

[Libreoffice Gerrit user]

 slideshow/source/engine/OGLTrans/win/UNUSED |4 
 1 file changed, 4 insertions(+)

New commits:
commit ab4a0f1165e43d5052603a1c66a07585edd2919e
Author: Tor Lillqvist 
Date:   Thu Jan 10 23:59:06 2013 +0200

Add note that these files are unused

Change-Id: I7fd226bf61d9983d843453919a0406442daaea70

diff --git a/slideshow/source/engine/OGLTrans/win/UNUSED 
b/slideshow/source/engine/OGLTrans/win/UNUSED
new file mode 100644
index 000..21b866b
--- /dev/null
+++ b/slideshow/source/engine/OGLTrans/win/UNUSED
@@ -0,0 +1,4 @@
+These source files are not built, but let's keep them until somebody
+has verified whether there is some Windows-specific code in them that
+is useful and isn't present in the code in ../generic, which now is
+for both X11 and Windows.
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: gmake: CXXFLAGS override gb_Library_add_cxxflags

[Lubos Lunak]

On Thursday 10 of January 2013, Matúš Kukan wrote:
> On 10 January 2013 09:16, Stephan Bergmann  wrote:
> > Ah, so Petr's "IMHO, it would make sense to use CXXFLAGS after the
> > default global flags but before the source file specific flags" sounds
> > reasonable to me.
>
> See https://gerrit.libreoffice.org/#/c/1632/ for a reasonable easy way
> to do this.
> It should work, etc.
> But it may break PCH_CXXFLAGS. I don't feel like testing --enable-pch
> build.

- for PCH gb_CxxObject__set_pchflags should be modified too.

- shouldn't the new flags be initialized in gb_LinkTarget_LinkTarget?

- (as a general rule) for non-obvious commits, please include in the commit 
log message not only what but also why, such as a link to this thread. In a 
year somebody's bound to want to reshuffle the flags and wonder about the 
commit.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: oox/inc sc/inc sd/inc svtools/inc svx/inc sw/inc vcl/inc writerfilter/inc

[Libreoffice Gerrit user]

 oox/inc/pch/precompiled_oox.hxx   |2 -
 sc/inc/pch/precompiled_sc.hxx |2 -
 sd/inc/pch/precompiled_sd.hxx |7 ++--
 svtools/inc/pch/precompiled_svt.hxx   |   31 ++---
 svx/inc/pch/precompiled_svx.hxx   |4 ++
 svx/inc/pch/precompiled_svxcore.hxx   |7 ++--
 sw/inc/pch/precompiled_msword.hxx |4 ++
 sw/inc/pch/precompiled_sw.hxx |3 +-
 vcl/inc/pch/precompiled_vcl.hxx   |   32 ++
 writerfilter/inc/pch/precompiled_writerfilter.hxx |4 ++
 10 files changed, 55 insertions(+), 41 deletions(-)

New commits:
commit 43f3be84c2ee77c3cd97fb729048f1c45f98b295
Author: Luboš Luňák 
Date:   Thu Jan 10 22:23:25 2013 +0100

include PCH headers for headers changes

Change-Id: Id94a4322428e27010757ef36b166f8b01697778f

diff --git a/oox/inc/pch/precompiled_oox.hxx b/oox/inc/pch/precompiled_oox.hxx
index 28a2030..c59a451 100644
--- a/oox/inc/pch/precompiled_oox.hxx
+++ b/oox/inc/pch/precompiled_oox.hxx
@@ -342,7 +342,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -360,6 +359,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/sc/inc/pch/precompiled_sc.hxx b/sc/inc/pch/precompiled_sc.hxx
index 83b3b9b..bc4f898 100644
--- a/sc/inc/pch/precompiled_sc.hxx
+++ b/sc/inc/pch/precompiled_sc.hxx
@@ -648,7 +648,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -872,6 +871,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/sd/inc/pch/precompiled_sd.hxx b/sd/inc/pch/precompiled_sd.hxx
index 6283dbc..2056f77 100644
--- a/sd/inc/pch/precompiled_sd.hxx
+++ b/sd/inc/pch/precompiled_sd.hxx
@@ -539,14 +539,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -567,7 +565,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -774,6 +771,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -809,6 +807,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -828,6 +827,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -861,6 +861,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/svtools/inc/pch/precompiled_svt.hxx 
b/svtools/inc/pch/precompiled_svt.hxx
index 5fd85ce..4136f1b 100644
--- a/svtools/inc/pch/precompiled_svt.hxx
+++ b/svtools/inc/pch/precompiled_svt.hxx
@@ -22,11 +22,9 @@
 #include "comphelper/string.hxx"
 #include "cppuhelper/implementationentry.hxx"
 #include "osl/diagnose.h"
-#include "osl/module.hxx"
 #include "rtl/ustring.hxx"
 #include "sal/config.h"
 #include "sal/types.h"
-#include "stdio.h"
 #include "svl/filenotation.hxx"
 #include "svl/inettype.hxx"
 #include "svl/urihelper.hxx"
@@ -52,14 +50,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -101,7 +95,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -182,7 +175,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -199,7 +191,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -235,15 +226,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -257,7 +243,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -266,8 +251,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -279,7 +262,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -317,7 +299,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -328,7 +309,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -376,7 +356,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -415,7 +394,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -428,6 +406,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -436,7 +415,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -453,7 +431,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -470,12 +448,9 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -486,7 +461,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -498,6 +472,7 @@
 #include 
 #include 
 #i

Inlining acquire and release in osl/mutex.

[Arnaud Versini (via Code Review)]

Arnaud Versini has abandoned this change.

Change subject: Inlining acquire and release in osl/mutex.
..


Patch Set 2: Abandoned

-- 
To view, visit https://gerrit.libreoffice.org/1276
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: abandon
Gerrit-Change-Id: I6bcbad2697a84449b7038aafdc9a988580104e68
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Arnaud Versini 
Gerrit-Reviewer: Arnaud Versini 
Gerrit-Reviewer: Caolán McNamara 
Gerrit-Reviewer: Michael Stahl 
Gerrit-Reviewer: Norbert Thiebaud 
Gerrit-Reviewer: Stephan Bergmann 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Use less RTTI in PDFParse by adding more virtual functions.

[Arnaud Versini (via Code Review)]

Arnaud Versini has abandoned this change.

Change subject: Use less RTTI in PDFParse by adding more virtual functions.
..


Patch Set 3: Abandoned

-- 
To view, visit https://gerrit.libreoffice.org/1035
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: abandon
Gerrit-Change-Id: I0e394f5f28874e66c833adfe6440f138321d6455
Gerrit-PatchSet: 3
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Arnaud Versini 
Gerrit-Reviewer: Arnaud Versini 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: fdo#58069: Invalidate sheet stream cache when directory path...

[Kohei Yoshida (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1634

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/34/1634/1

fdo#58069: Invalidate sheet stream cache when directory path changes.

To properly regenerate hyperlinks (among other things) which depend on
the full path of the host document.

Change-Id: I44fdd5b0ef0a57bf4fae13f29f1ebacfe1ab19a8
---
M sc/inc/document.hxx
M sc/source/core/data/document.cxx
M sc/source/ui/docshell/docsh.cxx
3 files changed, 49 insertions(+), 1 deletion(-)



diff --git a/sc/inc/document.hxx b/sc/inc/document.hxx
index 5b5a472..76df284 100644
--- a/sc/inc/document.hxx
+++ b/sc/inc/document.hxx
@@ -571,6 +571,7 @@
 
 void AppendTabOnLoad(const rtl::OUString& rName);
 void SetTabNameOnLoad(SCTAB nTab, const rtl::OUString& rName);
+void InvalidateStreamOnSave();
 
 SC_DLLPUBLIC bool   InsertTab( SCTAB nPos, const rtl::OUString& 
rName,
 bool bExternalDocument = false );
diff --git a/sc/source/core/data/document.cxx b/sc/source/core/data/document.cxx
index 9d8a8c3..65e904f 100644
--- a/sc/source/core/data/document.cxx
+++ b/sc/source/core/data/document.cxx
@@ -402,6 +402,17 @@
 maTabs[nTab]->SetName(rName);
 }
 
+void ScDocument::InvalidateStreamOnSave()
+{
+TableContainer::iterator it = maTabs.begin(), itEnd = maTabs.end();
+for (; it != itEnd; ++it)
+{
+ScTable* pTab = *it;
+if (pTab)
+pTab->SetStreamValid(false);
+}
+}
+
 bool ScDocument::InsertTab( SCTAB nPos, const rtl::OUString& rName,
 bool bExternalDocument )
 {
diff --git a/sc/source/ui/docshell/docsh.cxx b/sc/source/ui/docshell/docsh.cxx
index 291f5e0..948f622 100644
--- a/sc/source/ui/docshell/docsh.cxx
+++ b/sc/source/ui/docshell/docsh.cxx
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include "svl/urihelper.hxx"
 #include "chgtrack.hxx"
 #include "chgviset.hxx"
 #include 
@@ -1526,10 +1527,45 @@
 return bRet;
 }
 
+namespace {
+
+/**
+ * Remove the file name from the full path, to keep only the directory path.
+ */
+void popFileName(OUString& rPath)
+{
+if (!rPath.isEmpty())
+{
+INetURLObject aURLObj(rPath);
+aURLObj.removeSegment();
+rPath = aURLObj.GetMainURL(INetURLObject::NO_DECODE);
+}
+}
+
+}
 
 sal_Bool ScDocShell::SaveAs( SfxMedium& rMedium )
 {
-RTL_LOGFILE_CONTEXT_AUTHOR ( aLog, "sc", "nn93723", "ScDocShell::SaveAs" );
+OUString aCurPath; // empty for new document that hasn't been saved.
+const SfxMedium* pCurMedium = GetMedium();
+if (pCurMedium)
+{
+aCurPath = pCurMedium->GetName();
+popFileName(aCurPath);
+}
+
+if (!aCurPath.isEmpty())
+{
+// current document has a path -> not a brand-new document.
+OUString aNewPath = rMedium.GetName();
+popFileName(aNewPath);
+OUString aRel = URIHelper::simpleNormalizedMakeRelative(aCurPath, 
aNewPath);
+if (!aRel.isEmpty())
+{
+// Directory path will change before and after the save.
+aDocument.InvalidateStreamOnSave();
+}
+}
 
 ScTabViewShell* pViewShell = GetBestViewShell();
 bool bNeedsRehash = ScPassHashHelper::needsPassHashRegen(aDocument, 
PASSHASH_SHA1);

-- 
To view, visit https://gerrit.libreoffice.org/1634
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I44fdd5b0ef0a57bf4fae13f29f1ebacfe1ab19a8
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: [libreoffice-dev] - questions about calc extension

[Rai, Neeraj]

Hi Michael,

That's loads of good info. Looking at your link below and browsing around, I 
realised what Stephen meant when he used "EasyHacks" in one of the replies.
For now I'll stick with the 3.6.4.3 and refer to release notes as I upgrade to 
newer versions.

Thanks
Neeraj

-Original Message-
From: Michael Stahl [mailto:mst...@redhat.com]
Sent: Thursday, January 10, 2013 11:59 AM
To: Rai, Neeraj [ICG-MKTS]
Cc: 'libreoffice@lists.freedesktop.org'
Subject: Re: [libreoffice-dev] - questions about calc extension

On 10/01/13 16:42, Rai, Neeraj wrote:
> Hi Stephan,
>
> I am unable to find XDesktop2. Your sample below looks really simple
> and right way to go. I am working with release version 3.6.4.3 -
> built it from tar files.

XDesktop2 was only added a month ago, so it's only in 4.0.

of course when using the newest features it's always a problem that it
doesn't allow deploying your extension or whatever on older versions then...

> I don't mind upgrading to latest tip, but I had trouble building the
> git checkout version. Being fairly new to this large and
> comprehensive product, I decided to take the easy way to begin.

you can also download 4.0 beta releases, actually there should be a RC1
now even; i would expect those also have the SDK available.

> I would also be curious to know how to find out about such api -
> unfortunately, right now I am reading only specific emails on dev
> group and unable to follow conversations on other topics. Is reading
> docs the best way ? Is it possible to find some sample code ?

good question... currently the only real info for developers who don't
follow the git commits, which is probably no extension or macro
developer does, is the 4.0 release notes, which has a section on API
Changes:

https://wiki.documentfoundation.org/ReleaseNotes/4.0#API_Changes

but that doesn't talk much about what is added, mostly it's about what
is changed or removed.

of course you can also search in the API reference (or the IDL files)
for "since" tags with a particular version.

the OOo project had a "interface-announce" mailing list, which was used
both for API changes and additions, and for internal implementation
interface changes; i wonder how many extension developers actually read
that list in its time.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: sc/inc sc/source

[Libreoffice Gerrit user]

 sc/inc/document.hxx  |1 +
 sc/source/core/data/document.cxx |   11 +++
 sc/source/ui/docshell/docsh.cxx  |   38 +-
 3 files changed, 49 insertions(+), 1 deletion(-)

New commits:
commit 831d1b6e62e91e67f171bd00305651043731d496
Author: Kohei Yoshida 
Date:   Thu Jan 10 16:21:05 2013 -0500

fdo#58069: Invalidate sheet stream cache when directory path changes.

To properly regenerate hyperlinks (among other things) which depend on
the full path of the host document.

Change-Id: I44fdd5b0ef0a57bf4fae13f29f1ebacfe1ab19a8

diff --git a/sc/inc/document.hxx b/sc/inc/document.hxx
index a72f759..7573a80 100644
--- a/sc/inc/document.hxx
+++ b/sc/inc/document.hxx
@@ -572,6 +572,7 @@ public:
 
 void AppendTabOnLoad(const rtl::OUString& rName);
 void SetTabNameOnLoad(SCTAB nTab, const rtl::OUString& rName);
+void InvalidateStreamOnSave();
 
 SC_DLLPUBLIC bool   InsertTab( SCTAB nPos, const rtl::OUString& 
rName,
 bool bExternalDocument = false );
diff --git a/sc/source/core/data/document.cxx b/sc/source/core/data/document.cxx
index 78ae823..a3e5cfa 100644
--- a/sc/source/core/data/document.cxx
+++ b/sc/source/core/data/document.cxx
@@ -402,6 +402,17 @@ void ScDocument::SetTabNameOnLoad(SCTAB nTab, const 
rtl::OUString& rName)
 maTabs[nTab]->SetName(rName);
 }
 
+void ScDocument::InvalidateStreamOnSave()
+{
+TableContainer::iterator it = maTabs.begin(), itEnd = maTabs.end();
+for (; it != itEnd; ++it)
+{
+ScTable* pTab = *it;
+if (pTab)
+pTab->SetStreamValid(false);
+}
+}
+
 bool ScDocument::InsertTab( SCTAB nPos, const rtl::OUString& rName,
 bool bExternalDocument )
 {
diff --git a/sc/source/ui/docshell/docsh.cxx b/sc/source/ui/docshell/docsh.cxx
index c8ff10b..2c35c01 100644
--- a/sc/source/ui/docshell/docsh.cxx
+++ b/sc/source/ui/docshell/docsh.cxx
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include "svl/urihelper.hxx"
 #include "chgtrack.hxx"
 #include "chgviset.hxx"
 #include 
@@ -1528,10 +1529,45 @@ sal_Bool ScDocShell::Save()
 return bRet;
 }
 
+namespace {
+
+/**
+ * Remove the file name from the full path, to keep only the directory path.
+ */
+void popFileName(OUString& rPath)
+{
+if (!rPath.isEmpty())
+{
+INetURLObject aURLObj(rPath);
+aURLObj.removeSegment();
+rPath = aURLObj.GetMainURL(INetURLObject::NO_DECODE);
+}
+}
+
+}
 
 sal_Bool ScDocShell::SaveAs( SfxMedium& rMedium )
 {
-RTL_LOGFILE_CONTEXT_AUTHOR ( aLog, "sc", "nn93723", "ScDocShell::SaveAs" );
+OUString aCurPath; // empty for new document that hasn't been saved.
+const SfxMedium* pCurMedium = GetMedium();
+if (pCurMedium)
+{
+aCurPath = pCurMedium->GetName();
+popFileName(aCurPath);
+}
+
+if (!aCurPath.isEmpty())
+{
+// current document has a path -> not a brand-new document.
+OUString aNewPath = rMedium.GetName();
+popFileName(aNewPath);
+OUString aRel = URIHelper::simpleNormalizedMakeRelative(aCurPath, 
aNewPath);
+if (!aRel.isEmpty())
+{
+// Directory path will change before and after the save.
+aDocument.InvalidateStreamOnSave();
+}
+}
 
 ScTabViewShell* pViewShell = GetBestViewShell();
 bool bNeedsRehash = ScPassHashHelper::needsPassHashRegen(aDocument, 
PASSHASH_SHA1);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PATCH] Remove useless callback in unix socket implementation

[Arnaud Versini (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1633

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/33/1633/1

Remove useless callback in unix socket implementation

Change-Id: Ibe46e2f1628f4d2e4840429703e0d5a69059a188
---
M sal/osl/unx/socket.c
M sal/osl/unx/sockimpl.h
2 files changed, 0 insertions(+), 16 deletions(-)



diff --git a/sal/osl/unx/socket.c b/sal/osl/unx/socket.c
index 1af9039..a9f3fc0 100644
--- a/sal/osl/unx/socket.c
+++ b/sal/osl/unx/socket.c
@@ -469,8 +469,6 @@
 
 pSocket->m_Socket = Socket;
 pSocket->m_nLastError = 0;
-pSocket->m_CloseCallback = 0;
-pSocket->m_CallbackArg = 0;
 pSocket->m_nRefCount = 1;
 
 #if defined(LINUX)
@@ -1466,10 +1464,6 @@
 {
 pSocket->m_nLastError=errno;
 }
-
-
-pSocket->m_CloseCallback= NULL;
-pSocket->m_CallbackArg  = NULL;
 }
 
 return pSocket;
@@ -1559,12 +1553,6 @@
 pSocket->m_bIsAccepting = sal_False;
 }
 #endif /* LINUX */
-
-/* registrierten Callback ausfuehren */
-if (pSocket->m_CloseCallback != NULL)
-{
-pSocket->m_CloseCallback(pSocket->m_CallbackArg);
-}
 
 nRet=close(nFD);
 if ( nRet != 0 )
@@ -1905,8 +1893,6 @@
 
 pConnectionSockImpl->m_Socket   = Connection;
 pConnectionSockImpl->m_nLastError   = 0;
-pConnectionSockImpl->m_CloseCallback= NULL;
-pConnectionSockImpl->m_CallbackArg  = NULL;
 #if defined(LINUX)
 pConnectionSockImpl->m_bIsAccepting = sal_False;
 
diff --git a/sal/osl/unx/sockimpl.h b/sal/osl/unx/sockimpl.h
index d2c68b6..353d915 100644
--- a/sal/osl/unx/sockimpl.h
+++ b/sal/osl/unx/sockimpl.h
@@ -33,8 +33,6 @@
 struct oslSocketImpl {
 int m_Socket;
 int m_nLastError;
-oslCloseCallbackm_CloseCallback;
-void*   m_CallbackArg;
 oslInterlockedCount m_nRefCount;
 #if defined(LINUX)
 sal_Boolm_bIsAccepting;

-- 
To view, visit https://gerrit.libreoffice.org/1633
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ibe46e2f1628f4d2e4840429703e0d5a69059a188
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Arnaud Versini 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gmake: CXXFLAGS override gb_Library_add_cxxflags

[Matúš Kukan]

On 10 January 2013 09:16, Stephan Bergmann  wrote:
> Ah, so Petr's "IMHO, it would make sense to use CXXFLAGS after the default
> global flags but before the source file specific flags" sounds reasonable to
> me.

See https://gerrit.libreoffice.org/#/c/1632/ for a reasonable easy way
to do this.
It should work, etc.
But it may break PCH_CXXFLAGS. I don't feel like testing --enable-pch build.

HTH,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] append library specific compile flags at the end

[via Code Review]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1632

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/32/1632/1

append library specific compile flags at the end

Change-Id: If9d4640b59dd411734a581c66f9310d31ab9fbb7
---
M solenv/gbuild/LinkTarget.mk
M solenv/gbuild/platform/com_GCC_class.mk
M solenv/gbuild/platform/com_MSC_class.mk
3 files changed, 16 insertions(+), 16 deletions(-)



diff --git a/solenv/gbuild/LinkTarget.mk b/solenv/gbuild/LinkTarget.mk
index 2fb94f0..38cece0 100644
--- a/solenv/gbuild/LinkTarget.mk
+++ b/solenv/gbuild/LinkTarget.mk
@@ -632,9 +632,9 @@
 endef
 
 define gb_LinkTarget_add_cflags
-$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS += $(2)
+$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS_APPEND += $(2)
 ifeq ($(gb_FULLDEPS),$(true))
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS += $(2)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS_APPEND += $(2)
 endif
 
 endef
@@ -648,11 +648,11 @@
 
 define gb_LinkTarget_add_cxxflags
 $(call gb_LinkTarget_get_headers_target,$(1)) \
-$(call gb_LinkTarget_get_target,$(1)) : T_CXXFLAGS += $(2)
+$(call gb_LinkTarget_get_target,$(1)) : T_CXXFLAGS_APPEND += $(2)
 $(call gb_LinkTarget_get_headers_target,$(1)) \
 $(call gb_LinkTarget_get_target,$(1)) : PCH_CXXFLAGS += $(2)
 ifeq ($(gb_FULLDEPS),$(true))
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS += $(2)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS_APPEND += $(2)
 $(call gb_LinkTarget_get_dep_target,$(1)) : PCH_CXXFLAGS += $(2)
 endif
 endef
@@ -664,9 +664,9 @@
 endef
 
 define gb_LinkTarget_add_objcxxflags
-$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS += $(2)
+$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS_APPEND += $(2)
 ifeq ($(gb_FULLDEPS),$(true))
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS += $(2)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS_APPEND += $(2)
 endif
 endef
 
@@ -683,9 +683,9 @@
 endef
 
 define gb_LinkTarget_add_objcflags
-$(call gb_LinkTarget_get_target,$(1)) : T_OBJCFLAGS += $(2)
+$(call gb_LinkTarget_get_target,$(1)) : T_OBJCFLAGS_APPEND += $(2)
 ifeq ($(gb_FULLDEPS),$(true))
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCFLAGS += $(2)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCFLAGS_APPEND += $(2)
 endif
 
 endef
diff --git a/solenv/gbuild/platform/com_GCC_class.mk 
b/solenv/gbuild/platform/com_GCC_class.mk
index 350e000..4ea1a14 100644
--- a/solenv/gbuild/platform/com_GCC_class.mk
+++ b/solenv/gbuild/platform/com_GCC_class.mk
@@ -65,7 +65,7 @@
$(if $(VISIBILITY),,$(gb_VISIBILITY_FLAGS)) \
$(if $(WARNINGS_NOT_ERRORS),,$(gb_CFLAGS_WERROR)) \
$(if $(COMPILER_PLUGINS),$(gb_COMPILER_PLUGINS)) \
-   $(T_CFLAGS) \
+   $(T_CFLAGS) $(T_CFLAGS_APPEND) \
-c $(3) \
-o $(1) \
$(call gb_cxx_dep_generation_options,$(1),$(4)) \
@@ -83,7 +83,7 @@
 ICECC=no CCACHE_DISABLE=1 \
$(gb_CC) \
$(DEFS) \
-   $(T_CFLAGS) \
+   $(T_CFLAGS) $(T_CFLAGS_APPEND) \
-c $(2) \
-I$(dir $(2)) \
$(INCLUDE) \
@@ -105,7 +105,7 @@
$(if $(VISIBILITY),,$(gb_VISIBILITY_FLAGS)) \
$(if $(WARNINGS_NOT_ERRORS),,$(gb_CXXFLAGS_WERROR)) \
$(if $(COMPILER_PLUGINS),$(gb_COMPILER_PLUGINS)) \
-   $(T_CXXFLAGS) \
+   $(T_CXXFLAGS) $(T_CXXFLAGS_APPEND) \
-c $(3) \
-o $(1) \
$(call gb_cxx_dep_generation_options,$(1),$(4)) \
@@ -124,7 +124,7 @@
 ICECC=no CCACHE_DISABLE=1 \
$(gb_CXX) \
$(DEFS) \
-   $(T_CXXFLAGS) \
+   $(T_CXXFLAGS) $(T_CXXFLAGS_APPEND) \
-c $(2) \
-I$(dir $(2)) \
$(INCLUDE) \
@@ -142,7 +142,7 @@
$(DEFS) \
$(if $(VISIBILITY),,$(gb_VISIBILITY_FLAGS)) \
$(if $(WARNINGS_NOT_ERRORS),,$(gb_CXXFLAGS_WERROR)) \
-   $(T_OBJCXXFLAGS) \
+   $(T_OBJCXXFLAGS) $(T_OBJCXXFLAGS_APPEND) \
-c $(3) \
-o $(1) \
-MMD -MT $(1) \
@@ -161,7 +161,7 @@
$(DEFS) \
$(if $(VISIBILITY),,$(gb_VISIBILITY_FLAGS)) \
$(if $(WARNINGS_NOT_ERRORS),,$(gb_CFLAGS_WERROR)) \
-   $(T_OBJCFLAGS) \
+   $(T_OBJCFLAGS) $(T_OBJCFLAGS_APPEND) \
-c $(3) \
-o $(1) \
-MMD -MT $(1) \
diff --git a/solenv/gbuild/platform/com_MSC_class.mk 
b/solenv/gbuild/platform/com_MSC_class.mk
index 3af4af8..5ef198c 100644
--- a/solenv/gbuild/platform/com_MSC_class.mk
+++ b/solenv/gbuild/platform/com_MSC_class.mk
@@ -52,7 +52,7 @@
$(if $(filter YES,$(COBJECT_X64)), $(CXX_X64_BINARY), $(gb_CC)) \
$(DEFS) \
   

Re: Developer Input for Bugs

[Kohei Yoshida]

On 01/10/2013 02:18 PM, Joel Madero wrote:


59209   New option 'Ignore system input language' has no help.


I just confirmed this.

--
Kohei Yoshida, LibreOffice hacker, Calc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Developer Input for Bugs

[Joel Madero]

Hi All,

In order for QA team to meet our goal of having all bugs against 4.0 
triaged by next week we're going to need some devs to get involved for 
the more technical ones or ones that we just need other input. I'm going 
to keep this thread updated with a list, here is a very short list to 
begin with - a lot of these shouldn't take more than a few minutes to 
answer/triage.


Thanks in advance


Bug #   Summary
59209   New option 'Ignore system input language' has no help.
57417   LDAP address book support disappeared
59158   site link is wrong
58563   Missing module after install
57453   Java "I shall say this only once" error message
58865   Hardcoded product name in UI string





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: [libreoffice-dev] - questions about calc extension

[Rai, Neeraj]

Hi Kohei,

Using unlockController/lock brought down the time from 12sec to 3sec. Using 
DataArray brought it down to 14ms!
 Thanks for the tips. Great thing about starting with bad code is that I get to 
feel happy when it improves :-)

Hi Michael,

Who would have thought it was a script :-) Maybe 0 bytes callgrind should have 
given me a hint.
I am running callgrind now. Although, I don't need to based on above numbers, I 
am sure I'll write the next code as badly and will need it soon.
I never said in the email that I was running the wrapper but you figured it out 
anyway.
Thanks for catching it.

You guys are great.
Neeraj

-Original Message-
From: Michael Meeks [mailto:michael.me...@suse.com]
Sent: Thursday, January 10, 2013 11:34 AM
To: Rai, Neeraj [ICG-MKTS]
Cc: 'libreoffice@lists.freedesktop.org'; Kohei Yoshida
Subject: Re: [libreoffice-dev] - questions about calc extension


> > What's your hunch about how long it should take to update 60K cells with 
> > {getCellByPosition(ii,jj) and setValue() } ?

It should be ~instant - sub-second anyhow; it's an analog of loading
values from ODS. Kohei's suggestions are great:

> On Thu, 2013-01-10 at 10:59 -0500, Kohei Yoshida wrote:
> 2) Try lockControllers() and unlockControllers() to disable/enable
> repainting while updating cell values.  The example of these methods
> should be in my xcalc.cxx file I referenced earlier.

You'd need to run callgrind like this:

export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin

ie. on the soffice.bin not the wrapper script ;-)

HTH,

Michael.

--
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failure to build 3.6 branch

[Lubos Lunak]

On Thursday 10 of January 2013, Alexander Thurgood wrote:
> Le 10/01/13 12:24, Caolán McNamara a écrit :
> > I wonder if that file has grown too big for your toolchain. Try
> > splitting up the file into two and see if you can get it to compile that
> > way.
>
> Unfortunately, you have lost me there. I wouldn't know how to do that.
> I'm only trying to build at all to do get a debug build for QA.
> Development coding will be a very long way off yet.

 I'd rather guess simply a bug in the compiler (since it's on Mac, it's the 
old gcc-4.0.1, right?). Try if the file compiles successfully with 'make 
DEBUG=1', that will disable optimizations.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need confirmation about non-clearing of Character Styles

[Fernand Vanrie]

Caolán ,

thanks for the background and your atention to this problem

OK but ...its still very confusing for most users

they can clear all "direct formating" in the right place, the formating 
menu


they can clear "Paragraph formating" produced by a style using the 
Formating Toolbar option

why can they not clear Character formating produced by a style ?

+ there is no logic behind the clearing options
when using the formating tools in the "Formating Toolbar" we can use
 "Clear Formating" who clears the Paragraph format  who is actualy 
setting the slected text  to the "default" paragraph style
we can also do exactly the same by applying the  " Default Style" to the 
selected text


so i suppose we need to change  the Formating Toolbar "Styles dropdown"
- the existing option named "Clear Formating" has to name "Clear 
Paragraph Style Formating"
- a extra option named "Clear Character Style formating"  (who infact 
also will clear the Hyperlinks)


Greetz

Fernand

On Thu, 2013-01-10 at 10:55 +0100, Fernand Vanrie wrote:

Sinds all or editors use LO 3.6.2 (before OO3.3)

We have complains about the fact that parts of the text, who are
formated with a Character Style, can not been "cleared" to
no-formating,
not by "Clear Direct Formating (cntrl+M)"

There is a dirty work-around by applying the "Default" character style

Paragraph Styles can been cleared
Is this intentional behavior or a regression open for a issue ?

My understanding is
a) that its intentional, see
http://lists.freedesktop.org/archives/ooo-build/2010-February/000540.html
and the commit
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e690e0909459d46c53d17e7939891abea11e566
b) that "paragraph styles" are not cleared, i.e. the text should remain
using the original paragraph and character styles, but any additional
properties applied on top of that is reset to the underlying paragraph
and character styles properties.

C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: replacing OUString::valueOf(static_cast) ??

[Lubos Lunak]

On Thursday 10 of January 2013, Noel Grandin wrote:
> You are correct, we are indeed talking past each other.
> If you go back to the very first message in this thread, the patch
> mentioned there will perhaps help to establish come context.
>
> But I will try to explain again.
>
> The constructors and existing methods don't help because the specific
> problem we are trying to solve is that the C++ overload resolution rules
> will sometimes pick a non-intuitive method or constructor to apply.
>
> This leads to code that looks like:
>
> aStyleName.Append( OUString::valueOf( static_cast( nDepth ) ) );
>
> which is the integer case. Similar problems apply to the char and bool
> cases.
>
> The purpose of these methods is purely to reduce this boilerplate coding
> and increase readability, so that we have:
>
> aStyleName.Append( OUString::valueOfInt( nDepth ) );
>
> Given that our string classes are used pretty much everywhere, having a
> wide API that increases readability can only be a good thing.
>
> While you might not like the names of the new methods, I don't see how
> making the names of the new methods dramatically different from the names
> of the existing "valueOf" methods can be an improvement to the API.
> Sometimes, we have to work with what we have.

 That is not what I meant. What I wrote in my previous mail is that if these 
valueOf() issues are to be fixed, it's better to fix it completely rather 
than just slightly reduce the problem. And for that it would be better to 
remove the original valueOf() completely, and that results in all the 
follow-up issues that I raised.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW-4-0] oxygen-gtk support version ...

[Michael Meeks]

Hi there,

On Wed, 2013-01-09 at 21:08 +0400, Ruslan Kabatsayev wrote:
> >>  gtk_init_check( &nParams, &pCmdLineAry );
> >> +g_setenv("LibreOffice_Version","4.0.0.0",true);
...
> >> Of course, "4.0.0.0" should be replaced by some variable, name of
> >> which I currently don't know. But how do you like this idea? It seems
> >> the easiest and most efficient compared to any g_object_set_data()
> >> way.

I cleaned up the version bits (as well as I could in a back-portable
way for 4.0 - really we should drive this all from one setting in
configure.in IMHO).

I'd like to get the result into -4-0 if someone could review/ pick
these two:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=364cce0a511d3e7a3bbc51e09895999fbdf0dbe1
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0260f0b256c3675bb6d836c0a2babb7626577b7a

And hopefully it'd be possible (any chance you could do that Tor?) to
file an easy-hack to kill remaining code-based 'SUPD' uses to use
LIBO_VERSION_ bits

Thanks !

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need confirmation about non-clearing of Character Styles

[Fernand Vanrie]

Michael plaese see also my reply to Caloán

On 10/01/13 14:25, Caolán McNamara wrote:

On Thu, 2013-01-10 at 10:55 +0100, Fernand Vanrie wrote:

Sinds all or editors use LO 3.6.2 (before OO3.3)

We have complains about the fact that parts of the text, who are
formated with a Character Style, can not been "cleared" to
no-formating,
not by "Clear Direct Formating (cntrl+M)"

There is a dirty work-around by applying the "Default" character style

Paragraph Styles can been cleared
Is this intentional behavior or a regression open for a issue ?

My understanding is
a) that its intentional, see
http://lists.freedesktop.org/archives/ooo-build/2010-February/000540.html
and the commit
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e690e0909459d46c53d17e7939891abea11e566

the corresponding issues are an "interesting" read:

https://issues.apache.org/ooo/show_bug.cgi?id=47893 <- patch author
arguing for the change
https://issues.apache.org/ooo/show_bug.cgi?id=85464 <- a certain Cor
reporting the change as regression :)

i definitely think that there should be some button to reset formatting
that leaves character styles intact, and that should be the "most easily
accessible" option.  but i wouldn't object to a second button to reset
all formatting, including styles.

resetting the character styles should be as easy as setting "Default"
char style on the whole document, so i'm not sure if another option is
worth the additional clutter.

if you know this work around yes


but hyperlinks should not be touched by any "reset formatting" since
they are not formatting, but content entities (the reset feature also
doesn't convert fields to plain text).
when you works in the printing business you "must" get rid  of this kind 
of formating


also i'm thinking that ruby text should also not be touched by "reset
formatting", and this has not yet been changed (i.e. it is reset
currently); the reset will actually throw away the ruby text.  i'm
already sitting on a patch to remove ruby from the reset list...

idem ditto


___
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

[Libreoffice-commits] .: 2 commits - config/config_version.h.in configure.ac vcl/inc vcl/source vcl/unx

[Libreoffice Gerrit user]

 config/config_version.h.in   |   14 ++
 configure.ac |   18 ++
 vcl/inc/svdata.hxx   |5 +
 vcl/source/app/svapp.cxx |4 
 vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx |4 
 vcl/unx/gtk/window/gtkframe.cxx  |6 +-
 6 files changed, 46 insertions(+), 5 deletions(-)

New commits:
commit 0260f0b256c3675bb6d836c0a2babb7626577b7a
Author: Michael Meeks 
Date:   Thu Jan 10 17:38:18 2013 +

export cleaned up dotted version in environment and GtkWindow user-data.

Change-Id: If865127a9a5560f4b3636fb870699e2f3bac0e83

diff --git a/vcl/inc/svdata.hxx b/vcl/inc/svdata.hxx
index ff87f29..515bcbc 100644
--- a/vcl/inc/svdata.hxx
+++ b/vcl/inc/svdata.hxx
@@ -45,6 +45,11 @@
 
 #include 
 
+#include 
+
+#define LIBO_VERSION_DOTTED  (LIBO_VERSION_MAJOR "." LIBO_VERSION_MINOR "." \
+  LIBO_VERSION_MICRO "." LIBO_VERSION_PATCH)
+
 struct ImplTimerData;
 struct ImplConfigData;
 class ImplDirectFontSubstitution;
diff --git a/vcl/source/app/svapp.cxx b/vcl/source/app/svapp.cxx
index 1a79987..c6c6c5a 100644
--- a/vcl/source/app/svapp.cxx
+++ b/vcl/source/app/svapp.cxx
@@ -205,6 +205,10 @@ Application* GetpApp()
 
 Application::Application()
 {
+// useful for themes at least, perhaps extensions too
+rtl::OUString aVar("LIBO_VERSION"), aValue(LIBO_VERSION_DOTTED);
+osl_setEnvironment(aVar.pData, aValue.pData);
+
 if( ! ImplGetSVData() )
 ImplInitSVData();
 ImplGetSVData()->mpApp = this;
diff --git a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx 
b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
index 46a4c01..736834a 100644
--- a/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
+++ b/vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx
@@ -17,6 +17,7 @@
  *   the License at http://www.apache.org/licenses/LICENSE-2.0 .
  */
 
+#include 
 
 #include "vcl/svapp.hxx"
 
@@ -4173,6 +4174,9 @@ static void NWAddWidgetToCacheWindow( GtkWidget* widget, 
SalX11Screen nScreen )
 if ( !rData.gCacheWindow )
 {
 rData.gCacheWindow = gtk_window_new( GTK_WINDOW_TOPLEVEL );
+g_object_set_data( G_OBJECT( rData.gCacheWindow ), "libo-version",
+   (gpointer)LIBO_VERSION_DOTTED );
+
 GdkScreen* pScreen = gdk_display_get_screen( 
gdk_display_get_default(),
  nScreen.getXScreen() 
);
 if( pScreen )
diff --git a/vcl/unx/gtk/window/gtkframe.cxx b/vcl/unx/gtk/window/gtkframe.cxx
index 6bba141..398ece4 100644
--- a/vcl/unx/gtk/window/gtkframe.cxx
+++ b/vcl/unx/gtk/window/gtkframe.cxx
@@ -1071,11 +1071,7 @@ void GtkSalFrame::Init( SalFrame* pParent, sal_uLong 
nStyle )
 m_pWindow = gtk_widget_new( GTK_TYPE_WINDOW, "type", eWinType,
 "visible", FALSE, NULL );
 g_object_set_data( G_OBJECT( m_pWindow ), "SalFrame", this );
-
-static char pVersion[16] = "";
-if( pVersion[0] == '\0' )
-g_sprintf( pVersion, "%d", SUPD );
-g_object_set_data( G_OBJECT( m_pWindow ), "libo-version", pVersion );
+g_object_set_data( G_OBJECT( m_pWindow ), "libo-version", 
(gpointer)LIBO_VERSION_DOTTED);
 
 // force wm class hint
 m_nExtStyle = ~0;
commit 364cce0a511d3e7a3bbc51e09895999fbdf0dbe1
Author: Michael Meeks 
Date:   Thu Jan 10 17:15:37 2013 +

add LIBO_VERSION_* macros and a config header for them to live in.

Change-Id: Ia6735e3e7f3231722231e9d7a4c9839f08038b96

diff --git a/config/config_version.h.in b/config/config_version.h.in
new file mode 100644
index 000..caaa9c4
--- /dev/null
+++ b/config/config_version.h.in
@@ -0,0 +1,14 @@
+/*
+Version settings
+  version 4.0.0.1 is Major.Minor.Micro.Patch
+*/
+
+#ifndef CONFIG_VERSION_H
+#define CONFIG_VERSION_H
+
+#undef LIBO_VERSION_MAJOR
+#undef LIBO_VERSION_MINOR
+#undef LIBO_VERSION_MICRO
+#undef LIBO_VERSION_PATCH
+
+#endif
diff --git a/configure.ac b/configure.ac
index 2ef61b1..3b4fb48 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4320,6 +4320,23 @@ AC_SUBST(UPD)
 AC_SUBST(SOURCEVERSION)
 
 dnl ===
+dnl Grim-ness to export version number of LibreOffice to code
+dnl this needs to be turned around and to be driven by configure
+dnl ===
+LIBO_VERSION_MAJOR="`$GREP VERSIONMAJOR solenv/inc/minor.mk | sed "s/^.*=//"`"
+LIBO_VERSION_MINOR="`$GREP VERSIONMINOR solenv/inc/minor.mk | sed "s/^.*=//"`"
+LIBO_VERSION_MICRO="`$GREP VERSIONMICRO solenv/inc/minor.mk | sed "s/^.*=//"`"
+LIBO_VERSION_PATCH="`$GREP BUILD solenv/inc/minor.mk | sed "s/^.*=//"`"
+AC_SUBST(LIBO_VERSION_MAJOR)
+AC_SUBST(LIBO_VERSION_MINOR)
+AC_SUBST(LIBO_VERSION_MICRO)
+AC_SUBST(LIBO_VERSION_PATCH)
+AC_DEFINE_UNQUOTED(LIBO_VERSION_MAJOR,"$LIBO_VERSION_MAJOR")
+AC_DEFINE_UNQUOTED(LIBO_VERSION_MINOR,"$LIBO_VERSION_MINOR")
+AC_

Re: replacing OUString::valueOf(static_cast) ??

[Noel Grandin]

On Thu, Jan 10, 2013 at 5:31 PM, Lubos Lunak  wrote:

> On Thursday 10 of January 2013, Noel Grandin wrote:
> > On 2013-01-10 15:55, Lubos Lunak wrote:
> > > - There's no need for valueOfChar(). There is already OUString ctor
> from
> > > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > > thing complicated. Code using it can be converted to use the ctor
> > > instead.
> >
> > Which doesn't help with overload resolution problems.
>
>  It does. If you say it's wrong to use valueOfWhatever() for char->string
> conversion, there either will not be problems, or it will be wrong. If you
> want to fix an existing problem by introducing a new function, how does
> that
> make anything better than using an already existing function that does the
> job?
>
>
You are correct, we are indeed talking past each other.
If you go back to the very first message in this thread, the patch
mentioned there will perhaps help to establish come context.

But I will try to explain again.

The constructors and existing methods don't help because the specific
problem we are trying to solve is that the C++ overload resolution rules
will sometimes pick a non-intuitive method or constructor to apply.

This leads to code that looks like:

aStyleName.Append( OUString::valueOf( static_cast( nDepth ) ) );

which is the integer case. Similar problems apply to the char and bool
cases.

The purpose of these methods is purely to reduce this boilerplate coding
and increase readability, so that we have:

aStyleName.Append( OUString::valueOfInt( nDepth ) );

Given that our string classes are used pretty much everywhere, having a
wide API that increases readability can only be a good thing.

While you might not like the names of the new methods, I don't see how
making the names of the new methods dramatically different from the names
of the existing "valueOf" methods can be an improvement to the API.
Sometimes, we have to work with what we have.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failure to build 3.6 branch

[Alexander Thurgood]

Le 10/01/13 12:24, Caolán McNamara a écrit :

> I wonder if that file has grown too big for your toolchain. Try
> splitting up the file into two and see if you can get it to compile that
> way.
> 

Unfortunately, you have lost me there. I wouldn't know how to do that.
I'm only trying to build at all to do get a debug build for QA.
Development coding will be a very long way off yet.

Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: fdo#58531: Register cells with external references at compil...

[Kohei Yoshida (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1631

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/31/1631/1

fdo#58531: Register cells with external references at compile time.

In the old code, we would do this during interpretation.  But we need
to move that to the compilation to make this work properly without
full recalculation during ods import.

For 4.0, we'll just add calls to insertRefCells in ScCompiler.  On
master we should remove these calls from the old places to avoid
duplicate calls.  Duplicate calls for the same external file ID - cell
address pair will not hurt; it just adds more overhead.

Change-Id: I25cf2e08195da17c6c8f7d19c74d744df6e1638e
---
M sc/inc/compiler.hxx
M sc/inc/externalrefmgr.hxx
M sc/source/core/tool/compiler.cxx
3 files changed, 34 insertions(+), 2 deletions(-)



diff --git a/sc/inc/compiler.hxx b/sc/inc/compiler.hxx
index d40d261..10af901 100644
--- a/sc/inc/compiler.hxx
+++ b/sc/inc/compiler.hxx
@@ -331,6 +331,7 @@
 ExtendedErrorDetection  meExtendedErrorDetection;
 boolmbCloseBrackets;// whether to close open brackets 
automatically, default TRUE
 boolmbRewind;   // whether symbol is to be rewound 
to some step during lexical analysis
+std::vector maExternalFiles;
 
 bool   NextNewToken(bool bInArray = false);
 
diff --git a/sc/inc/externalrefmgr.hxx b/sc/inc/externalrefmgr.hxx
index 3fd3ab5..87693a3 100644
--- a/sc/inc/externalrefmgr.hxx
+++ b/sc/inc/externalrefmgr.hxx
@@ -679,13 +679,13 @@
  */
 bool containsUnsavedReferences() { return !maUnsavedDocShells.empty(); }
 
+void insertRefCell(sal_uInt16 nFileId, const ScAddress& rCell);
+
 private:
 ScExternalRefManager();
 ScExternalRefManager(const ScExternalRefManager&);
 
 void refreshAllRefCells(sal_uInt16 nFileId);
-
-void insertRefCell(sal_uInt16 nFileId, const ScAddress& rCell);
 
 void fillCellFormat(sal_uLong nFmtIndex, ScExternalRefCache::CellFormat* 
pFmt) const;
 
diff --git a/sc/source/core/tool/compiler.cxx b/sc/source/core/tool/compiler.cxx
index b827019..b6183ba 100644
--- a/sc/source/core/tool/compiler.cxx
+++ b/sc/source/core/tool/compiler.cxx
@@ -2717,6 +2717,7 @@
 const OUString* pRealTab = 
pRefMgr->getRealTableName(aExtInfo.mnFileId, aExtInfo.maTabName);
 aToken.SetExternalDoubleRef(
 aExtInfo.mnFileId, pRealTab ? *pRealTab : aExtInfo.maTabName, 
aRef);
+maExternalFiles.push_back(aExtInfo.mnFileId);
 }
 else
 {
@@ -2765,6 +2766,7 @@
 const OUString* pRealTab = 
pRefMgr->getRealTableName(aExtInfo.mnFileId, aExtInfo.maTabName);
 aToken.SetExternalSingleRef(
 aExtInfo.mnFileId, pRealTab ? *pRealTab : aExtInfo.maTabName, 
aRef);
+maExternalFiles.push_back(aExtInfo.mnFileId);
 }
 else
 aToken.SetSingleReference(aRef);
@@ -2973,6 +2975,7 @@
 const OUString* pRealName = pRefMgr->getRealRangeName(nFileId, aName);
 aToken.SetExternalName(nFileId, pRealName ? *pRealName : OUString(aTmp));
 pRawToken = aToken.Clone();
+maExternalFiles.push_back(nFileId);
 return true;
 }
 
@@ -3737,6 +3740,24 @@
 rFormulaNmsp = aFormulaNmsp;
 }
 
+namespace {
+
+class ExternalFileInserter : std::unary_function
+{
+ScAddress maPos;
+ScExternalRefManager& mrRefMgr;
+public:
+ExternalFileInserter(const ScAddress& rPos, ScExternalRefManager& rRefMgr) 
:
+maPos(rPos), mrRefMgr(rRefMgr) {}
+
+void operator() (sal_uInt16 nFileId) const
+{
+mrRefMgr.insertRefCell(nFileId, maPos);
+}
+};
+
+}
+
 ScTokenArray* ScCompiler::CompileString( const String& rFormula )
 {
 OSL_ENSURE( meGrammar != FormulaGrammar::GRAM_EXTERNAL, 
"ScCompiler::CompileString - unexpected grammar GRAM_EXTERNAL" );
@@ -3943,6 +3964,16 @@
 // remember pArr, in case a subsequent CompileTokenArray() is executed.
 ScTokenArray* pNew = new ScTokenArray( aArr );
 pArr = pNew;
+
+if (!maExternalFiles.empty())
+{
+// Remove duplicates, and register all external files found in this 
cell.
+std::sort(maExternalFiles.begin(), maExternalFiles.end());
+std::vector::iterator itEnd = 
std::unique(maExternalFiles.begin(), maExternalFiles.end());
+std::for_each(maExternalFiles.begin(), itEnd, 
ExternalFileInserter(aPos, *pDoc->GetExternalRefManager()));
+maExternalFiles.erase(itEnd, maExternalFiles.end());
+}
+
 return pNew;
 }
 

-- 
To view, visit https://gerrit.libreoffice.org/1631
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I25cf2e08195da17c6c8f7d19c74d744df6e1638e
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.fr

[Libreoffice-commits] .: sc/inc sc/source

[Libreoffice Gerrit user]

 sc/inc/compiler.hxx  |1 +
 sc/inc/externalrefmgr.hxx|4 ++--
 sc/source/core/tool/compiler.cxx |   31 +++
 3 files changed, 34 insertions(+), 2 deletions(-)

New commits:
commit 3d78fe6b23eb3d6552bf5ed65f3a8ead081533d1
Author: Kohei Yoshida 
Date:   Thu Jan 10 12:02:07 2013 -0500

fdo#58531: Register cells with external references at compile time.

In the old code, we would do this during interpretation.  But we need
to move that to the compilation to make this work properly without
full recalculation during ods import.

For 4.0, we'll just add calls to insertRefCells in ScCompiler.  On
master we should remove these calls from the old places to avoid
duplicate calls.  Duplicate calls for the same external file ID - cell
address pair will not hurt; it just adds more overhead.

Change-Id: I25cf2e08195da17c6c8f7d19c74d744df6e1638e

diff --git a/sc/inc/compiler.hxx b/sc/inc/compiler.hxx
index d40d261..10af901 100644
--- a/sc/inc/compiler.hxx
+++ b/sc/inc/compiler.hxx
@@ -331,6 +331,7 @@ private:
 ExtendedErrorDetection  meExtendedErrorDetection;
 boolmbCloseBrackets;// whether to close open brackets 
automatically, default TRUE
 boolmbRewind;   // whether symbol is to be rewound 
to some step during lexical analysis
+std::vector maExternalFiles;
 
 bool   NextNewToken(bool bInArray = false);
 
diff --git a/sc/inc/externalrefmgr.hxx b/sc/inc/externalrefmgr.hxx
index 3fd3ab5..87693a3 100644
--- a/sc/inc/externalrefmgr.hxx
+++ b/sc/inc/externalrefmgr.hxx
@@ -679,14 +679,14 @@ public:
  */
 bool containsUnsavedReferences() { return !maUnsavedDocShells.empty(); }
 
+void insertRefCell(sal_uInt16 nFileId, const ScAddress& rCell);
+
 private:
 ScExternalRefManager();
 ScExternalRefManager(const ScExternalRefManager&);
 
 void refreshAllRefCells(sal_uInt16 nFileId);
 
-void insertRefCell(sal_uInt16 nFileId, const ScAddress& rCell);
-
 void fillCellFormat(sal_uLong nFmtIndex, ScExternalRefCache::CellFormat* 
pFmt) const;
 
 ScExternalRefCache::TokenRef getSingleRefTokenFromSrcDoc(
diff --git a/sc/source/core/tool/compiler.cxx b/sc/source/core/tool/compiler.cxx
index 6de0417..7b7ab88 100644
--- a/sc/source/core/tool/compiler.cxx
+++ b/sc/source/core/tool/compiler.cxx
@@ -2717,6 +2717,7 @@ bool ScCompiler::IsDoubleReference( const String& rName )
 const OUString* pRealTab = 
pRefMgr->getRealTableName(aExtInfo.mnFileId, aExtInfo.maTabName);
 aToken.SetExternalDoubleRef(
 aExtInfo.mnFileId, pRealTab ? *pRealTab : aExtInfo.maTabName, 
aRef);
+maExternalFiles.push_back(aExtInfo.mnFileId);
 }
 else
 {
@@ -2765,6 +2766,7 @@ bool ScCompiler::IsSingleReference( const String& rName )
 const OUString* pRealTab = 
pRefMgr->getRealTableName(aExtInfo.mnFileId, aExtInfo.maTabName);
 aToken.SetExternalSingleRef(
 aExtInfo.mnFileId, pRealTab ? *pRealTab : aExtInfo.maTabName, 
aRef);
+maExternalFiles.push_back(aExtInfo.mnFileId);
 }
 else
 aToken.SetSingleReference(aRef);
@@ -2973,6 +2975,7 @@ bool ScCompiler::IsExternalNamedRange( const String& 
rSymbol )
 const OUString* pRealName = pRefMgr->getRealRangeName(nFileId, aName);
 aToken.SetExternalName(nFileId, pRealName ? *pRealName : OUString(aTmp));
 pRawToken = aToken.Clone();
+maExternalFiles.push_back(nFileId);
 return true;
 }
 
@@ -3736,6 +3739,24 @@ void ScCompiler::CreateStringFromXMLTokenArray( 
rtl::OUString& rFormula, rtl::OU
 rFormulaNmsp = aFormulaNmsp;
 }
 
+namespace {
+
+class ExternalFileInserter : std::unary_function
+{
+ScAddress maPos;
+ScExternalRefManager& mrRefMgr;
+public:
+ExternalFileInserter(const ScAddress& rPos, ScExternalRefManager& rRefMgr) 
:
+maPos(rPos), mrRefMgr(rRefMgr) {}
+
+void operator() (sal_uInt16 nFileId) const
+{
+mrRefMgr.insertRefCell(nFileId, maPos);
+}
+};
+
+}
+
 ScTokenArray* ScCompiler::CompileString( const String& rFormula )
 {
 OSL_ENSURE( meGrammar != FormulaGrammar::GRAM_EXTERNAL, 
"ScCompiler::CompileString - unexpected grammar GRAM_EXTERNAL" );
@@ -3942,6 +3963,16 @@ ScTokenArray* ScCompiler::CompileString( const String& 
rFormula )
 // remember pArr, in case a subsequent CompileTokenArray() is executed.
 ScTokenArray* pNew = new ScTokenArray( aArr );
 pArr = pNew;
+
+if (!maExternalFiles.empty())
+{
+// Remove duplicates, and register all external files found in this 
cell.
+std::sort(maExternalFiles.begin(), maExternalFiles.end());
+std::vector::iterator itEnd = 
std::unique(maExternalFiles.begin(), maExternalFiles.end());
+std::for_each(maExternalFiles.begin(), itEnd, 
ExternalFileInserter(aPos, *pDoc->GetExternalRefManager()));
+maExternalFiles.eras

[REVIEW 4.0] BitmapEx* -> BitmapEx [was: Re: LATE FEATURE: Personas in LibreOffice]

[Jan Holesovsky]

Hi Michael,

Michael Meeks píše v Út 08. 01. 2013 v 14:21 +:

>   But +1 from me for the -4-0 branch - assuming we can get another couple
> of reviews. As a quibble, I'd prefer to see BitmapEx's instead of
> BitmapEx*'s being used in the settings - which would simplify the code
> and make it less error prone I suspect; BitmapEx::IsEmpty is your
> friend :-)

Ah right, can you please cherry-pick

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0721b5b83e34de1e2fcb320d6a7deae1ad109d61

to libreoffice-4-0? :-)

[I just noticed I've used mpSomething there instead of maSomething for
BitmapEx'es, but I'll fix it together with another commit when fixing
the other glitches the others pointed out.]

Thank you,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need confirmation about non-clearing of Character Styles

[Caolán McNamara]

On Thu, 2013-01-10 at 15:10 +0100, Michael Stahl wrote:
> There should be some button to reset formatting that leaves character
> styles intact, and that should be the "most easily accessible" option.

> ... hyperlinks should not be touched by any "reset formatting" ...

And that's what we've got with "clear direct formatting" at the moment,
right ?

> also i'm thinking that ruby text should also not be touched by "reset
> formatting", and this has not yet been changed (i.e. it is reset
> currently); the reset will actually throw away the ruby text.  i'm
> already sitting on a patch to remove ruby from the reset list...

Yeah, that makes sense to me too. You should push that.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-dev] - questions about calc extension

[Michael Stahl]

On 10/01/13 16:42, Rai, Neeraj wrote:
> Hi Stephan,
> 
> I am unable to find XDesktop2. Your sample below looks really simple
> and right way to go. I am working with release version 3.6.4.3 -
> built it from tar files.

XDesktop2 was only added a month ago, so it's only in 4.0.

of course when using the newest features it's always a problem that it
doesn't allow deploying your extension or whatever on older versions then...

> I don't mind upgrading to latest tip, but I had trouble building the
> git checkout version. Being fairly new to this large and
> comprehensive product, I decided to take the easy way to begin.

you can also download 4.0 beta releases, actually there should be a RC1
now even; i would expect those also have the SDK available.

> I would also be curious to know how to find out about such api -
> unfortunately, right now I am reading only specific emails on dev
> group and unable to follow conversations on other topics. Is reading
> docs the best way ? Is it possible to find some sample code ?

good question... currently the only real info for developers who don't
follow the git commits, which is probably no extension or macro
developer does, is the 4.0 release notes, which has a section on API
Changes:

https://wiki.documentfoundation.org/ReleaseNotes/4.0#API_Changes

but that doesn't talk much about what is added, mostly it's about what
is changed or removed.

of course you can also search in the API reference (or the IDL files)
for "since" tags with a particular version.

the OOo project had a "interface-announce" mailing list, which was used
both for API changes and additions, and for internal implementation
interface changes; i wonder how many extension developers actually read
that list in its time.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

minutes of ESC call ...

[Michael Meeks]

* Present:
+ Fridrich, Stephan, Andras, Joel, Caolan, Markus, Norbert,
  Bjoern, Thorsten, Ahmad, Astron, Michael M, Eike, Michael S,
  Petr, Cedric.

* Completed Action Items
+ need to rename the MIGRATED flag and unwind / test re-migration 
(Michael)
+ apparently no need to do this - the new directory name
  takes care of it.
+ FOSDEM: how to debug spreadsheet file-format issues (Markus)
+ FOSDEM: how to debug writer file-format issues (Miklos)
+ FOSDEM: add: language-tags how they clean up our l10n story (Eike)
+ FOSDEM: types.rdb removal / re-writing (Stephan)
+ FOSDEM: hacking on the new android / impress-remote (Thorsten)
+ FOSDEM: hacking on CMIS / the new template dialog (Cedric)
+ Testing Marathon: get update with stats for wordpress to Michael 
(Joel)
+ 
http://joelmadero.wordpress.com/2012/12/27/libreoffice-test-marathon-results/
+ disable gnome-vfs for now on linux builds for RC1 (Fridrich)
+ remove overly lame .gitignore entries (Norbert)
+ hide TCP/IP mode in android app itself: bluetooth only by default 
(Miklos)
+ update existing 'find-bar' close button / bug to an easy-hack 58526 
(Michael)
+ obsolete - Joren on it.

* Last-time Action Items
+ Windows: .Net vs. our install still chasing (Tor / Fridrich)
+ FOSDEM: Easy QA introduction: bug triage etc. (Cor?)
+ FOSDEM: misc. new interop. feature and their development (Tibby)
+ on-line help for impress-remote would be useful, help appreciated (?)
+ full-word selection / editing ergonomics cf. UX-advise
+ https://bugs.freedesktop.org/show_bug.cgi?id=46517
+ pending input from Caolan / Cedric / Michael S
+ investigate re-using Win32 binary signing for Mac (Thorsten)

* Pending Action Items
+ [pending] add impress remote shots to features wiki page (Thorsten)
+ create a new AmbitiousHacks wiki page, based on GSOC page (Michael M)
+ minimal triage for good mentors for proposed easy hacks (Bjoern)
+ disable Rhino / Beanshell unless in experimental mode (Michael)
+ tweak the configure defaults (Kendy)
+ no submodules by default, no gnome-vfs
+ mail details on signing etc. to Caolan (Fridrich)
+ needs a GPG public key from Caolan, punted to Jan.

* Release Engineering update (Petr)
+ 4.0 timeline:
+ on-schedule, RC1 builds are available, up-loading
+ All fixes now need 1x review - don't push your own work
+ RC2 January 25th - 2 weeks out
+ final RC3 - one week later
+ hard UI / string freeze
+ l10n approval required for string changes.
+ no string changes in final RC3
+ 3.6.5 rc1 - deadline is Monday
+ if critical regression wait until after 4.0rc3 for it
+ L10n status (Andras)
+ pootle upgrade 2x weeks ago and 4.0 brought lots of changes
+ lots of ongoing work, status looks good
+ completing generic / Linux builds -> RedHat (Caolan)
+ fdo#58165 - drop stdlibs foo

* UX input (Astron)
+ template manager / progress
+ progressing nicely - thanks to Cedric
+ Personas
+ discussion on ux-advise
+ thanks for feedback ! (Kendy)
+ Initial color picker design [done]
+ would appreciate hackers / hands [!]
+ great design at:
  
https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker
+ Splash screens
+ new whiteboard for 4.0 branding suggestions
  
https://wiki.documentfoundation.org/Design/Whiteboards/4.0_Branding
+ so far may well stick with existing branding
+ T-shirts (Kendy)
+ whiteboard / feedback / CC the design list for FOSDEM
+ Save icon - are we going to switch back for 4.0 to the floppy ?
+ http://user-prompt.com/about-antiquated-metaphors-in-icons/
AI: + decision on whether to switch back tol old floppy save 
(Astron)
+ blog post pasting websites & loosing images ? (Bjoern)
AI: + agreement that default to not link should be fixed (Bjoern)

* Certification Committee update (Kendy/Stephan/Bjoern)
+ nice write-up, great progress

* FOSDEM update (Markus)
+ https://wiki.documentfoundation.org/Marketing/Events/Fosdem2013
+ preliminary timetable being tweaked
+ to be published later and Italo will enter to Penta
+ 20mins slots for 15min talks, and 40mins for 30min talks

* Features - please update:
+ http://wiki.documentfoundation.org/ReleaseNotes/4.0
+ other missing ?
   

License Statement for Contributions

[Lester Kakol]

Hello,

All of my past & future contributions to LibreOffice may be licensed under the 
MPL/LGPLv3+ dual license.

Cheers,
-Lester Kakol
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: basegfx/inc

[Libreoffice Gerrit user]

 basegfx/inc/basegfx/polygon/b2dpolypolygoncutter.hxx |  104 ---
 1 file changed, 68 insertions(+), 36 deletions(-)

New commits:
commit 9a11737360528249437bccbb374201453f5cddfe
Author: Thorsten Behrens 
Date:   Thu Jan 10 17:50:02 2013 +0100

Doxygenify helpful basegfx comments.

Change-Id: I60a49e643c336c8834862735f93f1b41d6dad348

diff --git a/basegfx/inc/basegfx/polygon/b2dpolypolygoncutter.hxx 
b/basegfx/inc/basegfx/polygon/b2dpolypolygoncutter.hxx
index dcd4841..31bd8b6 100644
--- a/basegfx/inc/basegfx/polygon/b2dpolypolygoncutter.hxx
+++ b/basegfx/inc/basegfx/polygon/b2dpolypolygoncutter.hxx
@@ -29,44 +29,76 @@ namespace basegfx
 {
 namespace tools
 {
-// Solve all crossovers in a polyPolygon. This re-layouts all 
contained polygons so that the
-// result will contain only non-cutting polygons. For that reason, 
points will be added at
-// crossover and touch points and the single Polygons may be 
re-combined. The orientations
-// of the contained polygons in not changed but used as topological 
information.
-// Self crossovers of the contained sub-polygons are implicitely 
handled, but to not lose
-// the topological information, it may be necessary to remove 
self-intersections of the
-// contained sub-polygons in a preparing step and to explicitly 
correct their orientations.
+/** Solve all crossovers (aka self-intersections) in a polyPolygon.
+
+This re-layouts all contained polygons so that the result
+will contain only non-cutting polygons. For that reason,
+points will be added at crossover and touch points and the
+single Polygons may be re-combined. The orientations of
+the contained polygons in not changed but used as
+topological information.  Self crossovers of the contained
+sub-polygons are implicitely handled, but to not lose the
+topological information, it may be necessary to remove
+self-intersections of the contained sub-polygons in a
+preparing step and to explicitly correct their
+orientations.
+*/
 BASEGFX_DLLPUBLIC B2DPolyPolygon solveCrossovers(const B2DPolyPolygon& 
rCandidate);
 
-// Version for single polygons. This is for solving 
self-intersections. Result will be free of
-// crossovers. When result contains multiple polygons, it may be 
necessary to rearrange their
-// orientations since holes may have been created (use 
correctOrientations eventually).
+/** Solve all crossovers (aka self-intersections) in a Polygon
+
+Same as above, but for single polygons. Result will be
+free of self-intersections. When result contains multiple
+polygons, it may be necessary to rearrange their
+orientations since holes may have been created (use
+correctOrientations eventually).
+*/
 BASEGFX_DLLPUBLIC B2DPolyPolygon solveCrossovers(const B2DPolygon& 
rCandidate);
 
-// Neutral polygons will be stripped. Neutral polygons are ones who's 
orientation is
-// neutral, so normally they have no volume -> just closed paths. A 
polygon with the same
-// positive and negative oriented volume is also neutral, so this may 
not be wanted. It is
-// safe to call with crossover-free polygons, though (that's where 
it's mostly used).
+/** Strip neutral polygons from PolyPolygon.
+
+Neutral polygons are ones who's orientation is neutral, so
+normally they have no volume -> just closed paths. A
+polygon with the same positive and negative oriented
+volume is also neutral, so this may not be wanted. It is
+safe to call with self-intersection-free polygons, though
+(that's where it's mostly used).
+*/
 BASEGFX_DLLPUBLIC B2DPolyPolygon stripNeutralPolygons(const 
B2DPolyPolygon& rCandidate);
 
-// Remove not necessary polygons. Works only correct with 
crossover-free polygons. For each
-// polygon, the depth for the PolyPolygon is calculated. The 
orientation is used to identify holes.
-// Start value for holes is -1, for polygons it's zero. Ech time a 
polygon is contained in another one,
-// it's depth is increased when inside a polygon, decreased when 
inside a hole. The result is a depth
-// which e.g. is -1 for holes outside everything, 1 for a polygon 
covered by another polygon and zero
-// for e.g. holes in a polygon or polygons outside everythig else.
-// In the 2nd step, all polygons with depth other than zero are 
removed. If bKeepAboveZero is used,
-// all polygons < 1 are removed. The bKeepAboveZero mode is useful for 
clipping, e.g. just append
-// one polygon to another and use this mode -> only parts where two 
polygons overlapped will be kept

Re: Doing massive source changes

[Lubos Lunak]

On Saturday 05 of January 2013, Michael Meeks wrote:
> On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote:
>   Having said that - it is something we really want to do; can we drop
> the published easy hack bug in this regard (or just close it) to avoid
> the drip of patches there ?

 I'm not aware of any easy hack specifically for this, people simply do it as 
a part of string cleanups.

 And note that this is not the only case where it's possible to do the change 
as one big patch. I think it might be possible to e.g. get rid of all 
CONSTASCII macros in one go as well, or convert OSL_DEBUG, and so on. Unless 
we want to stay with those things forever (which I hope we don't), they will 
be eventually cleaned up one way or another.

>   I suggest we do it at a similar time to Norbert's onegit - ie. around
> the 4.0.2 release or so - when the cross-branch cherry-picking starts to
> reduce in frequency.

 Ok, it can wait for a while.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-dev] - questions about calc extension

[Michael Meeks]

> > What's your hunch about how long it should take to update 60K cells with 
> > {getCellByPosition(ii,jj) and setValue() } ?

It should be ~instant - sub-second anyhow; it's an analog of loading
values from ODS. Kohei's suggestions are great:

> On Thu, 2013-01-10 at 10:59 -0500, Kohei Yoshida wrote:
> 2) Try lockControllers() and unlockControllers() to disable/enable 
> repainting while updating cell values.  The example of these methods 
> should be in my xcalc.cxx file I referenced earlier.

You'd need to run callgrind like this:

export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin

ie. on the soffice.bin not the wrapper script ;-)

HTH,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: src/docrecord.py src/docstream.py

[Miklos Vajna]

 src/docrecord.py |   39 +++
 src/docstream.py |5 -
 2 files changed, 43 insertions(+), 1 deletion(-)

New commits:
commit 867beebfcbb643f924e54f95e7238e975f334db5
Author: Miklos Vajna 
Date:   Thu Jan 10 17:25:10 2013 +0100

dump PlfLst

diff --git a/src/docrecord.py b/src/docrecord.py
index d5742f7..1dbff49 100644
--- a/src/docrecord.py
+++ b/src/docrecord.py
@@ -2385,4 +2385,43 @@ class PlcfGram(DOCDirStream, PLC):
 print ''
 print ''
 
+class LSTF(DOCDirStream):
+"""The LSTF structure contains formatting properties that apply to an 
entire list."""
+def __init__(self, plfLst):
+DOCDirStream.__init__(self, plfLst.bytes)
+self.pos = plfLst.pos
+self.size = 28
+
+def dump(self):
+print '' % (self.pos, 
self.size)
+self.printAndSet("lsid", self.readInt32())
+self.printAndSet("tplc", self.readInt32())
+for i in range(9):
+print '' % self.readInt16()
+buf = self.readuInt8()
+self.printAndSet("fSimpleList", self.getBit(buf, 0))
+self.printAndSet("unused1", self.getBit(buf, 1))
+self.printAndSet("fAutoNum", self.getBit(buf, 2))
+self.printAndSet("unused2", self.getBit(buf, 3))
+self.printAndSet("fHybrid", self.getBit(buf, 4))
+self.printAndSet("reserved1", (buf & 0xe0) >> 5) # 6..8th bits
+self.printAndSet("grfhic", self.readuInt8()) # TODO dump grfhic
+print ''
+
+class PlfLst(DOCDirStream):
+"""The PlfLst structure contains the list formatting information for the 
document."""
+def __init__(self, mainStream):
+DOCDirStream.__init__(self, 
mainStream.doc.getDirectoryStreamByName("1Table").bytes, mainStream = 
mainStream)
+self.pos = mainStream.fcPlfLst
+self.size = mainStream.lcbPlfLst
+
+def dump(self):
+print '' % 
(self.pos, self.size)
+self.printAndSet("cLst", self.readInt16())
+for i in range(self.cLst):
+rgLstf = LSTF(self)
+rgLstf.dump()
+self.pos = rgLstf.pos
+print ''
+
 # vim:set filetype=python shiftwidth=4 softtabstop=4 expandtab:
diff --git a/src/docstream.py b/src/docstream.py
index c5c9fcc..ad46e1a 100644
--- a/src/docstream.py
+++ b/src/docstream.py
@@ -350,7 +350,7 @@ class WordDocumentStream(DOCDirStream):
 ["fcSttbFnm"],
 ["lcbSttbFnm"],
 ["fcPlfLst"],
-["lcbPlfLst"],
+["lcbPlfLst", self.handleLcbPlfLst],
 ["fcPlfLfo"],
 ["lcbPlfLfo"],
 ["fcPlcfTxbxBkd"],
@@ -518,6 +518,9 @@ class WordDocumentStream(DOCDirStream):
 def handleLcbPlcfGram(self):
 docrecord.PlcfGram(self).dump()
 
+def handleLcbPlfLst(self):
+docrecord.PlfLst(self).dump()
+
 def dumpFibRgFcLcb97(self, name):
 print '<%s type="FibRgFcLcb97" size="744 bytes">' % name
 self.__dumpFibRgFcLcb97()
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Bug 54157] LibreOffice 3.7/4.0 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=54157

Bug 54157 depends on bug 58275, which changed state.

Bug 58275 Summary: Install fails if .NET Framework 4.0 (Client) is not present
https://bugs.freedesktop.org/show_bug.cgi?id=58275

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [libreoffice-dev] - questions about calc extension

[Kohei Yoshida]

On 01/10/2013 10:50 AM, Rai, Neeraj wrote:

Hi Michael,

Appreciate your feedback.
I ran callgrind but no output on screen and 0 bytes files generated. I can run 
it on non-LO exe.
I'll compile LO with --enable-debug and see if situation improves. Please 
advise if other steps might be needed.

What's your hunch about how long it should take to update 60K cells with 
{getCellByPosition(ii,jj) and setValue() } ?


Two things you might try.

1) Try getDataArray() and setDataArray() to update multiple contiguous 
cells.  Doing it this way is much much faster than updating one cell at 
a time.  These methods are available for cell range object.


2) Try lockControllers() and unlockControllers() to disable/enable 
repainting while updating cell values.  The example of these methods 
should be in my xcalc.cxx file I referenced earlier.


HTH,

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: Resolves: fdo#58301 make sure ScrollBar OptimalSize is up to...

[via Code Review]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1630

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/30/1630/1

Resolves: fdo#58301 make sure ScrollBar OptimalSize is up to date

if the scrollbar sizes haven't been calculated yet then the optimalsize will be
wrong, so it's necessary to enforce calculating them in that case.

(cherry picked from commit f41a2804dd4a23352b7af2dd28c03df02debfb13)

Change-Id: I12e95c3594ffbb508c7f79bd512e07aaf44a6eab
---
M vcl/inc/vcl/scrbar.hxx
M vcl/source/control/scrbar.cxx
2 files changed, 11 insertions(+), 3 deletions(-)



diff --git a/vcl/inc/vcl/scrbar.hxx b/vcl/inc/vcl/scrbar.hxx
index 8dbe270..7c62d94 100644
--- a/vcl/inc/vcl/scrbar.hxx
+++ b/vcl/inc/vcl/scrbar.hxx
@@ -83,8 +83,9 @@
 SAL_DLLPRIVATE long ImplDoAction( sal_Bool bCallEndScroll );
 SAL_DLLPRIVATE void ImplDoMouseAction( const Point& rPos, sal_Bool 
bCallAction = sal_True );
 SAL_DLLPRIVATE void ImplInvert();
-SAL_DLLPRIVATE sal_Bool ImplDrawNative( sal_uInt16 nDrawFlags );
+SAL_DLLPRIVATE sal_Bool ImplDrawNative( sal_uInt16 nDrawFlags );
 SAL_DLLPRIVATE void ImplDragThumb( const Point& rMousePos );
+SAL_DLLPRIVATE Size getCurrentCalcSize() const;
 DECL_DLLPRIVATE_LINK(   ImplTimerHdl, Timer* );
 DECL_DLLPRIVATE_LINK(   ImplAutoTimerHdl, void* );
 
diff --git a/vcl/source/control/scrbar.cxx b/vcl/source/control/scrbar.cxx
index 9e90362..b99ff26 100644
--- a/vcl/source/control/scrbar.cxx
+++ b/vcl/source/control/scrbar.cxx
@@ -323,7 +323,7 @@
 Rectangle& maTrackRect = mpData->maTrackRect;  // TODO: remove when 
maTrackRect is no longer in mpData
 if ( mbCalcSize )
 {
-Size aOldSize = GetOptimalSize(WINDOWSIZE_PREFERRED);
+Size aOldSize = getCurrentCalcSize();
 
 const Rectangle aControlRegion( Point(0,0), aSize );
 Rectangle aBtn1Region, aBtn2Region, aTrackRegion, aBoundingRegion;
@@ -416,7 +416,7 @@
 
 mbCalcSize = sal_False;
 
-Size aNewSize = GetOptimalSize(WINDOWSIZE_PREFERRED);
+Size aNewSize = getCurrentCalcSize();
 if (aOldSize != aNewSize)
 {
 queue_resize();
@@ -1509,6 +1509,13 @@
 
 Size ScrollBar::GetOptimalSize(WindowSizeType) const
 {
+if (mbCalcSize)
+const_cast(this)->ImplCalc(sal_False);
+return getCurrentCalcSize();
+}
+
+Size ScrollBar::getCurrentCalcSize() const
+{
 Rectangle aCtrlRegion;
 aCtrlRegion.Union(maBtn1Rect);
 aCtrlRegion.Union(maBtn2Rect);

-- 
To view, visit https://gerrit.libreoffice.org/1630
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I12e95c3594ffbb508c7f79bd512e07aaf44a6eab
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Extending Dictionaries

[Petr Mladek]

Samuel Mehrbrodt píše v Čt 03. 01. 2013 v 23:30 +0100:
> I just sent you a list of words directly.
> 
> Can we document this somewhere in the Wiki, how to add new words to a 
> dictionary? I guess there are more people wanting to do this.

I have created
https://wiki.documentfoundation.org/Development/Dictionaries
Feel free to update it or ask if anything is unclear.

> Also, are there any guidelines which words are accepted in the dictionary?

The preferred way is to contact author of the dictionary and get the
words accepted by him. He is usually an expert for the given language
and the best person for decision making. Also it helps to make sure that
the new words are not lost within further updates.

By other words, LO git repository includes just a copy of the
dictionary. It is better to change in on the original location where it
come from.

Best Regards,
Petr


> Thanks
> Samuel
> 
> Am 03.01.2013 22:30, schrieb Bjoern Jacke:
> > On 2013-01-03 at 17:30 +0100 Samuel Mehrbrodt sent off:
> >> If there are no objections from the plugin authors, I'll create a
> >> patch against the dictionaries file.
> > please jsut send me the list of words. Patching dictionaries doesn't make 
> > much
> > sense for getting that upstream. The dictionary is a "compiled" version of 
> > the
> > dictionaries of igerman98.
> >
> > Cheers
> > Björn
> 


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: [libreoffice-dev] - questions about calc extension

[Rai, Neeraj]

Hi Michael,

Appreciate your feedback.
I ran callgrind but no output on screen and 0 bytes files generated. I can run 
it on non-LO exe.
I'll compile LO with --enable-debug and see if situation improves. Please 
advise if other steps might be needed.

What's your hunch about how long it should take to update 60K cells with 
{getCellByPosition(ii,jj) and setValue() } ?
Moving from interprocess bridge speeded it up for me and I might have given up 
on further speed-up too quickly. I can certainly use further speedup.

Thanks
Neeraj
-Original Message-
From: Michael Meeks [mailto:michael.me...@suse.com]
Sent: Thursday, January 10, 2013 4:45 AM
To: Rai, Neeraj [ICG-MKTS]
Cc: 'libreoffice@lists.freedesktop.org'
Subject: RE: [libreoffice-dev] - questions about calc extension


On Wed, 2013-01-09 at 23:18 +, Rai, Neeraj wrote:
> I looked a little more into your code and copied the getactiveSheet function. 
> Now it takes 12s. I am happy.
> Sorry for the spam - you have good code sitting there.

12s sounds like a long time to me ;-> If you can run your macro under
callgrind:

export OOO_DISABLE_RECOVERY=1
valgrind --tool=callgrind --simulate-cache=yes  \
 --dump-instr=yes ./soffice.bin -writer --splash-pipe=0

(needs write-permission to the installed libreoffice directory to drop
it's callgrind.12345.txt file)

Then perhaps kcachegrind will show you something interesting for your
use-case.

HTH,

Michael.

--
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gb_COMPILERNOOPTFLAGS does not even obey the user passed CFLAGS

[Lubos Lunak]

On Thursday 10 of January 2013, Tomáš Chvátal wrote:
> 2013/1/10 Lubos Lunak :
> >> As written in subject the variable is used on multiple targets and it
> >> ignores the user defined cflags/cxxflags.
> >> This should never happen and all our targets should take into effect the
> >> user defined options too.
> >>
> >> I am not sure which variable I should append there, so could anyone
> >> check if the diff in attachment is right?
> >
> >  It doesn't look right. CXXFLAGS should always get used for building .cxx
> > sources, so this should have no effect, moreover gb_COMPILERNOOPTFLAGS is
> > simply the default noopt flag to use when doing debug build. And I don't
> > quite understand why you'd want this change, what problem are you trying
> > to solve?
>
> See how bridgetests are build,
>
> they fail on old systems because they just specify the -O0 and nothing
> else, not even march
>
> So Petr used this patch in build service [1] but i think we should
> make this respected everywhere.

 Reading this patch, your change looks to me like putting the CXXFLAGS in some 
random place where it will incidentally work, but the moment somebody doesn't 
include gb_COMPILERNOOPTFLAGS in the flags passed to add_cxxobject, the 
problem is back again. If add_cxxobject doesn't include CXXFLAGS, why not fix 
it to ensure that (which possibly may need others like add_noexception_object 
to delegate to add_cxxobject_internal instead of add_cxxobject)?

> [1]
> https://build.opensuse.org/package/view_file?file=bridges-missing-cxxflags.
>diff&package=libreoffice&project=LibreOffice%3AUnstable&rev=157

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: fdo#57938 SwPaM::HasReadonlySel: commented text ranges are n...

[Miklos Vajna (via Code Review)]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1629

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/29/1629/1

fdo#57938 SwPaM::HasReadonlySel: commented text ranges are not read-only

(cherry picked from commit fd0da52d371ca13d66be3b04d89f9d9cf73baddd)

Change-Id: I8191ed6383c4c636be67b8d42654dbba0a5c8b6f
---
M sw/source/core/crsr/pam.cxx
1 file changed, 7 insertions(+), 1 deletion(-)



diff --git a/sw/source/core/crsr/pam.cxx b/sw/source/core/crsr/pam.cxx
index baf62ad..6d7f07a 100644
--- a/sw/source/core/crsr/pam.cxx
+++ b/sw/source/core/crsr/pam.cxx
@@ -685,6 +685,7 @@
 sw::mark::IMark* pA = NULL;
 sw::mark::IMark* pB = NULL;
 bool bUnhandledMark = false;
+bool bCommentrangeMark = false;
 if ( pDoc )
 {
 const IDocumentMarkAccess* pMarksAccess = 
pDoc->getIDocumentMarkAccess( );
@@ -693,7 +694,11 @@
 
 sw::mark::IFieldmark* pFieldmark = pMarksAccess->getFieldmarkFor( 
*GetPoint() );
 if ( pFieldmark )
+{
 bUnhandledMark = pFieldmark->GetFieldname( ) == ODF_UNHANDLED;
+if (!bUnhandledMark)
+bCommentrangeMark = pFieldmark->GetFieldname() == 
ODF_COMMENTRANGE;
+}
 }
 
 if (!bRet)
@@ -701,7 +706,8 @@
 // Unhandled fieldmarks case shouldn't be edited manually to avoid 
breaking anything
 if ( ( pA == pB ) && bUnhandledMark )
 bRet = sal_True;
-else
+// Allow editing of commented ranges.
+else if (!((pA == pB) && bCommentrangeMark))
 {
 // Form protection case
 bool bAtStartA = pA != NULL && pA->GetMarkStart() == *GetPoint();

-- 
To view, visit https://gerrit.libreoffice.org/1629
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I8191ed6383c4c636be67b8d42654dbba0a5c8b6f
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Miklos Vajna 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: [libreoffice-dev] - questions about calc extension

[Rai, Neeraj]

Hi Stephan,

I am unable to find XDesktop2. Your sample below looks really simple and right 
way to go.
I am working with release version 3.6.4.3 - built it from tar files.
I don't mind upgrading to latest tip, but I had trouble building the git 
checkout version.
Being fairly new to this large and comprehensive product, I decided to take the 
easy way to begin.

I would also be curious to know how to find out about such api - unfortunately, 
right now I am reading only specific emails on dev group and unable to follow 
conversations on other topics. Is reading docs the best way ? Is it possible to 
find some sample code ?

Kohei seems to have a working version with source below. I had trouble finding 
source for the other calc extensions listed on site.
I understand that situation is complicated with taking over working code and 
existing docs. It may take some time to get those things in order.
I am a user of LO api and don't want to look like demanding regime change (like 
"LO spring" driven by nabble instead of facebook :-))
If it is feasible to dedicate space for source of extensions, I have a feeling 
space requirements there might grow quickly.
That said, I know it may take time getting these one off things done with 
everyone having current deadlines and some of you are working on this part time.
The current examples that come bundled are all great. They focus on single 
feature and demonstrate it well. All the ones I tried, compiled.

Thanks
Neeraj

-Original Message-
From: libreoffice-bounces+neeraj.rai=citi@lists.freedesktop.org 
[mailto:libreoffice-bounces+neeraj.rai=citi@lists.freedesktop.org] On 
Behalf Of Stephan Bergmann
Sent: Thursday, January 10, 2013 3:45 AM
To: libreoffice@lists.freedesktop.org
Subject: Re: [libreoffice-dev] - questions about calc extension

On 01/09/2013 07:41 PM, Kohei Yoshida wrote:
> On 01/09/2013 01:12 PM, Rai, Neeraj wrote:
>> What is the correct way to get a
>> handle to spreadsheet in extension code.
>
> I don't want you to look too close to this (since I no longer maintain
> this), bug this code of mine
>
> http://code.google.com/p/scsolver/source/browse/source/ui/xcalc.cxx
>
> may give you some hint, especially the top 3 methods,
> getCurrentComponent(), updateCurrentComponent(), and getServiceManager()
> should give you how to get the current component object from the current
> context object.  As an extension, you are given access to the current
> context object, and you can reach the current component from that one
> way or another.

Some comments on the above code, for the benefit of fresh development:

Obtaining the com.sun.star.frame.Desktop service (variable xDesktop) in
updateCurrentComponent can be greatly simplified through the use of
so-called new-style service constructors (and Noel's ongoing work of
changing existing old-style services into new-style ones in UNOIDL):

   Reference< frame::XDesktop2 > xDesktop(
   frame::Desktop::create(m_xCC));

- It already returns the proper interface of the service (in this case
XDesktop2, derived from XDesktop), so no need for querying from
XInterface to the correct type.

- It directly uses the component context, no need for the service
manager.  (In general, demand for explicitly using the service manager
should go away more and more over time.)

Stephan
___
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: replacing OUString::valueOf(static_cast) ??

[Lubos Lunak]

On Thursday 10 of January 2013, Noel Grandin wrote:
> On 2013-01-10 15:55, Lubos Lunak wrote:
> > - There's no need for valueOfChar(). There is already OUString ctor from
> > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > thing complicated. Code using it can be converted to use the ctor
> > instead.
>
> Which doesn't help with overload resolution problems.

 It does. If you say it's wrong to use valueOfWhatever() for char->string 
conversion, there either will not be problems, or it will be wrong. If you 
want to fix an existing problem by introducing a new function, how does that 
make anything better than using an already existing function that does the 
job?

> > - When more or less deprecating valueOf() this way, it has also float
> > overloads, so something should be created for those too.
>
> If those also suffer from overload resolution problems, then sure.
> But
>   git grep "String::valueOf.*static_cast<.*double"
> doesn't find anything that looks like it needs help.
>
> > - I'm still not sold on the naming, OUString::valueInt() doesn't say much
> > and OUString::valueOfInt() feels cryptic. Can we please use something
> > obvious that doesn't need decyphering, such as OUString::number() or
> > OUString::fromInt() (as much as I still don't like the idea of harcoding
> > the irrelevant type information in the name)?
>
> Which would be inconsistent with the existing method names.

 Oh. I think we may be talking past each others because we have different 
goals. Am I correct in the assumption that you merely want to add another set 
of functions that people can use whenever the originals don't work?

 I do not think it is a good idea to just do a quick hack to paper over a 
problem. The strings are one of the most basic classes in the LO code, and if 
we are going to do changes there, we may as well try to do them properly. 
Base classes are not something we should randomly throw changes at, and we 
can still spend ages fixing up all the design decisions in the string classes 
that already are there and could have been done better. So while I appreciate 
it that you're willing to write a kludge that'll help avoid a problem, I kind 
of consider it a waste of your time, when with just little more effort a 
proper solution could be created.

 If you just add another set of functions, it will be confusing which one to 
use. And people will still sometimes use the old one out of habbit or for 
whatever reason, and still the problem will occassionally show up, and then 
the code will need to be changed to the new function, which is not really 
that different to just adding a cast. And if you say that people should 
always directly use the new one, then you may as well remove the old one 
(except keep it for extensions backwards compatibility), and then all I've 
said applies (no need for char function, float function needed, use a good 
name, etc.).

 Or did I misunderstand the intent of your patch?

> >   I expect it won't, regular expressions can't tell what foo is in
> > "valueOf( foo )".
>
> Actually, regex can. It's called capturing groups.

 Capturing groups may tell you that foo is foo, but it won't tell you it's a 
float. So how will you know to which of your proposed valueX() functions you 
should change it?

> > Unless all you want to convert is only places which do the explicit
> > cast, this will need a (fairly simple) Clang plugin.
>
> Sure, if you feel like writing one.

 Actually, I'd prefer to write a howto about that first, whenever I get to 
doing that, so that I don't have to write every single plugin. Such a plugin 
will be still much simpler than a regexp or any other way.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: sw/source

[Libreoffice Gerrit user]

 sw/source/core/crsr/pam.cxx |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

New commits:
commit fd0da52d371ca13d66be3b04d89f9d9cf73baddd
Author: Miklos Vajna 
Date:   Thu Jan 10 16:21:55 2013 +0100

fdo#57938 SwPaM::HasReadonlySel: commented text ranges are not read-only

diff --git a/sw/source/core/crsr/pam.cxx b/sw/source/core/crsr/pam.cxx
index e9b7802..852 100644
--- a/sw/source/core/crsr/pam.cxx
+++ b/sw/source/core/crsr/pam.cxx
@@ -686,6 +686,7 @@ sal_Bool SwPaM::HasReadonlySel( bool bFormView ) const
 sw::mark::IMark* pA = NULL;
 sw::mark::IMark* pB = NULL;
 bool bUnhandledMark = false;
+bool bCommentrangeMark = false;
 if ( pDoc )
 {
 const IDocumentMarkAccess* pMarksAccess = 
pDoc->getIDocumentMarkAccess( );
@@ -694,7 +695,11 @@ sal_Bool SwPaM::HasReadonlySel( bool bFormView ) const
 
 sw::mark::IFieldmark* pFieldmark = pMarksAccess->getFieldmarkFor( 
*GetPoint() );
 if ( pFieldmark )
+{
 bUnhandledMark = pFieldmark->GetFieldname( ) == ODF_UNHANDLED;
+if (!bUnhandledMark)
+bCommentrangeMark = pFieldmark->GetFieldname() == 
ODF_COMMENTRANGE;
+}
 }
 
 if (!bRet)
@@ -702,7 +707,8 @@ sal_Bool SwPaM::HasReadonlySel( bool bFormView ) const
 // Unhandled fieldmarks case shouldn't be edited manually to avoid 
breaking anything
 if ( ( pA == pB ) && bUnhandledMark )
 bRet = sal_True;
-else
+// Allow editing of commented ranges.
+else if (!((pA == pB) && bCommentrangeMark))
 {
 // Form protection case
 bool bAtStartA = pA != NULL && pA->GetMarkStart() == *GetPoint();
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-l10n] Translation of the names of the keys on Windows

[Adolfo Jayme Barrientos]

On Tue, Jan 8, 2013 at 7:44 AM, Jesús Corrius  wrote:
> If you want to implement this, but you are not a developer, just send me
> the name of the keys with its translation and I will apply the changes
> myself.

Hi, I was wondering if you could add a Spanish translation:

static const struct KeysNameReplacement aImplReplacements_Spanish[] =
{
{ KEY_BACK, "Retroceso" },
{ KEY_ENTER, "Intro" },
{ KEY_SPACEBAR, "Espacio" },
{ KEY_HOME, "Inicio" },
{ KEY_UP, "Arriba" },
{ KEY_PAGEUP, "Re Pág" },
{ KEY_LEFT, "Izquierda" },
{ KEY_RIGHT, "Derecha" },
{ KEY_END, "Fin" },
{ KEY_DOWN, "Abajo" },
{ KEY_PAGEDOWN, "Av Pág" },
{ KEY_INSERT, "Ins" },
{ KEY_DELETE, "Supr" },
{ KEY_SHIFT, "Mayús" },
};

Thanks!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: cppcanvas/source

[Libreoffice Gerrit user]

 cppcanvas/source/mtfrenderer/emfplus.cxx |   45 +++
 1 file changed, 45 insertions(+)

New commits:
commit da09115cffeca384ab91ffe4d7af4d8eab6cee82
Author: Radek Doulik 
Date:   Thu Jan 10 15:58:30 2013 +0100

implemented EmfPlusRecordTypeFillPie record

Change-Id: I15e7464a6a295bb4c1313c0a65ee33b6443c61c8

diff --git a/cppcanvas/source/mtfrenderer/emfplus.cxx 
b/cppcanvas/source/mtfrenderer/emfplus.cxx
index 3c791d4..f1b0eff 100644
--- a/cppcanvas/source/mtfrenderer/emfplus.cxx
+++ b/cppcanvas/source/mtfrenderer/emfplus.cxx
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,6 +53,7 @@
 #define EmfPlusRecordTypeFillRects 16394
 #define EmfPlusRecordTypeFillPolygon 16396
 #define EmfPlusRecordTypeDrawLines 16397
+#define EmfPlusRecordTypeFillPie 16400
 #define EmfPlusRecordTypeFillPath 16404
 #define EmfPlusRecordTypeDrawPath 16405
 #define EmfPlusRecordTypeDrawImage 16410
@@ -93,6 +95,7 @@
 #endif
 
 using namespace ::com::sun::star;
+using namespace ::basegfx;
 
 namespace cppcanvas
 {
@@ -1234,6 +1237,48 @@ namespace cppcanvas
 case EmfPlusRecordTypeObject:
 processObjectRecord (rMF, flags);
 break;
+case EmfPlusRecordTypeFillPie:
+{
+sal_uInt32 brushIndexOrColor;
+float startAngle, sweepAngle;
+
+rMF >> brushIndexOrColor >> startAngle >> sweepAngle;
+
+EMFP_DEBUG (printf ("EMF+ FillPie colorOrIndex: %x 
startAngle: %f sweepAngle: %f\n", (unsigned int)brushIndexOrColor, startAngle, 
sweepAngle));
+
+float dx, dy, dw, dh;
+
+ReadRectangle (rMF, dx, dy, dw, dh, flags & 0x4000);
+
+EMFP_DEBUG (printf ("EMF+ RectData: %f,%f %fx%f\n", 
dx, dy, dw, dh));
+
+startAngle = 2*M_PI*startAngle/360;
+sweepAngle = 2*M_PI*sweepAngle/360;
+
+B2DPoint mappedCenter (Map (dx + dw/2, dy + dh/2));
+B2DSize mappedSize( MapSize (dw/2, dh/2));
+
+double endAngle = startAngle + sweepAngle;
+if (endAngle < 0)
+endAngle += M_PI*2;
+endAngle = fmod (endAngle, M_PI*2);
+
+if (sweepAngle < 0) {
+double tmp = startAngle;
+startAngle = endAngle;
+endAngle = tmp;
+}
+
+EMFP_DEBUG (printf ("EMF+ angles: %f,%f  ---> 
%f,%f\n", startAngle, sweepAngle, startAngle, endAngle));
+
+B2DPolygon polygon = 
tools::createPolygonFromEllipseSegment (mappedCenter, mappedSize.getX (), 
mappedSize.getY (), startAngle, endAngle);
+polygon.append (mappedCenter);
+polygon.setClosed (true);
+
+B2DPolyPolygon polyPolygon (polygon);
+EMFPPlusFillPolygon (polyPolygon, rFactoryParms, 
rState, rCanvas, flags & 0x8000, brushIndexOrColor);
+}
+break;
 case EmfPlusRecordTypeFillPath:
 {
 sal_uInt32 index = flags & 0xff;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - config_host.mk.in configure.ac solenv/gbuild

[Libreoffice Gerrit user]

 config_host.mk.in   |1 +
 configure.ac|   19 +++
 solenv/gbuild/gbuild.mk |4 
 3 files changed, 24 insertions(+)

New commits:
commit f0fd3bd8f8a13f6cbe2a27018b83eee24a694c09
Author: Tomas Chvatal 
Date:   Mon Dec 10 10:41:35 2012 +0100

Add configure switch that allows hardlink deliver

This switch just makes possible to configure in ln delivery instead of
cp based one.

The feature was already in the place, we just make it visible as
configure option now.

Change-Id: I778ef3b03e6b9a57057e66ff6307e7da46bcd935

diff --git a/config_host.mk.in b/config_host.mk.in
index 6ffd0fe..d7ede5a 100644
--- a/config_host.mk.in
+++ b/config_host.mk.in
@@ -215,6 +215,7 @@ export GUI=@GUI@
 export GUIBASE=@GUIBASE@
 export GUIBASE_FOR_BUILD=@GUIBASE_FOR_BUILD@
 export GUI_FOR_BUILD=@GUI_FOR_BUILD@
+export HARDLINKDELIVER=@HARDLINKDELIVER@
 export HAVE_CXX0X=@HAVE_CXX0X@
 export HAVE_GCC_AVX=@HAVE_GCC_AVX@
 export HAVE_GCC_BUILTIN_ATOMIC=@HAVE_GCC_BUILTIN_ATOMIC@
diff --git a/configure.ac b/configure.ac
index b028e39..9da5b39 100644
--- a/configure.ac
+++ b/configure.ac
@@ -651,6 +651,12 @@ AC_ARG_ENABLE(ext-wiki-publisher,
 
 dnl -- *** --
 
+AC_ARG_ENABLE([hardlink-deliver],
+AS_HELP_STRING([--enable-hardlink-deliver],
+[Put files into deliver folder as hardlinks instead of copying them
+over. Saves space and speeds up build.])
+)
+
 AC_ARG_ENABLE(mergelibs,
 AS_HELP_STRING([--enable-mergelibs],
 [Enables linking of big, merged, library. Experimental feature tested
@@ -11986,6 +11992,19 @@ else
 fi
 AC_SUBST(MERGELIBS)
 
+# ===
+# Create hardlinks on deliver instead of copying for smaller size and speed up
+# ===
+AC_MSG_CHECKING([whether to create hardlinks for delivering files])
+HARDLINKDELIVER=
+if test "$enable_hardlink_deliver" = "yes"; then
+HARDLINKDELIVER="TRUE"
+AC_MSG_RESULT([yes])
+else
+AC_MSG_RESULT([no])
+fi
+AC_SUBST(HARDLINKDELIVER)
+
 dnl ===
 dnl icerun is a wrapper that stops us spawning tens of processes
 dnl locally - for tools that can't be executed on the compile cluster
diff --git a/solenv/gbuild/gbuild.mk b/solenv/gbuild/gbuild.mk
index 321d42c..173222f 100644
--- a/solenv/gbuild/gbuild.mk
+++ b/solenv/gbuild/gbuild.mk
@@ -132,6 +132,10 @@ ENABLE_DEBUGINFO_FOR := all
 endif
 endif
 
+ifeq ($(HARDLINKDELIVER),TRUE)
+gb_Deliver_HARDLINK := $(true)
+endif
+
 ifeq ($(or $(ENABLE_SYMBOLS),$(enable_symbols)),FALSE)
 gb_SYMBOL := $(false)
 else
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-marketing] Latest Hardware and OS

[Rainer Bielefeld]

Tom Davies schrieb:

At the moment those devices are probably not seen as good things to use to edit 
documents.




Hi all,

of course (nearby) nobody will use an Android Handy to write a Novel or 
similar; nevertheless, yesterday in the omnibus, I watched a young woman 
and was fascinated concerning the speed she wrote on a handy only using 
her thumbs. I'm afraid she was faster than me here typing with 10 fingers.


But I think an android tablet or even a smartphone can be quite a nice 
ODF document viewer, may be with smaller edits in the documents or so, 
you can use LibO for creation of simple documents from Templates 
(timesheet, directly signed by the customer on the screen in a DRAW OLE 
object ...).


And LibO seems not to be the spear head there, please see 
!


On my Android tablet I use a different ODF viewer (forgot the name, 
result is not satisfying), because Versions from 
daily/master/Android-... crashed during installation).


So we need to interest more new additional Hackers helping to create a 
LibO Android suite based on the current Master, including Documentation, 
Project info, ... .


Best regards


Rainer Bielefeld
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: replacing OUString::valueOf(static_cast) ??

[Stephan Bergmann]

On 01/10/2013 02:55 PM, Lubos Lunak wrote:

On Thursday 10 of January 2013, Noel Grandin wrote:

https://gerrit.libreoffice.org/#/c/1625/


  Can we please keep the discussion still here? Gerrit may be fine for pointing
out technical details in the code, but it's not very suitable for discussions
about anything beyond that.

- There's no need for valueOfChar(). There is already OUString ctor from
sal_Unicode, so the valueOf() overload for it is just making an obvious thing
complicated. Code using it can be converted to use the ctor instead.

- It's a question if we really need 'OUString::valueOfBool( foo )' instead of
simply 'foo ? OUString( "true" ) : OUString( "false" )' (such a pity the
string literals handling doesn't allow "foo ? "true" : "false"' ). I wonder
how many places in the code really need to convert a boolean to the hardcoded
english string representation.

- When more or less deprecating valueOf() this way, it has also float
overloads, so something should be created for those too.

- I'm still not sold on the naming, OUString::valueInt() doesn't say much and
OUString::valueOfInt() feels cryptic. Can we please use something obvious
that doesn't need decyphering, such as OUString::number() or
OUString::fromInt() (as much as I still don't like the idea of harcoding the
irrelevant type information in the name)?


Btw, the name "valueOf" and the idea of overloading it for all 
conceivable (sal) types comes from the -- somewhat misguided -- attempt 
at modelling rtll::OUString after java.lang.String.


The "fromInt" etc. names look OK to me, too.

Re dropping valueOfBool, I'm not sure how many places actually use it; 
"for i in solver/*/lib/*.so*; do nm "$i" -D --undef | grep -F 
_valueOfBoolean; done" does indicate its not completely unused.  Also, 
we have rtl_ustr_valueOfBoolean around anyway.


Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Need confirmation about non-clearing of Character Styles

[Michael Stahl]

On 10/01/13 14:25, Caolán McNamara wrote:
> On Thu, 2013-01-10 at 10:55 +0100, Fernand Vanrie wrote:
>> Sinds all or editors use LO 3.6.2 (before OO3.3)
>>
>> We have complains about the fact that parts of the text, who are
>> formated with a Character Style, can not been "cleared" to
>> no-formating,
>> not by "Clear Direct Formating (cntrl+M)"
>>
>> There is a dirty work-around by applying the "Default" character style
>>
>> Paragraph Styles can been cleared
>> Is this intentional behavior or a regression open for a issue ?
> 
> My understanding is
> a) that its intentional, see
> http://lists.freedesktop.org/archives/ooo-build/2010-February/000540.html
> and the commit
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e690e0909459d46c53d17e7939891abea11e566

the corresponding issues are an "interesting" read:

https://issues.apache.org/ooo/show_bug.cgi?id=47893 <- patch author
arguing for the change
https://issues.apache.org/ooo/show_bug.cgi?id=85464 <- a certain Cor
reporting the change as regression :)

i definitely think that there should be some button to reset formatting
that leaves character styles intact, and that should be the "most easily
accessible" option.  but i wouldn't object to a second button to reset
all formatting, including styles.

resetting the character styles should be as easy as setting "Default"
char style on the whole document, so i'm not sure if another option is
worth the additional clutter.

but hyperlinks should not be touched by any "reset formatting" since
they are not formatting, but content entities (the reset feature also
doesn't convert fields to plain text).

also i'm thinking that ruby text should also not be touched by "reset
formatting", and this has not yet been changed (i.e. it is reset
currently); the reset will actually throw away the ruby text.  i'm
already sitting on a patch to remove ruby from the reset list...


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: replacing OUString::valueOf(static_cast) ??

[Noel Grandin]

On 2013-01-10 15:55, Lubos Lunak wrote:

On Thursday 10 of January 2013, Noel Grandin wrote:

Created a proof-of-concept patch along with some unit tests and pushed
to gerrit:

https://gerrit.libreoffice.org/#/c/1625/

  Can we please keep the discussion still here? Gerrit may be fine for pointing
out technical details in the code, but it's not very suitable for discussions
about anything beyond that.
That's why it said "proof of concept". Mostly, I did it to point that 
someone was willing to do the work :-)



- There's no need for valueOfChar(). There is already OUString ctor from
sal_Unicode, so the valueOf() overload for it is just making an obvious thing
complicated. Code using it can be converted to use the ctor instead.

Which doesn't help with overload resolution problems.



- When more or less deprecating valueOf() this way, it has also float
overloads, so something should be created for those too.

If those also suffer from overload resolution problems, then sure.
But
 git grep "String::valueOf.*static_cast<.*double"
doesn't find anything that looks like it needs help.


- I'm still not sold on the naming, OUString::valueInt() doesn't say much and
OUString::valueOfInt() feels cryptic. Can we please use something obvious
that doesn't need decyphering, such as OUString::number() or
OUString::fromInt() (as much as I still don't like the idea of harcoding the
irrelevant type information in the name)?

Which would be inconsistent with the existing method names.



  I expect it won't, regular expressions can't tell what foo is in "valueOf(
foo )".

Actually, regex can. It's called capturing groups.
http://www.regular-expressions.info/brackets.html
Doesn't work very well with complex expressions, but it can handle the 
simple cases.



Unless all you want to convert is only places which do the explicit
cast, this will need a (fairly simple) Clang plugin.

Sure, if you feel like writing one.


Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: gb_COMPILERNOOPTFLAGS does not even obey the user passed CFLAGS

[Lubos Lunak]

On Thursday 10 of January 2013, Tomáš Chvátal wrote:
> Hi guys,
>
> As written in subject the variable is used on multiple targets and it
> ignores the user defined cflags/cxxflags.
> This should never happen and all our targets should take into effect the
> user defined options too.
>
> I am not sure which variable I should append there, so could anyone check
> if the diff in attachment is right?

 It doesn't look right. CXXFLAGS should always get used for building .cxx 
sources, so this should have no effect, moreover gb_COMPILERNOOPTFLAGS is 
simply the default noopt flag to use when doing debug build. And I don't 
quite understand why you'd want this change, what problem are you trying to 
solve?

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: replacing OUString::valueOf(static_cast) ??

[Lubos Lunak]

On Thursday 10 of January 2013, Noel Grandin wrote:
> On 2013-01-09 19:58, Michael Meeks wrote:
> > At least in my mind :-) but we're starting to bike-shed here... I
> > didn't see anyone volunteering to do the actual batch cleanup there
> > ;-) Regards, Michael.
>
> Created a proof-of-concept patch along with some unit tests and pushed
> to gerrit:
>
> https://gerrit.libreoffice.org/#/c/1625/

 Can we please keep the discussion still here? Gerrit may be fine for pointing 
out technical details in the code, but it's not very suitable for discussions 
about anything beyond that.

- There's no need for valueOfChar(). There is already OUString ctor from 
sal_Unicode, so the valueOf() overload for it is just making an obvious thing 
complicated. Code using it can be converted to use the ctor instead.

- It's a question if we really need 'OUString::valueOfBool( foo )' instead of 
simply 'foo ? OUString( "true" ) : OUString( "false" )' (such a pity the 
string literals handling doesn't allow "foo ? "true" : "false"' ). I wonder 
how many places in the code really need to convert a boolean to the hardcoded 
english string representation.

- When more or less deprecating valueOf() this way, it has also float 
overloads, so something should be created for those too.

- I'm still not sold on the naming, OUString::valueInt() doesn't say much and 
OUString::valueOfInt() feels cryptic. Can we please use something obvious 
that doesn't need decyphering, such as OUString::number() or 
OUString::fromInt() (as much as I still don't like the idea of harcoding the 
irrelevant type information in the name)?

On Thursday 10 of January 2013, Noel Grandin wrote:
> On Wed, Jan 9, 2013 at 7:58 PM, Michael Meeks wrote:
> > At least in my mind :-) but we're starting to bike-shed here... I
> >  didn't see anyone volunteering to do the actual batch cleanup there ;-)
>
> Doesn't sound that hard - some regular expression magic will do most of the
> work.

 I expect it won't, regular expressions can't tell what foo is in "valueOf( 
foo )". Unless all you want to convert is only places which do the explicit 
cast, this will need a (fairly simple) Clang plugin.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: Resolves: fdo#59112 re-scroll to current entry when dialog r...

[via Code Review]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1628

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/28/1628/1

Resolves: fdo#59112 re-scroll to current entry when dialog resized

Change-Id: I96486f6edad11520bf9bb43b700b1716d9b2f170
(cherry picked from commit 2c403c7f36561410418ebb9f86664e46a8c1c968)
---
M sc/source/ui/dbgui/sortkeydlg.cxx
1 file changed, 1 insertion(+), 0 deletions(-)



diff --git a/sc/source/ui/dbgui/sortkeydlg.cxx 
b/sc/source/ui/dbgui/sortkeydlg.cxx
index 45d65ca..e71a48f 100644
--- a/sc/source/ui/dbgui/sortkeydlg.cxx
+++ b/sc/source/ui/dbgui/sortkeydlg.cxx
@@ -127,6 +127,7 @@
 sal_Int32 nVisibleItems = m_rScrolledWindow.getVisibleChildSize().Height() 
/ nScrollOffset;
 m_rVertScroll.SetPageSize( nVisibleItems - 1 );
 m_rVertScroll.SetVisibleSize( nVisibleItems );
+m_rVertScroll.Scroll();
 }
 
 // ---

-- 
To view, visit https://gerrit.libreoffice.org/1628
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I96486f6edad11520bf9bb43b700b1716d9b2f170
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: sc/source

[Libreoffice Gerrit user]

 sc/source/ui/dbgui/sortkeydlg.cxx |1 +
 1 file changed, 1 insertion(+)

New commits:
commit 2c403c7f36561410418ebb9f86664e46a8c1c968
Author: Caolán McNamara 
Date:   Thu Jan 10 13:49:20 2013 +

Resolves: fdo#59112 re-scroll to current entry when dialog resized

Change-Id: I96486f6edad11520bf9bb43b700b1716d9b2f170

diff --git a/sc/source/ui/dbgui/sortkeydlg.cxx 
b/sc/source/ui/dbgui/sortkeydlg.cxx
index 76a8747..211afcc 100644
--- a/sc/source/ui/dbgui/sortkeydlg.cxx
+++ b/sc/source/ui/dbgui/sortkeydlg.cxx
@@ -126,6 +126,7 @@ void ScSortKeyCtrl::setScrollRange()
 sal_Int32 nVisibleItems = m_rScrolledWindow.getVisibleChildSize().Height() 
/ nScrollOffset;
 m_rVertScroll.SetPageSize( nVisibleItems - 1 );
 m_rVertScroll.SetVisibleSize( nVisibleItems );
+m_rVertScroll.Scroll();
 }
 
 // ---
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

gb_COMPILERNOOPTFLAGS does not even obey the user passed CFLAGS

[Tomáš Chvátal]

Hi guys,

As written in subject the variable is used on multiple targets and it
ignores the user defined cflags/cxxflags.
This should never happen and all our targets should take into effect the
user defined options too.

I am not sure which variable I should append there, so could anyone check
if the diff in attachment is right?

Cheers

Tom


cxxflags.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: 4 commits - bridges/Module_bridges.mk cross_tail_build/Makefile Makefile.in solenv/bin solenv/gbuild tail_build/Makefile

[Libreoffice Gerrit user]

 Makefile.in |   11 ++--
 bridges/Module_bridges.mk   |2 
 cross_tail_build/Makefile   |1 
 solenv/bin/build.pl |2 
 solenv/gbuild/Module.mk |   61 +---
 solenv/gbuild/extensions/post_SpeedUpTargets.mk |   38 +++---
 solenv/gbuild/gbuild.mk |   10 ---
 solenv/gbuild/partial_build.mk  |3 -
 tail_build/Makefile |1 
 9 files changed, 30 insertions(+), 99 deletions(-)

New commits:
commit ca6aefe0839286515c6874b917e980eaa6d03282
Author: Matúš Kukan 
Date:   Thu Jan 10 14:42:07 2013 +0100

these are phony targets

Change-Id: I6de7842d5f03c6df5bffefdf77a90b5efee2fc78

diff --git a/Makefile.in b/Makefile.in
index 3ed0cdd..d114d81 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -422,6 +422,7 @@ check: dev-install subsequentcheck
 subsequentcheck :| $(if $(filter-out 
subsequentcheck,$(MAKECMDGOALS)),dev-install)
$(GNUMAKE) -j $(CHECK_PARALLELISM) $(GMAKE_OPTIONS) -f 
$(SRC_ROOT)/Makefile.post $@
 
+.PHONY : unitcheck slowcheck debugrun translations
 unitcheck slowcheck debugrun translations:
$(GNUMAKE) -j $(PARALLELISM) $(GMAKE_OPTIONS) -f 
$(SRC_ROOT)/Makefile.post $@
 
commit 26637fe8f241c6ae00f8fdcd5d2a647c7c3cb411
Author: Matúš Kukan 
Date:   Wed Jan 9 21:37:10 2013 +0100

optimize for build targets in one place

Change-Id: Ib886a323c1ade6dcd455a44d3dfc6702086416e3

diff --git a/bridges/Module_bridges.mk b/bridges/Module_bridges.mk
index 14a7255..c1dbcef 100644
--- a/bridges/Module_bridges.mk
+++ b/bridges/Module_bridges.mk
@@ -96,7 +96,7 @@ $(eval $(call gb_Module_add_targets,bridges,\
) \
 ))
 
-ifeq ($(gb_FULL_BUILD),$(true))
+ifeq (,$(gb_STRIPPED_BUILD))
 ifeq ($(strip $(bridges_SELECTED_BRIDGE)),)
 $(call gb_Output_error,no bridge selected for build: bailing out)
 endif
diff --git a/solenv/gbuild/Module.mk b/solenv/gbuild/Module.mk
index 0f985bb..d20176a 100644
--- a/solenv/gbuild/Module.mk
+++ b/solenv/gbuild/Module.mk
@@ -89,7 +89,7 @@ $(call gb_Module_get_target,%) :
mkdir -p $(dir $@) && \
touch $@)
 
-.PHONY : build all clean unitcheck slowcheck subsequentcheck showmodules 
translations
+.PHONY : all build unitcheck slowcheck subsequentcheck clean check debugrun 
help showmodules translations
 .DEFAULT_GOAL := all
 
 all : build unitcheck
@@ -130,6 +130,9 @@ check : unitcheck slowcheck
 debugrun :
$(call gb_Module_DEBUGRUNCOMMAND)
 
+help :
+   @cat $(SRCDIR)/solenv/gbuild/gbuild.help.txt
+
 showmodules :
$(info $(strip $(gb_Module_ALLMODULES)))
@true 
@@ -184,9 +187,6 @@ endif
 
 endef
 
-gb_FULL_BUILD := $(if $(filter showmodules 
translations,$(MAKECMDGOALS)),$(false),$(true))
-
-ifeq ($(gb_FULL_BUILD),$(true))
 define gb_Module_add_target
 $(call gb_Module__read_targetfile,$(1),$(2),target)
 
@@ -220,7 +220,6 @@ $(call gb_Module_get_subsequentcheck_target,$(1)) : 
$$(gb_Module_CURRENTTARGET)
 $(call gb_Module_get_clean_target,$(1)) : $$(gb_Module_CURRENTCLEANTARGET)
 
 endef
-endif
 
 define gb_Module_add_moduledir
 include $(patsubst $(1):%,%,$(filter 
$(1):%,$(gb_Module_MODULELOCATIONS)))/$(2)/Module_$(2).mk
diff --git a/solenv/gbuild/extensions/post_SpeedUpTargets.mk 
b/solenv/gbuild/extensions/post_SpeedUpTargets.mk
index 6175cbc..406a69e 100644
--- a/solenv/gbuild/extensions/post_SpeedUpTargets.mk
+++ b/solenv/gbuild/extensions/post_SpeedUpTargets.mk
@@ -25,23 +25,31 @@
 #   in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
 #   instead of those above.
 
-
-# speed up if no target need to parse all modules
-gb_SpeedUpTargets_WRAPPEDBUILD:=
 ifneq ($(strip $(MAKECMDGOALS)),)
-ifeq ($(filter-out id tags docs distro-pack-install fetch help debugrun 
$(SRCDIR)/config_host.mk,$(MAKECMDGOALS)),)
-gb_SpeedUpTargets_WRAPPEDBUILD:=T
+# speed up depending on the target
+gb_SpeedUpTargets_LEVEL_3 := debugrun help translations
+gb_SpeedUpTargets_LEVEL_2 := showmodules $(gb_SpeedUpTargets_LEVEL_3)
+gb_SpeedUpTargets_LEVEL_1 := clean showdeliverables 
$(gb_SpeedUpTargets_LEVEL_2)
+
+ifeq (T,$(if $(filter-out $(gb_SpeedUpTargets_LEVEL_1),$(MAKECMDGOALS)),,T))
+gb_FULLDEPS :=
+
+ifeq (T,$(if $(filter-out $(gb_SpeedUpTargets_LEVEL_2),$(MAKECMDGOALS)),,T))
+gb_Module_add_target :=
+gb_Module_add_check_target :=
+gb_Module_add_slowcheck_target :=
+gb_Module_add_subsequentcheck_target :=
+
+# Turns of check in bridges/Module_bridges.mk:
+gb_STRIPPED_BUILD := $(true)
+
+ifeq (T,$(if $(filter-out $(gb_SpeedUpTargets_LEVEL_3),$(MAKECMDGOALS)),,T))
+gb_Module_add_moduledir :=
+
+endif
 endif
 endif
 
-ifneq ($(strip $(gb_SpeedUpTargets_WRAPPEDBUILD)),)
-gb_Module_add_target=
-gb_Module_add_check_target=
-gb_Module_add_slowcheck_target=
-gb_Module_add_subsequentcheck_target=
-gb_Module_add_moduledir=
-gb_FULLDEPS=
 endif
 
 # vim:set shiftwidth=4

[Libreoffice-commits] .: 3 commits - configure.ac

[Libreoffice Gerrit user]

 configure.ac |  109 +--
 1 file changed, 61 insertions(+), 48 deletions(-)

New commits:
commit 417943f071cc6c7ebe4dad69dfdec411cc7de975
Author: Tor Lillqvist 
Date:   Thu Jan 10 15:41:02 2013 +0200

Get rid of last actual TABs in this file

Change-Id: Ic92c47834add4f5d0350343e6b7ea8294477b495

diff --git a/configure.ac b/configure.ac
index 7267536..2ef61b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4575,6 +4575,8 @@ if test -z "$GNUMAKE"; then
 AC_MSG_ERROR([not found. install GNU make.])
 fi
 
+TAB=`printf '\t'`
+
 AC_MSG_CHECKING([the GNU make version])
 _make_version=`$GNUMAKE --version | grep GNU | $GREP -v GPL | $SED -e 
's@^[[^0-9]]*@@' -e 's@ .*@@' -e 's@,.*@@'`
 _make_longver=`echo $_make_version | $AWK -F. '{ print \$1*1+\$2*100+\$3 
}'`
@@ -4596,16 +4598,16 @@ elif test "$_make_longver" -ge "038100"; then
 fi
 AC_MSG_CHECKING([for GNU make bug 20033])
 TESTGMAKEBUG20033=`mktemp -d tmp.XX`
-cat > $TESTGMAKEBUG20033/Makefile << EOF
+$SED -e "s//$TAB/" > $TESTGMAKEBUG20033/Makefile << EOF
 A := \$(wildcard *.a)
 
 .PHONY: all
 all: \$(A:.a=.b)
-   @echo survived bug20033. #dont kill these tabs, you will break the 
Makefile
+@echo survived bug20033. #dont kill these tabs, you will break the 
Makefile
 
 .PHONY: setup
 setup:
-   @touch 1.a 2.a 3.a 4.a 5.a 6.a
+@touch 1.a 2.a 3.a 4.a 5.a 6.a
 
 define d1
 @echo lala \$(1)
@@ -4618,9 +4620,9 @@ define d2
 endef
 
 %.b : %.a
-   \$(eval CHECKSUM := \$(word 1,\$(shell cat \$^ | $SHA1SUM))) \$(if 
\$(wildcard \$(CACHEDIR)/\$(CHECKSUM)),\
-   \$(call d1,\$(CHECKSUM)),\
-   \$(call d2,\$(CHECKSUM)))
+\$(eval CHECKSUM := \$(word 1,\$(shell cat \$^ | $SHA1SUM))) \$(if 
\$(wildcard \$(CACHEDIR)/\$(CHECKSUM)),\
+\$(call d1,\$(CHECKSUM)),\
+\$(call d2,\$(CHECKSUM)))
 EOF
 if test -z "`(cd $TESTGMAKEBUG20033 && $GNUMAKE setup && $GNUMAKE -j)|grep 
survived`"; then
 no_parallelism_make="YES"
@@ -4636,12 +4638,12 @@ fi
 # find if gnumake support file function
 AC_MSG_CHECKING([whether GNU make supports the 'file' function])
 TESTGMAKEFILEFUNC="`mktemp -d -t tst.XX`"
-cat > $TESTGMAKEFILEFUNC/Makefile << EOF
+$SED -e "s//$TAB/" > $TESTGMAKEFILEFUNC/Makefile << EOF
 \$(file >test.txt,Success )
 
 .PHONY: all
 all:
-   @cat test.txt
+@cat test.txt
 
 EOF
 $GNUMAKE -C $TESTGMAKEFILEFUNC 2>/dev/null 1>&2
commit f340cbb6af86c7046d34202d2781a68b0d991001
Author: Tor Lillqvist 
Date:   Thu Jan 10 15:13:49 2013 +0200

De-tab

Change-Id: If0e93181affadd7c608625c494daf6da78ba9bbc

diff --git a/configure.ac b/configure.ac
index 60daa23..7267536 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8293,9 +8293,9 @@ if test "$with_system_nss" = "yes"; then
 libo_MINGW_CHECK_DLL([SSL3], [ssl3])
 else
 SYSTEM_NSS="NO"
-   NSS_MAJOR="3"
-   NSS_MINOR="13"
-   NSS_PATCH="5"
+NSS_MAJOR="3"
+NSS_MINOR="13"
+NSS_PATCH="5"
 BUILD_TYPE="$BUILD_TYPE NSS"
 AC_MSG_RESULT([internal])
 fi # system nss
commit dc7e074fc89677d87194b2836c18755788c22f1c
Author: Tor Lillqvist 
Date:   Thu Jan 10 15:09:46 2013 +0200

Make it possible to even try building the OpenGL transitions for Windows

Change-Id: Id9b688a22518aedb8959120f909832f0cd84b324

diff --git a/configure.ac b/configure.ac
index 688f2e4..60daa23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -867,8 +867,7 @@ AC_ARG_ENABLE(cairo-canvas,
 
 AC_ARG_ENABLE(opengl,
 AS_HELP_STRING([--disable-opengl],
-[Determines whether to build the OpenGL 3D slide transitions 
component.]),
-,enable_opengl=yes)
+[Determines whether to build the OpenGL 3D slide transitions 
component.]))
 
 AC_ARG_ENABLE(dbus,
 AS_HELP_STRING([--disable-dbus],
@@ -9702,47 +9701,59 @@ dnl 
===
 AC_MSG_CHECKING([whether to build the OpenGL Transitions component])
 ENABLE_OPENGL=
 
-if test "$_os" = "Darwin"; then
+if test -z "$enable_opengl"; then
+if test $_os = WINNT; then
+# By default disable the OpenGL transitions for Windows (the code 
doesn't even compile
+# currently). In other words, use --enable-opengl only if you plan to 
hack on that code for
+# Windows.
+enable_opengl=no
+else
+enable_opengl=yes
+fi
+fi
+
+if test "x$enable_opengl" = "xno"; then
+AC_MSG_RESULT([no])
+elif test "$_os" = "Darwin"; then
 # We use frameworks on Mac OS X, no need for detail checks
 ENABLE_OPENGL=TRUE
 SYSTEM_MESA_HEADERS=YES
 AC_MSG_RESULT([yes])
+elif test $_os = WINNT; then
+# Experimental: try to use OpenGL on Windows
+ENABLE_OPENGL=TRUE
+# We need the internal "Mesa" headers.
+SYSTEM_MESA_HEADERS=NO
+BUILD_TYPE="$BUILD_TYPE MESA"
+AC_MSG_RESULT([yes])
 else
-if test "x$enable_opengl" != "xno"; then
-if test "$_os" != "WINNT"; then
-save_LDFLAGS=$LDFLAGS
-L

Re: Need confirmation about non-clearing of Character Styles

[Caolán McNamara]

On Thu, 2013-01-10 at 10:55 +0100, Fernand Vanrie wrote:
> Sinds all or editors use LO 3.6.2 (before OO3.3)
> 
> We have complains about the fact that parts of the text, who are
> formated with a Character Style, can not been "cleared" to
> no-formating,
> not by "Clear Direct Formating (cntrl+M)"
> 
> There is a dirty work-around by applying the "Default" character style
> 
> Paragraph Styles can been cleared
> Is this intentional behavior or a regression open for a issue ?

My understanding is
a) that its intentional, see
http://lists.freedesktop.org/archives/ooo-build/2010-February/000540.html
and the commit
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e690e0909459d46c53d17e7939891abea11e566
b) that "paragraph styles" are not cleared, i.e. the text should remain
using the original paragraph and character styles, but any additional
properties applied on top of that is reset to the underlying paragraph
and character styles properties.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: FYI: Make for faster windows build

[Lubos Lunak]

On Thursday 10 of January 2013, Michael Meeks wrote:
> On Wed, 2013-01-09 at 20:01 +0100, Lubos Lunak wrote:
> > Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> > put it there first, but still nice.
>
>   Nice work ! :-)
>
>   I'd love to see a configure option: --with-custom-gnumake that does the
> git clone, pre-builds, and uses our own gnumake (with the speedups).

 If I'm not mistaken, we need our custom make on Windows anyway, since LO 
build fails with the cygwin one for some reason (may or may not be our fault, 
I don't know). Moreover, this is most probably not going to work anyway, 
since it's the developer who runs the make, not the buildsystem (eventually, 
after we get rid of dmake). And Makefile.top has shown that make forwarding 
does not quite work as it should.

> Did you have any joy getting the fixes up-stream to gnumake ? ;-)

 I have not tried, the commands are rather LO-specific in some cases, so we 
need a patch anyway. I also consider it to be a bit of an ugly hack.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: FYI: Make for faster windows build

[Lubos Lunak]

On Thursday 10 of January 2013, Noel Grandin wrote:
> I think the WINDOWS32 #define is for building a "native" windows binary.
> (There is also stuff in there for building under AmigaOS and DOS, the
> gnumake code is pretty grotty)
>
> The cywin stuff is probably using a #ifdef CYGWIN.

 I don't see anything cygwin-specific there, except for handling the cygwin 
shell. And I expect the WINDOWS32 code should work just fine for cygwin make 
as well.

> You can't use the Win32 API as-is under cygwin, because you need to call
> cygpath() on the path argument first to convert from the cygwin
> filesystem structure to the Win32 representation.
> i.e. from "/cygdrive/C/libo" to "C:\libo"

 I have not done this, apparently make always gets windows paths when building 
LO, or does somebody have a problem with this (builtins have "(Built-in)" 
prefix when doing verbose make)?

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: WITH_MOZAB4WIN needing msvc?80.dll

[Michael Stahl]

On 10/01/13 14:01, Lubos Lunak wrote:
> 
>  Hello,
> 
>  as far as I understand it, the current problem with 
> W2008R2_20-With-Symbol-Bytemark-Hosting [*] , is caused by needing 
> specifically *80 msvc dlls for WITH_MOZAB4WIN (grep under scp2 for the 
> only 'msvcp' there). Does somebody have any idea why it's specifically this 
> version and if it's really needed this way? It dates back to 2009, so repo 
> history is as usually useless.

AFAIK the Mozilla stuff (moz/) does not build with MSVC 2008, only with
MSVC2005; that's why it has the unique distinction of allowing a binary
zip file containing all mozilla libraries to be used instead of building
it (--disable-build-mozilla); actually i've never built moz on windows
so i don't even know what you would need.

since it's built with MSVC 2005 and every release of MSVC brings a new
incompatible version of msvcrt libraries, the installer wants to bundles
these ones if you don't disable mozilla completely:

> [*]
> ERROR: The following files could not be found: 
> ERROR: File not found: Microsoft.VC80.CRT.manifest
> ERROR: File not found: msvcp80.dll
> ERROR: File not found: msvcr80.dll


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Fix some errors and remove duplicate code on Presenter

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1474

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1474
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Icd6f71ce2daa896494c8efe76779d49e16c547bf
Gerrit-PatchSet: 3
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Faisal al-otaibi 
Gerrit-Reviewer: Caolán McNamara 
Gerrit-Reviewer: Faisal al-otaibi 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] fdo#57422 - presenter console RTL support needs completion

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1284

Approvals:
  Faisal al-otaibi: Looks good to me, but someone else must approve
  Caolán McNamara: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1284
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I812e011b4e0aaeeb7ec6114a655240effc8c606a
Gerrit-PatchSet: 4
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Abdulelah Alarifi 
Gerrit-Reviewer: Abdulelah Alarifi 
Gerrit-Reviewer: Caolán McNamara 
Gerrit-Reviewer: Faisal al-otaibi 
Gerrit-Reviewer: Kohei Yoshida 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: sdext/source

[Libreoffice Gerrit user]

 sdext/source/presenter/PresenterToolBar.cxx |  162 +++-
 1 file changed, 41 insertions(+), 121 deletions(-)

New commits:
commit b0a827aa839afefd580c438ea72a7e5ca0b88aea
Author: Faisal M. Al-Otaibi 
Date:   Sun Dec 23 12:18:20 2012 +0300

Fix some errors and remove duplicate code on Presenter

Fix the toolbar text if the interface were RTL.
Remove duplicate code from PresenterToolBar.cxx

Change-Id: Icd6f71ce2daa896494c8efe76779d49e16c547bf
Reviewed-on: https://gerrit.libreoffice.org/1474
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/sdext/source/presenter/PresenterToolBar.cxx 
b/sdext/source/presenter/PresenterToolBar.cxx
index ac69c76..34dfb7e 100644
--- a/sdext/source/presenter/PresenterToolBar.cxx
+++ b/sdext/source/presenter/PresenterToolBar.cxx
@@ -1760,47 +1760,21 @@ void Text::Paint (
 aContext,
 rendering::TextDirection::WEAK_LEFT_TO_RIGHT,
 0));
-/** this responsible of the toolbar and the zoom
-that in the note mode.
-check whether RTL interface or not. */
-if(!Application::GetSettings().GetLayoutRTL()){
-geometry::RealRectangle2D aBox (xLayout->queryTextBounds());
-const double nTextWidth = aBox.X2 - aBox.X1;
-const double nY = rBoundingBox.Y + rBoundingBox.Height - aBox.Y2;
-const double nX = rBoundingBox.X + (rBoundingBox.Width - nTextWidth)/2;
-
-rendering::RenderState aRenderState(
-geometry::AffineMatrix2D(1,0,nX, 0,1,nY),
-NULL,
-Sequence(4),
-rendering::CompositeOperation::SOURCE);
-PresenterCanvasHelper::SetDeviceColor(aRenderState, mpFont->mnColor);
-rxCanvas->drawText(
-aContext,
-mpFont->mxFont,
-rViewState,
-aRenderState,
-rendering::TextDirection::WEAK_LEFT_TO_RIGHT);
-}
-else {
-geometry::RealRectangle2D aBox (xLayout->queryTextBounds());
-const double nTextWidth = aBox.X2 - aBox.X1;
-const double nY = rBoundingBox.Y + rBoundingBox.Height - aBox.Y2;
-const double nX = rBoundingBox.X + (rBoundingBox.Width + nTextWidth)/2;
-
-rendering::RenderState aRenderState(
-geometry::AffineMatrix2D(1,0,nX, 0,1,nY),
-NULL,
-Sequence(4),
-rendering::CompositeOperation::SOURCE);
-PresenterCanvasHelper::SetDeviceColor(aRenderState, mpFont->mnColor);
-rxCanvas->drawText(
-aContext,
-mpFont->mxFont,
-rViewState,
-aRenderState,
-rendering::TextDirection::WEAK_RIGHT_TO_LEFT);
-}
+geometry::RealRectangle2D aBox (xLayout->queryTextBounds());
+const double nTextWidth = aBox.X2 - aBox.X1;
+const double nY = rBoundingBox.Y + rBoundingBox.Height - aBox.Y2;
+const double nX = rBoundingBox.X + (rBoundingBox.Width - nTextWidth)/2;
+
+rendering::RenderState aRenderState(
+geometry::AffineMatrix2D(1,0,nX, 0,1,nY),
+NULL,
+Sequence(4),
+rendering::CompositeOperation::SOURCE);
+PresenterCanvasHelper::SetDeviceColor(aRenderState, mpFont->mnColor);
+rxCanvas->drawTextLayout(
+xLayout,
+rViewState,
+aRenderState);
 }
 
 geometry::RealRectangle2D Text::GetBoundingBox (const 
Reference& rxCanvas)
@@ -1811,25 +1785,13 @@ geometry::RealRectangle2D Text::GetBoundingBox (const 
ReferencePrepareFont(rxCanvas);
 if (mpFont->mxFont.is())
 {
-/// check whether RTL interface or not
-if(!Application::GetSettings().GetLayoutRTL()){
-rendering::StringContext aContext (msText, 0, 
msText.getLength());
-Reference xLayout (
-mpFont->mxFont->createTextLayout(
-aContext,
-rendering::TextDirection::WEAK_LEFT_TO_RIGHT,
-0));
-return xLayout->queryTextBounds();
-}
-else {
-rendering::StringContext aContext (msText, 0, 
msText.getLength());
-Reference xLayout (
-mpFont->mxFont->createTextLayout(
-aContext,
-rendering::TextDirection::WEAK_RIGHT_TO_LEFT,
-0));
-return xLayout->queryTextBounds();
-}
+rendering::StringContext aContext (msText, 0, msText.getLength());
+Reference xLayout (
+mpFont->mxFont->createTextLayout(
+aContext,
+rendering::TextDirection::WEAK_LEFT_TO_RIGHT,
+0));
+return xLayout->queryTextBounds();
 }
 }
 return geometry::RealRectangle2D(0,0,0,0);
@@ -1851,71 +1813,29 @@ OUString TimeFormatter::FormatTime (const oslDateTime& 
rTime)
 const sal_Int32 nHours (sal::static_

[Libreoffice-commits] .: sdext/source

[Libreoffice Gerrit user]

 sdext/source/presenter/PresenterSlideSorter.cxx |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

New commits:
commit eb0d07d3f2937315700dabf72d366f5ef4d4200d
Author: Abdulelah Alarifi 
Date:   Wed Dec 12 13:26:55 2012 +0300

fdo#57422 - presenter console RTL support needs completion

This patch will fix the text direction of the text that
appears when the mouse come over the slide in
Slide sorter view.

Change-Id: I2d3c5563b22dcd40ae4f70ed0ed06ad17f6c4132
Change-Id: I812e011b4e0aaeeb7ec6114a655240effc8c606a
Reviewed-on: https://gerrit.libreoffice.org/1284
Reviewed-by: Faisal al-otaibi 
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/sdext/source/presenter/PresenterSlideSorter.cxx 
b/sdext/source/presenter/PresenterSlideSorter.cxx
index eb0ce72..4148152 100644
--- a/sdext/source/presenter/PresenterSlideSorter.cxx
+++ b/sdext/source/presenter/PresenterSlideSorter.cxx
@@ -1583,12 +1583,10 @@ Reference 
PresenterSlideSorter::MouseOverManager::CreateBitm
 rendering::CompositeOperation::SOURCE);
 PresenterCanvasHelper::SetDeviceColor(aRenderState, mpFont->mnColor);
 
-xBitmapCanvas->drawText(
-aContext,
-mpFont->mxFont,
+xBitmapCanvas->drawTextLayout (
+xLayout,
 aViewState,
-aRenderState,
-rendering::TextDirection::WEAK_LEFT_TO_RIGHT);
+aRenderState);
 }
 
 return xBitmap;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: [libreoffice-l10n] Translation of the names of the keys on Windows

[Martin Srebotnjak]

Hi,

here is the Slovenian replacement table, please add it to the code:

static const struct KeysNameReplacement aImplReplacements_Slovenian[] =
{
 { KEY_ESC, "Ubežnica" },
 { KEY_BACK, "Vračalka" },
 { KEY_ENTER, "Vnašalka" },
 { KEY_SPACEBAR, "Preslednica" },
 { KEY_HOME, "Začetek" },
 { KEY_UP, "Navzgor" },
 { KEY_PAGEUP, "Prejšnja stran" },
 { KEY_LEFT, "Levo" },
 { KEY_RIGHT, "Desno" },
 { KEY_END, "Konec" },
 { KEY_DOWN, "Navzdol" },
 { KEY_PAGEDOWN, "Naslednja stran" },
 { KEY_INSERT, "Vrivalka" },
 { KEY_DELETE, "Brisalka" },
 { KEY_CONTROL, "Krmilka" },
 { KEY_SHIFT, "Dvigalka" },
 { KEY_ALT, "Izmenjalka" },
};

Please also add the following line to the aKeyboards[]:
{ "sl", aImplReplacements_Slovenian,
SAL_N_ELEMENTS(aImplReplacements_Slovenian) },

Please notify when this is in, so I can check that special characters look ok.

Thanks, m.

2013/1/8 Jesús Corrius :
> Hi all,
>
> Since today it's possible to provide custom translations of the names of
> the keys on Windows. This is useful because Windows gets the name of the
> key from the keyboard layout and, in some cases, they don't match properly.
>
> For example, Catalan users don't have a proper keyboard layout (well, they
> do have one but it's just an alias for the Spanish keyboard) so if a user
> uses the Spanish or French keyboard, the name of the keys in the UI will be
> in Spanish or French, but never in Catalan. I am sure other languages have
> this problem too.
>
> So it's now possible to provide custom names for keys for Windows using the
> same way we do for Linux. The file to modify is the following one and the
> process is exactly the same:
>
> http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/window/keynames.cxx
>
> If you want to implement this, but you are not a developer, just send me
> the name of the keys with its translation and I will apply the changes
> myself.
>
> Thanks and Happy 2013 to everybody!
>
> --
> Jesús Corrius 
>
> --
> Unsubscribe instructions: E-mail to l10n+h...@global.libreoffice.org
> Problems? 
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be deleted
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

WITH_MOZAB4WIN needing msvc?80.dll

[Lubos Lunak]

 Hello,

 as far as I understand it, the current problem with 
W2008R2_20-With-Symbol-Bytemark-Hosting [*] , is caused by needing 
specifically *80 msvc dlls for WITH_MOZAB4WIN (grep under scp2 for the 
only 'msvcp' there). Does somebody have any idea why it's specifically this 
version and if it's really needed this way? It dates back to 2009, so repo 
history is as usually useless.

[*]
ERROR: The following files could not be found: 
ERROR: File not found: Microsoft.VC80.CRT.manifest
ERROR: File not found: msvcp80.dll
ERROR: File not found: msvcr80.dll

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: slideshow/Library_OGLTrans.mk slideshow/source

[Libreoffice Gerrit user]

 slideshow/Library_OGLTrans.mk |2 
 slideshow/source/engine/OGLTrans/win/OGLTrans_Shaders.cxx |  142 --
 2 files changed, 1 insertion(+), 143 deletions(-)

New commits:
commit 6312695ad694598951f2cdd4ac26c53457fedb79
Author: Tor Lillqvist 
Date:   Thu Jan 10 14:55:33 2013 +0200

The "unx" and "win" OGLTrans_Shaders.cxx files were effectively identical

Just some OSL_TRACE/SAL_INFO changes in the "unx" one. And it isn't
like the "win" one would actually compile for Windows as is anyway, as
it unconditionally uses glX stuff. So certainly it is better to have
just one copy, and if we want to make the OpenGL transitions build on
Windows then add ifdefs for Windows to it.

Change-Id: If6887e24a0fc03c7e0e77f003d08feb51c264f30

diff --git a/slideshow/Library_OGLTrans.mk b/slideshow/Library_OGLTrans.mk
index bae4d99..44db60b 100644
--- a/slideshow/Library_OGLTrans.mk
+++ b/slideshow/Library_OGLTrans.mk
@@ -86,7 +86,7 @@ $(eval $(call gb_Library_use_system_win32_libs,OGLTrans,\
 ))
 
 $(eval $(call gb_Library_add_exception_objects,OGLTrans,\
-slideshow/source/engine/OGLTrans/win/OGLTrans_Shaders \
+slideshow/source/engine/OGLTrans/unx/OGLTrans_Shaders \
 slideshow/source/engine/OGLTrans/win/OGLTrans_TransitionerImpl \
 slideshow/source/engine/OGLTrans/win/OGLTrans_TransitionImpl \
 ))
diff --git a/slideshow/source/engine/OGLTrans/win/OGLTrans_Shaders.cxx 
b/slideshow/source/engine/OGLTrans/win/OGLTrans_Shaders.cxx
deleted file mode 100644
index c1beae1..000
--- a/slideshow/source/engine/OGLTrans/win/OGLTrans_Shaders.cxx
+++ /dev/null
@@ -1,142 +0,0 @@
-/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
-/*
- *
- * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
- *
- * Copyright 2008 by Sun Microsystems, Inc.
- *
- * OpenOffice.org - a multi-platform office productivity suite
- *
- * This file is part of OpenOffice.org.
- *
- * OpenOffice.org is free software: you can redistribute it and/or modify
- * it under the terms of the GNU Lesser General Public License version 3
- * only, as published by the Free Software Foundation.
- *
- * OpenOffice.org is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Lesser General Public License version 3 for more details
- * (a copy is included in the LICENSE file that accompanied this code).
- *
- * You should have received a copy of the GNU Lesser General Public License
- * version 3 along with OpenOffice.org.  If not, see
- * 
- * for a copy of the LGPLv3 License.
- *
- /
-
-#include 
-
-#include "OGLTrans_Shaders.hxx"
-
-namespace unx
-{
-#include 
-#include 
-}
-
-bool OGLShaders::cbInitialized = false;
-
-#ifdef GL_VERSION_2_0
-
-PFNGLCREATESHADERPROC OGLShaders::glCreateShader = NULL;
-PFNGLSHADERSOURCEPROC OGLShaders::glShaderSource = NULL;
-PFNGLCOMPILESHADERPROC OGLShaders::glCompileShader = NULL;
-PFNGLGETSHADERIVPROC OGLShaders::glGetShaderiv = NULL;
-PFNGLGETSHADERINFOLOGPROC OGLShaders::glGetShaderInfoLog = NULL;
-PFNGLDELETESHADERPROC OGLShaders::glDeleteShader = NULL;
-PFNGLCREATEPROGRAMPROC OGLShaders::glCreateProgram = NULL;
-PFNGLATTACHSHADERPROC OGLShaders::glAttachShader = NULL;
-PFNGLLINKPROGRAMPROC OGLShaders::glLinkProgram = NULL;
-PFNGLGETPROGRAMIVPROC OGLShaders::glGetProgramiv = NULL;
-PFNGLGETPROGRAMINFOLOGPROC OGLShaders::glGetProgramInfoLog = NULL;
-PFNGLUSEPROGRAMPROC OGLShaders::glUseProgram = NULL;
-PFNGLDELETEPROGRAMPROC OGLShaders::glDeleteProgram = NULL;
-PFNGLGETUNIFORMLOCATIONPROC OGLShaders::glGetUniformLocation = NULL;
-PFNGLUNIFORM1IPROC OGLShaders::glUniform1i = NULL;
-PFNGLUNIFORM1FPROC OGLShaders::glUniform1f = NULL;
-#endif
-
-bool OGLShaders::Initialize()
-{
-#ifdef GL_VERSION_2_0
-if( !cbInitialized ) {
-glCreateShader = (PFNGLCREATESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glCreateShader" );
-glShaderSource = (PFNGLSHADERSOURCEPROC) unx::glXGetProcAddress( 
(unsigned char *) "glShaderSource" );
-glCompileShader = (PFNGLCOMPILESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glCompileShader" );
-glGetShaderiv = (PFNGLGETSHADERIVPROC) unx::glXGetProcAddress( 
(unsigned char *) "glGetShaderiv" );
-glGetShaderInfoLog = (PFNGLGETSHADERINFOLOGPROC) 
unx::glXGetProcAddress( (unsigned char *) "glGetShaderInfoLog" );
-glDeleteShader = (PFNGLDELETESHADERPROC) unx::glXGetProcAddress( 
(unsigned char *) "glDeleteShader" );
-glCreateProgram = (PFNGLCREATEPROGRAMPROC) unx::glXGetProcAddress( 
(unsigned char *) "glCreateProgram" );
-glAttachShader = (PFNGLATTACHSHADERPROC) unx::glXGetProcAddress( 
(unsig

[PUSHED] - fdo#46460 - Missing Circles and Ovals toolbar

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1456

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1456
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: Rob Snelders 
Gerrit-Reviewer: Caolán McNamara 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Change in core[libreoffice-4-0]: - fdo#46460 - Missing Circles and Ovals toolbar

[via Code Review]

Hi,

I have submitted a patch for review:

https://gerrit.libreoffice.org/1627

To pull it, you can do:

git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/27/1627/1

- fdo#46460 - Missing Circles and Ovals toolbar

Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Reviewed-on: https://gerrit.libreoffice.org/1456
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 
(cherry picked from commit dcd974c3ca70065ba1d984ad6bd5514848cd58a9)
---
M officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
1 file changed, 1 insertion(+), 1 deletion(-)



diff --git 
a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu 
b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
index b035510..42358d2d 100644
--- a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
+++ b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
@@ -252,7 +252,7 @@
 false
 
 
-true
+false
 
 
 

-- 
To view, visit https://gerrit.libreoffice.org/1627
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Gerrit-PatchSet: 1
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Caolán McNamara 
Gerrit-Reviewer: Rob Snelders 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: officecfg/registry

[Libreoffice Gerrit user]

 officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit dcd974c3ca70065ba1d984ad6bd5514848cd58a9
Author: Rob Snelders 
Date:   Thu Dec 20 21:40:22 2012 +0100

- fdo#46460 - Missing Circles and Ovals toolbar

Change-Id: I08f2cef9c16ac998663f634653dad37a201f50c5
Reviewed-on: https://gerrit.libreoffice.org/1456
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git 
a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu 
b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
index b035510..42358d2d 100644
--- a/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
+++ b/officecfg/registry/data/org/openoffice/Office/UI/DrawWindowState.xcu
@@ -252,7 +252,7 @@
 false
 
 
-true
+false
 
 
 
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PUSHED] Change in core[libreoffice-3-6]: Always default-select English dictionary

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1613

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved
  Eike Rathke: Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1613
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-3-6
Gerrit-Owner: Stephan Bergmann 
Gerrit-Reviewer: Caolán McNamara 
Gerrit-Reviewer: Eike Rathke 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Change in core[libreoffice-4-0]: Always default-select English dictionary

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1614

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved
  Eike Rathke: Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1614
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Stephan Bergmann 
Gerrit-Reviewer: Caolán McNamara 
Gerrit-Reviewer: Eike Rathke 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-3-6' - setup_native/source

[Libreoffice Gerrit user]

 setup_native/source/packinfo/spellchecker_selection.pl |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

New commits:
commit 86ca8cfe7ff5bfb889f3d65b1647839965fc88a7
Author: Stephan Bergmann 
Date:   Wed Jan 9 15:09:58 2013 +0100

Always default-select English dictionary

It was discovered that on a Russian Windows, by default only Russian and
German dictionaries would be installed, but no English dictionary.  This is
because since e2fac98819c00b4fb50f9de9d0f32d20092f3191 "fdo#53009: For msi
installer, only default-select a subset of dictionaries" only those 
dictionaries
mentioned in setup_native/source/packinfo/spellchecker_selection.txt were
default-selected, but it apparently was a misunderstanding that
spellcheker_selection.txt for many locales does not list "en" even though an
English dictionary should always be default-installed.

Quoting Andras Timar :  "AFAIK en-US localization with 
English
dictionaries is always installed in all 3 supported platforms by default.  
On
Windows default install should always select en-US and English 
dictionaries.  If
it does not do so under certain circumstances, then it is a bug in my 
opinion.
We removed en-US entry from the spellchecker selection file for this very
reason.  It would have only bloated Mac and Linux langpacks."

So this fix simply makes sure that "en" is included in every line of the
generated spellchecker_selection.hxx that is used by
setup_native/source/win32/customactions/sellang/sellang.cxx to determine 
which
dictionaries to select by default.

Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
(cherry picked from commit d8385c2cfc63b25414f37699faf0143ee9f5ded9)
Reviewed-on: https://gerrit.libreoffice.org/1613
Reviewed-by: Eike Rathke 
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/setup_native/source/packinfo/spellchecker_selection.pl 
b/setup_native/source/packinfo/spellchecker_selection.pl
index b30a843..87f7cc2 100644
--- a/setup_native/source/packinfo/spellchecker_selection.pl
+++ b/setup_native/source/packinfo/spellchecker_selection.pl
@@ -27,8 +27,9 @@ while (<>) {
 @{$map{$lang}} = ();
 } else {
 @{$map{$lang}} = split(/,/, $dicts);
-$max = max($max, scalar(@{$map{$lang}}));
 }
+push(@{$map{$lang}}, ('en')) unless grep($_ eq 'en', @{$map{$lang}});
+$max = max($max, scalar(@{$map{$lang}}));
 }
 
 ++$max;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - setup_native/source

[Libreoffice Gerrit user]

 setup_native/source/packinfo/spellchecker_selection.pl |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

New commits:
commit 9299707ce09077f10c49ec836e26f6197ed20a1a
Author: Stephan Bergmann 
Date:   Wed Jan 9 15:09:58 2013 +0100

Always default-select English dictionary

It was discovered that on a Russian Windows, by default only Russian and
German dictionaries would be installed, but no English dictionary.  This is
because since e2fac98819c00b4fb50f9de9d0f32d20092f3191 "fdo#53009: For msi
installer, only default-select a subset of dictionaries" only those 
dictionaries
mentioned in setup_native/source/packinfo/spellchecker_selection.txt were
default-selected, but it apparently was a misunderstanding that
spellcheker_selection.txt for many locales does not list "en" even though an
English dictionary should always be default-installed.

Quoting Andras Timar :  "AFAIK en-US localization with 
English
dictionaries is always installed in all 3 supported platforms by default.  
On
Windows default install should always select en-US and English 
dictionaries.  If
it does not do so under certain circumstances, then it is a bug in my 
opinion.
We removed en-US entry from the spellchecker selection file for this very
reason.  It would have only bloated Mac and Linux langpacks."

So this fix simply makes sure that "en" is included in every line of the
generated spellchecker_selection.hxx that is used by
setup_native/source/win32/customactions/sellang/sellang.cxx to determine 
which
dictionaries to select by default.

Change-Id: I3db68585dc6269a7db2f6cbf6b79796dc09d05e8
(cherry picked from commit d8385c2cfc63b25414f37699faf0143ee9f5ded9)
Reviewed-on: https://gerrit.libreoffice.org/1614
Reviewed-by: Eike Rathke 
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/setup_native/source/packinfo/spellchecker_selection.pl 
b/setup_native/source/packinfo/spellchecker_selection.pl
index b30a843..87f7cc2 100644
--- a/setup_native/source/packinfo/spellchecker_selection.pl
+++ b/setup_native/source/packinfo/spellchecker_selection.pl
@@ -27,8 +27,9 @@ while (<>) {
 @{$map{$lang}} = ();
 } else {
 @{$map{$lang}} = split(/,/, $dicts);
-$max = max($max, scalar(@{$map{$lang}}));
 }
+push(@{$map{$lang}}, ('en')) unless grep($_ eq 'en', @{$map{$lang}});
+$max = max($max, scalar(@{$map{$lang}}));
 }
 
 ++$max;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PUSHED] Added Table Properties Widget

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1511

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1511
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I019b99e6194458b8b311b0cc3f2e231ef898ece0
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: master
Gerrit-Owner: gokul s 
Gerrit-Reviewer: Caolán McNamara 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Change in core[libreoffice-4-0]: fdo#58909: Missing BAK_EXTENSIONS bootstrap variable

[via Code Review]

Hi,

Thank you for your patch!  It has been merged to LibreOffice.

If you are interested in details, please visit

https://gerrit.libreoffice.org/1626

Approvals:
  Caolán McNamara: Verified; Looks good to me, approved


-- 
To view, visit https://gerrit.libreoffice.org/1626
To unsubscribe, visit https://gerrit.libreoffice.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ie73ce50b6c26bbee6f3b7230a4d163715180ef52
Gerrit-PatchSet: 2
Gerrit-Project: core
Gerrit-Branch: libreoffice-4-0
Gerrit-Owner: Stephan Bergmann 
Gerrit-Reviewer: Caolán McNamara 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: Branch 'libreoffice-4-0' - desktop/source scp2/source

[Libreoffice Gerrit user]

 desktop/source/deployment/manager/dp_manager.cxx |2 +-
 scp2/source/ooo/common_brand.scp |8 
 scp2/source/ooo/profileitem_ooo.scp  |9 +
 3 files changed, 18 insertions(+), 1 deletion(-)

New commits:
commit 147ce2ebeeac686d0a8e9e3d6d804aeba0fcbcdc
Author: Stephan Bergmann 
Date:   Thu Jan 10 11:54:28 2013 +0100

fdo#58909: Missing BAK_EXTENSIONS bootstrap variable

daeed90f4586eb9533041fb89bee163a5193596c "re-base on ALv2 code" had 
incorporated
from  "imported
patch extensions_i117681.patch" the parts using BAK_EXTENSIONS in
desktop/source/deployment/manager/, but not the parts setting 
BAK_EXTENSIONS in
scp2/source/ooo/.

Also, setting the stamp for "bak" in PackageManagerImpl::create needed to be
adapted to bee742eb7a0d5dfe23e61d9ee49a29286de90256 "Fix sense of r/o 
detection
code, and clean up" and 61eeb689d7605a23c3e71c652b57ee65cf5b28dc "fix 
smoketest
- need to check read-only-ness of non-existent paths."

(cherry picked from commit 8dd405d32cb331818dc8f9bd1af3c5a074100f0f)
Conflicts:
desktop/source/deployment/manager/dp_manager.cxx

Change-Id: Ie73ce50b6c26bbee6f3b7230a4d163715180ef52
Reviewed-on: https://gerrit.libreoffice.org/1626
Reviewed-by: Caolán McNamara 
Tested-by: Caolán McNamara 

diff --git a/desktop/source/deployment/manager/dp_manager.cxx 
b/desktop/source/deployment/manager/dp_manager.cxx
index ba67f9e..b9949df 100644
--- a/desktop/source/deployment/manager/dp_manager.cxx
+++ b/desktop/source/deployment/manager/dp_manager.cxx
@@ -398,7 +398,7 @@ Reference 
PackageManagerImpl::create(
 "vnd.sun.star.expand:$BAK_EXTENSIONS");
 that->m_registryCache = OUSTR(
 "vnd.sun.star.expand:$BAK_EXTENSIONS/registry");
-stamp = OUSTR("vnd.sun.star.expand:$BAK_EXTENSIONS/stamp.sys");
+stamp = OUSTR("$BAK_EXTENSIONS");
 }
 
 else if (! context.matchAsciiL(
diff --git a/scp2/source/ooo/common_brand.scp b/scp2/source/ooo/common_brand.scp
index 7ba7e76..0c21df8 100644
--- a/scp2/source/ooo/common_brand.scp
+++ b/scp2/source/ooo/common_brand.scp
@@ -1198,6 +1198,14 @@ ProfileItem 
gid_Brand_Profileitem_Fundamental_Uno_Tmp_Extensions
 Value = "${$ORIGIN/" PROFILENAME(uno) ":TMP_EXTENSIONS}";
 End
 
+ProfileItem gid_Brand_Profileitem_Fundamental_Uno_Bak_Extensions
+ModuleID = gid_Module_Root_Brand;
+ProfileID = gid_Brand_Profile_Fundamental_Ini;
+Section = "Bootstrap";
+Key = "BAK_EXTENSIONS";
+Value = "${$ORIGIN/" PROFILENAME(uno) ":TMP_EXTENSIONS}";
+End
+
 ProfileItem gid_Brand_Profileitem_Fundamental_Ure_More_Types
 ModuleID = gid_Module_Root_Brand;
 ProfileID = gid_Brand_Profile_Fundamental_Ini;
diff --git a/scp2/source/ooo/profileitem_ooo.scp 
b/scp2/source/ooo/profileitem_ooo.scp
index 69ca5c6..abe5df4 100644
--- a/scp2/source/ooo/profileitem_ooo.scp
+++ b/scp2/source/ooo/profileitem_ooo.scp
@@ -166,6 +166,15 @@ ProfileItem gid_Profileitem_Uno_Uno_Bundled_Tmp_Extensions
 Value = "${$BRAND_BASE_DIR/program/" PROFILENAME(bootstrap) 
":UserInstallation}/user/extensions/tmp";
 End
 
+ProfileItem gid_Profileitem_Uno_Uno_Bundled_Bak_Extensions
+ProfileID = gid_Profile_Uno_Ini;
+ModuleID = gid_Module_Root;
+Section = "Bootstrap";
+Order = 1;
+Key = "BAK_EXTENSIONS";
+Value = "${$BRAND_BASE_DIR/program/" PROFILENAME(bootstrap) 
":UserInstallation}/user/extensions/bak";
+End
+
 ProfileItem gid_Profileitem_Uno_Uno_User_Packages_Cache
 ProfileID = gid_Profile_Uno_Ini;
 ModuleID = gid_Module_Root;
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits