Availability of OS X-specific features
Steven Myers
programmer by trade), primarily on Windows and a little on Linux.
About six months ago, I bought a Macintosh and dropped Windows, and I'd
like to get back to Tcl.
I've been a lurker here for years and know my way around the Wiki, but
the information on writing a program in Tcl which looks and behaves
like an OS X application seems both sketchy and contradictory. My
particular interests also go beyond anything I've seen discussed before
either here or in the Wiki. What I'd like to do is this:
1. Be able to utilize the script as an ordinary application (i.e., as
an ".app" which could be in the Applications folder and which could be
kept permanently on the Dock). I assume, if this is possible, it would
mean embedding the script alongside some sort of skeleton program.
2. Be able to change the Dock icon from the script itself as the
script is running, similar to Apple's Mail, but instead of adding text
to the Dock as that program does, merely select one icon from among
several possibilities. To be clear, what I'd like to do is start with
Icon 1, then depending on some condition as the script is running,
switch to Icon 2, then possibly switch back to Icon 1.
3. Have a custom Dock menu (via control-clicking the Dock icon),
similar to iTunes, with its options to jump to the next song and the
like.
Is this currently possible with Tcl on OS X?
--
Steven Myers
smyers (at) sonic (dot) net
Robert Hicks
http://www.wordtech-software.com/aquify-tk-app.html
I use ActiveTcl from ActiveState on OSX although Tiger has a fairly
complete Tcl installstion:
http://www.activestate.com/Products/ActiveTcl/
There is a Mac Tcl mailing list on this page:
http://tcltkaqua.sourceforge.net/
The wiki has some info as well: http://wiki.tcl.tk/
HTH
Robert
Steven Myers
That first link answered my question #1. The info I had indicated that
embedding the script inside the .app structure had to be the way to go,
but the specifics of how to do it were never very clear.
Any thoughts on questions 2 or 3? A search through the tcl-mac archive
(http://sourceforge.net/mailarchive/forum.php?forum=tcl-mac for those
who are interested) didn't turn up anything.
My needs are certainly peculiar--they involving monitoring the status
of a dial-on-demand ppp connection on a different box, plus interacting
with various boxes on my home network. Most OS X apps don't bother
with having a custom Dock menu (question #3) or with changing the Dock
icon in mid-program (question #2), but both certainly can be done, so
it would be great if they could be done from Tcl.
With question #1 answered, I can actually solve my problem in a
roundabout way using Growl notifications (see http://growl.info), since
Growl has a Tcl binding. Unfortunately, Growl always struck me as
something really cool which doesn't fit the way I work. I'd also just
prefer an application which isn't dependent on having Growl installed.
Thanks for the suggestions.
Daniel A. Steffen
there are currently no direct Tk facilities to change the dock icon or
the dock menu, but both are indeed possible to do via carbon APIs,
which you can call from Tcl via Ffidl, or by writing a small critcl
extension:
http://developer.apple.com/documentation/Carbon/Conceptual/customizing_docktile/
http://developer.apple.com/documentation/Carbon/Reference/Dock_Manager/
the first url above also has instructions on how setup a static custom
dock menu without writing code by adding a key to Info.plist and adding
a .nib file to your .app bundle. You'll still have to install a carbon
event handler to react to the new menu events, an example on how to do
this with Ffidl is at the bottom of
http://wiki.tcl.tk/Ffidl
The abovementioned list tcl...@lists.sourceforge.net would be the best
place for a more detailed discussion about this.
Cheers,
Daniel
Steven Myers
<daniel....@gmail.com> said:
> there are currently no direct Tk facilities to change the dock icon or
> the dock menu, but both are indeed possible to do via carbon APIs,
> which you can call from Tcl via Ffidl, or by writing a small critcl
> extension:
> http://developer.apple.com/documentation/Carbon/Conceptual/customizing_docktile/
http://developer.apple.com/documentation/Carbon/Reference/Dock_Manager/
the
>
> first url above also has instructions on how setup a static custom
> dock menu without writing code by adding a key to Info.plist and adding
> a .nib file to your .app bundle. You'll still have to install a carbon
> event handler to react to the new menu events, an example on how to do
> this with Ffidl is at the bottom of
> http://wiki.tcl.tk/Ffidl
I appreciate the info, although I fear much of this may be (and writing
an extension certainly is) beyond my abilities. Just as a matter of
clarification, I didn't mean to suggest that the core should
necessarily have this functionality; I was hoping (perhaps selfishly,
given my lack of ability) that extensions to provide it already existed.
> The abovementioned list tcl...@lists.sourceforge.net would be the best
> place for a more detailed discussion about this.
I'm now careening off-topic, but is there any particular reason why the
subject of Tcl on Macintoshes should be ghetto-ized into a sourceforge
mailing list, rather than discussed on a long-standing newsgroup?
Obviously, if that's where the people who want to talk about the
subject are active, then that's the way it is, but Google Groups is a
lot more accessible than first learning that a mailing list exists,
then searching through the sourceforge archive. There's potentially a
lot of knowledge being buried. Fortunately, the list is available as a
newsgroup via gmane.org, but that's no panacea.
Robert Hicks
neccesarily appropriate for the newsgroup?
Daniel Steffen is one of the leading Tcl on Mac folks and he might find
it easier on his time to answer things on the list and he will probably
be a great resource for you regarding anything Tcl+OSX related.
Anything substantial should probably be added to the wiki anyway
regardless of the source.
Robert
Cameron Laird
.
.
.
>I'm now careening off-topic, but is there any particular reason why the
>subject of Tcl on Macintoshes should be ghetto-ized into a sourceforge
>mailing list, rather than discussed on a long-standing newsgroup?
.
.
<URL: http://www.faqs.org/faqs/usenet/creating-newsgroups/part1/ >
includes general comments on the general question, "Why doesn't
$SUBJECT have its own newsgroup?" Briefly, from the perspective
of the Usenet overlords, the natural vehicle for all topics is a
mailing list; it's only exceptionally vigorous ones that *might*
merit their own newsgroups.
Steven Myers
> <URL: http://www.faqs.org/faqs/usenet/creating-newsgroups/part1/ >
> includes general comments on the general question, "Why doesn't
> $SUBJECT have its own newsgroup?" Briefly, from the perspective
> of the Usenet overlords, the natural vehicle for all topics is a
> mailing list; it's only exceptionally vigorous ones that *might*
> merit their own newsgroups.
Ah, but you misunderstand me: I don't think Tcl on OS X deserves its
own newsgroup. I think it should be discussed here, on comp.lang.tcl,
along with Tcl on Linux, Tcl on Windows, Tcl on Solaris, etc. Hence my
earlier reference to a ghetto: why is the general subject of OS X (as
opposed to say, detailed, technical discussion of proposed patches to
the Tcl core) segregated into a mailing list?
I think this makes my point clearly enough. Closing up a discussion in
a mailing list, with the primitive search abilities available, creates
a strong potential that either: 1) the same wheel gets reinvented, or
2) someone who lacks that level of technical ability must make do
without a wheel at all, not knowing that it was ever invented.
That said, people can talk wherever they want about whatever they want.
It's not my intention to be critical of anyone. I just think that,
for the benefit of future users, the best forum for general discussion
of the use of Tcl on OS X along with any other operating system is
right here.
Robert Hicks
definately technical discussions on the list that I think would not be
appropriate for the ng. You have to make your own decisions. I think if
you don't get on the list then you are "cutting off your nose to spite
your face" so to speak.
Robert
Robert Hicks
with any other operating system is right here." -- emphasis mine
I think you are right and nobody is disputing that.
Robert
Kevin Walzer
Rightly or wrongly, the Tcl-Mac mailing list is strongly associated with
the Tcl/Tk Aqua distribution maintained by Daniel Steffen, which is
hosted at Sourceforge. For Mac Tcl/Tk developers, that's the canonical
place for Mac-specific Tcl/Tk issues. If you post at c.l.t with a
Mac-specific question, you will often be referred to the mailing list
for better answers (and the search capabilities at SF are pretty good).
Conversely, if you post there with a general Tcl/Tk question, you will
usually be referred here.
I see no problem with this.
--
Cheers,
Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
Kevin Walzer
>
> I appreciate the info, although I fear much of this may be (and writing
> an extension certainly is) beyond my abilities. Just as a matter of
> clarification, I didn't mean to suggest that the core should necessarily
> have this functionality; I was hoping (perhaps selfishly, given my lack
> of ability) that extensions to provide it already existed.
One of the things I'm finding with Tcl/Tk is that they are a very
powerful programming toolkit, but a knowledge of lower-level, more
hardcore programming (specifically C) is necessary if you want to
customize or extend the functionality of the language. Hence I am wading
slowly into the complexities of programming C. It's the only way to
really get what you want from Tcl/Tk if you don't want to depend on the
kindness of others.
Of course, even though learning C is no picnic, you don't have to spend
all your time there: moving into C for the Tcl/Tk additions that you
want and then moving back into Tcl/Tk is certainly easier than becoming
a full-bore C/C++/Objective-C Carbon or Cocoa programmer.
Steven Myers
> Rightly or wrongly, the Tcl-Mac mailing list is strongly associated with
> the Tcl/Tk Aqua distribution maintained by Daniel Steffen, which is
> hosted at Sourceforge. For Mac Tcl/Tk developers, that's the canonical
> place for Mac-specific Tcl/Tk issues. If you post at c.l.t with a
> Mac-specific question, you will often be referred to the mailing list
> for better answers (and the search capabilities at SF are pretty good).
> Conversely, if you post there with a general Tcl/Tk question, you will
> usually be referred here.
I had intended to let the subject drop (because I really don't mean to
be critical of anyone, and I recognize that Daniel Steffen and others
have done a lot of great work), but, given a couple of the responses, I
seem to have been unclear.
I think *general* discussion of Tcl encompasses more than "How does
eval work?" or the ever-popular "Why don't comments work like they do
in other languages?" I think it includes, "How can I use Tcl to create
a full-fledged application on my operating system?" That subject, in
various, more specific permutations, regularly comes up in
comp.lang.tcl with respect to Windows; why not OS X? I think
re-directing OS X-related questions to a mailing list is, in essence,
stuffing Tcl on OS X in a box that says, "You're different; go away."
Others disagree, and that's fine. I can go ahead and read the tcl-mac
mailing list via news.gmane.org.
If nothing else, anyone who does the Google Groups searches I did
before I posted my original question will find the signposts which this
discussion leaves behind.
Donal K. Fellows
> Ah, but you misunderstand me: I don't think Tcl on OS X deserves its
> own newsgroup. I think it should be discussed here, on comp.lang.tcl,
> along with Tcl on Linux, Tcl on Windows, Tcl on Solaris, etc. Hence my
> earlier reference to a ghetto: why is the general subject of OS X (as
> opposed to say, detailed, technical discussion of proposed patches to
> the Tcl core) segregated into a mailing list?
Leaving aside the point of "deserves" which I don't feel qualified to
answer, I'd like to say that I feel that any and all discussion of
issues relating to Tcl-on-OSX should definitely be welcome on c.l.t,
just as any other Tcl-related stuff is. (Why things have ended up that
way is something I think I can probably answer: "it just happened that
way and now there's everyone's inertia to overcome!" You know, the same
old story.) You even see tcl-core stuff some of the time here, and
that's a lot more confusing to people not tracking the core. (On the
other hand, some things that *should* show up aren't. *grmbl*)
In any case, it's always right to ask here. Sometimes you'll get
pointed elsewhere for more efficient discussion, but if there's been no
obvious answer in the past here, we'd naturally welcome a summary of
how things get resolved. It'll almost certainly help others in the
future, and will prove interesting to the rest of us too. :-)
Donal.
Daniel A. Steffen
> an extension certainly is) beyond my abilities. Just as a matter of
> clarification, I didn't mean to suggest that the core should
> necessarily have this functionality; I was hoping (perhaps selfishly,
> given my lack of ability) that extensions to provide it already existed.
I've added a brief example on how to set the application dock tile from
a png image to the wiki:
http://wiki.tcl.tk/Ffidl
as you'll see, it's really not very complicated.
> I'm now careening off-topic, but is there any particular reason why the
> subject of Tcl on Macintoshes should be ghetto-ized into a sourceforge
> mailing list, rather than discussed on a long-standing newsgroup?
Others have already responded to this, I'd just add that that my advice
to go to the list was purely pragmatic, because I know from experience
that most of the mac tcl/tk folks read the tcl-mac list but not the
newsgroup.
Personally, I know that while I try to read the newsgroup on a regular
basis, if time is short, I'll have a harder time ignoring list msgs
arriving on their own in my mail client as compared to having to
remember to fire up my news reader (c.l.t is the only newsgroup I read,
but I'm probably on close to 100 mailing lists...)
I don't disagree that I'd be nice in theory to have all mac discussions
on c.l.t but in practice, people are on tcl-mac and not on c.l.t for
historical reasons, and there is not much anyone can do about that at
this point.
It appears that tcl-mac development has been discussed on separate
mailing lists since the very first mac port of Tcl 7.3 in 1994, google
still finds some traces of historical tcl-mac lists:
http://www.ralentz.com/old/mac/unix/tcl.html
http://groups.yahoo.com/group/mactcl/messages/1
FWIW, the tcl-mac sourceforge list has three web archives
http://sourceforge.net/mailarchive/forum.php?forum=tcl-mac
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/tcl-mac
http://blog.gmane.org/gmane.comp.lang.tcl.mac
and as a result it is very googleable in my experience (adding MACTCL
to the query sometimes helps since that string appears in every subject
line).
Cheers,
Daniel
Steven Myers
<daniel....@gmail.com> said:
>> I appreciate the info, although I fear much of this may be (and writing
>> an extension certainly is) beyond my abilities. Just as a matter of
>> clarification, I didn't mean to suggest that the core should
>> necessarily have this functionality; I was hoping (perhaps selfishly,
>> given my lack of ability) that extensions to provide it already existed.
>
> I've added a brief example on how to set the application dock tile from
> a png image to the wiki:
> http://wiki.tcl.tk/Ffidl
> as you'll see, it's really not very complicated.
Thanks very much for this example. Just looking at it briefly, I'd say
that it might not be complicated for you, because you know what you're
doing. I, on the other hand, would have been sweating for a long time
to come up with that, if I could at all.
Jochem Huhmann
> FWIW, the tcl-mac sourceforge list has three web archives
> http://sourceforge.net/mailarchive/forum.php?forum=tcl-mac
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/tcl-mac
> http://blog.gmane.org/gmane.comp.lang.tcl.mac
> and as a result it is very googleable in my experience (adding MACTCL
> to the query sometimes helps since that string appears in every subject
> line).
The tcl-mac mailing list is also available as newsgroup at
news.gmane.org -- http://news.gmane.org/gmane.comp.lang.tcl.mac
It's read-only, but for reading and searching much better than the web
archives at Sourceforge.
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
Kristoffer Lawson
>
> I think this makes my point clearly enough. Closing up a discussion in
> a mailing list, with the primitive search abilities available, creates
> a strong potential that either: 1) the same wheel gets reinvented, or
> 2) someone who lacks that level of technical ability must make do
> without a wheel at all, not knowing that it was ever invented.
For what it's worth, I agree that the matters of which you posted should be
discussed on this newsgroup. They are general matters of Tk coding on the OS X
platform and useful to have documented here.
Melissa Schrumpf
> One of the things I'm finding with Tcl/Tk is that they are a very
> powerful programming toolkit, but a knowledge of lower-level, more
> hardcore programming (specifically C) is necessary if you want to
> customize or extend the functionality of the language.
Kevin,
That is pretty much true of any "interpreted" language. By definition.
Any given language [X] includes a core set {A} of features. Utilizing
those features, and those only, contained in {A} is referred to as
"programming" in language [X], and is the design of language [X].
Extending the feature set {A} of language [X] requires modifying
language [X] itself, usually in the language [Y] that language [X] is
written in.
The only exceptions to this rule are "languages" which are
feature-complete for their given platform: machine code, assembly.
C and other languages might be considered in this category if their
compiler package supports generating ALL opcodes for their given
chipset, but, generally speaking, even C is used 99.9% in the same
manner that Tcl is...
That is, Tcl and other languages, generally speaking, are different by
design. I tend to think of them as running on a "platform" which is an
OS, not directly on hardware. It is the abstraction that makes them
efficient, but which also makes them harder to extend by the average
user, because it requires programming in the parent language.
Unfortunately, an OS and its graphical extensions is a much more complex
"platform" than a processor, so these languages tend to be less
feature-complete.
> Hence I am wading
> slowly into the complexities of programming C. It's the only way to
> really get what you want from Tcl/Tk if you don't want to depend on the
> kindness of others.
True enough. A measure of a language's utility is perhaps given by the
ratio:
feature_completeness / complexity
> Of course, even though learning C is no picnic, you don't have to spend
> all your time there: moving into C for the Tcl/Tk additions that you
> want and then moving back into Tcl/Tk is certainly easier than becoming
> a full-bore C/C++/Objective-C Carbon or Cocoa programmer.
Indeed, and extensions for accessing binary libraries native to the OS
are a stopgap measure intended to bring the feature-completeness factor
up to 100%. Unfortunately, from what I've seen, they have the tendency
to increase the complexity factor significantly, by essentially
requiring EVERYONE WHO USES THEM to learn C in order to comprehend the
library functions you will be calling; a vast increase in
feature-completeness with a corresponding increase in complexity.
In such a case, it may, at times, be worthwhile for the user to drop
directly into C/C++/Whatever using the Tcl libraries (change of language
entirely), or to write a Tcl extension to make a small subset of new
feature available at the Tcl level (small incremental increase in
feature-completeness without increasing complexity).
I'm not knocking extensions such as ffidl. They do what they're
intended to do, for their intended users. Just that their user-base is
not the same as the entire Tcl/Tk user-base.
Good luck!
--
MKS