Re: extraordinary stoc/ thrash ...

[Stephan Bergmann]

On 04/03/2012 11:13 PM, Tomas Hlavaty wrote:

Some time ago we discussed something along the lines of modernizing rdb
related code.

I wrote an IDL parser and the java generator unoidl2java is getting
almost complete.  I have a few small patches lined up but I'd like to
get the java generator as far as I can so that I get a good picture of
what is it all about.  After that I'd like to explore what would be the
best format for a new rdb registry; maybe binary, maybe text, maybe
preprocessed idl or preparsed somehow etc.


Great to hear.


but writing a duplicate, much simpler xml parser at a higher level to
read only the new XML .rdb files and whacking them straight into a
hash or two might be a nice easy-hack to have around :-)


I might be missing context here but haven't we discussed some time ago
(probably with Michael) that speed and size are crucial for the
registry?  XML might not look like a good idea then.


First of all, remember that we have two different scenarios where we 
want to replace the old binary rdb format with something else, once for 
type information and once for service information.


Second, in this context here (creating a service manager on top of the 
available service information at LO start up), it looks like the most 
expensive part is the nested XRegistry instances.  So that becomes the 
natural place to tackle first.  (The decision to replace the old binary 
rdb format with an XML format for service information was mostly born 
out of convenience.  In itself, it does not look especially problematic, 
performance-wise.  While this is certainly open for debate and 
inspection, I just don't think it is relevant for the problem at hand.)



I think the problem is not the XML parsing, but the nested XRegistry
list.


Does "nested XRegistry list" mean the registry structure mirroring the
symbol hierarchy of uno packages/classes?  Why is that a problem?


No.  The nesting (or linear list, rather) represents the various files 
from which service information is obtained.  (And one of the most 
important ones, LO's program/services/services.rdb tends to only come 
near the very end of that list.)



I have a vague idea of placing yet another cppuhelper bootstrap
mechanism next to the existing ones, which will internally use
completely different (read: cheap) mechanisms to set up a component
context and associated service manager.  That way, I would avoid most
of the hassle of having to whack improvements into a rotten framework.

I'll toy around with that in the next days/weeks.  Hang on...


Does it mean this would allow for easier switch to a different registry
format?  Or have you already settled on some specific format which would
be part of this another bootstrap mechanism?


The question of on-disk data format (for both type and service 
information) would be rather orthogonal to this work.  There's always a 
trade-off between simplicity (reading in all data from disk upfront, 
creating a complete in-memory model from it) and a potential performance 
gain (reading in data only when it becomes necessary; but that may be a 
fallacy: often enough, a large part of the data is necessary during 
bootstrap, anyway, and structuring the on-disk data for delayed access 
can have negative performance implications).  And that trade-off tends 
to influence the overall design somewhat.  But apart from that, these 
things should be pretty separate.


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

Re: [PATCH] fdo#39749: calc unit test writing

[Tor Lillqvist]

> Please check in your editor
> settings how to automatically replace tabs with 4 spaces.

Not always 4, but 1..4 spaces, the right number so that the following
character is at a multiple of four characters from the start of the
line.

Also, whether that is the correct thing to do for a source file that
has freshly been edited and had hardcoded TABs inserted depends on
what the tab stop setting in the editor was. If it was 8 (the
traditional Unix tab size), and the programmer has lined up
indentations of new and/or edited lines that now have TABs to match
existing code lines (without TABs), the newly inserted TABs should be
expanded to 1..8 spaces, of course, to retain the same visual
appearance.

Sure, you probably know the above and just over-simplified. But I
*have* seen some people understand the "replace tabs with 4 spaces"
mantra literally.

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

Re: [libreoffice-design] Android UI work

[Jonathan Aquilina]

I had looked at think free office, which I know doesnt support ODF but I 
am using it more for the UI look. What I noted is that it displays all 
the directories in ones devices.


I was thinking instead of doing that, When loading it would some how 
index the location of all files and just display all the files that the 
user can open with the program, with icons just as you mentioned to show 
which program will open them.


On 4/4/12 3:12 AM, Andrew Pullins wrote:

What do you mean by directory tree? Do you mean that view where you see the
icon of the document, doc name, when created, what type, and other info all
in one line? Because I hate that view in the desktop.  It's fine to offer
that for the people who want it for some reason. But the default view shoud
be large document previews with the type of doc icon in one of the corners,
and the name under it.
On Apr 3, 2012 1:40 PM, "Jonathan Aquilina"  wrote:


Christopher this is userful, but in a way you are jumping the gun here.

Tor and I discussed yesterday on a good place to start, and I agree with
him at this point its best to get something to where we can just open the
files.

As in my original email I am wondering if its worth making it easy for the
users to open the files by just providing them with a list of all files
that can be opened by LO instead of a file explorer that displays the
entire directory tree.

On 03/04/2012 19:37, Christopher Stark wrote:


Hi,

in November I sent this email with a link several suggestions concerning
a Android UI:

http://www.christopherstark.**de/extern/LO-Android/Android_**LO.html

Maybe it helps for the current discussion.

best regards
Christopher



 Original Message 
Subject:Suggestions for an Android User Interface
Date:   Wed, 09 Nov 2011 13:04:44 +0100
From:   Christopher Stark
To: des...@global.libreoffice.org



Hi,

I would like to make some suggestions for an Adroid UI of LibreOffice:

http://www.christopherstark.**de/extern/LO-Android/Android_**LO.html

Maybe I can put this into the LO-Wiki, but I'm not sure if that works
with regular html-code...

best regards
Christopher




--
Unsubscribe instructions: E-mail to 
design+help@global.**libreoffice.org
Problems? http://www.libreoffice.org/**get-help/mailing-lists/how-to-**
unsubscribe/
Posting guidelines + more: http://wiki.**documentfoundation.org/**
Netiquette
List archive: 
http://listarchives.**libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be
deleted




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

Re: [PATCH] fdo#39749: calc unit test writing

[Markus Mohrhard]

Hey,

2012/4/2 karthik padmanabhan :
> Hi ,
>
> I'm submitting a patch for the easy hack 39749. I have written one test that
> tests the RenameTable() function in ScDocFunc class

Pushed with some minor tweaks.

You have still tabs in your patch. Please check in your editor
settings how to automatically replace tabs with 4 spaces. For vim and
emacs you can use the modelines in the files.

I changed the test strings to a bit more neutral names. While I
normally would not care I think it makes things a bit more easy for
every one and nobody is offended.

See 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=62d745ddde6b60796123f45b3df8c10e9869

Anyway great work and I hope we'll see another patch soon ;)

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

Re: [PATCH] fdo#39749: calc unit test writing

[Markus Mohrhard]

Hey,

> just to get a feeling for string treatment:
>
> Could this
>
> + m_pDoc->InsertTab(0,
> rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Sheet1")));
> + m_pDoc->InsertTab(1,
> rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Sheet2")));
>
> (now having Lubos' patch) be written as
>
> + m_pDoc->InsertTab(0, rtl::OUString("Sheet1"));
> + m_pDoc->InsertTab(1, rtl::OUString("Sheet2"));
>

It can be even written without the explicit rtl::OUString instance
because there is an implicit conversion.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

minor grammaro in /download/

[Kevin Hunter]

Hullo List,

What's the correct venue to report something so minor as this typo?

As of 1:00am -0400 today, the current /download/ page on libreoffice.org 
has this text:


"Handy ressources"

My email client has kindly suggested 'resources' from its English 
dictionary.


Cheers,

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

Re: Fwd: Re: [PATCH][IN PROGRESS] gbuild conversion: module cpputools

[David Tardon]

On Wed, Apr 04, 2012 at 12:50:47AM +0200, David Ostrovsky wrote:
> Hi David,
> 
> thank you for your comments. Here is another try.
> As you haven't merged feature/gbuild_components branch to master
> I let "gb_Executable_add_api" in place:

Good,

I will look at the patch and push it (with appropriate changes) after I
have integrated the branch.

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

dal...@psykax.com changed:

   What|Removed |Added

 Depends on||46071

--- Comment #262 from dal...@psykax.com 2012-04-03 20:49:08 PDT ---
Adding bug 46071 - Upgrading from 3.4 to 3.5 breaks Math/Formula Editor

-- 
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: [PATCH] EasyHack Bug 46610

[Daniel Bankston]

Lubos Lunak wrote:
> Looks good to me, I only removed the return's at the end of function, as
> they 
> are superfluous in void functions. Pushed, thank you.

Oops, I guess I got too robotic in that respect when I was changing the
return statements.  Thanks.

> It seems to me you are correct. I've added !IsEmpty() check to the if(), 
> which should do what the original author wanted.

I'm still a little worried about that aClip object that is being intersected
with aRegion which is now on line 673 but was originally in the conditional
on the line below.  The reason I'm worried is because the aClip object is
used again on line 697.  I don't know if the original author knew that
he/she was intersecting aClip with aRegion on line 673.  So what I'm asking
is: Should we completely remove SetClipRegion( aClip ) on line 673?  Sorry
if you already considered that before when you replied and pushed the patch. 
Thanks.



--
View this message in context: 
http://nabble.documentfoundation.org/PATCH-EasyHack-Bug-46610-tp3879786p3883107.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: extraordinary stoc/ thrash ...

[Tomas Hlavaty]

Hi Stephan,

thanks for the very informative long post!

Some time ago we discussed something along the lines of modernizing rdb
related code.

I wrote an IDL parser and the java generator unoidl2java is getting
almost complete.  I have a few small patches lined up but I'd like to
get the java generator as far as I can so that I get a good picture of
what is it all about.  After that I'd like to explore what would be the
best format for a new rdb registry; maybe binary, maybe text, maybe
preprocessed idl or preparsed somehow etc.

>> but writing a duplicate, much simpler xml parser at a higher level to
>> read only the new XML .rdb files and whacking them straight into a
>> hash or two might be a nice easy-hack to have around :-)

I might be missing context here but haven't we discussed some time ago
(probably with Michael) that speed and size are crucial for the
registry?  XML might not look like a good idea then.

> I think the problem is not the XML parsing, but the nested XRegistry
> list.

Does "nested XRegistry list" mean the registry structure mirroring the
symbol hierarchy of uno packages/classes?  Why is that a problem?

> I have a vague idea of placing yet another cppuhelper bootstrap
> mechanism next to the existing ones, which will internally use
> completely different (read: cheap) mechanisms to set up a component
> context and associated service manager.  That way, I would avoid most
> of the hassle of having to whack improvements into a rotten framework.
>
> I'll toy around with that in the next days/weeks.  Hang on...

Does it mean this would allow for easier switch to a different registry
format?  Or have you already settled on some specific format which would
be part of this another bootstrap mechanism?

Thank you,

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

Re: [UX advise] Key navigation in ValueSet controls

[Matteo Casalin]

Hi all,
I just pushed my rework of ValueSet key navigation to master. Main 
differences from the old one are:

* No more vertical wrap-around
* Last item can be easily displayed also when on a shorter row
ALso, the general behavior should be more consistent. NoneItem, if 
present, is still selected by normal key navigation (no special keys).

Next steps: fix the code that handles item selection.

Looking forward to your feedback
Matteo

On 03/24/2012 12:31 AM, Cor Nouws wrote:

Matteo Casalin wrote (23-03-12 21:30)


On 03/21/2012 01:23 PM, Cor Nouws wrote:



One could say, that because in other locations using modifiers do make a
difference, it is good to have that here too, thus that unintended use
of the modifiers, while no specific function is linked to that use,
indeed results in nothing happening.


Sorry, I think I made a little confusion here saying "nothing happens":
in my previous mail those words meant "if page up/down are pressed while
holding a key modifier, then the highlighting box is not moved but stays
on the previously highlighted item", but it could also be understood as
"cursor is moved but no special action is taken".
So: should the current behavior (highlighting box does not move) be kept
or should the modifiers be neglected and the highlighting box move one
page up/down as if the unmodified page up/down where pressed? My feeling
is that the first solution is the desired one, but I would prefer to
have a final confirmation on this.


I agree with you.


I agree with always passing through the "none" item.


I think we should split this point in two:
* Should top/bottom wrap-around behavior be allowed? This is the
current solution, but honestly I find it somewhat confusing (columns
can be long and scrolling can be involved) and, from my understanding,
Astron already agreed to remove this "feature".


OK for me.


If this wrap-around
should be kept, then passing through NoneItem is required (unless we
find a specific key combination to select/deselect it).
* If we do not want this wrap-around, what should we do for NoneItem?


OK..


My original proposal involved moving first to the first item, from where
the NoneItem could be accessed (with up/left key-presses). This may be
too tricky.


Current behaviour (from your 1st mail) does not remind me of
difficulties while using:
* Home key move to the "none" item if present, to the first element
otherwise.
* End key moves to the last item.


Better approaches could be:
* NoneItem is accessed from:
* any item in the first row by pressing "up"
* the first item also by pressing "left"


I would prefer the current behaviour. I associate Home & End with that.


* NoneItem can be exited by pressing
* "down", which move to first item in the last selected column
* "right", which moves to the first item of the first column


I agree with that.


This would allow to alway move in nearby locations, with full control
on what is being done. I would exclude page up/down because NoneItem
cannot be considered part of a page and, moreover, I wouldn't be able
to say what's the correct target position for page down when in
NoneItem. For consistency with this, I would also exclude "home" and
"end", but I'm less strong biased on this.


So that opens the door to an agreement ;-)


This proposal is of course arguable and my approach is biased by my
programmer side (I prefer to avoid special cases).




* Return key behavior: at least it should not close the color
configuration window, but my guess is that's a misconfiguration of
the specific instance of ValueSet.


Not sure which window you are looking at (Tools > Options > General ->
Colors -> Edit ?) and what behaviour is odd.


Correct, the window is the one you pointed to. I find odd that pressing
"return" key while moving through the ValueSet items closes that window,
especially because during key-navigation items are highlighted with a
different border than the one used for selected ones: this would lead me
to press the "return" key to perform a selection, but that also closes
the window.


I agree that it is confusing. Quite often (always?) when in a
list/control where items can be selected, Alt-Return is needed to start
the OK button.
In other situations, just Return is sufficient.


Using TAB to move to the next widget could be a solution,
but it's not straightforward, IMHO, since in other instances of ValueSet
(color selection menus) return is a better choice for selection. While I
expect a menu to close on selection, I do not expect a window to do so.
ValueSet key-navigation code seems to offer two different ways of
handling return keys, depending on WB_NO_DIRECTSELECT configuration
flag, but I didn't investigate it deeply, yet.


OK, looks as in indicator in the direction of what users experience ;-)


Not entirely sure about this one, although probably most people would
want to use Return and Tab the same way (i. e. to get to the next
widget and select a colour).


When there is some select+clo

licence

[nlecureuil]

I forward this mail from one of my co workers :

Hi,

Up to the present we don't have objections about the adopted LO
licensing model, therefore we also can state:

All of the code contributed to LibreOffice owned by Mandriva both now
and in the future can be licensed under the MPL/LGPLv3+ dual license.


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

license

[Rafael Cabral]

Hi,

Up to the present we don't have objections about the adopted LO 
licensing model, therefore we also can state:


All of the code contributed to LibreOffice owned by Mandriva both now 
and in the future can be licensed under the MPL/LGPLv3+ dual license.



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

librO python & ssl support

[Laurent Godard]

Hi all

I need HTTPS connection and SSL support in my python extension

Unfortunatelly, it seems that python provided in libro 3.5.1 is not 
ready for this


$ /opt/libreoffice3.5/program/python
Python 2.6.1 (r261:67515, Mar  5 2012, 18:19:36)
[GCC 4.2.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
Traceback (most recent call last):
  File "", line 1, in 
  File "/opt/libreoffice3.5/program/python-core-2.6.1/lib/ssl.py", line 
60, in 
import _ssl # if we can't import it, let the error 
propagate
ImportError: libssl.so.4: cannot open shared object file: No such file 
or directory

>>>

Discussing on IRC, vmiklos (thanks to him) pointed me on
http://opengrok.libreoffice.org/xref/core/python/Python-ssl.patch

is it the patch to be applied to allow SSL support ?
does it cause any known trouble ?

i would like to do the job, trying to propose an additionnal patch (if 
needed) and target the 3.5.3 release.


would there be any patient mentor to help me starting (pointers, what to 
do aso)


Thanks in advance

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

Fwd: Re: [PATCH][REVIEW] gbuild conversion: module cpputools

[David Ostrovsky]

Hi David,

cpputools/prj/makefile.mk was missing in my patch, and this broke the 
build, fixed:


David

 Original Message 
Subject:Re: [PATCH][REVIEW] gbuild conversion: module cpputools
Date:   Mon, 02 Apr 2012 22:32:28 +0200
From:   David Ostrovsky 
To: David Tardon , libreoffice@lists.freedesktop.org



Hi David,

thank you for your comments. Here is another try.
As you haven't merged feature/gbuild_components branch to master
I let "gb_Executable_add_api" in place:

As you suggested the next modules to convert are:
idlc, l10ntools, rdbmaker, soltools, unodevtools

David

PS:
contribution notice.

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

On 01.04.2012 17:10, David Tardon wrote:

On Sun, Apr 01, 2012 at 04:32:16PM +0200, David Ostrovsky wrote:

Hi,

this patch convert cpputools module to gbuild


Hi, David,

it is a good start, but unfortunately not quite correct yet. See the
comments below.


 From f44e44974d14be4482f1676600b8b3c407f60684 Mon Sep 17 00:00:00 2001
From: David Ostrovsky
Date: Sun, 1 Apr 2012 16:24:31 +0200
Subject: [PATCH 2/2] gbuild conversion: cpputools module
+$(eval $(call gb_Executable_add_api,regcomp,\
+udkapi \
+))

That one is not obvious, but it is wrong anyway. The original makefile
uses headers generated with cppumaker -C, as to not require unoapi.rdb
at runtime. I am afraid you will have to wait a few days till
feature/gbuild_components is integrated into master. Then you should use
gb_Executable_add_internal_comprehensive_api .


+
+$(eval $(call gb_Executable_add_linked_libs,regcomp,\
+basegfx \

This is most certainly useless. I cannot imagine why would the regcomp
executable need a graphic library .-)

Another thing that is not obvious (and I think even documented anywhere
at libreoffice) is that we want the module integrated into the old build
system as well. To do that, just copy prj/makefile.mk from some already
converted module, remove all lines containing "nmake" from prj/build.lst
(actually I suppose that could be "everything but first two lines") and
add something like

pt  cpputools\prj   nmake   -   all pt_prj NULL

. Also remove content from prj/d.lst .

Also, after you are done, you can remove the now useless makefile.mk
files (except the one in prj, of course).

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



>From 5c55a9a05171e162e2f1c9398ba070988afc52e1 Mon Sep 17 00:00:00 2001
From: David Ostrovsky 
Date: Wed, 4 Apr 2012 00:39:38 +0200
Subject: [PATCH] gbuild conversion: cpputools module

dmake stuff removed
---
 cpputools/prj/makefile.mk |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 cpputools/prj/makefile.mk

diff --git a/cpputools/prj/makefile.mk b/cpputools/prj/makefile.mk
new file mode 100644
index 000..0997622
--- /dev/null
+++ b/cpputools/prj/makefile.mk
@@ -0,0 +1 @@
+.INCLUDE : gbuildbridge.mk
-- 
1.7.5.4

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

[Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|38067   |

-- 
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: RTL_CONSTASCII_(U)STRINGPARAM officially obsolete

[Eike Rathke]

Hi Lubos,

On Tuesday, 2012-04-03 18:17:27 +0200, Lubos Lunak wrote:

>  I've committed all changes related to the macros and all the different 
> tinderbox compilers have already compiled fine, so I consider the experiment 
> successful.

Great, thanks!

A big step towards more readable and less inconvenient to write code.

  Eike

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


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

RE: Question about Bug 33599

[Dézsi Szabolcs]

>I think I know where is the problem.

I think I know where the problem is. <- Sorry for the mistakes, i don't know 
why i make them :)
  ___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Question about Bug 33599

[Dézsi Szabolcs]

Hi all!

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

I think I know where is the problem. In 
sw/source/ui/docvw/SidebarTxtControl.cxx function SidebarTxtControl::LoseFocus. 
There's a call for mrSidebarWin.UpdateData(); In this function it checks 
whether there was any modification to the comment's text. We can see that the 
bug is only occuring if we press alt+tab after we changed the text.
Upon further inspection we can see that the bug is present because of a 
Broadcast call in SwAnnotationWin::UpdateData().
There's a comment written before the Broadcast line: 
'// #i98686# if we have several views, all notes should update their text'
Commenting out that Broadcast call, or the whole call for UpdateData() solves 
the issue. My question is: what is the purpose of this UpdateData call (or the 
broadcast)?

ps.: i tried without commenting out calls. I created a Point and saved the 
Cursor's Pos before UpdateData and loaded it back after that. Bug was still 
present (but don't know why)

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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on||40948

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

[Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|40948   |

-- 
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-design] Android UI work

[Jonathan Aquilina]

Christopher this is userful, but in a way you are jumping the gun here.

Tor and I discussed yesterday on a good place to start, and I agree with 
him at this point its best to get something to where we can just open 
the files.


As in my original email I am wondering if its worth making it easy for 
the users to open the files by just providing them with a list of all 
files that can be opened by LO instead of a file explorer that displays 
the entire directory tree.


On 03/04/2012 19:37, Christopher Stark wrote:

Hi,

in November I sent this email with a link several suggestions concerning
a Android UI:

http://www.christopherstark.de/extern/LO-Android/Android_LO.html

Maybe it helps for the current discussion.

best regards
Christopher



 Original Message 
Subject:Suggestions for an Android User Interface
Date:   Wed, 09 Nov 2011 13:04:44 +0100
From:   Christopher Stark
To: des...@global.libreoffice.org



Hi,

I would like to make some suggestions for an Adroid UI of LibreOffice:

http://www.christopherstark.de/extern/LO-Android/Android_LO.html

Maybe I can put this into the LO-Wiki, but I'm not sure if that works
with regular html-code...

best regards
Christopher




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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Tor Lillqvist]

OK, I re-introduced SAL_REINTERPRET_CAST.

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Noel Grandin]

Don't we have a macro for marking these kinds of things as deprecated?


> is there some macro that is defined by LO build system for which we can
> assume that nobody outside of LO uses it?  we could wrap the deprecated
> cruft in an #ifndef now, and remove it for LO4.
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Michael Stahl]

On 03/04/12 18:36, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Lubos Lunak wrote:
>> On Tuesday 03 of April 2012, Michael Meeks wrote:
>>> On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
 On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that
> can be binned outright.)

  Stuff from sal/ is public API, so you should not remove anything from
 there or you might break backwards compatibility for somebody (the fix
 is trivial here, but still).
