On 09/17/2010 08:22 AM, Uwe Stöhr wrote:
Am 17.09.2010 08:09, schrieb Abdelrazak Younes:
Anyway, your last commit confirms me that you didn't learn anything
If the /// commit was wrong, why does every other inset header file
use it? Why are these changes only made in one file, why is the
Am 17.09.2010 08:09, schrieb Abdelrazak Younes:
On 09/17/2010 03:21 AM, Uwe Stöhr wrote:
>> Replacing pi.base.textwidth with the value of mi.base.textwidth
gave exactly the right drawing.
>
> Wrong again, my testing revealed a lot of misdrawing.
What else was wrong besides the large offset iss
On 09/17/2010 03:21 AM, Uwe Stöhr wrote:
>> Replacing pi.base.textwidth with the value of mi.base.textwidth
gave exactly the right drawing.
>
> Wrong again, my testing revealed a lot of misdrawing.
What else was wrong besides the large offset issue?
I am fed up with this Uwe. Try to learn by
>> Replacing pi.base.textwidth with the value of mi.base.textwidth gave exactly
the right drawing.
>
> Wrong again, my testing revealed a lot of misdrawing.
What else was wrong besides the large offset issue?
>>Now I'm upset. You reverted correct working code with wrong one:
>>
>>- pi.p
On 09/16/2010 03:33 AM, Uwe Stöhr wrote:
Am 15.09.2010 08:28, schrieb Abdelrazak Younes:
No, this is wrong. I need the text width and not the inset width! As
I wrote, the text width is
calculated in TextMetrics and I need this value in InsetLine.cpp. So
I only need to replace there
the wrong p
Am 15.09.2010 08:28, schrieb Abdelrazak Younes:
No, this is wrong. I need the text width and not the inset width! As I wrote,
the text width is
calculated in TextMetrics and I need this value in InsetLine.cpp. So I only
need to replace there
the wrong pi.base.textwidth with the value calculate
On 09/15/2010 03:02 AM, Richard Heck wrote:
On 09/14/2010 07:31 PM, Uwe Stöhr wrote:
Am 14.09.2010 20:13, schrieb Andre Poenitz:
This is my problem:
In line 433 of TextMetrics.cpp the text width is calculated:
int const w = max_width_ - leftMargin(max_width_, pit, ii->pos)
- right_margin
On 09/15/2010 01:27 AM, Uwe Stöhr wrote:
Am 15.09.2010 01:22, schrieb Uwe Stöhr:
So you just need the inset width AFAIU which happens to be egal to
the text width of the enclosing
text inset
The inset width is only equal if the line width is 100col% for a line
width of 5cm or 10 text% it is
On 09/15/2010 01:22 AM, Uwe Stöhr wrote:
Am 14.09.2010 15:26, schrieb Abdelrazak Younes:
You would very much help me very much if you could look at the code.
As said my problem is that
the value "w" (the text width) is calculated in
TextMetrics::redoParagraph. I need to have this
value in Inse
On 9/14/10 9:51 PM, Uwe Stöhr wrote:
Am 15.09.2010 03:02, schrieb Richard Heck:
How can I do this without changing the code for all of our 98!
insets? This information is only
needed in InsetLine and I thus cannot pollute all other insets with
info.
If there is no other solution than to make i
Am 15.09.2010 03:02, schrieb Richard Heck:
How can I do this without changing the code for all of our 98! insets? This
information is only
needed in InsetLine and I thus cannot pollute all other insets with info.
If there is no other solution than to make it accessible for all insets, how
can
On 09/14/2010 07:31 PM, Uwe Stöhr wrote:
Am 14.09.2010 20:13, schrieb Andre Poenitz:
This is my problem:
In line 433 of TextMetrics.cpp the text width is calculated:
int const w = max_width_ - leftMargin(max_width_, pit, ii->pos)-
right_margin;
I need this result "w" in InsetLine::draw
Am 14.09.2010 20:13, schrieb Andre Poenitz:
This is my problem:
In line 433 of TextMetrics.cpp the text width is calculated:
int const w = max_width_ - leftMargin(max_width_, pit, ii->pos) -
right_margin;
I need this result "w" in InsetLine::draw to be able to draw the line.
The store
Am 15.09.2010 01:22, schrieb Uwe Stöhr:
So you just need the inset width AFAIU which happens to be egal to the text
width of the enclosing
text inset
The inset width is only equal if the line width is 100col% for a line width of 5cm or 10 text% it is
of course much shorter that the text widt
Am 14.09.2010 15:26, schrieb Abdelrazak Younes:
You would very much help me very much if you could look at the code. As said my
problem is that
the value "w" (the text width) is calculated in TextMetrics::redoParagraph. I
need to have this
value in InsetLine::draw. I didn't find a better solut
On Tue, Sep 14, 2010 at 04:30:58AM +0200, Uwe Stöhr wrote:
> Am 13.09.2010 08:58, schrieb Abdelrazak Younes:
>
> >You forgot the attachement...
>
> Sorry.
> In the meantime I found a solution - ugly but does exactly what I want.
> This is my problem:
>
> In line 433 of TextMetrics.cpp the text w
On 09/14/2010 02:20 PM, Uwe Stöhr wrote:
Am 14.09.2010 08:21, schrieb Abdelrazak Younes:
I tried several approaches to achieve this but only the one via a
global variable does the job. Attached is the corresponding patch. It
fixes the problem exactly as it should, but I would like to get rid of
Am 14.09.2010 08:21, schrieb Abdelrazak Younes:
I tried several approaches to achieve this but only the one via a
global variable does the job. Attached is the corresponding patch. It
fixes the problem exactly as it should, but I would like to get rid of
the global variable. Is there a better so
On 09/14/2010 04:30 AM, Uwe Stöhr wrote:
Am 13.09.2010 08:58, schrieb Abdelrazak Younes:
You forgot the attachement...
Sorry.
In the meantime I found a solution - ugly but does exactly what I want.
This is my problem:
In line 433 of TextMetrics.cpp the text width is calculated:
int const w
Am 14.09.2010 04:30, schrieb Uwe Stöhr:
Attached is the corresponding patch.
This version was incorrect, take the attached one instead.
regards Uwe
Index: insets/InsetLine.cpp
===
--- insets/InsetLine.cpp (revision 35358)
+++ ins
Am 13.09.2010 08:58, schrieb Abdelrazak Younes:
You forgot the attachement...
Sorry.
In the meantime I found a solution - ugly but does exactly what I want.
This is my problem:
In line 433 of TextMetrics.cpp the text width is calculated:
int const w = max_width_ - leftMargin(max_width_, pit,
You forgot the attachement...
On 09/13/2010 05:40 AM, Uwe Stöhr wrote:
Am 12.09.2010 08:47, schrieb Abdelrazak Younes:
or do you have to transform this also from InsetCommandParams to
InsetWidgets?
InsetCommandParams is just a set of parameters...
InsetLine still contains some probably unu
Am 12.09.2010 08:47, schrieb Abdelrazak Younes:
or do you have to transform this also from InsetCommandParams to InsetWidgets?
InsetCommandParams is just a set of parameters...
InsetLine still contains some probably unused InsetCommand code. I'm not sure
what to remove.
Besides this, there
Uwe Stöhr wrote:
> > the problem is what happens when width_str is empty. then no width_str[0]
> > exists and accessing it is asking for crash.
>
> This string could not be empty because it was always filled by
> InsetCommandParams. The crash occurred after Abdel's transformation of
> GuiLine to
On 11/09/2010 18:11, Uwe Stöhr wrote:
>>> - there should be some implicit value in boxes, which are
generally sensible
>>> (best would be such values, which would repeat the behaviour
of 1.6
>>> version of horizontal line).
>>
>> I don't understand. The default values when inserting
Am 11.09.2010 09:09, schrieb Abdelrazak Younes:
Abdel, it didn't crash before you transformed the dialog from CommandInset to
InsetWidgets.
It didn't crash on me neither after I changed the dialog but as Pavel
explained, this is not the issue.
The reason for the crash was your transformati
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
This string could not be empty because it was always filled by InsetCommandParams. The crash
occurred after Abdel's transformation of GuiLine to InsetWidgets which doesn't s
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
This string could not be empty because it was always filled by InsetCommandParams. The crash
occurred after Abdel's transformation of GuiLine to InsetWidgets which doesn't s
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
This string could not be empty because it was always filled by InsetCommandParams. The crash occured
after Abdel's transformation of GuiLine to InsetWidgets which doesn't su
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
This string could not be empty because it was always filled by InsetCommandParams. The crash occured
after Abdel's transformation of GuiLine to InsetWidgets which doesn't su
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
This string could not be empty because it was always filled by InsetCommandParams. The crash occured
after Abdel's transformation of GuiLine to InsetWidgets which doesn't su
>>> - there should be some implicit value in boxes, which are generally
sensible
>>> (best would be such values, which would repeat the behaviour of 1.6
>>> version of horizontal line).
>>
>> I don't understand. The default values when inserting a horizontal line are
those of the old
On 08/09/2010 22:37, Uwe Stöhr wrote:
Am 08.09.2010 20:08, schrieb Pavel Sanda:
i was going to look what are the values here, but my lyx crashes when
i go to
horizontal line dialog, backtrace below.
#2 0xb6f8d348 in abort () from /lib/libc.so.6
#3 0x087c224c in lyx::frontend::GuiLine::dialog
Am Samstag, den 11.09.2010, 00:14 +0200 schrieb Pavel Sanda:
> Uwe Stöhr wrote:
> > Am 10.09.2010 20:49, schrieb Pavel Sanda:
> >
> >> do you understand why the code in r35299
> >>
> >> string width_str = fromqstr(WidthLE->text());
> >> if (width_str[0] == '-')
> >>width_str.erase(0,1);
> >>
>
Uwe Stöhr wrote:
> Am 10.09.2010 20:49, schrieb Pavel Sanda:
>
>> do you understand why the code in r35299
>>
>> string width_str = fromqstr(WidthLE->text());
>> if (width_str[0] == '-')
>>width_str.erase(0,1);
>>
>> must crash sooner or later?
>
> No. I check if the string begins with a '-' si
Am 10.09.2010 20:49, schrieb Pavel Sanda:
do you understand why the code in r35299
string width_str = fromqstr(WidthLE->text());
if (width_str[0] == '-')
width_str.erase(0,1);
must crash sooner or later?
No. I check if the string begins with a '-' sign and if so, I remove
this character
Uwe Stöhr wrote:
>> when i enabled debuging symbols on, the crash disappeared though.
>> so i can't give more precise backtrace, sorry.
>
> Abdel, it didn't crash before you transformed the dialog from CommandInset
> to InsetWidgets.
do you understand why the code in r35299
string width_str = fr
Le 8 sept. 10 à 18:42, Uwe Stöhr a écrit :
I need mi.base.textwidth in LineInset::draw. JMarc told me how to
acces it via text_metrics_.width() in rowpainter.cpp. But
text_metrics_.width() gives 684
while mi.base.textwidth gives 630
Therefore I added as workaround the factor 684/630.
Ugh. I d
Am 08.09.2010 20:08, schrieb Pavel Sanda:
i was going to look what are the values here, but my lyx crashes when i go to
horizontal line dialog, backtrace below.
#2 0xb6f8d348 in abort () from /lib/libc.so.6
#3 0x087c224c in lyx::frontend::GuiLine::dialogToParams() const ()
#4 0x0867cf9f in ly
Uwe Stöhr wrote:
>> Uwe can you give a more precise description where from are the numbers 684
>> / 630
>> inside the following code? :
i was going to look what are the values here, but my lyx crashes when i go to
horizontal line dialog, backtrace below.
#2 0xb6f8d348 in abort () from /lib/libc.
Am 08.09.2010 16:50, schrieb Pavel Sanda:
Thanks this works so far, but text_metrics_.width() is always bigger than
mi.base.textwidth (on my PC it is 1.08 times bigger).
Uwe can you give a more precise description where from are the numbers 684 / 630
inside the following code? :
+ // FIXME: t
Uwe Stöhr wrote:
> Am 06.09.2010 17:14, schrieb Jean-Marc LASGOUTTES:
>
>>> I do need it because my patch currently only works for real units.
>>> Length::inPixels calculates the length for non-real units via the
>>> textwidth. offset and height can have all kind of units, e.g. a height
>>> of 1\te
Am 07.09.2010 16:14, schrieb Abdelrazak Younes:
On 09/07/2010 03:03 AM, Uwe Stöhr wrote:
I understand. For now I nevertheless have put it in as InsetCommand because I'm
technically too
limites to get it working with short code as InsetParamsWidget. Feel free to
transform it to
InsetParamsWidg
On 09/07/2010 03:03 AM, Uwe Stöhr wrote:
I understand. For now I nevertheless have put it in as InsetCommand
because I'm technically too limites to get it working with short code
as InsetParamsWidget. Feel free to transform it to InsetParamsWidget.
I did that. As you can see, less code. Hope f
Am 06.09.2010 08:22, schrieb Abdelrazak Younes:
I started the dialog from GuiHspace but the result was much more code than that
I have now.
This is really weird... if you still have it could you post the patch?
I don't have this anymore. My main problem with using InsetLineParams (new param
Am 06.09.2010 17:14, schrieb Jean-Marc LASGOUTTES:
I do need it because my patch currently only works for real units.
Length::inPixels calculates the length for non-real units via the
textwidth. offset and height can have all kind of units, e.g. a height
of 1\textheight is sensible and inPixels
Uwe Stöhr writes:
> I do need it because my patch currently only works for real units.
> Length::inPixels calculates the length for non-real units via the
> textwidth. offset and height can have all kind of units, e.g. a height
> of 1\textheight is sensible and inPixels calculates this length also
Am 06.09.2010 15:14, schrieb Jean-Marc LASGOUTTES:
Can't you just use the Dimension object to infer the width of the line?
All the computations have been made already.
This only works for the width via dim.wid, but I also need to know the
offset and the height inPxiels in InsetLine::draw.
Bu
Uwe Stöhr writes:
> Am 06.09.2010 10:48, schrieb Jean-Marc LASGOUTTES:
>
>> Can't you just use the Dimension object to infer the width of the line?
>> All the computations have been made already.
>
> This only works for the width via dim.wid, but I also need to know the
> offset and the height in
Am 06.09.2010 10:48, schrieb Jean-Marc LASGOUTTES:
Can't you just use the Dimension object to infer the width of the line?
All the computations have been made already.
This only works for the width via dim.wid, but I also need to know the
offset and the height inPxiels in InsetLine::draw.
r
Uwe Stöhr writes:
> Attached is a revised patch where everything should be in shape
> (including lyx2lyx). There now only one remaining problem:
>
> In InsetLine::metrics I can successfully calculate the width in pixels
> but I need to have this information in InsetLine::draw. My attempt
> there w
On 09/05/2010 04:57 PM, Uwe Stöhr wrote:
Am 05.09.2010 09:05, schrieb Abdelrazak Younes:
Could you please try to use InsetParamsWidget for new dialogs instead
of GuiDialog? Each time I
migrate a dialog, some others are popping up...
InsetParamsWidget is easier to use and will results in much l
Am 06.09.2010 05:09, schrieb Uwe Stöhr:
Attached is a revised patch
That patch was corrupted, attached is a working one.
regards Uwe
Index: development/FORMAT
===
--- development/FORMAT (revision 35287)
+++ development/FORMAT (wo
Attached is a revised patch where everything should be in shape (including lyx2lyx). There now only
one remaining problem:
In InsetLine::metrics I can successfully calculate the width in pixels but I need to have this
information in InsetLine::draw. My attempt there with
int const w =
Am 05.09.2010 09:05, schrieb Abdelrazak Younes:
Could you please try to use InsetParamsWidget for new dialogs instead of
GuiDialog? Each time I
migrate a dialog, some others are popping up...
InsetParamsWidget is easier to use and will results in much less lines of code.
Look at GuiHSpace or
G
>> current_ls_ = line_solid;
>> - current_lw_ = line_thin;
>> + current_lw_ = 0.5;
>
> on many places you use int lw, while trying to store float...
Thanks. I fixed this now and committed the painter stuff.
>> void InsetLine::validate(LaTeXFeatures & features) const
>> {
>> -
On 05/09/2010 06:08, Uwe Stöhr wrote:
The attached patch adds support for horizontal lines via the LaTeX
command \rule.
It furthermore provides:
- remove the \lyxline command because this line had a fixed width and
height and it was surrounded by a paragraph. Now the user can
customize the he
Uwe Stöhr wrote:
> current_ls_ = line_solid;
> - current_lw_ = line_thin;
> + current_lw_ = 0.5;
on many places you use int lw, while trying to store float...
> void InsetLine::validate(LaTeXFeatures & features) const
> {
> - features.require("lyxline");
> +
> }
so this
The attached patch adds support for horizontal lines via the LaTeX command
\rule.
It furthermore provides:
- remove the \lyxline command because this line had a fixed width and height and it was surrounded
by a paragraph. Now the user can customize the height, width and decide if it should go i
59 matches
Mail list logo
