[Libreoffice] Me interesa tu anuncio
Hola! He visto que has puesto un anuncio en internet.Te ofrezco que utilices nuestra nueva pagina de anuncios gratuita: http://www.anunciategratis.org, para que tengas mas posibilidades! Entra en http://www.anunciategratis.org y publica todos tus anuncios gratuitos fácil y rápidamente! Te deseamos mucha suerte!El equipo de AnúnciateGratis.org Este email no es Spam. Si no desea recibir nuestras ofertas y promociones, por favor haga click aquí: mailto:ba...@anunciategratis.org&subject=Eliminar para darse de baja de nuestra lista de distribución. Hi! I have seen that you have published an ad on the net.I offer you to use our new web site for free ads: http://www.anunciategratis.org, so you can have more possibilities! Go to: http://www.anunciategratis.org and publish all your free ads easy and fast! Good luck!The AnúnciateGratis.org team This email is not spam. If you doesnt want to receive our offers and promotions, please click here: mailto:ba...@anunciategratis.org&subject=Eliminar to unsubscribe from the list. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Review needed - fix for 'wikihelp is not context sensitive'
On Wed, Dec 15, 2010 at 11:14:33PM +0100, Jan Holesovsky wrote: > Hi, > > https://bugs.freedesktop.org/show_bug.cgi?id=32338 > > Can you please review, sign-off and push the attached patch to > libreoffice-3-3? The root of the problem is that in case of the > built-in help, when a help-id is not referenced there, the code tries to > traverse over the parent windows to find at least something. > > In the case of the on-line help, we rather want to directly use that > (potentially missing) help id directly - otherwise we always end up on > the 'main' help page. [And also we can fix the missing help id in the > wikihelp, without the app recompilation.] > > Regards, > Kendy Done. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] GnuMake
Ok so I've pushed a feature/gnumake2 branch. It contain about half of the gnumake2 CWS plus few adjustment due to the fact that things have changed in our trees. I pushed at this point because: 1/ the regular build still function fully using the old method. and the modules "framework ooo sfx2 svl svtools sw toolkit tools xmloff" build successfully with the new gnumake system. 2/ I ran into a stretch of patches that rely on CWS sb139 being merged ( this implement a fix to http://qa.openoffice.org/issues/show_bug.cgi?id=113189 'passive registration of UNO components' ) that CWS had been merged into DEV300_m89. It is 15 or so commits, some of them massive( one is a 1.5MB patch) and is addressing a problem I know nothing about (yeah, I know... one day I need to find a way to grasp that UNO thing :-) ). Furthermore that also create a new module (xmlreader) which need to be assigned a git repository All that lead me to conclude that it would be wiser to wait and see what we do with m89 (kendy?), wait for it to be merged/cherry picked and then resume merging the rest of gnumake2 3/ I've done things on Linux so far. I'll be able to pull on MacOS and iron the problem there As usual Windows will have to be left as an exercise to the reader. Norbert. PS: not that it is very meaningful but: in sw, on a Quad-core, witch ccache (all runs fully cached) time build -P4 -- -P4 real1m47.932s user3m26.171s sys 1m7.191s time make -sr -j16 real1m0.491s user2m15.087s sys 1m14.152s time build -P5 real3m9.136s user3m18.709s sys 1m1.109s time make -sr -j5 real1m2.303s user2m12.577s sys 1m10.531s ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Failed while building module nss
On Thu, Dec 16, 2010 at 02:25:41AM +0800, imacat wrote: > Dear all, > > Hi. This is imacat from Taiwan. I try to compile LibreOffice on my > Debian Lenny 5.0.6 x86_64, gcc 4.3.2, glibc 2.7. It fails when building > module "nss": > > == > % make > Making all in po > ... > Module 'canvas' delivered successfully. 0 files copied, 40 files unchanged > > = > Building module nss > ===== > Entering > /usr/local/src/libreoffice-3.2.99.2-20101215/build/libreoffice-3.2.99.2/nss > > dmake: Error: -- > `./unxlngx6.pro/misc/71474203939fafbe271e1263e61d083e-nss-3.12.8-with-nspr-4.8.6.unpack' > not found, and can't be made You don't have the nss tarball. Run ./download in the root of the build tree. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Number of days for testing RC
Le 13/12/2010 15:04, Petr Mladek a écrit : > Hi Jean-Baptiste, > > Jean-Baptiste Faure píše v Pá 10. 12. 2010 v 20:02 +0100: >> Hi Petr, all, >> >> Le 10/12/2010 15:24, Petr Mladek a écrit : >>> Hi, >>> >>> Jean has modified http://wiki.documentfoundation.org/Release_Criteria >>> and increased the number of days for reporting blocker bugs from 7 to >>> 10. >> My first name is Jean-Baptiste :-) > Ah, I am sorry, shame on me. > >>> He says that they need to do the complete WE inside the period, >>> see http://wiki.documentfoundation.org/Talk:Release_Criteria >>> >>> Heh, what is "WE"? :-) >> Sorry, it is an acronym for a typical French expression : Week-End ;-) > This is why I proposed 7 days instead 5 days. 7 days have the Weekend > included by definition :-) Not really if the period start just before the WeekEnd. If a new RC is released on Friday for QA-test, most of the testers will not be able to start their tests before Monday. >> I think we need more time to allow volunteers to do manual tests. They >> do these tests during their spare time so often during the week-end. >>> OOo has only 5 days, see >>> http://wiki.services.openoffice.org/wiki/Release_criteria#Stopper_issues >>> How is it there with building and approving the national builds? >> Perhaps am I influenced by the big number of RC we have raised for OOo >> 3.3.0, but I think that if we take our time to deeply test our release >> candidates, we will have better stable version and enjoyed and not >> discouraged testers. > Hmm, I think that OOo-3.3 release is not a good example: Yes, from RC cycle point of view, it is an example that LibO should not follow. The process is not sufficiently clear: what QA-team must do when a stopper is found and known? If a new RC is build immediately, a second stopper can be fixed only on this new RC so it is not interesting to continue to test the old RC. It is more true because the new RC can introduce regression to the old one. So I think we need a very clear QA test process: known dates for RC, when it is useful to search blockers and when we can stop to search stoppers until a new RC is released. > OOo-3.3 development started on 2009-09-21 (branch for OOo-3.2) > OOo-3.3 feature freeze was on 2009-06-24 (branch for OOo-3.3, feature > freeze) > OOo-3.3-rc1 released on 2009-10-18 > > So, development took 9 months. Initial stabilization took 4 months. RC > phase takes nearly 2 months and is still not finished. > > Note that it was not full 9 months of development because many > developers were busy with stabilizing OOo-3.2 and OOo-3.2.1. > > Of course, it was affected by the acquisition of Sun by Oracle but it is > far from the original plan to release minor release every 6 months. > > The long cycle is discouraging for many volunteers. They want to have > their work living and used by users. Also it is much easier to fix bugs > shortly after a feature is finished than one year after implementation. > > > There is an idea of more micro bug fix releases. The published minor > release should be well usable for 99% of normal users. The micro > releases could be done every next month or so. They would include just > safe and reviewed bug fixes and should need not full QA. The second or > third micro release should be well usable for 99% experienced users. Ok for me. The only condition I see to make the end-users happy, is that the status of each version released must be very clear for the end-user. Individual users or small organizations may want use always the last micro-release while bigger organizations like administrations will have a longer cycle of update. >>> Also I think that it does not make sense that every national team would >>> do the whole testing. IMHO, 95% of the functionality is language >>> independent, so most of the testing can be shared and distributed. >> Right. For OOo, NL QA-team do only Release Sanity Test. But the current >> test period on OOo 3.3.0 shows that the last blockers have been found by >> the Community and these blockers could not be found by automatic or TCM >> tests; they have been found by users who have done tests on their >> documents they use in the real life. >> To do that we need time. > I see. Well, I think that even the released OOo version included pretty > annoying bugs and some of them would be considered as blockers. Such > bugs were usually fixed in the micro release x.y.1. > > We just need to define the right compromise that would be acceptable for > all sides developers, testers, and users. > > Just to get better picture. How much time would you need to finish all > known manual tests? For OOo and Release Sanity Test, time needed is about 2 to 4 hours to complete all the 25 tests in the scenario. But, as said the last blockers are out of the scope of these tests and have been found by test-cases and files from the real life. Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
[Libreoffice] Embedded parts and wikihelp/HC2
Hi Kendy, I've two questions concerning the wikihelp/HC2, there is no emergency for the answer, I know you're busy, but I don't want to forget to ask ;) Currently in the HC2 files, pages are composed by a mix of embedded chunks and local strings. We use two files to get the KID of the string, to display the embedded chunks, the .xhp tree and the OS dependent parts in order to do l10n QA on the files. I've added a screen shot of the result to my page on the wiki [1]. How somebody contributing to the wikihelp will see these embedded parts or OS specific parts. How will he knows that it should not make it to much particular to a certain page because it will appear elsewhere on other pages in the HC2? Some pages are mostly composed by embedded chunks, if those embedded part are removed, would that mean we will have to duplicate the localization? Kind regards Sophie [1] http://wiki.documentfoundation.org/User_talk:Sophi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] feature/calc-dp-unlimited-fields merged to master
Hi there, This is to inform you that I've just merged the feature/calc-dp-unlimited-fields branch into master. This change removes the current 8-field limit per field type in data pilot tables, and allows you to add as many fields as your memory permits. Since the core data pilot engine itself didn't have this 8-field limit, the change is mostly in the main data pilot dialog, though I had to modify some code in the core to replace c-style static arrays with dynamic arrays such as vector's. Anyway, testing appreciated. ;-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Python API and Danny.O00
My adoption and usage of "calc" means that I want to manipulate
the spreadsheet stuff easily.
This is stuff I cannot do at the moment at the "gig", as
its predominately windows, and also windows based "systems" at legacy labs,,
>> think a "geotechnical machine that costs 100k shear box with windows
3.1.. and works well still to this day.. "..
Dany.O00 goes some way towards manipulating a sheet with python, but am
disappointed that it years olde and no real "active" python dev, unless I
missed something..
For my application in a "goetechnical testing lab", I want to be able to
read/write to a sheet.. in pythonic way
Be easy just to do simple things, imagined in a heaven below
eg psudeo code.ish
### This is the Temparature measurement machine slave
JOB = {'job_id': 12345678, 'foo': 'bar', 'result': None}
import LibreOffice as LO
spread_full_path = "/jobs/%s/my_calc_spread_sheet.odf" % JOB.job_id #
whatever extension
spreadMe = LO.open(spread_full_path)
mySheet = spreadMe.sheet("foo", create=True) # create's if not exist,
otherwise error
mySheet.append( My_Data )
mySheet.close()
##// analyse data
analysysReader = LO.Open(spread_full_path, read_only=True) # or pyton
adoption.. prefer verbose..
aResult = analysysReader.sheets()[0].range("x_total")
if aResult > JOB.test.limitz:
send_message(aResult)
Thats all we need guys..
Now here is the deal..
If we can take this seriously then I'm in.. already got a danny.ooo
site hiking but crazy accumulation and we need to appraises and take a
"strategic" plan, stick some venom in there, poison the situation etc.. and
some out with a full anhydrite, ie go to your grandma's house and cut and
paste them olde docs..
In conclusion:
Anyone into developing the python.API and making it simple and idiot proff
Pete
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Help?
Alright, thanks for the reply. So, I tried to install the dependencies, but I ran into some problems. There were requests all over the place to change the architecture for lots of software from x86-64 to normal. should I go through with all of these changes, or did I do something wrong? On Tue, Dec 14, 2010 at 4:47 AM, Michael Meeks wrote: > Hi Jerry, > >First - welcome to LibreOffice :-) most of these questions are best > asked on IRC, but lets archive some of the answers here. > > On Mon, 2010-12-13 at 21:20 -0500, Jerry Shi wrote: > > Alright, so I just got off of irc.freenode.net, and now have another > > question. For some odd reason, make fetch does not work. It gives me > > an error, make: nothing to be done for 'fetch' > > That basically means - it has already fetched everything :-) that > is a > good sign. > > > Alright, thanks for all the help so far. To answer > > your questions, I'm using openSuse 11.2, on a fairly > > new dual core laptop. > > Oooh - old software on new hardware - fun :-) > > > zypper si -d OpenOffice_org-bootstrap # for OpenSUSE, > > but I recieve an error about how the > > OpenOffice_org-bootstrap doesn't exist. > > Ah - it is probable that you need the main OSS repositories > enabled; at > least - I believe we had the split build in 11.2 (which bootstrap is > from). Perhaps it is better to add the repository here: > >sudo zypper ar > http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_11.2/lo-unstable > >And then do the zypper si -d command (you could also install RC1 > pre-built to have a play). > > > So, as far as I can tell, the problem is with this > > line of code: PR_STATIC_ASSERT(sizeof(size_t) <= > > 4); in function > > Nurgh; still. I suspect this is some dependency problem that we > need to > check more carefully in configure. Petr - have you seen this before ? > > On Mon, 2010-12-13 at 21:29 -0500, Jerry Shi wrote: > > So, just one more thing before I go do something else...is it fine if > > I exclude modules? > > In general, if you hack pieces out of the build blindly, you will > eventually cause far more trouble than you solve :-) it is usually > better to try to trouble-shoot why it is not working in the first > instance, as every problem may have a root issue that causes many other > problems in turn. > > > I got around the nss thing by disabling it when I > > was running ./autogen.sh. Now, I have an error in graphite where "CPU > > you selected does not support x86-64 instruction set" I do have a 64 > > bit computer, as I neglected to mention. Should I just disable these > > modules so I can at least get a build, or should I try to get a > > solution? > > Wow :-) that's more fun indeed; again - Petr may be able to help, > you > really need all the dependencies installed right (hopefully the above > helps). > >All the best ! > >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] LibreOffice 3.3 release blockers / stoppers
On Wed, 2010-12-15 at 18:38 -0500, Arno Teigseth wrote: > My version is > LibreOffice 3.3.0 > OOO330m9 (Build:1) > libreoffice-build 3.2.99.2 That version is a dinosaur. Is that beta1? The latest is RC1, and RC2 almost out the door. So my suggestion is to get a hold of the RC1 and see if it's fixed there. BTW, our bugzilla is hosted on freedesktop.org: http://bugs.freedesktop.org/ To file a bug, use product name 'LibreOffice' (in case you are interested in filing it as a bug). HTH, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Base - sqlite - licence grief
On 15/12/10 20:33, Andrés Domínguez wrote: > 2010/12/13 Wols Lists : >> Can we put a hsqldb database in an odf container? The stuff I saw about >> sqlite 2 was things like "you can't modify a table". It's a very basic >> engine without a lot of the user-friendly padding. >> >> Anyways, in the first instance, I'm treating this as a "teach yourself >> C++" exercise - rather a "jump in the deep end" version :-) > Hi Wol, > > I'm also looking to fix sqlite3 driver for LibO. I didn't reply before > because I joined the list two days ago. I'm learning about libo and > sqlite3 driver source code, hope we can cooperate. I will tell you > as soon I do notable progress. > Good good good. I've committed the driver into my source tree, and I'm now trying to get it to compile. A quick hint - adding a "3" to a lot of the names will get you quite far quite quickly (unless you've got a different driver to me?). Mine's the sqlite 2 driver, updated to draft 3, so it's still got all the old names in it. I'm hoping to get time to plough on, but family and christmas are getting in the way. Chat off-list if you like and we'll see how far we get :-) Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice 3.3 release blockers / stoppers
I [still] don't know how to submit bugs on bugzilla, but is the bug that causes "libreoffice hangs when opening oxt from command line" fixed yet? if I do libreoffice qu_EC.oxt (to install the qu_EC dictionary extension) then libreoffice opens, shows me the extension manager and the license text, and .. hangs. Adding extensions works ok if done from the menu, just not from the cmdline. My version is LibreOffice 3.3.0 OOO330m9 (Build:1) libreoffice-build 3.2.99.2 Arno signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug to confirm: 32427
On Wed, 2010-12-15 at 18:12 -0500, Kohei Yoshida wrote: > > If my above assumption is right, then this should be an easy fix. I > can't remember which code I modified, but I'll get back to you when I > find out where the code is. It's in SfxApplication::OpenDocExec_Impl(). I modified here a bit to launch external xls documents in Calc instead of delegating that to the system (which tries to open it in Excel or fail). I've heard from someone that this change changed the logic of launching a web browser from soffice... So, that may *potentially* be the culprit, though I'm not 100% positive. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug to confirm: 32427
On Wed, 2010-12-15 at 22:54 +0100, Jan Holesovsky wrote: > Hi, > > https://bugs.freedesktop.org/show_bug.cgi?id=32427 > > Can anybody confirm this, please? I can't confirm this because my build for some reason still launches the old help (both 3.3 and master). But, this may have something to do with the change I introduced in the logic of launching external apps, which in the case of opening a web page, causes the soffice process to block until the browser process fully comes alive. For the most part firefox launches very quickly, so this is not an issue. But if someone is on a slow system where the browser takes a long time to launch, in theory this may block the LibreOffice process for a few seconds or more. > If yes, I'd nominate it as a blocker; > hopefully easy to fix :-) If my above assumption is right, then this should be an easy fix. I can't remember which code I modified, but I'll get back to you when I find out where the code is. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug to confirm: 32427
On Wed, 2010-12-15 at 23:23 +0100, Andrés Domínguez wrote: > 2010/12/15 Jan Holesovsky : > > Hi, > > > > https://bugs.freedesktop.org/show_bug.cgi?id=32427 > > > > Can anybody confirm this, please? If yes, I'd nominate it as a blocker; > > hopefully easy to fix :-) > > It works great for me. Firefox is Iceweasel 3.5.15 from debian testing. > LibO is master. > Hola, Ubutnu 10.10 and FF 3.6.13 - works as expected here. Drew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-documentation] Re: LibreOffice WikiHelp
Hi Kendy, *, Jan Holesovsky wrote (13-12-10 14:33) Maybe I am entering a thin ice here, but do not think we have a good help as of now. There is so few information there, in many times in the form "'Insert Picture' functionality inserts a picture from a file." ;-) [...] Some parts are (very) good, some not, or just useless (as you show with the example). We need to grow the family of the documentation writers, and we cannot do that by using the current tools. Authoring the .xhp files as we have [...] So we need to do the work easier not only for the translators, but for the help authors, or the documentation team in general, too. And I believe that with wiki, this has the biggest potential to scale. I think it is important and well worth trying, and from what I have seen in this thread (read a bit just this evening), there is good intention to communicate, understand the needs and work on a good solution :-) Also this evening, I saw that others try to help us with extra tips [1] which of course is very friendly ;-) Best, Cor 1] http://documentation.openoffice.org/servlets/ReadMsg?list=dev&msgNo=6558 -- - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug to confirm: 32427
2010/12/15 Jan Holesovsky : > Hi, > > https://bugs.freedesktop.org/show_bug.cgi?id=32427 > > Can anybody confirm this, please? If yes, I'd nominate it as a blocker; > hopefully easy to fix :-) It works great for me. Firefox is Iceweasel 3.5.15 from debian testing. LibO is master. Cheers, Andrés ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Review needed - fix for 'wikihelp is not context sensitive'
Hi,
https://bugs.freedesktop.org/show_bug.cgi?id=32338
Can you please review, sign-off and push the attached patch to
libreoffice-3-3? The root of the problem is that in case of the
built-in help, when a help-id is not referenced there, the code tries to
traverse over the parent windows to find at least something.
In the case of the on-line help, we rather want to directly use that
(potentially missing) help id directly - otherwise we always end up on
the 'main' help page. [And also we can fix the missing help id in the
wikihelp, without the app recompilation.]
Regards,
Kendy
>From 3be61d6854441af24f52f1b306a91537ba289174 Mon Sep 17 00:00:00 2001
From: Jan Holesovsky
Date: Wed, 15 Dec 2010 22:56:22 +0100
Subject: [PATCH] wikihelp: Use the right Help ID URL, fdo#32338.
The offline help has a fallback mechanism that (for non-existing Help IDs)
tries to traverse the parent windows to find at least something. This is not
desired in the case of on-line help, because there we can easily define new
redirects, without recompiling LibreOffice.
---
sfx2/source/appl/sfxhelp.cxx | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/sfx2/source/appl/sfxhelp.cxx b/sfx2/source/appl/sfxhelp.cxx
index 339e664..2fb3e01 100644
--- a/sfx2/source/appl/sfxhelp.cxx
+++ b/sfx2/source/appl/sfxhelp.cxx
@@ -745,6 +745,17 @@ SfxHelpWindow_Impl* impl_createHelp(Reference< XFrame >& rHelpTask ,
return pHelpWindow;
}
+/// Check for built-in help
+static bool impl_hasHelpInstalled()
+{
+String aHelpRootURL( DEFINE_CONST_OUSTRING("vnd.sun.star.help://") );
+AppendConfigToken_Impl( aHelpRootURL, sal_True );
+Sequence< ::rtl::OUString > aFactories = SfxContentHelper::GetResultSet( aHelpRootURL );
+
+return ( aFactories.getLength() != 0 );
+}
+
+/// Redirect the vnd.sun.star.help:// urls to http://help.libreoffice.org
static bool impl_showOnlineHelp( const String& rURL )
{
String aInternal( RTL_CONSTASCII_USTRINGPARAM( "vnd.sun.star.help://" ) );
@@ -811,13 +822,8 @@ BOOL SfxHelp::Start( const String& rURL, const Window* pWindow )
}
}
-// check if help is available
-String aHelpRootURL( DEFINE_CONST_OUSTRING("vnd.sun.star.help://") );
-AppendConfigToken_Impl( aHelpRootURL, sal_True );
-Sequence< ::rtl::OUString > aFactories = SfxContentHelper::GetResultSet( aHelpRootURL );
-if ( 0 == aFactories.getLength() )
+if ( !impl_hasHelpInstalled() )
{
-// no factories -> no help -> try online
if ( impl_showOnlineHelp( aHelpURL ) )
return TRUE;
else
@@ -871,7 +877,7 @@ BOOL SfxHelp::Start( ULONG nHelpId, const Window* pWindow )
{
String aHelpModuleName( GetHelpModuleName_Impl() );
String aHelpURL = CreateHelpURL( nHelpId, aHelpModuleName );
-if ( pWindow && SfxContentHelper::IsHelpErrorDocument( aHelpURL ) )
+if ( impl_hasHelpInstalled() && pWindow && SfxContentHelper::IsHelpErrorDocument( aHelpURL ) )
{
// no help found -> try with parent help id.
Window* pParent = pWindow->GetParent();
--
1.7.3.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Bug to confirm: 32427
Hi, https://bugs.freedesktop.org/show_bug.cgi?id=32427 Can anybody confirm this, please? If yes, I'd nominate it as a blocker; hopefully easy to fix :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Base - sqlite - licence grief
2010/12/13 Wols Lists : > > Can we put a hsqldb database in an odf container? The stuff I saw about > sqlite 2 was things like "you can't modify a table". It's a very basic > engine without a lot of the user-friendly padding. > > Anyways, in the first instance, I'm treating this as a "teach yourself > C++" exercise - rather a "jump in the deep end" version :-) Hi Wol, I'm also looking to fix sqlite3 driver for LibO. I didn't reply before because I joined the list two days ago. I'm learning about libo and sqlite3 driver source code, hope we can cooperate. I will tell you as soon I do notable progress. Cheers, Andrés ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Wed, 2010-12-15 at 18:27 +0100, Jan Holesovsky wrote: > Actually, I still might have the cvs -> git import I did 2-3 years back The source cvs repos are still around and online, right ?, i.e. :pserver:anon...@anoncvs.services.openoffice.org:2401/cvs C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Jan Holesovsky wrote: > Actually, I still might have the cvs -> git import I did 2-3 years back > that tracked all the branches, and also marked the integration commits > as merges; if there'd be more demand for that, I could try to resurrect > that for the history digging purposes ;-) > If you have it around, that would be cool. At times, some archeology helps understanding the more obscure areas... Cheers, -- Thorsten pgpWbTnzAL72I.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] vcl/unx: remove duplicate printer code
Hi,
I have found some duplicate classes between vcl/unx and
vcl/unx/headless; PspSalInfoPrinter and PspSalPrinter.
As suggested by Caolàn, the attached patch removes these two classes
from vcl/unx/headless
- The following removed methods were not strictly identical to the
existing:
BOOL PspSalInfoPrinter::Setup( SalFrame* pFrame, ImplJobSetup* pJobSetup )
void vcl_sal::PrinterUpdate::doUpdate()
void vcl_sal::PrinterUpdate::update()
- libvclplug_svpxl.so generated by vcl/unx/headless is now indirectly
linked with X11, something probably not desired for a headless library.
- There are still lot of common code between SvpSalInstance and
X11SalInstance.
I will move that common code in a base class. UnxSalInstance seems a
good name...
That code consists at least of CreateInfoPrinter, CreatePrinter, some
helper functions, and probably some mutex related code.
Any comment/suggestion on this idea are welcome...
Regards,
Joachim.
diff --git a/vcl/unx/headless/svpprn.cxx b/vcl/unx/headless/svpprn.cxx
index 5d7e67c..27af93d 100644
--- a/vcl/unx/headless/svpprn.cxx
+++ b/vcl/unx/headless/svpprn.cxx
@@ -36,7 +36,6 @@
#include "vcl/timer.hxx"
#include "vcl/printerinfomanager.hxx"
-#include "svpprn.hxx"
#include "svppspgraphics.hxx"
#include "svpinst.hxx"
@@ -44,6 +43,8 @@
#include
#include
+#include "salprn.h"
+
using namespace psp;
using namespace rtl;
@@ -169,143 +170,7 @@ static void copyJobDataToJobSetup( ImplJobSetup* pJobSetup, JobData& rData )
}
}
-static bool passFileToCommandLine( const String& rFilename, const String& rCommandLine, bool bRemoveFile = true )
-{
-bool bSuccess = false;
-
-rtl_TextEncoding aEncoding = osl_getThreadTextEncoding();
-ByteString aCmdLine( rCommandLine, aEncoding );
-ByteString aFilename( rFilename, aEncoding );
-
-bool bPipe = aCmdLine.Search( "(TMP)" ) != STRING_NOTFOUND ? false : true;
-
-// setup command line for exec
-if( ! bPipe )
-while( aCmdLine.SearchAndReplace( "(TMP)", aFilename ) != STRING_NOTFOUND )
-;
-
-#if OSL_DEBUG_LEVEL > 1
-fprintf( stderr, "%s commandline: \"%s\"\n",
- bPipe ? "piping to" : "executing",
- aCmdLine.GetBuffer() );
-struct stat aStat;
-if( stat( aFilename.GetBuffer(), &aStat ) )
-fprintf( stderr, "stat( %s ) failed\n", aFilename.GetBuffer() );
-fprintf( stderr, "Tmp file %s has modes: 0%03lo\n", aFilename.GetBuffer(), (long)aStat.st_mode );
-#endif
-const char* argv[4];
-if( ! ( argv[ 0 ] = getenv( "SHELL" ) ) )
-argv[ 0 ] = "/bin/sh";
-argv[ 1 ] = "-c";
-argv[ 2 ] = aCmdLine.GetBuffer();
-argv[ 3 ] = 0;
-
-bool bHavePipes = false;
-int pid, fd[2];
-
-if( bPipe )
-bHavePipes = pipe( fd ) ? false : true;
-if( ( pid = fork() ) > 0 )
-{
-if( bPipe && bHavePipes )
-{
-close( fd[0] );
-char aBuffer[ 2048 ];
-FILE* fp = fopen( aFilename.GetBuffer(), "r" );
-while( fp && ! feof( fp ) )
-{
-int nBytes = fread( aBuffer, 1, sizeof( aBuffer ), fp );
-if( nBytes )
-write( fd[ 1 ], aBuffer, nBytes );
-}
-fclose( fp );
-close( fd[ 1 ] );
-}
-int status = 0;
-waitpid( pid, &status, 0 );
-if( ! status )
-bSuccess = true;
-}
-else if( ! pid )
-{
-if( bPipe && bHavePipes )
-{
-close( fd[1] );
-if( fd[0] != STDIN_FILENO ) // not probable, but who knows :)
-dup2( fd[0], STDIN_FILENO );
-}
-execv( argv[0], const_cast(argv) );
-fprintf( stderr, "failed to execute \"%s\"\n", aCmdLine.GetBuffer() );
-_exit( 1 );
-}
-else
-fprintf( stderr, "failed to fork\n" );
-
-// clean up the mess
-if( bRemoveFile )
-unlink( aFilename.GetBuffer() );
-
-return bSuccess;
-}
-
-static bool sendAFax( const String& rFaxNumber, const String& rFileName, const String& rCommand )
-{
-std::list< OUString > aFaxNumbers;
-
-if( ! rFaxNumber.Len() )
-return false;
-
-sal_Int32 nIndex = 0;
-OUString aFaxes( rFaxNumber );
-OUString aBeginToken( RTL_CONSTASCII_USTRINGPARAM("") );
-OUString aEndToken( RTL_CONSTASCII_USTRINGPARAM("") );
-while( nIndex != -1 )
-{
-nIndex = aFaxes.indexOf( aBeginToken, nIndex );
-if( nIndex != -1 )
-{
-sal_Int32 nBegin = nIndex + aBeginToken.getLength();
-nIndex = aFaxes.indexOf( aEndToken, nIndex );
-if( nIndex != -1 )
-{
-aFaxNumbers.push_back( aFaxes.copy( nBegin, nIndex-nBegin ) );
-nIndex += aEndToken.getLength();
-}
-}
-}
-bool bSuccess = true;
-if( aFaxNumbers.begin() != aFaxNumbers.end() )
-{
-while( aFaxNumbers.begin() != aFaxNumbers.end() && bSucce
[Libreoffice] Failed while building module nss
Dear all, Hi. This is imacat from Taiwan. I try to compile LibreOffice on my Debian Lenny 5.0.6 x86_64, gcc 4.3.2, glibc 2.7. It fails when building module "nss": == % make Making all in po ... Module 'canvas' delivered successfully. 0 files copied, 40 files unchanged = Building module nss = Entering /usr/local/src/libreoffice-3.2.99.2-20101215/build/libreoffice-3.2.99.2/nss dmake: Error: -- `./unxlngx6.pro/misc/71474203939fafbe271e1263e61d083e-nss-3.12.8-with-nspr-4.8.6.unpack' not found, and can't be made Forcing regeneration of dependency info nothing to do here... dmake: Error: -- `./unxlngx6.pro/misc/71474203939fafbe271e1263e61d083e-nss-3.12.8-with-nspr-4.8.6.unpack' not found, and can't be made Retrying /usr/local/src/libreoffice-3.2.99.2-20101215/build/libreoffice-3.2.99.2/nss dmake: Error: -- `./unxlngx6.pro/misc/71474203939fafbe271e1263e61d083e-nss-3.12.8-with-nspr-4.8.6.unpack' not found, and can't be made --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development it seems that the error is inside 'nss', please re-run build inside this module to isolate the error and/or test your fix: --- /bin/sh cd /usr/local/src/libreoffice-3.2.99.2-20101215/build/libreoffice-3.2.99.2 source ./LinuxX86-64Env.Set.sh cd nss build when the problem is isolated and fixed exit and re-run 'make' from the top-level sometimes (sadly) it is necessary to rm -Rf unxlngx6.pro in a module. make: *** [stamp/build] Error 1 % == Is there any suggestion? Thank you very much in advance. -- Best regards, imacat ^_*' PGP Key http://www.imacat.idv.tw/me/pgpkey.asc <> News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ TLUG List Manager http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] dmake: Error code 1, while making '../unxlngx6.pro/misc/rsc_svt'
surensp...@gmail.com said: >> I'm pretty sure Michael has already fixed this yesterday. So, please >> update your build tree and see if you can go past that. I think the above has fixed my issue, though I still failed to build LO. I shall start a new thread on this. -- Best regards, imacat ^_*' PGP Key http://www.imacat.idv.tw/me/pgpkey.asc <> News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ TLUG List Manager http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-l10n] Re: LibreOffice WikiHelp
Hi Martin, On 2010-12-14 at 12:27 +0100, Martin Srebotnjak wrote: > > > I think the biggest issue is the offline editing; and I think here we > > > can use the Wiki Publisher > > > (http://extensions.services.openoffice.org/project/wikipublisher) to > > > edit the pages in LibreOffice. [...] > I believe that is not a good idea. It will reformat the content and make > changes tracking a nightmare. Also, translating from changed US wiki to > other languages will be a nightmare. Let's see - as I said, so far I haven't done any testing, to see how good it is; I can imagine it works just well, and of course, even the opposite scenario :-) > I propose you develop a system to have English help editable on wiki but > fully transportable back to the po/xliff system (interchangeable). > All the translations would start from the English po/xliff help files and > decide whether to > a) strictly translate English help (like we Slovenians decided) and keep > working with po/xliff files; the online help would be updated from these > files at least with every minor and major release; > or > b) develop their own help in the wiki and never go back again; Yes, this seems so far working for most :-) I'll make sure that all the work you've done on the the help translation so far is not lost. > Before I go on I need an answer to a question. I tried the help in RC1 and > it seems that help items do not get passed to wiki i.e. the default module > help page opens even if you press F1 in a certain dialog (the previous > bundled help showed that definite topic in the help). This is a blocker bug, already reported as: https://bugs.freedesktop.org/show_bug.cgi?id=32338 It works in some of the scenarios (eg. in the menus), but not in the dialogs. I am working on it, this is of course not intended. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Caolan, On 2010-12-09 at 20:08 +, Caolán McNamara wrote: > > AA: + write tooling to retain history across repo moves (Kendy) > > I suppose its silly to look into rewriting our existing history by > tracking back through the various old svn and cvs workspace branch > systems to determine who committed the various changes that ended up > getting bundled into the old-style releng mega commits. Wishful thinking > I guess. Actually, I still might have the cvs -> git import I did 2-3 years back that tracked all the branches, and also marked the integration commits as merges; if there'd be more demand for that, I could try to resurrect that for the history digging purposes ;-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mac OSX build fails in jurt, jvmaccess, jvmfwk
Alexander Thurgood wrote: > > From the errors produced in jvmaccess, it looks like something has > > happened to classpath.cxx and classpath.hxx. Virtually every line gives > > an error. > > > Same with jurt and jvmfwk. > Hi Alex, best join #libreoffice irc on freenode.net - either there are kinks in the setup, or a case of bad luck with pulling - but either way, best handled interactively. Cheers, -- Thorsten pgpmQb51U85m9.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mac OSX build fails in jurt, jvmaccess, jvmfwk
Le 15/12/10 17:15, Alexander Thurgood a écrit : > > From the errors produced in jvmaccess, it looks like something has > happened to classpath.cxx and classpath.hxx. Virtually every line gives > an error. > Same with jurt and jvmfwk. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] sw: reset num level on SplitNode if parent is outline.
On Tue, 14 Dec 2010 23:16:41 -0800, Octavio Alvarez wrote: On Tue, 14 Dec 2010 21:59:37 -0800, Octavio Alvarez wrote: Fixes the following scenario: 1. Create a paragraph style "S" bound to a list style. 2. Set the Heading 2 next style to "S". 3. Pressing ENTER at the end of a Heading 2 will create the new paragraph, but its numbering level will be set to 2. If this test is repeated for "Heading 3", the resulting paragraph will end up with numbering level == 3. There is another section of the file that uses a similar code. I'm not sure if I should also apply it there too: source/core/txtnode/ndtxt.cxx, SwTxtNode::AppendNode Thanks. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Mac OSX build fails in jurt, jvmaccess, jvmfwk
Hi again, Did a git pull, and restarted the build. It has failed again with loads of "out of scope" errors in jurt, jvmaccess and jvmfwk. Has somebody been messing with the java stuff ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mac OSX build fails in jurt, jvmaccess, jvmfwk
Le 15/12/10 17:09, Alexander Thurgood a écrit : > Hi again, > > Did a git pull, and restarted the build. It has failed again with loads > of "out of scope" errors in jurt, jvmaccess and jvmfwk. Has somebody > been messing with the java stuff ? > >From the errors produced in jvmaccess, it looks like something has happened to classpath.cxx and classpath.hxx. Virtually every line gives an error. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Any interest in porting this to 3.3?
On Tue, 2010-12-14 at 17:38 -0500, Kohei Yoshida wrote: > > In my opinion this is generally a safe bug fix that affects only > limited > functionality, but I'd like to know if it's worth porting this to > 3.3. Ok. I take the silence as a "no", which is fine. I'll keep this fix on master only. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX fails in soltools/mkdepend
Hi Thorsten, Le 15/12/10 14:58, Thorsten Behrens a écrit : > sorry for the lag - personally was only doing -3-3 builds on mac - > JoeP meanwhile fixed this, an unfortunate snafu with echo not taking > -n as an argument, but echoing it verbatim. Could you pull, autogen > & retry? Thought it might be something like that, but not knowing where to look, I was a bit lost. Will try again from renewed git sources. Thanks. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need review of the ooo/OOO330_m18 changes
On Tue, 2010-12-14 at 21:19 +0100, Jan Holesovsky wrote: > writer Done for the fix of i#115956. -- Cedric ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX fails in soltools/mkdepend
Alexander Thurgood wrote: > Hopefully someone can help out here. I've been attempting my first build > on MacOSX and the build fails in soltools trying to make mdepend : > > ../unxmacxi.pro/misc/make_makedepend.makedepend_1.cmd: line 1: -n: > command not found > dmake: Error code 127, while making '../unxmacxi.pro/bin/makedepend' > > The content of the incriminated file is as follows > > -n ccache g++-4.0 -Wl,-multiply_defined,suppress -lobjc > -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -bind_at_load > -L../unxmacxi.pro/lib > -L/Users/alex/DevHack/git/libo/solver/330/unxmacxi.pro/lib -L/usr/lib -o > ../unxmacxi.pro/bin/makedepend -lstdc++ -lm -filelist > ../unxmacxi.pro/misc/makedepend.list > Hi Alex, sorry for the lag - personally was only doing -3-3 builds on mac - JoeP meanwhile fixed this, an unfortunate snafu with echo not taking -n as an argument, but echoing it verbatim. Could you pull, autogen & retry? Cheers, -- Thorsten pgp2wqgEzCL0o.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] hsqldb update
Hi, On Wed, Dec 15, 2010 at 12:27:16AM +0100, Rene Engelhard wrote: > So 2.0 will even more break... (Besides that it probably will need many > adaptions) Note that OOo already works on that; see cws hsqldb19. The amount of changes (and tasks( is quite big, though... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
On Wed, 2010-12-15 at 10:04 +, Noel Power wrote: > did you look at the changes I committed to the branch ? ( of course > there are some more changes to look at now :-) ) I'd be interested in > your thoughts as I would like to get this stuff into master asap With this rather more test-able stuff; I wonder if there is some compile-time unit test we can be running in every build ? Looking forward to seeing it merged though. 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] hsqldb update
Hi Rene, On Wed, 2010-12-15 at 00:27 +0100, Rene Engelhard wrote: > On Tue, Dec 14, 2010 at 11:13:28PM +, Wols Lists wrote: > > > Version 2.0 has been out there for quite some time, 2.0.1 is well on the > > > way and as the website > > > states, the new version is much improved on various ends. > > The problem is that the file format upstream encodes the version. Even 1.8.0 > vs. > 1.8.1 breaks. Need to dig out the issue/mails wrt that... Oh - this is an extremely good point. > So 2.0 will even more break... (Besides that it probably will need many > adaptions) Quite - and since we store the data in the file itself; we have this horrible forwards/backwards compat. problem wrt. versions always. [ This is why I'd love a flat, std. SQL dump in the file personally ;-) ] So - sticking with a working version, and trying to deprecate that thing as quick as possible seems like a better approach (IMHO). Of course - we also rather need a datbase migration GUI (as I mentioned to Wols) - in particular for MS Access databases. HTH, 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] De-Java-ise flat XML export
On Tue, 2010-12-14 at 20:58 +0100, Thorsten Behrens wrote: > Michael Meeks wrote: > > Riight; interesting. Ultimately XSLT requires a DOM to operate on, so I > > suppose if we get SAX events from OO.o, we will need to map these to > > libxml's nodes. .. > Hm, just getting a DOM tree is even easier - instantiate a > "com.sun.star.xml.dom.DocumentBuilder" service & off you go - Riight - but I suspect that using libxml's DOM representation as directly hooked into by libxslt [etc.] is likely to be more efficient and easier. HTH, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Oracle & other auto-replies ...
On Tue, 2010-12-14 at 12:20 -0800, some...@boldandbusted.com wrote: > Please stop setting up autoreplies that reply to mailing lists... Dr. > Frank Peters. :) Ah - you should only get one each, and its nice to know that Frank is listening (when he is not on vacation) - personally I'm happy to put up with some minor inconveniences to have the benefit of these guy's experience at least nearby, if not actively participating. For the benfit of any other vacationing guys, if you visit: http://lists.freedesktop.org/mailman/options/libreoffice you should be able to authenticate, fiddle with your options, and turn off delivery while you're away - or perhaps a digest mode lets you still get the messages, but (perhaps) sending an away message to the digestor (might?) not spam other senders. HTH, 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] hsqldb update
On Wed, Dec 15, 2010 at 10:35:19AM +0100, Thorsten Behrens wrote: > Ugh - and there's no way of falling back to an older format version? http://de.openoffice.org/servlets/ReadMsg?list=dev&msgNo=44128 is where I first saw it. There's also http://user.services.openoffice.org/en/forum/viewtopic.php?f=13&t=31359&start=0 and as we see, the error is pretty unspecific... -> a version=1.8.1 file cannot be handled (Debian has a conflicts libhsqldb-java >= 1.8.1~ because of this and configure will also reject 1.8.1 for that reason) > That would be a pretty strong point against hsqldb usage in any way Jup :) Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Need review of the ooo/OOO330_m18 changes
On 14/12/10 20:19, Jan Holesovsky wrote: Hi, I wanted to merge the m18 changes today, but looking at the diff, it is not that trivial, and I don't feel like the right person reviewing it according to our post-RC criteria; so I'd like to ask you to review it. Best if you can merge/cherry-pick the changes too, if OK :-) The following repositories are affected: filters impress libs-core libs-extern-sys libs-gui writer I pushed the changes from libs-core and libs-gui, relates to dba33m ( connectivity changes where we don't typically make and changes ) and impress205 which seemed fairly self contained. Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build on MacOSX fails in soltools/mkdepend
Le 13/12/10 14:40, Alexander Thurgood a écrit : ping ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH]: Remove large blocks of unused code + script to find large comment blocks
On Tue, 2010-12-14 at 22:31 +0100, Anders Jonsson wrote: > Removal of two more large blocks of unused code. Looks good, one from 2006, so I guess we can be sure its not a recent work in progress, and the other is also lingering a long time. Thanks for these. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Basic Currency Issues #i31001# to #i107277#
Hi John, On 06/12/10 17:58, Noel Power wrote: Hi John, [...] in sbxToUnoValueImpl ( convert to uno without known target class ) in basic/source/classes/sbunoobj.cxx previously an Double or Float basic value ( within the range of an int ) was transfered as a the smallest type e.g. sal_Int8, sal_Int16 or sal_Int32 values greater were transferred as Float or Double I removed the '#if MAYBEFUTURE' I put around the code above. After some poking around and also looking at the dev guide it seems this code is to handle the case where the expected type ( on the uno side ) is unknown, in this case the value is down cast to the smallest ( non-internal ) basic type which is then converted to an uno type ( or at least that's my current take on the intention ) in basic/source/runtime/methods1.cxx you have added incomplete read/write support for types SbxSALINT64 & SbxSALUINT64, lets not add support to persist a new type incompletely ( to easy to forget about ) so I've #ifdefed it out ( with #if IMPLEMENTATION_READY ) I'm not sure it is needed but I enabled this ( and created a new stream operator to handle the 64 bit type ) I rewrote the ImpCurrencyToString, I took note of your suggestions re. optimizations whilst trying to point you to some existing functionality available from the String classes as its better to avoid generating even more number to string code. Somewhere between trying to write down some explanations and suggestions I'm afraid I found myself actually rewriting this and then I found mistakes in my 'new' implementation... couldn't help myself. Anyway hopefully some of the code there shows some other possibilities to achieve the same thing reusing some of the existing LO classes. ( I have no doubt that there probably is some bugs in my implementation too ). Additionally I am still very uncertain about ImpStringToCurrency() changes to use Locale specific separators. Also not sure about the local seperator logic, the heuristics used I think might give an undesired result under some circumstances. I don't want to rule it out but for the moment I would feel happier with the locale specific part being #ifdefed out ( so I did that with some more #if MAYBEFUTURE blocks ). I also rewrote the ImpStringToCurrency a little, actually more like I combined yours and the old implementation a little, mostly I just removed the home grown parser in favour of using the existing string->number conversions in OUString. Like the ImpCurrencyToString I have enclosed the locale specific functionality in a '#if MAYBEFUTURE' block. I removed the acceptance of blank characters in the middle of a string as VBA regards this as an error and the old implementation just truncated the number ( e.g. "12345 6" would end up as 12345 ), I raise an error in this case now. Hopefully if this breaks existing macros it will only break code already deeply in error ( from mis-interpreting the string/number ) The other reason for removing the parser is if/when we do apply some locale specific separator processing I would love to reuse/share whatever calc currently uses. SbxValue::LoadData & SbxValue::SaveData, we need to ensure that a Currency val written from the old Currency implementation can be read with the new implementation and vice-versa ( looking at the code it seems that it should work ). Hmmm but thinking about this more I really don't see why this is necessary, I can't think of why a types value would be saved with this this code, I still haven't figured out if this code is really used or not, currently erring on the side of caution I created a new stream operator for SvStream and additionally tweaked the handling for Currency and the SbxSALINT64 and SbxSALUINT64 from you orig patch, it seems there were some bugs with the orig patch. Currently I don't see an easy way of testing the changes ( so I have coded them untested ) so I hope that maybe another set of eyes might help. Please feel free to do that ( and I'll try and ask on the list for some help too ) It would be great if you could look over my changes and see if they are ok, if you are happy with the change and if we can satisfy ourselves that LoadData/SaveData item above is not an issue then we could probably commit this to the master, then we can look further into some of the ifdefed out stuff, how does that sound? did you look at the changes I committed to the branch ? ( of course there are some more changes to look at now :-) ) I'd be interested in your thoughts as I would like to get this stuff into master asap Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] hsqldb update
Rene Engelhard wrote: > On Tue, Dec 14, 2010 at 11:13:28PM +, Wols Lists wrote: > > > Version 2.0 has been out there for quite some time, 2.0.1 is well on the > > > way and as the website > > > states, the new version is much improved on various ends. > > The problem is that the file format upstream encodes the version. Even 1.8.0 > vs. > 1.8.1 breaks. Need to dig out the issue/mails wrt that... > > So 2.0 will even more break... (Besides that it probably will need many > adaptions) > Ugh - and there's no way of falling back to an older format version? That would be a pretty strong point against hsqldb usage in any way ... Cheers, -- Thorsten pgpWbnAwknntF.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Bug 31865 depends on bug 32330, which changed state. Bug 32330 Summary: The pdfimport extension draws the pdfs corrupted. https://bugs.freedesktop.org/show_bug.cgi?id=32330 What|Old Value |New Value Resolution||FIXED 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
[Libreoffice] [Bug 31865] [Task]: LibreOffice 3.3 release blockers / stoppers
https://bugs.freedesktop.org/show_bug.cgi?id=31865 Bug 31865 depends on bug 32304, which changed state. Bug 32304 Summary: Impress exports grouped objects incorrectly to ppt https://bugs.freedesktop.org/show_bug.cgi?id=32304 What|Old Value |New Value Resolution||FIXED Status|ASSIGNED|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] Need review of the ooo/OOO330_m18 changes
Jan Holesovsky wrote: > impress > Reviewed & cherry-picked the i#107568 fixes Cheers, -- Thorsten pgpLzIalt3kyB.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
