Re: [Libreoffice] [PATCH] conditional formatting with an unlimited number of rules
Hi Katarina, Thank for your evaluation work and your detailed feedback. I insert my answers in your text. Le 06/04/11 17:56, Katarina Machalkova a écrit : Hey Bob (& all) ... Wow, I'm impressed by how good job you did, esp. considering the fact that this is your first submission :) I've applied the patch and tested it and (save some small issues), it works reasonably well. Thanks so much for that. I've not invent anything, it's just the result of code analyse and reorganize it. (many "cut & paste"). Since this is quite a big feature patch, you're gonna receive rather long feedback from me, please don't be put off by that: 1) svx part of the patch is mostly OK ... except for the long list of new #includes. As the (French) comment says, not all of them are needed Oups ! I create a patch with translations of French comments ;-) More seriously : I have let things like that because I project to add other "preview fonctionalities" (rotate, borders, ...) and I don't know exactly which header-files are necessary. I will work to clean it. Is there a tool to make warning for useless hxx ? Now for sc/calc part: 2) I find "Insert" button (newly added to the dialog) a bit redundant. All it does is that it appends an empty condition rule at the end of the list (position N+1) -- the same thing can be achieved by enabling/selecting checkbox by Nth rule in the list -- the scrollbar then moves, so the users see they can add more rules. Additionally, its function is a bit buggy -- it tends to check some boxes that weren't previously checked and populates the affected entries with some default values (zeroes etc.) Therefore I'd suggest to remove it (+ related code as well) ... but we can discuss this further, it's a matter of taste. The "insert fonctionality" make _realy an insert_ ! But the visual result is not really evident for user ... A new entry is inserted on the first position in the dialog box (It's not correctly visible because I've directly selected aCbxCond1). I think then insert an unchecked entry, will better see new entry. What do you think about that ? (I hope my googled-english is readable ;-) 3) In ScConditionalFormatDlg::InsertEntry and ScConditionalFormatDlg::AddEntry -- instead of handling/copying array of pointers to conditional format entries in this way, it'd be cleaner to work with some C++ container holding the pointers to entries -- std::vector or boost::ptr_vector Ok, I'm going to buy a new C++ book, because I don't find "std::vector" references in my old one ! (Borland C++ dating the past siecle, with the price in francs ;-) I think I can work on this in a next time. 4) In ::Refresh and ::UpdateValueList (as well as ::CondNChecked) methods really, really lot of code is duplicated/copy&pasted around. That's on one hand consistent with the rest of the code in this class (yeah, unfortunately), but on the other hand not very nice. Ok, I can improve this. 5) Found a small buglet while testing (easy to fix) -- for newly appended condition entries, pre-selected style should be "Default". With your patch, it is the one that comes first in alphabetically sorted list (e.g. if I create a custom style named "Blue", it'll come before "Default" and all the newly created rules will have "Blue" style as default) Thank, I've stupidly not tested with other style names than "Default" and "undefined#" Sooo, what I'm gonna do now is that after fixing some very obvious quirks (reduce the list of includes in svx, fix some typos -- CondNChecked instead of CondNCheked, and three-liner fix for issue 5) I'll push the patch as it is, so that LibO users can use the feature already and give it a good deal of testing. Whaou ! super :-) I will send a new patch tomorrow As for the code cleanup -- this is mostly about issues 3& 4 -- we can do it together later. Or, if you feel like it, you can try to improve the code yourself and send a patch to LibO list for review Yes, I try to improve the code and send a next patch. Again, thanks a lot for the patch and keep up good work. Should you have any questions, please don't hesitate to poke any of Calc hackers (me, kohei, muthusuba etc.) on IRC Ok, thank you. In first times, I will send questions on this dev list because I'm not regular IRC user. Best regard Bob B. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] use RTL_CONSTASCII_USTRINGPARAM
Here it goes another patch, Same licence.
2011/4/6 Tor Lillqvist
> Thanks, pushed!
>
> --tml
>
>
From 6e2b921ea0d5a780bf910cb6bd1a2abc856a78f8 Mon Sep 17 00:00:00 2001
From: Xisco Fauli
Date: Thu, 7 Apr 2011 00:17:14 +0200
Subject: [PATCH] use RTL_CONSTASCII_USTRINGPARAM
---
framework/source/fwe/helper/undomanagerhelper.cxx |4 +-
framework/source/layoutmanager/helpers.cxx|2 +-
framework/source/lomenubar/FrameHelper.cxx| 56 ++---
framework/source/lomenubar/FrameJob.cxx | 14 +++---
4 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/framework/source/fwe/helper/undomanagerhelper.cxx b/framework/source/fwe/helper/undomanagerhelper.cxx
index 1bbd58b..2781bc2 100644
--- a/framework/source/fwe/helper/undomanagerhelper.cxx
+++ b/framework/source/fwe/helper/undomanagerhelper.cxx
@@ -651,7 +651,7 @@ namespace framework
? rUndoManager.GetUndoActionCount( IUndoManager::TopLevel )
: rUndoManager.GetRedoActionCount( IUndoManager::TopLevel );
if ( nElements == 0 )
-throw EmptyUndoStackException( ::rtl::OUString::createFromAscii( "stack is empty" ), getXUndoManager() );
+throw EmptyUndoStackException( ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( "stack is empty" )), getXUndoManager() );
aGuard.clear();
// <--- SYNCHRONIZED
@@ -1116,7 +1116,7 @@ namespace framework
IUndoManager& rUndoManager = m_pImpl->getUndoManager();
if ( rUndoManager.IsUndoEnabled() )
-throw NotLockedException( ::rtl::OUString::createFromAscii( "Undo manager is not locked" ), m_pImpl->getXUndoManager() );
+throw NotLockedException( ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( "Undo manager is not locked" )), m_pImpl->getXUndoManager() );
rUndoManager.EnableUndo( true );
// <--- SYNCHRONIZED
}
diff --git a/framework/source/layoutmanager/helpers.cxx b/framework/source/layoutmanager/helpers.cxx
index a855e04..652cf15 100644
--- a/framework/source/layoutmanager/helpers.cxx
+++ b/framework/source/layoutmanager/helpers.cxx
@@ -381,7 +381,7 @@ void impl_setDockingWindowVisibility( const css::uno::Reference< css::lang::XMul
xDispatcher->executeDispatch(
xProvider,
aDockWinCommand,
-::rtl::OUString::createFromAscii("_self"),
+::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("_self")),
0,
aArgs);
}
diff --git a/framework/source/lomenubar/FrameHelper.cxx b/framework/source/lomenubar/FrameHelper.cxx
index 7008cb3..8bc9372 100644
--- a/framework/source/lomenubar/FrameHelper.cxx
+++ b/framework/source/lomenubar/FrameHelper.cxx
@@ -131,9 +131,9 @@ item_about_to_show (DbusmenuMenuitem *item, gpointer user_data)
FrameHelper *helper = (FrameHelper*)user_data;
Reference < XFrame > xFrame = helper->getFrame ();
Reference< XPropertySet > frameProps (xFrame, UNO_QUERY);
-Reference < XLayoutManager > xLayoutManager(frameProps->getPropertyValue(OUString::createFromAscii("LayoutManager")),
+Reference < XLayoutManager > xLayoutManager(frameProps->getPropertyValue(OUString(RTL_CONSTASCII_USTRINGPARAM("LayoutManager"))),
UNO_QUERY);
-Reference < XUIElement > menuBar(xLayoutManager->getElement (OUString::createFromAscii("private:resource/menubar/menubar")),
+Reference < XUIElement > menuBar(xLayoutManager->getElement (OUString(RTL_CONSTASCII_USTRINGPARAM("private:resource/menubar/menubar"))),
UNO_QUERY);
Reference < XPropertySet > menuPropSet (menuBar, UNO_QUERY);
@@ -142,7 +142,7 @@ item_about_to_show (DbusmenuMenuitem *item, gpointer user_data)
return FALSE;
}
-Reference < XMenu > xMenu(menuPropSet->getPropertyValue(OUString::createFromAscii("XMenuBar")),
+Reference < XMenu > xMenu(menuPropSet->getPropertyValue(OUString(RTL_CONSTASCII_USTRINGPARAM("XMenuBar"))),
UNO_QUERY);
if (!xMenu.is())
{
@@ -204,14 +204,14 @@ FrameHelper::FrameHelper(const Reference< XMultiServiceFactory >& rServiceManag
this->m_server = server;
//Get xUICommands database (to retrieve labels, see FrameJob::getLabelFromCommandURL ())
-Reference < XNameAccess > xNameAccess (m_xMSF->createInstance(OUString::createFromAscii("com.sun.star.frame.UICommandDescription")),
+Reference < XNameAccess > xNameAccess (m_xMSF->createInstance(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.frame.UICommandDescription"))),
UNO_QUERY);
-m_xMM = Reference < XModuleManager> (m_xMSF->createInstance(OUString::createFromAscii("com.sun.star.frame.ModuleManager")),
+m_xMM = Reference < XModuleManager> (m_xMSF->createInstance(OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.sta
[Libreoffice] [PATCH] Translation of German comment in libs-core/svx/source/engine3d/
Hi, More translated German comments, which have been sitting around in my local repo for a while... You can commit the patch under the terms of MPL 1.1 / GPLv3+ / LGPLv3+ triple license. /Albert svx-source-engine3d-german.comments.diff.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Pискoвые oпеpации с налогaми
--- |ОПТИМИЗAЦИЯ HАЛOГООБЛОЖЕНИЯ | |и АНТИoптимизация (pискoвые oпeрации, кoторых дeлать нe cтоит)- | |HДC, пpибыль, HДФЛ. «Прoбoины» cтaрых схeм. Hовые cxeмы c 1.04.2011. | |14 pеaльных ошибoк, coвeршенных в дoкумeнтaции, пpиводящиx к потеpе | |налoгoвого крeдитa, донaчиcлении HДФЛ, EСВ, «пpогнозные» нюанcы пo пpибыли. | --- > Cеминар • 12 aпреля • 2011 г. > г. Киeв • ул. Шeлковичнaя, 12 > Тeл.: (044) 331-б4-14, 592-75-6Ч > ПPOГРАММА > ОПТИМИЗAЦИЯ HAЛОГООБЛОЖЕНИЯ. • Oпepирование пoнятиями: отгpузка, пеpeход пpaва coбственности, пoлучениe тoвapа для фoрмирования рaсходов пo пpибыли, «подводныe кaмни» пo HДC. Пoчeму нeльзя бecкoнечно нe пeредавать прaвo coбственности нa тoвaр. • Bлияние заключeнных договoров и прaвильно oфoрмленных пepвичныx дoкумeнтов нa нaлoгoвый учeт:пеpечень 14 пpaктических ошибoк, котоpые coвeршают бухгалтeра - Прaктика пpoвeрок 2011. • Возмoжность лeгaльно пoлучaть нaличку пoд 0-10-11-15-17%: вo всeх возмoжных кoмбинациях. Pазумное примeнение нaлоговых льгoт и возмoжнoсти нe плaтить налoги (нe базa) c 1.04.2011. Огpаниченность cхeм обopотом- 300 тыc., 500 тыc., 1млн. • Поcpеднические опepации: кoмиccия, поpучeние, агентcкий. Применeние пoсредников для oптимизации нaлогoобложения. • Пoкупкa тoвaра у ЧП c 1.04.2011 - кaк "oбойти" зaпрeт oтносить нa pacходы пo пpибыли. Мoжно ли «нaкупиться» дo 1.04 - пoйдeт ли нa раcходыпосле 1.04 • Уcлуги пo KBEД 72, 74. Пoнятие консультaции c тoчки зрeния укрaинcкого и мeждунаpодного зaконодательства. Oтличие дeятельнoсти oт oпepации. Kaк нe попаcть в пpизнание сдeлок ничтoжными, фиктивными. • Bсe пpо Дeятельнoсть в сфepе инфopматизации (72 кoд KВЕД) c 1.04.2011. Hужна ли ЧП спeциaльная подготoвка для окaзания этиx уcлуг. Экcклюзивные pазъяснения Минстaта нa эту тeму. • Можнo ли выплачивaть ДИВИДEНДЫ "кoгда зaхoчется" и бeз пpибыли. • "Подвoдныe кaмни" HАЛОГОВЫХ КАHИКУЛ- кoгда прийдетcя вcю пpибыль отдaть гoсудaрству. • HДC, пpибыль, HДФЛ, ЕСB- oпеpации, пpи кoторых нeт ни однoгo нaлoга. • Oдновременная рабoта ЧП_учрeдитель_директор c 2011 г. Рaбoта ЧП c oдним пpeдпpиятием- пpaктика пpовeрок. • KОЛЛЕКТИВНЫЙ ДOГОВОР кaк cпoсоб минимизиpoвать нaлoгoобложение. Примeнение мeждунapодной кoнвeнцци к пopядку зaключeния и исполнeния коллeктивного дoгoвoра. Heобходимость зaключения. Дейcтвительность в случаe oтcутcтвия pегиcтрации для целeй минимизaции нaлогов. • УДЕPЖАНИЯ пpи выплaтe PАБОТНИКУ: кaк пpи выплатe удepжaть 0-5-15 %. Kак офоpмить МАТЕPИАЛЬНУЮ ПOМOЩЬ, ПOДАРОК, ЛЕЧEHИЕ, OБУЧEHИЕ, … чтoбы пpи выплатe удерживaть минимaльноe кoличество нaлoгoв. • BСЕ СХEМЫ c учacтием eдинщиков c 1.04.2011 г. «Пpобoины» схeм, привoдящие к неoбxодимости отдaть вeсь дoxод гoсудaрству. > BЭД. Применeние междунaродных конвeнций для умeньшeния послeдствий oграничений c 1.04.2011 oффшoрных pасходов. Пocредники пpи импортe-экспорте: чтo «выжилo». Pиски пpи BЭД и метoды cнижeния. Нoвые нюанcы пo уcлугaм нерeзидента(ов) пo кoдeксу. > OТЧEТНОСТЬ: дeклaрации: HДC, пpибыль, HДФЛ, анaлог 1ДФ > ПPОВЕРКИ 2011. Hовые мexанизмы поведeния нaлогoплательщика в Haлоговом кодeкcе пpи xалaтном cоставлении Aкт пpoверки. Чтo неoбходимо ЗHAТЬ пpo CEРОГО контрaгента еcли «вaм звoнит нaлoговая милиция», чтoбы вырaбoтать стpатегию дeйcтвий: затaиться, отнecти оpигинaлы, oтнecти кceроксы, готовитcя к судeбнoму заcеданию или уплaтить всe налoги пo cделке (освoбождает ли этo oт отвeтcтвенности). Прoцeдуры, кoтopые примeняeт налoговая для лишeния налoгoплательщика нaлогового кpeдитa - чтo мoжнo cделать нa этaпе создaния дoкументов. ПPОВЕРКИ cоблюдения трудoвoго зaконoдательства: полномoчия ГHAУ, сoцcтрахов, ПФ, OБЕПА - вoзможныe пpинципы пepеквалификации дoгoворов c ЧП в тpудoвые. Нoвыe виды пpовeрок и cпоcобы нe допускaть провeряющих. Koсвенные мeтoды, cвязь c хозяйcтвенной деятeльнoстью и OБЫЧHЫЕ ЦЕHЫ. Пoнятиe ФAKТИЧЕСКОЙ ПРOВЕРКИ: правoмерность пpовeдения хpoнометража, контрoльных зaкупoк. ФИНМOНИТОРИНГ: нa какиe oпepации oбрaтят внимaние - изучaeм «пoдвoдныe кaмни» пpи рaбoте c cубъектами финмoнитоpинга - гдe (нe) дейcтвуетпонятие банкoвской, кoммерческой тaйны. > Aвтoры и вeдущиe cеминара: • Bельбицкая Иpинa Игoревна - аудитoр, автoр публикaций в пpессе, книги «Eдиный нaлог для юpидичecких и физичeских лиц». • Kpиворучко Aндpeй Ивaнoвич - юpиcт, имeющий бoльшoй oпыт спoров (судoв) c контpолирующими oргaнами нa стopоне нaлoгоплательщиков. > PАCПОРЯДОК • Региcтрация c 9:30 пo 10:00 • Нaчaло в 10:00 • Oкo
[Libreoffice] CVER / C52 cleaning
Hi all, CVER is defined in set_solenv.in and propagated in form of defines to the entire source tree. I've found it is almost unused expect in the following cases - when set to C52 (version 5.2 of a solaris-specific compiler) - when set to M1500 or M1600 (Microsoft Visual Studio compilers ?) The M1500/M1600 value is only used once or twice, to change the name of a file. Only the C52 value is reasonably well used in the tree (24 occurences, including comments). The only references I found about a 5.2 version of a Sun compiler are 10-year old and I suspect we could simply remove the #if defined(C52) checks from the tree. (and then remove CVER, simplifying things a bit more). Could a Solaris user confirm whether C52 is indeed completely obsolete or not in the year 2011 ? -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to disable addon installation
Hi Tor Allow me to strongly disagree. I don't think we should pack every tiny extension in LO. That leads to bloatware. Extensions are an elegant solution to enhance LO. As for security hole, enterprises don't like users installing unauthorised software. There are ways to block it, as I did by de-registering the extension GUI and erasing unopkg script. Firefox has a config parameter to disable user installed extensions, Nice feature to have in LO in the future. Olivier Em 04-04-2011 04:36, Tor Lillqvist escreveu: Extensions are a potentially security hole Yes, we should make the code in extensions just be a normal integral part of LibreOffice, like any other functionality, that will make the code much safer! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Olivier Hallot Founder, Steering Commitee Member - The Document Foundation Voicing the enterprise needs LibreOffice translation leader for Brazilian Portuguese ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] How to disable addon installation
Hi Manuel Em 06-04-2011 05:09, Manuel Reimer escreveu: Olivier Hallot writes: I second your concern. Extensions are a potentially security hole and it should be possible to install LibreOffice without the ability to install extensions. The extension installer, expecially the GUI should be an option at intall time. Doesn't help me at all, as I'm on Linux and there the package is usually prebuilt by the distributor. The only thing, that would help me, is a easy way to disable extension installation even after installation. Rename or erase unopkg executable/script in libreoffice/program. However I am not sure this is a clean way to do it. But if you want only to disable the GUI, de-register the proper dll in the command prompt: C:\Program Files\LibreOffice.org 3\Basis\program>..\..\URE\bin\regcomp -revoke -r services.rdb -c "vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno.dll" vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno.dll revoke component 'vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno. dll' from registry 'services.rdb' succesful! swoosh!, vanished. Just killing/renaming the relevant library also helped. Thanks for pointing me to this. Is there any way to simple toggle this even as user (non-root)? Can I, for example, place the library to somewhere in my libreoffice profile dir to re-enable extension installation? I don't know. The configuration mechanism in OO/LO changed from 3.2 to 3.3 and now all user changes are in registrymodifications.xcu in the user space. The original/defaults configurations are in /libreoffice/basis3.3/share/registry . I've filed two bugs about this discussion: https://bugs.freedesktop.org/show_bug.cgi?id=36017 https://bugs.freedesktop.org/show_bug.cgi?id=36019 Yours Manuel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Olivier Hallot Founder, Steering Commitee Member - The Document Foundation Voicing the enterprise needs LibreOffice translation leader for Brazilian Portuguese ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [partial PATCH] Easy hack: expunge duplicate enumerations in vcl
Hi Caolan, I've continued to remove psp::weight::type. At the end of your last e-mail you mention 3 enums. Given that width and weight are already two enums there is one left to remove. Or shouldn't "three" be taken literally. There are still left: italic, pitch, family <-> FontItalic, FontPitch, FontFamily For italic I need some help how to translate the vclenum values into the fontmanager values. For the final test, whether it builds or not, I would have to install Qt3 in order to allow --enable-kde. Is that the only way? Or could someone with Qt3 installed test it for me? And what about the FW_NORMAL, FW_BLACK etc. from sft.h? Shall they be replaced as well? Christina Am 05.04.2011 21:18, schrieb Caolán McNamara: On Tue, 2011-04-05 at 21:01 +0200, Christina Roßmanith wrote: removed some methods ToFontWidth() which aren't needed anymore. Yup, looks good, the removal of those redundant mappings is the target. After that vcl compiles fine for me. But it tells me that KDE is disabled (who did that?), so this part isn't checked by the compiler. see --enable-kde/--enable-kde4 as arguments to ./autogen.sh / configure If someone could please review this patch. If it is fine I'll go on. Would you recommend a huge push at the end of this work or one for each removed enum? Looks good, obviously remove the commented out code. Just the one push IMO for the three enums. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Change accel key back to "D" for "Clear direct formatting"
Hi Octavio,
Octavio Alvarez píše v Ne 03. 04. 2011 v 16:32 -0700:
> Now that "~Default Formatting" is named "~Clear Direct Formatting" it
> makes "C" not go directly to "Clear Direct Formatting" because there were
> other menu items already using "~C". I submit these patches to set it back
> to "~D", as it was before. Since it will use the previously assigned key,
> this should avoid any accel key collision.
>
> I really wish this could make it to 3.4 to prevent send inga conflicting
> key ("C") out in the Format and Context menus (particularly for Writer).
Thank you, pushed them all to 3.4 :-)
Regards,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] GSOC 2011
Hi Ivan, On Wed, 2011-04-06 at 17:55 +0200, ivpu...@foi.hr wrote: > I am a candidate for Google Summer of Code, and I found a project that > interested me enough, so I wrote a proposal, so I would be grateful if > you could see little that proposal and proposed modifications, to achieve > better results. You can file the application, but there are a few stuffs that shocked me: * Sending your proposal as Docx format for a work on LibreOffice... you know we want you to do free software, with open formats? * Presenting yourself is nice, but you told too few about the project itself, the time line you are planning to follow and so on. Regards, -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] use RTL_CONSTASCII_USTRINGPARAM
Thanks, pushed! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
On Wed, Apr 06, 2011 at 06:28:47PM +0200, Petr Mladek wrote: > Francois Tigeot píše v St 06. 04. 2011 v 18:01 +0200: > > > > I admit I only have taken a cursory look to the patch itself. Howewer, I've > > also updated my git repository and tried to build LibreOffice. > > The build failed exactly as I described it above. > > Ah, are you using git master? Yes, I don't dare touch the release branches yet ;-) > I have initially committed the fix only to the libreoffice-3-4 > branch :-( I have just cherry-picked it for master as well. Could you > please try once again? Doh! I should have seen configure.in wasn't updated. My apologies. Now that it is properly patched, the build is nicely chugging along :-) Many thanks for the patch. Kind Regards, -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
Francois Tigeot píše v St 06. 04. 2011 v 18:01 +0200:
> On Wed, Apr 06, 2011 at 05:45:39PM +0200, Petr Mladek wrote:
> > Francois Tigeot píše v St 06. 04. 2011 v 17:04 +0200:
> > >
> > > the test you have reused and the one I just wrote are for two different
> > > things.
> > > We have two things here:
> > >
> > > - the first check tested for --hash-style=gnu option support.
> > > ld supports it, result = yes
> >
> > If you look at my change, I have removed this check. IMHO, it is
> > obsoleted by the AC_TRY_RUN one. ;-)
> >
> > IMHO, it does not make sense to enable --hash-style=gnu if the
> > application can be linked and not started on the given system. So, the
> > AC_TRY_LINK is not needed because the same success/failure is detected
> > also by AC_TRY_RUN.
>
> Okay, I understand the logic.
>
> > > - the check I just wrote tested if binaries linked with the
> > > --hash-style=gnu
> > > can be run
> > > something in the system doesn't grok it, result = no
> > >
> > > By integrating the two autoconf checks, we're back to a situation where
> > > the build process happily links binaries with --hash-style=gnu and crashes
> > > a few moments later trying to run them.
> >
> > Are you sure? Have you looked at my changes? :-)
>
> I admit I only have taken a cursory look to the patch itself. Howewer, I've
> also updated my git repository and tried to build LibreOffice.
> The build failed exactly as I described it above.
Ah, are you using git master?
I have initially committed the fix only to the libreoffice-3-4
branch :-( I have just cherry-picked it for master as well. Could you
please try once again?
> > > What I wanted to do is set a reasonable default of "gnu" or "sysv" for the
> > > --with-hash-style option depending if the machine can run such binaries or
> > > not.
> >
> > I hope that I did the same.
>
> config.log says HAVE_LD_HASH_STYLE='TRUE' and yet my system can not run the
> newly generated makedepend.
If it is not the problem with master, could you please try the attached
test? Just do:
gcc -Wl,--hash-style=gnu test-link-hash.c
./a.out
I wonder if such a trivial program fails at runtime. It is possible that
we would need a more complicated test.
> > The only difference might be that my
> > approach does not care only about the default. In addition, it does not
> > allow to force "gnu" on systems that are able to link but are not able
> > to run such programs. IMHO, it does not make much sense.
>
> I preferred not to assume too much on this point and allow some foot shooting.
;-)
> > It would even
> > cause compilation problems because some helper tools need are compiled
> > and ran during build. Or did I miss anything?
>
> Yeah, that's exactly why my builds are failing :-(
Sure, we need to fix it.
Best Regards,
Petr
#include
int main(char argc, char** argv) {
printf ("hello world\n");
return 0;
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] GSOC 2011
salute... I am a candidate for Google Summer of Code, and I found a project that interested me enough, so I wrote a proposal, so I would be grateful if you could see little that proposal and proposed modifications, to achieve better results. Thank you Ivan P. libreOffice.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.documen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
On Wed, Apr 06, 2011 at 05:45:39PM +0200, Petr Mladek wrote: > Francois Tigeot píše v St 06. 04. 2011 v 17:04 +0200: > > > > the test you have reused and the one I just wrote are for two different > > things. > > We have two things here: > > > > - the first check tested for --hash-style=gnu option support. > > ld supports it, result = yes > > If you look at my change, I have removed this check. IMHO, it is > obsoleted by the AC_TRY_RUN one. ;-) > > IMHO, it does not make sense to enable --hash-style=gnu if the > application can be linked and not started on the given system. So, the > AC_TRY_LINK is not needed because the same success/failure is detected > also by AC_TRY_RUN. Okay, I understand the logic. > > - the check I just wrote tested if binaries linked with the --hash-style=gnu > > can be run > > something in the system doesn't grok it, result = no > > > > By integrating the two autoconf checks, we're back to a situation where > > the build process happily links binaries with --hash-style=gnu and crashes > > a few moments later trying to run them. > > Are you sure? Have you looked at my changes? :-) I admit I only have taken a cursory look to the patch itself. Howewer, I've also updated my git repository and tried to build LibreOffice. The build failed exactly as I described it above. > > What I wanted to do is set a reasonable default of "gnu" or "sysv" for the > > --with-hash-style option depending if the machine can run such binaries or > > not. > > I hope that I did the same. config.log says HAVE_LD_HASH_STYLE='TRUE' and yet my system can not run the newly generated makedepend. > The only difference might be that my > approach does not care only about the default. In addition, it does not > allow to force "gnu" on systems that are able to link but are not able > to run such programs. IMHO, it does not make much sense. I preferred not to assume too much on this point and allow some foot shooting. > It would even > cause compilation problems because some helper tools need are compiled > and ran during build. Or did I miss anything? Yeah, that's exactly why my builds are failing :-( -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] conditional formatting with an unlimited number of rules
Hey Bob (& all) > I finally finished my work on the conditional formatting with an > unlimited number of rules. > > Thank you to those who have helped me to create patch. > I hope I have done things correctly. You will find the patch in 2 > attachment. Wow, I'm impressed by how good job you did, esp. considering the fact that this is your first submission :) I've applied the patch and tested it and (save some small issues), it works reasonably well. Thanks so much for that. Since this is quite a big feature patch, you're gonna receive rather long feedback from me, please don't be put off by that: 1) svx part of the patch is mostly OK ... except for the long list of new #includes. As the (French) comment says, not all of them are needed Now for sc/calc part: 2) I find "Insert" button (newly added to the dialog) a bit redundant. All it does is that it appends an empty condition rule at the end of the list (position N+1) -- the same thing can be achieved by enabling/selecting checkbox by Nth rule in the list -- the scrollbar then moves, so the users see they can add more rules. Additionally, its function is a bit buggy -- it tends to check some boxes that weren't previously checked and populates the affected entries with some default values (zeroes etc.) Therefore I'd suggest to remove it (+ related code as well) ... but we can discuss this further, it's a matter of taste. 3) In ScConditionalFormatDlg::InsertEntry and ScConditionalFormatDlg::AddEntry -- instead of handling/copying array of pointers to conditional format entries in this way, it'd be cleaner to work with some C++ container holding the pointers to entries -- std::vector or boost::ptr_vector 4) In ::Refresh and ::UpdateValueList (as well as ::CondNChecked) methods really, really lot of code is duplicated/copy&pasted around. That's on one hand consistent with the rest of the code in this class (yeah, unfortunately), but on the other hand not very nice. 5) Found a small buglet while testing (easy to fix) -- for newly appended condition entries, pre-selected style should be "Default". With your patch, it is the one that comes first in alphabetically sorted list (e.g. if I create a custom style named "Blue", it'll come before "Default" and all the newly created rules will have "Blue" style as default) Sooo, what I'm gonna do now is that after fixing some very obvious quirks (reduce the list of includes in svx, fix some typos -- CondNChecked instead of CondNCheked, and three-liner fix for issue 5) I'll push the patch as it is, so that LibO users can use the feature already and give it a good deal of testing. As for the code cleanup -- this is mostly about issues 3 & 4 -- we can do it together later. Or, if you feel like it, you can try to improve the code yourself and send a patch to LibO list for review Again, thanks a lot for the patch and keep up good work. Should you have any questions, please don't hesitate to poke any of Calc hackers (me, kohei, muthusuba etc.) on IRC B. -- \ Katarina Machalkova \\\__o LibO developer __\\\'/_ & hedgehog painter 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] ld dynamic linker hash style
Francois Tigeot píše v St 06. 04. 2011 v 17:04 +0200: > On Wed, Apr 06, 2011 at 03:59:34PM +0200, Petr Mladek wrote: > > > > I have found that there already was a check for --hash-style. So, I used > > your draft and itegrated it into the existing test, see > > http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=34e8665b5d3544c48086701d9f758ef0b9d900f8 > > Er, wrong move :-( > > > Please, do not feel offended that I did not use your patch as is. The > > patch was nice but needed more love. > > I'm well aware of that, I'm no autoconf specialist and it was a > work-in-progress. > > Let me be offended on a different point ;-) > > the test you have reused and the one I just wrote are for two different > things. > We have two things here: > > - the first check tested for --hash-style=gnu option support. > ld supports it, result = yes If you look at my change, I have removed this check. IMHO, it is obsoleted by the AC_TRY_RUN one. ;-) AC_TRY_LINK compiles and links the program. AC_TRY_RUN compiles, links, and run the program. IMHO, it does not make sense to enable --hash-style=gnu if the application can be linked and not started on the given system. So, the AC_TRY_LINK is not needed because the same success/failure is detected also by AC_TRY_RUN. > - the check I just wrote tested if binaries linked with the --hash-style=gnu > can be run > something in the system doesn't grok it, result = no > > By integrating the two autoconf checks, we're back to a situation where > the build process happily links binaries with --hash-style=gnu and crashes > a few moments later trying to run them. Are you sure? Have you looked at my changes? :-) > What I wanted to do is set a reasonable default of "gnu" or "sysv" for the > --with-hash-style option depending if the machine can run such binaries or > not. I hope that I did the same. The only difference might be that my approach does not care only about the default. In addition, it does not allow to force "gnu" on systems that are able to link but are not able to run such programs. IMHO, it does not make much sense. It would even cause compilation problems because some helper tools need are compiled and ran during build. Or did I miss anything? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] icon in GNOME3
David Tardon wrote: > Well, not really. I just fixed the sysui/desktop/shared/create_tree.sh > script to use 128x128 px versions of the icons (that we had had already) > in addition to the other, smaller, resolutions. Of course the best thing > to do would be to install scalable versions of the icons alongside the > scaled ones, but I haven't found these anywhere in the tree... Do we > have SVG's of the icons? > Hi David, all, canonical bug for all things icon is: https://bugs.freedesktop.org/show_bug.cgi?id=33229 Not necessarily suggesting to put all issues there - but spin-outs should be listed as depending bugs. Cheers, -- Thorsten pgpEhbADYYYuR.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
On Wed, Apr 06, 2011 at 03:59:34PM +0200, Petr Mladek wrote: > > I have found that there already was a check for --hash-style. So, I used > your draft and itegrated it into the existing test, see > http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=34e8665b5d3544c48086701d9f758ef0b9d900f8 Er, wrong move :-( > Please, do not feel offended that I did not use your patch as is. The > patch was nice but needed more love. I'm well aware of that, I'm no autoconf specialist and it was a work-in-progress. Let me be offended on a different point ;-) the test you have reused and the one I just wrote are for two different things. We have two things here: - the first check tested for --hash-style=gnu option support. ld supports it, result = yes - the check I just wrote tested if binaries linked with the --hash-style=gnu can be run something in the system doesn't grok it, result = no By integrating the two autoconf checks, we're back to a situation where the build process happily links binaries with --hash-style=gnu and crashes a few moments later trying to run them. What I wanted to do is set a reasonable default of "gnu" or "sysv" for the --with-hash-style option depending if the machine can run such binaries or not. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] use RTL_CONSTASCII_USTRINGPARAM
Licesed under LGPLv3 and GPL.
From e7cbf2c25e1b08a2421663eaf5639df30a536ee4 Mon Sep 17 00:00:00 2001
From: Xisco Fauli
Date: Wed, 6 Apr 2011 16:53:52 +0200
Subject: [PATCH] use RTL_CONSTASCII_USTRINGPARAM
---
xmloff/source/chart/SchXMLAxisContext.cxx| 88 +-
xmloff/source/chart/SchXMLChartContext.cxx |2 +-
xmloff/source/chart/SchXMLExport.cxx |4 +-
xmloff/source/chart/SchXMLLegendContext.cxx |6 +-
xmloff/source/chart/SchXMLSeries2Context.cxx |2 +-
5 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/xmloff/source/chart/SchXMLAxisContext.cxx b/xmloff/source/chart/SchXMLAxisContext.cxx
index b4efdbb..149b6e1 100644
--- a/xmloff/source/chart/SchXMLAxisContext.cxx
+++ b/xmloff/source/chart/SchXMLAxisContext.cxx
@@ -178,18 +178,18 @@ Reference< drawing::XShape > SchXMLAxisContext::getTitleShape()
{
case SCH_XML_AXIS_X:
if( m_aCurrentAxis.nAxisIndex == 0 )
-aPropName = OUString::createFromAscii( "HasXAxisTitle" );
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM( "HasXAxisTitle" ));
else
-aPropName = OUString::createFromAscii( "HasSecondaryXAxisTitle" );
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM( "HasSecondaryXAxisTitle" ));
break;
case SCH_XML_AXIS_Y:
if( m_aCurrentAxis.nAxisIndex == 0 )
-aPropName = OUString::createFromAscii( "HasYAxisTitle" );
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM( "HasYAxisTitle" ));
else
-aPropName = OUString::createFromAscii( "HasSecondaryYAxisTitle" );
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM( "HasSecondaryYAxisTitle" ));
break;
case SCH_XML_AXIS_Z:
-aPropName = OUString::createFromAscii( "HasZAxisTitle" );
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM( "HasZAxisTitle" ));
break;
case SCH_XML_AXIS_UNDEF:
OSL_TRACE( "Invalid axis" );
@@ -212,21 +212,21 @@ void SchXMLAxisContext::CreateGrid( OUString sAutoStyleName, bool bIsMajor )
{
case SCH_XML_AXIS_X:
if( bIsMajor )
-aPropName = OUString::createFromAscii("HasXAxisGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasXAxisGrid"));
else
-aPropName = OUString::createFromAscii("HasXAxisHelpGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasXAxisHelpGrid"));
break;
case SCH_XML_AXIS_Y:
if( bIsMajor )
-aPropName = OUString::createFromAscii("HasYAxisGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasYAxisGrid"));
else
-aPropName = OUString::createFromAscii("HasYAxisHelpGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasYAxisHelpGrid"));
break;
case SCH_XML_AXIS_Z:
if( bIsMajor )
-aPropName = OUString::createFromAscii("HasZAxisGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasZAxisGrid"));
else
-aPropName = OUString::createFromAscii("HasZAxisHelpGrid");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasZAxisHelpGrid"));
break;
case SCH_XML_AXIS_UNDEF:
OSL_TRACE( "Invalid axis" );
@@ -418,21 +418,21 @@ void SchXMLAxisContext::CreateAxis()
{
case SCH_XML_AXIS_X:
if( m_aCurrentAxis.nAxisIndex == 0 )
-aPropName = OUString::createFromAscii("HasXAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasXAxis"));
else
-aPropName = OUString::createFromAscii("HasSecondaryXAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasSecondaryXAxis"));
break;
case SCH_XML_AXIS_Y:
if( m_aCurrentAxis.nAxisIndex == 0 )
-aPropName = OUString::createFromAscii("HasYAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasYAxis"));
else
-aPropName = OUString::createFromAscii("HasSecondaryYAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasSecondaryYAxis"));
break;
case SCH_XML_AXIS_Z:
if( m_aCurrentAxis.nAxisIndex == 0 )
-aPropName = OUString::createFromAscii("HasXAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasXAxis"));
else
-aPropName = OUString::createFromAscii("HasSecondaryXAxis");
+aPropName = OUString(RTL_CONSTASCII_USTRINGPARAM("HasSecondaryXAxis"));
break;
case SCH_XML_AXIS_UNDEF:
OSL_TRACE( "Invalid axis" );
@@ -468,7 +468,7 @@ void SchXMLAxisContext::C
Re: [Libreoffice] ld dynamic linker hash style
Francois Tigeot píše v St 06. 04. 2011 v 11:25 +0200: > On Tue, Apr 05, 2011 at 09:02:48PM +0200, Francois Tigeot wrote: > > On Tue, Apr 05, 2011 at 02:28:40PM +0200, Petr Mladek wrote: > > > > On Tue, Apr 05, 2011 at 11:53:55AM +0100, Michael Meeks wrote: > > > > > I guess it might be a good idea to default to 'auto' for > > > > > hash-style, > > > > > and compile and link a small test program with that, defaulting to > > > > > 'gnu' > > > > > if that is supported, and no flag if not. > > > > > > Francois, would you be able to cook up something, please? If it is > > > enough to use AC_TRY_RUN, you might find some samples in > > > bootstrap/configure.in. > > Here's a first patch to add a check if the build machine can run > --hash-style=gnu binaries. > > I still have to find a way to link this check to the AC_ARG_WITH section. It was a good start. I think that it would be confusing to integrate it to the AC_ARG_WITH section. These sections are usually pretty simple. All the more complex tests are done later in configure.in. I have found that there already was a check for --hash-style. So, I used your draft and itegrated it into the existing test, see http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4&id=34e8665b5d3544c48086701d9f758ef0b9d900f8 It seems to work here. I hope that it will work for you as well. Please, do not feel offended that I did not use your patch as is. The patch was nice but needed more love. I did not want to bother you too much. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about measure units.
Hi *, On Tue, Apr 5, 2011 at 12:31 AM, Xisco Faulí wrote: > Anyway how do you set the scale ? Drawing scale ? Yes, in Options → Draw > if so, in grid option is > still shown 0.00 km. Besides in Impress doesn't exist such an option. Setting the unit to km globally surely doesn't make any sense, it really only makes sense in drawings, where you'd add dimension lines. And as you weren't posting the correct bugID, I had no idea what you were talking about.. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Autogen.sh pb with junit
Hi Jonathan, On Wed, 2011-04-06 at 13:35 +0200, Jonathan Aquilina wrote: > Have you tested in master before pushing it to 3-4. I think its best Please read the minutes of the last TSC meeting. Bug fixes are welcome in libreoffice-3-4 without any form of approval until further notice. 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] Autogen.sh pb with junit
On 06/04/2011 13:07, Miklos Vajna wrote: On Mon, Apr 04, 2011 at 11:22:52AM +0200, Bjoern Michaelsen wrote: On current debians (I just tried sid) and Ubuntus there is the no classpath set in the system junit jar that also does not contain hamcrest. Since this problem is widespread: How about checking, if either: - the jar sets an classpath in the manifest - the jar contains hamcrest and complain explicitly "your junit jar neither sets a classpath nor includes hamcrest -- please provide a full junit jar or use --without-junit" if neither is the case. This also helps people making the right choice with the upstream jars, where both (including hamcrest and excluding hamcrest) are available. Doing this little additional testing might prevent some newcomers to run away screaming (it might not be the first issue they hit on their first build). I'm attaching a patch that tries to implement this. I've tested with our (Frugalware) junit jar where the classpath is in manifest and also with upstream junit jar, which bundles hamcrest. OK to push to libreoffice-3-4? Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Have you tested in master before pushing it to 3-4. I think its best to leave 3-4 as is for now till we test in master to confirm that nothing breaks before commiting to 3-4 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Autogen.sh pb with junit
On Mon, Apr 04, 2011 at 11:22:52AM +0200, Bjoern Michaelsen wrote: > On current debians (I just tried sid) and Ubuntus there is the no > classpath set in the system junit jar that also does not contain > hamcrest. Since this problem is widespread: How about checking, if > either: > > - the jar sets an classpath in the manifest > - the jar contains hamcrest > > and complain explicitly > "your junit jar neither sets a classpath nor includes hamcrest -- > please provide a full junit jar or use --without-junit" > if neither is the case. This also helps people making the right choice > with the upstream jars, where both (including hamcrest and excluding > hamcrest) are available. > > Doing this little additional testing might prevent some newcomers to > run away screaming (it might not be the first issue they hit on their > first build). I'm attaching a patch that tries to implement this. I've tested with our (Frugalware) junit jar where the classpath is in manifest and also with upstream junit jar, which bundles hamcrest. OK to push to libreoffice-3-4? Miklos From 2be5486a20abe69b7e96e0b8333eb42b4cfe5c90 Mon Sep 17 00:00:00 2001 From: Miklos Vajna Date: Wed, 6 Apr 2011 12:52:37 +0200 Subject: [PATCH] configure: check for junit's hamcrest dependency Make sure either class-path entry is available for hamcrest or it's bundled. --- configure.in | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/configure.in b/configure.in index 94626f1..fe2cfd4 100755 --- a/configure.in +++ b/configure.in @@ -7667,7 +7667,15 @@ if test "$SOLAR_JAVA" != "" && test "$with_junit" != "no"; then "$JAVA_HOME/bin/jar" tf "$OOO_JUNIT_JAR" 2>&5 | \ grep org/junit/Before.class > /dev/null 2>&5 if test $? -eq 0; then -AC_MSG_RESULT([$OOO_JUNIT_JAR]) +# check if either class-path entry is available for hamcrest or +# it's bundled +if "$JAVA_HOME/bin/jar" tf "$OOO_JUNIT_JAR" |grep hamcrest || \ +"$UNZIP" -c "$OOO_JUNIT_JAR" META-INF/MANIFEST.MF |grep -q 'Class-Path: hamcrest'; then +AC_MSG_RESULT([$OOO_JUNIT_JAR]) +else +AC_MSG_ERROR([your junit jar neither sets a classpath nor includes hamcrest; please +provide a full junit jar or use --without-junit]) +fi else AC_MSG_RESULT([no]) AC_MSG_ERROR([cannot find JUnit 4 jar; please install one in the default -- 1.7.4.1 pgpJJ2W269tCB.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Helgrind results for LO
> gtk a11y stack, while the initial helgrind ones end on in gdbusprivate.c > etc. The reports of races are not going to be accurate unless Helgrind sees all the sync events done by the lower level libraries. If they just use the pthread_ primitives that's fine, but if they roll their own locks etc then there will be noise until such time as the libraries are annotated to tell Helgrind what's going on. It's a not-insubstantial project. I see also you're not using the Helgrind dev branch. If you chase this more, it's worth using, since: * it shows the locks held by each thread in a race * it shows all 4 stacks involved in a lock order violation, not 3 * output format is easier to read * somewhat faster(*) and less memory-eating Branch = svn://svn.valgrind.org/valgrind/branches/HGDEV2 J (*) as in "now = as fast as treacle flowing uphill"; "before = as fast as treacle flowing uphill in a Canadian midwinter" ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build master on Windows, problem with icu
On Wed, 2011-04-06 at 10:10 +0700, Samphan Raruenrom wrote: > I try the steps explain in > http://wiki.documentfoundation.org/Development/How_to_build using the > following autogen options > $ build > dmake: Error: -- > > `./wntmsci12.pro/misc/43e56b71c407be5154de681eaa646a4a-icu4c-4_6-src.unpack' > not found, and can't be made Because there was an attempt to bump icu to 4.6, and then backed down to 4.4, I suspect a bit of a mismatch between your current tree and a previous state. rm -rf icu/wntmsci12.pro && build is likely to clear that specific issue anyway. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
On Tue, Apr 05, 2011 at 09:02:48PM +0200, Francois Tigeot wrote:
> On Tue, Apr 05, 2011 at 02:28:40PM +0200, Petr Mladek wrote:
> > > On Tue, Apr 05, 2011 at 11:53:55AM +0100, Michael Meeks wrote:
> > > > I guess it might be a good idea to default to 'auto' for
> > > > hash-style,
> > > > and compile and link a small test program with that, defaulting to 'gnu'
> > > > if that is supported, and no flag if not.
> >
> > Francois, would you be able to cook up something, please? If it is
> > enough to use AC_TRY_RUN, you might find some samples in
> > bootstrap/configure.in.
Here's a first patch to add a check if the build machine can run
--hash-style=gnu binaries.
I still have to find a way to link this check to the AC_ARG_WITH section.
--
Francois Tigeot
diff --git a/configure.in b/configure.in
index 50ea5e1..0904fdf 100755
--- a/configure.in
+++ b/configure.in
@@ -957,8 +957,13 @@ AC_ARG_WITH(system-mozilla,
WITH_SYSTEM_MOZILLA=no)
AC_ARG_WITH(linker-hash-style,
-[ --with-linker-hash-style
-], WITH_LINKER_HASH_STYLE=$withval, WITH_LINKER_HASH_STYLE=gnu)
+ AS_HELP_STRING([--with-linker-hash-style],
+ [Tells the linker to use --hash-style=choice when linking shared
+ objects. choice can be one of sysv, gnu, or both, the default
+ beeing gnu if it is supported on the build system, and sysv
+ otherwise.]),
+ WITH_LINKER_HASH_STYLE=$withval,
+ WITH_LINKER_HASH_STYLE=gnu)
AC_ARG_WITH(stlport,
AS_HELP_STRING([--with-stlport],
@@ -2825,6 +2830,26 @@ fi
AC_SUBST(HAVE_CXX0X)
+dnl ===
+dnl Test whether programs linked with --hash-style=gnu can be run
+dnl ===
+AC_MSG_CHECKING([whether programs linked with --hash-style=gnu can be run])
+
+save_CFLAGS=$CFLAGS
+CFLAGS="-Wl,--hash-style=gnu"
+
+AC_TRY_RUN([
+int main(char argc, char** argv) {
+ return 0;
+}
+], HAVE_HSGNU_SUPPORT=TRUE,AC_MSG_RESULT([no]))
+
+CFLAGS=$save_CFLAGS
+if test "$HAVE_HSGNU_SUPPORT" = "TRUE"; then
+ AC_MSG_RESULT([yes])
+fi
+AC_SUBST(HAVE_HSGNU_SUPPORT)
+
# ===
# use --ccache-skip?
# ===
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Order of filters in the Open dialog
Hello, >> My question is about exact order of filters in open dialog. >> Should they be grouped according to module they belong to? >> Now, it's working this way and to improve order there just need to be >> added more filters in UISort.xcu [1]. > > The idea to sort the filters is to relagate the less used ones to the > bottom of the list. At least in the "Save As" dialogs that would make > sense and isn't too complex to sort ;) > > You could perhaps start to fix that order before fixing the order in the > "Open" dialog. So I have send a patch. The order of filters is changed but maybe is not the best one. If so, I'll change it again. I have moved the task to completed easy hacks. regards, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Use cl.exe's -showIncludes to generate dependencies
Hi kendy, On Tue, 05 Apr 2011 22:51:34 +0200 Jan Holesovsky wrote: > The attached seems to generate nice dependency files for me - can you > please check for obvious mistakes / omissions? I'd like put it to > libreoffice-3-4, to save us from the obsolete makedepend, and to > speedup the build on Windows. A good starting point. However, there are some things missing there still, I guess: 1) Handling of errors Maybe I missed it, but arent you eating all compiler errors? 2) l10n of MSVC Localized versions of cl.exe will localize the "Note: including file:" string. Thus one would best make a "test-compile" in configure and find out how the string actually looks like on this machine. 3) case sensitivity For '#include ""' includes cl.exe creates all lowercase filepaths, while for '#include <>' it does the right thing and keeps case. make however is case sensitive (which makes sense, given that is is multiplatform and we are using a version running on a unix emulation even on windows). $(OUTDIR)/Foo.h and $(OUTDIR)/foo.h are different beasts for make. 3) is the hard one, as there is no easy way to derive the case of filenames from the all lowercase path. Checking on the fly is IO and thus expensive. Caching the filenames might make thing easier, but is also introducing complexity and fragility. Best Regards, Bjoern -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] writing project contribution
Hi Luiz, First - welcome to LibreOffice ! :-) On Tue, 2011-04-05 at 16:16 -0300, Luiz Henrique Natalino wrote: > hello, is there any way to write on the website of the contribution > libreoffice saying that doing? how? Trying to parse your question; I think it turns into: "how do I write on the easy hacks page that I'm working on a task" ? :-) If so, you need to head to: http://wiki.documentfoundation.org/Development/Easy_Hacks and click "Login / Create Account" at the top right. Create an account, then log-in, and then you can edit away to your hearts content :-) Please make sure you add your name + today's date to the task as/when you lock it - if you don't make progress after a week or so, then someone else can know & take it themselves. Looking forward to your patches ! 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] [PATCH] [PUSHED] Set proper names for MS Powerpoint AutoPlay filters
Thanks, pushed! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Set proper names for MS Powerpoint AutoPlay filters
Thanks Another one just to correct two filter names. matus From c0717d52ca5c7b8200fba61a0b692b8a2ddde40e Mon Sep 17 00:00:00 2001 From: Matus Kukan Date: Wed, 6 Apr 2011 09:45:47 +0200 Subject: [PATCH] Set proper names for MS Powerpoint AutoPlay filters There was blank line for MS PowerPoint 2007 XML AutoPlay filter in open dialog, so I set the name fot it. And also there where two equal names for different filters, so I have changed one to MS PowerPoint 97 AutoPlay. --- .../filters/MS_PowerPoint_97_AutoPlay.xcu |2 +- .../impress_MS_PowerPoint_2007_XML_AutoPlay.xcu|1 + 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/filter/source/config/fragments/filters/MS_PowerPoint_97_AutoPlay.xcu b/filter/source/config/fragments/filters/MS_PowerPoint_97_AutoPlay.xcu index c19eeb4..941d750 100644 --- a/filter/source/config/fragments/filters/MS_PowerPoint_97_AutoPlay.xcu +++ b/filter/source/config/fragments/filters/MS_PowerPoint_97_AutoPlay.xcu @@ -4,7 +4,7 @@ sdfilt -Microsoft PowerPoint 97/2000/XP +Microsoft PowerPoint 97/2000/XP AutoPlay 0 impress_MS_PowerPoint_97_AutoPlay diff --git a/filter/source/config/fragments/filters/impress_MS_PowerPoint_2007_XML_AutoPlay.xcu b/filter/source/config/fragments/filters/impress_MS_PowerPoint_2007_XML_AutoPlay.xcu index 7a2e17f..d1f0bcb 100644 --- a/filter/source/config/fragments/filters/impress_MS_PowerPoint_2007_XML_AutoPlay.xcu +++ b/filter/source/config/fragments/filters/impress_MS_PowerPoint_2007_XML_AutoPlay.xcu @@ -3,6 +3,7 @@ com.sun.star.comp.Impress.oox.PowerPointImport +Microsoft PowerPoint 2007 XML AutoPlay MS PowerPoint 2007 XML AutoPlay -- 1.7.1 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ Libreoffice ] icon in GNOME3
Hi David, all, David Tardon wrote: > On Tue, Apr 05, 2011 at 11:42:42AM +0100, Caolán McNamara wrote: > > On Tue, 2011-04-05 at 11:34 +0200, Andreas Proschofsky wrote: > > > *) Add 256x256 pixel versions of the LO icons > > > > caolanm->dtardon: didn't you fix this already, or at least tweak > > something to generate the correct size ? > > Well, not really. I just fixed the sysui/desktop/shared/create_tree.sh > script to use 128x128 px versions of the icons (that we had had already) > in addition to the other, smaller, resolutions. Could you implement 256x256 px versions too? > Of course the best thing > to do would be to install scalable versions of the icons alongside the > scaled ones, but I haven't found these anywhere in the tree... Do we > have SVG's of the icons? They are part of the large source file: http://wiki.documentfoundation.org/cgi_img_auth.php/d/d4/LibreOffice_Initial_Icons-pre_final.svg While extraction of .png bitmaps is realized via a script by Thorsten Behrens, I don't see a solution for automatic creation of flat SVG files for the single icons. We could do this for the present icons manually, but I think this is not reasonable to do this on every new iteration of the icons. Does anybody know about UI integration of SVG icons on other platforms and distribtutions? Would it be reasonable to create single SVG files now? Best regards Bernhard ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Improve order of open and save as dialogs
OK. Thanks! Pushed to master. (Unfortunately my environment had problems with the diacritics in your name, so I had to drop them from the author information.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] icon in GNOME3
On Wed, 2011-04-06 at 08:07 +0200, David Tardon wrote: > On Tue, Apr 05, 2011 at 11:42:42AM +0100, Caolán McNamara wrote: > > On Tue, 2011-04-05 at 11:34 +0200, Andreas Proschofsky wrote: > > > *) Add 256x256 pixel versions of the LO icons > > > > caolanm->dtardon: didn't you fix this already, or at least tweak > > something to generate the correct size ? > > Well, not really. I just fixed the sysui/desktop/shared/create_tree.sh > script to use 128x128 px versions of the icons (that we had had already) > in addition to the other, smaller, resolutions. Of course the best thing > to do would be to install scalable versions of the icons alongside the > scaled ones, but I haven't found these anywhere in the tree... Do we > have SVG's of the icons? Just wanted to point out that GNOME3 apps usually don't install the SVGs anymore (as you really can't make a icon look good in all sizes), so if you want to follow that, the best way would be to just add hires-icon-sizes like 256x256. cheers Andreas -- Andreas Proschofsky Gentoo Developer / OpenOffice.org Twitter: @suka_hiroaki Identi.ca: @suka 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] How to disable addon installation
Olivier Hallot writes: > I second your concern. Extensions are a potentially security hole and it > should be possible to install LibreOffice without the ability to install > extensions. The extension installer, expecially the GUI should be an > option at intall time. Doesn't help me at all, as I'm on Linux and there the package is usually prebuilt by the distributor. The only thing, that would help me, is a easy way to disable extension installation even after installation. > But if you want only to disable the GUI, de-register the proper dll in > the command prompt: > > C:\Program Files\LibreOffice.org 3\Basis\program>..\..\URE\bin\regcomp > -revoke -r services.rdb -c > "vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno.dll" > vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno.dll > revoke component > 'vnd.sun.star.expand:$OOO_BASE_DIR/program/deploymentguimi.uno. > dll' from registry 'services.rdb' succesful! > > swoosh!, vanished. Just killing/renaming the relevant library also helped. Thanks for pointing me to this. Is there any way to simple toggle this even as user (non-root)? Can I, for example, place the library to somewhere in my libreoffice profile dir to re-enable extension installation? I've filed two bugs about this discussion: https://bugs.freedesktop.org/show_bug.cgi?id=36017 https://bugs.freedesktop.org/show_bug.cgi?id=36019 Yours Manuel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Improve order of open and save as dialogs
On 6 April 2011 09:42, Tor Lillqvist wrote: > Hmm, if you just change the order of the elements in the SortedFilterList > properties, why do their lengths change? I have added more filters I have seen when I open these dialogs. I think they are newer and nobody have done it yet. But not all. Some filters for import like bmp, jpeg, ... (maybe around 10, all for draw) aren't there but may be added. > (A sidenote: Why is the text mixed German/English, I mean the > "Vorlage/Template" thingies?) Just old internal names for filters. Could be changed but probably not necessary. Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Improve order of open and save as dialogs
Hmm, if you just change the order of the elements in the SortedFilterList properties, why do their lengths change? (A sidenote: Why is the text mixed German/English, I mean the "Vorlage/Template" thingies?) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [WIP] [PATCH] [PUSHED] Additional translations of German comments in libs-core/sfx2/source/
Re-replying with the PUSHED tag in the subject... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [WIP] [PATCH] Additional translations of German comments in libs-core/sfx2/source/
Thanks, pushed to master! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Use cl.exe's -showIncludes to generate dependencies
I only have a master tree that was buildable last week; don't know if it is buildable by now, but I will try your stuff in it. My 3.4 tree I use for a build-style build attempt, and it is far from actually compiling anything yet. I doubt I have space to handle another 3.4 tree. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
