Re: new automated test concept for chart2

[Cor Nouws]

Hi Markus,

Writing to the Dutch Discuss list for people that do some things with 
charts...
From the text below,is it correct that I can tell them to just make 
some simple example files, which preferably clearly shows one issue, and 
add them to the issue ?


Markus Mohrhard wrote (28-03-12 05:30)

All you need to
create a new test case is a bit of time.
For everyone interested in writing and extending chart tests please
have a look at: https://bugs.freedesktop.org/show_bug.cgi?id=47667


Regards,

--
 - Cor
 - http://nl.libreoffice.org

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

Re: build breaks - icu49 ?

[Andreas Radke]

confirmed. builds well with internal ICU.

anyone who can have a look at this?

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

new automated test concept for chart2

[Markus Mohrhard]

Hey,

finally I was able to finish my work on a chart2 test concept. I have
implemented an idea that renders the chart and then dumps the layout
data into an xml based on the information stored in the
XShape/XShapes. This allows us to easily add new test cases without
having to know anything about programming or chart2. All you need to
create a new test case is a bit of time.
For everyone interested in writing and extending chart tests please
have a look at: https://bugs.freedesktop.org/show_bug.cgi?id=47667

So here some more technical details for all who are interested in it:

The dumper code is in chart2/source/view/main/ChartView.cxx and takes
the drawing::XDrawPage and dumps the containing XShape/XShapes into
xml. The dumper can be easily extended and it would be nice if
everyone fixing a bug in chart2 could have a look at it and check if
this bug could have been prevented if the dumper would included some
more information.
BY enabling the debug output of the dumper you will get a list of
supported service names in the dump and can just add a method for this
service or for one interface of this service.

It might be that the same code is valuable for Draw/Impress too and we
can then think about extracting the dumper and moving it into test.


The test is not yet activated but is working already. So if you want
to play a bit with it just add it into Module_sc.mk. Feedback as
always highly appreciated. If there are no objections I plan to
activate the test in sc's subsequentcheck target at the end of the
week.

Regards,
Markus

P.S. For calc devs I will add a hidden export filter that exports the
same content to make debugging chart bugs easier.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in helpcontent2

[Norbert Thiebaud]

On Tue, Mar 27, 2012 at 6:29 AM, Michael Meeks  wrote:
>
> On Tue, 2012-03-27 at 09:00 +0100, Mark Stanton wrote:
>> Thanks for your help.  Looks like you're right.  The branch output is
>
>        This happens quite a lot, even to me ;-)
>
>        I wonder - how hard would it be to add a feature to core/g to check
> that the checkout is consistent, and add that to configure.in :-)

That would be just another kind of pita...

1/  the additional git repos are not there at initial configure...
they get cloned during make fetch. so you can't check them. and if
they were there ./g would have worked to start with.
2/ it is quite common for people to only branch core when then do
feature branch or even local branch to test some patch or the like...

That problem would be solved by git submodule btw. since checking out
core would also select the 'right' commit on all submodules

I have not taken the time to play more with that, but their maybe a
way to have it do the right thing from git by just tweaking
.git/config (*)
in which case all that would be needed is a 'setup' script to set the
right value in .git/config once an for all
(of course the main pita would be the transition before-after
submodule... I haven't found a satisfactory solution to allow for
checking-out to a point prior to the 'sub-modulization' or
vice-versa... but that is a 'temporary pain.. just like onegit was...

Norbert

(*) submodules support would also require gerrit 2.3 which is still  in Beta.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Windows SDK is not found

[Regina Henschel]

Hi Fridrich,

Fridrich Strba schrieb:

Hello, Regina,

I would suggest as the best option is to install Windows SDK 7.1 that
installs even on Windows XP boxes and register it as a default SDK with
the Visual Studio.

This is what I use here and life is wonderful.


I have installed Windows SDK 7.1 now. "Register as default SDK" is still 
not possible. But configure reports no errors, so I will go on tomorrow.


Kind regards
Regina





On 27/03/12 13:24, Regina Henschel wrote:

Hi all,

Lubos Lunak schrieb:

On Monday 26 of March 2012, Kohei Yoshida wrote:

On Mon, Mar 26, 2012 at 5:14 PM, Regina Henschel

   wrote:

I have tried also with
--with-windows-sdk-home="/cygdrive/c/Programme/Microsoft
SDKs/Windows/v6.0A"


I believe that configure option has been renamed to
--with-dotnet-framework-home.  E.g. I have

  --with-dotnet-framework-home="/cygdrive/c/Program Files/Microsoft
SDKs/Windows/v7.0A"

in my configure option.


No, that does not solve the problem, neither with
--with-dotnet-framework-home alone nor in combination with
--with-windows-sdk-home


Hmm..  Anyone else have any ideas?


   I think one thing that has changed relatively recently is that the
SDK must
be registered as default with Visual Studio (in the menu: Microsoft
Windows
SDK 7.1 ->   Visual Studio Registration ->   Windows SDK Configuration
Tool).

   You can also have a look at configure.in to see what the check
actually looks
for.



I have examined configure.in and found this:
The automatic detection results in
$WINDOWS_SDK_HOME = /cygdrive/c/Programme/Microsoft SDKs/Windows/v6.0A
There configure is looking for the files
$WINDOWS_SDK_HOME/bin/msiinfo.exe
$WINDOWS_SDK_HOME/bin/msidb.exe
$WINDOWS_SDK_HOME/bin/msitran.exe
$WINDOWS_SDK_HOME/bin/uuidgen.exe

And indeed these files are not there. But I have found these files in
C:\Programme\Microsoft Platform SDK for Windows Server 2003 R2\Bin
and in
C:\Programme\Microsoft SDKs\Windows\v6.1\Bin

So which are the correct ones to use?

Kind regards
Regina


___
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: About fdo#47865, Crash on Writer when a footnote is inserted

[Simos Xenitellis]

On Tue, Mar 27, 2012 at 11:39 PM, julien2412  wrote:
> Hello,
>
> Am i the only one to have the problem described there
> :https://bugs.freedesktop.org/show_bug.cgi?id=47865
> I still reproduce it with master updated today, last commit :
> 1e91520e7af29c390c03d05b39992da5aaf6d1c7.
>
> Any idea ?
>

Did you

mv ~/.libreoffice ~/.libreoffice.disabled

and open LibreOffice Writer again?

Could not reproduce either with master.

In any case, if some settings in ~/.libreoffice/ cause the problem,
those settings are useful to identify the source of the problem.

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

About fdo#47865, Crash on Writer when a footnote is inserted

[julien2412]

Hello,

Am i the only one to have the problem described there
:https://bugs.freedesktop.org/show_bug.cgi?id=47865  
I still reproduce it with master updated today, last commit : 
1e91520e7af29c390c03d05b39992da5aaf6d1c7.

Any idea ?

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/About-fdo-47865-Crash-on-Writer-when-a-footnote-is-inserted-tp3862714p3862714.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

initializing extensions in daily from Master slooow

[Cor Nouws]

Hi,

Experienced with some daily build the last week(s) that initializing 
extensions on the first start is verry slow.

Known ? Issue ?

Cheers,

--
 - Cor
 - http://nl.libreoffice.org

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

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

[Caolán McNamara]

On Tue, 2012-03-27 at 21:20 +0200, Santiago Martinez wrote:
> This patch removes unused code as listed in unusedcode.easy 

looks good, pushed, thanks for this.

C.

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

[PATCH] Remove unused code (l10ntools)

[Santiago Martinez]

This patch removes unused code as listed in unusedcode.easy
From 85de68332e5419fbf2ef58957a9c11f588fad6c1 Mon Sep 17 00:00:00 2001
From: Santiago Martinez 
Date: Tue, 27 Mar 2012 21:16:50 +0200
Subject: [PATCH] Remove unused code in l10ntools.

---
 l10ntools/inc/xmlparse.hxx|6 
 l10ntools/source/xmlparse.cxx |   61 -
 unusedcode.easy   |2 -
 3 files changed, 0 insertions(+), 69 deletions(-)

diff --git a/l10ntools/inc/xmlparse.hxx b/l10ntools/inc/xmlparse.hxx
index cd9bc2b..0731a9f 100644
--- a/l10ntools/inc/xmlparse.hxx
+++ b/l10ntools/inc/xmlparse.hxx
@@ -169,13 +169,7 @@ public:
 XMLChildNode *pChild , size_t pos   /// the new child
 );
 
-int RemoveChild( XMLElement *pRefElement );
 void RemoveAndDeleteAllChildren();
-
-/// returns a child element which matches the given one
-XMLElement *GetChildElement(
-XMLElement *pRefElement // the reference elelement
-);
 };
 
 //-
diff --git a/l10ntools/source/xmlparse.cxx b/l10ntools/source/xmlparse.cxx
index e646308..5be1f0e 100644
--- a/l10ntools/source/xmlparse.cxx
+++ b/l10ntools/source/xmlparse.cxx
@@ -159,37 +159,6 @@ void XMLParentNode::AddChild( XMLChildNode *pChild , size_t pos )
 }
 
 /*/
-int XMLParentNode::RemoveChild( XMLElement *pRefElement )
-/*/
-{
-XMLElement* a;
-if ( pChildList ){
-for ( size_t i = 0; i < pChildList->size(); i++ ) {
-XMLChildNode *pChild = (*pChildList)[ i ];
-if ( pChild->GetNodeType() == XML_NODE_TYPE_ELEMENT ){
-a = static_cast(pChild);
-rtl::OString elemid(a->GetId().toAsciiLowerCase());
-rtl::OString elemLID(a->GetLanguageId().toAsciiLowerCase());
-rtl::OString pRefLID(
-pRefElement->GetLanguageId().toAsciiLowerCase());
-if (elemid == pRefElement->GetId() && elemLID == pRefLID)
-{
-if( pRefElement->ToOString().compareTo( a->ToOString() )==0 ){
-XMLChildNodeList::iterator it = pChildList->begin();
-::std::advance( it, i );
-pChildList->erase( it );
-delete a; // Test
-return i;
-}
-}
-}
-
-}
-}
-return -1;
-}
-
-/*/
 void XMLParentNode::RemoveAndDeleteAllChildren(){
 /*/
 if ( pChildList ) {
@@ -199,36 +168,6 @@ void XMLParentNode::RemoveAndDeleteAllChildren(){
 }
 }
 
-/*/
-XMLElement *XMLParentNode::GetChildElement( XMLElement *pRefElement )
-/*/
-{
-for ( size_t i = 0; i < pChildList->size(); i++ ) {
-XMLChildNode *pChild = (*pChildList)[ i ];
-if ( pChild->GetNodeType() == XML_NODE_TYPE_ELEMENT )
-if ((( XMLElement * ) pChild )->GetName() ==
-pRefElement->GetName())
-{
-XMLAttributeList *pList = pRefElement->GetAttributeList();
-if ( !pList )
-return ( XMLElement * ) pChild;
-
-sal_Bool bMatch = sal_False;
-for ( size_t j = 0; j < pList->size() && bMatch; j++ ) {
-XMLAttribute *pAttribute = (*pList)[ j ];
-XMLAttribute *pCandidate =
-(( XMLElement * ) pChild )->GetAttribute(
-pAttribute->GetName() );
-if ( !pCandidate || !pAttribute->IsEqual( *pCandidate ))
-bMatch = sal_False;
-}
-if ( bMatch )
-return ( XMLElement * ) pChild;
-}
-}
-return NULL;
-}
-
 //
 // class XMLFile
 //