>>>
>>> True, true - but pragmatically if you have an old extension, that you
>>> want to work on lots of older OpenOffice.org's / LibreOffices you'll
>>> want to build with an old SDK, since the new ones automagically require
>>> a newer LibreOffice.
>>
>>  Although this may seem like being overly pedantic, it's quite possible
>> that there is an extension that simply still uses the macro in the code
>> just as a relic of the past, even though otherwise it would have no problem
>> with recent SDK. And the cost in LO is leaving one simple macro in,
>> compared to a possibly massive search&replace.
> 
>  But the main thing I didn't say, it's easier to keep the mindset "SAL is 
> public API, so we don't break backwards compatibility there (unless possibly 
> really really necessary)", rather than "opengrok didn't find anything, I can 
> nuke it".

is there some macro that is defined by LO build system for which we can
assume that nobody outside of LO uses it?  we could wrap the deprecated
cruft in an #ifndef now, and remove it for LO4.

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Lubos Lunak]

On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Michael Meeks wrote:
> > On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > > (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that
> > > > can be binned outright.)
> > >
> > >  Stuff from sal/ is public API, so you should not remove anything from
> > > there or you might break backwards compatibility for somebody (the fix
> > > is trivial here, but still).
> >
> > True, true - but pragmatically if you have an old extension, that you
> > want to work on lots of older OpenOffice.org's / LibreOffices you'll
> > want to build with an old SDK, since the new ones automagically require
> > a newer LibreOffice.
>
>  Although this may seem like being overly pedantic, it's quite possible
> that there is an extension that simply still uses the macro in the code
> just as a relic of the past, even though otherwise it would have no problem
> with recent SDK. And the cost in LO is leaving one simple macro in,
> compared to a possibly massive search&replace.

 But the main thing I didn't say, it's easier to keep the mindset "SAL is 
