tcltk-perl

[tcltk-perl] radical rethink of Tk's loading ... (no C)

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

Here is an idea I have about changing around Tcl::Tk, and it's
fairly fundamental:

Change Tcl::Tk::new as follows:

     $i->SUPER::Init();
-    $i->Init();
+    #$i->Init();
+    $i->Eval("package require Tk 8.4");
+    $i->call('trace', 'add', 'command', '.', 'delete',
+            sub { $W{'.'} = undef; });
+    $i->ResetResult();
     $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");

and then add the following command:

sub MainLoop {
    my $int = (ref $_[0]?shift:$tkinterp);
    while (defined $W{'.'}) {
       $int->DoOneEvent(0);
    }
}

The one thing this requires is the addition of Tcl_DoOneEvent to
Tcl.xs (which I did for testing this).  Everything seems to work
just fine after these changes.  I had to make a few more to force
the Tk module on Linux not to load the dll (which isn't necessary
in any case, but I haven't fully excised it from the build), but
the crux of the changes work.

This means that the only C component is on the Tcl side - there
is NO Tk C component, only Tk.pm.  The loading an initialization
of Tk is build into the 'package require Tk' statement.

The disadvantage here is removing any access at the C level to
Tk stuff, but currently there is nothing there we use.

At the same time, I have a patch which adds Tcl stubs support to
the Tcl module.  That means we gain Tcl version independence and
have more control over what Tcl is used at runtime.  More on
that here:

http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

Jeff

RE: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

In addition to this, there is a large extra question ...

This reduced Tcl::Tk to only .pm files.  That means we can
consider collapsing it all into the 'Tcl' distribution.  Is
this something we should consider?

Advantages - single distro makes it easier to maintain.

Disadvantages - are we going to reach a painful growth level?
Will Tcl::Tk have numerous submodules eventually that we want
to split out?  Will there be C components for other Tk-related
modules that we don't yet support, but would like to?

Jeff

> -----Original Message-----
> From: tcl...@li... 
> [mailto:tcl...@li...] On Behalf Of 
> Jeff Hobbs
> Sent: Wednesday, April 28, 2004 4:28 PM
> To: tcl...@li...
> Subject: [tcltk-perl] radical rethink of Tk's loading ... (no C)
> 
> 
> Here is an idea I have about changing around Tcl::Tk, and 
> it's fairly fundamental:
> 
> Change Tcl::Tk::new as follows:
> 
>      $i->SUPER::Init();
> -    $i->Init();
> +    #$i->Init();
> +    $i->Eval("package require Tk 8.4");
> +    $i->call('trace', 'add', 'command', '.', 'delete',
> +            sub { $W{'.'} = undef; });
> +    $i->ResetResult();
>      $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");
> 
> and then add the following command:
> 
> sub MainLoop {
>     my $int = (ref $_[0]?shift:$tkinterp);
>     while (defined $W{'.'}) {
>        $int->DoOneEvent(0);
>     }
> }
> 
> The one thing this requires is the addition of Tcl_DoOneEvent 
> to Tcl.xs (which I did for testing this).  Everything seems 
> to work just fine after these changes.  I had to make a few 
> more to force the Tk module on Linux not to load the dll 
> (which isn't necessary in any case, but I haven't fully 
> excised it from the build), but the crux of the changes work.
> 
> This means that the only C component is on the Tcl side - 
> there is NO Tk C component, only Tk.pm.  The loading an 
> initialization of Tk is build into the 'package require Tk' statement.
> 
> The disadvantage here is removing any access at the C level 
> to Tk stuff, but currently there is nothing there we use.
> 
> At the same time, I have a patch which adds Tcl stubs support 
> to the Tcl module.  That means we gain Tcl version 
> independence and have more control over what Tcl is used at 
> runtime.  More on that here:
> http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

> This reduced Tcl::Tk to only .pm files.  That means we can
> consider collapsing it all into the 'Tcl' distribution.  Is
> this something we should consider?

I think this is really good.

For me, it was not very clear from very beginning why those must be two
modules. I supposed 'Tcl' module without Tcl::Tk needed for those who needs
Tcl without Tk, but I thought it is quite rare when a person must use Tcl
but can't use Tk.

What name of final distribution will be? I suggest moving to Tcl-Tk.



>
> Advantages - single distro makes it easier to maintain.
>
> Disadvantages - are we going to reach a painful growth level?
> Will Tcl::Tk have numerous submodules eventually that we want
> to split out?  Will there be C components for other Tk-related
> modules that we don't yet support, but would like to?

You mean, once we'll remove Tk.xs it will be not possible to add C code
afterwards?
But in this case code could be just added to Tcl.xs

Or I did not understood another possible problems with this?


> > Here is an idea I have about changing around Tcl::Tk, and
> > it's fairly fundamental:
> >
> > Change Tcl::Tk::new as follows:
> >
> >      $i->SUPER::Init();
> > -    $i->Init();
> > +    #$i->Init();
> > +    $i->Eval("package require Tk 8.4");
> > +    $i->call('trace', 'add', 'command', '.', 'delete',
> > +            sub { $W{'.'} = undef; });
> > +    $i->ResetResult();
> >      $Tcl::Tk::TK_VERSION = $i->GetVar("tk_version");
> >
> > and then add the following command:
> >
> > sub MainLoop {
> >     my $int = (ref $_[0]?shift:$tkinterp);
> >     while (defined $W{'.'}) {
> >        $int->DoOneEvent(0);
> >     }
> > }
> >
> > The one thing this requires is the addition of Tcl_DoOneEvent
> > to Tcl.xs (which I did for testing this).  Everything seems
> > to work just fine after these changes.  I had to make a few
> > more to force the Tk module on Linux not to load the dll
> > (which isn't necessary in any case, but I haven't fully
> > excised it from the build), but the crux of the changes work.
> >
> > This means that the only C component is on the Tcl side -
> > there is NO Tk C component, only Tk.pm.  The loading an
> > initialization of Tk is build into the 'package require Tk' statement.

I think this will only be good.
Tk.xs is extremely small and no-one will notice if it will be removed :)

