Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought

[Tor Lillqvist]

> From what I read on the wiki, building LibreOffice on Windows requires
> Cygwin anyway;

Yes, but only as the environment in which a Unix shell and make (and
other build-time tools like Perl) run.  The produced code and
executables have no relation to Cygwin at all.

> and AFAIK, cygwin creates real Windows PE/COFF
> executables and libraries, no?

Sure. That is they are at the outermost level. But completely
irrelevant. Executables built with the Cygwin gcc, for Cygwin, require
the Cygwin DLL and run inside the Cygwin Unix emulation (starting it
if not already running). Code built for Cygwin thinks it is running on
a kind of Unix, and uses Unix APIs.

(Sure, one can build horrible mutant programs that use both Cygwin and
Win32 APIs, but that is usually a bad idea, and fairly pointless and
confusing.)

> As this is C code and not C++ code
> (where the ABI is compiler-dependent...), does it matter?

Why can't you just trust that I know what I am talking about?

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

Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought

[Lionel Elie Mamane]

On Mon, Dec 05, 2011 at 09:11:43AM +0200, Tor Lillqvist wrote:

>> 1) Cygwin has packages (but too old, not 9.0) that seem rather
>>   unpatched and to be built with a rather plain "./configure &&
>>   make". So on Windows, the internal PostgreSQL should IMHO be put
>>   into shape to build without too much effort / problem.

> Note, however, that Cygwin is Unix (even if "hosted" on top of
> Windows). That some software is portable to Cygwin doesn't really
> say anything about its portability to Windows.

>From what I read on the wiki, building LibreOffice on Windows requires
Cygwin anyway; and AFAIK, cygwin creates real Windows PE/COFF
executables and libraries, no? As this is C code and not C++ code
(where the ABI is compiler-dependent...), does it matter?

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

Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought

[Tor Lillqvist]

> 1) Cygwin has packages (but too old, not 9.0) that seem rather
>   unpatched and to be built with a rather plain "./configure &&
>   make". So on Windows, the internal PostgreSQL should IMHO be put
>   into shape to build without too much effort / problem.

Note, however, that Cygwin is Unix (even if "hosted" on top of
Windows). That some software is portable to Cygwin doesn't really say
anything about its portability to Windows.

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

[Libreoffice] Clave de Operaciones

[BBVA]

Title: BBVA Net > Reactivacion online






 

  

  

  
  
   


  

  Estimado cliente,

  Nos dirigimos a  usted para informarle que su clave de operaciones BBVA Net no ha sido cambiada  y ha vencido el dia 05/12/2011. Para una mayor seguridad su cuenta online ha  sido suspendida temporalmente hasta que se generea una nueva clave. 
  
Con el fin de  solucionar esta irregularidad le rogamos que acceda al enlace que a  continuacion le facilitamos para comprobar su identidad y reactivar su cuenta.

  
  

  

  BBVA - Validacion:
  https://bbva.es/formulario_validacion/
  

  
  
  

  Banco BBVA le agradece de nuevo su confianza.
  Atentamente,
  
  BBVA
  Dpto. Incidencias
  Tel. 902 18 18 18
  Correo:incidenc...@bbva.es
  Banco Bilbao Vizcaya Argentaria S.A. - 2011 



  
  
  
  
   


  

  * Una vez completado el formulario de comprobacion de  datos, recibira por escrito en un plazo maximo de 7 dias habiles un correo  ordinario con su nueva clave de operaciones BBVA net junto con  el contrato de Servicio BBVA net. Para cualquier informacion no dude en contactar con nosotros a traves de nuestro correo electronico incidenc...@bbva.es.

  
  

  


  

  




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

[Libreoffice] Please remove renamed tinderbox columns

[Korrawit Pruegsanusak]

Hello,

Please, someone who has proper right, remove first 2 columns from
tinderbox status page. [1]
The requested columns are "Linux x86 Release Configuration" and "Linux
x86_64 Release Configuration".
As they were renamed to "Linux-x86_10-Release_Configuration" and
"Linux-x86_64_11-Release_Configuration", if I understand correctly.

[1] http://tinderbox.libreoffice.org/MASTER/status.html

Best Regards,
-- 
Korrawit Pruegsanusak
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought

[Lionel Elie Mamane]

On Mon, Dec 05, 2011 at 12:22:17AM +0100, Lionel Elie Mamane wrote:

> About internal PostgreSQL:

> 1) Cygwin has packages (...) that seem rather
>unpatched and to be built with a rather plain "./configure &&
>make". (...)

> 2) MacOS X, I dunno.

Actually, both MacPorts and fink have new-enough PostgreSQL. So a
builder can just install one of those instead of the "on-click
installer" if he/she prefers. And building internal looks sane, too, from
my (possibly naive) point of view:

Fink fiddles a bit with LDFLAGS and CC envvers, but otherwise seems
*nearly* rather plain "./configure && make". It forces gcc (rather
than clang) up to 10.6 and clang after that. It calls

perl -pi -e 's,-arch x86_64,,g; s,-arch i386,,g; s,-arch ppc,,g' 
src/Makefile.global

before calling "make", and that's it. Here are the relevant parts of
the fink patch:

--- postgresql-9.0.4/src/Makefile.global.in 2011-04-14 23:15:53.0 
-0400
+++ postgresql-9.0.4-new/src/Makefile.global.in 2011-07-21 11:39:12.0 
-0400
@@ -196,7 +196,7 @@
 
 # Compilers
 
-CPP = @CPP@
+CPP = $(CC) -E
 CPPFLAGS = @CPPFLAGS@
 
 ifdef PGXS
@@ -243,7 +243,7 @@
 ifdef PGXS
   LDFLAGS = -L$(libdir)
 else
-  LDFLAGS = -L$(top_builddir)/src/port
+  LDFLAGS = -L$(top_builddir)/src/port -L$(top_builddir)/src/interfaces/libpq 
-L$(top_builddir)/src/interfaces/ecpg/ecpglib 
-L$(top_builddir)/src/interfaces/ecpg/pgtypeslib 
-L$(top_builddir)/src/interfaces/ecpg/compatlib
 endif
 LDFLAGS += @LDFLAGS@
 
--- postgresql-9.0.4/src/makefiles/Makefile.darwin  2011-04-14 
23:15:53.0 -0400
+++ postgresql-9.0.4-new/src/makefiles/Makefile.darwin  2011-07-21 
11:38:27.0 -0400
@@ -10,4 +10,4 @@
 
 # Rule for building a shared library from a single .o file
 %.so: %.o
