[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New sheet implementation possibilities

From: Friedrich Beckmann
Subject: Re: New sheet implementation possibilities
Date: Tue, 5 Jan 2016 09:41:25 +0100

Am 05.01.2016 um 08:50 schrieb John Darrington <address@hidden>:

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. 


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]