Column widths in Store's Published Items list

If you open Published Items in Store and select a bundle or a package,
the Versions list shows you the names, blessing levels and dates for
each of the versions.  We have a situation here where the names
(versionString's) are being truncated.  It turns out that Store
dynamically calculates the column width by measuring all of the widths
of all of the version strings.  Then, instead of doing the reasonable
thing of selecting the maximum width to be the width of the column, it
calculates the mean plus two standard deviations. In our case, we had
about a hundred versions with short names and about 10 at the top with
long version names.  The column width was being made shorter by the many
shorter names and we could no longer read the top ones with longer names.

See the method PundleVersionPane >>
calculateAppropriateColumnLengthFor:emphasis:columnTextBlock:

Why can't you just use the maximum width?  The choice of "mean plus 2
standard deviations" seems very artificial and is bound to be wrong in
some cases.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The problem with using the maximum width is that just one version name
that's really, really long can push the all the other data fields out of
the window, requiring that the window size be adjusted for every use
with that package.

Mean plus 2 standard deviations includes 95% of a normally distributed
dataset.  That's why it was picked. For someone who is changing a
versioning convention to something much longer than before, I can see
that this would not be ideal.  Let me see if there's a way to make this
easier for you to modify to suit your needs...

Tom

On 5/2/15 7:58 PM, David Buck wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

when you said that i wondered why that is even a requirement. Wouldn’t it be much more convenient if that window remembered its size and the size of the columns? If you have a huge bundle-structure then the version column is always outside the window, which can be quite annoying.

Kind Regards

Karsten

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

That behavior seems to have been added since the VW 7.5. I had found a performance problem with similar line measurement code.

Some lists had thousands of items and VW was doing #computeHeightFrom:to:max: on all of them. The displays updated much faster by limiting the search to only the first fifty items. Yes, it is possible that text further down in the list text would be much taller, but that had never happened in our code and the cost of measuring all the lines was significant.

ComboBoxListView>>computeLineHeight
        "Performance Extension. The #computeLineHeight had created text for every single
         line in the list to figure out the tallest line--just to figure out the height to show a drop
         down list box. One huge side effect is that it could cause trips to GemStone for every line
         just to get print strings that it would then be discargarded. This workaround limits the search
         to a maximum number of lines. It doesn't need to be exact anyway. -plb 2011.08.31"

        ^self computeLineHeight_maxLines: 50

SequenceView>>computeLineHeight_maxLines: maxLines
        "Measure the receiver's lines."
        sequence notNil ifTrue: [
                self lineGrid: ((self computeHeightFrom: 1 to: (maxLines min: self numberOfElements)) max: 1).
        ].
        ^self lineGrid

Paul Baumann



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of David Buck
Sent: Saturday, May 02, 2015 21:59
To: 'VW NC'
Subject: [vwnc] Column widths in Store's Published Items list

If you open Published Items in Store and select a bundle or a package, the Versions list shows you the names, blessing levels and dates for each of the versions.  We have a situation here where the names
(versionString's) are being truncated.  It turns out that Store dynamically calculates the column width by measuring all of the widths of all of the version strings.  Then, instead of doing the reasonable thing of selecting the maximum width to be the width of the column, it calculates the mean plus two standard deviations. In our case, we had about a hundred versions with short names and about 10 at the top with long version names.  The column width was being made shorter by the many shorter names and we could no longer read the top ones with longer names.

See the method PundleVersionPane >>
calculateAppropriateColumnLengthFor:emphasis:columnTextBlock:

Why can't you just use the maximum width?  The choice of "mean plus 2 standard deviations" seems very artificial and is bound to be wrong in some cases.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

________________________________

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Couple of other alternatives;
- Use a dataset, the columns can then be easily resized.
- Use a tooltip to show the entire line.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
===========================================================

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Tom Robinson
> Sent: Sunday, May 03, 2015 11:35 PM
> To: [hidden email]; 'VW NC'
> Subject: Re: [vwnc] Column widths in Store's Published Items list
>
> The problem with using the maximum width is that just one version name
> that's really, really long can push the all the other data fields out of
the
> window, requiring that the window size be adjusted for every use with that
> package.
>
> Mean plus 2 standard deviations includes 95% of a normally distributed
> dataset.  That's why it was picked. For someone who is changing a
versioning


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 5/4/2015 5:35 AM, Tom Robinson wrote:
It seems to be over-engineered for this particular case: all columns
have a predictable width except the version name which depends on the
list contents.

So the hacker's solution would be to move the version name to be the
last column since resizing the last column to huge widths does not move
other information out of view.

This way the known-to-be-wrong heuristic can go away and be replaced by
a simple (and always correct) maximum as suggested by David.

The window can be resized too while being truncated to the maximum
screen width. (this is important because it removes needless clicking to
scroll horizontally in order to reveal the needed information in the
tool. Even though it can look ugly it makes for less interruptions of
mental flow).

R
-


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The Timestamp column is not a predictable width - that's the reason
*it's* the last column. :)

On 5/4/15 9:45 AM, Reinout Heeck wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 5/4/2015 5:23 PM, Terry Raymond wrote:
> Couple of other alternatives;
> - Use a dataset, the columns can then be easily resized.
> - Use a tooltip to show the entire line.

The problem with such solutions is that they require gesturing.

Here at Soops we patched several of the Store windows to automatically
widen to accommodate the data presented (so we need zero gesturing too
see the info we are interested in). The IDE becomes a lot more *fun* to
use when I no longer need to scroll and/or resize windows when the
computer could have done it for me.

The result sometimes *looks* ugly but always *feels* great :-)


R
-
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The Timestamp column is not a predictable width - that's the reason *it's* the last column. :)

