[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 35017, which changed state.

Bug 35017 Summary: Shortcuts that can not be modified permanently should be 
marked
https://bugs.freedesktop.org/show_bug.cgi?id=35017

   What|Old Value   |New Value

 Resolution||WORKSFORME
 Status|NEEDINFO|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: [Libreoffice] [Libreoffice-ux-advise] [REVIEW 3-5: Late feature] Improvements in the header / footer behavior

[Cedric Bosdonnat]

Hello everyone,

Sorry for my lack of responsiveness... but I was on holidays last week.

On Fri, 2011-12-30 at 18:18 +0100, Stefan Knorr (Astron) wrote:
> > Yeah ;-) - it is hard to make everyone happy, though I am not that
> > convinced that introducing one more option is the right solution.
> 
> Agree with that completely.

I agree with that too... though someone suggested me once that we could
have some hidden expert configuration feature a la mozilla. This kind of
configuration would be the ones that would appear only in that expert
config thing. That being said we can introduce some XCS/XCU file entry
for it without showing it an the UI ;)

> > So - what I'll try to do is that the appearing will start later (not 1
> > sec, but maybe 200 - 500 ms), but the functionality will be available
> > immediately when the mouse is there; so the impatient user who knows
> > where to click will be able to perform immediately, while the extensive
> > mouse traveller will not be annoyed.  Hopefully that will be the best
> > from the both worlds :-)
> 
> Sounds good. Almost wanted to propose that yesterday, but didn't dare
> because you had patches already.

I have no strong opinion on that.

> >> And... is it possible to show the controls only on a single page? See
> >> the attached screenshot - it's absolutely crazy! %-)
> 
> Not pretty... but a corner case nevertheless. If you have enough
> resources to fix all of these rendering bugs for 3.5 that would be
> great, but hopefully these won't hurt too much otherwise.

Indeed, not pretty :)

> So, for the future, we have the following drawing bugs present here:
> * Page breaks: When moving with the mouse cursor from one page break
> to the next very quickly, their little tabs don't disappear any more

I'll have a look at that.

> * Page breaks: The dotted lines are drawn above the little tabs

That can be fixed quickly.

> Another one that annoys me quite a bit (but can't be seen in Ivan's 
> screenshot):
> * Page breaks: the dotted line seems to move forward instead of just
> being overlaid by the tab.

Ok, I'll fix that one as it causes another bug (flickering tab when
moving the mouse over the left end of the line)

> > :-) The thing is that you are really editing all the pages at the same
> > time (header applies to all of them).  The way out of that might be
> > showing the dashed line on all the pages, but the control only on the
> > page where you have the mouse pointer.  I'll try how hard will that be.
> 
> Agree with your solution, but note: the header indicators are shown on
> _all_ pages, not just those with the same header style. If there's a
> page using another header style, no indicator should be shown at all.

What about showing only the two tabs of the currently "selected"
page(s)? It's just a wild idea without code consideration ATM ;)

--
Cedric

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

Re: [Libreoffice] [PATCH] 1/4 tools/rtti.hxx cleaning

[Stephan Bergmann]

On 12/20/2011 01:00 AM, Rafael Dominguez wrote:

Well yeah theres a penalty for using dynamic_cast but dunno how much
will affect performance since theres alot of calls, but im pretty sure
some code can be refactored to avoid casting.


Just FYI, when I redesigned configmgr, I abandoned my initial idea to 
dispatch on the various Node sub-types via dynamic_cast in favour of a 
more verbose Node::kind() and static_cast.  The former turned out to be 
just too slow (as Node instances are mass objects in configmgr).


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

Re: [Libreoffice] UPR local host problem

[Paul TOTH]

does anyone know the URP protocol ?

I've found very few information about it
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol

Regards
Paul TOTH
Le 29/12/2011 11:04, Paul TOTH a écrit :

Hi,

I've made a UPR client from scratch with Embarcadero Delphi
my purpose is to talk to a LibreOffice server without any dependency

I've made a test program available there:
www.execute-info.com/RemoteOfficeDemo.zip

this Windows application call the specified office server to open and 
convert a document to PDF


you just need to put the office IP address and port number (default 
are 127.0.0.1 and 8100) and press "Convert to PDF"

the current displayed text should be converted to RemoteOffice.PDF.

BUT, and that's why I post this mail, this program work perfectly on a 
remote office, but hang on a local host.


the very special thing is that when a first instance is hanged, a 
second one work just fine !


How is-it possible ?!

I debug mode, the socket doesn't receveive anything after the message :
 loadComponentFrom('private_stream', '_blank', ...)
and my program is still waiting a reply for ever :(

the first to tabs are using "XInitialize" to send the text, the 2 
other tabs are using XInputStream to handle large files.


Regards
Paul TOTH

___
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: [Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Stephan Bergmann]

On 12/21/2011 05:23 PM, Norbert Thiebaud wrote:

On Wed, Dec 21, 2011 at 9:58 AM, Eike Rathke  wrote:

Still, there should be a way to have non-dbgutil and dbgutil builds (or
builds with different switches, whatever) in parallel. So we'd need
_some_ mechanism to differentiate between output directories.


imo: that should eventually be separate workdir...


Probably even the semi-standard behaviour of calling configure from 
outside the (read-only) source tree and producing any output exclusively 
to the hierarchy rooted at cwd.


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

Re: [Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Stephan Bergmann]

On 12/20/2011 09:52 AM, Victor Lee wrote:

1) Statements setting $CPU="U" (looks like it should be "SPARC64")
could not be found in set_soenv.in or related files, but $(CPU)=="U"
is checked in some makefiles.  I left those lines untouched in this
patch.


Historically, there was a SPARC64 port done at Sun/Hamburg that never 
became "official" and was only available via the Hamburg-specific way to 
set up a build environment, not via set_soenv.in.


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

Re: [Libreoffice] UPR local host problem

[Stephan Bergmann]

On 01/02/2012 11:06 AM, Paul TOTH wrote:

does anyone know the URP protocol ?

I've found very few information about it
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol


But that's as detailed as you can reasonably expect it to be?  ;) 
Anyway, I assume your problem is higher up the abstraction hierarchy 
than plain URP.  If there were problems establishing localhost 
connections, you would get problems already before reaching the 
loadComponentFromURL call.



Le 29/12/2011 11:04, Paul TOTH a écrit :

