Re: XML?
On Fri, Jan 29, 2010 at 11:18:02PM +0100, Peter Kümmel wrote: Again, maybe I'm too late, but: Is a switch to XML is really a good idea? XML is everywhere. That simple. regards john
Re: XML?
On Fri, Jan 29, 2010 at 11:18:02PM +0100, Peter Kümmel wrote: > Again, maybe I'm too late, but: > Is a switch to XML is really a good idea? XML is everywhere. That simple. regards john
Re: Lyx + Boost and gcc 4.4
On Thu, Mar 05, 2009 at 01:23:26AM +0100, Lars Gullik Bjønnes wrote: But I must say if that is the most recent developemtn tools on solaris it is hugely useless as a development platform (and I don't belive it is). I get the impression most C++ people on Solaris are using Sun Studio. There must be something newer? Not yet but not too long hopefully. 3.4.3 is heavily patched for various Sun fixes so it's not entirely trivial to get GCC4 in place. regards john
Re: Lyx + Boost and gcc 4.4
On Thu, Mar 05, 2009 at 01:23:26AM +0100, Lars Gullik Bjønnes wrote: > But I must say if that is the most recent developemtn tools on solaris > it is hugely useless as a development platform (and I don't belive it > is). I get the impression most C++ people on Solaris are using Sun Studio. > There must be something newer? Not yet but not too long hopefully. 3.4.3 is heavily patched for various Sun fixes so it's not entirely trivial to get GCC4 in place. regards john
Re: menu structure
On Wed, Sep 17, 2008 at 06:49:05PM +0200, Jean-Marc Lasgouttes wrote: And about the discussion if we should merge View and Window - menu: Every application I seen on my desktop, all Apple apps, all Mozilla apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW menu, and there is a rationale behind it. Neither Word, OO or any of my Text-Editors has a Document-menu. I would be nice to dig the old thread concerning the current menu structure. John Levon had a pretty through analysis of Higs at the time. I've been idly watching this thread. It's obviously unfair of me to complain about anything since it's been so long since I did something useful, but I do think if Edwin wants to re-work everything, it'd be good if he did the same kind of analysis I did first time around: - what the biggest problems are with the current structure - why a new structure would help - the guiding principles behind the design of the new structure - what each of the main HIGs have to say about both the old and new setup I'm not necessarily saying that a re-org shouldn't happen, but I do think people should bear in mind that all menu structures have problems, and all re-workings cause a lot of upheaval. That is, you'd better be pretty sure that the new system is so much better that it's worth pissing off your users. I thought so, and gained enough consensus to commit the changes, but I know there's still LyX hackers around who disagreed with me on this the *first* time round. I did this back in the day, so I'm aware of the kind of scars you can accumulate by upsetting folks in this way :) cheers, john
Re: menu structure
On Thu, Sep 18, 2008 at 01:03:38AM +0200, [EMAIL PROTECTED] wrote: 1) The number of items is very big. Do we have any room to grow ? Oowriter interface is a clone of the old Word interface that was considered a 3) There is IMHO useless complexity, like the 7 different preview formats. If we just drop everything except pdf with a simple parser that would run aficionados) 4) Mathematics is a big elephant with a gigantic bottom crushing everybody. I don't have Mathematica, neither Maple, I don't write formulas in Fraktur. 5) There is some dead wood. Does Fax works anymore across platforms ? 6) The version control items are for geek. It should be done through macros and then every geek can choose its favorite version control system. All of these are true of any potential re-org. You want to remove some menu items into optional LyX modules: great (old) idea, but doesn't need a menu re-org. Please do this, it would be very cool. - why a new structure would help The Web is full of articles investigating how people navigate in a tree. It shows that if the tree is balanced with not too many levels and items are structured in a logical way, people find the good item quicker. I'll be very impressed if you can find a balanced menu layout that makes sense logically, and is significantly better than the existing one :) - the guiding principles behind the design of the new structure 1) Recreate a balanced tree by exploding the Insert menu 2) The Edit menu had become something very strange 3) Isolation of a Math menu starts the path towards Activity menus. I'd be interested to see what you're suggesting, though I believe it should be incremental during the development period (done by release, of course). Could you further explain point 2) ? Somewhere in the archives I have a detailed explanation of why the Edit menu is the way it is. regards, john
Re: menu structure
On Wed, Sep 17, 2008 at 06:49:05PM +0200, Jean-Marc Lasgouttes wrote: > > And about the discussion if we should merge View and Window - menu: > > Every application I seen on my desktop, all Apple apps, all Mozilla > > apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW > > menu, and there is a rationale behind it. > > Neither Word, OO or any of my Text-Editors has a Document-menu. > > I would be nice to dig the old thread concerning the current menu > structure. John Levon had a pretty through analysis of Higs at the > time. I've been idly watching this thread. It's obviously unfair of me to complain about anything since it's been so long since I did something useful, but I do think if Edwin wants to re-work everything, it'd be good if he did the same kind of analysis I did first time around: - what the biggest problems are with the current structure - why a new structure would help - the guiding principles behind the design of the new structure - what each of the main HIGs have to say about both the old and new setup I'm not necessarily saying that a re-org shouldn't happen, but I do think people should bear in mind that all menu structures have problems, and all re-workings cause a lot of upheaval. That is, you'd better be pretty sure that the new system is so much better that it's worth pissing off your users. I thought so, and gained enough consensus to commit the changes, but I know there's still LyX hackers around who disagreed with me on this the *first* time round. I did this back in the day, so I'm aware of the kind of scars you can accumulate by upsetting folks in this way :) cheers, john
Re: menu structure
On Thu, Sep 18, 2008 at 01:03:38AM +0200, [EMAIL PROTECTED] wrote: > 1) The number of items is very big. Do we have any room to grow ? Oowriter > interface is a clone of the old Word interface that was considered a > > 3) There is IMHO useless complexity, like the 7 different preview formats. > If we just drop everything except pdf with a simple parser that would run > aficionados) > 4) Mathematics is a big elephant with a gigantic bottom crushing everybody. > I don't have Mathematica, neither Maple, I don't write formulas in Fraktur. > 5) There is some dead wood. Does Fax works anymore across platforms ? > > 6) The version control items are for geek. It should be done through macros > and then every geek can choose its favorite version control system. All of these are true of any potential re-org. You want to remove some menu items into optional LyX modules: great (old) idea, but doesn't need a menu re-org. Please do this, it would be very cool. > > - why a new structure would help > > The Web is full of articles investigating how people navigate in a tree. It > shows that if the tree is balanced with not too many levels and items are > structured in a logical way, people find the good item quicker. I'll be very impressed if you can find a balanced menu layout that makes sense logically, and is significantly better than the existing one :) > > - the guiding principles behind the design of the new structure > > 1) Recreate a balanced tree by exploding the Insert menu > 2) The Edit menu had become something very strange > 3) Isolation of a Math menu starts the path towards Activity menus. I'd be interested to see what you're suggesting, though I believe it should be incremental during the development period (done by release, of course). Could you further explain point 2) ? Somewhere in the archives I have a detailed explanation of why the Edit menu is the way it is. regards, john
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 08:49:07AM +0200, Abdelrazak Younes wrote: You already failed. Why would I get used to it, when I can just go use TeXMacs and mark my stuff up as I like? But you (as a user) are free to go use other software (and apparently you do already). Finger painting is not our niche as far as I know. The typical Word or OO user has to unlearn a lot of things to use LyX efficiently, that would be another thing. The things they are unlearning are bad things. Natural selection* is not a bad thing, but you're making them unlearn it anyway. For what advantange? Ease of implementation as far as I can tell. regards john * I'm sorry.
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 08:02:05AM +0300, Martin Vermeer wrote: Isn't 'natural' usually better? These things feel like atoms, and inset-ness supports that. Not a big thing but anyway. I don't believe that people will think it's natural that selection jumps across an entire (say) firstname. If they feel that way, it is because they have been prejudiced by other applications... it _is_ natural. Rarely if ever will you want to select a piece of a firstname together with an adjoining piece of surname, e.g. Just doesn't happen. But as has been pointed out, this *IS* something you do with say code. Is it really worth maintaining this distinction, given how problematic it is? regards john
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 11:32:48AM +0200, Jean-Marc Lasgouttes wrote: I don't believe that people will think it's natural that selection jumps across an entire (say) firstname. When using using word (but not Oo.o), the selection jumps from word to word as soon as you are selecting more than one word. This is a feaure that I do not find annoying myself. Sure, that's pretty different thing though, in that you can break out of that decision as you mention regards john
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 08:49:07AM +0200, Abdelrazak Younes wrote: > >You already failed. Why would I get used to it, when I can just go use > >TeXMacs and mark my stuff up as I like? > > But you (as a user) are free to go use other software (and apparently > you do already). Finger painting is not our niche as far as I know. > The typical Word or OO user has to unlearn a lot of things to use LyX > efficiently, that would be another thing. The things they are unlearning are bad things. "Natural selection"* is not a bad thing, but you're making them unlearn it anyway. For what advantange? Ease of implementation as far as I can tell. regards john * I'm sorry.
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 08:02:05AM +0300, Martin Vermeer wrote: > > > Isn't 'natural' usually better? These things feel like atoms, > > > and inset-ness supports that. Not a big thing but anyway. > > > > I don't believe that people will think it's natural that selection jumps > > across an entire (say) . > > If they feel that way, it is because they have been prejudiced > by other applications... it _is_ natural. Rarely if ever will > you want to select a piece of a together with an > adjoining piece of , e.g. Just doesn't happen. But as has been pointed out, this *IS* something you do with say . Is it really worth maintaining this distinction, given how problematic it is? regards john
Re: *not* everything is an inset!
On Mon, Oct 08, 2007 at 11:32:48AM +0200, Jean-Marc Lasgouttes wrote: > > I don't believe that people will think it's natural that selection jumps > > across an entire (say) . > > When using using word (but not Oo.o), the selection jumps from word to > word as soon as you are selecting more than one word. This is a feaure > that I do not find annoying myself. Sure, that's pretty different thing though, in that you can break out of that decision as you mention regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:53:14PM +0300, Martin Vermeer wrote: I don't think you are. Do you seriously think I am that dogmatic? Come on. I can recognise a use case where insets are a plain bad idea. I don't think you're dogmatic. I'm genuinely interested in what makes CT insets fail for you but style insets work. I have my own reasons for CT insets being an awful idea, but they mostly apply to style insets too. You're serious about this aren't you? How would you do it? Two inset types deleted text and inserted text, right? And then you have to handle Delete, Backspace and typing characters: typing Del the first time creates a Deleted inset; second and later times will move characters from the right into the inset. Etc. Backspace works naturally, deleting inserted chars leftward. Is this what you mean? Sure you could do it. I would expect I'm not really interested in implementation. This thread is all about the UI, that's what REALLY matters. Given your other post it seems that you'd actually be for an inset-based CT UI. You are at least consistent :) regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 08:46:47PM +0300, Martin Vermeer wrote: Let me see: is your UI objection due to the fact that running text is linear, a narrative, and insets break that logic (selection, cursor movement, line breaking)? That seems like a fair summation. If so (a sensible argument), than for CT the argument becomes IMO invalid: here we have an indeed linear base narrative, but annotated with tentative additions and deletions, so no longer linear. And in CT mode, operations like select, cut and paste are anyway tightly circumscribed. Yes, there's actually /more/ of an argument for CT insets than style insets I think. However, my usual objections still apply I think. It'd still be jarring to have the cursor behave strangely just because a word has been inserted. How does that carry over to text styles? For mark-up such as emph, if it extends over some length of text, I see your point. But for other cases of well-defined semantic mark-up such as noun, I disagree. These are always short, self-contained, (well you may want to correct a person's name if spelled wrong but that's it), and essentially 'atoms' or single characters from the narrative POV. The same for the many short elements defined in XML. Those are natural insets. I understand what you're all saying about this difference. I think it's a fair thing to point out. However, I'm extremely dubious that it makes sense for the UI to express this semantic difference. How does this advantage the user? I don't remember seeing a clear answer to this question. And BTW you may exclude implementation from this argument, but in real life it _is_ along. Coding resources are limited, and other things being equal or close, it should be looked at. An implemented, good UI beats a perfect one that requires prohibitive implementation _and_ maintenance resources... I just about managed to get CT working and that was way harder. I'm entirely confident in the LyX team's ability to implement a range based style feature and make it maintainable. Since it seems the claim that inset code can provide a non-inset based UI has been dropped, the argument is pretty much entirely about an inset UI vs. a ranges UI I think. It's ultimately dangerous to consider implementation when arguing this, since you already have the inset code pretty much done, and lethargy tends to be a compelling argument :/ regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 10:13:54PM +0300, Martin Vermeer wrote: sense for the UI to express this semantic difference. How does this advantage the user? I don't remember seeing a clear answer to this question. Isn't 'natural' usually better? These things feel like atoms, and inset-ness supports that. Not a big thing but anyway. I don't believe that people will think it's natural that selection jumps across an entire (say) firstname. Ability yes. Resources... at the expense of what? Inset-based charstyles work here and now. Indeed, perfect is the enemy of the good. Most likely all this discussion will make no difference. But at least we tried. regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 09:41:11PM +0200, Abdelrazak Younes wrote: I don't believe that people will think it's natural that selection jumps across an entire (say) firstname. Even if so, once he gets used to it and realize how everything is faster ^^ You already failed. Why would I get used to it, when I can just go use TeXMacs and mark my stuff up as I like? Or even OpenOffice, which already does styles so much better than LyX does? john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:53:14PM +0300, Martin Vermeer wrote: > > > I don't think you are. Do you seriously think I am that > > > dogmatic? Come on. I can recognise a use case where insets > > > are a plain bad idea. > > > > I don't think you're dogmatic. I'm genuinely interested in what makes CT > > insets fail for you but style insets work. I have my own reasons for CT > > insets being an awful idea, but they mostly apply to style insets too. > > You're serious about this aren't you? How would you do it? Two > inset types "deleted text" and "inserted text", right? And > then you have to handle Delete, Backspace and typing > characters: typing Del the first time creates a Deleted inset; > second and later times will move characters from the right > into the inset. Etc. Backspace works naturally, deleting > inserted chars leftward. > > Is this what you mean? Sure you could do it. I would expect I'm not really interested in implementation. This thread is all about the UI, that's what REALLY matters. Given your other post it seems that you'd actually be for an inset-based CT UI. You are at least consistent :) regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 08:46:47PM +0300, Martin Vermeer wrote: > Let me see: is your UI objection due to the fact that running > text is linear, a narrative, and insets break that logic > (selection, cursor movement, line breaking)? That seems like a fair summation. > If so (a sensible argument), than for CT the argument becomes > IMO invalid: here we have an indeed linear base narrative, but > annotated with tentative additions and deletions, so no longer > linear. And in CT mode, operations like select, cut and paste > are anyway tightly circumscribed. Yes, there's actually /more/ of an argument for CT insets than style insets I think. However, my usual objections still apply I think. It'd still be jarring to have the cursor behave "strangely" just because a word has been inserted. > How does that carry over to text styles? For mark-up such as > emph, if it extends over some length of text, I see your point. > But for other cases of well-defined semantic mark-up such as > noun, I disagree. These are always short, self-contained, > (well you may want to correct a person's name if spelled wrong > but that's it), and essentially 'atoms' or single characters > from the narrative POV. > > The same for the many short elements defined in XML. Those are > natural insets. I understand what you're all saying about this difference. I think it's a fair thing to point out. However, I'm extremely dubious that it makes sense for the UI to express this semantic difference. How does this advantage the user? I don't remember seeing a clear answer to this question. > And BTW you may exclude implementation from this argument, but > in real life it _is_ along. Coding resources are limited, and > other things being equal or close, it should be looked at. An > implemented, good UI beats a perfect one that requires > prohibitive implementation _and_ maintenance resources... I just about managed to get CT working and that was way harder. I'm entirely confident in the LyX team's ability to implement a range based style feature and make it maintainable. Since it seems the claim that inset code can provide a non-inset based UI has been dropped, the argument is pretty much entirely about an inset UI vs. a ranges UI I think. It's ultimately dangerous to consider implementation when arguing this, since you already have the inset code pretty much done, and lethargy tends to be a compelling argument :/ regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 10:13:54PM +0300, Martin Vermeer wrote: > > sense for the UI to express this semantic difference. How does this > > advantage the user? I don't remember seeing a clear answer to this > > question. > > Isn't 'natural' usually better? These things feel like atoms, > and inset-ness supports that. Not a big thing but anyway. I don't believe that people will think it's natural that selection jumps across an entire (say) . > Ability yes. Resources... at the expense of what? Inset-based > charstyles work here and now. Indeed, perfect is the enemy of the good. Most likely all this discussion will make no difference. But at least we tried. regards john
Re: *not* everything is an inset!
On Sun, Oct 07, 2007 at 09:41:11PM +0200, Abdelrazak Younes wrote: > >I don't believe that people will think it's natural that selection jumps > >across an entire (say) . > > Even if so, once he gets used to it and realize how everything is faster ^^ You already failed. Why would I get used to it, when I can just go use TeXMacs and mark my stuff up as I like? Or even OpenOffice, which already does styles so much better than LyX does? john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 08:05:22AM +0200, Andre Poenitz wrote: Well indeed. This makes me somewhat dubious that your experience is relevant. I'm not anti-inset in any way where they make sense, and I think the branches stuff is a great example. I'm somewhat bemused by your comments regarding spaces. There's a massive difference between something that's ommitted from the document altogether, and something that ends up being rendered as an italic space or whatever. We already have DESM[1]. Why would this stop working? Styles do not make this different. There's really two cases: stylefoo /stylebar foostyle bar/style It's perfectly fine for us to strip these in the output (that is, styles never end or begin on a space). It is not, as spaces with differnt style might show differently. In some programming font they may even print something. I'm not sure might or may is useful. Is there a case when something DOES do that, and cannot be adequately covered by the protected space mechanism? john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 08:12:28AM +0200, Andre Poenitz wrote: The only thing I could ask for here, is to see the borders also when the cursor is right in front of the inset, because the delete key will delete the entire inset if used at that point. That is obvious if the frame is there, not so if it isn't. Hmmm... not so easy. ;-/ On first 'Delete' select the inset, on second 'Delete' delete it. Why would delete select? Shouldn't delete delete? Not if the chunk is larger than you'd might expect. You're tying yourself up in knots precisely because you won't do the right thing: delete the character in front of the cursor. In this case it is not even annoying to have to press delet twice. We've done that for math for a few years now and nobody complained. Before that we had a few complaints about not knowing what will get deleted. Mathed is different. I don't know how many times I have to say this before it sinks in :( regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:44:38AM +0200, Abdelrazak Younes wrote: 1) familiarity. This is how every other editor I'm familiar with works. This one is not an argument for me. Otherwise I'd still use MS Word. I am 80% sure that the success of LyX is in its ability to mix simplicity with power. Looking like word but not acting like word is a plus. I agree but John's argument is about _acting_ like word too. And this is where I disagree. You seem to be arguing that when we have two otherwise equal choices, and one behaves like Word, we should choose the other one. I really can't argue with a logic like this. regards john
Re: Inset Compromise Proposal
On Fri, Oct 05, 2007 at 07:42:41PM +0300, Martin Vermeer wrote: Actually I came to more or less the same view. So: - Noun should become an inset charstyle (lyx2lyx) - Strong should take a similar slot as Emph, i.e. a (non-inset) font attribute. But: - Code should be an inset charstyle. Something either is, or isn't, code. Objective meaning. Sounds like a plan? I'm totally confused by this plan. It does not fix ANY of the problems. It's also somewhat suspiciously close to let's do nothing and hope things are OK. john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 05:32:42PM +0100, John Levon wrote: I think John understand our point of view very well but he's playing the devil's advocate. Not at all. I genuinely don't understand how anybody could think that editing equations is like editing prose. (I'd love to be able to capture proof on this via mouse movements, eye tracking etc. but I'm hardly capable of such a set up.) regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 12:34:33PM +0200, Dov Feldstern wrote: I actually agree with Andre' here, this would be good behavior for *true* insets IMO. Agreed, I think it's a nice solution to the delete a footnote problem, with perhaps the change that it only applies if the inset is not collapsed. regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 09:02:03AM +0200, Abdelrazak Younes wrote: I think John understand our point of view very well but he's playing the devil's advocate. Not at all. I genuinely don't understand how anybody could think that editing equations is like editing prose. regards, john
Re: [Cvslog] r20690 - /lyx-devel/trunk/src/frontends/qt4/ui/WrapUi.ui
On Fri, Oct 05, 2007 at 08:38:27AM +0200, Abdelrazak Younes wrote: it is obvious that if the user doesn't check those boxes the parameters won't be set. and as i wrote, if we would do this we will deviate from what we are doing in the rest of lyx. Maybe Uwe thinks of them as Advanced options? In this case, those should probably go in an advanced dialog or tab. Advanced tabs are always a mistake. https://bugzilla.mozilla.org/show_bug.cgi?id=216931 regards, john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 07:59:11PM +0300, Martin Vermeer wrote: Change tracking. Initially it was crippled and very limited, then I partly un-crippled it, and then Michael put in _a lot_ of effort to iron all the bugs out and instill some sanity. Yes, change tracking was tough, and fixing it looked even tougher (I can only apologise ;) However, I'm far from convinced that it's the same as text styles. The difficult stuff is all around things like delete doesn't really mean delete. (Unfortunately insets are no good for CT) Interesting, why? From what I can see it seems that all the inset people's preferences apply just the same to CT. regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 07:00:41PM +0200, Abdelrazak Younes wrote: Not at all. I genuinely don't understand how anybody could think that editing equations is like editing prose. Well, I am a scientist and I often have the need to apply the same style to some specific words. These words are independent entities for me, I don't want to split them or half select them. Is it a bit clearer or is my use case completely strange? Your use case is completely understandable. Indeed, I expect that's how a lot of markup will work, /but significantly less than all/. All the other objections still apply. We need to cater for I'm just marking words, really /along with/ the other cases. Insets make this hard, and words-as-insets make this even harder, unless you abandon things like sensible cursor movement and selection as it seems you want to. (I'd love to be able to capture proof on this via mouse movements, eye tracking etc. but I'm hardly capable of such a set up.) I don't follow you here... I'd love to be able to prove that people interact with prose text differently from equations, by getting a lab and measuring it. Unfortunately I don't know of any studies and clearly I can't do it myself. regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 06:54:09PM +0200, Abdelrazak Younes wrote: You seem to be arguing that when we have two otherwise equal choices, and one behaves like Word, we should choose the other one. No, I meant that, in this _specific_ case, I hate the way MS Word behaves and we should do the same just because Word does it, that's all. I don't know how it's possible to read what I've been saying and think I just want LyX to behave like Word :( It's most certainly not about that. john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 07:09:31PM +0200, Abdelrazak Younes wrote: The font-related RTL business and the boundary stuff is far far from easy. Look at the different getFont() method and you will see how this stuff is complicated. RTL is hard full stop, I'm not sure that's related to styles at all regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 08:34:24PM +0300, Martin Vermeer wrote: (Unfortunately insets are no good for CT) Interesting, why? From what I can see it seems that all the inset people's preferences apply just the same to CT. Funny :-( I'm serious, I don't understand why it's different for you? regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 08:59:45PM +0200, Andre Poenitz wrote: I think John understand our point of view very well but he's playing the devil's advocate. Not at all. I genuinely don't understand how anybody could think that editing equations is like editing prose. You are not a mathematician, are you? No. regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:23:58PM +0300, Martin Vermeer wrote: (Unfortunately insets are no good for CT) Interesting, why? From what I can see it seems that all the inset people's preferences apply just the same to CT. Funny :-( I'm serious, I don't understand why it's different for you? I don't think you are. Do you seriously think I am that dogmatic? Come on. I can recognise a use case where insets are a plain bad idea. I don't think you're dogmatic. I'm genuinely interested in what makes CT insets fail for you but style insets work. I have my own reasons for CT insets being an awful idea, but they mostly apply to style insets too. regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 08:05:22AM +0200, Andre Poenitz wrote: > > Well indeed. This makes me somewhat dubious that your experience is > > relevant. I'm not anti-inset in any way where they make sense, and I > > think the branches stuff is a great example. > > > > I'm somewhat bemused by your comments regarding spaces. There's a > > massive difference between something that's ommitted from the document > > altogether, and something that ends up being rendered as an italic space > > or whatever. We already have DESM[1]. Why would this stop working? > > Styles do not make this different. > > > > There's really two cases: > > > > foo bar > > foo bar > > > > It's perfectly fine for us to strip these in the output (that is, styles > > never end or begin on a space). > > It is not, as spaces with differnt style might show differently. In some > "programming font" they may even print something. I'm not sure "might" or "may" is useful. Is there a case when something DOES do that, and cannot be adequately covered by the protected space mechanism? john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 08:12:28AM +0200, Andre Poenitz wrote: > > > > > The only thing I could ask for here, is to see the borders also when > > > > > the cursor is right in front of the inset, because the "delete" key > > > > > will delete the entire inset if used at that point. That is obvious if > > > > > the frame is there, not so if it isn't. > > > > > > > > Hmmm... not so easy. ;-/ > > > > > > On first 'Delete' select the inset, on second 'Delete' delete it. > > > > Why would delete select? Shouldn't delete delete? > > Not if the chunk is larger than you'd might expect. You're tying yourself up in knots precisely because you won't do the right thing: delete the character in front of the cursor. > In this case it is not even annoying to have to press delet twice. > We've done that for math for a few years now and nobody complained. > Before that we had a few complaints about "not knowing what will get > deleted". Mathed is different. I don't know how many times I have to say this before it sinks in :( regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:44:38AM +0200, Abdelrazak Younes wrote: > >>>1) familiarity. This is how every other editor I'm familiar with works. > >>This one is not an argument for me. Otherwise I'd still use MS Word. > > > >I am 80% sure that the success of LyX is in its ability to mix > >simplicity with power. Looking like word but not acting like word is a > >plus. > > I agree but John's argument is about _acting_ like word too. And this is > where I disagree. You seem to be arguing that when we have two otherwise equal choices, and one behaves like Word, we should choose the other one. I really can't argue with a "logic" like this. regards john
Re: Inset Compromise Proposal
On Fri, Oct 05, 2007 at 07:42:41PM +0300, Martin Vermeer wrote: > Actually I came to more or less the same view. > > So: > > - Noun should become an inset charstyle (lyx2lyx) > - Strong should take a similar slot as Emph, i.e. > a (non-inset) "font" attribute. > > But: > > - Code should be an inset charstyle. Something either > is, or isn't, code. Objective meaning. > > Sounds like a plan? I'm totally confused by this plan. It does not fix ANY of the problems. It's also somewhat suspiciously close to "let's do nothing and hope things are OK." john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 05:32:42PM +0100, John Levon wrote: > > I think John understand our point of view very well but he's playing the > > devil's advocate. > > Not at all. I genuinely don't understand how anybody could think that > editing equations is like editing prose. (I'd love to be able to capture proof on this via mouse movements, eye tracking etc. but I'm hardly capable of such a set up.) regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 12:34:33PM +0200, Dov Feldstern wrote: > I actually agree with Andre' here, this would be good behavior for > *true* insets IMO. Agreed, I think it's a nice solution to the "delete a footnote" problem, with perhaps the change that it only applies if the inset is not collapsed. regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 09:02:03AM +0200, Abdelrazak Younes wrote: > I think John understand our point of view very well but he's playing the > devil's advocate. Not at all. I genuinely don't understand how anybody could think that editing equations is like editing prose. regards, john
Re: [Cvslog] r20690 - /lyx-devel/trunk/src/frontends/qt4/ui/WrapUi.ui
On Fri, Oct 05, 2007 at 08:38:27AM +0200, Abdelrazak Younes wrote: > >it is obvious that if the user doesn't check those boxes the parameters > >won't be set. and as i wrote, if we would do this we will deviate from > >what we are doing in the rest of lyx. > > Maybe Uwe thinks of them as "Advanced options"? In this case, those > should probably go in an advanced dialog or tab. "Advanced" tabs are always a mistake. https://bugzilla.mozilla.org/show_bug.cgi?id=216931 regards, john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 07:59:11PM +0300, Martin Vermeer wrote: > Change tracking. Initially it was crippled and very limited, > then I partly un-crippled it, and then Michael put in _a lot_ > of effort to iron all the bugs out and instill some sanity. Yes, change tracking was tough, and fixing it looked even tougher (I can only apologise ;) However, I'm far from convinced that it's the same as text styles. The difficult stuff is all around things like "delete doesn't really mean delete". > (Unfortunately insets are no good for CT) Interesting, why? From what I can see it seems that all the inset people's preferences apply just the same to CT. regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 07:00:41PM +0200, Abdelrazak Younes wrote: > >>Not at all. I genuinely don't understand how anybody could think that > >>editing equations is like editing prose. > > Well, I am a scientist and I often have the need to apply the same style > to some specific words. These words are independent entities for me, I > don't want to split them or half select them. Is it a bit clearer or is > my use case completely strange? Your use case is completely understandable. Indeed, I expect that's how a lot of markup will work, /but significantly less than all/. All the other objections still apply. We need to cater for "I'm just marking words, really" /along with/ the other cases. Insets make this hard, and words-as-insets make this even harder, unless you abandon things like sensible cursor movement and selection as it seems you want to. > >(I'd love to be able to capture proof on this via mouse movements, eye > >tracking etc. but I'm hardly capable of such a set up.) > > I don't follow you here... I'd love to be able to prove that people interact with prose text differently from equations, by getting a lab and measuring it. Unfortunately I don't know of any studies and clearly I can't do it myself. regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 06:54:09PM +0200, Abdelrazak Younes wrote: > >You seem to be arguing that when we have two otherwise equal choices, > >and one behaves like Word, we should choose the other one. > > No, I meant that, in this _specific_ case, I hate the way MS Word > behaves and we should do the same just because Word does it, that's all. I don't know how it's possible to read what I've been saying and think I just want LyX to behave like Word :( It's most certainly not about that. john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 07:09:31PM +0200, Abdelrazak Younes wrote: > The font-related RTL business and the boundary stuff is far far from > easy. Look at the different getFont() method and you will see how this > stuff is complicated. RTL is hard full stop, I'm not sure that's related to styles at all regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 08:34:24PM +0300, Martin Vermeer wrote: > > > (Unfortunately insets are no good for CT) > > > > Interesting, why? From what I can see it seems that all the inset > > people's preferences apply just the same to CT. > > Funny :-( I'm serious, I don't understand why it's different for you? regards john
Re: CharStyles As Insets: TODO
On Fri, Oct 05, 2007 at 08:59:45PM +0200, Andre Poenitz wrote: > > > I think John understand our point of view very well but he's playing the > > > devil's advocate. > > > > Not at all. I genuinely don't understand how anybody could think that > > editing equations is like editing prose. > > You are not a mathematician, are you? No. regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 10:23:58PM +0300, Martin Vermeer wrote: > > > > > (Unfortunately insets are no good for CT) > > > > > > > > Interesting, why? From what I can see it seems that all the inset > > > > people's preferences apply just the same to CT. > > > > > > Funny :-( > > > > I'm serious, I don't understand why it's different for you? > > I don't think you are. Do you seriously think I am that > dogmatic? Come on. I can recognise a use case where insets > are a plain bad idea. I don't think you're dogmatic. I'm genuinely interested in what makes CT insets fail for you but style insets work. I have my own reasons for CT insets being an awful idea, but they mostly apply to style insets too. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 10:13:59AM +0200, Jean-Marc Lasgouttes wrote: More seriously, this whole discussion comes a bit late IMHO. I know that you emitted some objections when Martin started the implementation but they were not too strong. We have something _now_ and I'd be a pity to revert it because you and others don't like it. No. I always said I had reservation about the interface, and was promised it was super easy to make it seamless. I'm sure that the insets people will never solve inset-spanning selection, cursor movement, or line-breaking flow. And they're just three of the bigger things that came up here. Already we are seeing justifications as to why they don't need to be fixed. It's somewhat hard to believe that this isn't due to the implementation rather than some UI design (at least Andre's desire to press 'right' five times to actually move the cursor *is* a UI design choice!). john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 06:46:45PM +0300, Martin Vermeer wrote: Not very convincing, is it? Most people learn from experience. What would happen here is that they would quickly pick up that -- no, this stuff does not behave like italicize; it behaves like insets instead. Familiar paradigm that too, though different. After that realization, everything becomes natural, and the above mistakes silly in retrospect. And soon the penny will drop on the many advantages. Could you list the advantages of an exposed inset UI? thanks john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 06:52:48PM +0300, Martin Vermeer wrote: Why do we need to nest insets then ? :-P Actually I don't think we should (usually). In text, cases where we want to nest (charstyle) insets ought to be rare, if we have defined them as sensible semantic units. Over-use of nesting is a sign that we maybe haven't. That's not correct. http://www.docbook.org/tdg/en/html/author.html regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:48:33PM +0200, Andre Poenitz wrote: And for The Honoured Believers in Single Keystroke Navigation (formerly known as The Finger Painting Faction) the multiple pos 5, range * positions can be collapsed to a single one. A simple boolean preference, maybe even togglable by C-S-M-fullMoon-F7 could steer this wihout any I'd be fine with an option to turn *on* 'logic navigation' or whatever. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:42:09PM +0300, Martin Vermeer wrote: Why do we need to nest insets then ? :-P Actually I don't think we should (usually). In text, cases where we want to nest (charstyle) insets ought to be rare, if we have defined them as sensible semantic units. Over-use of nesting is a sign that we maybe haven't. That's not correct. http://www.docbook.org/tdg/en/html/author.html regards john Yes, for docbook. And then only for parts of the document. In the running text it is rare. I don't consider docbook to be 'rare'. Or, say, nesting 'function' inside of 'codeblock' or whatever. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:28:25PM +0300, Martin Vermeer wrote: Could you list the advantages of an exposed inset UI? 1) You know precisely where a typed character goes -- or where an already typed character belongs. Inside or outside any given inset. A special case of this is for blanks, which don't display much in terms of rendering style. 2) The discipline of nesting is imposed corresponding to the logic of semantics. Meaning, in the semantic sense, typically forms a tree. Exceptions to that which I have seen are either more or less pathological, or esoteric. 3) No ambiguity about nesting order. I'm confused about the difference between 2 and 3. They sound like the same thing: an inset UI enforces, clearly, a hierarchical style tree. 4) Because of 2) and 3), no problems with our favourite back-ends, LaTeX and XML. I presume you're referring the specific case of getting certain style ligatures wrong when you have to decompose a non-hierarchical style system into a hier one, right? Otherwise it sounds like you're talking about implementation. Here are the user interface advantages I have for a ranges UI: 1) familiarity. This is how every other editor I'm familiar with works. In particular problems like what happens if I have some text with style selected, and choose another style can be solved in the same fashion as other programs, when it makes sense 2) The existence of a style attribute does not affect how and where I can select text 3) Selection never 'jumps' - it always starts at the point I started, and ends at the nearest character to the position of the pointer 4) all cursor movement is based upon what I can see 5) Line-wrapping looks and behaves naturally. Note that I'm not listing overlapping styles. I don't think that's an interesting use case. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 11:16:50PM +0300, Martin Vermeer wrote: Branches are not charstyles, of course. Well indeed. This makes me somewhat dubious that your experience is relevant. I'm not anti-inset in any way where they make sense, and I think the branches stuff is a great example. I'm somewhat bemused by your comments regarding spaces. There's a massive difference between something that's ommitted from the document altogether, and something that ends up being rendered as an italic space or whatever. We already have DESM[1]. Why would this stop working? Styles do not make this different. There's really two cases: stylefoo /stylebar foostyle bar/style It's perfectly fine for us to strip these in the output (that is, styles never end or begin on a space). I don't see the need to so in the UI. regards john [1] Delete Empty Spaces Mechanism, if you'll excuse me
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 12:06:50AM +0300, Martin Vermeer wrote: _Especially_ from the writing process viewpoint you should appreciate the ease with which you can undo things in the inset paradigm. Regret an applied emphasis? Put the cursor inside and dissolve. No need to carefully select the emphasized range like you would have to in the character range paradigm. That's a nice feature indeed but there's no reason we can't do it with ranges if we like. (Or use undo... but that option disappears if you did other things inbetween that you wish to keep.) Of course, we should have a full undo history (but I won't bang on about /that/ ...) regards john
charstyles don't redraw properly?
If I type into say a FirstName charstyle in docbook, the blue banner beneath just over-writes itself. I think it might be because Author is centered text. It doesn't happen after a certain inset size. Anyone else? I can see a similar thing during selection too. Copy and paste doesn't seem to carry the style with it. BTW, why do the styles appear as CharStyle:foo in the menu? regards john
Re: CharStyles As Insets: TODO
On Thu, Oct 04, 2007 at 11:22:01PM +0200, Andre Poenitz wrote: The only thing I could ask for here, is to see the borders also when the cursor is right in front of the inset, because the delete key will delete the entire inset if used at that point. That is obvious if the frame is there, not so if it isn't. Hmmm... not so easy. ;-/ On first 'Delete' select the inset, on second 'Delete' delete it. Why would delete select? Shouldn't delete delete? john
Re: charstyles don't redraw properly?
On Thu, Oct 04, 2007 at 09:52:52PM -0400, Richard Heck wrote: I don't think it was designed to do so. If it should, then that probably isn't terribly hard. I do think it should... BTW, why do the styles appear as CharStyle:foo in the menu? This is a consequence of some of Martin's recent work, which introduced layout-level configurability of these things, as well as layout-level user-definable collapsable insets. This is a bit of the cleanup that is still TODO. OK, cool regards john
Re: charstyles don't redraw properly?
On Fri, Oct 05, 2007 at 06:56:25AM +0300, Martin Vermeer wrote: If I type into say a FirstName charstyle in docbook, the blue banner beneath just over-writes itself. I think it might be because Author is centered text. It doesn't happen after a certain inset size. Anyone else? Thought I fixed this... apparently not. When? My build is a couple of days old Copy and paste doesn't seem to carry the style with it. BTW, why do the styles appear as CharStyle:foo in the menu? Ouch... should be Element:foo. Hmm, can't we have it in proper English? It looks like code! regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 06:37:05AM +0300, Martin Vermeer wrote: If what Martin means is that *LyX* will have no ambiguity, e.g, when generating latex/XML, then I think that the disambiguation algorithm suggested in this thread http://permalink.gmane.org/gmane.editors.lyx.devel/95997 (plus the refinement suggested by JMarc, which uses the extent of the ranges, see the whole thread) would solve any ambiguities that might arise with ranges; hence, this is not an advantage relative to ranges. Doesn't exist yet, and doesn't sound simple. It's also pretty self-contained. Sometimes we must take the hit of some slightly more complicated code for a better UI experience. 1) familiarity. This is how every other editor I'm familiar with works. In particular problems like what happens if I have some text with style selected, and choose another style can be solved in the same fashion as other programs, when it makes sense LyX wouldn't be LyX if this argument were applied more generally ;-) That's absolutely true. However, *unless we have good reason to* we should not diverge from what people are used to. ...and for LyX users, familiarity with many other inset types argues similarly for inset-type charstyles. I think this is the fundamental problem the inset people have: they think that the way people use mathed and insets now is somehow like the way they mark up blocks of text. It's simply not true. There are two cases you could claim here. First, we have footnotes, branches and the like. These contain normal text so seem superficially similar. However, even the footnotes-crazy social science people don't use insets as much as normal people would mark up text. More importantly though, navigation *through* such items is significantly less common (if this weren't true, then being able to collapse them wouldn't be so useful). It's quite different from the contents of a normal flow of text. Secondly, we have mathed. Equations are highly structured and require precise control in a way that normal text doesn't. You never need to type stuff like: c/d or b bc/d a a with normal text; more importantly, you never need to navigate such a structure. It's a completely different way of navigating and constructing output. There is no such familiarity. 2) The existence of a style attribute does not affect how and where I can select text 3) Selection never 'jumps' - it always starts at the point I started, and ends at the nearest character to the position of the pointer 2) and 3) are aspects of the same thing, and IMHO an inevitable consequence of hierarchy. They're an inevitable consequence of the way *you* enforce hierarchy. you could modify selection so you can have contiguous parts of different insets/main text -- but you could never apply a new style around that selection. Better leave it as it is. Um, absolutely not true of ranges. This will work fine. Try any other program out there. 4) all cursor movement is based upon what I can see Also true for the inset alternative if inset boundaries are visible. Which would make normal text pretty unreadable (much like it is now). regards, john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 10:13:59AM +0200, Jean-Marc Lasgouttes wrote: > > More seriously, this whole discussion comes a bit late IMHO. I know > > that you emitted some objections when Martin started the > > implementation but they were not too strong. We have something _now_ > > and I'd be a pity to revert it because you and others don't like it. > > No. I always said I had reservation about the interface, and was > promised it was super easy to make it seamless. I'm sure that the insets people will never solve inset-spanning selection, cursor movement, or line-breaking flow. And they're just three of the bigger things that came up here. Already we are seeing justifications as to why they don't need to be fixed. It's somewhat hard to believe that this isn't due to the implementation rather than some UI design (at least Andre's desire to press 'right' five times to actually move the cursor *is* a UI design choice!). john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 06:46:45PM +0300, Martin Vermeer wrote: > Not very convincing, is it? Most people learn from experience. What > would happen here is that they would quickly pick up that -- no, this > stuff does not behave like italicize; it behaves like insets instead. > Familiar paradigm that too, though different. After that realization, > everything becomes natural, and the above mistakes silly in retrospect. > And soon the penny will drop on the many advantages. Could you list the advantages of an exposed inset UI? thanks john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 06:52:48PM +0300, Martin Vermeer wrote: > > Why do we need to nest insets then ? :-P > > Actually I don't think we should (usually). In text, cases where we > want to nest (charstyle) insets ought to be rare, if we have defined > them as sensible semantic units. Over-use of nesting is a sign that > we maybe haven't. That's not correct. http://www.docbook.org/tdg/en/html/author.html regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:48:33PM +0200, Andre Poenitz wrote: > And for The Honoured Believers in Single Keystroke Navigation (formerly > known as The Finger Painting Faction) the multiple "pos 5, range *" > positions can be collapsed to a single one. A simple boolean preference, > maybe even togglable by C-S-M-fullMoon-F7 could steer this wihout any I'd be fine with an option to turn *on* 'logic navigation' or whatever. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:42:09PM +0300, Martin Vermeer wrote: > > > > Why do we need to nest insets then ? :-P > > > > > > Actually I don't think we should (usually). In text, cases where we > > > want to nest (charstyle) insets ought to be rare, if we have defined > > > them as sensible semantic units. Over-use of nesting is a sign that > > > we maybe haven't. > > > > That's not correct. > > > > http://www.docbook.org/tdg/en/html/author.html > > > > regards > > john > > Yes, for docbook. And then only for parts of the document. In the > running text it is rare. I don't consider docbook to be 'rare'. Or, say, nesting 'function' inside of 'codeblock' or whatever. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 09:28:25PM +0300, Martin Vermeer wrote: > > Could you list the advantages of an exposed inset UI? > > 1) You know precisely where a typed character goes -- or where an > already typed character belongs. Inside or outside any given inset. > A special case of this is for blanks, which don't display much in > terms of rendering style. > > 2) The discipline of nesting is imposed corresponding to the logic of > semantics. Meaning, in the semantic sense, typically forms a tree. > Exceptions to that which I have seen are either more or less > pathological, or esoteric. > > 3) No ambiguity about nesting order. I'm confused about the difference between 2 and 3. They sound like the same thing: an inset UI enforces, clearly, a hierarchical style tree. > 4) Because of 2) and 3), no problems with our favourite back-ends, LaTeX > and XML. I presume you're referring the specific case of getting certain style "ligatures" wrong when you have to decompose a non-hierarchical style system into a hier one, right? Otherwise it sounds like you're talking about implementation. Here are the user interface advantages I have for a ranges UI: 1) familiarity. This is how every other editor I'm familiar with works. In particular problems like "what happens if I have some text with style selected, and choose another style" can be solved in the same fashion as other programs, when it makes sense 2) The existence of a style attribute does not affect how and where I can select text 3) Selection never 'jumps' - it always starts at the point I started, and ends at the nearest character to the position of the pointer 4) all cursor movement is based upon what I can see 5) Line-wrapping looks and behaves naturally. Note that I'm not listing overlapping styles. I don't think that's an interesting use case. regards john
Re: *not* everything is an inset!
On Thu, Oct 04, 2007 at 11:16:50PM +0300, Martin Vermeer wrote: > Branches are not charstyles, of course. Well indeed. This makes me somewhat dubious that your experience is relevant. I'm not anti-inset in any way where they make sense, and I think the branches stuff is a great example. I'm somewhat bemused by your comments regarding spaces. There's a massive difference between something that's ommitted from the document altogether, and something that ends up being rendered as an italic space or whatever. We already have DESM[1]. Why would this stop working? Styles do not make this different. There's really two cases: foo bar foo bar It's perfectly fine for us to strip these in the output (that is, styles never end or begin on a space). I don't see the need to so in the UI. regards john [1] Delete Empty Spaces Mechanism, if you'll excuse me
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 12:06:50AM +0300, Martin Vermeer wrote: > _Especially_ from the writing process viewpoint you should appreciate > the ease with which you can undo things in the inset paradigm. Regret an > applied emphasis? Put the cursor inside and dissolve. No need to > carefully select the emphasized range like you would have to in the > character range paradigm. That's a nice feature indeed but there's no reason we can't do it with ranges if we like. > (Or use undo... but that option disappears if > you did other things inbetween that you wish to keep.) Of course, we should have a full undo history (but I won't bang on about /that/ ...) regards john
charstyles don't redraw properly?
If I type into say a FirstName charstyle in docbook, the blue banner beneath just over-writes itself. I think it might be because Author is centered text. It doesn't happen after a certain inset size. Anyone else? I can see a similar thing during selection too. Copy and paste doesn't seem to carry the style with it. BTW, why do the styles appear as CharStyle:foo in the menu? regards john
Re: CharStyles As Insets: TODO
On Thu, Oct 04, 2007 at 11:22:01PM +0200, Andre Poenitz wrote: > > > The only thing I could ask for here, is to see the borders also when > > > the cursor is right in front of the inset, because the "delete" key > > > will delete the entire inset if used at that point. That is obvious if > > > the frame is there, not so if it isn't. > > > > Hmmm... not so easy. ;-/ > > On first 'Delete' select the inset, on second 'Delete' delete it. Why would delete select? Shouldn't delete delete? john
Re: charstyles don't redraw properly?
On Thu, Oct 04, 2007 at 09:52:52PM -0400, Richard Heck wrote: > I don't think it was designed to do so. If it should, then that probably > isn't terribly hard. I do think it should... > >BTW, why do the styles appear as CharStyle:foo in the menu? > > > This is a consequence of some of Martin's recent work, which introduced > layout-level configurability of these things, as well as layout-level > user-definable collapsable insets. This is a bit of the cleanup that is > still TODO. OK, cool regards john
Re: charstyles don't redraw properly?
On Fri, Oct 05, 2007 at 06:56:25AM +0300, Martin Vermeer wrote: > > If I type into say a FirstName charstyle in docbook, the blue banner > > beneath just over-writes itself. I think it might be because Author is > > centered text. It doesn't happen after a certain inset size. Anyone else? > > Thought I fixed this... apparently not. When? My build is a couple of days old > > Copy and paste doesn't seem to carry the style with it. > > > > BTW, why do the styles appear as CharStyle:foo in the menu? > > Ouch... should be Element:foo. Hmm, can't we have it in proper English? It looks like code! regards john
Re: *not* everything is an inset!
On Fri, Oct 05, 2007 at 06:37:05AM +0300, Martin Vermeer wrote: > > If what Martin means is that *LyX* will have no ambiguity, e.g, when > > generating latex/XML, then I think that the disambiguation algorithm > > suggested in this thread > > http://permalink.gmane.org/gmane.editors.lyx.devel/95997 (plus the > > refinement suggested by JMarc, which uses the extent of the ranges, see > > the whole thread) would solve any ambiguities that might arise with > > ranges; hence, this is not an advantage relative to ranges. > > Doesn't exist yet, and doesn't sound simple. It's also pretty self-contained. Sometimes we must take the hit of some slightly more complicated code for a better UI experience. > > >1) familiarity. This is how every other editor I'm familiar with works. > > >In particular problems like "what happens if I have some text with style > > >selected, and choose another style" can be solved in the same fashion as > > >other programs, when it makes sense > > LyX wouldn't be LyX if this argument were applied more generally ;-) That's absolutely true. However, *unless we have good reason to* we should not diverge from what people are used to. > ...and for LyX users, familiarity with many other inset types argues > similarly for inset-type charstyles. I think this is the fundamental problem the inset people have: they think that the way people use mathed and insets now is somehow like the way they mark up blocks of text. It's simply not true. There are two cases you could claim here. First, we have footnotes, branches and the like. These contain normal text so seem superficially similar. However, even the footnotes-crazy social science people don't use insets as much as normal people would mark up text. More importantly though, navigation *through* such items is significantly less common (if this weren't true, then being able to collapse them wouldn't be so useful). It's quite different from the contents of a "normal" flow of text. Secondly, we have mathed. Equations are highly structured and require precise control in a way that normal text doesn't. You never need to type stuff like: c/d or b bc/d a a with normal text; more importantly, you never need to navigate such a structure. It's a completely different way of navigating and constructing output. There is no such familiarity. > > >2) The existence of a style attribute does not affect how and where I > > >can select text > > > > > >3) Selection never 'jumps' - it always starts at the point I started, > > >and ends at the nearest character to the position of the pointer > > 2) and 3) are aspects of the same thing, and IMHO an inevitable > consequence of hierarchy. They're an inevitable consequence of the way *you* enforce hierarchy. > you could modify selection so you can have contiguous parts of > different insets/main text -- but you could never apply a new style > around that selection. Better leave it as it is. Um, absolutely not true of ranges. This will work fine. Try any other program out there. > > >4) all cursor movement is based upon what I can see > > Also true for the inset alternative if inset boundaries are visible. Which would make normal text pretty unreadable (much like it is now). regards, john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 08:25:12AM +0200, Abdelrazak Younes wrote: However, insets imply all sorts of things about cursor movement and mouse placement. Unless things in this area got *massively* cleaned up since I last looked at the code, getting correct cursor movement with char-ranges-as-insets will not be easy. We will face challenge for sure but Cursor movement is already working well for entering and leaving insets. We will have to decide what to do That's true for the current insets, absolutely *not* for char styles. It's not acceptable for it to need two keypresses to get from a to b in 'ab' just because a has a different char style. with selection though. I am in the opinion that when coming outside of an inset, whatever it is (charstyle included), we should select the full insets. Right now, the implementation offers no other choice in any case. This is also a difficult UI problem that will frustrate people I think. Imagine if I have: blah blah __blah foo foo__ and I want to reset the third blah to have no style like the others. It'll be immensely annoying to have to carefully select just up to the 'b' (any further, and you'll have the whole inset). regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:12:22PM +0200, Jean-Marc Lasgouttes wrote: We will face challenge for sure but Cursor movement is already working well for entering and leaving insets. We will have to decide what to do with selection though. I am in the opinion that when coming outside of an inset, whatever it is (charstyle included), we should select the full insets. Right now, the implementation offers no other choice in any case. I think this would be very unintuitive behavior in the case of character styles. I do not think so. I have yet to see of a good example where overlapping extents are useful (do you have a better example than the TEI one?). We should not design the UI around a weird case. This isn't about overlapping extents as I see it, it's about a natural feel for the UI. In particular, if I click-drag at point A in this diagram: foo bar C foo bar A foo bar foo bar B and drag towards B, it will prove extremely annoying that my selection changes to cover C too. That's not what I asked for! It's OK with today's insets because they're clearly separate chunks of text. john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 10:03:32AM +0200, Andre Poenitz wrote: Of course this would emphasize structure and would not be acceptable by the finger painting faction as that's not what they used to. How do you expect a reasonable discourse when you characterize your opponents thus? john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:30:32PM +0200, Jean-Marc Lasgouttes wrote: This isn't about overlapping extents as I see it, it's about a natural feel for the UI. In particular, if I click-drag at point A in this diagram: foo bar C foo bar A foo bar foo bar B and drag towards B, it will prove extremely annoying that my selection changes to cover C too. That's not what I asked for! It happens for example in tabular inset when the selection changes to encompass several cells. It's OK with today's insets because they're clearly separate chunks of text. What would you advocate? Stay with ranges or try to make the insets feel reasonable? My experience tells me that getting cursor handling (at least) right would be very difficult with insets - such that we'll end up with a half-finished version that sort of works OK by the next release. However, my experience is now years old, maybe Abdel is right and the core is in a much better state, so special-casing all the cursor movement code can be done cleanly and easily. Maybe we can even make selection be two free-form iterators and have logic to do the right thing. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:43:21PM +0200, Abdelrazak Younes wrote: What would you advocate? Stay with ranges or try to make the insets feel reasonable? The solution is maybe to limit the number of words to *one* within a given charstyle. This would mean that pressing space at the end of a word will create automatically another inset of the same type. Then if you want to go back to normal text, press [Backspace] to dissolve the newly created inset and voila. I think this behavior would be very intuitive and John's problem would be solved. I don't agree. Backspace must always delete the visible item to the left* of the cursor regards john * or right, depending on language direction
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:47:50PM +0200, Abdelrazak Younes wrote: That's true for the current insets, absolutely *not* for char styles. It's not acceptable for it to need two keypresses to get from a to b in 'ab' just because a has a different char style. But why would you want to have two different charstyles in the _same_ word? If you need that then I would say that this is a use case where you really want to use font attributes and not charstyle. This applies equally well to punctuation, spacing, whatever. Cursor movement operations must operate 'visibly' in all circumstances. This is also a difficult UI problem that will frustrate people I think. Imagine if I have: blah blah __blah foo foo__ and I want to reset the third blah to have no style like the others. It'll be immensely annoying to have to carefully select just up to the 'b' (any further, and you'll have the whole inset). Look at what I proposed in another message to you: I think that basically this problem would be easily solved by having one inset per word: blah blah __blah__ __foo__ __foo__ Of course, on export to LateX, LyX would be free to merge adjacent inset into _one_ charstyle. It's an interesting idea. I need to think some more about it. My main immediate problem would be that the selection behaviour depends entirely on whether it has a style. This still doesn't seem intuitive. I absolutely do want to be able to cut and paste with the 'innards' of words, regardless of style. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 03:00:13PM +0200, Abdelrazak Younes wrote: Nothing too recent I guess and I am not sure when was John's last visit to the source code :-) John, do you know about DocIterator? They were designed specifically for cursor navigation across insets. I do (I remember its birth ...) I'm not sure it helps much with decisions like where should I move when I press the right arrow key. Consider a nesting like this: foobiutable... if you're at the end of foo, then the 'right' answer is to descend to just before the table and no further. If you're at the start of table, and you press left, then we need to jump to outside of the table, but also presumably cross all of the char style insets. I can believe easily there are all sorts of fun special cases. I am on purpose rejecting char based selection because the moment you need that, you don't really need charstyle to begin with. That's not true. Just because I want to delete part of a word does not mean I want to make 'work' become bold in 'unworkable'. Although that's not really that crazy a desire. john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 03:17:09PM +0200, Abdelrazak Younes wrote: But why would you want to have two different charstyles in the _same_ word? If you need that then I would say that this is a use case where you really want to use font attributes and not charstyle. This applies equally well to punctuation, spacing, whatever. Cursor movement operations must operate 'visibly' in all circumstances. Ah but spaces are separators and punctuation should be attached to the previous word. That's a very bold statement to make, and is certainly not true of (for example) code fragments, where a comma is most certainly not part of the variable char style. Why absolutely? Isn't this something that you could learn an get used to? A-ha. Suddenly things have changed: the preference to use insets as the implementation is now causing us to invent new forms of unusual UI. This is exactly what Dov is talking about. If we're making people 'get used to' something that we purposefully introduced because our implementation needed it, we've gone very wrong. (As opposed to the idea of semantic markup, which is an intentional policy decision.) become very natural. I for one hate when I don't know if this particular punctuation is in 'arial' or 'times' when I type something in MS Words. At the end I just select everythng and reapply the font that I want, just to be sure. This genuine issue has other solutions (straw men include: a simple conglomerate style range marker in light blue with the name of the style; something in the status bar at the bottom; the combo box automatically switching to the current style) regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 03:44:34PM +0200, Abdelrazak Younes wrote: That's a very bold statement to make, and is certainly not true of (for example) code fragments, where a comma is most certainly not part of the variable char style. Then just put it outside the charstyle, something that is as easy to do with insets (press space or right arrow) as with fonts (toggle font). I don't believe this is a natural way to do things, again. If we're making people 'get used to' something that we purposefully introduced because our implementation needed it, we've gone very wrong. But charstyle _is_ something new! Aren't we allowed to design a new form of UI for something new? With MS word you can do similar things with macro and field but it is *very* cumbersome and not user friendly at all. What!?! Char styles are absolutely not something new. Whilst LyX has been sitting on its hands, even word processors have stood up and implemented char styles. And this is besides the point, anyway: char styles are so close to char markup (e.g. bold) in terms of the way you interact with them that to invent new UI is an awful idea IMO. OK, but I personally prefer a physical limit like imposed by the charstyle as it is implemented right now. Did you try it by the way? You will see that you will rarely need the 'easy' selection process you were talking about. Try what exactly? regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 04:23:00PM +0200, Abdelrazak Younes wrote: Really? I didn't know that, but then I am not a pro of MS Word. What is I haven't used or looked at MS Word in years. the equivalent of charstyle in MS Word? I hope you are not talking about the formatting styles that you get with Format-Font, those are just font style, not charstyle. They are just a way to apply a predefined set of font attributes. Start OpenOffice, select Format-Styles and Formatting, then click the second icon (with the 'a'). From here you can define new character styles or use some existing ones. You'll notice that these are indeed stored as styles too, they're not just some naming thing for font definitions. And this is besides the point, anyway: char styles are so close to char markup (e.g. bold) in terms of the way you interact with them that to invent new UI is an awful idea IMO. They are so close to markup because they _are_ markup in other processor. That's really, definitely not the case in LyX. You're living in the past I think. Try what exactly? charstyle. They are implemented as insets in 1.6svn. How do I get to it? john
Re: CharStyles As Insets: TODO
On Wed, Oct 03, 2007 at 12:15:52PM -0400, Richard Heck wrote: 4. Inset dissolving should be more intuitive. There should be a menu item Remove charstyle---it doesn't have to be called that---that dissolves the current (innermost) inset. Maybe there should also be a I believe you can do that simply by setting the style combo box back to 'None'. I think this is more natural. This is not good. CharStyle insets should be drawable across lines in the natural way. Sounds fun :) regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 12:22:00PM -0400, Richard Heck wrote: The difficulty is that, if you're already in the inset, you might be wanting to apply another one. How do you distinguish that from changing the inset type (which is the most natural thing). You only change anything if there's a selection. Otherwise, it's a new charstyle you want to start typing with. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 08:06:18PM +0300, Martin Vermeer wrote: No need to select... just be inside the inset to be dissolved. It's needed or you can't tell choose a style, then type in it from change this text to be the style I select regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 10:33:41PM +0300, Martin Vermeer wrote: No need to select... just be inside the inset to be dissolved. It's needed or you can't tell choose a style, then type in it from change this text to be the style I select regards john Dissolving... no such ambiguity. Well it's easy to construct a UI that's wonderfully unambiguous but pretty unusable. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 07:45:21PM +0200, Andre Poenitz wrote: Of course this would emphasize structure and would not be acceptable by the finger painting faction as that's not what they used to. How do you expect a reasonable discourse when you characterize your opponents thus? Why do you think I expect a reasonable discourse? The last few iterations of this particular discussion were not really productive, were they? I still don't see a reason to be quite so rude, but never mind. You were always entirely intransigent on this matter. john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 08:25:12AM +0200, Abdelrazak Younes wrote: > >However, insets imply all sorts of things about cursor movement and > >mouse placement. Unless things in this area got *massively* cleaned up > >since I last looked at the code, getting correct cursor movement with > >char-ranges-as-insets will not be easy. > > We will face challenge for sure but Cursor movement is already working > well for entering and leaving insets. We will have to decide what to do That's true for the current insets, absolutely *not* for char styles. It's not acceptable for it to need two keypresses to get from a to b in 'ab' just because a has a different char style. > with selection though. I am in the opinion that when coming outside of > an inset, whatever it is (charstyle included), we should select the full > insets. Right now, the implementation offers no other choice in any case. This is also a difficult UI problem that will frustrate people I think. Imagine if I have: blah blah __blah foo foo__ and I want to reset the third blah to have no style like the others. It'll be immensely annoying to have to carefully select just up to the 'b' (any further, and you'll have the whole inset). regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:12:22PM +0200, Jean-Marc Lasgouttes wrote: > >> We will face challenge for sure but Cursor movement is already > >> working well for entering and leaving insets. We will have to decide > >> what to do with selection though. I am in the opinion that when > >> coming outside of an inset, whatever it is (charstyle included), we > >> should select the full insets. Right now, the implementation offers > >> no other choice in any case. > > > > I think this would be very unintuitive behavior in the case of > > character styles. > > I do not think so. I have yet to see of a good example where > overlapping extents are useful (do you have a better example than the > TEI one?). We should not design the UI around a weird case. This isn't about overlapping extents as I see it, it's about a natural feel for the UI. In particular, if I click-drag at point A in this diagram: foo bar C foo bar A foo bar foo bar B and drag towards B, it will prove extremely annoying that my selection changes to cover C too. "That's not what I asked for!" It's OK with today's insets because they're clearly separate chunks of text. john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 10:03:32AM +0200, Andre Poenitz wrote: > Of course this would emphasize structure and would not be acceptable > by the finger painting faction as that's not what they used to. How do you expect a reasonable discourse when you characterize your opponents thus? john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:30:32PM +0200, Jean-Marc Lasgouttes wrote: > > This isn't about overlapping extents as I see it, it's about a natural > > feel for the UI. In particular, if I click-drag at point A in this > > diagram: > > > > foo bar C foo bar A foo bar foo bar B > > > > and drag towards B, it will prove extremely annoying that my selection > > changes to cover C too. "That's not what I asked for!" > > It happens for example in tabular inset when the selection changes to > encompass several cells. > > > It's OK with today's insets because they're clearly separate chunks of > > text. > > What would you advocate? Stay with ranges or try to make the insets > feel reasonable? My experience tells me that getting cursor handling (at least) right would be very difficult with insets - such that we'll end up with a half-finished version that sort of works OK by the next release. However, my experience is now years old, maybe Abdel is right and the core is in a much better state, so special-casing all the cursor movement code can be done cleanly and easily. Maybe we can even make selection be two "free-form" iterators and have logic to do the right thing. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:43:21PM +0200, Abdelrazak Younes wrote: > >What would you advocate? Stay with ranges or try to make the insets > >feel reasonable? > > The solution is maybe to limit the number of words to *one* within a > given charstyle. This would mean that pressing at the end of a > word will create automatically another inset of the same type. Then if > you want to go back to "normal" text, press [Backspace] to dissolve the > newly created inset and voila. I think this behavior would be very > intuitive and John's problem would be solved. I don't agree. Backspace must always delete the visible item to the left* of the cursor regards john * or right, depending on language direction
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 02:47:50PM +0200, Abdelrazak Younes wrote: > >That's true for the current insets, absolutely *not* for char styles. > >It's not acceptable for it to need two keypresses to get from a to b in > >'ab' just because a has a different char style. > > But why would you want to have two different charstyles in the _same_ > word? If you need that then I would say that this is a use case where > you really want to use font attributes and not charstyle. This applies equally well to punctuation, spacing, whatever. Cursor movement operations must operate 'visibly' in all circumstances. > >This is also a difficult UI problem that will frustrate people I think. > >Imagine if I have: > > > > blah blah __blah foo foo__ > > > >and I want to reset the third blah to have no style like the others. > >It'll be immensely annoying to have to carefully select just up to the > >'b' (any further, and you'll have the whole inset). > > Look at what I proposed in another message to you: I think that > basically this problem would be easily solved by having one inset per word: > > blah blah __blah__ __foo__ __foo__ > > Of course, on export to LateX, LyX would be free to merge adjacent inset > into _one_ charstyle. It's an interesting idea. I need to think some more about it. My main immediate problem would be that the selection behaviour depends entirely on whether it has a style. This still doesn't seem intuitive. I absolutely do want to be able to cut and paste with the 'innards' of words, regardless of style. regards john
Re: *not* everything is an inset!
On Wed, Oct 03, 2007 at 03:00:13PM +0200, Abdelrazak Younes wrote: > Nothing too recent I guess and I am not sure when was John's last visit > to the source code :-) > > John, do you know about DocIterator? They were designed specifically for > cursor navigation across insets. I do (I remember its birth ...) I'm not sure it helps much with decisions like "where should I move when I press the right arrow key". Consider a nesting like this: foo... if you're at the end of foo, then the 'right' answer is to descend to just before the table and no further. If you're at the start of table, and you press left, then we need to jump to outside of the table, but also presumably cross all of the char style insets. I can believe easily there are all sorts of fun special cases. > I am on purpose rejecting char based selection because the moment you > need that, you don't really need charstyle to begin with. That's not true. Just because I want to delete part of a word does not mean I want to make 'work' become bold in 'unworkable'. Although that's not really that crazy a desire. john