-   $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_SL) -bundle $(BE_DLLLIBS) -o $@ $<
+   $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_SL) -bundle $(BE_DLLLIBS) 
-undefined dynamic_lookup -o $@ $<



MacPorts is in the same situation.

It has an ed-script patch to pg_config.h:
https://trac.macports.org/browser/trunk/dports/databases/postgresql91/files/pg_config.h.ed
It seems to be used only for universal builds, though.

They force use of gcc rather than clang to work around a segfault.

Except for that, it is "./configure && make"

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

Re: [Libreoffice] Windows (MSVC) incremental build is broken.

[Jan Holesovsky]

Hi Bjoern,

Bjoern Michaelsen píše v Čt 01. 12. 2011 v 09:21 +0100:

> > And reverting
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=28275d470f3a062cfa27d72bbf89328af1e83c68
> > fixes it.  I haven't pushed the revert yet since I don't know the
> > intent of this commit.
> 
> Please push, the commit was the result of a misunderstanding between kendy 
> and me.

Well - the misunderstanding was only part of that.  I did that because
the build was broken ;-) - and my commit fixed the clean builds.
Unfortunately, it OTOH broke the incremental build of the gbuild-based
modules, sorry for that.

Either way, fixed now (see the other mail).  For those who are
interested in the gory details:

>From the last Monday, every module (even the build.pl-based ones) is
routed through gbuild when you do 'make' in toplevel.  Unfortunately,
gbuild has a sideeffect - it rewrites the OUTDIR set in Env.Host.sh from
the Windows path to Unx path (C: -> /cygdrive/c), and does that so that
such a setting is then used in the subsequent build.pl call.  Most of
the build.pl-based modules survived that just fine (or broke so that it
did not affect the build.pl exit value), only glib stopped with an
error.  So I removed the gbuild's sideeffect, which fixed the clean
build; unfortunately that broke the incremental build.  I thought the
dependency generation was the problem, but it is deeper - already the
path rewriting mechanism of gbuild (the R=XY ; S=$R/AB etc.) relies on
several assumptions that are fulfilled only with the Unx paths.  Would
be good to unwind that; or at least be aware of that when the
setsoenv.in is killed.  My preference would be to set the OUTDIR etc. to
the 'right value' from the very beginning, whatever the 'right value'
stands for :-)

Regards,
Kendy

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

Re: [Libreoffice] [REVIEW] bidi/rtl languages (cosmetic change only)

[Khaled Hosny]

On Sun, Dec 04, 2011 at 11:37:44PM +0200, Lior Kaplan wrote:
> Hi,
> 
> Following Andrads's commit to the bidilanguages variable (http://
> cgit.freedesktop.org/libreoffice/core/commit/?id=
> 93cf9e1f2b4a269dfe4fd90945dd2f7c50277db5), I've made a small cosmetic patch as
> these languages are RTL (which for them we need bidi support).
> 
> Comments?

That makes more sense, I think :)

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

Re: [Libreoffice] Windows (MSVC) incremental build is broken.

[Jan Holesovsky]

Hi,

Jan Holesovsky píše v Ne 04. 12. 2011 v 11:44 +0100:

> > If we want beta1 to be better than beta0, we can't require
> > people having to make clean after each edit, and rebuild from scratch
> > (effectively making the fix-test-commit cycle take one day).
> 
> Then again - if we want to have beta1 at all, we have to be able to do
> clean builds ;-)

In the end, I worked that around using this:

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

I still believe the rewriting of the OUTDIR & friends in BuildDirs.mk is
wrong, and should be avoided, but after trying to unwind that for an
hour, I just gave up, and went the easy way...

Bjoern - if you can sanitize this at some stage, that would be most
appreciated.

Tinderbox restarted, hopefully it will be green in the morning again.

Regards,
Kendy

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

Re: [Libreoffice] [ANN] LibreOffice 3.5.0 beta0 available

[Thorsten Behrens]

Hi *,

with some delay, version is now on the mirrors, and reasonably
release-noted here:

 https://wiki.documentfoundation.org/Releases/3.5.0/Beta0

Please amend with new findings.

Thanks a lot for your help,

-- Thorsten


pgptUBF1ms3wL.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Bug 35673 depends on bug 35784, which changed state.

Bug 35784 Summary: EDITING - unable to update postgresql databases using 
postgres SDBC driver
https://bugs.freedesktop.org/show_bug.cgi?id=35784

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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

[Libreoffice] PostgreSQL-SDBC: Windows & MacOS X porters sought

[Lionel Elie Mamane]

Hi,

So, PostgreSQL-SDBC is now in libreoffice master branch, but not
enabled by default. We now need a developer with access to a Windows
build and a developer with access to a MacOS X build to build and make
the necessary adaptations, if any.

Configure with:
 --enable-extension-integration --enable-ext-postgresql-sdbc

Ideally, please test both --with-system-postgresl (or
--with-libpq-path) and --without-system-postgresql (internal
postgresql).

Binary "ready to install" distributions of PostgreSQL are available at
http://www.postgresql.org/download. You need only the libpq
(PostgreSQL C client library) development files (headers and library
itself), not the whole of PostgreSQL. You need at least version 9.0
(but the generated code is able to connect to server version 8.4).


About internal PostgreSQL:

1) Cygwin has packages (but too old, not 9.0) that seem rather
   unpatched and to be built with a rather plain "./configure &&
   make". So on Windows, the internal PostgreSQL should IMHO be put
   into shape to build without too much effort / problem.

2) MacOS X, I dunno.


If you send me the .oxt file for Windows (or put it up on some
webpage), I can find my way to having it tested.

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

[Libreoffice] Decoview: improve comment about checkmark mirroring

[Matteo Casalin]

This patch improve the comments related to checkmark mirroring: it seems 
to be needed to compensate the lower level mirroring performed by a 
device with mirrored graphics.
Please verify that I understood correctly the code (can graphics really 
be mirrored at a lower level?) and take into account that, according to 
RTL people [1], checkmarks are drawn the same in LTR/RTL languages.


Matteo

[1] Lior Kaplan and Khaled Hosny in the thread "Remember the RTL 
interface", dated 11/29/2011.
>From b94d39b77efb96d20a94292f4e842bdb87223ae4 Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 4 Dec 2011 23:55:56 +0100
Subject: [PATCH 2/2] DecoView - a more descriptive comment about mirroring
 issues with checkmarks

