Write my own library/extension or create package that calls external program?
Kevin Walzer
some extensions that expose parts of the Mac OS X API not currently
wrapped by Tcl/Tk. However, I recently ran across a cool set of
command-line utilities that do *exactly* what I want--they do things
like get and set custom icons, convert them into formats readable by
Tcl/Tk, etc.
Is there any reason *not* to write a batch of Tcl procedures that wrap
the functionality of these tools, and then bundle that as a Tcl package?
(At the Tcl package level, the procedures would probably work by running
a lot of exec functions out to the command-line tools.) Is speed an
issue? Is this considered lousy application design? Do others wrap the
functions of command-line programs in Tcl procedures to provide a
cleaner (though non-C-level) interface to them?
I'd just rather tap into what these programs offer, rather than
implementing my own code at some distant point in the future, unless
there's a compelling reason not to.
In case anyone's interested, the command-line tools are osxutils
(http://osxutils.sourceforge.net).
--
Kevin Walzer
iReveal: File Search Tool
http://www.wordtech-software.com
Adrian Ho
> I've been making (glacial) progress at learning C so I can implement
> some extensions that expose parts of the Mac OS X API not currently
> wrapped by Tcl/Tk. However, I recently ran across a cool set of
> command-line utilities that do *exactly* what I want--they do things
> like get and set custom icons, convert them into formats readable by
> Tcl/Tk, etc.
>
> Is there any reason *not* to write a batch of Tcl procedures that wrap
> the functionality of these tools, and then bundle that as a Tcl package?
> (At the Tcl package level, the procedures would probably work by running
> a lot of exec functions out to the command-line tools.)
Well, you'll be dealing with osxutils lifecycle issues, e.g.:
* output format changes
* command-line syntax overhauls
* historical assumptions that no longer hold
* any other changes that would break your code
If it's for public consumption, and esp. in production code, you'd
have deployment issues. Do you include a fixed copy of osxutils in
your package, thereby trading off installer size for a more stable and
predictable environment?
How about osxutils' own dependencies? Do you include those too to
prevent major breakage during an unrelated (or so the user thinks)
upgrade or package removal?
How about the dependencies' own dependencies? Apply recursively.
And is any of the above even relevant to your use case? Are you even in
a position where you have to care about all of this?
> Is speed an issue?
Only the user of your package can answer that question -- if
s/he's creating a million aliases, for instance, I think the extra
process-spawning + other overhead of [exec] could *really* suck. You may
want to simply try the speed out for yourself on some practical tasks.
> Is this considered lousy application design?
Not really, at least not in my book. It's true that using the appropriate
APIs would be more elegant, but go with whatever works reliably and is
"fast enough" for the job. It's hard to feed the family with b0rkenware
or vaporware...
> Do others wrap the functions of command-line programs in Tcl procedures
> to provide a cleaner (though non-C-level) interface to them?
I don't see why not. I haven't needed to do that yet, but I wouldn't
rule it out...
- Adrian
Sean Woods
> (http://osxutils.sourceforge.net).
Looking at a lot of these tools, many of these functions used to be
done by
the file command in TCL under MacOS Classic.
Having done my fair share of hacking with the TCL internals (I'm the
poor schmuck
who write the Serial port interface for classic) It's really pretty
straighforward.
Especially since OS X comes with Xcode and a built in Tcl/Tk
interpreter.
All of the functions are already performed by TCL. The change extension
command is a simple call to "file rename". mkalias is a call to "file
link". Most
of the other metadata can be accessed through the "file attributes"
command.
Ok, the google command would require a rewrite. But why would I exec
out to
perl anyway. (blech) For that you can use the http package.
Sean Woods
I completely missed that 99% of what you were intersted in was fiddling
with the icons.
Back in classic we had the resource command to frob them. After a
couple of minutes
of fruitless searching it does seem that we have to go outside for
that.
I wouldn't make too many long term plans about using someones 3rd party
extension
to do something critical for your application. Developers sometimes get
wierd ideas
about what constitutes an improvement. For a one-off application you
should be good
though.
Kevin Walzer
> I completely missed that 99% of what you were intersted in was fiddling
> with the icons.
> Back in classic we had the resource command to frob them. After a
> couple of minutes
> of fruitless searching it does seem that we have to go outside for
> that.
>
Yup, that's what I'm really interested in.
I think I know what would be needed to get this working in Tcl:
*a Tcl wrapper for the Mac's Carbon LaunchServices and IconServices
API's, to allow getting default icons for various file types and
applications
*a Tcl extension that can read the .icns file format
Problem is, my rudimentary skills in C are nowhere near adequate to
either of these tasks. :-(
osxutils, however, handles both of these issues beautifully--the
"geticon" tool solves all of my problems, though it's probably a bit slow.
Cameron Laird
.
.
I'm not bashful at all about [exec]ing third-party
software, if it helps me supply functionality quicker.
I worry little about the upgrade cycle of the third-
party software; that's at least as predictable as what
clients are likely to demand.
Eckhard Lehmann
Kevin Walzer wrote:
Adrian gave the same points of view that I would have given... It is
mainly really a matter of deployment. If you want to deploy the
resulting application it could be very obstructive to have external
dependencies. You can make an installer that copies the files to
relevant locations, but does the user have write permissions? Does s/he
have another version of the tools installed that conflict with the
version your program needs? How about dependencies of the tools to
other tools/shared libraries? I would try to be as independent as
possible in this case.
It is another thing when I install the program on a machine that I know
inside out and where I have complete control. In this case it would be
absolutely feasible to use external tools and thus speed up the
development.
> *a Tcl wrapper for the Mac's Carbon LaunchServices and IconServices
> API's, to allow getting default icons for various file types and
> applications
A good solution, I think. The API interface should be kept stable by
Apple and behind it, there should be always an updated (patched)
implementation. Also, this interface is available on all Mac OSX
computers, I would say.. (I never worked with Macintosh, but it should
not be different from windows or unix platforms, regarding this kind of
services).
>
> *a Tcl extension that can read the .icns file format
This is more work, definitely. Maybe there is a static and even
platform independent library that can be employed for it? If so, it
boils down to writing a wrapper around this library.
>
> osxutils, however, handles both of these issues beautifully--the
> "geticon" tool solves all of my problems, though it's probably a bit slow.
As said, the easiest and fastest solution - and certainly adequate if
you can live with the small disadvantages of third party tools...
Eckhard