On Wed, Jul 06, 2005 at 08:56:40AM +, [EMAIL PROTECTED] wrote:
Log message:
get your ruler out, John! button insets are centered again [bug 1293]
Ah, gentle mockery ... thanks :)
john
On Wed, Jul 06, 2005 at 08:56:40AM +, [EMAIL PROTECTED] wrote:
> Log message:
> get your ruler out, John! button insets are centered again [bug 1293]
Ah, gentle mockery ... thanks :)
john
On Tue, Mar 11, 2003 at 08:02:27PM +, John Levon wrote:
The base concept is that of a document iterator. A document iterator
So all the hard bits have to be done in one big patch.
Well, there are a quite a few small steps left, i.e. Lars' paragraph
iterators work could and should
On Tue, Mar 11, 2003 at 08:02:27PM +, John Levon wrote:
> > The base concept is that of a "document iterator". A document iterator
>
> So all the hard bits have to be done in one big patch.
Well, there are a quite a few small steps left, i.e. Lars' paragraph
iterators work could and should
On Mon, Mar 10, 2003 at 07:10:41PM +, John Levon wrote:
On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
| You guessed wrongly: it hasn't. I still think it's possibly the worst
| idea we have in the lyx source.
What is your better solution?
A proper layout
On Mon, Mar 10, 2003 at 07:46:33PM +, John Levon wrote:
I just don't get how this can work in most places ... if we don't have
an iterator to start with (eg. inserting paragraph in the current cursor
pos) what do we do ? Iterate throught the whole doc until we find the
current par ?
The
On Mon Mar 10, 2003 20:10, John Levon wrote:
A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
etc. You can be sure Gecko doesn't have a hack like we do :)
qrichtext? khtml?
Ed.
On Tue, Mar 11, 2003 at 09:23:19AM +0100, Andre Poenitz wrote:
What is your better solution?
A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
etc.
It's not like 'everything is an inset' has not been proposed yet ;-}
Certainly it's not *my* solution :)
Though
On Tue, Mar 11, 2003 at 09:30:32AM +0100, Edwin Leuven wrote:
A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
etc. You can be sure Gecko doesn't have a hack like we do :)
qrichtext? khtml?
I don't know how you'd propose this working...
john
Andre Poenitz [EMAIL PROTECTED] writes:
| On Mon, Mar 10, 2003 at 07:46:33PM +, John Levon wrote:
| I just don't get how this can work in most places ... if we don't have
| an iterator to start with (eg. inserting paragraph in the current cursor
| pos) what do we do ? Iterate throught the
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
| Iteration through the whole doc happens only if the cursor is set bey
| mouseclick or similar.
Not even then, since we then can find a row close to the click, at in
worst case start from the row at top of screen.
And
On Tue, Mar 11, 2003 at 08:37:56AM +, John Levon wrote:
Though lars is right about the current inset stuff commingling data
and view in a bad way
Hm, I think the situation is currently improving in this area. Rapidly, if
I may add.
Start with small steps, and put the 'real metachars'
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
| Iteration through the whole doc happens only if the cursor is set bey
| mouseclick or similar.
Not even then, since we then can find a row close to the click, at in
worst case start from the row at top of screen.
Modulo
On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
Start with small steps, and put the 'real metachars' in an inset.
We would create insethfill.[Ch] in src/insets, add it to Makefile.am
Oh *that's* what you meant by real metachars. Sorry. That sounds
relatively possible though
Andre Poenitz wrote:
Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
iteration through the whole doc is not noticable after a user-invoked
mouseclick.
How brave you are. We do this already (I'll bet that more than one time). ;)
Alfredo
On Tue, Mar 11, 2003 at 08:52:23AM +, John Levon wrote:
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
| Iteration through the whole doc happens only if the cursor is set bey
| mouseclick or similar.
Not even then, since we then can find a row close to the
On Tue, Mar 11, 2003 at 09:02:37AM +, John Levon wrote:
On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
Start with small steps, and put the 'real metachars' in an inset.
We would create insethfill.[Ch] in src/insets, add it to Makefile.am
Oh *that's* what you
On Tue, Mar 11, 2003 at 09:59:25AM +0100, Alfredo Braunstein wrote:
Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
iteration through the whole doc is not noticable after a user-invoked
mouseclick.
How brave you are. We do this already (I'll bet that more than one
John Levon [EMAIL PROTECTED] writes:
| Start with small steps, and put the 'real metachars' in an inset.
Of course this will be all the metachars _except_ META_INSET...
The one I'd like to get removed the most is META_HFILL, having that as
an inset would be great.
--
Lgb
Andre Poenitz [EMAIL PROTECTED] writes:
| Process can be repeated with other metachars. If it turns out that lots of
| these insetmetachar look similar, we'd try to factor out a common base
| class or even collect them in a single InsetMetaChar. If I think abut it,
| I'd even start with a single
John Levon [EMAIL PROTECTED] writes:
| On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
|
| | Iteration through the whole doc happens only if the cursor is set bey
| | mouseclick or similar.
|
| Not even then, since we then can find a row close to the click, at in
|
On Tue, Mar 11, 2003 at 10:17:20AM +0100, Lars Gullik Bjønnes wrote:
Of course this will be all the metachars _except_ META_INSET...
The one I'd like to get removed the most is META_HFILL, having that as
an inset would be great.
And that's the tricky part to get right on screen, because
On Tue, Mar 11, 2003 at 10:15:56AM +0100, Andre' Poenitz wrote:
The one I'd like to get removed the most is META_HFILL, having that as
an inset would be great.
And that's the tricky part to get right on screen, because there are
things to the right. Input/Output should be easy...
I'll
On Tue, Mar 11, 2003 at 10:01:03AM +0100, Andre Poenitz wrote:
You don't have raw Row * anymore.
The base concept is that of a document iterator. A document iterator
So all the hard bits have to be done in one big patch.
john
On Tue, Mar 11, 2003 at 10:22:48AM +0100, Andre Poenitz wrote:
I'll have a go.
Neat.
John, you can avoid duplicated work
Oh, I have other things I want to do :)
john
On Mon, Mar 10, 2003 at 07:10:41PM +, John Levon wrote:
> On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
>
> > | You guessed wrongly: it hasn't. I still think it's possibly the worst
> > | idea we have in the lyx source.
> >
> > What is your better solution?
>
> A
On Mon, Mar 10, 2003 at 07:46:33PM +, John Levon wrote:
> I just don't get how this can work in most places ... if we don't have
> an iterator to start with (eg. inserting paragraph in the current cursor
> pos) what do we do ? Iterate throught the whole doc until we find the
> current par ?
On Mon Mar 10, 2003 20:10, John Levon wrote:
> A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
> etc. You can be sure Gecko doesn't have a hack like we do :)
qrichtext? khtml?
Ed.
On Tue, Mar 11, 2003 at 09:23:19AM +0100, Andre Poenitz wrote:
> > > What is your better solution?
> >
> > A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
> > etc.
>
> It's not like 'everything is an inset' has not been proposed yet ;-}
Certainly it's not *my* solution
On Tue, Mar 11, 2003 at 09:30:32AM +0100, Edwin Leuven wrote:
> > A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
> > etc. You can be sure Gecko doesn't have a hack like we do :)
>
> qrichtext? khtml?
I don't know how you'd propose this working...
john
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 07:46:33PM +, John Levon wrote:
| > I just don't get how this can work in most places ... if we don't have
| > an iterator to start with (eg. inserting paragraph in the current cursor
| > pos) what do we do ? Iterate throught
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
> | Iteration through the whole doc happens only if the cursor is set bey
> | mouseclick or similar.
>
> Not even then, since we then can find a row close to the click, at in
> worst case start from the row at top of screen.
On Tue, Mar 11, 2003 at 08:37:56AM +, John Levon wrote:
> Though lars is right about the current inset stuff commingling data
> and view in a bad way
Hm, I think the situation is currently improving in this area. Rapidly, if
I may add.
> > Start with small steps, and put the 'real
On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
> | Iteration through the whole doc happens only if the cursor is set bey
> | mouseclick or similar.
>
> Not even then, since we then can find a row close to the click, at in
> worst case start from the row at top of screen.
On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
> > > Start with small steps, and put the 'real metachars' in an inset.
>
> We would create insethfill.[Ch] in src/insets, add it to Makefile.am
Oh *that's* what you meant by "real metachars". Sorry. That sounds
relatively possible
Andre Poenitz wrote:
> Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
> iteration through the whole doc is not noticable after a user-invoked
> mouseclick.
How brave you are. We do this already (I'll bet that more than one time). ;)
Alfredo
On Tue, Mar 11, 2003 at 08:52:23AM +, John Levon wrote:
> On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
>
> > | Iteration through the whole doc happens only if the cursor is set bey
> > | mouseclick or similar.
> >
> > Not even then, since we then can find a row close
On Tue, Mar 11, 2003 at 09:02:37AM +, John Levon wrote:
> On Tue, Mar 11, 2003 at 09:53:13AM +0100, Andre Poenitz wrote:
>
> > > > Start with small steps, and put the 'real metachars' in an inset.
> >
> > We would create insethfill.[Ch] in src/insets, add it to Makefile.am
>
> Oh *that's*
On Tue, Mar 11, 2003 at 09:59:25AM +0100, Alfredo Braunstein wrote:
> > Modulo speed-up tricks, of course. But I'd bet a bottle of beer that
> > iteration through the whole doc is not noticable after a user-invoked
> > mouseclick.
>
> How brave you are. We do this already (I'll bet that more than
John Levon <[EMAIL PROTECTED]> writes:
| > Start with small steps, and put the 'real metachars' in an inset.
Of course this will be all the metachars _except_ META_INSET...
The one I'd like to get removed the most is META_HFILL, having that as
an inset would be great.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Process can be repeated with other metachars. If it turns out that lots of
| these inset look similar, we'd try to factor out a common base
| class or even collect them in a single InsetMetaChar. If I think abut it,
| I'd even start with a single
John Levon <[EMAIL PROTECTED]> writes:
| On Tue, Mar 11, 2003 at 09:42:10AM +0100, Lars Gullik Bj?nnes wrote:
|
| > | Iteration through the whole doc happens only if the cursor is set bey
| > | mouseclick or similar.
| >
| > Not even then, since we then can find a row close to the click, at in
On Tue, Mar 11, 2003 at 10:17:20AM +0100, Lars Gullik Bjønnes wrote:
> Of course this will be all the metachars _except_ META_INSET...
>
> The one I'd like to get removed the most is META_HFILL, having that as
> an inset would be great.
And that's the tricky part to get right on screen, because
On Tue, Mar 11, 2003 at 10:15:56AM +0100, Andre' Poenitz wrote:
> > The one I'd like to get removed the most is META_HFILL, having that as
> > an inset would be great.
>
> And that's the tricky part to get right on screen, because "there are
> things to the right". Input/Output should be easy...
On Tue, Mar 11, 2003 at 10:01:03AM +0100, Andre Poenitz wrote:
> You don't have raw Row * anymore.
>
> The base concept is that of a "document iterator". A document iterator
So all the hard bits have to be done in one big patch.
john
On Tue, Mar 11, 2003 at 10:22:48AM +0100, Andre Poenitz wrote:
> I'll have a go.
Neat.
> John, you can avoid duplicated work
Oh, I have other things I want to do :)
john
On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote:
Modified files:
lyx-devel/src/: ChangeLog text.C
Log message:
fix the row breaking. Sorry all !
Anyway, this *should* have one bug less, and be understandable.
Guess if my opinion
Dekel == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote:
Modified files: lyx-devel/src/: ChangeLog text.C
Log message: fix the row breaking. Sorry all !
Anyway, this *should* have one bug less, and be understandable.
Guess
On Mon, Mar 10, 2003 at 10:18:16AM +0100, Lars Gullik Bj?nnes wrote:
| Guess if my opinion on the cleverness of inset-as-metachar
| has changed
In what way has that changed?
You guessed wrongly: it hasn't. I still think it's possibly the worst
idea we have in the lyx source.
john
On Mon, Mar 10, 2003 at 11:04:15AM +0100, Jean-Marc Lasgouttes wrote:
Yes, I think this is the kind of bugs John was interested in fixing.
And indeed, that works fine now :)
john
John Levon [EMAIL PROTECTED] writes:
| On Mon, Mar 10, 2003 at 10:18:16AM +0100, Lars Gullik Bj?nnes wrote:
|
| | Guess if my opinion on the cleverness of inset-as-metachar
| | has changed
|
| In what way has that changed?
|
| You guessed wrongly: it hasn't. I still think it's possibly
On Mon, Mar 10, 2003 at 07:02:55PM +, John Levon wrote:
On Mon, Mar 10, 2003 at 11:04:15AM +0100, Jean-Marc Lasgouttes wrote:
Yes, I think this is the kind of bugs John was interested in fixing.
And indeed, that works fine now :)
But it is still broken in 1.3.1cvs.
On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
| You guessed wrongly: it hasn't. I still think it's possibly the worst
| idea we have in the lyx source.
What is your better solution?
A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
etc. You can
On Mon, Mar 10, 2003 at 09:10:17PM +0200, Dekel Tsur wrote:
But it is still broken in 1.3.1cvs.
And it will stay broken.
john
John Levon [EMAIL PROTECTED] writes:
| Of course it's just a pipe dream and I'll never have the energy to
| follow through on such a massive reworking.
And we cannot rework too much at the same time anyway...
So you should help me rework the paragraph list first instead.
--
Lgb
John Levon [EMAIL PROTECTED] writes:
| On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
|
| | You guessed wrongly: it hasn't. I still think it's possibly the worst
| | idea we have in the lyx source.
|
| What is your better solution?
|
| A proper layout engine ... very
On Mon, Mar 10, 2003 at 08:17:56PM +0100, Lars Gullik Bj?nnes wrote:
I do not belive that it is the layout engine that is hard... first we
must decide how to store the paragraphs.
Sure ... I'm not particularly speaking design wise, but the job of
getting from where we are today, to where we
John Levon [EMAIL PROTECTED] writes:
| p.s. it's a bit difficult to help you with the par list stuff when I
| don't know what needs doing !
A huge part of the jog is to remove all implict dependencies on the
next and previous members of Paragraph. One approach I have is to turn
the NO_NEXT
On Mon, Mar 10, 2003 at 08:42:49PM +0100, Lars Gullik Bj?nnes wrote:
A huge part of the jog is to remove all implict dependencies on the
next and previous members of Paragraph. One approach I have is to turn
the NO_NEXT define ON in paragraph.h and then single out a file to
work on, and move
John Levon [EMAIL PROTECTED] writes:
| On Mon, Mar 10, 2003 at 08:42:49PM +0100, Lars Gullik Bj?nnes wrote:
|
| A huge part of the jog is to remove all implict dependencies on the
| next and previous members of Paragraph. One approach I have is to turn
| the NO_NEXT define ON in paragraph.h
On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote:
> Modified files:
> lyx-devel/src/: ChangeLog text.C
>
> Log message:
> fix the row breaking. Sorry all !
>
> Anyway, this *should* have one bug less, and be understandable.
>
>>>>> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> On Mon, Mar 10, 2003 at 02:46:41AM +, [EMAIL PROTECTED] wrote:
>> Modified files: lyx-devel/src/: ChangeLog text.C
>>
>> Log message: fix the row breaking. Sorry
On Mon, Mar 10, 2003 at 10:18:16AM +0100, Lars Gullik Bj?nnes wrote:
> | Guess if my opinion on the "cleverness" of inset-as-metachar
> | has changed
>
> In what way has that changed?
You guessed wrongly: it hasn't. I still think it's possibly the worst
idea we have in the lyx source.
On Mon, Mar 10, 2003 at 11:04:15AM +0100, Jean-Marc Lasgouttes wrote:
> Yes, I think this is the kind of bugs John was interested in fixing.
And indeed, that works fine now :)
john
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 10:18:16AM +0100, Lars Gullik Bj?nnes wrote:
|
| > | Guess if my opinion on the "cleverness" of inset-as-metachar
| > | has changed
| >
| > In what way has that changed?
|
| You guessed wrongly: it hasn't. I still think it's
On Mon, Mar 10, 2003 at 07:02:55PM +, John Levon wrote:
> On Mon, Mar 10, 2003 at 11:04:15AM +0100, Jean-Marc Lasgouttes wrote:
>
> > Yes, I think this is the kind of bugs John was interested in fixing.
>
> And indeed, that works fine now :)
But it is still broken in 1.3.1cvs.
On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
> | You guessed wrongly: it hasn't. I still think it's possibly the worst
> | idea we have in the lyx source.
>
> What is your better solution?
A proper layout engine ... very lightweight InsetBullet, InsetParagraph,
etc. You
On Mon, Mar 10, 2003 at 09:10:17PM +0200, Dekel Tsur wrote:
> But it is still broken in 1.3.1cvs.
And it will stay broken.
john
John Levon <[EMAIL PROTECTED]> writes:
| Of course it's just a pipe dream and I'll never have the energy to
| follow through on such a massive reworking.
And we cannot rework too much at the same time anyway...
So you should help me rework the paragraph list first instead.
--
Lgb
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 08:06:13PM +0100, Lars Gullik Bj?nnes wrote:
|
| > | You guessed wrongly: it hasn't. I still think it's possibly the worst
| > | idea we have in the lyx source.
| >
| > What is your better solution?
|
| A proper layout engine ...
On Mon, Mar 10, 2003 at 08:17:56PM +0100, Lars Gullik Bj?nnes wrote:
> I do not belive that it is the layout engine that is hard... first we
> must decide how to store the paragraphs.
Sure ... I'm not particularly speaking design wise, but the job of
getting from where we are today, to where we
John Levon <[EMAIL PROTECTED]> writes:
| p.s. it's a bit difficult to help you with the par list stuff when I
| don't know what needs doing !
A huge part of the jog is to remove all implict dependencies on the
next and previous members of Paragraph. One approach I have is to turn
the NO_NEXT
On Mon, Mar 10, 2003 at 08:42:49PM +0100, Lars Gullik Bj?nnes wrote:
> A huge part of the jog is to remove all implict dependencies on the
> next and previous members of Paragraph. One approach I have is to turn
> the NO_NEXT define ON in paragraph.h and then single out a file to
> work on, and
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 08:42:49PM +0100, Lars Gullik Bj?nnes wrote:
|
| > A huge part of the jog is to remove all implict dependencies on the
| > next and previous members of Paragraph. One approach I have is to turn
| > the NO_NEXT define ON in
Compile failure:
toc.C: In function `const class toc::TocList toc::getTocList(const Buffer *)':
toc.C:79: passing `const Buffer' as `this' argument of `class ParIterator
Buffer::par_iterator_begin()' discards qualifiers
toc.C:80: passing `const Buffer' as `this' argument of `class ParIterator
Compile failure:
toc.C: In function `const class toc::TocList toc::getTocList(const Buffer *)':
toc.C:79: passing `const Buffer' as `this' argument of `class ParIterator
Buffer::par_iterator_begin()' discards qualifiers
toc.C:80: passing `const Buffer' as `this' argument of `class ParIterator
On Thu, Mar 14, 2002 at 02:40:20PM +, [EMAIL PROTECTED] wrote:
Log message:
Fix deleting of paragraphs after undo (fix #236).
Excellent !!! Shall test soon. pre1 is at hand ...
thanks
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as such.
On Thu, Mar 14, 2002 at 01:46:43PM +, John Levon wrote:
Excellent !!! Shall test soon. pre1 is at hand ...
but what's the purpose of the #if 0'd code in text2.C ?
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as such.
On 14-Mar-2002 John Levon wrote:
On Thu, Mar 14, 2002 at 01:46:43PM +, John Levon wrote:
Excellent !!! Shall test soon. pre1 is at hand ...
but what's the purpose of the #if 0'd code in text2.C ?
The ChangeLog is your friend ;)
Jug
--
On Thu, Mar 14, 2002 at 02:40:20PM +, [EMAIL PROTECTED] wrote:
> Log message:
> Fix deleting of paragraphs after undo (fix #236).
Excellent !!! Shall test soon. pre1 is at hand ...
thanks
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as
On Thu, Mar 14, 2002 at 01:46:43PM +, John Levon wrote:
> Excellent !!! Shall test soon. pre1 is at hand ...
but what's the purpose of the #if 0'd code in text2.C ?
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as such.
On 14-Mar-2002 John Levon wrote:
> On Thu, Mar 14, 2002 at 01:46:43PM +, John Levon wrote:
>
>> Excellent !!! Shall test soon. pre1 is at hand ...
>
> but what's the purpose of the #if 0'd code in text2.C ?
The ChangeLog is your friend ;)
Jug
--
82 matches
Mail list logo