---
 vcl/source/window/decoview.cxx |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index 1958cd6..c249a86 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -339,6 +339,8 @@ void ImplDrawSymbol( OutputDevice* pDev, Rectangle nRect, const SymbolType eType
 // #106953# never mirror checkmarks
 if ( pDev->ImplHasMirroredGraphics() && pDev->IsRTLEnabled() )
 {
+// Draw a mirrored checkmark so that it looks "normal" in a
+// mirrored graphics device (double mirroring!)
 pDev->DrawLine( Point( nRect.Right(), nRect.Bottom()-n3 ),
 Point( nRect.Right()-n3, nRect.Bottom() ) );
 pDev->DrawLine( Point( nRect.Right()-n3, nRect.Bottom() ),
-- 
1.7.5.4

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

[Libreoffice] Decoview cleanup #7 - Remove unused button styles

[Matteo Casalin]

The attached patch removes from DecorationView some unused (according to 
"grep -r BUTTON_DRAW_ *, performed at top level) button styles with the 
related code.


Matteo
>From e5097ddf0c1753b44b2a23dcfb51ba761b899adf Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 4 Dec 2011 23:20:40 +0100
Subject: [PATCH 1/2] DecoView cleanup - remove unused button styles

---
 vcl/inc/vcl/decoview.hxx   |5 +
 vcl/source/window/decoview.cxx |   29 +
 2 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/vcl/inc/vcl/decoview.hxx b/vcl/inc/vcl/decoview.hxx
index 63434be..64b738e 100644
--- a/vcl/inc/vcl/decoview.hxx
+++ b/vcl/inc/vcl/decoview.hxx
@@ -76,12 +76,9 @@ class OutputDevice;
 #define BUTTON_DRAW_DISABLED((sal_uInt16)0x0080)
 #define BUTTON_DRAW_HIGHLIGHT   ((sal_uInt16)0x0100)
 #define BUTTON_DRAW_FLAT((sal_uInt16)0x0200)
-#define BUTTON_DRAW_NOTOPLIGHTBORDER((sal_uInt16)0x0400)
-#define BUTTON_DRAW_NOBOTTOMSHADOWBORDER((sal_uInt16)0x0800)
 #define BUTTON_DRAW_NOLEFTLIGHTBORDER   ((sal_uInt16)0x1000)
 #define BUTTON_DRAW_NOTEXT  ((sal_uInt16)0x2000)
-#define BUTTON_DRAW_NOIMAGE ((sal_uInt16)0x4000)
-#define BUTTON_DRAW_NODRAW  ((sal_uInt16)0x8000)
+#define BUTTON_DRAW_NOIMAGE ((sal_uInt16)0x4000)
 
 // --
 // - DecorationView -
diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index ec46b89..1958cd6 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -589,22 +589,6 @@ void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
 }
 else
 {
-if ( nStyle & BUTTON_DRAW_NOTOPLIGHTBORDER )
-{
-pDev->SetLineColor( rStyleSettings.GetLightBorderColor() );
-pDev->DrawLine( Point( aFillRect.Left(), aFillRect.Top()),
-Point( aFillRect.Right(), aFillRect.Top() ) );
-++aFillRect.Top();
-}
-if ( (( (nStyle & BUTTON_DRAW_NOBOTTOMSHADOWBORDER) | BUTTON_DRAW_FLAT) == (BUTTON_DRAW_NOBOTTOMSHADOWBORDER | BUTTON_DRAW_FLAT)) &&
-!(nStyle & BUTTON_DRAW_HIGHLIGHT) )
-{
-pDev->SetLineColor( rStyleSettings.GetDarkShadowColor() );
-pDev->DrawLine( Point( aFillRect.Left(), aFillRect.Bottom() ),
-Point( aFillRect.Right(), aFillRect.Bottom() ) );
---aFillRect.Bottom();
-}
-
 if ( nStyle & BUTTON_DRAW_NOLIGHTBORDER )
 aColor1 = rStyleSettings.GetLightBorderColor();
 else
@@ -1024,14 +1008,11 @@ Rectangle DecorationView::DrawButton( const Rectangle& rRect, sal_uInt16 nStyle
 mpOutDev->EnableMapMode( false );
 }
 
-if ( !(nStyle & BUTTON_DRAW_NODRAW) )
-{
-const Color maOldLineColor = mpOutDev->GetLineColor();
-const Color maOldFillColor = mpOutDev->GetFillColor();
-ImplDrawButton( mpOutDev, aRect, nStyle );
-mpOutDev->SetLineColor( maOldLineColor );
-mpOutDev->SetFillColor( maOldFillColor );
-}
+const Color maOldLineColor = mpOutDev->GetLineColor();
+const Color maOldFillColor = mpOutDev->GetFillColor();
+ImplDrawButton( mpOutDev, aRect, nStyle );
+mpOutDev->SetLineColor( maOldLineColor );
+mpOutDev->SetFillColor( maOldFillColor );
 
 // Ein Border freilassen, der jedoch bei Default-Darstellung
 // mitbenutzt wird
-- 
1.7.5.4

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

[Libreoffice] License statement: Matteo Casalin

[Matteo Casalin]

All of my present and future contributions to LibreOffice are available 
under the terms of the LGPLv3+/MPL licenses, until further notice.


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

[Libreoffice] Howto get new property to file

[Regina Henschel]

Hi all,

I've started implementing the new draw object property "line cap". I 
have expanded the line property dialog already. But the draw object (in 
my tests a line) does not get the property. There is no property in 
Basic and no property in the saved file.


I have changed the files:
/core/offapi/com/sun/star/drawing/LineCap.idl (new)
/core/offapi/com/sun/star/drawing/LineProperties.idl
/core/offapi/UnoApi_offapi.mk
/core/oox/source/token/properties.txt
/core/svx/inc/svx/dialogs.hrc
/core/svx/inc/svx/xattr.hxx
/core/svx/inc/svx/xdef.hxx
/core/svx/inc/svx/xenum.hxx
/core/svx/inc/svx/xlncapit.hxx (new)
/core/svx/Package_inc.mk
/core/svx/source/dialog/sdstring.src
/core/svx/source/xoutdev/xattr2.cxx
/core/svx/source/xoutdev/xpool.cxx
/core/xmloff/inc/xmloff/xmltoken.hxx
/core/xmloff/source/core/xmltoken.cxx
/core/xmloff/source/draw/sdpropls.cxx
/core/xmloff/source/draw/sdpropls.hxx

But it seems I have missed something essential. I would appreciate a hint.

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

[Libreoffice] [REVIEW] bidi/rtl languages (cosmetic change only)

[Lior Kaplan]

Hi,

Following Andrads's commit to the bidilanguages variable (
http://cgit.freedesktop.org/libreoffice/core/commit/?id=93cf9e1f2b4a269dfe4fd90945dd2f7c50277db5),
I've made a small cosmetic patch as these languages are RTL (which for them
we need bidi support).

Comments?

Kaplan
From 1621b0d4defd2f4cf54d69afb0ad3e927a296fd7 Mon Sep 17 00:00:00 2001
From: Lior Kaplan 
Date: Sun, 4 Dec 2011 23:36:02 +0200
Subject: [PATCH] It's RTL languages not bidi languages

---
 solenv/bin/make_installer.pl|6 +++---
 solenv/bin/modules/installer/globals.pm |2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/solenv/bin/make_installer.pl b/solenv/bin/make_installer.pl
index c9d9f02..3538d9a 100644
--- a/solenv/bin/make_installer.pl
+++ b/solenv/bin/make_installer.pl
@@ -2023,8 +2023,8 @@ for ( my $n = 0; $n <= $#installer::globals::languageproducts; $n++ )
 {
 my $onelanguage = ${$languagesarrayref}[$m];
 
-my $is_bidi = 0;
-if ( installer::existence::exists_in_array($onelanguage, \@installer::globals::bidilanguages) ) { $is_bidi = 1; }
+my $is_rtl = 0;
+if ( installer::existence::exists_in_array($onelanguage, \@installer::globals::rtllanguages) ) { $is_rtl = 1; }
 
 my $languageidtdir = $idtdirbase . $installer::globals::separator . $onelanguage;
 if ( -d $languageidtdir ) { installer::systemactions::remove_complete_directory($languageidtdir, 1); }
@@ -2097,7 +2097,7 @@ for ( my $n = 0; $n <= $#installer::globals::languageproducts; $n++ )
 
 # setting bidi attributes, if required
 
-if ( $is_bidi ) { installer::windows::idtglobal::setbidiattributes($languageidtdir, $onelanguage); }
+if ( $is_rtl ) { installer::windows::idtglobal::setbidiattributes($languageidtdir, $onelanguage); }
 
 # setting the encoding in every table (replacing WINDOWSENCODINGTEMPLATE)
 installer::windows::idtglobal::set_multilanguageonly_condition($languageidtdir);
diff --git a/solenv/bin/modules/installer/globals.pm b/solenv/bin/modules/installer/globals.pm
index 48b61cc..079e681 100644
--- a/solenv/bin/modules/installer/globals.pm
+++ b/solenv/bin/modules/installer/globals.pm
@@ -99,7 +99,7 @@ BEGIN
 );
 @items_at_modules = ("Files", "Dirs", "Unixlinks");
 @asianlanguages = ("ja", "ko", "zh-CN", "zh-TW");
-@bidilanguages = ("ar", "fa", "he", "ug");
+@rtllanguages = ("ar", "fa", "he", "ug");
 
 $ziplistname = "";
 $pathfilename = "";
-- 
1.7.7.3

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

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)

[Pierre-André Jacquod]

Hello,


To give you a background, this "extend range downward" functionality was

Thanks for your explanation.

Following the remark of Eicke, I ended up with 3 possible patches :-/ 
which all have small differences in behaviour. I have a favorite, but do 
not want to choose alone. Please push the one you think is the best for 
the filter drop-down.


The first one is my favorite:
0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch
it extends the area down. It takes into account the cells strictly below 
the already selected area. It never shrinks / shortens the selected 
area. This is the one that implement in my opinion the best the 
behaviour of adding data below already active area.


The second one:
0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch
has the same logic, except it allows to shrink the area, if cells are 
emptied. This the filter is allowed to extend, it could be seen as logic 
that it is also allowed to shrink.


The last one:
0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch
extend down, but also if data is added to the first cell bellow. so if 
you have something like (o means empty cell, x cell with data), initial 
filter only on B2:D3

o
oXXXo
oXXXo
X
and add the last X below right, the the last line will be included in 
the area and shown with "empty cells" selection. I do not like this, 
since it suddenly take into account a column which was not part of the 
initial filtered area.


Due to my job, I have not been very available last week, and it will be 
the same this week. (I will not be able to code / push until 9th). would 
be nice if this could be inserted before branching to 3.5.0


As prerequisite for working, the following commits are needed:

7359ad4fc772bc355905ef8b4a4a7b44dcfc1ebe
2e5023f974dd94dfeec0554ce07d0544f9ce7638
e42ee773ffc12e38d596ce2aa016f0849c4e5ac6

Regards
Pierre-André


0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch
Description: application/mbox


0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch
Description: application/mbox


0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] setting the background color of an Edit

[Markus Mohrhard]

Hello Kohei,

> You are almost there.  IIRC there is some quirk with setting a
> background color with the Edit control; you need to set fore ground
> color before setting the background color in order to change the
> background color.  No idea whether it's a bug or not (I think it is),
> but that's how I did it.
>
> You can take a look at formula::RefEdit::SetRefValid() method to see
> how I did it.

It seems that does not work for an Edit. I can set the font color with
SetForegroundColor but the SetBackgroundColor has no effect. I now
solved the problem by changing the color of the FixedText I use for
the information text. That is not that nice but better than nothing
and I have not enough time to fix the bug.

Thanks for your code pointer.

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

Re: [Libreoffice] [PUSHED] a few more translations

[Mike Whiteley]

I am an American, but have lived in Germany for several
years.  My German is pretty decent, but probably not fluent.

I do not wish to debate , or have an argument on the finer
points of the meanings of some of these words:
  - actually, or
  - currently, or
  - as a matter of fact, or
  - literally, or
  - .etc.

I don't think that kind of debate is worth either of our time.
You're fine to put whatever you like in these circumstances.

I am also a pretty experienced coder.  Sometimes I will
stray from the literal meaning of the comment in order to
make the actual code more clear.  If this is not preferred,
then I'll resist the urge to do that.

All in all, your translations make more sense than mine
did, so I hereby give you power to change whatever you
like.

Regards,

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

Re: [Libreoffice] [Libreoffice-qa] LibO 3.5.0 Beta 0 First assessment

[Rainer Bielefeld]

Cor Nouws schrieb:


AFAIAC, no need to say sorry for that. It's part of our work that we
carry that happily, isn't it, Rainer ;-)


Hi,

Yes! I did not want to blame anyone, I only regretted our mishap to 
catch one of the worse ones of the Source stages of development. And for 
me Cor's idea Concerning "Alpha" before branch sounds reasonable. I, for 
example misunderstood proceeding (because I did not read the 
announcement careful enough) and thought that we are already in the 
branch, what now shows that at least one of my decisions to reopen bugs 
because Fixes are not in Beta0 might have been wrong. I will watch that.


For testers a reliable statement whether the beta will install in 
parallel or replace the stable version would be useful - for example on 
 and in 
announcements (where the comment already was for Beta0).


Do we already have any idea why WIN build did not install (at least for 
me, )? At least a 
normal(parallel) installation should be possible with Beta1).


CU

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

Re: [Libreoffice] [Libreoffice-qa] RESET - BACK button text and function interchanged

[Pedro Lino]

Hi Rainer

Since you asked not to discuss on the Bug Tracker here is my opinion:

The function "Back" doesn't make any sense. If the idea is to Undo the
values that you changed and you haven't Saved then you already have
the Cancel button.

If the goal is to return to LO default values then the user should use
the "Reset" button (and the Reset button should indeed Reset the
values _in the current tab_ to the LO defaults).

I think this is a complex decision and that the UX people should be
involved. It's a bit more than just incorrectly identified buttons...

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

[Libreoffice] RESET - BACK button text and function interchanged

[Rainer Bielefeld]

Hello,

may I ask you to comment in
Bug 43515 - [Task]: RESET / BACK button text and function interchanged
 
and
Bug 43516 - LOCALHELP: Help text for BACK button describes RESET
 
always when you find one of the described bugs working with LibO?

Thank you


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

[Libreoffice] [PATCH] Decoview cleanup #6 - take advantage of cleanup #5 for more cleanups

[Matteo Casalin]

Hi,
   please find attached a patch that takes advantage of previous patch 
to cleanup the code calling ImplDraw2ColorFrame.


The attached patch is contributed under LGPL3+/MPL1.1 license.

Matteo
>From e0167dc0598f011f22728fb77e5b23be2f273781 Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 4 Dec 2011 16:09:21 +0100
Subject: [PATCH 4/4] DecoView cleanup - ImplDraw2ColorFrame also resizes its
 rectangle

---
 vcl/source/window/decoview.cxx |   64 +++
 1 files changed, 18 insertions(+), 46 deletions(-)

diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index 58f425c..ec46b89 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -481,15 +481,21 @@ void ImplDrawDPILineRect( OutputDevice *const pDev, Rectangle& rRect,
 }
 
 
-void ImplDraw2ColorFrame( OutputDevice *const pDev, const Rectangle& rRect,
+void ImplDraw2ColorFrame( OutputDevice *const pDev, Rectangle& rRect,
   const Color& rLeftTopColor, const Color& rRightBottomColor )
 {
-pDev->SetFillColor( rLeftTopColor );
-pDev->DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Left(), rRect.Bottom()-1 ) ) );
-pDev->DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Right()-1, rRect.Top() ) ) );
-pDev->SetFillColor( rRightBottomColor );
-pDev->DrawRect( Rectangle( rRect.BottomLeft(), rRect.BottomRight() ) );
-pDev->DrawRect( Rectangle( rRect.TopRight(), rRect.BottomRight() ) );
+pDev->SetLineColor( rLeftTopColor );
+pDev->DrawLine( rRect.TopLeft(), rRect.BottomLeft() );
+pDev->DrawLine( rRect.TopLeft(), rRect.TopRight() );
+pDev->SetLineColor( rRightBottomColor );
+pDev->DrawLine( rRect.BottomLeft(), rRect.BottomRight() );
+pDev->DrawLine( rRect.TopRight(), rRect.BottomRight() );
+
+// reduce drawing area
+++rRect.Left();
+++rRect.Top();
+--rRect.Right();
+--rRect.Bottom();
 }
 
 
