In my KOMA book, I set up illustrations as floating objects with text flowing around them. However, I have found that this does not always work well in color boxes and does not work at all in lists: In color boxes, the page break is no longer correct. And wrapped graphics are generally only placed
>From 6f6e2162a34f573316bbd1a3d81a7966c393b94f Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Sat, 24 Dec 2022 12:25:54 +
Subject: [PATCH] Insert entries for Section boxes, Variable-width minipages,
Fix Computer Modern Fonts, LaTeX Kernel fixes, Minimalistic Insets and Title
From 81d11d01d7cac03645fc29cdca34ba762a536fb7 Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Fri, 23 Dec 2022 20:58:43 +
Subject: [PATCH] Insert entries for APA with NatBiB, Fancy Colored Boxes and
Graphic Boxes to Chapter 4: Modules of Additional.lyx
---
lib/doc/Additional.lyx | 582
On Sat, Dec 28, 2019 at 06:37:03AM +0100, Jürgen Spitzmüller wrote:
> Am Freitag, den 27.12.2019, 20:18 -0500 schrieb Scott Kostyshak:
> > Some variation probably makes sense depending on what the "..." are,
> > but
> > I wonder if some consistency would be welcome. On the other hand,
> > perhaps t
Am Freitag, den 27.12.2019, 20:18 -0500 schrieb Scott Kostyshak:
> Some variation probably makes sense depending on what the "..." are,
> but
> I wonder if some consistency would be welcome. On the other hand,
> perhaps too much consistency would make LyX too much like a robot
> instead of the ecce
All of the following are prefixes for at least one tooltip corresponding
to a check box:
- If this is checked, ...
- If checked, ...
- If this is selected, ...
- If unchecked, ...
- Select this if you want ...
- Select if ...
- Select this to ...
- Select for ...
-
Some variation probably makes
Am 18.06.2017 um 17:30 schrieb Scott Kostyshak :
>
> On Sun, Jun 18, 2017 at 04:32:30PM +0200, mn wrote:
>> On 17.06.17 23:05, Scott Kostyshak wrote:
>>> On Sat, Jun 17, 2017 at 04:49:33PM +0200, mn wrote:
>>>>
>>>> With 2.2.3 on mac 10.10 the spellin
On Sun, Jun 18, 2017 at 04:32:30PM +0200, mn wrote:
> On 17.06.17 23:05, Scott Kostyshak wrote:
> > On Sat, Jun 17, 2017 at 04:49:33PM +0200, mn wrote:
> >>
> >> With 2.2.3 on mac 10.10 the spelling panel has now overlapping boxes.
> >> Which makes them very
On 17.06.17 23:05, Scott Kostyshak wrote:
> On Sat, Jun 17, 2017 at 04:49:33PM +0200, mn wrote:
>>
>> With 2.2.3 on mac 10.10 the spelling panel has now overlapping boxes.
>> Which makes them very hard to use.
>> Checking 2.1.3 and alpha1: those do not seem to have th
On Sat, Jun 17, 2017 at 04:49:33PM +0200, mn wrote:
>
> With 2.2.3 on mac 10.10 the spelling panel has now overlapping boxes.
> Which makes them very hard to use.
> Checking 2.1.3 and alpha1: those do not seem to have this problem.
Are the Qt versions the same? (you can see this in
With 2.2.3 on mac 10.10 the spelling panel has now overlapping boxes.
Which makes them very hard to use.
Checking 2.1.3 and alpha1: those do not seem to have this problem.
Suspiciously there does not seem to be anything related to this on trac?
Can anyone confirm that it is indeed a regression
On Fri, Apr 21, 2017 at 01:05:44AM +0200, Uwe Stöhr wrote:
> El 19.04.2017 a las 06:58, Scott Kostyshak escribió:
>
> > > lyx2lyx/lyx_2_2.py: correct reversion of boxes
> >
> > git bisect suggests that this commit broke the test
> >
> >export/doc/
El 19.04.2017 a las 06:58, Scott Kostyshak escribió:
lyx2lyx/lyx_2_2.py: correct reversion of boxes
git bisect suggests that this commit broke the test
export/doc/Math_lyx21
Uwe, can you take a look?
At first I don't understand why I don't get any error or warning when
On Mon, Apr 17, 2017 at 04:06:56AM +0200, Uwe Stöhr wrote:
> commit 5b4cc6b6c84b4d3b35e7122a6ee9160816d2e108
> Author: Uwe Stöhr
> Date: Mon Apr 17 04:06:52 2017 +0200
>
> lyx2lyx/lyx_2_2.py: correct reversion of boxes
git bisect suggests that this commit broke the tes
Le 12/01/2017 à 16:39, Scott Kostyshak a écrit :
I think you also fixed
http://www.lyx.org/trac/ticket/10318
Good, I marked it as such.
I'll keep an eye out for other issues.
Thanks.
JMarc
On Thu, Jan 12, 2017 at 03:19:20PM +0100, Jean-Marc Lasgouttes wrote:
> Le 12/01/2017 à 15:01, Scott Kostyshak a écrit :
> > A recent commit on master (I'm guessing this one), fixed an issue where
> > if I do ctrl+m, ctrl+m, now the blue box looks the same as if I only did
> > one ctrl+m. Before, t
Le 12/01/2017 à 15:01, Scott Kostyshak a écrit :
A recent commit on master (I'm guessing this one), fixed an issue where
if I do ctrl+m, ctrl+m, now the blue box looks the same as if I only did
one ctrl+m. Before, there was a corner (it would alternate between
bottom-left and bottom-right corners
On Thu, Jan 12, 2017 at 12:15:51PM +0100, Jean-Marc Lasgouttes wrote:
> commit cdc847fd304019a19425a0d5d9d42a556a937097
> Author: Jean-Marc Lasgouttes
> Date: Thu Jan 12 12:15:17 2017 +0100
>
> Fix drawing of empty boxes
>
> They were actually bigger than the
On 11/19/2016 11:39 AM, Jean-Marc Lasgouttes wrote:
Le 19/11/2016 à 10:25, Michael Berger a écrit :
Dear all,
I observe that numbering of footnotes in boxes is automatically changing
to 'lettering' - see screen shot. Is this intended behavior or could it
be specific to classicthesis
ing of footnotes in boxes is automatically
changing to 'lettering' - see screen shot. Is this intended
behavior or could it be specific to classicthesis? I am not sure
to like it or not.
Any comment is appreciated.
I am using Lyx 2.2.2, texlive 2016, Miede's clas
Le 19/11/2016 à 10:25, Michael Berger a écrit :
Dear all,
I observe that numbering of footnotes in boxes is automatically changing
to 'lettering' - see screen shot. Is this intended behavior or could it
be specific to classicthesis? I am not sure to like it or not.
Hello Michael,
Dear all,
I observe that numbering of footnotes in boxes is automatically changing
to 'lettering' - see screen shot. Is this intended behavior or could it
be specific to classicthesis? I am not sure to like it or not.
Any comment is appreciated.
I am using Lyx 2.2.2, texlive 201
Am 09.11.2014 um 21:01 schrieb Richard Heck:
Seems fine to me. How does this interact with the other boxes we support?
This will be independent of our box dialog/inset because the graphic
boxes can contain almost everything and these boxes are to modify its
content while the other boxes are
On 11/08/2014 11:09 PM, Uwe Stöhr wrote:
Am 04.11.2014 um 02:25 schrieb Uwe Stöhr:
Dear LyXers,
attached is a module to support the 4 boxes provided by the
LaTeX-package graphicx:
- \scalebox
- \rotatebox
- \reflectbox
- \resizebox
I am now using my module in daily work and it turned out
Am 04.11.2014 um 02:25 schrieb Uwe Stöhr:
Dear LyXers,
attached is a module to support the 4 boxes provided by the
LaTeX-package graphicx:
- \scalebox
- \rotatebox
- \reflectbox
- \resizebox
I am now using my module in daily work and it turned out that it is too
complicated for average users
code for these boxes because they are
widely used in my experiences.
regards Uwe
2014-11-04 10:14 GMT+01:00 Jean-Marc Lasgouttes:
>
> No, the gettext machinery requires latin1. So "percent" should be used
>> here.
>>
>
> Degrees?
>
Yep. Speaks volumes about my own degree ;-)
Jürgen
>
> JMarc
>
>
Le 04/11/2014 10:10, Jürgen Spitzmüller a écrit :
2014-11-04 10:08 GMT+01:00 Jean-Marc Lasgouttes:
A comment: do we allow utf8 characters in strings?
Tooltip "Rotation angle in ° (counterclockwise)"
No, the gettext machinery requires latin1. So "percent" should be used
2014-11-04 10:08 GMT+01:00 Jean-Marc Lasgouttes:
> A comment: do we allow utf8 characters in strings?
> Tooltip "Rotation angle in ° (counterclockwise)"
>
No, the gettext machinery requires latin1. So "percent" should be used here.
Jürgen
>
> JMarc
>
>
Le 04/11/2014 10:05, Jürgen Spitzmüller a écrit :
Looks good. One thing: Do we have graphicx in LateXFeatures? If not, we
can also require graphics.
A comment: do we allow utf8 characters in strings?
Tooltip "Rotation angle in ° (counterclockwise)"
JMarc
2014-11-04 2:25 GMT+01:00 Uwe Stöhr:
> Dear LyXers,
>
> attached is a module to support the 4 boxes provided by the LaTeX-package
> graphicx:
> - \scalebox
> - \rotatebox
> - \reflectbox
> - \resizebox
>
> A description of these 4 boxes is already in the Embe
Dear LyXers,
attached is a module to support the 4 boxes provided by the
LaTeX-package graphicx:
- \scalebox
- \rotatebox
- \reflectbox
- \resizebox
A description of these 4 boxes is already in the EmbeddedObjects manual,
sec. 5.8.
The module would save a lot of TeX code and I would
On Sun, Dec 1, 2013 at 12:03 AM, Tommaso Cucinotta wrote:
> On 27/11/13 19:25, Scott Kostyshak wrote:
findadv-re-05-in.txt: FAILED
findadv-re-06-in.txt: Ok
>> Tommaso, is this test failure a regression or a bug in the test? Is it
>> on your ra
On 27/11/13 19:25, Scott Kostyshak wrote:
>>> findadv-re-05-in.txt: FAILED
>>> findadv-re-06-in.txt: Ok
>>>
> Tommaso, is this test failure a regression or a bug in the test? Is it
> on your radar to fix? Should the test be removed?
AFAICR, it a case working
On Thu, Nov 14, 2013 at 12:33 PM, Scott Kostyshak wrote:
> On Tue, Nov 12, 2013 at 9:33 PM, Tommaso Cucinotta wrote:
>> On 13/11/13 02:10, Tommaso Cucinotta wrote:
>>> On 12/11/13 22:26, Scott Kostyshak wrote:
On Sun, Oct 27, 2013 at 5:59 AM, Tommaso Cucinotta wrote:
> On 27/10/13 08:17
On Tue, Nov 12, 2013 at 9:33 PM, Tommaso Cucinotta wrote:
> On 13/11/13 02:10, Tommaso Cucinotta wrote:
>> On 12/11/13 22:26, Scott Kostyshak wrote:
>>> On Sun, Oct 27, 2013 at 5:59 AM, Tommaso Cucinotta wrote:
On 27/10/13 08:17, Scott Kostyshak wrote:
>
> Tommaso,
>
> I also
On 13/11/13 02:10, Tommaso Cucinotta wrote:
> On 12/11/13 22:26, Scott Kostyshak wrote:
>> On Sun, Oct 27, 2013 at 5:59 AM, Tommaso Cucinotta wrote:
>>> On 27/10/13 08:17, Scott Kostyshak wrote:
Tommaso,
I also have findadv-re-05 failing. Does it fail for you?
>>>
>>>
>>> Just
On 12/11/13 22:26, Scott Kostyshak wrote:
> On Sun, Oct 27, 2013 at 5:59 AM, Tommaso Cucinotta wrote:
>> On 27/10/13 08:17, Scott Kostyshak wrote:
>>>
>>> Tommaso,
>>>
>>> I also have findadv-re-05 failing. Does it fail for you?
>>
>>
>> Just upgraded to 13.10, let's see if I can still compile :-)
On Sun, Oct 27, 2013 at 5:59 AM, Tommaso Cucinotta wrote:
> On 27/10/13 08:17, Scott Kostyshak wrote:
>>
>> Tommaso,
>>
>> I also have findadv-re-05 failing. Does it fail for you?
>
>
> Just upgraded to 13.10, let's see if I can still compile :-)...
Just a reminder :)
Scott
On 27/10/13 08:17, Scott Kostyshak wrote:
Tommaso,
I also have findadv-re-05 failing. Does it fail for you?
Just upgraded to 13.10, let's see if I can still compile :-)...
T.
gt;
>
>> Now the regexp insets entered in Advanced F&R search/replace boxes do
>> not preview anymore independently, unless embedded/nested within other math
>> elements.
>
>> Fixing crash as described in #7805.
>
>>
>
>
>
> Thanks T
Am Samstag, 24. August 2013 um 14:08:00, schrieb Tommaso Cucinotta
> commit 203dab97c36308b74ec43f3706ade4fc23f5c35b
> Author: Tommaso Cucinotta
> Date: Sat Aug 24 13:06:05 2013 +0100
>
> Now the regexp insets entered in Advanced F&R search/replace boxes do not
On Thu, Apr 25, 2013 at 4:38 PM, Vincent van Ravesteijn wrote:
> Op 19-3-2013 8:43, Scott Kostyshak schreef:
>
>> Make a table and go to the tabular settings. Toggle multicolumn or
>> multirow and you'll see the combo boxes and the text box changing
>> width because
Op 19-3-2013 8:43, Scott Kostyshak schreef:
Make a table and go to the tabular settings. Toggle multicolumn or
multirow and you'll see the combo boxes and the text box changing
width because "At Decimal Separator" is no longer an option. This did
not happen before. I think
Make a table and go to the tabular settings. Toggle multicolumn or
multirow and you'll see the combo boxes and the text box changing
width because "At Decimal Separator" is no longer an option. This did
not happen before. I think commit 6f157533 triggered this.
I could not fi
Uwe Stöhr wrote:
> is it possible to implement the same for the font color of the main text and
> of the font inside greyed-out notes.
Probably. But alas, my TODO list is already too long.
Jürgen
Liviu Andronic wrote:
> > is it possible to implement the same for the font color of the main text
> > and of the font inside greyed-out notes.
>
> For reference:
> http://www.lyx.org/trac/ticket/6682#comment:2
I don't think this comment applies as long as only UI colors (not output
colors) are
On Fri, Nov 30, 2012 at 8:45 PM, Uwe Stöhr wrote:
> is it possible to implement the same for the font color of the main text and
> of the font inside greyed-out notes.
>
For reference:
http://www.lyx.org/trac/ticket/6682#comment:2
Liviu
Hi Jürgen,
many thanks for this feature! I tried to implemented this several times but
failed.
is it possible to implement the same for the font color of the main text and of the font inside
greyed-out notes.
best regards
Uwe
From: Richard Heck [rgh...@lyx.org]
Sent: Thursday, July 05, 2012 9:17 AM
>Since we do use eatLine(), we don't need them as delimiters. So it would be an
>option just not to write them.
Ticket created here:
http://www.lyx.org/trac/ticket/8237
On a different note, and more out of curiosity, woul
On 07/04/2012 01:42 AM, Scott Kostyshak wrote:
In tools > Preferences > File Handling > File Formats
my first entry is BMP. Despite the fact that "gimp" is in the viewerCO
combo box, it is set to Custom and "gimp" is in the text box. What
should happen is that "gimp" should be set in the combo
In tools > Preferences > File Handling > File Formats
my first entry is BMP. Despite the fact that "gimp" is in the viewerCO combo
box, it is set to Custom and "gimp" is in the text box. What should happen is
that "gimp" should be set in the combo box. (Note that gimp is just being used
as an ex
Georg Baum wrote:
> Can you rerun valgrind with
>
> --track-origins=yes
>
> ? That should give us a hint where the initialization is missing in your
> case.
I uploaded it here:
http://www.lyx.org/trac/attachment/ticket/7371/valgrind2.log.bz2
Jürgen
Jürgen Spitzmüller wrote:
> Georg Baum wrote:
>
>> The attached patch
>> is a shot in the dark.
>
> Unfortunately, it does not help.
I suspected that, but there was a tiny chance...
>> I also notice a lot of uninitialised value warnings for
>> QTransform::fromTranslate() in your valgrind log.
Am 19.03.2011 um 14:18 schrieb Jürgen Spitzmüller:
> Richard Heck wrote:
FWIW that is also the version I have used in my tests.
>>>
>>> It might explain why this bug shows up only now (also in branch).
>>
>> FWIW, I'm using 4.7.1, and can't reproduce.
>
> Do you have the possibility to che
Richard Heck wrote:
> >> FWIW that is also the version I have used in my tests.
> >
> > It might explain why this bug shows up only now (also in branch).
>
> FWIW, I'm using 4.7.1, and can't reproduce.
Do you have the possibility to check with 4.7.2 as well?
Jürgen
On 03/19/2011 05:33 AM, Jürgen Spitzmüller wrote:
José Matos wrote:
Qt 4.7.2.
Jürgen
FWIW that is also the version I have used in my tests.
It might explain why this bug shows up only now (also in branch).
FWIW, I'm using 4.7.1, and can't reproduce.
rh
Jürgen Spitzmüller wrote:
> No, that's a safe way for me to get it (if I run an installed binary, that
> is).
>
> I also get it if I insert an note inset and change a color in preferences (so
> it's no genuine problem of the document dialog).
maybe another dataloss problem in dialog (#7349) is
Am 19.03.2011 um 10:33 schrieb Jürgen Spitzmüller:
> José Matos wrote:
>>> Qt 4.7.2.
>>>
>>>
>>>
>>> Jürgen
>>
>> FWIW that is also the version I have used in my tests.
>
> It might explain why this bug shows up only now (also in branch).
This and the fact it has the potential to crash your
José Matos wrote:
> > Qt 4.7.2.
> >
> >
> >
> > Jürgen
>
> FWIW that is also the version I have used in my tests.
It might explain why this bug shows up only now (also in branch).
Jürgen
On Saturday 19 March 2011 07:49:18 Jürgen Spitzmüller wrote:
> Qt 4.7.2.
>
> Jürgen
FWIW that is also the version I have used in my tests.
--
José Abílio
Georg Baum wrote:
> No. I was unable to reproduce the problem (as Pavel, with the same qt
> version 4.6.3). The strange thing is that the background colors are only
> used for LaTeX output, so changing them should not influence any GUI color
> (actually it should, but it is not implemented. Uwe
Richard Heck wrote:
> I still can't reproduce it here, unfortunately, or I'd try to help. I
> set the French locale, created a document with a shaded box, changed the
> color of the box, and applied, but nothing bad happened. Any other advice?
No, that's a safe way for me to get it (if I run an
Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
>> It's the box inset's background color. If I remove the BgColor
>> specification from the shaded box definition, the error disappears
>
> It is a general problem with background colors or the color cache. I get
> the same problem when chang
On 03/18/2011 06:44 AM, Jürgen Spitzmüller wrote:
Vincent van Ravesteijn wrote:
Can you step through the code in debug mode and find out when hell
breaks loose ?
I tried. It's really difficult to find out. It must be either somewhere in
applyView() or classChanged(). The first debug message I g
Jürgen Spitzmüller wrote:
> I try to run with valgrind as well, maybe I get something more interesting.
I ran valgrind again. The log file is here:
http://www.lyx.org/trac/attachment/ticket/7371/valgrind.log.bz2
Jürgen
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Maybe we have an invalid color cache and/or color while redrawing the
> > screen? Does this ring a bell to someone?
>
> is it regression so we can bisect?
Actually, no. I can reproduce it in branch as well (changing the shaded
background prefs
Jürgen Spitzmüller wrote:
> Maybe we have an invalid color cache and/or color while redrawing the screen?
> Does this ring a bell to someone?
is it regression so we can bisect?
i have seen bformat in backtrace - shot in the dark - if you
remerge all strings, does it make any difference?
pavel
Jürgen Spitzmüller wrote:
> It's the box inset's background color. If I remove the BgColor
> specification from the shaded box definition, the error disappears
It is a general problem with background colors or the color cache. I get the
same problem when changing any color in document or prefs w
Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > Can you step through the code in debug mode and find out when hell
> > breaks loose ?
>
> I tried. It's really difficult to find out. It must be either somewhere in
> applyView() or classChanged(). The first debug message I get after th
Vincent van Ravesteijn wrote:
> Can you step through the code in debug mode and find out when hell
> breaks loose ?
I tried. It's really difficult to find out. It must be either somewhere in
applyView() or classChanged(). The first debug message I get after the weird
characters are output for t
Op 18-3-2011 11:32, Jürgen Spitzmüller schreef:
Jürgen Spitzmüller wrote:
I try to run with valgrind as well, maybe I get something more interesting.
Nothing that seems relevant. I tried some debugging, but found nothing so far.
Any ideas where I should look at?
Jürgen
Can you step through
Jürgen Spitzmüller wrote:
> I try to run with valgrind as well, maybe I get something more interesting.
Nothing that seems relevant. I tried some debugging, but found nothing so far.
Any ideas where I should look at?
Jürgen
Richard Heck wrote:
> It looks like there is a boolean there that hasn't been initialized. I
> suppose that could be causing us to read something bad. I've committed a
> repair at r37945.
Alas, this doesn't fix the problem.
Meanwhile I also noted that I can trigger the problem when changing a
On 03/17/2011 06:54 PM, Jean-Marc Lasgouttes wrote:
Le 17/03/11 19:57, José Matos a écrit :
I sent Jean-Marc the file 4 MB uncompressed and 180 KB compressed. If
anyone
else wants the valgrind report I can send it.
The problem may be related to the reportss below (the asserts begin
just afte
Le 17/03/11 19:57, José Matos a écrit :
I sent Jean-Marc the file 4 MB uncompressed and 180 KB compressed. If anyone
else wants the valgrind report I can send it.
The problem may be related to the reportss below (the asserts begin just
after them). I do not know what they mean, though.
This
On Thursday 17 March 2011 16:24:55 Jean-Marc Lasgouttes wrote:
> Le 17/03/2011 16:30, José Matos a écrit :
> > The message that should be there (at least compared with the case where
> > the language is English) is
> > "Converting document to new document documents class"
> >
> > But as I have tol
Le 17/03/2011 16:30, José Matos a écrit :
The message that should be there (at least compared with the case where the
language is English) is
"Converting document to new document documents class"
But as I have told before something is wrong here since it takes up to 5
seconds to apply the change
On Thursday 17 March 2011 15:16:10 Vincent van Ravesteijn wrote:
> Do you also see a connection with the shaded box. Any idea, what text
> should have been in the status bar at that moment ?
>
> Vincent
If you change first the document settings and only later insert the shaded box
then no probl
Op 17-3-2011 16:12, José Matos schreef:
On Wednesday 16 March 2011 17:24:52 Jürgen Spitzmüller wrote:
... and only if I run an installed LyX. If I run the lyx binary from the
build tree, the error neither triggers.
Jürgen
Here i happens if I start from the build directory, and just as you not
Am 16.03.2011 18:19, schrieb Jürgen Spitzmüller:
It seems the error only occurs if I use a localization other than
English. With LANG=en_EN, the error does not trigger, but I get it both
with LANG=de_DE and LANG=fr_FR.
... and only if I run an installed LyX. If I run the lyx binary from the
b
Am 16.03.2011 18:00, schrieb Jürgen Spitzmüller:
It looks like the message strings and/or the file name gets corrupted.
Look at the file name in the window title of the attached screen shot.
It seems the error only occurs if I use a localization other than
English. With LANG=en_EN, the error d
On Wednesday 16 March 2011 16:55:08 Richard Heck wrote:
> Nor here (Fedora 13).
>
> rh
Nor here, tested both on Fedora 14 and Fedora 15 (to be).
With that said there is something wrong going on since it says after pressing
OK that it says "Converting document to new document documents class" in
Am 16.03.2011 16:41, schrieb Stephan Witt:
Sorry, I cannot reproduce it on Mac with SVN.
It looks like the message strings and/or the file name gets corrupted.
Look at the file name in the window title of the attached screen shot.
Eventually LyX asserts with
lassert.cpp(21): ASSERTION conta
On 03/16/2011 11:41 AM, Stephan Witt wrote:
Am 16.03.2011 um 15:10 schrieb Jürgen Spitzmüller:
I cannot (yet) nail down this, and it's not always reproducible (actually, I
fail to reproduce it ATM), but I report it nevertheless since it strikes me to
be a severe problem (a release blocker):
Am 16.03.2011 um 15:10 schrieb Jürgen Spitzmüller:
> I cannot (yet) nail down this, and it's not always reproducible (actually, I
> fail to reproduce it ATM), but I report it nevertheless since it strikes me
> to be a severe problem (a release blocker):
>
> * insert a shaded box
> * go to docum
I cannot (yet) nail down this, and it's not always reproducible
(actually, I fail to reproduce it ATM), but I report it nevertheless
since it strikes me to be a severe problem (a release blocker):
* insert a shaded box
* go to document settings and change the shade color (I set it to grey,
#DD
>> > This small patch fixes the following bug:
>> > LyX allows to create \frameboxes with multiple paragraph if there is no
>> > inner box. But this is only possible for shaded boxes.
>>
>> Attached is a better patch that additionally fixes this issue:
>&
Uwe Stöhr wrote:
> > This small patch fixes the following bug:
> > LyX allows to create \frameboxes with multiple paragraph if there is no
> > inner box. But this is only possible for shaded boxes.
>
> Attached is a better patch that additionally fixes this issue:
> I
Am 08.07.2010 04:46, schrieb Uwe Stöhr:
This small patch fixes the following bug:
LyX allows to create \frameboxes with multiple paragraph if there is no
inner box. But this is only possible for shaded boxes.
Attached is a better patch that additionally fixes this issue:
If you have a shaded
This small patch fixes the following bug:
LyX allows to create \frameboxes with multiple paragraph if there is no inner box. But this is only
possible for shaded boxes.
OK?
regards Uwe
Index: InsetBox.cpp
===
--- InsetBox.cpp
Uwe Stöhr wrote:
> > 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 hin
> 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
> 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
Uwe Stöhr wrote:
> This doesn't work because in stdinsets we define the color for e.g. the
> greyed-out box as "gereyedouttext". If we would use another color name for
> every buffer the inset won't find the color.
i was proposing to have it coded _internally_ which means that nothing changes
fr
> use something like colorname_identificator_path_filename as color
> indetificator internally inside gui?
This doesn't work because in stdinsets we define the color for e.g. the
greyed-out box as "gereyedouttext". If we would use another color name
for every buffer the inset won't find the col
Uwe Stöhr wrote:
> The problem is that LyX does not store the colors buffer-dependent. If you
> have 2 documents opened and switch between them, the colors need to be
> updated. (Another manifestation of this bug is
> http://www.lyx.org/trac/ticket/6626).
>
> Does anybody have an idea how to fix
Am 03.04.2010 03:42, schrieb Uwe Stöhr:
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
Document->Settings->Colors, but the color
The attached patch introduces the feature to change the color for shaded boxes
(fixes http://www.lyx.org/trac/ticket/3863)
(I plan that this would be my last new feature for LyX 2.0.)
The patch is well tested and works as expected, except of one Ui-issue:
When loading a file with a shaded box
The problem is that GuiBox::setSpecial doesn't refill the width unit combo box
correctly (i.e., the data part of it).
In trunk, the bug was fixed due to a more extensive rewrite of the LengthCombo
handling (r28152).
I apply to branch if there are no objections.
Jürgen
Index: src/frontends/qt4/
1 - 100 of 309 matches
Mail list logo
