> Am 05.01.2016 um 08:50 schrieb John Darrington <[email protected]>: > > Thanks for the feedback Friedrich, > > The demo I posted, was just that - a demo. Many of the things you mention > would indeed have to > be improved. I was hoping to demonstrate how a lightweight widget could > efficiently display > (and edit) huge amounts of data without getting overcomplicated.
Yes, but your demo already shows the way to go. > > I have the impression that this is a bit twisted. Full flexibility for > the axis rendering with no > flexibility in the body rendering. Maybe we could get rid of the axis > alltogether and just render > the case data with your body rendering method. Then the problem left is > to get the required > rectangle sizes for the cell_renderer. For column and row headers (your > axis) I would use the same > method, i.e. no widgets. > > Like you say, the body is inflexible as I presented it - and that would have > to be improved - but it > wasn't my first priority. I was more thinking in the direction of removing complexity from the axis. In the end we only have a variable column width. The row height is fixed. The cooked down problem is the navigation in horizontal scrolling. How can you do that without going through all colums which might have different column width? Timm has shown his idea of combining the front estimate + exact width + end estimate. > Tree Model Interface > ================ > > I haven't looked at your code yet. Currently I'm of the opinion that > GtkTreeView is > too complex to satisfy some of our needs (it assumes that we want to present > tree like structures) and at the > same time it does not fit some of our other needs (for example there is no > simple way to get row headers on the > left hand side). I agree. I was more thinking of keeping the interface to the data model, i.e. Tree Model Interface. > Data kept inside the View > ====================== > > Obviously if the sheet is to be O(1) in space requirements, we cannot keep > per row/column/cell information in the view. > > - column width (when manually changing the width) > > For the case of pspp - this information is already in the model. Each > variable has a "display width" property. > I agree that is not the way I would have designed it - but that is what we > have. Wherever the column width data is stored, when it is stored we need the memory. The only place where we could make it lean is in the view, e.g. default width (maybe based on header rendering width) plus manually changed widths. > > Thanks for looking at this. I will try to look at what you have done > tomorrow and give you my thoughts. > Don’t look at that part too much. It is based on gtktreeview and that is also in my opinion not the way to go. I am currently reworking this. Friedrich
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