public API, so we don't break backwards compatibility there (unless possibly 
really really necessary)", rather than "opengrok didn't find anything, I can 
nuke it".

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Lubos Lunak]

On Tuesday 03 of April 2012, Michael Meeks wrote:
> On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> > On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > > (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
> > > be binned outright.)
> >
> >  Stuff from sal/ is public API, so you should not remove anything from
> > there or you might break backwards compatibility for somebody (the fix is
> > trivial here, but still).
>
>   True, true - but pragmatically if you have an old extension, that you
> want to work on lots of older OpenOffice.org's / LibreOffices you'll
> want to build with an old SDK, since the new ones automagically require
> a newer LibreOffice.

 Although this may seem like being overly pedantic, it's quite possible that 
there is an extension that simply still uses the macro in the code just as a 
relic of the past, even though otherwise it would have no problem with recent 
SDK. And the cost in LO is leaving one simple macro in, compared to a 
possibly massive search&replace.

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Michael Meeks]

On Tue, 2012-04-03 at 17:52 +0200, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> > (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
> > be binned outright.)
> 
>  Stuff from sal/ is public API, so you should not remove anything from there 
> or you might break backwards compatibility for somebody (the fix is trivial 
> here, but still).

True, true - but pragmatically if you have an old extension, that you
want to work on lots of older OpenOffice.org's / LibreOffices you'll
want to build with an old SDK, since the new ones automagically require
a newer LibreOffice.

