date:20120402


On 03/31/2012 02:10 PM, Regina Henschel wrote:

Is it intended that the old registrymodifications.xcu is overwritten?


registrymodifications.xcu typically gets re-written with every run of LO 
(even usually being re-written multiple times during a single run).  It 
changes whenever data that is stored in the configuration changes -- be 
that "Tools - Options" entries explicitly modified by the user, window 
positions/sizes implicitly modified by dragging things around, or ...


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

Re: Fwd: [tdf-discuss] LibreOffice Version Mismatch/Conflict

2012-04-02 Thread Petr Mladek

Andras Timar píše v Pá 30. 03. 2012 v 22:29 +0200:
> 2012/3/30 Petr Mladek :
> > Andras Timar píše v So 24. 03. 2012 v 16:30 +0100:
> >> Hi Petr,
> >>
> >> See the mail below. Is there a reason why we don't update VERSIONMICRO
> >> in solenv/inc/minor.mk?
> >
> > I am not sure what the version is for. I remember that we updated some
> > version in this file and it broke some import/export hacks for backward
> > compatibility.
> 
> As far as I remember, I introduced the VERSIONMICRO variable before
> 3.5 feature freeze, and it is used only in File Version field of
> Windows executables. The same is true for VERSIONMAJOR and
> VERSIONMINOR. It is safe to bump them, when necessary.

Good to know. I do not remember any mail about this new variable. :-)
Why was it introduced and how is it supposed to be used?

> > For example, see the check for nUPD == 350 in the recent commit
> > http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=befb1c7e26b79ae97d802659f3386882d4044251
> >
> > I am not sure what exact version string affects getBuildIds() function.
> > I just know that we need to be careful with modifying versions in that
> > minor.mk :-)
> 
> That 350 (and other values at this location) look like the version
> string of the Master Workspace (MWS), it is not constructed from
> VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO. This version number is
> generated by configure script, in line 3383. It is
> AC_PACKAGE_VERSION+0 and it is called UPD. AC_PACKAGE_VERSION is
> defined by AC_INIT, it is hardcoded in configure.in.
> The getBuildIds() function reads UPD (and build id, that is defined in
> minor.mk as well).

Ah, it is even bigger mess than I expected.


> > Ugh, the versioning is a real mess. The versions are defined on many
> > locations and used different ways. It is a good candidate for general
> > cleanup. Whoever would like to dig into it, please step up.
> 
> Now, for the 3.5.3 it would solve the inconsistencies, if you bumped
> VERSIONMICRO from minor.mk to 3, and if you displayed 3.5.3.buildid in
> About box. That way file versions on Windows, About box version and
> MSI version would be the same.

The question is what number we want to use for the buildid.

In the past, the windows installer used 3.5 version and we needed to use
the micro version in the buildid. We used the following scheme
to make it predictable:

  bugfixrelease micro + 0 + rcnumber

, so we get:

  buildid 101 for 3.5.1-rc1
  buildid 102 for 3.5.1-rc2
  buildid 201 for 3.5.1-rc1

If we use what you suggest, we will get in the about dialog:

  3.5.1.101 for 3.5.1-rc1
  3.5.1.102 for 3.5.1-rc2
  3.5.2.201 for 3.5.2-rc1

IMHO, it is ugly because the micro version is there twice.

How the windows installer distinguish the build version these days? Does
it use the VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO? Could we restart
buildid for each bugfix release and get the following?

buildid 1 for rc1
buildid 2 for rc2

The we could have in the about dialog what we use now:

  3.5.1.1 for 3.5.1-rc1
  3.5.1.2 for 3.5.1-rc2
  3.5.2.1 for 3.5.2-rc1


Best Regards,
Petr

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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


Hi Stephan,

Stephan Bergmann schrieb:

On 03/31/2012 02:10 PM, Regina Henschel wrote:

Is it intended that the old registrymodifications.xcu is overwritten?


registrymodifications.xcu typically gets re-written with every run of LO
(even usually being re-written multiple times during a single run). It
changes whenever data that is stored in the configuration changes -- be
that "Tools - Options" entries explicitly modified by the user, window
positions/sizes implicitly modified by dragging things around, or ...


It is about the fact, that all existing entries are lost. I had a 947KB 
file and after installation of LO3.6 it is 36KB. Even die fields "User 
Data" are empty.


Kind regards
Regain

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

Re: [PATCH] [Bug 47450] SVG: treat skewX and skewY correct


Hi Chrstina,

Chr. Rossmanith schrieb:

Hi Regina,

LibreOffice 3.6.0alpha0+ did not treat the skews correctly, that's why
I've sent the patch. Did you try both ways "Open->File->SVG test file"
and "Insert->Picture from file->SVG test file"? Only the first has
problems.


I see. I had only tried with Insert->Picture. Open->File is indeed still 
wrong in LO3.6.


Kind regards
Regina


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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


On 04/02/2012 10:41 AM, Regina Henschel wrote:

Stephan Bergmann schrieb:

On 03/31/2012 02:10 PM, Regina Henschel wrote:

Is it intended that the old registrymodifications.xcu is overwritten?


registrymodifications.xcu typically gets re-written with every run of LO
(even usually being re-written multiple times during a single run). It
changes whenever data that is stored in the configuration changes -- be
that "Tools - Options" entries explicitly modified by the user, window
positions/sizes implicitly modified by dragging things around, or ...


It is about the fact, that all existing entries are lost. I had a 947KB
file and after installation of LO3.6 it is 36KB. Even die fields "User
Data" are empty.


On Windows?  There was an issue with LO migrating existing user data 
onto itself (in which case it would drop most existing content of 
registrymodifications.xcu), but that should be fixed on master for a 
month now, see 
 
"Move migrateSettingsIfNecessary into create_user_install" and 
 
"User installation migrated onto itself."


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

Re: [PATCH] Fix RTF list level text follow

2012-04-02 Thread Miklos Vajna

Hi Brennan,

On Sat, Mar 31, 2012 at 03:37:20PM -0700, Brennan T Vincent 
 wrote:
> RTF documents including lists now have the list level text ("1." or
> similar) followed by the correct thing (space, tab, or nothing) as
> specified in the document, whereas previously they were always followed by
> tab.
> 
> I also updated the RTF exporter to correctly save RTF files containing
> non-default values for this parameter.

Thanks for the patch! It looks mostly correct,

> diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.hxx 
> b/writerfilter/source/rtftok/rtfdocumentimpl.hxx
> index eb7e27a..4a2f549 100644
> --- a/writerfilter/source/rtftok/rtfdocumentimpl.hxx
> +++ b/writerfilter/source/rtftok/rtfdocumentimpl.hxx
> @@ -286,6 +286,9 @@ namespace writerfilter {
>  /// List of character positions in leveltext to replace.
>  std::vector aLevelNumbers;
>  
> +/// What to follow the number in a list by. 0: tab; 1: 
> space; 2: nothing
> +int nLevelFollow;

Except this: is this really needed? As far as I see, it's not used.

Also:

- Please do a 'git commit -a', and 'git format-patch -1', and send us
  the result, not the output of 'git diff', as described here:

http://wiki.documentfoundation.org/Development#Preparing_patches

- Lastly, can you confirm that your contribution is provided under the
  project license?

Sending a mail to the list, saying:

"All of my past and future contributions to the LibreOffice project are
under LGPLv3+/GPLv3+/MPL until further notice."

should be enough. (You only need this once.)

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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


[putting libreoffice@ back on cc, assuming you dropped it inadvertently]

On 04/02/2012 11:23 AM, Regina Henschel wrote:

Stephan Bergmann schrieb:

On 04/02/2012 10:41 AM, Regina Henschel wrote:

Stephan Bergmann schrieb:

On 03/31/2012 02:10 PM, Regina Henschel wrote:

Is it intended that the old registrymodifications.xcu is overwritten?


registrymodifications.xcu typically gets re-written with every run
of LO
(even usually being re-written multiple times during a single run). It
changes whenever data that is stored in the configuration changes -- be
that "Tools - Options" entries explicitly modified by the user, window
positions/sizes implicitly modified by dragging things around, or ...


It is about the fact, that all existing entries are lost. I had a 947KB
file and after installation of LO3.6 it is 36KB. Even die fields "User
Data" are empty.


On Windows?


Yes, on WinXP.

There was an issue with LO migrating existing user data onto

itself (in which case it would drop most existing content of
registrymodifications.xcu), but that should be fixed on master for a
month now, see


"Move migrateSettingsIfNecessary into create_user_install" and


"User installation migrated onto itself."


I have pulled the source on Friday, so that's included. Is it possible,
that it fails because the old one was a normal build and the new one is
a debug build?


So you have a "LO3.5dev" and a master build sharing a user installation 
(what are the respective UserInstallation values in the two 
bootstrap.ini?).  Debug vs. non-debug should not matter.  Would be 
interesting to know what branch your master build takes in 
UserInstall::finalize (desktop/source/app/userinstall.cxx), what 
UserInstallStatus it returns, and whether it indeed goes into the 
conditional


  if (inst_fin == UserInstall::Created)
  {
Migration::migrateSettingsIfNecessary();
  }

in Desktop::Main (desktop/source/app/app.cxx).

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

Re: Exception specifications on functions useless?

On Tuesday 20 of March 2012, Lubos Lunak wrote:
> - C++11 deprecates it and instead introduces a noexcept keyword which
> forbids the function to throw anything
>
>  I'm not strongly biased either way, but what we have right now are really
> just pretty comments on functions. I think we should either say that we use
> the specifications, in which case -fno-enforce-sh-specs should not be used
> at least in debug builds, or we can say we follow the C++11/Boost/etc.
> trend and not use them, in which case we can have one macro for portable
> way of saying noexcept and have an EasyHack for removing the other
> specifications. BTW, it should be also noted that SAL_THROW() expands to
> nothing with gcc.
>
>  Opinions on this?

 Could this be please added to the next TSC agenda? It doesn't look to me like 
there's a clear consensus, and not caring much myself about either 
possibility, I don't want to do any change. I'll at most 
remove -fno-enforce-eh-specs from --enable-dbgutil builds if there's no 
resolution on this, so that clang is not the only compiler to find mistakes.

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

Re: [Libreoffice-qa] [ANN] LibreOffice 3.5.2 RC2 test builds available

2012-04-02 Thread Petr Mladek

Pedro Lino píše v Čt 29. 03. 2012 v 19:06 +0100:
> Hi all,
> 
> Did anyone verify that the version info is updated (re the
> secunia
> reports problem)
> 
> 
> I think Secunia has already fixed the numbering so that the warning it
> gone for version 3.5.1.
> 
> But the Version number in the file Properties for 3.5.2rc2 is now
> 3.5.0.202 instead of 3.5.2.2
> 
> Unless there is an rc3 and this is fixed meanwhile LO is going to get
> a bad image with Secunia (and all the security minded people :) )

Why could it cause bad image? IMHO, it was bug on the Secunia side and
it is fixed now. We used this version scheme also for LO-3.4 and nobody
complained.

> Personally I couldn't care less about Secunia but since it only takes
> a small number change, I think it would be worth the effort :)

It looks trivial but it is not. We would need to do clean build for all
systems, upload them to mirrors, restart smoketests, ... So, this change
would delay the release by many days.

Also, it is potentially dangerous. The version is defined and used on
many locations. Any change could cause strange side effects. Also there
are many scripts around that depends on a certain version scheme. So, we
should not change this between rc2 and rc3 if there is not a big reason.

Well, I agree that 3.5.0.202 is ugly. We are discussion to use the more
reasonable version scheme 3.5.2.2 now, see
http://lists.freedesktop.org/archives/libreoffice/2012-April/029263.html
If it goes well, we might try it for 3.5.3 release.


Best Regards,
Petr

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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


Stephan Bergmann schrieb:

[putting libreoffice@ back on cc, assuming you dropped it inadvertently]


Yes. (I don't like the settings of this mailing list, but it is the tool 
of the main developers and I need to take it as it is.)



On 04/02/2012 11:23 AM, Regina Henschel wrote:

Stephan Bergmann schrieb:

On 04/02/2012 10:41 AM, Regina Henschel wrote:

Stephan Bergmann schrieb:

On 03/31/2012 02:10 PM, Regina Henschel wrote:

Is it intended that the old registrymodifications.xcu is overwritten?


registrymodifications.xcu typically gets re-written with every run
of LO
(even usually being re-written multiple times during a single run). It
changes whenever data that is stored in the configuration changes
-- be
that "Tools - Options" entries explicitly modified by the user, window
positions/sizes implicitly modified by dragging things around, or ...


It is about the fact, that all existing entries are lost. I had a 947KB
file and after installation of LO3.6 it is 36KB. Even die fields "User
Data" are empty.


