Martin Vermeer wrote:
On Tue, 21 Aug 2007 10:22:44 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:
Richard Heck wrote:
Martin Vermeer wrote:
On Sat, Aug 18, 2007 at 02:40:27PM -0400, Richard Heck wrote:
This looks reasonable to me, though I haven't tested it. (I'm still
obsessing over BibTeX stuff.)
One suggestion: I think CharStyles should by default have an
unobtrusive presentation, NOT with the label showing.
OK, I did that.
Even better would be a layout parameter specifying the
default, as I remember you had. In XML, we use charstyles
as 'short elements' and then we do want to see the labels
by default.
Yes, that would be even better.
The default presentation now (or previously?) gets particularly
ugly if you try to nest them. Making them nest nicely is critical,
it seems to me, to any attempt to replace the Text Settings dialog
with CharStyles, which we are pretty much on the verge of doing
now. (I think it's really just the menu that needs sorting out for
that, as we'd need too many CharStyles to just list them all.)
I would already be happy to replace Noun and Emph. But
apparently you are also thinking of replacing all font attributes? I
would be unhappy with that.
There was a huge discussion on the list sone years ago
when I introduced the charstyle inset. You see, in the LyX
philosophy you want to support lgical character styles, not visual
editing ("finger painting"). This means that
all charstyles should represent some meaning -- the name
of a person, emphasising, 'strong' (like in HTML).
Perhaps this topic should be re-opened. There was some discussion
about it just a few weeks back, and my sense was that J"urgen had been
intending to do something along these lines. The discussion began
because I made the same suggestion independently. The motivation, in
my case, anyway, is that the Text Settings dialog is so broken that I
don't know it can be fixed. (See the many bugs collected under 3893.)
The truth is that, whatever LyX's own philosophy, people do use that
dialog. So I suggested that it should be demolished. That said, one
wouldn't have to have the "finger painting" styles appear with the
logic character styles on the menu. They could appear elsewhere,
perhaps with a stern warning that they are not to be used. ;-)
I see nothing wrong in replacing other text settings with charstyles,
as long as:
* Existing much-used styles, such as "emphasize" and
"foreign language" are preserved. They must be as easy to
use as before. (i.e. "emphasize" may very well become a generic
charstyle defined in a "stdcharstyle.inc" , but there should still be
that userfriendly emphasize button on the toolbar.
* Styles that have a visual representation (emphasize, colors,
bold, underline, font change, . . . should still be rendered
as well as they are today - i.e. use italics for emph, colors for colors,
and so on instead of framed insets. Extraneous frames really break up
the text.
Yes... we need the three-box model.
Being early in development I don't really see a problem with
a charstyle transition before 3-box drawing. I was actually
thinking more about the problem of having lots of boxes on the
screen. Not having a box for every emph is necessary, even if the
line breaking still suffer some.
* Today I can mark and emphasize the first 3/4 of a sentence, then
mark and color red the last 3/4 - and the middle 1/2 will then
be both red and emph. This way of working should work in the
future too - even if partial overlap don't fit a "nesting" model. One
solution is to create two "red" insets behind the scenes.
But this is "fingerpainting"... aka "why the * would you want to do that?"
Remember semantics: a charstyle should _mean_ something. How often do
you want to make two overlapping pieces of text stand out in two different
ways?
Two levels of emphasizing happens sometimes, just as
two levels of quotation. I can definitely see this happening if
language becomes an inset too. But this issue wasn't much of a
problem, applying a style on top of partially overlapping
stuff is easily solved by breaking the last style up into
several insets in the code. The user won't have to know.
Please don't create an artifical limitation out of this. Some
styles of writing are more "colorful" than a scientific article. :-)
Perhaps my example was dumb, I just wanted to give an example.
I think this can happen with styles that "mean" something too.
Helge Hafting
