Martin Vermeer wrote:
On Sun, Oct 07, 2007 at 02:17:02AM +0200, Dov Feldstern wrote:
Martin Vermeer wrote:
On Fri, Oct 05, 2007 at 01:03:16PM +0200, Dov Feldstern wrote:
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
You are clearly underestimating the required effort and
the maintainance nightmare of a font based solution. UI is important
yes but having developers understand the source code is also important
in an open source project.
I do not think that the current font range implementation cause lots
of problems.
I really think the way fonts are used in LyX is *really* complicated and
caused us lots of problem in the past.
Can you give examples of this? (Serious question --- I haven't found this
to be the case, I've actually found it to work well.)
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.
I have done this (or a small part of this) and implemented
new insets, and I can tell you what I found easier ;-)
I think this is not a fair argument. First of all, because this was done
using the current font-attribute implementation, which is not generalized
enough IMO.
It certainly needs clean-up and generalization. But even then I
don't think you can fully avoid having CT code
separately/specialized for spans of chararacters, paragraphs,
starts and ends of paragraphs, spans containing zero, one or
several paragraph breaks (actually already nicely generalized
IIRC), and cut-and-paste...
Secondly (and much more importantly), because CT itself is *very*
complicated any way you look at it, regardless of the implementation
details. I don't believe it would have been easier if you had used insets.
After I wrote my answer to John (I used to believe this too)
I have changed my opinion on this: I now think an inset based
solution would have been actually simpler.
You would have two inset types: "red" (deleted stuff) and "blue"
(inserted stuff) insets. When switching CT on, typing into the
main text would be blocked (but see below). The only LFUNs
working there would be selection, and the only thing you
could do with a selection, enclosing it in a red inset.
Inside a red inset, no LFUN would work. Inside a blue inset,
you could type normally and also use delete and backspace.
Next, we extend this by allowing typing in the main text. The
first char typed should create a blue inset and place the
cursor inside. Using delete/backspace in the main text creates
a red inset containing the deleted character / selected interval
(e.g., one containing only a par break). You would need
a background clean-up routine to merge all these single-position
red insets.
The only "spaghetti" I see in this approach is in modifying the
main-text dispatch routine for CT. All of the detailed
paragraph and par break handling would be encapsulated in
the insets. Also the existing, complex bookkeeping system
for CT ranges would be replaced by re-using the existing
one for insets. (One thing to look at when generalizing the
range code.)
Output is simple too: acceptance means dissolving blue and
deleting red insets, rejection the reverse. Previewing this
is easy using close/open all insets (of a type, not yet impl.)
A bit late in the game to go for this now, but something to
keep in mind.
I would love this kind of UI for CT personnally ;-)
Reason is simple and is actually the same as the reason why I prefer
charstyle as inset: you cannot select a chunk of changed text in one go.
For CT, it's even worse: you _have_ to use the mouse for accepting or
refusing the change. With insets you could do that with the keyboard:
- accept == dissolve
- refuse == delete
Very simple indeed.
Abdel.
Abdel.
