Re: [Libreoffice] [GSOC] how to call python code from the menu
On Tue, 2011-08-16 at 19:29 +0200, Xisco Faulí wrote: Thank you for pointing out this file but I don't really understand how it works. The wizard is called here : http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu#441 where MailMergeWizard is the service register in Writer.xcu ( http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Writer.xcu#30 ) but then I the case of mailmerge the thing that the menus calls then goes on to call the mailmerge service, so the menus don't call it directly. I imagine your example to call a python service directly from the menus is correct, except that the service you want to call needs to be registered first. how libo knows that this service refers to mailmerge.py ? http://opengrok.libreoffice.org/xref/core/scripting/source/pyprov/mailmerge.component is the magic bit which connects uses of the com.sun.star.mail.MailServiceProvider service to the mailmerge.py implementation. With these .component files I imagine that if you basically opengrok for mailmerge.py and mailmerge.component and follow the same pattern for your one that it'll get you a lot closer. Your current code is in a feature branch ?, which one ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Base fdo#40079 file / save (as) inoperant
Hi Lionel On 16/08/11 17:32, Lionel Elie Mamane wrote: Two questions, a) did you try this on master No, not yet. no problem ( I did and it appeared to work as expected ) but I am pretty 'base' disabled so I fear I may have missed something in trying to recreate it You have to be very cautious what you do to reproduce it, it is fragile: for example, if you open the Basic IDE, you have lost, as this, according to my testing, leads to the Dialog library having been loaded at the point I patch. I think I did it right then, but.. ok worth trying again I suppose, also I rebuilt a fresh 3.4 that at least can now open a database file so I will try there again with the same instructions lso should not be empty; it should contain at least one dialog. Which leads me to another bug: If I remove the librarie's only dialog and save, I restart LO, I reopen the file again, the dialog is back. If the library has two dialogs and I delete one, it is gone after a save and reload. This seems to be Base-specific. probably worth opening another bug for that then, anyway, lets look at one thing at a time ( otherwise I will get depressed ) b) is this behaviour specific to base documents? Well, this bug is, but that is because the other apps have another bug that hides this one :-( My testing shows that SfxDialogLibraryContainer::storeLibrariesToStorage aborts at the same place for a calc document (an exception is raised), but this does not abort the save. Thus, logically, in the conditions where this bug shows up, Calc looses the embedded images what are the steps to reproduce this? ( hopefully it is reproducible ) this sounds bad in Dialogs. This is tested. And I guess also looses (the changes to?) anything that is saved *after* the Dialogs, if anything is (this is not tested). thanks again Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANNOUNCE] Branch libreoffice-3-4-3 created
Hi all, there have been created the libreoffice-3-4-3 branch. It will be used for fine tuning of the 3.4.3 bugfix release. It is based on the tag libreoffice-3.4.3.1 for 3.4.3-rc1 release. The following rules apply: + preferably just translation or blocker fixes + only cherry-picking from libreoffice-3-4 branch + 2 additional reviews needed; 2nd reviewer pushes + no regular merges back to anything The 'libreoffice-3-4' branch is still active, will be used for the next bugfix release (3.4.4). Please read more at http://wiki.documentfoundation.org/ReleasePlan http://wiki.documentfoundation.org/Development/Branches Now, if you want to switch your clone to the libreoffice-3-4-3 branch, please do: ./g pull -r ./g checkout -b libreoffice-3-4-3 origin/libreoffice-3-4-3 Hopefully it will work for you :-) Most probably, you will also want to do (if you haven't done it yet): git config --global push.default tracking When you do git push with this, git will push only the branch you are on; e.g. libreoffice-3-4-3 when you have switched to it. This will save you some git shouting at you. Happy hacking, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC] merged library
On Aug 16, 2011, at 8:13 PM, Matúš Kukan wrote: - There are more objects with the same name in different modules. So, is it possible to create one object file for each module and make these variables, classes.. invisible outside object file and then create big library from them? I would guess it's not possible and we have to rename or get rid of them somehow? I assume with objects in the first sentence you mean named C++ entities like classes and functions, not linkable object files, right? In that case, there might be three different solutions: Either, the same-named entities are more or less copies of each other. In that case, the best fix would be to fold them into a single instance (but that of course can be somewhat difficult as long as your changes are BIGSVX conditional.) Or the same-named entities are different things, in which case either C++ namespaces or renaming would help (and the latter is preferable if it helps avoid confusion). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Graphite 1.0.1
Petr Mladek wrote: I guess that you need it with the md5sum prefix, so I uploaded it as http://download.go-oo.org/src/3c6b8de6b75eee445b29f1de5fe01f02-graphite2-1.0.1.tgz Seeing this - we've recently moved to http://dev-www.libreoffice.org/src for external source tarballs. Didn't find 3c6b8de6b75eee445b29f1de5fe01f02-graphite2-1.0.1.tgz at the quoted place, but 3115c721f5cb7c464f01c2dddccfaba6-graphite2-1.0.2.tgz - and copied that over. Cheers, -- Thorsten pgp4PCIOfptPJ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix missing DESTDIR variable in chmod call
Should be applied to master and 3-4-3 branch for which we need two more sign offs. So please review/ack :) From 989934ab08a5ef9e6e95c87ea78db495f2abcee4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Chv=C3=A1tal?= tchva...@suse.cz Date: Wed, 17 Aug 2011 11:33:55 +0200 Subject: [PATCH] Fixup non-respecting DESTDIR for DOCDIR chmod. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Tomáš Chvátal tchva...@suse.cz --- bin/distro-install-clean-up |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bin/distro-install-clean-up b/bin/distro-install-clean-up index df7ac9d..229b7e8 100755 --- a/bin/distro-install-clean-up +++ b/bin/distro-install-clean-up @@ -59,7 +59,7 @@ if test -f $DESTDIR$INSTALLDIR/help/en/sbasic.cfg -a \ fi echo Fixing permissions... -for dir in $DOCDIR $DESTDIR$INSTALLDIR/basis$PRODUCTVERSION/sdk/examples ; do +for dir in $DESTDIR$DOCDIR $DESTDIR$INSTALLDIR/basis$PRODUCTVERSION/sdk/examples ; do if test -d $dir -a -w $dir ; then find $dir -type f \( -name *.txt -o -name *.java -o -name *.xml-o \ -name *.xcu -o -name *.xcs -o -name *.html -o \ -- 1.7.6 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] signed/unsigned comparison (was: [PATCH] Replace SvULongs with vector and code clean up part 1)
On Aug 11, 2011, at 12:22 PM, Lubos Lunak wrote: On Wednesday 10 of August 2011, Stephan Bergmann wrote: On Aug 10, 2011, at 12:31 PM, Lubos Lunak wrote: On Tuesday 09 of August 2011, Stephan Bergmann wrote: Technically, lostd::list is no longer a container, as it violates the requirement that the return type of size() is size_type. (And if you redefine size_type as int, as you should do anyway in the above sketch, it violates the requirement that size_type is an unsigned integral type.) Do you realize that as long as the list does not contain 2E9 items, which it does not, this does not matter at all? That's not my point. My point is that such an IMO hacky solution that tries to outsmart the language is probably not worth it. (Imagine a compiler that emits a warning if a class that does not meet the container requirements is used with one of the standard algorithms…) This scores really very very low on my scale of hackiness. Can you come up with an example that would be broken by this that would not be more hacky on its own? And actually, there is even nothing wrong with it technically. If you use the class with anything that requires size_t to be unsigned, you use the class as std::vector, and there size_t is unsigned. It's only the wrapper that is signed. BTW, Qt has been doing this since at least Qt4.0 (see http://doc.qt.nokia.com/4.7/qvector.html#size_type-typedef) and apparently has been getting away with it nicely. There used to be exactly the same annoyances with older Qt and probably most people by now even don't even know there could be a problem with anything. I see. I'm still not convinced, though. For one, there are more uses of unsigned in the C/C++ ecosystem than std::vector::size_type, so there are potentially many more places in the code where you have to be aware of and be prepared to properly handle issues of signed/unsigned mismatch. For another, replacing standard functionality with its own invention (even if its only a wrapper) is something the OOo code base has often been criticized for (and often rightly so, IMO). But, sure, YMMV. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANNOUNCE] libreoffice-3.3.4.2 tag skipped (3.3.4-rc2)
Fridrich Strba schrieb: no changes have been committed into the libreoffice-3-3-4 branch. Hi, no Bug reports at all, so I will modify Version 3.3.4-RC to 3.3.4 Release in few minutes. CU Rainer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Git tags: why not 3.3.4-rc2 instead of 3.3.4.2
Hello, I was wondering why the git tags are named `3.3.4.2` for 3.3.4-rc2 instead of the more natural `3.3.4-rc2` or the more common `v3.3.4-rc2`. I am used to see 3.3.4.2 as the second bugfix release for 3.3.4, or, in more mathematical terms, 3.3.4.2 3.3.4 = 3.3.4.0. I hope 3.5-rc1 will not be tagged as 3.5.1. Is this behaviour a leftover of the SVN workflow? Could it be changed? Best, -- Gioele Barabucci gio...@svario.it ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] [PATCH] for Bug 32719
jeffrey chang wrote: Sorry for the delay. Here is the revised patch that fixes the dimension problem without all the rough scratch work/comments from last time. Hi Jeffrey, ah sorry, mixed up the two bugs - thanks Yifan for noting - templates indeed look much better with your fix, thanks a lot pushed it - maybe, if you've a bit more time, you could look into change 1d97771f1ea5dffc86a0fc5b1e1ec90a34553092 of sd/source/core/sdpage.cxx, which reworks the slide layout - my hunch would be, that this is causing the trouble. I also noticed that other templates, e.g. Characters with Glow now look slightly off (though not as bad as e.g. Keyboard was looking before) - maybe we'll need to fix the templates itself? Cheers, -- Thorsten pgpUyrgZybkIz.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Base fdo#40079 file / save (as) inoperant
On 16/08/11 17:32, Lionel Elie Mamane wrote: I disabled the export out any embedded image object code by adding a return; before it, and it does not loose the embedded images, even after restarting LO and re-opening the document. ( after refamiliarising myself with this code ) this behaviour is not at all expected. It seems that base documents are doing something strange ( well maybe better to say different ) here, in fact if you add, save and then remove some image controls ( with embedded images ) then the Picture streams are never discarded. With the other applications ( calc, writer etc. ) when you save you save you save to new storage and the storage content is regenerated from the document model so effectively the existing content is thrown away and recreated. In the case of basic of course some optimizations might occur like copying existing 'Basic' substorages to rather than writing to the target storage based on the in-memory libraries model. With that in mind and after doing a little testing I think your patch for loading the library in SfxDialogLibraryContainer::storeLibrariesToStorage is the simplest thing to do and should avoid any such problems in any other applications like the one you mentioned ( that I cannot reproduce ) in calc. So I will push this ( and good job too tracking it down ) The issue with the leaking 'Picture/xx.png etc. streams still remains, I guess I would need to understand what base actually does when saving with the existing content to see what we can do there, probably it is just a case of excluding the Pictures directory rather than blanket copying stuff. thanks, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Check your affiliation ? ...
Hi guys, I just created a repo for Cedric's gitdm work: git clone git://anongit.freedesktop.org/libreoffice/contrib/gitdm-config Containing the config files we use to generate our affiliation and progress graphs / stats like these: http://blog.documentfoundation.org/2011/07/26/a-glimpse-at-our-developer-community/ So - if you want to get your affiliation 'right' there - ie. perhaps a load of our 'new contributors' are really working for 'ACME' then feel free to commit that to domain-map, and if you have multiple E-mail address aliases (you have used when committing) please update alias-map. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Cherry-pick in 3.4.2?
Hi Caolan, On Tue, 2011-08-16 at 14:26 +0100, Caolán McNamara wrote: On Tue, 2011-08-16 at 05:48 -0700, cbosdonnat wrote: All is now working fine, and that later commit could be applied to 3.4 safely. Sorry, not trying to be a pain or anything, but that assignment operator now leaks the original mpXPoly of the SdrRectObj that's assigned to if there was one. Ok, after some details on the list, this is an additional fix for this and Lubos' comment: http://cgit.freedesktop.org/libreoffice/core/commit/?id=62d38bed44404844d94ce09b9fb35b3369835c88 Thanks for the review. -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] fix for fdo#39850 and fdo#39820: update range names and database ranges in formula cells
Hi Markus, On Wednesday, 2011-08-17 07:23:42 +0200, Markus Mohrhard wrote: That was my intention. My idea was that we should create a global range name as default and not a local range name that points to the same cell. But after a talk to Kohei and your impression it seems that this is counter intuitive, so I'll change it. Yes, if one has a sheet local name and copies the sheet or parts thereof s/he expects the same structure. In a dbgutil build the shell displays Error: FormulaToken::SetIndex: virtual dummy called From File /lo/core/formula/source/core/api/token.cxx at Line 212 Can it be that a debug build does not include the dgbutil messages? Yes, that is independent from each other. Apparently the FormulaToken used is not a FormulaIndexToken. Oh. I should not only override SetByte but also SetIndex. In calc all formula tokens are derived from ScToken which is derived from FormulaToken and not from FormulaIndexToken. I should no longer finish patchs after learning.c Maybe that's due to some confusion when ScToken is actually used instead of the types provided in formula/*. The general formula/* implementation handles everything that doesn't need to access the document model or know about application details, ScToken derivates implement spreadsheet specific parts that need to know about addressing and such or use Calc data types. Actually the new ScNameToken implemented would belong to formula/* instead, but there is already FormulaIndexToken, which also now has changes for local/global names, so ScNameToken is superfluous and can be removed. ScRawToken::CreateToken() needs to be changed back to return a FormulaIndexToken. I think best is that I add a unit test before I push any further modifications in this area. Always good. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpUYc06Z5P4P.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Ctrl+D and Ctrl+R
Hi, On Monday, 2011-08-15 09:47:02 +0200, Cor Nouws wrote: In OpenOffice.org legacy, Ctrl-D shows the Selection list. In LibreOffice that is turned off by default, but can be influenced by Tools OPtions LibreOffice Calc Compatibility It's noteworthy that Ctrl+D is (was?) the only method to access a selection list for cell input (i.e. cell has a defined list where the user can choose a value from) via keyboard. If that is deactivated it has an accessibility impact. Did that change? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpPWGblpzKo3.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] - cherrypick to 3.4.2 Base fdo#40079 file / save (as) inoperant
On 15/08/11 13:10, Lionel Elie Mamane wrote: I've committed the patch to the 3.4 branch ( and master ), I've changed the subject to cherry-pick to 3.4.2 as this issue causes data loss and as such I think should go into the branch. 2 more acks needed Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [RFC] Download repository layout
Hi guys, current layout of the download stuff is quite confusing regarding to old/etc. As I am working on downstream stuff I am pretty sure that the only thing we mostly favor is that the things are not moved regarding to theirs age. Also quite great is if we don't have to investigate some branches and what version belongs where by using just name and the version everywhere. So without much ado the simplified layout that I myself find sane (and hopefully you will like it too): d.tdf.o - domain | \ - PACKAGENAME (if the hosted packages are more than libreoffice) | \ - latest (symlink to latest version folder) \ - PACKAGEVERSION (full package version like 3.4.3.1) | (the folders should be kept empty if we have nothing for version) \- src/ \- box/ \- deb/ \- rpm/ \- win/ \- mac/ Alternative: Swapping the version and src/win/mac folders. Cheers Tomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] - cherrypick to 3.4.2 Base fdo#40079 file / save (as) inoperant
eek I meant to put REVIEW in the subject On 17/08/11 14:12, Noel Power wrote: On 15/08/11 13:10, Lionel Elie Mamane wrote: I've committed the patch to the 3.4 branch ( and master ), I've changed the subject to cherry-pick to 3.4.2 as this issue causes data loss and as such I think should go into the branch. 2 more acks needed ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] XML pretty printer (was: Where did Setup.xcu go?)
On Thursday 11 of August 2011, Miklos Vajna wrote: On Wed, Aug 10, 2011 at 11:28:42PM +0200, Eike Rathke o...@erack.de wrote: For which I always recommend xmlpp, http://software.decisionsoft.com/tools.html Is this better in some aspect than xmllint --format, which cames with libxml and requires no manual installation? :) Xmllint --format silently(!) drops any xml content it cannot handle (e.g if the .xml has one closing tag missing). Xmlpp seems to handle that fine (the only minor problem I noticed is that it alters the original xml in harmless ways such as changing to ' or reordering attributes). If you need to deal with possibly broken XML, I suggest to use http://cgit.freedesktop.org/libreoffice/build/tree/scratch/formatxml.cpp . It handles even malformed XML, it does not alter the contents in any way except for indenting it and explicitly marking problems in the XML structure with an easily visible comment. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Gtk3 button rendering
Hi Lucas, On Tue, 2011-08-16 at 21:13 +0200, Lucas Baudin wrote: Here is a patch to render gtk3 button correctly. I send it now because I won't have internet until tuesday, and it would be a bit stupid if anyone made the same thing... So, you are aware that the patch exists, if you need it :) Hey :-) That's fine - hope you had a great break. So, there are some warnings about unused variables, of course, they will be used later. I didn't split drawNativeControl(), but I suppose it will be necessary later. Great - so, some quite intense gtk3 work is happening in the feature/gtk3 branch - which is where I've merged your patch - thanks for that ! incidentally, I disabled it in IsNativeControlSupported with a #ifdef since I had a few issues with my theme prelight / highlight etc. I don't know if it is worth to apply it now (it is not finished at all), but it is under GPLv3+/MPL. Of course ! :-) good to get it in. I will try to complete to work again on gtk3 next week... I look forward to that :-) I'm working actively on feature/gtk3 but not so much in this area: more core re-factoring and porting away from the X code. Thanks ! Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] UNO API reference?
At 3:59am -0400 Tue, 16 Aug 2011, Cor Nouws wrote: Kevin Hunter wrote (16-08-11 01:07) Do we have, or is there a canonical reference for the UNO API? Specifically with Python bindings? The various references I've been able to find online seem haphazard at best. Is that what we have to work with, or is there an obvious link I've overlooked? The obvious (start for) reference of course is http://api.openoffice.org/ So I guess you must have investigated that one.. Yes, I've investigated that site; it doesn't seem terribly fruitful. Perhaps I'm not clicking the right links? I'm looking for a few things that I don't currently see, like - Code snippets for all the UNO API language bindings. I see a few, for the likes of Java, OOBasic, and ooRexx, but they harken back to 2.0 and 1.1 days. Further, Since the API has multiple language bindings, I'm looking for more than just those 3. For instance, I see barely six examples for CPP, six for Python, etc. - Complete object and method listing. One of the things I currently lack is the grander idea of what I can do with the API. Generically I understand that it's a lot, but I don't know how to access most of it. - Complete, self-contained code examples. There are above-mentioned code snippets, perhaps, but complete, downloadable examples that show off a particular functionality would be incredibly useful. I'm trying to ascertain what resources are available to me while I hack away at LO, and just those three items would be tremendous. Do these exist? Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] UNO API reference?
On Wed, 2011-08-17 at 10:18 -0400, Kevin Hunter wrote: At 3:59am -0400 Tue, 16 Aug 2011, Cor Nouws wrote: Kevin Hunter wrote (16-08-11 01:07) Do we have, or is there a canonical reference for the UNO API? Specifically with Python bindings? The various references I've been able to find online seem haphazard at best. Is that what we have to work with, or is there an obvious link I've overlooked? The obvious (start for) reference of course is http://api.openoffice.org/ So I guess you must have investigated that one.. Yes, I've investigated that site; it doesn't seem terribly fruitful. Perhaps I'm not clicking the right links? I'm looking for a few things that I don't currently see, like http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide http://www.pitonyak.org/book/ and http://wiki.services.openoffice.org/wiki/Python are about as good as it gets at the moment I think (?) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Tinderbox failure... not mine!
On Wed, Aug 17, 2011 at 1:26 PM, Lionel Elie Mamane lio...@mamane.lu wrote: On Wed, Aug 17, 2011 at 04:36:03PM +, nthieb...@gmail.com wrote: One of you broke the build of LibreOffice with your commit :-( Please commit and push a fix ASAP! That's plainly wrong. The build log for the version for the previous green build is chokefull of errors. I suspect a build system or tinderbox bug that fails to detect that the build failed. The previous 'green' build should not have been green indeed... I'll try to figure out what happened here (I suspect a bad return code hidden in a production rules somewhere in make...) that being said you would still have been spammed for the next commit, since the tinderbox send email to all committer since the last 'good' commit. Full log available at http://tinderbox.libreoffice.org/MASTER/status.html Tinderbox info: Box name: MacOSX 10.6.7 Intel no-moz Machine: Darwin tpamac.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 Configured with: --with-distro=LibreOfficeMacOSX --with-max-jobs=8 --with-num-cpus=6 --disable-mozilla --enable-werror --enable-epm --disable-systray Commits since the last success: core 0c34093 TMP_LIONEL_NOTES d6ed363 Overhaul BerkeleyDB detection logic Oh, $SWEAR_WORD. The TMP_LIONEL_NOTES commit was *not* supposed to be pushed (it adds TODO notes for myself as comments). I'm terribly sorry about that. Well, now it is in the LO-history for all eternity :-D you way want to push a patch to remove it though... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Bugzilla handling of multiple branches
Hi, I don't see any way in bugzilla to say things like: bug present / not present in master / libreoffice-3.4, ... bug fixed / not fixed in master / libreoffice-3.4, ... There is only *one* version field, and *one* status field, not one per branch. So I don't know when to close a bug. When it is fixed in master? When it is fixed in all branches where we want it fixed? For example, bug #40079; it is fixed in master, so I closed it. But now it shows up as not blocking LibreOffice 3.4 most annoying bugs anymore (it is striked out), which is incorrect since it is not fixed in 3.4. How do we handle these things? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] duplication of ItemHolder2
On Wed, 2011-08-17 at 19:38 +0200, Matúš Kukan wrote: [snip] So, can I just rename ItemHolder2 in svtools to ItemHolder3 ? I have a vague memory from the times of OpenOffice.org of a numeric suffix on a name indicating the number of template parameters. Templates with Helper in the name, perhaps? If (IF, mind you) that vague memory is correct, I wonder whether a different convention for naming the new class might avoid confusion down the road? Or are we beyond that decision point? Terry. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bugzilla handling of multiple branches
Shouldn't it be backported in this case? ... 2011/8/17 Lionel Elie Mamane lio...@mamane.lu Hi, I don't see any way in bugzilla to say things like: bug present / not present in master / libreoffice-3.4, ... bug fixed / not fixed in master / libreoffice-3.4, ... There is only *one* version field, and *one* status field, not one per branch. So I don't know when to close a bug. When it is fixed in master? When it is fixed in all branches where we want it fixed? For example, bug #40079; it is fixed in master, so I closed it. But now it shows up as not blocking LibreOffice 3.4 most annoying bugs anymore (it is striked out), which is incorrect since it is not fixed in 3.4. How do we handle these things? -- Lionel ___ 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] duplication of ItemHolder2
Hi Matúš,
On Monday, 2011-08-15 13:50:44 +0200, Matúš Kukan wrote:
I'm trying to build bigger libraries
What would be the benefit of that in this specific case?
but I have small problem with ItemHolder2.
It's implemented in svl/source/config/itemholder2.cxx and also in
svtools/source/config/itemholder2.cxx.
The one in svtools seems to be more general but svtools's library is
linking against the svl one.
They implement exclusively different sets regarding the items of the
configuration parts in {svl,svtools}/source/config/
Maybe history sheds some light here: svl was factored out from svtools
and contains the parts that do not need vcl. I think lumping them
together again actually is not a good idea.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
pgp58AlB3tkXQ.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to call from one component to another (sw-starmath)
Hi Lubos, On Tue, 16 Aug 2011 12:09:19 +0200 Lubos Lunak l.lu...@suse.cz wrote: No, starmath doesn't need to call back to writer. The problem is that this is still needlessly complicated. How about the attached patch? While it works, I would prefer if the 10.000-feet-view of the project stays reasonably understandable as the codebase as is is already hard enough to grok -- esp. for newcomers. One of the few sane structurings of the codebase is: http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/Dependencies#Office_modules which certainly could use improvement, but tearing it down without having resources and a good plan for a better structure is not a good idea IMHO. So why not go with Caolans proposal? Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] feature/gsoc2011_wizards from components migrated from components to core
Hi Xisco, Hi Norbert, all, I migrated the feature/gsoc2011_wizards branch from components to core. While that should have been a simple git format-patch/git am combo with a bit of manual fudging for the merge commits: 9e91dbca08056fc31f388f5642fdfa3d2b910990 e52421bc118e9c5f3fce5a32ba9efdcad7627d92 It unfortunately turned out to be a bit more, mostly because of commits from the components repo: 002da0a3abe9e60f5c07105839b53008182f171a 811df4a1faed5f6b6527c6cbd34f3dd720ecfcfc a17a95aeab757e35240c7cbfd720b9586f1422ee 7e87b3f97b9ccb83dbe70fc213cdda50718225f2 d32fd9c1046b42da3d0d4141047aed8bd4f6d481 7f8fd4372bba6fde150d32ad07ca96b032d077e1 0245c6d17aa378e2d563ce0a50ee8ce14517f195 d9a8459a5e80e648440a71a245809736b77b88e1 7d23e260cce288878b61e78a1db523b7678ba299 to the branch, which seem to have been manually applied or copied/cherrypicked from master (Why? Esp. since most seem to be trivial and unrelated nonvital changes). These failed to apply, so I copied the dirstate of touched files after the commit from the old repo over to the new repo commit. This likely re-introduced broken whitespace (i.e. unfixed by Norberts whitespace fixer). Anyway: feature/goc2011_wizards in core now has the same dirstate in wizards as it had in components (modulo some missing linefeeds before EOF which where automagically fixed). As for the broken whitespace reintroduction: The whitespace fixer should be run again over all files touched by commits(*): 7bd40550a45e1013efaeec0a93ab152329254fc1 1cf8feb7da1b3188e0800e3f46abe9cfab55114b d3318788b34f6c570dff9f3a969ab4182f127b0e 326324dd764385d21754aaa2e7fc196386eb4729 0234a75db73b215d5212d140f6346d6842364ae4 34390079fef2c02bc2bf0b1c336759afb49a7477 583e72a8c49d3eee7679056f9b0178002e39f54a efc03133b105af9e4b16e2f4b8797395f0ba6fde d9db3380ec68c367955234f32ec66e2f6c9850d0 before the branch gets merged to master, so that we dont make master dirty again by that. Best, Bjoern (*) which are the corresponding commits to those mentioned above in the core repo -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Mutex(Guard) ignores failure to create/acquire Mutex
Hi, I noticed that Mutex(Guard) C++ helper classes silently ignores failures to create / acquire / release / destroy a mutex, which seems rather worrying: if one puts a mutex acquire, it means the rest of the code should not execute if the mutex was not acquired, lest subtle bugs crop up (corruption of thread-shared variables and all that). So my natural tendency would be to make create (in Mutex::Mutex) and acquire (in Guard::Guard, ResettableGuard::reset, etc) errors hard errors by throwing a RuntimeException; that is, obviously, unless the file is compiled without exception support, in which case... we fallback to the current behaviour? Or rather an OSL_FAIL? Release errors in a MutexGuard destructor cannot be an exception, so an OSL_FAIL. The Mutex/MutexGuard classes are implemented 100% in header file, so they can adapt to the compilation options of the file they are used in, and it seems the LO build system nicely defines EXCEPTIONS_ON or EXCEPTIONS_OFF to give that information. Opinions? Any reason this is a bad idea? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
