as converting to bool converts any non-zero to true (which has the
value of 1 with gcc, although I'm not quite sure the spec mandates this). So
if in those examples above the return type and the type of the variable were
bool, this just works (unlike sal_Bool). With bool it can break only if
e looks as something LO-related rather than KDE-related.
Maybe Kendy knows.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
n 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 t
.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 12 of April 2011, Caolán McNamara wrote:
> On Tue, 2011-04-12 at 16:01 +0200, Lubos Lunak wrote:
> > it. Almost five times the size of data is really a lot more data for I/O
> > to shuffle back and forth.
>
> I noticed recently that my linux --eanble-symbols solver
On Tuesday 12 of April 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Tue, 12 Apr 2011 16:25:58 +0200
>
> Lubos Lunak wrote:
> > > solenv/inc/unxgcc.mk:LINKFLAGSOPTIMIZE*=-Wl,-O1
> >
> > No, I forgot to mention, that's not the one:
> > [...]
lineedit popups only, or generic? In the latter case it should
just go to SetAccelKey().
> and I saw get_desktop_session() but
> that isn't public API and I'm not sure how it's meant to be used. If
> there's a better approach, pointers welcome.
&g
On Tuesday 19 of April 2011, Christian Dywan wrote:
> > Am 19.04.2011 13:35:54 schrieb Lubos Lunak:
> > I think it makes more sense to have it as a style setting rather than
> > hardcoding a bunch of if's
>
> I don't think it makes sense as a setting, and no platf
On Tuesday 19 of April 2011, Christian Dywan wrote:
> I stumbled upon a big chunk of code that's commented out in
> ToolbarMenu::implPaint not touched since November 2005.
Pushed, thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice m
d as such it needs to be kept
for backwards compatibility for extensions.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
would be able to successfully run LO for some time :), so that'd require a
transitional period, e.g. similar to how compile warnings are fixed to make
compilation with -Werror possible. No idea how much effort this would be,
it's the technically right way, but I don't
fy this bug, let alone fix this behavior.
The attached small app fakes a single scroll to the left (change the 6's to
7's for right). Compile and link with something like 'g++
a.cpp -lXtst -lX11'.
--
Lubos Lunak
l.lu...@suse.cz
#include
#include
int main( int argc, char*
it be said more specifically what we cannot
fix currently? As I understand it we cannot break backwards compatibility
only for things related to extensions (UNO, what else?), but even there I'm
not sure what that all means code-wise.
--
Lubos L
On Wednesday 20 of April 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > I'd like to remove the backtrace printing from OSL_ASSERT and friends,
> > or, even better and if possible, make these functions work properly, i.e.
> > abort on failure (I'm not really
'Generic input/output error' :(. But I don't know a good universal
solution to this, it probably required fixing code that does things like
this.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
r it to be checked as I have no
clue about LO UI string handling or error handling (and I bow to the
creativitity of whoever has created this complex error handling system).
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/uui/source/iahndl.cxx b/uui/source/iahndl.cxx
index 868dfc1..b4186d3 100644
--- a/
On Friday 22 of April 2011, Jan Holesovsky wrote:
> Hi Lubos,
>
> On 2011-04-21 at 17:12 +0200, Lubos Lunak wrote:
> > > Then, there's sal-disable-backtrace.diff,
> > > which I can happily merge - just set DISABLE_SAL_BACKTRACE then.
> >
> > Again, it
On Friday 22 of April 2011, Kohei Yoshida wrote:
> Hi Lubos,
>
> On Fri, 2011-04-22 at 15:36 +0200, Lubos Lunak wrote:
> > Hello,
> >
> > could somebody review the attached patch for bnc#689116? When e.g.
> > Writer is not installed (which can happen with split
KDE hidding any disabled menu items anywhere, AFAIK they
always get just greyed out. I don't have any access to OS X, so I don't know
there, but a google query turned up [*], which also seems to just do that
instead of hiding.
[*] http://macintopics.com/media/2010/06/context-menu-text-s
indows 8 decides that all icons should be
pink on green, then probably LO on W8 should paint icons that way too.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
p the same switch in a very misleading way.
>
> Thanks for the nice patches, which I just pushed.
>
> So sorry it took a week to get this, IMHO helpful and sensible cleanup
> pushed.
I've reverted the KDE parts of the patch as they do not match K
ems to be pointless, as ReleaseSolarMutex()
would just return 0 otherwise. The -1 is to compensate for this one
additional acquire. Just confused and pointless, as far as I can say.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ndly JunitTest_* target is just a phony
target depending on the .../done target, so they both should work.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
at ?
I'd be interested too. I don't know about GCC (besides the rumour that PCH
there is fragile), but with Clang I actually couldn't see any noticeable
improvement when using PCH (barring the cases when it seems to make the
compile even slower for me for some reason). With MSVC the
ut incorrect #include directives should not be left in
the sources, one way or another.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ossible to check mechanically, while I
do not see a way to prevent the problem above.
Opinions on this?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
mehow ?
And do we need such a tool at all? If Glade is not capable of providing
sensible defaults for spacing and similar features, cannot our code for
loading the .ui files handle that?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice
; (See
> http://opengrok.libreoffice.org/xref/core/vcl/unx/kde4/KDESalFrame.cxx#292)
>
> Must we keep QPalette::WindowText and QPalette::Window or
> QPalette::ButtonText and QPalette::Button ?
It looks like a leftover from the KDE3 version and if it's been
(The
> style of above example would be fine with me.)
Yes, a script should be enough for this. And yes, "somebody" just needs to do
it :).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 18 of March 2013, julien2412 [via Document Foundation Mail Archive]
wrote:
> Hi Lubos,
>
> But which ones are the useless?
> QPalette::WindowText and QPalette::Window
> or
> QPalette::ButtonText and QPalette::Button
The ones which are not used.
--
Lubos Luna
quot;
>
> The 2nd produces a 'failed' but not the first.
>
> Is there some way we can propagate the failure / exit code from the
> spawned process through icerun ? perhaps that is fixed already, I have:
>
> $ icerun --version
> ICERUN 0.9.98.3
Hmm ...
and presumably they're both implemented the same way). I tried with
1 include files with GCC and the difference, if any, is just lost in the
noise.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
t; source on a quick fly in the editor is easier for the eye.
>
> How do others see this?
I think there is still so much to do before arguing about spaces or other
similar matter of taste details that have very little practical consequences.
--
Lubos Lunak
l.lu...@suse.cz
enting -fno-enforce-eh-specs in Clang should be no big deal.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
; config I assume) can change. I pondered changing that to
e.g. -1, but as I wasn't entirely sure of all the consequences of that change
in practice it should be rather rare, I didn't do anything with this part.
If this is in line with what you meant, then ok.
[*] The display vs screen
in practice, the specifications in our case are like writting out asserts
in the code, and the only questions that there should be are whether it makes
sense to have such asserts and whether they are worth the code clutter.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Monday 03 of December 2012, Michael Meeks wrote:
> On Fri, 2012-11-30 at 18:53 +0100, Lubos Lunak wrote:
> > On Friday 30 of November 2012, Stephan Bergmann wrote:
> > > I'm not sure this is a good move.
>
> ...
>
> > > Which leaves us with the be
> > On Sun, Dec 2, 2012 at 4:56 PM, Lubos Lunak wrote:
> >> The work is based on threads [1] and [2] and occassionally seeing in
> >> the commits that people doing string cleanups sometimes change ugly code
> >> to only slightly less ugly code. With the new
de
> -
> void ScGridWindow::MouseMove( const MouseEvent& rMEvt )
> {
> -fprintf( stderr, "MouseMove: %s %d %d %d\n",
> -rMEvt.IsSynthetic() ? "synthetic" : "real",
> -rMEvt.GetMode(), rMEvt.GetModifier(), rMEvt.GetB
ed buffer...
>
> yeah, someone noticed that when writing i18npool/i18nutil and wrote a
> non-memsetting version which I moved into comphelper as
> rtl_uString_alloc/rtl_string_alloc
But that doesn't make much sense, does it? What's the point of an internal
string helper functio
cause it can be
overriden by command-line, and I'm not sure if adding #include
to sal/config.h would be really included everywhere where
needed.
--
Lubos Lunak
l.lu...@suse.cz
From d525797786b148c742cad298e91183732dc575ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3
On Friday 07 of December 2012, Norbert Thiebaud wrote:
> On Fri, Dec 7, 2012 at 11:42 AM, Lubos Lunak wrote:
> > There are more such -D options that could be changed, although with some
> > it'd be better be careful, e.g. OSL_DEBUG can't go there, because it can
> &g
ig/ , created by configure. Compile command should
have -I$(SRCDIR)/config option.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 07 of December 2012, Norbert Thiebaud wrote:
> On Fri, Dec 7, 2012 at 12:56 PM, Lubos Lunak wrote:
> > On Friday 07 of December 2012, Norbert Thiebaud wrote:
> >> and we could also mandate that every source need to include
> >> #include
> >> or s
gt; +if(rString.endsWithAsciiL(".gif", 4))
...
These should be rString.endsWith( ".gif" ) . Specifying the length manually
is error-prone and unnecessary.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
n't
work out for some reason).
> My statement:
> All of my past & future contributions to LibreOffice may be licensed
> under the MPL/LGPLv3+ dual license
>
> Thank you,
> Christos.
--
Lubos Lunak
l.lu...@suse.cz
___
Lib
it if you could try
something a bit more systematic such as fixing the configure check that's
been put there for a reason instead of a half-assed band-aid somewhere in the
code. If you think that's too much work, maybe you'll change your mind as
you'll have to do
uble. Also, I modified the PCH
support a bit to make the extra PCH code very non-intrusive (it's just two
extra files in inc/pch and one line in the makefile).
It's considered experimental now, but whoever wants can indeed give it a t
patch there's also a line about the helpcontent2 git subrepository,
meaning that it's probably out of date. You need to either do 'git submodule
update' after each 'git pull -r' ('./g pull -r' in the toplevel dir does that
automatically), or delete helpcontent2
On Monday 10 of December 2012, Michael Stahl wrote:
> On 10/12/12 12:54, Lubos Lunak wrote:
> > - lack of a tinderbox to test it - I intend to switch #6 to use it and
> > see how it works in practice
>
> hopefully we'll get faster tinderbox turnarounds too...
A
it). It's always a good idea how have a brief look at the actual
commit/patch before pushing/sending it. As Michael removed the definition
before pushing, and there's nothing to do about the mail, just please check
that your further commits have this correct.
--
Lubos Lunak
l.lu.
On Tuesday 11 of December 2012, Noel Grandin wrote:
> Maybe give it a more explicit name?
> Without looking, it's not clear at all what the macro does.
>
> Perhaps
> SAL_DELETE_MEMBER
> or
> SAL_CPP11_DELETE
> ??
Good point. Pushed SAL_DELETED_FUNCTION.
--
and com::sun::star.
I don't understand what fundamental drawback you mean.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
s library, and you've just introduced usage of
it. I've pushed a fix for this.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
he initializer
is not the default value for the type.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
y bad experience here ?
>
> I seem to recall a bug (maybe fixed ?) where in the kde file dialog
> typing foo.doc as the save name would auto pick the word 6 format
> instead of the word 8 format.
Definitely fixed.
--
Lubos Lunak
l.lu...@suse.cz
___
nd?
http://cgit.freedesktop.org/libreoffice/core/commit/?id=a6e3c2b4800144df40e5f78f6f912cdc6a575a32
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
find it much simpler to
check them out in CLANGDIR/include/clang/AST/ rather than the doxygen
documentation).
It's not exactly trivial, but it's probably simpler to get than a lot of LO
code. If you decide to give it a try, feel free to ask if you r
On Friday 14 of December 2012, pkoroau pkoroau wrote:
> 2012/12/12 Caolán McNamara :
> > Could you submit a new patch with the fixups ?
> >
> > C.
>
> Sure! Thank you for the review.
Looks like this has been pushed yet, so done, thanks for the patch.
--
L
t
from plain '// TODO '. Besides, I think we've been cleaning
up the codebase from things like this for the last 2 years.
So this solution first needs a problem it's supposed to solve, sorry.
--
Lubos Lunak
l.lu...@suse.cz
___
:= $(CXX)
> endif
>
> gb_COMPILERDEFS := \
> - -DMSC \
> -D_CRT_NON_CONFORMING_SWPRINTFS \
> -D_CRT_NONSTDC_NO_DEPRECATE \
You have not removed all usage of this #define. I can see a number of '#ifdef
MSC' in the sources (and I don't kn
rything is built from
tail_build, it would be equivalent to 'make 2>&1 | tee build_error.log' .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
give it a spin.
It doesn't even build on Windows because of a stray SAL_CALL, see
668bec99efb4a15ca0fe364fa3c217baba8a6f27 .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ld includes only LinkTarget .d, not object .d files . And
LinkTarget .d files are dummies (just like object .d files) during the first
build, during that build object .d files are updated while building the
targets, and before second build LinkTarget .d files are created from
object
and the builtins are already LO-specific code anyway.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
@ -57,6 +57,7 @@ certain functionality.
>
> @li @c desktop
> @li @c desktop.deployment
> +@li @c desktop.migration
Note that the idea is that next to the area name there is a very short
description of it (especially for the non-obvious ones).
--
Lubos Lunak
l.lu...@suse.cz
_
ce/UI/GenericCommands.xcu . How do
I get the UI strings for the usage in the code (i.e. including l10n) and,
since I assume that includes removing it from the .xcu file, will something
else be affected by that?
--
Lubos Lunak
l.lu...@suse.cz
void SvxFontNameBox_Impl::CheckAndMarkUnknownFont( const OUS
assSet/Jar/unoloader/done] Error 1
> make[1]: *** Waiting for unfinished jobs
Running 'make VERBOSE=1' will show you also the executed commands, so you can
find the failing one and debug what the problem is.
--
Lubos Lunak
l.lu...@suse.cz
_
ing then. I normally use -1/-2 as
the reverse of +1/+2 and the current 'do not merge' is vague enough to mean
anything in that direction. It should include 'I disagree with the change' or
similar.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Friday 15 of February 2013, Norbert Thiebaud wrote:
> On Fri, Feb 15, 2013 at 12:36 PM, Lubos Lunak wrote:
> > That should be made more obvious in the wording then. I normally use
> > -1/-2 as the reverse of +1/+2
>
> Well, there are not symetrical:
Yes, I get that now.
(although as Norbert said
> to push the change you would need to bypass gerrit anyway, but we dont have
> to rub that it) and 'consensus'/'discussion' gives a clear road on how to
> proceed for the contributor.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
;s a good or bad idea) or some other way
would need to be found.
- it'd be good to know how fast/slow the function is. Exceptions generally
aren't very fast, but if the function was called every time in the ctor, then
depending on fast it is that might make it debug-build-only feature.
-
On Saturday 16 of February 2013, Michael Meeks wrote:
> On Fri, 2013-02-15 at 21:50 +0100, Lubos Lunak wrote:
> > > PPS: please do not shoot the messenger...
> >
> > I'm not shooting the messenger, I'm telling him that the way it is he'll
> &g
the practice with tinderboxes is often that if one of them
collects a larger number of commits between two rebuilds, then if a breakage
shows up, nobody seems to feel responsible. So, if possible, I think it'd be
better if this was run more often than 2-3 weeks, possibly as another
tin
On Monday 18 of February 2013, Tom Tromey wrote:
> >>>>> "Lubos" == Lubos Lunak writes:
>
> Lubos> This could be very useful ('catch throw' is so cumbersome in
> Lubos> gdb),
>
> Is there something we could do to improve it?
I don&#x
for MinGW cross-compilation.]),
> )
>
> +AC_ARG_ENABLE(clang,
> +AS_HELP_STRING([--enable-clang],
> +[Build using the clang compiler.]),
> +)
> +
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 26 of March 2013, Peter Foley wrote:
> On Tue, Mar 26, 2013 at 2:19 PM, Lubos Lunak wrote:
> > That already exists: configure CC=clang CXX=clang++
> > What's the point of having such an explicit option? We already have
> > enough options that reinvent the
ebc32fbe73c251719494fe
> Reviewed-on: https://gerrit.libreoffice.org/3064
> Tested-by: Petr Mladek
> Reviewed-by: Petr Mladek
I have reverted this commit, as it fails on at least two 4-0 tinderboxes
(Clang and Win-x86_6). I also couldn't find
On Friday 29 of March 2013, Noel Power wrote:
> On 29/03/13 16:18, Lubos Lunak wrote:
> > On Thursday 28 of March 2013, Noel Power wrote:
> > I have reverted this commit, as it fails on at least two 4-0
> > tinderboxes (Clang and Win-x86_6). I also couldn't find
and won't as long as it takes that
much time it takes.
I actually agree with Terence. If a library changes, its dependent libraries
should change and thus relink even without having .so <- .so dependencies. I
do not see a good use case where this would be a problem.
--
Lubos Lunak
oduce troubles like e.g.:
> - making linking against a 'private' header from another module a bit to
> easy
Both these ways, and the current way, make it about equally easy if one
really wants to do it.
> As you might guess, if we go for this I would clearly prefer the first
tons of includes. Full rebuild of
master on Win86-6 is now something like 3 hours, without PCH it'd be at least
4 (I don't remember anymore and it'd take a while to measure).
I have not tried with GCC, and with Clang it's actually not worth it at all.
--
Lubos Lunak
l.lu...
On Saturday 06 of April 2013, Bjoern Michaelsen wrote:
> Just out of curiousity, what are the numbers for sc now, if you have them
> at hand?
make Library_sc
PCH: 5:18 (PCH creation is about 24 seconds).
non-PCH: 16:38
--
Lubos Lunak
l.lu...@s
ormat really called OOoXML? Seeing this commit made me
pretty confused until I figured out after a while that it has in fact nothing
to do with OOXML.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
; get it to pass that.
Actually removing it is not a mistake. The macro is a cumbersome
micro-optimization and here it presumably doesn't make any difference. Just
calling matchIgnoreAsciiCase() should do.
Also note that LO has SAL_N_ELEMENTS macro for getting the numbe
> I would suggest not to use clang if this is your first build. _If_ you use
> clang, be prepared to do some work to keep it running now and then.
Nah, the Clang build does not break more often than GCC build. But I don't
know if Clang-3.0 builds LO without proble
ich I expect should be
fairly easy to do and just needs somebody to do it. It it to be used like
other rewriters (see the README), expect it won't rewrite anything and only
generate the data.
There's no white-listing either, but that shouldn't be difficult, and the
code could
(call
gb_StaticLibrary_use_externals,plugcon,gtk cairo))" helps with the problem,
but I assume this cannot be just hardcoded and I don't know how to do it
properly? Gbuild experts?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freed
UNO code less "noisy".
> > And it matches the natural semantics of C++, which is that it's possible
> > to pass a subtype of the expected parameter's type.
>
> hmmm... looking at the amount of boilerplate involved one gets
rol() doesn't get called anymore. As there have
been no other changes in the area, I suspect this commit. Could you please
have a look?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
tes,
> nBufSz-nBytes))>0) { nBytes += nResult;
> if (pReceiveBuffer[nBytes-1]=='\0') {
> break;
> }
> }
> -/* make sure the buffer is \0 terminated */
> -if (nBytes > 0)
&
On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
Archive] wrote:
> Lubos Lunak wrote
>
> > On Tuesday 19 of February 2013, Julien Nabet wrote:
> >> diff --git a/desktop/source/app/officeipcthread.cxx
> >> b/desktop/source/app/officeipcthr
e the overload that explicitly accepts length.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ding NUL bytes at places where the receiving side expects them,
> worked on a clean-up of that code, but didn't come around yet to push
> it. Will happen shortly.
I don't know what the code is supposed to do exactly, but just from looking
at it I agree with Matteo's c
rit.libreoffice.org/2302 :-)
It is intentional that some C++11 features are used if available, in order to
provide various benefits (SAL_OVERRIDE for example).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop
On Thursday 21 of February 2013, Michael Meeks wrote:
> Hi Lubos,
>
> On Mon, 2013-02-18 at 15:01 +0100, Lubos Lunak wrote:
> > > Heh; so "do not merge" is the equivalent of "do not submit" but much
> > > clearer and friendlier, fits inside the text
he
instsetoo_native gbuild conversion. The #7 tinderbox apparently builds fine,
but it looks like it doesn't create the .zip archives to upload, quite
possibly for similar reasons.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing lis
On Friday 01 of March 2013, Christina Rossmanith wrote:
> Hi,
>
> Lubos Lunak has prepared a huge automatically generated patch removing all
> those ::rtl prefixes. So it is a little waste of time to prepare such
> patches manually. Instead maybe you could help removing
>
ich needs to re-start on
> > first start after any upgrade to cater for potential changes in bundled
> > extensions etc.).
>
> I followed the instructions here:
> https://wiki.documentfoundation.org/QA/HowToBibisect
I have edited the page to not recommend running the binary
On Friday 22 of February 2013, Stefan Schick wrote:
> Hey,
> there are more translation patches to come in the next days...
>
> All of my past & future contributions to LibreOffice may be
>licensed under the MPL/LGPLv3+ dual license.
Pushed, thanks for the patch.
--
101 - 200 of 726 matches
Mail list logo