diff --git a/unusedcode.easy b/unusedcode.easy
index 54ba512..79a729f 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -341,8 +341,6 @@ XMLFontAutoStylePoolNames_Impl::Remove(rtl::OUString*)
 XMLFontAutoStylePool_Impl::GetPos(XMLFontAutoStylePoolEntry_Impl const*) const
 XMLFontAutoStylePool_Impl::Remove(XMLFontAutoStylePoolEntry_Impl*)
 XMLParentNode::AddChild(XMLChildNode*, unsigned long)
-XMLParentNode::GetChildElement(XMLElement*)
-XMLParentNode::RemoveChild(XMLElement*)
 XMLPropertyBackpatcher::XMLPropertyBackpatcher(char const*)
 XMLPropertyBackpatcher::XMLPropertyBackpatcher(char const*, char const*, unsigned char, rtl::OUString)
 XMLPropertyBackpatcher::XMLPropertyBackpatcher(rtl::OUString const&, rtl:

Re: [PATCH] [PUSHED] Convert the SV PTRARR_DEL to boost::ptr_vector

[Kohei Yoshida]

On Mon, 2012-03-26 at 23:50 +0200, Bartosz wrote:

> I converted the SV PTRARR_DEL to boost::ptr_vector in sw component.
> Could you please check and push this path?

Looks good to me.  Pushed to master.

Thanks a lot.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc

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

Re: [PATCH] convert tools/table.hxx usage in to std::map in ScChartPosition class in SC module

[Ivan Timofeev]

On 27.03.2012 10:31, Ivan Timofeev wrote:

I will push this patch with some corrections towards evening,


Hum, towards *tomorrow's* evening. :)

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

Re: ancient openssl bundled

[Norbert Thiebaud]

On Tue, Mar 27, 2012 at 12:33 PM, Enrico Weigelt  wrote:
>
> I'll maintain my downstream fork dropping the 3rdparty packages step
> by step. (I'll contigiously rebase, to I'll be ontop of master).
>
Again. most packager for unix based distro can do just that with the
proper configure argument of LibreOffice out of the box.
And MacOSX does that to for the few library that _are_ in the standard system...

we maintain a copy of the external libraries for the platforms that
don't have them.. but you _can_ use the system version for most of
them if your system have them.

Norbert
___
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 39928, which changed state.

Bug 39928 Summary: VIEWING: pictures in particular .doc shown wrong, picture 
size correct, but contents shrunken and surrounded by white margin.
https://bugs.freedesktop.org/show_bug.cgi?id=39928

   What|Old Value   |New Value

 Resolution||FIXED
 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: ancient openssl bundled

[Enrico Weigelt]

>   :-) if you have fixes / improvements they are most welcome. Clearly
> waiting for an up-stream release (eg. gnumake - at over 12 months
> since the last release), is not always an option - at which point, you have
> to patch the pristine source tar-ball; checkout the patch count on most
> working linux distributions :-)

In that case: join in the upstream project or the distros to fix the
problem at the source.

About 10 years ago, I've started the "OSS QM project" which tried to do
some kind of overlay repository for all those packages where upstream
is too slow (or sometimes even unwilling) to do necessary fixes, which
are left to the distros (but instead doing general fixes instead of
distro-specific hacks). I've utilized this, eg., in several of my
embedded projects (eg. at that time many fundamental packages were
simply not crosscompilable out-of-the-box, quite often due the
conceptionally broken nature of autotools). Unfortunately, nobody
(outside my own consuming projects) joined in - distros and upstreams
prefered not to speak with each other :(
(often silly rivals between distros, etc).

>   Sounds like they fell into the embedded linux trap, and needed to
> standardise on a better setup shared with others, pocky / Yocto or
> something. I agree with your analysis here.

Yep, but that's not a technological problem. Proper technologies are
available for long time (I've also got my own one here, but others
like eg. PTXdist also would have suited fine here). Instead it's a
mental problem of the decision makers. Not even an economic issue,
as I showed by cost numbers.

> So - perhaps I just don't understand the alternative well enough;
> lets assume we find a build bug in openssl on some minority platform - say
> AIX, what does your perfect-world flow look like :-)

Report it to openssl project. They'll keep up quite fast.
And, of course, inform the AIX package maintainer. Maybe the fix
will take a while to get into upstream, but that's not a problem if
the according distro(s) react fast enough.

On the other hand: if you bundle a package, you'll need to do virtually
everything that the distros normally do (for that package).
Perhaps you can get your fix used a few days earlier, but this requires
you to have the necessary resources to do the whole maintenance all
on your own. Do you really have them ?


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

Re: ancient openssl bundled

[Tor Lillqvist]

> M$

Bt. Thanks for playing!

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

Re: ancient openssl bundled

[Enrico Weigelt]

>   Sounds good to me; as/when you have a nice, working package
>   management
> system for Windows & Mac, that is invisible to the user, and handles
> one-click application downloads, creates no extra unwanted UI
> interfaces, and deals with version requirement skew across unrelated
> applications [ unwinding the Windows DLL hell ], then we'll want to
> use
> it I'm sure. You could try poking at what the CoApp guys do, they
> have
> some similar ideas, but it's not such an easy problem to solve I
> think.

Yep, that's a really good hint.
I'd like to encourage the windows folks here to jump on that train.

I, personally, can't be of much help here, as I've lef the M$ world
over 15 years ago (dont even have a single windows instance since that)

> > > If your intention is to update the internal opensssl, then the
> > > best
> > > is to do that in a bug in our bugzilla
> > 
> > No, I absolutely don't intend that.
> 
>   Shame :-) someone needs to update that thing and re-validate it.

NAK. Someone needs to drop them. (as explained earlier)

Assuming the window folks go on the coapp route (or something similar),
we'll have no need for bundling them anymore in near future.
They can switch off building/using the bundled libs one by one
(as already on *nix side by the --without-system-foo switches)

I'll maintain my downstream fork dropping the 3rdparty packages step
by step. (I'll contigiously rebase, to I'll be ontop of master).

Once windows are ready to live without a certain 3rdparty package,
we can take the appropriate patch from my branch to mainline.

But for all of this, the main strategy must be clear: move the
dependency handling to out of the application layer to the distro
layer.

> > I've already seen that reaction coming. Seen the same in dozens
> > over
> > dozens of other projects in the last 15 years. None of these
> > projects
> > ever agreed do solve that problem once and for all by a generic
> > solution
> 
>   So - perhaps sitting down and understanding why developers don't go
> routinely updating their external libraries and solving the problems
> they see there might work - why do we have an ancient openssl
> internally ? is it the pain of re-basing our patches ? is it that we
> are conservative & scared of touching things that appear to work ? :-) 

Probably both: manually rebasing patches is ugly. That's why clever
people invented SCMs like git. And, oh, that's also why the concpet
of modularization was invented somewhen in the 60th of the last century.

Being scared of what changes might changes might do might be another
reason. In the linux embedded project I meantioned in earlier mail,
I was really the only person who knew how to configure and build a
kernel in that team, until about half a year another freelancer came
into the team (but unfortunately was allocated for a completely
different product). Again, that's yet another reason why the concept
of modularization was invented (unncessary to mention that modules
and libraries are completely different concepts).

> is it that it is hard to test changes on mutiple platforms, and
> external deps tend to be the most fragile pieces ? would a gerrit
> flow help that ? etc.

Yes. And that's why distros were invented. They know their scope
(supported hardware, involved software, user requirements, etc, etc)
very well. All of these things we cannot really handle properly in
an application development project. If wanted to, we needed to do an
full-blown distro on our own.

The bottom line is: you've raised good arguments. Against bundling.

>   Ultimately, the overhead of shipping duplicates seems somewhat small
> size-wise in a world where people virtualise & duplicate whole
> operating
> systems on their devices in virtual machines, at least compared to
> the
> convenience of pseudo-application-virtualisation ;-)

Distribution size is not an argument anymore. But RAM requirements
still is - these bundled libraries cannot be shared with other
applications. (well, in *theory* this *could* be done, in specific
cases, when other applications use mostly *equal* binaries, using
KSM - but how likely is that ? ;-o)


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

Re: ancient openssl bundled

[Michael Meeks]

Hi Enrico,

On Tue, 2012-03-27 at 19:04 +0200, Enrico Weigelt wrote:
> Most of the patches are ancient, against ancient versions, completely
> outdated. Many of them are only quick and dirty hacks for the bundled
> building

:-) if you have fixes / improvements they are most welcome. Clearly
waiting for an up-stream release (eg. gnumake - at over 12 months since
the last release), is not always an option - at which point, you have to
patch the pristine source tar-ball; checkout the patch count on most
working linux distributions :-)

> Just a sidenote: in one of my recent projects, i've been working on
> for about a year, we had exactly the same problem. It's a software for
> medical data aquisition computers und Linux embedded devices.

Sounds like they fell into the embedded linux trap, and needed to
standardise on a better setup shared with others, pocky / Yocto or
something. I agree with your analysis here.

> PS: please forgive me, if I'm a bit too emotional, but I really hate
> seeing resources burned on nonsense.

So - perhaps I just don't understand the alternative well enough; lets
assume we find a build bug in openssl on some minority platform - say
AIX, what does your perfect-world flow look like :-)

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: Experiemental interactive formula editing ...

[Regina Henschel]

Michael Meeks schrieb:

Hi guys,

I wondered - are there any serious known issues in this anymore ?
and/or is there any reason why it's left as an experimental feature ?


I know that users coming from Word MathType will like it. But I do not 
want to use it and need an option to disable it, when it leaves 
"experimental mode".


Main reason for me: It does not preserve the StarMath notation.

In more detail:
The feature works directly on the MathML code. But that does not know 
all StarMath markup. For example "sum from {i=1} to n {n_i cdot 2^i}" or 
"1 over 22 = nospace{0,0 overline {45}}"


If you use the new feature, then the formulas are changed. Try it, 
change for example "2" to "3". Without that feature the StarMath markup 
is preserved as annotation inside the MathML code and restored when loading.


If the new feature is enabled, then those working with the command 
window like me loose the ability to mark a part of the formula by 
double-click on it in the rendering. And that is needed for easily 
changing single figures or variables in a complex formula.


Therefore I want to be able to still use the old kind editing.

Kind regards
Regina



--- a/starmath/source/view.cxx
+++ b/starmath/source/view.cxx
@@ -2134,7 +2134,7 @@ void SmViewShell::Notify( SfxBroadcaster&  , const 
SfxHint&  rHint )

  bool SmViewShell::IsInlineEditEnabled() const
  {
-return pImpl->aOpts.IsExperimentalMode();
+return true;
  }

  /* vim:set shiftwidth=4 softtabstop=4 expandtab: */


Having had Jonas do all the work, it seems a shame not to ship it -
right ? :-) Olivier - do you have a view ?

All the best,

Michael.



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

Re: ancient openssl bundled

[Enrico Weigelt]

>   It'd be lovely to have that done & tested :-) of course, some
>   careful
> work is needed to ensure that the existing patches are either forward
> ported, or checked to ensure that they are no longer needed.

ACK. The existance of those patches already shows the problem I was
talking about in my previous mail.

Most of the patches are ancient, against ancient versions, completely
outdated. Many of them are only quick and dirty hacks for the bundled
building (often simply done just because the package's build system
was not driven correctly).

Folks, this is the typical maintenance hell, I've already seen in
lots of commercial/inhouse projects, that most likely come from the
unwillingness of certain managers that don't want to invest a few
resources in clean long-term solution (and fail to see that such
hacks become magnitudes more expensive in the longer run). Just look
at any larger former-commercial codebase, Mozilla is also good
example for this.

Just a sidenote: in one of my recent projects, i've been working on
for about a year, we had exactly the same problem. It's a software for
medical data aquisition computers und Linux embedded devices.
These guys had bundled all the 3rdparty packages (beginning with an
*really* ancient kernel, with really dirty hacked patches - up to
lots of userland libraries). The build system was utterly complex
and untable (when I came in, it only worked on an ancient customized
Debian system, which of nobody had backed up ;-o). They completely
refused the idea that this mess produces costly maintenance overhead.
They claimed that this stuff wouldn't need to be touched, even while
we *DID* need to touch it exactly for this tasks I was hired for.

And I have real economic numbers on that: on my first weeks I proposed
a cleanup and using a generic embedded distro engine (eg. Briegel or
PTXdist), would have manpower costs of about 10kEUR. Obviously, they
refused and continued the old way. Within that year, this old was
produced costs in the scale of 50kEUR (without solving the actual
problem, so I guess these costs will come every year, again and again).

Well, these jerks were funny anyways: they're using MSVC for coding
(via SMB shares) and use Team Foundation Server als source control
(more precisely: what they belive in what source countrol would be).
I've measured the extra costs compared to git: about 2kEUR per month.


cu

PS: please forgive me, if I'm a bit too emotional, but I really hate
seeing resources burned on nonsense.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] format clipboard

[Maxime de Roucy]

Hello,

Following my discussion with Cedric on IRC here is some other
explanations on why I chose to remove the "nSelectionType ==
nsSelectionType::SEL_TBL" case from the lcl_CreateEmptyItemSet function
in formatclipboard.cxx.

Without the patch : lcl_CreateEmptyItemSet is called only in the
formatclipboard.cxx file, at line 326, 399 and 511. At line 399, the
function is called with the nSelectionType parameter equal to
nsSelectionType::SEL_TBL. At the other place the function is called
with the nSelectionType parameter equal to the output of
"rWrtShell.GetSelectionType();". rWrtShell is a SwWrtShell. If you look
in the SwWrtShell::GetSelectionType function (line 1412 file
sw/source/ui/wrtsh/wrtsh1.cxx) you will see that when the program take
the only path where the function output can hold an
nsSelectionType::SEL_TBL attribut, the "shorter" function output is equal
to : "GetCntType() | nsSelectionType::SEL_TBL".
Then if you look in the SwEditShell::GetCntType function
(sw/source/core/edit/edws.cxx line 163) you will see this function HAVE
TO return something different from 0 : "OSL_ASSERT( nRet );"

Then we can say that the "rWrtShell.GetSelectionType();" instruction
can't return exactly "nsSelectionType::SEL_TBL". So the "nSelectionType
== nsSelectionType::SEL_TBL" part of the lcl_CreateEmptyItemSet
function is only call by the "lcl_CreateEmptyItemSet(
nsSelectionType::SEL_TBL, rPool );" instruction (line 399).

I think the "nSelectionType == nsSelectionType::SEL_TBL" part of the
lcl_CreateEmptyItemSet function is confusing so I moved it line 399
(just to recall : line 399, the only place where it is currently executed).

I hope this clarified a bit my choice to remove the "nSelectionType ==
nsSelectionType::SEL_TBL" part from the lcl_CreateEmptyItemSet
function.

Regards

Maxime de Roucy

-- 
Maxime de Roucy
Groupe LINAGORA - OSSA
80 rue Roque de Fillol
92800 PUTEAUX
Tel. : 0 810 251 251


Le vendredi 16 mars 2012 à 10:16 +0100, Maxime de Roucy a écrit :
> Here a copy of the mail I send to Cedric Bosdonnat… forgot to add the
> list as "Cc:".
> 
> Hello
> 
> Thanks you for asking me…
> 
> When you select a cell in Writer the selection type is a mix of
> nsSelectionType::SEL_TBL_CELLS, nsSelectionType::SEL_TBL and
> nsSelectionType::SEL_TXT.
> So when the lcl_CreateEmptyItemSet function is called directly with
> the nSelectionType (from rWrtShell.GetSelectionType()) the if
> statement "nSelectionType == nsSelectionType::SEL_TBL" is false.
> 
> So in the SwFormatClipboard::Copy function there is another
> statement : 
> 
> 
> 
> __
> 
> 
> 
> 
>   if( nSelectionType & nsSelectionType::SEL_TBL_CELLS )//only copy table 
> attributes if really cells are selected (not only text in tables)
>   {
>   m_pTableItemSet = lcl_CreateEmptyItemSet( 
> nsSelectionType::SEL_TBL, rPool );
>   lcl_getTableAttributes( *m_pTableItemSet, rWrtShell );
>   }
> 
> 
> 
> __
> 
> 
> 
> 
> That call lcl_CreateEmptyItemSet with just nsSelectionType::SEL_TBL if
> the real selection type contain nsSelectionType::SEL_TBL_CELLS.
> 
> I found this way of doing a bit confusing and as tables parameters are
> handle separately in the whole format paintbrush code I thought that
> replacing : 
> 
> 
> 
> __
> 
> 
> 
> 
>   m_pTableItemSet = lcl_CreateEmptyItemSet( nsSelectionType::SEL_TBL, 
> rPool );
> 
> 
> 
> __
> 
> 
> 
> 
> by : 
> 
> 
> 
> __
> 
> 
> 
> 
>   m_pTableItemSet = new SfxItemSet(rPool,
>   SID_ATTR_BORDER_INNER,  SID_ATTR_BORDER_SHADOW, 
> //SID_ATTR_BORDER_OUTER is inbetween
>   RES_BACKGROUND, RES_SHADOW, //RES_BOX is inbetween
>   SID_ATTR_BRUSH_ROW, SID_ATTR_BRUSH_TABLE,
>   RES_BREAK,  RES_BREAK,
>   RES_PAGEDESC,   RES_PAGEDESC,
>   RES_LAYOUT_SPLIT,   RES_LAYOUT_SPLIT,
>   RES_ROW_SPLIT,  RES_ROW_SPLIT,
>   RES_KEEP,   RES_KEEP,
>   RES_FRAMEDIR,   RES_FRAMEDIR,
>   FN_PARAM_TABLE_HEADLINE, FN_PARAM_TABLE_HEADLINE,
>   FN_TABLE_BOX_TEXTORIENTATION, FN_TABLE_BOX_TEXTORIENTATION,
>   FN_TABLE_SET_VERT_ALIGN, FN_TABLE_SET_VERT_ALIGN,
>   0);
> 
> 
> 
> __
> 
> 
> 
> 
> was not irrelevant.
> 
> After this replacement was made there where no reasons keeping the
> "nSelectionType == nsSelectionType::SEL_TBL" block in the
> lcl_CreateEmptyItemSet function.
> 
> I hope I answered your question.
> 
> BEWARE : this patch need the first patch
> 0001-add-GetCurParAttr-an

[ANNOUNCE] libreoffice-3.5.2.2 tag created (3.5.2-rc2)

[Petr Mladek]

Hi,

there have been created the libreoffice-3.5.2.2 tag for 3.5.2-rc2
release. The corresponding official builds will be available within
next few days. It will be used as final if no blocker is found.

