Re: Migrating from OOO Calc to LO Calc | SDK, UNO, Officebean, Plugin

[libreoffice...@gmail.com]

Dear Michael,

Many thanks for quick response.
See our answers in green.

Best Regards
[Nick] & Team


On 3/6/2012 7:38 PM, Michael Meeks wrote:

Hi there,

On Tue, 2012-03-06 at 19:23 +0400, libreoffice...@gmail.com wrote:

We are working on   Open source Project   where OOO Calc  was used
for report designer.  Now we are going to migrate  from OOO calc to LO
Calc and need your help with following:

Great - where is your source code out of interest ? :-)

[Nick]
Old code hosted on Sourceforge CVS can be found here: 
http://fina.cvs.sourceforge.net/viewvc/fina
Code related with OOO addin  is here: 
http://fina.cvs.sourceforge.net/viewvc/fina/addin/

Old project is here: http://sourceforge.net/projects/fina

New code hosted on Atlasian  SVN  is here: 
https://fina2net.atlassian.net/svn/FINA/trunk ( current version is 0.2)

New Project is here: jira.fina2.net


1.   We are using OOO SDK 2.1   to register Calc Add in.
· Was new LO SDK changed significantly?

It should not have been. One thing to bear in mind is that our xcu
(configuration data) parser is a lot stricter, so you need well formed
XML that matches the schema (which was not true in older versions). But
if you get that right things should be ok I hope.

[Nick]
Do you think we need to rewrite the code? Or XML configuration / 
customization will be enough?



· Where is a docs we need to read before development?

Assume that the docs are the same as before I guess, but they are here:

http://api.libreoffice.org/

bug reports / patches to the docs much appreciated.

[Nick] Thanks.

2.   We have used OOOBean [officebean.jar]   for opening OOO Calc
in Java Environment . Are you planning to develop officebean  project?
Where can we find docs and/or wiki materials?

The bean should still exist, is still packaged, etc. There are a few
reports of problems with it, again fixes appreciated for that.

[Nick] Thanks. Can we generate HTML file without opening OOO (LO).

Right now (in old version) we are using the method  - please see here:  
https://fina2net.atlassian.net/source/browse/FINA/trunk/fina/fina-server/src/main/java/net/fina/server/ooo/OOSheet.java?hb=true 


(or see code below). Connection with OOO takes allot of time: 2-3 sec.



3.   One of the option we have is to use Libreoffice.org Calc
Plugin connected to JBoss through web services (like this project).
   Could you please give us links on similar projects or “how to” doc?

Not that clear what you want, you want mail-merge ? if so, you'd want
to provide something that looked like a database I suppose to provide
that.


[Nick]

*We would like to write an extension for LO which will exchange data 
with web services.We are planning to link it with JBoss.  Will send you 
more infomration and screenshot on what we are discussing.*




4.UNO Interface  - was it significantly changed?

In a nutshell we should be backwards compatible with OpenOffice.org -
at least, this is what we try to be. Of course, there are always bugs we
need to find out :-)

Hope that helps !

Michael.




CODE HOW TO SAVE OOO to HTML
 public byte[] exportAsHtml(byte[] tempReportContent) {
byte[] htmlContent = null;

try {
log.info("Exporting As Html");

XStorable xStorable = null;

Object desktop = null;
XComponent document = null;

xRemoteContext = getRemoteContext();

xRemoteServiceManager = 
xRemoteContext.getServiceManager();


// Get a desktop instance
desktop = 
xRemoteServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", 
xRemoteContext);


// Get a reference to the desktop interface 
that can load files
XComponentLoader loader = (XComponentLoader) 
UnoRuntime.queryInterface(XComponentLoader.class, desktop);


XInputStream xStream = new 
ByteArrayToXInputStreamAdapter(tempReportContent);


PropertyValue[] args = new PropertyValue[2];

args[0] = new PropertyValue();
args[0].Name = "InputStream";
args[0].Value = xStream;
args[0].State = PropertyState.DIRECT_VALUE;

args[1] = new PropertyValue();
args[1].Name = "Hidden";
args[1].Value = new Boolean(true);

document = 
loader.loadComponentFromURL("private:stream", "_blank", 0, args);


ByteArrayOutputStream out = new 
ByteArrayOutputStream();


XOutputStream xOut = new 
OutputStreamToXOutputStreamAdapter(out);


PropertyValue[] args1 = new PropertyValue[2];

 

Re: windows build: failure in linking: duplicate resource?

[Tor Lillqvist]

> Looks like a known issue in master on Windows as of now

Should be fixed now as of 9dacc3c6b626c4a2efd65bded0998b55f8b7aa28.
The problem was that the npsoplugin DLL was linked with two .res files
both containing a VERSION resource (for the same language). Presumably
we only want the more specific one.

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

RE: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button

[Winfried Donkers]

Astron wrote (06-03-2012 17:44)
>> That is expected behaviour to me. The startup background colur is
>> transparent (hence the gray bitmap in the button).

>To the uninitiated, this behaviour might seem very confusing (exactly
>as it did to Ivan). In Excel, the default background colour seems to
>be yellow, so let's do something similar here – I don't like yellow
>per se, but Excel users are probably used to yellow, so no need to
>break the functionality for them.
>So, I'd propose to use either "Yellow" or "Chart 3" as the default.

I simply -and without further thought- copied the initial setting of 
the old style button, which was transparent and which shows as gray
(see colour palette). I have no problem in changing the initial 
colour to yellow (as with writer highlight colour), but once you 
select transparent colour from the palette, the button shows gray 
again...

Just let me know which initial colour you prefer and I will try to
implement it :)

Another thing: After Ivan's comment on the not getting the background
transparent again, I checked the other split buttons and found that 
the problem is not isolated. I will submit a fix for this as soon as I can.

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

Re: GNU make version

[David Tardon]

On Wed, Mar 07, 2012 at 01:28:05AM +0100, Mat M wrote:
> Hello
> 
> Could someone point to archive on choosing gnumake ?
> I am surprised cmake was not elected, since the C means
> cross-platform, and that is one basic of LO.

Sigh, life would not be complete without enthusiasts telling us we
should switch to cmake (or Qt) every few months. So, please, go read
http://wiki.services.openoffice.org/wiki/Build_System_Analysis for the
basics and
http://openoffice.2283327.n4.nabble.com/New-build-system-td2928559.html
for more questions and answers.

GNU make _is_ cross-platform without having to put "c" in its name (just
like all GNU tools). And I presume it already supports more platforms
than cmake ever will.

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

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Norbert Thiebaud]

On Wed, Mar 7, 2012 at 12:18 AM, Norbert Thiebaud  wrote:
> On Tue, Mar 6, 2012 at 12:54 PM, Michael Stahl  wrote:
>>
>> the first thing i'd like to see added to make is a function to create a
>> response file that is automatically deleted (a feature that dmake has),
>> to get rid of the (necessarily) horrible Tempfile.mk.
>
> actually, fromthe gnu-make ML:
> "
> A new function $(file ...) has been implemented for the next release which
> allows writing its argument to a file, in either overwrite or append mode.
> "
>
PS: it does not remove the need to delete the file, but at least that
would simply the cut-in-piece gymanstic.

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

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Norbert Thiebaud]

On Tue, Mar 6, 2012 at 12:54 PM, Michael Stahl  wrote:
>
> the first thing i'd like to see added to make is a function to create a
> response file that is automatically deleted (a feature that dmake has),
> to get rid of the (necessarily) horrible Tempfile.mk.

actually, fromthe gnu-make ML:
"
A new function $(file ...) has been implemented for the next release which
allows writing its argument to a file, in either overwrite or append mode.
"

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

Re: GNU make version

[David Tardon]

On Tue, Mar 06, 2012 at 05:12:56PM +, Michael Meeks wrote:
> 
> On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
> > Don't see why we shouldn't maintain our own patched copy of gmake the
> > same way we maintain patched copies of other components.
> 
>   There was a long discussion about this at the ESC :-) and I disagree
> with the decision, am still suffering slower builds from it on all my
> machines, but don't much feel like re-opening it personally.
> 
>   We currently have an improved / patched version of gnumake here:
> 
>   http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/
> 
>   Which has the speedup patch, and Norbert's nice debugging code etc.
> unfortunately it is extremely non-trivial to get that to automatically
> work as part of the build.
> 
>   Personally, I'd be thrilled to have a '--with-internal-gmake' configure
> option that would download, build, locally install and setup the paths
> to use an internal, faster gnumake - so I could just add it to my
> autogen.lastrun's -and- IIRC that'd be ok by what we decided last on the
> topic too.

Or you can build it once and put it into your ~/bin ;-) That is exactly
what I do (because of the additional debugging abilities, which is
someting I use _a lot_).

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

Re: [PATCH] fdo#46939: Crash after trying to rename autotext entry

[Tor Lillqvist]

Patch looks sane, but I still would like somebody else who is more
into C++ and our way of using C++ to say whether it's the Right Thing
to do or not.