So compute it from the list contents as we do now.

Replace my 'predictable width' verbiage with 'mostly the same width for all entries' so we can concentrate on making *this tool* feel nicer rather than making the generic solution less wrong.



I like smilies :-)

R
-

On 5/4/15 9:45 AM, Reinout Heeck wrote:

On 5/4/2015 5:35 AM, Tom Robinson wrote:

The problem with using the maximum width is that just one version name that's really, really long can push the all the other data fields out of the window, requiring that the window size be adjusted for every use with that package.

Mean plus 2 standard deviations includes 95% of a normally distributed dataset.  That's why it was picked. For someone who is changing a versioning convention to something much longer than before, I can see that this would not be ideal.  Let me see if there's a way to make this easier for you to modify to suit your needs...

It seems to be over-engineered for this particular case: all columns have a predictable width except the version name which depends on the list contents.

So the hacker's solution would be to move the version name to be the last column since resizing the last column to huge widths does not move other information out of view.

This way the known-to-be-wrong heuristic can go away and be replaced by a simple (and always correct) maximum as suggested by David.

The window can be resized too while being truncated to the maximum screen width. (this is important because it removes needless clicking to scroll horizontally in order to reveal the needed information in the tool. Even though it can look ugly it makes for less interruptions of mental flow).

R
-

Tom

On 5/2/15 7:58 PM, David Buck wrote:

If you open Published Items in Store and select a bundle or a package, the Versions list shows you the names, blessing levels and dates for each of the versions.  We have a situation here where the names (versionString's) are being truncated.  It turns out that Store dynamically calculates the column width by measuring all of the widths of all of the version strings.  Then, instead of doing the reasonable thing of selecting the maximum width to be the width of the column, it calculates the mean plus two standard deviations. In our case, we had about a hundred versions with short names and about 10 at the top with long version names. The column width was being made shorter by the many shorter names and we could no longer read the top ones with longer names.

See the method PundleVersionPane >> calculateAppropriateColumnLengthFor:emphasis:columnTextBlock:

Why can't you just use the maximum width?  The choice of "mean plus 2 standard deviations" seems very artificial and is bound to be wrong in some cases.

David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc