John Levon wrote: > Minipages. If I set two minipages to 50% it would be nice if they > appeared next to each other, like they used to. That's all.
Didn't knew that (never used that myself). I don't know if I would like it though - that too much wysiwyg at the cost of clutter editing. > Colour me dubious about this. I think things would still be broken. It may be, but in 1.3.x we didn't had width depending on the rowbreaking. And this is what is giving problems now. >> So what is your ideal_width? What kind of heuristic optimization does it? >> For instance, given the following, where the size of the inset [I] is yet >> to be decided, what does ideal_width return? (suppose of course that it's >> *not* a full row inset; nowadays full row insets are only displayed math >> and tables IIRC; it's simply a "natural width" inset as all >> insettext-derived ones in today's setup) >> >> blah blah blah [I] blah >> blah blah blah blah blah bla > > I don't understand your example. Row breaking is done in left-to-right, > top-to-bottom manner, how could the above ever have an unknown width ? Well soppose [I] is an inset full of text (i.e. the figure above corresponds to the collapsed case). Then in your proposal its width depend of its internal text + maxwidth + remainig_row_width, right? How, exactly? >> The only real problem I see with the current implementation is the inset >> placement in the first position of the first indented line of a >> paragraph. It is probably easy IMHO to find a quick solution for that >> without changing the overall scheme... > > This seems really silly. Andre chose to go down the path of rewriting > lyx so things could be done right this time, and you want to re-add some > curious hack? Well let's put it this way. You are discussing implementation for some reason, I'm discussing desired behaviour. I don't know why you assume that the desired behaviour is obvious in some way and you don't even care to describe it. > What about indentation due to bullets ? Ever placed a fullrow inset on a > bullet line (in 1.3 or 1.4, it goes wrong). Can you describe the problem better? I don't see anything unusual with a note for instance. >> [for instance, a "solution" that would work reasonably well in most >> [(all?) >> cases is to add this 'special casing': a single char on a row, if it's >> wider than the avail width the we could draw it without using the row >> indent: it's anyways better than what we do now: to make it exceed to the >> right] > > This sort of thing is what helped make lyx unmaintainable in the first > place IMHO. I sort of knew you would say that ;-). And I still don't understand your solution to the problem. Alfredo
