tcltk-perl

[tcltk-perl] how to extract perlTk support to separate files (modules)

[Konovalov, V. <vko...@sp...>]

Once we have now every type of perlTk widget to live on its own package --
(Button in Tcl::Tk::Widget::Button and so on), it will be extremely easy to
separate those into separate module and have them removed from Tk.pm file.

Say, create files
./lib/Tcl/Tk/Widget/Menu.pm
./lib/Tcl/Tk/Widget/Menubutton.pm

put proper text in there (we already have text in $Tcl::Tk::VTEMP), put
there methods (those are currently arguments to
"create_method_in_widget_package") and here it is.
Need only to replace in those subroutines $wint{$$wid} with more correct
$wid->interp

After small addition to Tcl::Tk::Widget::AUTOLOAD widget package will be
loaded on demand.

Right now, Tk.pm is small enough, and I think there's no real need to remove
something yet.
Module could grow twice its size, then we'll move out documentation to
Tcl::Tk.pod file.

However I'll move one or more Tix widgets to see how it works and to create
a sample way for other widgets to follow.
First candidate is Tix's Balloon widget.

If anyone have ideas, please let me know.

Best regards,
Vadim.

[tcltk-perl] %replace_options question

[Vadim K. <va...@ar...>]

while implementing pTk compatibility widget "BrowseEntry" I used
%replace_options and it looks to me keys to this hash must be perlTk name
and not Tcl/Tk name, because different widgets could be implemented with a
single Tcl/Tk widget (it appears BrowseEntry cound be implemented with
ComboBox)

Should I change %replace_options logic a bit?

Vadim.

RE: [tcltk-perl] %replace_options question

[Jeff H. <je...@Ac...>]

> while implementing pTk compatibility widget "BrowseEntry" I 
> used %replace_options and it looks to me keys to this hash 
> must be perlTk name and not Tcl/Tk name, because different 
> widgets could be implemented with a single Tcl/Tk widget (it 
> appears BrowseEntry cound be implemented with ComboBox)
> 
> Should I change %replace_options logic a bit?

If that's what is necessary, although I don't know quite what you mean
without an example ...

Jeff

Re: [tcltk-perl] %replace_options question

[Vadim K. <va...@ar...>]

> > while implementing pTk compatibility widget "BrowseEntry" I
> > used %replace_options and it looks to me keys to this hash
> > must be perlTk name and not Tcl/Tk name, because different
> > widgets could be implemented with a single Tcl/Tk widget (it
> > appears BrowseEntry cound be implemented with ComboBox)
> >
> > Should I change %replace_options logic a bit?
>
> If that's what is necessary, although I don't know quite what you mean
> without an example ...

I just added few lines to implement perlTk's BrowseEntry
Browseentry.pm in perlTk lives in "Tixish" directory, but I did not found it
in Tix.

Nevertheless, it appears BrowseEntry could be implemented with ComboBox.

So I add
     ComboBox   => {-choices=>'-values'},
to %replace_options

This is slightly odd, because someone who previously inserted that line to
hash did not intended to have "-choices".

Another way will be better: I'll add key pair
     BrowseEntry   => {-choices=>'-values'},
and nothing outside said widget will be touched.

Interesting to say, implementing perlTk's TList in a level needed by my
application, ended with adding just one line to %ptk2tcltk and fwe lines to
need_tk!

Vadim.

[tcltk-perl] EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

I really want to change name of Tcl::EV to Tcl::Ev

ALL-CAPS names usually used for constant subroutines and for some special
for Perl subroutines, and never such names are used to just name ordinary
subroutine, like in our case.

Please add your argumentation, and better yet let us agree to rename it.

Best regards,
Vadim.

[tcltk-perl] Re: EV subroutine in Tcl.pm

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
> I really want to change name of Tcl::EV to Tcl::Ev
> 
> ALL-CAPS names usually used for constant subroutines and for some special
> for Perl subroutines, and never such names are used to just name ordinary
> subroutine, like in our case.
> 
> Please add your argumentation, and better yet let us agree to rename it.

OK, I was just trying to differentiate from the original.
I have started using it in code, so I will just have to watch
for that commit and change those references.

I still prefer using the ('%X', '%Y') argument style though.
Since users have to change their code around anyway, it seems
safe to make it more explicit what they are doing.  I suppose
you could still support \\'XY' given ref-ref-scalar's are
unlikely to be used as regular arguments.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

> > I really want to change name of Tcl::EV to Tcl::Ev
> >
> > ALL-CAPS names usually used for constant subroutines and for some
special
> > for Perl subroutines, and never such names are used to just name
ordinary
> > subroutine, like in our case.
> >
> > Please add your argumentation, and better yet let us agree to rename it.
>
> OK, I was just trying to differentiate from the original.
> I have started using it in code, so I will just have to watch
> for that commit and change those references.

Differentiate from original is easy - once you see \\'XY' you catch an error
and ask user to fix.
But once you started using that newer scheme -- indeed, it's another.

But as long as Tcl.pm changes are very hot, it will be easy to change this
back, because you remember what you recently did.
And, again, once you'll rename EV->Ev, you'll get diagnostic quickly and
will fix them.

