tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

[Joe E. <jen...@fl...>]

[I wrote]

> I used the keywords "single"/"multiple" because that seems more
> intuitive than "browse"/"extended" (even though the behavior
> is closer to what the core listbox calls the latter).

Addendum: consistency with Tk important for Tile, except for
the (rare) areas where Tk's design itself is flawed; and
I've never liked the single/multiple/browse/extended scheme.

This was apparently copied from the Motif XmList widget (which I've
always suspected originally just had "single" and "multiple" modes that
didn't work very well so "browse" and "extended" got added later as
"unbreak-my-program" options.  But maybe that's just me...)


--JE

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

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

Joe English wrote:
> I used the keywords "single"/"multiple" because that seems 
> more intuitive than "browse"/"extended" (even though the 
> behavior is closer to what the core listbox calls the latter).

Er .... umm, it may be more blackbox intuitive, but since we already have
-selectmode as an option elsewhere using different terms for the similar
behavior (and more specifically different behavior for the terms you chose),
wouldn't it be best to go with browse/extended?

Jeff

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:
> [JE]:
> > '-selectmode extended' and '-selectmode browse' were omitted
> > on purpose. These are well-established, but not, I think,
> > terribly well-defined.
>
> I would disagree on the choices.  I use treectrl quite a bit, and have used
> many related trees.  The -selectmode browse is the most common, and indeed th
> e default of the core listbox.  It is what users will most commonly expect.
> -selectmode extended would also be useful (disjoint multiple selection).  I
> think multiple and single are in fact the least common variants.

Agreed, and in fact the behavior with '-selectmode single'
is much like a listbox with '-selectmode browse' (selection
is linked to the focus item, etc.)  Likewise a ttk::treeview
with '-selectmode multiple' acts (mostly) like a core listbox
with '-selectmode extended'.

I used the keywords "single"/"multiple" because that seems more
intuitive than "browse"/"extended" (even though the behavior
is closer to what the core listbox calls the latter).


--Joe English

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

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

> For review: proposed '-selectmode' option for the=20
> ttk::treeview widget.

> |	  Controls how the built-in class bindings manage  the selection.
> |	  One of multiple, single, or none.

> This is (intentionally) a minimal set, intended to cover only=20
> the two most common use cases.  If applications need=20
> something different, they can use '-selectmode none' and=20
> implement whatever behaviour they want in widget and/or tag=20
> bindings. This should (hopefully!) not be too difficult.

> '-selectmode extended' and '-selectmode browse' were omitted=20
> on purpose. These are well-established, but not, I think,=20
> terribly well-defined.

I would disagree on the choices.  I use treectrl quite a bit, and have =
used
many related trees.  The -selectmode browse is the most common, and =
indeed the
default of the core listbox.  It is what users will most commonly =
expect.
-selectmode extended would also be useful (disjoint multiple selection). =
 I
think multiple and single are in fact the least common variants.

Jeff

[Tile-dev] ttk::treeview -selectmode option; please review.

[Joe E. <jen...@fl...>]

For review: proposed '-selectmode' option for the ttk::treeview widget.

|   Command-Line Name:-selectmode
|   Database Name:  selectMode
|   Database Class: SelectMode
|
|	  Controls how the built-in class bindings manage  the  selection.
|	  One of multiple, single, or none.
|
|	  If  set  to  multiple  (the  default),  multiple  items  may  be
|	  selected.  If single, only a single item will be selected  at  a
|	  time.  If none, the selection will not be changed.
|
|	  Note  that  application code and tag bindings can set the selec-
|	  tion however they wish, regardless of the value of  -selectmode.


This is (intentionally) a minimal set, intended to cover only
the two most common use cases.  If applications need something
different, they can use '-selectmode none' and implement
whatever behaviour they want in widget and/or tag bindings.
This should (hopefully!) not be too difficult.

Other potentially-useful selection modes I can think of are:

Single-selection submodes:
    + selection optional or exactly one item selected?
    + independent focus or focus item linked to selection?

Multiple-selection submodes:
    + contiguous or disjoint selection?
    + "anchored" mode or "expansion" mode when extending selection?
    + <B1-Motion>: extend selection, or begin drag-and-drop?

Current choices are: focus item linked to selection in 'single' mode;
selection extension uses "anchored" mode (anchor is the focus item);
disjoint selections are allowed; <B1-Motion> is currently a no-op.

'-selectmode extended' and '-selectmode browse' were omitted on purpose.
These are well-established, but not, I think, terribly well-defined.



--Joe English

  jen...@fl...

[Tile-dev] Tile Toplevel?

[Joey M. <jo...@sw...>]

I was browsing the wiki and found this gem from Schelte Bron:

proc ttk::toplevel {w args} {
    eval [linsert $args 0 ::toplevel $w]
    place [ttk::frame $w.tilebg] -x 0 -y 0 -relwidth 1 -relheight 1
    set w
}

It seems to work really well and I always wondered why Tile couldn't
do a toplevel window since it's obviously drawing them.

Anyway, is there any reason why this isn't in the main tile core?

Thanks,
Joey

[Tile-dev] New feature: treeview item tags

[Joe E. <jen...@fl...>]

Now in CVS: treeview item tags.

Treeview tags are inspired by the core [text] and [canvas] widgets;
they're used to associate event binding scripts with items and
to configure the item appearance.   Updated manpage here:

    <URL: http://tktable.sourceforge.net/tile/doc/treeview.html >

In the [text] widget, each character has a set of tags; configuration
options are set on tags; and tag precedence order is global to the whole
widget.  In the [canvas] widget, each item has a list of tags; and
configuration options are set on *items* and modified *through* tags
(i.e., [$canvas tag configure foo ...] only applies to items that currently
have tag 'foo').

The treeview widget takes yet a third approach: each item has
an ordered list of tags, specified by the '-tags' item option;
configuration options are stored on tags, and are applied to
items dynamically; tag precedence order is per-item, determined
by the -tags option list order.

There are two new tag-related commands:

    $tv tag bind _tag_ ?<sequence> ?script....??
    	Specifies an event binding script for the specified tag.
	When an event is delivered to an item, matching binding scripts
	for each of the item's tags are evaluated in order
	as per bindtags(n).

	<KeyPress>, <KeyRelease>, and virtual events are sent
	to the focus item.  <ButtonPress>, <ButtonRelease>,
	and <Motion> events are sent to the item under the mouse pointer.
	No other event types are supported.


   $tv tag configure _tag_ ?-option ?value ...??
   	Query or modify tag options.  Available options are:
	-foreground, -background, -font; and possibly -image,
	-text, and -anchor.

There are still some kinks to work out with [$tv tag configure ...],
mostly related to the order of precedence relative to style options,
style dynamic settings, item options, and column options.

[$tv tag bind ...] works pretty well though.


Possible future enhancements:

 * Column names are tags.
    Automatically apply an additional tag to each data cell corresponding
    to its column name.  This would allow bindings and configuration options
    to be applied to individual columns.

 * $tv tag map -option ?statespec value ...?
    Specify state-specific option settings for tags, analogous
    to [style map ...].

 * Convenience methods for tag modification:
    [$tv tag ...] subcommands to add, remove, raise, lower, and/or otherwise
    reorder item tags, either globally or for a specified list of items.

 * Convenience methods for searching:
    [$tv tag ...] subcommand to return a list of all items having
    a specified tag or set of tags.

 * -rowtags and -columntags widget options.
    Right now, you get "zebra stripes" in the treeview widget
    whether you want them or not.  "-rowtags" would specify
    a cyclic list of tags to apply to each display row in
    order (if -rowtags is an $n-element list, then tag
    ($i % $n) is applied to display row $i).  So for example
    the current zebra-stripe effect could be achieved with:

    	$tv configure -rowtags [list even odd]
	$tv tag configure even -background #EEEEEE

    The -rowtags list can contain any number of elements,
    so longer repeating patterns are possible.

    -columntags would work the same way.

 * %I (current item), %C (current column), and %T (current tag)
    substitutions in tag binding scripts.  This isn't strictly
    necessary since the same information is available with
    [$tv identify ...] and [$tv focus]; and I'd rather not
    have to do it if possible as this involves pretty much
    completely rewriting Tk_BindEvent() and related functions;
    but it might end up being necessary for:

 * Support <Enter>/<Leave> and <FocusIn>/<FocusOut> events
    Send <Leave>/<Enter> events (resp Focus events) when the
    active item (resp focus item) changes.

Coming up next: treeview -selectmode option.


--Joe English

  jen...@fl...

Re: [Tile-dev] Widget 'identify' methods

[Georgios P. <pe...@ii...>]

I also think you should make the identify option consistent across all 
tile widgets.
And I will suggest to rename paned to panedwindow, as Tk uses, even if 
this means
breaking existing scripts...

George

Re: [Tile-dev] Widget 'identify' methods

[Will D. <Wil...@jp...>]

I'd say ttk::panedwindow rather than ttk::paned.

Also, I think you should make identify/element identical
across ttk:: widgets--and add an additional command for
widgets with special needs, i.e., the ttk::notebook.

Will

On Sep 17, 2006, at 4:44 PM, Joe English wrote:

>
> Jeff Hobbs wrote:
>> Joe English wrote:
>>> Recently, Pat added an "identify" method to all Tile widgets
>>> that previously lacked one.  Usage is: [$w identify $x $y],
>>> which returns the name of the element at $x,$y.  This is useful
>>
>> Maybe 'element' would be a better name them?
>
> The core [scrollbar], [scale], and [spinbox] widgets
> all have "identify" methods that mean essentially
> the same thing as the Tile versions (that's where
> the name came from...)
>
> The [panedwindow] 'identify x y' method returns a two-element
> list (sash index, element under the pointer), so there's
> precedent for variant behaviors too.
>
>>> [re: ttk::paned widget]
>>
>> 2 points - this *really* needs to be renamed ttk::panedwindow [...]
>
> Straw poll: what do others think about this?  Should
> [ttk::paned] be renamed?  And if so, is it worth breaking
> existing scripts?  (Actually they won't break immediately,
> [ttk::deprecated ttk::paned ttk::panedwindow] would be
> in effect for a release or two to smooth the transition...)
>
>
> --Joe English
>
>   jen...@fl...
>
> ----------------------------------------------------------------------- 
> --
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your job  
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>
>
------------------------------------------------------------------------
Will Duquette, JPL  | Wil...@jp...
But I speak only    | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself.         | It's amazing what you can do with the right tools.

Re: [Tile-dev] Widget 'identify' methods

[Damon C. <da...@tc...>]

+1 for panedwindow.

Damon


Joe English wrote:
> Jeff Hobbs wrote:
>   
>> Joe English wrote:
>>     
>>> Recently, Pat added an "identify" method to all Tile widgets
>>> that previously lacked one.  Usage is: [$w identify $x $y],
>>> which returns the name of the element at $x,$y.  This is useful
>>>       
>> Maybe 'element' would be a better name them?
>>     
>
> The core [scrollbar], [scale], and [spinbox] widgets
> all have "identify" methods that mean essentially
> the same thing as the Tile versions (that's where
> the name came from...)
>
> The [panedwindow] 'identify x y' method returns a two-element
> list (sash index, element under the pointer), so there's
> precedent for variant behaviors too.
>
>   
>>> [re: ttk::paned widget]
>>>       
>> 2 points - this *really* needs to be renamed ttk::panedwindow [...]
>>     
>
> Straw poll: what do others think about this?  Should
> [ttk::paned] be renamed?  And if so, is it worth breaking
> existing scripts?  (Actually they won't break immediately,
> [ttk::deprecated ttk::paned ttk::panedwindow] would be
> in effect for a release or two to smooth the transition...)
>
>
> --Joe English
>
>   jen...@fl...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>   

Re: [Tile-dev] Widget 'identify' methods

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:
> Joe English wrote:
> > Recently, Pat added an "identify" method to all Tile widgets
> > that previously lacked one.  Usage is: [$w identify $x $y],
> > which returns the name of the element at $x,$y.  This is useful
>
> Maybe 'element' would be a better name them?

The core [scrollbar], [scale], and [spinbox] widgets
all have "identify" methods that mean essentially
the same thing as the Tile versions (that's where
the name came from...)

The [panedwindow] 'identify x y' method returns a two-element
list (sash index, element under the pointer), so there's
precedent for variant behaviors too.

> > [re: ttk::paned widget]
>
> 2 points - this *really* needs to be renamed ttk::panedwindow [...]

Straw poll: what do others think about this?  Should
[ttk::paned] be renamed?  And if so, is it worth breaking
existing scripts?  (Actually they won't break immediately,
[ttk::deprecated ttk::paned ttk::panedwindow] would be
in effect for a release or two to smooth the transition...)


--Joe English

  jen...@fl...

Re: [Tile-dev] Widget 'identify' methods

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

Joe English wrote:
> Recently, Pat added an "identify" method to all Tile widgets
> that previously lacked one.  Usage is: [$w identify $x $y],
> which returns the name of the element at $x,$y.  This is useful

Maybe 'element' would be a better name them?

> For [ttk::paned], the 'identify' method returns a two-element
> list containing the index of the sash at $x,$y followed by
> the name of the sash element.  (At least that's how it's
> documented -- in reality the element name lookup is
> Not Yet Implemented.  This would be useful for e.g.,
> sashes with "collapse" and "expand" buttons.)

2 points - this *really* needs to be renamed ttk::panedwindow, and 
collapseable sashes would be cool.

> For [ttk::treeview], the 'identify' method is a hairball
> and needs to be revised anyway.

but it is an important method.

> So my question: should the ttk::notebook 'identify' method
> be changed to work like the ttk::paned widget (how it's
> documented, that is, not how it's currently implemented)?
> Or is it worthwhile to make [$w identify] consistent across
> all widget classes like 'configure', 'cget', and 'state' are?

My $.02 are make ttk::notebook have a useful identify method (or call it 
something else), as I also think the identify/element method should be 
consistent across themed widgets.  At this point, I'm more inclined 
towards the 'element' method name, as that is rare in other widgets (the 
treectrl has one).

Jeff

[Tile-dev] Widget 'identify' methods

[Joe E. <jen...@fl...>]

Recently, Pat added an "identify" method to all Tile widgets
that previously lacked one.  Usage is: [$w identify $x $y],
which returns the name of the element at $x,$y.  This is useful
in conjunction with custom layouts for creating certain types
of megawidgets: class bindings can do different things depending
on which element was pressed.

There are a couple exceptions, though -- the ttk::treeview
and ttk::paned widgets already had 'identify' methods
with a different return value.

For [ttk::paned], the 'identify' method returns a two-element
list containing the index of the sash at $x,$y followed by
the name of the sash element.  (At least that's how it's
documented -- in reality the element name lookup is
Not Yet Implemented.  This would be useful for e.g.,
sashes with "collapse" and "expand" buttons.)

For [ttk::treeview], the 'identify' method is a hairball
and needs to be revised anyway.

The ttk::notebook widget currently uses the generic
'identify' method implementation.  This is not as useful
as it could be, since it only examines the notebook's base
layout and what you're generally interested in is the tabs.
See SF#1458239 for primary use case ("close" buttons in tabs).

So my question: should the ttk::notebook 'identify' method
be changed to work like the ttk::paned widget (how it's
documented, that is, not how it's currently implemented)?
Or is it worthwhile to make [$w identify] consistent across
all widget classes like 'configure', 'cget', and 'state' are?

(With the latter solution, [$w identify] would return
the tab/sash or base layout element, and the tab/sash index
could be identified with a different method).

I'm leaning towards the former approach.

--Joe English

Re: [Tile-dev] Tile & notebook tabs...

[Joe E. <jen...@fl...>]

[ Cc: tktable-tile-dev, as this is probably of general interest ]

Georgios Petasis wrote:

> I am not sure I have understood how to develop tab elements in tile themes.
> In my tileqt extension I need to draw "outside" of a tab area when
> when a tab is raised. In the current implementation, I simply draw outside.
> This worked for some earlier versions of tile, but not with the latest ones.

Hm.  Drawing outside the tab's bounding box should still work,
don't know why it doesn't.  But see below for more.

> Can you please explain in a few words how tabs that expand should be
> drawn? Tabs is the last thing that I have to fix in order to release
> tileqt 0.4 [...]

Notebook tab placement in 0.7.6 is a bit more flexible than
it was before.  The layout is controlled by the "-tabposition"
and "-tabmargins" TNotebook style options, and the "-expand"
TNotebook.Tab style option.

"-tabposition" is a labelanchor string, as in the labelframe widget,
specifying where to place the tabs.  Default is "nw", or you can use
"n" to get centered tabs like in (old-style) Aqua notebooks.

"-tabmargins" and "-expand" are both padding specifications.
The notebook adds "-tabmargins" padding outside the tab row as a
whole, and "-expand" specifies how much to stretch individual tabs.
("-expand" is like [grid]'s "-ipadx" and "-ipady" options, except
that the extra space is allocated outside the parcel instead
of inside.)

So for example: to make the selected tab overlap the notebook
border, you could use:

    style default TNotebook -borderwidth 2
    style map TNotebook.Tab -expand [list selected {0 0 0 2}]

To make the selected tab overlap its neighbors and expand upwards
into the margins (like on Windows XP) you could use:

    style default TNotebook -tabmargins {2 2 2 0} -tabposition nw
    style map TNotebook.Tab -expand [list selected {2 2 2 0}]

You can also adjust the Tab "-padding" option to get different
effects -- add extra padding at the bottom of the selected tab
to make the label "pop up" (as in the "alt" theme), or add it
at the top to keep the baseline aligned (as in the "clam" theme).


 * * *

A few more things are still needed to support all the common
notebook styles.  For "-tabposition [ew]*", the notebook should
pack tabs from top to bottom instead of left to right.  Themes
need to define separate layouts for left-, right-, and bottom-
side tabs.  There should be something like the ttk::labelframe's
"-labeloutside false" to get (new-style) Aqua tabs that are
centered on the client pane border; and there needs to be a
way to distinguish the first and last tabs (again for new-style
Aqua tabs).


--Joe English

  jen...@fl...

Re: [Tile-dev] Tk Tile & Windows

[Michael F. <mi...@pc...>]

Pat Thoyts wrote:
> Michael Foord <mi...@pc...> writes:
>
>   
>> The 0.7.6 announcement says that a prebuilt windows binary 'may' be
>> available. It isn't available for download via sourceforge (yet). Does
>> anyone have a successfully built binary for windows that I could use ?
>>     
>
> I'll try and get on with it.
>
>   
Great. I'm nearly ready to use it. :-)

Thanks

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Re: [Tile-dev] Size grip widget added

[Donal K. F. <don...@ma...>]

Joe English wrote:
> ttk::sizegrips can handle toplevels with gridded geometry,
> but not those placed relative to the right or bottom
> of the screen, i.e., if negative X or Y coordinates are
> specified for [wm geometry].  
> 
> (Tk implements negative positions in a not-quite-ICCCM-compliant
> way, which leads to bad interactions with some WMs when
> resizing.  For the same reason, ttk::sizegrips only support
> "southeast" resizing.)

FWIW, it's not worthwhile doing much hacking around with other anchor
locations anyway; I've seen any number of window managers not handle it
quite right. I can't remember ever seeing it's equivalent in use on
non-X11 platforms either. Maybe lots of things support it, but nobody
seems to use it. Sounds like "let users provide a patch to make it work
after release :-)" to me...

Donal.

[Tile-dev] Size grip widget added

[Joe E. <jen...@fl...>]

Now in CVS: a new 'ttk::sizegrip' widget, the gizmo
that sits in the lower right corner of a window
that users can drag around to resize the window.

Native appearance on Windows, Windows XP, and OSX.
(ttk::sizegrips are redundant on OSX, since Tk automagically
inserts one for you, but putting a ttk::sizegrip in can help
to keep other widgets lined up properly.)

No options or methods other than the standard ones;
all behaviour is implemented in the class bindings.

ttk::sizegrips can handle toplevels with gridded geometry,
but not those placed relative to the right or bottom
of the screen, i.e., if negative X or Y coordinates are
specified for [wm geometry].  

(Tk implements negative positions in a not-quite-ICCCM-compliant
way, which leads to bad interactions with some WMs when
resizing.  For the same reason, ttk::sizegrips only support
"southeast" resizing.)


--Joe English

  jen...@fl...

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Joe E. <jen...@fl...>]

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

  jen...@fl...

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Adam R. <av...@am...>]

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/

