Re: [Libreoffice] A (new?) bug in LibreOffice 3.4 and a missing feature?
On Fri, 03 Jun 2011 09:35:06 +0200 Axel Reimer lopar...@fpgas.de wrote: 2. There is mentioned a unity integration in the release notes of 3.4. But the menus do not integrate in the global menu and I cannot find an option in LibreOffice to do so. Is this feature really integrated? see also: http://wiki.documentfoundation.org/ReleaseNotes/3.4#GUI The status of this is: - the code has been moved upstream to LibreOffice. - it is disabled in the default build (so also in the build done upstream). - Ubuntu will enable this in its build, but on Oneiric you would still need a (new) lo-menubar package installed to activate it in the install as there are quite a few problems with it still, see: https://bugs.launchpad.net/ubuntu/+source/lo-menubar Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Results from LibreOffice TSC call, Thur June 2nd - 14:00 UTC
Hello, following an advice from Petr Mladek I would like to ask you to have a look on http://wiki.documentfoundation.org/User:RBd/LibO_Extensions_Repository (considerations concerning own Extensions repository) and http://wiki.documentfoundation.org/User:RBd/Improve_Bug_Tracking_System (considerations how to improve our bug tracking system). Thank you and best regards Rainer Bielefeld ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 --- Comment #138 from Petr Mladek pmla...@suse.cz 2011-06-06 03:06:40 PDT --- (In reply to comment #133) I suggest adding this https://bugs.freedesktop.org/show_bug.cgi?id=37516 and fixing if in 3.4.1 release It has already been added few days ago. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Petr Mladek pmla...@suse.cz changed: What|Removed |Added Depends on||37930 --- Comment #139 from Petr Mladek pmla...@suse.cz 2011-06-06 03:09:32 PDT --- (In reply to comment #134) I nominate bug 37930 : it is a crash with the filepicker of Seven/Vista when you insert an hyperlink. Yup, it deserves to be here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Proposal to join Apache OpenOffice
On Saturday 04 of June 2011, Kohei Yoshida wrote: On Fri, 2011-06-03 at 22:06 -0400, Allen Pulsifer wrote: So here is my suggestion: I propose the everyone here head over to the Apache Incubator and join the proposal as an initial member. Just so you know, I've been following that thread on the Apache list by reading the archives, pretty much fully, so I have a pretty good idea of what's going on over there. Just FWIW, I've been following the thread too, and I fully agree with all Kohei's conclusions. I can probably sum it in an even shorter way as the possible choices: - merging as LO - that'd require that all Oracle, IBM and ASF would be willing to do that, which seems unlikely (Oracle or Apache may be irrelevant in this list depending on the state of the rights transfer). - merging as OOo - that'd require that a significant number of us is willing to go with the Apache license and that we find it worthwhile to merge our 8 months of work back. Note that while we've been merging periodically from OOo they haven't been doing the same back, so it'd be presumably a lot of work (including persuading them that are changes are right), and if the only other OOo contributor would be IBM, who so far hasn't contributed that much to OOo, it just may not be worth it. It'd also mean that we work inside ASF, i.e. according to ASF rules (Apache lincense only, SVN as repository, ...), and the Apache OOo project is at the very beginning. I don't know how many people would refuse to go with the Apache License, but even the technical cost is IMO not worth it at the time being. - LO and OOo cooperating - that would be even more work than the item above, as we'd need to do that continually, for, at the present time, unsure gains. If OOo manages to pull it off and actually provide any value, we may reconsider it at any later time. So I would suggest that you sign up as Apache OOo contributor only if that is actually what you want and not for some false reasons like 'we need to get involved now or it'll be too late'. Pretty much everybody who's capable of non-trivial LO contributions should have no difficulty contributing to OOo too, unless ASF OOo would be suicidal enough to make contributing to OOo hard. In general I think we should continue working on LO and not get involved at this time at all. The situation seems to be the best realistic outcome and it seems we can't improve it, so let's be happy about it, but we should not drown our resources in something that has unsure future and value for us. If OOo improves enough to be worth our effort, we can always reconsider later. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Android versions that we will compile LO for
I am working with 2 other great individuals in regards to bring LO to android devices. The sdk has support for android version 1.5 all the way up to the latest 3.1 Question becomes what versions do we want to get cross compilation to work with? Having just come off a low level android project, I would suggest you target 2.3 as your earliest, at least until you have it working. Anything before that is fraught with problems and your mileage as to whether anything will work will vary. Yours, Martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Android versions that we will compile LO for
Thanks for the feedback martin :D ill remove the other apis i have installed for the time being :) On 06/06/2011 12:26 PM, Martin Hosken wrote: I am working with 2 other great individuals in regards to bring LO to android devices. The sdk has support for android version 1.5 all the way up to the latest 3.1 Question becomes what versions do we want to get cross compilation to work with? Having just come off a low level android project, I would suggest you target 2.3 as your earliest, at least until you have it working. Anything before that is fraught with problems and your mileage as to whether anything will work will vary. Yours, Martin ___ 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] Android versions that we will compile LO for
Hi, Martin and everybody I'm one of the great individuals Jonathan mentioned (although I'm not so great like he said :P). Our plans is to make an LibO version for tablets. Of course, Android API make it possible to tablet apps run on smartphones as well, but it affects our target version. Jonathan, I think it'd be better to target 3.0 for now. I think that most of the Android tablets will run 3.1 but, let's stick with 3.0 until we have good reasons to increase our minimum version. What do you think? Regards! -- Rodrigo http://www.rodrigocarvalho.blog.br Participe do I Hack'n Rio http://hacknrio.org/ On Mon, Jun 6, 2011 at 07:26, Martin Hosken mhos...@gmail.com wrote: I am working with 2 other great individuals in regards to bring LO to android devices. The sdk has support for android version 1.5 all the way up to the latest 3.1 Question becomes what versions do we want to get cross compilation to work with? Having just come off a low level android project, I would suggest you target 2.3 as your earliest, at least until you have it working. Anything before that is fraught with problems and your mileage as to whether anything will work will vary. Yours, Martin ___ 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] [REVIEW] Complete fix for fdo#32684
Hi all, On Mon, 2011-05-23 at 12:55 +0200, Cedric Bosdonnat wrote: That bug was badly fixed (by me) quite some times ago. Here is a correct fix (why did I add that code at all ?). Could you review it and push it in 3.4 and 3.4.0? More cleanup is needed but it'll end up in master: some options aren't used at all in that area. Any chance to get it reviewed for 3.4.1? Thanks, -- 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
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on||37488 --- Comment #140 from Rainer Bielefeld libreoff...@bielefeldundbuss.de 2011-06-06 04:19:56 PDT --- Nominate Bug 37488 - PRINTING result completely messed up, tables and DRAW objects crippled in WIN printouts. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] A (new?) bug in LibreOffice 3.4 and a missing feature?
On Mon, 2011-06-06 at 11:34 +0200, Bjoern Michaelsen wrote: - the code has been moved upstream to LibreOffice. - it is disabled in the default build (so also in the build done upstream). So - I personally love the idea of unified menus, and I'd love to have this turned on when unity is detected; surely that is not too difficult ? [ we already have a build/ patch to detect MeeGo and do similar throwing-babies-overboard ] ;-) - Ubuntu will enable this in its build, but on Oneiric you would still need a (new) lo-menubar package installed to activate it in the install as there are quite a few problems with it still, see: Ah - well, that is different :-) in which case, I concede that perhaps it is not the best plan if it doesn't work so well. ATB, 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] Performance improvements for calcs' sheet actions
On Sun, 2011-06-05 at 02:04 +0200, Markus Mohrhard wrote: I've been looking a bit further into the performance problem when dealing with several sheets and am now at the move method.(ScDocument::MoveTab) ;-) FWIW - document -load- used to cause way more progress-bar updating CPU cycles than it took to load the spreadsheet (the once-per-cell notification did that). I -believe- that I had a patch that used gettimeofday in the case that a visibly different value would be shown in the progress bar - so just one syscall per cell that sped that up a lot ;-) Then I think (for import), someone introduced a thread - that sat in 'usleep' so we could throttle any updates to one every half-second or so - which AFAIR was rather more efficient, and avoids a load of syscall related slowness. I -though- / hoped / etc. that that could be made more generic, so we could have a progress-bar class that is ~impossible to use badly; of course it mostly sucks to have a 'sleep' thread ;-) but ... it is only one at a time. So, I wonder if the UX guys don't mind us never updating a progress bar more than twice per second (say) [1] we could do this for all progress bars in one place. Clearly calling a FooProgres-update(percent) method a bazillion times is not slow, if we never re-draw anyway. Thoughts ? Michael. [1] - and I don't expect it to be configurable ;+) -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] A (new?) bug in LibreOffice 3.4 and a missing feature?
On Mon, 06 Jun 2011 12:36:00 +0100 Michael Meeks michael.me...@novell.com wrote: Ah - well, that is different :-) in which case, I concede that perhaps it is not the best plan if it doesn't work so well. It works well enough for the average home user to use it, but has enough bugs for the average admin of a 100 seats installation to hate us for it. Also, as is (with the lo-menubar being activated by a framwork job xcu), we (Ubuntu) in theory can still enable this one day before feature freeze for our release if it is stable enough by then -- without major changes to the (compiled) code. Unfortunately, it seems the real fix for some issues would require some major rework/redesign of the whole thing: moving at least parts to the vcl layer. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] fdo#37985 dialog layout issue
Hi, Can someone please review and cherry-pick to 3-4 this harmless patch that resolves a truncation issue in the Pivot Table creation dialog? http://cgit.freedesktop.org/libreoffice/calc/commit/?id=f4f929a6f7a8645956983c9c72a5590d0ceb7c2d Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Android versions that we will compile LO for
Dear Rodrigo, Our plans is to make an LibO version for tablets. Of course, Android API make it possible to tablet apps run on smartphones as well, but it affects our target version. Jonathan, I think it'd be better to target 3.0 for now. I think that most of the Android tablets will run 3.1 but, let's stick with 3.0 until we have good reasons to increase our minimum version. What do you think? Thanks for letting me revise my suggestion. Yes I think 3.0 as the minimum without crying if you have to go to 3.1 is the best course of action. 3.1 is in too much flux at the moment, so I wouldn't start there. And yes, it's pointless going back to 2.x because you are a tablet app. Yours, Martin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Как продать то, что не продаётся?
Как продать то, что не продаётся?Поможем увеличить продажи до 30%,Не получится, вернём деньги.Заходите и смотрите методику, увеличение продаж в Вашей компании http://uasem.com.ua/kak_prodat.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] question about image control
Hi,
I'm creating a new ToolPanel for my product.
I want to a an image which is the icon of a remote document, which can
be edited in LO.
I can't display image. If I inserted a button with the same image, the
button displays correctly the icon but not the controlImage.
What I've missed ?
Here's the portion of the code which add components.
Regards,
Ludovic SMADJA
Code start ***
Object btnControl = ControlHelper.createControl(mainPanel.getContext(),
UnoControlButton, 0, position, 20, fontHeight,
new String[]{ImageURL, BackgroundColor},
new Object[]{imgUrl, 0xff1234});
XControl xBtnControl = UnoRuntime.queryInterface(XControl.class,
btnControl);
searchResultPanel.addControl(img_ + i, xBtnControl);
Object imgControl = ControlHelper.createControl(mainPanel.getContext(),
UnoControlImage, 20, position, 20, fontHeight,
new String[]{ImageURL, BackgroundColor},
new Object[]{imgUrl, 0xff1234});
XControl xImgControl = UnoRuntime.queryInterface(XControl.class,
imgControl);
searchResultPanel.addControl(img2_ + i, xImgControl);
Object docControl = ControlHelper.createControl(mainPanel.getContext(),
UnoControlFixedText, 40, position, size, fontHeight,
new String[]{Label},
new Object[]{name});
XControl xDocControl = UnoRuntime.queryInterface(XControl.class,
docControl);
searchResultPanel.addControl(doc_ + i, xDocControl);
Code end ***
--
ludovic ludovic.sma...@jalios.com
JALIOS SA RD
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice licensing
- Original Message From: Jesús Corrius je...@softcatala.org To: michael.me...@novell.com Hi Michael, On Sat, Jun 4, 2011 at 6:11 PM, Michael Meeks michael.me...@novell.com wrote: On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer wrote: 1. TDF takes OOo under the Apache License and combines it with LO contributions under the LGPL/MPL and licenses the combined work (LibreOffice) under both the LGPL and MPL? So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting code would be under those (compatible) licenses. Which are copy-left. 2. A third party takes OOo under the Apache License and combines it with LO contributions under the MPL and proprietary closed-source code of its own to create a proprietary closed-source product? If they have changed the MPL code modules - they need to release those changes; otherwise (since the MPL is a weak-copy-left) they can not release other changes (like extensions) they bundle - obviously. That would not however stop third parties from combining the Apache OpenOffice code with LibreOffice code and doing with that whatever both licenses allowed. Sure - one example is IBM, they have a load of MPL code, and even LGPL code in Lotus Symphony. Amusingly, IBM are far more pragmatic in practise than ASF is - one of the tragic ironies of the situation. I guess it would be useful to create a wiki page with a FAQ about these license topics :) Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. So yes, someone could take LO code directly, make a downstream, proprietary product and sell it - and they only have to make the code to that proprietary version (whether it is identical to the LO version or modified) to those who have purchased their proprietary product. (MPL says for 12 months; FSF recommends per GPL/LGPL 3 years). My point being that Allen is 100% correct, and copy-left does not prevent the situation you all seem to be so concerned about. Remember, Copy-Left is about the End-User, not the Developer. $0.02 Ben ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 37942, which changed state. Bug 37942 Summary: some formulas not recognized https://bugs.freedesktop.org/show_bug.cgi?id=37942 What|Old Value |New Value Resolution||NOTABUG Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice licensing
On Mon, 2011-06-06 at 07:39 -0700, BRM wrote: Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). Not entirely correct. The source has to be made available to the legal recipients of the binary. Whether or not they are customers is irrelevant in this context. IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure. But we can certainly ask for the source if we are interested, and they are obligated to provide it if we have (legally) received the binary, under the same license as the original source code. This is a very important point. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I wouldn't put it that way. It works better for the downstream maintainers if they upstream their work, to make it easier to maintain their own modifications. If they think the benefit outweighs the cost of upstreaming, then they have every right not to upstream their changes. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. I don't think it is overlooked, but is already implied. (MPL says for 12 months; FSF recommends per GPL/LGPL 3 years). This I didn't know. Good to know. My point being that Allen is 100% correct, and copy-left does not prevent the situation you all seem to be so concerned about. Remember, Copy-Left is about the End-User, not the Developer. In the context where copy-left licenses such as GPL/LGPL are used, the end users sometimes (or many times) equal developers. Surely the majority of end users of consumer applications who are not developers or servicers of those apps don't really care about the availability of the source code, though they may care more about the availability of the binaries. They may want to have the source available in case they need to hire consultancies to service the software after the purchase (or download), but even in those cases the direct beneficiaries of the copy-left licenses (often referred to as users in some context) are developers who end up servicing the app for the users of the binary. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions
On Mon, 2011-06-06 at 12:55 +0100, Michael Meeks wrote: So, I wonder if the UX guys don't mind us never updating a progress bar more than twice per second (say) [1] we could do this for all progress bars in one place. Clearly calling a FooProgres-update(percent) method a bazillion times is not slow, if we never re-draw anyway. I personally like this approach better. Then we can leave the current rate of progress bar update in MoveTab as it is (per column per sheet). Still, I would like to get my 2nd suggestion (of having the method receive a pointer to the existing progress bar instance instead of creating and deleting it per call) implemented, to make unit-testing of this method possible (by having the unit test code pass a NULL pointer to this method to ignore progress bar updates). Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Weekly merge of libreoffice-3-4 - master
On Mon, 2011-06-06 at 14:55 +0200, Jan Holesovsky wrote: - calc: Kohei, can you please do it? There were 3 conflicts or so. I'll work on it once my clean build of master finishes. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][REVIEW][PUSHED-3-4] Fix bug in CloneList
Rafael Dominguez píše v Čt 26. 05. 2011 v 10:08 -0430: This patch fix a code i ommited in a previos commit 674c10b068d27d5ebdb25458d31dd8a61b343eb6, also should be included in 3.4.1 I have pushed it into the libreoffice-3-4 branch. Best Regards, Petr PS: It was better to use [REVIEW] in subject. We use it to search for stuff that need to go to stable branches. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED] Duplicate code: join ImportFrom and InsertFrom
Noel Power píše v St 01. 06. 2011 v 10:16 +0100: On 31/05/11 13:03, Chr. Rossmanith wrote: Hi, more duplicate code cleanup. Class SfxObjectShell has two nearly identical methods: ImportFrom and InsertFrom. The latter has a few lines of code more, so I've removed InsertFrom (which was added to the code base later than ImportFrom), added a boolean parameter to ImportFrom and adjusted the few calls to those methods. And InsertFrom is not virtual like ImportFrom. Please review the attached patches. I'll commit them if I get an ok. looks good to me, please commit it to master ( or I will commit it later after I get a build /me unfortunately accidently did a make clean on his master build ) I see all patches pushed in master now. Thanks for the nice work. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace List for vector
Rafael Dominguez píše v Čt 02. 06. 2011 v 12:41 -0430: Pushed into master. Thanks for the nice work! Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED] Replace List for vector
Once again with the correct subject. Rafael Dominguez píše v Čt 02. 06. 2011 v 12:41 -0430: Pushed into master. Thanks for the nice work! Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] QA manual test Litmus session on 3.3.3Rc
Merci Sophie Le 2011-06-05 16:36, Sophie Gautier a écrit : Hi all, *please, follow up on the projects list, thanks in advance* I am new to this, the litmus tutorial link is broken. Could someone fix this? Cheers Marc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] Performance improvements for calcs' sheet actions
[ Stepping in since Christoph without doubt is bathing his baby ;-) ] Kohei Yoshida wrote (06-06-11 18:01) On Mon, 2011-06-06 at 12:55 +0100, Michael Meeks wrote: So, I wonder if the UX guys don't mind us never updating a progress bar more than twice per second (say) [1] we could do this for all progress bars in one place. Would really like to have an impression how that looks like. In a world where people and software go more and more about eye-candidness .. Clearly calling a FooProgres-update(percent) method a bazillion times is not slow, if wenever re-draw anyway. I personally like this approach better. Then we can leave the current rate of progress bar update in MoveTab as it is (per column per sheet). NB: I don't see any mail from libreoffice-ux-adv...@lists.freedesktop.org coming in ... so prolly some administer work to do, and people expecting mail missing it? Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC][patch] Multiline inputbar
Hello Kohei,
I was able to figure out how to make the text appear properly in the
inputbar when in single line mode. I'm sending my patch over here.
Please have a look into it and let me know about further improvements
that can be done.
Thanks and regards.
--
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index db934bd..044fcb7 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -787,19 +787,29 @@ void ScTextWnd::Paint( const Rectangle rRec )
InitEditEngine(SfxObjectShell::Current());
if (pEditView)
+{
+
pEditView-Paint(rRec);
+
+}
}
+
+
void ScTextWnd::Resize()
{
if (pEditView)
{
Size aSize = GetOutputSizePixel();
-Point aPos(0, 0);
+int count = pEditEngine-GetLineCount(0);
+printf(%d %d\n, aSize.Height() , count);
+//Point aPos(0,(count-1)*aSize.Height());
+Point aPos(TEXT_STARTPOS,aSize.Height()/4);
+Point aPos2(aSize.Width()-5,3*aSize.Height()/4);
// TODO : When in single line mode, set the height to the height of a
// single line, and set the position so that the text look centered.
pEditView-SetOutputArea(
-PixelToLogic(Rectangle(aPos, aSize)));
+PixelToLogic(Rectangle(aPos, aPos2)));
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] svg embedding?
Hello everyone, [in case this is in the wrong list/group, feel free to set me straight] I just realized that OpenOffice 3.4 finally has one of my most wished-for features, which is the embedding of SVG images. As images, including all the really cool features that SVG supports. I tried it, and it works fine. now ... is that going to find its way into LibreOffice, too? This is the feature I'm talking about: http://openoffice.org/bugzilla/show_bug.cgi?id=49991 Especially in the light of the not-quite-right support of other vector image formats, I think there should be at least one that works always and reliably. Cheers, Zak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] svg embedding?
Hi Zak, Zak McKracken wrote (06-06-11 09:18) [in case this is in the wrong list/group, feel free to set me straight] Yes it is. See http://lists.freedesktop.org/mailman/listinfo/libreoffice Better mail your question to disc...@documentfoundation.org Regards, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC][patch] Multiline inputbar
Hi Anurag, On Tue, 2011-06-07 at 00:15 +0530, Anurag Jain wrote: Hello Kohei, I was able to figure out how to make the text appear properly in the inputbar when in single line mode. I'm sending my patch over here. Please have a look into it and let me know about further improvements that can be done. We talked a bit in IRC but just to let the list know... This change looks great! The text gets wrapped and the cursor moves to the next line as the line reaches the full width of the input bar. And the up/down arrow keys shifts the cursor to the previous/next line as you would expect. Good work! :-) Now, a minor nit pick is that, the very lower portion of the text appears to be cut off. For instance, when you type 'j', the lower portion of the letter is not displayed and it looks like 'i'. Have you tried EditEngine::GetTextHeight() ? That may give you a more appropriate height to use rather than hard-coding it to the 1/4 of the height of the input box. I've checked in this change to your feature branch, though I didn't check in those extra blank lines. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice licensing
- Original Message From: Kohei Yoshida kyosh...@novell.com To: BRM bm_witn...@yahoo.com Cc: libreoffice@lists.freedesktop.org Sent: Mon, June 6, 2011 11:44:37 AM Subject: Re: [Libreoffice] LibreOffice licensing On Mon, 2011-06-06 at 07:39 -0700, BRM wrote: Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). Not entirely correct. The source has to be made available to the legal recipients of the binary. Whether or not they are customers is irrelevant in this context. When dealing with a proprietary product, they are one-in-the-same, however they present the EULA. IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure. But we can certainly ask for the source if we are interested, and they are obligated to provide it if we have (legally) received the binary, under the same license as the original source code. This is a very important point. As you pointed out - only if you have a _legal_ right to ask. That won't likely be the case though unless you are their customer. Yes, they can't prevent you from distributing the GPL/LGPL/MPL portion of the work; but they could prevent you from distributing their additions to the degree that the MPL/GPL/LGPL derivative work restrictions apply, if at all. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I wouldn't put it that way. It works better for the downstream maintainers if they upstream their work, to make it easier to maintain their own modifications. If they think the benefit outweighs the cost of upstreaming, then they have every right not to upstream their changes. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. I don't think it is overlooked, but is already implied. Overlooked b/c of the nature of the statement. Your next response goes to show it... (MPL says for 12 months; FSF recommends per GPL/LGPL 3 years). This I didn't know. Good to know. Most on FLOSS don't - or don't realize it. But if you stopped and read the license it would become obvious - especially in the MPL case, didn't take me long to find section 3.2, or section 6 of the GPLv3 (specifically 6.d, a-c refer to distributing the object code/binary while 6d covers the source requirement). And, FYI, it doesn't have to be public - it could be behind an access protected service, or simply a write them and let them know you want a CD kind of thing - or even for free. So yes, one could start a company, make a derivative of LO. Offer it for sale; even make modifications, etc. and the only recipients of the changes would be said customers of the proprietary version. Further, they only necessarily have to get the source if they request it in some form, which may or may not happen during the required time period. (There is no requirement in either license beyond the required time period.) So, for example, a customer buys a copy from said company. After 4 years, they find a bug they want fixed, but the company only produced the one version. The customer is then out-of-luck with any ability to gain access to the source - the company is under no obligation to do so. Now suppose the company went out of business 2 years after the sale, they must then setup a means for 1 year by which customers can get the source (supposing Bankruptcy Court/etc allow the estate to meet the requirement). But if they went out of business 3 years and 1 day after the sale then again, there is no further obligation. My point being that Allen is 100% correct, and copy-left does not prevent the situation you all seem to be so concerned about. Remember, Copy-Left is about the End-User, not the Developer. In the context where copy-left licenses such as GPL/LGPL are used, the end users sometimes (or many times) equal developers. Surely the majority of end users of consumer applications who are not developers or servicers of those apps don't really care about the availability of the source code, though they may care more about the availability of the binaries. They may want to have the source available in case they need to hire consultancies to service the software after the purchase (or download), but even in those cases the direct beneficiaries of the copy-left licenses (often referred to as users in some context) are developers who end up servicing the app for the users of the binary. Only if the end-user obtains the source to provide to the developer. The developer may not necessarily be
Re: [Libreoffice] [GSOC][patch] Multiline inputbar
Hi Kohei,
Have a look into this. I've fixed the display problem with the j and g letters.
On Tue, Jun 7, 2011 at 12:57 AM, Kohei Yoshida kyosh...@novell.com wrote:
Hi Anurag,
On Tue, 2011-06-07 at 00:15 +0530, Anurag Jain wrote:
Hello Kohei,
I was able to figure out how to make the text appear properly in the
inputbar when in single line mode. I'm sending my patch over here.
Please have a look into it and let me know about further improvements
that can be done.
We talked a bit in IRC but just to let the list know...
This change looks great! The text gets wrapped and the cursor moves to
the next line as the line reaches the full width of the input bar. And
the up/down arrow keys shifts the cursor to the previous/next line as
you would expect. Good work! :-)
Thanks Kohei for the feedback and the motivation. ;)
Now, a minor nit pick is that, the very lower portion of the text
appears to be cut off. For instance, when you type 'j', the lower
portion of the letter is not displayed and it looks like 'i'. Have you
tried EditEngine::GetTextHeight() ? That may give you a more
appropriate height to use rather than hard-coding it to the 1/4 of the
height of the input box.
Yeah this patch will fix the j and g thing. Also I'll remove the hard
coding once you let me know about this patch.
I've checked in this change to your feature branch, though I didn't
check in those extra blank lines.
Yeah I'll take care of such things.
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com
Thanks and regards.
--
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index db934bd..b77d7c4 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -787,19 +787,29 @@ void ScTextWnd::Paint( const Rectangle rRec )
InitEditEngine(SfxObjectShell::Current());
if (pEditView)
+{
+
pEditView-Paint(rRec);
+
+}
}
+
+
void ScTextWnd::Resize()
{
if (pEditView)
{
Size aSize = GetOutputSizePixel();
-Point aPos(0, 0);
+int count = pEditEngine-GetLineCount(0);
+printf(%d %d\n, aSize.Height() , count);
+//Point aPos(0,(count-1)*aSize.Height());
+Point aPos(TEXT_STARTPOS,4*aSize.Height()/22);
+Point aPos2(aSize.Width()-5,18*aSize.Height()/22);
// TODO : When in single line mode, set the height to the height of a
// single line, and set the position so that the text look centered.
pEditView-SetOutputArea(
-PixelToLogic(Rectangle(aPos, aSize)));
+PixelToLogic(Rectangle(aPos, aPos2)));
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC] Re: KCachegrind
Hi Micheal, could you please have a look at http://kcachegrind.sourceforge.net/html/CallgrindFormat.html 1.4 Extended Example If we would like to 'hide' just func1 there is no way to include its cost into main because it's calling func2, which is not hidden. We could add all its inclusive cost to main but that would be what we want? Maybe yes, if we want to hide objects (libraries) that are calling just themselves and hidden objects. And that's probably the case. Is it? I'm not sure about result but this could be possible. And do we want also loose information about calling such function? Like it was just jump into another place or something like that and still the same function? regards, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice licensing
On Mon, 2011-06-06 at 12:32 -0700, BRM wrote: - Original Message From: Kohei Yoshida kyosh...@novell.com To: BRM bm_witn...@yahoo.com Cc: libreoffice@lists.freedesktop.org Sent: Mon, June 6, 2011 11:44:37 AM Subject: Re: [Libreoffice] LibreOffice licensing On Mon, 2011-06-06 at 07:39 -0700, BRM wrote: Just remember, that even with LGPL/GPL the changes _do not have to be contributed back to the community_; only made available to the customers of that product upon request (per LGPL, GPL and MPL). Not entirely correct. The source has to be made available to the legal recipients of the binary. Whether or not they are customers is irrelevant in this context. When dealing with a proprietary product, they are one-in-the-same, however they present the EULA. Not one-in-the-same (sic). But I think we are talking past each other, so I won't discuss any further. Your statement already implies that they are not exactly the same. IOW, TDF may not necessarily get the contribution. It's just like any downstream project - they can modify it and don't necessarily have to contribute those modifications back to the upstream project. Sure. But we can certainly ask for the source if we are interested, and they are obligated to provide it if we have (legally) received the binary, under the same license as the original source code. This is a very important point. As you pointed out - only if you have a _legal_ right to ask. That won't likely be the case though unless you are their customer. Beta test, evaluation versions, demos etc..? There are a number of ways of obtaining the binary legally without being a customer. Yes, they can't prevent you from distributing the GPL/LGPL/MPL portion of the work; but they could prevent you from distributing their additions to the degree that the MPL/GPL/LGPL derivative work restrictions apply, if at all. Sure, it works best when they do as everyone benefits, but they are not _required_ to do so. I wouldn't put it that way. It works better for the downstream maintainers if they upstream their work, to make it easier to maintain their own modifications. If they think the benefit outweighs the cost of upstreaming, then they have every right not to upstream their changes. I only mention this, as it is often overlooked - and in comments like the above - by Meeks and others - they seem to forget that aspect about Copy-Left, LGPL/GPL/MPL. I don't think it is overlooked, but is already implied. Overlooked b/c of the nature of the statement. Your next response goes to show it... I don't understand the connection. Only if the end-user obtains the source to provide to the developer. Of course. The developer may not necessarily be granted the right by the proprietary distributor to get direct access to the source. So I still maintain that it is end-users and not _necessarily_ developers that Copy-left is about. Ok. This is already becoming a meaningless word game. My point basically is that the distinction between the end users and developers are not necessarily clear cut when talking about copy-left licenses. No more no less. And I believe, based on what you said you also agree with that. However, if I as a developer come along and tell them that I could add some feature to it, they would need to ask for and obtain the source code for me if that was necessary. Of course. I never said that the developers didn't have to get the source code to service the software. Anyway, this is already off-topic here on this list. I suggest we end this thread here, and if anybody is interested on pursuing this, take it to a more appropriate list. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC] Re: KCachegrind
Hi Matus, On Mon, 2011-06-06 at 21:40 +0200, Matúš Kukan wrote: could you please have a look at http://kcachegrind.sourceforge.net/html/CallgrindFormat.html 1.4 Extended Example Looks fun :-) If we would like to 'hide' just func1 there is no way to include its cost into main because it's calling func2, which is not hidden. True - then again, we could make func1 of zero cost - pushing all its self cycles up into its caller (?) so it still exists in the call tree, but with an apparently instant effect ? ;-) We could add all its inclusive cost to main but that would be what we want? Maybe yes, if we want to hide objects (libraries) that are calling just themselves and hidden objects. And that's probably the case. Is it? So - I guess the problem is then when functions call themselves, perhaps some recursive 'qsort' caller when glibc is hidden ( or whatever similar madness ;-). And do we want also loose information about calling such function? Like it was just jump into another place or something like that and still the same function? Not sure :-) I guess we prolly want to build (or re-use) some simple test code - does kcachegrind have a couple of test libraries that it can be used to profile ? Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] fdo#37998 OpenOffice.org strings in package descriptions
Hi, Can someone please review my patch and cherry-pick it to 3-4. http://cgit.freedesktop.org/libreoffice/components/commit/?id=023080bb79698eb747d525fc9e7c7078d7c99501 In some 3.4.0 RPMs the vendor string was OpenOffice.org instead of The Document Foundation and the description contained OpenOffice.org instead of LibreOffice. Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] fdo#38007 fix for a truncated German string
Hi, Can someone please review my patch and cherry-pick it to 3-4: http://cgit.freedesktop.org/libreoffice/writer/commit/?id=02a8e58fa874a11419348a8758739abd1240ebf2 fdo#38007 fix for a truncated German string Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC] [rtfimport] 2nd week
Hi, Second week starts here: http://cgit.freedesktop.org/~vmiklos/lo-gsoc/tree/README#n179 In short, it was about: - character styles - paragraph styles - character properties - paragraph properties Miklos pgpUm0Zkq4R5s.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANN] LibreOffice 3.3.3 RC1 available
Dear Community, The Document Foundation is happy to announce the first release candidate of LibreOffice 3.3.3. The upcoming 3.3.3 is the third in a series of frequent bugfix releases on top of our LibreOffice 3.3 product. Please be aware that LibreOffice 3.3.3 RC1 is not yet ready for production use, you should continue to use LibreOffice 3.3.2 for that. The Release Candidate 1 is available for Windows, Linux and Mac OS X from our QA builds download page at http://www.libreoffice.org/download/pre-releases/ Should you find bugs, please report them to the FreeDesktop Bugzilla: https://bugs.freedesktop.org For other ways to get involved with this exciting project - you can e.g. contribute code: https://www.libreoffice.org/get-involved/developers/ translate LibreOffice to your language: http://wiki.documentfoundation.org/Translation_for_3_3 or help with funding our foundation: http://challenge.documentfoundation.org/ A list of known issues with 3.3.3 RC1 is available from our wiki: http://wiki.documentfoundation.org/Releases/3.3.3/RC1 Please find the list of changes against LibreOffice 3.3.2 here: http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-3-release-3.3.3-rc1.log Let us close again with a BIG Thank You! to all of you having contributed to the LibreOffice project - this release would not have been possible without your help. Yours, The Steering Committee of The Document Foundation pgpIx5jL1OF24.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANN] List for collaboration around user experience topics created
Hi Thorsten, *, Thorsten Behrens schrieb: Friedrich Strohmaier wrote: Think about it - less work for You in total ;o)) well, I don't care at all where the list is located - I just recalled the across-the-board rule of having reply-to-mangling active on the TDF lists, so I wanted to spare me the discussion. We won't escape while communicating with (non tec) design people ;o)) But I'm with You in this point. Also, purely mail-based moderation is a PITA really - but that maybe just me. :) I've opposite preference: going to any web interface (with finally one more account - yeah ever wanted that - sucks! mlmmj can't provide web interface - so: Your turn. As I won't be able to care before Thursday maybe better I leave it to You. Gruß/regards -- Friedrich Libreoffice-Box http://libreofficebox.org/ LibreOffice and more on CD/DVD images ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC][patch] Multiline inputbar
Hello Kohei,
In this patch I've removed the hard coded values for the height
Thanks and regards.
--
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx
index db934bd..130ea63 100644
--- a/sc/source/ui/app/inputwin.cxx
+++ b/sc/source/ui/app/inputwin.cxx
@@ -795,11 +795,16 @@ void ScTextWnd::Resize()
if (pEditView)
{
Size aSize = GetOutputSizePixel();
-Point aPos(0, 0);
+Size bSize = LogicToPixel(Size(0,pEditEngine-GetLineHeight(0,0)));
+int nDiff=(aSize.Height()-bSize.Height())/2;
+printf(here %d %d %d\n, nDiff , bSize.Height(), aSize.Height());
+//Point aPos(0,(count-1)*aSize.Height());
+Point aPos(TEXT_STARTPOS,nDiff*aSize.Height()/aSize.Height());
+Point aPos2(aSize.Width()-5,(aSize.Height()-nDiff)*aSize.Height()/aSize.Height());
// TODO : When in single line mode, set the height to the height of a
// single line, and set the position so that the text look centered.
pEditView-SetOutputArea(
-PixelToLogic(Rectangle(aPos, aSize)));
+PixelToLogic(Rectangle(aPos, aPos2)));
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC][patch] Multiline inputbar
On Tue, 2011-06-07 at 07:27 +0530, Anurag Jain wrote: Hello Kohei, In this patch I've removed the hard coded values for the height Yup. This one looks much better. Pushed to your feature branch. :-) BTW, it would be nice to have you pull the new changes from the repository so that your next change will be against the most recent commit in the remote repo. So, please run cd sc git pull -r to get the latest changes before you make your next changes. This will make it easier for me to apply your patch in the future. Regards, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Merge of branch feature/unlimited-number-of-sheets to master
Hello all, I just merged the branch feature/unlimited-number-of-sheets to master. This only affects calc, but we did a lot of changes to the core of calc so if you notice any problems with building or with functions that are not working as expected please send me a short mail. Calc should now be faster, but we were not able to remove the limit, only to increase it 32000 sheets because uno and libs-gui still use sal_Int16 for sheet index. But most important are the performance improvements, working with several sheets should be much faster, and most operations with a few sheets should be a bit faster too. There are still some performance improvements I would like to do: - the undo code around sheet actions needs way to much memory - ScTable is misused for some actions - we call ScTabView::SetTabNo way to often when we perform a sheet action Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] delete obsoleted help pages fdo#37543
Hello all, This patch delete the obsoleted help pages as described in fdo#37543, by removing filename in the makefile, and delete that pages. Also, as described in fdo#37543, may I ask how to delete WhatLinksHere as well? Next, I understand that the WIKIHELP pages will be deleted automatically after my patch was committed, thus I don't have (and don't have any right) to do anything in WIKIHELP, right? Moreover, I've found two fdo#33468 (Updates help page outdated) fixes by Andras Timar (links are in comment #3 and #4), he logged in the commit that text was not removed - we may need it later which is not as same as my thought. IMHO we are using the revision control system, so I decided not keeping them, or else in the next few years we may have remove unlinked help files easy hacks. ;) What do you think? If you agree with me, I can help sending a patch for deleting the left-over pages from fdo#33468 fix, too. Please feel free to comment. Best Regards, -- Korrawit Pruegsanusak From 06938121c0c7fb88fa53dde52c4a30e5f3adf96a Mon Sep 17 00:00:00 2001 From: Korrawit Pruegsanusak detective.conan.1...@gmail.com Date: Tue, 7 Jun 2011 11:31:39 +0700 Subject: [PATCH] Delete obsoleted help pages fdo#37543 Delete two obsoleted help pages: * Start-up wizard * Online Registration And remove them in makefile --- helpcontent2/source/text/shared/01/08060100.xhp| 74 helpcontent2/source/text/shared/01/makefile.mk |1 - helpcontent2/source/text/shared/autopi/makefile.mk |1 - helpcontent2/source/text/shared/autopi/startup.xhp | 62 helpcontent2/util/sbasic/makefile.mk |2 - helpcontent2/util/scalc/makefile.mk|2 - helpcontent2/util/schart/makefile.mk |2 - helpcontent2/util/sdatabase/makefile.mk|2 - helpcontent2/util/sdraw/makefile.mk|2 - helpcontent2/util/simpress/makefile.mk |2 - helpcontent2/util/smath/makefile.mk|2 - helpcontent2/util/swriter/makefile.mk |2 - 12 files changed, 0 insertions(+), 154 deletions(-) delete mode 100644 helpcontent2/source/text/shared/01/08060100.xhp delete mode 100644 helpcontent2/source/text/shared/autopi/startup.xhp diff --git a/helpcontent2/source/text/shared/01/08060100.xhp b/helpcontent2/source/text/shared/01/08060100.xhp deleted file mode 100644 index 302243e..000 --- a/helpcontent2/source/text/shared/01/08060100.xhp +++ /dev/null @@ -1,74 +0,0 @@ -?xml version=1.0 encoding=UTF-8? -helpdocument version=1.0 - -!-- -*** - * - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * Copyright 2000, 2010 Oracle and/or its affiliates. - * - * OpenOffice.org - a multi-platform office productivity suite - * - * This file is part of OpenOffice.org. - * - * OpenOffice.org is free software: you can redistribute it and/or modify - * it under the terms of the GNU Lesser General Public License version 3 - * only, as published by the Free Software Foundation. - * - * OpenOffice.org is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Lesser General Public License version 3 for more details - * (a copy is included in the LICENSE file that accompanied this code). - * - * You should have received a copy of the GNU Lesser General Public License - * version 3 along with OpenOffice.org. If not, see - * http://www.openoffice.org/license.html - * for a copy of the LGPLv3 License. - * - - -- - - -meta - topic id=textshared0108060100xml indexer=include - title xml-lang=en-US id=titRegistration/title - filename/text/shared/01/08060100.xhp/filename - /topic - /meta - body - paragraph xml-lang=en-US id=par_id3152876 role=paragraph l10n=E oldref=1 - localize=false/ - section id=registrierung -bookmark xml-lang=en-US branch=index id=bm_id8190557bookmark_valueonline registration/bookmark_value - bookmark_valueregistering; %PRODUCTNAME/bookmark_value -/bookmark -bookmark xml-lang=en-US branch=hid/.uno:OnlineRegistrationDlg id=bm_id3640231 localize=false/ -bookmark xml-lang=en-US branch=hid/.uno:OnlineRegistrationDlg id=bm_id3147617 localize=false/ -bookmark xml-lang=en-US branch=hid/DESKTOP_HID_FIRSTSTART_REGISTRATION id=bm_id2025818 localize=false/ -paragraph xml-lang=en-US id=hd_id3147477 role=heading level=1 l10n=U oldref=2link href=text/shared/01/08060100.xhp name=RegistrationRegistration/link/paragraph - paragraph xml-lang=en-US id=par_id3153882 role=paragraph l10n=U oldref=3ahelp hid=.uno:OnlineRegistrationDlgConnects to the $[officename] Web site where you can register your copy of $[officename]./ahelp/paragraph - /section -