(If all callers of a particular method catch the exceptions it can
throw even during fairly normal operation, and either just ignore
them, or turn them into returning some error-indicating return value
instead, what's the point in using the heavy-weight (?) and
harder-to-get-right exception mechanism in the first place? What am I
missing, except C++ evangelism?)

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

Re: Base hangs when trying to close it

[Michael Meeks]

Hi Julien,

On Tue, 2012-03-06 at 04:38 -0800, julien2412 wrote:
> "make check" failed before I git update (and so didn't retrieve yet your
> commit which includes a possible fix).

:-) so - I didn't commit the patch I sent you, I'd love some testing /
feedback though.

> Of course, it's a different thing.

Right :-) of course, did the patch fix the bug for you though ?

> - should I file a bug for initial problem (or is too late because
> you patch fixes it) ?

Until we get a patch that works, it's still there.

> - if I git update, is it useful to run make check whereas I've got
> already an error (and so i should first try to fix this error) ?

Not really, fixing 'make check' is fairly non-trivial :-)

Thanks !

Michael.

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

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

Re: GNU make version

[Michael Meeks]

On Tue, 2012-03-06 at 19:56 +0100, Michael Stahl wrote:
> personally i'd be rather more thrilled if all those nice patches found
> their way upstream and a new release were done (after we test it on all
> platforms of course).

Sure - you can hope that these guys will release :-) but ... six months
since the last release and no signs, and of course no-one has been
motivated to write these built-in functions yet :-)

> then we can consider making that release a pre-requisite for LO build...

This is the current plan, so far it doesn't seem to be going so
well ;-) also - as-of-now we don't check for gnumake >= 3.82 - though
IIRC 3.81 causes some hideous problems so ...

ATB,

Michael.

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

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

[PATCH] fdo#46939: Crash after trying to rename autotext entry

[Dézsi Szabolcs]

Hi!

So... after a long debugging session, I managed to trace the crash all the way
from glossary.cxx through
gloshdl.cxx->swblock.cxx->shellio.cxx->SwXMLTextBlocks.cxx to storage.cxx.

First of all, the crash only happens when I rename an AutoText but set the
shortcut to something already existing.

storage.cxx:3282 here's where the exception throw happens. Although don't know
why. Someone already was thinking about this very same question, hence the
question marks in the comments at the end of the line :)
This thrown exception is caught a few lines later only to create a log entry,
and to be rethrown. And this rethrown exception is not handled. -> that is our
problem.

So I added a try catch block in the nearest place (not in xstorage.cxx because
someone might want to catch that rethrown exception elsewhere).
And that nearest place is: SwXMLTextBlocks.cxx:218
xRoot->renameElement ( aOldStreamName, aNewStreamName );

It can be seen a few lines later, that xBlkRoot is handled the same way,
catching a container::ElementExistException, but doing nothing in the catch
block.

I tested it, it worked for me. At least I think it's working, if you spot any
errors, just let me know.

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

Szabolcs  From d01dbb62419fdeed2aae107512e4bcd3f6660c09 Mon Sep 17 00:00:00 2001
From: Szabolcs Dezsi 
Date: Wed, 7 Mar 2012 04:15:30 +0100
Subject: [PATCH] Fixed crash when renaming AutoText

---
 sw/source/core/swg/SwXMLTextBlocks.cxx |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/sw/source/core/swg/SwXMLTextBlocks.cxx b/sw/source/core/swg/SwXMLTextBlocks.cxx
index 5a19bc6..f51b019 100644
--- a/sw/source/core/swg/SwXMLTextBlocks.cxx
+++ b/sw/source/core/swg/SwXMLTextBlocks.cxx
@@ -215,7 +215,10 @@ sal_uLong SwXMLTextBlocks::Rename( sal_uInt16 nIdx, const String& rNewShort, con
 String aNewStreamName( aPackageName ); aNewStreamName += sExt;
 
 xRoot = xBlkRoot->openStorageElement( aOldName, embed::ElementModes::READWRITE );
-xRoot->renameElement ( aOldStreamName, aNewStreamName );
+try {
+xRoot->renameElement ( aOldStreamName, aNewStreamName );
+}
+catch( const container::ElementExistException& ){}
 uno::Reference < embed::XTransactedObject > xTrans( xRoot, uno::UNO_QUERY );
 if ( xTrans.is() )
 xTrans->commit();
-- 
1.7.7

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

Re: GNU make version

[Norbert Thiebaud]

I just ran a make no-op (a make on a fully built product, which
presumably should expose the performance of make itself more than
anything else)
on a Windows VM, using _our_ 3.82 form dev-tools and _our_ 3.81 form dev-tools
the result are
3.82:  14m19.125  4m31.200 9m15.539
3.81:  14m20.618  4m39.261 9m12.333

iow. the whole thing about 3.82 is slow is unfounded. Stock 3.82 _is_
slow because there was a bug that has been found and patched, even
up-streamed by michael IIRC... and that was almost a year ago now...

I was amongst those that resisted the notion of having our own gnu
make forcibly bootstrapped in the build process, like we have dmake
now...
I do not object to a --build-make or something like that in
configure.in to automate the building of our own gmake... at least
until the situation settle upstream
_but_ any such version we optionally build from configure _must_ be
straight-up compatible with upstream. we cannot afford to start having
Makefile that
_require_ a custom gnu-make to build.

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

Re: [PUSHED][PATCH] Add option to find-german-comments to only list filenames

[Josh Heidenreich]

> Here's a patch for find-german-comments:
> This adds the argument -f (--filenames-only), which only prints the
> filenames of files containing German comments.
> I personally scan the whole file for German strings anyway, as we do not
> find German strings with less than 4 chars. So there's not so much use in
> printing the found strings.

Thanks.
Looks good, doesn't break, pushed.

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

Sarah Edwards -

[SarahEdwards]

Greetings,
 


My name is  Sarah Edwards and I would like to forward our new Carabineer Travel Mugto the person who handles the marketing. PIease let me know what types of products have you order before with your imprint and  email your logo in PDF or EPS formatand I will email you a price quote and a virtual proof.
 
To receive a Price Quote click here 
Promotional Products Sample Request Form 
Thank you and Best Regards,Sarah Edwards(562) 888-1952sarahedwa...@gmx.us
 
 

 
Confidentiality, Privacy, and Security Notice:
The content, materials, and accompanying attachment(s) contained
within any eMail (electronic mail transmission) is intended solelyfor the individual or entity to which it is addressed [authorized
recipient(s)] which may be confidential, exempt from disclosure
under the Electronic Communications Privacy Act, and/or legallyprivileged. The message facilitates a previous agreement of the
transaction/service of a transactional relationship for which
the intended recipient explicitly has double confirmed agreementto be contacted and informed in an ongoing capacity. If you are
not the intended recipient(s), responsible for delivering partially
or in full any transmission to the intended recipient(s), and/orhave received the transmission in error, you are hereby notified
you are strictly prohibited from reading, copying, printing,
distributing and/or disclosing any of the content, materials, andaccompanying attachment(s) contained within. If you have received
any portion of the transmission in error, please notify the
original sender by forwarding all transmissions towlcpromoti...@gmx.us
    
and delete the original along with all
 

copies of the transmission to include any accompanying attachment 
(s). Any views, commentary, and/or opinions presented within are
 
solely those of the author(s) and do not necessarily represent 

those of any other company(s) or parent entity(s).At anytime you may stop further transactional communications by
 

letting us know by emailing us at 
unsubscribeyourem...@gmx.us
and you will no longer receive communications from us.This advertisement is in complete Compliance with the FEDERAL CAN
 

SPAM ACT of 2003. You may unsubscribe at anytime by simply clicking
here
   
Unsubscribe me from this list within the email. 
 
To Report SPAM ABUSE 


Please Email The Hosting Company At:abuse-uss-excali...@gmx.us 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: GNU make version

[Mat M]

Hello

Could someone point to archive on choosing gnumake ?
I am surprised cmake was not elected, since the C means cross-platform,  
and that is one basic of LO.


regards

Mat M

Le Wed, 07 Mar 2012 00:13:11 +0100, Matúš Kukan  a  
écrit:



On 6 March 2012 19:56, Michael Stahl  wrote:

On 06/03/12 18:12, Michael Meeks wrote:


On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:

Don't see why we shouldn't maintain our own patched copy of gmake the
same way we maintain patched copies of other components.


  There was a long discussion about this at the ESC :-) and I  
disagree

with the decision, am still suffering slower builds from it on all my
machines, but don't much feel like re-opening it personally.


uhm, wasn't one of the reasons for picking GNU make that "it's standard,
and available everywhere, and we won't get stuck in the situation where
we have to maintain our own build tool" ?


That could be a reason but when now turns out that also GNU make sucks,
why we couldn't change our mind ?
From what I read here on the dev ML I understood it's ~impossible to get
our patches upstream so there is no other option than build again our  
own make.

It's small and builds nicely (I think), so hopefully that's easy.
The problem with patched 3.81 being faster than 3.82 can be hopefully
also solved.

Of course there can be also real disadvantages, I just can't see them.
Anyway, don't take me too much seriously, just my 2 cents.

All the best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