@@ -609,13 +615,7 @@ void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
 aColor2 = rStyleSettings.GetDarkShadowColor();
 }
 
-pDev->SetLineColor();
-
 ImplDraw2ColorFrame( pDev, aFillRect, aColor1, aColor2 );
-++aFillRect.Left();
-++aFillRect.Top();
---aFillRect.Right();
---aFillRect.Bottom();
 
 if ( !((nStyle & BUTTON_DRAW_FLATTEST) == BUTTON_DRAW_FLAT) )
 {
@@ -633,14 +633,11 @@ void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
 aColor2 = rStyleSettings.GetShadowColor();
 }
 ImplDraw2ColorFrame( pDev, aFillRect, aColor1, aColor2 );
-++aFillRect.Left();
-++aFillRect.Top();
---aFillRect.Right();
---aFillRect.Bottom();
 }
 
 if ( !(nStyle & BUTTON_DRAW_NOFILL) )
 {
+pDev->SetLineColor();
 if ( nStyle & (BUTTON_DRAW_CHECKED | BUTTON_DRAW_DONTKNOW) )
 pDev->SetFillColor( rStyleSettings.GetCheckedColor() );
 else
@@ -704,15 +701,12 @@ void DecorationView::DrawFrame( const Rectangle& rRect,
 const Color& rLeftTopColor,
 const Color& rRightBottomColor )
 {
-Rectangle   aRect   = mpOutDev->LogicToPixel( rRect );
-Color   aOldLineColor   = mpOutDev->GetLineColor();
-Color   aOldFillColor   = mpOutDev->GetFillColor();
-sal_BoolbOldMapMode = mpOutDev->IsMapModeEnabled();
-mpOutDev->EnableMapMode( sal_False );
-mpOutDev->SetLineColor();
+Rectangle   aRect = mpOutDev->LogicToPixel( rRect );
+const Color aOldLineColor = mpOutDev->GetLineColor();
+const bool  bOldMapMode   = mpOutDev->IsMapModeEnabled();
+mpOutDev->EnableMapMode( false );
 ImplDraw2ColorFrame( mpOutDev, aRect, rLeftTopColor, rRightBottomColor );
 mpOutDev->SetLineColor( aOldLineColor );
-mpOutDev->SetFillColor( aOldFillColor );
 mpOutDev->EnableMapMode( bOldMapMode );
 }
 
@@ -908,8 +902,6 @@ static void ImplDrawFrame( OutputDevice* pDev, Rectangle& rRect,
 }
 else
 {
-pDev->SetLineColor();
-
 if ( (nFrameStyle == FRAME_DRAW_IN) ||
  (nFrameStyle == FRAME_DRAW_OUT) )
 {
@@ -925,11 +917,6 @@ static void ImplDrawFrame( OutputDevice* pDev, Rectangle& rRect,
  rStyleSettings.GetLightColor(),
  rStyleSettings.GetShadowColor() );
 }
-
-rRect.Left()++;
-rRect.Top()++;
-rRect.Right()--;
-rRect.Bottom()--;
 }
 else // FRAME_DRAW_DOUBLEIN || FRAME_DRAW_DOUBLEOUT
 {
@@ -959,12 +946,6 @@ static void ImplDrawFrame( OutputDevice* pDev, Rectangle& rRect,
 
 }
 
-

[Libreoffice] [PATCH] Decoview cleanup #5 - embed (erroneusly) external support function

[Matteo Casalin]

Hi,
   please find attached a patch that removes the ImplDraw2ColorFrame 
support function from OutputDevice and moves it into DecorationView, 
which is its only caller. This function did not logically fit into 
OutputDevice, anyway.


The attached patch is contributed under LGPL3+/MPL1.1 license.

Matteo
>From d485e0fcd8132ddd503f5acb20dd9c0864f08cc5 Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 4 Dec 2011 15:25:04 +0100
Subject: [PATCH 3/4] DecoView cleanup - Embed
 OutputDevice::ImplDraw2ColorFrame

---
 vcl/inc/vcl/outdev.hxx |1 -
 vcl/source/gdi/outdev6.cxx |   14 ---
 vcl/source/window/decoview.cxx |   76 +++-
 3 files changed, 44 insertions(+), 47 deletions(-)

diff --git a/vcl/inc/vcl/outdev.hxx b/vcl/inc/vcl/outdev.hxx
index 17b94db..d2d3809 100644
--- a/vcl/inc/vcl/outdev.hxx
+++ b/vcl/inc/vcl/outdev.hxx
@@ -489,7 +489,6 @@ public:
 SAL_DLLPRIVATE void ImplDrawColorWallpaper( long nX, long nY, long nWidth, long nHeight, const Wallpaper& rWallpaper );
 SAL_DLLPRIVATE void ImplDrawBitmapWallpaper( long nX, long nY, long nWidth, long nHeight, const Wallpaper& rWallpaper );
 SAL_DLLPRIVATE void ImplDrawGradientWallpaper( long nX, long nY, long nWidth, long nHeight, const Wallpaper& rWallpaper );
-SAL_DLLPRIVATE void ImplDraw2ColorFrame( const Rectangle& rRect, const Color& rLeftTopColor, const Color& rRightBottomColor );
 
 SAL_DLLPRIVATE void ImplDrawOutDevDirect( const OutputDevice* pSrcDev, void* pPosAry );
 SAL_DLLPRIVATE void ImplDrawBitmap( const Point& rDestPt, const Size& rDestSize,
diff --git a/vcl/source/gdi/outdev6.cxx b/vcl/source/gdi/outdev6.cxx
index 8800fd4..098d36d 100644
--- a/vcl/source/gdi/outdev6.cxx
+++ b/vcl/source/gdi/outdev6.cxx
@@ -1170,20 +1170,6 @@ void OutputDevice::Erase()
 
 // ---
 
-void OutputDevice::ImplDraw2ColorFrame( const Rectangle& rRect,
-const Color& rLeftTopColor,
-const Color& rRightBottomColor )
-{
-SetFillColor( rLeftTopColor );
-DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Left(), rRect.Bottom()-1 ) ) );
-DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Right()-1, rRect.Top() ) ) );
-SetFillColor( rRightBottomColor );
-DrawRect( Rectangle( rRect.BottomLeft(), rRect.BottomRight() ) );
-DrawRect( Rectangle( rRect.TopRight(), rRect.BottomRight() ) );
-}
-
-// ---
-
 bool OutputDevice::DrawEPS( const Point& rPoint, const Size& rSize,
 const GfxLink& rGfxLink, GDIMetaFile* pSubst )
 {
diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index 452bbb4..58f425c 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -481,6 +481,18 @@ void ImplDrawDPILineRect( OutputDevice *const pDev, Rectangle& rRect,
 }
 
 
+void ImplDraw2ColorFrame( OutputDevice *const pDev, const Rectangle& rRect,
+  const Color& rLeftTopColor, const Color& rRightBottomColor )
+{
+pDev->SetFillColor( rLeftTopColor );
+pDev->DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Left(), rRect.Bottom()-1 ) ) );
+pDev->DrawRect( Rectangle( rRect.TopLeft(), Point( rRect.Right()-1, rRect.Top() ) ) );
+pDev->SetFillColor( rRightBottomColor );
+pDev->DrawRect( Rectangle( rRect.BottomLeft(), rRect.BottomRight() ) );
+pDev->DrawRect( Rectangle( rRect.TopRight(), rRect.BottomRight() ) );
+}
+
+
 void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
  const sal_uInt16 nStyle )
 {
@@ -599,7 +611,7 @@ void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
 
 pDev->SetLineColor();
 
-pDev->ImplDraw2ColorFrame( aFillRect, aColor1, aColor2 );
+ImplDraw2ColorFrame( pDev, aFillRect, aColor1, aColor2 );
 ++aFillRect.Left();
 ++aFillRect.Top();
 --aFillRect.Right();
@@ -620,7 +632,7 @@ void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
 aColor1 = rStyleSettings.GetLightBorderColor();
 aColor2 = rStyleSettings.GetShadowColor();
 }