and 

  generic/make

As well as the Makefile(s) in generic.

Thanks!

-Adam


> > 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
> 
>   jen...@fl...

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Joe E. <jen...@fl...>]

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

  jen...@fl...

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Adam R. <av...@am...>]

[...]

> 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)?

Attached.

This is what the directory looks like -- the one I ran configure and
make in:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-rw-r--r--  1 501   501    2618 May  6 11:18 ANNOUNCE.txt
-rw-r--r--  1 501   501  160838 May  6 10:59 ChangeLog
-rw-r--r--  1 root  501    8045 Jul 22 20:22 Makefile
-rw-r--r--  1 501   501    7003 Oct 23  2005 Makefile.in
-rw-r--r--  1 501   501    3195 Oct 17  2004 README.txt
-rw-r--r--  1 501   501      51 Nov  9  2004 aclocal.m4
-rw-r--r--  1 root  501   47365 Jul 22 20:22 config.log
-rwxr-xr-x  1 root  501   26052 Jul 22 20:22 config.status*
-rwxr-xr-x  1 501   501  409129 Apr 20 15:08 configure*
-rw-r--r--  1 501   501    1818 Apr 20 15:07 configure.in
-rwxr-xr-x  1 root  501  406223 Jul 22 20:22 configure.lineno*
drwxr-xr-x  3 501   501     512 May  6 11:18 demos/
drwxr-xr-x  4 501   501    1024 May  6 11:18 doc/
drwxr-xr-x  2 501   501    1024 Jul 17 20:31 generic/
drwxr-xr-x  2 501   501    1024 May  6 11:18 library/
-rw-r--r--  1 501   501    1169 Oct 13  2003 license.terms
drwxr-xr-x  2 501   501     512 May  6 11:18 macosx/
drwxr-xr-x  2 501   501     512 Jul 17 10:53 tclconfig/
drwxr-xr-x  2 501   501    1024 May  6 11:18 tests/
drwxr-xr-x  2 501   501     512 May  6 11:18 tools/
drwxr-xr-x  2 501   501     512 May  6 11:18 win/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Thanks.

