Hello LyX developers,
I'm looking at the list of suggested features at
http://www.devel.lyx.org/tasks.php3 and wanted to speak up in favor of
implementing outlining (listed as the possibility to collapse parts of
the document). Outlining is an invaluable tool for dealing with large,
structured
This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
in LyXCursor.
The drawback is obvious: we have O(n) access in some cases where we had
O(1) before. However,I have not seen _any_ indication that this is
noticable after playing around with the UserGuide.
In any case, the
Andre Poenitz [EMAIL PROTECTED] writes:
| This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
| in LyXCursor.
| The drawback is obvious: we have O(n) access in some cases where we had
| O(1) before.
Only some cases?
| However,I have not seen _any_ indication that this is
|
John Levon wrote:
still lists 1.3.2 as the stable release.
Fixed.
And what happened to the Qt graphical tour ?
Wa d'ya mean? Ahhh. The _Qt_ graphical tour.
The link 'The LyX Graphical Tour' on http://www.lyx.org/about/ points
to http://www.lyx.org/about/lgt-1.0/lgt.html. It should point
Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
which is a non-issue in my book since it drags in system files only.
Ok, ok, so you don't like list. I note that support/types.h still
drags in vector.
--
Angus
Angus Leeming [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
| which is a non-issue in my book since it drags in system files only.
| Ok, ok, so you don't like list. I note that support/types.h still
| drags in vector.
And I claim that
Lars Gullik Bjønnes wrote:
| Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
| which is a non-issue in my book since it drags in system files
| only. Ok, ok, so you don't like list. I note that
| support/types.h still drags in vector.
And I claim that you can
On Thu, Oct 09, 2003 at 10:18:58AM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
| in LyXCursor.
| The drawback is obvious: we have O(n) access in some cases where we had
| O(1) before.
On Thu, Oct 09, 2003 at 09:31:13AM +, Angus Leeming wrote:
Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
which is a non-issue in my book since it drags in system files only.
Ok, ok, so you don't like list. I note that support/types.h still
drags in
On Thu, Oct 09, 2003 at 10:46:56AM +0200, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
| which is a non-issue in my book since it drags in system files only.
| Ok, ok, so you don't like
On Thu, Oct 09, 2003 at 09:55:32AM +, Angus Leeming wrote:
Conclusion: the worst case is that this costs us 400secs on a full
compile.
Nice numbers, but you miss the point. I am currently trying to fix
crashs, not #includes..
Andre'
--
Those who desire to give up Freedom in order to
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 10:18:58AM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
| in LyXCursor.
| The drawback is obvious: we have O(n) access in
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 09:31:13AM +, Angus Leeming wrote:
Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
which is a non-issue in my book since it drags in system files only.
Ok, ok, so you don't like list. I note
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 10:46:56AM +0200, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
And we've lost a few dependency on ParagraphList_fwd.h.
| which is a non-issue in my book since it drags in system
On Thu, Oct 09, 2003 at 11:12:46AM +0200, Lars Gullik Bjønnes wrote:
| Debugging suggests that we have a problem with cursors accessing not
| existing paragraphs. Looking at the code this might well be possible: If
| the paragraph list is changed heavily (say assigned to) we invalidate
| all
On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
What type does std::distance return? We should use that for the
offsets.
Some difference_type.
I currently use
typedef std::vectorchar::difference_type par_type;
which is not _exactly_ what we need, but
On Thu, Oct 09, 2003 at 11:16:54AM +0200, Lars Gullik Bjønnes wrote:
Your first mail left a lot of explaining to be desired, a lot better
now. Not need to begin ranting.
I'll try.
Andre'
Andre Poenitz wrote:
Nice numbers, but you miss the point. I am currently trying to fix
crashs, not #includes..
No, I didn't miss the point. I was just being a pain in the ass. I'll
try and stop that ;-)
--
Angus
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| You are no way ahead of me.
^
w
--
Lgb
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
What type does std::distance return? We should use that for the
offsets.
| Some difference_type.
| I currently use
|
| typedef std::vectorchar::difference_type
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 11:12:46AM +0200, Lars Gullik Bjønnes wrote:
| Debugging suggests that we have a problem with cursors accessing not
| existing paragraphs. Looking at the code this might well be possible: If
| the paragraph list is changed
On Thu, Oct 09, 2003 at 11:27:10AM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
What type does std::distance return? We should use that for the
offsets.
| Some difference_type.
| I
On Thu, Oct 09, 2003 at 11:25:19AM +0200, Lars Gullik Bjønnes wrote:
I wonder... would a more explicit uninitialized value be in order?
boost::optionaloffset_t
Please not.
-1 is as explicit as we need it.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not
Andre Poenitz [EMAIL PROTECTED] writes:
| Happy?
pretty much.
--
Lgb
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus The link 'The LyX Graphical Tour' on http://www.lyx.org/about/
Angus points to http://www.lyx.org/about/lgt-1.0/lgt.html. It should
Angus point to http://www.lyx.org/about/lgt/lgt.php3. However,
Angus setting this by hand results in a page
I found that the package 'snapshot' and 'bundledoc'
produce dependency files and tar files for latex files.
So 99% of the work is already done.
I;m trying to get the converter to work correctly now.
Often I want to send a complete manuscript to a co-author to edit it.
Of course I send the
André, I've been trying to make sense of why previewed mathed insets
no longer appear centred and hit on the idea of using a different
background colour to visualise the inset's boundaries.
Why does the mathed formula in display mode extend so much beyond the
editble area? See the snapshots
On Thu, Oct 09, 2003 at 03:52:35PM +, Angus Leeming wrote:
André, I've been trying to make sense of why previewed mathed insets
no longer appear centred and hit on the idea of using a different
background colour to visualise the inset's boundaries.
Why does the mathed formula in
Andre Poenitz wrote:
Would this not work for mathed insets too?
Possibly. Try it.
Indeed, is there not a case for storing an 'indent' or 'offset'
variable in Dimension?
No. Dimension should stay as small as possible. It's heavily used in
places without 'indent' or 'offset'
Actually,
Andre Poenitz wrote:
On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
Actually, you calculate offset_ already, but ddn't use it. The
attached patch does use it and seems to be the right thing to do.
However, I see that the problem now is how to tell the inset that
it should
On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
Actually, you calculate offset_ already, but ddn't use it. The
attached patch does use it and seems to be the right thing to do.
However, I see that the problem now is how to tell the inset that it
should appear on the next row.
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Andre Poenitz wrote:
On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
Actually, you calculate offset_ already, but ddn't use it. The
attached patch does use it and seems to be the right thing to do.
However, I see that the
Jean-Marc Lasgouttes wrote:
Angus When inserting a mathed inset in display mode, could we not
Angus also insert an 'invisible' line break inset (Cntl-Return
Angus without the visual feedback). Toggling to/from display mode
Angus just adds/munches this line break.
In 1.3.x, I see in inset.h:
On Thu, Oct 09, 2003 at 04:47:12PM +, Angus Leeming wrote:
How does LaTeX do this?
Special handling. 'Break stuff above, insert displayed stuff, break
stuff below'.
When inserting a mathed inset in display mode, could we not also
insert an 'invisible' line break inset (Cntl-Return
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Because all 'normal' insets can now do this themselves?
Angus If fact, mathed nver used 'needFullRow'. Instead the
Angus controlling code used the 'display' member function:
I do not understand why having insets do things by themselves is
Andre Poenitz wrote:
On Thu, Oct 09, 2003 at 04:47:12PM +, Angus Leeming wrote:
How does LaTeX do this?
Special handling. 'Break stuff above, insert displayed stuff, break
stuff below'.
Then it sounds like we had the correct solution in 1.3.x where the
insets had a
bool
On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
This got rid of fullRow but also got rid of the logic controlling
display(). Looks like it was a little over-eager.
I can't see anything wrong with reporting inset width = text width if
you want the thing 'displayed' and the line
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
This got rid of fullRow but also got rid of the logic controlling
display(). Looks like it was a little over-eager.
| I can't see anything wrong with reporting inset width = text width if
Andre Poenitz wrote:
On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
This got rid of fullRow but also got rid of the logic controlling
display(). Looks like it was a little over-eager.
I can't see anything wrong with reporting inset width = text width
if you want the thing
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
This got rid of fullRow but also got rid of the logic controlling
display(). Looks like it was a little over-eager.
Andre I can't see anything wrong with reporting inset width
Unfortunately, I have not had a spare minute to look into this.
Can anyone else help here?
On Thu, Oct 09, 2003 at 09:57:29AM +0200, Dr. Peter Hartmann wrote:
Hi Keyvan,
I got exactly the same problem when compiling lyx 1.3.3 on Linux. Have you got
an idea yet how to fix it ?
Kayvan A. Sylvan wrote:
Unfortunately, I have not had a spare minute to look into this.
Can anyone else help here?
On Thu, Oct 09, 2003 at 09:57:29AM +0200, Dr. Peter Hartmann wrote:
I got exactly the same problem when compiling lyx 1.3.3 on Linux.
Have you got an idea yet how to fix it ?
Nobody told me the list will be channeled to gmane, so I have no idea
_how_ it gets channeled. Has somebody subscribed gmane to the list?
This whole thing should have absolutely nothing to do with TMDA, because
archives and friends needs to be subscribed to a different list (a sublist
of the
Angus Leeming wrote:
They're a bit ugly aren't they ;-)
So, I thought I'd use lyx together with lyxpreview2bitmap.sh to
harness latex's typesetting power.
Generated from the attached latex file as
$ sh lyxpreview2bitmap.sh buttons.tex 100 ppm
What do you think? Could these be turned
Angus Leeming wrote:
They're a bit ugly aren't they ;-)
So, I thought I'd use lyx together with lyxpreview2bitmap.sh to
harness latex's typesetting power.
Generated from the attached latex file as
$ sh lyxpreview2bitmap.sh buttons.tex 100 ppm
What do you think? Could these be turned
André, how does InsetFormula know when it is being edited?
Is the test below correct?
void InsetFormula::draw(PainterInfo pi, int x, int y) const
{
// The previews are updated/drawn only when we're not editing the inset.
bool const editing_inset = mathcursor
Is this the solution to the long link times we have?
http://article.gmane.org/gmane.comp.lib.boost.devel/26446
In the next couple of articles in the thread, it appears that they're
going to do this in the boost builds, so I guess it must be a
reasonable thing to do.
Angus Leeming wrote:
André, how does InsetFormula know when it is being edited?
Is the test below correct?
void InsetFormula::draw(PainterInfo pi, int x, int y) const
{
// The previews are updated/drawn only when we're not editing the
inset. bool const editing_inset = mathcursor
Hi.. you may want to take a look at a request I made some time back.. I
think the idea is similar... there're also a couple of links to useful
packages...
http://bugzilla.lyx.org/show_bug.cgi?id=1303
nirmal
Mark van Rossum wrote:
I found that the package 'snapshot' and 'bundledoc'
produce
Hello LyX developers,
I'm looking at the list of suggested features at
http://www.devel.lyx.org/tasks.php3 and wanted to speak up in favor of
implementing outlining (listed as "the possibility to collapse parts of
the document"). Outlining is an invaluable tool for dealing with large,
structured
This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
in LyXCursor.
The drawback is obvious: we have O(n) access in some cases where we had
O(1) before. However,I have not seen _any_ indication that this is
noticable after playing around with the UserGuide.
In any case, the
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
| in LyXCursor.
>
| The drawback is obvious: we have O(n) access in some cases where we had
| O(1) before.
Only some cases?
| However,I have not seen _any_ indication that this is
John Levon wrote:
>
> still lists 1.3.2 as the stable release.
Fixed.
> And what happened to the Qt graphical tour ?
Wa d'ya mean? Ahhh. The _Qt_ graphical tour.
The link 'The LyX Graphical Tour' on http://www.lyx.org/about/ points
to http://www.lyx.org/about/lgt-1.0/lgt.html. It should
Andre Poenitz wrote:
> And we've lost a few dependency on ParagraphList_fwd.h.
which is a non-issue in my book since it drags in system files only.
Ok, ok, so you don't like . I note that support/types.h still
drags in .
--
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>> And we've lost a few dependency on ParagraphList_fwd.h.
| which is a non-issue in my book since it drags in system files only.
| Ok, ok, so you don't like . I note that support/types.h still
| drags in .
And I claim that you
Lars Gullik Bjønnes wrote:
> | Andre Poenitz wrote:
>>> And we've lost a few dependency on ParagraphList_fwd.h.
> | which is a non-issue in my book since it drags in system files
> | only. Ok, ok, so you don't like . I note that
> | support/types.h still drags in .
>
> And I claim that you can
On Thu, Oct 09, 2003 at 10:18:58AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
> | in LyXCursor.
> >
> | The drawback is obvious: we have O(n) access in some cases where we had
> | O(1)
On Thu, Oct 09, 2003 at 09:31:13AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > And we've lost a few dependency on ParagraphList_fwd.h.
> which is a non-issue in my book since it drags in system files only.
> Ok, ok, so you don't like . I note that support/types.h still
> drags in .
On Thu, Oct 09, 2003 at 10:46:56AM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
> >> And we've lost a few dependency on ParagraphList_fwd.h.
> | which is a non-issue in my book since it drags in system files only.
> | Ok, ok, so you
On Thu, Oct 09, 2003 at 09:55:32AM +, Angus Leeming wrote:
> Conclusion: the worst case is that this costs us 400secs on a full
> compile.
Nice numbers, but you miss the point. I am currently trying to fix
crashs, not #includes..
Andre'
--
Those who desire to give up Freedom in order to
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 10:18:58AM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | This is a patch to use 'par_type' offsets to ownerParagraphs().begin()
>> | in LyXCursor.
>> >
>> | The drawback is obvious: we
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 09:31:13AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > And we've lost a few dependency on ParagraphList_fwd.h.
>> which is a non-issue in my book since it drags in system files only.
>> Ok, ok, so you don't like . I
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 10:46:56AM +0200, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | Andre Poenitz wrote:
>> >> And we've lost a few dependency on ParagraphList_fwd.h.
>> | which is a non-issue in my book since it
On Thu, Oct 09, 2003 at 11:12:46AM +0200, Lars Gullik Bjønnes wrote:
> | Debugging suggests that we have a problem with cursors accessing not
> | existing paragraphs. Looking at the code this might well be possible: If
> | the paragraph list is changed heavily (say assigned to) we invalidate
> |
On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
> What type does std::distance return? We should use that for the
> offsets.
Some difference_type.
I currently use
typedef std::vector::difference_type par_type;
which is not _exactly_ what we need, but I've
On Thu, Oct 09, 2003 at 11:16:54AM +0200, Lars Gullik Bjønnes wrote:
> Your first mail left a lot of explaining to be desired, a lot better
> now. Not need to begin ranting.
I'll try.
Andre'
Andre Poenitz wrote:
> Nice numbers, but you miss the point. I am currently trying to fix
> crashs, not #includes..
No, I didn't miss the point. I was just being a pain in the ass. I'll
try and stop that ;-)
--
Angus
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| You are no way ahead of me.
^
w
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
>> What type does std::distance return? We should use that for the
>> offsets.
>
| Some difference_type.
>
| I currently use
|
| typedef std::vector::difference_type
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 11:12:46AM +0200, Lars Gullik Bjønnes wrote:
>> | Debugging suggests that we have a problem with cursors accessing not
>> | existing paragraphs. Looking at the code this might well be possible: If
>> | the paragraph list is
On Thu, Oct 09, 2003 at 11:27:10AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Oct 09, 2003 at 11:14:04AM +0200, Lars Gullik Bjønnes wrote:
> >> What type does std::distance return? We should use that for the
> >> offsets.
> >
> | Some
On Thu, Oct 09, 2003 at 11:25:19AM +0200, Lars Gullik Bjønnes wrote:
> I wonder... would a more explicit "uninitialized" value be in order?
>
> boost::optional
Please not.
-1 is as explicit as we need it.
Andre'
>
--
Those who desire to give up Freedom in order to gain Security, will not
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Happy?
pretty much.
--
Lgb
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> The link 'The LyX Graphical Tour' on http://www.lyx.org/about/
Angus> points to http://www.lyx.org/about/lgt-1.0/lgt.html. It should
Angus> point to http://www.lyx.org/about/lgt/lgt.php3. However,
Angus> setting this by hand
I found that the package 'snapshot' and 'bundledoc'
produce dependency files and tar files for latex files.
So 99% of the work is already done.
I;m trying to get the converter to work correctly now.
>
> Often I want to send a complete manuscript to a co-author to edit it.
> Of course I send
André, I've been trying to make sense of why previewed mathed insets
no longer appear centred and hit on the idea of using a different
background colour to visualise the inset's boundaries.
Why does the mathed formula in display mode extend so much beyond the
editble area? See the snapshots
On Thu, Oct 09, 2003 at 03:52:35PM +, Angus Leeming wrote:
> André, I've been trying to make sense of why previewed mathed insets
> no longer appear centred and hit on the idea of using a different
> background colour to visualise the inset's boundaries.
>
> Why does the mathed formula in
Andre Poenitz wrote:
>> Would this not work for mathed insets too?
>
> Possibly. Try it.
>
>> Indeed, is there not a case for storing an 'indent' or 'offset'
>> variable in Dimension?
>
> No. Dimension should stay as small as possible. It's heavily used in
> places without 'indent' or 'offset'
Andre Poenitz wrote:
> On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
>> Actually, you calculate offset_ already, but ddn't use it. The
>> attached patch does use it and seems to be the right thing to do.
>> However, I see that the problem now is how to tell the inset that
>> it
On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
> Actually, you calculate offset_ already, but ddn't use it. The
> attached patch does use it and seems to be the right thing to do.
> However, I see that the problem now is how to tell the inset that it
> should appear on the next
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Andre Poenitz wrote:
>> On Thu, Oct 09, 2003 at 04:31:08PM +, Angus Leeming wrote:
>>> Actually, you calculate offset_ already, but ddn't use it. The
>>> attached patch does use it and seems to be the right thing to do.
>>>
Jean-Marc Lasgouttes wrote:
> Angus> When inserting a mathed inset in display mode, could we not
> Angus> also insert an 'invisible' line break inset (Cntl-Return
> Angus> without the visual feedback). Toggling to/from display mode
> Angus> just adds/munches this line break.
>
> In 1.3.x, I see
On Thu, Oct 09, 2003 at 04:47:12PM +, Angus Leeming wrote:
> How does LaTeX do this?
Special handling. 'Break stuff above, insert displayed stuff, break
stuff below'.
> When inserting a mathed inset in display mode, could we not also
> insert an 'invisible' line break inset (Cntl-Return
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Because all 'normal' insets can now do this themselves?
Angus> If fact, mathed nver used 'needFullRow'. Instead the
Angus> controlling code used the 'display' member function:
I do not understand why having insets do things by
Andre Poenitz wrote:
> On Thu, Oct 09, 2003 at 04:47:12PM +, Angus Leeming wrote:
>> How does LaTeX do this?
>
> Special handling. 'Break stuff above, insert displayed stuff, break
> stuff below'.
Then it sounds like we had the correct solution in 1.3.x where the
insets had a
bool
On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
> This got rid of fullRow but also got rid of the logic controlling
> display(). Looks like it was a little over-eager.
I can't see anything wrong with reporting inset width = text width if
you want the thing 'displayed' and the line
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
>> This got rid of fullRow but also got rid of the logic controlling
>> display(). Looks like it was a little over-eager.
>
| I can't see anything wrong with reporting inset width = text
Andre Poenitz wrote:
> On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
>> This got rid of fullRow but also got rid of the logic controlling
>> display(). Looks like it was a little over-eager.
>
> I can't see anything wrong with reporting inset width = text width
> if you want the
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
>> This got rid of fullRow but also got rid of the logic controlling
>> display(). Looks like it was a little over-eager.
Andre> I can't see anything wrong with
Unfortunately, I have not had a spare minute to look into this.
Can anyone else help here?
On Thu, Oct 09, 2003 at 09:57:29AM +0200, Dr. Peter Hartmann wrote:
> Hi Keyvan,
>
> I got exactly the same problem when compiling lyx 1.3.3 on Linux. Have you got
> an idea yet how to fix it ?
>
>
>
Kayvan A. Sylvan wrote:
> Unfortunately, I have not had a spare minute to look into this.
> Can anyone else help here?
> On Thu, Oct 09, 2003 at 09:57:29AM +0200, Dr. Peter Hartmann wrote:
>> I got exactly the same problem when compiling lyx 1.3.3 on Linux.
>> Have you got an idea yet how to fix
Nobody told me the list will be channeled to gmane, so I have no idea
_how_ it gets channeled. Has somebody subscribed gmane to the list?
This whole thing should have absolutely nothing to do with TMDA, because
archives and friends needs to be subscribed to a different list (a sublist
of the
Angus Leeming wrote:
> They're a bit ugly aren't they ;-)
>
> So, I thought I'd use lyx together with lyxpreview2bitmap.sh to
> harness latex's typesetting power.
>
> Generated from the attached latex file as
> $ sh lyxpreview2bitmap.sh buttons.tex 100 ppm
>
> What do you think? Could these be
Angus Leeming wrote:
> They're a bit ugly aren't they ;-)
>
> So, I thought I'd use lyx together with lyxpreview2bitmap.sh to
> harness latex's typesetting power.
>
> Generated from the attached latex file as
> $ sh lyxpreview2bitmap.sh buttons.tex 100 ppm
>
> What do you think? Could these be
André, how does InsetFormula know when it is being edited?
Is the test below correct?
void InsetFormula::draw(PainterInfo & pi, int x, int y) const
{
// The previews are updated/drawn only when we're not editing the inset.
bool const editing_inset = mathcursor &&
Is this the solution to the long link times we have?
http://article.gmane.org/gmane.comp.lib.boost.devel/26446
In the next couple of articles in the thread, it appears that they're
going to do this in the boost builds, so I guess it must be a
reasonable thing to do.
Angus Leeming wrote:
> André, how does InsetFormula know when it is being edited?
> Is the test below correct?
>
> void InsetFormula::draw(PainterInfo & pi, int x, int y) const
> {
> // The previews are updated/drawn only when we're not editing the
> inset. bool const editing_inset = mathcursor
Hi.. you may want to take a look at a request I made some time back.. I
think the idea is similar... there're also a couple of links to useful
packages...
http://bugzilla.lyx.org/show_bug.cgi?id=1303
nirmal
Mark van Rossum wrote:
I found that the package 'snapshot' and 'bundledoc'
produce
98 matches
Mail list logo