However removing any C code from Tcl::Tk does not necessarily mean we must
join both modules. We might do joining a little bit later.

> >
> > The disadvantage here is removing any access at the C level
> > to Tk stuff, but currently there is nothing there we use.
> >
> > At the same time, I have a patch which adds Tcl stubs support
> > to the Tcl module.  That means we gain Tcl version
> > independence and have more control over what Tcl is used at
> > runtime.  More on that here:
> > http://aspn.activestate.com/ASPN/docs/ActiveTcl/tcl/TclLib/InitStubs.htm

I vote for moving forward.

Best regards,
Vadim.

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

Vadim Konovalov wrote:
>>This reduced Tcl::Tk to only .pm files.  That means we can
>>consider collapsing it all into the 'Tcl' distribution.  Is
>>this something we should consider?
> 
> I think this is really good.
> 
> For me, it was not very clear from very beginning why those must be two
> modules. I supposed 'Tcl' module without Tcl::Tk needed for those who needs
> Tcl without Tk, but I thought it is quite rare when a person must use Tcl
> but can't use Tk.
> 
> What name of final distribution will be? I suggest moving to Tcl-Tk.

I was thinking of leaving it as "Tcl" (the distro), and it
includes modules for 'use Tcl' and 'use Tcl::Tk'.  The use of
Tcl::Tk can and is still independent of those that still want
to just use Tcl.

Also, we might want to consider a bigger number jump if we do
this (perhaps to 1.0?).  At the same time, we can remove some
of the older bits of cruft exposed in the C API.  Every time I
look at some of those exposed bits, it reminds me of Tcl circa
1994.  We should move beyond that and make the integration
between the two really seamless.

>>Disadvantages - are we going to reach a painful growth level?
>>Will Tcl::Tk have numerous submodules eventually that we want
>>to split out?  Will there be C components for other Tk-related
>>modules that we don't yet support, but would like to?
> 
> 
> You mean, once we'll remove Tk.xs it will be not possible to add C code
> afterwards?
> But in this case code could be just added to Tcl.xs
> 
> Or I did not understood another possible problems with this?

If we remove Tk.xs, it means we will not be compiling anything
that requires any direct build connection to Tk.  We rely on
Tcl to handle that, treating Tk just like any other module we
would load (as Tk really is now in the Tcl world).  If you
wanted to add Tk_* C API invocations, that would argue for
maintaining the separate Tcl-Tk dist.

> However removing any C code from Tcl::Tk does not necessarily mean we must
> join both modules. We might do joining a little bit later.

Correct, so perhaps I'll just remove the Tcl::Tk C stuff and we
can reconsider joining the modules at a later date, after we
have adjusted to Tcl::Tk being pure Perl, and not missing any
access to Tk_* C APIs.

> I vote for moving forward.

OK, if there are no other objections, I'll do this tomorrow and
set both Tcl and Tcl-Tk to 0.80 (prep'd for a weekend release).

Jeff

Re: [tcltk-perl] radical rethink of Tk's loading ... (no C)

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

I'm all for this change and for merging it all under the 'Tcl' name.

I would even suggest that we bundle Tcl/Tk in the distribution itself.
Then we have a known version we interface against and there are no
prereqs to install the module from CPAN.  I think this is needed to
compete with 'Tk' which already does this.

We should then adopt a version number derived from the version of
Tcl/Tk we bundle.

--Gisle