Re: On screen (inset) update
On Tue, Aug 05, 2003 at 08:18:14AM +0200, Andre Poenitz wrote: However even now that I know about it I don't see a way to make it leaner than 'full \textwidth'. Please try it in a working version of lyx, it takes up only the space needed for the text, NOT the full width john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Tue, Aug 05, 2003 at 08:18:14AM +0200, Andre Poenitz wrote: > However even now that I know about it I don't see a way to make it > leaner than 'full \textwidth'. Please try it in a working version of lyx, it takes up only the space needed for the text, NOT the full width john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 06:12:59PM +0200, Juergen Spitzmueller wrote: Andre Poenitz wrote: And how do I edit inlined ERT? Are you shure you have already detected inlined ERT? No I haven't. However even now that I know about it I don't see a way to make it leaner than 'full \textwidth'. (hint: right mouse click on ert button) Mouse is bad for wrists. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 06:12:59PM +0200, Juergen Spitzmueller wrote: > Andre Poenitz wrote: > > And how do I edit inlined ERT? > > Are you shure you have already detected inlined ERT? No I haven't. However even now that I know about it I don't see a way to make it leaner than 'full \textwidth'. > (hint: right mouse click on ert button) Mouse is bad for wrists. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
On screen (inset) update
Take this as a positive feedback on the ongoing update work: I have a minipage with lot of cruft (ert etc.) in it. In 1.3cvs, trying to uncollapse the minipage results in an infinite loop as soon as I change the width to 50%col (100%col works). 1.4cvs doesn't have any problems at all (apart from the well-known border offsets). Seems like the rewrite is beginning to pay off. Good work! Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:16:48PM +0200, Juergen Spitzmueller wrote: Take this as a positive feedback on the ongoing update work: Thanks ;-) I have a minipage with lot of cruft (ert etc.) in it. In 1.3cvs, trying to uncollapse the minipage results in an infinite loop as soon as I change the width to 50%col (100%col works). 1.4cvs doesn't have any problems at all (apart from the well-known border offsets). With border-offset you mean this 1cm-extra 'linen background' on the left and right border of minipages etc? I wish I knew what code is responsible for that... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: With border-offset you mean this 1cm-extra 'linen background' on the left and right border of minipages etc? I mean basically that the border is off the right screen border for 100% wide minipages/footnotes etc. You have discussed this several times afair. Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:57:22PM +0200, Juergen Spitzmueller wrote: Andre Poenitz wrote: With border-offset you mean this 1cm-extra 'linen background' on the left and right border of minipages etc? I mean basically that the border is off the right screen border for 100% wide minipages/footnotes etc. You have discussed this several times afair. Ah... this one. I think this is the immediate consequence of this extra space inside the inset. I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: I think this is the immediate consequence of this extra space inside the inset. I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Isn't the extra space stored somewhere? IMHO the inset width should be calculated wrt work area with, extra space and paragraph indentation, or is this too complicated? Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 01:14:43PM +0200, Juergen Spitzmueller wrote: Andre Poenitz wrote: I think this is the immediate consequence of this extra space inside the inset. I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Isn't the extra space stored somewhere? IMHO the inset width should be calculated wrt work area with, extra space and paragraph indentation, or is this too complicated? No, the problem is I can't figure out where in the code this extra space gets added. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:56:10PM +0200, Andre Poenitz wrote: I think this is the immediate consequence of this extra space inside the inset. No it's not, it's a consequence of space outside. I wonder how many more times I can explain the problem :/ I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Subtracting leftMargin() value or even PAPER_SIZE is a start ... john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:13:57PM +0200, Andre Poenitz wrote: I think this is the immediate consequence of this extra space inside the inset. I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. No, the problem is I can't figure out where in the code this extra space gets added. The extra left hand space *inside* the inset is LEFT_MARGIN via leftMargin(). But that is irrelevant to the insets bleeding over the right hand side of the screen: no matter what, the inset should fit itself inside the work width. That's a different problem. regards john p.s. xdelimitarea(1) is a great tool for measuring pixels :) -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 02:40:03PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 12:56:10PM +0200, Andre Poenitz wrote: I think this is the immediate consequence of this extra space inside the inset. No it's not, it's a consequence of space outside. I wonder how many more times I can explain the problem :/ I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Subtracting leftMargin() value or even PAPER_SIZE is a start ... leftMargin seems to be the cause. Now, why do we have 190 lines of code to figure out what our left margin looks like? Cant' we just have labels as paragraph properties? [For the dynamic one we'd propably a new dialog to edit them, but judging from the existence of 'Paragraph::beginnningOfBody' this might be a good idea... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:04:58PM +0200, Andre Poenitz wrote: Now, why do we have 190 lines of code to figure out what our left margin looks like? Isn't it fun. Cant' we just have labels as paragraph properties? If we're talking what things should be, labels should be an inset. [For the dynamic one we'd propably a new dialog to edit them, but This is a horrible idea IMO. Dialogs suck. I thought you agreed with that. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:19:29PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 04:04:58PM +0200, Andre Poenitz wrote: Now, why do we have 190 lines of code to figure out what our left margin looks like? Isn't it fun. Cant' we just have labels as paragraph properties? If we're talking what things should be, labels should be an inset. [For the dynamic one we'd propably a new dialog to edit them, but This is a horrible idea IMO. Dialogs suck. I thought you agreed with that. IN general yes. But what kind of editing mechanism would you propose for paragraph labels. floating text inset? (simple, but unusal) Text inset fixed to the first position of par? (not so simple, but more similar to current fisrt word is label hack) [If that were mathed I'd simply use something similar to MathFrameBoxInset, but I am pretty sure people won't like it (actually, even I don't like it...)] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:26:34PM +0200, Andre Poenitz wrote: floating text inset? (simple, but unusal) Floating ? Text inset fixed to the first position of par? (not so simple, but more similar to current fisrt word is label hack) A proper layout engine indeed is not simple (at least, not starting from where we are now). But it's the right way. And I woon't agree with a usability-harming hack approach instead of that. So frankly I think we must live with this horrific label code until such a time they can be implemented as frames/insets properly. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
Andre Poenitz wrote: But what kind of editing mechanism would you propose for paragraph labels. e.g list \items? floating text inset? (simple, but unusal) what's that? Text inset fixed to the first position of par? (not so simple, but more similar to current fisrt word is label hack) This is an evil hack and should go IMHO. [If that were mathed I'd simply use something similar to MathFrameBoxInset, but I am pretty sure people won't like it (actually, even I don't like it...)] Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:43:36PM +0200, Juergen Spitzmueller wrote: Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). I don't see any good reason to have any different user-visible behaviour whatsoever regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:36:00PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 04:26:34PM +0200, Andre Poenitz wrote: floating text inset? (simple, but unusal) Floating ? within the paragraph. Much like InsetOptional. Text inset fixed to the first position of par? (not so simple, but more similar to current fisrt word is label hack) A proper layout engine indeed is not simple (at least, not starting from where we are now). But it's the right way. And I woon't agree with a usability-harming hack approach instead of that. So frankly I think we must live with this horrific label code until such a time they can be implemented as frames/insets properly. With the 'much like InsetOptional' approach we could have 'labels as insets' in an hour or so. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre With the 'much like InsetOptional' approach we could have Andre 'labels as insets' in an hour or so. I can believe that. But it would be crappy ;) JMarc
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:49:16PM +0200, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre With the 'much like InsetOptional' approach we could have Andre 'labels as insets' in an hour or so. I can believe that. But it would be crappy ;) Code-wise certainly not. Optically probably yes, but that'd just mean we need to come up with some generic solutions for 'things at the begin of a paragraph' some day. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre == Andre Poenitz [EMAIL PROTECTED] writes: I can believe that. But it would be crappy ;) Andre Code-wise certainly not. Sure... Andre Optically probably yes, but that'd just mean we need to come up Andre with some generic solutions for 'things at the begin of a Andre paragraph' some day. Or not put in paragraphs things that do not belong there. This means reimplementing (but in a nice way) the bibitem inset that you scrapped. Actually, fixing the bibitem may be a good playground for testing solutions. JMarc
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:43:25PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 04:43:36PM +0200, Juergen Spitzmueller wrote: Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). I don't see any good reason to have any different user-visible behaviour whatsoever For short ERT and \label, 'inline editing' would be beneficial as well. So arguable, this is no 'different user-visible behaviour' but rather some kind of inset that's not yet implemented. Sort of a InsetText wrapper 'thinner than InsetCollapsable'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:12:26PM +0200, Andre Poenitz wrote: For short ERT and \label, 'inline editing' would be beneficial as well. I don't see the relevance... we have inline editing for ERT as it is. So arguable, this is no 'different user-visible behaviour' but rather some kind of inset that's not yet implemented. Simple test: if the user can't tell the label is implemented in terms of an inset, it's not different. Else it is. No argument to be had ... Sort of a InsetText wrapper 'thinner than InsetCollapsable'. Yes, would be nice. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:22:34PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 05:12:26PM +0200, Andre Poenitz wrote: For short ERT and \label, 'inline editing' would be beneficial as well. I don't see the relevance... we have inline editing for ERT as it is. Huch? By 'inline' I do not mean 'create something fancy as wide as the full screen'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
John Levon wrote: Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). I don't see any good reason to have any different user-visible behaviour whatsoever I haven't said that it has to be yet another inset apperance. ERT inlined is there and would be o.k. for starters. Though I think that the inlined inset look and feel can be improved. I don't use mathed that often, but for my taste the inlined formula inset feels better than the ert inline inset. Can't the latter gain from the former, or perhaps it can even be unified to an InsetInlined? Juergen.
Re: On screen (inset) update
Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
I can believe that. But it would be crappy ;)
Andre Code-wise certainly not.
Sure...
Andre Optically probably yes, but that'd just mean we need to come
up Andre with some generic solutions for 'things at the begin of a
Andre paragraph' some day.
Or not put in paragraphs things that do not belong there. This means
reimplementing (but in a nice way) the bibitem inset that you
scrapped. Actually, fixing the bibitem may be a good playground for
testing solutions.
Jean-Marc, are you describing something along the lines of:
class Paragraph {
std::listitems things_at_the_front;
ParagraphContents the_main_text;
std::listitems things_at_the_end;
}
Obviously, the names are arbitrary...
--
Angus
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:48:03PM +0200, Juergen Spitzmueller wrote: John Levon wrote: Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). I don't see any good reason to have any different user-visible behaviour whatsoever I haven't said that it has to be yet another inset apperance. ERT inlined is there and would be o.k. for starters. Though I think that the inlined inset look and feel can be improved. I don't use mathed that often, but for my taste the inlined formula inset feels better than the ert inline inset. Can't the latter gain from the former, or perhaps it can even be unified to an InsetInlined? Do I smell a volunteer for the Great Inset Unification? Seriously, Math Rest do not fit well together.. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:32:39PM +0200, Andre Poenitz wrote: By 'inline' I do not mean 'create something fancy as wide as the full screen'. And ERT in inline mode is not something fancy and it doesn't take up the full screen john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
Andre Poenitz wrote: Do I smell a volunteer for the Great Inset Unification? No. Seriously, Math Rest do not fit well together.. OK. But this doesn't mean that the ert inlined inset (as a general inlined inset) could behave more like the math inline inset ui-wise. Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:48:53PM +0100, John Levon wrote: On Mon, Aug 04, 2003 at 05:32:39PM +0200, Andre Poenitz wrote: By 'inline' I do not mean 'create something fancy as wide as the full screen'. And ERT in inline mode is not something fancy and it doesn't take up the full screen And how do I edit inlined ERT? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 06:05:36PM +0200, Juergen Spitzmueller wrote: Andre Poenitz wrote: Do I smell a volunteer for the Great Inset Unification? No. Seriously, Math Rest do not fit well together.. OK. But this doesn't mean that the ert inlined inset (as a general inlined inset) could behave more like the math inline inset ui-wise. They could. And probably even should. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: OK. But this doesn't mean that the ert inlined inset (as a general inlined inset) could behave more like the math inline inset ui-wise. They could. And probably even should. That's all I wanted to say. And that such an inset could be used for list labels and stuff. Much better than yet another collapsable or button-dialog IMO. Juergen.
Re: On screen (inset) update
Andre Poenitz wrote: And how do I edit inlined ERT? Are you shure you have already detected inlined ERT? (hint: right mouse click on ert button) Juergen.
Re: On screen (inset) update
Juergen Spitzmueller wrote: Are you shure before Kuba jumps in: I have already noticed it ;-) Juergen.
On screen (inset) update
Take this as a positive feedback on the ongoing update work: I have a minipage with lot of cruft (ert etc.) in it. In 1.3cvs, trying to uncollapse the minipage results in an infinite loop as soon as I change the width to 50%col (100%col works). 1.4cvs doesn't have any problems at all (apart from the well-known border offsets). Seems like the rewrite is beginning to pay off. Good work! Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:16:48PM +0200, Juergen Spitzmueller wrote: > Take this as a positive feedback on the ongoing update work: Thanks ;-) > I have a minipage with lot of cruft (ert etc.) in it. In 1.3cvs, trying to > uncollapse the minipage results in an infinite loop as soon as I change the > width to 50%col (100%col works). > 1.4cvs doesn't have any problems at all (apart from the well-known border > offsets). With border-offset you mean this 1cm-extra 'linen background' on the left and right border of minipages etc? I wish I knew what code is responsible for that... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: > With border-offset you mean this 1cm-extra 'linen background' on the > left and right border of minipages etc? I mean basically that the border is off the right screen border for 100% wide minipages/footnotes etc. You have discussed this several times afair. Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:57:22PM +0200, Juergen Spitzmueller wrote: > Andre Poenitz wrote: > > With border-offset you mean this 1cm-extra 'linen background' on the > > left and right border of minipages etc? > > I mean basically that the border is off the right screen border for 100% wide > minipages/footnotes etc. You have discussed this several times afair. Ah... this one. I think this is the immediate consequence of this extra space inside the inset. I could simply remove a few pixel from the text width to get the ~100% cases right, but that would not be a proper fix. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: > I think this is the immediate consequence of this extra space inside the > inset. I could simply remove a few pixel from the text width to get the > ~100% cases right, but that would not be a proper fix. Isn't the extra space stored somewhere? IMHO the inset width should be calculated wrt work area with, extra space and paragraph indentation, or is this too complicated? Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 01:14:43PM +0200, Juergen Spitzmueller wrote: > Andre Poenitz wrote: > > I think this is the immediate consequence of this extra space inside the > > inset. I could simply remove a few pixel from the text width to get the > > ~100% cases right, but that would not be a proper fix. > > Isn't the extra space stored somewhere? IMHO the inset width should be > calculated wrt work area with, extra space and paragraph indentation, or is > this too complicated? No, the problem is I can't figure out where in the code this extra space gets added. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 12:56:10PM +0200, Andre Poenitz wrote: > I think this is the immediate consequence of this extra space inside the > inset. No it's not, it's a consequence of space outside. I wonder how many more times I can explain the problem :/ > I could simply remove a few pixel from the text width to get the > ~100% cases right, but that would not be a proper fix. Subtracting leftMargin() value or even PAPER_SIZE is a start ... john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:13:57PM +0200, Andre Poenitz wrote: > > > I think this is the immediate consequence of this extra space inside the > > > inset. I could simply remove a few pixel from the text width to get the > > > ~100% cases right, but that would not be a proper fix. > > No, the problem is I can't figure out where in the code this extra space > gets added. The extra left hand space *inside* the inset is LEFT_MARGIN via leftMargin(). But that is irrelevant to the insets bleeding over the right hand side of the screen: no matter what, the inset should fit itself inside the work width. That's a different problem. regards john p.s. xdelimitarea(1) is a great tool for measuring pixels :) -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 02:40:03PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 12:56:10PM +0200, Andre Poenitz wrote: > > > I think this is the immediate consequence of this extra space inside the > > inset. > > No it's not, it's a consequence of space outside. > > I wonder how many more times I can explain the problem :/ > > > I could simply remove a few pixel from the text width to get the > > ~100% cases right, but that would not be a proper fix. > > Subtracting leftMargin() value or even PAPER_SIZE is a start ... leftMargin seems to be the cause. Now, why do we have 190 lines of code to figure out what our left margin looks like? Cant' we just have labels as paragraph properties? [For the dynamic one we'd propably a new dialog to edit them, but judging from the existence of 'Paragraph::beginnningOfBody' this might be a good idea... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:04:58PM +0200, Andre Poenitz wrote: > Now, why do we have 190 lines of code to figure out what our left > margin looks like? Isn't it fun. > Cant' we just have labels as paragraph properties? If we're talking what things should be, labels should be an inset. > [For the dynamic one we'd propably a new dialog to edit them, but This is a horrible idea IMO. Dialogs suck. I thought you agreed with that. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:19:29PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 04:04:58PM +0200, Andre Poenitz wrote: > > > Now, why do we have 190 lines of code to figure out what our left > > margin looks like? > > Isn't it fun. > > > Cant' we just have labels as paragraph properties? > > If we're talking what things should be, labels should be an inset. > > > [For the dynamic one we'd propably a new dialog to edit them, but > > This is a horrible idea IMO. Dialogs suck. I thought you agreed with > that. IN general yes. But what kind of editing mechanism would you propose for "paragraph labels". "floating text inset"? (simple, but "unusal") Text inset fixed to the first position of par? (not so simple, but more similar to current "fisrt word is label" hack) [If that were mathed I'd simply use something similar to MathFrameBoxInset, but I am pretty sure people won't like it (actually, even I don't like it...)] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:26:34PM +0200, Andre Poenitz wrote: > "floating text inset"? (simple, but "unusal") Floating ? > Text inset fixed to the first position of par? (not so simple, but more > similar to current "fisrt word is label" hack) A proper layout engine indeed is not simple (at least, not starting from where we are now). But it's the right way. And I woon't agree with a usability-harming hack approach instead of that. So frankly I think we must live with this horrific label code until such a time they can be implemented as frames/insets properly. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
Andre Poenitz wrote: > But what kind of editing mechanism would you propose for > "paragraph labels". e.g list \items? > "floating text inset"? (simple, but "unusal") what's that? > Text inset fixed to the first position of par? (not so simple, but more > similar to current "fisrt word is label" hack) This is an evil hack and should go IMHO. > [If that were mathed I'd simply use something similar to > MathFrameBoxInset, but I am pretty sure people won't like it > (actually, even I don't like it...)] Actually, for labels I'd prefer something like that (something like an inlined inset with a frame that is drawn when the cursor is inside and can be escaped with the tab key). Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:43:36PM +0200, Juergen Spitzmueller wrote: > Actually, for labels I'd prefer something like that (something like an inlined > inset with a frame that is drawn when the cursor is inside and can be escaped > with the tab key). I don't see any good reason to have any different user-visible behaviour whatsoever regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:36:00PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 04:26:34PM +0200, Andre Poenitz wrote: > > > "floating text inset"? (simple, but "unusal") > > Floating ? within the paragraph. Much like InsetOptional. > > Text inset fixed to the first position of par? (not so simple, but more > > similar to current "fisrt word is label" hack) > > A proper layout engine indeed is not simple (at least, not starting from > where we are now). But it's the right way. And I woon't agree with a > usability-harming hack approach instead of that. > > So frankly I think we must live with this horrific label code until such > a time they can be implemented as frames/insets properly. With the 'much like InsetOptional' approach we could have 'labels as insets' in an hour or so. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> With the 'much like InsetOptional' approach we could have Andre> 'labels as insets' in an hour or so. I can believe that. But it would be crappy ;) JMarc
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:49:16PM +0200, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> With the 'much like InsetOptional' approach we could have > Andre> 'labels as insets' in an hour or so. > > I can believe that. But it would be crappy ;) Code-wise certainly not. Optically probably yes, but that'd just mean we need to come up with some generic solutions for 'things at the begin of a paragraph' some day. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> I can believe that. But it would be crappy ;) Andre> Code-wise certainly not. Sure... Andre> Optically probably yes, but that'd just mean we need to come up Andre> with some generic solutions for 'things at the begin of a Andre> paragraph' some day. Or not put in paragraphs things that do not belong there. This means reimplementing (but in a nice way) the bibitem inset that you scrapped. Actually, fixing the bibitem may be a good playground for testing solutions. JMarc
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 03:43:25PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 04:43:36PM +0200, Juergen Spitzmueller wrote: > > > Actually, for labels I'd prefer something like that (something like an inlined > > inset with a frame that is drawn when the cursor is inside and can be escaped > > with the tab key). > > I don't see any good reason to have any different user-visible behaviour > whatsoever For short ERT and \label, 'inline editing' would be beneficial as well. So arguable, this is no 'different user-visible behaviour' but rather some kind of inset that's not yet implemented. Sort of a InsetText wrapper 'thinner than InsetCollapsable'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:12:26PM +0200, Andre Poenitz wrote: > For short ERT and \label, 'inline editing' would be beneficial as well. I don't see the relevance... we have inline editing for ERT as it is. > So arguable, this is no 'different user-visible behaviour' but rather > some kind of inset that's not yet implemented. Simple test: if the user can't tell the label is implemented in terms of an inset, it's not different. Else it is. No argument to be had ... > Sort of a InsetText wrapper 'thinner than InsetCollapsable'. Yes, would be nice. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:22:34PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 05:12:26PM +0200, Andre Poenitz wrote: > > > For short ERT and \label, 'inline editing' would be beneficial as well. > > I don't see the relevance... we have inline editing for ERT as it is. Huch? By 'inline' I do not mean 'create something fancy as wide as the full screen'. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
John Levon wrote: > > Actually, for labels I'd prefer something like that (something like an > > inlined inset with a frame that is drawn when the cursor is inside and > > can be escaped with the tab key). > > I don't see any good reason to have any different user-visible behaviour > whatsoever I haven't said that it has to be yet another inset apperance. ERT inlined is there and would be o.k. for starters. Though I think that the inlined inset "look and feel" can be improved. I don't use mathed that often, but for my taste the "inlined formula" inset "feels" better than the ert inline inset. Can't the latter gain from the former, or perhaps it can even be unified to an InsetInlined? Juergen.
Re: On screen (inset) update
Jean-Marc Lasgouttes wrote:
>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
>>> I can believe that. But it would be crappy ;)
>
> Andre> Code-wise certainly not.
>
> Sure...
>
> Andre> Optically probably yes, but that'd just mean we need to come
> up Andre> with some generic solutions for 'things at the begin of a
> Andre> paragraph' some day.
>
> Or not put in paragraphs things that do not belong there. This means
> reimplementing (but in a nice way) the bibitem inset that you
> scrapped. Actually, fixing the bibitem may be a good playground for
> testing solutions.
Jean-Marc, are you describing something along the lines of:
class Paragraph {
std::list things_at_the_front;
ParagraphContents the_main_text;
std::list things_at_the_end;
}
Obviously, the names are arbitrary...
--
Angus
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:48:03PM +0200, Juergen Spitzmueller wrote: > John Levon wrote: > > > Actually, for labels I'd prefer something like that (something like an > > > inlined inset with a frame that is drawn when the cursor is inside and > > > can be escaped with the tab key). > > > > I don't see any good reason to have any different user-visible behaviour > > whatsoever > > I haven't said that it has to be yet another inset apperance. ERT inlined is > there and would be o.k. for starters. Though I think that the inlined inset > "look and feel" can be improved. I don't use mathed that often, but for my > taste the "inlined formula" inset "feels" better than the ert inline inset. > Can't the latter gain from the former, or perhaps it can even be unified to > an InsetInlined? Do I smell a volunteer for the Great Inset Unification? Seriously, Math & Rest do not fit well together.. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 05:32:39PM +0200, Andre Poenitz wrote: > By 'inline' I do not mean 'create something fancy as wide as the full > screen'. And ERT in inline mode is not something fancy and it doesn't take up the full screen john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: On screen (inset) update
Andre Poenitz wrote: > Do I smell a volunteer for the Great Inset Unification? No. > Seriously, Math & Rest do not fit well together.. OK. But this doesn't mean that the ert inlined inset (as a general inlined inset) could behave more like the math inline inset ui-wise. Juergen.
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 04:48:53PM +0100, John Levon wrote: > On Mon, Aug 04, 2003 at 05:32:39PM +0200, Andre Poenitz wrote: > > > By 'inline' I do not mean 'create something fancy as wide as the full > > screen'. > > And ERT in inline mode is not something fancy and it doesn't take up the > full screen And how do I edit inlined ERT? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
On Mon, Aug 04, 2003 at 06:05:36PM +0200, Juergen Spitzmueller wrote: > Andre Poenitz wrote: > > Do I smell a volunteer for the Great Inset Unification? > > No. > > > Seriously, Math & Rest do not fit well together.. > > OK. But this doesn't mean that the ert inlined inset (as a general inlined > inset) could behave more like the math inline inset ui-wise. They could. And probably even should. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: On screen (inset) update
Andre Poenitz wrote: > > OK. But this doesn't mean that the ert inlined inset (as a general > > inlined inset) could behave more like the math inline inset ui-wise. > > They could. And probably even should. That's all I wanted to say. And that such an inset could be used for list labels and stuff. Much better than yet another collapsable or button-dialog IMO. Juergen.
Re: On screen (inset) update
Andre Poenitz wrote: > And how do I edit inlined ERT? Are you shure you have already detected inlined ERT? (hint: right mouse click on ert button) Juergen.
Re: On screen (inset) update
Juergen Spitzmueller wrote: > Are you shure before Kuba jumps in: I have already noticed it ;-) Juergen.
Re: Inset::update()
On Tue, Jun 03, 2003 at 08:48:33AM +0200, Andre Poenitz wrote: The attached patch basically disables Inset::update() and yet the sky does not fall on our heads. There are some glitches in the table drawing (I've seen diagonal(!) lines once) and somehow everything is left-aligned there but nested minipages etc seem flawlessly. actually this sounds pretty much like the sky went into freefall ... actually fixing these bugs is probably extremely difficult. i.e. if we're going to do this I'd want it to be all working /before/ any commits. (And I can help with that wherever I can ...) john
Re: Inset::update()
On Tue, Jun 03, 2003 at 08:48:33AM +0200, Andre Poenitz wrote: > The attached patch basically disables Inset::update() and yet the sky > does not fall on our heads. > > There are some glitches in the table drawing (I've seen diagonal(!) lines > once) and somehow everything is left-aligned there but nested minipages etc > seem flawlessly. actually this sounds pretty much like the sky went into freefall ... actually fixing these bugs is probably extremely difficult. i.e. if we're going to do this I'd want it to be all working /before/ any commits. (And I can help with that wherever I can ...) john
Inset::update()
... could die.
The attached patch basically disables Inset::update() and yet the sky
does not fall on our heads.
There are some glitches in the table drawing (I've seen diagonal(!) lines
once) and somehow everything is left-aligned there but nested minipages etc
seem flawlessly.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.18
diff -u -p -r1.18 rowpainter.C
--- rowpainter.C30 May 2003 06:48:20 - 1.18
+++ rowpainter.C3 Jun 2003 06:42:42 -
@@ -105,7 +105,12 @@ void RowPainter::paintInset(pos_type con
lyx::Assert(inset);
#warning inset-update FIXME
- inset-update(perv(bv_), false);
+ //inset-update(perv(bv_), false);
+ MetricsInfo mi;
+ mi.base.bv = perv(bv_);
+ mi.base.font = getFont(pos);
+ Dimension dim;
+ inset-metrics(mi, dim);
PainterInfo pi(perv(bv_));
pi.base.font = getFont(pos);
@@ -291,8 +296,6 @@ void RowPainter::paintFromPos(pos_type
}
paintForeignMark(orig_x, orig_font);
-
- return;
}
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.365
diff -u -p -r1.365 text.C
--- text.C 28 May 2003 16:36:53 - 1.365
+++ text.C 3 Jun 2003 06:42:43 -
@@ -310,7 +310,7 @@ int LyXText::singleWidth(ParagraphList::
// this IS needed otherwise on initialitation we don't get the
fill
// of the row right (ONLY on initialization if we read a file!)
// should be changed! (Jug 20011204)
- tmpinset-update(bv());
+ //tmpinset-update(bv());
#endif
return tmpinset-width(bv(), font);
}
@@ -1071,7 +1071,7 @@ void LyXText::setHeightOfRow(RowList::it
if (tmpinset) {
#if 1 // this is needed for deep update on initialitation
#warning inset-update FIXME
- tmpinset-update(bv());
+ //tmpinset-update(bv());
#endif
maxwidth += tmpinset-width(bv(), tmpfont);
maxasc = max(maxasc,
Index: frontends/font_metrics.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/font_metrics.h,v
retrieving revision 1.6
diff -u -p -r1.6 font_metrics.h
--- frontends/font_metrics.h1 Dec 2002 22:59:18 - 1.6
+++ frontends/font_metrics.h3 Jun 2003 06:42:43 -
@@ -16,6 +16,7 @@
#include LString.h
class LyXFont;
+class Dimension;
/**
* A namespace holding helper functions for determining
@@ -55,6 +56,10 @@ namespace font_metrics {
int rbearing(char c, LyXFont const f);
/// return the width of the string in the font
int width(char const * s, size_t n, LyXFont const f);
+ /// dimension of string
+ void dim(string const s, LyXFont const f, Dimension dim);
+ /// dimension of string
+ void dim(char c, LyXFont const f, Dimension dim);
/// return the width of the char in the font
inline int width(char c, LyXFont const f) {
return width(c, 1, f);
Index: insets/inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.98
diff -u -p -r1.98 inset.h
--- insets/inset.h 2 Jun 2003 16:14:33 - 1.98
+++ insets/inset.h 3 Jun 2003 06:42:43 -
@@ -161,8 +161,8 @@ public:
///
int width(BufferView *, LyXFont const ) const;
/// update the inset representation
- virtual void update(BufferView *, bool = false)
- {}
+ //virtual void update(BufferView *, bool = false)
+ // {}
/// what appears in the minibuffer when opening
virtual string const editMessage() const;
///
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.147
diff -u -p -r1.147 insetcollapsable.C
--- insets/insetcollapsable.C 2 Jun 2003 10:03:22 - 1.147
+++ insets/insetcollapsable.C 3 Jun 2003 06:42:43 -
@@ -285,7 +285,7 @@ int InsetCollapsable::docbook(Buffer con
return inset.docbook(buf, os, mixcont);
}
-
+/*
void InsetCollapsable::update(BufferView * bv, bool reinit)
{
if (in_update) {
@@ -301,6 +301,7 @@ void InsetCollapsable::update(BufferView
Re: Inset::update()
On Tue, Jun 03, 2003 at 08:48:33AM +0200, Andre' Poenitz wrote: ... could die. The attached patch basically disables Inset::update() and yet the sky does not fall on our heads. There are some glitches in the table drawing (I've seen diagonal(!) lines once) and somehow everything is left-aligned there but nested minipages etc seem flawlessly. Grr... the patch I posted contains a bit more than necessary, I'll re-do it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Inset::update()
... could die.
The attached patch basically disables Inset::update() and yet the sky
does not fall on our heads.
There are some glitches in the table drawing (I've seen diagonal(!) lines
once) and somehow everything is left-aligned there but nested minipages etc
seem flawlessly.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.18
diff -u -p -r1.18 rowpainter.C
--- rowpainter.C30 May 2003 06:48:20 - 1.18
+++ rowpainter.C3 Jun 2003 06:42:42 -
@@ -105,7 +105,12 @@ void RowPainter::paintInset(pos_type con
lyx::Assert(inset);
#warning inset->update FIXME
- inset->update(perv(bv_), false);
+ //inset->update(perv(bv_), false);
+ MetricsInfo mi;
+ mi.base.bv = perv(bv_);
+ mi.base.font = getFont(pos);
+ Dimension dim;
+ inset->metrics(mi, dim);
PainterInfo pi(perv(bv_));
pi.base.font = getFont(pos);
@@ -291,8 +296,6 @@ void RowPainter::paintFromPos(pos_type &
}
paintForeignMark(orig_x, orig_font);
-
- return;
}
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.365
diff -u -p -r1.365 text.C
--- text.C 28 May 2003 16:36:53 - 1.365
+++ text.C 3 Jun 2003 06:42:43 -
@@ -310,7 +310,7 @@ int LyXText::singleWidth(ParagraphList::
// this IS needed otherwise on initialitation we don't get the
fill
// of the row right (ONLY on initialization if we read a file!)
// should be changed! (Jug 20011204)
- tmpinset->update(bv());
+ //tmpinset->update(bv());
#endif
return tmpinset->width(bv(), font);
}
@@ -1071,7 +1071,7 @@ void LyXText::setHeightOfRow(RowList::it
if (tmpinset) {
#if 1 // this is needed for deep update on initialitation
#warning inset->update FIXME
- tmpinset->update(bv());
+ //tmpinset->update(bv());
#endif
maxwidth += tmpinset->width(bv(), tmpfont);
maxasc = max(maxasc,
Index: frontends/font_metrics.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/font_metrics.h,v
retrieving revision 1.6
diff -u -p -r1.6 font_metrics.h
--- frontends/font_metrics.h1 Dec 2002 22:59:18 - 1.6
+++ frontends/font_metrics.h3 Jun 2003 06:42:43 -
@@ -16,6 +16,7 @@
#include "LString.h"
class LyXFont;
+class Dimension;
/**
* A namespace holding helper functions for determining
@@ -55,6 +56,10 @@ namespace font_metrics {
int rbearing(char c, LyXFont const & f);
/// return the width of the string in the font
int width(char const * s, size_t n, LyXFont const & f);
+ /// dimension of string
+ void dim(string const & s, LyXFont const & f, Dimension & dim);
+ /// dimension of string
+ void dim(char c, LyXFont const & f, Dimension & dim);
/// return the width of the char in the font
inline int width(char c, LyXFont const & f) {
return width(, 1, f);
Index: insets/inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.98
diff -u -p -r1.98 inset.h
--- insets/inset.h 2 Jun 2003 16:14:33 - 1.98
+++ insets/inset.h 3 Jun 2003 06:42:43 -
@@ -161,8 +161,8 @@ public:
///
int width(BufferView *, LyXFont const &) const;
/// update the inset representation
- virtual void update(BufferView *, bool = false)
- {}
+ //virtual void update(BufferView *, bool = false)
+ // {}
/// what appears in the minibuffer when opening
virtual string const editMessage() const;
///
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.147
diff -u -p -r1.147 insetcollapsable.C
--- insets/insetcollapsable.C 2 Jun 2003 10:03:22 - 1.147
+++ insets/insetcollapsable.C 3 Jun 2003 06:42:43 -
@@ -285,7 +285,7 @@ int InsetCollapsable::docbook(Buffer con
return inset.docbook(buf, os, mixcont);
}
-
+/*
void InsetCollapsable::update(BufferView * bv,
Re: Inset::update()
On Tue, Jun 03, 2003 at 08:48:33AM +0200, Andre' Poenitz wrote: > ... could die. > > The attached patch basically disables Inset::update() and yet the sky > does not fall on our heads. > > There are some glitches in the table drawing (I've seen diagonal(!) lines > once) and somehow everything is left-aligned there but nested minipages etc > seem flawlessly. Grr... the patch I posted contains a bit more than necessary, I'll re-do it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [PATCH] fix some inset-in-inset update problems
On 05-Dec-2001 Allan Rae wrote: The insets allocated memory is at the same place isn't it? Wouldn't a signal connection be sufficient? Or a table of waiting-insets and the process they are waiting for a (UNIX) signal from? The signal stuff would be a good way to eliminate the use of a owner_ pointer. If a child changes it just has to signal it to it's owner. I find this a good and easy enough solution ;) Allan. (ARRae)I love stacks. Well I really cannot follow all your cursor and stack and the lot discussion, it seems very complicated only from reading your mail. But I'm sure when you implemted it it will be quite easy to handle thereafter ;) Anyway I love other things much more then stacks #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I'm a Lisp variable -- bind me!
Re: [PATCH] fix some inset-in-inset update problems
On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote: Anyway I love other things much more then stacks #:O) Shouldn't this depend on you position in the stack? Andre', just thinking... -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On Wed, 5 Dec 2001, Andre Poenitz wrote: On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote: Anyway I love other things much more then stacks #:O) Shouldn't this depend on you position in the stack? Andre', just thinking... And nobody said there has to be just one stack... Different stacks for different purposes. Allan. (ARRae)
Re: [PATCH] fix some inset-in-inset update problems
On 05-Dec-2001 Allan Rae wrote: > The insets allocated memory is at the same place isn't it? Wouldn't a > signal connection be sufficient? Or a table of waiting-insets and the > process they are waiting for a (UNIX) signal from? The signal stuff would be a good way to eliminate the use of a owner_ pointer. If a child changes it just has to signal it to it's owner. I find this a good and easy enough solution ;) > Allan. (ARRae)I love stacks. Well I really cannot follow all your cursor and stack and the lot discussion, it seems very complicated only from reading your mail. But I'm sure when you implemted it it will be quite easy to handle thereafter ;) Anyway I love "other" things much more then stacks #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I'm a Lisp variable -- bind me!
Re: [PATCH] fix some inset-in-inset update problems
On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote: > Anyway I love "other" things much more then stacks #:O) Shouldn't this depend on you position in the stack? Andre', just thinking... -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On Wed, 5 Dec 2001, Andre Poenitz wrote: > On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote: > > Anyway I love "other" things much more then stacks #:O) > > Shouldn't this depend on you position in the stack? > > Andre', just thinking... And nobody said there has to be just one stack... Different stacks for different purposes. Allan. (ARRae)
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: So you are saying that setUpdateStatus(NONE) indicates that no update has been done so a FULL update is needed? Nope! NONE just gives the minimal amount of Update I envise for this call. Then setUpdateStatus has to decide if we need more than this minimal amount. So if the change in LyXText was minimal we probably will have only a CURSOR_PAR, if the change was mayor (a break in a row) then we would have FULL, but if we didn't have ANY change then the update would be NONE. Obviously we could put the code if lt-status() == NEED_VERY_LITTLE_REFRESH then setUpdateStatus(CURSOR_PAR) else if lt-status() == NEED_MORE_REFRESH then setUpdateStatus(FULL) else setUpdateStatus(myminimal_status) everywhere we call that function but I really don't see the point of enlarging the code with duplicates. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Play Rogue, visit exotic locations, meet strange creatures and kill them.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: Or are you just thinking of insettabular and the no-mans-land between the cells? Then an insettabular::iterator should handle those more obtuse actions. If you have two cursors with one set to the first pos of an inset and the second set to the end of the same inset haven't you just selected the whole inset? So why do you need a no-mans-land to mark a whole inset? It seems to me you all hide your head in the sand ;) What about this: blah blah |[inset1] blah blah blah blah [inset2] blah blah blah. Now an insetgraphics inside [inset2] is requesing an update because it finished rendering. I don't see any cursor near [inset2], do you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Is death legally binding?
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Andre Poenitz wrote: Honour to whom honour is true: The concept is from the math cursor first implemented by Alejandro. And even after the rework, the math cursor does exactly this: Hold two stacks of cursor positions (one for the cursor, one for the selection anchor), each position is a triplet of values: (pointer to an inset, cell number of the inset, offset in that cell) Well honor whoever you want, but I would say that a text with a 1000's of lines and I don't know how much insets is a bit more complicated than a single line math inset, don't you? Anyway I already pointed out that maybe we can do without the owner_ of an inset, but we have to rewrite just some code which right now IS working. So you surely won't have 1.2.0 out in 2004 would you? Jug P.S.: maybe means that I may see an option but I'm not at all sure it will work! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The time is right to make new friends.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: Then we should only need to use the same two cursors to do anything. The second one only needed for selections. We don't the stuff is a bit more complicated when updates and redraws are involved. But I would say if you know all of it why don't you start coding and so you can proove us that you're right. I would surely be happy about that! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 09:38:02AM +0100, Juergen Vigna wrote: Now an insetgraphics inside [inset2] is requesing an update because it finished rendering. I don't see any cursor near [inset2], do you? Inset rendering is a bit special, it's the only case of asynchronous operation, isn't it? What about giving the I am done call back of the inset rendering a snapshot copy of the cursor from the moment where the inset is created and rendering started? Anre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 09:42:52AM +0100, Juergen Vigna wrote: Well honor whoever you want, but I would say that a text with a 1000's of lines and I don't know how much insets is a bit more complicated than a single line math inset, don't you? No. What is the problem with the concept of a list of paragraphs, each holding a list of rows, each with some characters or nested insets? The only problem I see is some implementation that makes things complicated. Hand wired paragraph lists etc. No need to feel offended I am not blaming anybody here, most of the stuff seems to be in from the very beginning. I see quite a few parallels between math cells and paragraph rows and math inset and paragraph. Anyway I already pointed out that maybe we can do without the owner_ of an inset, but we have to rewrite just some code which right now IS working. So you surely won't have 1.2.0 out in 2004 would you? I am not talking about 1.2. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Andre Poenitz wrote: Inset rendering is a bit special, it's the only case of asynchronous operation, isn't it? Well, ... What about giving the I am done call back of the inset rendering a snapshot copy of the cursor from the moment where the inset is created and rendering started? And what if the inset-pointer changed in the meantime (Undo/Redo)? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Whoever dies with the most toys wins.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Andre Poenitz wrote: I am not talking about 1.2. Well let's say that we agree that we could change something in the logic in the future (and I'm not sure it will be in 1.3 as I really would like to have the main-view GUIIfied in 1.3, some added features but nothing which redoes a lot of code. We HAVE to finish GUII as fast as possible IMO. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ That's life. What's life? A magazine. How much does it cost? Two-fifty. I only have a dollar. That's life.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Juergen Vigna wrote: And what if the inset-pointer changed in the meantime (Undo/Redo)? No IMO that theLockingInset() stuff is pretty good and easy. It only goes one direction and is only there if we really enter an inset. We could do it with the cursor, but IMO we would add complex handling not remove it. While the above update has nothing to do with neighter cursor nor theLockingInset() we just have to have a good iterator and we'll find the inset which want's to be updated quite fast! Anyway the update/redraw process has do go from the outermost inset to the innermost inset and back again and we have this more or less already BufferView::updateInset(inset-to-update), the theLockingInset mechanism is IMO only a shortcut as 98% of the update stuff (or more) most probably will occur in the spot where we're actually editing. So IMO we won't need any complicated cursor as we don't have to know the outer inset if we access the whole stuff from the right direction. Much of the code there was written long time ago and build up on each other. The whole Inset hierarchy has to be rethought, as I already pointed out with my mail about the need of a ContainerInset. But as I also said before I don't see this done neighter in 1.2 nor in 1.3 as I see other priorities. I think that this should be done after we have GUII finished as then we also have a cleaner base to build on and redo this old code. I hope we agree all that GUII should have precedence in 1.3 and that we shouldn't wait another 3 year for the 1.3 release, but it should go out quite fast. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I'd never join any club that would have the likes of me as a member. -- Groucho Marx
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 10:35:23AM +0100, Juergen Vigna wrote: On 04-Dec-2001 Andre Poenitz wrote: Inset rendering is a bit special, it's the only case of asynchronous operation, isn't it? Well, ... What about giving the I am done call back of the inset rendering a snapshot copy of the cursor from the moment where the inset is created and rendering started? And what if the inset-pointer changed in the meantime (Undo/Redo)? If the paragraph is still there, the pointer should not have changed, since it is still the same thing, should it? But since you are asking I suppose the pointer may change indeed. Well, there are other solutions: We will need a method to create a cursor stack from (x,y) coordinates anyway, since people want to put the cursor somewhere by clicking with the mouse. So we could recreate the cursor from some cached inset position. If that has changed, we could redraw everything on screen - I doubt that one has more that a few graphic insets on one _screen_. Or we could ignore the matter altogether and force a complete redraw of the full screen every second or so... How expensive is a full screen redraw anyway? Does is justify all the code used to figure out whether we need very little or just a little redraw? If a complete redraw takes less than 0.05 second, we could scrap the complicated parts of the redrawing entirely and nobody will notice. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote: Well let's say that we agree that we could change something in the logic in the future (and I'm not sure it will be in 1.3 as I really would like to have the main-view GUIIfied in 1.3, some added features but nothing which redoes a lot of code. We HAVE to finish GUII as fast as possible IMO. Depends on the cycle length. If it takes several years again... ;-} Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Andre Poenitz wrote: On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote: Well let's say that we agree that we could change something in the logic in the future (and I'm not sure it will be in 1.3 as I really would like to have the main-view GUIIfied in 1.3, some added features but nothing which redoes a lot of code. We HAVE to finish GUII as fast as possible IMO. Depends on the cycle length. If it takes several years again... ;-} Well it took several years BECAUSE we changed some important stuff in the core. If we refrain from doing that in the 1.3 cycle and concentrate ONLY on the points we want to realize then IMO we could do it quite fast! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You look tired.
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote: Well let's say that we agree that we could change something in the logic in the future (and I'm not sure it will be in 1.3 as I really would like to have the main-view GUIIfied in 1.3, some added features but nothing which redoes a lot of code. We HAVE to finish GUII as fast as possible IMO. violently agree here, as do the utilitarianists ;) john -- Faced with the prospect of rereading this book, I would rather have my brains ripped out by a plastic fork. - Charles Cooper on Business at the Speed of Thought
Re: [PATCH] fix some inset-in-inset update problems
On Tue, 4 Dec 2001, Juergen Vigna wrote: On 04-Dec-2001 Allan Rae wrote: Then we should only need to use the same two cursors to do anything. The second one only needed for selections. We don't the stuff is a bit more complicated when updates and redraws are involved. But I would say if you know all of it why don't you start coding and so you can proove us that you're right. I would surely be happy about that! I guess from this you are referring to the need to know which parts of the document are visible -- that is, which _rows_ are visible. Do we need a cursor for that? Maybe I'm just being pedantic but while we could use the Cursor class needed to make selections to mark the limits of visible rows they aren't user-visible or user-interactive cursors. Anyway, it seems we might need perhaps 5 cursors in total. The two user-visible I mentioned originally, the two for marking visible boundaries and another for iterating through the visible area for updating. These are document global (stored in BufferView or should it be LyXText?) and passed down the inset hierarchy as needed. There shouldn't really be any need for an inset to maintain its own cursor -- there will certainly need to be an iterator added to the cursor stack when an inset-in-an-inset is encountered but that is the document-global cursor. So does this sound more complete or do you see a need yet another cursor somewhere? Allan. (ARRae)
Re: [PATCH] fix some inset-in-inset update problems
On Tue, 4 Dec 2001, Juergen Vigna wrote: On 04-Dec-2001 Juergen Vigna wrote: And what if the inset-pointer changed in the meantime (Undo/Redo)? The insets allocated memory is at the same place isn't it? Wouldn't a signal connection be sufficient? Or a table of waiting-insets and the process they are waiting for a (UNIX) signal from? No IMO that theLockingInset() stuff is pretty good and easy. It only goes one direction and is only there if we really enter an inset. We could do it with the cursor, but IMO we would add complex handling not remove it. While the above update has nothing to do with neighter cursor nor theLockingInset() we just have to have a good iterator and we'll find the inset which want's to be updated quite fast! I wrote the fastest inset finder/iterator in the universe a few years ago based on a signal. But that was overkill. Anyway the update/redraw process has do go from the outermost inset to the innermost inset and back again and we have this more or less already BufferView::updateInset(inset-to-update), the theLockingInset mechanism is IMO only a shortcut as 98% of the update stuff (or more) most probably will occur in the spot where we're actually editing. 98%, so you agree that most stuff happens at the cursor. It seems that InsetGraphics is the only example anyone has offered So IMO we won't need any complicated cursor as we don't have to know the outer inset if we access the whole stuff from the right direction. Much of the code there was written long time ago and build up on each other. The whole Inset hierarchy has to be rethought, as I already pointed out with my mail about the need of a ContainerInset. Sure and we are influencing how that Inset hierarchy rethink might go by discussing new ways of maintaining positions (cursors). But as I also said before I don't see this done neighter in 1.2 nor in 1.3 as I see other priorities. I think that this should be done after we have GUII finished as then we also have a cleaner base to build on and redo this old code. I hope we agree all that GUII should have precedence in 1.3 and that we shouldn't wait another 3 year for the 1.3 release, but it should go out quite fast. I don't think anyone will have a problem with this. There is no need to rush to switch to stacked cursors. The current code is sufficient for the time being. But as the inset heirarchy is rethought yet further the possibility of revising cursor operation should not be overlooked. Allan. (ARRae)I love stacks.
Re: [PATCH] fix some inset-in-inset update problems
On Wed, Dec 05, 2001 at 12:24:53PM +1000, Allan Rae wrote: I guess from this you are referring to the need to know which parts of the document are visible -- that is, which _rows_ are visible. Do we need a cursor for that? No. A full redraw could start searching the cursor path towards the root of the inset tree (and the full document should be an inset, too, btw.) until it find an inset that claim to cover all of the user visible screen. This could be the big document inset, but this could be a large figure or table cell, too. This inset is asked to redraw the region (and this process recursively descends into contained insets etc). And if needed, this drawing is the second stage in a two stage process, with the first stage building caches of size information of the insets. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: > So you are saying that setUpdateStatus(NONE) indicates that no update > has been done so a FULL update is needed? Nope! NONE just gives the minimal amount of Update I envise for this call. Then setUpdateStatus has to decide if we need more than this minimal amount. So if the change in LyXText was minimal we probably will have only a CURSOR_PAR, if the change was mayor (a break in a row) then we would have FULL, but if we didn't have ANY change then the update would be NONE. Obviously we could put the code if lt->status() == NEED_VERY_LITTLE_REFRESH then setUpdateStatus(CURSOR_PAR) else if lt->status() == NEED_MORE_REFRESH then setUpdateStatus(FULL) else setUpdateStatus(myminimal_status) everywhere we call that function but I really don't see the point of enlarging the code with duplicates. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Play Rogue, visit exotic locations, meet strange creatures and kill them.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: > Or are you just thinking of insettabular and the no-mans-land between > the cells? Then an insettabular::iterator should handle those more > obtuse actions. If you have two cursors with one set to the first pos > of an inset and the second set to the end of the same inset haven't > you just selected the whole inset? So why do you need a no-mans-land > to mark a whole inset? It seems to me you all hide your head in the sand ;) What about this: blah blah |[inset1] blah blah blah blah [inset2] blah blah blah. Now an insetgraphics inside [inset2] is requesing an update because it finished rendering. I don't see any cursor near [inset2], do you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Is death legally binding?
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Andre Poenitz wrote: > Honour to whom honour is true: The concept is from the math cursor first > implemented by Alejandro. And even after the rework, the math cursor does > exactly this: Hold two stacks of "cursor positions" (one for the cursor, > one for the selection anchor), each position is a triplet of values: > (pointer to an inset, cell number of the inset, offset in that cell) Well honor whoever you want, but I would say that a text with a 1000's of lines and I don't know how much insets is a bit more complicated than a single line math inset, don't you? Anyway I already pointed out that "maybe" we can do without the owner_ of an inset, but we have to rewrite just some code which right now IS working. So you surely won't have 1.2.0 out in 2004 would you? Jug P.S.: "maybe" means that I may see an option but I'm not at all sure it will work! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The time is right to make new friends.
Re: [PATCH] fix some inset-in-inset update problems
On 04-Dec-2001 Allan Rae wrote: > Then we should only need to use the same two cursors to do anything. > The second one only needed for selections. We don't the stuff is a bit more complicated when updates and redraws are involved. But I would say if you know all of it why don't you start coding and so you can proove us that you're right. I would surely be happy about that! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. -- Mark Twain
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 09:38:02AM +0100, Juergen Vigna wrote: > Now an insetgraphics inside [inset2] is requesing an update because > it finished rendering. I don't see any cursor near [inset2], do you? Inset rendering is a bit special, it's the only case of asynchronous operation, isn't it? What about giving the "I am done" call back of the inset rendering a snapshot copy of the cursor from the moment where the inset is created and rendering started? Anre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [PATCH] fix some inset-in-inset update problems
On Tue, Dec 04, 2001 at 09:42:52AM +0100, Juergen Vigna wrote: > Well honor whoever you want, but I would say that a text with a 1000's of > lines and I don't know how much insets is a bit more complicated than > a single line math inset, don't you? No. What is the problem with the concept of a list of paragraphs, each holding a list of rows, each with some characters or nested insets? The only problem I see is some implementation that makes things complicated. "Hand wired" paragraph lists etc. No need to feel offended I am not blaming anybody here, most of the stuff seems to be in from the very beginning. I see quite a few parallels between "math cells" and "paragraph rows" and "math inset" and "paragraph". > Anyway I already pointed out that "maybe" we can do without the owner_ > of an inset, but we have to rewrite just some code which right now IS > working. So you surely won't have 1.2.0 out in 2004 would you? I am not talking about 1.2. Andre' -- André Pönitz .. [EMAIL PROTECTED]