--
Utilisant le logiciel de courrier révolutionnaire d'Opera :  
http://www.opera.com/mail/

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

Re: GNU make version

[Matúš Kukan]

On 6 March 2012 19:56, Michael Stahl  wrote:
> On 06/03/12 18:12, Michael Meeks wrote:
>>
>> On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
>>> Don't see why we shouldn't maintain our own patched copy of gmake the
>>> same way we maintain patched copies of other components.
>>
>>       There was a long discussion about this at the ESC :-) and I disagree
>> with the decision, am still suffering slower builds from it on all my
>> machines, but don't much feel like re-opening it personally.
>
> uhm, wasn't one of the reasons for picking GNU make that "it's standard,
> and available everywhere, and we won't get stuck in the situation where
> we have to maintain our own build tool" ?

That could be a reason but when now turns out that also GNU make sucks,
why we couldn't change our mind ?
From what I read here on the dev ML I understood it's ~impossible to get
our patches upstream so there is no other option than build again our own make.
It's small and builds nicely (I think), so hopefully that's easy.
The problem with patched 3.81 being faster than 3.82 can be hopefully
also solved.

Of course there can be also real disadvantages, I just can't see them.
Anyway, don't take me too much seriously, just my 2 cents.

All the best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: current master build on linux is borked

[Matúš Kukan]

On 6 March 2012 18:17, Takeshi Abe  wrote:
> So I doubt 90491a073c5b5faee782ad5eab63276fda2342e6.
> In my case (gmake 3.81 on Debian wheezy) reverting it makes `make sal`
> work again.

Oh no, I guess I should start to use make 3.81 when doing such changes.

Unfortunately I don't know how to fix that.
make 3.81 just can't behave. It ignores the trailing '/' in $(OUTDIR)/%/ :
and I think it ignores even more (everything after % ?).

I created attached patch where
+$(OUTDIR)/% :
+   $(if $<,$(call gb_Deliver_deliver,$<,$@),mkdir -p $@)
was supposed to solve problems (and maybe bring others).

Then there was problem with cppunittester because it's in special
directory, but well, I can skip mentioning that. Can be solved.

The next problem is again with picking wrong rules:
$(gb_Library_OUTDIRLOCATION)/%$(gb_Library_PLAINEXT) :
$(call gb_Helper_abbreviate_dirs,\
$(call gb_Deliver_deliver,$<,$@) \
$(foreach target,$(AUXTARGETS), && $(call
gb_Deliver_deliver,$(dir $<)/$(notdir $(target)),$(target

make 3.81 can't prefer this rule over the first seen $(OUTDIR)/% :
even if it is more specific (longer prefix and also there is suffix specified)

So I am giving up on hope I can hack around misbehaving of make 3.81
and we most probably want to revert nice improvement in
90491a073c5b5faee782ad5eab63276fda2342e6

Matus
From e086cf12524ff8ea325ec46002a3bd00cbfad009 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mat=C3=BA=C5=A1=20Kukan?= 
Date: Tue, 6 Mar 2012 22:08:42 +0100
Subject: [PATCH] fix for make 3.81

Make 3.81 ignores trailing '/' in target, so distinguish between
directory and regular file by checking if there is any prerequisite.

The dark side is that now test in gb_Deliver_deliver is not doing it's
job and we can't error on files with missing prerequisite.
---
 solenv/gbuild/ComponentTarget.mk |5 -
 solenv/gbuild/Configuration.mk   |   28 
 solenv/gbuild/Helper.mk  |6 ++
 solenv/gbuild/Package.mk |6 --
 solenv/gbuild/Rdb.mk |6 --
 solenv/gbuild/TargetLocations.mk |9 -
 6 files changed, 6 insertions(+), 54 deletions(-)

diff --git a/solenv/gbuild/ComponentTarget.mk b/solenv/gbuild/ComponentTarget.mk
index adec783..97ca493 100644
--- a/solenv/gbuild/ComponentTarget.mk
+++ b/solenv/gbuild/ComponentTarget.mk
@@ -52,11 +52,6 @@ $(call gb_ComponentTarget_get_target,%) : $(call gb_ComponentTarget_get_source,$
 $(call gb_ComponentTarget_get_target,%) :
 	$(eval $(call gb_Outpt_error,Unable to find component file $(call gb_ComponentTarget_get_source,,$*) in the repositories: $(gb_ComponentTarget_REPOS) or xsltproc is missing.))
 
-$(call gb_ComponentTarget_get_outdir_target,%/) :
-	mkdir -p $@
-
-$(call gb_ComponentTarget_get_outdir_target,%) :
-	$(call gb_Deliver_deliver,$<,$@)
 
 define gb_ComponentTarget_ComponentTarget
 $(call gb_ComponentTarget_get_target,$(1)) : COMPONENTPREFIX := $(2)
diff --git a/solenv/gbuild/Configuration.mk b/solenv/gbuild/Configuration.mk
index c16bc13..a63325a 100644
--- a/solenv/gbuild/Configuration.mk
+++ b/solenv/gbuild/Configuration.mk
@@ -101,13 +101,6 @@ $(call gb_XcsTarget_get_clean_target,%) :
 		rm -f $(call gb_XcsTarget_get_target,$*) \
 			  $(call gb_XcsTarget_get_outdir_target,$(XCSFILE)))
 
-$(call gb_XcsTarget_get_outdir_target,%/) :
-	mkdir -p $@
-
-$(call gb_XcsTarget_get_outdir_target,%) :
-	$(call gb_Helper_abbreviate_dirs,\
-		$(call gb_Deliver_deliver,$<,$@))
-
 
 # XcuDataTarget class
 
@@ -145,13 +138,6 @@ $(call gb_XcuDataTarget_get_clean_target,%) :
 		rm -f $(call gb_XcuDataTarget_get_target,$*) \
 			  $(call gb_XcuDataTarget_get_outdir_target,$(XCUFILE)))
 
-$(call gb_XcuDataTarget_get_outdir_target,%/) :
-	mkdir -p $@
-
-$(call gb_XcuDataTarget_get_outdir_target,%) :
-	$(call gb_Helper_abbreviate_dirs,\
-		$(call gb_Deliver_deliver,$<,$@))
-
 
 # XcuModuleTarget class
 
@@ -185,13 +171,6 @@ $(call gb_XcuModuleTarget_get_clean_target,%) :
 		rm -f $(call gb_XcuModuleTarget_get_target,$*) \
 			  $(call gb_XcuModuleTarget_get_outdir_target,$(XCUFILE)))
 
-$(call gb_XcuModuleTarget_get_outdir_target,%/) :
-	mkdir -p $@
-
-$(call gb_XcuModuleTarget_get_outdir_target,%) :
-	$(call gb_Helper_abbreviate_dirs,\
-		$(call gb_Deliver_deliver,$<,$@))
-
 
 # XcuLangpackTarget class
 
@@ -223,13 +202,6 @@ $(call gb_XcuLangpackTarget_get_clean_target,%) :
 			  $(call gb_XcuLangpackTarget__get_target_with_lang,$*,$(lang)) \
 			  $(call gb_XcuLangpackTarget__get_outdir_target_with_lang,$(XCUFILE),$(lang
 
-$(call gb_XcuLangpackTarget_get_outdir_target,%/) :
-	mkdir -p $@
-
-$(call gb_XcuLangpackTarget_get_outdir_target,%) :
-	$(call gb_Helper_abbreviate_dirs,\
-		$(call gb_Deliver_deliver,$<,$@))
-
 
 # XcuMergeTarget class
 
diff --git a/solenv/gbuild/Helper.mk b/solenv/gbuild/Helper.mk
index 10dac0b..41f597a 100644
--- a/solenv/gbuild/Helper.mk
+++ b/solenv/gbuild/Helper.mk
@@ -36,6 +36,12 @@ gb_Helper_PHONY := $(gb_Helper_MISC)/PHONY
 # general p

Re: GNU make version

[Rene Engelhard]

On Tue, Mar 06, 2012 at 07:56:20PM +0100, Michael Stahl wrote:
> then we can consider making that release a pre-requisite for LO build...

And break the build on all distros who won't have it? No.

Even make 3.82 isn't yet everywhere because of it's incompatibilities (and as
it looks, even Debian wheezy - the *next* stable - will still ship with 3.81)

$ rmadison make
 make | 3.81-5  | lenny| alpha, amd64, arm, armel, hppa, i386, 
ia64, mips, mipsel, powerpc, s390, sparc
 make | 3.81-8  | squeeze  | amd64, armel, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 make | 3.81-8.1| wheezy   | amd64, armel, i386, ia64, kfreebsd-amd64, 
kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 make | 3.81-8.1| sid  | amd64, armel, hurd-i386, i386, ia64, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 make | 3.81-8.1+b1 | wheezy   | armhf, s390x
 make | 3.81-8.1+b1 | sid  | armhf, s390x
 make | 3.82-1  | experimental | amd64, armel, armhf, hurd-i386, i386, 
ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc

Regards,

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

Re: [LibreOffice] find ctrl-g/ctrl-shift-g accelerator patch

[khagaroth]

Just don't use any Ctrl+Alt+? key combination on Windows as you have
about 90% chance it won't work. Ctrl+Alt on Windows automatically
translates to AltGr and that is used for special character input on
most locales. That's also the reason why Ctrl+Alt+F was changed to
Ctrl+H. For example on Czech keyboard Ctrl+Alt+F writes the symbol
'['.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

License statement

[Martin Kretzschmar]

Hi,

I'd like to state that

All of my contributions (as an individual) to go-oo or ooo-build
before September 2006 may be licensed under the MPL/LGPLv3+ dual
license.

Contributions made as work for hire prior to September 2006 are
covered by license statements from SUSE or Canonical.

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

[PATCH] Add option to find-german-comments to only list filenames

[Philipp Weissenbacher]

Hi all!

Here's a patch for find-german-comments:
This adds the argument -f (--filenames-only), which only prints the
filenames of files containing German comments.
I personally scan the whole file for German strings anyway, as we do not
find German strings with less than 4 chars. So there's not so much use in
printing the found strings.

Please note that my Python is noob-level at best, so I might not do things
in a very pythonic way.

Cheers,
Philipp


0001-Add-option-to-only-list-filenames.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW 3-5] fdo#46508 use ISCHECKFORPRODUCTUPDATES property for online update

[Andras Timar]

Hi,

In some scenarios it is desirable to disable Online Update feature. It
can be done interactively but I'm thinking of silent install on
Windows in a corporate environment. It can be done easily from the
command line with the REMOVE=gm_o_Onlineupdate option, however, it
would be better to use the ISCHECKFORPRODUCTUPDATES variable, because
sysadmins are more familiar with that.

I pushed the fix to master, and a similar patch for libreoffice-3-5
branch is attached.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5ce699f0c82d5bfd629c22be0747bbe3b851a9fd

Thanks,
Andras


0001-fdo-46508-use-ISCHECKFORPRODUCTUPDATES-property-for-.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [LibreOffice] find ctrl-g/ctrl-shift-g accelerator patch

[Cameron Paul]

First, I would like to apologize for spamming the mailing lists. The
mail client on my tablet decided to send a half written email when I
put it to sleep, so I still have more to say.

I plan on continuing to work on both getting .uno:UpSearch and
.unoDownSearch implemented as accelerators, as well as getting
accelerators to work when combo boxes in toolbars are selected. I
spent most of the weekend reading code and documentation so I already
have some idea how to approach both problems.

In response to Petr, the shortcut to open the find and replace dialog
was moved from ctrl-alt-f to ctrl-h. We are talking about the shortcut
to repeat a search, which is still set to ctrl-shift-f. Mentioning
this did cause me to notice another problem though. On Mac OSX, H_MOD1
becomes Command-h, which is the system shortcut to hide an
application. This means if you attempt to open this dialog with the
shortcut, you end up hiding the application instead. If that ends up
needing to be changed let me know and I can take care of it since I'm
digging around in the accelerators already.

Let me know if anything changes.

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Bug 37361 depends on bug 40320, which changed state.

Bug 40320 Summary: Pie charts colors messed up when saving opening Excel (.xls) 
documents
https://bugs.freedesktop.org/show_bug.cgi?id=40320

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

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

Re: [PUSHED 3-5] lp#527938, debian#602953, fdo#33266, i#105408: do not crash on clicking bibliography when base isnt installed

[Bjoern Michaelsen]

On Tue, Mar 06, 2012 at 06:02:04PM +, Michael Meeks wrote:
>   Not hyper-happy with the fix personally :-) it leaves other methods eg.
> loadView just below that look decidedly flaky in a similar way.

loadView is private and only called from load().

>   Couldn't we package the bibliography component into base ? ;-) or is
> that too extreme. Could we fail more cleanly in component_getFactory or
> somesuch ?

Unsure if that will work. Also, this is quite a messy bit ping-pong going on
(roughly, IIRC):
- libsw calling into libfwk
- libfwk calling async into libbiblio via the servicename from the config
- libiblio calling into libfrm
- libfrm calling into libdba
(all via UNO)

One could try to catch it even earlier, but it is buried in the abstraction
onion of framework and its config files. I would not be sure to find all
entries to the implementation there.

OTOH, let me just reply with a sentence I heard you say quite often: "Patches
welcome!" ;)

Best,

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

Re: GNU make version

[Michael Stahl]

On 06/03/12 18:12, Michael Meeks wrote:
> 
> On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
>> Don't see why we shouldn't maintain our own patched copy of gmake the
>> same way we maintain patched copies of other components.
> 
>   There was a long discussion about this at the ESC :-) and I disagree
> with the decision, am still suffering slower builds from it on all my
> machines, but don't much feel like re-opening it personally.

uhm, wasn't one of the reasons for picking GNU make that "it's standard,
and available everywhere, and we won't get stuck in the situation where
we have to maintain our own build tool" ?

>   We currently have an improved / patched version of gnumake here:
> 
>   http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/
> 
>   Which has the speedup patch, and Norbert's nice debugging code etc.
> unfortunately it is extremely non-trivial to get that to automatically
> work as part of the build.
> 
>   Personally, I'd be thrilled to have a '--with-internal-gmake' configure
> option that would download, build, locally install and setup the paths
> to use an internal, faster gnumake - so I could just add it to my
> autogen.lastrun's -and- IIRC that'd be ok by what we decided last on the
> topic too.

personally i'd be rather more thrilled if all those nice patches found
their way upstream and a new release were done (after we test it on all
platforms of course).

then we can consider making that release a pre-requisite for LO build...

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

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Michael Stahl]

