So, the discussion is whether there is a need for ParBox or not. Lars said: > Some data<->view stuff seems to be mixed here.
This is the key to the answer: If you have ParBox, the view part will be simpler. ParBox corresponds to a list of Paragraphs. This is a sane concept, and is reflected in LaTeX as well. I'm sure Jean-Marc can tell you the LaTeX name for this thing, because it corresponds exactly to a LaTeX concept. Of course, you can call a ParBox an Inset, and collapse these things to one object hierarchy. However, I don't think this will help you. In general, you will be better of with separating concerns. Why do you want to collapse ParBox'es into Inset? If you want to do that, you should ask yourself why not collapse Paragraphs into Insets? This will not help you. An inset can be many things, but it does not have to concern itself with flow. A Paragraph is something else, but it's not polymorphic. It concerns itself with flowing insets and characters in the three-box model. A ParBox is also something else, and it's not polymorphic either. It has a fixed width, and growing y-coordinates. It concerns itself with stacking paragraphs on top of each others, and it provides a simple interface for documents and table cells to display the paragraphs there. For sure, you want to keep this separate code, separate. An Inset should be simple to implement. It should not worry about scrollbars and y-positions, stacking paragraphs and repaint-logic. These things should be delagated to the ParBox. Just like you delegate the task of flowing the characters and insets to the Paragraph class. Also, by restricting polymorphism to Insets, you will find that things are simpler to handle from the pure Data-side of things. This is my experience from the prototype kernel I implemented for LyX a long time ago. It's simple: Your nesting is much more controlled when you restrict polymorphism to one place in the hierarchy. And we have prior art to help us: The current LyX kernel is containing a list of paragraphs. Wrap this into a class and call it ParBox, and you will see what we are talking about. And Andre has prior art in Mathed which works just as well. (Andre is making a mistake to call it a cell, because normally a cell is an atomic thing. However, a ParBox is a composed thing, so that name is confusing things.) Please point to prior art that does the "everything-is-an-Inset" thing. I don't think you can find any. At the end of the day, this is an old discussion re-emerging. I'm sure you can find a lot of good arguments about this a couple of years back in the mailing list archive. At that point in time, we manage to reach a consensus that ParBox'es were a good thing, and with enough persistence, we can reach the same conclusion today. Why? Simply because it is the better solution ;-) Best regards, Asger