See the attached list of changes against 3.5.2-rc1.


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

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

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
+ core
+ compatibility option for incorrect relative moves after closePath (fdo#47406) [Fridrich Štrba]
+ fix Java script examples after gbuild'ification (fdo#46102) [Stephan Bergmann]
+ fix a regression caused by List removal. (fdo#46942) [Kohei Yoshida]
+ fix autoformat Undo cursors: (fdo#39003) [Michael Stahl]
+ fix incorrect relative moves after closePath (fdo#47406) [Thorsten Behrens]
+ fix scripting jar manifests after gbuild'ification (fdo#46102) [Stephan Bergmann]
+ load Java scripts with class loaders that actually find them (fdo#46102) [Stephan Bergmann]
+ prevent update during init in new autofilter dlg, (fdo#45679) [Markus Mohrhard]
+ revert "delay painting borders until after subsidiary lines" (fdo#42750) [Petr Mladek]
+ wW8TableInfo::processSwTable: check that table has layout (fdo#45522) [Caolán McNamara]
+ dictionaries
+ typo (fdo#47736) [Andras Timar]
+ common
+ version 3.5.2.2, tag libreoffice-3.5.2.2 (3.5.2-rc2) [Petr Mladek]
+ core
+ adapt arrowhead pathes to corrected svg path z hangling [Regina Henschel]
+ bump product version to 3.5.2-rc1+, release number to 201 [Petr Mladek]
+ bump product version to 3.5.2-rc2, release number to 202 [Petr Mladek]
+ compatibility option for incorrect relative moves after closePath (fdo#47406) [Fridrich Štrba]
+ fix Java script examples after gbuild'ification (fdo#46102) [Stephan Bergmann]
+ fix a regression caused by List removal. (fdo#46942) [Kohei Yoshida]
+ fix autoformat Undo cursors: (fdo#39003) [Michael Stahl]
+ fix incorrect relative moves after closePath (fdo#47406) [Thorsten Behrens]
+ fix scripting jar manifests after gbuild'ification (fdo#46102) [Stephan Bergmann]
+ in the current glib version only the main glib.h can be included directly. [Daniel Mihalyi]
+ load Java scripts with class loaders that actually find them (fdo#46102) [Stephan Bergmann]
+ prevent update during init in new autofilter dlg, (fdo#45679) [Markus Mohrhard]
+ revert "delay painting borders until after subsidiary lines" (fdo#42750) [Petr Mladek]
+ version 3.5.2.2, tag libreoffice-3.5.2.2 (3.5.2-rc2) [Petr Mladek]
+ wW8TableInfo::processSwTable: check that table has layout (fdo#45522) [Caolán McNamara]
+ dictionaries
+ typo (fdo#47736) [Andras Timar]
+ translations
+ update translations for LibreOffice 3.5.2 rc2 [Andras Timar]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ancient openssl bundled

[Michael Meeks]

Hi Enrico,

On Tue, 2012-03-27 at 18:28 +0200, Enrico Weigelt wrote:
> Instead of everyone bundling hundreds of (often outdated) libraries,
> the generic solution is quite simple: create a generic package
> management system for that platform and then let it handle all.

Sounds good to me; as/when you have a nice, working package management
system for Windows & Mac, that is invisible to the user, and handles
one-click application downloads, creates no extra unwanted UI
interfaces, and deals with version requirement skew across unrelated
applications [ unwinding the Windows DLL hell ], then we'll want to use
it I'm sure. You could try poking at what the CoApp guys do, they have
some similar ideas, but it's not such an easy problem to solve I think.

> > If your intention is to update the internal opensssl, then the best
> > is to do that in a bug in our bugzilla
> 
> No, I absolutely don't intend that.

Shame :-) someone needs to update that thing and re-validate it.

> I've already seen that reaction coming. Seen the same in dozens over
> dozens of other projects in the last 15 years. None of these projects
> ever agreed do solve that problem once and for all by a generic solution

So - perhaps sitting down and understanding why developers don't go
routinely updating their external libraries and solving the problems
they see there might work - why do we have an ancient openssl
internally ? is it the pain of re-basing our patches ? is it that we are
conservative & scared of touching things that appear to work ? :-) is it
that it is hard to test changes on mutiple platforms, and external deps
tend to be the most fragile pieces ? would a gerrit flow help that ?
etc.

Ultimately, the overhead of shipping duplicates seems somewhat small
size-wise in a world where people virtualise & duplicate whole operating
systems on their devices in virtual machines, at least compared to the
convenience of pseudo-application-virtualisation ;-)

> If you choose option b, I won't take part in it, but do my own fork.

Free Software advances by forking and merging back improvements, so I'd
call it make a branch - if you create something cool - we'll use it of
course (when it's ready), if it meets our requirements.

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: Excessive exception size cost ...

[Stephan Bergmann]

On 03/27/2012 04:21 PM, Michael Meeks wrote:

Well, we force page them in as we launch LibreOffice, and then we go


Yeah, the pagein hack.  More a testimony that we are doing something 
wrong here -- trying to outsmart the OS instead of fixing it --, than a 
legitimate critique on the exception handling implementation, IMO.



throwing a handful of random non-exceptional UNO exceptions as we start
up, so ... not sure :-)


Routinely thrown exceptions indicate design bugs; addressable latest 
with an incompatible LO 4.



Presumably exceptions are fair enough in the UNO-world where exception
throwing is done mostly for fun - before sfx2 throws all the results
away in favour of a user-reported, and translated 'General Error'
wrapper ;-)


That wrapper, more often than not, is a bug rather than a feature.  I 
often wished that exceptions indicating programming or packaging errors 
were left unhandled, leading to easy-to-diagnose unhandled exception 
termination rather than unhelpful LO error boxes.



Obviously as we use UNO less for core functionality for
which it is not suited, I suggest we try to avoid using exceptions in
new code where possible, and try to avoid these highly granular
exceptions that ripple up from every trivial object allocation / string
method.


I still do not consider the eh table sizes problematic enough to dismiss 
exceptions as a useful tool.  If you are concerned about object size, 
I'd rather look into things like -Os or generally removing cruft from 
our code base.


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

Re: ancient openssl bundled

[Enrico Weigelt]

> As soon as you get Microsoft to install system openssl library, you
> can probably do that, in the mean time

This is a general problem on such esoteric platforms which have no
package management. It's an distro issue, nothing in the scope of 
individual applications.

Instead of everyone bundling hundreds of (often outdated) libraries,
the generic solution is quite simple: create a generic package
management system for that platform and then let it handle all.
Cygwin might be a good starting point for that.

> If your intention is to update the internal opensssl, then the best
> is to do that in a bug in our bugzilla

No, I absolutely don't intend that.

I've already seen that reaction coming. Seen the same in dozens over
dozens of other projects in the last 15 years. None of these projects
ever agreed do solve that problem once and for all by a generic solution
(cant even count how many mails I've already written on that topic),
but prefer to burn resources on practically maintain their own distros
for just their application. So, I finally gave up to invest more time
and brain capacity here.


I see two practical options here:

a) we start working on an distro-based build machinery (which is not
part of the LO application, but a layer above - just like all the
GNU/Linux or *BSD distros do) and drop all the 3rdparty stuff from LO

b) continue to burn resources on maintaining the 3rdparty stuff forever,
including all the hassle of LO-specific hacks, backporting security
fixed manually, vulnerabilities due not properly maintained 3rdparty
packages (let's be realistic: we won't have the resources to be as
fast and good as the major distros here, anytime soon)

If you choose option b, I won't take part in it, but do my own fork.


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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||34093

-- 
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 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|34093   |

-- 
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][PATCH] remove unused code (oox, sc)

[Caolán McNamara]

On Tue, 2012-03-27 at 16:27 +0200, Petr Vorel wrote:
> Hi there,
> 
> another bits of unused code removed.

looks good, pushed now, thanks for these.

C.


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

Re: Excessive exception size cost ...

[Caolán McNamara]

On Tue, 2012-03-27 at 15:21 +0100, Michael Meeks wrote:
> I assume you're compiling -Os ? (if so, it's another nail in the x86_64
> story I guess).

The defaults for LibO are -Os for ia32 and -O2 for ia64 (and most other
gcc targets), IIRC we fell over and died with -Os back in the early days
of the x86_64 port so left it as -O2 since. Though likely the bug was
with us and not gcc and probably fixed along somewhere along the way
either way. Milage varies, now that I think about it I have
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
additional flags in my env over the defaults.

>   Well, we force page them in as we launch LibreOffice

Thoughts of debuginfo-style extraction of the sections to a compressed
external file and read them in on first-exception comes to mind :-)

C.

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

Re: [PUSHED][3-5-2] fdo#39003 Writer autoformat Uno cursor not restored

[Petr Mladek]

Caolán McNamara píše v Po 26. 03. 2012 v 14:55 +0100:
> On Thu, 2012-03-22 at 23:18 +0100, Michael Stahl wrote:
> > regression from OOo 3.4, CWS undoapi, please apply to libreoffice-3-5:
> > 
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=f24153cded54954da7f0d80941707715c78e4627
> 
> Pushed to 3-5

Looked fine, worked well. Also got approval from Cedric on irc => pushed
into 3-5-2.


Best Regards,
Petr

___
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, Part 1

[Noel Grandin]

Hi

Patch to update makefiles attached.

Regards, Noel Grandin

On 2012-03-27 14:58, Stephan Bergmann wrote:

then I get lost :-)

Ach, looks like we both forgot about 
 again, the 
need to move idl files from gb_UnoApiTarget_add_idlfiles_noheader to 
gb_UnoApiTarget_add_idlfiles_nohdl.  ;)


Can you produce a fix for your five parts so far (I guess one commit 
that can be applied on top the other five and addresses all the 
conversions would be just fine).


Stephan



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




0001-fdo-46808-Adapt-UNO-services-to-new-style-Part-6-upd.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Excessive exception size cost ...

[Noel Grandin]

On 2012-03-27 16:21, Michael Meeks wrote:
Well, we force page them in as we launch LibreOffice, and then we go 
throwing a handful of random non-exceptional UNO exceptions as we 
start up, so ... not sure :-) 


Perhaps we can use linker magic to move those tables to the end of the 
executable image, and then try and eliminate unnecessary exception 
throwing at startup?



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


___
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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||32181

-- 
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 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|32181   |

-- 
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: Windows SDK is not found

[Fridrich Strba]

I have recently removed from oowintool two checks that were looking for
a particular versions of SDK. The reason was that 1) if the SDK is not
registered with visual studio, our vsbuild.exe built external libraries
have problem and 2) The 6.1 that oowintool was looking for has the habit
to leave lingering registry keys even after being uninstalled, so it is
creating a mighty mess when the registry key points to something that is
actually not there.

oowintool looks now for the default SDK and if it does not find it, it
will fail. Better at the configure time then later in the build with
cryptic errors.

Cheers

Fridrich

On 26/03/12 23:52, Lubos Lunak wrote:
> On Monday 26 of March 2012, Kohei Yoshida wrote:
>> On Mon, Mar 26, 2012 at 5:14 PM, Regina Henschel
>>
>>  wrote:
> I have tried also with
> --with-windows-sdk-home="/cygdrive/c/Programme/Microsoft
> SDKs/Windows/v6.0A"

 I believe that configure option has been renamed to
 --with-dotnet-framework-home.  E.g. I have

 --with-dotnet-framework-home="/cygdrive/c/Program Files/Microsoft
 SDKs/Windows/v7.0A"

 in my configure option.
>>>
>>> No, that does not solve the problem, neither with
>>> --with-dotnet-framework-home alone nor in combination with
>>> --with-windows-sdk-home
>>
>> Hmm..  Anyone else have any ideas?
> 
>  I think one thing that has changed relatively recently is that the SDK must 
> be registered as default with Visual Studio (in the menu: Microsoft Windows 
> SDK 7.1 -> Visual Studio Registration -> Windows SDK Configuration Tool).
> 
>  You can also have a look at configure.in to see what the check actually 
> looks 
> for.
> 

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

Re: Windows SDK is not found

[Fridrich Strba]

Hello, Regina,

I would suggest as the best option is to install Windows SDK 7.1 that
installs even on Windows XP boxes and register it as a default SDK with
the Visual Studio.

This is what I use here and life is wonderful.

Cheers

Fridrich

On 27/03/12 13:24, Regina Henschel wrote:
> Hi all,
> 
> Lubos Lunak schrieb:
>> On Monday 26 of March 2012, Kohei Yoshida wrote:
>>> On Mon, Mar 26, 2012 at 5:14 PM, Regina Henschel
>>>
>>>   wrote:
>> I have tried also with
>> --with-windows-sdk-home="/cygdrive/c/Programme/Microsoft
>> SDKs/Windows/v6.0A"
>
> I believe that configure option has been renamed to
> --with-dotnet-framework-home.  E.g. I have
>
>  --with-dotnet-framework-home="/cygdrive/c/Program Files/Microsoft
> SDKs/Windows/v7.0A"
>
> in my configure option.

 No, that does not solve the problem, neither with
 --with-dotnet-framework-home alone nor in combination with
 --with-windows-sdk-home
>>>
>>> Hmm..  Anyone else have any ideas?
>>
>>   I think one thing that has changed relatively recently is that the
>> SDK must
>> be registered as default with Visual Studio (in the menu: Microsoft
>> Windows
>> SDK 7.1 ->  Visual Studio Registration ->  Windows SDK Configuration
>> Tool).
>>
>>   You can also have a look at configure.in to see what the check
>> actually looks
>> for.
>>
> 
> I have examined configure.in and found this:
> The automatic detection results in
> $WINDOWS_SDK_HOME = /cygdrive/c/Programme/Microsoft SDKs/Windows/v6.0A
> There configure is looking for the files
> $WINDOWS_SDK_HOME/bin/msiinfo.exe
> $WINDOWS_SDK_HOME/bin/msidb.exe
> $WINDOWS_SDK_HOME/bin/msitran.exe
> $WINDOWS_SDK_HOME/bin/uuidgen.exe
> 
> And indeed these files are not there. But I have found these files in
> C:\Programme\Microsoft Platform SDK for Windows Server 2003 R2\Bin
> and in
> C:\Programme\Microsoft SDKs\Windows\v6.1\Bin
> 
> So which are the correct ones to use?
> 
> Kind regards
> Regina
> 
> 
> ___
> 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] remove unused code (oox, sc)

[Petr Vorel]

Hi there,

another bits of unused code removed.

Regards,
Petr

>From e31c211d2ebb7cde8a260ec0bcef5359c0c1db8f Mon Sep 17 00:00:00 2001
From: Petr Vorel 
Date: Tue, 27 Mar 2012 11:03:09 +0200
Subject: [PATCH] remove unused code (oox, sc)

---
 oox/inc/oox/dump/dumperbase.hxx   |4 --
 oox/inc/oox/mathml/importutils.hxx|4 --
 oox/inc/oox/ppt/pptshape.hxx  |1 -
 oox/source/dump/dumperbase.cxx|5 ---
 oox/source/mathml/importutils.cxx |   10 -
 oox/source/ppt/pptshape.cxx   |7 
 sc/source/filter/inc/addressconverter.hxx |1 -
 sc/source/filter/inc/biffoutputstream.hxx |   14 
 sc/source/filter/inc/sheetdatabuffer.hxx  |   10 -
 sc/source/filter/oox/addressconverter.cxx |6 ---
 sc/source/filter/oox/biffoutputstream.cxx |   23 -
 sc/source/filter/oox/sheetdatabuffer.cxx  |   52 +
 unusedcode.easy   |   12 ---
 13 files changed, 1 insertions(+), 148 deletions(-)

diff --git a/oox/inc/oox/dump/dumperbase.hxx b/oox/inc/oox/dump/dumperbase.hxx
index 534776b..5989c1e 100644
--- a/oox/inc/oox/dump/dumperbase.hxx
+++ b/oox/inc/oox/dump/dumperbase.hxx
@@ -1860,10 +1860,6 @@ public:
 const BinaryInputStreamRef& rxStrm,
 const ::rtl::OUString& rSysFileName );
 
-explicitXmlStreamObject(
-const OutputObjectBase& rParent,
-const BinaryInputStreamRef& rxStrm );
-
 protected:
 virtual voidimplDumpText( TextInputStream& rTextStrm );
 };
diff --git a/oox/inc/oox/mathml/importutils.hxx b/oox/inc/oox/mathml/importutils.hxx
index 9b90681..fc0e276 100644
--- a/oox/inc/oox/mathml/importutils.hxx
+++ b/oox/inc/oox/mathml/importutils.hxx
@@ -213,10 +213,6 @@ public:
 */
 bool findTag( int token );
 /**
- Skips the given element (i.e. reads up to and including the matching closing tag).
-*/
-void skipElement( int token );
-/**
  Handle the current (unexpected) tag.
 */
 void handleUnexpectedTag();
diff --git a/oox/inc/oox/ppt/pptshape.hxx b/oox/inc/oox/ppt/pptshape.hxx
index e06fda6..07ab723 100644
--- a/oox/inc/oox/ppt/pptshape.hxx
+++ b/oox/inc/oox/ppt/pptshape.hxx
@@ -67,7 +67,6 @@ public:
 
 static oox::drawingml::ShapePtr findPlaceholder( const sal_Int32 nMasterPlaceholder, std::vector< oox::drawingml::ShapePtr >& rShapes );
 static oox::drawingml::ShapePtr findPlaceholderByIndex( const sal_Int32 nIdx, std::vector< oox::drawingml::ShapePtr >& rShapes );
-static oox::drawingml::ShapePtr findPlaceholder( sal_Int32 nFirstPlaceholder, sal_Int32 nSecondPlaceholder, std::vector< oox::drawingml::ShapePtr >& rShapes );
 
 static oox::drawingml::TextListStylePtr getSubTypeTextListStyle( const SlidePersist& rSlidePersist, sal_Int32 nSubType );
 
diff --git a/oox/source/dump/dumperbase.cxx b/oox/source/dump/dumperbase.cxx
index f078111..366090c 100644
--- a/oox/source/dump/dumperbase.cxx
+++ b/oox/source/dump/dumperbase.cxx
@@ -2920,11 +2920,6 @@ XmlStreamObject::XmlStreamObject( const ObjectBase& rParent,
 TextStreamObjectBase::construct( rParent, rxStrm, RTL_TEXTENCODING_UTF8, rSysFileName );
 }
 
-XmlStreamObject::XmlStreamObject( const OutputObjectBase& rParent, const BinaryInputStreamRef& rxStrm )
-{
-TextStreamObjectBase::construct( rParent, rxStrm, RTL_TEXTENCODING_UTF8 );
-}
-
 void XmlStreamObject::implDumpText( TextInputStream& rTextStrm )
 {
 /*  Buffers a start element and the following element text. Needed to dump
diff --git a/oox/source/mathml/importutils.cxx b/oox/source/mathml/importutils.cxx
index ab9d224..41a254d 100644
--- a/oox/source/mathml/importutils.cxx
+++ b/oox/source/mathml/importutils.cxx
@@ -114,11 +114,6 @@ static OUString tokenToString( int token )
 
 } // namespace
 
-bool XmlStream::AttributeList::hasAttribute( int token ) const
-{
-return attrs.find( token ) != attrs.end();
-}
-
 rtl::OUString XmlStream::AttributeList::attribute( int token, const rtl::OUString& def ) const
 {
 std::map< int, rtl::OUString >::const_iterator find = attrs.find( token );
@@ -304,11 +299,6 @@ bool XmlStream::findTagInternal( int token, bool silent )
 return false;
 }
 
-void XmlStream::skipElement( int token )
-{
-return skipElementInternal( token, true ); // no debug about skipping if called from outside
-}
-
 void XmlStream::skipElementInternal( int token, bool silent )
 {
 int closing = ( token & ~TAG_OPENING ) | TAG_CLOSING; // make it a closing tag
diff --git a/oox/source/ppt/pptshape.cxx b/oox/source/ppt/pptshape.cxx
index a72a10c..2b017f0 100644
--- a/oox/source/ppt/pptshape.cxx
+++ b/oox/source/ppt/pptshape.cxx
@@ -423,13 +423,6 @@ oox::drawingml::ShapePtr PPTShape::findPlaceholderByIndex( const sal_Int32 nIdx,
 return aShapePtr;
 }
 
-// if nFirstPlaceholder can't be found, it will be searched for nSecondPlaceholder
-oox::

Re: Excessive exception size cost ...

[Michael Meeks]

Hi there,

First - thanks for spending the time to generate some new data to look
at :-) it's really interesting:

On Tue, 2012-03-27 at 12:53 +0100, Caolán McNamara wrote:
> So, here's my numbers.
> Firstly x86_64 product-mode, no symbols, code-as-it-is-in-master
> 
> code140465kb - 40%
>  exceptions  49501kb - 14%
> Total: 358418576 bytes

Interesting. The 64-bit-ness leaves the exception unwind tables almost
the same size, while the code increases in size:

 code 74126kb# ia32
 code140465kb# ia64
Total: 170285850 bytes   # ia32
Total: 358418576 bytes   # ia64

Which is frankly staggering :-) an extra byte-prefix in front of each
64bit instruction and a few longer constants really does that ? ;-) that
the %age of the overall size ~40% doesn't increase is further testimony
to other substantial size increases; I assume you're compiling -Os ? (if
so, it's another nail in the x86_64 story I guess).

Usually, I'd assume compiler optimisation is a pointless / done task -
but this looks -really- bad :-) Quite possibly our most efficient path
wrt. shrinkage is to go and give hard stares to our respective compiler
guys.

> > Perhaps what is more frightening, is the sheer weight of the exception
> > information: we have fourty-eight (48) Mb of exception unwind
> > information vs. 75Mb of cod
> 
> They are frighteningly huge alright. On the other hand, presumably those
> sections aren't loaded unless an exception actually gets thrown (?) so
> does their presence matter performance-wise.

Well, we force page them in as we launch LibreOffice, and then we go
throwing a handful of random non-exceptional UNO exceptions as we start
up, so ... not sure :-)

> Maybe large bits of mozilla are compiled without exceptions ?,

It seems likely, certainly.

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

I guess it'd be the ripple effect of every method that throws something
no matter how small polluting it's callers. Of course, annotating all
methods carefully with the right 'nothrow' attribute is not feasible
either, but in theory LTO is able to detect and propagate that through
functions.

Presumably exceptions are fair enough in the UNO-world where exception
throwing is done mostly for fun - before sfx2 throws all the results
away in favour of a user-reported, and translated 'General Error'
wrapper ;-) Obviously as we use UNO less for core functionality for
which it is not suited, I suggest we try to avoid using exceptions in
new code where possible, and try to avoid these highly granular
exceptions that ripple up from every trivial object allocation / string
method.

But - beyond that, I'm still in shock over the 64bit doubling of the
code-size ;-)

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: Bug 43022 - FILEOPEN shows particular SVG distorted

[Caolán McNamara]

On Thu, 2012-03-22 at 11:10 +0100, Chr. Rossmanith wrote:
> Hi,
> 
> maybe the "aspect ratio"-fix fixed bug 43022 as well. I can't tell any 
> difference between the display of inkscape and LibreOffice (LibreOffice 
> 3.6.0alpha0+ Build ID: ee4bfba-8a74106-c695ec).
> 
> Next step would be to assign the bug to me and mark it as resolved?

I marked bug 43022 as a duplicate of 47451 and marked it as resolved, as
the substantial issue of 43022 was the aspect ratio

C.

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

Re: Experiemental interactive formula editing ...

[Ivan Timofeev]

On 27.03.2012 17:40, Ivan Timofeev wrote:

3. Impossible to write statements like 'cos x' without adding a space
between 'cos' and 'x'.


Sorry, I mean this statement becomes 'cos ~ x' - additional space is added.

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

Re: Experiemental interactive formula editing ...

[Ivan Timofeev]

Hi Michael,

On 27.03.2012 17:24, Michael Meeks wrote:

I wondered - are there any serious known issues in this anymore ?
and/or is there any reason why it's left as an experimental feature ?


There are some small (or not small) problems:

1. Ctrl+Z doesn't work.
2. Typed keywords aren't recognized as such (try to input 'newline' or 
'~' and then modify the starmath source).
3. Impossible to write statements like 'cos x' without adding a space 
between 'cos' and 'x'. (Or I just don't know how to do it?)
4. Cursor position is wrong sometimes (try to input ~50 letters 'f' in 
succession)

And maybe something more generic...

But all these seem fixable though.

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

Experiemental interactive formula editing ...

[Michael Meeks]

Hi guys,

I wondered - are there any serious known issues in this anymore ?
and/or is there any reason why it's left as an experimental feature ?

--- a/starmath/source/view.cxx
+++ b/starmath/source/view.cxx
@@ -2134,7 +2134,7 @@ void SmViewShell::Notify( SfxBroadcaster& , const 
SfxHint& rHint )
 
 bool SmViewShell::IsInlineEditEnabled() const
 {
-return pImpl->aOpts.IsExperimentalMode();
+return true;
 }
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */


Having had Jonas do all the work, it seems a shame not to ship it -
right ? :-) Olivier - do you have a view ?

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] EasyHack, fdo#46808, Adapt UNO services to new style, Part 1

[Stephan Bergmann]

On 03/27/2012 02:48 PM, Noel Grandin wrote:

I'm starting work on converting some of the call-sites, and I seem to be
running into an include path problem that my makefile skills are a
little inadequate to debug.

Specifically, I'm adding the include
#include 
to
svx/source/form/fmshimp.cpp
so I can call
Introspection::create
and gcc complains about "no such file or directory"

I've traced the compiler-include-infrastructure back to
gb_UnoApiTarget_get_header_target in solenv/gbuild/UnoApiTarget.mk and
then I get lost :-)


Ach, looks like we both forgot about 
 again, the need 
to move idl files from gb_UnoApiTarget_add_idlfiles_noheader to 
gb_UnoApiTarget_add_idlfiles_nohdl.  ;)


Can you produce a fix for your five parts so far (I guess one commit 
that can be applied on top the other five and addresses all the 
conversions would be just fine).


Stephan
___
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, Part 1

[Noel Grandin]

I'm starting work on converting some of the call-sites, and I seem to be 
running into an include path problem that my makefile skills are a 
little inadequate to debug.


Specifically, I'm adding the include
#include 
to
   svx/source/form/fmshimp.cpp
so I can call
   Introspection::create
and gcc complains about "no such file or directory"

I've traced the compiler-include-infrastructure back to 
gb_UnoApiTarget_get_header_target in solenv/gbuild/UnoApiTarget.mk and 
then I get lost :-)


-- Noel Grandin

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


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

Re: operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules

[Stephan Bergmann]

On 03/27/2012 12:58 PM, Caolán McNamara wrote:

On Thu, 2012-03-22 at 14:24 +0100, Stephan Bergmann wrote:

I unfortunately lost track long ago which platforms we use our own
memory allocator on, which platforms we additionally use libsalcpprt on,
and what the rationale was for the exceptions.


I'm now inclined to leave things as they are. Given that MacOSX and
Windows didn't route operator new through the rtl_Alloc family it
doesn't seem to make a massive pile of sense to me to have the Linux one
do so on its own without an evidence-based reason to do so again.


As discussed offline, and for the record:  The original raison d'être 
for our home-grown memory allocation machinery, IIRC, was loading 
certain Calc documents, which temporarily required large amounts of heap 
memory that could be released again later on (either after loading was 
complete or when closing the specific document; I do not remember).  As 
traditional malloc implementations only ever grow a process's heap and 
never shrink it again, this meant that an soffice process's memory 
requirements as seen by the OS could be excessively large, needlessly 
degrading overall system behaviour.


At least to me, it always felt kind of wrong to include memory 
management facilities in our code base. -- It increases maintenance cost 
and cuts us off advancements in the OSs' stock memory management facilities.


I have no idea if there are still any scenarios where our home-grown 
memory management is beneficial, let alone if such scenarios would 
depend on our global new/delete handlers (i.e., if such scenarios obtain 
the relevant memory via stock C++ new, instead of directly via 
rtl_allocateMemory or explicitly defined operator new instances that in 
turn call rtl_allocateMemory).


Stephan
___
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, Part 1

[Stephan Bergmann]

On 03/27/2012 12:57 PM, Noel Grandin wrote:

I deliberately skipped anything marked deprecated,


Great.


but I didn't conduct any searches to make sure the services were
actually being used.


I only got the idea to do so while reviewing your patch.  Back when I 
added new-style services about a decade ago, I remember going over the 
then-existing services and converting those few I identified as suitable 
for conversion.  Unfortunately, I no longer remember exactly what 
criteria I used then.  And looking at the large number of old-style 
services implementing a single interface in existence today, I have the 
bad feeling that I rejected some of them back then, for reasons lost.  I 
just can't imagine all that broken stuff got added in the meantime, by 
copying existing old-style services cargo-cult--style...


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

Re: Excessive exception size cost ...

[Caolán McNamara]

On Thu, 2012-03-08 at 17:05 +, Michael Meeks wrote:
>   So - because of the expert skepticism of my estimate of where the
> wasteage is: ie. exception unwind tables, I re-ran my relocstats.pl tool
> (which I've checked in here):

So, here's my numbers.

Firstly x86_64 product-mode, no symbols, code-as-it-is-in-master

 code140465kb - 40%
 exceptions  49501kb - 14%
 Total: 358418576 bytes

Then with relocstat-no-inline.patch applied to add additional
rtl_string2UString_throw vs rtl_string2UString etc entry points in order
to extract the "if (pData == 0) throw bad_alloc;" out from the inline
OUString constructors and into standalone functions which are allowed to
throw.

 code140273kb - 40%
 exceptions  49485kb - 14%
 Total: 358116559 bytes

So, a total reduction in size of 294k bytes with that patch applied.
a 192k reduction in code-section-size

Then with relocstat.no-throws.patch applied instead to simply delete the
std::bad_alloc throws

 code139542kb - 40%
 exceptions  48011kb - 14%
 Total: 356163070 bytes

which makes a far more hefty 2000k over-all reduction with that patch
applied instead. A 923k reduction in code-section-size.

>   Perhaps what is more frightening, is the sheer weight of the exception
> information: we have fourty-eight (48) Mb of exception unwind
> information vs. 75Mb of cod

They are frighteningly huge alright. On the other hand, presumably those
sections aren't loaded unless an exception actually gets thrown (?) so
does their presence matter performance-wise.

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

>   We can also see that of the two potential causes of bloat removal of
> not doing this:
> 
>   a) not in-lining:
> 
>   if (error_return) throw ::std::bad_alloc();

>From the no-inlines experiment the effect of removing the throw here is
presumably two-fold, removing the obvious code, but also letting the
compiler additionally know that the constructors now only call
non-throwing methods (e.g. rtl_string2UString is marked as throw()),
making them effectively nothrow as well which is the bigger button.

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

