On Tue, Apr 11, 2006 at 04:08:15PM +0200, Georg Baum wrote: > Helge Hafting wrote: > > > After studying the code some more, I agree that InsetSpace is the better > > base for this. quad, qquad, enskip and enspace are already implemented, > > there simply isn't any gui way (short of the command line) to add them. > > There is a bug in bugzilla for the missing gui, don't remember the number. > > > So this will certainly be the easier way, and I look to vspace only for > > details on > > the dialog box, and parsing of glue lengths. > > > > But why do you want me to rename InsetSpace to InsetHspace? > > Why not simply extend it with the user defined hspace lengths? > > Is this for naming consistency with vspace, or something else? > > Yes. It is not too important, but I thought it would be worth it, since you > change the file format anyway because of the new lengths. > Well, but without changing the name, the format will only be extended, not changed. So no need to convert old files then, only conversion to ERT when opening a new file with an older lyx.
> > As for parsing of lengths - there seems to be an excellent routine > > for that in VSpace. Horisontal spacing will use exactly the same > > lengths (2.5cm, -4in, . . .) so surely this can be reused. What's the > > proper way of doing this? Surely this part must be moved from the > > VSpace class and into something of its own - otherwise I'll have > > to copy&paste it. (Perhaps the first attempt will do that anyway, > > but it'd be nice to clean up the duplication too.) > > No need to copy or move aything. The function you want is isValidLength and > already declared in src/lyxlength.h and uses a LyXLength, not a VSpace.i I was thinking of isValidGlueLength, but I see this too is independent of vspace. I misunderstood as it was implemented in the vspace.C file. > The really interesting thing is to extend LyXLength to handle user defined > lengths. How would that be done? Having a central place where the user > could define his own lengths, or simply allowing an arbitray unit for user > defined lengths? A good question indeed. I was planning on allowing anything starting with a backslash, so the user can use things like \medskipamount and all the other lengths latex (and various packages) defines for us. But of course this makes latex compile errors possible too. If that isn't good enough, I'll drop this part for now. It can always be added later. Document settings could certainly have a page for user defined lengths, and .layout files could be extended to provide "allowed" lengths provided by latex or the packages the .layout brings in. But that is material for a later patch. It is something I'm not missing right now. User defined lengths don't seem that necessary when we can write stuff like -2.45pt. Ability to use lengths defined by latex might be more useful - if latex defines any important lengths that is. > > > The final question is about hfill. Currently, hfill is an inset of its > > own, not part of the space inset. The plan was to make hfill part of > > horizontal spacing, similiar to how vfill is part of vertical spacing. > > Doing this will alter the file format without anything new happening > > though. > > Don't worry about the file format change. Implementing it in lyx2lyx will be > trivial. If there is a good reason for a change, just do it. > Sure, but only if there is good reason for change. Not changing the format is even easier, no lyx2lyx work. :-) > > But there is another alternative. One of my next tasks will be > > to add other fills, such as dotfill and rulefill. hfill could be grouped > > with those instead. > > > > So what is most important - the fact that hfill is _blank_ and therefore > > a kind of hspace, or the fact that hfill is a _fill_ like those other > > fills? > > I never needed the other fills, so I am not sure. Well, I am not so sure how useful it is to change a "hfill" into something else, be it a fixed-length space or a different fill. One can always just delete and insert the other kind. Changing from dotfill to rulefill is something I can imagine doing to fine-tune the look though. Or changing a quad to enskip. But a fill doesn't seem so likely to be replaced with a non-fill. Anyway, it can be done later. Actually getting a hspace dialog is a step forward on its own. Helge Hafting
