PerlTk - Two packing problems

Author

Two packing problems

Torsten Mohr

2004-09-08, 4:00 pm

Hi,

in the example below i get strange results when:

1. i drag the Adjuster, it seems the Listbox is not
resized

2. When i make the whole window larger, not only the
Tk::Text is enlarged, but also the Frame "top", that
only contains the "Exit" button.

Is this related to the used Tk::Scrolled widget?

Best regards,
Torsten.

#! /usr/bin/perl -w

use Tk;

$mw = MainWindow->new();

$top = $mw->Frame();
$txt = $mw->Frame();
$choice = $mw->Frame();

$lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
$lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);

$q = $top->Button('-text' => 'Exit', '-command' => \&ex);
$q->pack('-side' => 'left');

$t = $txt->Scrolled('Text', '-scrollbars' => 'se');
$t->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);

$choice->packAdjust('-side' => 'left', '-fill' => 'both', '-expand' => 1);
$top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 1);
$txt->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);

MainLoop;

sub ex {
exit;
}

Jack D

2004-09-08, 8:56 pm

"Torsten Mohr" <tmohr@s.netic.de> wrote in message
news:chnk1u$akg$1@schleim.qwe.de...
> Hi,
>
> in the example below i get strange results when:
>
> 1. i drag the Adjuster, it seems the Listbox is not
> resized
>
> 2. When i make the whole window larger, not only the
> Tk::Text is enlarged, but also the Frame "top", that
> only contains the "Exit" button.
>
> Is this related to the used Tk::Scrolled widget?
>
>
> Best regards,
> Torsten.
>
>
> #! /usr/bin/perl -w
>
> use Tk;
>
> $mw = MainWindow->new();
>
> $top = $mw->Frame();
> $txt = $mw->Frame();
> $choice = $mw->Frame();
>
> $lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
> $lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);
#######
$lb->pack(-in=>$choice, '-side' => 'left', '-fill' => 'both', '-expand' =>
1);
#######
>
> $q = $top->Button('-text' => 'Exit', '-command' => \&ex);
> $q->pack('-side' => 'left');
>
> $t = $txt->Scrolled('Text', '-scrollbars' => 'se');
> $t->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);
>
> $choice->packAdjust('-side' => 'left', '-fill' => 'both', '-expand' => 1);
> $top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 1);
#######
$top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 0);
#######

> $txt->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);
>
>
> MainLoop;
>
> sub ex {
> exit;
> }
>

Jack

zentara

2004-09-09, 3:58 pm

On Wed, 08 Sep 2004 20:46:22 +0200, Torsten Mohr <tmohr@s.netic.de>
wrote:
>
>$lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
>$lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);

Hi, just a style comment. Before you get into a "habit" of doing it,
the left side of an options hash element, dosn't need to be quoted.
Not only will it save you some keystrokes, it helps "colorization"
in editors which highlight Perl syntax.

>
>$lb = $mw->Scrolled('Listbox', -scrollbars => 'se');
>$lb->pack(-side => 'left', -fill => 'both', -expand => 1);

--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Torsten Mohr

2004-09-09, 3:58 pm

Jack D wrote:

Thanks! That solves both problems.

Best regards,
Torsten.

Torsten Mohr

2004-09-09, 3:58 pm

Hi,

> Hi, just a style comment. Before you get into a "habit" of doing it,
> the left side of an options hash element, dosn't need to be quoted.
> Not only will it save you some keystrokes, it helps "colorization"
> in editors which highlight Perl syntax.

i once got the hint in this newsgroup that i should quote
the keys because at the moment it works, but this may change
in future.

Best regards,
Torsten.

Ala Qumsieh

2004-09-09, 3:58 pm

Torsten Mohr wrote:
> Hi,
>
>
>
>
> i once got the hint in this newsgroup that i should quote
> the keys because at the moment it works, but this may change
> in future.

Not exactly :) If I'm not mistaken, you got the hint that you should
have a leading dash in front of your option keys since old Tk versions
allowed option names with no leading dashes.

The quotes are not required in this case because of Perl's "fat comma"
operator (=> ) which is identical to a normal comma, except that it
automagically treats what is on its left as a quoted string. So, the
following are identical:

-option => 'value'

and

'-option', 'value'

--Ala

Matthew Braid

2004-09-09, 8:56 pm

Ala Qumsieh wrote:
<snip>

