tktable-tile-dev — Discussion about tile development

RE: [Tile-dev] Tile in 8.5 Tk CVS head--how to use?

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

Kevin Walzer wrote:
> I'm trying to track down the documentation for how to use 
> Tile in Tk 8.5 CVS head, as it's now approved for inclusion 
> in the core. Trying "package require tile" in a recent build 
> of Tcl/Tk from CVS head resulted in "can't find package 
> tile". Am I doing something wrong? Or should I continue to 
> build Tile separately, as I was doing with Tk 8.4.12?

You made a couple mistakes ... first, assuming that we'd commited
the code yet (we'll certainly let people know), and second, using
'tile' as the package name.  As the TIP notes, the package name
will be Ttk in the core, not tile.

I was planning to get this in before xmas, but didn't quite
squeeze it in.  After a long vacation, I'll be working on it
again this month.

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

[Tile-dev] Tile in 8.5 Tk CVS head--how to use?

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to track down the documentation for how to use Tile in Tk 8.5
CVS head, as it's now approved for inclusion in the core. Trying
"package require tile" in a recent build of Tcl/Tk from CVS head
resulted in "can't find package tile". Am I doing something wrong? Or
should I continue to build Tile separately, as I was doing with Tk 8.4.12?

- --
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDwW9RJmdQs+6YVcoRAql9AJ9iremgJJ2H3aY7iwHjz+S9J4CzuQCgizrV
z9aJ9+BJz/scLQTnTdGBXxY=
=m4rW
-----END PGP SIGNATURE-----

Re: [Tile-dev] Question about Aqua column headers in treeview

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

Kevin Walzer wrote:

> Is there any flag in the Tile treeview widget that I can set that will
> turn the column headers blue on OS X when that column is selected? This
> effect is doable in tktreectrl, at least in some of the samples in the
> demo, and I'd like to do the same thing in Tile.

    $tv heading $column state selected

will turn the 'selected' state flag on, and

    $tv heading $column state !selected

will turn it off; this changes the heading appearance
in the aqua theme, but not on any others.

(On OSX it currently also displays a sort arrow -- don't
know why this was added.  NEM?)


--Joe English

  jen...@fl...

[Tile-dev] Question about Aqua column headers in treeview

[Kevin W. <sw...@wo...>]

Is there any flag in the Tile treeview widget that I can set that will 
turn the column headers blue on OS X when that column is selected? This 
effect is doable in tktreectrl, at least in some of the samples in the 
demo, and I'd like to do the same thing in Tile.

-- 
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com

[Tile-dev] blue theme blues

[Brian G. <bgr...@mo...>]

Hi,

I've been playing around with tile recently and spending a lot of time 
staring at the "blue" theme and I've come to the conclusion that the 
buttons are upside down.  If you swap the button-n and button-p images, 
it looks much better.  Reason:  light always comes from above-left.  The 
highlighting on the button has the light source on the bottom, while the 
vertical scrollbar has the light from the left.  This gives the 
appearance of sunken button, yet a raised vertical scrollbar.  And the 
horizontal scrollbar matches the button, both sunken.

IMHO,
-Brian

-- 
#                         You missed the
# 12th Annual Tcl/Tk Conference: Oct 24-28, 2005, Portland OR
#              http://www.tcl.tk/community/tcl2005
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-------------------------------------------------------------

Re: [Tile-dev] progress bar: fixed height?

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

Bryan Oakley wrote:

> I tried the progressbar in tile 0.7.2 for the first time today. Looks 
> prett spiffy on MacOSX!
> 
> However, the height (when oriented horizontally) seems fixed. When I use 
> place it in line with a status bar, it doesn't fill the cell in the Y 
> direction.
> 
> Is this going to be a fact of life, or is it a bug?

Probably a bug.  Something similar happens in the X11 themes --
the progress bar trough expands to fill the available height,
but the bar itself stays centered at the default thickness.

The following fixes this for the X11 themes:

    style theme settings default {
	style layout Horizontal.TProgressbar {
	    Horizontal.Progressbar.trough -sticky nswe -children {
		Horizontal.Progressbar.pbar -side left -sticky ns
	    }
	}
    }

(i.e., change the ".pbar" element from '-sticky {}' to '-sticky ns';
will fix this in CVS).

In the aqua theme, however, it's already using '-sticky nsew',
and the progress bar element draw function is passing the entire
parcel to DrawThemeTrack().  So the Appearance manager might be
hardwired to draw progress bars with the HIG-specified thickness.

Will investigate further (bug filed at SF: #1357605).


--Joe English

  jen...@fl...

[Tile-dev] progress bar: fixed height?

[Bryan O. <oa...@ba...>]

I tried the progressbar in tile 0.7.2 for the first time today. Looks 
prett spiffy on MacOSX!

However, the height (when oriented horizontally) seems fixed. When I use 
place it in line with a status bar, it doesn't fill the cell in the Y 
direction.

Is this going to be a fact of life, or is it a bug?

Here's a script that shows what I mean. On my box, the progressbar is 
only about half as tall as the statusbar.

Here's code to illustrate the problem:

package require tile 0.7.2

ttk::frame .main
ttk::frame .statusbar -borderwidth 2 -relief sunken
pack .statusbar -side bottom -fill x
pack .main -side top -fill both -expand y

ttk::button .main.start -text "Start" -command {busy 1}
ttk::button .main.stop -text "Stop" -command {busy 0}
pack .main.start .main.stop

ttk::progressbar .pb -length 64 -mode indeterminate
ttk::label .status -width 40
pack .pb -in .statusbar -side left -fill y
pack .status -in .statusbar -side left -fill both

proc busy {on} {
   if {$on} {
     .status configure -text "Working..."
     .pb start
   } else {
     .status configure -text ""
     .pb stop
   }
}

Re: [Tile-dev] tile treeview column heading alignment...

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

[ Catching up on email backlog ... ]

Several weeks ago, Bryan Oakley wrote:

> In the tile treeview it doesn't seem possible to change the anchor of
> the text in a column heading. Is this an intentional design decision
> either at the widget or style level? It seems like either the heading
> ought to have the same anchor as the column, or there should be a
> 'heading $column -anchor' option.


This was an accidental oversight -- [$tv heading $column -anchor]
ought to work.  This *would* be trivial to add, except for some
quirks in the way that the text, image, label, and heading elements
are currently put together; it'll just take a bit of shuffling around.

Questions: what should the default -anchor be?  Centered?
Would anyone object if I added an -anchor option that doesn't
work right now, but will maybe eventually work someday? :-)

Also, a heads up to any ttk::treeview users: I plan to change
the default bindings so that clicking on an item will no longer
automatically select it (see #1328192 for the rationale).

Right now, ttk::treeview does the right thing for many common
cases, but it's really, really hard to make it Not Do That for
those cases where the current behavior isn't desired.  It'd be
better for the treeview to do less by default (as long as there's
an easy way to make it do more, which currently isn't the case
either.)


--Joe English

  jen...@fl...

[Tile-dev] [ 1338148 ] ttk::scale crashes

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

I duplicate this bugreport here since it sometimes show up in SFs
bug list and sometimes not.
Direct link:
http://sourceforge.net/tracker/?group_id=11464&atid=111464&func=detail&aid=1338148

-----------------------

toplevel .t
set opacity 100
ttk::scale .t.s -orient horizontal -from 50 -to 100 \
  -variable opacity -value $opacity
pack .t.s

The following script isolates a crash scenario:

toplevel .t
set opacity 100
ttk::scale .t.s -orient horizontal -from 50 -to 100 \
  -variable opacity -value $opacity
pack .t.s


if destroyed and then executed once more.
Backtrace:
Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
 #0   0x018f0c10 in ScaleVariableChanged
 #1   0x018fa148 in VarTraceProc
 #2   0x0a070748 in CallVarTraces
 #3   0x0a06e064 in TclPtrSetVar
 #4   0x0a032ea4 in TclExecuteByteCode
 #5   0x0a031bb0 in TclCompEvalObj
 #6   0x0a0619dc in TclObjInterpProc
 #7   0x0a00eb00 in TclEvalObjvInternal
 #8   0x0a0325ac in TclExecuteByteCode
 #9   0x0a031bb0 in TclCompEvalObj
 #10  0x0a0619dc in TclObjInterpProc
...
Using scale.c version:
/* $Id: scale.c,v 1.45 2005/10/08 14:02:47 jenglish Exp $

See the attached screenshot.

Mats

Re: [Tile-dev] clam labelframe

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

Mats Bengtsson wrote:

> Noted that the -labelwidget must be a child of the labelframe and
> not a sibling. Is this an intentional change?
> The docs still describe the 0.6 behaviour.

The -labelwidget can be a sibling of the labelframe; however
you may need to [raise] the -labelwidget now, since the ttk::labelframe
doesn't do this automatically anymore.


--Joe English

  jen...@fl...

Re: [Tile-dev] clam labelframe

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

Noted that the -labelwidget must be a child of the labelframe and
not a sibling. Is this an intentional change?
The docs still describe the 0.6 behaviour.

/Mats


Joe English wrote:
> 
> Mats Bengtsson wrote:
> >
> > Seems that the border for labelframe in the clam theme is gone with 0.7.1
> > -1
> > If I want a labelframe without a border I can do this myself,
> > but not the opposite.
> 
> Works for me...
> 
> Is it possible that $::tile::library is pointing to an
> older installation?  There have been some labelframe changes
> since the last release, using the version of clamTheme.tcl
> from 0.6.4 with tile 0.7.2 would cause the symptoms you describe.
> 
> > Also the -labelwidget has no effect anymore.
> 
> This works for me too ...  A new OSX-specific problem maybe?
> 
> --Joe English
> 
>   jen...@fl...
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

Re: [Tile-dev] clam labelframe

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

Joe English wrote:
> 
> Mats Bengtsson wrote:
> >
> > Seems that the border for labelframe in the clam theme is gone with 0.7.1
> > -1
> > If I want a labelframe without a border I can do this myself,
> > but not the opposite.
> 
> Works for me...
> 
> Is it possible that $::tile::library is pointing to an
> older installation?  There have been some labelframe changes
> since the last release, using the version of clamTheme.tcl
> from 0.6.4 with tile 0.7.2 would cause the symptoms you describe.
> 

True.
Guess the best solution is to get rid of 0.6 completely.

Mats

Re: [Tile-dev] clam labelframe

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

Mats Bengtsson wrote:
>
> Seems that the border for labelframe in the clam theme is gone with 0.7.1
> -1
> If I want a labelframe without a border I can do this myself,
> but not the opposite.

Works for me...

Is it possible that $::tile::library is pointing to an
older installation?  There have been some labelframe changes
since the last release, using the version of clamTheme.tcl
from 0.6.4 with tile 0.7.2 would cause the symptoms you describe.

> Also the -labelwidget has no effect anymore.

This works for me too ...  A new OSX-specific problem maybe?


--Joe English

  jen...@fl...

[Tile-dev] clam labelframe

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

Seems that the border for labelframe in the clam theme is gone with 0.7.1
-1
If I want a labelframe without a border I can do this myself,
but not the opposite.
Also the -labelwidget has no effect anymore.

Mats

[Tile-dev] ANNOUNCE: Tile widget set version 0.7.2 released

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

[19 Oct 2005]

ANNOUNCE: Tile Widget Set, version 0.7.2.

~ What is it?

The Tile widget set is an experimental reimplementation
of some of the standard Tk widgets.  The main features are:

    + Native look and feel under Windows (XP, NT, 2K, 98 and 95)
    + Nearly-native look and feel under Mac OSX
    + "Revitalized" look and feel under X11
    + Appearance controlled by a theme engine, providing
      greater flexibility for custom widgets
    + New widgets, including notebook, progressbar, combobox,
      and separator

~ What's New in 0.7.2

* * * INCOMPATIBILITY * * * 

The Tk 8.4 widget compatibility options have been disabled in 
this release.  

* * * INCOMPATIBILITY * * *

[style default] has been changed to the more sensibly-named 
[style configure].  [style default] is temporarily retained
as a synonym.

The API may be considered more-or-less stable at this point 
(with the exception of procedures in the 'tile::*' namespace;
and ttk::treeview, ttk::dialog, and ttk::scale, which still 
have some more work to be done).

Other user-visible changes include:

ttk::entry widget validation behavior has changed; see manpage 
for details.

ttk::notebook tabs and ttk::paned panes no longer need to be
direct children of the master widget.

The ttk::scale '-showvalue' option has been removed
(this feature may reappear later).

The ttk::progress widget has been removed, as promised earlier.

More introspection features have been implemented.

Several bugs have been fixed; see ChangeLog for details.


~ A note on version numbers:

To help distinguish formal releases from CVS snapshots,
the version number returned by [package provide tile]
now includes a patch level, currently 0.7.2.

The patch number will be incremented immediately before and 
immediately after making a release.  Thus odd-numbered subminor
versions indicate a CVS snapshot, and even-numbered ones indicate
a known release.

Tile 0.7.2 corresponds to the CVS snapshot labelled '0.7.1' 
which was included in the recently-released ActiveTcl 8.4.11.2.


~ Availability

The tile widget set is hosted under the tktable project
at SourceForge:

    <URL: http://tktable.sourceforge.net/tile/ >
    <URL: http://sourceforge.net/projects/tktable/ >

Sources are available under the 'tile' module in CVS.
A prebundled tarball is available in the file release area:

    <URL: http://sourceforge.net/project/showfiles.php?group_id=11464 >

Documentation is available here:

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


Precompiled libraries for Windows may also be present;
check for availability.

[Tile-dev] Re: scale display options

[Goodwin L. <goo...@uc...>]

Hi Pat,

I implemented your idea for a -format option for the scale widget and 
put the patch up here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1233729&group_id=11464&atid=311464

You could also use the -format option for non-numerical display. Eg

::ttk::scale .s -format "Small" -value 0 -from 0 -to 2 -command UpdateScale
pack .s

proc UpdateScale {val} {
    if {$val < 1} {
       .s config -format "Small"
    } else {
       .s config -format "Big"
    }
}

you could, of course, include the value:
proc UpdateScale {val} {
    if {$val < 1} {
       .s config -format "%.2f - Small"
    } else {
       .s config -format "%.2f - Big"
    }
}

In the patch, I got around the overhang problem (for horizontal 
orientation anyway) by sticking the displayed text to the edge when it 
hits it (not overhanging it) and letting the slider then "catch up" as 
it approaches the edge.

Some issues:
-float->hex conversion. At the moment there's no way to get int->hex 
conversion (which may be what people expect).
- should the widget value should be formatted the same as the displayed 
value (it is in tk)

Having said this, I've no objections to a -displayvariable option.

Goodwin

Re: [MACTCL] Re: [Tile-dev] Universal binary of Tile: some progress

[Daniel A. S. <st...@ic...>]

Donal,

On Thursday, Sep 29, 2005, at 18:30 Australia/Sydney, Donal K. Fellows 
wrote:

> Kevin Walzer wrote:
>> Earlier, the build was dying after complaining that some defintions in
>> tkMacOSXInt.h had errors. Looking at the code in question, I noticed
>> that the lines began with the phrase "Module Scope," like this:
>> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
>> enable);
>> Commenting out those lines and replacing them without the phrase 
>> "module
>> scope" allowed the build to proceed, and I built Tile and Tktreectrl
>> successfully in the standard fashion (not as universal binaries).
>
> OK, that might indicate that TkMacOSXUseAntialiasedText may need to be
> promoted from a module-scoped symbol (i.e. utterly Tk-internal) to Tk's
> internal stubs table. No big deal if the symbol is needed.

I think the problem was more that I had introduced MODULE_SCOPE to 
tkaqua headers without adding the conditional definition of 
MODULE_SCOPE to tkInt.h from tclInt.h (will fix that when I commit 
various other small changes)

As MODULE_SCOPE is defined by tk configure on Mac OS X, this did not 
show up when building tk itself, only when using internal tkaqua 
headers from an extension where MODULE_SCOPE is not AC_DEFINEd...

>> I'm not sure why commenting out the "module scope" bits worked; I'm 
>> sure
>> that is there for a reason, but it's not clear to me.
>
> The module scope stuff is about trying to clean up the Tcl/Tk core so
> that symbols are exactly as widely available as they need to be. This
> really stems from the fact that its introducing a concept that
> traditional Unix linkers didn't support; symbol visibility wider than
> the file level but less than the application level.

FWIW, it appears the NEXT MachO linker had supported this with 
__private_extern__ for a long time, and the Mac OS X linker continues 
to do so, hence our #define MODULE_SCOPE __private_extern__

The only issue is that prior to Mac OS X 10.4, MODULE_SCOPE has to be 
present both at function declaration and function definition for the 
symbol to be unexported, I've started doing that in macosx specific 
tcl/tk sources, but not in the generic sources

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

[Tile-dev] scale display options

[Pat T. <pat...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The scale widget needs to be able to display it's value a bit more
flexibly. My first thought (nice and simple) was to provide a -format
option which just takes the string template for sprintf. eg:
~  ttk::scale .s -format 0x%08x -from 0 -to 65535
would have it displaying hex like 0x012345678.

However, the scale is often useful for more than numerical display. For
instance in a video display it may be desirable to display the time as
hours:minutes:seconds. Or this widget is sometimes used for selecting
coarse options like Small, Medium, Big (eg: Windows display settings for
screen size).

My thought was to provide a -displayvariable option which if set would
use the value of the variable name provided as the scale value display.
So for a video display we can use something like:

~  scale .s -from 0 -to end_of_movie -displayvariable ::dispvalue \
~     -command [list UpdateDisplay ::dispvalue]

~  proc UpdateDisplay {varname value} {
~      set $varname [DisplayTimecode $value]]
~  }
where SplitTimecode would convert a time in usec into something human
readable.

An alternative would be to have the widget use a command option instead
which would display the result of the command - however this seems
expensive to run each time we repaint widget. It would be possible to
cache the display result and invalidate it when the widget value changes
perhaps.

Another issue is what to do about handling overhang at the edges. I'm
not sure that adjusting the ends of the track according to the width of
the display value would be a good plan. It would end up making the
widget jiggle as the width of the display value changed.

Anyway - are we happy with a -displayvariable option? Or something else.
If we have such an option would we want -format as well?

Pat Thoyts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iQCVAwUBQzxhf2B90JXwhOSJAQhIbQP+IbHESvgGf16ZUuSa7tfDKndeURavYCss
x7ACSpNUW7MSkVX20l4bDiNlmpADbzfkEpm+Ll2ZzWGhudezM9OgJVzniBRos4C8
8VruDIvSNlO5EdH6LvthWvg5HzkmJhCuOb168D33wM3yZhtzYJhKw1b/iG+A2TlW
HfzRY+jJll4=
=DIEZ
-----END PGP SIGNATURE-----

Re: [Tile-dev] Universal binary of Tile: some progress

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

Kevin Walzer wrote:
> Earlier, the build was dying after complaining that some defintions in
> tkMacOSXInt.h had errors. Looking at the code in question, I noticed
> that the lines began with the phrase "Module Scope," like this:
> 
> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
> enable);
> 
> Commenting out those lines and replacing them without the phrase "module
> scope" allowed the build to proceed, and I built Tile and Tktreectrl
> successfully in the standard fashion (not as universal binaries).

OK, that might indicate that TkMacOSXUseAntialiasedText may need to be
promoted from a module-scoped symbol (i.e. utterly Tk-internal) to Tk's
internal stubs table. No big deal if the symbol is needed.

> I'm not sure why commenting out the "module scope" bits worked; I'm sure
> that is there for a reason, but it's not clear to me.

The module scope stuff is about trying to clean up the Tcl/Tk core so
that symbols are exactly as widely available as they need to be. This
really stems from the fact that its introducing a concept that
traditional Unix linkers didn't support; symbol visibility wider than
the file level but less than the application level.

Donal.

RE: [Tile-dev] Stippling images in disabled buttons

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

Joe English wrote:
> Tile widgets with an -image (buttons, labels, etc.) currently 
> draw the image stippled when they are in the disabled state, 
> like the core widgets do.
> 
> Would anyone complain if this feature went away?  

Went away in favor of not doing anything for disabled state?
No, that wouldn't be nice, but ...

> This behavior is disabled on OSX to work around an AquaTk bug 
> (#1100117); according to a recent post on comp.lang.tcl [*] 
> it doesn't work all 
> that well under X11 either (specifically, when the image has an 
> alpha channel); and even when it does work it doesn't look 
> very good (common practice nowadays is to use a desaturated, 
> darkened, or grayscale image instead of stippling).

Under X11 the stippling looks fine to me, but not on OS X
or Windows.  I actually had code that desaturated the image
by default on Windows.  It may even be x-platform code
(operating on the image).  I think the reason I didn't
commit it is that it operated on the fly (desaturating the
image at each request for repaint).

> Note that the Tile widgets allow the program to specify 
> state-dependent auxilliary images, so this effect is still 
> possible; it just takes some extra work on the programmer's 
> part.  We could provide a utility routine to automatically 
> generate "grayed-out" versions of icon images to ease the pain.

State based is best, but what about the default action
again?

Jeff

Re: [Tile-dev] Universal binary of Tile: some progress

[<lm...@bi...>]

On Wed, Sep 28, 2005 at 05:23:01PM -0700, Jeff Hobbs wrote:
> Joe English wrote:
> > Kevin Walzer wrote:
> > > I've done a bit more investigating on building Tile as a universal 
> > > binary on OS X. It seems like an issue with TkAqua rather than Tile, 
> > > because I'm seeing the same issues trying to build another extension
> > > (tktreectrl) as a universal binary.
> 	...
> > Also: did you run "./configure ; make" in the top-level tile 
> > directory or in tile/generic?  Whichever one you tried and it 
> > didn't work, try the other one and see if you have better 
> > luck.  The top-level build structure is "TEA-compliant" 
> > (meaning: works for Jeff); the one in generic/ is "Modified 
> > TEA" (meaning: works for me). Usually one or the other will 
> > eventually spit out a working shared library if you kick it 
> > hard enough, but since neither Jeff nor I have a Macintosh we 
> > can't make any guarantees.  Sorry.
> 
> I just want to note that I do have a Mac, but not a MacTel at
> this point.  I do build treectrl and tile on it regularly,
> but I haven't made any attempts to do universal binaries yet.

We have a MacTel and if we can help out let us know what you want.
We don't have a lot of spare cycles but we're trying to do stuff on
that box.  We have found that unlink/stat are busted, Oscar can give
you a pointer to bug report if you like.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

RE: [Tile-dev] Universal binary of Tile: some progress

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

Joe English wrote:
> Kevin Walzer wrote:
> > I've done a bit more investigating on building Tile as a universal 
> > binary on OS X. It seems like an issue with TkAqua rather than Tile, 
> > because I'm seeing the same issues trying to build another extension
> > (tktreectrl) as a universal binary.
	...
> Also: did you run "./configure ; make" in the top-level tile 
> directory or in tile/generic?  Whichever one you tried and it 
> didn't work, try the other one and see if you have better 
> luck.  The top-level build structure is "TEA-compliant" 
> (meaning: works for Jeff); the one in generic/ is "Modified 
> TEA" (meaning: works for me). Usually one or the other will 
> eventually spit out a working shared library if you kick it 
> hard enough, but since neither Jeff nor I have a Macintosh we 
> can't make any guarantees.  Sorry.

I just want to note that I do have a Mac, but not a MacTel at
this point.  I do build treectrl and tile on it regularly,
but I haven't made any attempts to do universal binaries yet.

Jeff

[Tile-dev] Re: [MACTCL] Universal binary of Tile: some progress

[Daniel A. S. <st...@ic...>]

Kevin,

On 29/09/2005, at 9:14, Kevin Walzer wrote:

> Earlier, the build was dying after complaining that some defintions in
> tkMacOSXInt.h had errors. Looking at the code in question, I noticed
> that the lines began with the phrase "Module Scope," like this:
>
> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
> enable);
>
> Commenting out those lines and replacing them without the phrase 
> "module
> scope" allowed the build to proceed, and I built Tile and Tktreectrl
> successfully in the standard fashion (not as universal binaries).
>
> I'm not sure why commenting out the "module scope" bits worked; I'm 
> sure
> that is there for a reason, but it's not clear to me.

the problem is that MODULE_SCOPE is not defined in you build, it looks 
like this is probably a bug on my end, it should be defined in tkInt.h 
as it is in tclInt.h, in the meantime, including tclInt.h before 
tkMacOSXInt.h should fix the problem. As mentioned, you can't rely on 
using those routines in tile anyway, so maybe tkMacOSXInt.h shouldn't 
be included at all

> Trying again as a universal binary (building against the 10.4 sdk, 
> -arch
> i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way
> through the builds before dying with this error message:
>
> ld: Undefined symbols:
> _tclStubsPtr
> _Tcl_InitStubs
> _Tk_InitStubs
> _tkStubsPtr
> _tkIntXlibStubsPtr
> _tkIntStubsPtr
> _tkIntPlatStubsPtr
> _tkPlatStubsPtr
> /usr/bin/libtool: internal link edit command failed
> lipo: can't figure out the architecture type of: /var/tmp//ccOMqrpA.out
> make: *** [libtile0.6.dylib] Error 1
>
> I'm not sure where these symbols are supposed to come in: perhaps
> someone with more knowledge than me would find this error message 
> useful?

this means that linking with the tcl/tk stubs lib goes wrong somehwere 
as these symbols are all defined in libtclstub.a resp libtkstub.a. Are 
you sure you are linking against universal stubs libs ? make sure those 
libs got built fat as well (check with lipo -info), otherwise rebuild 
your tcl & tk

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

Re: [Tile-dev] Universal binary of Tile: some progress

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

Kevin Walzer wrote:

> I've done a bit more investigating on building Tile as a universal
> binary on OS X. It seems like an issue with TkAqua rather than Tile,
> because I'm seeing the same issues trying to build another extension
> (tktreectrl) as a universal binary.
>  [...]
> Trying again as a universal binary (building against the 10.4 sdk, -arch
> i386, -arch ppc, and so on), Tile (and tktreectrl) got all the way
> through the builds before dying with this error message:
> ld: Undefined symbols:
> _tclStubsPtr
> _Tcl_InitStubs
> _Tk_InitStubs
> _tkStubsPtr
> _tkIntXlibStubsPtr
> _tkIntStubsPtr
> _tkIntPlatStubsPtr
> _tkPlatStubsPtr
> [...]
> I'm not sure where these symbols are supposed to come in: perhaps
> someone with more knowledge than me would find this error message useful?

That I can help with: all of the above come from the Tcl (resp Tk)
stubs libraries, {lib}{tcl|tk}stub{8.4|84|.8.4}.{a|lib}.

On OSX, IIRC, make sure the link line includes '-ltkstub8.4' and
'-ltclstub8.4'.  Also make sure that libXXXstubX.Y.a appear in
the linker search path; if not, add "-L" flags and/or
"-framework Tcl" / "-framework Tk" flags to the link line.

Also: did you run "./configure ; make" in the top-level tile directory
or in tile/generic?  Whichever one you tried and it didn't work,
try the other one and see if you have better luck.  The top-level
build structure is "TEA-compliant" (meaning: works for Jeff);
the one in generic/ is "Modified TEA" (meaning: works for me).
Usually one or the other will eventually spit out a working
shared library if you kick it hard enough, but since neither
Jeff nor I have a Macintosh we can't make any guarantees.  Sorry.


> Earlier, the build was dying after complaining that some defintions in
> tkMacOSXInt.h had errors. Looking at the code in question, I noticed
> that the lines began with the phrase "Module Scope," like this:
>
> ~ MODULE_SCOPE int TkMacOSXUseAntialiasedText(Tcl_Interp *interp, int
> enable);

That one I can't help with.  I have a suspicion that the MODULE_SCOPE
macro is just a bad idea that will eventually be expunged, but don't
know all the details yet.  Sorry.


--Joe English

Re: [MACTCL] Re: [Tile-dev] Problems building "universal binary" of Tile

[Daniel A. S. <st...@ic...>]

Kevin,

On 28/09/2005, at 12:46, Kevin Walzer wrote:

> Daniel Steffen also mentioned on the Tcl-Mac list that he is preparing
> some additional updates to Tcl-Mac to address things like byte swapping
> in preparation for the transition to MacTel.

sorry for not being more clear, my changes only concern a very small  
area of tcl HEAD in tclMacOSXFCmd.c, c.f. patch below; there is no  
global way to magically handle byte swapping issues like these, they  
can only be discovered by testing/debugging on an actual mactel box or  
by careful code inspection.

For instance, I discovered the issues in tclMacOSXFCmd.c by reading the  
Apple Universal Binary Programming Guidelines:
	http://developer.apple.com/documentation/MacOSX/Conceptual/ 
universal_binary/
and seeing two issues mentioned that I remembered from originally  
writing the tclMacOSXFCmd.c code...

There is no easier way than this unfortunately, and I would be wary of  
shipping any code to customers that has just been recompiled as  
universal without having gone through detailed testing on a transition  
kit, you'd be much better off having people run your existing binaries  
via Rosetta if you can't actually test on a mactel box before shipping.

>  After posting my earlier
> message, I also noticed some similar errors when I tried to compile
> tktreectrl as a universal binary.

tktreectrl is part of Darwin in Tiger and as such has been built  
successfully on i386 (I doubt it has been tested in detail though),  
what issues are you seeing exactly?

>  Perhaps once Daniel's new revisions are committed, that might address  
> the issue.

those changes certainly won't help with building a universal  
tktreectrl, as explained above

> |>I'm trying to build a "universal binary" of Tile on Mac OS X, 10.4,  
> with
> |>gcc 4. I've successfully compiled Tk, but during make, Tile returns
> |>these errors:
> |>
> |>In file included from ./macosx/aquaTheme.c:35:
> |>/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before
> |>'int'In file included from ./macosx/aquaTheme.c:35:
> |>/Users/kevin/tk/macosx/tkMacOSXInt.h:154: error: syntax error before  
> 'int'
> |>
> |>[ ... gobs of errors elided ... ]

it would be useful to track down further where this problem comes from,  
presumably you have tried building just for ppc with gcc4 and Tiger?  
otherwise this could be well a gcc4 or Tiger issue, tile may not have  
been built like that previously...

> | macosx/aquaTheme.c currently includes the following headers:
> |
> | | #include <Carbon/Carbon.h>
> | | #include <tk.h>
> | | #include <tkInt.h>
> | | #include <tkMacOSX.h>
> | | #include <tkMacOSXInt.h>
> | | #include "tkTheme.h"
> |
> |
> | Now I'm pretty sure that's the Wrong Thing -- it was arrived at
> | by trial and error, by adding, deleting, and reordering the #includes
> | until the file finally compiled on the machine I was using at the  
> time --
> | but I don't know what the Right Thing is.
> |
> | Any advice from AquaTk gurus?  aquaTheme.c needs the Carbon API(s),
> | plus a couple routines from the platform-specific public Tk API
> | (TkMacOSXGetDrawablePort and TkMacOSXWinBounds).  What headers
> | should be included, and in which order?

it should be sufficient to just #include <tkMacOSXInt.h>, which itself  
includes tkInt.h, tkMacOSX.h, tkPort.h and Carbon.h (as you can easily  
determine by looking at the top of that file...)

generally the rule should be that it is sufficient to include the most  
specific header file that you need for the APIs in question, with the  
header reform on HEAD reestablishing the order tk.h < tkPort.h <  
tkInt.h < tkMacOSXInt.h

I'm not sure if you actually need anything from tkMacOSXInt.h from your  
description, note that any function declarations in that file are not  
in the stubs table, and are no longer exported from the Tk shared lib  
in 8.5 at all (due to use of MODULE_SCOPE).

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  <mailto:st...@ma...>
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

Index: tclMacOSXFCmd.c
===================================================================
RCS file: /cvsroot/tcl/tcl/macosx/tclMacOSXFCmd.c,v
retrieving revision 1.4
diff -u -p -r1.4 tclMacOSXFCmd.c
--- tclMacOSXFCmd.c	25 Jul 2005 20:48:34 -0000	1.4
+++ tclMacOSXFCmd.c	28 Sep 2005 22:53:06 -0000
@@ -5,6 +5,7 @@
   *	subcommands of the "file" command.
   *
   * Copyright (c) 2003 Tcl Core Team.
+ *
   *
   * See the file "license.terms" for information on usage and  
redistribution of
   * this file, and for a DISCLAIMER OF ALL WARRANTIES.
@@ -19,6 +20,8 @@
  #include <sys/paths.h>
  #endif

+#include <libkern/OSByteOrder.h>
+
  /*
   * Constants for file attributes subcommand. Need to be kept in sync  
with
   * tclUnixFCmd.c !
@@ -46,9 +49,11 @@ static int		Tcl_GetOSTypeFromObj(Tcl_Int
  static Tcl_Obj *	Tcl_NewOSTypeStringObj(CONST OSType newOSType);

  enum {
-   kFinfoIsInvisible = 0x4000,
+   kIsInvisible = 0x4000,
  };

+#define kFinfoIsInvisible (OSSwapHostToBigConstInt16(kIsInvisible))
+
  typedef struct fileinfobuf {
      u_int32_t info_length;
      union {
@@ -56,8 +61,9 @@ typedef struct fileinfobuf {
  	    u_int32_t type;
  	    u_int32_t creator;
  	    u_int16_t fdFlags;
-	    u_int16_t location;
-	    u_int32_t padding[4];
+	    u_int32_t location;
+	    u_int16_t reserved;
+	    u_int32_t extendedFileInfo[4];
  	} finder;
  	off_t rsrcForkSize;
      } data __attribute__ ((packed));
@@ -115,7 +121,7 @@ TclMacOSXGetFileAttribute(interp, objInd
  	return TCL_ERROR;
      }

-    memset(&alist, 0, sizeof(struct attrlist));
+    bzero(&alist, sizeof(struct attrlist));
      alist.bitmapcount = ATTR_BIT_MAP_COUNT;
      if (objIndex == MACOSX_RSRCLENGTH_ATTRIBUTE) {
  	alist.fileattr = ATTR_FILE_RSRCLENGTH;
@@ -134,10 +140,12 @@ TclMacOSXGetFileAttribute(interp, objInd

      switch (objIndex) {
      case MACOSX_CREATOR_ATTRIBUTE:
-	*attributePtrPtr = Tcl_NewOSTypeStringObj(finfo.data.finder.creator);
+	*attributePtrPtr = Tcl_NewOSTypeStringObj(
+		OSSwapBigToHostInt32(finfo.data.finder.creator));
  	break;
      case MACOSX_TYPE_ATTRIBUTE:
-	*attributePtrPtr = Tcl_NewOSTypeStringObj(finfo.data.finder.type);
+	*attributePtrPtr = Tcl_NewOSTypeStringObj(
+		OSSwapBigToHostInt32(finfo.data.finder.type));
  	break;
      case MACOSX_HIDDEN_ATTRIBUTE:
  	*attributePtrPtr = Tcl_NewBooleanObj(
@@ -206,7 +214,7 @@ TclMacOSXSetFileAttribute(interp, objInd
  	return TCL_ERROR;
      }

-    memset(&alist, 0, sizeof(struct attrlist));
+    bzero(&alist, sizeof(struct attrlist));
      alist.bitmapcount = ATTR_BIT_MAP_COUNT;
      if (objIndex == MACOSX_RSRCLENGTH_ATTRIBUTE) {
  	alist.fileattr = ATTR_FILE_RSRCLENGTH;
@@ -224,33 +232,33 @@ TclMacOSXSetFileAttribute(interp, objInd
      }

      if (objIndex != MACOSX_RSRCLENGTH_ATTRIBUTE) {
+	OSType t;
+	int h;
+
  	switch (objIndex) {
  	case MACOSX_CREATOR_ATTRIBUTE:
-	    if (Tcl_GetOSTypeFromObj(interp, attributePtr,
-		    &finfo.data.finder.creator) != TCL_OK) {
+	    if (Tcl_GetOSTypeFromObj(interp, attributePtr, &t) != TCL_OK) {
  		return TCL_ERROR;
  	    }
+	    finfo.data.finder.creator = OSSwapHostToBigInt32(t);
  	    break;
  	case MACOSX_TYPE_ATTRIBUTE:
-	    if (Tcl_GetOSTypeFromObj(interp, attributePtr,
-		    &finfo.data.finder.type) != TCL_OK) {
+	    if (Tcl_GetOSTypeFromObj(interp, attributePtr, &t) != TCL_OK) {
  		return TCL_ERROR;
  	    }
+	    finfo.data.finder.type = OSSwapHostToBigInt32(t);
  	    break;
-	case MACOSX_HIDDEN_ATTRIBUTE: {
-	    int hidden;
-
-	    if (Tcl_GetBooleanFromObj(interp,attributePtr,&hidden) != TCL_OK)  
{
+	case MACOSX_HIDDEN_ATTRIBUTE:
+	    if (Tcl_GetBooleanFromObj(interp, attributePtr, &h) != TCL_OK) {
  		return TCL_ERROR;
  	    }
-	    if (hidden) {
+	    if (h) {
  		finfo.data.finder.fdFlags |= kFinfoIsInvisible;
  	    } else {
  		finfo.data.finder.fdFlags &= ~kFinfoIsInvisible;
  	    }
  	    break;
  	}
-	}

  	result = setattrlist(native, &alist,
  		&finfo.data, sizeof(finfo.data), 0);
@@ -342,7 +350,7 @@ TclMacOSXCopyFileAttributes(src, dst, st
      struct attrlist alist;
      fileinfobuf finfo;

-    memset(&alist, 0, sizeof(struct attrlist));
+    bzero(&alist, sizeof(struct attrlist));
      alist.bitmapcount = ATTR_BIT_MAP_COUNT;
      alist.commonattr = ATTR_CMN_FNDRINFO;

@@ -429,15 +437,19 @@ Tcl_GetOSTypeFromObj(
      string = Tcl_GetStringFromObj(objPtr, &length);
      Tcl_UtfToExternalDString(encoding, string, length, &ds);

-    if (Tcl_DStringLength(&ds) > sizeof(OSType)) {
+    if (Tcl_DStringLength(&ds) > 4) {
  	Tcl_AppendResult(interp,
  		"expected Macintosh OS type but got \"",
  		string, "\": ", (char *) NULL);
  	result = TCL_ERROR;
      } else {
-	memset(osTypePtr, 0, sizeof(OSType));
-	memcpy(osTypePtr, Tcl_DStringValue(&ds),
+	char string[4] = {'\0','\0','\0','\0'};
+	memcpy(string, Tcl_DStringValue(&ds),
  		(size_t) Tcl_DStringLength(&ds));
+	*osTypePtr = (OSType) string[0] << 24 |
+	             (OSType) string[1] << 16 |
+	             (OSType) string[2] <<  8 |
+	             (OSType) string[3];
      }
      Tcl_DStringFree(&ds);
      Tcl_FreeEncoding(encoding);
@@ -464,13 +476,16 @@ static Tcl_Obj *
  Tcl_NewOSTypeStringObj(
      CONST OSType newOSType)    /* OSType used to initialize the new  
object. */
  {
-    char string[sizeof(OSType)+1];
+    char string[5];
      Tcl_Obj *resultPtr;
      Tcl_DString ds;
      Tcl_Encoding encoding = Tcl_GetEncoding(NULL, "macRoman");

-    memcpy(string, &newOSType, sizeof(OSType));
-    string[sizeof(OSType)] = '\0';
+    string[0] = (char) (newOSType >> 24);
+    string[1] = (char) (newOSType >> 16);
+    string[2] = (char) (newOSType >>  8);
+    string[3] = (char) (newOSType);
+    string[4] = '\0';
      Tcl_ExternalToUtfDString(encoding, string, -1, &ds);
      resultPtr = Tcl_NewStringObj(Tcl_DStringValue(&ds),
  	    Tcl_DStringLength(&ds));