-Adam

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Joe E. <jen...@fl...>]

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

Re: [Tile-dev] [Fwd: Re: building on freebsd]

[Mats B. <ma...@pr...>]

Forwarded from av...@am...:


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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

BTW: the reason I installed tktable package is because I thought it
contained the tile subpackage, but I don't think it does (I could be
wrong, but I'm not sure how to tell):

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
hydra[~]# find / -name "tile.tcl" -print
/usr/home/adamrich/src/tcl/kits/coccinella/bin/library/tile/tile.tcl
/usr/local/src/tile-0.7.6/library/tile.tcl
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

tile.tcl was only found in the coccinella sources and the tile sources.

  [tcl.h]

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

I haven't seen any other errors before this one.

-Adam


> > Date: Tue, 18 Jul 2006 10:37:36 -0700
> > From: Joe English <jen...@fl...>
> > To: tkt...@li...
> > Subject: Re: [Tile-dev] building on freebsd
> > 
> > 
> > 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
> > 
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys -- and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Tktable-tile-dev mailing list
> > Tkt...@li...
> > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> > 

Re: [Tile-dev] building on freebsd

[Joe E. <jen...@fl...>]

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

[Tile-dev] building on freebsd

[Mats B. <ma...@pr...>]

I've got one potential Coccinella user that is trying to build tile on freebsd, can you help him?

/Mats

---------------------------------------------------------------------------------
I've started by trying to get tile installed.  I am able to get 
configure to work: 

++++++++++++++++++++++++++++++ +++++++++++++ 
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 
++++++++++++++++++++++++++++++ +++++++++++++ 

Looking at the relevant lines in source generic/tkstate.c which is 
causing make to fail: 

++++++++++++++++++++++++++++++ +++++++++++++ 
[...] 
static 
struct Tcl_ObjType StateSpecObjType = 
{
   "StateSpec", 
   StateSpecFreeIntRep, 
   StateSpecDupIntRep, 
   StateSpecUpdateString, 
   StateSpecSetFromAny 
}; 
[...] 
++++++++++++++++++++++++++++++ +++++++++++++ 

I'm not really that familiar with Tcl/Tk infrastructure so I'm not sure 
where to go from here...