>
> I still prefer using the ('%X', '%Y') argument style though.
> Since users have to change their code around anyway, it seems
> safe to make it more explicit what they are doing.  I suppose
> you could still support \\'XY' given ref-ref-scalar's are
> unlikely to be used as regular arguments.

This is not what I need :)
As long as there is no simpliest to user just Ev('X'), any reasonable scheme
is fine to me.

Jeff, will you perform renaming EV->Ev? Please?

I will be very grateful.

Best regards,
Vadim.

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
>>>I really want to change name of Tcl::EV to Tcl::Ev
	...
> Jeff, will you perform renaming EV->Ev? Please?

I will do this conversion, but it may not be until Monday morning
as I'm not sure when I'll get into work this weekend (it's a nice,
sunny weekend here for a change :) ).

Jeff

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

> I will do this conversion, but it may not be until Monday morning
> as I'm not sure when I'll get into work this weekend (it's a nice,
> sunny weekend here for a change :) ).

ok, I'll do this myself.

Have a nice weekend :)

Best regards,
Vadim.

[tcltk-perl] $widget->exists

[Gisle A. <gi...@Ac...>]

The following change:

             * lib/Tcl/Tk.pm: perlTk compatibility: sub PathName,
             Exists, class, toplevel, parent, *all* winfo methods.

broke our app, because we used $bwtree->exists($path) to access the
".tree exists path" subcommand of BWTree.  After this change this
method call was routed to winfo instead.  I fixed it in our sources be
removing the winfo override for exists.  I suggest we make that
official too.  There is already Tcl::Tk::Exists() for doing 'winfo
exists' checks.

Anyway, this illustrates that we need a better mechanism to deal with
conflicts like this.  There should be a way for force method calls to
resolve a particular way.

--Gisle

Re: [tcltk-perl] $widget->exists

[Jeff H. <je...@Ac...>]

Gisle Aas wrote:
> broke our app, because we used $bwtree->exists($path) to access the
> ".tree exists path" subcommand of BWTree.  After this change this
> method call was routed to winfo instead.  I fixed it in our sources be
> removing the winfo override for exists.  I suggest we make that
> official too.  There is already Tcl::Tk::Exists() for doing 'winfo
> exists' checks.

This is the correct way anyway, as the 'exists' method makes
most sense to be done without calling through the object
itself (it's like 'defined').

Jeff

[tcltk-perl] about difference in Tk.pm between 1.49 and 1.50

[Vadim K. <va...@ar...>]

Dear Jeff,

I see you did many changes in Tk.pm.

But in case you do such global replacement, please make sure you're doing
replacement correctly.

For me, there is no much improvement in writing everywhere

   my $int = $W{$$wid}->{'INT'};


instead of
   my $int = $wint{$$wid};

Here is why:
both are not perfect but yours is larger, yet will be a bit slower (takes
one more hash dereference).

For me, better is just to write

$wid->interp;


Actually, when doing such global replacement, please let it be finished way
of doing things, and let us agree on how things will be done. I think those
global package-wide hashes should actually be part of Tcl::Tk interpreter
object.

As Gisle already mentioned, simple changes should go directly to CVS but
serious changes should be discussed first, may be best way is to send such
patches to this list first.

Best regards,
Vadim.

[tcltk-perl] Re: about difference in Tk.pm between 1.49 and 1.50

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
> For me, there is no much improvement in writing everywhere
>    my $int = $W{$$wid}->{'INT'};
> instead of
>    my $int = $wint{$$wid};
> 
> Here is why:
> both are not perfect but yours is larger, yet will be a bit slower (takes
> one more hash dereference).
> 
> For me, better is just to write
> 
> $wid->interp;

I would prefer the latter as well, but according to Jan the method
call is much slower than the extra hash dereference, so I chose the
more gruesome code in the interim.

Jeff

[tcltk-perl] how to support pure-perl perlTk widgets?

[Vadim K. <va...@ar...>]

Implementation of pure-Perl widgets is based on Tix embedded into perlTk
(ConfigSpecs, ConstructWidget are parts of Tix and used in perlTk)
So, it could be possible to provide support for pure-Perl widgets using
namely that mechanism.

How do you all think, is it reasonable at all trying to support pure-perl
widgets?
Or have them re-implemented each time those are needed?

I, personally, do not like an idea for supporting those, and, at least, this
could be tried separatedly as independent effort once we'll have Tcl::Tk in
a good shape (and this is already the case, IMHO :)

Best regards,
Vadim.

[tcltk-perl] Re: about difference in Tk.pm between 1.49 and 1.50

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:

> Actually, when doing such global replacement, please let it be finished way
> of doing things, and let us agree on how things will be done. I think those
> global package-wide hashes should actually be part of Tcl::Tk interpreter
> object.

Ah, we crossed messages (see my related post).  As I said, it
wasn't meant to be final.

> As Gisle already mentioned, simple changes should go directly to CVS but
> serious changes should be discussed first, may be best way is to send such
> patches to this list first.

This was actually done to just fix bugs in the new design around
the class method subroutines for widgets.  I guess we all agree
on what should be done.  Today's work was mostly a learning effort,
but while not "cleaner", it did address several bugs.  I will take
dirty over broken anytime.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos