date:20120526

 cui/source/options/treeopt.hrc |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

New commits:
commit eb0a1da770161a7d680061eaa3d79f8ea8eef6ac
Author: David Tardon dtar...@redhat.com
Date:   Fri May 25 10:50:54 2012 +0200

resize options dialog to fit to increased tab height

Change-Id: I6255eba78aa4e012e6d29b7faed5f3bbc5302d25

diff --git a/cui/source/options/treeopt.hrc b/cui/source/options/treeopt.hrc
index 46572f4..fc4e55f 100644
--- a/cui/source/options/treeopt.hrc
+++ b/cui/source/options/treeopt.hrc
@@ -25,6 +25,8 @@
  *
  /
 
+#include sfx2/tabpage.hrc
+
 #include svtools/controldims.hrc
 
 #define PB_OK   1
@@ -55,8 +57,8 @@
 
 // metrics
 
-#define WIDTH_PAGEFRAME 263
-#define HEIGHT_PAGEFRAME191
+#define WIDTH_PAGEFRAME (TP_WIDTH + 3)
+#define HEIGHT_PAGEFRAME(TP_HEIGHT + 6)
 
 #define COL_1   (RSC_SP_DLG_INNERBORDER_LEFT)
 #define COL_2   (COL_1+0)
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: Branch 'feature/gbuild_merge' - testtools/CustomTarget_bridgetest.mk

2012-05-26 Thread David Ostrovsky

 testtools/CustomTarget_bridgetest.mk |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

New commits:
commit b17a8fb79f44327fbb30be8301029c15a6962aa4
Author: David Ostrovsky david.ostrov...@gmx.de
Date:   Sat May 26 09:50:26 2012 +0200

fixed build error with --without-java parameter

Change-Id: Id383a2cd8bdaa14e6d991ee971a6b26230922b10

diff --git a/testtools/CustomTarget_bridgetest.mk 
b/testtools/CustomTarget_bridgetest.mk
index 4452c8e..a4237d3 100644
--- a/testtools/CustomTarget_bridgetest.mk
+++ b/testtools/CustomTarget_bridgetest.mk
@@ -37,11 +37,16 @@ BATCH_SUFFIX :=
 GIVE_EXEC_RIGHTS=chmod +x
 endif
 
-$(call gb_CustomTarget_get_target,testtools/bridgetest) : \
-   $(workdir_SERVER)/bridgetest_server$(BATCH_SUFFIX) \
+bridgetest_TARGET := $(workdir_SERVER)/bridgetest_server$(BATCH_SUFFIX) \
+   $(workdir_SERVER)/bridgetest_client$(BATCH_SUFFIX)
+
+ifneq ($(SOLAR_JAVA),)
+bridgetest_TARGET := $(bridgetest_TARGET) \
$(workdir_SERVER)/bridgetest_javaserver$(BATCH_SUFFIX) \
-   $(workdir_SERVER)/bridgetest_inprocess_java(BATCH_SUFFIX) \
-   $(workdir_SERVER)/bridgetest_client$(BATCH_SUFFIX) \
+   $(workdir_SERVER)/bridgetest_inprocess_java(BATCH_SUFFIX)
+endif
+
+$(call gb_CustomTarget_get_target,testtools/bridgetest) : $(bridgetest_TARGET)
 
 # which other prerequisites do we need here?
 $(workdir_SERVER)/bridgetest_server$(BATCH_SUFFIX) : \
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: build time optimization


On Thu, 2012-05-24 at 09:23 +0200, David Ostrovsky wrote:
 I'm trying to accelerate LO (developer) build on linux_x86-64 system.

:-) one systematic approach to this might be to try to unwind which
complex[1] headers are most included and see if, in fact, with some more
strategic forward definitions we can avoid that.

For the gnumake world the workdir/*/*.d files have all those deps that
can easily be sedded / sorted / uniq -c'd / sorted etc. into a list of
the top includes.

That of course has the benefit of creating a long-term speedup for all
of us that won't involve custom tweaking the system. IIRC there was some
easy hack related to that too.

ATB,

Michael.

[1] - where complex is presumably defined by 'slow to parse' (perhaps we
could time a compile of include that-header.hxx in a .cxx)
-- 
michael.me...@suse.com  , Pseudo Engineer, itinerant idiot

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

Re: ODS import with merged cells

Hi Daniel,

On Sat, 2012-05-26 at 03:36 -0500, Daniel Bankston wrote:
 I pushed my changes to ScXMLTableRowCellContext::DoMerge() where I have 
 removed the ScDocFunc layer and simplified the whole method in general.

Oh - hmm. So - for the collaborative editing work we need a clean
interface between user input (controller) and the model. So far we're
using the ScDocFunc for that, and at least we need to intercept all UI
editing at some suitably granular level through there.

Of course for file-filters we don't want people to go through there so
- that's fine ;-) but it'd be good not to start a get rid of ScDocFunc
jihad in general [IMHO etc.].

 Also, ScXMLTableRowCellContext::IsMerged() and the unmerge portion of 
 ScXMLTableRowCellContext::DoMerge() that existed before this latest 
 commit seem to have no purpose during import.

:-)

 After these changes, I can still successfully compile and pass sc unit 
 tests.  Also, when I manually run calc and open a spreadsheet with 
 merged cells, I see that the file is imported correctly.

Sounds lovely to me.

All the best,

Michael.

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

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

[PATCH] Unify OUTPATH values

2012-05-26 Thread Francois Tigeot

Hi,

I don't think there's any good reason to have wildly different OUTPATH names
for each specific platform variant.

The various names also lead to unnecessary work when packaging, just to
correctly handle LD_LIBRARY_PATH.

The attached patch reduces OUTPATH to two possible values: unx and wnt. Since
it is potentially intrusive, I prefer to show it here for review instead of
committing it directly.

-- 
Francois Tigeot
From d726ef2fca9430395010f0e6d34469f34583c78a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Tigeot?= ftig...@wolfpond.org
Date: Sat, 26 May 2012 12:48:42 +0200
Subject: [PATCH] Unify OUTPATH values

* unx for Unix platforms, wnt for Windows ones

* this move reduces path lengths and simplifies packaging

Change-Id: I480a729c5bd25518dab09d89d52c104054d461c0
---
 configure.in |   48 ++--
 1 file changed, 14 insertions(+), 34 deletions(-)

diff --git a/configure.in b/configure.in
index 2382c83..ffa75d5 100644
--- a/configure.in
+++ b/configure.in
@@ -2994,7 +2994,7 @@ aix*)
 OS=AIX
 RTL_OS=AIX
 RTL_ARCH=PowerPC
-OUTPATH=unxaigppc
+OUTPATH=unx
 P_SEP=:
 SOLARLIB=-L../lib -L$SRC_ROOT/solenv/$OUTPATH/lib
 SOLARLIB=$SOLARLIB -L${SOLARVER}/${OUTPATH}${PROEXT}/lib
@@ -3008,6 +3008,7 @@ cygwin*)
 OS=WNT
 RTL_OS=Windows
 P_SEP=;
+OUTPATH=wnt
 
 case $host_cpu in
 i*86|x86_64)
@@ -3016,12 +3017,10 @@ cygwin*)
 CPUNAME=X86_64
 RTL_ARCH=X86_64
 LIB64=lib/x64
-OUTPATH=wntmscx$COMEX
 else
 CPU=I
 CPUNAME=INTEL
 RTL_ARCH=x86
-OUTPATH=wntmsci$COMEX
 fi
 ;;
 *)
@@ -3048,20 +3047,20 @@ darwin*)
 CPUNAME=ARM
 RTL_ARCH=ARM_EABI
 GUIBASE=cocoatouch
-OUTPATH=unxiosr
+OUTPATH=unx
 OS=IOS;
 ;;
 powerpc*)
 CPU=P
 CPUNAME=POWERPC
 RTL_ARCH=PowerPC
-OUTPATH=unxmacxp
+OUTPATH=unx
 ;;
 i*86|x86_64)
 CPU=I
 CPUNAME=INTEL
 RTL_ARCH=x86
-OUTPATH=unxmacxi
+OUTPATH=unx
 ;;
 *)
 AC_MSG_ERROR([Unsupported host_cpu $host_cpu for host_os $host_os])
@@ -3076,7 +3075,7 @@ dragonfly*)
 GUIBASE=unx
 OS=DRAGONFLY
 RTL_OS=DragonFly
-OUTPATH=unxdfly
+OUTPATH=unx
 P_SEP=:
 
 case $host_cpu in
@@ -3105,7 +3104,7 @@ freebsd*)
 GUIBASE=unx
 RTL_OS=FreeBSD
 OS=FREEBSD
-OUTPATH=unxfbsd
+OUTPATH=unx
 P_SEP=:
 
 case $host_cpu in
@@ -3113,7 +3112,6 @@ freebsd*)
 CPU=I
 CPUNAME=INTEL
 RTL_ARCH=x86
-OUTPATH=unxfbsdi
 ;;
 x86_64)
 CPU=X
@@ -3135,20 +3133,19 @@ kfreebsd*)
 GUIBASE=unx
 OS=LINUX
 RTL_OS=kFreeBSD
+OUTPATH=unx
 case $host_cpu in
 
 i*86)
 CPU=I
 CPUNAME=INTEL
 RTL_ARCH=x86
-OUTPATH=unxkfgi6
 ;;
 x86_64)
 CPU=X
 CPUNAME=X86_64
 RTL_ARCH=X86_64
 LIB64=lib64
-OUTPATH=unxkfgx6
 ;;
 *)
 AC_MSG_ERROR([Unsupported host_cpu $host_cpu for host_os $host_os])
@@ -3166,6 +3163,7 @@ linux-gnu*)
 OS=LINUX
 RTL_OS=Linux
 P_SEP=:
+OUTPATH=unx
 
 case $host_cpu in
 
@@ -3173,13 +3171,11 @@ linux-gnu*)
 CPU=L
 CPUNAME=AXP
 RTL_ARCH=ALPHA
-OUTPATH=unxlngaxp
 ;;
 arm*)
 CPU=R
 CPUNAME=ARM
 EPM_FLAGS=-a arm
-OUTPATH=unxlngr
 RTL_ARCH=ARM_EABI
 case $host_cpu in
 arm*-linux)
@@ -3192,92 +3188,78 @@ linux-gnu*)
 CPUNAME=HPPA
 RTL_ARCH=HPPA
 EPM_FLAGS=-a hppa
-OUTPATH=unxlnghppa
 ;;
 i*86)
 CPU=I
 CPUNAME=INTEL
 RTL_ARCH=x86
-OUTPATH=unxlngi6
 ;;
 ia64)
 CPU=A
 CPUNAME=IA64
 RTL_ARCH=IA64
-OUTPATH=unxlnga
 ;;
 mips)
 CPU=M
 CPUNAME=GODSON
 RTL_ARCH=MIPS_EB
 EPM_FLAGS=-a mips
-OUTPATH=unxlngmips
 ;;
 mips64)
 CPU=M
 CPUNAME=GODSON
 RTL_ARCH=MIPS_EB
 EPM_FLAGS=-a mips64
-OUTPATH=unxlngmips
 ;;
 mips64el)
 CPU=M
 CPUNAME=GODSON
 RTL_ARCH=MIPS_EL
 EPM_FLAGS=-a mips64el
-OUTPATH=unxlngmips
 ;;
 mipsel)
 CPU=M
 CPUNAME=GODSON
 RTL_ARCH=MIPS_EL
 EPM_FLAGS=-a mipsel
-OUTPATH=unxlngmips
 ;;
 m68k)
 CPU=6
 CPUNAME=M68K
 RTL_ARCH=M68K
-OUTPATH=unxlngm68k
 ;;
 powerpc)
 CPU=P
 CPUNAME=POWERPC
 RTL_ARCH=PowerPC
-OUTPATH=unxlngppc
 ;;
 powerpc64)
 CPU=P
 CPUNAME=POWERPC64
 RTL_ARCH=PowerPC_64
 LIB64=lib64
-OUTPATH=unxlngppc64
 ;;
 sparc)

Re: mentor gsoc

Hi Robert,

On Fri, 2012-05-25 at 19:42 -0400, Robert Sink wrote:
 I recently applied and accidently withdrew my request to be a mentor
 [was actually going to resubmit something more specific].

:-)

   I am an Android hobbyist with six HTC phones [G1, G2, Droid Eris,
 Evo 4G, and two Wildfire S [gsm/cdma]; all various adreno gpus] and
 two tablets [Nook Color and HP Touchpad].  I enjoy mostly rom cooking
 and perfecting, but I see a need for an open source office tool.  So,
 I'd like to pitch in some time.. call me a collaborator as I'm
 hesitant to think of myself in mentor terms.

Sounds good to me.

   I know xml, java and c++ and have the aforementioned testing
 platforms for Android if I may be of service.  Thank you for your
 time.

It'd be great to have you hacking on the project alongside the GSOC
student, that should present no problems I'm aware of - indeed, it might
encourage more open interactive development.

So - IIWY I'd just poke the existing developer  mentor for some code
pointers and get stuck in.

Great to have you around,

ATB,

Michael.

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

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

[Libreoffice] [GSoC 2012][svg export filter] Weekly Report #1

2012-05-26 Thread Marco Cecchetti

Hi everybody,
it follows my weekly report:

Report #1
-
In order to enable future support for slide transitions has been
needed to modify the part of the presentation engine handling
the slides navigation feature. A new structure for slide and
master page elements has been designed.

In order to simplify and speed up testing the new slide and master
page structures are created in JavaScript by transforming the
current exported elements. In case the new design will lead to
a good implementation these structures will be created directly in
C++ (except for the master page view group and its sub-elements
that are generated on-the-fly).

A MasterPageView class has been implemented in order to create
a master page view element and its sub-elements; it is also
responsible for updating the content of the included text fields.
A sub-element (both use or a clone) is created only if the
related exported visibility property, parsed by the MetaSlide
instance the master page view object belongs to, is set to true.
This strategy simplify visibility handling.

Modified Thumbnail class implementation, now the thumbnail element
structure in the index page is simplified. Modification to the
index mode implementation has been needed in order to get the index
mode working with the new slide and master page structure, moreover
Firefox performance in index mode has been improved.

Tested the new implementation on the following browsers:

- Firefox 3.6, 4, 10, latest, aurora;
- IE 9, 10;
- Chrome 10, latest;
- Opera 11.50, 11.62, Next;
- Safari 5.1.5
- Fennec, Opera Mobile.

The last two through emulators. All work correctly.

Add a lot of comments to the source code. Added documentation
comments to classes and methods.
---

You can read more details on my project log book:
https://docs.google.com/document/d/1GSLPSIWRGSDTSi69dT9Te8tRyTJcAekxT7scoCoGO2M/edit?pli=1#heading=h.zd4f29g9qeoc

You can download a sample presentation here:
https://docs.google.com/open?id=0BwS_9-CU4098UFhHSm1BYWE3Q0k
In order to download the zip file click on the Download item
under the File menu.

Indeed all new features are under the hood, for something more
exciting to watch you have to wait until the first slide
transitions will be available.

You can look at the source code in the feature branch:
feature/svg-export.

Cheers,
-- Marco

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Unify OUTPATH values

Hi Francois,

On Sat, 2012-05-26 at 12:59 +0200, Francois Tigeot wrote:
 I don't think there's any good reason to have wildly different OUTPATH names
 for each specific platform variant.

:-)

 The various names also lead to unnecessary work when packaging, just to
 correctly handle LD_LIBRARY_PATH.

Heh.

 The attached patch reduces OUTPATH to two possible values: unx and wnt. Since
 it is potentially intrusive, I prefer to show it here for review instead of
 committing it directly.

Just to check; I cross compile from unix-linux to unix-android, and
have to have both native and remote toolchains eg.

$ ls /opt/libreoffice/devel/soltools
adjustvisibility  checkdll  cpp  giparser  inc  javadep  ldump  mkdepend
prj  support  testhxx  unxandr.pro  unxlngi6.pro  util  winunistd

Would your change make that more difficult ? [ admittedly the names are
highly non-intuitive, and hard to write when explaining to others, and I
don't believe the parallel .pro / non-pro distinctions is necessary ;-)
]

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: [Libreoffice] [GSoC 2012][svg export filter] Weekly Report #1

2012-05-26 Thread Marco Cecchetti

On Sat, 26 May 2012 13:09:09 +0200, Marco Cecchetti mrcek...@gmail.com  
wrote:


skip


You can download a sample presentation here:
https://docs.google.com/open?id=0BwS_9-CU4098UFhHSm1BYWE3Q0k
In order to download the zip file click on the Download item
under the File menu.


Sorry, the right link is the following one:
https://docs.google.com/open?id=0BwS_9-CU4098bk5QMjNtS2IzZzQ


-- Marco



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Unify OUTPATH values

2012-05-26 Thread Francois Tigeot

Hey Michael,

On Sat, May 26, 2012 at 12:15:51PM +0100, Michael Meeks wrote:
 
 On Sat, 2012-05-26 at 12:59 +0200, Francois Tigeot wrote:
  The attached patch reduces OUTPATH to two possible values: unx and wnt. 
  Since
  it is potentially intrusive, I prefer to show it here for review instead of
  committing it directly.
 
   Just to check; I cross compile from unix-linux to unix-android, and
 have to have both native and remote toolchains eg.
 
 $ ls /opt/libreoffice/devel/soltools
 adjustvisibility  checkdll  cpp  giparser  inc  javadep  ldump  mkdepend
 prj  support  testhxx  unxandr.pro  unxlngi6.pro  util  winunistd
 
   Would your change make that more difficult ?

With the patch, there would only be one unx.pro directory.

I didn't think cross-compiling could be done this way; in my mind, separate
git clones were used for each destination platform.

 [ admittedly the names are
 highly non-intuitive, and hard to write when explaining to others, and I
 don't believe the parallel .pro / non-pro distinctions is necessary ;-)

The names are suspiciously close to 8.3 ms-dos names. Probably another dark
remnant from the past ;)

The .pro extension may not be present in all cases; iirc it disappears when
some debug options are enabled.

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

Re: feature/gbuild_merge needs testing

On Fri, May 25, 2012 at 02:20:42PM +0200, Noel Grandin wrote:
 Build error log attached for a cygwin build (i.e. on Windows).
 

 /cygdrive/c/LibreOffice/libo/connectivity/Library_postgresql-sdbc-impl.mk:49: 
 *** Cannot link against library/libraries openssl secur32 ldap. Libraries 
 must be registered in Repository.mk.  Stop.

Should be fixed now.

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

[Libreoffice-commits] .: Branch 'feature/gbuild_merge' - solenv/gbuild

 solenv/gbuild/platform/WNT_INTEL_MSC.mk |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 3ae36ad5b5b9e81a4ab208138e91ec463ec0c2a6
Author: David Tardon dtar...@redhat.com
Date:   Sat May 26 14:04:25 2012 +0200

register additional libs required by postgressql

Change-Id: I223122d9f99c8068af21c80f9b52642c762c79af

diff --git a/solenv/gbuild/platform/WNT_INTEL_MSC.mk 
b/solenv/gbuild/platform/WNT_INTEL_MSC.mk
index 0676ea7..fb833f7 100644
--- a/solenv/gbuild/platform/WNT_INTEL_MSC.mk
+++ b/solenv/gbuild/platform/WNT_INTEL_MSC.mk
@@ -396,6 +396,7 @@ gb_Library_PLAINLIBS_NONE += \
imm32\
kernel32 \
jawt \
+   ldap \
libcmt \
libcmtd \
mpr \
@@ -406,7 +407,9 @@ gb_Library_PLAINLIBS_NONE += \
$(gb_Library_win32_OLDNAMES) \
ole32 \
oleaut32 \
+   openssl \
propsys \
+   secur32 \
shell32 \
shlwapi \
urlmon \
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Re: feature/gbuild_merge needs testing

2012-05-26 Thread David Ostrovsky


On 25.05.2012 14:20, Noel Grandin wrote:

make[2]: *** No rule to make target 
`D:/workdir/wntmsci12.pro/CustomTarget/testtools/bridgetest/bridgetest_javaserver.bat',
 needed by `D:/workdir/wntmsci12.pro/CustomTarget/testtools/bridgetest.done'.  
Stop.

should be fixed now (with --without-java)

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

Re: [PATCH] Unify OUTPATH values


On Sat, 2012-05-26 at 13:47 +0200, Francois Tigeot wrote:
 I didn't think cross-compiling could be done this way; in my mind, separate
 git clones were used for each destination platform.

Right; but currently we build both the native platform tools necessary
for doing the cross-compiling, and also the target platform tools into
the same source tree :-) There are other ways to imagine doing it of
course, but - this one works as of now.

 The names are suspiciously close to 8.3 ms-dos names. Probably another dark
 remnant from the past ;)

:-)

So, sadly I don't think this flies as of now,

Regards,

Michael.

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

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

[PATCH] fix name in the package description (fr)

2012-05-26 Thread Olivier R.

Hi *,

A tiny fix in a description file:
http://nabble.documentfoundation.org/file/n3986158/0001-fix-name-in-the-package-description-fr.patch
0001-fix-name-in-the-package-description-fr.patch 

Olivier

--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-fix-name-in-the-package-description-fr-tp3986158.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: feature/gbuild_merge needs testing

Hi David,

On Fri, 2012-05-25 at 13:28 +0200, David Tardon wrote:
 There is experimental branch feature/tail_build that adds 19 more, but
 it requires a change to build.pl, so I do not intend to push it into 3.6.
 Of course, if people who actually know something about the build.pl
 script look at commit 726ac115a981567b3f41613d0e0163bd010e6b17 and tell
 me that I am not a total idiot, or even that it might work at the right
 phase of moon, I can be convinced otherwise :-)

I had the misfortune to hack on build.pl before :-) and your patch
looks reasonable to me. I'd love to have it in for 3.6 ... I didn't
checkout the branch and/or I couldn't make the make command that dumps
the deps work but I assume the parsing logic is fine. We may have some
explicit \r\n removal nonsense on windows (chomp has never worked well
for me there for some - prolly cygwin related reason) - but lets see.

-my $modcount = %modules;
 
 return %modules;

seems redundant in get_tail_build_modules.

 # insert dep. on tail_build, if necessary
 if (@tail_build_deps  !defined $$deps{$tail_build_prj}) {
 $$deps{$tail_build_prj} = 1;
 }

The !defined looks redundant until you read get_parent_deps which has a
count of the deps in there.

So - it all looks fine really :-) [ at least to me ]

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: ODS import with merged cells

2012-05-26 Thread Markus Mohrhard

Hey Daniel,

2012/5/26 Daniel Bankston daniel.dev.libreoff...@gmail.com:
 Hi, Kohei and Markus,

 I pushed my changes to ScXMLTableRowCellContext::DoMerge() where I have
 removed the ScDocFunc layer and simplified the whole method in general.

Great. I will have a look at it on Tuesday.


 As I mentioned to Kohei at some point, when I was originally removing the
 UNO calls from the code, I was trying not to question the logic too much and
 just focus on direct conversion to equivalent Sc calls.  I went back through
 the ScXMLTableRowCellContext merge methods closely following what occurs in
 the code and thinking about what is actually trying to be accomplished.

 It seems that the only thing that is actually needed here during import is a
 call to ScDocument::DoMerge().  As far as I could tell, everything else was
 unnecessary in the ScDocFunc layer.  Also,
 ScXMLTableRowCellContext::IsMerged() and the unmerge portion of
 ScXMLTableRowCellContext::DoMerge() that existed before this latest commit
 seem to have no purpose during import.  Whether a cell is merged or not is
 decided before ScXMLTableRowCellContext::DoMerge() is called (member
 bIsMerged), otherwise it wouldn't be called.  And unmerging a cell on import
 doesn't make sense, right?

I'm not 100% sure about that. If I recall correctly we need to unmerge
cells before we can merge bigger areas. But without having a closer
look at the code I can only speculate that it is for this.


 After these changes, I can still successfully compile and pass sc unit
 tests.  Also, when I manually run calc and open a spreadsheet with merged
 cells, I see that the file is imported correctly.

That our tests pass doe not mean much. It is always a good diea to
check if one of the featurres that you convert is covered by our
import tests. and even if it is it has often just some basic test
cases like in the merge case. In such cases it would be great if you
could add some more test cases especially for the corner cases you saw
in the code.


 Can you see anything that I might have missed or incorrectly removed?

No. From what you say it seems all reasonable.

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

Re: ODS import with merged cells

2012-05-26 Thread Markus Mohrhard

Hey Michael,

        Oh - hmm. So - for the collaborative editing work we need a clean
 interface between user input (controller) and the model. So far we're
 using the ScDocFunc for that, and at least we need to intercept all UI
 editing at some suitably granular level through there.

        Of course for file-filters we don't want people to go through there so
 - that's fine ;-) but it'd be good not to start a get rid of ScDocFunc
 jihad in general [IMHO etc.].

That is not planned. Only during import all the code in ScDocFunc does
not make much sense. We neither need to repaint areas nor do we need
undo/redo code.

We did not plan to replace ScDocFunc calls in any other place in calc.

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

fdo#45830 - Language/User Interface: current choice indicated as default

2012-05-26 Thread Rob Snelders


Hi All,

I saw this bug and I found where the change needs to be for this bug.
The problem is that the default-value for the locale setting is in the 
list the current setting, not the locale of the system. But can I solve 
this or should this be asked to the usability-mailinglist? And what is 
the emailaddress of that mailinglist?


--
Greetings,
Rob Snelders
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ODS import with merged cells


On Sat, 2012-05-26 at 17:24 +0200, Markus Mohrhard wrote:
 That is not planned. Only during import all the code in ScDocFunc does
 not make much sense. We neither need to repaint areas nor do we need
 undo/redo code.

Cool - yes, it's a nonsense to be doing all that pointless non-work on
import :-)

 We did not plan to replace ScDocFunc calls in any other place in calc.

Good stuff - thanks !

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] .: remotebridges/InternalUnoApi_uuresolver.mk remotebridges/Library_uuresolver.mk remotebridges/Makefile remotebridges/Module_remotebridges.mk remotebridges/prj remotebridges/sou

 Repository.mk|1 
 remotebridges/InternalUnoApi_uuresolver.mk   |   32 ++
 remotebridges/Library_uuresolver.mk  |   47 +++
 remotebridges/Makefile   |7 ++
 remotebridges/Module_remotebridges.mk|   35 +++
 remotebridges/prj/build.lst  |2 
 remotebridges/prj/d.lst  |4 -
 remotebridges/source/unourl_resolver/makefile.mk |   72 ---
 ure/Rdb_ure.mk   |2 
 9 files changed, 124 insertions(+), 78 deletions(-)

New commits:
commit e726638eb8bd9e8fab3268259ddee9de88c56a39
Author: David Tardon dtar...@redhat.com
Date:   Sat May 26 16:06:33 2012 +0200

gbuildize remotebridges

Change-Id: I01e97df2f9f098719e3de578526cb1d13d2db6fa

diff --git a/Repository.mk b/Repository.mk
index ebefb94..a8cb169 100644
--- a/Repository.mk
+++ b/Repository.mk
@@ -561,6 +561,7 @@ $(eval $(call gb_Helper_register_libraries,UNOLIBS_URE, \
 streams \
 textinstream \
 textoutstream \
+uuresolver \
 ))
 
 $(eval $(call gb_Helper_register_libraries,UNOVERLIBS, \
diff --git a/remotebridges/InternalUnoApi_uuresolver.mk 
b/remotebridges/InternalUnoApi_uuresolver.mk
new file mode 100644
index 000..2ac538e
--- /dev/null
+++ b/remotebridges/InternalUnoApi_uuresolver.mk
@@ -0,0 +1,32 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
+# Version: MPL 1.1 / GPLv3+ / LGPLv3+
+#
+# The contents of this file are subject to the Mozilla Public License Version
+# 1.1 (the License); you may not use this file except in compliance with
+# the License or as specified alternatively below. You may obtain a copy of
+# the License at http://www.mozilla.org/MPL/
+#
+# Software distributed under the License is distributed on an AS IS basis,
+# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+# for the specific language governing rights and limitations under the
+# License.
+#
+# Major Contributor(s):
+# Copyright (C) 2012 Red Hat, Inc., David Tardon dtar...@redhat.com
+#  (initial developer)
+#
+# All Rights Reserved.
+#
+# For minor contributions see the git repository.
+#
+# Alternatively, the contents of this file may be used under the terms of
+# either the GNU General Public License Version 3 or later (the GPLv3+), or
+# the GNU Lesser General Public License Version 3 or later (the LGPLv3+),
+# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
+# instead of those above.
+
+$(eval $(call gb_InternalUnoApi_InternalUnoApi,uuresolver))
+
+$(eval $(call 
gb_InternalUnoApi_set_xmlfile,uuresolver,remotebridges/source/unourl_resolver/uuresolver.xml))
+
+# vim: set shiftwidth=4 tabstop=4 noexpandtab:
diff --git a/remotebridges/Library_uuresolver.mk 
b/remotebridges/Library_uuresolver.mk
new file mode 100644
index 000..15fa64e
--- /dev/null
+++ b/remotebridges/Library_uuresolver.mk
@@ -0,0 +1,47 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
+# Version: MPL 1.1 / GPLv3+ / LGPLv3+
+#
+# The contents of this file are subject to the Mozilla Public License Version
+# 1.1 (the License); you may not use this file except in compliance with
+# the License or as specified alternatively below. You may obtain a copy of
+# the License at http://www.mozilla.org/MPL/
+#
+# Software distributed under the License is distributed on an AS IS basis,
+# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+# for the specific language governing rights and limitations under the
+# License.
+#
+# Major Contributor(s):
+# Copyright (C) 2012 Red Hat, Inc., David Tardon dtar...@redhat.com
+#  (initial developer)
+#
+# All Rights Reserved.
+#
+# For minor contributions see the git repository.
+#
+# Alternatively, the contents of this file may be used under the terms of
+# either the GNU General Public License Version 3 or later (the GPLv3+), or
+# the GNU Lesser General Public License Version 3 or later (the LGPLv3+),
+# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
+# instead of those above.
+
+$(eval $(call gb_Library_Library,uuresolver))
+
+$(eval $(call 
gb_Library_set_componentfile,uuresolver,remotebridges/source/unourl_resolver/uuresolver))
+
+$(eval $(call gb_Library_use_internal_api,uuresolver,\
+   uuresolver \
+))
+
+$(eval $(call gb_Library_use_libraries,uuresolver,\
+   cppu \
+   cppuhelper \
+   sal \
+   $(gb_STDLIBS) \
+))
+
+$(eval $(call gb_Library_add_exception_objects,uuresolver,\
+   remotebridges/source/unourl_resolver/unourl_resolver \
+))
+
+# vim: set shiftwidth=4 tabstop=4 noexpandtab:
diff --git a/remotebridges/Makefile b/remotebridges/Makefile
new file mode 100644
index 000..ccb1c85
--- /dev/null
+++ b/remotebridges/Makefile
@@ -0,0 +1,7 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
+
+module_directory:=$(dir $(realpath

Re: ODS import with merged cells

2012-05-26 Thread Daniel Bankston


On 05/26/2012 10:58 AM, Michael Meeks wrote:

On Sat, 2012-05-26 at 17:24 +0200, Markus Mohrhard wrote:

That is not planned. Only during import all the code in ScDocFunc does
not make much sense. We neither need to repaint areas nor do we need
undo/redo code.

Cool - yes, it's a nonsense to be doing all that pointless non-work on
import :-)


We did not plan to replace ScDocFunc calls in any other place in calc.

Good stuff - thanks !

Michael.



However, here is a message of doom to all UNO or ScDocFunc calls during 
import:

Your days are numbered because I'm coming for you! :-)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Don't make tab headers bold by default

On Fri, May 25, 2012 at 12:07 PM, Stefan Knorr (Astron)
heinzless...@googlemail.com wrote:
 Hi there,

 I've always wondered why LibreOffice (and before it Ooo) would make
 the selected tab header bold, because no OS I know does that natively.
 While there is an option with which backends could turn this behaviour
 off, if there's no need for that we probably should remove it, I
 guess.
 Attached patch does that and even works. Can I push or is there
 something that seems wrong?


I'm confused:

@@ -723,9 +705,7 @@ void TabControl::ImplShowFocus()
 // make sure the focussed item rect is computed using a bold font
 // the font may have changed meanwhile due to mouse over

-Font aOldFont( GetFont() );
-Font aFont( aOldFont );
-aFont.SetWeight( (!ImplGetSVData()-maNWFData.mbNoBoldTabFocus) ?
WEIGHT_BOLD : WEIGHT_LIGHT );
+Font aFont( GetFont() );
 SetFont( aFont );
^^^ you are setting the Font to the same thing it used to have here no
(since you remove the code that used to potentially alter it)?

 sal_uInt16   nCurPos = GetPagePos( mnCurPageId );
@@ -771,8 +751,7 @@ void TabControl::ImplShowFocus()
 aRect.Bottom() = aRect.Top() + aImageSize.Height() + 4;
 }
 ShowFocus( aRect );
-
-SetFont( aOldFont );
+SetFont( aFont );
 }

Why the last SetFont() ? you are not messing with the font anymore
right ? so it has not changed... no need to restore it, no?

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

Re: [PATCH] Unify OUTPATH values

On Sat, May 26, 2012 at 5:59 AM, Francois Tigeot ftig...@wolfpond.org wrote:
 Hi,

 I don't think there's any good reason to have wildly different OUTPATH names
 for each specific platform variant.

 The various names also lead to unnecessary work when packaging, just to
 correctly handle LD_LIBRARY_PATH.

 The attached patch reduces OUTPATH to two possible values: unx and wnt. Since
 it is potentially intrusive, I prefer to show it here for review instead of
 committing it directly.

Francois,

That would fatally break at least cross-compile. I'm afraid that
cannot be merged in that form.

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

Re: feature/gbuild_merge needs testing

Hi,

On Sat, May 26, 2012 at 03:36:54PM +0100, Michael Meeks wrote:
 Hi David,
 
 On Fri, 2012-05-25 at 13:28 +0200, David Tardon wrote:
  There is experimental branch feature/tail_build that adds 19 more, but
  it requires a change to build.pl, so I do not intend to push it into 3.6.
  Of course, if people who actually know something about the build.pl
  script look at commit 726ac115a981567b3f41613d0e0163bd010e6b17 and tell
  me that I am not a total idiot, or even that it might work at the right
  phase of moon, I can be convinced otherwise :-)
 
   I had the misfortune to hack on build.pl before :-) and your patch
 looks reasonable to me. I'd love to have it in for 3.6 ... I didn't
 checkout the branch and/or I couldn't make the make command that dumps
 the deps work but I assume the parsing logic is fine. We may have some
 explicit \r\n removal nonsense on windows (chomp has never worked well
 for me there for some - prolly cygwin related reason) - but lets see.

Let's hope the branch is going to get some testing on Windows, then.

 
 -my $modcount = %modules;
  
  return %modules;
 
   seems redundant in get_tail_build_modules.

Right, it is a forgotten remnant of a debug print. There is also a print
in filter_tail_build_dependencies that I plan to remove before merging
the branch on master.

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

Re: feature/gbuild_merge needs testing

On Fri, May 25, 2012 at 6:28 AM, David Tardon dtar...@redhat.com wrote:
 Hi all,

 The number of modules newly added to tail_build is not as good as I
 expected--only 9, if I counted correctly.

I ran module_dep on gbuild_merge...
for postprocess the parent list looks like (note: (*) indicate a gbuild module)

n_th@tpamac /Volumes/TBRAM/core
$/Volumes/Raid0/dev-tools/modules_dep/modules_dep -p postprocess -u
Error: dependency helpcontent2 of module postprocess does not have a
known build.lst associated to it (I did not have helpcontent2 hence
the message)
postprocess
  + tail_build (*)
 + xsltml
+ external
   + soltools
  + solenv (*)
 + xmlreader (*)
+ sal (*)
   + cppunit
   + boost
   + xml2cmp (*)
+ offapi (*)
   + idlc (*)
  + registry (*)
 + store (*)
 + salhelper (*)
   + udkapi (*)
  + codemaker (*)
+ cppu (*)
 + ure (*)
+ stoc (*)
   + libxslt
  + libxml2
   + jvmfwk (*)
  + comphelper (*)
 + officecfg (*)
 + ucbhelper (*)
+ cppuhelper (*)
   + jvmaccess (*)
  + ridljar (*)
   + rdbmaker (*)
+ remotebridges
+ javaunohelper (*)
   + unoil (*)
  + cli_ure
 + bridges
+ jurt (*)
+ io (*)
+ binaryurp (*)
 + unotest (*)
+ qadevOOo (*)
 + tools (*)
+ i18npool (*)
   + cpputools (*)
   + regexp (*)
  + i18nutil (*)
 + icu
   + sax (*)
  + expat
+ basegfx (*)
   + o3tl (*)
+ zlib
 + sysui
+ setup_native
   + l10ntools (*)
  + clucene (*)
  + berkeleydb
 + rhino
 + readlicense_oo
 + icc
 + xpdf
 + vigra
 + twain (*)
 + saxon
+ stax
 + sane (*)
 + redland
+ openssl
 + python
 + postgresql
+ moz
   + nss
 + neon
 + mythes
+ hunspell
 + mdds
 + lpsolve
 + libvisio
+ libwpg
   + libwpd
 + libwps
 + libxmlsec
 + libexttextcat
 + libcmis
+ curl
 + libcdr
+ lcms2
 + jpeg
 + jfreereport
+ apache-commons
   + tomcat
 + hyphen
 + hsqldb
 + graphite
 + freetype
 + fontconfig
 + cairo
+ libpng
 + beanshell
 + afms
  + stlport
  + nlpsolver (*)
  + mysqlc
 + mysqlcppconn
  + languagetool
  + pyuno
  + dictionaries
  + more_fonts
  + testtools (*)
  + odk
 + unodevtools (*)
 + autodoc
+ udm
   + cosv
  + librsvg
 + gettext
 + glib
 + gdk-pixbuf
 + libgsf
 + libcroco
 + pango
  + extras
  + epm
  + embedserv (*)
  + ct2n
  + crashrep
 + shell (*)
  + binfilter


unotest parents give:
n_th@tpamac /Volumes/TBRAM/core
$/Volumes/Raid0/dev-tools/modules_dep/modules_dep -c unotest -u | grep
-v (\*)
Error: dependency helpcontent2 of module postprocess does not have a
known build.lst associated to it
 + postprocess
   + instsetoo_native
 + binfilter
   + crashrep
+ pyuno
   + cross_toolset

since binfilter is already treated separately (i.e wait for tail_build
to finish)
unotest can be integrated... on the other hand it seems quite a few
module use it without telling their build.lst they do... so their can
be partial build issue

twain:
twain (*)
  + tail_build (*)
 + postprocess
+ packimages (*)
   + instsetoo_native
 + binfilter
  + extensions (*)

ditto for sane.

so they can be merged in tail_build I think

nlpsolver, embedserv and testttols are directly dep of postprocess and
nothing else.. they can be put in tail_build.

-- 
module_dep is in contrib/dev-tools/module_dep
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] GTK theme toolbar button rendering

2012-05-26 Thread Ruslan Kabatsayev

Hello,

Current GTK theming plugin renders toolbar buttons as non-flat
unconditionally. But some themes, e.g. oxygen-gtk expect toolbuttons
to be flat, and the desktop integration fails.
I'm attaching a patch to fix this. The patch has been tested with
oxygen-gtk(current master), QtCurve-GTK, Glossy and Simple themes.

Regards,
Ruslan


0001-GTK-theming-fix-rendering-of-toolbuttons.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] .: extras/source

2012-05-26 Thread Alexander Wilms

 extras/source/templates/layout/lyt-metropolis.otp |binary
 1 file changed

New commits:
commit d1dd475389b798e99d09f2dd9f1b52341bb610a0
Author: Alexander Wilms alexander.wi...@zoho.com
Date:   Sat May 26 14:42:04 2012 +0200

added the metropolis master page

diff --git a/extras/source/templates/layout/lyt-metropolis.otp 
b/extras/source/templates/layout/lyt-metropolis.otp
new file mode 100644
index 000..a1aaf7d
Binary files /dev/null and b/extras/source/templates/layout/lyt-metropolis.otp 
differ
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[Libreoffice-commits] .: Branch 'feature/gbuild_merge' - connectivity/prj