Re: CharStyle discussion
On Mon, Dec 08, 2003 at 02:08:03PM -0500, Kuba Ober wrote: Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have bold on and bold off flags. This does not work well with user defined styles and we don't have the memory to associate each individual character with arbitrary data. 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: CharStyle discussion
On Tue, Dec 09, 2003 at 08:18:34AM +0100, Andre Poenitz spake thusly: On Mon, Dec 08, 2003 at 02:08:03PM -0500, Kuba Ober wrote: Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have bold on and bold off flags. This does not work well with user defined styles and we don't have the memory to associate each individual character with arbitrary data. Andre' Actually I don't think that's the way it would be done. I did study the possibility to implement charstyles as ranges after John wrote his write-up, and came to the conclusion that indeed it would be doable in this way using mostly the existing char attribute infrastructure. The only thing to store for a character belonging to a charstyle would be a number pointer to an entry in the textclass'es charstyle list. (User-definable charstyles would complicate this a little, but not much.) In this approach, an LCS would be kept separately from the physical char attributes, but be merged with them at some suitable point using the realize() method to get the display font. This means that every LCS would consist of a bit pattern of physical character attributes. It would certainly have worked, but LCS's would not be nestable/overlappable, i.e., a character could only belong to one at a time. Not a real limitation IMHO. Still I like the inset approach more. - Martin pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Mon, 8 Dec 2003, Andre Poenitz wrote: On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' I'm using Sawfish, and I've got that function bound to S-M-Left. and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' Sorry, I haven't seen this function though... It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) Those corners are nice... which reminds me, do you remember that problem with extra space after the math-inset (the one where the extra space made you think that there was a real space, and then at the printout you got stuff like in this formula C=2you have) Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... I'm not sure if I was clear enough, but I was worried that we might get into similar problems if we put a box around something that's in emaphasis for instance. This holds for a novel or such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Now I'm confused... I don't write novels, but I am a book-aholic, and there's quite often markup (italics, bold etc) even in them. Some modern novels look awful due to too much markup btw. The average novel I read is just flat text with a heading every 20 pages or so. Oh come on, I'm sure you'll find italics more often than every 20 pages ;) Anyway, to illustrate what I mean, look at this link: http://www.baen.com/chapters/W29/0671319590___2.htm The first italic word is in the 4th paragraph, and the next in the 5th, and then in the 7th. Anyway, this markup would show up as boxes wouldn't it? Yes. (and thus possibly impede the writer of that text). Of course, this will only be an example of something annoying if the emphasis is highlighted using boxes in LyX. Additionally, any distraction is considerably reduced if the box is only shown when the cursor is actually inside such a box (when the cursor is outside the emphasized text, that text is only shown as in italics). Somewhat related... if someone says something, like in the 9th paragraph Ah, there, Little Bite! is this something that would end up as a character style, i.e. as a style indicating that this is something that is said. (If it is, then any dialog will be swamped with this kind of character style). You lost me. If too much markup in a novel annoys you, so why do you try to use 'people need lots of markup in novels' as an argument? Sorry, I should have said bad typography... the example I was thinking of used lots of different fonts AND font sizes - urk! /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Tue, Dec 09, 2003 at 02:46:35PM +0100, Christian Ridderström wrote: On Mon, 8 Dec 2003, Andre Poenitz wrote: On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' I'm using Sawfish, and I've got that function bound to S-M-Left. and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' Sorry, I haven't seen this function though... In Fvwm2 it's: Key LeftA M Scroll -100 +0 Key LeftA SM CursorMove -1 +0 Key LeftA C CursorMove -50 +0 (50 is 'half a screen'). Pretty covienient if you use X as an 'xterm multiplexer' with 4 xterms per virtual screen (or two long ones...) Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... I'm not sure if I was clear enough, but I was worried that we might get into similar problems if we put a box around something that's in emaphasis for instance. Probably. But the pink corners could overlap to the outside instead of requiring additional space Anyway, to illustrate what I mean, look at this link: http://www.baen.com/chapters/W29/0671319590___2.htm The first italic word is in the 4th paragraph, and the next in the 5th, and then in the 7th. So we have less than one box per paragraph. Doesn't sound overly complicated... Andre'
Re: CharStyle discussion
On Tue, 9 Dec 2003, Andre Poenitz wrote: Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... I'm not sure if I was clear enough, but I was worried that we might get into similar problems if we put a box around something that's in emaphasis for instance. Probably. But the pink corners could overlap to the outside instead of requiring additional space Do you mean that the corners would written 'on top' of the surrounding text? (Is that possible using the Qt and Xforms frontend btw?) Anyway, to illustrate what I mean, look at this link: http://www.baen.com/chapters/W29/0671319590___2.htm The first italic word is in the 4th paragraph, and the next in the 5th, and then in the 7th. So we have less than one box per paragraph. Doesn't sound overly complicated... Are you trying to be difficult on purpose here? You ignore the change in magnitude of how often it occurs (once every 20 pages to a few times per page), and also the case of dialogs? If you are dead-set on using boxes, just say so ... /Christian (getting tired of this thread) -- Dr. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: CharStyle discussion
On Tue, Dec 09, 2003 at 03:41:47PM +0100, Christian Ridderström wrote: On Tue, 9 Dec 2003, Andre Poenitz wrote: Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... I'm not sure if I was clear enough, but I was worried that we might get into similar problems if we put a box around something that's in emaphasis for instance. Probably. But the pink corners could overlap to the outside instead of requiring additional space Do you mean that the corners would written 'on top' of the surrounding text? (Is that possible using the Qt and Xforms frontend btw?) This would be a possibility for the boxes containing the cursor. This means we wouldn't get this annoying gap. It is currently not possible, but should not be too hard to implement. Anyway, to illustrate what I mean, look at this link: http://www.baen.com/chapters/W29/0671319590___2.htm The first italic word is in the 4th paragraph, and the next in the 5th, and then in the 7th. So we have less than one box per paragraph. Doesn't sound overly complicated... Are you trying to be difficult on purpose here? Not at all. The typical novel I read comes on dead trees and does not have font changes every second paragraph... /Christian (getting tired of this thread) So stop it. Andre'
Re: CharStyle discussion
On Mon, Dec 08, 2003 at 02:08:03PM -0500, Kuba Ober wrote: > Oh yes, then certainly it will work like that. Another way of doing it is > instead of having character style insets just have character style flags and > have the core do the job. I.e. have "bold on" and "bold off" flags. This does not work well with user defined styles and we don't have the memory to associate each individual character with arbitrary data. 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: CharStyle discussion
On Tue, Dec 09, 2003 at 08:18:34AM +0100, Andre Poenitz spake thusly: > On Mon, Dec 08, 2003 at 02:08:03PM -0500, Kuba Ober wrote: > > Oh yes, then certainly it will work like that. Another way of doing it is > > instead of having character style insets just have character style flags and > > have the core do the job. I.e. have "bold on" and "bold off" flags. > > This does not work well with user defined styles and we don't have the > memory to associate each individual character with arbitrary data. > > Andre' Actually I don't think that's the way it would be done. I did study the possibility to implement charstyles as ranges after John wrote his write-up, and came to the conclusion that indeed it would be doable in this way using mostly the existing char attribute infrastructure. The only thing to store for a character belonging to a charstyle would be a number pointer to an entry in the textclass'es charstyle list. (User-definable charstyles would complicate this a little, but not much.) In this approach, an LCS would be kept separately from the physical char attributes, but be merged with them at some suitable point using the realize() method to get the display font. This means that every LCS would consist of a bit pattern of physical character attributes. It would certainly have worked, but LCS's would not be nestable/overlappable, i.e., a character could only belong to one at a time. Not a real limitation IMHO. Still I like the inset approach more. - Martin pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Mon, 8 Dec 2003, Andre Poenitz wrote: > On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: > > > > You need to fix your window manager? SCNR > > > > > > Indeed. Save a few small changes I use the same configuration as 14 > > > years ago. > > > > ok... and all new WM features since then are just crap? ;) > > Maybe it's just their documentation. > > For one, I've not yet figured out how to bind e.g. > > 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' I'm using Sawfish, and I've got that function bound to S-M-Left. > and > > 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, > going to the next screen to the left when necessary' Sorry, I haven't seen this function though... > > > It could be made less intrusive like the pink corners of the math boxes > > > (instead of a 'solid' box...) > > > > Those corners are nice... which reminds me, do you remember that problem > > with extra space after the math-inset (the one where the extra space made > > you think that there was a real space, and then at the printout you got > > stuff like "in this formula C=2you have") > > Yes, I run into this regularly myself. But that's just the usual 2 point > box space acculmulated by nested boxes... Maybe going down to 1 would > help already... I'm not sure if I was clear enough, but I was worried that we might get into similar problems if we put a box around something that's in emaphasis for instance. > > > This holds for a novel or such, but even the random science paper has > > > structure. And, btw, if you only have flat text you'll never see a box > > > even with all-boxes. > > > > Now I'm confused... I don't write novels, but I am a book-aholic, and > > there's quite often markup (italics, bold etc) even in them. Some modern > > novels look awful due to too much markup btw. > > The average novel I read is just flat text with a heading every 20 > pages or so. Oh come on, I'm sure you'll find italics more often than every 20 pages ;) Anyway, to illustrate what I mean, look at this link: http://www.baen.com/chapters/W29/0671319590___2.htm The first italic word is in the 4th paragraph, and the next in the 5th, and then in the 7th. > > Anyway, this markup would show up as boxes wouldn't it? > > Yes. > > > (and thus possibly impede the writer of that text). Of course, this will only be an example of something annoying if the emphasis is highlighted using boxes in LyX. Additionally, any distraction is considerably reduced if the box is only shown when the cursor is actually inside such a box (when the cursor is outside the emphasized text, that text is only shown as in italics). Somewhat related... if someone says something, like in the 9th paragraph "Ah, there, Little Bite!" is this something that would end up as a character style, i.e. as a style indicating that this is something that is said. (If it is, then any dialog will be swamped with this kind of character style). > You lost me. If too much markup in a novel annoys you, so why do you > try to use 'people need lots of markup in novels' as an argument? Sorry, I should have said bad typography... the example I was thinking of used lots of different fonts AND font sizes - urk! /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Tue, Dec 09, 2003 at 02:46:35PM +0100, Christian Ridderström wrote: > On Mon, 8 Dec 2003, Andre Poenitz wrote: > > > On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: > > > > > You need to fix your window manager? SCNR > > > > > > > > Indeed. Save a few small changes I use the same configuration as 14 > > > > years ago. > > > > > > ok... and all new WM features since then are just crap? ;) > > > > Maybe it's just their documentation. > > > > For one, I've not yet figured out how to bind e.g. > > > > 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' > > I'm using Sawfish, and I've got that function bound to S-M-Left. > > > and > > > > 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, > > going to the next screen to the left when necessary' > > Sorry, I haven't seen this function though... In Fvwm2 it's: Key LeftA M Scroll -100 +0 Key LeftA SM CursorMove -1 +0 Key LeftA C CursorMove -50 +0 (50 is 'half a screen'). Pretty covienient if you use X as an 'xterm multiplexer' with 4 xterms per virtual screen (or two long ones...) > > Yes, I run into this regularly myself. But that's just the usual 2 point > > box space acculmulated by nested boxes... Maybe going down to 1 would > > help already... > > I'm not sure if I was clear enough, but I was worried that we might get > into similar problems if we put a box around something that's in > emaphasis for instance. Probably. But the pink corners could overlap to the outside instead of requiring additional space > Anyway, to illustrate what I mean, look at this link: > http://www.baen.com/chapters/W29/0671319590___2.htm > > The first italic word is in the 4th paragraph, and the next in the 5th, > and then in the 7th. So we have less than one box per paragraph. Doesn't sound overly complicated... Andre'
Re: CharStyle discussion
On Tue, 9 Dec 2003, Andre Poenitz wrote: > > > Yes, I run into this regularly myself. But that's just the usual 2 point > > > box space acculmulated by nested boxes... Maybe going down to 1 would > > > help already... > > > > I'm not sure if I was clear enough, but I was worried that we might get > > into similar problems if we put a box around something that's in > > emaphasis for instance. > > Probably. But the pink corners could overlap to the outside instead of > requiring additional space Do you mean that the corners would written 'on top' of the surrounding text? (Is that possible using the Qt and Xforms frontend btw?) > > Anyway, to illustrate what I mean, look at this link: > > http://www.baen.com/chapters/W29/0671319590___2.htm > > > > The first italic word is in the 4th paragraph, and the next in the 5th, > > and then in the 7th. > > So we have less than one box per paragraph. Doesn't sound overly > complicated... > Are you trying to be difficult on purpose here? You ignore the change in magnitude of how often it occurs (once every 20 pages to a few times per page), and also the case of dialogs? If you are dead-set on using boxes, just say so ... /Christian (getting tired of this thread) -- Dr. Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: CharStyle discussion
On Tue, Dec 09, 2003 at 03:41:47PM +0100, Christian Ridderström wrote: > On Tue, 9 Dec 2003, Andre Poenitz wrote: > > > > > Yes, I run into this regularly myself. But that's just the usual 2 point > > > > box space acculmulated by nested boxes... Maybe going down to 1 would > > > > help already... > > > > > > I'm not sure if I was clear enough, but I was worried that we might get > > > into similar problems if we put a box around something that's in > > > emaphasis for instance. > > > > Probably. But the pink corners could overlap to the outside instead of > > requiring additional space > > Do you mean that the corners would written 'on top' of the > surrounding text? (Is that possible using the Qt and Xforms frontend btw?) This would be a possibility for the boxes containing the cursor. This means we wouldn't get this annoying gap. It is currently not possible, but should not be too hard to implement. > > > Anyway, to illustrate what I mean, look at this link: > > > http://www.baen.com/chapters/W29/0671319590___2.htm > > > > > > The first italic word is in the 4th paragraph, and the next in the 5th, > > > and then in the 7th. > > > > So we have less than one box per paragraph. Doesn't sound overly > > complicated... > > Are you trying to be difficult on purpose here? Not at all. The typical novel I read comes on dead trees and does not have font changes every second paragraph... > /Christian (getting tired of this thread) So stop it. Andre'
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' in either KDE or Gnome. I even asked on usenet... It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) Those corners are nice... which reminds me, do you remember that problem with extra space after the math-inset (the one where the extra space made you think that there was a real space, and then at the printout you got stuff like in this formula C=2you have) Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... Well, it's not easy to know if it's too much or not. That's one reason I think it would be good to be able to switch between modes... for that matter different people probably have different thresholds. Too much choice is bad as well. This holds for a novel or such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Now I'm confused... I don't write novels, but I am a book-aholic, and there's quite often markup (italics, bold etc) even in them. Some modern novels look awful due to too much markup btw. The average novel I read is just flat text with a heading every 20 pages or so. Anyway, this markup would show up as boxes wouldn't it? Yes. (and thus possibly impede the writer of that text). You lost me. If too much markup in a novel annoys you, so why do you try to use 'people need lots of markup in novels' as an argument? Andre'
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller wrote: Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. The main problem is the 20 pixel room for the [ nesting markers (which won't be needed in all-boxes btw) Andre'
Re: CharStyle discussion
On Sunday 07 December 2003 06:53 am, you wrote: On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Well, there is the point that a quotation occationally will contain a few short paragraphs, so using the paragraph end as a limit won't work well. People do select two and a half paragraph in order to apply a style. Perhaps not often, but it do happen. It is nice if it works, even if the code have to create several insets for the multiple paragraphs. Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have bold on and bold off flags. Obviously their manipulation will need some equilibristic skills. I guess that implementation with insets is just plain easier, and making the insets behave to the user as expected should involve less work than keeping state of the flags sprinkled around the text. Kuba
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: > > > You need to fix your window manager? SCNR > > > > Indeed. Save a few small changes I use the same configuration as 14 > > years ago. > > ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' in either KDE or Gnome. I even asked on usenet... > > It could be made less intrusive like the pink corners of the math boxes > > (instead of a 'solid' box...) > > Those corners are nice... which reminds me, do you remember that problem > with extra space after the math-inset (the one where the extra space made > you think that there was a real space, and then at the printout you got > stuff like "in this formula C=2you have") Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... > Well, it's not easy to know if it's too much or not. That's one reason I > think it would be good to be able to switch between modes... for that > matter different people probably have different thresholds. Too much choice is bad as well. > > This holds for a novel or such, but even the random science paper has > > structure. And, btw, if you only have flat text you'll never see a box > > even with all-boxes. > > Now I'm confused... I don't write novels, but I am a book-aholic, and > there's quite often markup (italics, bold etc) even in them. Some modern > novels look awful due to too much markup btw. The average novel I read is just flat text with a heading every 20 pages or so. > Anyway, this markup would show up as boxes wouldn't it? Yes. > (and thus possibly impede the writer of that text). You lost me. If too much markup in a novel annoys you, so why do you try to use 'people need lots of markup in novels' as an argument? Andre'
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: > > BTW is it possible to get rid of the space at the beginning of a char style > > inset? > > Apparently this has more than one source. One part of the problem is that the > insettext inside the inset has indended paragraph if the document uses > paragraph indendation. The main problem is the 20 pixel room for the [ nesting markers (which won't be needed in all-boxes btw) Andre'
Re: CharStyle discussion
On Sunday 07 December 2003 06:53 am, you wrote: > On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: > > There will also be some constraints as to how far a character style can > > go. I imagine we will artificially need to terminate all character > > styling at the end of the paragraph, otherwise it'll be an uncontainable > > mess. This may actually make sense for logical formatting - typically, > > you're making a word/sentence bolded, not the whole document; if it's the > > whole document you should adjust the default paragraph style properties > > (in LyX's case it would be more like document properties). > > > > I haven't read the whole thread yet, so if my points have already been > > raised, feel free to ignore me :) > > Well, there is the point that a quotation occationally will contain a few > short paragraphs, so using the paragraph end as a limit won't work well. > > People do select "two and a half" paragraph in order to apply a style. > Perhaps not often, but it do happen. It is nice if it works, even if > the code have to create several insets for the multiple paragraphs. Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have "bold on" and "bold off" flags. Obviously their manipulation will need some equilibristic skills. I guess that implementation with insets is just plain easier, and making the insets behave to the user as "expected" should involve less work than keeping state of the flags sprinkled around the text. Kuba
Re: CharStyle discussion
On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Well, there is the point that a quotation occationally will contain a few short paragraphs, so using the paragraph end as a limit won't work well. People do select two and a half paragraph in order to apply a style. Perhaps not often, but it do happen. It is nice if it works, even if the code have to create several insets for the multiple paragraphs. If you can select something, then you can cut/paste it. It'd be nice if styles always will apply too. Helge Hafting
Re: CharStyle discussion
On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: > There will also be some constraints as to how far a character style can go. I > imagine we will artificially need to terminate all character styling at the > end of the paragraph, otherwise it'll be an uncontainable mess. This may > actually make sense for logical formatting - typically, you're making a > word/sentence bolded, not the whole document; if it's the whole document you > should adjust the default paragraph style properties (in LyX's case it would > be more like document properties). > > I haven't read the whole thread yet, so if my points have already been raised, > feel free to ignore me :) Well, there is the point that a quotation occationally will contain a few short paragraphs, so using the paragraph end as a limit won't work well. People do select "two and a half" paragraph in order to apply a style. Perhaps not often, but it do happen. It is nice if it works, even if the code have to create several insets for the multiple paragraphs. If you can select something, then you can cut/paste it. It'd be nice if styles always will apply too. Helge Hafting
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:54:58PM +0200, Martin Vermeer spake thusly: Patch attached. As I haven't heard any real objections (just blue-sky ideas building on it) I'll commit later today. Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Martin Vermeer wrote: Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. Looks very promising! I found one bug though. Special characters are not escaped inside the char style (I have tested noun). Type \today inside noun (not in ert) and you'll see what I mean. Jürgen BTW is it possible to get rid of the space at the beginning of a char style inset?
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. Jürgen
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 02:46:15PM +0100, Andre Poenitz wrote:
On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote:
Note: Isn't it overkill drawing something that's emphasized using a box
AND (e.g.) italics? We don't want to flood the user with visual info.
Interesting point. Hm, maybe. Maybe not, though...
Lyx knows that bold/italic/font/size/color shows visually, so not drawing
a box for those is possible. A language change or a user supplied
style (using \userunknownmarkup{}) could get a box/frame since there is no
way to distinguish it from other text.
There is also the option of light gray frames that aren't so striking.
They are weaker than the black text and therefore won't interfere much with reading.
Helge Hafting
Re: CharStyle discussion
Insets are an appropriate means for structured editing but they are not suitable for writing consecutive text. If I had had to insert an inset for every emphasized term, for every capitalized product name, for every keyword in typewriter font, and for every figure reference in sans serif in my PhD, I would have jumped out of the window!!! I guess one should keep in mind that insets are 99% programming paradigms, and only about 1% user-visible things. User has no concept of an inset. It all boils down to making the interface to creating such character-style insets an easy one. In such a case we have two possible behaviours: 1. MicroPro WordStar (last time I used it on a CP/M machine in mid-80's) approach: all formatting is an invisible character, so both bold on and bold off is an invisible character, and you can both delete it and you have to jump over it with arrow cursors if say you're moving cursor in the text with arrows (^S/^D for left/right anyone? :). Apparently, thousands of users found that acceptable and this is directly modeled by right arrow only enters the inset, but it makes some problems with backspace -- essentially a backspace at the bold end character did expand the bold all the way to end of paragraph or somesuch, whereas in our case it would delete the whole inset. Not a nice thing. It may not be such a great idea nowadays methinks. 2. Your average editor approach - insets or whatever implements character styles are invisible. Backspace just outside of the right end of a bold inset should automatically enter the inset and then perform the action of backspace. I find that 2 is widely accepted nowadays. Implementation-wise I imagine that character-style insets are OK as long as certain things done just outside of both ends of the inset (say backspace on the right, delete on the left) first enter the inset and then feed-forward the action to the inset itself. There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Cheers, Kuba
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller spake thusly: Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. That is not the reason here. Irritating isn't it? Jürgen - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:54:58PM +0200, Martin Vermeer spake thusly: > Patch attached. As I haven't heard any real objections (just blue-sky > ideas building on it) I'll commit later today. Committed. I fixed one more bug: now the labelfont definition is actually used for the label (blue default font for all styles; twice reduced). Also the underline (now having two little end hooks) takes the label's colour. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Martin Vermeer wrote: > Committed. I fixed one more bug: now the labelfont definition is > actually used for the label (blue default font for all styles; twice > reduced). Also the underline (now having two little end hooks) takes > the label's colour. Looks very promising! I found one bug though. Special characters are not escaped inside the char style (I have tested noun). Type \today inside noun (not in ert) and you'll see what I mean. Jürgen BTW is it possible to get rid of the space at the beginning of a char style inset?
Re: [Patch] Re: [Patch] Re: CharStyle discussion
Juergen Spitzmueller wrote: > BTW is it possible to get rid of the space at the beginning of a char style > inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. Jürgen
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 02:46:15PM +0100, Andre Poenitz wrote:
> On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote:
>
> > Note: Isn't it overkill drawing something that's emphasized using a box
> > AND (e.g.) italics? We don't want to flood the user with visual info.
>
> Interesting point. Hm, maybe. Maybe not, though...
>
Lyx knows that bold/italic/font/size/color shows visually, so not drawing
a box for those is possible. A language change or a user supplied
style (using \userunknownmarkup{}) could get a box/frame since there is no
way to distinguish it from other text.
There is also the option of light gray frames that aren't so striking.
They are weaker than the black text and therefore won't interfere much with reading.
Helge Hafting
Re: CharStyle discussion
> Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!! I guess one should keep in mind that insets are 99% programming paradigms, and only about 1% user-visible things. User has no concept of an inset. It all boils down to making the interface to creating such character-style insets an easy one. In such a case we have two possible behaviours: 1. MicroPro WordStar (last time I used it on a CP/M machine in mid-80's) approach: all formatting is an invisible character, so both "bold on" and "bold off" is an invisible character, and you can both delete it and you have to "jump over" it with arrow cursors if say you're moving cursor in the text with arrows (^S/^D for left/right anyone? :). Apparently, thousands of users found that acceptable and this is directly modeled by "right arrow only enters the inset", but it makes some problems with backspace -- essentially a backspace at the "bold end" character did expand the "bold" all the way to end of paragraph or somesuch, whereas in our case it would delete the whole inset. Not a nice thing. It may not be such a great idea nowadays methinks. 2. Your average editor approach - "insets" or whatever implements character styles are invisible. Backspace just outside of the right end of a "bold" inset should automatically enter the inset and then perform the action of backspace. I find that "2" is widely accepted nowadays. Implementation-wise I imagine that character-style insets are OK as long as certain things done just outside of both ends of the inset (say backspace on the right, delete on the left) first enter the inset and then feed-forward the action to the inset itself. There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Cheers, Kuba
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller spake thusly: > > Juergen Spitzmueller wrote: > > BTW is it possible to get rid of the space at the beginning of a char style > > inset? > > Apparently this has more than one source. One part of the problem is that the > insettext inside the inset has indended paragraph if the document uses > paragraph indendation. That is not the reason here. Irritating isn't it? > Jürgen - Martin pgp0.pgp Description: PGP signature
[Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake thusly:
I tightened up the thing a little bit. The patch is attached.
I think this is such a clear improvement on what we had, that this
should go in as it stands, despite small quirks (which I am not even
sure have to do with the patch). I think we have at least the right
visual model now.
- Martin
Here's a slightly improved patch. Less quirks (And this time I
remembered the .h file :-)
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C5 Dec 2003 07:01:30 -
@@ -25,6 +25,8 @@
#include metricsinfo.h
#include paragraph.h
+#include frontends/font_metrics.h
+#include frontends/Painter.h
#include support/std_sstream.h
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName(CharStyle);
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs-name;
params_.latextype = cs-latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,41 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const buf, LyXLex lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = Style: + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
+void InsetCharStyle::draw(PainterInfo pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ inset.draw(pi, x, y);
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w), y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +135,19 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const cmd,
idx_type idx, pos_type pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ break;
+ default:
+ return InsetCollapsable::priv_dispatch(cmd, idx, pos);
+ }
}
Index: insetcharstyle.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.h,v
retrieving revision 1.2
diff -u -p -r1.2 insetcharstyle.h
--- insetcharstyle.h1 Dec 2003 16:01:50 - 1.2
+++ insetcharstyle.h5 Dec 2003 07:01:30 -
@@ -60,10 +60,10 @@ public:
///
void read(Buffer const buf, LyXLex lex);
///
- void setButtonLabel();
- ///
void metrics(MetricsInfo , Dimension ) const;
///
+ void draw(PainterInfo , int, int) const;
+ ///
void getDrawFont(LyXFont ) const;
///
int latex(Buffer const , std::ostream ,
@@ -96,6 +96,8 @@ private:
void init();
///
InsetCharStyleParams params_;
+ ///
+ bool has_label_;
};
#endif
pgp0.pgp
Description: PGP signature
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: Dear Martin et al., do you need some more comments? Ok, here are mine :-) Yes, box removing by Backspace is 'direct manipulation' according to this definition. Nobody, not a single person! complained about this since 1.3.0 is out. I am really tempted to call this argument 'FUD'. Personally, I have no problem with this feature. Although I consider myself a power-user, I have never noticed it in mathed. This also means that it has never been an obstacle when writing some formula :-) HOWEVER... and now I will make you very angry ... I don't like the CharStyle inset approach at all - at least in the way it is planned at the moment. Insets are an appropriate means for structured editing but they are not suitable for writing consecutive text. If I had had to insert an inset for every emphasized term, for every capitalized product name, for every keyword in typewriter font, and for every figure reference in sans serif in my PhD, I would have jumped out of the window!!! You have to press C-e for emphasized anyway. Whether the result is realized by an inset or some other structure internally is irrelevant for the users. If the inset is visibly indistinguishable from the current display (which is at least for short stuff possible but requires Asger's three-box-drawing model for long) nobody will notice anyway. The only point to discuss IMO is whether there could/should be two physical cursor positions (boxes/mathed model) or just one (OOo/Word) Personally, having the two logicaly positions (just before some change/at the beginning of a change) is _the_ But instead of starting a discussion on how to display insets in the most comfortable way, we have to clarify the general concepts of character styles first. IMHO there should be no fixed set of char styles. Instead the user should be able to define his own styles and change them later (similar to branches). This, of course, requires additional dialogs, etc. etc. As a first step, reading them from the layout would be ok. Second step is to incorporate '.layout' snippets into the .lyx. Last step is to provide some gui... So... do we really want such a mammoth project while LyX is broken at each corner? This is pretty independent from the core fixes. Last night, I worked four hours on a simple insetcollapsable/insertert code merge just to find out that the crashes I experienced also occur with the latest cvs :-( (The fact that my 1Ghz 128MB computer spent more than half of the time on compiling and swapping did not improve my bad mood). Hm yes. This is still bad and got suddenly worse again a few weeks ago... Shouldn't we concentrate on bug fixing rather than starting new projects? For those people willing and able to work on the core, probably yes. But I don't see a reason why the others should be stopped... Andre'
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 07:14:18PM +0200, Martin Vermeer wrote: Talking about looks, see the attached. Still a bit intrusive ... I need to do some cleaning on the patch still, but this works, and not just sort-of. What is unelegant about it is that it still bases CharStyle on Collapsable, though it is forced permanently into Inlined mode. There should be a way to base it directly off UpdatableInset (right?) but I didn't get anywhere trying. Rather from InsetText. But I think you could leave it as it is for now. Andre'
Re: CharStyle discussion
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Personally, having the two logicaly positions (just before some Andre change/at the beginning of a change) is _the_ _the_ what? We could have a solution where there is only one position in general, but we have a lfun that switches to the other position (when relevant) when needed. Of course there should be some visual indication of what happens. This would be only a power user thing, so it needn't be very discoverable. I did not chime in in the thread between John and Andre, in part because we had a 24h network outage :(. However, I have to say that I am not comfortable with andre's position... I really think that an application should be developed in the UI-to-code direction, and not code-to-UI. Saying that, since a certain data structure is sound then we should use it and then expose it to the user is taking things backward IMO. JMarc
Re: [Patch] Re: CharStyle discussion
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake Martin thusly: I tightened up the thing a little bit. The patch is attached. I think this is such a clear improvement on what we had, that this should go in as it stands, despite small quirks (which I am not even sure have to do with the patch). I think we have at least the right visual model now. Isn't it possible to have this code in InsetCollapsable? My though is that we should try to limit the number of possible appearance of insets rather than have each inset invent something. I think that all insets in inline mode would benefit from this representation (think of ERT). JMarc
Re: [Patch] Re: CharStyle discussion
On Friday 05 December 2003 09:19, Jean-Marc Lasgouttes wrote: I think that all insets in inline mode would benefit from this representation (think of ERT). I agree. JMarc -- José Abílio LyX and docbook, a perfect match. :-)
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:15:10AM +0100, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Personally, having the two logicaly positions (just before some Andre change/at the beginning of a change) is _the_ _the_ what? ... thing that annoys me most in the main text (well, apart from the general lack of easily accessible functions to jump around and SR). And that's not because that's the natural way with the all-boxes approaches but because it's the way I think of the text markup. And not being sure whether I am inside or outside makes me uncomfortable. We could have a solution where there is only one position in general, but we have a lfun that switches to the other position (when relevant) when needed. Of course there should be some visual indication of what happens. This would be only a power user thing, so it needn't be very discoverable. I did not chime in in the thread between John and Andre, in part because we had a 24h network outage :(. However, I have to say that I am not comfortable with andre's position... I know. I really think that an application should be developed in the UI-to-code direction, and not code-to-UI. Saying that, since a certain data structure is sound then we should use it and then expose it to the user is taking things backward IMO. But almost any UI can be provided on top of a flexible data structure. If your data structure is only geared towards a single UI, some UI quirks simply won't be fixable or some features are hard to implement because your data structure does not support 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] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:19:29AM +0100, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake Martin thusly: I tightened up the thing a little bit. The patch is attached. I think this is such a clear improvement on what we had, that this should go in as it stands, despite small quirks (which I am not even sure have to do with the patch). I think we have at least the right visual model now. Isn't it possible to have this code in InsetCollapsable? My though is that we should try to limit the number of possible appearance of insets rather than have each inset invent something. I think we could somehow consolitate InsetText and InsetCollapsable. InsetText is only used in InsetCollapsable and InsetTabular, and InsetTabular should contain LyXTexts rather than InsetTexts... Andre'
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: Dear Martin et al., do you need some more comments? Ok, here are mine :-) box removing by Backspace I find this function _very_ useful in mathed, but difficult to discover :-( Uwe Stöhr has written a manual for mathed (in German), I think we need a manual (in English) for mathed... You have to press C-e for emphasized anyway. Whether the result is realized by an inset or some other structure internally is irrelevant for the users. If the inset is visibly indistinguishable from the current display (which is at least for short stuff possible but requires Asger's three-box-drawing model for long) nobody will notice anyway. The only point to discuss IMO is whether there could/should be two physical cursor positions (boxes/mathed model) or just one (OOo/Word) Personally, having the two logicaly positions (just before some change/at the beginning of a change) is _the_ ?question? Wow... finally a question I understand... IMO, working with text and formulas is quite different with respect to what is the most common cursor movement operation. In formulas, I mostly need fine control of movement, whereas in text I mostly want 'course' control of movement. Perhaps... 'course' movement can be defined as moving between 'content', and 'fine' movment as moving between markup? (Maybe we can even start talking about a content space and a markup space :-) For formulas, I want very fine-grained control of 'where' the cursor is, so the 2-cursor approach is useful, even if it sometimes feels like you are pressing the left/right arrows way to often. For normal text, I think I'd be annoyed if I had to do double 'left's just because I was crossing a markup border. Some ideas out of the blue: * Have a mode setting that controls if movement is course or fine * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' Mathed This would be great in mathed, unfortunately, you probably want -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm stupid, why not change the behaviour of C-Left/C-Right.. at the moment these keys aren't so useful in mathed anyway. But instead of starting a discussion on how to display insets in the most comfortable way How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes Some final thoughts: In mathEd, the 'where' is important -- is the cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? How about a figure float? No... that's not the same as a being in a subscript to me, since the subscript belongs to something. A footnote might belong to something though... bah, this gets too complicated... /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:19:29AM +0100, Jean-Marc Lasgouttes spake thusly:
Isn't it possible to have this code in InsetCollapsable? My though is
that we should try to limit the number of possible appearance of
insets rather than have each inset invent something.
I think that all insets in inline mode would benefit from this
representation (think of ERT).
JMarc
Good idea actually. Especially ERT. Only I don't feel like doing that
right now.
I slightly improved again the patch; now the frame has been replaced
by a blue underline to be less conspicuous. Otherwise the same.
Patch attached. As I haven't heard any real objections (just blue-sky
ideas building on it) I'll commit later today.
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C5 Dec 2003 10:37:43 -
@@ -25,6 +25,8 @@
#include metricsinfo.h
#include paragraph.h
+#include frontends/font_metrics.h
+#include frontends/Painter.h
#include support/std_sstream.h
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName(CharStyle);
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs-name;
params_.latextype = cs-latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,48 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const buf, LyXLex lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = Style: + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
+void InsetCharStyle::draw(PainterInfo pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ inset.setDrawFrame(InsetText::NEVER);
+ inset.draw(pi, x, y);
+
+ pi.pain.line(x + 2, y + inset.descent(), x + dim_.wid - 2,
+ y + inset.descent(), LColor::blue);
+
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w),
+ y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +142,19 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const cmd,
idx_type idx, pos_type pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ break;
+ default:
+ return InsetCollapsable::priv_dispatch(cmd, idx, pos);
+ }
}
Index: insetcharstyle.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.h,v
retrieving revision 1.2
diff -u -p -r1.2 insetcharstyle.h
--- insetcharstyle.h1 Dec 2003 16:01:50 - 1.2
+++ insetcharstyle.h5 Dec 2003 10:37:43 -
@@ -60,10 +60,10 @@ public:
///
void read(Buffer const buf, LyXLex lex);
///
- void setButtonLabel();
- ///
void metrics(MetricsInfo , Dimension ) const;
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström spake thusly: How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes We have that already -- in principle. See insettext.h:44. - Martin pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Fri, 5 Dec 2003, Martin Vermeer wrote: On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström spake thusly: How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes We have that already -- in principle. See insettext.h:44. ... in principle... :-) I take it you mean it shouldn't be too difficult to implement this... But the question is if this something we want? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: On Fri, Dec 05, 2003 at 10:15:10AM +0100, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Personally, having the two logicaly positions (just before some Andre change/at the beginning of a change) is _the_ ... thing that annoys me most in the main text (well, apart from the general lack of easily accessible functions to jump around and SR). You tricky bastard... ;-) I was so sure you meant question that I wrote a long post on that subject... I thought I'd be doing work stuff by now. Instead I'm suddenly caught up in this mail thread, damn you... (hypocritical-smiley) And that's not because that's the natural way with the all-boxes approaches but because it's the way I think of the text markup. And not being sure whether I am inside or outside makes me uncomfortable. Are you thinking of a special situation here? (could you give an example) I remember it being a bit annoying to know where you are when you use C-e, but I couldn't find an example just now. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström wrote: For formulas, I want very fine-grained control of 'where' the cursor is, so the 2-cursor approach is useful, even if it sometimes feels like you are pressing the left/right arrows way to often. For normal text, I think I'd be annoyed if I had to do double 'left's just because I was crossing a markup border. But you'd cross markup borders less often than in math. If you can cope with that in math (i.e. 'words' of typical length 1) you should be able to handle that for phrease of lenght 10 or 20 or so as well. After all the overhead in this case is just 10% or 5% of what you accept in math. Some ideas out of the blue: * Have a mode setting that controls if movement is course or fine * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' M-Left/Right switches virtual screens here. No good. SCNR ;-) Mathed This would be great in mathed, unfortunately, you probably want -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm stupid, why not change the behaviour of C-Left/C-Right.. at the moment these keys aren't so useful in mathed anyway. Because C-Left moves the mouse pointer half a screen to the left I rarely test this feature... But instead of starting a discussion on how to display insets in the most comfortable way How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes I think the second point is sufficient and everything else not strictly needed. Some final thoughts: In mathEd, the 'where' is important -- is the cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? The typical XML document structure is hierarical. So, yes. How about a figure float? Edited at it's 'anchor point' as it is right now. Works good enough and fits into the hierarchy. No need to change. No... that's not the same as a being in a subscript to me, since the subscript belongs to something. A footnote might belong to something though... Sure, to the word or phrase it is explaining, i.e. the 'anchor' bah, this gets too complicated... Not really. A simple tree. 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: CharStyle discussion
On Fri, 5 Dec 2003, Christian Ridderström wrote: And that's not because that's the natural way with the all-boxes approaches but because it's the way I think of the text markup. And not being sure whether I am inside or outside makes me uncomfortable. Are you thinking of a special situation here? (could you give an example) I remember it being a bit annoying to know where you are when you use C-e, but I couldn't find an example just now. A somewhat related example, see attached .lyx. I guess the question here is what markup is applied to the ' ' at the end of a word. For emphasis this would only make a practical different in the output if it was printed using for instance underline. Here's the plain text from the example: Example sentence: Here is the first-word and here is the second-word i.e. differnt selection. In the sentence above, 'first-word' was selected and marked with emphasis, and 'second-word ' was marked with empahsis. Note the extra ' ' at the end of 'second-word '. When moving the cursor at the end of the 'words', the emphasis-mode is exactly the same... Is the ' ' in emphasis or not? /Christian -- Christian Ridderström http://www.md.kth.se/~chr #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Standard Example sentence: \layout Quote Here is the \emph on first-word \emph default and here is the \emph on second-word \emph default i.e. differnt selection. \layout Standard In the sentence above, 'first-word' was selected and marked with emphasis, and 'second-word ' was marked with empahsis. Note the extra ' ' at the end of 'second-word '. When moving the cursor at the end of the 'words', the emphasis-mode is exactly the same... Is the ' ' in emphasis or not? \the_end
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:13:03PM +0100, Christian Ridderström wrote: Are you thinking of a special situation here? (could you give an example) If I knew what's the exact situation I'd probably have tried to change that. It just bites from time to time. It may well be that most of the biting comes from that unholy 'toggle emphasize on a whole word' feature but I had this deactivated for a while in my tree and I seem to remember that the problem was not entirely gone. [Btw we should drop this 'toggle word' feature] 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: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström wrote: For formulas, I want very fine-grained control of 'where' the cursor is, so the 2-cursor approach is useful, even if it sometimes feels like you are pressing the left/right arrows way to often. For normal text, I think I'd be annoyed if I had to do double 'left's just because I was crossing a markup border. But you'd cross markup borders less often than in math. If you can cope with that in math (i.e. 'words' of typical length 1) you should be able to handle that for phrease of lenght 10 or 20 or so as well. After all the overhead in this case is just 10% or 5% of what you accept in math. Umm.. actually, it might be even more annoying because it only happens now and then. In mathed, you get (sort of) used to it since it's so frequent. In textEd, I'd probably just get pissed off... With the ERT inset (in textEd) for instance, this is not really a problem since you have the visual barrier (box) that you pass through. Some ideas out of the blue: * Have a mode setting that controls if movement is course or fine * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' M-Left/Right switches virtual screens here. No good. SCNR ;-) I know you CNR, but I've changed that mapping to S-M-Left/Right (and use C-M-Left/Right to switch and bring the current application along). SCNR ;) Mathed This would be great in mathed, unfortunately, you probably want -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm stupid, why not change the behaviour of C-Left/C-Right.. at the moment these keys aren't so useful in mathed anyway. Because C-Left moves the mouse pointer half a screen to the left I rarely test this feature... You need to fix your window manager? SCNR Seriously, what do you mean? Is it broken in 1.4? (in 1.3 it moves to the left/right-most position inside the math-inset IIRC) But instead of starting a discussion on how to display insets in the most comfortable way How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes I think the second point is sufficient and everything else not strictly needed. For text editing, I'm pretty sure I'd like a mode without any boxes... it's annoying as it is with ERT boxes, index boxes etc, that clutter the screen and takes away my focus from the actual text content. Have you used word and NOT been irritated by the squiggly lines below words? (I'm not talking about the crappy grammar/vocabulary here) That said, I guess I'd have to actually try a lyx version where only the current word(s) that are e.g. emphasized appear in a box in order to see how annyoing it'd be. Note: Isn't it overkill drawing something that's emphasized using a box AND (e.g.) italics? We don't want to flood the user with visual info. Some final thoughts: In mathEd, the 'where' is important -- is the cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? The typical XML document structure is hierarical. So, yes. Sorry, I don't buy that argument. You are talking about data structures intended to be machine readable, whereas I am talking about how we (our brain) thinks about text. In my mind, text is more of a linear (sequential) object than something with the tree structure of a formula. How about a figure float? Edited at it's 'anchor point' as it is right now. Works good enough and fits into the hierarchy. No need to change. No... that's not the same as a being in a subscript to me, since the subscript belongs to something. A footnote might belong to something though... Sure, to the word or phrase it is explaining, i.e. the 'anchor' bah, this gets too complicated... Not really. A simple tree. I am still talking about how I think our brains associate objects and would prefer working with the text when we are in an intuitive phase, like when writing a lot. And for this case I'm not sure a (non-trivial) tree is the best metaphor. The tree is useful when we already have most of the text, and we for instance want to go in and emphasize a word. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: It may well be that most of the biting comes from that unholy 'toggle emphasize on a whole word' feature but I had this deactivated for a while in my tree and I seem to remember that the problem was not entirely gone. That was actually the first thing I thought of too... but when I tried it I couldn't (immediately) find something to complain about it. But it definitely bites you know and then, wish I could remember exactly when. [Btw we should drop this 'toggle word' feature] I agree, and leave it as an LFUN for people who're used to it. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
Michael Schmitt wrote: Jean-Marc Lasgouttes wrote: Martin Talking about looks, see the attached. Looks good, Martin! |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. Ha! That was exactly _my_ idea (about 15 seconds ago) :-) I think the red frame should be removed, if possible, since (a) it occupies some space and (b) looks too eye-catching. Too eye-catching is also fixable by changing the color from red to something more neutral like a shade of gray. That way it won't interfere much with reading the text on-screen, but still visible for those occations when we need the information. I changed the math color from blue to green in my preferences, that way the math don't stand out so much from the default yellow background. It is still visible enough though. Helge Hafting
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote: With the ERT inset (in textEd) for instance, this is not really a problem since you have the visual barrier (box) that you pass through. Well, the idea of all-boxes is to have that barrier for each change. Because C-Left moves the mouse pointer half a screen to the left I rarely test this feature... You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. Seriously, what do you mean? I mean 'I don't know what Ctrl-Left is doing as this key sequence is handled by my window manager so LyX never sees it. M-x word-backward/forward work fine, though. Is it broken in 1.4? (in 1.3 it moves to the left/right-most position inside the math-inset IIRC) 1.4 too. I think the second point is sufficient and everything else not strictly needed. For text editing, I'm pretty sure I'd like a mode without any boxes... Even without the once the cursor is in? it's annoying as it is with ERT boxes, index boxes etc, that clutter the screen and takes away my focus from the actual text content. It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) Have you used word and NOT been irritated by the squiggly lines below words? Rarely. and yes, I find this confusing. Note: Isn't it overkill drawing something that's emphasized using a box AND (e.g.) italics? We don't want to flood the user with visual info. Interesting point. Hm, maybe. Maybe not, though... cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? The typical XML document structure is hierarical. So, yes. Sorry, I don't buy that argument. You are talking about data structures intended to be machine readable, whereas I am talking about how we (our brain) thinks about text. It helps to adjust your way of thinking a bit to the way the machine handles stuff. This enables you to work with the machine, not against it... 'Documents are trees' is not a bad mode of thought IMO. In my mind, text is more of a linear (sequential) object than something with the tree structure of a formula. This holds for a novel ore such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Andr'e
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote: With the ERT inset (in textEd) for instance, this is not really a problem since you have the visual barrier (box) that you pass through. Well, the idea of all-boxes is to have that barrier for each change. which works for the ERT since the barrier is visible before you approach it, so you are more prepared for the resistance. However, I thought neither of us want these boxes being shown all the time? Speaking of boxes, in another thread the suggestion was made to only have a thin line underneath the object. This sounds good since it's less visually intrusive, but what if this also makes the barrier seem to vanish, the user might get annoyed at having to press left/right twice... Because C-Left moves the mouse pointer half a screen to the left I rarely test this feature... You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. ok... and all new WM features since then are just crap? ;) I think the second point is sufficient and everything else not strictly needed. For text editing, I'm pretty sure I'd like a mode without any boxes... Even without the once the cursor is in? To clarify: Normally, I'd probably like the 'current' inset to have a box, but I can imagine that sometimes I don't even want the current inset to be shown. Especially if I am moving through the text using lots of left/rights (if there was a small delay before the box showed up, that might not be a problem though) it's annoying as it is with ERT boxes, index boxes etc, that clutter the screen and takes away my focus from the actual text content. It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) Those corners are nice... which reminds me, do you remember that problem with extra space after the math-inset (the one where the extra space made you think that there was a real space, and then at the printout you got stuff like in this formula C=2you have) I just checked the latest xforms, and there is still extra space after the math inset... I can't really remember, but wasn't it something about the width of the box that forced us to accept that space? Have you used word and NOT been irritated by the squiggly lines below words? Rarely. and yes, I find this confusing. Note: Isn't it overkill drawing something that's emphasized using a box AND (e.g.) italics? We don't want to flood the user with visual info. Interesting point. Hm, maybe. Maybe not, though... Well, it's not easy to know if it's too much or not. That's one reason I think it would be good to be able to switch between modes... for that matter different people probably have different thresholds. (I think the old story about information overload comes from Vietnam pilots who had to much beeps and indicators going on so they simply shut off 'unimportant' stuff like warning of enemy radar locks...) cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? The typical XML document structure is hierarical. So, yes. Sorry, I don't buy that argument. You are talking about data structures intended to be machine readable, whereas I am talking about how we (our brain) thinks about text. It helps to adjust your way of thinking a bit to the way the machine handles stuff. This enables you to work with the machine, not against it... 'Documents are trees' is not a bad mode of thought IMO. Don't get me wrong, I actually use that metaphor a lot (and have actually tried to convince others to think that way), but I do know that some people like to write stuff from start to end. (ie a bit unstructured IMO, but maybe I'm just envious because I can't ;) In my mind, text is more of a linear (sequential) object than something with the tree structure of a formula. This holds for a novel or such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Now I'm confused... I don't write novels, but I am a book-aholic, and there's quite often markup (italics, bold etc) even in them. Some modern novels look awful due to too much markup btw. Anyway, this markup would show up as boxes wouldn't it? (and thus possibly impede the writer of that text). And even though my science papers are usually heavily tree-structured, perhaps papers in other fields (psychology?) are more like novels? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake thusly:
>
> I tightened up the thing a little bit. The patch is attached.
>
> I think this is such a clear improvement on what we had, that this
> should go in as it stands, despite small quirks (which I am not even
> sure have to do with the patch). I think we have at least the right
> visual model now.
>
> - Martin
Here's a slightly improved patch. Less quirks (And this time I
remembered the .h file :-)
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C5 Dec 2003 07:01:30 -
@@ -25,6 +25,8 @@
#include "metricsinfo.h"
#include "paragraph.h"
+#include "frontends/font_metrics.h"
+#include "frontends/Painter.h"
#include "support/std_sstream.h"
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName("CharStyle");
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const & bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs->name;
params_.latextype = cs->latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const & in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,41 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const & buf, LyXLex & lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = "Style: " + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
+void InsetCharStyle::draw(PainterInfo & pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ inset.draw(pi, x, y);
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w), y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +135,19 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const & cmd,
idx_type & idx, pos_type & pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ break;
+ default:
+ return InsetCollapsable::priv_dispatch(cmd, idx, pos);
+ }
}
Index: insetcharstyle.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.h,v
retrieving revision 1.2
diff -u -p -r1.2 insetcharstyle.h
--- insetcharstyle.h1 Dec 2003 16:01:50 - 1.2
+++ insetcharstyle.h5 Dec 2003 07:01:30 -
@@ -60,10 +60,10 @@ public:
///
void read(Buffer const & buf, LyXLex & lex);
///
- void setButtonLabel();
- ///
void metrics(MetricsInfo &, Dimension &) const;
///
+ void draw(PainterInfo &, int, int) const;
+ ///
void getDrawFont(LyXFont &) const;
///
int latex(Buffer const &, std::ostream &,
@@ -96,6 +96,8 @@ private:
void init();
///
InsetCharStyleParams params_;
+ ///
+ bool has_label_;
};
#endif
pgp0.pgp
Description: PGP signature
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > Dear Martin et al., > > do you need some more comments? Ok, here are mine :-) > > > Yes, box removing by is 'direct manipulation' according to > > this definition. > > > Nobody, not a single person! complained about this since 1.3.0 is out. > > I am really tempted to call this argument 'FUD'. > > Personally, I have no problem with this feature. Although I consider > myself a power-user, I have never noticed it in mathed. This also means > that it has never been an obstacle when writing some formula :-) > > HOWEVER... and now I will make you very angry ... I don't like the > CharStyle inset approach at all - at least in the way it is planned at > the moment. > > Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!! You have to press C-e for emphasized anyway. Whether the result is realized by an inset or some other structure internally is irrelevant for the users. If the inset is visibly indistinguishable from the current display (which is at least for short stuff possible but requires Asger's three-box-drawing model for long) nobody will notice anyway. The only point to discuss IMO is whether there could/should be two physical cursor positions (boxes/mathed model) or just one (OOo/Word) Personally, having the two logicaly positions (just before some change/at the beginning of a change) is _the_ > But instead of starting a discussion on how to display insets in the > most comfortable way, we have to clarify the general concepts of > character styles first. IMHO there should be no fixed set of char > styles. Instead the user should be able to define his own styles and > change them later (similar to branches). This, of course, requires > additional dialogs, etc. etc. As a first step, reading them from the layout would be ok. Second step is to incorporate '.layout' snippets into the .lyx. Last step is to provide some gui... > So... do we really want such a mammoth project while LyX is broken at > each corner? This is pretty independent from the core fixes. > Last night, I worked four hours on a simple > insetcollapsable/insertert code merge just to find out that the > crashes I experienced also occur with the latest cvs :-( (The fact > that my 1Ghz 128MB computer spent more than half of the time on > compiling and swapping did not improve my bad mood). Hm yes. This is still bad and got suddenly worse again a few weeks ago... > Shouldn't we concentrate on bug fixing rather than starting new > projects? For those people willing and able to work on the core, probably yes. But I don't see a reason why the others should be stopped... Andre'
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 07:14:18PM +0200, Martin Vermeer wrote: > Talking about looks, see the attached. Still a bit intrusive ... > I need to do some cleaning on the patch still, but this works, and not > just sort-of. What is unelegant about it is that it still bases > CharStyle on Collapsable, though it is forced permanently into > Inlined mode. There should be a way to base it directly off > UpdatableInset (right?) but I didn't get anywhere trying. Rather from InsetText. But I think you could leave it as it is for now. Andre'
Re: CharStyle discussion
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Personally, having the two logicaly positions (just before some Andre> change/at the beginning of a change) is _the_ _the_ what? We could have a solution where there is only one position in general, but we have a lfun that switches to the other position (when relevant) when needed. Of course there should be some visual indication of what happens. This would be only a power user thing, so it needn't be very discoverable. I did not chime in in the thread between John and Andre, in part because we had a 24h network outage :(. However, I have to say that I am not comfortable with andre's position... I really think that an application should be developed in the UI-to-code direction, and not code-to-UI. Saying that, since a certain data structure is sound then we should use it and then expose it to the user is taking things backward IMO. JMarc
Re: [Patch] Re: CharStyle discussion
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake Martin> thusly: >> I tightened up the thing a little bit. The patch is attached. >> >> I think this is such a clear improvement on what we had, that this >> should go in as it stands, despite small quirks (which I am not >> even sure have to do with the patch). I think we have at least the >> right visual model now. Isn't it possible to have this code in InsetCollapsable? My though is that we should try to limit the number of possible appearance of insets rather than have each inset invent something. I think that all insets in inline mode would benefit from this representation (think of ERT). JMarc
Re: [Patch] Re: CharStyle discussion
On Friday 05 December 2003 09:19, Jean-Marc Lasgouttes wrote: > > I think that all insets in inline mode would benefit from this > representation (think of ERT). I agree. > JMarc -- José Abílio LyX and docbook, a perfect match. :-)
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:15:10AM +0100, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> Personally, having the two logicaly positions (just before some > Andre> change/at the beginning of a change) is _the_ > > _the_ what? ... thing that annoys me most in the main text (well, apart from the general lack of easily accessible functions to jump around and S). And that's not because that's the natural way with the all-boxes approaches but because it's the way I think of the text markup. And not being sure whether I am inside or outside makes me uncomfortable. > We could have a solution where there is only one position in general, > but we have a lfun that switches to the other position (when relevant) > when needed. Of course there should be some visual indication of what > happens. This would be only a power user thing, so it needn't be very > discoverable. > > I did not chime in in the thread between John and Andre, in part > because we had a 24h network outage :(. However, I have to say that I > am not comfortable with andre's position... I know. > I really think that an application should be developed in the > UI-to-code direction, and not code-to-UI. Saying that, since a certain > data structure is sound then we should use it and then expose it to > the user is taking things backward IMO. But almost any UI can be provided on top of a flexible data structure. If your data structure is only geared towards a single UI, some UI quirks simply won't be fixable or some features are hard to implement because your data structure does not support 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] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:19:29AM +0100, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> On Fri, Dec 05, 2003 at 12:02:19AM +0200, Martin Vermeer spake > Martin> thusly: > >> I tightened up the thing a little bit. The patch is attached. > >> > >> I think this is such a clear improvement on what we had, that this > >> should go in as it stands, despite small quirks (which I am not > >> even sure have to do with the patch). I think we have at least the > >> right visual model now. > > Isn't it possible to have this code in InsetCollapsable? My though is > that we should try to limit the number of possible appearance of > insets rather than have each inset invent something. I think we could somehow consolitate InsetText and InsetCollapsable. InsetText is only used in InsetCollapsable and InsetTabular, and InsetTabular should contain LyXTexts rather than InsetTexts... Andre'
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: > On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > > Dear Martin et al., > > > > do you need some more comments? Ok, here are mine :-) > > > > > box removing by I find this function _very_ useful in mathed, but difficult to discover :-( Uwe Stöhr has written a manual for mathed (in German), I think we need a manual (in English) for mathed... > You have to press C-e for emphasized anyway. Whether the result is > realized by an inset or some other structure internally is irrelevant > for the users. If the inset is visibly indistinguishable from the > current display (which is at least for short stuff possible but requires > Asger's three-box-drawing model for long) nobody will notice anyway. > > The only point to discuss IMO is whether there could/should be two > physical cursor positions (boxes/mathed model) or just one (OOo/Word) > > Personally, having the two logicaly positions (just before some > change/at the beginning of a change) is _the_ ?question? Wow... finally a question I understand... IMO, working with text and formulas is quite different with respect to what is the most common cursor movement operation. In formulas, I mostly need fine control of movement, whereas in text I mostly want 'course' control of movement. Perhaps... 'course' movement can be defined as moving between 'content', and 'fine' movment as moving between markup? (Maybe we can even start talking about a content space and a markup space :-) For formulas, I want very fine-grained control of 'where' the cursor is, so the 2-cursor approach is useful, even if it sometimes feels like you are pressing the left/right arrows way to often. For normal text, I think I'd be annoyed if I had to do double 'left's just because I was crossing a markup border. Some ideas out of the blue: * Have a "mode" setting that controls if movement is "course" or "fine" * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' Mathed This would be great in mathed, unfortunately, you probably want -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm stupid, why not change the behaviour of C-Left/C-Right.. at the moment these keys aren't so useful in mathed anyway. > > But instead of starting a discussion on how to display insets in the > > most comfortable way How about modes for controlling if markup borders (i.e. insets?) should be shown, these could be: * Don't show any boxes etc * Only show box of the inset(s) that the cursor is in * Show all boxes Some final thoughts: In mathEd, the 'where' is important -- is the cursor in a subscript, or in a superscript... objects are in a strict hierarchy. Is there a similar distiction in 'textEd'? How about a figure float? No... that's not the same as a being in a subscript to me, since the subscript "belongs" to something. A footnote might belong to something though... bah, this gets too complicated... /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[Patch] Re: [Patch] Re: CharStyle discussion
On Fri, Dec 05, 2003 at 10:19:29AM +0100, Jean-Marc Lasgouttes spake thusly:
> Isn't it possible to have this code in InsetCollapsable? My though is
> that we should try to limit the number of possible appearance of
> insets rather than have each inset invent something.
>
> I think that all insets in inline mode would benefit from this
> representation (think of ERT).
>
> JMarc
Good idea actually. Especially ERT. Only I don't feel like doing that
right now.
I slightly improved again the patch; now the frame has been replaced
by a blue underline to be less conspicuous. Otherwise the same.
Patch attached. As I haven't heard any real objections (just blue-sky
ideas building on it) I'll commit later today.
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C5 Dec 2003 10:37:43 -
@@ -25,6 +25,8 @@
#include "metricsinfo.h"
#include "paragraph.h"
+#include "frontends/font_metrics.h"
+#include "frontends/Painter.h"
#include "support/std_sstream.h"
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName("CharStyle");
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const & bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs->name;
params_.latextype = cs->latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const & in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,48 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const & buf, LyXLex & lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = "Style: " + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
+void InsetCharStyle::draw(PainterInfo & pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ inset.setDrawFrame(InsetText::NEVER);
+ inset.draw(pi, x, y);
+
+ pi.pain.line(x + 2, y + inset.descent(), x + dim_.wid - 2,
+ y + inset.descent(), LColor::blue);
+
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w),
+ y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +142,19 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const & cmd,
idx_type & idx, pos_type & pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ break;
+ default:
+ return InsetCollapsable::priv_dispatch(cmd, idx, pos);
+ }
}
Index: insetcharstyle.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.h,v
retrieving revision 1.2
diff -u -p -r1.2 insetcharstyle.h
--- insetcharstyle.h1 Dec 2003 16:01:50 - 1.2
+++ insetcharstyle.h5 Dec 2003 10:37:43 -
@@ -60,10 +60,10 @@ public:
///
void read(Buffer const & buf, LyXLex & lex);
///
- void setButtonLabel();
- ///
void
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström spake thusly: > How about modes for controlling if markup borders (i.e. insets?) should be > shown, these could be: > * Don't show any boxes etc > * Only show box of the inset(s) that the cursor is in > * Show all boxes We have that already -- in principle. See insettext.h:44. - Martin pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Fri, 5 Dec 2003, Martin Vermeer wrote: > On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström spake thusly: > > > How about modes for controlling if markup borders (i.e. insets?) should be > > shown, these could be: > > * Don't show any boxes etc > > * Only show box of the inset(s) that the cursor is in > > * Show all boxes > > We have that already -- in principle. See insettext.h:44. ... in principle... :-) I take it you mean it shouldn't be too difficult to implement this... But the question is if this something we want? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: > On Fri, Dec 05, 2003 at 10:15:10AM +0100, Jean-Marc Lasgouttes wrote: > > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > > > Andre> Personally, having the two logicaly positions (just before some > > Andre> change/at the beginning of a change) is _the_ > > ... thing that annoys me most in the main text (well, apart from the > general lack of easily accessible functions to jump around and S). > You tricky bastard... ;-) I was so sure you meant "question" that I wrote a long post on that subject... I thought I'd be doing "work" stuff by now. Instead I'm suddenly caught up in this mail thread, damn you... (hypocritical-smiley) > And that's not because that's the natural way with the all-boxes > approaches but because it's the way I think of the text markup. And > not being sure whether I am inside or outside makes me uncomfortable. Are you thinking of a special situation here? (could you give an example) I remember it being a bit annoying to know where you are when you use C-e, but I couldn't find an example just now. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström wrote: > For formulas, I want very fine-grained control of 'where' the cursor is, > so the 2-cursor approach is useful, even if it sometimes feels like you > are pressing the left/right arrows way to often. For normal text, I think > I'd be annoyed if I had to do double 'left's just because I was crossing a > markup border. But you'd cross markup borders less often than in math. If you can cope with that in math (i.e. 'words' of typical length 1) you should be able to handle that for phrease of lenght 10 or 20 or so as well. After all the overhead in this case is just 10% or 5% of what you accept in math. > Some ideas out of the blue: > * Have a "mode" setting that controls if movement is "course" or "fine" > * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' M-Left/Right switches virtual screens here. No good. SCNR ;-) > Mathed This would be great in mathed, unfortunately, you probably want > -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm >stupid, why not change the behaviour of C-Left/C-Right.. at the >moment these keys aren't so useful in mathed anyway. Because C-Left moves the mouse pointer half a screen to the left I rarely test this feature... > > > But instead of starting a discussion on how to display insets in the > > > most comfortable way > > How about modes for controlling if markup borders (i.e. insets?) should be > shown, these could be: > * Don't show any boxes etc > * Only show box of the inset(s) that the cursor is in > * Show all boxes I think the second point is sufficient and everything else not strictly needed. > Some final thoughts: In mathEd, the 'where' is important -- is the > cursor in a subscript, or in a superscript... objects are in a strict > hierarchy. Is there a similar distiction in 'textEd'? The typical XML document structure is hierarical. So, yes. > How about a figure float? Edited at it's 'anchor point' as it is right now. Works good enough and fits into the hierarchy. No need to change. > No... that's not the same as a being in a subscript to me, since the > subscript "belongs" to something. A footnote might belong to > something though... Sure, to the word or phrase it is explaining, i.e. the 'anchor' > bah, this gets too complicated... Not really. A simple tree. 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: CharStyle discussion
On Fri, 5 Dec 2003, Christian Ridderström wrote: > > And that's not because that's the natural way with the all-boxes > > approaches but because it's the way I think of the text markup. And > > not being sure whether I am inside or outside makes me uncomfortable. > > Are you thinking of a special situation here? (could you give an example) > I remember it being a bit annoying to know where you are when you use C-e, > but I couldn't find an example just now. A somewhat related example, see attached .lyx. I guess the question here is what markup is applied to the ' ' at the end of a word. For emphasis this would only make a practical different in the output if it was printed using for instance underline. Here's the plain text from the example: Example sentence: Here is the first-word and here is the second-word i.e. differnt selection. In the sentence above, 'first-word' was selected and marked with emphasis, and 'second-word ' was marked with empahsis. Note the extra ' ' at the end of 'second-word '. When moving the cursor at the end of the 'words', the emphasis-mode is exactly the same... Is the ' ' in emphasis or not? /Christian -- Christian Ridderström http://www.md.kth.se/~chr #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \language english \inputencoding auto \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Standard Example sentence: \layout Quote Here is the \emph on first-word \emph default and here is the \emph on second-word \emph default i.e. differnt selection. \layout Standard In the sentence above, 'first-word' was selected and marked with emphasis, and 'second-word ' was marked with empahsis. Note the extra ' ' at the end of 'second-word '. When moving the cursor at the end of the 'words', the emphasis-mode is exactly the same... Is the ' ' in emphasis or not? \the_end
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:13:03PM +0100, Christian Ridderström wrote: > Are you thinking of a special situation here? (could you give an example) If I knew what's the exact situation I'd probably have tried to change that. It just bites from time to time. It may well be that most of the biting comes from that unholy 'toggle emphasize on a whole word' feature but I had this deactivated for a while in my tree and I seem to remember that the problem was not entirely gone. [Btw we should drop this 'toggle word' feature] 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: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: > On Fri, Dec 05, 2003 at 11:30:20AM +0100, Christian Ridderström wrote: > > For formulas, I want very fine-grained control of 'where' the cursor is, > > so the 2-cursor approach is useful, even if it sometimes feels like you > > are pressing the left/right arrows way to often. For normal text, I think > > I'd be annoyed if I had to do double 'left's just because I was crossing a > > markup border. > > But you'd cross markup borders less often than in math. If you can cope > with that in math (i.e. 'words' of typical length 1) you should be able to > handle that for phrease of lenght 10 or 20 or so as well. After all the > overhead in this case is just 10% or 5% of what you accept in math. Umm.. actually, it might be even more annoying because it only happens now and then. In mathed, you get (sort of) used to it since it's so frequent. In textEd, I'd probably just get pissed off... With the ERT inset (in textEd) for instance, this is not really a problem since you have the visual "barrier" (box) that you pass through. > > > Some ideas out of the blue: > > * Have a "mode" setting that controls if movement is "course" or "fine" > > * Use modifier (e.g. M-Left/M-Right) for fine grained movement in 'textEd' > > M-Left/Right switches virtual screens here. No good. > SCNR ;-) I know you CNR, but I've changed that mapping to S-M-Left/Right (and use C-M-Left/Right to switch and bring the current application along). SCNR ;) > > > Mathed This would be great in mathed, unfortunately, you probably want > > -idea: M-Left/M-Right to do course movement there :-( Bah.. I'm > > stupid, why not change the behaviour of C-Left/C-Right.. at the > > moment these keys aren't so useful in mathed anyway. > > Because C-Left moves the mouse pointer half a screen to the left I > rarely test this feature... You need to fix your window manager? SCNR Seriously, what do you mean? Is it broken in 1.4? (in 1.3 it moves to the left/right-most position inside the math-inset IIRC) > > > > > But instead of starting a discussion on how to display insets in the > > > > most comfortable way > > > > How about modes for controlling if markup borders (i.e. insets?) should be > > shown, these could be: > > * Don't show any boxes etc > > * Only show box of the inset(s) that the cursor is in > > * Show all boxes > > I think the second point is sufficient and everything else not strictly > needed. For text editing, I'm pretty sure I'd like a mode without any boxes... it's annoying as it is with ERT boxes, index boxes etc, that clutter the screen and takes away my focus from the actual text content. Have you used word and NOT been irritated by the squiggly lines below words? (I'm not talking about the crappy grammar/vocabulary here) That said, I guess I'd have to actually try a lyx version where only the current word(s) that are e.g. emphasized appear in a "box" in order to see how annyoing it'd be. Note: Isn't it overkill drawing something that's emphasized using a box AND (e.g.) italics? We don't want to flood the user with visual info. > > > Some final thoughts: In mathEd, the 'where' is important -- is the > > cursor in a subscript, or in a superscript... objects are in a strict > > hierarchy. Is there a similar distiction in 'textEd'? > > The typical XML document structure is hierarical. So, yes. Sorry, I don't buy that argument. You are talking about data structures intended to be machine readable, whereas I am talking about how we (our brain) thinks about text. In my mind, text is more of a linear (sequential) object than something with the tree structure of a formula. > > > How about a figure float? > > Edited at it's 'anchor point' as it is right now. Works good enough and > fits into the hierarchy. No need to change. > > > No... that's not the same as a being in a subscript to me, since the > > subscript "belongs" to something. A footnote might belong to > > something though... > > Sure, to the word or phrase it is explaining, i.e. the 'anchor' > > > bah, this gets too complicated... > > Not really. A simple tree. I am still talking about how I think our brains associate objects and would prefer working with the text when we are in an "intuitive" phase, like when writing a lot. And for this case I'm not sure a (non-trivial) tree is the best metaphor. The tree is useful when we already have most of the text, and we for instance want to go in and emphasize a word. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: > It may well be that most of the biting comes from that unholy 'toggle > emphasize on a whole word' feature but I had this deactivated for a > while in my tree and I seem to remember that the problem was not > entirely gone. That was actually the first thing I thought of too... but when I tried it I couldn't (immediately) find something to complain about it. But it definitely bites you know and then, wish I could remember exactly when. > [Btw we should drop this 'toggle word' feature] I agree, and leave it as an LFUN for people who're used to it. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
Michael Schmitt wrote: Jean-Marc Lasgouttes wrote: Martin> Talking about looks, see the attached. Looks good, Martin! |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. Ha! That was exactly _my_ idea (about 15 seconds ago) :-) I think the red frame should be removed, if possible, since (a) it occupies some space and (b) looks too eye-catching. Too eye-catching is also fixable by changing the color from red to something more neutral like a shade of gray. That way it won't interfere much with reading the text on-screen, but still visible for those occations when we need the information. I changed the math color from blue to green in my preferences, that way the math don't stand out so much from the default yellow background. It is still visible enough though. Helge Hafting
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote: > With the ERT inset (in textEd) for instance, this is not really a problem > since you have the visual "barrier" (box) that you pass through. Well, the idea of all-boxes is to have that barrier for each change. > > Because C-Left moves the mouse pointer half a screen to the left I > > rarely test this feature... > > You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. > Seriously, what do you mean? I mean 'I don't know what Ctrl-Left is doing as this key sequence is handled by my window manager so LyX never sees it. M-x word-backward/forward work fine, though. > Is it broken in 1.4? (in 1.3 it moves to the > left/right-most position inside the math-inset IIRC) 1.4 too. > > I think the second point is sufficient and everything else not strictly > > needed. > > For text editing, I'm pretty sure I'd like a mode without any boxes... Even without the once the cursor is in? > it's annoying as it is with ERT boxes, index boxes etc, that clutter the > screen and takes away my focus from the actual text content. It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) > Have you used word and NOT been irritated by the squiggly lines below > words? Rarely. and yes, I find this confusing. > Note: Isn't it overkill drawing something that's emphasized using a box > AND (e.g.) italics? We don't want to flood the user with visual info. Interesting point. Hm, maybe. Maybe not, though... > > > cursor in a subscript, or in a superscript... objects are in a strict > > > hierarchy. Is there a similar distiction in 'textEd'? > > > > The typical XML document structure is hierarical. So, yes. > > Sorry, I don't buy that argument. You are talking about data structures > intended to be machine readable, whereas I am talking about how we (our > brain) thinks about text. It helps to adjust your way of thinking a bit to the way the machine handles stuff. This enables you to work with the machine, not against it... 'Documents are trees' is not a bad mode of thought IMO. > In my mind, text is more of a linear (sequential) object than > something with the tree structure of a formula. This holds for a novel ore such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Andr'e
Re: CharStyle discussion
On Fri, 5 Dec 2003, Andre Poenitz wrote: > On Fri, Dec 05, 2003 at 12:53:04PM +0100, Christian Ridderström wrote: > > With the ERT inset (in textEd) for instance, this is not really a problem > > since you have the visual "barrier" (box) that you pass through. > > Well, the idea of all-boxes is to have that barrier for each change. which works for the ERT since the barrier is visible before you approach it, so you are more prepared for the "resistance". However, I thought neither of us want these boxes being shown all the time? Speaking of boxes, in another thread the suggestion was made to only have a thin line underneath the object. This sounds good since it's less visually intrusive, but what if this also makes the "barrier" seem to vanish, the user might get annoyed at having to press left/right twice... > > > Because C-Left moves the mouse pointer half a screen to the left I > > > rarely test this feature... > > > > You need to fix your window manager? SCNR > > Indeed. Save a few small changes I use the same configuration as 14 > years ago. ok... and all new WM features since then are just crap? ;) > > > I think the second point is sufficient and everything else not strictly > > > needed. > > > > For text editing, I'm pretty sure I'd like a mode without any boxes... > > Even without the once the cursor is in? To clarify: Normally, I'd probably like the 'current' inset to have a box, but I can imagine that sometimes I don't even want the current inset to be shown. Especially if I am moving through the text using lots of left/rights (if there was a small delay before the box showed up, that might not be a problem though) > > > it's annoying as it is with ERT boxes, index boxes etc, that clutter the > > screen and takes away my focus from the actual text content. > > It could be made less intrusive like the pink corners of the math boxes > (instead of a 'solid' box...) Those corners are nice... which reminds me, do you remember that problem with extra space after the math-inset (the one where the extra space made you think that there was a real space, and then at the printout you got stuff like "in this formula C=2you have") I just checked the latest xforms, and there is still extra space after the math inset... I can't really remember, but wasn't it something about the width of the box that forced us to accept that space? > > > Have you used word and NOT been irritated by the squiggly lines below > > words? > > Rarely. and yes, I find this confusing. > > > Note: Isn't it overkill drawing something that's emphasized using a box > > AND (e.g.) italics? We don't want to flood the user with visual info. > > Interesting point. Hm, maybe. Maybe not, though... > Well, it's not easy to know if it's too much or not. That's one reason I think it would be good to be able to switch between modes... for that matter different people probably have different thresholds. (I think the old story about information overload comes from Vietnam pilots who had to much beeps and indicators going on so they simply shut off 'unimportant' stuff like warning of enemy radar locks...) > > > > cursor in a subscript, or in a superscript... objects are in a strict > > > > hierarchy. Is there a similar distiction in 'textEd'? > > > > > > The typical XML document structure is hierarical. So, yes. > > > > Sorry, I don't buy that argument. You are talking about data structures > > intended to be machine readable, whereas I am talking about how we (our > > brain) thinks about text. > > It helps to adjust your way of thinking a bit to the way the machine > handles stuff. This enables you to work with the machine, not against > it... 'Documents are trees' is not a bad mode of thought IMO. Don't get me wrong, I actually use that metaphor a lot (and have actually tried to convince others to think that way), but I do know that some people like to write stuff from start to end. (ie a bit unstructured IMO, but maybe I'm just envious because I can't ;) > > > In my mind, text is more of a linear (sequential) object than > > something with the tree structure of a formula. > > This holds for a novel or such, but even the random science paper has > structure. And, btw, if you only have flat text you'll never see a box > even with all-boxes. Now I'm confused... I don't write novels, but I am a book-aholic, and there's quite often markup (italics, bold etc) even in them. Some modern novels look awful due to too much markup btw. Anyway, this markup would show up as boxes wouldn't it? (and thus possibly impede the writer of that text). And even though my science papers are usually heavily tree-structured, perhaps papers in other fields (psychology?) are more like novels? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. We're talking about where it should go after. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
John Levon wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. That means existing documents will be converted? Which char styles are supported at the moment? We're talking about where it should go after. You mean after 1.4? Kind regards, Michael
Re: CharStyle discussion
On Thursday 04 December 2003 15:17, Michael Schmitt wrote: Dear Martin et al., do you need some more comments? Ok, here are mine :-) Good to hear. Yes, box removing by Backspace is 'direct manipulation' according to this definition. Nobody, not a single person! complained about this since 1.3.0 is out. I am really tempted to call this argument 'FUD'. Personally, I have no problem with this feature. Although I consider myself a power-user, I have never noticed it in mathed. This also means that it has never been an obstacle when writing some formula :-) HOWEVER... and now I will make you very angry ... I don't like the CharStyle inset approach at all - at least in the way it is planned at the moment. You don't make us angry just be disagreeing with us. :-) Insets are an appropriate means for structured editing but they are not suitable for writing consecutive text. If I had had to insert an inset for every emphasized term, for every capitalized product name, for every keyword in typewriter font, and for every figure reference in sans serif in my PhD, I would have jumped out of the window!!! The LyX motto WYSIWM it is not really implemented at moment. And one of the reasons is because we lake the logical char styles. In several aspects we still encourage the user to think about italics, capitalized, typewriter and sans serif. Notice that you used those words instead of their concepts above. What if suddenly you want to change that to a new style, what do you do? I know that we should have some kind of compromise, but you seem to be pushing it to WYSIWYG. But instead of starting a discussion on how to display insets in the most comfortable way, we have to clarify the general concepts of character styles first. The point again is that the insets are an implementation detail. And courageous step, IMHO, in the right direction. Also you will not be forced to use them, they are really usefull at this moment for linuxdoc, docbook and AGU. Yes, they are usefull also to latex, but for the other fontends they are a must have. We have been discussing this for the last 4 years (at least). And Martin showed a simple self-contained approach, the amount of code needed is minimal, and non-intrusive. IMHO there should be no fixed set of char styles. Instead the user should be able to define his own styles and change them later (similar to branches). This, of course, requires additional dialogs, etc. etc. That was of the goals stated by Martin since the first hour. And we need to start somewhere... So... do we really want such a mammoth project while LyX is broken at each corner? Last night, I worked four hours on a simple insetcollapsable/insertert code merge just to find out that the crashes I experienced also occur with the latest cvs :-( (The fact that my 1Ghz 128MB computer spent more than half of the time on compiling and swapping did not improve my bad mood). That is always the question of the 90%-10%. They also very useful as they are an can be improved for sure. Shouldn't we concentrate on bug fixing rather than starting new projects? I think that Martin, André or me have been fixing our share of bugs. (Is there such a thing? ;-) ). Michael PS: Everything said should be taken with a grain of salt, or sugar, or chocolate or every if you prefer. ;-) -- José Abílio LyX and docbook, a perfect match. :-)
Re: CharStyle discussion
Michael Schmitt wrote: John Levon wrote: I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. Which char styles are supported at the moment? [EMAIL PROTECTED]:~/lyx-devel-1.4.0-devel/lib/layouts grep Char * agu_stdclass.inc:CharStyle Firstname agu_stdclass.inc:CharStyle Surname agu_stdclass.inc:CharStyle Filename agu_stdclass.inc:CharStyle Literal db_stdclass.inc:CharStyle Filename db_stdclass.inc:CharStyle Firstname db_stdclass.inc:CharStyle Surname db_stdclass.inc:CharStyle Literal stdclass.inc:CharStyle Noun For LyX 1.4, shouldn't we better remove the CharStyle Noun from stdclass.inc again? The rest is less controversial. Michael
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake thusly: On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. Talking about looks, see the attached. I need to do some cleaning on the patch still, but this works, and not just sort-of. What is unelegant about it is that it still bases CharStyle on Collapsable, though it is forced permanently into Inlined mode. There should be a way to base it directly off UpdatableInset (right?) but I didn't get anywhere trying. You remove/restore the blue label by right mouse clicking the inset. Not very discoverable but I'm sure we can work on that :-) - Martin attachment: a.jpeg pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 07:14:18PM +0200, Martin Vermeer wrote: Talking about looks, see the attached. Looks good regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake Martin thusly: On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. Martin Talking about looks, see the attached. What about putting the blue label on the frame of the inset like |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. JMarc
Re: CharStyle discussion
Jean-Marc Lasgouttes wrote: Martin Talking about looks, see the attached. Looks good, Martin! |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. Ha! That was exactly _my_ idea (about 15 seconds ago) :-) I think the red frame should be removed, if possible, since (a) it occupies some space and (b) looks too eye-catching. However, we might need the red box for insets that span more than one row. Martin, can we check whether an inset is a one-liner or not and output it differently in both possible cases? That would be (nearly) perfect! Michael
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 06:25:24PM +0100, Michael Schmitt spake thusly:
Jean-Marc Lasgouttes wrote:
Martin Talking about looks, see the attached.
Looks good, Martin!
|some contents here|
name
This would reduce the height of the inset...
You can even do
some contents here
\---name-/
and avoid the frame altogether.
Ha! That was exactly _my_ idea (about 15 seconds ago) :-)
I think the red frame should be removed, if possible, since (a) it
occupies some space and (b) looks too eye-catching.
However, we might need the red box for insets that span more than one
row. Martin, can we check whether an inset is a one-liner or not and
output it differently in both possible cases? That would be (nearly)
perfect!
Michael
That isn't quite so easy... feel free to try ;-)
I tightened up the thing a little bit. The patch is attached.
I think this is such a clear improvement on what we had, that this
should go in as it stands, despite small quirks (which I am not even
sure have to do with the patch). I think we have at least the right
visual model now.
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C4 Dec 2003 21:31:08 -
@@ -25,6 +25,8 @@
#include metricsinfo.h
#include paragraph.h
+#include frontends/font_metrics.h
+#include frontends/Painter.h
#include support/std_sstream.h
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName(CharStyle);
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs-name;
params_.latextype = cs-latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,41 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const buf, LyXLex lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = Style: + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo mi, Dimension dim) const
+void InsetCharStyle::draw(PainterInfo pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ InsetCollapsable::draw(pi, x, y);
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w), y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +135,17 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const cmd,
idx_type idx, pos_type pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ default:
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ }
}
pgp0.pgp
Description: PGP signature
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. We're talking about where it should go after. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
John Levon wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. That means existing documents will be converted? Which char styles are supported at the moment? We're talking about where it should go after. You mean after 1.4? Kind regards, Michael
Re: CharStyle discussion
On Thursday 04 December 2003 15:17, Michael Schmitt wrote: > Dear Martin et al., > > do you need some more comments? Ok, here are mine :-) Good to hear. > > Yes, box removing by is 'direct manipulation' according to > > this definition. > > > > Nobody, not a single person! complained about this since 1.3.0 is out. > > I am really tempted to call this argument 'FUD'. > > Personally, I have no problem with this feature. Although I consider > myself a power-user, I have never noticed it in mathed. This also means > that it has never been an obstacle when writing some formula :-) > > HOWEVER... and now I will make you very angry ... I don't like the > CharStyle inset approach at all - at least in the way it is planned at > the moment. You don't make us angry just be disagreeing with us. :-) > Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!! The LyX motto "WYSIWM" it is not really implemented at moment. And one of the reasons is because we lake the logical char styles. In several aspects we still encourage the user to think about italics, capitalized, typewriter and sans serif. Notice that you used those words instead of their concepts above. What if suddenly you want to change that to a new style, what do you do? I know that we should have some kind of compromise, but you seem to be pushing it to WYSIWYG. > But instead of starting a discussion on how to display insets in the > most comfortable way, we have to clarify the general concepts of > character styles first. The point again is that the insets are an implementation detail. And courageous step, IMHO, in the right direction. Also you will not be forced to use them, they are really usefull at this moment for linuxdoc, docbook and AGU. Yes, they are usefull also to latex, but for the other fontends they are a must have. We have been discussing this for the last 4 years (at least). And Martin showed a simple self-contained approach, the amount of code needed is minimal, and non-intrusive. > IMHO there should be no fixed set of char styles. > Instead the user should be able to define his own styles and > change them later (similar to branches). This, of course, requires > additional dialogs, etc. etc. That was of the goals stated by Martin since the first hour. And we need to start somewhere... > So... do we really want such a mammoth project while LyX is broken at > each corner? Last night, I worked four hours on a simple > insetcollapsable/insertert code merge just to find out that the crashes > I experienced also occur with the latest cvs :-( (The fact that my 1Ghz > 128MB computer spent more than half of the time on compiling and > swapping did not improve my bad mood). That is always the question of the 90%-10%. They also very useful as they are an can be improved for sure. > Shouldn't we concentrate on bug fixing rather than starting new projects? I think that Martin, André or me have been fixing our share of bugs. (Is there such a thing? ;-) ). > Michael PS: Everything said should be taken with a grain of salt, or sugar, or chocolate or every if you prefer. ;-) -- José Abílio LyX and docbook, a perfect match. :-)
Re: CharStyle discussion
Michael Schmitt wrote: John Levon wrote: I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. > Which char styles are supported at the moment? [EMAIL PROTECTED]:~/lyx-devel-1.4.0-devel/lib/layouts> grep Char * agu_stdclass.inc:CharStyle Firstname agu_stdclass.inc:CharStyle Surname agu_stdclass.inc:CharStyle Filename agu_stdclass.inc:CharStyle Literal db_stdclass.inc:CharStyle Filename db_stdclass.inc:CharStyle Firstname db_stdclass.inc:CharStyle Surname db_stdclass.inc:CharStyle Literal stdclass.inc:CharStyle Noun For LyX 1.4, shouldn't we better remove the CharStyle "Noun" from stdclass.inc again? The rest is less controversial. Michael
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake thusly: > On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > > > Shouldn't we concentrate on bug fixing rather than starting new projects? > > I think we're all agreed that the current char style stuff (modulo some > minor changes in the way the insets look) should stay as is for now. Talking about looks, see the attached. I need to do some cleaning on the patch still, but this works, and not just sort-of. What is unelegant about it is that it still bases CharStyle on Collapsable, though it is forced permanently into Inlined mode. There should be a way to base it directly off UpdatableInset (right?) but I didn't get anywhere trying. You remove/restore the blue label by right mouse clicking the inset. Not very discoverable but I'm sure we can work on that :-) - Martin <> pgp0.pgp Description: PGP signature
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 07:14:18PM +0200, Martin Vermeer wrote: > Talking about looks, see the attached. Looks good regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake Martin> thusly: >> On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: >> >> > Shouldn't we concentrate on bug fixing rather than starting new >> projects? >> >> I think we're all agreed that the current char style stuff (modulo >> some minor changes in the way the insets look) should stay as is >> for now. Martin> Talking about looks, see the attached. What about putting the blue label on the frame of the inset like |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. JMarc
Re: CharStyle discussion
Jean-Marc Lasgouttes wrote: Martin> Talking about looks, see the attached. Looks good, Martin! |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. Ha! That was exactly _my_ idea (about 15 seconds ago) :-) I think the red frame should be removed, if possible, since (a) it occupies some space and (b) looks too eye-catching. However, we might need the red box for insets that span more than one row. Martin, can we check whether an inset is a one-liner or not and output it differently in both possible cases? That would be (nearly) perfect! Michael
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 06:25:24PM +0100, Michael Schmitt spake thusly:
> Jean-Marc Lasgouttes wrote:
>
> > Martin> Talking about looks, see the attached.
>
> Looks good, Martin!
>
> >
> > |some contents here|
> > name
> >
> > This would reduce the height of the inset...
>
>
> > You can even do
> > some contents here
> > \---name-/
> > and avoid the frame altogether.
>
> Ha! That was exactly _my_ idea (about 15 seconds ago) :-)
>
> I think the red frame should be removed, if possible, since (a) it
> occupies some space and (b) looks too eye-catching.
>
> However, we might need the red box for insets that span more than one
> row. Martin, can we check whether an inset is a one-liner or not and
> output it differently in both possible cases? That would be (nearly)
> perfect!
>
> Michael
That isn't quite so easy... feel free to try ;-)
I tightened up the thing a little bit. The patch is attached.
I think this is such a clear improvement on what we had, that this
should go in as it stands, despite small quirks (which I am not even
sure have to do with the patch). I think we have at least the right
visual model now.
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C4 Dec 2003 21:31:08 -
@@ -25,6 +25,8 @@
#include "metricsinfo.h"
#include "paragraph.h"
+#include "frontends/font_metrics.h"
+#include "frontends/Painter.h"
#include "support/std_sstream.h"
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName("CharStyle");
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const & bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs->name;
params_.latextype = cs->latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const & in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,41 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const & buf, LyXLex & lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = "Style: " + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
+void InsetCharStyle::draw(PainterInfo & pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ InsetCollapsable::draw(pi, x, y);
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w), y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +135,17 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const & cmd,
idx_type & idx, pos_type & pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ default:
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ }
}
pgp0.pgp
Description: PGP signature