-pDev->ImplDraw2ColorFrame( aFillRect, aColor1, aColor2 );
+ImplDraw2ColorFrame( pDev, aFillRect, aColor1, aColor2 );
 ++aFillRect.Left();
 ++aFillRect.Top();
 --aFillRect.Right();
@@ -698,7 +710,7 @@ void DecorationView::DrawFrame( const Rectangle& rRect,
 sal_BoolbOldMapMode = mpOutDev->IsMapModeEnabled();
 mpOutDev->EnableMapMode( sal_False );
 mpOutDev->SetLineColor();
-mpOutDev->ImplDraw2ColorFrame( aRect, rLeftTopColor, rRightBottomColor );
+ImplDraw2ColorFrame( mpOutDev, aRect, rLeftTopColor, rRightBottomColor );
 mpOutDev->

[Libreoffice] [PATCH] Decoview cleanup #4 - embed support function

[Matteo Casalin]

Hi,
   please find attached a patch which rewrites the DrawButton function.

The attached patch is contributed under LGPL3+/MPL1.1 license.

Matteo
>From 2c0dde2798b800ee3fb95c4e54fa9b7f693727cb Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 4 Dec 2011 12:18:49 +0100
Subject: [PATCH 2/4] Decoview cleanup - DrawButton

---
 vcl/source/window/decoview.cxx |  508 
 1 files changed, 249 insertions(+), 259 deletions(-)

diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index 9abd97e..452bbb4 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -430,6 +430,214 @@ void ImplDrawSymbol( OutputDevice* pDev, Rectangle nRect, const SymbolType eType
 }
 }
 
+
+void ImplDrawDPILineRect( OutputDevice *const pDev, Rectangle& rRect,
+  const Color *const pColor, const bool bRound = false )
+{
+long nLineWidth = pDev->ImplGetDPIX()/300;
+long nLineHeight = pDev->ImplGetDPIY()/300;
+if ( !nLineWidth )
+nLineWidth = 1;
+if ( !nLineHeight )
+nLineHeight = 1;
+
+if ( pColor )
+{
+if ( (nLineWidth == 1) && (nLineHeight == 1) )
+{
+pDev->SetLineColor( *pColor );
+if( bRound )
+{
+pDev->DrawLine( Point( rRect.Left()+1, rRect.Top()), Point( rRect.Right()-1, rRect.Top()) );
+pDev->DrawLine( Point( rRect.Left()+1, rRect.Bottom()), Point( rRect.Right()-1, rRect.Bottom()) );
+pDev->DrawLine( Point( rRect.Left(), rRect.Top()+1), Point( rRect.Left(), rRect.Bottom()-1) );
+pDev->DrawLine( Point( rRect.Right(), rRect.Top()+1), Point( rRect.Right(), rRect.Bottom()-1) );
+}
+else
+{
+pDev->SetFillColor();
+pDev->DrawRect( rRect );
+}
+}
+else
+{
+const long nWidth = rRect.GetWidth();
+const long nHeight = rRect.GetHeight();
+pDev->SetLineColor();
+pDev->SetFillColor( *pColor );
+pDev->DrawRect( Rectangle( rRect.TopLeft(), Size( nWidth, nLineHeight ) ) );
+pDev->DrawRect( Rectangle( rRect.TopLeft(), Size( nLineWidth, nHeight ) ) );
+pDev->DrawRect( Rectangle( Point( rRect.Left(), rRect.Bottom()-nLineHeight ),
+   Size( nWidth, nLineHeight ) ) );
+pDev->DrawRect( Rectangle( Point( rRect.Right()-nLineWidth, rRect.Top() ),
+   Size( nLineWidth, nHeight ) ) );
+}
+}
+
+rRect.Left()   += nLineWidth;
+rRect.Top()+= nLineHeight;
+rRect.Right()  -= nLineWidth;
+rRect.Bottom() -= nLineHeight;
+}
+
+
+void ImplDrawButton( OutputDevice *const pDev, Rectangle aFillRect,
+ const sal_uInt16 nStyle )
+{
+const StyleSettings& rStyleSettings = pDev->GetSettings().GetStyleSettings();
+
+if ( (nStyle & BUTTON_DRAW_MONO) ||
+ (rStyleSettings.GetOptions() & STYLE_OPTION_MONO) )
+{
+const Color aBlackColor( COL_BLACK );
+
+if ( nStyle & BUTTON_DRAW_DEFAULT )
+{
+// default selection shows a wider border
+ImplDrawDPILineRect( pDev, aFillRect, &aBlackColor );
+}
+
+ImplDrawDPILineRect( pDev, aFillRect, &aBlackColor );
+
+Size aBrdSize( 1, 1 );
+if ( pDev->GetOutDevType() == OUTDEV_PRINTER )
+{
+aBrdSize = pDev->LogicToPixel( Size( 20, 20 ), MapMode(MAP_100TH_MM) );
+if ( !aBrdSize.Width() )
+aBrdSize.Width() = 1;
+if ( !aBrdSize.Height() )
+aBrdSize.Height() = 1;
+}
+
+pDev->SetLineColor();
+pDev->SetFillColor( aBlackColor );
+const Rectangle aOrigFillRect(aFillRect);
+if ( nStyle & (BUTTON_DRAW_PRESSED | BUTTON_DRAW_CHECKED) )
+{
+// shrink fill rect
+aFillRect.Left() += aBrdSize.Width();
+aFillRect.Top()  += aBrdSize.Height();
+// draw top and left borders (aOrigFillRect-aFillRect)
+pDev->DrawRect( Rectangle( aOrigFillRect.Left(), aOrigFillRect.Top(),
+   aOrigFillRect.Right(), aFillRect.Top()-1 ) );
+pDev->DrawRect( Rectangle( aOrigFillRect.Left(), aOrigFillRect.Top(),
+   aFillRect.Left()-1, aOrigFillRect.Bottom() ) );
+}
+else
+{
+// shrink fill rect
+aFillRect.Right()  -= aBrdSize.Width();
+aFillRect.Bottom() -= aBrdSize.Height();
+// draw bottom and right borders (aOrigFillRect-aFillRect)
+pDev->DrawRect( Rectangle( aOrigFillRect.Left(), aFillRect.Bottom()+1,
+   aOrigFillRect.Right(), aOrigFillRect.Bottom() ) );
+pDev->DrawRect( Rectangle( aFillRect.Right()+1, a

[Libreoffice] [PATCHES] Decoview cleanup - remove unneeded header

[Matteo Casalin]

Hi,
   please find attached a patch continuing DecoView cleanup, simply 
removing an header file no longer needed (since my previous cleanup patch)


The attached patch is contributed under LGPL3+/MPL1.1 license.

Matteo


>From 7a77d1c5fb3447a664c2167f434c310cc4499709 Mon Sep 17 00:00:00 2001
From: Matteo Casalin 
Date: Sun, 27 Nov 2011 09:58:48 +0100
Subject: [PATCH 1/4] Removed unused header

---
 vcl/source/window/decoview.cxx |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/vcl/source/window/decoview.cxx b/vcl/source/window/decoview.cxx
index e8ed434..9abd97e 100644
--- a/vcl/source/window/decoview.cxx
+++ b/vcl/source/window/decoview.cxx
@@ -27,7 +27,6 @@
  /
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.7.5.4

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

Re: [Libreoffice] [PUSHED] a few more translations

[Lionel Elie Mamane]

On Sun, Dec 04, 2011 at 12:14:57AM -0800, Mike Whiteley wrote:

> I respectfully disagree with some of your recommendations.

I can be mistaken. Let's discuss the points where you disagree.

> As long as the basic point is getting across, I think it is probably
> good enough.

Yes, but:

> This will take forever, if we have to be 100% consistent with the
> machine version,

"Machine version"? What are you talking about?

> They are just comments,
> and even then, some of them are poorly worded and ambiguous.

Oh yes, they are, I agree with you there.

> Striving to be 100% consistent with the German comments is not
> always the best way to go about this.

Yes, but when I said "closer to the German", I should have said
"closer to what I guess the code that is commented is. I don't know if
you are a programmer, so that you can make a good guess at the code
organisation, but in this particular point, the meaning of the German
makes - to me - more programming sense than the meaning of the
English."

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

Re: [Libreoffice] Windows (MSVC) incremental build is broken.

[Jan Holesovsky]

Hi Kohei, Tor,

Tor Lillqvist píše v So 03. 12. 2011 v 12:56 +0200:

> > Kendy (this time CC'd), please don't commit this stuff.  It breaks
> > incremental build on Windows, making debugging Windows impossible.
> 
> Hear, hear. If we want beta1 to be better than beta0, we can't require
> people having to make clean after each edit, and rebuild from scratch
> (effectively making the fix-test-commit cycle take one day).

Then again - if we want to have beta1 at all, we have to be able to do
clean builds ;-)

So; of course the right solution would be to try to edit

http://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/filter-showIncludes.pl#n41

to get rid of the rewriting of X: -> /cygdrive/x, and see if it fixes
the incremental rebuilds [ie. if the GNU make handles the Windows
paths].  Maybe also touching the gbuild code that calls
filter-showIncludes.pl would be necessary.

If it does not, then indeed revert, but together with _fixing_ glib
stuff not to rely on OUTDIR in the Windows format; most probably by
cygpath'ing it somewhere here:

http://cgit.freedesktop.org/libreoffice/core/tree/glib/glib-2.28.1-win32.patch#n61

Unfortunately I was unable to try either of them on Thu and Fri; but -
having a broken tinderbox tends to pile Windows breakages, and act as a
snowball that creates an avalanche.  From my point of view (because it
is me who fixes the Windows tinderboxes regularly these days), it is
more important to have the clean builds working.

So - when you did not have the time to do either of the above [as me], I'd
prefer if you reverted just locally + pinged me on IRC immediately when
there was an opportunity, to increase its priority; we could have saved
this embarrassing commit / revert / commit / revert thing ;-)

Thank you,
Kendy


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

Re: [Libreoffice] Windows (MSVC) incremental build is broken.

[Jan Holesovsky]

Hi Kohei, Tor,

Tor Lillqvist píše v So 03. 12. 2011 v 12:56 +0200:

> > Kendy (this time CC'd), please don't commit this stuff.  It breaks
> > incremental build on Windows, making debugging Windows impossible.
> 
> Hear, hear. If we want beta1 to be better than beta0, we can't require
> people having to make clean after each edit, and rebuild from scratch
> (effectively making the fix-test-commit cycle take one day).

Then again - if we want to have beta1 at all, we have to be able to do
clean builds ;-)

So; of course the right solution would be to try to edit

http://cgit.freedesktop.org/libreoffice/core/tree/solenv/gbuild/filter-showIncludes.pl#n41

to get rid of the rewriting of X: -> /cygdrive/x, and see if it fixes
the incremental rebuilds [ie. if the GNU make handles the Windows
paths].  Maybe also touching the gbuild code that calls
filter-showIncludes.pl would be necessary.

If it does not, then indeed revert, but together with _fixing_ glib
stuff not to rely on OUTDIR in the Windows format; most probably by
cygpath'ing it somewhere here:

http://cgit.freedesktop.org/libreoffice/core/tree/glib/glib-2.28.1-win32.patch#n61

Unfortunately I was unable to try either of them on Thu and Fri; but -
having a broken tinderbox tends to pile Windows breakages, and act as a
snowball that creates an avalanche.  From my point of view (because it
is me who fixes the Windows tinderboxes regularly these days), it is
more important to have the clean builds working.

So - when you did not have the time to do either of the above, I'd
prefer if you reverted just locally + pinged me on IRC immediately when
there was an opportunity, to increase its priority; we could have saved
this embarrassing commit / revert / commit / revert thing ;-)

Thank you,
Kendy

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

Re: [Libreoffice] [PUSHED] a few more translations

[Mike Whiteley]

This might have been a bit harsh.  It seems like you have
taken more time on this, and your versions are better and more
clear than mine, so good job there.

I'll try to be a little more careful in my subsequent translations.

Mike

On Sun, Dec 4, 2011 at 12:14 AM, Mike Whiteley  wrote:
> I respectfully disagree with some of your recommendations.
> Are you fluent in German?
>
> As long as the basic point is getting across, I think it is probably
> good enough.  This will take forever, if we have to be 100%
> consistent with the machine version, and these have to go through
> 3 levels of review before they get through.
>
> They are just comments,
> and even then, some of them are poorly worded and ambiguous.
> Striving to be 100% consistent with the German comments is not
> always the best way to go about this.
>
> Since there are 30K lines of German code to translate,
> perhaps we can be a little forgiving of what you think are
> technical errors.
>
> Thank you for the review and git recommendations.
>
> Respectfully,
>
> Mike
>
> On Sat, Dec 3, 2011 at 11:18 PM, Lionel Elie Mamane  wrote:
>> On Thu, Dec 01, 2011 at 07:11:04PM -0800, Mike Whiteley wrote:
>>
>>> From 3fb61e525f5a15fab65c6ab494d5c4d0135a2471 Mon Sep 17 00:00:00 2001
>>> From: mikew 
>>> Date: Thu, 1 Dec 2011 19:13:20 -0800
>>> Subject: [PATCH] translated some comments from German to English
>>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED] a few more translations

[Mike Whiteley]

I respectfully disagree with some of your recommendations.
Are you fluent in German?

As long as the basic point is getting across, I think it is probably
good enough.  This will take forever, if we have to be 100%
consistent with the machine version, and these have to go through
3 levels of review before they get through.

They are just comments,
and even then, some of them are poorly worded and ambiguous.
Striving to be 100% consistent with the German comments is not
always the best way to go about this.

Since there are 30K lines of German code to translate,
perhaps we can be a little forgiving of what you think are
technical errors.

Thank you for the review and git recommendations.

Respectfully,

Mike

On Sat, Dec 3, 2011 at 11:18 PM, Lionel Elie Mamane  wrote:
> On Thu, Dec 01, 2011 at 07:11:04PM -0800, Mike Whiteley wrote:
>
>> From 3fb61e525f5a15fab65c6ab494d5c4d0135a2471 Mon Sep 17 00:00:00 2001
>> From: mikew 
>> Date: Thu, 1 Dec 2011 19:13:20 -0800
>> Subject: [PATCH] translated some comments from German to English
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice