Re: fdo#46808 - [Easy Hack] Adapt UNO services to new-style

[Noel Grandin]

All I did was modify Engine.idl to read

  published service Engine : com::sun::star::script::XEngine;


On Tue, Mar 20, 2012 at 17:00, Stephan Bergmann  wrote:
> On 03/20/2012 12:55 PM, Noel Grandin wrote:
>>
>> I started with the Engine service, but after running the instructions
>> referenced in the git commit, I'm still getting:
>>
>> SERVICE: /UCR/com/sun/star/script/Engine
>> service1 contains 1 more references as service2
>> incompatible change: Reference 0 ('XEngine') in 'r1' is not longer a
>> reference of this service in 'r2'
>> /home/noel/libo/solver/unxlngx6.pro/bin/regcompare: registries are
>> incompatible: 1 differences!
>> make[1]: *** Deleting file
>> `/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb'
>> make[1]: *** No rule to make target
>> `/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb', needed by
>> `/home/noel/libo/solver/unxlngx6.pro/bin/types.rdb'. Stop.
>> make: *** [offapi] Error 2
>
>
> Noel, can you provide a patch of your changes so far?  That would make it
> easier to see why you run into that problem.
>
> Stephan
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] [WIP] fdo#45747 - [EasyHack] remove the limitation to 3 sort entries in calc

[Markus Mohrhard]

Hey Albert,

2012/3/20 Albert Thuswaldner :
> Hi Markus,
>
> On Thu, Mar 15, 2012 at 04:27, Markus Mohrhard
>  wrote:
>> Hello Albert,
>>
>> I have a simple idea that shouldn't be too complex to implement. I
>> think we can agree that only the sort entries are the difficult part.
>> I would create a control for an entry an instantiate this one for each
>> new sort entry. I think we do similar things for several other
>> dialogs, e.g. SvTabListBox with simple entries or the document
>> properties dialog with more complex entries.
>>
> Great, Let me know if there is anything that I can do to help.

The idea is to create a normal dialog or reuse the existing dialog.
But instead of hard coding the sort entry positions we need an own
control that just deals with the sort entries.

You can have a look at this idea in ScNamedDlg. ScNameDlg is a dialog
but the table is written in an own control that just deals with range
names and does not need to know anything about the dialog that
contains it. I think a similar approach will work for this here too.
The only difficult part will be the scroll handler. Do you think that
this is something that you can put together?

>
>> Just two small comments. I think it would be a good idea to group the
>> three entries in ScSortParam into a own struct so that we only need
>> one vector. That will make it easier to keep the entries in sync.
>> And you have a lot of whitespace changes. Can you check your editor
>> why it replaces so many spaces with tabs. It is quite difficult to
>> review it otherwise.
>
> Sorry for the messy patch, I didn't check it properly prior to posting
> it. I have reworked the patch and also split it up into two.
>
> Now the first patch contains only the internal rework to remove the
> limits and converting the data containers from arrays to std:vector.
> I've also grouped the three entries in ScSortParam into a own struct
> as you suggested, which resulted in quite a number of changes.
>
> Once reviewed this patch can be pushed directly to master since it is
> self contained and doesn't change the old
> behavior, me thinks.

I will check this patch tomorrow. A quick look through the patch did
not show any serious problems only some small nit-picks that I will
change while reviewing.

Thanks so far for this amazing work. I hope that the UI part does not
sound too scary and am looking forward to a patch for this too. If you
need more help with the UI rework just write a short mail or ping me
in IRC.

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

Re: Questions about Bug 33773 (chart)

[Markus Mohrhard]

Hello Rafael,

2012/3/21 Rafael Dominguez :
> Hello, i been working on bug 33773 for a few days already,  and i got to the
> point where i can display and manipulate
> X Error bars, but theres a few issues i dont know how to proceed.

Great. Sounds interesting.

>
> 1.- How i should handle export/import??? It seems ODF 1.2 and below, only
> support working with Y error bars,
> XLS import/export code, already supports having both bars. Tested it by
> exporting to xls and then importing it.
>
> Is there any way we can add features not implemented in the ODF spec???

I think to be conform with the spec we need to export it into an own
namespace and maybe propose it to OASIS for 1.3.

>
> 2.- What is the code inside chart2/source/controller/charapiwrapper for???
> Backward compability with chart API???

Yes. Our current chart code is a mixture of chart and chart2 api interfaces.

>
> 3.- Should i push my code to a feature branch??? So other people can review
> my work??

This sounds like a good idea for such a complex feature. It makes it
easier for us to help you with upcoming problems.

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

Questions about Bug 33773 (chart)

[Rafael Dominguez]

Hello, i been working on bug 33773 for a few days already,  and i got to
the point where i can display and manipulate
X Error bars, but theres a few issues i dont know how to proceed.

1.- How i should handle export/import??? It seems ODF 1.2 and below, only
support working with Y error bars,
XLS import/export code, already supports having both bars. Tested it by
exporting to xls and then importing it.

Is there any way we can add features not implemented in the ODF spec???

2.- What is the code inside chart2/source/controller/charapiwrapper for???
Backward compability with chart API???

3.- Should i push my code to a feature branch??? So other people can review
my work??

Any suggestion or code pointers is also welcome!

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

Re: Building master on Windows. Installer fails.

[julien2412]

Did you try to remove your LO profile ? Could it be a
conflict ?
I google-searched too and found this :
https://issues.apache.org/ooo/show_bug.cgi?id=44976.
Hope it's not a regression :-)

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Building-master-on-Windows-Installer-fails-tp3843864p3844103.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Compilation fix - GTK print dialog headers for GTK < 2.14

[David Bolen]

This fell out when I was working on my last patch for sub-menu icons.
Initially building with GTK failed on my system due to a missing
gtkunixprint.h header, which I worked around by just manually
disabling ENABLE_GTK_PRINT.

Afterwards I took another peek, and it looks like the problem is that
gtkunixprint.h was only added in GTK 2.14, so the attached patch fixes
compilation with older GTKs if they have the older setup.

I almost didn't send this because while it compiles and runs on my GTK
2.12 system without errors, I seem to get some sort of print dialog
even with ENABLE_GTK_PRINT disabled, so am not entirely certain what
it affects.  I also don't have a GTK 2.14+ system to actually compile
on at the moment.  But the patch is pretty easy to inspect visually
and a successful build seems a better option than a compilation
failure, so...

-- David


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

Exception specifications on functions useless?

[Lubos Lunak]

 Hello,

 I've just found out that exception specification on functions in LO have been 
just pretty comments, for about 10 years.

 Just to make sure what I'm talking about, it's the throw() in e.g. this

void foo( int a, void* b ) throw( css::uno::RuntimeException );

which says what exceptions a function can throw.

 I found out by compiling LO with Clang, running it and having it crash where 
gcc-compiler version had no problem. Stephan Bergmann and repo history 
revealed that in 2001 -fno-enforce-eh-specs was added to gcc's flags, turning 
off code generated that ensures these specifications are actually followed 
(and MSVC has reportedly never cared). Clang does not have the option. I've 
already actually fixed the problem (in 
vbahelper/inc/vbahelper/vbaccesshelper.hxx) and it appears the specifications 
somehow magically haven't rotten, as now LO runs fine for me (as far as I can 
say, I can't test everything).

 That however brings up the question of what the specification are for in the 
codebase. The 'Deprecated Exception Specifications, Added noexcept' part of 
http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/
 
is quite interesting read, the summary is:

- the specifications enforce that disallowed exceptions are not thrown at 
runtime, adding code to each such function to check it, thus actually making 
the performance worse

- boost, and pretty much everybody else it seems, do not consider it worth the 
hassle of specifying what a function may or may not throw, except for 
flagging a non-inline method as not throwing any exception at all as a means 
of optimization for places where such functions are called

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

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

Re: Building master on Windows. Installer fails.

[Andras Timar]

Hi Kohei,

2012/3/20 Kohei Yoshida :
> Hi there,
>
> I decided to give master a try on Windows once again.  The good news
> is that, it just built flawlessly without ever needing my
> intervention.  The bad news is that, the installer fails.  I've
> attached a screenshot of the error I'm seeing.
>
> Anyone has any clue as to how to fix this?
>
> My tree is most recent as of this morning.
>

I'm afraid that I broke it. I pushed a fix, you need to rebuild the installer.

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

Re: [PUSHED][PATCH] Remove unused code

[Caolán McNamara]

On Tue, 2012-03-20 at 21:26 +0100, Chr. Rossmanith wrote:
> A PresenterAnimation could be instantiated here
> 
>  ModeChangeAnimation (
>  const ::boost::shared_ptr& rpSprite,
>  const Reference& rxCanvas)
>  : PresenterAnimation (0, 1000, 20),
>mpSprite(rpSprite),
>mxCanvas(rxCanvas)
>  {
>  }
> 
> in PresenterWindowManager.cxx - iff ModeChangeAnimation would be used 
> anywhere. I can't find any place where it is used. Double check would be 
> nice. So first ModeChangeAnimation would have to go, then 
> PresenterAnimation could be removed as well.

Yup, callcatcher is correct here. ModeChangeAnimation itself is all
inlines and itself is never instantiated so gcc doesn't even emit any
ModeChangeAnimation code, so both it and PresenterAnimation can go. 

I'd actually ModeChangeAnimation chopped out here locally, I've pushed
that now with the last unused-code update

C.

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

Re: [PUSHED][PATCH] Remove unused code

[Chr. Rossmanith]

Am 20.03.2012 15:56, schrieb Caolán McNamara:

On Tue, 2012-03-20 at 13:54 +, Caolán McNamara wrote:

Yeah, in unused.easy I see that the PresenterAnimator::PresenterAnimator
ctor is never called, and its the only constructor, so one is never
instantiated, so you can remove the whole thing without loss of
functionality.

Whoops, its PresenterAnimation (not PresenterAnimator) which has only
one ctor that is never used and so is never instantiated and is trivial
to remove.

A PresenterAnimation could be instantiated here

ModeChangeAnimation (
const ::boost::shared_ptr& rpSprite,
const Reference& rxCanvas)
: PresenterAnimation (0, 1000, 20),
  mpSprite(rpSprite),
  mxCanvas(rxCanvas)
{
}

in PresenterWindowManager.cxx - iff ModeChangeAnimation would be used 
anywhere. I can't find any place where it is used. Double check would be 
nice. So first ModeChangeAnimation would have to go, then 
PresenterAnimation could be removed as well.


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

Re: GSoC idea proposal

[Enrico Weigelt]

> The overview of the idea is:
> there are cases where we may need to edit the attachment file in the
> mail
> and probably send the edited attachment to someone.. so in that case,
> instead of downloading, editing and then again attaching the file, we
> could
> have some provisions by which we can directly edit the attachment
> from
> libreoffice.. Once the changes are saved, it must be reflected in the
> attachment too.. For this, we could have some sort of link between
> the mail
> id and libreoffice.. Does this idea seems to be a need and feasible??

That issue is to be solved in your MUA, not in LO.


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

Re: [GBUILD] Can we get rid of recursively invoking custom targets ?

[Matúš Kukan]

On 20 March 2012 11:17, Michael Stahl  wrote:
> 1. var namespace collisions:
>   because make doesn't have namespaces for global variables, it's
>   possible that variables defined in different modules' custom
>   makefiles have the same name and thus collide.
>   this can be avoided by agreeing to a naming convention, such as
>   prefixing all variables by the name of the module where they are
>   defined, and reviewing all custom makefiles so that this convention
>   is met.

We have to create custom makefiles, so no problem with reviewing.
But is it really such problem ? I mean, we can't use INCLUDE variable of course
but if some variable is used in different custom makefile and we are
initializing it,
there should be no problem, because as make is parsing makefile, it
will be properly set.
Anyway, we can grep for the name of variable and set it that way, so
there is no collision.
I would really like to use only short variables for the working directory,
because they are used often and I think it is more readable then.

> 2. pattern rule collisions:
>   the pattern rules defined in a lot of custom makefiles also can lead
>   to collisions, both with other custom makefiles, and with the
>   pattern rules defined in solenv/gbuild, which is complicated due
>   to different pattern rule matching in make 3.81 and 3.82.
>   so the pattern rules in custom makefiles should all have targets of
>   the form $(WORKDIR)/CustomTarget/$(MODULE)/... and this prefix
>   should be different across modules and so the problem of getting
>   these to work in 3.81 and 3.82 should be module local and hence
>   hopefully manageable.

Ah, I did not think about this. So, what are the rules for pattern matching?
I thought make 3.81 picks first one and make 3.82 the one with longest
matching prefix.
oh, well, it does not matter, you are right,
(WORKDIR)/CustomTarget/$(MODULE)/ is good since there is nothing colliding.
So, no problem.

> but please rename the CDPI variable to packimages_CDPI or expand it
> (also, CUSTOM_images, CUSTOM_PREFERRED_FALLBACK_[12])

CDPI was supposed to be custom-target-directory-packimages.
That's not good because CD would be the same for all custom targets,
but 3(4) letters should be enough? First two for  and third
(or also fourth) for directory in module.
It must be enough to avoid collision, we don't have so many modules.

Also, there is no chance anyone would want to use such terrible name
as CUSTOM_images
and I think he is responsible for the name (it's easy to grep) and
moreover if there would
be collision, it should work anyway, or not ?

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

[PATCH] maTransform had to go ( was always = identity)

[Chr. Rossmanith]

No maTransform in PresenterSprite anymore.

Christina

Am 20.03.2012 16:07, schrieb Caolán McNamara:

On Tue, 2012-03-20 at 15:24 +0100, Chr. Rossmanith wrote:

At least it doesn't change the position of mxSprite. Only the cpu is a
little less idle  :-)  Then I'll continue to remove maTransform? Or
should it be kept for future use?

I'm not a fan of "some day we'll use it", ditch it if it doesn't do
anything right now would be my feeling.

I've a shed full of stuff I can't throw out just in case some day we
need it. Not that removing stuff from sdext will give me more space in
my shed I suppose.

C.

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


>From 3bd1567e844340d29ffa217eb4f70f63af74915d Mon Sep 17 00:00:00 2001
From: Christina Rossmanith 
Date: Tue, 20 Mar 2012 20:35:01 +0100
Subject: [PATCH] maTransform had to go ( was always = identity)

---
 sdext/source/presenter/PresenterSprite.cxx |2 --
 sdext/source/presenter/PresenterSprite.hxx |1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/sdext/source/presenter/PresenterSprite.cxx b/sdext/source/presenter/PresenterSprite.cxx
index 0fca939..428f34b 100644
--- a/sdext/source/presenter/PresenterSprite.cxx
+++ b/sdext/source/presenter/PresenterSprite.cxx
@@ -44,7 +44,6 @@ PresenterSprite::PresenterSprite (void)
   mxSprite(),
   maSize(0,0),
   maLocation(0,0),
-  maTransform(1,0,0, 0,1,0),
   mbIsVisible(false),
   mnPriority(0),
   mnAlpha(1.0)
@@ -149,7 +148,6 @@ void PresenterSprite::ProvideSprite (void)
 mxSprite = mxSpriteFactory->createCustomSprite(maSize);
 if (mxSprite.is())
 {
-mxSprite->transform(maTransform);
 mxSprite->move(maLocation,
 rendering::ViewState(
 geometry::AffineMatrix2D(1,0,0, 0,1,0),
diff --git a/sdext/source/presenter/PresenterSprite.hxx b/sdext/source/presenter/PresenterSprite.hxx
index 58755d7..787d1fa 100644
--- a/sdext/source/presenter/PresenterSprite.hxx
+++ b/sdext/source/presenter/PresenterSprite.hxx
@@ -74,7 +74,6 @@ private:
 ::css::uno::Reference mxSprite;
 css::geometry::RealSize2D maSize;
 css::geometry::RealPoint2D maLocation;
-css::geometry::AffineMatrix2D maTransform;
 bool mbIsVisible;
 double mnPriority;
 double mnAlpha;
-- 
1.7.4.1

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

GSoC idea proposal

[M.Sharan Kumar]

The overview of the idea is:
there are cases where we may need to edit the attachment file in the mail
and probably send the edited attachment to someone.. so in that case,
instead of downloading, editing and then again attaching the file, we could
have some provisions by which we can directly edit the attachment from
libreoffice.. Once the changes are saved, it must be reflected in the
attachment too.. For this, we could have some sort of link between the mail
id and libreoffice.. Does this idea seems to be a need and feasible??

--
View this message in context: 
http://nabble.documentfoundation.org/GSoC-idea-proposal-tp3843455p3843455.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][PATCH] Remove unused code (sdext)

[Michael Meeks]

On Tue, 2012-03-20 at 15:07 +, Caolán McNamara wrote:
> I've a shed full of stuff I can't throw out just in case some day we
> need it. Not that removing stuff from sdext will give me more space in
> my shed I suppose.

:-) I have a similar shed - I can't get into it either ;-) but I really
ought to do something about it, I love the attitude.

All the best,

Michael.

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

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

[ANNOUNCE] Branch libreoffice-3-5-2 created

[Petr Mladek]

Hi all,

there have been created the libreoffice-3-5-2 branch. It will be used
for fine tuning of the 3.5.2 release.

The following rules apply:

+ preferably just translation or blocker fixes
+ only cherry-picking from libreoffice-3-5 branch
+ 2 additional reviews needed; 2nd reviewer pushes
+ no regular merges back to anything

The 'libreoffice-3-5' branch is still active and will be used for the
3.5.3 bugfix release. Please read more at

   http://wiki.documentfoundation.org/ReleasePlan
   http://wiki.documentfoundation.org/Development/Branches


Now, if you want to switch your clone to the branch, please do:

./g pull -r
./g checkout -b libreoffice-3-5-0 origin/libreoffice-3-5-2

Hopefully it will work for you :-)  Most probably, you will also want to
do (if you haven't done it yet):

git config --global push.default tracking

When you do git push with this, git will push only the branch you are
on; e.g. libreoffice-3-5-2 when you have switched to it.  This will
save you some git shouting at you.


Happy hacking,
Petr

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

[Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Bug 35673 depends on bug 45355, which changed state.

Bug 45355 Summary: CRASH if characters in text of BENGALI, TIBETAN, MALAYALAM, 
MARATHI, NEPALI, ORIYA, TAMIL, TELUGU
https://bugs.freedesktop.org/show_bug.cgi?id=45355

   What|Old Value   |New Value

 Resolution||WORKSFORME
 Status|NEW |RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[ANNOUNCE] libreoffice-3.5.2.1 tag created (3.5.2-rc1)

[Petr Mladek]

Hi,

there have been created the libreoffice-3.5.2.1 tag for 3.5.2-rc1
release. The corresponding official builds will be available within
next few days.

See the attached list of changes against 3.5.1-final.


Now, you might switch your current 3-5 source tree to it using:

./g fetch --tags
./g checkout -b tag-libreoffice-3.5.2.1 libreoffice-3.5.2.1

Linux distro packages might find source tarballs at
http://dev-builds.libreoffice.org/pre-releases/src/
They will be available from the official page together with the builds.


See also the schedule at 
http://wiki.documentfoundation.org/ReleasePlan#3.5_release
and release criteria at http://wiki.documentfoundation.org/Release_Criteria


Best Regards,
Petr
+ binfilter
+ restore ascii export for getTextFromPam (fdo#45521) [Caolán McNamara]
+ core
+ "Distributy Columns Evenly" does not work with the selected columns (fdo#46144) [Ivan Timofeev]
+ osl_syncFile having written, and avoid doing that on start (fdo#40607) [Michael Meeks]
+ adapt string type checks to work with both Python 2 and 3 (fdo#46859) [David Bolen]
+ add Gurmukhi MT font for pa-IN (fdo#46571) [Andras Timar]
+ add all imported properties to ScDBData, (fdo#40426) [Markus Mohrhard]
+ add junit test for these (fdo#39694, fdo#42073) [Michael Stahl]
+ add test document (fdo#39694) [Juergen Steinhilber]
+ also shrink used area for HTML in some cases, (bnc#677811, fdo#46230) [Markus Mohrhard]
+ another partial fix for (fdo#45219) [Thorsten Behrens]
+ bASISINSTALLLOCATION = INSTALLLOCATION (fdo#46377) [Andras Timar]
+ check for negative sheet number here too, (fdo#47503) [Markus Mohrhard]
+ clear full sprite area for (fdo#45219) [Thorsten Behrens]
+ clear sprites to white . (fdo#45219) [Thorsten Behrens]
+ clear whole layer in slideshow sprites (fdo#45219) [Thorsten Behrens]
+ correctly import data point formats in data series. (fdo#40320) [Kohei Yoshida]
+ default conversion of sequences is now again SAFEARRAY of VARIANTs #fdo46165 (i#117010) [Joachim Lingner]
+ delay painting borders until after subsidiary lines (fdo#42750) [Michael Stahl]
+ dmapper: fix line width default (fdo#43965) [Miklos Vajna]
+ do not crash on clicking bibliography when base isnt installed (lp#527938, fdo#33266, debian#602953, i#105408) [Bjoern Michaelsen]
+ don't copy page styles into temporary clipboard doc (fdo#46038) [Caolán McNamara]
+ don't crash for empty input data in charts, (fdo#46885) [Markus Mohrhard]
+ don't crash when scrolling in input line, (fdo#46975) [Markus Mohrhard]
+ don't create uno::Sequence with new, (fdo#46825) [Markus Mohrhard]
+ don't let env vars interfere with internal bootstrap vars (fdo#42961) [Stephan Bergmann]
+ don't paste content if user cancels html import, (fdo#47393) [Markus Mohrhard]
+ don't show an error message for empty names in Define Names, (fdo#46816) [Markus Mohrhard]
+ don't use an invalidated iterator (fdo#46337) [Luboš Luňák]
+ dyaLinePitch only valid between [1-31680] (fdo#40686) [Caolán McNamara]
+ expand group memberships in PostgreSQL-SDBC get*Privileges (fdo#46675) [Lionel Elie Mamane]
+ export all row styles, (fdo#46336) [Markus Mohrhard]
+ fix Query Wizard by putting the right ElementName (fdo#46339) [Julien Nabet]
+ fix RTF import of \up and \dn with custom parameters (fdo#43965) [Miklos Vajna]
+ fix RTF import of ms932-encoded characters (fdo#45543) [Miklos Vajna]
+ fix UNO struct comparison in Python 2 (fdo#46926) [David Bolen]
+ fix anchor handling in SwXText::convertToTextFrame() (bnc#695479) [Miklos Vajna]
+ fix context menu key yanking cursor out of header/footer (fdo#45962) [Michael Stahl]
+ fix core when clicking on entries in Manage Names dialog in calc (fdo#46568) [Noel Power]
+ fix crash in SdrGrafObj::getInputStream: (fdo#46340) [Michael Stahl]
+ fix crash using instances dialog of dataform navigator (fdo#44816) [Noel Power]
+ fix crash with document from (bnc#693238) [Tor Lillqvist]
+ fix frame duplication: (i#112763, fdo#40599) [Michael Stahl]
+ fix logout with quickstarter (lp#562027) [Bjoern Michaelsen]
+ fix rtf/docx import of transparent frames (bnc#695479) [Miklos Vajna]
+ fix the fix for Python 3 (fdo#46926) [Michael Stahl]
+ fix title field in header, footer (i#84393) [Szabolcs Dezsi]
+ fix to update inputbar when setting a range for a formula (fdo#46809) [Noel Power]
+ fix uno bootstrapping for .NET ( and perhaps c++ ) (fdo#46832) [Noel Power]
+ fix wrong transparency for animated objects. (fdo#45219) [Thorsten Behrens]
+ fixed SpellCheck dialog display issues (fdo#46531) [Cédric Bosdonnat]
+ fixed docx textbox borders style and width import (fdo#45560) [Cédric Bosdonnat]
+ fixed docx textbox position and size import (fdo#45560) [Cédric Bosdonnat]
+ force imported xlsx active tab to be shown (bnc#748198) [Noel Power]
+ insert only a plac

Re: About Strings

[Tor Lillqvist]

> To me, both look equally wrong if OUString is considered immutable, and
> equally OK if it isn't.

Ah, but if you let your C# (or Java?) exposure influence you, foo =
foo + bar looks ok even if OUString is considered immutable. The old
object that the foo variable refered to is lost (unless it had other
references), and foo is set to refer to a new object which is the
concatenation of the old foo and bar. Not any stranger than tem = foo
+ bar; foo = null.

But foo += bar looks weird, as it seems to say that the immutable
object that foo refers to gets something appended to it.

At least thinking of C# is how I explain to myself why I like one but
not the other... But sure, I know that variables and objects in C++ is
a completely different thing than in C# or Java, despite superficial
similarities

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||47406

--- Comment #242 from Petr Mladek  2012-03-20 08:49:52 PDT ---
Add bug 47406: Almost all graphics that have internal circuits is wrongly
positioned in ODT import. It is a regression against 3.4.

-- 
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: About Strings

[Lubos Lunak]

On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> >  Before I start experimenting with more stuff in OUString that might look
> > a bit like operator+= , what exactly is so irritating about operator= or
> > operator+= in OUString and why?
>
> It's just that if OUString was supposed to be immutable,

 That is the theory, but what does it matter in practice? The only result of 
this that I can see is that it leads to cumbersome 
string->stringbuffer->string back and forths, so I wonder what the actual 
benefit of it is supposed to be? The way I see it it would be much better to 
just go with the string class and improve it as necessary, the buffer should 
be either deprecated or left for cases where the modifications are extensive.

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

Re: About Strings

[Stephan Bergmann]

On 03/20/2012 03:29 PM, Caolán McNamara wrote:

On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:

On Tuesday 20 of March 2012, Caolán McNamara wrote:

On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:

(And even if immutable classes are
generally also a good idea in C++, esp. in combination with
multi-threading, the mutable rtl::OUString::operator= spoils this,
anyway.)


And the += operator irritates me.


  Before I start experimenting with more stuff in OUString that might look a
bit like operator+= , what exactly is so irritating about operator= or
operator+= in OUString and why?


It's just that if OUString was supposed to be immutable, then a
foo += bar; "feels wrong" to me in some vague way that, I guess
bizarrely, foo = foo + bar doesn't. *shrug*


To me, both look equally wrong if OUString is considered immutable, and 
equally OK if it isn't.


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

Re: [PUSHED][PATCH] Remove unused code (sdext)

[Caolán McNamara]

On Tue, 2012-03-20 at 15:24 +0100, Chr. Rossmanith wrote:
> At least it doesn't change the position of mxSprite. Only the cpu is a 
> little less idle  :-)  Then I'll continue to remove maTransform? Or 
> should it be kept for future use?

I'm not a fan of "some day we'll use it", ditch it if it doesn't do
anything right now would be my feeling. 

I've a shed full of stuff I can't throw out just in case some day we
need it. Not that removing stuff from sdext will give me more space in
my shed I suppose.

C.

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

Re: fdo#46808 - [Easy Hack] Adapt UNO services to new-style

[Stephan Bergmann]

On 03/20/2012 12:55 PM, Noel Grandin wrote:

I started with the Engine service, but after running the instructions
referenced in the git commit, I'm still getting:

SERVICE: /UCR/com/sun/star/script/Engine
service1 contains 1 more references as service2
incompatible change: Reference 0 ('XEngine') in 'r1' is not longer a
reference of this service in 'r2'
/home/noel/libo/solver/unxlngx6.pro/bin/regcompare: registries are
incompatible: 1 differences!
make[1]: *** Deleting file
`/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb'
make[1]: *** No rule to make target
`/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb', needed by
`/home/noel/libo/solver/unxlngx6.pro/bin/types.rdb'. Stop.
make: *** [offapi] Error 2


Noel, can you provide a patch of your changes so far?  That would make 
it easier to see why you run into that problem.


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

Re: [PUSHED][PATCH] Remove unused code

[Caolán McNamara]

On Tue, 2012-03-20 at 13:54 +, Caolán McNamara wrote:
> Yeah, in unused.easy I see that the PresenterAnimator::PresenterAnimator
> ctor is never called, and its the only constructor, so one is never
> instantiated, so you can remove the whole thing without loss of
> functionality.

Whoops, its PresenterAnimation (not PresenterAnimator) which has only
one ctor that is never used and so is never instantiated and is trivial
to remove. 

Nevertheless, PresenterAnimator itself only has a trivial ctor which
doesn't do anything much and no public methods, so as far as I can see
the only thing that currently actually gets executed is that we call

"PresenterTimer::CancelTask(0)"

in the PresenterAnimator dtor. I have no idea if anything relies on that
sort of "accident" to continue working. I *doubt* it, but its possible I
suppose.

C.

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

Re: About Strings

[Tor Lillqvist]

> It's just that if OUString was supposed to be immutable, then a
> foo += bar; "feels wrong" to me in some vague way that, I guess
> bizarrely, foo = foo + bar doesn't.

Ditto.

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

Re: Worked in OOo, doesn't load well in LibO

[Terrence Enger]

On Mon, 2012-03-19 at 22:02 +0100, Joop KIEFTE wrote:
> Can anyone identify what's the problem in this document or in
LibreOffice?
> 
> Joop Kiefte

Joop,

I have taken it upon myself to file bug 47545 "FILEOPEN,VIEWING:
different position of some items"
.  You may want to
check what I wrote and add your self to the CC List of the bug.

HTH,
Terry.


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

Re: Worked in OOo, doesn't load well in LibO

[Yifan Jiang]

Hi Joop,

Ye, I can see the most obvious problem in the title page, the text box and
graphics in the header seems not aligned well. Besides this could be also a
regression problem against 3.4.x.

It is a typical problem to be reported in bugzilla, would you please refer to
the wiki and report the bug:

http://wiki.documentfoundation.org/BugReport

Thanks~

Best wishes,
Yifan

On Mon, Mar 19, 2012 at 10:02:35PM +0100, Joop KIEFTE wrote:
> Can anyone identify what's the problem in this document or in LibreOffice?
> 
> Joop Kiefte


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

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

Re: About Strings

[Caolán McNamara]

On Tue, 2012-03-20 at 15:20 +0100, Lubos Lunak wrote:
> On Tuesday 20 of March 2012, Caolán McNamara wrote:
> > On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> > > (And even if immutable classes are
> > > generally also a good idea in C++, esp. in combination with
> > > multi-threading, the mutable rtl::OUString::operator= spoils this,
> > > anyway.)
> >
> > And the += operator irritates me.
> 
>  Before I start experimenting with more stuff in OUString that might look a 
> bit like operator+= , what exactly is so irritating about operator= or 
> operator+= in OUString and why?

It's just that if OUString was supposed to be immutable, then a 
foo += bar; "feels wrong" to me in some vague way that, I guess
bizarrely, foo = foo + bar doesn't. *shrug*

C.

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

Re: [PUSHED][PATCH] convert tools/table.hxx usage to std::map in IDL module

[Caolán McNamara]

On Sun, 2012-03-11 at 12:15 +0200, Noel Grandin wrote:
>...

Seems good to me, unless I'm missing something that makes noone want to
touch this patch, in which case I'm sure I'll hear about it :-). Pushed
now, thanks for this, sorry for delay.

C.

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

Re: [PUSHED][PATCH] Remove unused code (sdext)

[Chr. Rossmanith]

Hi,

Probably the private variable maTransform can be removed as well: it is
initialized with the identity transform and never changed afterwards.

Does that suggest that the actual call to
mxSprite->transform(maTransform) is actually a no-op ?
At least it doesn't change the position of mxSprite. Only the cpu is a 
little less idle  :-)  Then I'll continue to remove maTransform? Or 
should it be kept for future use?


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

Re: About Strings

[Lubos Lunak]

On Tuesday 20 of March 2012, Caolán McNamara wrote:
> On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> > (And even if immutable classes are
> > generally also a good idea in C++, esp. in combination with
> > multi-threading, the mutable rtl::OUString::operator= spoils this,
> > anyway.)
>
> And the += operator irritates me.

 Before I start experimenting with more stuff in OUString that might look a 
bit like operator+= , what exactly is so irritating about operator= or 
operator+= in OUString and why?

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

Re: About Strings

[Caolán McNamara]

On Mon, 2012-03-19 at 13:39 +0100, Stephan Bergmann wrote:
> (And even if immutable classes are 
> generally also a good idea in C++, esp. in combination with 
> multi-threading, the mutable rtl::OUString::operator= spoils this, anyway.)

And the += operator irritates me.

Either way though, its a nonsense to have 4 (well three now, ByteString
is gone) string classes. And given that the rtl::O[U]String classes are
the ones that are available for external api users its only fair that we
use *that* one and not run back to the "classic" non-exported UniString
when rtl::OUString is too hard to use for something

C.

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

Re: [PUSHED][PATCH] Remove unused code (sdext)

[Caolán McNamara]

On Sat, 2012-03-17 at 21:03 +0100, Chr. Rossmanith wrote:
> Hi,
> 
> some more code removal. 

Looks good, pushed this now.

> Probably the private variable maTransform can be removed as well: it is
> initialized with the identity transform and never changed afterwards.

Does that suggest that the actual call to
mxSprite->transform(maTransform) is actually a no-op ?

C.

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

Re: [PUSHED][PATCH] Remove unused code

[Caolán McNamara]

On Sat, 2012-03-17 at 15:34 +0100, Chr. Rossmanith wrote:
> Hi,
> 
> I had a look at unusedcode.easy (sdext/presenter) and removed a little 
> bit more than mentioned there: as there are no end callbacks added 
> (AddEndCallback() was unused), there is no need to run them -> 
> RunEndCallbacks() could be removed as well. Same logic for start 
> callbacks. Finally mpStartCallbacks and mpEndCallbacks could leave, too.

Yup, I agree, I pushed this now.

> In PresenterAnimator AddAnimation() was unused and it seems that the 
> whole class might be removed?!?

Yeah, in unused.easy I see that the PresenterAnimator::PresenterAnimator
ctor is never called, and its the only constructor, so one is never
instantiated, so you can remove the whole thing without loss of
functionality.

C.

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

Re: [PUSHED] Deleting some commented out code.

[Luke Petrolekas]

Okay, that's been done, thanks for letting me know.

On Tue, Mar 20, 2012 at 4:00 AM, Stephan Bergmann wrote:

> On 03/19/2012 11:59 PM, Luke Petrolekas wrote:
>
>> and some more, also contributed under the LGPLv3+ / MPL.
>>
>> On Mon, Mar 19, 2012 at 6:46 PM, Luke Petrolekas
>> > >
>> wrote:
>>
>>I would have thought we would have deleted all commented out stuff
>>already! :) Woot for first commit in nearly a year.
>>
>>Code is contributed under the LGPLv3+ / MPL.
>>
>
> Pushed both patches to master now.
>
> Luke, can you please add yourself to  documentfoundation.org/**Development/Developers>,
> including a link to your license statement?
>
> Thanks,
> Stephan
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

License Statement

[Luke Petrolekas]

Hi,

All my current and past contributions made to the LibreOffice project
have been provided under MPL1.1+ / GPLv3+ / LGPLv3+.

Until further notice, all my future contributions to the LibreOffice
project are also available under MPL1.1+ / GPLv3+ / LGPLv3+.

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

Re: [PUSHED][PATCH] remove unused code (oox, sc)

[Caolán McNamara]

On Sun, 2012-03-18 at 14:40 +0100, Petr Vorel wrote:
> Hi there,
> 
> some unused code removed (oox, sc).

Looks good to me, pushed now, thanks for these.

C.

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

[Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Bug 35673 depends on bug 37860, which changed state.

Bug 37860 Summary: Formula returns #VALUE in 3.4RC2 but works as expected in 3.3
https://bugs.freedesktop.org/show_bug.cgi?id=37860

   What|Old Value   |New Value

 Resolution||DUPLICATE
 Status|REOPENED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED:master,3-5] Cppcheck reports "Logical disjunction always evaluates to true" in sdext module

[Petr Mladek]

julien2412 píše v Ne 18. 03. 2012 v 10:24 -0700:
> Hello,
> 
> Cppcheck reports this in sdext module :
> [source/minimizer/optimizerdialog.cxx:276]: (warning) Logical disjunction
> always evaluates to true: nNewStep >= 0 || nNewStep <= 4
> Here is the line :
> if ( ( nNewStep != mnCurrentStep ) && ( ( nNewStep <= MAX_STEP ) || (
> nNewStep >= 0 ) ) )
> 
> Shouldn't it be :
> if ( ( nNewStep != mnCurrentStep ) && ( nNewStep <= MAX_STEP ) && ( nNewStep
> >= 0 ) )

Yup, it makes perfect sense. I have pushed the change into both master
and 3-5 branch, see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=9481eb32e76568fc675982479cc07c57c6a7cb39
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=8eb5b36284c3a6c6535508a3f0651be1b5ada2dc


> Moreover, if I'm right, should we additionnally throw an exception (which
> one ?) if "nNewStep" is not between 0 and MAX_STEP 

I would leave it as is. The affected method is
OptimizerDialog::SwitchPage. IMHO, it is better to do not switch pages
instead of canceling the whole operation with an useless exception.


Best Regards,
Petr

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

Re: Template translation / shrink bloated install size

[Michael Stahl]

On 18/03/12 17:42, Hasitha Dhananjaya wrote:
> Hi all,
> 
> I'm a second year undergraduate student from University of Moratuwa. 
> I would like to join GSocC 2012 to following project. *Template
> translation / shrink bloated install size* I have followed Java
> course and now I'm following C++ course. So I think I can contribute
> for this project and I try to do my best. I got this project idea
> from this link. 
> https://wiki.documentfoundation.org/Development/Gsoc/Ideas

hello Hasitha,

great to hear that you are interested in participating in GSoC.

quoting from
http://www.google-melange.com/gsoc/org/google/gsoc2012/libreoffice:

> Prove that you want to get involved into LibreOffice. In order to
> check this we will require students to complete one of the Easy
> programming tasks on the Easy_Hacks page (or part of one if that
> EasyHack is a selection of separate tasks), though the dead-line for
> this isn't hard but needs to be somewhere before the end of the
> selection process

to get started, read these, and build LO from source:

http://www.libreoffice.org/developers-2/
https://wiki.documentfoundation.org/Development
https://wiki.documentfoundation.org/Easy_Hacks#Easy_Programming_tasks

in case you run into build problems, don't hesitate to ask for advice on
IRC or this list.

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

Re: [PUSHED][REVIEW-3-5] revert fdo#33090 to fix fdo#46750 memory corrupter

[Caolán McNamara]

On Fri, 2012-03-16 at 20:57 +, Michael Meeks wrote:
> So,
> 
>   I'd prefer to live with fdo#33090 (a Thai text rendering issue) than
> have the subtle memory corruption in fdo#46750 - so I suggest that we
> revert:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=e601c32661735e9fd78def7ee11bfe21279cca71
> 
>   in libreoffice-3-5 for Monday - unless anyone has a better idea
> ( Caolan did you get to the bottom of the maze to find a fix ? :-)

Well, I reckon https://bugs.freedesktop.org/attachment.cgi?id=58434 is
likely to be the right fix. 

i.e. https://bugs.freedesktop.org/show_bug.cgi?id=46923

But lets take the conservative approach for 3-5 anyway, so reverted the
original windows-glyph-fallback improvement attempt now in 3-5

C.

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

Re: [PUSHED][PATCH] Remove unused code

[Caolán McNamara]

On Fri, 2012-03-16 at 20:20 +0100, Santiago Martinez wrote:
> This patch removes unused code as listed in unusedcode.easy

Looks good to me, pushed now, thanks for this.

C.

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

Re: [PUSHED][PATCH] removed unused code

[Caolán McNamara]

On Fri, 2012-03-16 at 14:42 +0100, Petr Vorel wrote:
> Hi there,
> 
> another unused code removed (part of oox).

Looks good, pushed now, thanks for this.

C.

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

Re: Unused code patches

[Caolán McNamara]

On Mon, 2012-03-19 at 15:08 -0500, David T. Biedrzycki wrote:
> We do have a question though, how up to date is the unusedcode.easy
> file? There are many methods that have already been removed that are
> still listed.

Can you give an example of one that's been removed bit is still listed.
I generally regenerate the list regularly

FWIW, something like CharPosArray::Insert is listed as unused (and is
unused), but is hard to find in the code because its generated from a
SV_DECL_VARARR macro, so there's some overlap with the easy-hack to
convert from those macros to generic STL
https://bugs.freedesktop.org/show_bug.cgi?id=38832
Targeting STL conversion to the stuff that appears in unusedcode.easy
kills two birds with one stone.

C.


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

fdo#46808 - [Easy Hack] Adapt UNO services to new-style

[Noel Grandin]

Hi

Following instructions here:
https://bugs.freedesktop.org/show_bug.cgi?id=46808
and here:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=30a7a6189916396c7c2ee9bbd5861ad19bf7724c

I started with the Engine service, but after running the instructions 
referenced in the git commit, I'm still getting:


SERVICE: /UCR/com/sun/star/script/Engine
service1 contains 1 more references as service2
  incompatible change: Reference 0 ('XEngine') in 'r1' is not longer a 
reference of this service in 'r2'
/home/noel/libo/solver/unxlngx6.pro/bin/regcompare: registries are 
incompatible: 1 differences!
make[1]: *** Deleting file 
`/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb'
make[1]: *** No rule to make target 
`/home/noel/libo/workdir/unxlngx6.pro/UnoApiTarget/types.rdb', needed by 
`/home/noel/libo/solver/unxlngx6.pro/bin/types.rdb'.  Stop.

make: *** [offapi] Error 2


Thanks, Noel Grandin

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


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

Re: [PUSHED:master,3-5] Missing sub-menu arrows with 3.5.x and GTK < 2.15

[Petr Mladek]

Michael Meeks píše v Út 20. 03. 2012 v 11:32 +:
> Hi David,
> 
> On Mon, 2012-03-19 at 17:48 -0400, David Bolen wrote:
> > Even if the implementation stinks using it was easy enough :-)
> 
>   :-)
> 
> > (a) Direct use of gtk_widget_class_find_style_property in lieu of the
> > version check.
> 
>   This looks really nice.

Thanks for review. I have pushed it into both master and libreoffice-3-5
branch. So, it will be even in 3.5.2 bugfix release.

Of course, thanks a lot for the great fix.


Best Regards,
Petr

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Bug 37361 depends on bug 47560, which changed state.

Bug 47560 Summary: EDITING: queries open for reediting: only last out-of-order 
sort column kept (duplicated)
https://bugs.freedesktop.org/show_bug.cgi?id=47560

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Bug 37361 depends on bug 47370, which changed state.

Bug 47370 Summary: EDITING: queries mangle sorting-order when open for reediting
https://bugs.freedesktop.org/show_bug.cgi?id=47370

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED:3-5] graphical query editor mangles sorting order

[Petr Mladek]

Lionel Elie Mamane píše v Út 20. 03. 2012 v 11:30 +0100:
> Attached patch fixes (old! at least back to 3.3) bugs exposed by
> fixing fdo#46843, about sort orders in the graphical query editor:
> 
> fdo#47370: when sort columns order does not match result columns
>order, sort is reordered to result order
> 
>  E.g. "SELECT a, b, c FROM foo ORDER BY c, a"
>becomes "SELECT a, b, c FROM foo ORDER BY a, c"
> 
> fdo#47560: when several sort columns are "out of result order", all
>are set to the last
> 
>  E.g. "SELECT a, b, c FROM foo ORDER BY c, a, b"
>  becomes "SELECT a, b, c FROM foo ORDER BY c, b, b"
> 
>  That is simply because those "additional" sort columns were
>  set in the *same* in-memory structure. Fix: allocate a
>  fresh structure for each new sort column.

Great catch! Both fixes make sense and work like a charm. I have pushed
them into 3-5 branch. They will be in 3.5.2.

Best Regards,
Petr

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

Re: [PATCH] Missing sub-menu arrows with 3.5.x and GTK < 2.15

[Michael Meeks]

Hi David,

On Mon, 2012-03-19 at 17:48 -0400, David Bolen wrote:
> Even if the implementation stinks using it was easy enough :-)

:-)

> (a) Direct use of gtk_widget_class_find_style_property in lieu of the
> version check.

This looks really nice.

> (a) is a more conservative change, but (b) feels a little nicer in
> terms of less overhead and redundant queries in actual operation.

Heh - so, gtk+ spends it's life doing string lookups all over the
place, and the overhead is negligible compared to what the client side
rendering is going to do with your CPU ;-)

> it actually feels like more of this code should be able to be hoisted
> to a less frequent spot (initialization or something), since I can't
> imagine how often the properties change value during run-time?  But I
> doubt it's a performance bottleneck.

Yep - looks nice.

> One other curiosity - GTK 2.24.4 actually uses a value of 0.80 for
> arrow-scaling, but I can absolutely say that the arrows are nowhere
> near 0.80 of the menu font, and using 0.80 under GTK 2.12 looks
> ridiculously large.  I've actually dropped my default of 0.5 to 0.4 as
> it more accurately matches 2.24 (plus the prior LO 3.4 on my 2.12
> system).  I think I actually liked 0.5 a little better myself, but
> figure trying to match existing behavior should win.

:-)

>   I'm guessing
> being 1/2 of the 0.8 property value isn't a coincidence, so there must
> be some other scaling going on under the covers somewhere under 2.24
> since obviously this code uses the scaling factor the same way in both
> cases.

Thanks for unwinding all that and the nice fix, I think Petr picked it
and it should be in 3.5.2.

Any other gtk+ theming nasties annoying you ? :-)

All the best !

Michael.

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

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

Re: [PATCH]fdo45671 set initial colours for split buttons

[Stefan Knorr (Astron)]

Hi Winfried,

> Is this the initial setting you wanted? AFAICS it hasn't been pushed yet, nor 
> rejected :)

Sorry for the lack of feedback. Yes, those should be the right
colours. If I there's no one to complain, I'll just push this later
today as it seems reasonably simple.

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

Re: [REVIEW][3-5][PUSHED] fdo#42750 sw: thin table borders hidden by subsidiary lines

[Cedric Bosdonnat]

Hi Michael,

On Fri, 2012-03-16 at 23:29 +0100, Michael Stahl wrote:
> this fix introduces a new array to store the borders and paints them
> after the subsidiary lines are done, effectively on top of the
> subsidiary lines.
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=804d0a896731629397c5328c13c04a45bc55f459

Thanks for the patch. I apologize as I should have done that a lot
earlier. I cherry-picked and pushed it to -3-5.

> there is quite a bit of complex stuff going on in paintfrm.cxx with
> border lines and subsidiary lines, e.g. the subsidiary lines are
> actually checked and the ones that overlap with border lines are removed
> and never painted, but unfortunately that does not work with the new way
> the border lines are painted (via drawinglayer), and so i'm not sure if
> there are not even more problems here.
> 
> i've also tried to avoid adding a new global variable by adding a
> parameter to some methods, but it turned out it would be necessary to
> add this to SwFrm::Paint, which is overridden in a boatload of
> subclasses, so i didn't like have that in -3-5.

I'ld even love to get rid of that subsidiary lines delaying. and paint
everything in the proper Paint methods. That would ease (and clean up)
that code a bit and make borders painting a bit more understandable by
newcomers.

--
Cedric

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

Re: [REVIEW][PUSHED] 3 RTF import fixes

[Cedric Bosdonnat]

Hi Miklos,

All 3 patches are OK for me. I cherry-picked them to 3-5 and pushed
them.

--
Cedric

On Mon, 2012-03-19 at 09:17 +0100, Miklos Vajna wrote:
> Hi,
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=44f7c5ddf9d730c899f480ca644ddc29c7de9dc6
> 
> Testcase for this: sw/qa/extras/rtftok/data/fdo46662.rtf
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb34b73730a3109bdcae0a03137c1faffab610d5
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=dac6b7938173d0793810ee5731de51c440c1af5e
> 
> Testcase for these: sw/qa/extras/rtftok/data/fdo43965.rtf
> 
> (Testcases are master-only, the RTF subsequent test was introduced after
> the -3-5 branchoff.)
> 
> Thanks,
> 
> Miklos
> ___
> 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: [UX advise] Key navigation in ValueSet controls

[Stefan Knorr (Astron)]

Hi Matteo,

> Would you mind confirming them (yes/no will suffice)?

Yes. I believe that's all as we discussed. I hope all of this makes
sense, if not, we'll see later on. :)

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

Re: [PUSHED:3-5] fix STL assertion in vcl graphite code

[Petr Mladek]

Martin Hosken píše v Po 19. 03. 2012 v 15:22 +0100:
> Dear Petr,
> 
> Thank you for the reminder of this issue. My apologies for not getting to it 
> earlier.
> 
> > > 
> > > I do not understand the code either. I just wonder if it would make
> > > sense to check for:
> > > 
> > >   while (++nCharIndex - mnMinCharPos <
> > > static_cast(mvChar2BaseGlyph.size()))

> I would go with the first of these. It makes no sense to compare a
>  charIndex against a glyph->char mapping array, whose size is the
>  number of glyphs, not characters. I think it is simply a bug.

Sounds reasonable. I have updated the code in master, see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a878d3dbfdb11cf2f0cce9dbf28a408c130d556

And pushed it into 3-5 branch, see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a878d3dbfdb11cf2f0cce9dbf28a408c130d556


> Notice that I am not claiming authoritative understanding of this code
>  since it was written by Keith, who unfortunately is no longer with us
>  and so cannot comment. I am hoping that when I eventually get time to
>  work on this code, and particularly the mac port, I can refactor the
>  code and gain the necessary authoritative confidence.

It would be great. Thanks a lot for your opinion.

Best Regards,
Petr

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

Re: [REVIEW-3-5][CHERRY-PICKED-3-5] Fix fdo#45219 wrong transparency for animated objects.

[Radek Doulik]

Hi Thorsten,

looks good, cherry picked an pushed.

Cheers
Radek

On Fri, 2012-03-16 at 18:26 +0100, Thorsten Behrens wrote:
> Hi there,
> 
>   
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c7e061997202df9e602e209cf40c61606582e8e
> 
> fixes the most obvious glitch in fdo#45219 - multiple paints of the
> same sprite on top of each other, killing the hue for transparent
> objects.
> 
> (std::unique in this case _needs_ to eliminate duplicate, but
> otherwise equal-under-SpriteWeakOrder entries. Also, std::unique
> wants a BinaryPredicate, not a StrictWeakOrder. Note further that
> the used rtl::Reference does have a working operator==)
> 
> Cheers,
> 
> -- Thorsten
> ___
> 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

[PATCH] [REVIEW:3-5] graphical query editor mangles sorting order

[Lionel Elie Mamane]

Attached patch fixes (old! at least back to 3.3) bugs exposed by
fixing fdo#46843, about sort orders in the graphical query editor:

fdo#47370: when sort columns order does not match result columns
   order, sort is reordered to result order

   E.g. "SELECT a, b, c FROM foo ORDER BY c, a"
   becomes "SELECT a, b, c FROM foo ORDER BY a, c"

fdo#47560: when several sort columns are "out of result order", all
   are set to the last

   E.g. "SELECT a, b, c FROM foo ORDER BY c, a, b"
   becomes "SELECT a, b, c FROM foo ORDER BY c, b, b"

   That is simply because those "additional" sort columns were
   set in the *same* in-memory structure. Fix: allocate a
   fresh structure for each new sort column.

Please apply to libreoffice-3-5.

-- 
Lionel
>From bf1294a1597a50a495ae76aa111d411e254a8e41 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Tue, 20 Mar 2012 11:01:12 +0100
Subject: [PATCH 1/2] fdo#47370 properly duplicate (invisible) out-of-order
 sort columns

Keep track of position of previous sorting column and use it to decide whether to duplicate invisible new sort column
---
 .../source/ui/querydesign/SelectionBrowseBox.cxx   |   12 ++--
 .../source/ui/querydesign/SelectionBrowseBox.hxx   |1 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx b/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
index d13d5f9..177313c 100644
--- a/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
+++ b/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
@@ -68,6 +68,7 @@ const String g_strZero = String::CreateFromAscii("0");
 #define CHECKBOX_SIZE   10
 #define HANDLE_ID0
 #define HANDLE_COLUMN_WITDH 70
+#define SORT_COLUMN_NONE0x
 
 // -
 namespace
@@ -113,6 +114,7 @@ OSelectionBrowseBox::OSelectionBrowseBox( Window* pParent )
   BROWSER_HIDECURSOR | BROWSER_HLINESFULL | BROWSER_VLINESFULL )
,m_aFunctionStrings(ModuleRes(STR_QUERY_FUNCTIONS))
,m_nVisibleCount(0)
+   ,m_nLastSortColumn(SORT_COLUMN_NONE)
,m_bOrderByUnRelated(sal_True)
,m_bGroupByUnRelated(sal_True)
,m_bStopTimer(sal_False)
@@ -418,6 +420,7 @@ void OSelectionBrowseBox::ClearAll()
 aIter = getFields().rbegin();
 }
 }
+m_nLastSortColumn = SORT_COLUMN_NONE;
 SetUpdateMode(sal_True);
 }
 //--
@@ -1873,11 +1876,14 @@ void OSelectionBrowseBox::AddCondition( const OTableFieldDescRef& rInfo, const S
 //--
 void OSelectionBrowseBox::AddOrder( const OTableFieldDescRef& rInfo, const EOrderDir eDir, sal_uInt32 _nCurrentPos)
 {
+if (_nCurrentPos == 0)
+m_nLastSortColumn = SORT_COLUMN_NONE;
+
 Reference< XConnection> xConnection = static_cast(getDesignView()->getController()).getConnection();
 if(!xConnection.is())
 return;
 DBG_CHKTHIS(OSelectionBrowseBox,NULL);
-OSL_ENSURE(!rInfo->IsEmpty(),"AddOrder:: OTableFieldDescRef sollte nicht Empty sein!");
+OSL_ENSURE(!rInfo->IsEmpty(),"AddOrder:: OTableFieldDescRef should not be Empty!");
 OTableFieldDescRef pEntry;
 Reference xMeta = xConnection->getMetaData();
 ::comphelper::UStringMixEqual bCase(xMeta.is() && xMeta->supportsMixedCaseQuotedIdentifiers());
@@ -1896,7 +1902,7 @@ void OSelectionBrowseBox::AddOrder( const OTableFieldDescRef& rInfo, const EOrde
 bCase(aAlias,rInfo->GetAlias()))
 {
 sal_uInt32 nPos = aIter - rFields.begin();
-bAppend = _nCurrentPos > nPos;
+bAppend = (m_nLastSortColumn != SORT_COLUMN_NONE) && (nPos <= m_nLastSortColumn);
 if ( bAppend )
 aIter = rFields.end();
 else
@@ -1904,6 +1910,7 @@ void OSelectionBrowseBox::AddOrder( const OTableFieldDescRef& rInfo, const EOrde
 if ( !m_bOrderByUnRelated )
 pEntry->SetVisible(sal_True);
 pEntry->SetOrderDir( eDir );
+m_nLastSortColumn = nPos;
 }
 break;
 }
@@ -1914,6 +1921,7 @@ void OSelectionBrowseBox::AddOrder( const OTableFieldDescRef& rInfo, const EOrde
 OTableFieldDescRef pTmp = InsertField(rInfo, BROWSER_INVALIDID, sal_False, sal_False );
 if(pTmp.is())
 {
+m_nLastSortColumn = pTmp->GetColumnId() - 1;
 if ( !m_bOrderByUnRelated && !bAppend )
 pTmp->SetVisible(sal_True);
 pTmp->SetOrderDir( eDir );
diff --git a/dbaccess/source/ui/querydesign/SelectionBrowseBox.hxx b/dbaccess/source/ui/querydesign/SelectionBrowseBox.hxx
index 35b666f..50c0244

Re: [GBUILD] Can we get rid of recursively invoking custom targets ?

[Michael Stahl]

On 16/03/12 15:47, Matúš Kukan wrote:
> Hi,
> 
> I'd like to propose removing gbuild_simple.mk over time.
> Surely there will be more custom targets as gbuild is growing and I
> can't see why we would need gbuild_simple.
> Instead we can write rules to Package_foo.mk makefiles or if that
> would be problem (because they will be ugly)
> We can start using CutomTarget_foo.mk which will be supposed to be ugly.
> 
> The reasons are:
> 1, Sometimes we need to parse custom target's Makefile each time as in
> packimages case.
> I had to use:
> $(eval $(call gb_CustomTarget_add_outdir_dependencies,packimages/pack,\
> $(gb_Helper_PHONY) \
> ))
> to achieve that.
> 
> 2, It is enough then to write dependencies only once.
> 
> 3, No need to maintain gbuild_simple.
> 
> 4, No recursive make running.

i think nobody really likes the way custom targets are currently
implemented, and iirc Bjoern even denies being responsible for the design :)

having to write dependencies twice so the recursive make invocation
works is really annoying and error-prone.

there are some potential problems with having the custom stuff in the
same make process, but i think these are solvable:

1. var namespace collisions:
   because make doesn't have namespaces for global variables, it's
   possible that variables defined in different modules' custom
   makefiles have the same name and thus collide.
   this can be avoided by agreeing to a naming convention, such as
   prefixing all variables by the name of the module where they are
   defined, and reviewing all custom makefiles so that this convention
   is met.

2. pattern rule collisions:
   the pattern rules defined in a lot of custom makefiles also can lead
   to collisions, both with other custom makefiles, and with the
   pattern rules defined in solenv/gbuild, which is complicated due
   to different pattern rule matching in make 3.81 and 3.82.
   so the pattern rules in custom makefiles should all have targets of
   the form $(WORKDIR)/CustomTarget/$(MODULE)/... and this prefix
   should be different across modules and so the problem of getting
   these to work in 3.81 and 3.82 should be module local and hence
   hopefully manageable.

[for non-custom makefiles both of these problems are avoided by
designing gbuild so that variables and pattern rules are only defined in
solenv/gbuild, not in user makefiles.]

> I am sending two patches for packimages.
> Maybe we should use the second one and keep Package_foo.mk pretty ?
> One small disadvantage is that we need to depend on directory.
> 
> It allows as to use compatible mode and keep old way of processing
> custom targets until they are replaced.
> There are 31 custom targets now, so that should not be a big problem.
> I can do it over time or maybe we could even write an easy hack for that.
> The important thing is to write new custom targets in
> CustomTarget_foo.mk makefile.
> 
> What do you think ? Am I missing something ?

so overall i think your proposal is a good direction to go.

your second patch (with the CustomTarget_foo.mk) looks better to me, as
having the ugly custom stuff easily discoverable is a good idea;
but please rename the CDPI variable to packimages_CDPI or expand it
(also, CUSTOM_images, CUSTOM_PREFERRED_FALLBACK_[12])

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

Re: [PUSHED:3-5] fix for fdo#47503, crash opening a xls file with chart

[Petr Mladek]

Markus Mohrhard píše v Út 20. 03. 2012 v 05:07 +0100:
> Hey,
> 
> [1] fixes the crash opening the file in fdo#47503. The code in
> ScDocument::HasData needs to check that the sheet index is valid
> before it uses the sheet index to access the table.
> 
> This patch is simple and safe and I think we easily integrate it into 3-5.

Yup, it makes sense and solves the crash. I have pushed it into the 3-5
branch, see
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=f24545a72cf43d0852c4f8edae0b3a9919120cdd


Best Regards,
Petr

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Bug 37361 depends on bug 46843, which changed state.

Bug 46843 Summary: EDITING: Queries loose sorting-order when reopening for 
editing
https://bugs.freedesktop.org/show_bug.cgi?id=46843

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Lionel Elie Mamane  changed:

   What|Removed |Added

 Depends on||47560

-- 
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: [PUSHED:3-5] fdo#46843 graphical query editor loses sorting order

[Petr Mladek]

Lionel Elie Mamane píše v Po 19. 03. 2012 v 16:51 +0100:
> On Mon, Mar 19, 2012 at 04:31:34PM +0100, Petr Mladek wrote:
> > It works better, definitely. I wonder if there is one more bug or if it
> > needs another values instead of the hardcoded "4".
> 
> Yes, there is one more bug, filed as fdo#47370. I'm working on it. Ah,
> I should make it most annoying, forgot to do that. Doing now.

Great. Thanks for explanation. The fix for fdo#46843 is thus part of the
overal fix, it improves the situation a lot, makes perfect sense, so I
have pushed it, see
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=73a5ef4cb245acb120f02d487ba7c3aeb40f4fad


Best Regards,
Petr



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

Re: [PUSHED:3-5] Fix redundant assignment of "nAngle" in switch in svx

[Petr Mladek]

Petr Mladek píše v Út 20. 03. 2012 v 09:49 +0100:
> Yup, I see the values used also svx/source/items/algitem.cxx in
> SvxOrientationItem::SetFromRotation. I can't imagine any workaround for
> this bug because the angle 9000 has newer been assigned. Your fix is
> correct and looks safe => I have pushed it to 3-5 branch, see
> http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=85c6043d0d339d3df6a4037eedce78df38272ea6

Marked the thread as pushed.

Best Regards,
Petr

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

Re: [REVIEW for 3.5] Fix redundant assignment of "nAngle" in switch in svx

[Petr Mladek]

julien2412 píše v Po 19. 03. 2012 v 14:40 -0700:
> yep it creates fractal :-)

You know, it is better to be careful. There are many workarounds for
bugs in the code. For example, there was a bug in widgets ordering. The
workaround made one widget transparent and passed events to the other
widget. Once we fixed the ordering, the other widget was suddenly
hidden. So the fixed bug caused regressions ;-)


> More seriously, I saw that it's at least used here in this file
> sw/source/core/doc/tblafmt.cxx (line 413)

Yup, I see the values used also svx/source/items/algitem.cxx in
SvxOrientationItem::SetFromRotation. I can't imagine any workaround for
this bug because the angle 9000 has newer been assigned. Your fix is
correct and looks safe => I have pushed it to 3-5 branch, see
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=85c6043d0d339d3df6a4037eedce78df38272ea6

You do great work!


Best Regards,
Petr

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

[PATCH] convert tools/table.hxx usage to std::map in Basic IDE module

[Noel Grandin]

Hi

License is on file.

Passes make check and some UI testing.

Regards, Noel Grandin

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




0001-Convert-tools-table.hxx-usage-to-std-map-in-Basic-ID.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED] Deleting some commented out code.

[Stephan Bergmann]

On 03/19/2012 11:59 PM, Luke Petrolekas wrote:

and some more, also contributed under the LGPLv3+ / MPL.

On Mon, Mar 19, 2012 at 6:46 PM, Luke Petrolekas
mailto:luke.petrole...@gmail.com>> wrote:

I would have thought we would have deleted all commented out stuff
already! :) Woot for first commit in nearly a year.

Code is contributed under the LGPLv3+ / MPL.


Pushed both patches to master now.

Luke, can you please add yourself to 
, including a 
link to your license statement?


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

Re: Cppcheck reports "Logical conjunction always evaluates to false" in text_gfx.cxx

[Stephan Bergmann]

On 03/19/2012 10:25 PM, julien2412 wrote:

remarks :
- I replaced this
 nChar>= 0xff62&&  nChar<  0xff64
by this for readability
 nChar == 0xff62 || nChar == 0xff63
- I added in the outer "if", "nChar == 0xffe3" because if not, "nChar ==
0xffe3" in the inner "if" is useless.

Is this patch ok ?
If yes, I can commit and push it on master.


I at least know just as little as anybody else whether this is right or 
not (the U+FFE3 FULLWIDTH MACRON still looks odd here, but who knows). 
Presumably the patch is fine, but to know for sure somebody would have 
to dig out what exactly the code is actually supposed to do.


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

Re: Unused code patches

[Stephan Bergmann]

On 03/19/2012 09:26 PM, Lubos Lunak wrote:

On Monday 19 of March 2012, David T. Biedrzycki wrote:

There are *many* methods that have already been
removed that are still listed. If we are missing something, please let us
know, otherwise, we have been working on, and have almost finished,
automating a process to remove methods from that file that no longer exist
in the source.


  That will not work reliably, unless your process also verifies that they are
really unused in all configurations. The list is generated from one
configuration and a manual check is needed that each item is indeed unused.


I think you are talking past each other here.  David asked about 
functions listed in unusedcode.easy that are no longer existing in the 
code base, while Lubos warned against automatically removing functions 
from the code that are listed in unusedcode.easy.


David, unusedcode.easy is generated afresh rather regularly by Caolan, 
so should not be too outdated (but there indeed was lots of activity 
around removing unused code recently, IIRC) -- you can look into its git 
log to find out how old it currently is.


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

RE: [PATCH]fdo45671 set initial colours for split buttons

[Winfried Donkers]

> Sent: zondag 11 maart 2012 09:07
> Subject: [PATCH]fdo45671 set initial colours for split buttons
> 
> The attached patch contain sthe changes to set the initial colours for
> split buttons as discussed on this list last week.
> I also placed some comments as the initials colours are set in up to 3
> different places.
> 
> Winfried

Astron,

Is this the initial setting you wanted? AFAICS it hasn't been pushed yet, nor 
rejected :)

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

[Bug 41883] MinGW port Most Annoying Bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||47548

--- Comment #13 from Rainer Bielefeld  
2012-03-20 00:08:39 PDT ---
Add "Bug 47548 - [MinGW] build will not launch"

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