So - IMHO we shouldn't be overly concerned about this level of source /
API breakage as long as the ABI stays backwards compatible.

HTH,

Michael.

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

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

RTL_CONSTASCII_(U)STRINGPARAM officially obsolete

[Lubos Lunak]

 Hello,

 I've committed all changes related to the macros and all the different 
tinderbox compilers have already compiled fine, so I consider the experiment 
successful.

 As of now, there should be no need to use either of these macros. 
OString/OUString now have overloads that handle string literals, and string 
literals convert automatically to OString/OUString, which means it should be 
fine to just use string literals without any additional stuff.

 In other words, either of these

if (foo.equalsAsciiL(RTL_CONSTASCII_STRINGPARAM("X")))
if (foo.equals(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("X"

can be written as

if( foo == "X" )

, this

rtl::OUString foo(RTL_CONSTASCII_USTRINGPARAM("X"));

can be written simply as

rtl::OUString foo("X");

and

functionFoo( rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("X")))

can be written as

functionFoo( "X" );


 There are even more horrible multiline constructs in the code that can be 
converted to a simple one-liner, but I don't want to scare anybody :).


 I don't know if we want to encourage mass converts for this or create an Easy 
Hack, we have thousands of instances of the macros in the source, so this 
might lead to an unwanted flood.

 There are few small catches when writting new code or converting existing 
code:

- return "foo"; does not work for OUString return values 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41426)

- extern const char foo[]; (i.e. extern without a size given) does not work 
with MSVC (and it's probably allowed to reject that), but this should be very 
rare and can be fixed by converting to const char* const foo or specifying 
the size

- embedded \0 in string literals is undefined, it cannot be detected at 
compile time, but there will be runtime warnings. The reason for this is this

struct foo { const char s[ 3 ]; };
const foo foos[] = { "a", "bc" };

where foos[0] is actually "a\0" (i.e. 'a', '\0', '\0' ).


 On a somewhat related note, I've also added macro SAL_DEBUG, which is like 
SAL_INFO, except that it is meant in place of the usual debug-style printf() 
calls that some people put temporarily in the code while debugging. Moreover 
I've included rtl/oustringostreaminserter.hxx directly into rtl/ustring.hxx 
(hopefully I'm right that it won't break anything in practice), so if you now 
need to know what 'foo' is, just do

SAL_DEBUG( "foo is " << foo );

 The git commit hook will reject commits with these debug outputs left in 
code.


 I have also updated 
https://wiki.documentfoundation.org/Development/String_Classes accordingly.

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Lubos Lunak]

On Tuesday 03 of April 2012, Tor Lillqvist wrote:
> (SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
> be binned outright.)

 Stuff from sal/ is public API, so you should not remove anything from there 
or you might break backwards compatibility for somebody (the fix is trivial 
here, but still).

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

Re: GSOC 2012 , submitting a patch for easy hack

[kud360]

Thanks a lot :) :)  My first contribution :) Yeay ! ... 

I would now like to know about my project specification . I had written
a mail about this to Mr. Thorsten Behrens about this , but I received no
reply .. can someone please tell me a way to contact him ... I have some
ideas with me that i am presently working on... 

A slide changing app is ready with me that I made in java by emulating
keystrokes and hence using the generated arrow keystrokes ... I wanted to
know if libreoffice listens in on any-port .. if not I was wondering of how
hard would it be to start a daemon as a part of libreoffice to listen in on
network ports.

--
View this message in context: 
http://nabble.documentfoundation.org/GSOC-2012-submitting-a-patch-for-easy-hack-tp3872816p3881419.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Tor Lillqvist]

> Yes.

Done, https://bugs.freedesktop.org/show_bug.cgi?id=48253

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Stephan Bergmann]

On 04/03/2012 04:12 PM, Tor Lillqvist wrote:

And why do we test the OS here anyway, shouldn't we be testing the
compiler and perhaps compiler version?


We didn't have/know about such fancy macros back when the crude 
approximation OS => specific compiler worked oh so well for us.



Should this be simplified to always expand to the C++-style casts, and
then an Easy Hack added to do the expansion inline so that we can get
rid of the then pointless macros?


Yes.

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

Re: EasyHack, fdo#46808, Adapt UNO services to new style, Phase II

[Stephan Bergmann]

On 04/03/2012 03:11 PM, Noel Grandin wrote:

I'm working my way through the codebase, translating the easy stuff.
What is the cleanest translation of this:

Reference< graphic::XGraphicProvider > xGraphProv(
xFact->createInstance( C2U("com.sun.star.graphic.GraphicProvider")),
uno::UNO_QUERY_THROW );

Normally I would use

Reference< graphic::XGraphicProvider > xGraphProv(
graphic::GraphicProvider::create(xContext) );

But that doesn't throw an exception on error.


It does throw.  The constructors are guaranteed to either return a 
non-null reference or throw an exception (the default constructors all 
throw com.sun.star.uno.DeploymentException, which is derived from 
RuntimeException; explicit constructors can in principle also throw 
other exceptions).


So you'd probably also come across code like

  Reference x(...createInstance...);
  if (x.is()) { ... }

that you can simplify by using a constructor and removing the x.is() check.

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

Re: The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Noel Grandin]

Based on this:

noel@ubuntu:~/libo$ git grep const_cast | wc -l
1986
noel@ubuntu:~/libo$ git grep reinterpret_cast | wc -l
3944
noel@ubuntu:~/libo$ git grep static_cast | wc -l
21179

I think we can safely say that no-one cares about using those old compilers.



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


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

Re: Some extensions in daily build not work on Windows?

[Michael Meeks]

On Tue, 2012-04-03 at 20:53 +0700, Korrawit Pruegsanusak wrote:
> I'm not sure whether this is the correct list, sorry if not :-)

Yep - regressions on master vs. the last release are of interest to
hackers to catch quickly, so - certainly here is a good place :-)

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: [PUSHED][REVIEW 3-5] Re: build breaks - icu49 ?

[Eike Rathke]

Hi,

On Tuesday, 2012-04-03 15:08:41 +0200, Eike Rathke wrote:

> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=43084e8b30c101a44510b7a8267d5c2b316a17bb
> 
> Could you check if that works with your ICU 4.9 build and if so commit
> it to the 3-5 branch?

Needed some backporting love, still pushed with Tomáš' sign-off from
IRC, so beat me if I fouled anything up ;-)
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=ba3550bc82b8fb697b905c9913e399e1835b7cc0

  Eike

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


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

Android UI rework

[Jonathan Aquilina]

After the discussions yesterday and looking at some already existing 
apps, I think i have developed a plan to move forward with  being able 
to read and just open documents for starters.


I was thinking instead of providing the user with the whole Directory 
tree, what do you guys think of giving a file explorer, but that would 
search the system and just display all documents and file formats that 
can be opened by LO?

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

The C-style definitions of SAL_CONST_CAST and SAL_STATIC_CAST

[Tor Lillqvist]

In  we have:

/** Wrap C++ const_cast, reinterpret_cast and static_cast expressions in
macros to keep code portable to old compilers (since most compilers still
lack RTTI support, dynamic_cast is not included here).
 */
#ifdef __cplusplus
#if defined SAL_W32 || defined SOLARIS || defined LINUX || defined MACOSX || \
defined FREEBSD || defined NETBSD || defined AIX || \
defined OPENBSD || defined DRAGONFLY
#define SAL_CONST_CAST(type, expr) (const_cast< type >(expr))
#define SAL_REINTERPRET_CAST(type, expr) (reinterpret_cast< type >(expr))
#define SAL_STATIC_CAST(type, expr) (static_cast< type >(expr))
#else /* SAL_W32, SOLARIS, LINUX */
#define SAL_CONST_CAST(type, expr) ((type) (expr))
#define SAL_REINTERPRET_CAST(type, expr) ((type) (expr))
#define SAL_STATIC_CAST(type, expr) ((type) (expr))
#endif /* SAL_W32, SOLARIS, LINUX */
#endif /* __cplusplus */

Does the #else branch make any sense any more? Is there any OS for
which the #else branch would be needed? And why do we test the OS here
anyway, shouldn't we be testing the compiler and perhaps compiler
version?

Should this be simplified to always expand to the C++-style casts, and
then an Easy Hack added to do the expansion inline so that we can get
rid of the then pointless macros?

(The lack of ANDROID and IOS in the test is just an oversight, I will
add them there.)

(SAL_REINTERPRET_CAST is not used anywhere, says opengrok, so that can
be binned outright.)

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

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

[Fridrich Strba]

Thanks, Christina for doing wonderful job with the SVG stuff. I pushed
this one to master.

Cheers

Fridrich

On 01/04/12 21:29, Chr. Rossmanith wrote:
> Hi,
> 
> this patch is a correction for the calculation of transformation
> matrices for skewX and skewY. With the patch applied the SVG test file
> coords-trans-03-t.svg (opened with File->Open) is displayed nearly
> correctly, only text and a black marker is still missing.
> 
> Christina
> 
> 
> 
> 
> ___
> 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

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

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

Bug 37361 depends on bug 47406, which changed state.

Bug 47406 Summary: Almost all graphics that have internal circuits are not 
rending correctly.
https://bugs.freedesktop.org/show_bug.cgi?id=47406

   What|Old Value   |New Value

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

Some extensions in daily build not work on Windows?

[Korrawit Pruegsanusak]

Hello all,

I'm not sure whether this is the correct list, sorry if not :-)

I notice that in daily build for Windows, three extensions are not
shown in Extension Manager, maybe actually not working.
Bug report at https://bugs.freedesktop.org/show_bug.cgi?id=48243

All 3 problematic extensions are in sdext/ ...
Might be related to gbuild-ing this module?

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

fdo #36946 -- categories for slide transitions in impress -- where to implement categorisation

[Andrzej J. R. Hunt]

Hi,

I'm currently working on adding categories to the transitions viewable 
in the Impress GUI (https://bugs.freedesktop.org/show_bug.cgi?id=36946).


I'm not sure how best to assign categories to the transitions. The list 
of transitions is in xml/transitions.xml, which is loaded by 
source/core/TransitionPreset.cxx. Initially I used the transition-type 
(mnTransition) as the category, which does work, but results in too many 
categories, many of which should be joined into one. Therefore I'd like 
to create new UI categories, but don't know where I should do this.


I could assign the categories directly in the transitions.xml file 
(which would require some changes to the code importing this file, 
including changes in xmloff), or I could write a new method in the 
TransitionPreset class that contains a list of which transition types 
map to which UI categories (much simpler to write, but less elegant in 
the case that someone adds more transitions to the file).


Which of these options should I choose, or is there a better way that I 
could do this?


Cheers,

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

EasyHack, fdo#46808, Adapt UNO services to new style, Phase II

[Noel Grandin]

Hi

I'm working my way through the codebase, translating the easy stuff. 
What is the cleanest translation of this:


Reference< graphic::XGraphicProvider > xGraphProv(
xFact->createInstance( 
C2U("com.sun.star.graphic.GraphicProvider")), uno::UNO_QUERY_THROW );


Normally I would use

Reference< graphic::XGraphicProvider > xGraphProv( 
graphic::GraphicProvider::create(xContext) );


But that doesn't throw an exception on error.

Is there a utility method I'm not aware of, or should I restructure the 
surrounding code to work without exceptions?


Thanks, Noel Grandin

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


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

Re: [PATCH] fdo#39749: calc unit test writing

[Chr. Rossmanith]

Hi,

just to get a feeling for string treatment:

Could this

+   m_pDoc->InsertTab(0, 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Sheet1")));
+   m_pDoc->InsertTab(1, 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Sheet2")));

(now having Lubos' patch) be written as

+   m_pDoc->InsertTab(0, rtl::OUString("Sheet1"));
+   m_pDoc->InsertTab(1, rtl::OUString("Sheet2"));

?

Christina

Am 02.04.2012 21:55, schrieb karthik padmanabhan:

Hi ,

I'm submitting a patch for the easy hack 39749. I have written one 
test that tests the RenameTable() function in ScDocFunc class


Thanks and Regards
Karthik


___
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: [REVIEW 3-5] Re: build breaks - icu49 ?

[Eike Rathke]

Hi Tomáš,

On Tuesday, 2012-04-03 00:54:22 +0200, Eike Rathke wrote:

> http://cgit.freedesktop.org/libreoffice/core/commit/?id=43084e8b30c101a44510b7a8267d5c2b316a17bb

Could you check if that works with your ICU 4.9 build and if so commit
it to the 3-5 branch?

Thanks
  Eike

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


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

[PUSHED] Re: [PATCH] fdo#46390: EasyHack: Move VERBOSE to OSL_DEBUG_LEVEL

[Jan Holesovsky]

Hi Rob,

On 2012-04-03 at 00:07 +0200, Rob Snelders wrote:

> I have created 2 little patches. The first one is to start on the bug 
> fdo#46390.
> The other patch solves also some build-errors I got when turning on the 
> debug-mode. Also is rRequestData removed. It isn't defined in the class 
> as far as I can see. It should be the aKey because that holds the SdrPage.

Pushed, thank you! :-)

Regards,
Kendy

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

Re: Who can tell me more about SfxToolBoxControls and registerControl()?

[Jan Holesovsky]

Hi Winfried,

On 2012-04-03 at 10:08 +0200, Winfried Donkers wrote:

> The 'split button' is a derived SfxToolBoxControl which triggers an
> Execute function when the colour is chosen from the colour palette and
> triggers a virtual Select function when the left half of the button
> (last used colour) is clicked. According to a comment
> in /core/sfx2/inx/sfx2/tbxc.hxx (line 179-185) RegisterControl must be
> used for extra functionality (such as the split button uses).
> 
> The absence of RegisterControl may well be the cause of the problems I
> encounter (the afore-mentioned font color in reportdesign does not
> call registerControl), but I don't understand how and where to apply
> RegisterControl correctly. 
> 
> (the font color button in reportdesign is
> in /core/reportdesign/source/ui/misc/toolboxcontroller.cxx )
> 
>  
> 
> Who can give me advise and or hints?

git grep advises that they are in the factory functions like
SwDLL::RegisterControls() in sw/source/ui/app/swmodule.cxx; so in the
case of the report designer, I'd call it somewhere where it is
instantiated - one of the create() methods listed in
reportdesign/source/ui/misc/rptuiservices.cxx, probably.

But haven't actually tried that - so please report back if this leads to
a dead end.

Regards,
Kendy


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

Re: extraordinary stoc/ thrash ...

[Stephan Bergmann]

On 04/03/2012 01:57 PM, Michael Meeks wrote:

On Tue, 2012-04-03 at 10:41 +0200, Stephan Bergmann wrote:

That way, you have a chance of surviving the process.  But you also
pile up guilt.


Lol :-) well, we managed to keep it going, despite the guilt pile
somehow :-) I guess in this case we'll hack something evil, but writing
a duplicate, much simpler xml parser at a higher level to read only the
new XML .rdb files and whacking them straight into a hash or two might
be a nice easy-hack to have around :-)


