Home > Archive > PerlTk > December 2004 > Subwidgets
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Rob Seegel 2004-11-24, 3:57 am |
| I know the various arguments about breaking encapsulations and all, but
I could really use a more convenient method of
configuing subwidgets. I'm currently in the process of revamping
JComboBox. I've compiled a list of complaints and ideas
from the past year or so, and I'm trying to smooth out the rough spots,
simplify it where I can, while at the same time adding
some new functionality. My approach is to document the Subwidgets as
well as I can -- especially where developers might run into
trouble when configuring them directly, and to phase out several options.
I'm using another method, that would be highly convenient if it or
something like it were added to Tk::Derived. I think I've
mentioned the method on this forum or c.l.p.tk before -- It's called:
configureSubwidgets. An example usage would be something
like:
$jcomboBox->configureSubwidgets(
## Config a blue background for both Button and popup
[qw/Button Popup/] => { -bg => 'blue' },
## Config white background, and blue foreground for Box and Listbox
[qw/Box Listbox/] => { -bg => 'white', -fg => 'blue' },
## Config borderwidth of 2, relief of sunken for Popup
Popup => { -bd => 2, -relief => 'sunken' }
);
This method would take 1..n pairs of Subwidget name(s)/Config
Parameters, the first iterm in the pair would be a single Subwidget name
or an Array reference containing one or more Subwidget names, and the
second item would contain a hash ref of configuration parameters that
would be passed to the named Subwidget(s). It's meant as a convenience
more than anything else. JComboBox will also have a -subwidgets option
that will be able to take a similar structure.
I'm interested in what people think of this idea (The good, bad, and the
ugly), and In the end, it doesn't particularly bother me one way or
another if functionality like this goes into Tk::Derived or not, but it
would allow me to take it out of several other widgets I'm working on ;-)
Rob
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to majordomo@lists.stanford.edu
| |
| zentara 2004-11-24, 4:00 pm |
| On Tue, 23 Nov 2004 22:50:47 -0500, Rob Seegel <RobSeegel@comcast.net>
wrote:
>I know the various arguments about breaking encapsulations and all, but
>I could really use a more convenient method of
>configuing subwidgets.
>I'm interested in what people think of this idea (The good, bad, and the
>ugly), and In the end, it doesn't particularly bother me one way or
>another if functionality like this goes into Tk::Derived or not, but it
>would allow me to take it out of several other widgets I'm working on ;-)
>
>Rob
I'm not well-versed enough in module design to comment on whether your
idea is good or bad; BUT I do LIKE the idea of making the subwidgets
easily accesible to manipulate. It seems that only a few Tk modules
actually have "Advertised Subwidgets", like in Tk::ExecuteCommand.
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
| |
| Slaven Rezic 2004-11-30, 8:57 pm |
| Rob Seegel <RobSeegel@comcast.net> writes:
> I know the various arguments about breaking encapsulations and all,
> but I could really use a more convenient method of
> configuing subwidgets. I'm currently in the process of revamping
> JComboBox. I've compiled a list of complaints and ideas
> from the past year or so, and I'm trying to smooth out the rough
> spots, simplify it where I can, while at the same time adding
> some new functionality. My approach is to document the Subwidgets as
> well as I can -- especially where developers might run into
> trouble when configuring them directly, and to phase out several options.
>
> I'm using another method, that would be highly convenient if it or
> something like it were added to Tk::Derived. I think I've
> mentioned the method on this forum or c.l.p.tk before -- It's called:
> configureSubwidgets. An example usage would be something
> like:
>
> $jcomboBox->configureSubwidgets(
> ## Config a blue background for both Button and popup
> [qw/Button Popup/] => { -bg => 'blue' },
> ## Config white background, and blue foreground for Box and Listbox
> [qw/Box Listbox/] => { -bg => 'white', -fg => 'blue' },
>
> ## Config borderwidth of 2, relief of sunken for Popup
> Popup => { -bd => 2, -relief => 'sunken' }
> );
>
> This method would take 1..n pairs of Subwidget name(s)/Config
> Parameters, the first iterm in the pair would be a single Subwidget
> name or an Array reference containing one or more Subwidget names, and
> the second item would contain a hash ref of configuration parameters
> that would be passed to the named Subwidget(s). It's meant as a
> convenience more than anything else. JComboBox will also have a
> -subwidgets option that will be able to take a similar structure.
>
> I'm interested in what people think of this idea (The good, bad, and
> the ugly), and In the end, it doesn't particularly bother me one way
> or another if functionality like this goes into Tk::Derived or not,
> but it would allow me to take it out of several other widgets I'm
> working on ;-)
>
ConfigSpecs has already Subwidget support. You can write something
like
$w->ConfigSpecs(
-background => [ {-background => 'subwidget1',
-foreground => 'subwidget2' },
undef, undef, 'blue'
],
);
to use the -background option to configure subwidget1's background and
subwidget2's foreground, both by default blue.
See the Tk::ConfigSpecs manpage.
Regards,
Slaven
--
Slaven Rezic - slaven <at> rezic <dot> de
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to majordomo@lists.stanford.edu
| |
| Rob Seegel 2004-12-01, 3:56 am |
| Slaven Rezic wrote:
>ConfigSpecs has already Subwidget support. You can write something
>like
>
> $w->ConfigSpecs(
> -background => [ {-background => 'subwidget1',
> -foreground => 'subwidget2' },
> undef, undef, 'blue'
> ],
> );
>
>to use the -background option to configure subwidget1's background and
>subwidget2's foreground, both by default blue.
>
>
I think I must not have explained very well.
I know about ConfigSpecs and have used it quite a bit in the past, but
are you suggesting using it outside of say a Populate method? I tend to
reserve it for use in setting up Composites, exclusively as the designer
of the composite. It lays out basic rules. Not something I'd use as a
user of that Composite. ConfigSpecs, by itself, is a fairly passive
mechanism that doesn't apply configurations to a widget. It stores the
"option rules" for other methods to use to do the configuring.
What I'm getting at is a shortcut for having to do the following:
$cw->Subwidget('Listbox')->configure( -fg => 'blue', -bg => 'white');
$cw->Subwidget('Button')->configure( -fg => 'blue', -bg => 'yellow');
I'd rather be able to have a simple method do this:
$cw->configureSubwidgets(
[qw/Listbox Button/] => { -fg => 'blue' },
Listbox => { -bg => 'white' },
Button => { -bg => 'yellow'}
);
I see this as coexisting with ConfigSpecs -- not replacing it, and
giving users of Composites a single method to configure a composites
Subwidgets to their liking. One benefit of this, is that I can define a
Hash that has these options and pass it with one method to each of my
composites if I'm using more than one.
Could I instead use ConfigSpecs to setup a new option that applies
foreground to both "Listbox" and "Button" subwidgets ? Sure, but given
even a moderate number of Subwidgets, this approach could easily be
taken to extremes. I could conceivable end up with such options as:
-listbackground
-listforeground
-listheight
-listwidth
-listrelief
-listborderwidth
-buttonbackground
.....
and many many more besides. I think this also serves to make the
Composite less accessible to others, if they have to learn dozens
(perhaps even more than a hundred depending on the number of
subwidgets!). Used in moderation, I think this can be a good approach to
use for a select number of often used combinations. Otherwise, it seems
burdensome to me.
Regards,
Rob
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to majordomo@lists.stanford.edu
|
|
|
|
|