Helge Hafting wrote: > 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.
You are right, but in our terminology this is a format change, too. We have serveral of these with an empty convert() function in lyx2lyx. > 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. This is indeed not very nice. Should be cleanep up one day. >> 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. This would be good for a start. The only problem: How do we represent such a length on screen? > 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. I disagree. Example: I have a complicated table in our lecture notes. When I want to include it in a beamer presentation I have to change several (~20) lengths. They cannot be described with the help of text% etc. If LyX would accept user defined lengths for column widths and in minipages I would only need to redefine one length variable, because all these lengths can be described as a multiple of it. Of course this has not much to do with the hspace changes, it is a more general thing. > 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. Indeed. > Anyway, it can be done later. Actually getting a hspace dialog > is a step forward on its own. Yes. So maybe you start with just that? Georg