On Windows?


Yes, on WinXP.

There was an issue with LO migrating existing user data onto

itself (in which case it would drop most existing content of
registrymodifications.xcu), but that should be fixed on master for a
month now, see



"Move migrateSettingsIfNecessary into create_user_install" and



"User installation migrated onto itself."


I have pulled the source on Friday, so that's included. Is it possible,
that it fails because the old one was a normal build and the new one is
a debug build?


So you have a "LO3.5dev" and a master build sharing a user installation
(what are the respective UserInstallation values in the two
bootstrap.ini?).


No, I only have "LOdev 3.6". "LOdev 3.5" was removed during installation 
of "LOdev 3.6". Therefore I have expected that the settings were migrated.


In bootstap.ini is
ProductKey=LOdev 3.6
UserInstallation=$SYSUSERCONFIG/LOdev/3

I cannot look in LOdev 3.5 because it was uninstalled. But LOdev 3.6 
uses the same "user"-folder. Other things like Basic macros are retained.


 Debug vs. non-debug should not matter. Would be

interesting to know what branch your master build takes in
UserInstall::finalize (desktop/source/app/userinstall.cxx), what
UserInstallStatus it returns, and whether it indeed goes into the
conditional

if (inst_fin == UserInstall::Created)
{
Migration::migrateSettingsIfNecessary();
}

in Desktop::Main (desktop/source/app/app.cxx).

Stephan



Kind regards
Regina

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

Re: Headless for everything in build? (Re: [Libreoffice-commits] .: hwpfilter/CppunitTest_hwpfilter_test_hwpfilter.mk)

On Thursday 29 of March 2012, Caolán McNamara wrote:
> On Thu, 2012-03-29 at 16:56 +0200, Lubos Lunak wrote:
> >  Is there any need to run UI stuff during build? IOW, can't we simply
> > globally force using headless for everything during build?
>
> Unix has the env SAL_USE_VCLPLUGIN=svp which would force headless mode.
> Though I don't think macosx or windows honors that, hence the --headless

 I see. On the other hand, I think it's only Unix where it matters, as only 
there we use vclplugs (which I'm not even sure have proper make dependencies 
on), and only those should possibly time out on D-Bus.

> I'm not sure why e.g. the fairly simple hwpfilter test, or any of them
> really, would end up triggering anything UI-related. I guess there might
> be some painful-to-fix assumption somewhere that tries to create a
> dialog or render some text into a drawable and want to query the
> desktop-settings for the default fontoptions on the system or some such
> which cascades out of control.

 I have checked that adding --headless to all cppunittests passes make check 
fine, and at least some tinderboxes build without any UI available, so I 
think it makes sense to simply use it always and not require manual addition 
to every single test. Committed as 802518c59a2cf4b47ff893305ad9781db4353ec2 .

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

Re: [PATCH] Make LibreOffice waterproof


On Sun, 2012-04-01 at 19:08 +0200, Jesús Corrius wrote:
> * Resistance of operative parts. Immersion in 10 cm of water with a
> force of 5 N perpendicular to the About Box for 10 minutes.

Is that the old, or the new Andrew Higginson About Box ? I expect the
new one to be substantially more water-proof :-)

Nice work !

Michael.

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

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

Android UI work


  
  
Hey Michael,  Tor, and all

I have an initial android project I created for the UI which can be
integrated into the core. I have a git hub repository here 

https://github.com/eagles051387/LibreOffice-Android-UI-

My question though is what would be the best way to hook that
project in with the core, as well as submit it for inclusion into
the core repository so that we have an initial beginning for others
to clone the android UI stuff from the LO source instead of my
github respository above. Correct me if I am wrong in assuming this
(not trying to make an ass out of you and me or anyone for that
matter with my assumption ;) ), but from what I can see is that the
android project generates its own files during compile, and puts
them in the project tree structure in their respective directories.

Please let me know how you would like me to proceed. I will try get
a screen shot when I have a bit more time this afternoon. The UI was
developed and tested on an HTC Desire HD instead of using an AVD.



  

  Regards
  Jonathan Aquilina

  


  

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

Re: Android UI work

> https://github.com/eagles051387/LibreOffice-Android-UI-
>

I notice that you have committed also "binaries" (build output files, even
temporary ones) into git...

Looking at the actual (single) source file (
https://github.com/eagles051387/LibreOffice-Android-UI-/blob/master/LoDroidUI/src/loDroid/UI/LO_Program_Selector.java),
I see maybe five lines of non-boilerplate code?


> My question though is what would be the best way to hook that project in
> with the core,
>

At this stage, I think that would be just a waste of time.

Do we even know if we want just one Android app that would contain all the
"aspects" (text, spreadsheet, presentation, drawing, database, formula)? I
find it likely that it would be better to have separate apps. In that case
we don't even need such a UI for selecting which aspect to start.

For instance Apple's office app suite for iOS consists of three separate
apps (text, spreadsheet, presentation) (i.e. Pages, Numbers and Keynote).

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

[REVIEW: 3-5] fdo#47963 ext. list shrinks when resizing window

2012-04-02 Thread David Tardon

Hi,

the problem is that height of the "user/shared/installation" checkboxes
at the bottom of the dialog is increased by 3 pixels on each call of
Resize(). This is obviously a mistake and commit
c4c6b52a214b474353013f9b1b03d56a5d9a0380 fixes it.

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

Re: Android UI work

On 4/2/12 12:52 PM, Tor Lillqvist wrote:

https://github.com/eagles051387/LibreOffice-Android-UI-

I notice that you have committed also "binaries" (build output files,
even temporary ones) into git...

Looking at the actual (single) source file
(https://github.com/eagles051387/LibreOffice-Android-UI-/blob/master/LoDroidUI/src/loDroid/UI/LO_Program_Selector.java
), I see maybe five lines of non-boilerplate code?

So the menu xml file and the single java file would be sufficient to
commit to the LO repository, and nothing else?

My question though is what would be the best way to hook that
project in with the core,

At this stage, I think that would be just a waste of time.

Do we even know if we want just one Android app that would contain all
the "aspects" (text, spreadsheet, presentation, drawing, database,
formula)? I find it likely that it would be better to have separate
apps. In that case we don't even need such a UI for selecting which
aspect to start.

I am not saying a single app, I in a way trying to keep it with an
application chooser that would for instance open up the respectily
chosen application. The menu I did is equivalent to the application
chooser on linux mac etc. I have yet to start on the in application
menus for writer for instance.

For instance Apple's office app suite for iOS consists of three
separate apps (text, spreadsheet, presentation) (i.e. Pages, Numbers
and Keynote).

--tml

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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit

On 26/03/12 11:56, Noel Grandin wrote:
> Hi
> 
> I note that some of the C++ unit tests are being run from JUnit, which 
> seems counter-intuitive.

writing C++ unit tests in Java would be rather impossible.

there are however various UNO API tests that are written in Java with
JUnit, i guess you're talking about those.

> Is there is a good reason for this, or would it simplify matters to 
> convert them to CppUnit?

the tests that are implemented in the "qadevOOo" module (aka "unoapi"
tests, run via various $MODULE/qa/unoapi/$MODULE.sce files) are pretty
awful in general and replacing them with something better and reliable,
however implemented, is a good idea.

the other kind of JUnit based tests are so-called "complex" tests
(usually in $MODULE/qa/complex), and those are in general rather more
sensible (especially the ones i've written :), so i don't see a need to
do anything about those really, and replacing these with something that
rather inevitably ends up not being a real unit test either, just
implemented in C++, sounds like pointless busywork to me.

regards,
 michael

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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


On 04/02/2012 12:18 PM, Regina Henschel wrote:

I have pulled the source on Friday, so that's included. Is it possible,
that it fails because the old one was a normal build and the new one is
a debug build?


So you have a "LO3.5dev" and a master build sharing a user installation
(what are the respective UserInstallation values in the two
bootstrap.ini?).


No, I only have "LOdev 3.6". "LOdev 3.5" was removed during installation
of "LOdev 3.6". Therefore I have expected that the settings were migrated.


Note the following difference:

If the UserInstallation settings of two installations point to the same 
directory (after expanding macros like $SYSUSERCONFIG), no user data 
should be migrated, but the two installations should actually share a 
single user data instance.  registrymodifications.xcu should not shrink 
in this case.  Everything else looks like a bug (and debugging into the 
desktop/source/app/ code would be necessary to find out more).


IIUC, only if the UserInstallation settings of the two installations 
point to different directories should migration kick in.  And in that 
case, it is normal and expected that the migrated 
registrymodifications.xcu in the new installation is substantially 
smaller than the original one in the old installation (as not all the 
configuration changes are intended to be migrated).


Stephan


In bootstap.ini is
ProductKey=LOdev 3.6
UserInstallation=$SYSUSERCONFIG/LOdev/3

I cannot look in LOdev 3.5 because it was uninstalled. But LOdev 3.6
uses the same "user"-folder. Other things like Basic macros are retained.

Debug vs. non-debug should not matter. Would be

interesting to know what branch your master build takes in
UserInstall::finalize (desktop/source/app/userinstall.cxx), what
UserInstallStatus it returns, and whether it indeed goes into the
conditional

if (inst_fin == UserInstall::Created)
{
Migration::migrateSettingsIfNecessary();
}

in Desktop::Main (desktop/source/app/app.cxx).

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

Re: Android UI work

> So the menu xml file and the single java file would be sufficient to commit
> to the LO repository, and nothing else?

The "bin" and "gen" directories should not be in source control.

> I am not saying a single app, I in a way trying to keep it with an
> application chooser that would for instance open up the respectily chosen
> application.

The user interface of *Android* itself is an app chooser. I am farily
sure one is not supposed to work around that and have one's own "app
chooser" app that "opens up" sub-apps.

Anyway, before we get so far that we can actually edit (and thus
create) documents on Android, we intend to make viewer apps, as far as
I know. So most likely the normal way to start such a viewer would be
by associating it with a MIME type (or whatever the corresponding
Android terminology is), so that if one clicks such a document in a
web browser, it gets downloaded and viewed in the LO-based app.

> The menu I did is equivalent to the application chooser on
> linux mac etc.

And that is something not needed on Android (or iOS). (In fact,
personally I think the "Start Centre" (as I think its official name
is) makes little sense on normal desktop OSes, either, and we keep it
just because we don't have the courage (or the UX resources) to get
rid of it...)

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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit

2012-04-02 Thread Noel Grandin




On 2012-04-02 13:16, Michael Stahl wrote:
there are however various UNO API tests that are written in Java with 
JUnit, i guess you're talking about those. 

That is correct.

the tests that are implemented in the "qadevOOo" module (aka "unoapi" 
tests, run via various $MODULE/qa/unoapi/$MODULE.sce files) are pretty 
awful in general and replacing them with something better and 
reliable, however implemented, is a good idea. 


So moving them to CppUnit would at least be a step in the right direction?



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


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

[PUSHED] Re: GSOC 2012 , submitting a patch for easy hack

2012-04-02 Thread Olivier Hallot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

comitted .

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

Regards

Em 01-04-2012 03:25, kud360 escreveu:
> 
> 
> On Sun, Apr 1, 2012 at 5:09 AM, Olivier Hallot [via Document Foundation
> Mail Archive] <[hidden email]
> > wrote:
> 
> Hi Karam
> 
> Em 31-03-2012 13:29, kud360 escreveu:
>> Done .. also I had made a new topic in the Dev section marked with
> [PATCH] as
>> suggested
> 
> 
> Please correct the font spacing dialog as shown in this image, where
> the
> help button does not fit inside the dialog box. You must increase the
> dialog height, and possibly balance the leftmost text to avoid a large
> blank space below it.
> 
> And resubmit your patch in this list (not in nabble).
> 
> Thank you
> 
> 
> ___
> LibreOffice mailing list
> [hidden email] 
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
> *imagem19.png* (22K) Download Attachment
> 
> 
> 
> 
> If you reply to this email, your message will be added to the
> discussion below:
> 
> http://nabble.documentfoundation.org/GSOC-2012-submitting-a-patch-for-easy-hack-tp3872816p3874382.html
> 
> To unsubscribe from GSOC 2012 , submitting a patch for easy hack,
> click here.
> NAML
> 
> 
> 
> 
> 
> 
> *0001-Added-Help-Buttons-to-dialog-buttons-in-starmath.patch* (24K)
> Download Attachment
> 
> 
> 
> View this message in context: Re: GSOC 2012 , submitting a patch for
> easy hack
> 
> Sent from the Dev mailing list archive
>  at Nabble.com.
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPeY4mAAoJEJp3R7nH3vLxGCIIALh9ZV2eYm38upYobWvOdr0q
2HjGtAr1ThK9scaAXUR8LLB7Cr6aCYmkhwiOubihzdr4qPJVo0xuGEVLksd/KPTy
RbcXl2oCs1YEqZ9ObRiCs375p9RNRPM9VwCcESCoZJMgGpI258yqlwX654tqwSEW
1td2dZnoSbpicr7OTjh7tM7wNN/YKnerfSc0pIciI4J1NYgKy6WhT+M+sas3AFte
n1DY85SMXxu5Oh4Qf1o5Y4zGa/zrQEGXXJLaeId5MKzN237dzWMLT1FhwcqGpK7C
luV7LfFq8quv16yRM1chGEvdL8y84paAG7aiI39iIbGqXN2G8a1Qav01fmgGmRw=
=koPr
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Android UI work


On 4/2/12 1:17 PM, Tor Lillqvist wrote:

So the menu xml file and the single java file would be sufficient to commit
to the LO repository, and nothing else?

The "bin" and "gen" directories should not be in source control.


I am not saying a single app, I in a way trying to keep it with an
application chooser that would for instance open up the respectily chosen
application.

The user interface of *Android* itself is an app chooser. I am farily
sure one is not supposed to work around that and have one's own "app
chooser" app that "opens up" sub-apps.
I think though we could still keep something like this, but when an app 
is chosen, the start center on the device is unloaded, and the 
appropriate app is started therefore eliminating the need for any sub 
applications whats so ever.




Anyway, before we get so far that we can actually edit (and thus
create) documents on Android, we intend to make viewer apps, as far as
I know. So most likely the normal way to start such a viewer would be
by associating it with a MIME type (or whatever the corresponding
Android terminology is), so that if one clicks such a document in a
web browser, it gets downloaded and viewed in the LO-based app.
Would you recommend i revamp the menu to allow for now just open and 
choosing of a file and opening it and displaying it on screen?



The menu I did is equivalent to the application chooser on
linux mac etc.

And that is something not needed on Android (or iOS). (In fact,
personally I think the "Start Centre" (as I think its official name
is) makes little sense on normal desktop OSes, either, and we keep it
just because we don't have the courage (or the UX resources) to get
rid of it...)

--tml


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

Re: old registrymodifications.xcu is overwritten by LO3.6dev


Hi Stephan,

Stephan Bergmann schrieb:

On 04/02/2012 12:18 PM, Regina Henschel wrote:

I have pulled the source on Friday, so that's included. Is it possible,
that it fails because the old one was a normal build and the new one is
a debug build?


So you have a "LO3.5dev" and a master build sharing a user installation
(what are the respective UserInstallation values in the two
bootstrap.ini?).


No, I only have "LOdev 3.6". "LOdev 3.5" was removed during installation
of "LOdev 3.6". Therefore I have expected that the settings were
migrated.


Note the following difference:

If the UserInstallation settings of two installations point to the same
directory (after expanding macros like $SYSUSERCONFIG), no user data
should be migrated, but the two installations


LOdev3.6 does not install beside LOdev3.5 but replaces it. So there is 
only one installation.


 should actually share a

single user data instance. registrymodifications.xcu should not shrink
in this case. Everything else looks like a bug (and debugging into the
desktop/source/app/ code would be necessary to find out more).


I have submitted https://bugs.freedesktop.org/show_bug.cgi?id=48188

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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit

On 02/04/12 13:29, Noel Grandin wrote:
> 
> 
> On 2012-04-02 13:16, Michael Stahl wrote:

>> the tests that are implemented in the "qadevOOo" module (aka "unoapi" 
>> tests, run via various $MODULE/qa/unoapi/$MODULE.sce files) are pretty 
>> awful in general and replacing them with something better and 
>> reliable, however implemented, is a good idea. 
> 
> So moving them to CppUnit would at least be a step in the right direction?

sure, as long as you're not just blindly translating the stupid qadevOOo
test to C++; the biggest potential for improvement is to make the tests
more thorough and more specific to the service that is being tested
(e.g. the qadevOOo XPropertySet test is almost completely useless
because it is completely generic).

a good place to start would be the one sub-test of sc_unoapi that runs
for 10 minutes or so, perhaps the only example of a qadevOOo test that
has the _inverse_ problem and is overly thorough :)

also, a lot of tests are commented out since ages (there are actually 2
mechanisms for disabling them: disable the entire service in the .sce
file, or disable a single interface via a knownissues.xcl file); if you
start with these then we can actually expand test coverage (though there
is some risk that you run into some core bug that needs fixing).

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

Re: Android UI work

> I think though we could still keep something like this, but when an app is
> chosen, the start center on the device is unloaded,

"unloaded", you mean it exits? Android app processes should never exit
by own choice. If you leave an app, it just stays in the background.
It's the OS that then kills the (background) process if it is taking
too much resources.

In general, the application lifecycle on all (relevant) modern
non-desktop OSes is like this, as far as I know. The idea of
applications exiting due to some user action is gone.

> and the appropriate app is started therefore eliminating the need for any sub 
> applications

When I said "sub application" I meant a LO-based text, spreadsheet,
presentation etc app.

 > Would you recommend i revamp the menu to allow for now just open and
> choosing of a file and opening it and displaying it on screen?

I don't think so. I think our viewer apps will be started
automatically by the system thanks to being associated with some MIME
types (or whatever the terminology is).

Do comparable Android apps really have "file choosers"? (I just have
the emulator, which is somewhat painful to use, and no 3rd-party apps.
But at least in the bare OS without any 3rd-party apps I couldn't,
quickly looking, find anything corresponding to a "file explorer"
even. Which is as expected, surely?)

As always, I am open to be convinced otherwise if you show me examples...

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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit

2012-04-02 Thread Noel Grandin




On 2012-04-02 13:43, Michael Stahl wrote:
sure, as long as you're not just blindly translating the stupid 
qadevOOo test to C++;

Ah, but that's why it's an __EasyHack__ :-)

