Re: [Libreoffice] comments translated in writer\sw\source\core\edit\edfmt.cxx
On Mon, Dec 27, 2010 at 12:49 PM, TentleXS tentl...@web.de wrote:
Hallo @all,
my name is Pascal and I would like to contribute the following
translated code comments in writer\sw\source\core\edit\edfmt.cxx. My
native language is german so I hope it's OK that I did the translation.
Hi Pascal,
Welcome to LibreOffice dev.
A translation by a native german speaker is mst welcome.
I am learning the workflow for contributing, so please excuse me if I
did something wrong.
You did it right.
to make it perfect you could do this:
http://wiki.documentfoundation.org/Development#Preparing_patches
The reason for this is that git format-patch contain all the
authorship information as you want them to be.
It is also nice to suffix the patch file name with the repository
name, so it is a no-brainer for the commiter to know on which repo
this patch apply (for instance sw is in the 'writer' repo, so the
patch filename should look something like 0001-xxx.writer.patch)
I am glad if you decide to point me to resources
where I can read up on how to contribute more effectively. I am not sure
if I should mention that this code and its comments is contributed under
LGPLv3+ / MPL ... because I just changed the comments ... but of course
it is. (It 's just for new code/code-changes, right?)
A little bit about me:
I am a software developer working with Microsoft Dynamics NAV and
C#/.NET for almost nine years now.
My condolences.
I do understand C/C++ and have done
some small projects some years ago using these languages, but I feel
that I have to warm up to using them again :). This is my first
contribution to a libre software project and I hope it will not be the
last one. I know that I have much to learn and I am excited to do so.
we all have much to learn... that's a big part of the fun :-)
It would be great to receive at least a reply like: This was OK. or
You should just have attached the file. or something like that. :)
If you would please send the name under which to commit your submission ?
I could use 'Pascal tentl...@web.de', but I'd rather be sure that is
what you really want (can't change it after the fact)
Norbert
Here is the diff (also to be found in the attached file):
diff
diff --git a/sw/source/core/edit/edfmt.cxx b/sw/source/core/edit/edfmt.cxx
index 016fa4d..1ec3814 100644
--- a/sw/source/core/edit/edfmt.cxx
+++ b/sw/source/core/edit/edfmt.cxx
@@ -39,7 +39,7 @@
#include fchrfmt.hxx
#include frmfmt.hxx
#include charfmt.hxx
-#include ndtxt.hxx // Fuer GetXXXFmt
+#include ndtxt.hxx // for GetXXXFmt
#include hints.hxx
/*
@@ -93,7 +93,7 @@ void SwEditShell::FillByEx(SwCharFmt* pCharFmt, BOOL
bReset)
{
const SwPosition* pPtPos = pPam-GetPoint();
const SwPosition* pMkPos = pPam-GetMark();
- if( pPtPos-nNode == pMkPos-nNode ) // im selben Node ?
+ if( pPtPos-nNode == pMkPos-nNode ) // in the same
node?
{
nStt = pPtPos-nContent.GetIndex();
if( nStt pMkPos-nContent.GetIndex() )
@@ -155,7 +155,7 @@ SwCharFmt* SwEditShell::MakeCharFmt( const String
rName,
}
//--
-// inlines im Product
+// inlines in product
SwTxtFmtColl* SwEditShell::GetTxtCollFromPool( USHORT nId )
@@ -164,7 +164,7 @@ SwTxtFmtColl* SwEditShell::GetTxtCollFromPool( USHORT
nId )
}
- // return das geforderte automatische Format - Basis-Klasse !
+ // return the demanded automatic format - base-class !
SwFmt* SwEditShell::GetFmtFromPool( USHORT nId )
{
return GetDoc()-GetFmtFromPool( nId );
/diff
___
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] comments translated in writer\sw\source\core\edit\edfmt.cxx
On Tue, Dec 28, 2010 at 5:25 AM, TentleXS tentl...@web.de wrote: Am 27.12.2010 20:12, schrieb Octavio Alvarez: On Mon, 27 Dec 2010 10:49:19 -0800, TentleXS tentl...@web.de wrote: Hallo @all, my name is Pascal and I would like to contribute the following translated code comments in writer\sw\source\core\edit\edfmt.cxx. My native language is german so I hope it's OK that I did the translation. Do you take requests? :-) I've been trying to work with these files, but I can't get the sense out of them. I'm putting my hope on the comments which are currently in German. sw/source/core/crsr/callnk.cxx sw/source/core/crsr/viscrs.cxx I am learning the workflow for contributing, so please excuse me if I did something wrong. I am glad if you decide to point me to resources where I can read up on how to contribute more effectively. I am not sure if I should mention that this code and its comments is contributed under LGPLv3+ / MPL ... because I just changed the comments ... but of course it is. (It's just for new code/code-changes, right?) Also, I would send it as a git patch so the committer can keep your authorship information. Otherwise, if someone picks your diff up he will need to apply your diff and create the commit himself and your authorship information gets lost. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice I hope I did this right. This should be a patch file for writer/sw/source/core/edit/edfmt.cxx writer/sw/source/core/crsr/callnk.cxx you can combine change to multiple sources files together, as long as they belong to the same git repository. Do I have to name the file differently? If you use git format-patch the default name will be based on the commit message, which hopefully will be distinctive enough if not, make sure that the title in your mailing list post in new and differents from previous patch submission that will help us not to miss any. When a patch is pushed to the git repo, we typically send a reply to the ML with [Pushed] added to the title. Using the same title for two or more patch submission, increase the chance that a patch being accidentally dropped. Norbert ___ 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] cppcheck cleaning in svx
On Mon, Dec 27, 2010 at 10:22:19PM +0100, Julien Nabet wrote: Hello, Here is a patch for cppcheck cleaning in svx Compiling was ok (Sorry for the last message, i forgot to put the attachment). Julien (LGPLv3+ / MPL) Pushed. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
2010/12/29 Jan Holesovsky ke...@suse.cz https://bugs.freedesktop.org/show_bug.cgi?id=32563 According to the l10n people, the lack of localized preamble in the LICENSE.odt (accessible from the Help menu) is seen a blocker. For sure we don't want to distribute n copies of the 132 pages long document, so I've implemented a separate dialog for that that leads to the document. Please review, sign-off push if OK :-) Hi Kendy, The first word (This) has an unnecessary access key on it. It would be better to avoid manual line breaks at end of lines, many translations will look awkward, if the translators don't calculate line lenght correctly. Lines should break automatically. Instead of one big string, could you please use 5 strings for the 5 paragraphs? This way we can reuse older translations automatically. Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Pushed] comments translated in writer\sw\source\core\edit\edfmt.cxx
On Tue, Dec 28, 2010 at 5:25 AM, TentleXS tentl...@web.de wrote: Am 27.12.2010 20:12, schrieb Octavio Alvarez: On Mon, 27 Dec 2010 10:49:19 -0800, TentleXS tentl...@web.de wrote: Hallo @all, my name is Pascal and I would like to contribute the following translated code comments in writer\sw\source\core\edit\edfmt.cxx. My native language is german so I hope it's OK that I did the translation. Do you take requests? :-) I've been trying to work with these files, but I can't get the sense out of them. I'm putting my hope on the comments which are currently in German. sw/source/core/crsr/callnk.cxx sw/source/core/crsr/viscrs.cxx I am learning the workflow for contributing, so please excuse me if I did something wrong. I am glad if you decide to point me to resources where I can read up on how to contribute more effectively. I am not sure if I should mention that this code and its comments is contributed under LGPLv3+ / MPL ... because I just changed the comments ... but of course it is. (It's just for new code/code-changes, right?) Also, I would send it as a git patch so the committer can keep your authorship information. Otherwise, if someone picks your diff up he will need to apply your diff and create the commit himself and your authorship information gets lost. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice I hope I did this right. This should be a patch file for writer/sw/source/core/edit/edfmt.cxx writer/sw/source/core/crsr/callnk.cxx Do I have to name the file differently? ___ 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] format inspector (Was : Re: sw: numbering misbehaviour)
On Tue, Dec 28, 2010 at 10:59 AM, Wols Lists antli...@youngman.org.uk wrote: On 28/12/10 12:54, Philipp Weissenbacher wrote: But I didn't know about that OOo bug. I'll need to learn styles, but yes, *me* learning styles is totally useless when it's *someone* *else* who's messed up *their* document (and expects me to fix it for them). I think that's *exactly* *the* use case: fixing broken formatting. Actually, no it isn't. It's a very useful use case, when I'm helping other people ... But when *I* am creating a document in WordPerfect I nearly always have reveal codes switched on. I *think* in markup mode, and the whole point of reveal codes is it is a markup window that shows me what's going on. As has been said, it keeps me in touch with what formatting is active (is the cursor *in*side or *out*side the style selection for example :-) I actually use reveal codes as my main working window, not the wysiwyg one. At this point, use LaTeX. I mean, If you are evolved enough to be able to cope with tag, why no use the real thing ? (and add git for a perfect difference tracking system and multi-user editing) Oh - and something Word can't do, dunno about Writer ... what on earth do you do when you have two formatting objects one on top of the other? How do you click on the object? It's easy to get like that with text over/under a picture or stuff like that, but I said something Word couldn't do ... Writer suck at it too. I have a set of document that use a big dimmed logo picture as a 'background' and there are multiple element on top of it. It is impossible to resize the column of a table. I have to delete the picture, edit the table and put the picture back. Norbert Cheers, Wol ___ 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] [PUSHED] cppcheck cleaning in svx
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] RTL_CONSTASCII_USTRINGPARAM in sw and toolkit
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] typo fix in helppacks.ulf
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] code cleanup and fix typos in comments
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] cppcheck prefix operator in components
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Custom-intro-and-about-files-now-defaultly-png-files
Hi Kami, On 2010-12-24 at 03:33 +0100, Kálmán „KAMI” Szalai wrote: Please review the attached files and integrate into libreoffice-3-3 Background: Now png files are default as intro and about picture files. It seems only intro.png and about.png used. These patches are: * force tu specify png files * rename and pack custom definied intro as intro.png and about as about.png. I am sorry, but the second patch does not look correct to me :-( $(null,$(INTRO_BITMAPS) $(MISC)$/$(RSCDEFIMG)$/brand$/intro.png $(INTRO_BITMAPS)) means expand $(INTRO_BITMAPS), and if it is NULL, return $(MISC)$/$(RSCDEFIMG)$/brand$/intro.png, otherwise $(INTRO_BITMAPS). With your change, $(COMMONBIN)$/brand_new$/intro.png is always non-NULL, and always returns $(MISC)$/$(RSCDEFIMG)$/brand$/intro.png. More here: http://tools.openoffice.org/dmake/dmake_4.9.html Can you please revisit the patch? Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] De-Java-ise flat XML export
Hi Gioele,
I've gotten so far as to have a working implementation of XSLTFilter
which uses libxml2/libxslt to do the XSL transformation. It's still
missing some details like passing parameters to the xslt script, but it
works for the flat xml export and for xhtml export as well. Using this
implementation would remove the java dependency from xslt filter
processing, but actually it might still be a good idea to implement the
flat xml filter as a special filter which doesn't depend on xslt at all
(like in the odk example). The current stylesheets basically do an
identity transformation and then some split-long-lines. I don't quite
understand the purpose of that stylesheet. What does it do?
Thanks,
Peter
Am Sonntag, den 12.12.2010, 13:27 +0100 schrieb Gioele Barabucci:
Peter Jentsch 11/12/2010 22:42:
Hi, I'm looking for an easy task to start hacking on OOo and because
I've got some experience with XSLT and Java I stumbled upon that
de-java-ising task for the XSLT export filter.
Am I missing something? Xalan C++ doesn't support XSLT 2.0, does anybody
known if XSLT export filters promise to support XSLT 2.0 (or XSLT 1.1)?
Hi,
the flat XML export XSLT filters ('odfflatxml') are quite simple. They
do not require XSLT 2.0; I tested them with libxml's xsltproc and they
work fine.
IIRC the idea [1] was to move as much XSLT processing as possible to
libxml, not to Xalan, as libxml is already used internally by
LibreOffice. I think it could make sense to have a list of filters that
can be run using an XSLT 1.0 procesor and use libxml to run them.
Maybe the flat XML format could be treated as a special filter: it could
be handled internally (with libxml) and shipped by default.
Bye,
[1]
http://article.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/2729
--
Gioele Barabucci gio...@svario.it
___
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] Annoying cursor behavior on sw tables
Hi Octavio, On 2010-12-23 at 21:07 -0800, Octavio Alvarez wrote: There is this really annoying behavior: 0. Open Writer. 1. Create a table, say 3 x 3. 2. Place the cursor in a cell. 3. Type some text, like asdfasdfasdfasdf. 4. Using the mouse, place the cursor in the middle of the asdf-word. 5. Using the keyboard go left and right and left and right... [...] diff --git a/sw/source/core/crsr/crsrsh.cxx b/sw/source/core/crsr/crsrsh.cxx index 5b92560..cbf39f3 100644 --- a/sw/source/core/crsr/crsrsh.cxx +++ b/sw/source/core/crsr/crsrsh.cxx @@ -344,7 +344,6 @@ BOOL SwCrsrShell::LeftRight( BOOL bLeft, USHORT nCnt, USHORT nMode, if( IsTableMode() ) return bLeft ? GoPrevCell() : GoNextCell(); -SwCallLink aLk( *this );// Crsr-Moves ueberwachen, evt. Link callen BOOL bRet = FALSE; // #i27615# Handle cursor in front of label. Wow, great start! Of course, I don't have the slightest idea of what an SwCallLink is or does and what its side effects are. Yes - that is core of the trouble; as usually, the class is not documented, so the purpose is not really visible: http://opengrok.go-oo.org/xref/writer/sw/source/core/crsr/callnk.hxx http://opengrok.go-oo.org/xref/writer/sw/source/core/crsr/callnk.cxx From what I see, it does most of its work in a destructor, so this looks like a kind of 'guard' that restores/updates stuff when the SwCallLink instance is destructed. Either way; I'd try to revert the callnk.cxx changes from commit 47472e8e70c1ae3dc55a5b00ef69eaa85f651a7f, it has something to do with tables, and see if you still see the problem. If not, then it might limit the scope of your debugging to that commit only. Hopefully I am not misleading you :-) And Pascal - great work translating the comments there, thank you! Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: Test script patch review request(0)
Hi Yifan, On 2010-12-24 at 17:20 +0800, Yifan Jiang wrote: I've updated several test scripts and intended to make them more reliable. I have tested them in SUSE Linux. Could you help review the patches and if possible help run relevant cases in various platforms. Thank you all for concerning and help! The belowing is the outline and details in the patch * 0001-use-uno-to-invoke-File-Digital-Signature-dialog.patch * 0003-more-stable-export-graphic-test.patch * 0004-use-uno-slot-to-click-File-Save-as-in-Base.patch * 0005-slideshow-test-case-update.patch All of them look good, pushed, thank you! Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Test script patch review request (1)
Hi Yifan, On 2010-12-24 at 17:23 +0800, Yifan Jiang wrote: Here is a bigger one, I forgot to compress it before, sorry to separate them. * 0002-replace-all-tabs-with-4-spaces.patch But did not push this one, sorry for that. This would cause trouble when merging changes from OOo, unfortunately; we will be able to do these changes with newer git version though - a change in the merge strategy that will allow to merge whitespace changes transparently is already introduced, hopefully it will get into a stable release soon. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] online registration menu element - 404
Hi Kami, On 2010-12-24 at 23:54 +0100, Kálmán „KAMI” Szalai wrote: If someone enables online registration menu element, and click on it gets a pege with 404 error. The address is: http://survey.libreoffice.org/user/index.php please put a redirector here, or we should change the link in LibO. Somebody has fixed that (thank you!), now it redirects to www.libreoffice.org. But how exactly do you mean it with enabling the online registration menu - by an user action, or during the build? I'd say the best thing would be to get rid of that completely, and remove all the related code... Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to Update the Downloaded Source?
Hi Octavio, On 2010-12-24 at 20:45 -0800, Octavio Alvarez wrote: But how can I update the downloaded source? Do I need to download all the 4.4GB source whenever I want to update it? ./g pull Just a small note, to streamline the history, we should be using ./g pull -r in most of the cases. [-r means 'rebase', which in this case puts your commits on top of the commits that you fetched from the remote end.] The most notable exception to this is merging OOo milestones, where we should be using ./g pull --no-rebase so that we don't lose the merge commits. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
Hi Andras, On 2010-12-29 at 09:59 +0100, Andras Timar wrote: The first word (This) has an unnecessary access key on it. I'll change it to %OOOPRODUCTNAME, or what exactly is the name of the variable to avoid confusion, that will be best I think. It would be better to avoid manual line breaks at end of lines, many translations will look awkward, if the translators don't calculate line lenght correctly. The logic is the other way around, the size of the dialog is computed according to the size of the text it contains - so if you choose another split, nothing really happens, the dialog will become bigger or smaller accordingly. Lines should break automatically. Instead of one big string, could you please use 5 strings for the 5 paragraphs? This way we can reuse older translations automatically. Hmm, let me see if I can do that ~trivially. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Annoying cursor behavior on sw tables
Sorry for breaking the thread, i was not subscribed to the list when this message was posted. Octavio Alvarez wrote: There is this really annoying behavior: 0. Open Writer. 1. Create a table, say 3 x 3. 2. Place the cursor in a cell. 3. Type some text, like asdfasdfasdfasdf. 4. Using the mouse, place the cursor in the middle of the asdf-word. 5. Using the keyboard go left and right and left and right... Notice how the cursor disappears. You don't know where exactly are you at a particular moment. I've tried to reproduce this in rc1 as packaged on Debian experimental and the cursor didn't disappear. It seems to work well. Under Windows 2000 seem to behave like you say, but i'm not sure since now i'm using the pc remotely through VNC. Cesare. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
Hi Sophie, On 2010-12-29 at 08:25 +0300, Sophie Gautier wrote: https://bugs.freedesktop.org/show_bug.cgi?id=32563 Thank you very much for that :) :-) I've a small request concerning the button, could you make sure that it's large enough for long languages. For example, I'll need 19 characters to translate [Show License] and French is not the longest language we get. Thanks in advance! I've changed it so that the size of the buttons is computed according to the length of the text they contain, so whatever reasonable (about 30 chars) will fit, and will look good for every lang. I also incorporated Andras' proposals minus the one not to use \n, as there would be too much variables to take into account then, which is painful when we do not have real dialog layouting (really looking forward to that! - being worked on in a feature branch). Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Le 29/12/2010 16:20, Jonas Finnemann Jensen a écrit : Hi, If you have enabled visual formula editing (The Enable experimental (unstable) features checkbox). Then the cursor should act more like MathType etc... e.g. like a WYSIWYG editor... It's demonstrated here: http://www.youtube.com/watch?v=3foNqKYAlYY Well, how say that kindly ? ;-) : For me the main advantage of Math module is that it is *not* like MathType. It was a reason because I switched from MS-Word to StarOffice at the end of the last millennium. I use the mouse to select a formula element *only* when I can't remember its syntax. [...] The visual formula editor is a move towards something more user friendly like MathType. Ok, we do not have the same definition of user friendly. :-) You'll still be able to write the formulas using the command text interface. But the formula cursor will not be rectangular anymore... And at the moment it will not synchronize it's position with the command text interface cursor. If I can continue to write formulas using the command text interface *and* to have the cursor in the formula window synchronizing it's position with the command text interface cursor, there is no problem for me if you want use your MathType clone. In other words, if you want to code a MathType clone, you must keep entirely the current edit mode and add the possibility to switch from a mode to the other. Formula editor is a very good compromise between keyboard only editor like Latex and mouse only editor like MathType. So, please, do not destroy that. Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi Sophie, On 2010-12-28 at 14:30 +0300, Sophie Gautier wrote: It may be quite hard to make difference between a *new* (m90) translated string and an old one. This is why I ask: do we merge Libo with the last dev versions or do we work on the last SDF file only (I think it's OOo330m9) because it is now two completely separated products? We are still working towards a plan how to cherry pick or merge from OOo from now on, so do not expect any huge changes in the next 2 weeks or so ;-) We have to evaluate the possibilities first, but most probably, this will be more on case-by-case basis, ie. the amount of strings to translate will grow at reasonable pace, not a huge drop of stuff to translate from a day to day. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
On 29/12/2010 19:08, Jan Holesovsky wrote: Hi Sophie, On 2010-12-29 at 08:25 +0300, Sophie Gautier wrote: https://bugs.freedesktop.org/show_bug.cgi?id=32563 Thank you very much for that :) :-) I've a small request concerning the button, could you make sure that it's large enough for long languages. For example, I'll need 19 characters to translate [Show License] and French is not the longest language we get. Thanks in advance! I've changed it so that the size of the buttons is computed according to the length of the text they contain, so whatever reasonable (about 30 chars) will fit, and will look good for every lang. This is great thanks ! I really hope that one day all our dialogs will be able to magically adapt to our strings, that will save everybody's time. Well, I know it's not easy any way. I also incorporated Andras' proposals minus the one not to use \n, as there would be too much variables to take into account then, which is painful when we do not have real dialog layouting (really looking forward to that! - being worked on in a feature branch). Thanks also for taking care here. Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Annoying cursor behavior on sw tables
On Wed, 29 Dec 2010 06:57:27 -0800, Cesare Leonardi celeo...@gmail.com wrote: Sorry for breaking the thread, i was not subscribed to the list when this message was posted. Octavio Alvarez wrote: There is this really annoying behavior: 0. Open Writer. 1. Create a table, say 3 x 3. 2. Place the cursor in a cell. 3. Type some text, like asdfasdfasdfasdf. 4. Using the mouse, place the cursor in the middle of the asdf-word. 5. Using the keyboard go left and right and left and right... Notice how the cursor disappears. You don't know where exactly are you at a particular moment. I've tried to reproduce this in rc1 as packaged on Debian experimental and the cursor didn't disappear. It seems to work well. Under Windows 2000 seem to behave like you say, but i'm not sure since now i'm using the pc remotely through VNC. Under Linux you should notice the cursor doesn't immediately disappear, but it moves and then quickly blinks off (where it should blink on). So no, it doesn't disappear as such. That's why using it over VNC makes the problem more apparent. Maybe trying it on Linux over VNC makes it more apparent too. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi Kendy, On 29/12/2010 19:21, Jan Holesovsky wrote: Hi Sophie, On 2010-12-28 at 14:30 +0300, Sophie Gautier wrote: It may be quite hard to make difference between a *new* (m90) translated string and an old one. This is why I ask: do we merge Libo with the last dev versions or do we work on the last SDF file only (I think it's OOo330m9) because it is now two completely separated products? We are still working towards a plan how to cherry pick or merge from OOo from now on, so do not expect any huge changes in the next 2 weeks or so ;-) We have to evaluate the possibilities first, but most probably, this will be more on case-by-case basis, ie. the amount of strings to translate will grow at reasonable pace, not a huge drop of stuff to translate from a day to day. Our concerns here, with Olivier and the few of us not doing localization for OOo any more, is that the localization will be done by someone else, may be a professional agency. Most of the time the quality is very very low because the agencies know nothing about the product where we work with it and localize it since years. So, no matter the amount of strings, if we are sure of the consistency and we do not have to research in the files to ensure it. Currently there is a little more than 6000 new/fuzzy words until DEV300m90, it's not so much and even less if we have a long deadline ;) But we need to merge the strings quiet soon now because we didn't have the opportunity any more to fix l10n issues in OOo 3.3 since September/October, so we may have a quite long list on our table now. Even if it's in 3 weeks or the month after, having an idea of the time frame will help to reserve the needed time/resources to fix these issues. Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi, I keep localizing OOo on my computer, with regular updates, knowing or hoping that at this stage most of changes for OOo 3.4 will make it to LO 3.4. Later, when all files are merged (OOo sdf + lo-build) into a LO set of po files, I can center on localizing those only. Lp, m. 2010/12/29 Sophie Gautier gautier.sop...@gmail.com Hi Kendy, On 29/12/2010 19:21, Jan Holesovsky wrote: Hi Sophie, On 2010-12-28 at 14:30 +0300, Sophie Gautier wrote: It may be quite hard to make difference between a *new* (m90) translated string and an old one. This is why I ask: do we merge Libo with the last dev versions or do we work on the last SDF file only (I think it's OOo330m9) because it is now two completely separated products? We are still working towards a plan how to cherry pick or merge from OOo from now on, so do not expect any huge changes in the next 2 weeks or so ;-) We have to evaluate the possibilities first, but most probably, this will be more on case-by-case basis, ie. the amount of strings to translate will grow at reasonable pace, not a huge drop of stuff to translate from a day to day. Our concerns here, with Olivier and the few of us not doing localization for OOo any more, is that the localization will be done by someone else, may be a professional agency. Most of the time the quality is very very low because the agencies know nothing about the product where we work with it and localize it since years. So, no matter the amount of strings, if we are sure of the consistency and we do not have to research in the files to ensure it. Currently there is a little more than 6000 new/fuzzy words until DEV300m90, it's not so much and even less if we have a long deadline ;) But we need to merge the strings quiet soon now because we didn't have the opportunity any more to fix l10n issues in OOo 3.3 since September/October, so we may have a quite long list on our table now. Even if it's in 3 weeks or the month after, having an idea of the time frame will help to reserve the needed time/resources to fix these issues. Kind regards Sophie -- Unsubscribe instructions: E-mail to l10n+h...@libreoffice.orgl10n%2bh...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/l10n/ *** All posts to this list are publicly archived for eternity *** ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi, Well, how say that kindly ? ;-) : For me the main advantage of Math module is that it is *not* like MathType. I agree that for some people, power users, the command text interface might be faster to use... But it's next to impossible to convince normal users to sit down and learn a command language. (Most non-programmers can hardly set brackets for parsing correctly). But, there's no plans to remove the old command text interface... And loss of the square cursor is probably not a problem for power users :) Ok, we do not have the same definition of user friendly. :-) I'll admit that I haven't done a usability study on the subject... - Those things are utterly boring to do :) But if the target group is ordinary office users, and a course in formula writing isn't a prerequisite, I can pretty much guess the result... I'm not saying that the command text interface isn't faster and easier to use once you've learned it... (But so is vim and emacs). Anyway, command text interface is not disappearing... So you have nothing to fear... -- Regards Jonas Finnemann Jensen. On Wed, Dec 29, 2010 at 17:17, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: Le 29/12/2010 16:20, Jonas Finnemann Jensen a écrit : Hi, If you have enabled visual formula editing (The Enable experimental (unstable) features checkbox). Then the cursor should act more like MathType etc... e.g. like a WYSIWYG editor... It's demonstrated here: http://www.youtube.com/watch?v=3foNqKYAlYY Well, how say that kindly ? ;-) : For me the main advantage of Math module is that it is *not* like MathType. It was a reason because I switched from MS-Word to StarOffice at the end of the last millennium. I use the mouse to select a formula element *only* when I can't remember its syntax. [...] The visual formula editor is a move towards something more user friendly like MathType. Ok, we do not have the same definition of user friendly. :-) You'll still be able to write the formulas using the command text interface. But the formula cursor will not be rectangular anymore... And at the moment it will not synchronize it's position with the command text interface cursor. If I can continue to write formulas using the command text interface *and* to have the cursor in the formula window synchronizing it's position with the command text interface cursor, there is no problem for me if you want use your MathType clone. In other words, if you want to code a MathType clone, you must keep entirely the current edit mode and add the possibility to switch from a mode to the other. Formula editor is a very good compromise between keyboard only editor like Latex and mouse only editor like MathType. So, please, do not destroy that. Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ 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] making binfilter aka StarOffice FileFormat read-only
Hi Pierre-Andre, On 2010-12-27 at 21:31 +0100, Pierre-André Jacquod wrote: An easy (and clean) possibility would be to change the filters defined in binfilter as read-only filters (using as filter flag SFX_FILTER_OPENREADONLY defined as 0x0001L) This will make the opening read-only. By this way, this is not possible any more to save using these file formats. (I have not yet found where this is set, but still searching) IIRC the resolution was a bit different ;-) This way the user will be unable to modify the document, unless she uses the 'create copy' possibility, right? The proposal was to load it so that it is read/write, but issue a warning like The format of the file you opened is legacy, and the write support is discontinued. You will be unable to save your changes, unless you choose another file format. Please consider migrating the document to a newer format, like ODF., and remove it from from the Save As... menu (and consequently from Save). To do the latter, it might be (as the first step) enough to remove EXPORT from filter/source/config/fragments/filters/StarWriter_5_0.xcu and others that use com.sun.star.comp.office.BF_MigrateFilter as the FilterService. c) it seems there are elements in the sfx2 of binfilter that are still called, generated, but have no impact on the running system. For exemple function SfxFilterContainer::ReadExternalFilters (in binfilter/bf_sfx2/source/bastyp/sfx2_fltfnc.cxx) is still called, produced me a lot of debug text, but the above mentionned code inserted at the same place (as in libs-core but within his function) did not produced any effect. So this function is still called, but its effects are not taken into account. d) So binfilter could be simplified if I take out all wrinting stuff, and not needed section of code still called... Yes - I think Caolan's callcatches might help you here a lot. with the ExportTo function going magically to the binfilter module. I did not understood what I read there, with the uno part... http://kohei.us/2007/05/08/how-to-pretend-to-write-an-export-filter/ might hopefully help you to understand part of the magic :-) So how to go ahead? Here I am asking you: - is it OK to go ahead with this idea? As outlined above, my favorite approach would be to 'disconnect' the binfilter from the save functionality first, add the dialog on open, and then do the cleanup. - should I make a feature/StarOffice-read-only branch ? Let's do the first step directly against master, once you have the initial patch (that removes the Save and Save As... functionality for binfilter), and the rest (the cleanup) in a feature branch; how does that sound? - could someone (help me) implement the sorting in order to ensure that read-only filters are not available for Save / Save As? I hope I helped a bit, please ask more if not really :-) Thanks a lot, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi Sophie, On 2010-12-29 at 19:52 +0300, Sophie Gautier wrote: But we need to merge the strings quiet soon now because we didn't have the opportunity any more to fix l10n issues in OOo 3.3 since I am confused - did you mean 3.4 here, or I did not understand your initial mail, please? Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi Sophie, On 2010-12-29 at 19:52 +0300, Sophie Gautier wrote: This is why I ask: do we merge Libo with the last dev versions or do we work on the last SDF file only (I think it's OOo330m9) because it is now two completely separated products? We are still working towards a plan how to cherry pick or merge from OOo from now on, so do not expect any huge changes in the next 2 weeks or so ;-) We have to evaluate the possibilities first, but most probably, this will be more on case-by-case basis, ie. the amount of strings to translate will grow at reasonable pace, not a huge drop of stuff to translate from a day to day. Our concerns here, with Olivier and the few of us not doing localization for OOo any more, is that the localization will be done by someone else, may be a professional agency. Most of the time the quality is very very low because the agencies know nothing about the product where we work with it and localize it since years. So, no matter the amount of strings, if we are sure of the consistency and we do not have to research in the files to ensure it. Currently there is a little more than 6000 new/fuzzy words until DEV300m90, it's not so much and even less if we have a long deadline ;) Ah, maybe I understand now ;-) So of course, it is up to you to define if you want to have the translations merged from the OOo tree to the LO tree for 3.4, or not. I understand it that you'd prefer not to, ie. l10n repo (containing the localize.sdf's) untouched by the merges from OOo, right? Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
On Wed, Dec 29, 2010 at 07:22:07PM +0300, Sophie Gautier wrote: This is great thanks ! I really hope that one day all our dialogs will be able to magically adapt to our strings, that will save everybody's time. Well, I know it's not easy any way. And I hope some f* day a day will come when it's nt a blocker when a enlish text isn't translated. (That of course depends on the circumstances, but I don't thinhk a untranslated preamble is such a circumstance) English is de facto a thing everyone should know, even more so if they are going to read the license. (And I would even argue the preamble of the license belongs to the license itself, and thus shouldn't be translated anyways). I also have to live with the fact that en_US iś english, whereas that's deserved by en_GB because that's the original english. I don't add this as stopper either. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
On 29/12/2010 20:25, Jan Holesovsky wrote: Hi Sophie, On 2010-12-29 at 19:52 +0300, Sophie Gautier wrote: But we need to merge the strings quiet soon now because we didn't have the opportunity any more to fix l10n issues in OOo 3.3 since I am confused - did you mean 3.4 here, or I did not understand your initial mail, please? No I mean 3.3. Sorry the difficulty to explain all this... We are normally continuously correcting small bugs in our translation files, mostly the help files but also sometimes UI. This is now two/three months that we didn't touch the files because we do not have them in the LO Pootle repository and we are not working any more on the OOo Pootle repository. So some teams have now a fair amount of issues to fix in their files, that will take time and resources, and we need to have the complete set of files in the LO Pootle repository for that. Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: Update of the localization files
Hi Kendy, On 29/12/2010 20:31, Jan Holesovsky wrote: Hi Sophie, On 2010-12-29 at 19:52 +0300, Sophie Gautier wrote: This is why I ask: do we merge Libo with the last dev versions or do we work on the last SDF file only (I think it's OOo330m9) because it is now two completely separated products? We are still working towards a plan how to cherry pick or merge from OOo from now on, so do not expect any huge changes in the next 2 weeks or so ;-) We have to evaluate the possibilities first, but most probably, this will be more on case-by-case basis, ie. the amount of strings to translate will grow at reasonable pace, not a huge drop of stuff to translate from a day to day. Our concerns here, with Olivier and the few of us not doing localization for OOo any more, is that the localization will be done by someone else, may be a professional agency. Most of the time the quality is very very low because the agencies know nothing about the product where we work with it and localize it since years. So, no matter the amount of strings, if we are sure of the consistency and we do not have to research in the files to ensure it. Currently there is a little more than 6000 new/fuzzy words until DEV300m90, it's not so much and even less if we have a long deadline ;) Ah, maybe I understand now ;-) So of course, it is up to you to define if you want to have the translations merged from the OOo tree to the LO tree for 3.4, or not. I understand it that you'd prefer not to, ie. l10n repo (containing the localize.sdf's) untouched by the merges from OOo, right? That was what I was not sure about: all the new features and bug fixes for OOo will be merged to the LO tree for 3.4. In that case yes, we want the l10n repo merged and containing all the new features or fixes strings from OOo. And the sooner the better whatever the amount of strings :-) So that means that we can extract the strings from the last OOoDEV and merge them with our LO file to have the complete (UI+HC2) set of strings up to date until now? Thanks to you and your patience Kendy :) Kind regards Sophie ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review push to libreoffice-3-3
On 29/12/10 17:46, Rene Engelhard wrote: English is de facto a thing everyone should know, even more so if they are going to read the license. (And I would even argue the preamble of the license belongs to the license itself, and thus shouldn't be translated anyways). Actually, as a native English speaker (that's English, not American :-) I'm pretty appalled by the fact we expect everyone else to speak our language, so I wouldn't agree English is something everyone should know. Oh - and if we're going by European first languages at least, then the dominant native tongue is some variant of latin. Making Latin the standard language of Europe would make a lot of sense :-) English is very much an also-ran in those stakes... I also have to live with the fact that en_US iś english, whereas that's deserved by en_GB because that's the original english. I don't add this as stopper either. And again, no, en_GB is not the original english. It is the language of the English nation, true (who are Saxons, not Angles :-), but American is actually a lot closer to historical English than is Modern English. (btw, the Angles speak Scots :-) Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi, Jonas Finnemann Jensen schrieb: Hi, Well, how say that kindly ? ;-) : For me the main advantage of Math module is that it is *not* like MathType. I agree that for some people, power users, the command text interface might be faster to use... But it's next to impossible to convince normal users to sit down and learn a command language. (Most non-programmers can hardly set brackets for parsing correctly). I disagree. I have teached the formula essentials including command line in school in 20 min to 17 age old pupils and in 80 min to 14 age old pupils without problems. It is only difficult for people, who do not get a starting instruction. But, there's no plans to remove the old command text interface... And loss of the square cursor is probably not a problem for power users :) It is loss of a useful tool. In the old kind double clicking an object in the view will selects it in the command line. That is very useful to look about in large complex command lines. (For example writing a matrix equation leads to commands over several lines.) Ok, we do not have the same definition of user friendly. :-) I'll admit that I haven't done a usability study on the subject... - Those things are utterly boring to do :) But if the target group is ordinary office users, and a course in formula writing isn't a prerequisite, I can pretty much guess the result... Ordinary office users do not need the formula editor at all. But all of those who write scientific texts. I'm not saying that the command text interface isn't faster and easier to use once you've learned it... (But so is vim and emacs). Anyway, command text interface is not disappearing... So you have nothing to fear... One feature is already lost. I fear more regressions. kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi Regina, It is only difficult for people, who do not get a starting instruction. True... I would assume that most users are not given an introduction course... In most schools students are given an introduction to MS Word and MathType. If an introduction is given, it's quite often assume that people can use word... But we need to find a balance between easy-to-learn and fast-to-use. At the moment it requires quite a lot of effort to learn it... Hench my reference to vim/emacs... I mean it would be faster to write the text in LibreOffice if it had a vim-mode. But LibreOffice don't have a vim-mode because of the learning curve. I'm hoping the sensible shortcuts and perhaps (this is on my dream-list) inline auto-completion for supporting commands in the visual formula editor... could improve the efficiency of the visual formula editor. Ordinary office users do not need the formula editor at all. But all of those who write scientific texts. Hmm... You might be right about that one :) - I thought everybody needed to write scientific texts, at least that's how I think the world ought to be :) One feature is already lost. I fear more regressions. If you disable experimental features, everything is back to normal. And position and selection synchronization can be fixed before this feature is enabled by default... Assuming someone cares to implement it... and you're are welcome to step up to the plate :) I hope we can agree that a visual editor, where the old command text interface is still available, is a good idea... And a great improvement to many users... Especially those migrating from Microsoft Office. -- Regards Jonas Finnemann Jensen. On Wed, Dec 29, 2010 at 19:31, Regina Henschel rb.hensc...@t-online.de wrote: Hi, Jonas Finnemann Jensen schrieb: Hi, Well, how say that kindly ? ;-) : For me the main advantage of Math module is that it is *not* like MathType. I agree that for some people, power users, the command text interface might be faster to use... But it's next to impossible to convince normal users to sit down and learn a command language. (Most non-programmers can hardly set brackets for parsing correctly). I disagree. I have teached the formula essentials including command line in school in 20 min to 17 age old pupils and in 80 min to 14 age old pupils without problems. It is only difficult for people, who do not get a starting instruction. But, there's no plans to remove the old command text interface... And loss of the square cursor is probably not a problem for power users :) It is loss of a useful tool. In the old kind double clicking an object in the view will selects it in the command line. That is very useful to look about in large complex command lines. (For example writing a matrix equation leads to commands over several lines.) Ok, we do not have the same definition of user friendly. :-) I'll admit that I haven't done a usability study on the subject... - Those things are utterly boring to do :) But if the target group is ordinary office users, and a course in formula writing isn't a prerequisite, I can pretty much guess the result... Ordinary office users do not need the formula editor at all. But all of those who write scientific texts. I'm not saying that the command text interface isn't faster and easier to use once you've learned it... (But so is vim and emacs). Anyway, command text interface is not disappearing... So you have nothing to fear... One feature is already lost. I fear more regressions. kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
On 29/12/10 19:06, Jonas Finnemann Jensen wrote: Hi Regina, It is only difficult for people, who do not get a starting instruction. True... I would assume that most users are not given an introduction course... In most schools students are given an introduction to MS Word and MathType. If an introduction is given, it's quite often assume that people can use word... But we need to find a balance between easy-to-learn and fast-to-use. At the moment it requires quite a lot of effort to learn it... Hench my reference to vim/emacs... I mean it would be faster to write the text in LibreOffice if it had a vim-mode. But LibreOffice don't have a vim-mode because of the learning curve. This is exactly my thing with WordPerfect ... it was aimed at TRAINED typists! You know, those people who type at 120 words per minute WITHOUT LOOKING AT THE TYPEWRITER. (Which is why I hate Word - if you *do* know what you're doing, all these enhancements are like Bob, a bl**dy pain!) We need to plan towards an expert mode with NO popups, NO distractions, NOTHING that gets in the way of a fast typist bashing in the text. I'm not saying the WordPerfect way is best, but again, something I remember hearing said about it, it presented the user with a blank screen, like a blank piece of paper, but all the power of the menus, drop downs, etc was easily accessible if required. It shouldn't be that hard to fix things so we have a learning mode for the two-fingered hunt-n-peck people, and an expert mode for the experienced typists ... and if it IS difficult, then there's something wrong with LO! Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Le 29/12/2010 20:06, Jonas Finnemann Jensen a écrit : [...] If you disable experimental features, everything is back to normal. And position and selection synchronization can be fixed before this feature is enabled by default... Assuming someone cares to implement it... and you're are welcome to step up to the plate :) I strongly disagree : it is you who must not to destroy what is working very well. If you need to remove cursor formula feature to implement your visual editor, that proves there is some defect in your implementation. Please, do not tell we do not need this feature when you do not know how to implement your visual editor without destroying it. I hope we can agree that a visual editor, where the old command text interface is still available, is a good idea... And a great improvement to many users... Especially those migrating from Microsoft Office. Not sure: you seem to be assuming that users migrating from MS-Office do that only because LibO is free. It is not what I see around me. Many users, scientists, students, are leaving MS-Word because it does not work well enough, especially the MathType module bundled with MSO. They are ready to use Latex instead of LibO... Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
On Sat, 2010-12-25 at 13:43 +0100, Miklos Vajna wrote:
On Fri, Dec 24, 2010 at 01:41:56PM +, Caolán McNamara
caol...@redhat.com wrote:
Try now again, there was one cppunit header included outside those
guard. I've moved it inside the guards now. Does that now work ?
No, I get the same output. However, using the attached patch everything
is OK.
If you change std:: in that little section to ext_std:: i.e. the
attached, does that work ?
If it does, go ahead and commit and push this, if it doesn't then go
ahead an push your own fix instead.
C.
diff --git a/starmath/qa/cppunit/test_nodetotextvisitors.cxx b/starmath/qa/cppunit/test_nodetotextvisitors.cxx
index 9fa5ec0..687f75b 100644
--- a/starmath/qa/cppunit/test_nodetotextvisitors.cxx
+++ b/starmath/qa/cppunit/test_nodetotextvisitors.cxx
@@ -66,9 +66,9 @@ struct assertion_traitsString
return x == y;
}
-static std::string toString(const String x)
+static ext_std::string toString(const String x)
{
-std::string text = ByteString(x, RTL_TEXTENCODING_UTF8).GetBuffer();
+ext_std::string text = ByteString(x, RTL_TEXTENCODING_UTF8).GetBuffer();
OStringStream ost;
ost text;
return ost.str();
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] starmath / cppunit breakage in master
On Wed, Dec 29, 2010 at 09:28:56PM +, Caolán McNamara caol...@redhat.com wrote: If you change std:: in that little section to ext_std:: i.e. the attached, does that work ? Yes. :) If it does, go ahead and commit and push this, if it doesn't then go ahead an push your own fix instead. Pushed your one. Thanks! pgpnkJKvOVcGU.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
If you need to remove cursor formula feature to implement your visual editor, that proves there is some defect in your implementation. Please, do not tell we do not need this feature when you do not know how to implement your visual editor without destroying it. As I said position and selection synchronization between the two editors is possible. But it's not a priority of mine, fixing current bugs in the visual editor is :) Note: That the visual editor is still an experimental feature, and not enabled by default! If the visual editor causes regressions in a magnitude worth talking about we can take that discussion when it's declared stable... - That is not happening now... But I will keep in mind that the current user base is not fond of regressions... :) By the way, do you totally discard the need for an easy-to-use formula editor ? I'm not saying that there's no need command text interface... And if you love the way the formula cursor works now... I don't think it's a problem to create a settings checkbox where you can determine formula cursor behavior... But I'm hoping that at some point during the development the two things will blend nicely, so that it works out for everybody :) -- Regards Jonas Finnemann Jensen. On Wed, Dec 29, 2010 at 21:11, Jean-Baptiste Faure jbf.fa...@orange.fr wrote: Le 29/12/2010 20:06, Jonas Finnemann Jensen a écrit : [...] If you disable experimental features, everything is back to normal. And position and selection synchronization can be fixed before this feature is enabled by default... Assuming someone cares to implement it... and you're are welcome to step up to the plate :) I strongly disagree : it is you who must not to destroy what is working very well. If you need to remove cursor formula feature to implement your visual editor, that proves there is some defect in your implementation. Please, do not tell we do not need this feature when you do not know how to implement your visual editor without destroying it. I hope we can agree that a visual editor, where the old command text interface is still available, is a good idea... And a great improvement to many users... Especially those migrating from Microsoft Office. Not sure: you seem to be assuming that users migrating from MS-Office do that only because LibO is free. It is not what I see around me. Many users, scientists, students, are leaving MS-Word because it does not work well enough, especially the MathType module bundled with MSO. They are ready to use Latex instead of LibO... Best regards. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ 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] Formula cursor : bug or feature ?
Hi,
Le 29/12/2010 23:59, Jonas Finnemann Jensen a écrit :
If you need to remove cursor formula feature to implement your visual
editor, that proves there is some defect in your implementation.
Please, do not tell we do not need this feature when you do not know how
to implement your visual editor without destroying it.
As I said position and selection synchronization between the two
editors is possible.
But it's not a priority of mine, fixing current bugs in the visual editor is
:)
If visual editor remove cursors synchronization (formula cursor), it is
a bug.
Note: That the visual editor is still an experimental feature, and not
enabled by default!
If the visual editor causes regressions in a magnitude worth talking
about we can take that discussion when it's declared stable...
I prefer to alert you before...
- That is not happening now...
But I will keep in mind that the current user base is not fond of
regressions... :)
By the way, do you totally discard the need for an easy-to-use formula editor
?
No. But what do you mean by easy-to-use formula editor ? easy-to-use
formula editor is not a specification for an editor. The specification
describe the set of functions you will implement and you expect that
this set of functions will let say the users: ok, now we have an
easy-to-use formula editor.
In other words easy-to-use formula editor is a marketing expression
behind which you can have anything.
For me the current formula editor is already easy-to-use. However it
will be more easy to use if the command window was able to show the
complementary braket or brace. It would be very useful when you have
complex formulas with several levels of group brakets to write.
I'm not saying that there's no need command text interface... And if
you love the way the formula cursor works now... I don't think it's a
problem to create a settings checkbox where you can determine formula
cursor behavior...
I think that is, indeed, the least of the things to do if you want add a
visual mode to the current editor.
However the button to activate the formula cursor already exists, but it
does not work if experimental functions are activated.
In fact I would prefer a checkbox to choose the editor mode, text mode
or visual mode.
But I'm hoping that at some point during the development the two
things will blend nicely, so that it works out for everybody :)
For that you need to design your visual editor to allow the possibility
to write formulas without using the mouse. For example it would be nice
to write sqrt{} in the formula and obtain a square root.
Best regards.
JBF
--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] new cppcheck cleaning in svx
Hello,
Here are 2 new patches for cppcheck cleaning in svx
Compiling was ok
Remarks :
I had this with the last git version of cppcheck :
1)
[./svdotxln.cxx:67]: (style) The class 'ImpSdrObjTextLink' does not have
a constructor.
but we can read this on the file :
class ImpSdrObjTextLink: public ::sfx2::SvBaseLink
{
SdrTextObj* pSdrObj;
public:
ImpSdrObjTextLink( SdrTextObj* pObj1 )
: ::sfx2::SvBaseLink( ::sfx2::LINKUPDATE_ONCALL, FORMAT_FILE ),
pSdrObj( pObj1 )
{}
...
It seems there is a constructor, doesn't it ? So either if it's a false
positive and i do a tracker or it's ok and i would need some explanation
(please ! :-) ).
2)
in view3d.cxx, I've got this :
[./view3d.cxx:299]: (style) Variable 'pM' is assigned a value that is
never used
but either pM should be used (and i don't know how) or pM is useless and
this entire line too :
pM = GetSdrMarkByIndex(nObjs);
3)
Checking ./gridctrl.cxx...
[./gridctrl.cxx:3720]: (error) Possible null pointer dereference:
pListeners - otherwise it is redundant to check if pListeners is null at
line 3722
but I don't know what to do with this.
There are still some cppcheck in svx, i hope to correct all of them soon.
Julien
(LGPLv3+ / MPL)
commit 2c7fd1b55ec2c937308f4edc2ea2f996126a1c4c
Author: Julien Nabet serval2...@yahoo.fr
Date: Thu Dec 30 00:18:04 2010 +0100
cppcheck cleaning
diff --git a/svx/source/svdraw/svdfmtf.cxx b/svx/source/svdraw/svdfmtf.cxx
index 1ea7fb0..1984b65 100644
--- a/svx/source/svdraw/svdfmtf.cxx
+++ b/svx/source/svdraw/svdfmtf.cxx
@@ -82,6 +82,7 @@ ImpSdrGDIMetaFileImport::ImpSdrGDIMetaFileImport(SdrModel
rModel):
nLineWidth(0),
maLineJoin(basegfx::B2DLINEJOIN_NONE),
maDash(XDASH_RECT, 0, 0, 0, 0, 0),
+fScaleX(0.0),fScaleY(0.0),
bFntDirty(TRUE),
bLastObjWasPolyWithoutLine(FALSE),bNoLine(FALSE),bNoFill(FALSE),bLastObjWasLine(FALSE)
{
diff --git a/svx/source/svdraw/svdocirc.cxx b/svx/source/svdraw/svdocirc.cxx
index e175402..ee5bcb0 100644
--- a/svx/source/svdraw/svdocirc.cxx
+++ b/svx/source/svdraw/svdocirc.cxx
@@ -387,6 +387,7 @@ public:
nWdt(0),
nStart(0),
nEnd(0),
+nWink(0),
bRight(FALSE)
{}
void SetCreateParams(SdrDragStat rStat);
diff --git a/svx/source/svdraw/svdoole2.cxx b/svx/source/svdraw/svdoole2.cxx
index a8fa0ee..61e084c 100644
--- a/svx/source/svdraw/svdoole2.cxx
+++ b/svx/source/svdraw/svdoole2.cxx
@@ -700,6 +700,7 @@ public:
SdrOle2ObjImpl()
: pGraphicObject( NULL )
+, pLightClient ( NULL )
// #107645#
// init to start situation, loading did not fail
, mbLoadingOLEObjectFailed( sal_False )
diff --git a/svx/source/toolbars/extrusionbar.cxx
b/svx/source/toolbars/extrusionbar.cxx
index 63e5219..06296ac 100644
--- a/svx/source/toolbars/extrusionbar.cxx
+++ b/svx/source/toolbars/extrusionbar.cxx
@@ -686,10 +686,7 @@ void getExtrusionDirectionState( SdrView* pSdrView,
SfxItemSet rSet )
sal_Bool bParallel = sal_True;
Position3D aViewPoint( 3472, -3472, 25000 );
-double fOriginX = 0.50;
-double fOriginY = -0.50;
double fSkewAngle = -135;
-double fSkew = 50.0;
pAny = aGeometryItem.GetPropertyValueByName( sExtrusion,
sProjectionMode );
sal_Int16 nProjectionMode = sal_Int16();
@@ -698,6 +695,7 @@ void getExtrusionDirectionState( SdrView* pSdrView,
SfxItemSet rSet )
if( bParallel )
{
+double fSkew = 50.0;
EnhancedCustomShapeParameterPair aSkewPropPair;
pAny = aGeometryItem.GetPropertyValueByName( sExtrusion, sSkew
);
if( pAny ( *pAny = aSkewPropPair ) )
@@ -712,6 +710,8 @@ void getExtrusionDirectionState( SdrView* pSdrView,
SfxItemSet rSet )
}
else
{
+double fOriginX = 0.50;
+double fOriginY = -0.50;
pAny = aGeometryItem.GetPropertyValueByName( sExtrusion,
sViewPoint );
if( pAny )
*pAny = aViewPoint;
commit 84dfdf5cb54f769cf616b213ba9fbca824b844dd
Author: Julien Nabet serval2...@yahoo.fr
Date: Thu Dec 30 00:50:00 2010 +0100
cppcheck cleaning in svx part 2
diff --git a/svx/source/dialog/dialcontrol.cxx
b/svx/source/dialog/dialcontrol.cxx
index d5d5d5c..5c23584 100644
--- a/svx/source/dialog/dialcontrol.cxx
+++ b/svx/source/dialog/dialcontrol.cxx
@@ -77,6 +77,8 @@ private:
DialControlBmp::DialControlBmp( Window rParent ) :
VirtualDevice( rParent, 0, 0 ),
mrParent( rParent ),
+mnCenterX(0),
+mnCenterY(0),
mbEnabled( true )
{
EnableRTL( FALSE );
@@ -266,6 +268,8 @@ DialControl_Impl::DialControl_Impl( Window rParent ) :
maBmpBuffered( rParent ),
mpLinkField( 0 ),
mnAngle( 0 ),
+
[Libreoffice] LO Pootle
Hi Sophie, Thank you for all the explanations! :-) On 2010-12-29 at 21:00 +0300, Sophie Gautier wrote: This is now two/three months that we didn't touch the files because we do not have them in the LO Pootle repository and we are not working any more on the OOo Pootle repository. So some teams have now a fair amount of issues to fix in their files, that will take time and resources, and we need to have the complete set of files in the LO Pootle repository for that. I see, OK. What is at the moment blocking the import of the content of the OOo Pootle into the LO Pootle, please? Just some missing tooling, or the decision of what is the source for the translations how to organize them? On 2010-12-29 at 21:00 +0300, Sophie Gautier wrote: Ah, maybe I understand now ;-) So of course, it is up to you to define if you want to have the translations merged from the OOo tree to the LO tree for 3.4, or not. I understand it that you'd prefer not to, ie. l10n repo (containing the localize.sdf's) untouched by the merges from OOo, right? That was what I was not sure about: all the new features and bug fixes for OOo will be merged to the LO tree for 3.4. Most probably we won't be merging everything, which might cause trouble when merging the localizations as a whole :-( In that case yes, we want the l10n repo merged and containing all the new features or fixes strings from OOo. And the sooner the better whatever the amount of strings :-) So that means that we can extract the strings from the last OOoDEV and merge them with our LO file to have the complete (UI+HC2) set of strings up to date until now? Based on what you wrote, I think for LO master (towards-3.4), the best would be to extract all the strings from the current git repositories (ie. from the LO master branch, not from OOoDEV) to have the complete set (so that it would look similar to what is in the OOo Pootle now, but based on LO sources), and msgmerge the translations from OOo and from lo-build.po. That way, it would be easy to merge updated translations from OOo later (should there be any), while still having the LO strings as the base. Or are there reasons not to do that? BTW - would it help you if we got rid of the sdf files, and instead we had .po files in the l10n git repository? [For sure it would help us who work with the git repos, because the sdf file format is just something incredibly terrible for version control.] Would you be able to merge directly from the OOo Pootle, or from .po files produced by that, or do you still need .sdf for part of your workflow? Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Allow Admins to Hide Enable experimental features
Hello friends *If* this has not yet been done, I have a request make the Enable experimental (unstable) features hideable from the UI, possibly thru an XCU configuration file. I can open a bug for the records, just let me know. Motivation: In large deployments with tight IT control such option as a source of troubles for the help desk, where software stability is a must. This option can spark user curiosity and he/she may break the installation by ill-behaved (unstable) features. I am not asking to remove this option from the code, but just give a way to deploy LibreOffice with this option out of the reach of the end user. The configuration can even keep the option visible by default, but should let us/admins hide it. Thank you -- Olivier Hallot Founder, Steering Commitee Member - The Document Foundation Voicing the enterprise need. Translation Leader for Brazilian Portuguese ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi, Jean-Baptiste Faure schrieb: Hi, Le 29/12/2010 23:59, Jonas Finnemann Jensen a écrit : If you need to remove cursor formula feature to implement your visual editor, that proves there is some defect in your implementation. Please, do not tell we do not need this feature when you do not know how to implement your visual editor without destroying it. As I said position and selection synchronization between the two editors is possible. But it's not a priority of mine, fixing current bugs in the visual editor is :) If visual editor remove cursors synchronization (formula cursor), it is a bug. +1 Note: That the visual editor is still an experimental feature, and not enabled by default! If the visual editor causes regressions in a magnitude worth talking about we can take that discussion when it's declared stable... I prefer to alert you before... +1 [..) For me the current formula editor is already easy-to-use. However it will be more easy to use if the command window was able to show the complementary braket or brace. It would be very useful when you have complex formulas with several levels of group brakets to write. That would be great indeed. My additional wish for the editor is an insert special character dialog. The workaround with copying from Writer is cumbersome. (Aside from that I have a lot of other wishes, for example: Free choice of color, nice scaling integral sign, easier way to add new symbols, alignment to equal sign in stacks and matrices, inheritance of font size from environment or style.) Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi Jonas, On 2010-12-29 at 20:06 +0100, Jonas Finnemann Jensen wrote: One feature is already lost. I fear more regressions. If you disable experimental features, everything is back to normal. And position and selection synchronization can be fixed before this feature is enabled by default... Assuming someone cares to implement it... and you're are welcome to step up to the plate :) Do we have it among the Easy Hacks? If not yet - can you please add it there? :-) I hope we can agree that a visual editor, where the old command text interface is still available, is a good idea... And a great improvement to many users... Especially those migrating from Microsoft Office. Yes; I support this :-) Thank you a lot, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi, Le 30/12/2010 01:14, Regina Henschel a écrit : Hi, Jean-Baptiste Faure schrieb: Hi, Le 29/12/2010 23:59, Jonas Finnemann Jensen a écrit : If you need to remove cursor formula feature to implement your visual editor, that proves there is some defect in your implementation. Please, do not tell we do not need this feature when you do not know how to implement your visual editor without destroying it. As I said position and selection synchronization between the two editors is possible. But it's not a priority of mine, fixing current bugs in the visual editor is :) If visual editor remove cursors synchronization (formula cursor), it is a bug. +1 Note: That the visual editor is still an experimental feature, and not enabled by default! If the visual editor causes regressions in a magnitude worth talking about we can take that discussion when it's declared stable... I prefer to alert you before... +1 [..) For me the current formula editor is already easy-to-use. However it will be more easy to use if the command window was able to show the complementary braket or brace. It would be very useful when you have complex formulas with several levels of group brakets to write. That would be great indeed. My additional wish for the editor is an insert special character dialog. The workaround with copying from Writer is cumbersome. +1 (Aside from that I have a lot of other wishes, for example: Free choice of color, nice scaling integral sign, easier way to add new symbols, alignment to equal sign in stacks and matrices, inheritance of font size from environment or style.) +100 :-) And a fix for http://www.openoffice.org/issues/show_bug.cgi?id=66848 Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Formula cursor : bug or feature ?
Hi Regina, On 2010-12-30 at 01:14 +0100, Regina Henschel wrote: For me the current formula editor is already easy-to-use. However it will be more easy to use if the command window was able to show the complementary braket or brace. It would be very useful when you have complex formulas with several levels of group brakets to write. That would be great indeed. My additional wish for the editor is an insert special character dialog. The workaround with copying from Writer is cumbersome. (Aside from that I have a lot of other wishes, for example: Free choice of color, nice scaling integral sign, easier way to add new symbols, alignment to equal sign in stacks and matrices, inheritance of font size from environment or style.) Go ahead and file all these to the Easy Hacks too! :-) And please - don't bash Jonas for the great work he's done, I am sure he aims to make it perfect for everyone; file bugs, or add Easy Hacks instead. BTW - enabling the incomplete features... It is the only way to get more interest in them, early feedback [as actually shown in this thread too ;-)], and more people actually hacking on them. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] online registration menu element - 404
Hi Bernhard, On 2010-12-30 at 02:16 +0100, Bernhard Dippold wrote: But there already has been a thread on the marketing list (IIRC) asking for an improved user feedback in future - probably quite helpful for marketing and UX. If such a feature can be based on the present code, I don't know if it is reasonable to remove it completely. Redirecting to a webpage is a few lines of code, nothing that cannot be revived quickly should the need be :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for review: bug 32427
Hi Norbert, all,
On 2010-12-21 at 10:18 +0100, Jan Holesovsky wrote:
Good point - actually, the easiest / best might be to enclose the entire
call into '(' and ')', and add '' to that? Ie. it'd result into
'( firefox something ) '. Any objections?
Updated patch attached to
https://bugs.freedesktop.org/show_bug.cgi?id=32427
Can you / anybody else please check it apply it to libreoffice-3-3?
Thank you,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Annoying cursor behavior on sw tables
On Wed, 29 Dec 2010 05:37:31 -0800, Jan Holesovsky ke...@suse.cz wrote: On 2010-12-23 at 21:07 -0800, Octavio Alvarez wrote: There is this really annoying behavior: 0. Open Writer. 1. Create a table, say 3 x 3. 2. Place the cursor in a cell. 3. Type some text, like asdfasdfasdfasdf. 4. Using the mouse, place the cursor in the middle of the asdf-word. 5. Using the keyboard go left and right and left and right... [...] if( IsTableMode() ) return bLeft ? GoPrevCell() : GoNextCell(); -SwCallLink aLk( *this );// Crsr-Moves ueberwachen, evt. From what I see, it does most of its work in a destructor, so this looks like a kind of 'guard' that restores/updates stuff when the SwCallLink instance is destructed. Either way; I'd try to revert the callnk.cxx changes from commit 47472e8e70c1ae3dc55a5b00ef69eaa85f651a7f, it has something to do with tables, and see if you still see the problem. If not, then it might limit the scope of your debugging to that commit only. Hopefully I am not misleading you :-) Indeed, reverting the commit did the trick. Now, look at this, this blog post documents the patch: :-O http://cedric.bosdonnat.free.fr/wordpress/?p=472 The thing is that Window::Invalidate() gets called if I move or if I type inside a table cell, which almost any key triggers, which is wrong. bUpdatedTable gets set to True inside SwCallLink::~SwCallLink() after some tests. Another option would be to correct those tests, but that would be far beyond my knowledge. Considering the above blog post from cbos I removed the Invalidate() and tested inserting a 1x1 table inside the cell of another 1x1 table and it seemed to work and update correctly and open the collapsed cell if I place the cursor inside it (by pressing Left or Right, for example). It closes back again if I go outside the empty cell. Now, do we really need these lines? I tested saving and loading a file and also using the main window. It worked. I saw no side effects, and my problem gone, but then again, I really don't know what problems am I looking for. I also don't know when else may a problem arise... diff --git a/sw/source/core/crsr/callnk.cxx b/sw/source/core/crsr/callnk.cxx index ea998fe..cabef45 100644 --- a/sw/source/core/crsr/callnk.cxx +++ b/sw/source/core/crsr/callnk.cxx @@ -143,9 +143,6 @@ SwCallLink::~SwCallLink() } } -if ( bUpdatedTable ) -rShell.GetWin( )-Invalidate( 0 ); - xub_StrLen nCmp, nAktCntnt = pCurCrsr-GetPoint()-nContent.GetIndex(); USHORT nNdWhich = pCNd-GetNodeType(); ULONG nAktNode = pCurCrsr-GetPoint()-nNode.GetIndex(); BTW, thanks for your help, Kendy, and thanks for the translations, Pascal. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Refreshing some OxygenOffice related patches
Hi All, I attaching two patch that: * refreshing some OxygenOffice related patches * disable few OxygenOffice only patches from apply file Please review it and apply. Best regards, KAMI From 89bdf591bfb4298499bbe37f606e8a53bf845654 Mon Sep 17 00:00:00 2001 From: Kalman Szalai - KAMI kami...@gmail.com Date: Thu, 30 Dec 2010 08:10:27 +0100 Subject: [PATCH 1/2] Update OxygenOffice sections in apply file --- patches/dev300/apply | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/patches/dev300/apply b/patches/dev300/apply index 9f4e017..f91d417 100755 --- a/patches/dev300/apply +++ b/patches/dev300/apply @@ -1778,7 +1778,7 @@ unit-sc.diff [ OxygenOfficePalettes ] palette-enhanced-arrow.diff -palette-enhanced-color.diff +## palette-enhanced-color.diff palette-enhanced-dash.diff palette-enhanced-gradient.diff palette-enhanced-hatch.diff @@ -1829,14 +1829,14 @@ always-create-backups.diff captionnumbering-hu.diff, i#110273, timar [ OxygenOfficeExtras ] -extras_wizard.diff +## extras_wizard.diff # Add our macros stuffs to wizard module -premium_macro_build.diff -premium_macro_dialog.diff -premium_macro_script.diff -premium_macro_target.diff +## premium_macro_build.diff +## premium_macro_dialog.diff +## premium_macro_script.diff +## premium_macro_target.diff # Add menu elements for Users guide -helpdocument-genericcommand.diff +## helpdocument-genericcommand.diff # Uniformize Help menu of us helpdocument-menubar.diff @@ -1954,7 +1954,7 @@ base64.diff, i#100620, hmth [ OxygenOfficeDefaultSettings ] #Create langpack and full installers -ooop-langpack-policy.diff +## ooop-langpack-policy.diff [ OOXMLExport ] # hack to ignore writerfilter when odf-converter is present -- 1.7.1 From 71a07cacc10d139d761671b29727cc0dfd6055f5 Mon Sep 17 00:00:00 2001 From: Kalman Szalai - KAMI kami...@gmail.com Date: Thu, 30 Dec 2010 08:12:19 +0100 Subject: [PATCH 2/2] Make some OxygenOffice patches apply again --- patches/dev300/helpdocument-menubar.diff | 486 ++--- patches/dev300/ooop-splash.diff | 20 +- patches/dev300/ooop-win32-installer-branding.diff | 16 +- 3 files changed, 245 insertions(+), 277 deletions(-) diff --git a/patches/dev300/helpdocument-menubar.diff b/patches/dev300/helpdocument-menubar.diff index bf983db..c6b4ba5 100644 --- a/patches/dev300/helpdocument-menubar.diff +++ b/patches/dev300/helpdocument-menubar.diff @@ -1,184 +1,215 @@ basctl/uiconfig/basicide/menubar/menubar.xml.orig 2007-08-10 19:03:30.0 +0200 -+++ basctl/uiconfig/basicide/menubar/menubar.xml 2007-09-12 15:16:03.567590800 +0200 -@@ -79,9 +79,15 @@ - menu:menu menu:id=.uno:HelpMenu - menu:menupopup - menu:menuitem menu:id=.uno:HelpIndex/ -+menu:menuseparator/ - menu:menuitem menu:id=.uno:ExtendedHelp/ -+menu:menuitem menu:id=.uno:HelpTip/ -+menu:menuitem menu:id=.uno:ActiveHelp/ -+menu:menuseparator/ -+menu:menuitem menu:id=.uno:HelperDialog/ - menu:menuseparator/ - menu:menuitem menu:id=.uno:HelpSupport/ -+menu:menuitem menu:id=macro:///Premium.OOoHelpDocumentation.OpenHelpDocument/ - menu:menuitem menu:id=.uno:OnlineRegistrationDlg/ - menu:menuseparator/ - menu:menuitem menu:id=.uno:About/ chart2/uiconfig/menubar/menubar.xml.orig 2007-08-10 19:06:32.0 +0200 -+++ chart2/uiconfig/menubar/menubar.xml 2007-09-13 07:09:07.559364300 +0200 -@@ -140,9 +140,15 @@ - menu:menu menu:id=.uno:HelpMenu - menu:menupopup - menu:menuitem menu:id=.uno:HelpIndex/ -+menu:menuseparator/ - menu:menuitem menu:id=.uno:ExtendedHelp/ -+menu:menuitem menu:id=.uno:HelpTip/ -+menu:menuitem menu:id=.uno:ActiveHelp/ -+menu:menuseparator/ -+menu:menuitem menu:id=.uno:HelperDialog/ - menu:menuseparator/ - menu:menuitem menu:id=.uno:HelpSupport/ -+menu:menuitem menu:id=macro:///Premium.OOoHelpDocumentation.OpenHelpDocument/ - menu:menuitem menu:id=.uno:OnlineRegistrationDlg/ - menu:menuseparator/ - menu:menuitem menu:id=.uno:About/ framework/uiconfig/startmodule/menubar/menubar.xml.orig 2007-08-10 19:09:20.0 +0200 -+++ framework/uiconfig/startmodule/menubar/menubar.xml 2007-09-12 15:16:03.661342000 +0200 -@@ -72,12 +72,19 @@ - menu:menu menu:id=.uno:HelpMenu - menu:menupopup - menu:menuitem menu:id=.uno:HelpIndex/ -+menu:menuseparator/ - menu:menuitem menu:id=.uno:ExtendedHelp/ -+menu:menuitem menu:id=.uno:HelpTip/ -+menu:menuitem menu:id=.uno:ActiveHelp/ -+menu:menuseparator/ -+menu:menuitem menu:id=.uno:HelperDialog/ - menu:menuseparator/ - menu:menuitem menu:id=.uno:HelpSupport/ -+menu:menuitem menu:id=macro:///Premium.OOoHelpDocumentation.OpenHelpDocument/ - menu:menuitem menu:id=.uno:OnlineRegistrationDlg/ -
