Re: The current char style UI

On Sun, Nov 30, 2003 at 10:44:11PM +0200, Martin Vermeer wrote:

> > But since this is really only a halfway
> > house to what we really want, that might not be suitable. 
> 
> What *do* we/you really want? 

Well as outlined and discussed some months ago.

> > slightly weird to have some completely different UI for handling logical
> > styles from physical settings, as we have currently.
> 
> Hmmm perhaps. Did I point out already that I don't really like physical
> character attributes? 

They shouldn't exist at all, but that has some other implications.

> I can see your problem though. Having insets is a quite different
> paradigm, but is conceptually cleaner and more practical to implement.
> IMHO.

This is why we have the half-way house :)

> An essential difference is that a char attribute can be applied or
> unapplied. An inset can only be inserted (i.e., "applied" after
> selecting the text to be contained in it.)

Exactly ... this is just one of the many problems with a box-based
approach visible in the UI (as opposed to a purely internal box
paradigm)

vspace ui

What on earth is a vspace of "none" ? Why is it the default ?

There are missing tooltips it seems ... (qt)

regards
john

--

-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

CVS can't compile in xforms directory !?!

Hi,

CVS compilation gets stuck at:

[...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms'
cmp -s lyx_forms.h-tmp lyx_forms.h || {\
         rm -f lyx_forms.h ;\
         cp lyx_forms.h-tmp lyx_forms.h ;\
}
echo timestamp > stamp-forms
if cmp -s lyx_xpm.h-tmp lyx_xpm.h || {\
         rm -f lyx_xpm.h ;\
         cp lyx_xpm.h-tmp lyx_xpm.h ;\
}
/usr/local/bin/bash: -c: line 2: syntax error: unexpected end of file
gmake[4]: *** [stamp-xpm] Error 2

Syntac error? Could it be that you should use "(...)" instead of "{...}" here
for grouping commands?

This is up-to-date LyX-CVS on FreeBSD box.

Rob.

Re: A working InsetVSpace

On Sun, Nov 30, 2003 at 10:01:07PM +0100, Georg Baum spake thusly:
> Am Sonntag, 30. November 2003 10:00 schrieb Juergen Spitzmueller:
> > Georg Baum wrote:
> > > Apart from that, I get error messages like
> > >
> > > Paragraph ended in line 31
> > > Missing \end_layout.
> > >
> > > if I use the VSpace inset (see attached example). Is this expected (CVS
> > > from this morning)? I checked the file by hand, the structure seems to
> > > be correct.
> >
> > cannot reproduce (and you forgot to attach the file).
> 
> Oops. Now really attached. I am using gcc 2.95.4 + stlport. Could this be 
> the problem? 
> 
> 
> Georg

Confirmed. The problem seems to be (debugging)

Handling token: `\begin_layout'
Handling paragraph token: `begin'
Handling paragraph token: `\begin_inset'
Handling paragraph token: `\end_inset'
Paragraph ended in line 31
Missing \end_layout.

The paragraph reading code readParagraph() in paragraph_funcs.C

Re: The current char style UI

On Mon, Dec 01, 2003 at 12:17:38AM +0000, John Levon spake thusly:
> 
> On Sun, Nov 30, 2003 at 10:44:11PM +0200, Martin Vermeer wrote:
> 
> > > But since this is really only a halfway
> > > house to what we really want, that might not be suitable. 
> > 
> > What *do* we/you really want? 
> 
> Well as outlined and discussed some months ago.

Don't remember precisely. Wasn't it about three-box inlined? 

As I wrote earlier, one-box inlined is implementable right now but
won't work right for current CVS because of the width stuff.

> > > slightly weird to have some completely different UI for handling logical
> > > styles from physical settings, as we have currently.
> > 
> > Hmmm perhaps. Did I point out already that I don't really like physical
> > character attributes? 
> 
> They shouldn't exist at all, but that has some other implications.

They won't be going away any time soon. Just like in LaTeX.

> > I can see your problem though. Having insets is a quite different
> > paradigm, but is conceptually cleaner and more practical to implement.
> > IMHO.
> 

Remove stray "if" in src/frontends/xforms/Makefile.am

Angus,

Apologies for the person-to-person email, but my emails to the devel list
seem to end up in /dev/null :(.

Another patch is needed to src/frontends/xforms/Makefile.am in CVS, to
remove a stray 'if':

Index: src/frontends/xforms/Makefile.am
===================================================================
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/Makefile.am,v
retrieving revision 1.111
diff -u -r1.111 Makefile.am
--- src/frontends/xforms/Makefile.am	2003/11/30 17:11:50	1.111
+++ src/frontends/xforms/Makefile.am	2003/12/01 07:24:42
 <at>  <at>  -194,7 +194,7  <at>  <at> 
  	 <at> :

  stamp-xpm: lyx_xpm.h-tmp
-	if cmp -s $< lyx_xpm.h || {\
+	cmp -s $< lyx_xpm.h || {\
  		rm -f lyx_xpm.h ;\
  		cp $< lyx_xpm.h ;\
  	}

Cheers,
Rob.

[PATCH] Minifix in chess.layout

Hello,

this one fixes a message. Please apply.

Michael

Index: lib/ChangeLog
===================================================================
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.545
diff -u -r1.545 ChangeLog
--- lib/ChangeLog	2003/11/28 17:38:37	1.545
+++ lib/ChangeLog	2003/12/01 07:29:44
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2003-11-28  Michael Schmitt  <michael.schmitt <at> teststep.org>
+
+	* layouts/chess.layout: Remove blanks in style name
+
 2003-11-28  Angus Leeming  <leeming <at> lyx.org>

 	* ui/stdmenus.ui: add Insert VSpace.
Index: lib/layouts/chess.layout
===================================================================
RCS file: /cvs/lyx/lyx-devel/lib/layouts/chess.layout,v
retrieving revision 1.6
diff -u -r1.6 chess.layout
--- lib/layouts/chess.layout	2003/10/13 09:50:09	1.6
+++ lib/layouts/chess.layout	2003/12/01 07:29:46
 <at>  <at>  -81,7 +81,7  <at>  <at> 

Re: vspace ui

John Levon wrote:
> What on earth is a vspace of "none" ? Why is it the default ?

Don't know. But it does not make any sense to me either.

> There are missing tooltips it seems ... (qt)

Where?

Jürgen.

Re: The current char style UI

John Levon wrote:
> What are people's future plans in this regard ? I know its already been
> discussed wrt how the inset should look, but I have real issues with
> this stuff being in the Insert menu at all. I'd muich rather see text
> style being a submenu in Edit. 

IMHO we should have another combo in the (one) toolbar. Char Styles should 
conceptually be handled like paragraph styles. I know, there is not much 
place, but we can remove the noun, emph and font-free buttons, and we should 
default to 2 toolbars anyway.

> But since this is really only a halfway
> house to what we really want, that might not be suitable. But it's
> slightly weird to have some completely different UI for handling logical
> styles from physical settings, as we have currently.

WRT the physical appearance, I'd strongly vote against the collapsable 
approach. Collapsables are o.k. for text on another level than the main text 
(i.e. footnotes, margins, notes, ert etc.), but not for parts of the main 
text. Apart from that, the screen is already cluttered enough with boxes and 
stuff. Perhaps it's only me, but this seriously disturbs me. I think the  
conglomerate-like solution (where the content description can be switched 
off) would fit very much to LyX's philosophy and is user friendly. But if I 
understand Martin, the current solution is only interim anyway.

Regards,
Jürgen

> regards
> john

Re: [Devel] Re: A working InsetVSpace

On Fri, Nov 28, 2003 at 09:04:42PM +0100, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > 5. Qt: I got rid of the VSpace stuff from the Paragraph dialog but have not
> > written QVSpace.
> 
> Done (patch attached).

Thanks a lot.

> - is there any special reason why you have removed "keep" (i.e. \vspace*) in 
> the xforms dialog? I have reintroduced it (as "protect") in qt.

No, oversight.

> - is the "Vertical Space ()" intended when setting "none" in the dialog?

I think 'NONE' is not needed anymore. After all, if I insert a vspace, I
want 'SOME' there...

Andre'