> The patch is well tested and works as expected, except of one Ui-issue:
> When loading a file with a shaded box, the color is wrong within LyX. Take
for example the
> attached LyX-file where the color is set to yellow. Yellow is correctly
recognized and used to
> paint the button in the menu D
Am 08.04.2010 02:07, schrieb Uwe Stöhr:
While compiling branch, I noticed a few warnings in GuiToolbar.cpp.
GuiToolbar.cpp:909: warning: suggest parentheses around && within ||
GuiToolbar.cpp:910: warning: suggest parentheses around && within ||
GuiToolbar.cpp:911: warning: suggest parentheses a
jeanpierre.chretien writes:
While compiling branch, I noticed a few warnings in GuiToolbar.cpp.
GuiToolbar.cpp:909: warning: suggest parentheses around && within ||
GuiToolbar.cpp:910: warning: suggest parentheses around && within ||
GuiToolbar.cpp:911: warning: suggest parentheses around && with
Am 07.04.2010 um 13:35 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> I'd like to finish the first attempt of Aspell-integration for Mac - if
>> possible.
>> It's working here already. So it's a doable task.
>
> that would be nice.
>
>> You asked for the build scripts I'm using. These I want to
On 04/07/2010 03:00 PM, Uwe Stöhr wrote:
> Grant a long-standing wish of Lars's: LyX now functions even if we
> have no text classes for some reason (e.g., a corrupt textclass.lst).
> We still give the user a chance to reconfigure (Bo's idea).
Many thanks! Corrupted text classes occur more often
> Grant a long-standing wish of Lars's: LyX now functions even if we
> have no text classes for some reason (e.g., a corrupt textclass.lst).
> We still give the user a chance to reconfigure (Bo's idea).
Many thanks! Corrupted text classes occur more often than one thinks
(like when the Internet
> i was proposing to have it coded _internally_ which means that
nothing > changes from the point of the stdinstes files or gui names.
only the
> functions for reading and writing would need more code to add/strip
> the filename part.
OK.
Can you please give me a hint in what routine I would ha
Am Mittwoch 07 April 2010 schrieb José Matos:
> On Wednesday 07 April 2010 15:23:18 Kornel Benko wrote:
> > Corrected and commited already.
> > Sorry for not being responsive, but I broke my right arm, and it is
> > somehow not easy to use a computer.
> >
> > Kornel
>
> I hope you have a f
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
What about bug #6608 ? Could the patch I suggested be applied ?
trac is down, but if I remember correctly, this was the French/prettyref
issue, right? I think this is too late for 1.6.6, we have to look into that
more deeply first.
N
On Wednesday 07 April 2010 09:42:54 Jean-Marc Lasgouttes wrote:
> Yes, it is very common in free software (at least those who get to these
> big numbers).
>
> JMarc
I would go far and say that this is the rule. :-)
Something like major.minor.bugfix where each mark (major, minor and bugfix) is
a
rgheck writes:
> Actually, this is the kind of thing I was wondering about. But then,
> if the buffer is closed, can't the old lv become invalid? That's the
> other thing I was wondering about.
>
> I can revert if the old devil seems nicer than the new one.
Let's wait and see :)
JMarc
On 04/07/2010 10:23 AM, Kornel Benko wrote:
Sorry for not being responsive, but I broke my right arm, and it is somehow not
easy
to use a computer.
Sorry to hear that!
rh
Jean-Marc Lasgouttes wrote:
> Yes, probably something like that for now.
i'll put it in.
> > +#Wait some time for bumping automake 1.11, which knows this.
> > +lyxdist: dist
> > + bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> > + xz -9 $(PACKAGE)-$(VERSION).tar
> > + ls -hl $(PACKAGE)-$(VERSION).
Am Mittwoch 07 April 2010 schrieb BH:
> On Tue, Apr 6, 2010 at 10:29 PM, rgheck wrote:
> I'm guessing this is some Windows, or possibly cmake, thing. This is a
> macro defined in config.h, and it should be available.
> >>>
> >>> Indeed: SCons compiles while CMake doesn't.
> >>
> >> It's
On 04/07/2010 09:08 AM, Jean-Marc Lasgouttes wrote:
rgh...@lyx.org writes:
Author: rgheck
Date: Wed Apr 7 14:41:19 2010
New Revision: 34072
URL: http://www.lyx.org/trac/changeset/34072
Log:
The lv variable was used back in LyXView.cpp, where we didn't have such
easy access to the current
On 04/07/2010 09:44 AM, Pavel Sanda wrote:
Rob Oakes wrote:
It seems to be choking on some of the XHTML code in Buffer.cpp. I haven't
looked into it, but might a solution be to move the XHTML header code into
a lib file instead of hardcoding into Buffer.cpp?
please send the exact err
Pavel Sanda writes:
> like this. ugly, but wont diturb other people.
> opinions?
Yes, probably something like that for now.
> +#Wait some time for bumping automake 1.11, which knows this.
> +lyxdist: dist
> + bunzip2 $(PACKAGE)-$(VERSION).tar.bz2
> + xz -9 $(PACKAGE)-$(VERSION).tar
> +
Rob Oakes wrote:
> It seems to be choking on some of the XHTML code in Buffer.cpp. I haven't
> looked into it, but might a solution be to move the XHTML header code into
> a lib file instead of hardcoding into Buffer.cpp?
please send the exact error message.
pavel
Hi Pavel,
If it hasn't been addressed already ( I saw an earlier email), the SVN
version of LyX no longer compiles with cmake. I've had issues both on
Mac and Linux.
It seems to be choking on some of the XHTML code in Buffer.cpp. I
haven't looked into it, but might a solution be to move
rgh...@lyx.org writes:
> Author: rgheck
> Date: Wed Apr 7 14:41:19 2010
> New Revision: 34072
> URL: http://www.lyx.org/trac/changeset/34072
>
> Log:
> The lv variable was used back in LyXView.cpp, where we didn't have such
> easy access to the current view. So we don't need it. Moreover, it seem
On Tue, Apr 6, 2010 at 10:29 PM, rgheck wrote:
I'm guessing this is some Windows, or possibly cmake, thing. This is a
macro defined in config.h, and it should be available.
>>>
>>> Indeed: SCons compiles while CMake doesn't.
>>>
>>
>> It's not just Windows -- I have the same problem
Richard Heck wrote:
>> #6519 changes in document settings cannot be saved
>>
>>
> Done.
thanks.
>> #6611 assert on old configuration
>>
>>
> I didn't quite understand this one and asked a question there.
already answered ;)
pavel
On 04/07/2010 06:46 AM, Pavel Sanda wrote:
hi,
i would like to release alpha2 next week.
showstoppers marked as highest priority bugs in trac.
currently:
#6519changes in document settings cannot be saved
Done.
#6611assert on old configuration
I didn't quite understand this
Am 07.04.2010 um 13:31 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> Index: src/AspellChecker.cpp
>> ===
>> --- src/AspellChecker.cpp(Revision 34068)
>> +++ src/AspellChecker.cpp(Arbeitskopie)
>> @@ -18,6 +18,9 @@
>> #include
Stephan Witt wrote:
> I'd like to finish the first attempt of Aspell-integration for Mac - if
> possible.
> It's working here already. So it's a doable task.
that would be nice.
> You asked for the build scripts I'm using. These I want to check in too.
> Since they are new files, may I check the
Stephan Witt wrote:
> Index: src/AspellChecker.cpp
> ===
> --- src/AspellChecker.cpp (Revision 34068)
> +++ src/AspellChecker.cpp (Arbeitskopie)
> @@ -18,6 +18,9 @@
> #include "support/lassert.h"
> #include "support/debug.h"
Am 07.04.2010 um 12:46 schrieb Pavel Sanda:
> hi,
>
> i would like to release alpha2 next week.
> showstoppers marked as highest priority bugs in trac.
>
> currently:
> #6519 changes in document settings cannot be saved
> #6611 assert on old configuration
>
> anybody can take
Pavel Sanda wrote:
> if really wanted we can produce lzma/xz by new hardcoded target in automake
> file.
like this. ugly, but wont diturb other people.
opinions?
pavel
diff --git a/Makefile.am b/Makefile.am
index 50977a2..decdf4c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -25,6 +25,12 @@ EXTR
hi,
i would like to release alpha2 next week.
showstoppers marked as highest priority bugs in trac.
currently:
#6519changes in document settings cannot be saved
#6611assert on old configuration
anybody can take a look?
other bugs you want to see fixed for alpha2?
pavel
Pavel Sanda wrote:
> when i create new file, without touching anything .lyx file
> has entry "\color #008000" as if some special color was
> selected. is this correct (we do not print out default values
> often, moreover its hard to guess which color does it sets...)?
This is the label color of th
Vincent van Ravesteijn wrote:
> I probably can manage to get it back up running. However, it's annoying to
> update things, find workarounds, while I absolutely don't see any advantage
> at all.
ok, i think its better to spend your time on bugs than on hassling with automake
business. i'll bring
Juergen,
when i create new file, without touching anything .lyx file
has entry "\color #008000" as if some special color was
selected. is this correct (we do not print out default values
often, moreover its hard to guess which color does it sets...)?
pavel
On Wed, Apr 07, 2010 at 12:40:27AM +0200, Vincent van Ravesteijn wrote:
> Luckily, in the end, it was possible to
> compile on Windows without the hassle of cygwin/mingw.
He, he... That only demonstrates how opinions can differ.
AFAIC, luckily, it is possible to compile on Windows with
cygwin/min
Jack Desert writes:
> Ah, it seems I downloaded 1.9 thinking it was newer than 1.10. (As a
> decimal number it looks bigger.) Is it conventional for 1.9 to be
> lesser than 1.10? If so, I guess I'll have to get used to it.
Yes, it is very common in free software (at least those who get to these
b
Vincent van Ravesteijn writes:
> Anyway, I'd prefer not to bump the requirements without a necessity or
> clear reason. It only might turn off users/possible developers and so
> forth. As I'm not a Linux guy at all, I really don't care how the
> tarballs are compressed, and if it's only needed for
35 matches
Mail list logo
