Re: [Libreoffice] file name glob filter (was: Re: Order of filters in the Open dialog)
On Mon, 2011-04-04 at 12:52 -0400, Kevin Hunter wrote: At 11:59am -0400 Mon, 04 Apr 2011, Michael Meeks wrote: On Mon, 2011-04-04 at 09:39 +0200, Cedric Bosdonnat wrote: I'm not sure what we want to do for the Open dialog filters... anyone else has an idea what to do? Not worrying about 'open' would be my tip. Almost no-one manually selects a filter in the open dialog, they just expect the auto-detection to work right, and 99% of the time it might even do that ;-) In a similar vein, I would love for a *.EXT functionality, where I don't have to click on the filters, but could type in to the location bar something with a filename glob and it would filter accordingly. Like, 2010_Taxes*.ods might filter all but the files that match that glob pattern. That could be a nice idea, indeed. 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] a faster gnumake ? ...
Thats too close to be a accidental. It seems like GNU make restats every target everytime it gets named as a dependency without any caching (or expecting the OS to do the caching). And why wouldn't it? Make can not know that some files are typically static and not modified by commands being run. Consider the following Makefile (sorry this is a Windows-specific case, but the first one I could think of). The top targets are a DLL and its import library. These two targets are produced by the same command, the one that links the DLL. ALL: foo.dll libfoo.dll.a foo.dll libfoo.dll.a: foo.o gcc -shared -o foo.dll foo.o -Wl,-out-implib,libfoo.dll.a foo.o: foo.c gcc -c foo.c clean: rm foo.dll libfoo.dll.a foo.o Now, assume thre are old foo.dll and libfoo.dll.a files around, but foo.c has been edited. If Make would cache stat calls, it would not have any reason to believe that libfoo.dll.a indeed got updated, too, when foo.dll was produced by its recipe, would it? So it would run the recipe once more. Well, yeah, Make could reasonably assume that the command does indeed update both foo.dll and libfoo.dll.a as both are targets of the command and the recipe didn't contain $@. Or something like that. One probably can easily come up with more heuristics that could be added to (GNU) Make and make it better in our case. But if we start using a modified Make, we are back where we started, with our own Make. OTOH, http://savannah.gnu.org/bugs/?443 says GNU make does have a directory cache which is used for a significant performance advantage; much of the time make spends is for doing stat(2) system calls , hmm. Need to get the Make sources and investigate. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED] Removal of bogus comments
Hi Anurag,
this patch was fine. I've additionally removed some lines you've missed.
And skipped this deletion:
-sal_uInt32 exportDoc(enum ::xmloff::token::XMLTokenEnum /*eClass*/)
{return 0;}
+sal_uInt32 exportDoc(enum ::xmloff::token::XMLTokenEnum) {return 0;}
Pushed!
Christina
Am 05.04.2011 03:40, schrieb Anurag Jain:
I've updates my patch as said. I've included some more files in
this.There were lots of German
comments present in the module and I've skipped such comments
containing some bug IDs.
Hoping to see this one getting pushed :) .
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] a faster gnumake ? ...
On Monday 04 of April 2011, Norbert Thiebaud wrote:
On Mon, Apr 4, 2011 at 10:30 AM, Bjoern Michaelsen
b) be fixed by sorting out duplicates when generating the dep file. This
could be done in the solenv/gbuild/processdeps.awk(*) script and
would then likely result in a 100% speedup.
Not quite. Sure, make {void} will be faster, but at a the cost of
running a script for each dep generation, that include an alphanumeric
sort or a sometime quite large number of entry, and almost always
these entry will have a very high correlation up to all but the last
few chars
iow a likely poor performing sort.
If this really would be significant in practice, then the sort could first
compare lengths of the strings and then go backwards (or even have a hash) -
if only uniqueness is needed, then it doesn't matter what the order is.
--
Lubos Lunak
l.lu...@suse.cz
___
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. Taking it, looking into it. Please stay tuned 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
[Libreoffice] dbgmacros.hxx / dbgmacros.cxx
Hi,
after removal of comments it becomes clear that DbgAssert() is empty. It
is used for the definition of PRE_CONDITION (unused), POST_CONDITION
(used in classfactory.cxx and propertyhdl.cxx) and ENSURE (used at
several places).
I think PRE_CONDITION, POST_CONDITION and ENSURE can be removed from the
code and afterwards dbgmacros.{cxx,hxx} can be removed from the code
base. Should the macros be replaced by some more recent macros?
Christina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
shell part pushed. Christina Am 20.03.2011 00:52, schrieb Xisco Faulí: Here we go with the first round of patches. Whitespaces are not deleted anymore and all the bogus have been deleted. Everything builds allright. Part 1 -- http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz I'll post the second part soon Greetings ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] a faster gnumake ? ...
On Mon, Apr 4, 2011 at 10:30 AM, Bjoern Michaelsen bjoern.michael...@canonical.com wrote: Hi Michael, Hi all, On Mon, 04 Apr 2011 15:07:32 +0100 Michael Meeks michael.me...@novell.com wrote: stats file 1428 /data/opt/libreoffice/bootstrap/clone/writer/sw/inc/swdllapi.h Hmmm: find solver/300/unxlngx6.pro/workdir/Dep/CxxObject/sw|xargs grep swdllapi.h|wc -l 1425 BTW: cd solver/300/unxlngx6.pro/workdir/Dep/CxxObject/sw grep -l -R swdllapi.h * | wc -l 746 so sort-post-processing would only get rid of half of these... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Повышение квaлификации
БЛИЖАЙШИE СEМИНАРЫ И ТРЕHИНГИ 6 aпpeля. Cовpеменный мeрчeндайзинг в Украинe. 7 апpеля. МАСТEР-ПРЕЗЕНТАЦИЙ: пpинципы и пpавилa coздaния запоминaющихся прeзентаций 7 апpeля. Эффективныe дeловыe пеpеговоры: стрaтегия win-win 12-13 апpеля. Зміни зaконодавства у сфеpі cтaндартизації, cертифікації, сaнітарно-епідеміологічної eкспертизи xаpчової прoдукції 13 апpeля. БОНУC-сервис или pезультативные прoдажи в розницe. 13 апpeля. Эффeктивнoе pуководство coтрудниками: ключевыe компeтенции сoвременного менеджeра. 14 aпpеля. VIP-сeминар «Тaйм-менeджмент для пеpвыx лиц» 19-20 aпpеля. 7 ключeвых навыкoв руковoдителя. Кaк стaть дейcтвительно эффeктивным? 20 апpеля. Kак успeшнo пpодaвать рeклaмные площaди или «cказочные поxождения» рeклaмного aгентa 21 апpеля. Сиcтема aктивныx прoдaж - пoвышeниe прoфeссионального уpoвня, личнoй пpoдуктивнoсти и эффeктивноcти менeджeра пo прoдажам. 28 aпpеля. Paзрешительная докумeнтация в cтроительстве oт A дo Я в сoответствии c пocлeдними закoнодательными изменeниями. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] a faster gnumake ? ...
On Tue, 2011-04-05 at 09:33 +0200, Bjoern Michaelsen wrote: I did some rough measurements and they seem to make no noticeable difference on a full build. They will however make a noticeable different on a partial rebuild because it greatly reduces parsing the huge dep files. Sure - I expect this only to impact the incremental make. Running 'make -d -r' shows the reading to be the pain: Reading makefile `/data/opt/libreoffice/bootstrap/solver/300/unxlngi6.pro/workdir/Dep/LinkTarget/Library/libswdli.so.d' (search path) (no ~ expansion)... took ~1.5 seconds :-) it is 50Mb small: ls -lh libswli.so.d -rw-r--r-- 1 michael users 50M Apr 4 18:31 libswli.so.d wc -l libswli.so.d 537483 libswli.so.d It seems to me that the fundamental problem is one of flattening all dependencies of a file into a list; when in reality each file includes only a dozen other files, which in turn include half a dozen, that in turn ... In theory, make should be able to cope with some compressed / intermediate representation of that (surely?). I wonder - if we had a single phony target for each file's dependencies, and a tree of these, instead of this 50Mb flattened monster blob; if that would be significantly faster [ and/or if it is even possible ] Hmm, 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] a faster gnumake ? ...
On Tue, 05 Apr 2011 01:42:23 -0600 Tor Lillqvist tlillqv...@novell.com wrote: Now, assume thre are old foo.dll and libfoo.dll.a files around, but foo.c has been edited. If Make would cache stat calls, it would not have any reason to believe that libfoo.dll.a indeed got updated, too, when foo.dll was produced by its recipe, would it? So it would run the recipe once more. GNU make needs to rebuild everything depending on a file, if that file has been rebuild, regardless of timestamps. If any of the direct or indirect dependencies of a file are newer it will be rebuild. Other wise it would be a build-order only dependency (with :| ). Well, yeah, Make could reasonably assume that the command does indeed update both foo.dll and libfoo.dll.a as both are targets of the command and the recipe didn't contain $@. Or something like that. One probably can easily come up with more heuristics that could be added to (GNU) Make and make it better in our case. But if we start using a modified Make, we are back where we started, with our own Make. No, GNU make considers a target outdated, if the rule of any of its dependencies fired, regardless if that actually changes any timestamps. You can see that already pretty well using make --debug=b. Best, 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] dbgmacros.hxx / dbgmacros.cxx
Hi Christina
\On 05/04/11 09:11, Christina Roßmanith wrote:
Hi,
after removal of comments it becomes clear that DbgAssert() is empty.
It is used for the definition of PRE_CONDITION (unused),
POST_CONDITION (used in classfactory.cxx and propertyhdl.cxx) and
ENSURE (used at several places).
I think PRE_CONDITION, POST_CONDITION and ENSURE can be removed from
the code and afterwards dbgmacros.{cxx,hxx} can be removed from the
code base. Should the macros be replaced by some more recent macros?
the OSL_ equivalent macros probably are a suitable replacement(s),
see http://opengrok.libreoffice.org/xref/ure/sal/inc/osl/diagnose.h#53
Noel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] a faster gnumake ? ...
Hi Michael, On Tue, 05 Apr 2011 09:41:10 +0100 Michael Meeks michael.me...@novell.com wrote: I wonder - if we had a single phony target for each file's dependencies, and a tree of these, instead of this 50Mb flattened monster blob; if that would be significantly faster [ and/or if it is even possible ] In theory you could generate the direct dependencies for each header file and cxx and make a nice tree from that. In practice, it has its own set of problems: - we have a lot more headers than cxx and you would have to track the dependency file for each of those - the dep tree would get a lot deeper by that alone - this is context sensitive: header files might have different deps depending on where it was included from as DEFINEs might toggle stuff - generating the deps by the compiler is costing us almost nothing currently, doing something like that for each header _will_ cost us. - as long as we have headers in multiple locations (deliver), that can lead to fun results too. Thus that would introduce a lot of fragility and not be KISS at all. Lets not forget the words of wisdom by the Don: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Remember also that sw already has 24000 include statements alone (about 1/7 of the whole product).(*) IMHO if we want to solve this, we need to be honest to ourselves and admit that this is only the symptom of the real problem that is is the huge amount of includes we are using. A few of those might be sensible, a few of them might be superfluous and a lot of them will only be solved by better encapsulation in our codebase. Best Regards, Bjoern (*) http://blogs.sun.com/GullFOSS/entry/gbuild_to_boldy_go_where -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] ~2x faster gnumake ...
Hi there, Weelll ... nicer structures aside; having put a breakpoint in stat64 ( catch syscall stat64 FWIW ;-) - I discovered that the vast majority of our stats were not from 'stat' at all (which clearly has been optimised heavily) - but instead from 'glob': read.c (parse_file_seq) calls glob on all dependencies. For each of those it does a stat ;-) make -sr before: real0m5.795s user0m3.513s sys 0m2.274s make -sr passing 'PARSEFS_NOGLOB' to the beastie[1] real0m2.496s user0m2.342s sys 0m0.150s Which essentially killed the system component of performance, and saved a truck-load of system calls ;-) I'll do some more poking around to make it an up-stream-able, robust patch. ATB, Michael. [1] - un-conditionally breaking globbing for sure but - why not ? :-) -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] icon in GNOME3
Hi Florian, Well yes and no. The icons in the Linux binary are the right ones, but if you build from source you still get the old ones by default. To add complexity to this story: The icons in the screenshot are from the openSUSE default icon set, I've used them on my system for the screens as the LibreOffice default icons look pretty bad in GNOME3 atm. (Disclaimer to those who don't know me: I'm the author of the article in question). That's simply because we (LO) don't deliver high resolution icons right now. What GNOME Shell / GNOME 3.0 would need is shiny 256x256 Pixel resolutions. 48x48 are scaled up and look very fuzzy as a result. So what needs to be done: *) Add 256x256 pixel versions of the LO icons *) Adapt libreoffice-build to actually use them ;) *) Optionally: Make openSUSE to not use its own icons for LibreOffice ;) cheers Andreas On Mon, 2011-04-04 at 12:34 +0200, Florian Effenberger wrote: Hello, I just got notice that the LibO icon in GNOME3 seems to be the OOo logo, see http://derstandard.at/1297821927182/Ansichtssache-GNOME3---Details-der-neuen-Desktop-Generation?sap=2_slideNumber=8_seite= Anyone from GNOME reading this list and can make necessary changes? ;-) NB: I am *not* subscribed to this list, so please Cc me on all replies. Thanks, florian -- 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] icon in GNOME3
Hi, Michael Meeks wrote on 2011-04-04 17.00: Hmm - I guess, that looks like the icon we install; and the ones we're using on my desktop too (odd). then it clearly looks like a bug to me. :-) Having said that, have we fixed the palette / sizing issues around the existing icons and their integration with Tango ? it would be nice to have that for the 3.4. I have no clue. Also - I guess the design guys should have commit access to the icons by now, if not whomever is working hardest on that should get it [ please mail me privately ]. Good point... Thanks for following up! Florian -- Florian Effenberger flo...@documentfoundation.org Steering Committee and Founding Member of The Document Foundation Tel: +49 8341 99660880 | Mobile: +49 151 14424108 Skype: floeff | Twitter/Identi.ca: @floeff ___ 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 Po 04. 04. 2011 v 22:51 +0200: Hi all, During the last few days, my builds have been broken with this error message: makedepend: Shared object has no run-time symbol table I have tracked the start of my troubles to this commit: 83b781819557f269fda65ce551ec9a008fade511 http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?id=83b781819557f269fda65ce551ec9a008fade511 It adds the --hash-style=gnu string on ld invocations. --hash-style=gnu sets the type of linker's hash tables to a new .gnu.hash format. The problem is, this flag also prevents ld to write classic ELF .hash sections, preventing some systems to be able to run the generated binaries. Googling a bit, I found references to this issue on all types of systems See here for a Suse one: http://mail.openjdk.java.net/pipermail/porters-dev/2009-January/000235.html The new .gnu.hash sections are not recognized by old binutils versions such as 2.17 and may or may not be used on more recent ones. One of my machines is using binutils-2.21 and cannot run binaries linked with the --hash-style=gnu option. I need to investigate. Howewer, the fix is quite simple: replace --hash-style=gnu by --hash-style=both The --hash-style=both option generates both old and new-style sections, keeping all binutils happy. Sounds reasonable. Michael, what is your opinion? Could it cause any regression in the start up speed? Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] a faster gnumake ? ...
Now, assume thre are old foo.dll and libfoo.dll.a files around, but foo.c has been edited. If Make would cache stat calls, it would not have any reason to believe that libfoo.dll.a indeed got updated, too, when foo.dll was produced by its recipe, would it? So it would run the recipe once more. GNU make needs to rebuild everything depending on a file, if that file has been rebuild, regardless of timestamps. If any of the direct or indirect dependencies of a file are newer it will be rebuild. Hmm, but how is what you say related to the example I described? foo.c has been edited by the user, not updated by a recipe run by Make. If you are saying what I think you are saying, doing a make clean make foo.dll libfoo.dll.a in my example would have it run the recipe twice, once to update foo.dll and once to update libfoo.dll.a. But it doesn't, it says `libfoo.dll.a' is up to date. Anyway, I don't know if this is directly related to the problem(s) at hand, so I will stop using non-related examples now. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ~2x faster gnumake ...
On Tue, 05 Apr 2011 10:35:08 +0100 Michael Meeks michael.me...@novell.com wrote: make -sr passing 'PARSEFS_NOGLOB' to the beastie[1] real 0m2.496s user 0m2.342s sys 0m0.150s Kudos. Great catch! Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Easy hack: expunge duplicate enumerations in vcl
On Mon, 2011-04-04 at 23:18 +0200, Christina Roßmanith wrote: As far as I understand the description, psp::width::UC shall be removed. But shall the enum from sft.hxx or from vclenum.hxx be kept? 60:40 for vclenum.hxx I would guess. Yeah, the psprint stuff used to live somewhere else, so the enum was added there and the mapping stuff to allow that build to work, psprint got folded into vcl, so no need for the dup of that one anymore. So a) the psp:: ones definitely go, and b) definitely get replaced with the vclenum.hxx ones. The sft.hxx stuff on the other hand are from another piece of code that got merged into vcl from some third party source IIRC, and describe the values used in the truetype font format, I think those values match the physical numbers stored in those files so they should, for now anyway, get left alone, and the mappings from/to them and the vclenum values left alone. why has tools its own WIDTH_ULTRA_CONDENSED? hum, wasn't aware of that. The original commit there says move this from vcl to get xmloff free of vcl stuff, so (as a follow up maybe) it would seem to make sense to e.g. remove the dups from vclenum.hxx and have it include tools/fontenum.hxx to provide those. And if vcl is an acronym: what does it stand for? I think its Visual Components Library. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] l10n based on PO files
Andras Timar píše v Po 04. 04. 2011 v 16:51 +0200: 2011/4/4 Petr Mladek pmla...@suse.cz: Are you going to add a strict dependency on this feature? In this case, it would be great to improve the configure option for the system translate-toolkit. I could do it if you want. Yes, I'm afraid we need this feature, it is not optional. Can you please adjust the configure option. Done, see http://cgit.freedesktop.org/libreoffice/bootstrap/commit/?h=libreoffice-3-4id=918685b04662b23855efd486e0fe9e7b438176c2 Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] substantial 'glob' speedup ...
Hi guys,
Over in LibreOffice land, we're transitioning our whole build to use
gnumake - with the goal of having a single gnumake instance able to
re-build the (many thousands) of files we have, and store and act on all
of the dependencies.
Anyhow - one problem we are seeing is that as we load and parse the
~50Mb of dependencies that we need (for part of writer) we are statting
the same files involved in dependencies sometimes a thousand times or
so. We do around 700k stats with lots of duplication.
These ~all come from calling 'glob'; I append a patch that tries to
call glob only if needed - it could be done more prettily:
+ if (nlist != name)
not the nicest thing in the world; but I didn't want a big indentation
change. Timings for a make -sr with nothing to do are:
before after
real0m5.795s0m2.634s
user0m3.513s0m2.526s
sys 0m2.274s0m0.101s
Which is a worthwhile saving at least in our use case, though
naturally, being spectacularly incompetant - it is probably a
side-effect of me breaking everything ;-) Having said that, the
dependency rules (at least) appear to continue to work nicely when I
test with manual touching, and 'make check' passes ...
Thoughts much appreciated,
Thanks,
Michael.
diff --git a/read.c b/read.c
index a3ad88e..48de4fe 100644
--- a/read.c
+++ b/read.c
@@ -2824,6 +2824,20 @@ tilde_expand (const char *name)
#endif /* !VMS */
return 0;
}
+
+
+static int
+need_to_glob (const char *name)
+{
+ int i;
+ for (i = 0; name[i] != '\0'; i++) {
+if (name[i] == '?' || name[i] == '*' || name[i] == '[') {
+ return 1;
+}
+ }
+ return 0;
+}
+
/* Parse a string into a sequence of filenames represented as a chain of
struct nameseq's and return that chain. Optionally expand the strings via
@@ -3112,6 +3126,14 @@ parse_file_seq (char **stringp, unsigned int size, int
stopchar,
}
#endif /* !NO_ARCHIVES */
+ /* glob is expensive - always stating, try to avoid it if possible */
+ if (!need_to_glob (name)) {
+ nlist = name;
+ i = 1;
+ if (flags PARSEFS_EXISTS !file_exists_p (name))
+ i = 0;
+ }
+ else
switch (glob (name, GLOB_NOSORT|GLOB_ALTDIRFUNC, NULL, gl))
{
case GLOB_NOSPACE:
@@ -3174,7 +3196,8 @@ parse_file_seq (char **stringp, unsigned int size, int
stopchar,
#endif /* !NO_ARCHIVES */
NEWELT (concat (2, prefix, nlist[i]));
- globfree (gl);
+ if (nlist != name)
+ globfree (gl);
#ifndef NO_ARCHIVES
if (arname)
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] icon in GNOME3
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 ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
Hi Francois, On Mon, 2011-04-04 at 22:51 +0200, Francois Tigeot wrote: During the last few days, my builds have been broken with this error message: makedepend: Shared object has no run-time symbol table Oh - that is a downer indeed. What system are you using ? It adds the --hash-style=gnu string on ld invocations. --hash-style=gnu sets the type of linker's hash tables to a new .gnu.hash format. Right - if your gcc supports that, presumably your system library should too [ after all, it is trivial to implement, and a huge speedup for linking ]. The problem is, this flag also prevents ld to write classic ELF .hash sections, preventing some systems to be able to run the generated binaries. Right - because they are big, and there is not much point in dragging all that obsolete bloat around ;-) One of my machines is using binutils-2.21 and cannot run binaries linked with the --hash-style=gnu option. I need to investigate. So - if you want to create binaries to run on other systems, then you need to beware. You will have hideous problems beyond belief, and way beyond just linking issues: glibc symbol versions alone will break almost everything :-) Howewer, the fix is quite simple: replace --hash-style=gnu by --hash-style=both The --hash-style=both option generates both old and new-style sections, keeping all binutils happy. Well - we need to do this for the 'Generic' builds with an explicit =both (cf. distro-configs) so it can run even on ancient systems, but Linux distributions in general should use the --hash-style=gnu if it is present in the toolchain (IMHO). The attached patch does just that. So - I'm really not convinced :-) What system are you compiling on, and/or did you upgrade your gcc/binutils without upgrading glibc ? 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. Should be fairly easy to do that with an AC_TRY_RUN (?). ie. since the win from --hash-style=gnu is fairly huge, I'd like to have this by default wherever possible, --hash-style=both adds some real chunk of data we don't need to the output, so it is not a great default for a fast office suite :-) 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] file name glob filter (was: Re: Order of filters in the Open dialog)
Hi Kevin, On Mon, 2011-04-04 at 12:52 -0400, Kevin Hunter wrote: In a similar vein, I would love for a *.EXT functionality, where I don't have to click on the filters, but could type in to the location Ho hum; that starts to do quite some violence to the platform-specific file-selector dialogs; doing interactive changes to the filter logic while the user types is likely to make the behaviour of these things even worse than it is now ;-) So - in general, I'd rather prefer to see that feature in the platform file-selectors (personally), and perhaps (if anyone at all uses it), in the built-in LO selector. Nice feature idea though; be great to see it Gtk+, KDE etc. 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] [PUSHED] Build fail in scp2 on Mac - file_font_accessories.par malformed
On Mon, 2011-04-04 at 18:54 +0200, Alexander Thurgood wrote: Sorry about that, I had a sneaky suspicion that might happen, but I was uncertain as to whether attachments actually made it to the list. If I manage to do any more in the future, I'll attach them to an issue in fdo. Hey - no attachments make it through nicely, as long as they are not many megabytes in size. 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] Build of master fails on impress
Hi Rob, On Mon, 2011-04-04 at 23:49 +0200, Rob Snelders wrote: I tried to build the master but it fails on the sd-map. The problem is in sd/source/ui/framework/factories/ViewShellWrapper.cxx Ah ! :-) so I guess we recommend using the libreoffice-3-4 branch at the moment - where much of the fixing and so on is on-going for the 3.4 release. That is - if you want to help out with that :-) Of course, ideally everything should still build ;-) I'll get a master tree building myself to see what's up there, do you still have the problem after a g pull ? 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] Calc's status bar is blank
On Mon, 2011-04-04 at 14:53 -0400, Kohei Yoshida wrote: On Mon, 2011-04-04 at 14:32 -0400, Kohei Yoshida wrote: Now I'm going to figure out how to fix this... Fixed on libreoffice-3-4. It was trivial. Interesting - is there likely to be any similar badness around in other places ? and/or who moved it why ? :-) Should be merged to master whenever it gets merged the next time. Yep - I guess it might be nice to do a merge to master - we have quite a few fixes in libreoffice-3-4. 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] Build of master fails on impress
Hi Michael, I did do a pull before building. I'm trying to fix the easy-hack 3.17 VBA support add support for Worksheets.Copy and I tougth it would be best to do that in the master branch. I am just starting with helping on Libre-office, so I try to find easy-hacks to do, but not all easy-hacks are clear to me. -- Greetings, Rob On Tue, 05 Apr 2011 12:12:46 +0100, Michael Meeks wrote: Hi Rob, On Mon, 2011-04-04 at 23:49 +0200, Rob Snelders wrote: I tried to build the master but it fails on the sd-map. The problem is in sd/source/ui/framework/factories/ViewShellWrapper.cxx Ah ! :-) so I guess we recommend using the libreoffice-3-4 branch at the moment - where much of the fixing and so on is on-going for the 3.4 release. That is - if you want to help out with that :-) Of course, ideally everything should still build ;-) I'll get a master tree building myself to see what's up there, do you still have the problem after a g pull ? Thanks, Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build of master fails on impress
On Tue, 2011-04-05 at 12:12 +0100, Michael Meeks wrote: Hi Rob, On Mon, 2011-04-04 at 23:49 +0200, Rob Snelders wrote: I tried to build the master but it fails on the sd-map. The problem is in sd/source/ui/framework/factories/ViewShellWrapper.cxx 'UnoTunnelIdInit' was not declared in this scope The error looks like mine, but ViewShellWrapper.cxx should include comphelper/servicehelper.hxx and that should have UnoTunnelIdInit in it so it should work fine. Builds here and the tinderboxes are silent about it C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ld dynamic linker hash style
Hi Michael, On Tue, Apr 05, 2011 at 11:53:55AM +0100, Michael Meeks wrote: On Mon, 2011-04-04 at 22:51 +0200, Francois Tigeot wrote: During the last few days, my builds have been broken with this error message: makedepend: Shared object has no run-time symbol table Oh - that is a downer indeed. What system are you using ? DragonFly. The problem is, this flag also prevents ld to write classic ELF .hash sections, preventing some systems to be able to run the generated binaries. Right - because they are big, and there is not much point in dragging all that obsolete bloat around ;-) Well, if you can't run binaries without it, that's not so obsolete IMO. One of my machines is using binutils-2.21 and cannot run binaries linked with the --hash-style=gnu option. I need to investigate. So - if you want to create binaries to run on other systems, then you need to beware. You will have hideous problems beyond belief, and way beyond just linking issues: glibc symbol versions alone will break almost everything :-) The first step is to have the binaries run on the system they were compiled on. And I'm pretty sure I won't have any trouble with glibc ;-) What I meant to say is even with binutils-2.21, the gnu-hash option doesn't work in all cases. Howewer, the fix is quite simple: replace --hash-style=gnu by --hash-style=both The --hash-style=both option generates both old and new-style sections, keeping all binutils happy. Well - we need to do this for the 'Generic' builds with an explicit =both (cf. distro-configs) so it can run even on ancient systems, but Linux distributions in general should use the --hash-style=gnu if it is present in the toolchain (IMHO). You lost me here: with the last commit, --hash-style=gnu is the default and is not limited to Linux or specific Linux distributions. So - I'm really not convinced :-) What system are you compiling on, and/or did you upgrade your gcc/binutils without upgrading glibc ? System: DragonFly 2.9/x86_64 gcc: 4.4.5 binutils: 2.21 glibc: none Be convinced :) 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. Should be fairly easy to do that with an AC_TRY_RUN (?). That would be *much* better. Cheers, -- 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 Út 05. 04. 2011 v 13:51 +0200: 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. Should be fairly easy to do that with an AC_TRY_RUN (?). That would be *much* better. It sounds like the best solution. 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. If you want to require a minimal binutils version, you might take inspiration at http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/link-as-needed.diff Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc's status bar is blank
On Tue, 2011-04-05 at 12:20 +0100, Michael Meeks wrote: On Mon, 2011-04-04 at 14:53 -0400, Kohei Yoshida wrote: On Mon, 2011-04-04 at 14:32 -0400, Kohei Yoshida wrote: Now I'm going to figure out how to fix this... Fixed on libreoffice-3-4. It was trivial. Interesting - is there likely to be any similar badness around in other places ? and/or who moved it why ? :-) Nah, I don't think so. ;-) This was due to our recent migration of sc to gnumake, and it was just a minor copy-n-paste silliness that led to the statusbar.xml being delivered to the wrong place. I double-checked the list of uiconfig XML files in Package_uiconfig.mk, and aside from the statusbar.xml the rest looks good (to me). Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Fran franj...@gmail.com changed: What|Removed |Added Depends on||35345 -- 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] EasyHack: VBA support add support for Worksheets.Copy
On 05/04/11 14:18, Michael Meeks wrote: Hokay - can we remove it from the easy hacks page if it is not an easy hac hopefully that's premature, I thought on IRC I'd given enough hints on how to progress this, maybe though this mail was sent before we talked more about that. If not and you are still unsure how to go, don't give up, poke me again and I'll try to get you over the hump :-) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: VBA support add support for Worksheets.Copy
No it's ok. And i think I got a clue what I must do. My mail was a response to another mail, where someone wanted to start developing Libo with this EasyHack because I forgot to notice it in the wiki that I work on it. Markus 2011/4/5 Noel Power nopo...@novell.com On 05/04/11 14:18, Michael Meeks wrote: Hokay - can we remove it from the easy hacks page if it is not an easy hac hopefully that's premature, I thought on IRC I'd given enough hints on how to progress this, maybe though this mail was sent before we talked more about that. If not and you are still unsure how to go, don't give up, poke me again and I'll try to get you over the hump :-) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] file name glob filter
At 7:02am -0400 Tue, 05 Apr 2011, Michael Meeks wrote: On Mon, 2011-04-04 at 12:52 -0400, Kevin Hunter wrote: In a similar vein, I would love for a *.EXT functionality, where I don't have to click on the filters, but could type in to the location Ho hum; that starts to do quite some violence to the platform-specific file-selector dialogs; doing interactive changes to the filter logic while the user types is likely to make the behaviour of these things even worse than it is now ;-) So - in general, I'd rather prefer to see that feature in the platform file-selectors (personally), and perhaps (if anyone at all uses it), in the built-in LO selector. Nice feature idea though; be great to see it Gtk+, KDE etc. Or, put differently, there /is/ a technical reason why not: support from the native GUI toolkit libraries. Darn. I was hoping that the reason I couldn't see a QD path was because I just don't know the Gtk+/KDE APIs very well. Alas. Thanks, Kevin P.S. If this does turn out to be possible, and since the earliest I could even attempt to look at this little feature idea would be late May, I'll mention that if someone else were to look at this, the functionality I'm thinking of would be to hit return to update the dialog box, not to update on each keystroke. ___ 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,
to see if I'm walking into the right direction I've replaced
psp::width::type with FontWidth and removed some methods ToFontWidth()
which aren't needed anymore. 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.
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?
Christina
Am 05.04.2011 11:57, schrieb Caolán McNamara:
On Mon, 2011-04-04 at 23:18 +0200, Christina Roßmanith wrote:
As far as I understand the description, psp::width::UC shall be
removed. But shall the enum from sft.hxx or from vclenum.hxx be kept?
60:40 for vclenum.hxx I would guess.
Yeah, the psprint stuff used to live somewhere else, so the enum was
added there and the mapping stuff to allow that build to work, psprint
got folded into vcl, so no need for the dup of that one anymore. So
a) the psp:: ones definitely go, and
b) definitely get replaced with the vclenum.hxx ones.
The sft.hxx stuff on the other hand are from another piece of code that
got merged into vcl from some third party source IIRC, and describe the
values used in the truetype font format, I think those values match the
physical numbers stored in those files so they should, for now anyway,
get left alone, and the mappings from/to them and the vclenum values
left alone.
why has tools its own WIDTH_ULTRA_CONDENSED?
hum, wasn't aware of that. The original commit there says move this
from vcl to get xmloff free of vcl stuff, so (as a follow up maybe) it
would seem to make sense to e.g. remove the dups from vclenum.hxx and
have it include tools/fontenum.hxx to provide those.
From e78b1c8f6cadeeddfa6c936acdcabbe2604aedb7 Mon Sep 17 00:00:00 2001
From: Christina Rossmanith chrrossman...@web.de
Date: Tue, 5 Apr 2011 20:54:37 +0200
Subject: [PATCH] Replaced psp::width::type with FontWidth
---
vcl/inc/vcl/fontmanager.hxx| 16 ++--
vcl/unx/gtk/gdi/salnativewidgets-gtk.cxx | 23 ---
vcl/unx/headless/svppspgraphics.cxx| 20 +-
vcl/unx/headless/svppspgraphics.hxx|1 -
vcl/unx/inc/pspgraphics.h |2 +-
vcl/unx/kde/salnativewidgets-kde.cxx | 21 +++---
vcl/unx/source/fontmanager/fontcache.cxx |2 +-
vcl/unx/source/fontmanager/fontconfig.cxx | 48 +++---
vcl/unx/source/fontmanager/fontmanager.cxx | 42 ++--
vcl/unx/source/gdi/pspgraphics.cxx | 23 +--
vcl/unx/source/gdi/salgdi3.cxx | 99 ++--
11 files changed, 115 insertions(+), 182 deletions(-)
diff --git a/vcl/inc/vcl/fontmanager.hxx b/vcl/inc/vcl/fontmanager.hxx
index bb03bc3..632e304 100644
--- a/vcl/inc/vcl/fontmanager.hxx
+++ b/vcl/inc/vcl/fontmanager.hxx
@@ -36,7 +36,7 @@
#include vcl/dllapi.h
#include vcl/helper.hxx
-
+#include vcl/vclenum.hxx
#include com/sun/star/lang/Locale.hpp
#include vector
@@ -162,7 +162,7 @@ struct FastPrintFontInfo
std::list rtl::OUString m_aAliases;
family::type m_eFamilyStyle;
italic::type m_eItalic;
-width::type m_eWidth;
+FontWidth m_eWidth;
weight::type m_eWeight;
pitch::type m_ePitch;
rtl_TextEncoding m_aEncoding;
@@ -174,7 +174,7 @@ struct FastPrintFontInfo
m_eType( fonttype::Unknown ),
m_eFamilyStyle( family::Unknown ),
m_eItalic( italic::Unknown ),
-m_eWidth( width::Unknown ),
+m_eWidth( WIDTH_DONTKNOW ),
m_eWeight( weight::Unknown ),
m_ePitch( pitch::Unknown ),
m_aEncoding( RTL_TEXTENCODING_DONTKNOW )
@@ -276,7 +276,7 @@ class VCL_PLUGIN_PUBLIC PrintFontManager
int m_nPSName; // atom
rtl::OUString m_aStyleName;
italic::typem_eItalic;
-width::type m_eWidth;
+FontWidth m_eWidth;
weight::typem_eWeight;
pitch::type m_ePitch;
rtl_TextEncodingm_aEncoding;
@@ -360,7 +360,7 @@ class VCL_PLUGIN_PUBLIC PrintFontManager
rtl::OString aAddStyle;
italic::type eItalic;
weight::type eWeight;
-width::type eWidth;
+FontWidth eWidth;
pitch::type ePitch;
rtl_TextEncoding aEncoding;
@@ -521,10 +521,10 @@ public:
}
// get a specific fonts width type
-width::type getFontWidth( fontID nFontID ) const
+FontWidth getFontWidth( fontID nFontID ) const
{
PrintFont* pFont = getFont( nFontID );
-return pFont ? pFont-m_eWidth : width::Unknown;
+return pFont ?
Re: [Libreoffice] ld dynamic linker hash style
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. I'm trying, but I can't figure out how to pass the needed --hash-style=gnu option to the linker :-/ If you want to require a minimal binutils version, you might take inspiration at http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/link-as-needed.diff Thanks for the link, but I'm afraid it won't help here. The binutils version is only important when you want to generate ELF files using the new .gnu.hash section; it is of no use when you want to check if a particular system can _run_ them. Kind Regards, -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] writing project contribution
hello, is there any way to write on the website of the contribution libreoffice saying that doing? how? thanks -- Att. Luiz Henrique Natalino ___ 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
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. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] icon in GNOME3
Hi Andreas, Florian, all (CC'ing two lists because I can't reach all the people involved on one of them) Andreas Proschofsky schrieb: Hi Florian, Well yes and no. The icons in the Linux binary are the right ones, but if you build from source you still get the old ones by default. So this is a bug - the source shouldn't contain old OOo icons any more. The relevant bug report is https://bugs.freedesktop.org/show_bug.cgi?id=33229, but I don't know how far Thorsten (or anybody else?) has been able by now to update the places where the old icons appear. To add complexity to this story: The icons in the screenshot are from the openSUSE default icon set, I've used them on my system for the screens as the LibreOffice default icons look pretty bad in GNOME3 atm. (Disclaimer to those who don't know me: I'm the author of the article in question). That's simply because we (LO) don't deliver high resolution icons right now. We do. Thorsten did integrate all the different sizes we (LibO Design Team) provided. The largest scale is 256x256 for all application/document icons. They look like this: http://wiki.documentfoundation.org/File:LibreOffice_icons_256.png One month ago Jakub Steiner mentioned already the lack of 256px icons. Thorsten had been involved in this discussion, but I don't know if the source of the problem could already be found out and solved in master. If not, it's my fault too, because I didn't include the topic in the bug report until today :-( What GNOME Shell / GNOME 3.0 would need is shiny 256x256 Pixel resolutions. 48x48 are scaled up and look very fuzzy as a result. Of course. We do provide the large scale, they are just not distributed in the respective /usr/share/icons/hicolor/ folders. So what needs to be done: *) Add 256x256 pixel versions of the LO icons ... to the right folders ;-) *) Adapt libreoffice-build to actually use them ;) ... I think this might be a GUI feature ... *) Optionally: Make openSUSE to not use its own icons for LibreOffice ;) It's their decision (even if we hope they would be satisfied by our hires icons). The least we would ask is not to use OpenOffice.org symbols... Best regards Bernhard PS: Designers: We should think of providing single SVG icons (256px) to be provided as scalable sources in /usr/share/icons/hicolor/scalable. But I think it is not as easy as extracting .png files from the Inkscape source, if we want to get single flat icons for every application... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [libreoffice-design] Re: icon in GNOME3
Hi Michael, all, Michael Meeks schrieb: Hi Florian, On Mon, 2011-04-04 at 12:34 +0200, Florian Effenberger wrote: I just got notice that the LibO icon in GNOME3 seems to be the OOo logo, see http://derstandard.at/1297821927182/Ansichtssache-GNOME3---Details-der-neuen-Desktop-Generation?sap=2_slideNumber=8_seite= Anyone from GNOME reading this list and can make necessary changes? ;-) Hmm - I guess, that looks like the icon we install; and the ones we're using on my desktop too (odd). Is this already mentioned in the bug report? https://bugs.freedesktop.org/show_bug.cgi?id=33229 If not - could you please leave a comment / screenshot? Having said that, have we fixed the palette / sizing issues around the existing icons and their integration with Tango ? it would be nice to have that for the 3.4. Paulo created the icons and they have been attached to the bug. I don't know how far integration has been gone. Also - I guess the design guys should have commit access to the icons by now, if not whomever is working hardest on that should get it [ please mail me privately ]. Is there an easy way to commit without developer skills? (And without the time to learn how to build?) Additionally to this question we need a possibility to check the committed design related patches - probably this will be able to be solved by (nearly) nightly master installers... I added these points to the WWN wiki page: http://wiki.documentfoundation.org/Design/Kick-Off/WhatWeNeed#Proposals_by_Bernhard_Dippold (hopefully not interfering with Christoph's structuring of this page...) Best regards Bernhard ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Организация импортa
г. Kиeв - 15 апpеля, 2011 г. ОРГAНИЗАЦИЯ ИМПOРТA ИЗ КИТAЯ г. Kиeв, ул. Гоpького, 172 в здaнии бизнeс-цeнтра "Палaдиум-Сити", 8 эт. oф. 814 Тeл.: (0ЧЧ) ЗЗ1-6Ч1Ч, 592-756Ч AKТУАЛЬНОСТЬ Сeйчaс самoе врeмя рaбoтать c Kитаeм! Тaк кaк в дaнный мoмeнт cущeствует цeлый pяд плюсoв и пpeимуществ пpи рaботе c китaйскими пoставщиками и пpoизводителями, кoтoрыми необxодимо уcпeть вoспoльзоваться. И oб этoм мы тожe рacскажем! ЦEЛЬ СЕМИHАРА Hаучить cпeциaлистов в облаcти импoртa бeзопaсно и эффeктивно pабoтать c Китаeм, быть увеpенным в своиx дeйcтвиях и видeть oбщую кapтину пpoцeсса импортa, c минимaльным pиcкoм извлeкaть мaксимальную выгoду из рaботы c китайcкими поcтавщиками. ЦEЛЕBАЯ AУДИТOРИЯ Бренд-мeнеджеры, мeнеджeры отдeлoв внeшнеэкoномической дeятельности, pукoводители oтделoв зaкупoк, pуковoдители oтдeлов внeшнeэкoномической деятeльности, рукoвoдители предпpиятий, спeциализирующихся нa импоpте. ДОКЛAДЧИКИ Cушко Aлeкcандр Aлександрович — oргaнизовывает и ocуществляет импoрт тoваpов и прoдукции ширoкoго пpофиля из Kитая, cтpан Юго-Bосточной Aзии, Boсточной и Запaдной Eврoпы. Имeeт большoй oпыт рукoвoдителя отдeлoв BЭД кpупныx кoмпаний. Бoлee 5 лeт плoтнo paбoтает c Kитаем в сфеpе импортa, болeе 10 лeт изучаeт язык, культуpу, cоциальные оcoбенности этoй стpаны. Бизнеc-тpенер, aвтор и вeдущий ceминаров «Оpганизация импopта из Китaя», «Деловaя поездкa в Китaй». Иpина Hеcтеренко — специaлист пo налoговому плaнированию, "International Consulting Group". ПPOГPAММА 1. Поиcк товаpа и выбop пocтaвщика Cпоcобы и вoзможнoсти поиcка нужныx поcтавщиков обзоp спocобов: пo интepнeту (обзop caйтoв, тeхнология вeдения пepeговоров, прeзeнтация компaнии, пеpвый зaпрoс), пocещение выстaвoк (оcобенности oрганизации пoездки, визы, нюанcы пoceщения выстaвки, нa чтo обрaщать внимaниe) pазбор плюcов и минуcoв кaждогo, oптимальная кoмбинaция. Kак pаcшить кpуг поиcкa и сделaть прaвильный выбop. Тeндeры, обрaзцы и подбоp aссортимента (кpитepии выбоpа пoставщиков). Возмoжные pиcки и нежeлaтельные ситуaции. Kак провeрить нaдeжность пocтaвщика (спocобы пpoвeрки надежнoсти постaвщика, кaкие oрганизации мoгут помoчь в прoверке нaдeжности, cписoк региcтрационных дoкументов, aудит кoмпании). Cпоcобы пеpеговоров, услoвия и cpоки постaвки. Зaключeние договoра. (ocобенности вeдения пеpeговоров, пoлучeния нужныx нaм уcлoвий, мeтoды и пpиемы). 2. Рaзмещение и кoнтpоль выпoлнeния зaкaза Кoнтpоль пpoцeсса прoизводства, eгo cpоков (неcоблюдение cpоков, метoды бoрьбы c зaтягивaнием сpоков). Cпособы oплаты. Кaк выбpать oптимальный и безoпасный спocоб oплaты тoвapа. Bозможные риcки и пути иx снижeния (обзop ваpиaнтов oплaты, пoдpoбный разбoр фoрмы аккpeдитива, кейc: рaсчет дaт отгpузки и пpедoставления документoв, путь документoв). Cтикeры, инcтрукция, упакoвкa, экcпоpтная маpкиpовка гpуза. Oбщие и cпециaльные тpeбования к исполнeнию, пpоизвoдство нa зaказ и пoд бpендом. Соглaсование cpоков окончaния пpoизводства, дaты отгpузки и инcпекции (рeшeние кейca). Пpoведение инcпекции прoизведенного тoваpа. (виды инcпекция, oбзop инспeктoрских кoмпaний, cтoимость, пopядoк пpoвeдения, pазбoр отчетa). 3. Доcтавка зaкaза, егo легализaция нa Украинe Выбoр оптимальнoго спocоба дocтавки тoвapа (обзop видoв тpaнспорта, пpименимoсть в paботе c Китаeм, критepии выборa транcпортной кoмпании, из eго сoстоит ценa зa тpанспорт, цeны, динaмикa цeн). Тaмoженная oчиcтка тoвapа (ocобенности тaможенной очиcтки китайcкиx товapов, метoды докaзaтельства цeны, спиcок дoкументов, котopые мoгут пoмoчь в докaзaтельстве цeны, Oбзoр вoзможнoстей иcпользования Тамoженно- лицeнзионного cклада и cклада врeмeнного xрaнения). Сeртификация товаpа в Укpаине (виды cертификатов, порядoк пoлучeния ceртификата). 4. Дoпoлнитeльные cведения o Kитae. ЧТO НУЖHО ЗНAТЬ! Нoвыe cлoжнoсти импopта из Kитая (умeньшeние/увеличение вoзвpaта HДС и eго влияниe нa cтoимость импoртa, измeнeние курсa дoллаp-юaнь, изменeние цeны мaтepиалoв). Эксклюзивныe дoговора (чтo можeт дaть экcклюзивный догoвор, пpактика пpимeнения). Koпирование кaк oсобенность pаботы китайскиx произвoдителей. Haциональные пpаздники, оcoбенности (иx влияниe нa cpоки произвoдства, стоимoсть трaнcпорта и т.п.). 5. Блoк пo оффшoрам Oффшоры пpи импоpте из Китaя. Осoбенности минимизaции нaлогообложения пpи импортныx опepациях. Документoоборот и движениe товaров. Ocобенности иcпoльзование кoмпaний из Гoнконга и Beликoбритании в тopгoвле c Kитаем. Хaрaктеристика cтpан: Панaмa, Гoнконг, Beликобритания, Бeлиз. PEГЛAМEHТ Рeгистрация c 9:00 пo 9:30 Hачало в 9:30 Окончaние19:00 CТOИМOСТЬ 1300.00 гpн. зa однoгo учacтникa, (пpи oплатe нa ФЛП). 1430.00 гpн. зa однoгo учacтника, (пpи oплaте нa Юp. лицo). Для втopoгo и тpeтьeго учаcтникa cкидки — 15% B cтoимocть вxoдит: инфopмaционно-консультационное oбcлуживaние нa ceминapе, cбopник мaтериaлов, питaние, oбcуждeние дoклaдов и oбмeн мнeниями c лeктopoм. Kaждый учacтник пoлучaeт буxгалтеpский кoмплeкт дoкумeнтoв. выбор кофепауза учеба стоимость
Re: [Libreoffice] Problem with build environment: Gtk-linkage error
Hi Kayo/List So I believe that this can be your problem, zypper si -d libreoffice-bootstrap (or OpenOffice_org-bootstrap) will install the sources that LibreOffice needs to build[1], not the source of libreoffice-bootstrap. [1] - http://wiki.documentfoundation.org/Development/Linux_Build_Dependencies Do it and try to compile again. Ok, just to give feedback on this: 1.) I installed the dependencies as you (Kayo) wrote (missed that part of the wiki instructions) however as expected I had most of the packages installed already (only some mono-stuff got installed). I also pulled down a new bootstrap and pulled the rest of the sources with 'make fetch', so I had an absolutely untainted build tree. Compiled using 'make 21 | tee build.log' = same error! 2.) For the record I regularly build emacs (gtk) from source, and I never had any problems with gtk linking there. 3.) Tried to add '--disable-unix-qstart' as argument to ./autogen since my problem seems to relate to that part of the code = same error. The disable flag does not work? 4.) So I gave up on gtk and run './autogen.sh --with-num-cpus=2 --with-max-jobs=2 --without-junit --disable-unix-qstart --disable-gtk --enable-kde4', which compiled sucessfully. Also 'make dev-install' works. However when starting libreoffice it crashes with the dialog box Fatal Error, the application can not be started. [context=shared] caught unexpected exception! (BTW shouldn't it be caught an unexpected exception! ?) 5.) So any hints on how I can debug this error further would be much appreciated. What tools to use? What methods/tutorials to follow? Thanks. /Albert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] EasyHack: Improved bug filing form / flow
Hi Samuel, hi Ivan, all! Am Montag, den 04.04.2011, 22:57 +0100 schrieb Samuel Atkins: On 04/04/2011 11:14 AM, Ivan M. wrote: [...] I do have one question though: would the submitted form actually submit a bug report in Bugzilla, or would it get sent to someone for moderation/confirmation? [...] I think the plan was to have it submit directly to bugzilla, but it may well be beneficial to have some sort of moderation. I don't know whether this had been discussed already - but I think Bugzilla itself may be the tool to do the moderation (unconfirmed -- confirmed). But then it'll be helpful to identify where the bug came from ... maybe adding a keyword like BugFromSimpleBugForm that enables filtering? E.g. for letting QA focus on such issues, or even doing some statistics (e.g. how many of these bugs turned into duplicates). Last year, I've attended a very nice research talk that dealed with Mozilla bug reports and their reporters. Just by 2 cents. Thank you both for working on that! Cheers, Christoph ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Powerful Marketing News for All of Us
Hello, How would your company like to get a much greater number of sales, signups or clients. I use this system to market all 3 of my different home businesses. Please call or email me for just a minute or two of hearing how this can happen. There will be no reason you will ever need to search for contacts or clients again. Very professional, legitmate and can be used for any wholesale, retail, service or home based business. Please take a minute and call me, Sincerely, Wayne Hartunian 541-368-7437 skype pct ___ 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/bastyp, control, dialog
On Mon, Mar 21, 2011 at 17:41, Muthu Subramanian K sumu...@novell.com wrote: @Albert: There seems to be some conflicts with the newer code, would it be possible for you to fix those, please? I have pushed a few files from this patch set though. Thank you very much! PS: I had actually reviewed most parts of the patch, but when i tried to commit and do a 'pull -r' i had too many conflicts to resolve. Resolved conflicts, please see new file attached. /Albert sfx2-additional-fixes.diff.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
