TkTable / Tile / Vu

Mats Bengtsson wrote:
>
> [Forwarded from avr at amazon]
>
> Here's what I have installed:
>
>   [tcl/tk freebsd ports/packages]
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> hydra[~]# pkg_info | grep "tcl|tk" | grep -v "gtk|atk"
> py24-tkinter-2.4.3_1   Python bindings to the Tk widget set
> tcl-8.4.13_1,1         Tool Command Language
> tcltls-1.5.0           SSL extensions for TCL; dynamicly loadable
> tk-8.4.13,2            Graphical toolkit for TCL
> tktable-2.8_1          A table/matrix widget extension to tk/tcl
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[...]

> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> hydra[~]# find / -name "tcl.h" -print
> /usr/local/include/tcl8.4/generic/tcl.h
> /usr/local/include/tcl8.4/tcl.h
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So it looks like the tcl-8.4.13 port includes all the
requisite headers.

And, from earlier:

> hydra[/usr/local/src/tile-0.7.6]# ./configure
> --with-tcl=/usr/local/lib/tcl8 .4/ --with-tk=/usr/local/lib/tk8.4 /

This looks correct too.  Still not enough information
to diagnose what's going wrong, unfortunately.

Could you email me the full output of the 'configure'
process, the generated Makefile, and the full output
of 'make' (standard output and standard error)?

Better yet, are there any FreeBSD users on the list? :-)
FreeBSD is a completely sane system, building Tile there
*should* be painless and easy.  It's probably just a
matter of the autoconf dwimmery guessing badly and going astray.


--Joe English

Adam Richards wrote:
>
> This is what the directory looks like -- the one I ran configure and
> make in [...]

Aha!  Now I see what the problem is.

Excerpt from configure output:

> checking for Tcl private include files... Using srcdir found in tclConfig.sh: ${WRKDIRPREFIX}/usr/ports/lang/tcl84/work/tcl8.4.13
> checking for Tk private include files... Using srcdir found in tkConfig.sh: ${WRKDIRPREFIX}/usr/ports/x11-toolkits/tk84/work/tk8.4.13


Excerpt from Makefile:

> INCLUDES	=  -I. -I"./generic" \
>		  -I"${WRKDIRPREFIX}/usr/ports/lang/tcl84/work/tcl8.4.13/generic" -I"${WRKDIRPREFIX}/usr/ports/lang/tcl84/work/tcl8.4.13/unix" -I"${WRKDIRPREFIX}/usr/ports/x11-toolkits/tk84/work/tk8.4.13/generic" -I"${WRKDIRPREFIX}/usr/ports/x11-toolkits/tk84/work/tk8.4.13/unix" -I/usr/X11R6/include


So this is the usual TEA_PRIVATE_TCL_HEADERS brokenness.

(Cause of the problem: by default, the TEA_PRIVATE_{TCL|TK}_HEADERS
autoconf macros only work if the Tcl/Tk source directories
are still present on the system.  The FreeBSD tcl port doesn't
keep the original sources around, and apparently doesn't take
the additional steps necessary to make TEA_PRIVATE_*_HEADERS
work.  Many distributions don't.)

It is possible to build Tile without Tk private headers, at least
on Unix.  Try the alternate build system in the "generic" subdirectory:

	cd generic;
	./configure; make ; make test
	make install

That ought to work.


--Joe English

  jenglish@...

Adam Richards wrote:

>
> Ok, so I tried the alternate configure and make.  Got a different error
> this time -- make failed for tile.c.  I've attached the output of:
>
> generic/configure --with-tcl=/usr/local/lib/tcl8.4/
>     --with-tk=/usr/local/lib/tk8.4/

Argh, sorry, that should have been:

	cd generic;
	./configure --disable-private-headers \
	    [... --with-tcl, --with-tk as before ]

I forgot that --disable-private-headers is off by default now.


--Joe English

  jenglish@...

Mats Bengtsson wrote:

> I've got one potential Coccinella user that is trying to build tile on 
> freebsd, can you help him?
> 
[...]
> hydra[/usr/local/src/tile-0.7.6]# ./configure 
> --with-tcl=/usr/local/lib/tcl8.4/ --with-tk=/usr/local/lib/tk8.4 /
[...]
> but `make' is failing: 
> 
> ++++++++++++++++++++++++++++++ +++++++++++++ 
> [...] 
> ./generic/tkstate.c: At top level: 
> ./generic/tkstate.c:50: error: storage size of `StateSpecObjType' isn't 
> known 
> *** Error code 1 
> ++++++++++++++++++++++++++++++ +++++++++++++ 


Are there any other error messages before this one?

"storage size of `StateSpecObjType' isn't known" 
probably means that <tcl.h> wasn't found (the compiler
should have complained about that...), which in turn
probably means that the user's tcl development environment
isn't set up properly.

For FreeBSD, this is probably just a matter of running
"pkg_add tcl" or something similar -- any FreeBSD users
around who can fill in the details?



--JE

My reading of your list ordering had me questioning immediately the sense of
#1 and #2 order.  I don't know that I'm relying on it (I have various
specialized bits), but I would vote to modify it regardless.

Jeff

Joe English wrote:
> Currently, the Tile theme engine uses the following 
> precedence order for computing element options:
> 
>     1. Dynamic settings specified by [style map ...]
>     2. Widget options specified by [$w configure ...]
>     3. Style defaults specified by [style configure ...]
>     4. Built-in defaults supplied by the element
> 
> So [style map ...] settings override widget settings.
> 
> If I remember correctly, the rationale for this order was so 
> that [style map ...] settings would act the same way as the 
> state-specific widget options like "-activeforeground" that 
> they replaced.  
> 
> However, I can't think of any use cases where this ends up 
> being helpful, and there's at least one case where it's 
> undesirable (see #1517110).  I'm starting to think that #1 
> and #2 should be swapped, so that widget options always take 
> precedence.
> 
> Any thoughts?  Is anyone relying on the current behavior?

[I wrote]:
>
> So [style map ...] settings override widget settings. [...]
> However, I can't think of any use cases where this ends up
> being helpful [...]

Found one: aquaTheme.tcl uses this feature to disable the
"-underline" option on buttons and other widgets:

|    style map . -underline {{} -1}

This is mostly a convenience hack for cross-platform portability.
Macintosh applications don't traditionally use underlining to highlight
mnemonics (and the "Alt" modifier doesn't work on OSX anyway).
The idea was that apps developed for Windows or X11 wouldn't
need to conditionally remove all the "-underline" specifications
when running under OSX.

So this hack won't work any more.  That's probably not a big deal.


--Joe English

  jenglish@...