On Sun, Oct 07, 2007 at 07:43:32PM +0100, John Levon wrote: > 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.
Well, we won't find out as it isn't going to happen ;-/ (And why 'strangely'? Insets are used all over the place. Users are going to bump into them somewhere if not here.) > > 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. Isn't 'natural' usually better? These things feel like atoms, and inset-ness supports that. Not a big thing but anyway. > > 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. Ability yes. Resources... at the expense of what? Inset-based charstyles work here and now. But by all means prove me wrong: the ranges code does need work. > 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 :/ Lethargy is an ugly word... let's rather talk allocation of limited resources ;-) - Martin