I think the problem is not the XML parsing, but the nested XRegistry list.

I have a vague idea of placing yet another cppuhelper bootstrap 
mechanism next to the existing ones, which will internally use 
completely different (read: cheap) mechanisms to set up a component 
context and associated service manager.  That way, I would avoid most of 
the hassle of having to whack improvements into a rotten framework.


I'll toy around with that in the next days/weeks.  Hang on...


Yes - roll on LibreOffice4 :-) I'm hoping that LO 3.7 should be 4.0
but ... ;-) need to discuss that at more length.


Yep.

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

[PUSHED]Re: [PATCH] EasyHack Bug 46610

[Lubos Lunak]

On Tuesday 03 of April 2012, Lubos Lunak wrote:
> On Tuesday 03 of April 2012, Daniel Bankston [danthedev] wrote:
> > Hello, everyone,
> >
> > I have attached my patches for EasyHack Bug 46610.
>
>  Looks good to me, I only removed the return's at the end of function, as
> they are superfluous in void functions. Pushed, thank you.

 Adding [PUSHED].

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

Re: extraordinary stoc/ thrash ...

[Michael Meeks]

Hi Stephan,

On Tue, 2012-04-03 at 10:41 +0200, Stephan Bergmann wrote:
> Yes, this is indeed a bit of a tragedy.  The relevant UNO types and 
> services bootstrapping code is very old, and concepts are tightly knit 

Thanks for your lovely detailed write-up, I'm just editing it into the
stoc/README, hopefully it'll do some good there.

> That way, you have a chance of surviving the process.  But you also
> pile up guilt.

Lol :-) well, we managed to keep it going, despite the guilt pile
somehow :-) I guess in this case we'll hack something evil, but writing
a duplicate, much simpler xml parser at a higher level to read only the
new XML .rdb files and whacking them straight into a hash or two might
be a nice easy-hack to have around :-)

> I guess I'll have to have a look at that mess once more (and hopefully 
> for the last time). -- We need to get started with our journey to LO 4 
> dreamland anyway, I'd say.

Yes - roll on LibreOffice4 :-) I'm hoping that LO 3.7 should be 4.0
but ... ;-) need to discuss that at more length.

All the best,

Michael.

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

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

Re: [PATCH] EasyHack Bug 46610

[Lubos Lunak]

On Tuesday 03 of April 2012, Daniel Bankston [danthedev] wrote:
> Hello, everyone,
>
> I have attached my patches for EasyHack Bug 46610.

 Looks good to me, I only removed the return's at the end of function, as they 
are superfluous in void functions. Pushed, thank you.

> I identified that the return value of Intersect was being used in
> vcl/source/edit.cxx::673 in a conditional.  I re-factored the code so
> that the conditional did not use the return value but still called
> Intersect so as to not affect the original functionality.  However, I
> wonder if the original author misunderstood what this Intersect method
> actually does.  Maybe being mislead by the return type, the author's
> intent was to check if these Regions intersected instead of combining
> the regions (which is what I believe these methods actually do)?  This
> usage should probably be checked by someone more knowledgeable and
> experienced than me.  Maybe it is nothing, but it is probably worth
> checking to be sure.

 It seems to me you are correct. I've added !IsEmpty() check to the if(), 
which should do what the original author wanted.

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

Re: extraordinary stoc/ thrash ...

[Michael Meeks]

Hi Enrico,

On Tue, 2012-04-03 at 11:04 +0200, Enrico Weigelt wrote:
> > Yes, this is indeed a bit of a tragedy.  The relevant UNO types and
> > services bootstrapping code is very old, and concepts are tightly
> > knit together there, and whenever you want to change something you risk
> > backwards incompatibility. 
> 
> Backwards compatibility to whom ? Binaries ? Source ? User data ?

Extensions. You know the things you don't like and don't believe should
exist :-)

> Perhaps it could make sense to design a new interface and step by step
> get rid of the old one ?

It is worth considering the expense of answering questions before
asking too many of them. Do you intend to make a difference to the code
around this area ? if so, that would be excellent, and I'm happy to help
out.

What needs doing is (usually) somewhat obvious, as is your
suggestion :-) The only missing piece is the manpower to do it. By
asking dozens of questions without any intention to work on something
you consume the scarce resource necessary to fix it: man-power. That
makes sense only if you intend to contribute code to improve the
situation :-)

Do you ? :-)

All the best,

Michael.

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

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

Re: [PUSHED] Some String replacements in starmath

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

done

Em 03-04-2012 07:08, Michael Meeks escreveu:
> Hi Olivier,
> 
>   Looks lovely - do push such nice but simple patches yourself without
> review :-)
> 
>   ATB,
> 
>   Michael.
> 

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

iQEcBAEBAgAGBQJPetdwAAoJEJp3R7nH3vLx9coH/RZtnBTzqj94APqNDh4Inx5M
ffTj2cyqA22XEJvNV80nuOvdFt+uHean5d41fuWK7uaNIKEETm3NYM2pjU0Pd6aM
1KLCwu2mDKNGXUiGQAvZhnMPVbcdx8f0jqMYUlY9VUKwnZKSeYaOafD1Tw5Ec8Zg
lhLe0XT9eZD/5u9ICq7ug18TJY9SdvGf9amI/DWQtGP4M7Yg6gZlZ3LHnRh+2H+/
YjEB8EpwWi+SNthkoMD6VEtvAF+y6YAfniG4vf126JSCWkH55XoklOE4Al1TVXwQ
HCImfgDHIlj56Y1ccvu0Txjx/nlZYZFtWAxItV7lFFC6VYVcKDKOORkrNDL10ps=
=bE0y
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 35673] LibreOffice 3.4 most annoying bugs

[bugzilla-daemon]

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

Bug 35673 depends on bug 36482, which changed state.

Bug 36482 Summary: PDF EXPORT Options dialog  missing - in relation with user 
profile of previous (...) version
https://bugs.freedesktop.org/show_bug.cgi?id=36482

   What|Old Value   |New Value

 Resolution||WORKSFORME
 Status|NEW |RESOLVED

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

Re: [PATCH] Some String replacements in starmath

[Michael Meeks]

Hi Olivier,

Looks lovely - do push such nice but simple patches yourself without
review :-)

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: Need help in UNO

[Dézsi Szabolcs]

> uhm... i'm not that familiar with drawing layer stuff, but there are 2
> different kinds of images in Writer, one is directly implemented in
> Writer, and the other is from svx/drawing objects (and thus works the
> same way in all applications).  each of these 2 different kinds of
> images has features that the other lacks, so if your plan is to convert
> from one to the other in order to get the ability to rotate then there
> is a real chance that this will break some existing use-case, and i
> don't really think adding this to the default LO UI makes sense.
> 
> the real solution for this would be to add the missing functionality to
> the svx drawing objects and then remove the Writer specific images.
> AFAIK Armin and Oliver-Rainer actually did substantial work in that
> direction in some OOo CWS, but alas they have had to waste their time
> removing features whose license their new employer doesn't like from
> ApacheOO during the last year...