On 06/03/12 16:13, Michael Meeks wrote:
> 
> On Tue, 2012-03-06 at 12:43 +0100, Matúš Kukan wrote:
>> On 6 March 2012 11:55, Michael Meeks  wrote:
>>>I guess the other big win there to get the time down to seconds would
>>> be to get idlc/'s idlcpp to compile lots of these IDL files at once.

>> On cygwin, most of the time takes 5, and touching files is also slow.
>> The real work there in 2, and 4, is +-fast and you won't save much by
>> making it faster.

forking processes and filesystem are slow on cygwin, we knew that
already, but good to have some numbers for it :)

>> This seems to be true but idlc is called less than touch and much less than 
>> cp.
>> So, maybe next improvement would be to call cp once for all files from
>> the same directory.
> 
>   Sounds sensible :-)

yes.  there is already some weird code to group files with an extra
parameter, perhaps that could be re-used, i don't know why that was
introduced (by Ause iirc), perhaps because appending to the variables
didn't scale well once the number of files got really large?

> On Tue, 2012-03-06 at 14:10 +0200, Tor Lillqvist wrote:
>>> So, maybe next improvement would be to call cp once for all files
>>> from the same directory.
>>
>> As we de facto are requiring to use our own fork of Make anyway
>> (aren't we?).
> 
>   Not really, though we have a copy of a recent cvs version around it is
> deliberately hard to build & use, the sad thing is gnumake is maintained
> in cvs & releases rather infrequently ;-(

indeed gbuild should work on 3.81 with the fix for bug 20033, or 3.82
(works but is a little slow, or extremely slow on cygwin).

>> couldn't we add "touch", "mkdir" and "cp" functions to
>> Make? Implementing those should be fairly trivial.
> 
>   Would be lovely, would be even better to get them up-stream.

the first thing i'd like to see added to make is a function to create a
response file that is automatically deleted (a feature that dmake has),
to get rid of the (necessarily) horrible Tempfile.mk.

http://lists.gnu.org/archive/html/help-make/2011-04/msg00047.html


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

[PUSHED 3-5] lp#527938, debian#602953, fdo#33266, i#105408: do not crash on clicking bibliography when base isnt installed

[Michael Meeks]

Hi Bjoern,

On Tue, 2012-03-06 at 18:23 +0100, Bjoern Michaelsen wrote:
> please review:
>  
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=1889c1af41650576a29c587a0b2cdeaf0d297587

Not hyper-happy with the fix personally :-) it leaves other methods eg.
loadView just below that look decidedly flaky in a similar way.

> which fixes the longstanding "LibreOffice crashes on clicking
> bibliography without base being installed"-issue.

Couldn't we package the bibliography component into base ? ;-) or is
that too extreme. Could we fail more cleanly in component_getFactory or
somesuch ?

Anyhow - it looks sensible and if it fixes the bug that's great, so I
cherry-picked to libreoffice-3-5 :-)

Thanks,

Michael.

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

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

Re: [Libreoffice-ux-advise] [LibreOffice] find ctrl-g/ctrl-shift-g accelerator patch

[Petr Mladek]

Jan Holesovsky píše v Út 06. 03. 2012 v 11:20 +0100:
> Hi Cameron,
> 
> This is some good research, I hope you don't mind if I CC: the devel
> mailing list, and the UX advise list too? :-)
> 
> On 2012-03-05 at 16:41 -0500, Cameron Paul wrote:
> 
> > It turns out I was mistaken. I was only able to move .uno:RepeatSearch
> > to ctrl-g. Using .uno:DownSearch or .uno:UpSearch did nothing. I
> > suspect this is because those events need some data source telling
> > them what to search for, and that data isn't present when the find bar
> > is closed. I have attached a patch that simply moves .uno:RepeatSearch
> > from F_SHIFT_MOD1 to G_MOD1. This does cause some inconsistent
> > behavior though since ctrl-g will be RepeatSearch when the document is
> > selected and DownSearch when the toolbar is selected.