But yes, I agree, building upon such a change to improve the test 
infrastructure is a better idea.


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


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

Re: Android UI work

>  I couldn't, quickly looking, find anything corresponding to a "file explorer"
> even. Which is as expected, surely?)

(I meant that I think it is expected that there is no "file explorer",
not that a such would be expected.)

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

Re: Android UI work


On Mon, 2012-04-02 at 14:17 +0300, Tor Lillqvist wrote:
> And that is something not needed on Android (or iOS). (In fact,
> personally I think the "Start Centre" (as I think its official name
> is) makes little sense on normal desktop OSes, either, and we keep it
> just because we don't have the courage (or the UX resources) to get
> rid of it...)

Some app-stores require that only a single app-icon is installed, eg.
Intel App-Up; it's nice to have that shell/start-centre for those cases
I guess.

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: Android UI work


SNIP.

  >  Would you recommend i revamp the menu to allow for now just open and

choosing of a file and opening it and displaying it on screen?

I don't think so. I think our viewer apps will be started
automatically by the system thanks to being associated with some MIME
types (or whatever the terminology is).

Do comparable Android apps really have "file choosers"? (I just have
the emulator, which is somewhat painful to use, and no 3rd-party apps.
But at least in the bare OS without any 3rd-party apps I couldn't,
quickly looking, find anything corresponding to a "file explorer"
even. Which is as expected, surely?)
I stand corrected, The office suite i know that is available for 
android, granted its a paid application, basically has files associated 
with the respective app to load them.


http://www.androidappsource.com/images/icons/-1874687392502665318_0_screenshot.png. 
Would this be the way we would want to take things?



As always, I am open to be convinced otherwise if you show me examples...

--tml


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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit


On 04/02/2012 01:29 PM, Noel Grandin wrote:

So moving them to CppUnit would at least be a step in the right direction?


I don't think simply rewriting them from Java to C++ in their current 
form is worth it.  It would be better to replace them with better tests. 
 And once these better tests offer coverage comparable to the old ones, 
we can finally ditch them.


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

Re: Android UI work


On 4/2/12 1:17 PM, Tor Lillqvist wrote:

SNIP

The user interface of *Android* itself is an app chooser. I am farily
sure one is not supposed to work around that and have one's own "app
chooser" app that "opens up" sub-apps.

Anyway, before we get so far that we can actually edit (and thus
create) documents on Android, we intend to make viewer apps, as far as
I know. So most likely the normal way to start such a viewer would be
by associating it with a MIME type (or whatever the corresponding
Android terminology is), so that if one clicks such a document in a
web browser, it gets downloaded and viewed in the LO-based app.
I just did a some looking up :) and found what i need to do for the MIME 
types, which is something I will work on this evening :) and update my 
repository.


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

Re: Android UI work

2012-04-02 Thread Charles-H. Schulz

Jonathan,

Le Mon, 02 Apr 2012 13:35:02 +0200,
Jonathan Aquilina  a écrit :

> >> The menu I did is equivalent to the application chooser on
> >> linux mac etc.
> > And that is something not needed on Android (or iOS). (In fact,
> > personally I think the "Start Centre" (as I think its official name
> > is) makes little sense on normal desktop OSes, either, and we keep
> > it just because we don't have the courage (or the UX resources) to
> > get rid of it...)
> >

May I also suggest, from a non-developer perspective, that you
coordinate your work with the UX and design team ? They're been writing
specs for an Android interface, if I remember well. 

Thank you,
-- 
Charles-H. Schulz
Co-founder & Director,
The Document Foundation.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Headless for everything in build? (Re: [Libreoffice-commits] .: hwpfilter/CppunitTest_hwpfilter_test_hwpfilter.mk)

2012-04-02 Thread Caolán McNamara

On Sat, 2012-03-31 at 16:25 +0200, Enrico Weigelt wrote:
> Directly using freetype (without any useless wrapper) seems to be the
> right way.

What useless wrapper is that ?

C.

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

Re: Android UI work


On 4/2/12 2:11 PM, Charles-H. Schulz wrote:

Jonathan,

Le Mon, 02 Apr 2012 13:35:02 +0200,
Jonathan Aquilina  a écrit :


The menu I did is equivalent to the application chooser on
linux mac etc.

And that is something not needed on Android (or iOS). (In fact,
personally I think the "Start Centre" (as I think its official name
is) makes little sense on normal desktop OSes, either, and we keep
it just because we don't have the courage (or the UX resources) to
get rid of it...)


May I also suggest, from a non-developer perspective, that you
coordinate your work with the UX and design team ? They're been writing
specs for an Android interface, if I remember well.

Thank you,

Thanks for the heads up charles :) will include them in my next email :)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Android UI work

2012-04-02 Thread Alexander Thurgood

Le 02/04/12 13:45, Tor Lillqvist a écrit :

Hi Tor,


> Do comparable Android apps really have "file choosers"? (I just have
> the emulator, which is somewhat painful to use, and no 3rd-party apps.

Yes, quite a few office suite editing apps (and not just viewers) still
do have either a basic file explorer or else they hook into a 3rd party one.

Examples :

Androffice : http://www.androffice.com/

ThinkFree Office (not ODF capable)

Symphony

OpenOffice Document Reader (offers a choice of built-in file browser or
hooked to 3rd party)

DocumentsToGo (non ODF capable)

Softmaker Textmaker


Alex








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

Re: Android UI work

> http://www.androidappsource.com/images/icons/-1874687392502665318_0_screenshot.png.
> Would this be the way we would want to take things?

Hmm, yeah, I stand corrected; clearly comparable apps *do* have
something like a "file chooser". (Although very miminal compared to
file choosers on desktop OSes.) I have no idea what directories one
can browse with that. Just some area private to the app? How does one
get documents into it? By saving documents downloaded from the web and
opened in the app?

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

Re: Android UI work


On 4/2/12 2:32 PM, Alexander Thurgood wrote:

Le 02/04/12 13:45, Tor Lillqvist a écrit :

Hi Tor,



Do comparable Android apps really have "file choosers"? (I just have
the emulator, which is somewhat painful to use, and no 3rd-party apps.

Yes, quite a few office suite editing apps (and not just viewers) still
do have either a basic file explorer or else they hook into a 3rd party one.
The thing is is it necessary to display all the directories in the file 
system?


Examples :

Androffice : http://www.androffice.com/

ThinkFree Office (not ODF capable)

I am just using it more for the UI more then anything.


Symphony

OpenOffice Document Reader (offers a choice of built-in file browser or
hooked to 3rd party)

DocumentsToGo (non ODF capable)

Softmaker Textmaker


Alex








___
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: new gdb pretty printers in master


On Sun, 2012-04-01 at 16:39 +0200, David Tardon wrote:
> over the past few days I knocked together pretty printers for some boost
> stuff. I have created a project for it at
> http://code.google.com/p/boost-gdb-printers/ (in (probably vain) hope it

Oh wow ! :-)

> It works automagically--all you need to do get it is

You rock :-) I've spent quite a white staring at somewhat impenetrable
and unreadable stl containers in the past.

Good work !

Michael.

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

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

Re: Android UI work


On 4/2/12 2:34 PM, Tor Lillqvist wrote:

http://www.androidappsource.com/images/icons/-1874687392502665318_0_screenshot.png.
Would this be the way we would want to take things?

Hmm, yeah, I stand corrected; clearly comparable apps *do* have
something like a "file chooser". (Although very miminal compared to
file choosers on desktop OSes.) I have no idea what directories one
can browse with that. Just some area private to the app? How does one
get documents into it? By saving documents downloaded from the web and
opened in the app?

--tml

From what I am seeing with thinkfree office, as Alexander mentioned it 
doesnt support ODF but I am just using it for the UI look and to see 
what I need to do for this project. But it lists the entire directory 
tree then you navigate to the directory where the file is downloaded.

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

Re: Android UI work

2012-04-02 Thread Jovan Kostovski

On Mon, Apr 2, 2012 at 2:11 PM, Charles-H. Schulz
 wrote:
> May I also suggest, from a non-developer perspective, that you
> coordinate your work with the UX and design team ? They're been writing
> specs for an Android interface, if I remember well.

Great suggestion Charles, here a link to that discussion
http://nabble.documentfoundation.org/Re-Libreoffice-ux-advise-Android-design-td3720082.html
and a link to some of the mock-ups
http://clickortap.wordpress.com/frivl/

Jonathan, write if you need help, I'm an experienced Android dev,
commit the changes and I'll clone the repo ;)
One suggestion:
In the file LO_Program_Selector.java i see that you're defining
static final String[] APPLICATION = new String[]
If you use the same strings for displaying texts in the UI you better
put them in strings.xml so that they get translated
when we do internationalization of the app.
If you use them just as identifier it would be better if you make them
as a integers or even a new class LoApplication or similar.

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

Re: Android UI work


On 4/2/12 2:51 PM, Jovan Kostovski wrote:

On Mon, Apr 2, 2012 at 2:11 PM, Charles-H. Schulz
  wrote:

May I also suggest, from a non-developer perspective, that you
coordinate your work with the UX and design team ? They're been writing
specs for an Android interface, if I remember well.

Great suggestion Charles, here a link to that discussion
http://nabble.documentfoundation.org/Re-Libreoffice-ux-advise-Android-design-td3720082.html
and a link to some of the mock-ups
http://clickortap.wordpress.com/frivl/


Jonathan, write if you need help, I'm an experienced Android dev,
commit the changes and I'll clone the repo ;)
One suggestion:
In the file LO_Program_Selector.java i see that you're defining
static final String[] APPLICATION = new String[]
If you use the same strings for displaying texts in the UI you better
put them in strings.xml so that they get translated
when we do internationalization of the app.
If you use them just as identifier it would be better if you make them
as a integers or even a new class LoApplication or similar.
I did this in a hurry basing it off the hello world tutorial. Do you 
have skype or anything that way we can discuss off list any issues i 
might encounter with out needing to cause any noise on here.


Regards.


BR,
Jovan
___
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

[REVIEW 3-5] registry key in SDK installer

Hi,

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4c725f72df1253e5d4e61ede750b4b24c1e1672
This commit fixes a (potential) problem in SDK's Windows installer.
The install location of corresponding LibreOffice version could not be
detected correctly.

Please cherry pick to libreoffice-3-5 branch.

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

Re: [PATCH] Fix memory errors in SwWW8ImplReader

On Saturday 31 of March 2012, Arnaud Versini wrote:
> Hi,
>
> This patch prevent and fix memory issue in SwWW8ImplReader. 

 Did you base your patch just on your valgrind findings, or do you have also 
some other base for these changes, such as something in the .doc spec?

 You are right that reading of some of the sprm's is broken, but looking at 
the first problem with the test document in Read_UL(), it is called with nId 
= 0x246D, which is sprmPFContextualSpacing, and the .doc spec for that one 
says it's 1 byte, while e.g. nId = 0xA413, sprmPDyaBefore, is 2 bytes 
according to the spec. So as far as I understand it, somebody was a bit lazy 
and lumped together two slightly different things, which should otherwise be 
read differently, and the proper fix would be to always read the exact size 
depending on the nId. On the other hand, looking at the end of 
WW8AttributeOutput::FormatULSpace(), we apparently do write 
sprmPFContextualSpacing as 2 bytes, which seems wrong.

 So could you please explain why you decided to fix the problem this way?

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

[REVIEW 3-5] fdo#34324 Math icon color bug

Hi,

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b36a42fb831b853120928e05dcf322898a92a731
This commit fixes fdo#34324. Icon of LibreOffice Math was in
grayscale, and was displayed with wrong colors (blue instead of white)
in Quickstarter menu under Linux.

Please cherry pick to libreoffice-3-5 branch.

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

[PUSHED] Re: [PATCH][REVIEW] Fix memory leak in SwWW8ImplReader::ReadPlainChars

On Sunday 01 of April 2012, Arnaud Versini wrote:
> Hi,
>
> This patch fix a memory leak in SwWW8ImplReader::ReadPlainChars during
> import of the RTF specification (
> http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10725in
> doc format).

 Altered slightly to avoid the copy in the OUString constructor and pushed, 
thank you.

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

Re: Excessive exception size cost ...

On 27/03/12 13:53, Caolán McNamara wrote:
> On Thu, 2012-03-08 at 17:05 +, Michael Meeks wrote:

>>  It is also a markedly higher proportion than mozilla:
> 
> Maybe large bits of mozilla are compiled without exceptions ?,
> historically at least given https://developer.mozilla.org/en/C
> ++_Portability_Guide#Don%27t_use_exceptions exceptions seems to have
> been avoided.

there appear to be plans to use C++ exceptions in mozilla land, though a
quick search doesn't seem to find anything about when and how these
things were actually implemented:

http://blog.mozilla.com/tglek/2007/12/19/exceptions/
http://blog.mozilla.com/tglek/2007/11/26/mozilla-2-outparamdel/
https://wiki.mozilla.org/Exceptions

>>  They provide us with very little real value since we just abort when
>> they are thrown in ~all cases.
> 
> These specific bad_alloc exceptions or all of our exceptions?, because
> trying to e.g. revert to a global -fno-exceptions world seems
> impractical.

indeed:
http://blog.mozilla.com/nnethercote/2011/01/18/the-dangers-of-fno-exceptions/


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

Re: Android UI work

On 02/04/12 13:17, Tor Lillqvist wrote:
> (In fact,
> personally I think the "Start Centre" (as I think its official name
> is) makes little sense on normal desktop OSes, either, and we keep it
> just because we don't have the courage (or the UX resources) to get
> rid of it...)

OOo 2.x used to present an ugly empty grey window when you close the
last document, but that was somehow deemed absolutely unacceptable to
show to Mac users, so for the native Mac GUI port in OOo 3.0 the Start
Centre was designed (in its fully gradiented glory) so it can be shown
to those posh Mac users in the case when no document is opened.

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

Re: [REVIEWED: 3-5][PUSHED] fdo#47963 ext. list shrinks when resizing window

Hi,

2012/4/2 David Tardon :
> Hi,
>
> the problem is that height of the "user/shared/installation" checkboxes
> at the bottom of the dialog is increased by 3 pixels on each call of
> Resize(). This is obviously a mistake and commit
> c4c6b52a214b474353013f9b1b03d56a5d9a0380 fixes it.
>
The fix works and there are no side-effects. Cherry-picked to libreoffice-3-5.

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

Re: Android UI work

> so for the native Mac GUI port in OOo 3.0 the Start
> Centre was designed (in its fully gradiented glory) so it can be shown
> to those posh Mac users in the case when no document is opened.

("posh"?)

Oh, odd, as that's not how "normal" Mac apps work, is it?

If you have no documents open in TextEdit, for instance, no window is
open (but the TextEdit menu bar still is showing). So if the Start
Centre was designed because of Mac, somebody was misunderstanding how
Mac apps behave. Or am *I* misunderstanding? Or do some (3rd-party?)
Mac apps behave like LO, and display a special "no-document-open"
window when no documents are open? Are such apps considered exhibiting
a good UI according to current Mac UI design standards?

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

Re: [PATCH] Fix memory errors in SwWW8ImplReader

2012-04-02 Thread Miklos Vajna

Hi Lubos,

On Mon, Apr 02, 2012 at 03:04:22PM +0200, Lubos Lunak  wrote:
>  You are right that reading of some of the sprm's is broken, but looking at 
> the first problem with the test document in Read_UL(), it is called with nId 
> = 0x246D, which is sprmPFContextualSpacing, and the .doc spec for that one 
> says it's 1 byte, while e.g. nId = 0xA413, sprmPDyaBefore, is 2 bytes 
> according to the spec. So as far as I understand it, somebody was a bit lazy 
> and lumped together two slightly different things, which should otherwise be 
> read differently, and the proper fix would be to always read the exact size 
> depending on the nId.

They are read in the same method, since they are all part of the same
SvxULSpaceItem.

> On the other hand, looking at the end of 
> WW8AttributeOutput::FormatULSpace(), we apparently do write 
> sprmPFContextualSpacing as 2 bytes, which seems wrong.

Both reading and writing of sprmPFContextualSpacing should be fixed with
http://cgit.freedesktop.org/libreoffice/core/commit/?id=36e176ee2354e62d5e4208fb0ae2a101ba32d7f5

Hope this helps. :)

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

Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5

On 28/03/12 12:26, Tor Lillqvist wrote:
>> MARKER: These services are not intended to be instantiated via their service 
>> names.
> 
> How is it in general with service names, if one browses services.rdb
> (either of them), one doesn't have to look long to notice components
> that have identical service names (but different implementation
> names). What does this mean? That they are not supposed to be
> instantiated via service names but via implementation names? Sorry if
> this is a very fundamental question, but I guess I never fully have
> understood UNO...

indeed i've also noticed that; in many cases there are actually multiple
implementations for a given service.  sometimes, these are for generic
things like e.g. enumerations that are only available via some getter or
property from another service, and in that case an implementation name
may or may not exist; but in other cases, the service is actually
instantiated via a factory, and the implementation name is necessary;
the first example that comes to mind is the import/export filter
service, which is implemented once per application per file format, and
of course you want to be using the specific one for the format the user
selected.

> Hmm, I now see that the first such duplicated service name I come
> across just visually browsing is css.frame.ContentHandler, which you
> indeed mark with MARKER in your message.
> 
>> (And there's unfortunately lots of these, needlessly obscuring things in 
>> many ways.)
> 
> Indeed. Is there any point at all in cluttering services.rdb (and
> other configuration files?) with these components if they aren't
> looked for from there at run-time anyway?

hmm... good question... perhaps they are necessary for runtime
introspection, i.e. services implement a getSupportedServiceNames method
that returns these and then some introspection thing can look up
metadata from the RDB, like what interfaces and properties may be available.

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

[PATCH] remove unused code (oox)

2012-04-02 Thread Petr Vorel

Hi there,

removed unused classes from oox.

Regards,
Petr
>From b4350501d1fe85da2cce5750b480e33eb6409301 Mon Sep 17 00:00:00 2001
From: Petr Vorel 
Date: Mon, 2 Apr 2012 11:40:06 +0200
Subject: [PATCH] remove unused code (oox)

---
 oox/inc/oox/dump/dumperbase.hxx |   18 --
 oox/inc/oox/dump/oledumper.hxx  |   21 ---
 oox/source/dump/dumperbase.cxx  |  107 
 oox/source/dump/oledumper.cxx   |  114 ---
 unusedcode.easy |   17 --
 5 files changed, 0 insertions(+), 277 deletions(-)

diff --git a/oox/inc/oox/dump/dumperbase.hxx b/oox/inc/oox/dump/dumperbase.hxx
index 7f18220..a099886 100644
--- a/oox/inc/oox/dump/dumperbase.hxx
+++ b/oox/inc/oox/dump/dumperbase.hxx
@@ -395,7 +395,6 @@ public:
 // token list -
 
 static void appendToken( ::rtl::OUStringBuffer& rStr, const ::rtl::OUString& rToken, sal_Unicode cSep = OOX_DUMP_LISTSEP );
-static void appendToken( ::rtl::OUStringBuffer& rStr, sal_Int64 nToken, sal_Unicode cSep = OOX_DUMP_LISTSEP );
 
 static void appendIndex( ::rtl::OUStringBuffer& rStr, const ::rtl::OUString& rIdx );
 static void appendIndex( ::rtl::OUStringBuffer& rStr, sal_Int64 nIdx );
@@ -1074,9 +1073,6 @@ public:
 voidwriteColRowRange( sal_Int32 nColRow1, sal_Int32 nColRow2 );
 voidwriteColRange( sal_Int32 nCol1, sal_Int32 nCol2 );
 voidwriteRowRange( sal_Int32 nRow1, sal_Int32 nRow2 );
-voidwriteAddress( const Address& rPos );
-voidwriteRange( const Range& rRange );
-voidwriteRangeList( const RangeList& rRanges );
 
 template< typename Type >
 inline void writeDec( Type nData, sal_Int32 nWidth = 0, sal_Unicode cFill = ' ' )
@@ -1349,17 +1345,6 @@ protected:
 voidwriteArrayItem( const String& rName, const sal_uInt8* pnData, sal_Size nSize, sal_Unicode cSep = OOX_DUMP_LISTSEP );
 voidwriteDateTimeItem( const String& rName, const ::com::sun::star::util::DateTime& rDateTime );
 voidwriteGuidItem( const String& rName, const ::rtl::OUString& rGuid );
-voidwriteColIndexItem( const String& rName, sal_Int32 nCol );
-voidwriteRowIndexItem( const String& rName, sal_Int32 nRow );
-voidwriteColRangeItem( const String& rName, sal_Int32 nCol1, sal_Int32 nCol2 );
-voidwriteRowRangeItem( const String& rName, sal_Int32 nRow1, sal_Int32 nRow2 );
-voidwriteAddressItem( const String& rName, const Address& rPos );
-voidwriteRangeItem( const String& rName, const Range& rRange );
-voidwriteRangeListItem( const String& rName, const RangeList& rRanges );
-voidwriteTokenAddressItem( const String& rName, const TokenAddress& rPos, bool bNameMode );
-voidwriteTokenAddress3dItem( const String& rName, const ::rtl::OUString& rRef, const TokenAddress& rPos, bool bNameMode );
-voidwriteTokenRangeItem( const String& rName, const TokenRange& rRange, bool bNameMode );
-voidwriteTokenRange3dItem( const String& rName, const ::rtl::OUString& rRef, const TokenRange& rRange, bool bNameMode );
 
 template< typename Type >
 voidaddNameToItem( Type nData, const NameListWrapper& rListWrp );
@@ -1753,9 +1738,6 @@ protected:
 const OutputObjectBase& rParent,
 const BinaryInputStreamRef& rxStrm,
 rtl_TextEncoding eTextEnc );
-voidconstruct(
-const InputObjectBase& rParent,
-rtl_TextEncoding eTextEnc );
 
 virtual boolimplIsValid() const;
 virtual voidimplDump();
diff --git a/oox/inc/oox/dump/oledumper.hxx b/oox/inc/oox/dump/oledumper.hxx
index 4d3ceaa..64d3d5c 100644
--- a/oox/inc/oox/dump/oledumper.hxx
+++ b/oox/inc/oox/dump/oledumper.hxx
@@ -84,27 +84,6 @@ protected:
 };
 
 // 
-
-class StdHlinkObject : public OleInputObjectBase
-{
-public:
-explicitStdHlinkObject( const InputObjectBase& rParent );
-
-protected:
-virtual voidimplDump();
-
-private:
-::rtl::OUString dumpHyperlinkString( const String& rName, bool bUnicode );
-
-booldumpGuidAndMoniker();
-voiddumpUrlMoniker();
-voiddumpFileMoniker();
-voiddumpItemMoniker();
-voiddumpAntiMoniker();
-voiddumpCompositeMoniker();
-};
-
-// 
 // =

Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5

On 28/03/12 12:11, Stephan Bergmann wrote:
> * CTORS accessible.AccessBridge:  This service being of interface type 
> XInitialization looks strange.  (XInitialization is more of an internal 
> interface, so that instances of such a service can obtain arguments when 
> being constructed.  Explicit constructors of new-style services 
> internally call it.)

i wonder, this XInitialization always seemed to be like some backward
compatibility kludge, would it be possible to get rid of this for LO4
and pass the arguments to the C++ ctor of the implementing class
directly or at least a static factory method or something like that, or
is there some reason why that wouldn't work?

> * MODULE:  These services are not intended to be instantiated at the 
> global component context/service manager, but rather via 
> document-specific factories.  (Some that I labelled MODULE might 
> actually be MARKER -- I did not look too close.)

but it would actually be possible use a hypothetical document-specific
component context to construct these.  which currently does not exist
for any application, so maybe it doesn't make sense to expose such
constructors just yet :)

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

Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5

2012-04-02 Thread Caolán McNamara

On Mon, 2012-04-02 at 16:15 +0200, Michael Stahl wrote:
> would it be possible to get rid of this for LO4 and pass the arguments
> to the C++ ctor of the implementing class

I guess one potential gotcha is that you can't call virtual methods on
your in-construction object in a C++ ctor while ::initialize happens
after construction so it can.

C.

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

string / size bits ... #2 ...


On Fri, 2012-03-30 at 15:21 +0100, Michael Meeks wrote:
>   I up-loaded the output of my string debug for a writer start:

And discovered there was a bazillion problems with it, in particular
the handling of OUStrings, having nailed that - it now has some
considerable error due to 'String' handling; nevertheless a new version:

http://www.gnome.org/~michael/llog4.txt.gz

is up;

re-running that shows:

$ zcat /tmp/llog.txt.gz | grep '^+' | sort | uniq -c | sort -n -r | head -n 10

  81840 +/
  41125 +IMPLEMENTATIONS
  36468 +/IMPLEMENTATIONS/
  35796 +/IMPLEMENTATIONS
  29744 +UNO
  11341 +SERVICES
  10331 +ACTIVATOR
   7167 +en-US
   6669 +
   5204 +LOCATION

How we get 81k allocations of a string containing '/' is somewhat
curious ;-) possibly we want to have a table of static one-char ascii
strings for the one character entries - to save atomic ref-counting
thrash, and pointless often transient allocations.

Interestingly, all these top uses are newish; when I last did the
stats. As a rather less reliable dump: (due to the unreliable use of
String classes I think) - I find it hard to believe we have 19k live '/'
strings - does anyone feel guilty about that ? [ actually, I'm just
poking at the configmgr code which looks like it might be the culprit ]

37209 live strings remain at end of log

copies  string
19011   /
5910en-US
1920
689 en
650 Normal
559 void
347 com.sun.star.uno.XInterface::release
347 com.sun.star.uno.XInterface::queryInterface
347 com.sun.star.uno.XInterface::acquire
249 x-default
241 Regular
224 /UCR
219 com.sun.star.i18n.Transliteration.l10n
209 IMPLEMENTATIONS
200 com
194 com.sun.star.loader.SharedLibrary
194 -甭
175 ALIEN
169 IMPORT
159 boolean
156 Bold
154 EXPORT
142 com.sun.star.uno.XInterface

Interestingly the "com.sun.star" string shows up 286k times in the log
of alloc / deletes - oh for the day that we can stop pushing that around
as UCS2 in memory.

Anyhow - so far, I saved 1% of our memory allocate / free's by fixing
the (busted IMHO) rtl URI encode/decode - with a ~4 line patch :-) which
is encouraging, that was just noticing this:

+
+/d
-/d
+/data/
-/data/
+/data/opt/OOIn
-/data/opt/OOIn
+/data/opt/OOInstall/program/oo
-/data/opt/OOInstall/program/oo
+/data/opt/OOInstall/program/oosplash

in the URI handling code ;-) trivially fixed.

There are lots of other instances of ineffiency visible here though eg.

+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
+/
+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory

repeated a dozen+ times back to back for no obvious reason :-)

$ zcat /tmp/llog4.txt.gz | grep 
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory | wc -l
159

We seem to do this dozens of times for each of our singletons, and so
on.

Of course, the log is by no means perfect, but hopefully it shows
something useful :-)

ATB,

Michael.

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


strings.pl
Description: Perl program
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Font rendering oddities: is this already known?

2012-04-02 Thread Caolán McNamara

On Fri, 2012-03-30 at 16:22 -0300, Olivier Hallot wrote:
> Hi
> 
> The image in the link below shows some font oddities in all applications
> of LibreOffice

Is this something new ? (hopefully not). For the case of writer itself,
and the differences from pdf and on-screen etc, one piece of code that
has long been on my "figure this out" list is
http://opengrok.libreoffice.org/xref/core/sw/source/core/txtnode/fntcache.cxx#798
 and the various glyph-positioning-wiggling going on there.

C.

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

[PATCH] Fix RTF list level text follow

2012-04-02 Thread Brennan T Vincent

Miklos,

> Except this: is this really needed? As far as I see, it's not used.
You are correct, of course. I had added those lines before I fully
understood how the code worked, and forgotten to remove them. I have
updated my patch and formatted it correctly.


0001-Fix-RTF-levelfollow-import-and-export.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Legal stuff

2012-04-02 Thread Brennan T Vincent

All of my past and future contributions to the LibreOffice project are
under LGPLv3+/GPLv3+/MPL until further notice.

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

Re: string / size bits ... #2 ...

2012-04-02 Thread Noel Grandin

To make it easier to find culprits, perhaps you could add a feature to 
your script?
Use some kind of variable to select a specific string, and then store 
the callstack every time that string gets allocated, using backtrace()

Then dump the top 100 call-stacks using backtrace_symbols()

Brute force maybe, but it would make it easier to find the source(s) of 
the problems.


On 2012-04-02 16:25, Michael Meeks wrote:

On Fri, 2012-03-30 at 15:21 +0100, Michael Meeks wrote:

I up-loaded the output of my string debug for a writer start:

And discovered there was a bazillion problems with it, in particular
the handling of OUStrings, having nailed that - it now has some
considerable error due to 'String' handling; nevertheless a new version:

http://www.gnome.org/~michael/llog4.txt.gz

is up;

re-running that shows:

$ zcat /tmp/llog.txt.gz | grep '^+' | sort | uniq -c | sort -n -r | head -n 10

   81840 +/
   41125 +IMPLEMENTATIONS
   36468 +/IMPLEMENTATIONS/
   35796 +/IMPLEMENTATIONS
   29744 +UNO
   11341 +SERVICES
   10331 +ACTIVATOR
7167 +en-US
6669 +
5204 +LOCATION

How we get 81k allocations of a string containing '/' is somewhat
curious ;-) possibly we want to have a table of static one-char ascii
strings for the one character entries - to save atomic ref-counting
thrash, and pointless often transient allocations.

Interestingly, all these top uses are newish; when I last did the
stats. As a rather less reliable dump: (due to the unreliable use of
String classes I think) - I find it hard to believe we have 19k live '/'
strings - does anyone feel guilty about that ? [ actually, I'm just
poking at the configmgr code which looks like it might be the culprit ]

37209 live strings remain at end of log

copies  string
19011   /
5910en-US
1920
689 en
650 Normal
559 void
347 com.sun.star.uno.XInterface::release
347 com.sun.star.uno.XInterface::queryInterface
347 com.sun.star.uno.XInterface::acquire
249 x-default
241 Regular
224 /UCR
219 com.sun.star.i18n.Transliteration.l10n
209 IMPLEMENTATIONS
200 com
194 com.sun.star.loader.SharedLibrary
194 -?
175 ALIEN
169 IMPORT
159 boolean
156 Bold
154 EXPORT
142 com.sun.star.uno.XInterface

Interestingly the "com.sun.star" string shows up 286k times in the log
of alloc / deletes - oh for the day that we can stop pushing that around
as UCS2 in memory.

Anyhow - so far, I saved 1% of our memory allocate / free's by fixing
the (busted IMHO) rtl URI encode/decode - with a ~4 line patch :-) which
is encouraging, that was just noticing this:

+
+/d
-/d
+/data/
-/data/
+/data/opt/OOIn
-/data/opt/OOIn
+/data/opt/OOInstall/program/oo
-/data/opt/OOInstall/program/oo
+/data/opt/OOInstall/program/oosplash

in the URI handling code ;-) trivially fixed.

There are lots of other instances of ineffiency visible here though eg.

+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
+/
+SINGLETONS
+com.sun.star.deployment.thePackageManagerFactory
+/SINGLETONS/
-/SINGLETONS/
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory
-SINGLETONS
-com.sun.star.deployment.thePackageManagerFactory
-/
-/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory

repeated a dozen+ times back to back for no obvious reason :-)

$ zcat /tmp/llog4.txt.gz | grep 
+/SINGLETONS/com.sun.star.deployment.thePackageManagerFactory | wc -l
159

We seem to do this dozens of times for each of our singletons, and so
on.

Of course, the log is by no means perfect, but hopefully it shows
something useful :-)

ATB,

Michael.



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


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


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

[CFT] Windows native file/folder picker (fop/fps)

hi all,

some weeks ago on master (5142e628b563a9876e8884c5dd4914eff4a2f307) i've
merged 2 Windows-only DLLs, namely the contents of the "fop" library
into "fps":  "fop" implements a native Windows folder picker, while
"fps" implements a native Windows file picker; now both file and folder
picker are implemented by "fps" library.

it would be great if somebody could test if both native folder and file
picker still work as they did before (e.g. compare with 3.5 branch) on
the various supported Windows releases.

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

Re: Fwd: [tdf-discuss] LibreOffice Version Mismatch/Conflict

Hi Petr,

2012/4/2 Petr Mladek :
>> As far as I remember, I introduced the VERSIONMICRO variable before
>> 3.5 feature freeze, and it is used only in File Version field of
>> Windows executables. The same is true for VERSIONMAJOR and
>> VERSIONMINOR. It is safe to bump them, when necessary.
>
> Good to know. I do not remember any mail about this new variable. :-)
> Why was it introduced and how is it supposed to be used?
>

In order to fully utilize Windows installer capabilities, files should
be versioned properly. We have not reached this goal yet with 3.5, but
we are closer. In 3.4 and earlier versions file versioning was messy.
This was resolved by
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3fbedc3e8f65c91999dcee42daa8312e387dcf40
Currently VERSIONMICRO is used only in the VersionInfo resource of
executables under Windows.

>>
>> Now, for the 3.5.3 it would solve the inconsistencies, if you bumped
>> VERSIONMICRO from minor.mk to 3, and if you displayed 3.5.3.buildid in
>> About box. That way file versions on Windows, About box version and
>> MSI version would be the same.
>
> The question is what number we want to use for the buildid.
>
> In the past, the windows installer used 3.5 version and we needed to use
> the micro version in the buildid. We used the following scheme
> to make it predictable:
>
>      bugfixrelease micro + 0 + rcnumber
>
> , so we get:
>
>      buildid 101 for 3.5.1-rc1
>      buildid 102 for 3.5.1-rc2
>      buildid 201 for 3.5.1-rc1
>
> If we use what you suggest, we will get in the about dialog:
>
>      3.5.1.101 for 3.5.1-rc1
>      3.5.1.102 for 3.5.1-rc2
>      3.5.2.201 for 3.5.2-rc1
>
> IMHO, it is ugly because the micro version is there twice.
>
> How the windows installer distinguish the build version these days? Does
> it use the VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO? Could we restart
> buildid for each bugfix release and get the following?
>
>        buildid 1 for rc1
>        buildid 2 for rc2
>
> The we could have in the about dialog what we use now:
>
>      3.5.1.1 for 3.5.1-rc1
>      3.5.1.2 for 3.5.1-rc2
>      3.5.2.1 for 3.5.2-rc1

I fully agree with this versioning scheme. 3.5.3.1 will be higher than
3.5.2.202, so upgrade will happen. Note, that we cannot do this for a
hypothetical 3.5.2 rc3, because 3.5.2.3 would be lower than 3.5.2.202.

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Android UI work

2012-04-02 Thread Christian Lohmaier

Hi *,

On Mon, Apr 2, 2012 at 4:06 PM, Tor Lillqvist  wrote:
>> so for the native Mac GUI port in OOo 3.0 the Start
>> Centre was designed (in its fully gradiented glory) so it can be shown
>> to those posh Mac users in the case when no document is opened.
>
> ("posh"?)
>
> Oh, odd, as that's not how "normal" Mac apps work, is it?
>
> If you have no documents open in TextEdit, for instance, no window is
> open (but the TextEdit menu bar still is showing).

TextEdit only handles one kind of documents.

> So if the Start
> Centre was designed because of Mac, somebody was misunderstanding how
> Mac apps behave. Or am *I* misunderstanding?

In the ol' days, OpenOffice.org started with a writer document on Mac.
This lead to a load of questions like "how would I create a
spreadsheet or presentation". Or the alternative: "I want my default
document (i.e. what gets opened when I start OOo) to be a spreadsheet,
I never edit text, I only do calculations".

So the startcenter was not for when all documents are closed, but when
it is launched. (hence the name)

> Or do some (3rd-party?)
> Mac apps behave like LO,

Is there a third-party-app that is comparable to LO? I.e. has one
launcher, but handles different kind of documents?

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

Re: [CFT] Windows native file/folder picker (fop/fps)

2012-04-02 Thread Christian Lohmaier

Hi *,

On Mon, Apr 2, 2012 at 4:55 PM, Michael Stahl  wrote:
> [...]
> it would be great if somebody could test if both native folder and file
> picker still work as they did before (e.g. compare with 3.5 branch) on
> the various supported Windows releases.

Nor sure whether it is still an issue, but Windows users often had the
problem of not being able to safely remove a thumb/usb drive after
having opened (and closed of course) file from there.
IIRC it was because windows always flagged the last used folder as "in
use", the workaround was to open a file from the regular disk.

So one of the things to test...

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

[PUSHED] registry key in SDK installer


On Mon, 2012-04-02 at 15:03 +0200, Andras Timar wrote:
> This commit fixes a (potential) problem in SDK's Windows installer.
> The install location of corresponding LibreOffice version could not be
> detected correctly.

Looks reasonable 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

Legal stuff

2012-04-02 Thread karthik padmanabhan

All of my past and future contributions to the LibreOffice project are
under LGPLv3+/GPLv3+/MPL until further notice.


Regards
Karthik Anantha Padmanabhan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5


On 04/02/2012 04:15 PM, Michael Stahl wrote:

i wonder, this XInitialization always seemed to be like some backward
compatibility kludge, would it be possible to get rid of this for LO4
and pass the arguments to the C++ ctor of the implementing class
directly or at least a static factory method or something like that, or
is there some reason why that wouldn't work?


Simplifying the way UNO service instances are created (there should be 
better ways than the current nested multi/single service factories, 
IMO), there should be no reason that XInitialization is still needed for 
it.  (Virtual methods is a red herring here, btw.)  Also, that would 
finally make it possible to have different constructors for a UNO 
service with similar parameter lists.


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

Re: [PATCH] Make LibreOffice waterproof

2012-04-02 Thread Andrew Higginson

On 02/04/12 11:31, Michael Meeks wrote:
> 
> On Sun, 2012-04-01 at 19:08 +0200, Jesús Corrius wrote:
>> * Resistance of operative parts. Immersion in 10 cm of water with a
>> force of 5 N perpendicular to the About Box for 10 minutes.
> 
>   Is that the old, or the new Andrew Higginson About Box ? I expect the
> new one to be substantially more water-proof :-)
> 
>   Nice work !
> 
>   Michael.

Aww man...this slipped my mind...

Maybe we could have a look at getting this http://www.p2i.com/ under an
open source license? :P

--
Andrew

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

Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5


On 03/28/2012 12:26 PM, Tor Lillqvist wrote:

MARKER: These services are not intended to be instantiated via their service 
names.


How is it in general with service names, if one browses services.rdb
(either of them), one doesn't have to look long to notice components
that have identical service names (but different implementation
names). What does this mean? That they are not supposed to be
instantiated via service names but via implementation names? Sorry if
this is a very fundamental question, but I guess I never fully have
understood UNO...


Slide 8 ("Services of the Past") of 
 
tried to explain that.



(And there's unfortunately lots of these, needlessly obscuring things in many 
ways.)


Indeed. Is there any point at all in cluttering services.rdb (and
other configuration files?) with these components if they aren't
looked for from there at run-time anyway?


At least theoretically, applications could read that information at 
runtime.  (And it is really only .rdb files where this information is 
preserved at runtime.  For example, neither cppumaker nor javamaker 
generate output for old-style services.)


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

[REVIEWED 3-5] fdo#34324 Math icon color bug


On Mon, 2012-04-02 at 15:06 +0200, Andras Timar wrote:
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=b36a42fb831b853120928e05dcf322898a92a731
> This commit fixes fdo#34324. Icon of LibreOffice Math was in
> grayscale, and was displayed with wrong colors (blue instead of white)
> in Quickstarter menu under Linux.

That's a bit odd - we shouldn't be rendering blue for that; at least, I
don't see that in the images themselves - I wonder what's going wrong
there.

I wonder if it'd be better to fix it like this (untested):

--- a/sfx2/source/appl/shutdowniconunx.cxx
+++ b/sfx2/source/appl/shutdowniconunx.cxx
@@ -90,6 +90,9 @@ static GdkPixbuf * ResIdToPixbuf( sal_uInt16 nResId )
 Bitmap pInSalBitmap = aIcon.GetBitmap();
 AlphaMask pInSalAlpha = aIcon.GetAlpha();
 
+if( pInSalBitmap.GetBitCount() != 24 )
+pInSalBitmap.Convert( BMP_CONVERSION_24BIT );
+
 Bitmap::ScopedReadAccess pSalBitmap(pInSalBitmap);
 AlphaMask::ScopedReadAccess pSalAlpha(pInSalAlpha);


And that's not just because I'm too lazy to convert the icon paths for
the old source tree layout ;-)

Really we should share this code with GtkFrame::SetIcon, and really the
bulk of the quick-starter should live in vcl/ too but ...

Does that help ?

Michael.

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

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

[Bug 35673] LibreOffice 3.4 most annoying bugs

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|32948   |

-- 
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

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||32948

-- 
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

Re: string / size bits ... #2 ...

On Mon, 2012-04-02 at 16:52 +0200, Noel Grandin wrote:
> To make it easier to find culprits, perhaps you could add a feature to
> your script ?

Checkout sal/rtl/source/strimp.hxx and instrument the _NEW piece to
your heart's content. Potentially it'd be good to out-line that into a
concrete implementation if it grows though, to avoid the macro-ness.
Patches most welcome :-)

> Brute force maybe, but it would make it easier to find the source(s)
> of the problems.

Indeed :-) better than a git grep for the same I suppose.

ATB,

Michael.

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

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

Re: Headless for everything in build? (Re: [Libreoffice-commits] .: hwpfilter/CppunitTest_hwpfilter_test_hwpfilter.mk)


On 04/02/2012 12:27 PM, Lubos Lunak wrote:

  I have checked that adding --headless to all cppunittests passes make check
fine, and at least some tinderboxes build without any UI available, so I
think it makes sense to simply use it always and not require manual addition
to every single test. Committed as 802518c59a2cf4b47ff893305ad9781db4353ec2 .


Well, at least sal/qa/osl/security/osl_Security.cxx interprets command 
line arguments and now breaks on W2008R2@16-minimal_build.


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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit

2012-04-02 Thread Markus Mohrhard

2012/4/2 Stephan Bergmann :
> On 04/02/2012 01:29 PM, Noel Grandin wrote:
>>
>> So moving them to CppUnit would at least be a step in the right direction?
>
>
> I don't think simply rewriting them from Java to C++ in their current form
> is worth it.  It would be better to replace them with better tests.

I agree with that. But it is still a good idea what the old interface
tests did because often they had some nice ideas for corner cases that
you would normally forget. A big advantage of the c++ based tests is
that we are no longer bound to one test method for each api method.
And then there are the test documents(generated test documents) in the
java tests that I found extremelly valuable. Just storing the file in
the java api test and reusing the content to write a c++ based test is
really helpful.

> And once these better tests offer coverage comparable to the old ones, we can
> finally ditch them.
>

I would prefer an incremental process here, but that is just my
opinion. I think it makes sense every time a interface is covered by a
c++ based test that we disable the old java test and only use the new
test.

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

--- Comment #260 from Rainer Bielefeld  
2012-04-02 08:50:00 PDT ---
Add "Bug 44725 - VIEWING: Heading - Footer - Pagebreak lines appear somewhere
in the page". It's harmless and acceptable for a x.x.0, but not acceptable for
x.x.3 and a daunting view for someone who wants to try LibO. You don't get a
second chance at a first impression.

-- 
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

[Bug 37361] LibreOffice 3.5 most annoying bugs

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||44725

--- Comment #261 from Rainer Bielefeld  
2012-04-02 08:50:50 PDT ---
Now really added Bug 44725

-- 
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

Re: Android UI work

> So the startcenter was not for when all documents are closed, but when
> it is launched. (hence the name)

Ah. Yes of course, silly me. Good that I am not ashamed to admit it
when I have been talking crack.

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

Re: [PATCH] Re: build breaks - icu49 ?

2012-04-02 Thread Eike Rathke

Hi Tomáš,

On Saturday, 2012-03-31 21:52:06 +0200, Tomáš Chvátal wrote:

> Gentoo dev reporting the issue actually tried to write patch. [1]
> It is backported from ICU upstream. [2]
> Let me know if it is correct enough for commiting and I will do it.
> 
> [1] http://people.apache.org/~Arfrever/libreoffice-3.5.2.2-icu-49.patch
> [2] https://ssl.icu-
> project.org/trac/changeset/31071/icu/trunk/source/data/brkitr/char.txt

It took me some digging around to find what actually the comment in [2]
"TODO: Restore if the Prepend set becomes non-empty again" was
referring.. so, according to UAX #29 rev19 for Unicode version 6.1 we
have in section 3.1
http://www.unicode.org/reports/tr29/tr29-19.html#Default_Grapheme_Cluster_Table
Prepend: (Currently there are no characters with this value.)

UAX #29 rev17 for Unicode Version 6.0 was the last revision that listed
some characters for Prepend, and Unicode Version 6.1 changed that
handling.

Note that Prepend characters were defined only for THAI, LAO and TAI
VIET, see
http://www.unicode.org/reports/tr29/tr29-17.html#Default_Grapheme_Cluster_Table
and as our char_in.txt is used only for Indic languages the Prepend rule
shouldn't have any effect there anyway. Or I think so ...

So yes, Tomáš, I think it's safe to commit the patch.

Btw, we have a slight problem here, specifically the case if Prepend
became non-empty again we wouldn't notice other than polling UAX #29
changes, and in general using modified RBBI rules based on maybe
completely outdated rules we once adapted for an ancient ICU version.
Problem is that no one can judge on them other than native speakers AND
those have to be Unicode segmentation rules and ICU RBBI rules savvy ...

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

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

[no subject]

2012-04-02 Thread Michel Basilieres

http://www.marketersbase.com/wp-includes/theme-compat/02efpk.html";> 
http://www.marketersbase.com/wp-includes/theme-compat/02efpk.html___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Android UI work


On 02/04/2012 16:59, Christian Lohmaier wrote:

Hi *,

On Mon, Apr 2, 2012 at 4:06 PM, Tor Lillqvist  wrote:

so for the native Mac GUI port in OOo 3.0 the Start
Centre was designed (in its fully gradiented glory) so it can be shown
to those posh Mac users in the case when no document is opened.

("posh"?)

Oh, odd, as that's not how "normal" Mac apps work, is it?

If you have no documents open in TextEdit, for instance, no window is
open (but the TextEdit menu bar still is showing).

TextEdit only handles one kind of documents.


So if the Start
Centre was designed because of Mac, somebody was misunderstanding how
Mac apps behave. Or am *I* misunderstanding?

In the ol' days, OpenOffice.org started with a writer document on Mac.
This lead to a load of questions like "how would I create a
spreadsheet or presentation". Or the alternative: "I want my default
document (i.e. what gets opened when I start OOo) to be a spreadsheet,
I never edit text, I only do calculations".

So the startcenter was not for when all documents are closed, but when
it is launched. (hence the name)


Or do some (3rd-party?)
Mac apps behave like LO,

Is there a third-party-app that is comparable to LO? I.e. has one
launcher, but handles different kind of documents?


The only office suite i have seen which isnt open source or free is 
thinkfree office but it doesnt support ODF.


Is this something that would warrent a discussion of some sort via skype 
or other voip means?



ciao
Christian
___
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: Android UI work

Tor do you still feel like this is worth including even on a mobile 
device or bypassing all together?


On 02/04/2012 17:57, Tor Lillqvist wrote:

So the startcenter was not for when all documents are closed, but when
it is launched. (hence the name)

Ah. Yes of course, silly me. Good that I am not ashamed to admit it
when I have been talking crack.

--tml
___
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

[GSoC] Almost away for 3 weeks

2012-04-02 Thread Cedric Bosdonnat

Hi all,

I'll be on paternity leave during the next three weeks starting today.
For any question regarding GSoC administration, please ask Fridrich, or
make sure you have the both of us in the email loop.

I'll have some internet connection, so I'll be able to read my email
from time to time and I'll be able to evaluate the students proposals
after April 16th.

Note that the application scores shouldn't change after April 20th where
the deduplication process will start.

--
Cedric

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

Re: string / size bits ... #2 ...

2012-04-02 Thread Eike Rathke

Hi Michael,

On Monday, 2012-04-02 15:25:58 +0100, Michael Meeks wrote:

>   How we get 81k allocations of a string containing '/' is somewhat
> curious ;-)

My first shoot would be configuration paths ...

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


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

Re: Android UI work

> Tor do you still feel like this is worth including even on a mobile device
> or bypassing all together?

As long as we don't have a way to *create*
text/spreadsheet/presentation contents from scratch, I don't see the
point in having a Start Centre in a non-desktop LO-based app. I.e.
there shouldn't be any need to just start the app by itself.

But don't trust me, trust what the UX people say.

Except that they might not consider technical restrictions -- like app
size, do we really want to have a single viewer app for all kinds of
documents? Or separate ones for text/spreadsheet/presentation ones? I
have no idea.

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

Re: [REVIEW 3-5] Re: build breaks - icu49 ?

2012-04-02 Thread Tomáš Chvátal

Ok,

I commited the patch to the master, as the distros will mostly add icu49 now 
and libreoffice is the only offender that wont compile against it now please 
review the patch for 3-5 branch and commit if applicable. [1]

Cheers

Tom

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c08a84c04b166ab6479716e2c33cd444d7e3dbe

signature.asc
Description: This is a digitally signed message part.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Exception specifications on functions useless?


On Mon, 2012-04-02 at 11:59 +0200, Lubos Lunak wrote:
>  Could this be please added to the next TSC agenda ?

Yep, pushed & will invite you to the meeting :-)

ATB,

Michael.

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

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

Re: proposed easyhack: converting c++ unit tests from JUnit to CppUnit


On 04/02/2012 05:49 PM, Markus Mohrhard wrote:

2012/4/2 Stephan Bergmann:

And once these better tests offer coverage comparable to the old ones, we can
finally ditch them.


I would prefer an incremental process here, but that is just my
opinion. I think it makes sense every time a interface is covered by a
c++ based test that we disable the old java test and only use the new
test.


I'm actually fine any way we do that.  My only concern is that we do not 
retire old tests without having adequate coverage through new ones in place.


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

Re: intermittent flaw in gnumake deps on Win32 ..

2012-04-02 Thread Kevin Hunter


At 7:56am -0400 Fri, 30 Mar 2012, Christian Lohmaier wrote:

On Fri, Mar 30, 2012 at 1:05 PM, Matúš Kukan wrote:

On 30 March 2012 11:36, Michael Meeks wrote:

Regina's problem comes down to a corrupt .d file.
[...]
One more data-point, that file was exactly 4096 bytes large:


What does that mean ?


Well - it is either a coincidence, or not.. A multiple of 1024 i.e
exactly 4KB in size..


Perhaps dumb question: Is she out of space on that drive/partition?

Kevin

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

Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)

2012-04-02 Thread R Skinner


On 03/31/12 15:58, Alexander Thurgood wrote:

Le 29/03/12 13:29, R Skinner a écrit :

Hi again,

For what its worth, the build from master is currently failing for me at
the same point in the sc cppunit tests on Linux 32bit Ubuntu Oneiric,
despite repeated cleans and pulls from git master, so it would appear
that the problem is not just BSD specific.

Sounds ominous; or vindicating, whichever seems appropriate.

How does it go building with clang? Thats what I'm trying now, as 
suggested by Albert.

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

[PATCH] Remove unused HTMLMODE_FIRSTLINE

2012-04-02 Thread Harri Pitkänen

HTMLMODE_FIRSTLINE was disabled in all HTML export modes. It seems to
have been used to add first line indent for paragraphs in Netscape
version 3 but all currently available export modes use CSS for that.

Harri>From 26abdf32a398dc2bfcea60e751e0a1b3edb984c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harri=20Pitk=C3=A4nen?= 
Date: Sun, 1 Apr 2012 09:27:11 +0300
Subject: [PATCH] Remove unused HTMLMODE_FIRSTLINE

HTMLMODE_FIRSTLINE was disabled in all HTML export modes. It seems to
have been used to add first line indent for paragraphs in Netscape
version 3 but all currently available export modes use CSS for that.
---
 cui/source/tabpages/paragrph.cxx  |9 ++
 sfx2/inc/sfx2/htmlmode.hxx|1 -
 sw/source/filter/html/htmlatr.cxx |   55 +
 sw/source/ui/shells/txtattr.cxx   |2 +-
 4 files changed, 5 insertions(+), 62 deletions(-)

diff --git a/cui/source/tabpages/paragrph.cxx b/cui/source/tabpages/paragrph.cxx
index a2334b5..24ebdeb 100644
--- a/cui/source/tabpages/paragrph.cxx
+++ b/cui/source/tabpages/paragrph.cxx
@@ -611,11 +611,8 @@ void SvxStdParagraphTabPage::Reset( const SfxItemSet& rSet )
 aRightIndent.Disable();
 aTopDist.Disable();  //HTML3.2 und NS 3.0
 aBottomDist.Disable();
-if(!(nHtmlMode & HTMLMODE_FIRSTLINE)) //NS 3.0
-{
-aFLineIndent.Disable();
-aFLineLabel.Disable();
-}
+aFLineIndent.Disable();
+aFLineLabel.Disable();
 }
 }
 
@@ -1282,7 +1279,7 @@ void SvxParaAlignTabPage::Reset( const SfxItemSet& rSet )
 aLastLineLB.Hide();
 aLastLineFT.Hide();
 aExpandCB.Hide();
-if(!(nHtmlMode & (HTMLMODE_FULL_STYLES|HTMLMODE_FIRSTLINE)) )
+if(!(nHtmlMode & HTMLMODE_FULL_STYLES) )
 aJustify.Disable();
 aSnapToGridCB.Show(sal_False);
 }
diff --git a/sfx2/inc/sfx2/htmlmode.hxx b/sfx2/inc/sfx2/htmlmode.hxx
index 63b0bfe..0cbcda8 100644
--- a/sfx2/inc/sfx2/htmlmode.hxx
+++ b/sfx2/inc/sfx2/htmlmode.hxx
@@ -35,7 +35,6 @@
 #define HTMLMODE_SOME_STYLES0x0020 /* mind. MS IE */
 #define HTMLMODE_FULL_STYLES0x0040 /* == SW */
 #define HTMLMODE_PARA_BLOCK 0x0100
-#define HTMLMODE_FIRSTLINE  0x0400 /* First-line intent with Spacer == NS 3.0 */
 #define HTMLMODE_SOME_ABS_POS   0x2000
 #define HTMLMODE_RESERVED1  0x4000
 #define HTMLMODE_RESERVED0  0x8000
diff --git a/sw/source/filter/html/htmlatr.cxx b/sw/source/filter/html/htmlatr.cxx
index 9d15312..f0121ce 100644
--- a/sw/source/filter/html/htmlatr.cxx
+++ b/sw/source/filter/html/htmlatr.cxx
@@ -120,30 +120,6 @@ HTMLOutEvent aAnchorEventTable[] =
 
 static Writer& OutHTML_SvxAdjust( Writer& rWrt, const SfxPoolItem& rHt );
 