I debug mode, the socket doesn't receveive anything after the message :
loadComponentFrom('private_stream', '_blank', ...)
and my program is still waiting a reply for ever :(


Does the soffice.bin process hang displaying some message box, awaiting 
user input (or rather trying to display such a box, in case of 
--headless -- but does that even work on Windows, not sure)?  You might 
need to debug soffice.bin to find out more.


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

Re: [Libreoffice] [REVIEW:3-4, 3-4-5] crash in LO 3.4.5 rc1 : fdo40253

[Petr Mladek]

Jean-Baptiste Faure píše v Po 26. 12. 2011 v 10:51 +0100:
> Hi,
> 
> Bug fdo40253 seems to be fixed in LO 3.5.0 beta2+ but still crashes LO
> 3.4.5 rc1. I don't know which commit solved this but is it possible to
> backport the fix to 3.4.5 ?

I guess that it has been fixed by
http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbaadd31d3ff53f18a7b8d2b0af947328dc81d91

It looks good and pretty safe to me. Similar thing is done also in 
SdrTableObj::setTableStyle.

Thorsten, is it ok for you to add it into 3.4.5 release?



Best Regards,
Petr

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

Re: [Libreoffice] [MacOS] Starting dev-install is hairy

[Stephan Bergmann]

On 12/22/2011 08:33 AM, James C wrote:

   - cd-ing into Contents/MacOS and running soffice, gives me
apparently the version installed in /Applications


Did you call it as plain "soffice" (instead of "./soffice") so it picked 
the one from PATH?


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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||36681

--- Comment #68 from Petr Mladek  2012-01-02 02:51:32 PST ---
(In reply to comment #67)
> hello,
> 
> I re-openend https://bugs.freedesktop.org/show_bug.cgi?id=36681.
> 
> For an average user this bug is very confusing and dissapointing. Should
> be corrected before releasing a new version. I also did see it in the
> main-build, 3.6.

I agree that it is quite annoying => adding here. Well, I am not if we will be
able to fix it. Random bugs are always hard to cope with.

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||44040

--- Comment #69 from Petr Mladek  2012-01-02 03:00:16 PST ---
(In reply to comment #66)
> I nominate the bug #44040. Crash when page preview after  (data sources).

Yup, that sounds pretty nasty.

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on|44040   |

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

[Libreoffice] [Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Petr Mladek  changed:

   What|Removed |Added

 Depends on||44040

-- 
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: [Libreoffice] UPR local host problem

[Paul TOTH]

Hi,

Le 02/01/2012 14:21, Stephan Bergmann a écrit :

On 01/02/2012 11:06 AM, Paul TOTH wrote:

does anyone know the URP protocol ?

I've found very few information about it
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol



But that's as detailed as you can reasonably expect it to be?  ;)
Anyway, I assume your problem is higher up the abstraction hierarchy
than plain URP.  If there were problems establishing localhost
connections, you would get problems already before reaching the
loadComponentFromURL call.



Well I havent' found any document on how the IDs (like 
1e3ad60;uno[0];18b8;85f8da80603b478cb08cd837553b7f6d) are defined...so 
I've used Windows GUID to identify my objects instances.



Le 29/12/2011 11:04, Paul TOTH a écrit :

I debug mode, the socket doesn't receveive anything after the message :
loadComponentFrom('private_stream', '_blank', ...)
and my program is still waiting a reply for ever :(


Does the soffice.bin process hang displaying some message box,
awaiting user input (or rather trying to display such a box, in case
of --headless -- but does that even work on Windows, not sure)?  You
might need to debug soffice.bin to find out more.

soffice is waiting also for something because the document is opened 
when I kill my application !


my application is a single thread process, after the protocol handcheck, 
I send a request a read answers until I get my own threadID back, 
something like :


  send_my_request(my_thread_id);
  while (get_reply->thread_id != my_thread_id) process_server_request();
  process_server_reply();

from my point of view, soffice and my application are both waiting for 
something from the other side.


it's probably something wrong in my URP implementation, but what I can't 
understand is that the same client work just fine on a remote office, 
and that a second instance of my client work also just fine on a local 
host. How can my code be wrong only on the first connexion to a local 
office ?!


BTW I agree with you, the best way to understand what's going on is to 
look at the server side, but I'm a Delphi developper, debugging 
soffice.bin is an hard task for me :)


I've made a protocol sniffer to trace Python to Office exchange...it 
does a lot of unnecessary things (XTypeProvider, XElementAccess, 
XNameAccess, XUnoTunnel.getSomething, etc...) but I can't figure what is 
missing/wrong in my code to just open a private stream.


Paul

Stephan


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

Re: [Libreoffice] [PATCH] Remove options "Show preview of fonts" and "Show font history"

[Stefan Knorr (Astron)]

Hi everyone,

> But even when thinking of the performance, I think the 'font history'
> part of the patch is non-controversial, right? :-)

I'd go so far as to say both are uncritical.
However, if it is feasible to just cache the font names shortly after
startup or if it is possible to speed up their display otherwise, we
should try to do that for 3.6.


> Another thing to remove from the font listbox would be the bitmap
> indicating the vector fonts; we do not show any bitmap fonts there any
> more (do we?), so it is shown for every font in the list.

Checked on Windows and Linux and we don't seem to. So, yes, that might
rid us of at least two icons and a bit of code if we decide we don't
ever want to display bitmap-based fonts again.

Regards/happy new year,

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

Re: [Libreoffice] UPR local host problem

[Stephan Bergmann]

On 01/02/2012 12:37 PM, Paul TOTH wrote:

Hi,

Le 02/01/2012 14:21, Stephan Bergmann a écrit :

On 01/02/2012 11:06 AM, Paul TOTH wrote:

does anyone know the URP protocol ?

I've found very few information about it
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol




But that's as detailed as you can reasonably expect it to be? ;)
Anyway, I assume your problem is higher up the abstraction hierarchy
than plain URP. If there were problems establishing localhost
connections, you would get problems already before reaching the
loadComponentFromURL call.



Well I havent' found any document on how the IDs (like
1e3ad60;uno[0];18b8;85f8da80603b478cb08cd837553b7f6d) are defined...so
I've used Windows GUID to identify my objects instances.


Ah, it had escaped me that you implemented an URP end-point of your own. 
 How such IDs are generated is indeed unspecified.  See also 
 "Missing 
Specification to Guarantee Unique URP Thread IDs."



my application is a single thread process, after the protocol handcheck,
I send a request a read answers until I get my own threadID back,
something like :

send_my_request(my_thread_id);
while (get_reply->thread_id != my_thread_id) process_server_request();
process_server_reply();


Are you sure that you would handle scenarios correctly where the remote 
side sends back requests on the same thread ID while you are waiting for 
a reply?


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

Re: [Libreoffice] UPR local host problem

[Paul TOTH]

Le 02/01/2012 16:43, Stephan Bergmann a écrit :

On 01/02/2012 12:37 PM, Paul TOTH wrote:

Hi,

Le 02/01/2012 14:21, Stephan Bergmann a écrit :

On 01/02/2012 11:06 AM, Paul TOTH wrote:

does anyone know the URP protocol ?

I've found very few information about it
http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol 






But that's as detailed as you can reasonably expect it to be? ;)
Anyway, I assume your problem is higher up the abstraction hierarchy
than plain URP. If there were problems establishing localhost
connections, you would get problems already before reaching the
loadComponentFromURL call.



Well I havent' found any document on how the IDs (like
1e3ad60;uno[0];18b8;85f8da80603b478cb08cd837553b7f6d) are defined...so
I've used Windows GUID to identify my objects instances.


Ah, it had escaped me that you implemented an URP end-point of your 
own.  How such IDs are generated is indeed unspecified.  See also 
 "Missing 
Specification to Guarantee Unique URP Thread IDs."




I've notice some strange behaviors when using a predefined ThreadID like 
"RemoteOffice-ThreadID", on a first request, everything is fine, but 
some objects OIDs seems to be persistant event after the socket 
deconnexion. I guess when they are cleared ?! So I use a unique one now.



my application is a single thread process, after the protocol handcheck,
I send a request a read answers until I get my own threadID back,
something like :

send_my_request(my_thread_id);
while (get_reply->thread_id != my_thread_id) process_server_request();
process_server_reply();


Are you sure that you would handle scenarios correctly where the 
remote side sends back requests on the same thread ID while you are 
waiting for a reply?


well, I'm not sure how Office is done, but from the tests I've made :
- with XInitialize the server do not send any request
- with an XInputStream the server request some interfaces like 
XSeekable, XCloseable,  call some methods (seek, readsomeBytes...) but 
this is done on an other thread, and then the XComponent OIDs is send on 
the main ThreadID.


Paul


Stephan


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

Re: [Libreoffice] UPR local host problem

[Stephan Bergmann]

On 01/02/2012 01:56 PM, Paul TOTH wrote:

I've notice some strange behaviors when using a predefined ThreadID like
"RemoteOffice-ThreadID", on a first request, everything is fine, but
some objects OIDs seems to be persistant event after the socket
deconnexion. I guess when they are cleared ?! So I use a unique one now.


Not sure how TIDs and OIDs would relate here (but then again, there can 
indeed be unexpected interferences between seemingly unrelated things 
with URP).



well, I'm not sure how Office is done, but from the tests I've made :
- with XInitialize the server do not send any request
- with an XInputStream the server request some interfaces like
XSeekable, XCloseable, call some methods (seek, readsomeBytes...) but
this is done on an other thread, and then the XComponent OIDs is send on
the main ThreadID.


Hard to tell what causes the hang without actually looking at the state 
of the two processes...  Sorry, no quick and easy ideas what could cause 
this.


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

Re: [Libreoffice] [REVIEW-3-4-5] bug#36874 to be patched in 3.4.5 as well?

[Petr Mladek]

Winfried Donkers píše v Pá 23. 12. 2011 v 17:04 +0100:
> >Your code looks definitely better than the original one. Well, I am
> >still not sure about the calculation. It makes perfect sense when I
> >imagine the paper with blank labels. On the other hand,
> >please look at http://download.go-oo.org/tmp/labels.png. 
> 
> I looked at a lot of (blank) labels and also came to the conclusion that the 
> definition of the labels leaves room for interpretation.
> My calculation is based on the assumption (presumption?) that the
> page containing the labels is symmetrical, i.e. rotating the page
> 180 degrees is not a problem, left margine equals right margin and
> top margin equals bottom margin.