C.
diff --git a/sal/inc/rtl/ustring.h b/sal/inc/rtl/ustring.h
index b9184e0..cfa191b 100644
--- a/sal/inc/rtl/ustring.h
+++ b/sal/inc/rtl/ustring.h
@@ -1253,6 +1253,8 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromAscii(
  */
 SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromLiteral(
 rtl_uString ** newStr, const sal_Char * value, sal_Int32 len ) SAL_THROW_EXTERN_C();
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromLiteral_throw(
+rtl_uString ** newStr, const sal_Char * value, sal_Int32 len );
 
 /** Allocate a new string from an array of Unicode code points.
 
@@ -1276,6 +1278,10 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromLiteral(
 SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromCodePoints(
 rtl_uString ** newString, sal_uInt32 const * codePoints,
 sal_Int32 codePointCount) SAL_THROW_EXTERN_C();
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_newFromCodePoints_throw(
+rtl_uString ** newString, sal_uInt32 const * codePoints,
+sal_Int32 codePointCount);
+
 
 /** Assign a new value to a string.
 
@@ -1733,6 +1739,9 @@ SAL_DLLPUBLIC sal_Int32 SAL_CALL rtl_uString_getToken(
  */
 SAL_DLLPUBLIC void SAL_CALL rtl_string2UString(
 rtl_uString ** newStr, const sal_Char * str, sal_Int32 len, rtl_TextEncoding encoding, sal_uInt32 convertFlags ) SAL_THROW_EXTERN_C();
+SAL_DLLPUBLIC void SAL_CALL rtl_string2UString_throw(
+rtl_uString ** newStr, const sal_Char * str, sal_Int32 len, rtl_TextEncoding encoding, sal_uInt32 convertFlags );
+
 
 /* === */
 /* Interning methods */
@@ -1758,6 +1767,9 @@ SAL_DLLPUBLIC void SAL_CALL rtl_string2UString(
  */
 SAL_DLLPUBLIC void SAL_CALL rtl_uString_intern(
 rtl_uString ** newStr, rtl_uString * str) SAL_THROW_EXTERN_C();
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_intern_throw(
+rtl_uString ** newStr, rtl_uString * str);
+
 
 /** Return a canonical representation for a string.
 
@@ -1801,6 +1813,14 @@ SAL_DLLPUBLIC void SAL_CALL rtl_uString_internConvert(
  rtl_TextEncoding encoding,
  sal_uInt32   convertFlags,
  sal_uInt32  *pInfo) SAL_THROW_EXTERN_C();
+SAL_DLLPUBLIC void SAL_CALL rtl_uString_internConvert_throw(
+   

[REVIEW-3.5][REVIEW-3-5-2] fdo#46728

[Noel Power]

another very ugly glitch with the multibar feature, see fdo#46728 and fix
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5ae64e4b0c23f209410fe84df041c9445234df74

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

Re: Build failure in helpcontent2

[Michael Meeks]

On Tue, 2012-03-27 at 09:00 +0100, Mark Stanton wrote:
> Thanks for your help.  Looks like you're right.  The branch output is 

This happens quite a lot, even to me ;-)

I wonder - how hard would it be to add a feature to core/g to check
that the checkout is consistent, and add that to configure.in :-)

Perhaps I'll add an easy-hack for that,

ATB,

Michael.

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

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

[PUSHED] Fix for Bug 43895: Never let users save in /tmp by default

[Bjoern Michaelsen]

On Tue, Mar 27, 2012 at 01:20:27AM +0200, Bjoern Michaelsen wrote:
> Patch looking good -- I will apply, test and push tomorrow(*).

Pushed as:

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

Twaeking according to Stephans comments.

Best,

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

Re: [PUSHED] fix for fdo#46738, formatting lost when more than 84 formatted rows after last data row

[Noel Power]

On 27/03/12 11:55, Noel Power wrote:

On 27/03/12 04:26, Markus Mohrhard wrote:

Hey,

[1] fixes the export bug that more if more than 84 empty but formatted
rows were after the last row containing data, the exporter skipped
those rows.

The patch is safe and should not change the behavior in any other case
but will allow to switch other methods too that might have been
accidentally affected by the original change.

Regards,
Markus
looks good to me, if no-one objects I will push later ( currently my 
3-5 has a half complete patch still uncommitted I want to finish )


Noel

ok, pushed now

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

Re: Windows SDK is not found

[Regina Henschel]

Hi all,

Lubos Lunak schrieb:

On Monday 26 of March 2012, Kohei Yoshida wrote:

On Mon, Mar 26, 2012 at 5:14 PM, Regina Henschel

  wrote:

I have tried also with
--with-windows-sdk-home="/cygdrive/c/Programme/Microsoft
SDKs/Windows/v6.0A"


I believe that configure option has been renamed to
--with-dotnet-framework-home.  E.g. I have

 --with-dotnet-framework-home="/cygdrive/c/Program Files/Microsoft
SDKs/Windows/v7.0A"

in my configure option.


No, that does not solve the problem, neither with
--with-dotnet-framework-home alone nor in combination with
--with-windows-sdk-home


Hmm..  Anyone else have any ideas?


  I think one thing that has changed relatively recently is that the SDK must
be registered as default with Visual Studio (in the menu: Microsoft Windows
SDK 7.1 ->  Visual Studio Registration ->  Windows SDK Configuration Tool).

  You can also have a look at configure.in to see what the check actually looks
for.



I have examined configure.in and found this:
The automatic detection results in
$WINDOWS_SDK_HOME = /cygdrive/c/Programme/Microsoft SDKs/Windows/v6.0A
There configure is looking for the files
$WINDOWS_SDK_HOME/bin/msiinfo.exe
$WINDOWS_SDK_HOME/bin/msidb.exe
$WINDOWS_SDK_HOME/bin/msitran.exe
$WINDOWS_SDK_HOME/bin/uuidgen.exe

And indeed these files are not there. But I have found these files in
C:\Programme\Microsoft Platform SDK for Windows Server 2003 R2\Bin
and in
C:\Programme\Microsoft SDKs\Windows\v6.1\Bin

So which are the correct ones to use?

Kind regards
Regina


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

[PUSHED] Fix for fdo#46942.

[Michael Meeks]

On Tue, 2012-03-27 at 11:57 +0100, Noel Power wrote:
> > We need one more approval for 3-5-2.
>
> looks good to me too + 1 unfortunately at this minute I don't have a 

Looks like a no-brainer to me ! :-) thanks for that,

Pushed,

Michael.

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

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

Re: operator new no longer routes through rtl_AllocMemory in libsalcpprt under gbuild link rules

[Caolán McNamara]

On Thu, 2012-03-22 at 14:24 +0100, Stephan Bergmann wrote:
> I unfortunately lost track long ago which platforms we use our own 
> memory allocator on, which platforms we additionally use libsalcpprt on, 
> and what the rationale was for the exceptions.

I'm now inclined to leave things as they are. Given that MacOSX and
Windows didn't route operator new through the rtl_Alloc family it
doesn't seem to make a massive pile of sense to me to have the Linux one
do so on its own without an evidence-based reason to do so again.

C.

___
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, Part 1

[Noel Grandin]

Hi

I deliberately skipped anything marked deprecated, but I didn't conduct 
any searches to make sure the services were actually being used.


Regards, Noel Grandin

On 2012-03-27 12:48, Stephan Bergmann wrote:

On 03/26/2012 03:10 PM, Noel Grandin wrote:

This is the first commit in the series.
It updates the IDL files in the UDKAPI module.
I'll wait for your OK before continuing.


Looks good, pushed now.  One thing I'm looking out for is that the 
converted services are (a) not marked as deprecated and (b) actually 
implemented somewhere (by looking into an installation's 
program/services/services.rdb and ure/share/misc/services.rdb; not 
being implemented is typically a strong indicator that the service is 
de-facto deprecated).  After all, each incompatible change is a kind 
of sin, and I would like to keep this sinning as reasonably little as 
possible.  ;)  (The converted com.sun.star.script.AllListenerAdapter 
service appears to not be implemented anywhere, and is probably dead 
stuff.  I left it in the committed patch nonetheless, mainly because 
reverting the changes to offapi/type_reference/types.rdb would be 
tedious.)


I will look at your following four parts later.

Thanks again,
Stephan



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


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

Re: [REVIEW 3-5-2?] Fix for fdo#46942.

[Noel Power]

On 27/03/12 10:53, Petr Mladek wrote:

Stephan Bergmann píše v Út 27. 03. 2012 v 09:50 +0200:

On 03/26/2012 10:34 PM, Kohei Yoshida wrote:

I'd like to have the attached patch applied for the 3-5 and possibly for
the 3-5-2 branch as well.

Pushed to libreoffice-3-5 as

"fdo#46942: Fix a regression caused by List removal."

More reviews needed in case the fix shall also go into libreoffice-3-5-2.

Looks good and works perfectly.

We need one more approval for 3-5-2.

looks good to me too + 1 unfortunately at this minute I don't have a 
tree to commit to  ( I will have later this afternoon, if that's ok 
otherwise could someone else push? )


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

Re: [REVIEW-3-5] fix for fdo#46738, formatting lost when more than 84 formatted rows after last data row

[Noel Power]

On 27/03/12 04:26, Markus Mohrhard wrote:

Hey,

[1] fixes the export bug that more if more than 84 empty but formatted
rows were after the last row containing data, the exporter skipped
those rows.

The patch is safe and should not change the behavior in any other case
but will allow to switch other methods too that might have been
accidentally affected by the original change.

Regards,
Markus
looks good to me, if no-one objects I will push later ( currently my 3-5 
has a half complete patch still uncommitted I want to finish )


Noel
___
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, Part 1

[Stephan Bergmann]

On 03/26/2012 03:10 PM, Noel Grandin wrote:

This is the first commit in the series.
It updates the IDL files in the UDKAPI module.
I'll wait for your OK before continuing.


Looks good, pushed now.  One thing I'm looking out for is that the 
converted services are (a) not marked as deprecated and (b) actually 
implemented somewhere (by looking into an installation's 
program/services/services.rdb and ure/share/misc/services.rdb; not being 
implemented is typically a strong indicator that the service is de-facto 
deprecated).  After all, each incompatible change is a kind of sin, and 
I would like to keep this sinning as reasonably little as possible.  ;) 
 (The converted com.sun.star.script.AllListenerAdapter service appears 
to not be implemented anywhere, and is probably dead stuff.  I left it 
in the committed patch nonetheless, mainly because reverting the changes 
to offapi/type_reference/types.rdb would be tedious.)


I will look at your following four parts later.

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

Re: [REVIEW 3-5-2?] Fix for fdo#46942.

[Petr Mladek]

Stephan Bergmann píše v Út 27. 03. 2012 v 09:50 +0200:
> On 03/26/2012 10:34 PM, Kohei Yoshida wrote:
> > I'd like to have the attached patch applied for the 3-5 and possibly for
> > the 3-5-2 branch as well.
> 
> Pushed to libreoffice-3-5 as 
> 
>  
> "fdo#46942: Fix a regression caused by List removal."
> 
> More reviews needed in case the fix shall also go into libreoffice-3-5-2.

Looks good and works perfectly.

We need one more approval for 3-5-2.


Best Regards,
Petr

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

Re: [REVIEW-3-5] Fix wrong vcl alpha blending

[Muthu Subramanian K]

+1

[There were some duplicate code, which I attempted to remove - if there
are no mistakes there, pushing that is better? Or probably merging via
master is better?]


On 03/27/2012 06:38 AM, Thorsten Behrens wrote:
> Hi there,
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=06c16e1e26a0137a0048085cdf1c7758d3ac96cd
> fixes a somewhat nasty bug in the vcl alpha vdev blending algo, see
> attached bugdoc (and start slideshow) to see the problem.
> 
> Big kudos to Muthu for pointing my nose repeatedly at the faulty
> code, and insisting it is indeed wrong. ;)
> 
> Cheers,
> 
> -- Thorsten
> 
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice



n714787-dup.diff
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Request for information

[Muthu Subramanian K]

These links help too:
https://wiki.documentfoundation.org/Development/GSoc#How_to_apply
http://www.google-melange.com/gsoc/org/google/gsoc2012/libreoffice

On 03/26/2012 08:11 PM, Коростіль Данило wrote:
> On 03/26/2012 05:23 PM, Abhishek Jindal wrote:
>> I am highly interested in working with Libre Office this summer.
>> I have fairly good knowledge of C and C++ and also I am ready to make all
>>  possible effort required in understanding and writing code.
>> Can I make the grade?
>> Do I stand a chance?
>> I am highly enthusiastic about it and eagerly awaiting your response.
> Firstly you need to find a task you would like. You can see it here:
> http://wiki.documentfoundation.org/Development/Gsoc/Ideas
> After your choice you ought to make some Easyhack related to your task.
> 
> Good luck. ;)
> 
> P.S. I'm also student, not a developer.
> ___
> 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: [REVIEWED] fdo#46102 script dispatch java extensions are broken

[Fridrich Strba]

Rubber-stamp: booom!!!

I will cherry-pick now

Cheers

Fridrich

On 27/03/12 11:08, Petr Mladek wrote:
> Michael Stahl píše v Pá 23. 03. 2012 v 20:50 +0100:
>> On 23/03/12 16:58, Stephan Bergmann wrote:
>>> To fix  "script 
>>> dispatch java extensions are broken" requires
>>>
>>> * 
>>> 
>>> "fdo#46102: Fix scripting jar manifests after gbuild'ification"
>>>
>>> * and 
>>> 
>>>  
>>> "fdo#46102: Load Java scripts with class loaders that actually find them"
>>>
>>> * and optionally also 
>>> 
>>>  
>>> "fdo#46102: Fix Java script examples after gbuild'ification" so that the 
>>> three example Java scripts bundled with LO work again.
>>>
>>> Please consider for inclusion in libreoffice-3-5 and, at reviewer's 
>>> discretion, libreoffice-3-5-2.
>>
>> perhaps some of these java gbuild things are a bit suboptimal, i never
>> liked that package root thing, but whatever...
>>
>> pushed to libreoffice-3-5
> 
> To be honest, I do not understand everything. Though, it looks sensible.
> It fixes the problem. Java extensions, javascript, and javabeans
> examples still work. So, it looks fine to me.
> 
> We need one more approval for 3-5-2.
> 
> 
> Best Regards,
> Petr
> 
> ___
> 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: Investigation into bug 35862 - allow "increase/decrease font" for text selection with multiple font sizes

[Ahmed]

Logic in this line is executed when selecting text in different sizes in
writer, and it disables buttons.
 if( !aSetItem.GetItemOfScript( rSh.GetScriptType() )) 
rSet.DisableItem( nSlot ); 

I tried to comment the line and test without it to see if it works - now
buttons are visible but increasing or decreasing fonts in different sizes
are still  not working! 

I think that case FN_GROW_FONT_SIZE and case FN_SHRINK_FONT_SIZE in method 
"void SwTextShell::ExecCharAttrArgs(SfxRequest &rReq)" are responsible for
actual increase and decrease
and the problem may be here.


--
View this message in context: 
http://nabble.documentfoundation.org/Investigation-into-bug-35862-allow-increase-decrease-font-for-text-selection-with-multiple-font-sizes-tp3855568p3860755.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: [REVIEW-3-5][REVIEW-3-5-2?] fdo#46102 script dispatch java extensions are broken

[Petr Mladek]

Michael Stahl píše v Pá 23. 03. 2012 v 20:50 +0100:
> On 23/03/12 16:58, Stephan Bergmann wrote:
> > To fix  "script 
> > dispatch java extensions are broken" requires
> > 
> > * 
> > 
> > "fdo#46102: Fix scripting jar manifests after gbuild'ification"
> > 
> > * and 
> > 
> >  
> > "fdo#46102: Load Java scripts with class loaders that actually find them"
> > 
> > * and optionally also 
> > 
> >  
> > "fdo#46102: Fix Java script examples after gbuild'ification" so that the 
> > three example Java scripts bundled with LO work again.
> > 
> > Please consider for inclusion in libreoffice-3-5 and, at reviewer's 
> > discretion, libreoffice-3-5-2.
> 
> perhaps some of these java gbuild things are a bit suboptimal, i never
> liked that package root thing, but whatever...
> 
> pushed to libreoffice-3-5

To be honest, I do not understand everything. Though, it looks sensible.
It fixes the problem. Java extensions, javascript, and javabeans
examples still work. So, it looks fine to me.

We need one more approval for 3-5-2.


Best Regards,
Petr

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

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

[Noel Grandin]

Hi

OK, so I went ahead anyway, at the risk of having to redo stuff :-)
This is the next 4 commits.
It updates the IDL files in the OFFAPI module.

Because the patches are quite large, I hosted them on mediafire, at this 
link:


http://www.mediafire.com/?3xcdus735rst9ja,xh1ro7crx1d7vov,49u7h6gpzg7y31o,cicr1u74t886ybb

Regards, Noel Grandin


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


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

[PATCH] [REVIEW:3-5] fdo#47937 UI locks read-only when partial write privilege

[Lionel Elie Mamane]

Attached patch fixes fdo#47937, namely that if the current user has
privileges to UPDATE or INSERT only some columns of table tbl, then
the Base UI locks the whole tbl for insertion or editing, and does not
let the user add new rows, nor edit the columns (s)he *is* allowed to
insert / edit.

This patch may look like an ugly hack, but not that much:

See 
http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getTablePrivileges(java.lang.String,%20java.lang.String,%20java.lang.String)
which says:
 Note that a table privilege applies to one or more columns in the
 table. It would be wrong to assume that this privilege applies to all
 columns (this may be true for some systems but is not true for all.)

Which means that at least some JDBC drivers will return a privilege
(for the table) even when the privilege is only over one column among
several. So this patch actually unifies the situation "manually" so
that Base works well with all drivers: those that list a privilege as
soon as one column, and those that list a privilege only if all
columns (and then give the detailed privileges in
getColumnPrivileges).

Future enhancement: selectively lock columns / controls depending on
privileges on the underlying column.

Please apply to libreoffice-3-5.

-- 
Lionel
>From ff325831dd327761ba9985f5f657dc9716ff4df6 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Tue, 27 Mar 2012 10:49:49 +0200
Subject: [PATCH] fdo#47937: copy column privileges into table privileges

---
 connectivity/source/commontools/dbtools2.cxx |   73 ++
 1 files changed, 62 insertions(+), 11 deletions(-)

diff --git a/connectivity/source/commontools/dbtools2.cxx b/connectivity/source/commontools/dbtools2.cxx
index 63492b4..6d37f99 100644
--- a/connectivity/source/commontools/dbtools2.cxx
+++ b/connectivity/source/commontools/dbtools2.cxx
@@ -675,19 +675,20 @@ sal_Int32 getTablePrivileges(const Reference< XDatabaseMetaData>& _xMetaData,
 Reference< XResultSet > xPrivileges = _xMetaData->getTablePrivileges(aVal, _sSchema, _sTable);
 Reference< XRow > xCurrentRow(xPrivileges, UNO_QUERY);
 
+const ::rtl::OUString sUserWorkingFor = _xMetaData->getUserName();
+static const ::rtl::OUString sSELECT( RTL_CONSTASCII_USTRINGPARAM( "SELECT" ));
+static const ::rtl::OUString sINSERT( RTL_CONSTASCII_USTRINGPARAM( "INSERT" ));
+static const ::rtl::OUString sUPDATE( RTL_CONSTASCII_USTRINGPARAM( "UPDATE" ));
+static const ::rtl::OUString sDELETE( RTL_CONSTASCII_USTRINGPARAM( "DELETE" ));
+static const ::rtl::OUString sREAD( RTL_CONSTASCII_USTRINGPARAM( "READ" ));
+static const ::rtl::OUString sCREATE( RTL_CONSTASCII_USTRINGPARAM( "CREATE" ));
+static const ::rtl::OUString sALTER( RTL_CONSTASCII_USTRINGPARAM( "ALTER" ));
+static const ::rtl::OUString sREFERENCE( RTL_CONSTASCII_USTRINGPARAM( "REFERENCE" ));
+static const ::rtl::OUString sDROP( RTL_CONSTASCII_USTRINGPARAM( "DROP" ));
+
 if ( xCurrentRow.is() )
 {
-::rtl::OUString sUserWorkingFor = _xMetaData->getUserName();
-static const ::rtl::OUString sSELECT( RTL_CONSTASCII_USTRINGPARAM( "SELECT" ));
-static const ::rtl::OUString sINSERT( RTL_CONSTASCII_USTRINGPARAM( "INSERT" ));
-static const ::rtl::OUString sUPDATE( RTL_CONSTASCII_USTRINGPARAM( "UPDATE" ));
-static const ::rtl::OUString sDELETE( RTL_CONSTASCII_USTRINGPARAM( "DELETE" ));
-static const ::rtl::OUString sREAD( RTL_CONSTASCII_USTRINGPARAM( "READ" ));
-static const ::rtl::OUString sCREATE( RTL_CONSTASCII_USTRINGPARAM( "CREATE" ));
-static const ::rtl::OUString sALTER( RTL_CONSTASCII_USTRINGPARAM( "ALTER" ));
-static const ::rtl::OUString sREFERENCE( RTL_CONSTASCII_USTRINGPARAM( "REFERENCE" ));
-static const ::rtl::OUString sDROP( RTL_CONSTASCII_USTRINGPARAM( "DROP" ));
-// after creation the set is positioned before the first record, per definitionem
+// after creation the set is positioned before the first record, per definition
 #ifdef DBG_UTIL
 Reference< XResultSetMetaDataSupplier > xSup(xPrivileges,UNO_QUERY);
 if ( xSup.is() )
@@ -744,6 +745,56 @@ sal_Int32 getTablePrivileges(const Reference< XDatabaseMetaData>& _xMetaData,
 }
 }
 disposeComponent(xPrivileges);
+
+// Some drivers put a table privilege as soon as any column has the privilege,
+// some drivers only if all columns have the privilege.
+// To unifiy the situation, collect column privileges here, too.
+Reference< XResultSet > xColumnPrivileges = _xMetaData->getColumnPrivileges(aVal, _sSchema, _sTable, ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("%")));
+Reference< XRow > xColumnCurrentRow(xColumnPrivileges, UNO_QUERY);
+if ( xColumnCurrentRow.is() )
+{
+// after creati

Re: where can I load windows DLL file

[huqitu du]

I have finished the work, and thank you a lot.
by the way, I did it by rewrite the DLL's function to the "filter model",
and when LO open a abc.wps file will invoke my translate function.

2012/3/27 huqitu du 

> I don't need detect the file format, I only need to know the file
> extension name and if it is .wps(for example abc.wps) when open file then
> lets my DLL function( the function can translate the wps file into LO file
> format) handle it, and the function will make a new file named .odt( for
> example abc.odt) and let's LO reopen the abc.odt file, that's all.
>
> 2012/3/26 Michael Meeks 
>
>>
>> On Mon, 2012-03-26 at 13:12 +0200, khagaroth wrote:
>> > LO can open WPS (Woks) files just fine. Don't know if it handles
>> > Chines glyphs in WPS, but the English and Czech files I tried opened
>> > and displayed correctly.
>>
>>Sure - so see the 'libwps' module with the parser for that.
>>
>> > > On Mon, Mar 26, 2012 at 03:17:19PM +0800, huqitu du 
>> wrote:
>> > > The DLL function is when LO open a .wps file(this file format is very
>> > > common in china and not supported in LO yet)
>>
>> It's quite hard to build libreoffice without wps support ;-) but
>> perhaps there is something unusual about the chinese files / encodint /
>> glyphs that breaks autodetection and/or load.
>>
>>I'd play with libwps/src/conv/raw and the wps2raw or similar tool
>> to
>> see if you can work out what's happening in the underlying streams
>> there.
>>
>>HTH,
>>
>>Michael.
>>
>> --
>> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>>
>>
>
>
> --
> 内蒙古蒙科立公司
> 胡其图
> email:huq...@gmail.com
>



-- 
内蒙古蒙科立公司
胡其图
email:huq...@gmail.com
___
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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||36766

-- 
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 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|36766   |

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||37529

-- 
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 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|37529   |

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||34814

-- 
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 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|34814   |

-- 
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: [[REVIEW][3-5-2] fdo#47717, fdo#45562 sw: yet more border painting regressions (was: Re: [REVIEW][3-5][PUSHED] fdo#42750 sw: thin table borders hidden by subsidiary lines)

[Petr Mladek]

Michael Stahl píše v Pá 23. 03. 2012 v 17:44 +0100:
> On 20/03/12 12:19, Cedric Bosdonnat wrote:
> > 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.
> 
> unfortunately it turns out that the patch introduced a regression,
> fdo#47717, which is hopefully fixed with this one (as is fdo#45562,
> which is about borders vs. hellish drawing objects), so please consider
> it for libreoffice-3-5-2:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=1024c172a5bfb3d85a86fcf7a046aa2b03950edd
> 
> because up until a week ago my knowledge of Writer's drawing code was
> precisely zero, it would be a good idea to test this a bit.  in case
> something is still wrong i'd strongly consider reverting the original
> commit (0f0896c26fb260d1bbf31d7a886df3f61837f0f2).

The other commit did not fix all problems, so we should go the reverting
way for 3.5.2. Cedric is against reverting the old
0f0896c26fb260d1bbf31d7a886df3f61837f0f2 because some other things
depends on it and it could cause another regressions.

So, I reverted only the 804d0a896731629397c5328c13c04a45bc55f459 in
3-5-2, see
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5-2&id=47ef805d8ab2f2a41be058ab5f7e0fe061ffe7a0
This will bring us to the state of 3.5.1.

Best Regards,
Petr

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

Re: [PUSHED 3-5][REVIEW 3-5-2?] Fix for fdo#46942.

[Stephan Bergmann]

On 03/26/2012 10:34 PM, Kohei Yoshida wrote:

I'd like to have the attached patch applied for the 3-5 and possibly for
the 3-5-2 branch as well.


Pushed to libreoffice-3-5 as 
 
"fdo#46942: Fix a regression caused by List removal."


More reviews needed in case the fix shall also go into libreoffice-3-5-2.

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

Re: Build failure in helpcontent2

[Mark Stanton]

Hi Norbert, 

Thanks for your help.  Looks like you're right.  The branch output is 

= main repo =
* libreoffice-3-5
  master
= dictionaries =
* master
= help =
* master

Now building... And it seems to have worked.
Thank you again
Mark Stanton
One small step for mankind...


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

Re: [PUSHED 3.5] Re: [PUSHED] Re: Disabling dependency tracking (Re: [Libreoffice-commits] .: solenv/gbuild)

[Lubos Lunak]

On Tuesday 27 of March 2012, Matúš Kukan wrote:
> On 26 March 2012 17:31, Lubos Lunak  wrote:
> > [ build srs ]
> > /builds/tinderbox/libo-master/basctl/source/basicide/basicprint.src cpp:
> > line 31, Fatal error: Cannot open include file "svx/svxids.hrc" #include
> > 
> > from
> > file
> > /builds/tinderbox/libo-master/workdir/unxlngx6/SrsPartMergeTarget/basctl/
> >source/basicide/basicprint.src, line 28:
> > #include 
> > make[1]: ***
> > [/builds/tinderbox/libo-master/workdir/unxlngx6/SrsPartTarget/basctl/sour
> >ce/basicide/basicprint.src] Error 1
>
> This is fixed together with another one in
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=f64d58e3e1c65589163
>a1255b36fde4cbd84b3a0
>
> Maybe could be pushed to 3-5 branch too?
> And also
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=c59beae71273d6c8894
>f7d6eaff25131d6c124a4 ?

 I've pushed both.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
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, Part 1

[Noel Grandin]

Sorry about that, I resent it because the mailing list rejected the 
first one (attachment too big)
And the second time I zipped it, but it looks like the mailing list 
manager strips out zip attachments.

Next time I'll use a website to host the patch :-)

On 2012-03-27 08:56, Stephan Bergmann wrote:
Noel, something looks broken with the mail setup.  While I personally 
received your mail twice (yesterday and today), both times with 
attached patch, I only see it on the mailing list once (from today) -- 
and with the attachment stripped.


Anyway, I will have a look at it today.

Stephan

On 03/27/2012 08:52 AM, Noel Grandin wrote:

This is the first commit in the series.
It updates the IDL files in the UDKAPI module.
I'll wait for your OK before continuing.




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


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