-static Writer& OutHTML_HoriSpacer( Writer& rWrt, sal_Int16 nSize )
-{
-OSL_ENSURE( nSize>0, "horizontaler SPACER mit negativem Wert?" );
-if( nSize <= 0 )
-return rWrt;
-
-if( Application::GetDefaultDevice() )
-{
-nSize = (sal_Int16)Application::GetDefaultDevice()
-->LogicToPixel( Size(nSize,0), MapMode(MAP_TWIP) ).Width();
-}
-
-rtl::OStringBuffer sOut;
-sOut.append('<').append(OOO_STRING_SVTOOLS_HTML_spacer).append(' ').
- append(OOO_STRING_SVTOOLS_HTML_O_type).append('=').
- append(OOO_STRING_SVTOOLS_HTML_SPTYPE_horizontal).append(' ').
- append(OOO_STRING_SVTOOLS_HTML_O_size).append('=').
- append(static_cast(nSize)).append('>');
-
-rWrt.Strm() << sOut.getStr();
-
-return rWrt;
-}
-
 sal_uInt16 SwHTMLWriter::GetDefListLvl( const String& rNm, sal_uInt16 nPoolId )
 {
 if( nPoolId == RES_POOLCOLL_HTML_DD )
@@ -1077,18 +1053,6 @@ void OutHTML_SwFmt( Writer& rWrt, const SwFmt& rFmt,
 rInfo.aToken = rtl::OString();
 }
 
-// ??? Warum nicht ueber den Hint-Mechanismus ???
-if( rHWrt.IsHTMLMode(HTMLMODE_FIRSTLINE) )
-{
-const SvxLRSpaceItem& rLRSpaceTmp =
-pNodeItemSet ? ((const SvxLRSpaceItem &)pNodeItemSet->Get(RES_LR_SPACE))
- : rFmt.GetLRSpace();
-if( rLRSpaceTmp.GetTxtFirstLineOfst() > 0 )
-{
-OutHTML_HoriSpacer( rWrt, rLRSpaceTmp.GetTxtFirstLineOfst() );
-}
-}
-
 if( nBulletGrfLvl != 255 )
 {
 OSL_ENSURE( aNumInfo.GetNumRule(), "Wo ist die Numerierung geblieben???" );
@@ -2527,24 +2491,7 @@ Writer& OutHTML_SwTxtNode( Writer& rWrt, const SwCntntNode& rNode )
 do {
 if ( pHt->GetEnd() && !pHt->HasDummyChar() )
 {
-if( RES_CHRATR_KERNING == pHt->Which() &&
-rHTMLWrt.IsHTMLMode(HTMLMODE_FIRSTLINE) &&
-*pHt->GetEnd() - nStrPos == 1 &&
-' ' == rStr.GetChar(nStrPos) &&
-((const SvxKerningItem&)pHt->GetAttr()).GetValue() > 0 )
-

Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)

2012-04-02 Thread R Skinner


On 03/31/12 18:49, Lubos Lunak wrote:

On Saturday 31 of March 2012, Albert Thuswaldner wrote:

Hi,
Sorry, I'm not much of help...

On Thu, Mar 29, 2012 at 13:29, R Skinner

  wrote:

[I tried at the users list but was advised I should post here instead]

Hi, I'm new here, and I'm driven here by desperation. I'm trying to build
libreoffice-3.4.5.2 on FreeBSD and it is failing the testing stage. I'm
running out of time for a client to pick up, so I need to fix this now
and I need some pointers on how to figure out whats wrong here.

I haven't tried to build LO on FreeBSD, but others have. Have you
searched the ML to find some clue to solve your problem?

This for instance:
http://lists.freedesktop.org/archives/libreoffice/2012-February/027383.html

  If you use the Clang compiler, then I somehow doubt you'll manage to get
3.4.5 working with that. In fact I'm even surprised the link mentions 3.5 as
usable with Clang, since I had to do several fixes in master this month to
get LO compile and run with Clang on Linux.

Could be a different version of clang - on FBSD we use 3.0, not to 
mention other unimaginable tweaks the Core have put into it.


I'll report whether it works
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)

2012-04-02 Thread R Skinner

On 03/31/12 18:49, Lubos Lunak wrote:

On Saturday 31 of March 2012, Albert Thuswaldner wrote:

Hi,
Sorry, I'm not much of help...

On Thu, Mar 29, 2012 at 13:29, R Skinner

wrote:

[I tried at the users list but was advised I should post here instead]

Hi, I'm new here, and I'm driven here by desperation. I'm trying to build
libreoffice-3.4.5.2 on FreeBSD and it is failing the testing stage. I'm
running out of time for a client to pick up, so I need to fix this now
and I need some pointers on how to figure out whats wrong here.

I haven't tried to build LO on FreeBSD, but others have. Have you
searched the ML to find some clue to solve your problem?

This for instance:
http://lists.freedesktop.org/archives/libreoffice/2012-February/027383.html

If you use the Clang compiler, then I somehow doubt you'll manage to get
3.4.5 working with that. In fact I'm even surprised the link mentions 3.5 as
usable with Clang, since I had to do several fixes in master this month to
get LO compile and run with Clang on Linux.

With a bit raping in the Makefile it seems to work, roughly, on FreeBSD-
clang is designed to run on its descendant after all (MacOSX) ;)

I'm stuck here though:

In file included from
/usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/soltools/giparser/gi_list.cxx:33:

In file included from ../inc/gi_list.hxx:33:
../inc/st_list.hxx:298:10: error: use of undeclared identfier 'push_back'
push_back( new XY(*(*it)) );
^
this->
... more notes - usually related to this issue...
../inc/st_list.hxx:311:5: error: use of undeclared identifier 'checkSize'
checkSize(DynamicList::len-2);
^
this->
... even more notes the last error...

And then the usual fail routine.

Any pointers on what is going on? I love clang - it shows up all the
little nuances :) More than likely the root of my original issue...

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

Re: intermittent flaw in gnumake deps on Win32 ..


Hi Kervin,

Kevin Hunter schrieb:

At 7:56am -0400 Fri, 30 Mar 2012, Christian Lohmaier wrote:

On Fri, Mar 30, 2012 at 1:05 PM, Matúš Kukan wrote:

On 30 March 2012 11:36, Michael Meeks wrote:

Regina's problem comes down to a corrupt .d file.
[...]
One more data-point, that file was exactly 4096 bytes large:


What does that mean ?


Well - it is either a coincidence, or not.. A multiple of 1024 i.e
exactly 4KB in size..


Perhaps dumb question: Is she out of space on that drive/partition?


No, I'm not. There are about 149 GB free.

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

Re: intermittent flaw in gnumake deps on Win32 ..


Should be "Hi Kevin". Please excuse.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: string / size bits ... #2 ...

On Monday 02 of April 2012, Michael Meeks wrote:
> On Fri, 2012-03-30 at 15:21 +0100, Michael Meeks wrote:
> > I up-loaded the output of my string debug for a writer start:
>
>   And discovered there was a bazillion problems with it, in particular
> the handling of OUStrings, having nailed that - it now has some
> considerable error due to 'String' handling; nevertheless a new version:
...
>   How we get 81k allocations of a string containing '/' is somewhat
> curious ;-) possibly we want to have a table of static one-char ascii
> strings for the one character entries - to save atomic ref-counting
> thrash, and pointless often transient allocations.
>
>   Interestingly, all these top uses are newish; when I last did the
> stats. As a rather less reliable dump: (due to the unreliable use of
> String classes I think) - I find it hard to believe we have 19k live '/'
> strings - does anyone feel guilty about that ? [ actually, I'm just
> poking at the configmgr code which looks like it might be the culprit ]

 I don't want to spoil the fun much for you :) , but I expect the number of 
string allocations to go down when RTL_CONSTASCII_* stops being used in favor 
of string literals, and further down after whenever I get to implementing the 
efficient operator+. So you may be profiling a problem for a part of which a 
solution already exists.

 Grepping configmgr/ for "/" shows things like
nodepath = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("/")) + nodepath;

 where the / string instance can be avoided completely. My changes won't do 
anything about the long-lived / instances though, so there indeed one shared 
instance may take care of all of them.

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

Need help in UNO

2012-04-02 Thread Dézsi Szabolcs


Hi all!

I'm working on Bug 34423 (more of a feature request).
There's this extension called OpenOffice Toolbox on the bug's page. It 
implements image rotation. I want to port that to C++.
I added a menu item to the right click menu of the image (Rotate... <- will 
call a dialog), now it just rotates the image with a hard coded value (90 
degrees).
To be precise it should rotate the image, but I don't really know this UNO 
thing, so I'm not sure what I'm doing (wrong) :)

My goal is to somehow get the selected image (XShape ?) and change its 
'RotateAngle' property (this was used in the extension code (basic)).
I hope someone can help me with this.

Szabolcs
  From 2b65880c462367c71b2eb07b0787404260a193b1 Mon Sep 17 00:00:00 2001
From: Szabolcs Dezsi 
Date: Mon, 2 Apr 2012 19:15:17 +0200
Subject: [PATCH] Rotate help

---
 sw/inc/cmdid.h|2 ++
 sw/inc/swcommands.h   |1 +
 sw/sdi/_grfsh.sdi |6 ++
 sw/sdi/swriter.sdi|   23 +++
 sw/source/ui/app/mn.src   |6 ++
 sw/source/ui/shells/grfsh.cxx |   23 +++
 6 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/sw/inc/cmdid.h b/sw/inc/cmdid.h
index 7802db7..d888c05 100644
--- a/sw/inc/cmdid.h
+++ b/sw/inc/cmdid.h
@@ -619,6 +619,8 @@ included in c-context files, so c++ style stuff will cause problems.
 #define FN_TABLE_AUTOSUM(FN_FORMAT + 195)  /* */
 #define FN_SET_CONTROL_HANDLER  (FN_FORMAT + 199)  /* set macro */
 
+#define FN_ROTATE   (FN_FORMAT + 196)  /* rotate picture */
+
 #define FN_IS_IMAGE  (FN_FORMAT2 + 6)   /* numbering: with graphic? */
 
 #define FN_GOTO_NEXT_REGION  (FN_FORMAT2 + 9)   /* */
diff --git a/sw/inc/swcommands.h b/sw/inc/swcommands.h
index 411ec5c..e211ef5 100644
--- a/sw/inc/swcommands.h
+++ b/sw/inc/swcommands.h
@@ -439,6 +439,7 @@
 #define CMD_FN_HEADERFOOTER_BORDERBACK  ".uno:HeaderFooterBorderBackground"
 #define CMD_FN_PAGEBREAK_EDIT   ".uno:PageBreakEdit"
 #define CMD_FN_PAGEBREAK_DELETE ".uno:PageBreakDelete"
+#define CMD_FN_ROTATE   ".uno:RotatePicture"
 
 #endif
 
diff --git a/sw/sdi/_grfsh.sdi b/sw/sdi/_grfsh.sdi
index d60dc39..942b990 100644
--- a/sw/sdi/_grfsh.sdi
+++ b/sw/sdi/_grfsh.sdi
@@ -70,6 +70,12 @@ interface BaseTextGraphic
 DisableFlags="SW_DISABLE_ON_PROTECTED_CURSOR";
 ]
 
+FN_ROTATE
+[
+ExecMethod = Execute ;
+StateMethod = GetAttrState ;
+]
+
 SID_TWAIN_TRANSFER
 [
 ExecMethod = Execute ;
diff --git a/sw/sdi/swriter.sdi b/sw/sdi/swriter.sdi
index d7cb8b3..ee307f7 100644
--- a/sw/sdi/swriter.sdi
+++ b/sw/sdi/swriter.sdi
@@ -3536,6 +3536,29 @@ SfxVoidItem ExternalEdit FN_EXTERNAL_EDIT
 ]
 //
 
+SfxVoidItem RotatePicture FN_ROTATE
+()
+[
+/* flags: */
+AutoUpdate = FALSE,
+Cachable = Cachable,
+FastCall = FALSE,
+HasCoreId = FALSE,
+HasDialog = FALSE,
+ReadOnlyDoc = TRUE,
+Toggle = FALSE,
+Container = FALSE,
+RecordAbsolute = FALSE,
+RecordPerSet;
+Synchron;
+
+/* config: */
+AccelConfig = TRUE,
+MenuConfig = TRUE,
+StatusBarConfig = FALSE,
+ToolBoxConfig = TRUE,
+GroupId = GID_GRAPHIC;
+]
 
 //--
 SfxVoidItem Grow FN_GROW_FONT_SIZE
diff --git a/sw/source/ui/app/mn.src b/sw/source/ui/app/mn.src
index e1f2aa1..1933fec 100644
--- a/sw/source/ui/app/mn.src
+++ b/sw/source/ui/app/mn.src
@@ -1262,6 +1262,12 @@ Menu MN_GRF_POPUPMENU
 {
 MN_ALIGN_FRAME
 MN_MOUSE_FRAME_WITH_CONTOUR
+MenuItem
+{
+Identifier = FN_ROTATE ;
+HelpId = CMD_FN_ROTATE ;
+Text [ en-US ] = "Rotate..." ;
+};
 SEPARATOR ;
 MN_TITLE_DESCRIPTION_SHAPE
 SEPARATOR ;
diff --git a/sw/source/ui/shells/grfsh.cxx b/sw/source/ui/shells/grfsh.cxx
index 7b537e4..e1dcb25 100644
--- a/sw/source/ui/shells/grfsh.cxx
+++ b/sw/source/ui/shells/grfsh.cxx
@@ -81,8 +81,15 @@
 
 #include "swabstdlg.hxx"
 
+#include 
+#include 
+#include 
+#include 
+
 #define TOOLBOX_NAME::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "colorbar" ) )
 
+using namespace ::com::sun::star;
+
 SFX_IMPL_INTERFACE(SwGrfShell, SwBaseShell, SW_RES(STR_SHELLNAME_GRAPHIC))
 {
 SFX_POPUPMENU_REGISTRATION(SW_RES(MN_GRF_POPUPMENU));
@@ -125,6 +132,22 @@ void SwGrfShell::Execute(SfxRequest &rReq)
 }
 break;
 
+case FN_ROTATE:
+{
+uno::Reference< frame::XModel > xModel = GetView().GetDocShell() ? GetView().GetDocShell()->GetModel() : NULL;
+if ( xModel.is() )
+{
+uno::Reference< frame::XController > xController = xModel->getCurrentController();
+

Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)