Hi, you are right. The extension which manages to solve this creates a Hidden 
draw document, copies and pastes the selected picture with a unique name 
("Bild_" + actual date), copies it back to Writer, iterates in drawPage 
searching for the image with the unique name and uses its RotateAngle property 
to change rotation (because now it has RotateAngle <- effect of the 
Writer->Draw->Writer copy)

I don't think this is a very pretty solution. For instance my patch added a 
menuitem to the rightclick menu of the images (which can't be rotated by 
default), but this is wrong, because if i do this whole Writer->Draw->Writer 
copy, then the image type changes and the rotate menuitem won't show after 
first rotation. We can see this behavior by using OpenOffice Toolbox and 
rotating by x degrees.

So what I want to say, that this whole 'Rotate option in the Right click menu' 
was a wrong approach. This really requires deeper changes in Writer.

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

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

[Michael Meeks]

On Tue, 2012-04-03 at 00:54 +0200, Eike Rathke wrote:
> Hmm.. a year ago Martin Hosken introduced char.txt and commented out the
> use of SpacingMark and Prepend according to UAX #29 updates, along with
> changes in breakiterator script identification. So we already have the
> changed behavior since then. It seems that so far no Thai user
> complained

It should prolly be noted that (IIRC) Martin reads/writes/speaks Thai
(and I guess Northen Thai too ;-) - so if it's good for him ... ;-)

ATB,

Michael.

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

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

[PUSHED] Re: [REVIEW:3-5] fdo#46955 fix RTF import of all capitals char prop

[Michael Stahl]

On 03/04/12 11:22, Miklos Vajna wrote:
> Hi,
> 
> See
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=04cae9ec1e1f04833b06fe9f24e23cfaf5265599
> 
> Trivial patch, regression from 3.4. I'm attaching a backport to 3.5, as
> we don't have a testsuite there.

pushed to libreoffice-3-5

http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=05fde8006966df49221871fe3489aba8c2ca8e3f

oops, managed to forget to add a Signed-off-by...


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

[REVIEW:3-5] fdo#46955 fix RTF import of all capitals char prop

[Miklos Vajna]

Hi,

See
http://cgit.freedesktop.org/libreoffice/core/commit/?id=04cae9ec1e1f04833b06fe9f24e23cfaf5265599

Trivial patch, regression from 3.4. I'm attaching a backport to 3.5, as
we don't have a testsuite there.

Thanks,

Miklos
>From 13ea3153a56cc028b6de4c340449caff1283e063 Mon Sep 17 00:00:00 2001
From: Miklos Vajna 
Date: Sat, 24 Mar 2012 17:14:12 +0100
Subject: [PATCH] fdo#46955 fix RTF import of all capitals char prop

---
 writerfilter/source/rtftok/rtfdocumentimpl.cxx |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.cxx b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
index d5d8ee6..ef4d3b8 100644
--- a/writerfilter/source/rtftok/rtfdocumentimpl.cxx
+++ b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
@@ -2770,6 +2770,7 @@ int RTFDocumentImpl::dispatchToggle(RTFKeyword nKeyword, bool bParam, int nParam
 case RTF_STRIKED: nSprm = NS_sprm::LN_CFDStrike; break;
 case RTF_SCAPS: nSprm = NS_sprm::LN_CFSmallCaps; break;
 case RTF_IMPR: nSprm = NS_sprm::LN_CFImprint; break;
+case RTF_CAPS: nSprm = NS_sprm::LN_CFCaps; break;
 default: break;
 }
 if (nSprm >= 0)
-- 
1.7.7

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

Re: Need help in UNO

[Michael Stahl]

On 02/04/12 23:11, Miklos Vajna wrote:
> On Mon, Apr 02, 2012 at 08:20:18PM +0200, Dézsi Szabolcs 
>  wrote:
>>> Not sure if you noticed that the RotationDescriptor service is
>>> deprecated, just in case you plan to spend too much time on it. ;)
>>
>>
>> Yes, I noticed it, I think I have to use Transformation (?).
>>
>> This is just a test to see if I can do it with RotateAngle (like in 
>> extension), after that I can use Transformation (I hope).
> 
> Hi Szabolcs,
> 
> Indeed, which API you use is irrelevant at the moment. :)
> 
> Seems your problem is that the extension first converts the picture
> frame (SwXTextGraphicObject) to an SwXShape (you can see the position of
> the shape is changed - though probably that's an accident), and then it
> sets the RotationAngle property, since that object will have that
> property then.
> 
> Check how that conversion is done in the extension, then you can do
> something similar in SwGrfShell::Execute().

uhm... i'm not that familiar with drawing layer stuff, but there are 2
different kinds of images in Writer, one is directly implemented in
Writer, and the other is from svx/drawing objects (and thus works the
same way in all applications).  each of these 2 different kinds of
images has features that the other lacks, so if your plan is to convert
from one to the other in order to get the ability to rotate then there
is a real chance that this will break some existing use-case, and i
don't really think adding this to the default LO UI makes sense.

the real solution for this would be to add the missing functionality to
the svx drawing objects and then remove the Writer specific images.
AFAIK Armin and Oliver-Rainer actually did substantial work in that
direction in some OOo CWS, but alas they have had to waste their time
removing features whose license their new employer doesn't like from
ApacheOO during the last year...

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

Re: extraordinary stoc/ thrash ...

[Michael Meeks]

Hi Enrico,

On Tue, 2012-04-03 at 05:15 +0200, Enrico Weigelt wrote:
> > What would be ultimately nice would be to rid ourselves of this
> > XRegistry 'stuff' and have a simple XML file, read into some simple
> > structures, and added to a couple of hashes for the common lookup
> > patterns we want. Is there any chance of doing that separately, so we
> > can sever the back-compatible .rdb reading for LibreOffice 4 mostly
> > by code removal ?
> 
> Maybe that XML file could even be mmap'ed, just having the index on
> heap.

mmapping is the least of our worries wrt. memory use and load
performance (read Stephan's nice write-up) :-) if we're truly worried
about the page-cache we could f/madvise DONTNEED after parsing; only if
we wanted to deal better with many concurrent processes touching the
same data would we mmap it; and then we'd need to switch to UTF-8
strings internally - and of course be rather vulnerable to SIGBUS'

>  Depending on the actual structure and access patterns, the
> whole thing could also be splitted into several files, and just use
> the filesystem hierachy as index.

Sure - but then we loose wrt. seek time on cold starts :-)

> Do you already have some ideas how that XML file would look like ?

Checkout services.rdb in the install; again do you actively want to
work on this ? or are you just offering the benefit of your insight ?

Regards,

Michael.

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

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

Re: extraordinary stoc/ thrash ...

[Enrico Weigelt]

Hi,

> Yes, this is indeed a bit of a tragedy.  The relevant UNO types and
> services bootstrapping code is very old, and concepts are tightly
> knit together there, and whenever you want to change something you risk
> backwards incompatibility. 

Backwards compatibility to whom ? Binaries ? Source ? User data ?

> At the heart of the matter there is the old binary "store" file
> structure and the XRegistry interface on top of it.  At runtime, both
> all the UNO type information (scattered across a number of binary rdb
> files) and all the UNO service information (scattered across a number
> of rdb files that used to be binary but have been mostly changed to XML
> now) are represented by a single XRegistry instance each.

What kind of data do these files hold ?
Is that data somewhat changed after build or does it remain constant ?

> The way the respective information is represented in the XRegistry
> interface simply corresponds to the way the information is stored in
> the binary rdb files.

How is that data structured ? How is it accessed, by whom ?
It is ro or rw data ?

Perhaps it could make sense to design a new interface and step by step
get rid of the old one ?

> Hence, for example information about a UNO interface type
> com.sun.star.foo.XBar is stored in a nested "folder" with path
> com - sun - star - foo - XBar, containing little blobs of information
> about the type's ancestors, its methods, etc. 

Does that type name necessarily have to have path semantics, or
would a "flat" string key also be fine ?

> As there are typically multiple rdb files containing types resp.
> services (URE specific, LO specific, from extensions, ...), but they
> need to be represented by a single XRegistry instance, so "nested
> registries" were invented.  They effectively form a linear list of
> chaining XRegistry instances together.  Whenever a path needs to be
> looked up in the top-level registry, it effectively searches through
> the linear list of nested registries.

Does this nested XRegistry have mounting or union semantics ? Or both ?
Can we compile that splitted registry into a big one ?

> When I introduced XML service rdbs, I sort of chickened out (see
> above for rationale) and put them behind an XRegistry facade, so that they
> would seamlessly integrate with the existing mess.  I postponed
> systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once
> we'll become incompatible with OOo," as the phrase used to be back then).

Which kind of incompatibility would happen exactly ?


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

Re: extraordinary stoc/ thrash ...

[Stephan Bergmann]

On 04/02/2012 11:06 PM, Michael Meeks wrote:

Digging through the string logs, trying to make sense of the extremely
intense thrash around this SINGLETON/ stuff, I was curious to get rather
deep stacks, cf. appended trace.

AFAICS the purpose of this code is mostly to turn a pretty simple,
pretty flat XML structure, into a simple list of singletons that we can
then whack into a hash table somewhere else.

Is all this heavy-lifting really necessary for that ? it seems just a
little intense :-)