I remember that it has been recently modified to Ctrl-H, see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a75cb232c41b9f895e27dd85532ff624f85181de


Best Regards,
Petr

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

Re: GSoC & error during make

[Korrawit Pruegsanusak]

Hello Mariana,

First, welcome to LibreOffice :-)

On Mon, Mar 5, 2012 at 08:08, Mariana Marasoiu
 wrote:
> I don't know what should I do next. I tried googling the error, but
> came up with nothing conclusive. I was hoping you could help me fix
> this and finish building LibreOffice so I could start hacking :D.

To get the HEAD commit in which you're working, do:
git log -1# or  git show
and compare it with http://cgit.freedesktop.org/libreoffice/core/

And as Norbert said: ./g pull -r should do the trick.

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

[REVIEW 3-5] lp#527938, debian#602953, fdo#33266, i#105408: do not crash on clicking bibliography when base isnt installed

[Bjoern Michaelsen]

Hi,

please review:

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

which fixes the longstanding "LibreOffice crashes on clicking bibliography 
without base being installed"-issue.

Thanks,

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

Re: current master build on linux is borked

[Takeshi Abe]

Hi Noel, Michael, all,

On Tue, 06 Mar 2012 15:48:58 +, Michael Meeks  
wrote:
> On Tue, 2012-03-06 at 16:04 +0200, Noel Grandin wrote:
>> Generating tons of errors in SAL module like this:
>> 
>> [ build CXX ] sal/qa/rtl/strings/test_strings_replace.cxx
>> /home/noel/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: fatal error: 
>> sal/config.h: No such file or directory
I have stumbled on the same error.
Interestingly even `make sal.clean` failed like:
> tabe@thunk:~/core$ LANG=C make sal.clean
> cd sal && make -j 1 -rs clean gb_PARTIALBUILD=T
> [ clean LNK ] Executable/osl_process_child
> [ clean LNK ] Executable/cppunit/cppunittester
> [ clean MAK ] sal/util
> [ clean PKG ] sal_generated
> rm: cannot remove `/home/tabe/core/solver/unxlngx6.pro/inc/rtlbootstrap.mk': 
> Is a directory
> rm: cannot remove `/home/tabe/core/solver/unxlngx6.pro/inc/sal/udkversion.h': 
> Is a directory
> rm: cannot remove `/home/tabe/core/solver/unxlngx6.pro/inc/sal/typesizes.h': 
> Is a directory
> make[1]: *** 
> [/home/tabe/core/workdir/unxlngx6.pro/Clean/Package/sal_generated] Error 123
> make: *** [sal.clean] Error 2
So I doubt 90491a073c5b5faee782ad5eab63276fda2342e6.
In my case (gmake 3.81 on Debian wheezy) reverting it makes `make sal`
work again.

Cheers,
-- Takeshi Abe

> 
>   Most odd; and sal/inc/sal/config.h is there ?
> 
>   I'm rather suspicious of our dependencies at the moment - am poking
> into them.
> 
>   sal/ builds from clean fine for me with:
> 
> commit 51791eaf8611287c21ad53645036a77c1dd84ddf
> 
>   HTH,
> 
>   Michael.
> 
> -- 
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
> 
> ___
> 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: GNU make version

[Michael Meeks]

On Tue, 2012-03-06 at 19:08 +0200, Noel Grandin wrote:
> Don't see why we shouldn't maintain our own patched copy of gmake the
> same way we maintain patched copies of other components.

There was a long discussion about this at the ESC :-) and I disagree
with the decision, am still suffering slower builds from it on all my
machines, but don't much feel like re-opening it personally.

We currently have an improved / patched version of gnumake here:

http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/

Which has the speedup patch, and Norbert's nice debugging code etc.
unfortunately it is extremely non-trivial to get that to automatically
work as part of the build.

Personally, I'd be thrilled to have a '--with-internal-gmake' configure
option that would download, build, locally install and setup the paths
to use an internal, faster gnumake - so I could just add it to my
autogen.lastrun's -and- IIRC that'd be ok by what we decided last on the
topic too.

Volunteers for that appreciated :-)

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: GNU make version

[Noel Grandin]

Don't see why we shouldn't maintain our own patched copy of gmake the same
way we maintain patched copies of other components.


On Tue, Mar 6, 2012 at 16:12, Michael Meeks  wrote:

>
> On Fri, 2012-02-10 at 11:34 +0100, Michael Stahl wrote:
> > that commit can't be the reason because the wildcards added there are
> > for source files and mmeeks' output shows headers which are never added
> > directly by gb_LinkTarget_add_*Object.
>
> Hah - I think I was just being a dofus (again) and assuming my fix
> is
> in gnumake 3.82 when it isn't (?) [ though to be sure a CVS [!] repo is
> hard to track anything in ].
>
>ATB,
>
>Michael.
>
> --
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button

[Stefan Knorr (Astron)]

Hi Winfried, Ivan,


>>> 1. Open a new Writer doc
>>> 2. Type smth
>>> 3. Press the "Background Color" button
>>>    ->  nothing happens (?)
>>
>> That is expected behaviour to me. The startup background colur is
>> transparent (hence the gray bitmap in the button).

To the uninitiated, this behaviour might seem very confusing (exactly
as it did to Ivan). In Excel, the default background colour seems to
be yellow, so let's do something similar here – I don't like yellow
per se, but Excel users are probably used to yellow, so no need to
break the functionality for them.
So, I'd propose to use either "Yellow" or "Chart 3" as the default.

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

Re: [PUSHED][PATCH]fdo45671 writer par. bg color simplified code for split button

[Ivan Timofeev]

Hi Winfried,

On 06.03.2012 11:50, Winfried Donkers wrote:

Ivan Timofeev wrote (5 maart 2012 18:08)

1. Open a new Writer doc
2. Type smth
3. Press the "Background Color" button
->  nothing happens (?)

That is expected behaviour to me. The startup background colur is transparent 
(hence the gray bitmap in the button).


I expected the background would be gray...


4. Select some color from the picker
->  ok, it works
5. Select "No Fill"
->  nothing happens

That is not OK.
I put back the original (pre fdo44611 patch) code and that restored the wanted 
behaviour.
Do you want me to submit a separate fix for this (easiest for me) or do you 
wanty me to resubmit the patch (which will have to wait till the end of the day 
then and will need some experimenting with git)?


No, let me do it myself. :) I simply wanted to submit that to your approval.

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

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

Re: current master build on linux is borked

[Michael Meeks]

Hi there,

On Tue, 2012-03-06 at 16:04 +0200, Noel Grandin wrote:
> Generating tons of errors in SAL module like this:
> 
> [ build CXX ] sal/qa/rtl/strings/test_strings_replace.cxx
> /home/noel/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: fatal error: 
> sal/config.h: No such file or directory

Most odd; and sal/inc/sal/config.h is there ?

I'm rather suspicious of our dependencies at the moment - am poking
into them.

sal/ builds from clean fine for me with:

commit 51791eaf8611287c21ad53645036a77c1dd84ddf

HTH,

Michael.

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

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

Re: Migrating from OOO Calc to LO Calc | SDK, UNO, Officebean, Plugin

[Michael Meeks]

Hi there,

On Tue, 2012-03-06 at 19:23 +0400, libreoffice...@gmail.com wrote:
> We are working on   Open source Project   where OOO Calc  was used
> for report designer.  Now we are going to migrate  from OOO calc to LO
> Calc and need your help with following: 

Great - where is your source code out of interest ? :-)

> 1.   We are using OOO SDK 2.1   to register Calc Add in.   
> · Was new LO SDK changed significantly?  

It should not have been. One thing to bear in mind is that our xcu
(configuration data) parser is a lot stricter, so you need well formed
XML that matches the schema (which was not true in older versions). But
if you get that right things should be ok I hope.

> · Where is a docs we need to read before development?

Assume that the docs are the same as before I guess, but they are here:

http://api.libreoffice.org/

bug reports / patches to the docs much appreciated.

> 2.   We have used OOOBean [officebean.jar]   for opening OOO Calc
> in Java Environment . Are you planning to develop officebean  project?
> Where can we find docs and/or wiki materials?   

The bean should still exist, is still packaged, etc. There are a few
reports of problems with it, again fixes appreciated for that.

> 3.   One of the option we have is to use Libreoffice.org Calc
> Plugin connected to JBoss through web services (like this project).
>   Could you please give us links on similar projects or “how to” doc? 

Not that clear what you want, you want mail-merge ? if so, you'd want
to provide something that looked like a database I suppose to provide
that.

> 4.UNO Interface  - was it significantly changed?   

In a nutshell we should be backwards compatible with OpenOffice.org -
at least, this is what we try to be. Of course, there are always bugs we
need to find out :-)

Hope that helps !

Michael.

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

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

Migrating from OOO Calc to LO Calc | SDK, UNO, Officebean, Plugin

[libreoffice...@gmail.com]

Dear LO Admins,

We are working on Open source Project where OOO 
Calc was usedfor report designer. Now we are going to migrate from OOO 
calc to LO Calc and need your help with following:


1.We are using OOO SDK 2.1 to register Calc Add in.

·Was new LO SDK changed significantly?

·Where is a docs we need to read before development?


2.We have used OOOBean [officebean.jar] for opening OOO Calc in Java 
Environment . Are you planning to develop officebean project? Where can 
we find docs and/or wiki materials?



3.One of the option we have is to use Libreoffice.org Calc Plugin 
connected to JBoss through web services (like this 
 project). Could you please 
give us links on similar projects or “how to” doc?



4.UNO Interface- was it significantly changed?

Any Help , reference or support  highly appreciated.

Thanks, George and Dev Team
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Michael Meeks]

On Tue, 2012-03-06 at 12:43 +0100, Matúš Kukan wrote:
> On 6 March 2012 11:55, Michael Meeks  wrote:
> >I guess the other big win there to get the time down to seconds would
> > be to get idlc/'s idlcpp to compile lots of these IDL files at once.
> 
> Not really. On Linux this may be true but with cygwin processing idl
> files is not the main issue.

Ah ! :-)

> On cygwin, most of the time takes 5, and touching files is also slow.
> The real work there in 2, and 4, is +-fast and you won't save much by
> making it faster.

Makes sense; great to see you've done some really detailed analysis
already that puts mine to shame :-)

> This seems to be true but idlc is called less than touch and much less than 
> cp.
> So, maybe next improvement would be to call cp once for all files from
> the same directory.

Sounds sensible :-)

> Maybe you could file an easy hack for improving gbuild's Package.mk,

Pushed to my queue of things to file, thanks :-)

On Tue, 2012-03-06 at 14:10 +0200, Tor Lillqvist wrote:
> > So, maybe next improvement would be to call cp once for all files
> > from the same directory.
> 
> As we de facto are requiring to use our own fork of Make anyway
> (aren't we?).

Not really, though we have a copy of a recent cvs version around it is
deliberately hard to build & use, the sad thing is gnumake is maintained
in cvs & releases rather infrequently ;-(

> couldn't we add "touch", "mkdir" and "cp" functions to
> Make? Implementing those should be fairly trivial.

Would be lovely, would be even better to get them up-stream.

> If we don't want to require our own Make fork, we could wrap these in
> gbuild macros that check the Make version and call external commands
> instead if needed.

:-) I guess that's actually relatively easy to do:

 make/function.c (func_shell_base) after the construct_command_argv
call looks like a sensible place to insert that lot, and there doesn't
seem to be anything there already that does this for us that we can just
enable (sadly).
 
Interesting ideas for sure, should I push that to the easy-hacks list
too ? :-)

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: [Patch] [PUSHED] Fix for fdo#38207 and another idea of mine

[Tor Lillqvist]

> Specifically my question is, does the following make sense?
>
> -    aRepeatHeaderCB.Check(aInsOpts.mnRowsToRepeat > 0);
> +    aRepeatHeaderCB.Check((!bHTMLMode) && (aInsOpts.mnRowsToRepeat > 0));

Assuming bHTMLMode means what it seems to mean, looks fine to me?

Pushed to master.

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

Re: Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)

[Jonathan Adams]

Also I had to undo a revision in the latest git to get it to compile:

  587  git diff a1410ef073d2117cb2a3c9d9a4e9ecff7d911344
90491a073c5b5faee782ad5eab63276fda2342e6 > /tmp/mkdir-p.diff
  591  patch -Rbp1 < /tmp/mkdir-p.diff

a change made in the "mkdir -p" which helps on cygwin, unfortunately
it now "mkdir"s files instead of "touch"ing them causing a very early
death to my compilation.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)

[Jonathan Adams]

I've found the files that adds maps to the compile command and added
SOLARIS as an exception so that the compile goes a lot further.

solenv/inc/_tg_shl.mk if you look for "ANDROID" before
"SHL[0-9]VERSIONMAPPARA" and add "&& "$(OS)" != "SOLARIS"" you
shouldn't have problems with maps any more.

I now just have to get past i18npool ...

Jon

On 6 March 2012 12:14, Michael Stahl  wrote:
> On 05/03/12 13:06, Jonathan Adams wrote:
>> I'm sure I'd tried that before ... ahh yes:
>>
>> Compiling: registry/tools/rdbedit.cxx
>> Making:    regmerge
>> Undefined                       first referenced
>>  symbol                             in file
>> _ZTI*                               ../unxsoli/lib/libreg.so
>> _ZTS*                               ../unxsoli/lib/libreg.so
>> _ZGVNSt7num_put*                    ../unxsoli/lib/libreg.so
>> _ZNSt7num_put*                      ../unxsoli/lib/libreg.so
>> ld: fatal: symbol referencing errors. No output written to
>> .../unxsoli/bin/regmerge
>> collect2: ld returned 1 exit status
>> dmake:  Error code 1, while making '../unxsoli/bin/regmerge'
>
> those _ZTI* and _ZTS* symbols need to be exported to make dynamic_cast
> and exception handling work across libraries.
>
> http://www.openoffice.org/udk/common/man/apicppclasses.html
>
>> some of the map files have "*"s in them, I'm assuming that SUN ld map
>> stuff doesn't like them ...
>
> unfortunately the only kind of wildcard supported by Solaris ld is
> "local: *;"
>
> http://docs.oracle.com/cd/E19253-01/817-1984/chapter5-84101/index.html
>
>> Both the version name and the symbols associated with the version
>> must remain constant. To help enforce these requirements, wildcard
>> expansion of the symbol names defined within a version definition is
>> not supported. The number of symbols that can match a wildcard might
>> differ over the course of an objects evolution. This difference can
>> lead to accidental interface instability.
>
> so it looks like there's no simple way to use the GCC map files with
> Solaris ld.
>
> AFAIR we have decided that we want to get rid of map files anyway,
> because visibility markup (SAL_DLLPUBLIC etc.) works on all supported
> platforms now and is easier to maintain; the map files are only retained
> on Linux/GCC to retain backwards compatibility of URE libraries (because
> clients such as extensions depend on the version info).
>
> because a Solaris/GCC port doesn't maintain ABI compatibility with
> anything ever shipped anyway, it would be an option to just not use map
> files on this port (but that will only work on master, where the
> relevant URE libraries have been converted to gbuild and the public
> headers been annotated with visibility markup, which is used with MSVC
> and Apple GCC).
>
> other things that you might try: it's apparently possible to get a GCC
> that is configured for Solaris ld to use GNU ld instead, using
> LD_ALTEXEC (which is even documented in the man page):
>
> http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] fdo#33043: Would be nice if the 'Start Center' had an exit button

[Michael Meeks]

On Tue, 2012-03-06 at 14:33 +0100, Stefan Knorr (Astron) wrote:
> I tend to think we don't really need this...

Fair enough - sorry Dezsi - a bad steer from me, I've closed the bug
wontfix.

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: GNU make version

[Michael Meeks]

On Fri, 2012-02-10 at 11:34 +0100, Michael Stahl wrote:
> that commit can't be the reason because the wildcards added there are
> for source files and mmeeks' output shows headers which are never added
> directly by gb_LinkTarget_add_*Object.

Hah - I think I was just being a dofus (again) and assuming my fix is
in gnumake 3.82 when it isn't (?) [ though to be sure a CVS [!] repo is
hard to track anything in ].

ATB,

Michael.

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

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

current master build on linux is borked

[Noel Grandin]

Generating tons of errors in SAL module like this:

[ build CXX ] sal/qa/rtl/strings/test_strings_replace.cxx
/home/noel/libo/sal/qa/rtl/math/test-rtl-math.cxx:29:24: fatal error: 
sal/config.h: No such file or directory

compilation terminated.
/home/noel/libo/sal/qa/osl/setthreadname/test-setthreadname.cxx:29:24: 
fatal error: sal/config.h: No such file or directory

compilation terminated.
/home/noel/libo/sal/qa/sal/test_types.cxx:29:24: fatal error: 
sal/config.h: No such file or directory

compilation terminated.
/home/noel/libo/sal/qa/osl/mutex/osl_Mutex.cxx:32:24: fatal error: 
sal/config.h: No such file or directory

compilation terminated.
/home/noel/libo/sal/qa/osl/profile/osl_old_testprofile.cxx:33:24: fatal 
error: sal/config.h: No such file or directory

compilation terminated.



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


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

Re: [PATCH] fdo#33043: Would be nice if the 'Start Center' had an exit button

[Noel Grandin]

How about just a button, positioned somewhere on the bottom right, with 
the text "Exit" on it?
That would closely mimic the existing behaviour of platform dialogs, 
which is what this most closely resembles.


If you really want an icon next to the text, use the platform's close 
icon (a small "x" on windows and ubuntu).


On 2012-03-06 15:33, Stefan Knorr (Astron) wrote:

Hi all,

I tend to think we don't really need this...
* Android/iOS/Windows Phone don't need this (as Tor explained)
* MeeGo/Mer (sadly) currently doesn't have hardware industry partners
* Tizen is apparently all about HTML 5, so I don't know if it's even
realistic to port there. Also, it's vapourware so far.
* People using alternative WMs on Linux can probably use the menu bar.
Feel free to disagree.

A screenshot of LibO with patch applied is attached. I'll also add
that positioning the icon on the bottom right sounds like a better
idea than positioning it so close to extensions/templates/info.

In any case, we already have an icon called [sl]c_quit.png in
icon-themes/(theme)/cmd/ that should fit the purpose.

Regards,
Astron.


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


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


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

Re: [Libreoffice] [PATCH] [PUSHED] Automatically select an option page if a user clicks on a category

[Stefan Knorr (Astron)]

Hi Cor,

What specifically doesn't work for you? For me it's about okay ~today.
(I remember August promised you a better solution for later, though.)

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

[Patch] Fix for fdo#38207 and another idea of mine

[Stefan Knorr (Astron)]

Hi all,

I shouldn't be let around code, but here's a patch for a trivial bug
for you to take a look at anyway.
It fixes fdo# 38207 (i.e. moves the item "Borders" up, if we are in
Writer/Web options) and also hides "Repeat [heading] on each page"
since that option doesn't seem to make sense for websites either.

Specifically my question is, does the following make sense?

-aRepeatHeaderCB.Check(aInsOpts.mnRowsToRepeat > 0);
+aRepeatHeaderCB.Check((!bHTMLMode) && (aInsOpts.mnRowsToRepeat > 0));

(That is, does it prevent setting aRepeatHeader to true when in
Writer/Web mode or is that bogus?)

Regards,
Astron.
From ef47ccad183584d0d2da4d84dfed8d5af8bcaa0e Mon Sep 17 00:00:00 2001
From: "Stefan Knorr (astron)" 
Date: Sat, 3 Mar 2012 22:02:23 +0100
Subject: [PATCH] Fix fdo#38207 and also hide another option in Writer/Web

---
 sw/source/ui/config/optpage.cxx |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/sw/source/ui/config/optpage.cxx b/sw/source/ui/config/optpage.cxx
index 014f04d..89cb4eb 100644
--- a/sw/source/ui/config/optpage.cxx
+++ b/sw/source/ui/config/optpage.cxx
@@ -1287,15 +1287,27 @@ void SwTableOptionsTabPage::Reset( const SfxItemSet& rSet)
 // hide certain controls for html
 if(bHTMLMode)
 {
-
+aRepeatHeaderCB.Hide();
 aDontSplitCB.Hide();
+
+long nMoveUpBy =
+aRepeatHeaderCB.LogicToPixel( Size( 13, 13 ), MAP_APPFONT ).Height();
+
+Point aPos = aRepeatHeaderCB.GetPosPixel();
+aRepeatHeaderCB.SetPosPixel( Point( aPos.X(), aPos.Y() - nMoveUpBy ) );
+
+nMoveUpBy +=
+aDontSplitCB.LogicToPixel( Size( 13, 13 ), MAP_APPFONT ).Height();
+
+aPos = aBorderCB.GetPosPixel();
+aBorderCB.SetPosPixel( Point( aPos.X(), aPos.Y() - nMoveUpBy ) );
 }
 
 SwInsertTableOptions aInsOpts = pModOpt->GetInsTblFlags(bHTMLMode);
 sal_uInt16 nInsTblFlags = aInsOpts.mnInsMode;
 
 aHeaderCB.Check(0 != (nInsTblFlags & tabopts::HEADLINE));
-aRepeatHeaderCB.Check(aInsOpts.mnRowsToRepeat > 0);
+aRepeatHeaderCB.Check((!bHTMLMode) && (aInsOpts.mnRowsToRepeat > 0));
 aDontSplitCB.Check(!(nInsTblFlags & tabopts::SPLIT_LAYOUT));
 aBorderCB.Check(0 != (nInsTblFlags & tabopts::DEFAULT_BORDER));
 
-- 
1.7.5.4

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

Re: Base hangs when trying to close it

[julien2412]

Michael Meeks-2 wrote
> 
> On Mon, 2012-03-05 at 12:56 -0800, julien2412 wrote:
>   The attached might work, input / testing appreciated :-) particularly
> of the other component's exit, and the results of 'make check' before
> and after.
> 
"make check" failed before I git update (and so didn't retrieve yet your
commit which includes a possible fix).
I had this :
No core dump at 
/home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/user,
 
to create core dumps (and stack traces)
for crashed soffice instances, enable core dumps with:

ulimit -c unlimited

E
Time: 341,824
There was 1 failure:
1) test(org.openoffice.test.UnoApiTest)
java.lang.AssertionError:
 at org.openoffice.test.UnoApiTest.test(UnoApiTest.java:45)

FAILURES!!!
Tests run: 1,  Failures: 1

see full error log at 
/home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/done.log
to rerun just this failed test without all others, run:

 make 
/home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/done

cd into the module dir to run the tests faster
Or to do interactive debugging, run two shells with (Linux only):

 make debugrun
 make gb_JunitTest_DEBUGRUN=T 
/home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/done

make[1]: *** 
[/home/julien/compile-libreoffice/libo/workdir/unxlngx6/JunitTest/sw_unoapi/done]
 
Erreur 1
make: *** [subsequentcheck] Erreur 2

http://nabble.documentfoundation.org/file/n3803458/done.log.zip done.log.zip 

Of course, it's a different thing.

Now :
- should I file a bug for initial problem (or is too late because you patch
fixes it) ?
- if i git update, is it useful to run make check whereas I've got already
an error (and so i should first try to fix this error) ?

Julien.


--
View this message in context: 
http://nabble.documentfoundation.org/Base-hangs-when-trying-to-close-it-tp3798832p3803458.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

Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)

[Michael Stahl]

On 05/03/12 13:06, Jonathan Adams wrote:
> I'm sure I'd tried that before ... ahh yes:
> 
> Compiling: registry/tools/rdbedit.cxx
> Making:regmerge
> Undefined   first referenced
>  symbol in file
> _ZTI*   ../unxsoli/lib/libreg.so
> _ZTS*   ../unxsoli/lib/libreg.so
> _ZGVNSt7num_put*../unxsoli/lib/libreg.so
> _ZNSt7num_put*  ../unxsoli/lib/libreg.so
> ld: fatal: symbol referencing errors. No output written to
> .../unxsoli/bin/regmerge
> collect2: ld returned 1 exit status
> dmake:  Error code 1, while making '../unxsoli/bin/regmerge'

those _ZTI* and _ZTS* symbols need to be exported to make dynamic_cast
and exception handling work across libraries.

http://www.openoffice.org/udk/common/man/apicppclasses.html

> some of the map files have "*"s in them, I'm assuming that SUN ld map
> stuff doesn't like them ...

unfortunately the only kind of wildcard supported by Solaris ld is
"local: *;"

http://docs.oracle.com/cd/E19253-01/817-1984/chapter5-84101/index.html

> Both the version name and the symbols associated with the version
> must remain constant. To help enforce these requirements, wildcard
> expansion of the symbol names defined within a version definition is
> not supported. The number of symbols that can match a wildcard might
> differ over the course of an objects evolution. This difference can
> lead to accidental interface instability.

so it looks like there's no simple way to use the GCC map files with
Solaris ld.

AFAIR we have decided that we want to get rid of map files anyway,
because visibility markup (SAL_DLLPUBLIC etc.) works on all supported
platforms now and is easier to maintain; the map files are only retained
on Linux/GCC to retain backwards compatibility of URE libraries (because
clients such as extensions depend on the version info).

because a Solaris/GCC port doesn't maintain ABI compatibility with
anything ever shipped anyway, it would be an option to just not use map
files on this port (but that will only work on master, where the
relevant URE libraries have been converted to gbuild and the public
headers been annotated with visibility markup, which is used with MSVC
and Apple GCC).

other things that you might try: it's apparently possible to get a GCC
that is configured for Solaris ld to use GNU ld instead, using
LD_ALTEXEC (which is even documented in the man page):

http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Tor Lillqvist]

> So, maybe next improvement would be to call cp once for all files from
> the same directory.

As we de facto are requiring to use our own fork of Make anyway
(aren't we?), couldn't we add "touch", "mkdir" and "cp" functions to
Make? Implementing those should be fairly trivial.

If we don't want to require our own Make fork, we could wrap these in
gbuild macros that check the Make version and call external commands
instead if needed.

While at it, we could then add a"ifeq" and "ifneq" functions (don't
confuse with the line-based "ifeq" and "ifneq" directives processed
while reading in makefiles). That would enable making many of the
conditionals easier to understand, I think. Such macros would be
harder to wrap portably, though, I think.

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

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Matúš Kukan]

On 6 March 2012 11:55, Michael Meeks  wrote:
>        I guess the other big win there to get the time down to seconds would
> be to get idlc/'s idlcpp to compile lots of these IDL files at once.

Not really. On Linux this may be true but with cygwin processing idl
files is not the main issue.
If you look what is happening in *api, make is:
1, touching .d files
2, processing .idl files
3, again touching .d files
4, creating .rdb files and something else maybe
5, copying .idl .hpp .hdl files to solver

On cygwin, most of the time takes 5, and touching files is also slow.
The real work there in 2, and 4, is +-fast and you won't save much by
making it faster.

> That is assuming that some large chunk of the overhead on windows comes
> from several thousand invocations of the same small tool :-)

This seems to be true but idlc is called less than touch and much less than cp.
So, maybe next improvement would be to call cp once for all files from
the same directory.

>        Would that interest you Matus ? or should I file an easy hack ?

No. You can file an easy hack, but do not expect big difference.

Maybe you could file an easy hack for improving gbuild's Package.mk,
so that we would copy all files to the same directory at once.
It would be great, I think, to have some other person who would
understand our makefiles,
but I don't know how easy that is. It takes time first but then I
think it's easy.
Should be possible to make the directory in solver depend on files we
want to copy there and create rule for that.

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

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

[Petr Mladek]

Michael Stahl píše v St 29. 02. 2012 v 23:08 +0100:
> this patch fixes a STL assertion in GraphiteLayout::expandOrCondense;
> since i don't know how the multitude of arrays in there are supposed to
> be used, i thought it's probably a good idea to check the size of the
> array that will be indexed in the next line, as opposed to one that
> isn't mentioned in the block...
> 
> in case this is the right fix, it should be applied to libreoffice-3-5,
> and possibly libreoffice-3-4 as well (haven't checked).
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=d066f7e4afb3c9e395932ba7bf8715ad0770bcdd

I do not understand the code either. I just wonder if it would make
sense to check for:

while (++nCharIndex - mnMinCharPos <
static_cast(mvChar2BaseGlyph.size()))

As the array is accessed as mvChar2BaseGlyph[nCharIndex-mnMinCharPos].
Otherwise, the cycle might end too early. 

Another conservative solution would be to combine it with the original
check:

while (++nCharIndex < static_cast(mvGlyph2Char.size()) &&
   nCharIndex - mnMinCharPos <
static_cast(mvChar2BaseGlyph.size()))


Best Regards,
Petr

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

Re: offapi again builds faster; user of gb_Deliver_deliver responsible for the directory

[Michael Meeks]

Hi Matus,

On Mon, 2012-03-05 at 23:11 +0100, Matúš Kukan wrote:
> I was inspired by Norbert's work in d44a3e291cb8c4b3ec5ce1775edd527b475ebca4
...
> On cygwin this is really improvement:
> Building offapi is now much faster if you build with only one job: make -sr
> real27m38s  ->  12m6s

Lovely ! :-) so we halving(?) the number of processes being spawned
halves the time ?

I guess the other big win there to get the time down to seconds would
be to get idlc/'s idlcpp to compile lots of these IDL files at once.
That looks like something that idlc/source/idlcmain.cxx either already
does, or could trivially be adapted to (with a rather easy-to-verify
"did it work" mode by diffing the generated .hpp/.hdl files I guess).
That is assuming that some large chunk of the overhead on windows comes
from several thousand invocations of the same small tool :-)

Would that interest you Matus ? or should I file an easy hack ?

Anyhow - nice work, and lovely speedup :-)

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: windows build: failure in linking: duplicate resource?

[Michael Meeks]

Hi Noel,

On Tue, 2012-03-06 at 11:55 +0200, Noel Grandin wrote:
> So my windows 64-bit build machine suffered a hard-drive crash, and I'm 
> starting to resurrect it.

Sorry to hear that ...

> But I'm getting weird link errors (see below), and this is from a clean 
> build. Any ideas?

Looks like a known issue in master on Windows as of now - I've been
trying to find some time to help unwind it, Matus was struggling to get
both the cross-compiled, and native forms to work concurently IIRC :-)

Thanks !

Michael.

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

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

Re: [LibreOffice] find ctrl-g/ctrl-shift-g accelerator patch

[Jan Holesovsky]

Hi Cameron,

This is some good research, I hope you don't mind if I CC: the devel
mailing list, and the UX advise list too? :-)

On 2012-03-05 at 16:41 -0500, Cameron Paul wrote:

> It turns out I was mistaken. I was only able to move .uno:RepeatSearch
> to ctrl-g. Using .uno:DownSearch or .uno:UpSearch did nothing. I
> suspect this is because those events need some data source telling
> them what to search for, and that data isn't present when the find bar
> is closed. I have attached a patch that simply moves .uno:RepeatSearch
> from F_SHIFT_MOD1 to G_MOD1. This does cause some inconsistent
> behavior though since ctrl-g will be RepeatSearch when the document is
> selected and DownSearch when the toolbar is selected.

Yes, this is not ideal.

> I think an ideal solution would be one where RepeatSearch could remain
> at F_SHIFT_MOD1, and DownSearch/UpSearch simply be added to
> G_MOD1/G_SHIFT_MOD1. This would allow us to keep all 3 functions bound
> to shortcuts and avoid confusing anyone who already knows the
> ctrl-shift-f shortcut. Unfortunately it is not immediately obvious to
> me how to implement it like this.

I think this is actually a good question for the UX advise list :-)  My
proposal would be to get rid of the RepeatSearch functionality (and
consequently of Ctrl-Shift-f), and let only DownSearch and UpSearch -
more consistency, and more control for the user.  RepeatSearch it is not
accessible from the menu, so I'd expect that not that many people will
know that - but of course some hard data would be good here.

So - if the UX advise guys agree, I'd try to make DownSearch and
UpSearch working even without the toolbar active.  The code for
RepeatSearch is here:

sw/source/ui/uiview/viewsrch.cxx

The code for Up/DownSearch here:

svx/source/tbxctrls/tbunosearchcontrollers.cxx
[DownSearchToolboxController::execute()]

I'd try to look if the control flow gets to the ::execute() when you
bind Ctrl-g to .uno:DownSearch and use it in the document.  If yes, then
it might be only a matter of checking why exactly it does nothing.  Of
course, if the control flow does not get there at all, it is for deeper
investigation - I'd then try to spot differences between what is
happening in the .uno:RepeatSearch and .uno:DownSearch case.  If it gets
more complicated, please let me know; but hopefully it'll be OK.

> As for the accelerators not working when a text area in a menu bar is
> selected, I think that might be a bigger problem. For example, this
> also prevents things like ctrl-s saving a document, which could
> potentially lead to data loss if someone doesn't know their work is
> not being saved. I don't know what changing that would actually
> involve, but I would be happy to work on it if people want that
> modification.

Good point!  I have just checked, and it is a more general problem -
when you try that in eg. the 'Font size' combobox, you cannot do Ctrl-s
either.  Should I file an easy hack for that, or will you try to
investigate this one too? :-)

All the best,
Kendy

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

windows build: failure in linking: duplicate resource?

[Noel Grandin]

HI

So my windows 64-bit build machine suffered a hard-drive crash, and I'm 
starting to resurrect it.
But I'm getting weird link errors (see below), and this is from a clean 
build.

Any ideas?

Regards, Noel Grandin.

c:/LibreOffice/libo/workdir/wntmsci12.pro/CxxObject/extensions/source/nsplugin/source/so_env.o 
c:/LibreOffice/libo/workdir/wntmsci12.pro/CxxObject/extensions/source/nsplugin/source/npshell.o 
c:/LibreOffice/libo/workdir/wntmsci12.pro/WinResTarget/npsoplugin/default.res 
c:/LibreOffice/libo/workdir/wntmsci12.pro/WinResTarget/npsoplugin_res.res
   Creating library 
c:/LibreOffice/libo/workdir/wntmsci12.pro/LinkTarget/Library/npsoplugin.lib 
and object 
c:/LibreOffice/libo/workdir/wntmsci12.pro/LinkTarget/Library/npsoplugin.exp
CVTRES : fatal error CVT1100: duplicate resource.  type:VERSION, name:1, 
language:0x0409
LINK : fatal error LNK1123: failure during conversion to COFF: file 
invalid or corrupt
make[1]: *** 
[/cygdrive/c/LibreOffice/libo/workdir/wntmsci12.pro/LinkTarget/Library/npsoplugin.lib] 
Error 99

dmake:  Error code 2, while making 'all'


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


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

Re: [PUSHED 3.5] fix for fdo#46975 , crash when using mouse wheel in input line

[Noel Power]

Hi Markus
On 06/03/12 00:28, Markus Mohrhard wrote:

Hey,

[1] fixes a crash when you use the mouse wheel while a formula is in
the selected cell. We should not handle the mouse wheel event for the
input line.

I think this patch is safe. I did not move the handling of the event
to the parent window because this would result in scrolling through
the document even if you are over the input line.

Regards,
Markus

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

I think it looks ok, I wonder though what changed?, I suppose pEditView 
is now set where previously it wasn't ( a side effect of the multiline 
input stuff ). I worry though there might be other events that might 
cause problems and also need to be ignored :/ Anyway I cherry-picked it 
to 3.5


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