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.