> Van: lyx-devel mailto:lyx-devel-boun...@lists.lyx.org Namens Stef Pillaert
> Verzonden: donderdag 13 februari 2025 11:42
...
> See this screenshot, I use LyX in Dutch
> • I think it should be "Kaderinstellingen" (so without the "e" after "ll")
> • I see "regelbreedte" twice? Probably the second o
Am Donnerstag, dem 13.02.2025 um 10:42 + schrieb Stef Pillaert:
>
> Hello
> See this screenshot, I use LyX in Dutch
> *
> I think it should be "Kaderinstellingen" (so without the "e" after
> "ll")
> *
> I see "regelbreedte" twice? Probably the second one should be
> something else? (
Hello
See this screenshot, I use LyX in Dutch
*
I think it should be "Kaderinstellingen" (so without the "e" after "ll")
*
I see "regelbreedte" twice? Probably the second one should be something else?
(I think "regelbreeedte" is "linewidth" in English, but not sure: I'm not a
"LaTeX"-person
Yes. Changing the theme fixes the problem. It seems that the "windows11"
theme is the only one with this issue.
On Mon, Jul 8, 2024 at 4:49 PM LyX Ticket Tracker wrote:
> #13082: Tools | Preferences | Look & Feel | Display graphics | Preview
> size box
>
Le 25/02/2024 à 11:25, Andreas Plihal a écrit :
Hi,
I am working with LYX 2.3.7 (January 1, 2023) on Windows 11 Home,
version 23H2.
Since I don't see too well, I increased the general text size in the
Windows settings. However, this had an unexpected impact on LyX:
The Environment choic
n unexpected impact on LyX:
>
> The Environment choice box, which is located on the left end of the
> toolbar, reduces its font size! See my two attached pictures.
>
> I haven't found a way to compensate for this phenomenon within LyX.
> Please, can you fix this bug?
>
>F
On Sat, 2023-09-30 at 13:08 +0200, Jürgen Spitzmüller wrote:
> Not my doing, but I fixed it.
I know, thank you. :-)
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Samstag, dem 30.09.2023 um 11:34 +0100 schrieb José Matos:
> FWIW the code works because there is no \h escape sequence but, in
> any case, it is better to fix this.
Not my doing, but I fixed it.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinf
On Sat, 2023-09-30 at 08:38 +0200, Juergen Spitzmueller wrote:
>
> Introduce default box frame color (#12921)
>
> This better aligns with dark mode
Hi Jürgen,
what I am about to report is unrelated to this file format change. I
have just noticed it because of it.
Wh
Am 07.12.2022 um 14:36 schrieb Pavel Sanda :
>
> On Tue, Dec 06, 2022 at 11:12:37PM +0100, Stephan Witt wrote:
>> commit a66ee4109ee84a4a501dbaa29580cdefe1aadd36
>> Author: Stephan Witt
>> Date: Wed Dec 7 00:08:11 2022 +0100
>>
>>Add OS version info t
On Tue, Dec 06, 2022 at 11:12:37PM +0100, Stephan Witt wrote:
> commit a66ee4109ee84a4a501dbaa29580cdefe1aadd36
> Author: Stephan Witt
> Date: Wed Dec 7 00:08:11 2022 +0100
>
> Add OS version info to About box.
> ---
> src/frontends/qt/GuiAbout.cpp |6 ++
On Wed, Nov 23, 2022 at 03:20:59PM -0500, Richard Kimberly Heck wrote:
> On 11/23/22 12:57, Scott Kostyshak wrote:
> > In my Beamer document, if I want to insert a Block layout, I type
> > Alt + p, space, and then type "Block". This gives three results:
> > "Block", "ExampleBlock", and "AlertBlock"
On 11/23/22 12:57, Scott Kostyshak wrote:
In my Beamer document, if I want to insert a Block layout, I type
Alt + p, space, and then type "Block". This gives three results:
"Block", "ExampleBlock", and "AlertBlock". "AlertBlock" is highlighted,
so I press to get to "Block".
Is there a faster w
In my Beamer document, if I want to insert a Block layout, I type
Alt + p, space, and then type "Block". This gives three results:
"Block", "ExampleBlock", and "AlertBlock". "AlertBlock" is highlighted,
so I press to get to "Block".
Is there a faster way by default than the above key combination
On Sat, Apr 09, 2022 at 10:33:01AM +0200, Jürgen Spitzmüller wrote:
> Am Freitag, dem 08.04.2022 um 10:30 -0400 schrieb Scott Kostyshak:
> > For lyx2lyx backwards conversion, I suppose there are 2 options:
> >
> > 1. Try to figure out the default color from the .lyx file and set the
> > color e
Am Freitag, dem 08.04.2022 um 10:30 -0400 schrieb Scott Kostyshak:
> For lyx2lyx backwards conversion, I suppose there are 2 options:
>
> 1. Try to figure out the default color from the .lyx file and set the
> color explicitly.
Not an option IMHO. Since this color is dynamic, it could be chang
On Fri, Apr 08, 2022 at 07:00:29AM +0200, Jürgen Spitzmüller wrote:
> Am Donnerstag, dem 07.04.2022 um 22:31 -0400 schrieb Scott Kostyshak:
> > Indeed using tcolorbox might suit my needs better. I might look into
> > using that. In any case, I worked on a patch for fcolorbox.
>
> You are aware tha
Am Donnerstag, dem 07.04.2022 um 22:31 -0400 schrieb Scott Kostyshak:
> Indeed using tcolorbox might suit my needs better. I might look into
> using that. In any case, I worked on a patch for fcolorbox.
You are aware that this is a file format change?
Jürgen
signature.asc
Description: This is
On Wed, Apr 06, 2022 at 10:15:21AM +0200, Jean-Marc Lasgouttes wrote:
> Le 06/04/2022 à 08:23, Daniel a écrit :
> > On 2022-04-02 17:10, Scott Kostyshak wrote:
> > > If I go to Insert > Box, for the color, I see "Black" for the frame. In
> > > LaTeX, if
Le 06/04/2022 à 08:23, Daniel a écrit :
On 2022-04-02 17:10, Scott Kostyshak wrote:
If I go to Insert > Box, for the color, I see "Black" for the frame. In
LaTeX, if we use ".", then that uses the "current"/"inherited" (I'm not
sure of the correct
On 2022-04-02 17:10, Scott Kostyshak wrote:
If I go to Insert > Box, for the color, I see "Black" for the frame. In
LaTeX, if we use ".", then that uses the "current"/"inherited" (I'm not
sure of the correct terminology) color, but that doesn'
On Sat, Apr 02, 2022 at 11:10:51AM -0400, Scott Kostyshak wrote:
> If I go to Insert > Box, for the color, I see "Black" for the frame. In
> LaTeX, if we use ".", then that uses the "current"/"inherited" (I'm not
> sure of the correct termi
If I go to Insert > Box, for the color, I see "Black" for the frame. In
LaTeX, if we use ".", then that uses the "current"/"inherited" (I'm not
sure of the correct terminology) color, but that doesn't seem to be an
option in the combo box. Is th
On 7/04/2020 7:38 pm, Jürgen Spitzmüller wrote:
Am Dienstag, den 07.04.2020, 08:48 +0200 schrieb Daniel:
On 2020-04-06 23:32, Andrew Parsloe wrote:
When I put a verbatim environment inside a Box (Minipage, simple
frame)
I get a Latex error:
Argument of \@xverbatim has an extra }
which then
Am Dienstag, den 07.04.2020, 08:48 +0200 schrieb Daniel:
> On 2020-04-06 23:32, Andrew Parsloe wrote:
> > When I put a verbatim environment inside a Box (Minipage, simple
> > frame)
> > I get a Latex error:
> >
> > Argument of \@xverbatim has an extra }
> >
On 2020-04-06 23:32, Andrew Parsloe wrote:
When I put a verbatim environment inside a Box (Minipage, simple frame)
I get a Latex error:
Argument of \@xverbatim has an extra }
which then produces various later errors, and the document doesn't
compile. The other options, including double
When I put a verbatim environment inside a Box (Minipage, simple frame)
I get a Latex error:
Argument of \@xverbatim has an extra }
which then produces various later errors, and the document doesn't
compile. The other options, including double frame, work fine. This is
with both 2.
in a
>> pop-up menu, regardless of how long the file path is. At the same time, in
>> an attempt to display the long pop-up menu item, the width of the dialog box
>> is adjusted, apparently without limit. The width can easily exceed the width
>> of the screen. The user ca
>> The dialog for Cross References attempts to display the entire path
>> to the file in a pop-up menu, regardless of how long the file path
>> is. At the same time, in an attempt to display the long pop-up menu
>> item, the width of the dialog box is adjusted, apparently w
me, in an
> attempt to display the long pop-up menu item, the width of the dialog box is
> adjusted, apparently without limit. The width can easily exceed the width of
> the screen. The user can, with patience, drag the dialog box so that the
> right edge is visible and can thus click on
the file path
> is. At the same time, in an attempt to display the long pop-up menu
> item, the width of the dialog box is adjusted, apparently without
> limit. The width can easily exceed the width of the screen. The user
> can, with patience, drag the dialog box so that the right edge
dialog box is
adjusted, apparently without limit. The width can easily exceed the width of
the screen. The user can, with patience, drag the dialog box so that the right
edge is visible and can thus click on OK or Cancel or Apply, but attempts to
drag the right side of the box to the left and thus
El 24.04.2017 a las 17:31, Richard Heck escribió:
OK.
It is in.
regards Uwe
OK.
On 04/20/2017 07:11 PM, Uwe Stöhr wrote:
> El 17.04.2017 a las 05:30, Uwe Stöhr escribió:
>
>> the attached patch fixes several box reversion issues in lyx2lyx.
>> Scott could verify that the conversion to LyX 2.1.x works now as
>> expected.
>
> Hi Richard,
&g
El 17.04.2017 a las 05:30, Uwe Stöhr escribió:
the attached patch fixes several box reversion issues in lyx2lyx. Scott
could verify that the conversion to LyX 2.1.x works now as expected.
Hi Richard,
this patch fixed some issues but Math.lyx uncovered an issue that I
introduced with this
El 17.04.2017 a las 21:57, Richard Heck escribió:
I will look these over and commit them if they're acceptable.
Attached are the obvious "\\" fixes that should be backported.
regards
Uwe
diff --git
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\lyx_2_0-0271602.002.py"
"b/D:\\LyXGit\
On Mon, Apr 17, 2017 at 05:30:19AM +0200, Uwe Stöhr wrote:
> Hi Richard,
>
> the attached patch fixes several box reversion issues in lyx2lyx. Scott
> could verify that the conversion to LyX 2.1.x works now as expected.
Just to be clear: when I report results of ctests, it is
El 17.04.2017 a las 21:57, Richard Heck escribió:
OK.
it is in.
I will look these over and commit them if they're acceptable.
thanks.
regards Uwe
On 04/17/2017 03:30 PM, Uwe Stöhr wrote:
> El 17.04.2017 a las 17:22, Richard Heck escribió:
>
>> OK.
>
> It is in.
>
> Attached is another fix fixing the box reversion from 2.0 to 1.6.
> Kornel verified that it works for him too OK to go in?
OK.
>> You can us
El 17.04.2017 a las 17:22, Richard Heck escribió:
OK.
It is in.
Attached is another fix fixing the box reversion from 2.0 to 1.6. Kornel
verified that it works for him too OK to go in?
You can use git blame to identify where the changes come from. Then we
can look at the individual
On 04/16/2017 11:30 PM, Uwe Stöhr wrote:
> Hi Richard,
>
> the attached patch fixes several box reversion issues in lyx2lyx.
> Scott could verify that the conversion to LyX 2.1.x works now as
> expected. Could this therefore also go in for LyX 2.2.3?
OK.
> Another issue: when
Hi Richard,
the attached patch fixes several box reversion issues in lyx2lyx. Scott
could verify that the conversion to LyX 2.1.x works now as expected.
Could this therefore also go in for LyX 2.2.3?
--
Another issue: when I compare lyx-2_2.py in master with branch I see a
lot of
Le 25/10/2016 à 10:37, Stephan Witt a écrit :
One question not related to drawing issues: I’ve noticed the Arrow-Left
key moves to the left (forward in text). But, Fn-Arrow-Left (Home) moves
to the right. Of course „Home“ is the begin of the line but this is not
obvious to me. I’m not sure if the
Am 25.10.2016 um 00:35 schrieb LyX Ticket Tracker :
>
> #10436: RTL characters protrude over inset box
> ---+
> Reporter: uwestoehr | Owner: skostysh
> Type: defect | Status: fixedinma
Le 06/08/2016 à 10:31, Abdelrazak Younes a écrit :
Hi Guillaume,
Just my 2 cents about those recent commits:
1) Switching to C++11 thread is a good thing
2) All these #if (gcc 4.6) are uglyfying the code considerably, you
should enter C++11 with 2 steps or just leave it.
Thanks,
Abdel
Hi A
,
By touching upon the problem of static variables and threading in LyX
(see my patch at <http://mid.gmane.org/nltsru$pag$1...@ger.gmane.org>), I
have the impression that I opened Pandora's box.
I just committed a series of patches that fixes "FIXME thread" in cases
where c++11 g
On 08/01/2016 06:50 PM, Guillaume Munch wrote:
> Le 31/07/2016 à 19:52, Richard Heck a écrit :
>>> +++ b/src/frontends/qt4/GuiCitation.cpp
>>
>> Is there some way we could store these per BufferView or something? I'd
>> kind of like to save the last searched string for each document,
>> rather than
On 08/01/2016 04:01 PM, Guillaume Munch wrote:
> Le 31/07/2016 à 19:52, Richard Heck a écrit :
>> On 07/31/2016 01:38 PM, Guillaume Munch wrote:
>>
>>> For other "FIXME thread" issues, either the solution is more
>>> complex, or
>>> using statics is inappropriate altogether (I think). Is there a pl
Le 31/07/2016 à 19:52, Richard Heck a écrit :
+++ b/src/frontends/qt4/GuiCitation.cpp
Is there some way we could store these per BufferView or something? I'd
kind of
like to save the last searched string for each document, rather than
globally.
Yes, I think there must be a better solution.
Le 31/07/2016 à 19:52, Richard Heck a écrit :
On 07/31/2016 01:38 PM, Guillaume Munch wrote:
For other "FIXME thread" issues, either the solution is more complex, or
using statics is inappropriate altogether (I think). Is there a plan to
get rid of these?
It looks to me as if most of the ones
Patch comments.
> From 7fd53bc44bd278fd1f30400c030e350f2c0a6aa3 Mon Sep 17 00:00:00 2001
> From: Guillaume Munch
> Date: Sun, 31 Jul 2016 00:42:51 +0100
> Subject: [PATCH] Replace static with thread_local when used for caching
>
> thread_local is a per-thread static variable, so it is thread-saf
On 07/31/2016 01:38 PM, Guillaume Munch wrote:
> Hi list,
>
> By touching upon the problem of static variables and threading in LyX
> (see my patch at <http://mid.gmane.org/nltsru$pag$1...@ger.gmane.org>), I
> have the impression that I opened Pandora's box.
I think the
Hi list,
By touching upon the problem of static variables and threading in LyX
(see my patch at <http://mid.gmane.org/nltsru$pag$1...@ger.gmane.org>), I
have the impression that I opened Pandora's box.
I just committed a series of patches that fixes "FIXME thread" in cases
On 06/26/2016 07:33 AM, Jean-Marc Lasgouttes wrote:
Le 25/06/2016 23:41, Richard Heck a écrit :
But then it doesn't work with non-LyX-provided insets, i.e., ones you
make yourself. If you had a lot of such insets, this would get very
messy, too.
I'd be happy if it were done as an icon-based men
Le 25/06/2016 23:41, Richard Heck a écrit :
But then it doesn't work with non-LyX-provided insets, i.e., ones you
make yourself. If you had a lot of such insets, this would get very
messy, too.
I'd be happy if it were done as an icon-based menu. As I've said, I just
don't know how to do that.
On Sat, Jun 25, 2016 at 8:05 PM, Richard Heck wrote:
> On 06/25/2016 12:23 PM, Liviu Andronic wrote:
>> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
>>> I've fixed both these issues with the attached.
>>>
>> I have trouble applying this patch. I've tried everything from patch
>> -p1 < fil
On Sat, Jun 25, 2016 at 11:41 PM, Richard Heck wrote:
> On 06/25/2016 04:55 PM, Jean-Marc Lasgouttes wrote:
>> Le 25/06/2016 22:37, Guillaume Munch a écrit :
>>> Le 25/06/2016 19:15, Richard Heck a écrit :
For now, the branch is here:
http://git.lyx.org/?p=developers/rgheck/lyx.git;
On Sat, Jun 25, 2016 at 7:30 PM, Pavel Sanda wrote:
> Liviu Andronic wrote:
>> The next patch would create the file src/frontends/qt4/InsetCombo.cpp,
>> which already exists! Assume -R? [n]
>> Apply anyway? [n]
>
> Delete new files (InsetCombo*). P
That was it, thanks.
Liviu
On 06/25/2016 04:55 PM, Jean-Marc Lasgouttes wrote:
> Le 25/06/2016 22:37, Guillaume Munch a écrit :
>> Le 25/06/2016 19:15, Richard Heck a écrit :
>>>
>>> For now, the branch is here:
>>> http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets
>>>
>>>
>>>
>>
>
Le 25/06/2016 22:37, Guillaume Munch a écrit :
Le 25/06/2016 19:15, Richard Heck a écrit :
For now, the branch is here:
http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets
If you are satisfied with it then you could commit it, I think.
What is your
Le 25/06/2016 19:15, Richard Heck a écrit :
For now, the branch is here:
http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets
If you are satisfied with it then you could commit it, I think.
What is your plan?
On 06/25/2016 01:36 PM, Guillaume Munch wrote:
> Le 25/06/2016 17:00, Richard Heck a écrit :
>> On 06/25/2016 02:58 AM, Liviu Andronic wrote:
>>> On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck wrote:
>>>> Attached please find a patch that implements a combo box for
On 06/25/2016 12:23 PM, Liviu Andronic wrote:
> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
>> I've fixed both these issues with the attached.
>>
> I have trouble applying this patch. I've tried everything from patch
> -p1 < filename.patch to git apply filename.patch on a clean tree and
>
tCombo
later, when it is inserted in the toolbar. Yes, this is tricky and not
done like that usually.
Also, I should have written what is the correct version for clarity. Do
not delete it there.
>/**
> * \warning Don't Delete! The layout box is actually owned by
> * whiche
Le 25/06/2016 17:01, Richard Heck a écrit :
I'd be happy for someone else to make it into a menu, but I do not know
enough about Qt to do it myself. I mostly stole this from LayoutBox.
Yes, looks like it is not immediate.
Le 25/06/2016 17:00, Richard Heck a écrit :
On 06/25/2016 02:58 AM, Liviu Andronic wrote:
On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck wrote:
Attached please find a patch that implements a combo box for custom
insets, much like the layout box. This is a very simple version. More
complicated
Liviu Andronic wrote:
> The next patch would create the file src/frontends/qt4/InsetCombo.cpp,
> which already exists! Assume -R? [n]
> Apply anyway? [n]
Delete new files (InsetCombo*). P
Am Samstag, 25. Juni 2016 um 18:34:14, schrieb Liviu Andronic
> On Sat, Jun 25, 2016 at 6:29 PM, Kornel Benko wrote:
> > Am Samstag, 25. Juni 2016 um 18:23:03, schrieb Liviu Andronic
> >
> >> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
> >> > I've fixed both these issues with the atta
On Sat, Jun 25, 2016 at 6:29 PM, Kornel Benko wrote:
> Am Samstag, 25. Juni 2016 um 18:23:03, schrieb Liviu Andronic
>
>> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
>> > I've fixed both these issues with the attached.
>> >
>> I have trouble applying this patch. I've tried everything f
Am Samstag, 25. Juni 2016 um 18:23:03, schrieb Liviu Andronic
> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
> > I've fixed both these issues with the attached.
> >
> I have trouble applying this patch. I've tried everything from patch
> -p1 < filename.patch to git apply filename.patch on
On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck wrote:
> I've fixed both these issues with the attached.
>
I have trouble applying this patch. I've tried everything from patch
-p1 < filename.patch to git apply filename.patch on a clean tree and
it fails.
>git apply "0001-Initial-work-for-inset-tool
On 06/25/2016 05:29 AM, Jean-Marc Lasgouttes wrote:
> That means that we probably shouldn't use a x but a kind of menu, maybe
> attached to an icon
Try the latest version.
I'd be happy for someone else to make it into a menu, but I do not know
enough about Qt to do it myself. I mostly stole this
On 06/25/2016 02:58 AM, Liviu Andronic wrote:
> On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck wrote:
>> Attached please find a patch that implements a combo box for custom
>> insets, much like the layout box. This is a very simple version. More
>> complicated ones might als
That means that we probably shouldn't use a x but a kind of menu, maybe
attached to an icon
JMarc
Le 25 juin 2016 08:58:57 GMT+02:00, Liviu Andronic a écrit :
>On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck wrote:
>Looks good. Couple of comments:
>- since unlike styles we don't always have a
On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck wrote:
>
> Attached please find a patch that implements a combo box for custom
> insets, much like the layout box. This is a very simple version. More
> complicated ones might also have an InsetLayout tag that governed
> whether an ins
Attached please find a patch that implements a combo box for custom
insets, much like the layout box. This is a very simple version. More
complicated ones might also have an InsetLayout tag that governed
whether an inset would appear here. It would also be very easy to adapt
this also to give us
Le 05/04/2016 13:33, Helge Hafting a écrit :
Impressive. This solved my problem - both large and small content gets a
nice box now. :-)
Thanks for testing. I will propose that for 2.2.1, there is no hurry.
Now, would you say it would be better to actually compute the width?
This is not very
Den 05. april 2016 10:51, skrev LyX Ticket Tracker:
#10048: Box with unit \width as width renders way too narrow
[...]
Comment:
Here is a trivial patch that avoids the error. It might be better to
actually compute the width using information returned by
{{{InsetText::metrics}}}, but I
class
* articificial use_parbox, use_makebox, inner_box parameters that have
to be set in a very precise manner in fragile code that I am not able to
follow.
It is not artificial. What do you find artificial? LaTeX is very
complicated here (some box types allow widths, some not, some boxes
allow to change
Le 03/02/2016 21:41, Uwe Stöhr a écrit :
Am 03.02.2016 um 10:20 schrieb Jean-Marc Lasgouttes:
The problem is that every time I look
at this box code, my eyes bleed:
* type as a string instead of enum
I have not invented this. Why is important how a parameter is stored? If
it is important to
Am 03.02.2016 um 10:20 schrieb Jean-Marc Lasgouttes:
OK, I'll try to have a go at it.
Thanks for having a look.
The problem is that every time I look
at this box code, my eyes bleed:
* type as a string instead of enum
I have not invented this. Why is important how a parameter is s
Le 29/01/2016 01:30, Uwe Stöhr a écrit :
Attached is a patch to fix bug http://www.lyx.org/trac/ticket/8712.
OK, I'll try to have a go at it. The problem is that every time I look
at this box code, my eyes bleed:
* type as a string instead of enum
* special length as string inste
Am 29.01.2016 um 01:30 schrieb Uwe Stöhr:
Attached is a patch to fix bug http://www.lyx.org/trac/ticket/8712.
Scott or anyone else, can this go in?
If So this is in my opinion also safe to be backported.
thanks and regards
Uwe
Attached is a patch to fix bug http://www.lyx.org/trac/ticket/8712.
The problem was that if there is no inner box and one executes to remove
the outer box (frame) the result is an empty box (no inner AND no outer
box). But in this case a makebox must be used. This is already handled
in the
Am 30.11.2015 um 12:59 schrieb Uwe Stöhr:
Sure. I'll file a bug report that this is not forgotten.
Done:
http://www.lyx.org/trac/ticket/9885
Regards Uwe
Le 29/11/2015 23:55, Uwe Stöhr a écrit :
Am 29.11.2015 um 22:26 schrieb Jean-Marc Lasgouttes:
This separation between box alignment and paragraph alignment does not
exist in LaTeX. This is a creation that you propose.
Yes, because LyX doesn't allow you to choose between e.g. \begin{cente
Original Message
From: Jean-Marc Lasgouttes
Sent: Montag, 30. November 2015 10:32
>> Yes, because LyX doesn't allow you to choose between e.g. \begin{center} or
>> \centering.
> So the right solution would be to add a checkbox 'compact alignment' (or
'tight' or whatever) so that the align
Am 29.11.2015 um 22:26 schrieb Jean-Marc Lasgouttes:
Why would the text in the minipage need different vertical spacing than
the main text? They are of same nature.
Well, the user is free to decide. if he likes it, why not? Note that i
am arguing for a method to set the alignment to ALL box
text
Why would the text in the minipage need different vertical spacing than
the main text? They are of same nature.
The paragraph separation in this file is the default - indentation not
vertical space.
So users just want to e.g. right-align a paragraph in the box. there is
no reason that ver
want to e.g. right-align a paragraph in the box. there is
no reason that vertical space is added. This is definitely not wanted.
As I already said earlier, magic happens here:
bool noTrivlistCentering(InsetCode code)
{
return code == FLOAT_CODE
|| code == WRAP_CODE
Le 24/11/2015 20:02, Uwe Stöhr a écrit :
As I already explained in the relevant thread, there are already cases
where we do what you want: table cells and floats. It would be trivial
to extend this so that alignment is done like that also for makebox (we
do not want to change minipage/parbox, do
Original Message
From: Jean-Marc Lasgouttes
Sent: Dienstag, 24. November 2015 09:33
> As I already explained in the relevant thread, there are already cases
where we do what you want: table cells and floats. It would be trivial
to extend this so that alignment is done like that also for ma
in the box dialog.
First: why would one choose parbox, minipage or makebox. This choice
assumes that one knows how LaTeX boxes work. In this case, one also
knows about alignment parameters, right?
Hmm, it is explained in the docs that a minipage is like a page and that
a parbox is like a small
sets the alignment inside a box, the paragraph settings
menu gets deactivated and the alignment is set via \raggedleft etc.
Right now it is not obvious why one cannot set the alignment for text
inside minipages and parboxes.
To be fair, that are many things that are not obvious in the box dialog
Le 22/11/2015 18:52, Uwe Stöhr a écrit :
I am fine with your patch to be in but there are more things to do:
I know, but my patch never intended to do this things. This patch is
merely a spin-off of the discussion about your commit.
My idea was to allow to set the alignment of the box
Le 21/11/2015 10:02, Georg Baum a écrit :
You have my vote for submitting this.
Thanks. It is in now.
JMarc
.
For screen layout, we always want to specify some alignment, so we
always respect hor_pos.
Thanks JMarc for the patch.
I am fine with your patch to be in but there are more things to do:
My idea was to allow to set the alignment of the box content inside the
box. It is still not possible t
Jean-Marc Lasgouttes wrote:
> This new version of the patch is also able to handle 'stretch' alignment.
>
> Concerning LaTeX output, hor_pos 'c' value is obtained by omitting
> alignment parameter. I guess one can specify 'c' explicitly, though.
> For screen layout, we always want to specify some
Le 23/10/2015 21:47, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Actually fixing this for LR boxes (so-called makebox in the code) is not
difficult because we have the framework for table cells already. I
propose to put that in master. Would it be OK?
I did not know that mechanism. This
Le 23/10/2015 21:47, Georg Baum a écrit :
I did not know that mechanism. This looks indeed nice. However, I wonder
whether the condition for ignoring hor_pos should be the same as the one
used for LaTeX output. When looking at your patch I could not see whether
both places are equivalent. Anyway
1 - 100 of 761 matches
Mail list logo
