't know how to do it right but also wrote it in a
way that cleaning it up will uncover another problem (I'm pretty sure I've
run into such one already).
> First one isn't an assignment but a comparison! Isn't it a little
> dangerous?
No idea what you mean.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
RA_WIDTH, false, sal_True);
20464 ^
20465 1 warning generated.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
the original makefile
> writers. An extra header file, processed by sed, rather then adding one
> item to CDEFS? Really?
Please use config_xxx.h files rather than -D flags whenever possible (which,
interestingly, is an extra header file, processed by sed, rather than adding
one item to CDEF
on?
No, but checking config.log should tell you why configure failed to find the
header.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
r', 'short' and 'unsigned' are
ancient stuff from times when the extra few bits of information mattered.
With some exceptions, nowadays the usually little storage saved by this is
just not worth the associated trouble.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ell& operator =(const OXMLCell&) SAL_DELETED_FUNCTION;
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
t; void SAL_CALL IMPL_RTL_STRINGNAME( new_WithLength )(
> IMPL_RTL_STRINGDATA** ppThis, sal_Int32 nLen ) SAL_THROW_EXTERN_C()
>
> with
>
> *ppThis = IMPL_RTL_STRINGNAME( ImplAlloc )( nLen );
> OSL_ASSERT(*ppThis != NULL);
> (*ppThis)->length = 0;
>
> in th
, I do not get this
> error. The system version is 1.49.0.1
>
> I am guessing that we are using a somewhat older version of boost.
> So: a) can anyone duplicate this? b) which version of boost should we
> upgrade to?
Use whichever one works for you. I'll have a look at the in
cppuhelper, odk - any others?), so this hopefully should be safe, but most of
the changes have been done using sed, so there may be something that I've
missed
Does somebody have a preference? I consider the last one to be the best
option.
On Thursday 03 of January 2013, Markus Mohrhard wrote:
> 2013/1/3 Lubos Lunak :
> > On Thursday 03 of January 2013, Markus Mohrhard wrote:
> >> Hey,
> >>
> >> while going through the list of calc documents crashing during import
> >> I came across gnome
nt
> to try the same. Should I update the wiki too?
If there's anything wrong or important missing, yes, go ahead.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
verted this commit in the repository. It does not build because of a
missing file and the commit message and contents suggest it was not meant to
be pushed. If it was meant to be pushed, please fix it and push again.
--
Lubos Lunak
l.lu...@suse.cz
__
thing that
you will get though, and that's comparison warnings about mixing signed and
unsigned types, and all the useless casts in our code that hide them.
It's not like OUString needs to hold a string that's more than 2G characters
long anyway.
--
Lubos Lunak
l.lu...@suse.cz
...
Hello, I'd like to ask, is there any plan to have such a mac machine? Or
preferably a shared mac build host where developers could test their changes
or find out more about tinderboxes breakages (which are sometimes rather hard
to debug from just the log)? Thanks.
--
Lubos
type actually is and the
functions would just do the right thing (well, as long as the type is not
sal_uInt8 or sal_uInt16, since, SAL types madness striking again, those are
actually sal_Bool resp. sal_Unicode).
[***] That meaning language integer types, not the SAL stuff. Overloading on
th
3-01-09_08.08.08_LibO-Dev_4.1.0.0.a
>lpha0_MacOS_x86_sdk.dmg>) but not in others (like
> <http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-01-09_08.31.
>35/>).
I think I have fixed this one in tinbuild.
--
Lubos Lunak
l.lu...@suse.cz
_
On Wednesday 09 of January 2013, Michael Stahl wrote:
> On 09/01/13 17:02, Lubos Lunak wrote:
> > Is there really such a big difference between
> > OUString::valueOf( sal_Int32( 0 ))
> > and
> > OUString::valueOfInt32( 0 )
>
> it has the advantage of being
a shell? Why would openSUSE do that in the first place?
It's when building RPM packages, which are supposed to be built with
$RPM_OPT_FLAGS.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
some simple commands used by gbuild such as
mkdir or cp, and since fork() is pretty slow on Cygwin, this makes some
operations such as delivering noticeably faster. Tinderbox #6 has been using
it for two weeks without a problem.
--
Lubos Lunak
l.lu...@su
On Wednesday 09 of January 2013, Lubos Lunak wrote:
> Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> put it there first, but still nice.
Oh well, looks like somebody actually does develop LO on Windows :). So on a
related note, two more things that might be h
On Wednesday 09 of January 2013, Lubos Lunak wrote:
> Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> put it there first, but still nice.
>
> Those of you who build on Windows, you might want to pull again from
> git://gerrit.libreoffice.org/dev-tools
‘valueOf(sal_Unicode&, int)’ is ambiguous
Should be fixed now.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
gt; way.
>
> Hmm, if I try and build just unotools, I get the following error when
> building unotools_inc :
> gb_Deliver-deliver : file does not exist in solver, and cannot be
> delivered :
> /Users/Shared/Repos/LO/core/solver/unxmacxi.pro/lib/libcomphelpgcc3.dylib
make
version and if it's really needed this way? It dates back to 2009, so repo
history is as usually useless.
[*]
ERROR: The following files could not be found:
ERROR: File not found: Microsoft.VC80.CRT.manifest
ERROR: File not found: msvcp80.dll
ERROR: File not found: msvcr80.dll
--
Lubos Lu
argument first to convert from the cygwin
> filesystem structure to the Win32 representation.
> i.e. from "/cygdrive/C/libo" to "C:\libo"
I have not done this, apparently make always gets windows paths when building
LO, or does somebody have a problem with this (builtins ha
On Thursday 10 of January 2013, Michael Meeks wrote:
> On Wed, 2013-01-09 at 20:01 +0100, Lubos Lunak wrote:
> > Looks what I found under the tree! Faster make for Cygwin. Granted, I had
> > put it there first, but still nice.
>
> Nice work ! :-)
>
> I'
- some regular expression magic will do most of the
> work.
I expect it won't, regular expressions can't tell what foo is in "valueOf(
foo )". Unless all you want to convert is only places which do the explicit
cast, this will need a (fairly simple) Clang plugin.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
e default noopt flag to use when doing debug build. And I don't
quite understand why you'd want this change, what problem are you trying to
solve?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
htt
On Thursday 10 of January 2013, Noel Grandin wrote:
> On 2013-01-10 15:55, Lubos Lunak wrote:
> > - There's no need for valueOfChar(). There is already OUString ctor from
> > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > thing complic
On Thursday 10 of January 2013, Tomáš Chvátal wrote:
> 2013/1/10 Lubos Lunak :
> >> As written in subject the variable is used on multiple targets and it
> >> ignores the user defined cflags/cxxflags.
> >> This should never happen and all our targets should take int
On Saturday 05 of January 2013, Michael Meeks wrote:
> On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote:
> Having said that - it is something we really want to do; can we drop
> the published easy hack bug in this regard (or just close it) to avoid
> the drip of patches there
d, it's better to fix it completely rather
than just slightly reduce the problem. And for that it would be better to
remove the original valueOf() completely, and that results in all the
follow-up issues that I raised.
--
Lubos Lunak
l.lu...@suse.cz
4.0.1, right?). Try if the file compiles successfully with 'make
DEBUG=1', that will disable optimizations.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
't the new flags be initialized in gb_LinkTarget_LinkTarget?
- (as a general rule) for non-obvious commits, please include in the commit
log message not only what but also why, such as a link to this thread. In a
year somebody's bound to want to reshuffle the f
On Friday 11 of January 2013, Noel Grandin wrote:
> On 2013-01-10 15:55, Lubos Lunak wrote:
> > - There's no need for valueOfChar(). There is already OUString ctor from
> > sal_Unicode, so the valueOf() overload for it is just making an obvious
> > thing complicated. Code
On Friday 11 of January 2013, Jean-Noël Rouvignac wrote:
> 2013/1/10 Lubos Lunak
>
> > > > Unless all you want to convert is only places which do the explicit
> > > >
> > > > cast, this will need a (fairly simple) Clang plugin.
> > >
> >
OUString
> convertion have to be carefully audited by hand,
What you wrote above is AFAIK not written down anywhere, not in the wiki
page, not in the (non-existent) String class documentation, so any bets on
what the reality is?
Could you please add these cases to the strin
overloads, for anything except signed/unsigned char/short:
On Friday 11 of January 2013, Lubos Lunak wrote:
> So, based on this, the best solution to the problem that I can see is
> creating fromNumber() or number() , overloaded for all signed/unsigned
> int/long/long long types and all flo
I've commented out calling this specific test, until it gets
fixed.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
chosen over
unsigned char AKA sal_Bool , so Caolan added it in
e8bbb76827dd7a0e30d7d1db34a812a84d85f390
- if SvStream gets overload for bool, the warning can be dumped
Or am I missing something there?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreO
nge and
didn't get this one quite right.
> If testintrosp.cxx is still used, an idea how to make this line more clear
> (and perhaps removing the double use of OUString)?
aRetStr += " (Typ: " + xIdlClass->getName() + ")";
--
Lubos Lunak
l.lu...@suse
blematic ones. Given that a number of system typedefs are internally
unsigned integers despite all the signed vs unsigned trouble this causes,
usage of the type is much more likely than usage of a problematic value of
the type, so IMO it makes mo
On Monday 21 of January 2013, Stephan Bergmann wrote:
> On 01/21/2013 06:05 PM, Lubos Lunak wrote:
> > On Monday 21 of January 2013, Stephan Bergmann wrote:
> >> While the gotcha of printing a large unsigned value as a negative value
> >> thanks to calling rtl_ustr_value
t copied to solver, and installer creation failed.
> Also it did not work in VC90 case.
So why is this not said in the commit log message? As it is, there was no way
to find out what your commit was actually about, other than the obvious.
--
Lubos Lunak
l.lu...@suse.cz
_
but I don't have an estimate for download. MSVC
downloads only those .pdb files it actually needs, and it can cache them
locally, so it's hopefully not that much.
- is there any other option I should be asking :) ?
Attached is a tinderbox master.sh script I currently use.
--
ying
font system supports and then just uses it normally as if it was a system
font).
There's a class EmbeddedFontsHelper in VCL that I created for handling
embedded fonts, that should be the place to start if you want to give
implementing this a try.
--
Lubos Lunak
l.lu...@suse.cz
diff --
x27;s use, and convert or reuse back
when writing out a document.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
s on
improper locking, but release builds still managed to cope with it somehow
(more often than not, anyway).
Developer builds should of course fall flat on their face in such cases, but
in practice it's probably better to value end product stability more than
practically
or
> libreoffice-4-3, but it was a mistake. I reverted it.
My bad, the original code had several unhandled switch cases together and I
overlooked that (not that I get how the fix worked in master).
Andras, could you please include the commit back to 4.2+4.3 together with
74c6ba1b741ae76a
his instead of the primitive&working way of having parents
responsible for cleaning up their children on destruction? Stack-allocated
objects is probably the most sensible C++ lifecycle management ever, so if it
doesn't work with vcl, vcl has got to be seriously broken in that regard.
--
+ would support better names for Writer (Bjorn)
> + can re-write classes with Clang ? (Michael)
Clang should be able to rewrite pretty much whatever would matter. E.g.
compilerplugins/clang/store/changefunctioncalls.cxx could be used to rename
all calls of a specific function.
On Monday 08 of December 2014, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Fri, Dec 05, 2014 at 06:46:17PM +0100, Lubos Lunak wrote:
> > On Thursday 04 of December 2014, Michael Meeks wrote:
> > > * Large scale renames (Kendy)
> >
> > ...
> >
> > >
n-hidden visibility).
Given we have SAL_DLLPUBLIC_TEMPLATE, it seems likely that there shouldn't be
any big trouble there.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
integrated,
for icecream I have a patch but compilers do not allow specifying proper path
refering to the .dwo file when building in a different path).
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.
a pointer to a member function, because that one requires
also the this pointer, so you need to go with boost::bind. See e.g. 96369e97.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.f
o hide its boost
> usages from the header?
He can't. Signals usually form part of the public API of a class.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
y
> http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
Sadly, it'd also break it considerably. Unless that has improved recently
(which I doubt), things like hidden symbol visibility make these functions
practically useless.
--
Lubos Lunak
l.lu...@collabora.com
___
On Monday 15 of August 2011, Miklos Vajna wrote:
> On Mon, Aug 15, 2011 at 05:16:17PM +0200, Lubos Lunak
wrote:
> > I'm implementing .docx OOXML support for writing math formulas. As this
> > is something that could be used not only by Writer but also by other
>
On Tuesday 16 of August 2011, Caolán McNamara wrote:
> On Mon, 2011-08-15 at 17:16 +0200, Lubos Lunak wrote:
> > I already have a pointer to SmModel and SmDocShell (I can get it the same
> > way the .doc code does) and just need to call their method, passing the
> > XML se
ent.
You need to handle the else case as well.
If this is fixed, you have my ACK.
> +
> +return *this;
> +}
>
> All is now working fine, and that later commit could be applied to 3.4
> safely.
--
Lubos Lunak
l.lu...@suse.cz
__
On Tuesday 16 of August 2011, Michael Meeks wrote:
> Hi Lubos,
>
> On Tue, 2011-08-16 at 12:09 +0200, Lubos Lunak wrote:
> > No, starmath doesn't need to call back to writer. The problem is that
> > this is still needlessly complicated. How about the attached pa
ng it and explicitly marking problems in the XML structure with an
easily visible comment.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Thursday 18 of August 2011, Bjoern Michaelsen wrote:
> Hi Lubos,
>
> On Tue, 16 Aug 2011 12:09:19 +0200
>
> Lubos Lunak wrote:
> > No, starmath doesn't need to call back to writer. The problem is
> > that this is still needlessly complicated. How about the
On Thursday 18 of August 2011, Lubos Lunak wrote:
> Is that true in practice? Sw and writerfilter have a hard depedency on
Correction: Writerfilter does not. It doesn't change anything though.
> filter already. I only added few more dependencies to starmath that sw
> al
On Thursday 18 of August 2011, Bjoern Michaelsen wrote:
> On Thu, 18 Aug 2011 08:31:55 +0200
>
> Lubos Lunak wrote:
> > On Thursday 18 of August 2011, Lubos Lunak wrote:
> > > Is that true in practice? Sw and writerfilter have a hard
> > > depedency on
> >
On Thursday 18 of August 2011, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> > However, I can't help noticing that the template layout is ... er, not
> > suitable for easy use:
>
> How about attached patch? Does that address your points?
It does, but does it real
On Thursday 18 of August 2011, Bjoern Michaelsen wrote:
> Hi all,
>
> On Thu, 18 Aug 2011 10:21:54 +0200
>
> Lubos Lunak wrote:
> > It does, but does it really need to be so chatty to repeat the
> > obvious facts that each contributor's copyright relates only
as, given it was
based on KDE3, so even then it'd be probably better to have one common base
and build two different versions from it (note that in this case also Trinity
should not use KDE3 library and header names).
--
Lubos Lunak
l.lu...@suse.cz
__
> > improve the readability.
>
> autoconf stuff isn't readable anyway, so.. ;-)
But that doesn't mean we intentionally have to make it even worse :).
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
doubt ccache warrants
being enabled by default just like that.
> I don't do that in configure for the same reason we don't change
> CCACHE_DIR or the cache dir size.
> Using ccache if available is one thing... but trying to
> 'auto-magically' optimize ccache is
On Saturday 10 of September 2011, Norbert Thiebaud wrote:
> On Fri, Sep 9, 2011 at 1:22 PM, Lubos Lunak wrote:
> > Since there (AFAIR) haven't been any actual data presented in the
> > discussion
>
> here are some number for my linux buildbot.
Ccache hit statistics f
i.documentfoundation.org/Development/Unit_Tests to
match the current status.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
good.
> i don't think it's a good idea that the Linux developers introduce such
> regressions
Agreed, but Linux developers getting mysterious crashes is not a very good
idea either, so it is a question if STL debug mode is worth it.
--
Lubos Lunak
l.lu...@suse.cz
__
check for this automatically, so
the only way to find such a problem would presumably be getting a strange
crash.
But I'm not against, if not having STL debug enabled on Linux makes building
on Windows even more of a nightmare, then I guess we could live with that.
--
Lubos Lunak
l.lu..
bstractions, especially in a
non-optimized build.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wednesday 21 of September 2011, Bjoern Michaelsen wrote:
> On Wed, 21 Sep 2011 12:55:44 +0200
>
> Lubos Lunak wrote:
> > You forgot Qt4/KDE4. LO does not use STL with it, so this is just to
> > show that it's not so trivial to check if there's a potential
>
heck.
Even if ods does not officially store it, presumably you can have an
LO-specific field where LO could cache the value for faster reading anyway,
no?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.o
t.
It's going to take ages for it all to be translated manually and IMO the
translations can be occassionally useful, even if of questionable quality.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop
he pO->GetData() to something like
> po->data(), instead of &(*pO)[0] (and similar) used on many places...
That same would be allowed by
class bytes : public std::vector
{
public:
const sal_uInt8* data() const { return &front(); }
...
--
Lubos Lunak
l.lu...@suse.cz
___
living Child(s) destroyed:
21SfxEmptySplitWin_Impl (window text: '')')
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
his :)
Possibly 'help catch' and 'help commands' could make this easier/faster, but
I have not actually tried it.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
wants this would
need to examine the makefiles it generates.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
ease (freeze is Dec 5th) quite
> easily.
The original mail rings a bell ...
http://lists.freedesktop.org/archives/libreoffice/2011-September/017515.html .
And I don't remember any reply to my questions, and I don't see anything
changing since then,
ch
OSL_ASSERT is really meant to assert and which is just a warning.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
backwards
compatibility with KDE3 or not. The configure checks in the patch search for
KDE3/Qt3 names, so I would assume the answer is yes. If not, then at least
that part of the patch is definitely wrong.
--
Lubos Lunak
l.lu...@suse.cz
--- /home/llunak/build/src/libo/vcl/unx/kde/salnativewid
27;t say I understand the actual problem, but if you want to configure on
a system with unusual locations, there's $QT4INC and $QT4LIB.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
minute and write
something short. The same applies whenever you write something new of course.
Now that you know how, there's no real excuse.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
d I don't really dare to just guess, as the 'return TRUE' part is a clear
evidence the function was written by somebody brain-damaged.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http:/
me to the right
places in the code? Thanks.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
iant, perhaps they should
be simply rather fixed/improved
- WTH should we intentionally have two sets of one functionality again?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
that is supposed to work.
What do you suggest to do about it?
PS: I've attached a backport of the Qt change to
https://bugs.freedesktop.org/show_bug.cgi?id=40298 .
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Tuesday 22 of November 2011, Stephan Bergmann wrote:
> On 11/22/2011 05:17 PM, Lubos Lunak wrote:
...
> I did not commit it in order to stop any discussion. Sorry if it looked
> that way. Rather, as I did not get any totally disagreeing reactions, I
> thought it would be easier to
lso, string usage in LO is rather cumbersome as it is and in general it'd be
probably a good trade-off to waste a couple of bytes on each string operation
that doesn't need a whole line of code to express a trivial operation.
--
Lubos Lunak
l.lu...@suse.cz
_
e does not
have SwNode as its first base class (and trying to change that goes horribly
wrong). But I myself wouldn't consider that a good reason for keeping the
serials.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing li
On Tuesday 22 of November 2011, Michael Meeks wrote:
> On Tue, 2011-11-22 at 18:26 +0100, Lubos Lunak wrote:
> > Since 3.4 at least, when run with KDE4 integration, LO kind of happens
> > to have a runtime dependency on a yet unreleased Qt version, otherwise LO
> > w
On Wednesday 23 of November 2011, Michael Meeks wrote:
> On Wed, 2011-11-23 at 14:56 +0100, Lubos Lunak wrote:
> > And some of the arguments are rather weak as well, I can get you easy to
> > use and read, better to translate and similarly space efficient without
> >
On Wednesday 23 of November 2011, Lubos Lunak wrote:
> I expect it would be even possible to achieve such single in-place call
> even for the LOG( "P is " << p << " and b is " << b ) case, or even do this
> for string+string operation, which would tu
al data is split,
then the concatenation has to happen at some level.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
call
> SmOoxmlImport::handleBorderBox(void)"
> (?handleBorderBox@SmOoxmlImport@@AAE?AVOUString@rtl@@XZ)
> c:/libreoffice/workdir/wntmsci12.pro/LinkTarget/Library/smlo.dll : fatal
> error LNK1120: 3 unresolved externals make[1]: ***
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
it uses?). Moreover, in Qt-based land -Whadow
is (AFAICT) usually considered a nuisance rather than help (and this shows
why), so I expect nobody will even seriously look at it anyway, for a reason.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
201 - 300 of 726 matches
Mail list logo