I'm also curious if the performance issue here (this code features
reasonably high on a startup profile IIRC) might be related to the
multiple '.rdb' file code (?).


Yes, this is indeed a bit of a tragedy.  The relevant UNO types and 
services bootstrapping code is very old, and concepts are tightly knit 
together there, and whenever you want to change something you risk 
backwards incompatibility.  The code causes mental pain, and whenever 
you need to touch it you want to run away screaming.  One typically ends 
up doing minimally invasive changes.  That way, you have a chance of 
surviving the process.  But you also pile up guilt.


At the heart of the matter there is the old binary "store" file 
structure and the XRegistry interface on top of it.  At runtime, both 
all the UNO type information (scattered across a number of binary rdb 
files) and all the UNO service information (scattered across a number of 
rdb files that used to be binary but have been mostly changed to XML 
now) are represented by a single XRegistry instance each.


The way the respective information is represented in the XRegistry 
interface simply corresponds to the way the information is stored in the 
binary rdb files.  Those files are designed for storage of 
hierarchically nested small blobs of information.  Hence, for example 
information about a UNO interface type com.sun.star.foo.XBar is stored 
in a nested "folder" with path com - sun - star - foo - XBar, containing 
little blobs of information about the type's ancestors, its methods, 
etc.  Similarly for information about instantiable services like 
com.sun.star.baz.Boz.


As there are typically multiple rdb files containing types resp. 
services (URE specific, LO specific, from extensions, ...), but they 
need to be represented by a single XRegistry instance, so "nested 
registries" were invented.  They effectively form a linear list of 
chaining XRegistry instances together.  Whenever a path needs to be 
looked up in the top-level registry, it effectively searches through the 
linear list of nested registries.  All with the cumbersome UNO XRegistry 
interface between the individual parts.  Horror.


When I introduced XML service rdbs, I sort of chickened out (see above 
for rationale) and put them behind an XRegistry facade, so that they 
would seamlessly integrate with the existing mess.  I postponed 
systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once we'll 
become incompatible with OOo," as the phrase used to be back then).


So, while the situation is catastrophic, I do not think it has become 
significantly more catastrophic in recent times.  It can well have 
gradually degraded, though.  For example, each types or services rdb 
that is added into the game makes the corresponding linear list of 
nested registries longer.  And I wouldn't be surprised if some of the 
XRegistry-nesting nonsense causes overhead that is effectively quadratic 
in the length of that linear list...


This Gordian knot is not easily slain, however.  As I said, things are 
tightly knit.  Of the various bootstrapping methods offered by 
cppuhelper, some even offer not to distinguish among types and services 
rdbs -- you could lump everything together, and the code would sort out 
the mess, through enquiries of the uniform XRegistry interface.


I guess I'll have to have a look at that mess once more (and hopefully 
for the last time). -- We need to get started with our journey to LO 4 
dreamland anyway, I'd say.


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

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

[Tor Lillqvist]

> Okay. Do situations where std::string doesnt suffice happen that often,
> that we need to OUString virtually everywhere ?

You aren't telling us anything we don't know already. Sure, stopping
using UTF-16 strings in situations where it is just ASCII anyway that
is handled is one thing we want to investigate doing eventually. Or
moving to UTF-8 strings even. We are not suffering from a lack of good
(or even crazy) ideas. But ideas are not trivial to implement.

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

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

[Enrico Weigelt]

> > Just curious: what's the big difference between rtl::OUString and
> > std::string ?
> 
>  http://lists.freedesktop.org/archives/libreoffice/2012-March/028485.html
>  (and
> click the next message link a couple of times).

Okay. Do situations where std::string doesnt suffice happen that often,
that we need to OUString virtually everywhere ?

I imagine lots of situations where even const char* is really enough.

> I doubt any compiler we use treats std::string specially, I'd expect
> it's a normal class for it just like any other.

Honstly, I don't know. But I think it's certainly possible.
That would be one of the first thing I tried when I wanted to write
an good optimizing compiler.


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

Who can tell me more about SfxToolBoxControls and registerControl()?

[Winfried Donkers]

Hello all,

I am struggling a bit to get various colour buttons (e.g. 
font/background/border colour) working as split buttons, so that the last used 
colour can be applied again right away. See fdo45671 for more details on the 
specific buttons/wishes.

For a lot of buttons I have succeeded to convert them to split buttons, for 
some other buttons I encounter problems. The button on the toolbar is of type 
split button (two buttons in one), but the left part of the button (use last 
used colour) does not work An example, that is present since before my 
interferences is the font color in reportdesign (base).

The 'split button' is a derived SfxToolBoxControl which triggers an Execute 
function when the colour is chosen from the colour palette and triggers a 
virtual Select function when the left half of the button (last used colour) is 
clicked. According to a comment in /core/sfx2/inx/sfx2/tbxc.hxx (line 
179-185)
 RegisterControl must be used for extra functionality (such as the split button 
uses).
The absence of RegisterControl may well be the cause of the problems I 
encounter (the afore-mentioned font color in reportdesign does not call 
registerControl), but I don't understand how and where to apply RegisterControl 
correctly.
(the font color button in reportdesign is in 
/core/reportdesign/source/ui/misc/toolboxcontroller.cxx
 )

Who can give me advise and or hints?



Winfried

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

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

[Lubos Lunak]

On Tuesday 03 of April 2012, Enrico Weigelt wrote:
> Hi,
>
> >  I don't want to spoil the fun much for you :) , but I expect the
> >  number of
> > string allocations to go down when RTL_CONSTASCII_* stops being used
> > in favor
> > of string literals, and further down after whenever I get to
> > implementing the
> > efficient operator+. So you may be profiling a problem for a part of
> > which a
> > solution already exists.
>
> Just curious: what's the big difference between rtl::OUString and
> std::string ?

 http://lists.freedesktop.org/archives/libreoffice/2012-March/028485.html (and 
click the next message link a couple of times).

> I guess a good toolchain (compiler+stdlibs) can do a lot of optimizations,
> which it cannot with an own implementation. For example, if we have lots
> of static strings (literals, or statically initialized and const
> std::string objects), it could put them all together into one instance in
> const data section.

 I doubt any compiler we use treats std::string specially, I'd expect it's a 
normal class for it just like any other.

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

Re: extraordinary stoc/ thrash ...

[Enrico Weigelt]

> Or, for files that are static in a distributed LO (i.e. not modified
> at installation. even less at run-time), process them into source
> code that set up the structures as much as possible at compile-time
> already?

Even better!

There seems to be a lot currently dynamic data, that could be
directly compiled-in (landing .text or .cdata section) and so
save a lot runtime overhead.

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

Re: [PUSHED] Fix RTF list level text follow

[Miklos Vajna]

On Mon, Apr 02, 2012 at 07:43:11AM -0700, Brennan T Vincent 
 wrote:
> You are correct, of course. I had added those lines before I fully
> understood how the code worked, and forgotten to remove them. I have
> updated my patch and formatted it correctly.

Pushed, thanks for this!

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