I see the point and agree with your assumption. Your patch makes sense
and I have pushed it to the 3-4 branch, see
http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=502ef71db74c3cdb1433c3402a0d93971dc47f1b

We need two more approvals for the 3-4-5 branch.

Bjoern pushed your patch to master. I wonder if he could vote here ;-)


> It would be much better if the label-definitions contain all dimensions, i.e.
> should include either right margin and bottom margin or the page size.
> That was too great a change for me to commit without proper discussion.

Yes, it would make sense.


> >Is just the visualization wrong in LO?
> I have not looked at the visualisation/UI

The visualization is crazy. It would be great to fix it.

> , but at the page size as shown in
> format-page and at the printer behaviour (the printer at our office wants 
> exact 
> A4 definiton, otherwise it asks for custom paper sheets).

I see.


> Should you wish further information (hacking ?), feel free to ask. Currently 
> I am
> wrestling with easyhack 34425, but should I get that right, I can have a go 
> at further
> improvements of labels.
> For users, label printing is mostly troublesome, so any extra 
> user-friendliness
> of the application is a plus.

It is great that you are hacking on it.

Best Regards,
Petr

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

Re: [Libreoffice] [REVIEW][PUSHED] invalid ODF fdo#37390 fdo#44073 fdo#44082

[Lubos Lunak]

On Friday 23 of December 2011, Petr Mladek wrote:
> Cedric Bosdonnat píše v Pá 23. 12. 2011 v 09:35 +0100:
> > On Fri, 2011-12-23 at 00:16 +0100, Michael Stahl wrote:
> > > proposing the following commits for 3.4.5, as they prevent LO from
> > > writing invalid ODF:
> > >
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1e1ef80e842851
> > >4499b061e00801a6a6298d0b0
> > >
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=59a5c37d0df9b56
> > >12552c4b749191385ca0adc80

> I have pushed it to the libreoffice-3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=005f59ac32ce48397fa7df3b4f6586467c7f9bda
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=09b32d79015b9e4fd933492b495b99ab1cda051d
>
>
> We need one more approval for 3-4-5 branch.

 Ack, and pushed to 3-4-5 branch.

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

Re: [Libreoffice] [REVIEW 3-4-5][PUSHED-3-4-5] fdo#38435

[Petr Mladek]

Muthu Subramanian K píše v Pá 30. 12. 2011 v 17:15 +0530:
> Approved from me too.

+1 => third approval => pushed, see
http://cgit.freedesktop.org/libreoffice/base/commit/?h=libreoffice-3-4-5&id=88e31643c7036cc68571752f8ecdf486e67282da


Best Regards,
Petr

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

[Libreoffice] REMINDER: Release 3.4.5-rc2 from libreoffice-3-4-5 branch

[Petr Mladek]

Hi,

please note that the commit deadline for 3.4.5-rc2 is today, January 2,
2012. It will be used as LO-3.4.5 final if no blocker is reported.

See also
http://wiki.documentfoundation.org/ReleasePlan#3.4_release
http://wiki.documentfoundation.org/Release_Criteria
http://wiki.documentfoundation.org/Development/Branches


Best Regards,
Petr


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

Re: [Libreoffice] feature/gbuild_cppuhelper

[Stephan Bergmann]

On 12/26/2011 02:15 PM, Matúš Kukan wrote:

I just tested with MinGW and it builds too.


So now that it is known to work on Linux, Mac OS X, and MinGW, I folded 
feature/gbuild_cppuhelper back into master.  I will see to get my two 
temporary hacks ("Temporary hack to work around autodoc bug" and 
"Temporary hack around cppu_detail_getCppuType variants violating ODR.") 
addressed directly on master.


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

Re: [Libreoffice] [REVIEW-3-4-5] bug#36874 to be patched in 3.4.5 as well?

[Bjoern Michaelsen]

On Mon, Jan 02, 2012 at 02:46:11PM +0100, Petr Mladek wrote:
> Bjoern pushed your patch to master. I wonder if he could vote here ;-)

Looking good to me for 3.4.5.

Best,

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

Re: [Libreoffice] [REVIEW] fdo#40482 sw: view options changed by printing

[Cedric Bosdonnat]

On Thu, 2011-12-22 at 10:11 +, Caolán McNamara wrote:
> On Wed, 2011-12-21 at 17:11 +0100, Michael Stahl wrote:
> > i'd like to have the fix for $SUBJECT in 3.4.5, it is a regression
> > introduced in 3.4.2 or 3.4.3, am too lazy to check which.
> > 
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=89d2733e16ae6233deea6bef3193bd45c89b854c
> 
> Bah :-(. Well, this looks better to me anyway. So +1 from me. On the
> other hand I cocked up with the "make it not crash" fix so could
> definitely do with someone else's approval in addition :-)

That looks OK to me too. On more approval needed is that right? or
should I cherry-pick it to 3.4.5?

--
Cedric

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

Re: [Libreoffice] [REVIEW 3-4] Related: fdo#33463 (writerfilter)

[Petr Mladek]

Miklos Vajna píše v So 31. 12. 2011 v 14:51 +0100:
> Hi,
> 
> In https://bugs.freedesktop.org/show_bug.cgi?id=33463#c25 Michael stated
> "Unfortunately, it seems to provoke a (prolly) unrelated import problem,
> such that comments end up with some double-strike-out style if you
> re-import them ;-) but at least there is no data loss."
>
> I don't have a -3-4 checkout around - could someone check if commit
> 52f51f57287fc955fd83b521c80519beb5c923bf in master is what fixes the
> double strike-though problem? If yes, I think it would make sense to
> backport that one to -3-4 as well.

The fix makes perfect sense. The same check is used for other
attributes, e.g. LN_CFStrike, LN_CFBold, LN_CFCaps => I have pushed it
to the libreoffice-3-4 branch, see
http://cgit.freedesktop.org/libreoffice/filters/commit/?h=libreoffice-3-4&id=9dcc765e88bf23418ffbf66345e4eaa4c36005e4

We need two more approvals for the 3-4-5 branch.

Unfortunately, I am not able to reproduce the original problem with the
double striked format => I am not sure if it fixes the problem. Michael?


Best Regards,
Petr

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

Re: [Libreoffice] Change in addition for date handling (intentional change??)

[Andrew Douglas Pitonyak]

I created a bug for this.

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=44385

I will poke around and see if I am able to build the source and test a 
solution... Running git now.


On 01/01/2012 11:01 AM, Andrew Douglas Pitonyak wrote:

Thanks for checking Will wait and see what Noel has to say...

The change broke more in that it also ignores EXP, MUL, DIV, MINUS, 
and NEG. I expect, however, that PLUS and MINUS are the most common 
operations (to add and subtract days and similar). I cannot think of a 
highly plausible reason for EXP, MUL, or NEG. Hmmm, or perhaps I can, 
but it is a stretch.


Certainly the change will increase performance for the cases when a 
date is not used / expected.


Off hand, I am of the opinion that a fix should at least be added for 
PLUS and MINUS.


On 01/01/2012 09:52 AM, Regina Henschel wrote:

Hi Andrew,

I don't know any about the content, but I have searched, when the 
changes where made:


The part
// #45465 Date needs with "+" a special handling: forces date type
  if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
 aL.eType = SbxDATE;
moved from after the switch inside the switch with commit
1421b098ae19a10acb4836fa3752188cf7c52eb2
by Noel Power 06-Dec-2010

and the "#if 0" is a WaE fix by Tor Lillqvist 06-Oct-2011
8529da08517b41bd9317714e3216bb6d487b24ee

So I think, Noel should know.

Kind regards
Regina

Andrew Douglas Pitonyak schrieb:

I thought I found a bug, I decided to take a crack at fixing the bug,
and then I became confused because the bug appears to be intentional.
Let me explain:

Consider some comments related to Basic.

In the last release of OOo, the statement "Now + 2" returns a date /
time that is two days later than now. In LibreOffice, the same 
statement

appears to return the double representation of the same. Now, off hand,
this appears fine, until one tries to do something like this (which
works in OOo, but fails in LO)

DateValue(Now + 2)

This is no big deal if I am writing new code, because I can compensate:
DateValue(CDate(Now + 2)), but t kills legacy code.