> The quotes are not required in this case because of Perl's "fat comma"
> operator (=> ) which is identical to a normal comma, except that it
> automagically treats what is on its left as a quoted string. So, the
> following are identical:
>
> -option => 'value'
>
> and
>
> '-option', 'value'
>
> --Ala

Isn't the leading dash technically an exception to the rule? I thought the rule
was if the thing on the left of the fat comma looks like a bareword it will be
automagically quoted, otherwise it will be evaluated. Since lots of people use
the -name form for keys in an option hash a 'negated bareword' exception was
added to the rule.

I may of course be completely wrong :)
MB

Ala Qumsieh

2004-09-10, 3:58 am

Matthew Braid wrote:

> Isn't the leading dash technically an exception to the rule?

Yes. Perl recognizes that this is a bareword and not a "negative
string". It does not attempt to subtract it from nothing. Otherwise, you
would get warnings like:

Argument "option" isn't numeric in subtraction at ...

(assuming you have warnings enabled of course).

But this has nothing to do with the fact that earlier Tk versions
allowed options without dashes. Tk804 requires the dashes.

> I thought
> the rule was if the thing on the left of the fat comma looks like a
> bareword it will be automagically quoted, otherwise it will be
> evaluated. Since lots of people use the -name form for keys in an option
> hash a 'negated bareword' exception was added to the rule.

I never saw => evaluate its left hand side, and couldn't come up with a
case were it will. According to perlop, the left hand side of => will
always be treated as a quoted string:

The => operator is a synonym for the comma, but forces any word to its
left to be interpreted as a string (as of 5.001). It is helpful in
documenting the correspondence between keys and values in hashes, and
other paired elements in lists.

--Ala

Matthew Braid

2004-09-10, 3:58 am

Ala Qumsieh wrote:

<snip>
>
>
> I never saw => evaluate its left hand side, and couldn't come up with a
> case were it will. According to perlop, the left hand side of => will
> always be treated as a quoted string:
>
> The => operator is a synonym for the comma, but forces any word to its
> left to be interpreted as a string (as of 5.001). It is helpful in
> documenting the correspondence between keys and values in hashes, and
> other paired elements in lists.
>
> --Ala

Sorry, by 'evaluated' I meant it is considered to be a normal expression, eg:

$two = 2;
%hash = (1 => "one",
$two => "two",
1 + $two => "three",
FOUR => 4);
print join(", ", sort keys %hash), "\n";

results in:
1, 2, 3, FOUR

not
$two, 1, 1 + $two, FOUR

or some other weird output.

MB

Ala Qumsieh

2004-09-10, 3:58 am

Matthew Braid wrote:

> Sorry, by 'evaluated' I meant it is considered to be a normal
> expression, eg:
>
> $two = 2;
> %hash = (1 => "one",
> $two => "two",
> 1 + $two => "three",
> FOUR => 4);
> print join(", ", sort keys %hash), "\n";
>
> results in:
> 1, 2, 3, FOUR
>
> not
> $two, 1, 1 + $two, FOUR
>
> or some other weird output.

That's due to precedence. Again, perlop to the rescue:

left terms and list operators (leftward)
left ->
nonassoc ++ --
right **
right ! ~ \ and unary + and -
left =~ !~
left * / % x
left + - .
left << >>
nonassoc named unary operators
nonassoc < > <= >= lt gt le ge
nonassoc == != <=> eq ne cmp
left &
left | ^
left &&
left ||
nonassoc .. ...
right ?:
right = += -= *= etc.
left , =>
nonassoc list operators (rightward)
right not
left and
left or xor

Terms have highest precedence, so they get evaluated first. Addition has
a higher precedence than =>, so it gets executed next:

1 + $two => "two"
becomes
1 + 2 => "two"
becomes
3 => "two"

--Ala

Ala Qumsieh

2004-09-10, 4:00 pm

Ala Qumsieh wrote:

> Terms have highest precedence, so they get evaluated first. Addition has
> a higher precedence than =>, so it gets executed next:
>
> 1 + $two => "two"
> becomes
> 1 + 2 => "two"
> becomes
> 3 => "two"

Randal pointed out this gotcha on clpmisc a while ago:

use constant CONST => 'hello';
my %x = (CONST => 1);
print ">>$_<<\n" for keys %x;
__END__

This prints:

CONST

The fat comma forced CONST to be treated as a literal string, instead of
substituting it for its value. To get the "correct" behaviour, you have
to do this:

my %x = (CONST() => 1);

That works beceause constants are implemented as inlinable subroutines.
This is all described in 'perldoc constant' of course ;)

--Ala

Sponsored Links