in reply to Tk autosizing Scrolled widgets

I think that you have the first part, that the scrollbars disappear when they are not necessary.

I think what you want is: When the display pops up onto the screen, it should use the entire height and width of the monitor and not have any scrollbars unless they are necessary? Since you have solved the first part of the problem (scrollbars disappear if the aren't needed). This comes down to the equivalent requirement of how to size the window so that you can see everything without scrollbars, if possible?

There isn't any pack() parameter, to my knowledge that says "use entire screen space".
I think you will have to calculate your "ideally" required space (height and width in pixels), and compare that with the pixel resolution of the monitor that you are running on. If there aren't enough pixels available, then the best that you can do is have a window of the max monitor's pixel width.

These functions are available:

$widget->reqheight  #requested height
$widget->height     #actual height
$widget->reqwidth   #requested width
$widget->width      #actual width

[download]
It been a very long time since I worked with Tk. I'm not familiar with some of the widgets that you used, so I wrote my own example to play with.

What I wanted to show is how to count up pixel widths of objects and then use that total to configure the window size. For some reason the configure method didn't work in my testing, but but I'm sure that is some kind of brain cramp on my part. I just set the minimum width of the window to size needed for the columns shown. I added a 20 pixel "fudge factor" at the end of the row to account for the scroll bars in my example which work differently than yours. I just did the width calculation, but height would be similar.

Anyway here is my hacking code for further thought.. 

use Tk;
use Tk::Pane;

use strict;
use warnings;

my $Window = MainWindow->new();
$Window->geometry("+0+0"); # start in upper left corner of display

my $sframe = $Window; 

my $scroll = $sframe->Scrolled('Pane',
                         -sticky => 'news',
                         -scrollbars => 'se',
    );
$scroll->pack(-expand => 1, -fill => 'both');;

my $total_row_width = 0;

foreach my $row (0..9)
{
    my $row_frame = $scroll->Frame()->pack(-side=>'top',-fill=>'x');
    
    $total_row_width = 0; 
    foreach my $col (0..12)
    {
       my $this_entry =$row_frame -> Entry(-text => "Whatever $row,$co
+l",
                                           -width => 12)->pack(-side =
+> 'left');
       my $width_this_widget = $this_entry->reqwidth;
       $total_row_width += $width_this_widget;
       
    }
    #print "width in pixels this row of widgets: $total_row_width\n";
}
my $fudge = 20;
print "total row width = $total_row_width\n";
$Window->minsize($total_row_width + $fudge,300);

MainLoop;

[download]
You will of course have to figure out the pixel width of the monitor that you are running upon. But that is not a Tk function to my knowledge.
Also be aware that Tk sometimes uses "width in characters" instead of pixels. But that is only an approximate measure (see my width of Entry window).

Replies are listed 'Best First'.
Re^2: Tk autosizing Scrolled widgets
by olgo (Sexton) on Sep 14, 2021 at 06:46 UTC

    It seems that my original post lacked a bit of context so I will give it some more effort here:
    The code example I posted was simply an effort to reduce the problem to highlight the issue I was having, i.e. the autosizing of the variable grid data.

    My entire GUI consist of many more elements, but the rest I have already got working, at least sufficiently.

    The screen consists of a starting upper left block of widgets; Labels, Entrys, Checkboxes, BrowseEntrys and ProgressBars. Nothing strange there.
    Then comes the varying part of the GUI: A grid (based on an HList in my case) that contains all the dynamic data, in response to what the user does with the top widgets.
    My dynamic grid consists of lines of varying column content, Entries, Labels, BrowseEntrys and Checkboxes, all with varying dimensions.
    In the case where the dynamic grid contains only a limited amount of data, I want all the data to be visible, no scrollbars and the outer window tightly snug around the entire GUI.
    In the case where the dynamic grid contains massive amounts on data, I want as much data as possible to be visisble and scrollbars available to be able to scroll the dynamic grid data. The outer window should in this case extend to the entire screen (width/height wise depending on which direction the data extends)

    tybalt89: Thanks for the alternative method of producing the grid data. I considered this method before but discarded it due to having to use the grid packing method.
    There was a note somewhere saying one should avoid mixing packing methods and I have used only form so far (not pack as in my example). However, seeing your example code, I will definately have a go at it.
    Your code example however still produces scrollbars when adding more data in the grid (Even your example code produces a horizontal one).

    Marshall:You code does solve the problem.
    Enlarging the window by means of changing the window MinSize is however not what I want (I want the user to be able to resize it at will), but -configuring the scrolled pane size worked equally well.

    Conclusion
    If this is indeed the best/only solution, I will have to sum up the total of all my top widgets and dynamic grid contents.
    I still have the feeling that there should be some neat Tk packing or whatever mechanism for doing this but maybe there isn't.
    Giving this type of task to the "application" seems wrong. Best solution would be to add this as a new option to the packer algorithm. Maybe this could be added as a Tk request somewhere?

    Getting answers (and even programming efforts) to my question in less than 24h is way more than I expected.
    Thank you all.

[reply]

      The mixing of ->pack and ->grid only applies within ONE parent, different parents can have different geometry managers within one application. No Problem. I do it all the time. Example follows.

      Read more... (2 kB)

      Applications resizing themselves without user input is a BAD IDEA. Just imagine your user trying to click on something and having it move out of the way just before the click. BAD IDEA!

      See the "widget" demo program for an example of what an HList looks like. It should have come with the Perl/Tk package.
      "I do not think it means what you think it means."

[reply]
[d/l]

        tybalt89:contrary to your strong recommendation, my application DOES NOT resize itself without user input. It reacts on user input and thus gets more or less data to present. Maybe I was unclear about this.
        By the way, the widget demo, specifically the HList one was what made me choose this Grid mechanism in the first place. But, as I also wrote before, I will give your ->grid packer a go, now that I now that it is an alternative. (The HList does do the job though, but there might be overhead)
        Thanks!

[reply]

In Section Seekers of Perl Wisdom