I started poking through the code and I found
core/basic/source/sbx/sbxvalue.cxx

In the version of the LO code that I have, around line 1312, I see the
following:

case SbxPLUS:
aL.nDouble += aR.nDouble; break;
#if 0
// See 'break' on preceding line... this
// is unreachable code. Do not delete this
// #if 0 block unless you know for sure
// the 'break' above is intentional.

// #45465 Date needs with "+" a special handling: forces date type
if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
aL.eType = SbxDATE;
#endif

In OOo, the code ends at the break, but following the switch statement,
there is the following check:

// #45465 Date braucht bei + eine Spezial-Behandlung
if( eOp == SbxPLUS && (GetType() == SbxDATE || rOp.GetType() == 
SbxDATE ) )

aL.eType = SbxDATE;

So, it looks like someone did a code clean-up and the special handling
code was moved into the switch statement and then it was commented out.

I was so proud that I figured out where this occurred, but, I am a bit
stymied as to what happened here. It seems that I have almost 
nothing to

fix because someone did this intentionally, or was this left as is
because whomever made the change did not understand why the code was
there

Sorry, just a bit confused as to what should be done. My opinion is 
that

a bug was introduced and that the fix is clear, move the break and let
the code run...

case SbxPLUS:
aL.nDouble += aR.nDouble;
// #45465 Date needs with "+" a special handling: forces date type
if( GetType() == SbxDATE || rOp.GetType() == SbxDATE )
aL.eType = SbxDATE;
break;

So, what am I missing?



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





--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

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

[Libreoffice] Funny piece of code.

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

I stumbled on this piece of code in

registry/tools/regcompare.cxx

There must be a finesse in lines 326, 330, and so on that I missed
miserably...

Any advise welcome, or I will rip off the ternary operator.

Thanks

Olivier

static OString getFieldAccess(RTFieldAccess fieldAccess)
318 {
319 OString ret;
320 if ( (fieldAccess & RT_ACCESS_INVALID) == RT_ACCESS_INVALID )
321 {
322 ret += OString("INVALID");
323 }
324 if ( (fieldAccess & RT_ACCESS_READONLY) == RT_ACCESS_READONLY )
325 {
326 ret += OString(ret.getLength() > 0 ? ",READONLY" :
"READONLY");
327 }
328 if ( (fieldAccess & RT_ACCESS_OPTIONAL) == RT_ACCESS_OPTIONAL )
329 {
330 ret += OString(ret.getLength() > 0 ? ",OPTIONAL" :
"OPTIONAL");

(snip)


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

iQEcBAEBAgAGBQJPAc/xAAoJEJp3R7nH3vLxzlwH/2ImYxCTRbrpzzDamR8V48AV
IXbv5yhv8TIUYL6BRgDAHoT0Qte5HDXSL1FJAuDhUqu6R31hRfOBjToFb7k5DVsS
dFkfIrrmEG2efs4jF4GM1yUNF307CECaN0byOw/7uSlJHjqOn4n5FX1m0UK9vHWU
MJaOkBEHh55/V0pXgoTWqxi1FRliV7PDVXTn8tiUpzQGU18sz6+XJmP7GUYMHieK
yS167M7oY0GtxAUzF+TIz16e3vvk23m6dwue/XLowwIqX9cVWACgmyTAjB81t36a
1zle5kDFpt9M/VP6gbebahhKTXn99yshyyHfesqb0HvNTdvWqs0a1qrGWQeMmYE=
=8r/d
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Funny piece of code.

[Jesús Corrius]

On Mon, Jan 2, 2012 at 4:40 PM, Olivier Hallot
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi
>
> I stumbled on this piece of code in
>
> registry/tools/regcompare.cxx
>
> There must be a finesse in lines 326, 330, and so on that I missed
> miserably...

If the string is empty, it adds the text.
If the string already has some content, it adds the text with a
preceding coma to separate the elements.

-- 
Jesús Corrius 
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Fwd: Funny piece of code.

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

never mind...

a (almos unseen) comma makes the difference...

Sorry to bother you

Olivier

-  Mensagem original 
Assunto: Funny piece of code.
Data: Mon, 02 Jan 2012 13:40:33 -0200
De: Olivier Hallot 
Responder a: olivier.hal...@documentfoundation.org
Empresa: The Document Foundation
Para: LO-dev 

Hi

I stumbled on this piece of code in

registry/tools/regcompare.cxx

There must be a finesse in lines 326, 330, and so on that I missed
miserably...

Any advise welcome, or I will rip off the ternary operator.

Thanks

Olivier

static OString getFieldAccess(RTFieldAccess fieldAccess)
318 {
319 OString ret;
320 if ( (fieldAccess & RT_ACCESS_INVALID) == RT_ACCESS_INVALID )
321 {
322 ret += OString("INVALID");
323 }
324 if ( (fieldAccess & RT_ACCESS_READONLY) == RT_ACCESS_READONLY )
325 {
326 ret += OString(ret.getLength() > 0 ? ",READONLY" :
"READONLY");
327 }
328 if ( (fieldAccess & RT_ACCESS_OPTIONAL) == RT_ACCESS_OPTIONAL )
329 {
330 ret += OString(ret.getLength() > 0 ? ",OPTIONAL" :
"OPTIONAL");

(snip)



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

iQEcBAEBAgAGBQJPAdEPAAoJEJp3R7nH3vLx/WsH/3GeeQ8TdO8qXNBZ70gU/jAP
Sk0/Gkoj5MPKkfK+BTv/PEEwEFKUmu0eLYwR4DVGJEqxGi94IfI/0BAMDyH9Y9Ce
hcCBJIWi+KhWocjSYk2tCgYrjSCdOcJQtQH/wB8D+hYUJpyJ93X9mMRgJFnMTUpe
iZ6fCzuuLzJ7tpNKZ769q7ROrTbm7VdSEXx0Sostsx0yt2AsrRppfO5LoqSxPwuq
lkkIiUvKQkAlqwRukM3gNtbL7IxZEIWMn0o1umRnfAXEX+W9VmuLLuVvIanK4KuU
PrtE4j3nNYARThkG8ticuWpEUIMLKfW3m8BK6/yHw7wx+ogT9B7Adx8qPN/7Ujo=
=55k1
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Funny piece of code.

[Stephan Bergmann]

On 01/02/2012 04:40 PM, Olivier Hallot wrote:

I stumbled on this piece of code in

registry/tools/regcompare.cxx

There must be a finesse in lines 326, 330, and so on that I missed
miserably...

Any advise welcome, or I will rip off the ternary operator.


note the leading commas in the !isEmpty() cases

Stephan



Thanks

Olivier

static OString getFieldAccess(RTFieldAccess fieldAccess)
 318 {
 319 OString ret;
 320 if ( (fieldAccess&  RT_ACCESS_INVALID) == RT_ACCESS_INVALID )
 321 {
 322 ret += OString("INVALID");
 323 }
 324 if ( (fieldAccess&  RT_ACCESS_READONLY) == RT_ACCESS_READONLY )
 325 {
 326 ret += OString(ret.getLength()>  0 ? ",READONLY" :
"READONLY");
 327 }
 328 if ( (fieldAccess&  RT_ACCESS_OPTIONAL) == RT_ACCESS_OPTIONAL )
 329 {
 330 ret += OString(ret.getLength()>  0 ? ",OPTIONAL" :
"OPTIONAL");

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

Re: [Libreoffice] Funny piece of code.

[Petr Mladek]

Olivier Hallot píše v Po 02. 01. 2012 v 13:40 -0200:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi
> 
> I stumbled on this piece of code in
> 
> registry/tools/regcompare.cxx
> 
> There must be a finesse in lines 326, 330, and so on that I missed
> miserably...
> 
> Any advise welcome, or I will rip off the ternary operator.
> 
> Thanks
> 
> Olivier
> 
> static OString getFieldAccess(RTFieldAccess fieldAccess)
> 318 {
> 319 OString ret;
> 320 if ( (fieldAccess & RT_ACCESS_INVALID) == RT_ACCESS_INVALID )
> 321 {
> 322 ret += OString("INVALID");
> 323 }
> 324 if ( (fieldAccess & RT_ACCESS_READONLY) == RT_ACCESS_READONLY )
> 325 {
> 326 ret += OString(ret.getLength() > 0 ? ",READONLY" :
> "READONLY");
> 327 }
> 328 if ( (fieldAccess & RT_ACCESS_OPTIONAL) == RT_ACCESS_OPTIONAL )
> 329 {
> 330 ret += OString(ret.getLength() > 0 ? ",OPTIONAL" :
> "OPTIONAL");

IMHO, you missed the comma "," ;-) It is used to delimit the words where
there are more added. The code generates strings like:

"INVALID"
"INVALID,READONLY" // uses comma ',' before "READONLY"
"READONLY" // uses pure "READONLY"
"READONLY,OPTIONAL"


Best Regards,
Petr

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

Re: [Libreoffice] Funny piece of code.

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks you guys for the help

the "finesse" was indeed a "thin-esse"

Olivier

Em 02-01-2012 13:51, Petr Mladek escreveu:
> Olivier Hallot píše v Po 02. 01. 2012 v 13:40 -0200:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi
>>
>> I stumbled on this piece of code in
>>
>> registry/tools/regcompare.cxx
>>
>> There must be a finesse in lines 326, 330, and so on that I missed
>> miserably...
>>
>> Any advise welcome, or I will rip off the ternary operator.
>>
>> Thanks
>>
>> Olivier
>>
>> static OString getFieldAccess(RTFieldAccess fieldAccess)
>> 318 {
>> 319 OString ret;
>> 320 if ( (fieldAccess & RT_ACCESS_INVALID) == RT_ACCESS_INVALID )
>> 321 {
>> 322 ret += OString("INVALID");
>> 323 }
>> 324 if ( (fieldAccess & RT_ACCESS_READONLY) == RT_ACCESS_READONLY )
>> 325 {
>> 326 ret += OString(ret.getLength() > 0 ? ",READONLY" :
>> "READONLY");
>> 327 }
>> 328 if ( (fieldAccess & RT_ACCESS_OPTIONAL) == RT_ACCESS_OPTIONAL )
>> 329 {
>> 330 ret += OString(ret.getLength() > 0 ? ",OPTIONAL" :
>> "OPTIONAL");
> 
> IMHO, you missed the comma "," ;-) It is used to delimit the words where
> there are more added. The code generates strings like:
> 
> "INVALID"
> "INVALID,READONLY" // uses comma ',' before "READONLY"
> "READONLY" // uses pure "READONLY"
> "READONLY,OPTIONAL"
> 
> 
> Best Regards,
> Petr
> 

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

iQEcBAEBAgAGBQJPAdTMAAoJEJp3R7nH3vLxZ68IAK9+VlAVae76/NqWCcrBzm/2
IJIkdN/mlT4t5dJ1SRO9doPpcgZ2iEt+9sd/DDer7Z9E4b7Eoj7vI1ZpKThH6aND
7K15Hd6fw0xhUJDMdgnn+UYy87T2h9CxZbnn6EVbyImWkJy8R8fRGLm7+s7pLqBg
PJzFuXgykYJ2lcTW8L6rKCZQfvDuBRa07NKkV5gMVjK9sCmYPInduuuOs8XL4qBk
bDE7P5Vyiv6FK0w+vZxy54MjbpRHdfsTrvOsIIQn4IFULNmkBeIqxWOv9s2bGO9U
uDO9lZjZQNfFvHUuKIrmGcZfnddQXtCxrdmXJ8uNuoV6OAtJRpkBcoTituIqT78=
=3c+u
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Few word about set_soenv.in and config_host.mk.in

[Norbert Thiebaud]

set_soenv.in is the base for a perl program, executed during configure
that generate Env.Host.sh

in turn Env.Host.sh (and Env.Build.sh in case of cross-compile) need
to be 'sourced' in the shell... which lead to the need of some
recurdsion magic in the Makefile.

config_host.mk.in isthe base to generate a file config_host.k (and
config_build.mk in case of cross compile). this file is designed in
such way that it can be sourced in a shell _OR_ included directly in a
Makefile.
The later option would alleviate the need to recurse

The main issue involved in this conversion are:

- set_soenv would 'undef' any variable that end-up with an empty
value. Most of the build test of == "" and does not rely on ifndef,
but still there are exceptions which can cause trouble during the
conversion.
(Note: supporting the undef behavior is quite painfull to do in a way
that maintain the goal of being both source-able and include-able)

- set_soenv do path modification (to deal with windows mostly). it is
very easy to get confused as to when a PATH should be 'windows' like
and when it should be unix like... this is not help by the fact that
the dmake build system actually tweak things along the way...

- set_soenv deal with PATH. managing that properly is quite painful...
I have not even started to think how I'm going to do that (except that
I probably will need a kidn of path_munge() function in configure.in


so, if your build start to act stupid on master... that may be my fault :-)

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

Re: [Libreoffice] [REVIEWED][PUSHED:3-4-5] fdo#40482 sw: view options changed by printing

[Petr Mladek]

Cedric Bosdonnat píše v Po 02. 01. 2012 v 16:02 +0100:
> On Thu, 2011-12-22 at 10:11 +, Caolán McNamara wrote:
> > On Wed, 2011-12-21 at 17:11 +0100, Michael Stahl wrote:
> > > i'd like to have the fix for $SUBJECT in 3.4.5, it is a regression
> > > introduced in 3.4.2 or 3.4.3, am too lazy to check which.
> > > 
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=89d2733e16ae6233deea6bef3193bd45c89b854c
> > 
> > Bah :-(. Well, this looks better to me anyway. So +1 from me. On the
> > other hand I cocked up with the "make it not crash" fix so could
> > definitely do with someone else's approval in addition :-)
> 
> That looks OK to me too. On more approval needed is that right? or
> should I cherry-pick it to 3.4.5?

Looks fine and works fine here => 3rd approval => pushed to the 3-4-5
branch, see
http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4-5&id=2e183bde347bff8f617a275beff12eb257aac719

Best Regards,
Petr

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

Re: [Libreoffice] [PATCH][PUSHED] Remove unused code

[Lubos Lunak]

On Wednesday 28 of December 2011, Marcel Metz wrote:
> Hello lo-devs,
>
> There is never an instance of mpDateTable allocated and a lot of
> code is never executed because of that. This patch removes the
> unused code.

 Pushed, thanks.

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

Re: [Libreoffice] [REVIEW:3-4-5] crash in LO 3.4.5 rc1 : fdo40253

[Petr Mladek]

Petr Mladek píše v Po 02. 01. 2012 v 11:31 +0100:
> Jean-Baptiste Faure píše v Po 26. 12. 2011 v 10:51 +0100:
> > Hi,
> > 
> > Bug fdo40253 seems to be fixed in LO 3.5.0 beta2+ but still crashes LO
> > 3.4.5 rc1. I don't know which commit solved this but is it possible to
> > backport the fix to 3.4.5 ?
> 
> I guess that it has been fixed by
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbaadd31d3ff53f18a7b8d2b0af947328dc81d91
> 
> It looks good and pretty safe to me. Similar thing is done also in 
> SdrTableObj::setTableStyle.

It really fixes the crash and works fine. The fix makes sense and looks
safe => pushed to the 3-4 branch, see
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=395c05c288116683ffb3bceb658f61694c042b28

We need 2 more approvals for the 3-4-5 branch.



Best Regards,
Petr

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

Re: [Libreoffice] [REVIEW 3-4] Related: fdo#33463 (writerfilter)

[Lubos Lunak]

On Monday 02 of January 2012, Petr Mladek wrote:
> Miklos Vajna píše v So 31. 12. 2011 v 14:51 +0100:
> > I don't have a -3-4 checkout around - could someone check if commit
> > 52f51f57287fc955fd83b521c80519beb5c923bf in master is what fixes the
> > double strike-though problem? If yes, I think it would make sense to
> > backport that one to -3-4 as well.
>
> The fix makes perfect sense. The same check is used for other
> attributes, e.g. LN_CFStrike, LN_CFBold, LN_CFCaps => I have pushed it
> to the libreoffice-3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/filters/commit/?h=libreoffice-3-4&i
>d=9dcc765e88bf23418ffbf66345e4eaa4c36005e4

 Yes, it's correct.

> We need two more approvals for the 3-4-5 branch.

 One.

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

Re: [Libreoffice] [REVIEW-3-4-5] bug#36874 to be patched in 3.4.5 as well?

[Lubos Lunak]

On Monday 02 of January 2012, Petr Mladek wrote:
> Winfried Donkers píše v Pá 23. 12. 2011 v 17:04 +0100:
> > >Your code looks definitely better than the original one. Well, I am
> > >still not sure about the calculation. It makes perfect sense when I
> > >imagine the paper with blank labels. On the other hand,
> > >please look at http://download.go-oo.org/tmp/labels.png.
> >
> > I looked at a lot of (blank) labels and also came to the conclusion that
> > the definition of the labels leaves room for interpretation.
> > My calculation is based on the assumption (presumption?) that the
> > page containing the labels is symmetrical, i.e. rotating the page
> > 180 degrees is not a problem, left margine equals right margin and
> > top margin equals bottom margin.
>
> I see the point and agree with your assumption. Your patch makes sense
> and I have pushed it to the 3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id
>=502ef71db74c3cdb1433c3402a0d93971dc47f1b
>
> We need two more approvals for the 3-4-5 branch.

 Looks ok.

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

Re: [Libreoffice] [REVIEW 3-4] Related: fdo#33463 (writerfilter)

[Tommy]

On Mon, 02 Jan 2012 18:29:15 +0100, Lubos Lunak  wrote:


On Monday 02 of January 2012, Petr Mladek wrote:

Miklos Vajna píše v So 31. 12. 2011 v 14:51 +0100:
> I don't have a -3-4 checkout around - could someone check if commit
> 52f51f57287fc955fd83b521c80519beb5c923bf in master is what fixes the
> double strike-though problem? If yes, I think it would make sense to
> backport that one to -3-4 as well.

The fix makes perfect sense. The same check is used for other
attributes, e.g. LN_CFStrike, LN_CFBold, LN_CFCaps => I have pushed it
to the libreoffice-3-4 branch, see
http://cgit.freedesktop.org/libreoffice/filters/commit/?h=libreoffice-3-4&i
d=9dcc765e88bf23418ffbf66345e4eaa4c36005e4


 Yes, it's correct.


We need two more approvals for the 3-4-5 branch.


 One.




please hurry up since today is 3.4.5 commit deadline :-)

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

Re: [Libreoffice] [REVIEW:3-4-5] crash in LO 3.4.5 rc1 : fdo40253

[Lubos Lunak]

On Monday 02 of January 2012, Petr Mladek wrote:
> Petr Mladek píše v Po 02. 01. 2012 v 11:31 +0100:
> > Jean-Baptiste Faure píše v Po 26. 12. 2011 v 10:51 +0100:
> > > Hi,
> > >
> > > Bug fdo40253 seems to be fixed in LO 3.5.0 beta2+ but still crashes LO
> > > 3.4.5 rc1. I don't know which commit solved this but is it possible to
> > > backport the fix to 3.4.5 ?
> >
> > I guess that it has been fixed by
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=cbaadd31d3ff53f18
> >a7b8d2b0af947328dc81d91
> >
> > It looks good and pretty safe to me. Similar thing is done also in
> > SdrTableObj::setTableStyle.
>
> It really fixes the crash and works fine. The fix makes sense and looks
> safe => pushed to the 3-4 branch, see
> http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4
>&id=395c05c288116683ffb3bceb658f61694c042b28
>
> We need 2 more approvals for the 3-4-5 branch.

 Makes sense.

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

[Libreoffice] [PATCH] Fix for fdo43460 Part XXVII getLength() to isEmpty()

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please find attached a partial fix for Easy Hack FDO43460

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

iQEcBAEBAgAGBQJPAfAyAAoJEJp3R7nH3vLxcsQIAJNGxFiQVZfrJlVqn6ZbpdNu
La4PzIhEcefWxxSZqD7e/jr87Xq4kgDMzMiYSOuvIz81QHqrOb9XFKFrNw6N88G5
wHH6O1c7auwwPRUgawxYDRSfy6ODdBJkP9YdU8QYaPrKlDLEQ7vm6ZLZch8epRXW
yEW4WtfcPHaHvOxjS9aOBXTF3bEOScQR156vG3T6qZnXfJVRoJzWz2DGyq5PF48O
E6+UkleqBhmU/yEuWSywpoQJCCSiYTCXPbVbM1mTSUZZG5bhJT22ue45xoaZEJ1c
E0cyHp5X2ggEb42YhHouM1uNr26ezhM2JM3M6wNn8lkw/0tZwW9RcSTQ8JCB3a4=
=aOwt
-END PGP SIGNATURE-
>From 06538e2fafa2c2c33decab84181059dbceb05d1b Mon Sep 17 00:00:00 2001
From: Olivier Hallot 
Date: Mon, 2 Jan 2012 15:53:49 -0200
Subject: [PATCH] Fix for fdo43460 Part XXVII getLength() to isEmpty()

Part XXVII
Modules
padmin, pyuno, rdbmaker, regexp, registry, rsc, sal
---
 padmin/source/adddlg.cxx|4 +-
 padmin/source/cmddlg.cxx|2 +-
 padmin/source/padialog.cxx  |4 +-
 pyuno/source/loader/pyuno_loader.cxx|4 +-
 pyuno/source/module/pyuno_module.cxx|2 +-
 pyuno/source/module/pyuno_runtime.cxx   |4 +-
 rdbmaker/source/codemaker/dependency.cxx|8 ++--
 rdbmaker/source/codemaker/global.cxx|2 +-
 rdbmaker/source/rdbmaker/rdbmaker.cxx   |8 ++--
 regexp/source/reclass.cxx   |2 +-
 registry/source/keyimpl.cxx |   14 
 registry/source/reflwrit.cxx|   28 
 registry/source/regimpl.cxx |   18 +-
 registry/tools/checksingleton.cxx   |2 +-
 registry/tools/regcompare.cxx   |   28 
 rsc/source/parser/rscdb.cxx |   12 +++---
 rsc/source/parser/rscibas.cxx   |4 +-
 rsc/source/rsc/rsc.cxx  |   46 +-
 sal/osl/unx/file_path_helper.cxx|2 +-
 sal/osl/unx/file_stat.cxx   |4 +-
 sal/osl/unx/file_url.cxx|4 +-
 sal/qa/osl/file/osl_File.cxx|2 +-
 sal/qa/osl/security/osl_Security.cxx|2 +-
 sal/qa/rtl/doublelock/rtl_doublelocking.cxx |2 +-
 sal/rtl/source/bootstrap.cxx|   10 +++---
 25 files changed, 109 insertions(+), 109 deletions(-)

diff --git a/padmin/source/adddlg.cxx b/padmin/source/adddlg.cxx
index 62a4f14..d23f426 100644
--- a/padmin/source/adddlg.cxx
+++ b/padmin/source/adddlg.cxx
@@ -165,7 +165,7 @@ void APChooseDriverPage::updateDrivers( bool bRefresh, const rtl::OUString& rSel
 for( std::list< rtl::OUString >::const_iterator it = aDrivers.begin(); it != aDrivers.end(); ++it )
 {
 rtl::OUString aDriver( psp::PPDParser::getPPDPrinterName( *it ) );
-if( aDriver.getLength() )
+if( !aDriver.isEmpty() )
 {
 int nPos = m_aDriverBox.InsertEntry( aDriver );
 m_aDriverBox.SetEntryData( nPos, new String( *it ) );
@@ -567,7 +567,7 @@ APOldPrinterPage::APOldPrinterPage( AddPrinterDialog* pParent )
 
 aValue = aConfig.ReadKey( "PageSize", aDefPageSize );
 int nLeft, nRight, nTop, nBottom;
-if( aValue.getLength() &&
+if( !aValue.isEmpty() &&
 aInfo.m_pParser->getMargins( rtl::OStringToOUString(aValue, aEncoding),
  nLeft, nRight, nTop, nBottom ) )
 {
diff --git a/padmin/source/cmddlg.cxx b/padmin/source/cmddlg.cxx
index 5dc0864..6ab1dfc 100644
--- a/padmin/source/cmddlg.cxx
+++ b/padmin/source/cmddlg.cxx
@@ -344,7 +344,7 @@ void RTSCommandPage::save()
 aToken.compareToAscii( "external_dialog" )
   )
 {
-if( aToken.getLength() )
+if( !aToken.isEmpty() )
 {
 if( aFeatures.Len() )
 aFeatures += ',';
diff --git a/padmin/source/padialog.cxx b/padmin/source/padialog.cxx
index 51e996e..1aeab2c 100644
--- a/padmin/source/padialog.cxx
+++ b/padmin/source/padialog.cxx
@@ -278,7 +278,7 @@ void PADialog::UpdateDefPrt()
 void PADialog::UpdateText()
 {
 OUString aDev( getSelectedDevice() );
-if( aDev.getLength() )
+if( !aDev.isEmpty() )
 {
 const PrinterInfo& rInfo = m_rPIManager.getPrinterInfo( aDev );
 String aDriver( rInfo.m_aPrinterName );
@@ -722,7 +722,7 @@ void PADialog::UpdateDevice()
 while( nIndex != -1 && ! bAutoQueue )
 {
 OUString aToken( rInfo.m_aFeatures.getToken( 0, ',', nIndex ) );
-if( aToken.getLength() )
+if( !aToken.isEmpty() )
 {
 if( aToken.compareToA

Re: [Libreoffice] [PATCH] Fix for fdo43460 Part XXV getLength() to isEmpty()

[Lubos Lunak]

On Sunday 01 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXI
> Module
> oox

 Pushed, thanks.

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

Re: [Libreoffice] [PATCH][PUSHED] Fix for fdo43460 Part XXVI getLength() to isEmpty()

[Lubos Lunak]

On Sunday 01 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXVI
> Module
> package

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

Re: [Libreoffice] [PATCH][PUSHED] Fix for fdo43460 Part XXVII getLength() to isEmpty()

[Lubos Lunak]

On Monday 02 of January 2012, Olivier Hallot wrote:
> Please find attached a partial fix for Easy Hack FDO43460
>
> Part XXVII
> Modules
> padmin, pyuno, rdbmaker, regexp, registry, rsc, sal

 Pushed as well.

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

[Libreoffice] [PATCH] Replace ByteString with rtl::OString

[Chr. Rossmanith]

Hi,

could someone please review this small patch and give feed back.

Thank you,
Christina
>From c1770ed9ab8ba9f11cab7574e9ce626ec754337c Mon Sep 17 00:00:00 2001
From: Christina Rossmanith 
Date: Mon, 2 Jan 2012 21:56:19 +0100
Subject: [PATCH] Replace ByteString with rtl::OString

---
 vcl/generic/print/genprnpsp.cxx |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/vcl/generic/print/genprnpsp.cxx b/vcl/generic/print/genprnpsp.cxx
index 23a7bf5..ba81a72 100644
--- a/vcl/generic/print/genprnpsp.cxx
+++ b/vcl/generic/print/genprnpsp.cxx
@@ -47,6 +47,7 @@
 #endif
 
 #include "rtl/ustring.hxx"
+#include "comphelper/string.hxx"
 
 #include "osl/module.h"
 
@@ -86,19 +87,19 @@ typedef int(*faxFunction)(String&);
 static faxFunction pFaxNrFunction   = NULL;
 }
 
-static String getPdfDir( const PrinterInfo& rInfo )
+static rtl::OUString getPdfDir( const PrinterInfo& rInfo )
 {
-String aDir;
+rtl::OUString aDir;
 sal_Int32 nIndex = 0;
 while( nIndex != -1 )
 {
-OUString aToken( rInfo.m_aFeatures.getToken( 0, ',', nIndex ) );
+rtl::OUString aToken( rInfo.m_aFeatures.getToken( 0, ',', nIndex ) );
 if( ! aToken.compareToAscii( "pdf=", 4 ) )
 {
 sal_Int32 nPos = 0;
 aDir = aToken.getToken( 1, '=', nPos );
-if( ! aDir.Len() )
-aDir = String( ByteString( getenv( "HOME" ) ), osl_getThreadTextEncoding() );
+if( aDir.isEmpty() )
+aDir = rtl::OUString( getenv( "HOME" ), 4, osl_getThreadTextEncoding() );
 break;
 }
 }
@@ -235,20 +236,19 @@ static bool passFileToCommandLine( const String& rFilename, const String& rComma
 bool bSuccess = false;
 
 rtl_TextEncoding aEncoding = osl_getThreadTextEncoding();
-ByteString aCmdLine(rtl::OUStringToOString(rCommandLine, aEncoding));
+rtl::OString aCmdLine(rtl::OUStringToOString(rCommandLine, aEncoding));
 rtl::OString aFilename(rtl::OUStringToOString(rFilename, aEncoding));
 
-bool bPipe = aCmdLine.Search( "(TMP)" ) != STRING_NOTFOUND ? false : true;
+bool bPipe = aCmdLine.indexOf( "(TMP)" ) >= 0 ? false : true;
 
 // setup command line for exec
 if( ! bPipe )
-while( aCmdLine.SearchAndReplace( "(TMP)", aFilename ) != STRING_NOTFOUND )
-;
+aCmdLine = comphelper::string::replace( aCmdLine, rtl::OString("(TMP)"), aFilename );
 
 #if OSL_DEBUG_LEVEL > 1
 fprintf( stderr, "%s commandline: \"%s\"\n",
  bPipe ? "piping to" : "executing",
- aCmdLine.GetBuffer() );
+ aCmdLine.getStr() );
 struct stat aStat;
 if( stat( aFilename.getStr(), &aStat ) )
 fprintf( stderr, "stat( %s ) failed\n", aFilename.getStr() );
@@ -258,7 +258,7 @@ static bool passFileToCommandLine( const String& rFilename, const String& rComma
 if( ! ( argv[ 0 ] = getenv( "SHELL" ) ) )
 argv[ 0 ] = "/bin/sh";
 argv[ 1 ] = "-c";
-argv[ 2 ] = aCmdLine.GetBuffer();
+argv[ 2 ] = aCmdLine.getStr();
 argv[ 3 ] = 0;
 
 bool bHavePipes = false;
@@ -301,7 +301,7 @@ static bool passFileToCommandLine( const String& rFilename, const String& rComma
 dup2( fd[0], STDIN_FILENO );
 }
 execv( argv[0], const_cast(argv) );
-fprintf( stderr, "failed to execute \"%s\"\n", aCmdLine.GetBuffer() );
+fprintf( stderr, "failed to execute \"%s\"\n", aCmdLine.getStr() );
 _exit( 1 );
 }
 else
-- 
1.7.4.1

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

Re: [Libreoffice] product-name in title bar of the office ?

[Eike Rathke]

Hi Cor,

On Wednesday, 2011-12-28 17:18:02 +0100, Cor Nouws wrote:

> >>>Up until recently I could change the product-name in the title bar of
> >>>the window via this file: share/registry/brand.xcd>  prop oooname
> >>
> >>It is in share/registry/main.xcd
> >>component-data oor:name="Setup"
> >>node oor:name="Product"
> >>prop oor:name="ooName"
> 
> how do you guys edit smthng as main.xcd?
> XML copy editor sort of hangs
> Emacs is, well, sort of doable ..

Vim ;-)  on a slow machine best invoked with

vim -c 'syntax off' main.xcd

to not have it calculate colors on those long lines for seconds.. Or use
either xmllint or xmlpp to convert to a pretty-printed file, which also
makes syntax highlighting a viable option again because of the then
shorter lines, and any editor should be able to handle it.

> >There's also .../program/versionrc where you can change the
> >ProductSource entry. Easier to edit on the fly..
> 
> But that does not change the title bar of the window?

It does, but apparently only in an --enable-dbgutil build. Sorry for
confusion ;-)

  Eike

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


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

Re: [Libreoffice] product-name in title bar of the office ?

[Cor Nouws]

Hi Eike,

Eike Rathke wrote (02-01-12 22:18)

On Wednesday, 2011-12-28 17:18:02 +0100, Cor Nouws wrote:



But that does not change the title bar of the window?


It does, but apparently only in an --enable-dbgutil build. Sorry for
confusion ;-)


Another learning moment, thanks for that ;-)

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

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

Re: [Libreoffice] [PATCH] Easyhack fdo#38831 - Convert some SvStrings to std::vector

[Eike Rathke]

Hi Brad,

On Wednesday, 2011-12-28 16:47:17 +1300, Brad Sowden wrote:

> Any comments on the size_t changes/best practice welcomed.

> diff --git a/sw/source/ui/dochdl/gloshdl.cxx b/sw/source/ui/dochdl/gloshdl.cxx
> @@ -138,13 +136,13 @@ void SwGlossaryHdl::SetCurGroup(const String &rGrp, 
> sal_Bool bApi, sal_Bool bAlw
>  String sCurBase = aTemp.getBase();
>  aTemp.removeSegment();
>  const String sCurEntryPath = 
> aTemp.GetMainURL(INetURLObject::NO_DECODE);
> -const SvStrings* pPathArr = rStatGlossaries.GetPathArray();
> +const std::vector *pPathArr = 
> rStatGlossaries.GetPathArray();
>  sal_uInt16 nCurrentPath = USHRT_MAX;
> -for(sal_uInt16 nPath = 0; nPath < pPathArr->Count(); nPath++)
> +for( size_t nPath = 0; nPath < pPathArr->size(); nPath++ )
>  {
>  if(sCurEntryPath == *(*pPathArr)[nPath])
>  {
> -nCurrentPath = nPath;
> +nCurrentPath = static_cast(nPath);
>  break;
>  }
>  }

I have some doubt about the sal_uInt16 nCurrentPath usage there. I'm not
familiar at all with that code and have no idea how the PathArray is
controlled as in how many elements could be added or how it is even
used. The SvStrings container wasn't capable of holding more than 64k
elements and things probably went astray anyway if there were more, but
now the vector at least theoretically could hold more elements, so
down casting size_t nPath to sal_uInt16 might not be correct. Changing
things to size_t may be quite invasive though, and if there's some
mechanism that prevents the PathArray to grow beyond 64k elements it's
not nice but fine ;) to downcast. Else it could be a nasty source of
possible failure.

However, apart from that, the loop over all elements to find an
identical string cries out for a hash_map instead of a vector and use
find instead of a loop. That said without having inspected any
neighborhood. It might as well be that due to other context a vector is
appropriate.

Anyhow, that can be optimized and isn't your fault ;) good patch.

  Eike

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


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

Re: [Libreoffice] [PATCH] Replace ByteString with rtl::OString

[Eike Rathke]

Hi Chr.,

On Monday, 2012-01-02 22:05:15 +0100, Chr. Rossmanith wrote:

> could someone please review this small patch and give feed back.

Sure.

> diff --git a/vcl/generic/print/genprnpsp.cxx b/vcl/generic/print/genprnpsp.cxx
> [...]
> -static String getPdfDir( const PrinterInfo& rInfo )
> +static rtl::OUString getPdfDir( const PrinterInfo& rInfo )
>  {
> -String aDir;
> +rtl::OUString aDir;
>  sal_Int32 nIndex = 0;
>  while( nIndex != -1 )
>  {
> -OUString aToken( rInfo.m_aFeatures.getToken( 0, ',', nIndex ) );
> +rtl::OUString aToken( rInfo.m_aFeatures.getToken( 0, ',', nIndex ) );

Prefixing with rtl:: in those places shouldn't be necessary, as further
above the file has a   using ::rtl::OUString;   directive.

>  if( ! aToken.compareToAscii( "pdf=", 4 ) )
>  {
>  sal_Int32 nPos = 0;
>  aDir = aToken.getToken( 1, '=', nPos );
> -if( ! aDir.Len() )
> -aDir = String( ByteString( getenv( "HOME" ) ), 
> osl_getThreadTextEncoding() );
> +if( aDir.isEmpty() )
> +aDir = rtl::OUString( getenv( "HOME" ), 4, 
> osl_getThreadTextEncoding() );

Trapped ;-)  The string isn't constructed of the word HOME, but the
content of the HOME environment variable instead, so assuming 4 here
isn't correct.

Besides that, already the original code didn't deal with a possible NULL
pointer returned by getenv() in case a HOME variable wasn't set at all..
that should be handled instead of relying on some OUString (back then
String) magic, which it seems OUString does not silently do and would
crash instead if a length >0 was passed.

Otherwise the patch looks good.

  Eike

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


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

Re: [Libreoffice] [MacOS] Starting dev-install is hairy

[James C]

Hi Stephen,

Probably not.  There is currently no soffice in my path (as determined
by which), and I don't think I've ever put anything in /Applications
into the path, because the mechanism for starting those does not rely
on it.

What now strikes me as more likely is:
  - each process from each version of LibreOffice cooperates with
other processes, so that only one LO process is running
  - (probably) the cooperation extends across versions
  - I don't recall whether I got a window, or only a change of current
application
  - I may have had a change to an already-running process from the other version
  - (probably) closing that to retry enabled me to have the version I wanted

There is a better bodge for unix-like (rather than Mac-like) resource
discovery; applescript can do 'set  to path to me', and
Automator can run pieces of applescript.  I don't know whether the
startup for an Xcode application can be a piece of applescript or not.

Regards,
James.

On Mon, Jan 2, 2012 at 11:38 PM, Stephan Bergmann  wrote:
> On 12/22/2011 08:33 AM, James C wrote:
>>
>>   - cd-ing into Contents/MacOS and running soffice, gives me
>> apparently the version installed in /Applications
>
>
> Did you call it as plain "soffice" (instead of "./soffice") so it picked the
> one from PATH?
>
> Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW-3-4-5] bug#36874 to be patched in 3.4.5 as well?

[Korrawit Pruegsanusak]

Hello Lubos,

On Tue, Jan 3, 2012 at 00:35, Lubos Lunak  wrote:
> On Monday 02 of January 2012, Petr Mladek wrote:
>> Winfried Donkers píše v Pá 23. 12. 2011 v 17:04 +0100:
>> > >Your code looks definitely better than the original one. Well, I am
>> > >still not sure about the calculation. It makes perfect sense when I
>> > >imagine the paper with blank labels. On the other hand,
>> > >please look at http://download.go-oo.org/tmp/labels.png.
>> >
>> > I looked at a lot of (blank) labels and also came to the conclusion that
>> > the definition of the labels leaves room for interpretation.
>> > My calculation is based on the assumption (presumption?) that the
>> > page containing the labels is symmetrical, i.e. rotating the page
>> > 180 degrees is not a problem, left margine equals right margin and
>> > top margin equals bottom margin.
>>
>> I see the point and agree with your assumption. Your patch makes sense
>> and I have pushed it to the 3-4 branch, see
>> http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id
>>=502ef71db74c3cdb1433c3402a0d93971dc47f1b
>>
>> We need two more approvals for the 3-4-5 branch.
>
>  Looks ok.

Just a reminder. As you are the third reviewer, could you please
cherry-pick it to 3-4-5?

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

[Libreoffice] bug 36874 (label printing) further improvement?

[Winfried Donkers]

(See bug 36874 (and this list) for history)

>> It would be much better if the label-definitions contain all dimensions, i.e.

>> should include either right margin and bottom margin or the page size.

>The visualization is crazy. It would be great to fix it.

>> For users, label printing is mostly troublesome, so any extra

>> user-friendliness of the application is a plus.



I am quite willing to further improve the labelprinting functionality by adding 
the page size to the label definitions and label-creation code, but I need 
someone who is willing to improve/change the UI (label wizard dialog) with me.

Anyone wanting to co-hack?



Winfried

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

Re: [Libreoffice] bug 36874 (label printing) further improvement?

[Rainer Bielefeld]

Winfried Donkers schrieb:

(See bug 36874 (and this list) for history)



I am quite willing to further improve the labelprinting functionality by
adding the page size to the label definitions and label-creation code,
but I need someone who is willing to improve/change the UI


Hello,

Ivan Timofeev was very active eliminating problems and improving GUI.

Ivan, what do you think? Are you interested?

Best regards

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

Re: [Libreoffice] [MacOS] Starting dev-install is hairy

[Stephan Bergmann]

On 01/03/2012 02:35 AM, James C wrote:

What now strikes me as more likely is:
   - each process from each version of LibreOffice cooperates with
other processes, so that only one LO process is running
   - (probably) the cooperation extends across versions
   - I don't recall whether I got a window, or only a change of current
application
   - I may have had a change to an already-running process from the other 
version
   - (probably) closing that to retry enabled me to have the version I wanted


Yes, that's another source of confusion.  Upon startup, an soffice 
instance tries to connect to a "named pipe" with a well-known name (and 
sets that pipe up in listening mode if it does not yet exist).  That 
way, only one instance will ever be running for a given installation. 
The well-known name contains (a hash of) the user installation path, so 
whenever two installations would share a user installation, they are 
connected in this way.  (See desktop/source/app/officeipcthread.cxx for 
details.)


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