ANNOUNCE: TkDesk, a file manager for Unix/X
C. Bolik
ANNOUNCE: TkDesk 1.0a1 31.3.96
---------------------------------------------------------------------------
Summary:
TkDesk is a file-manager for Unix and X. It has got loads of features,
such as file-specific popup-menus, history management etc. etc. See
below for more. It needs Tcl 7.4 and Tk 4.0 installed to run. TkDesk
is mainly implemented in Tcl/Tk, with core functions written in C.
Most every aspect of TkDesk can be configured through configuration
files (which again are simple Tcl scripts, and thus give the user who
knows Tcl enormous power).
Have a look at URL http://sun1.rrzn-user.uni-hannover.de/~zzhibol/tkdesk/
for some screen snapshots (that is, as soon as our auto-mounter works
again)!
You can get TkDesk from (no guarantees on the paths given below):
ftp://sunsite.unc.edu/pub/Linux/Incoming/tkdesk-1.0a1.tar.gz
or
ftp://sunsite.unc.edu/pub/Linux/X11/xutils/managers/tkdesk-1.0a1.tar.gz
and all of sunsite's mirrors.
ftp://ftp.aud.alcatel.com/tcl/potpourri/tkdesk-1.0a1.tar.gz
or
ftp://ftp.aud.alcatel.com/tcl/code/tkdesk-1.0a1.tar.gz
and all of alcatel's mirrors.
You can also get TkDesk from my homepage:
http://sun1.rrzn-user.uni-hannover.de/~zzhibol/tkdesk/
More detailed:
This is to announce the alpha-release of TkDesk, a graphical file
manager for Unix (esp. Linux) and the X Window System. Compared
with other file managers available, it offers the most complete set
of file operations and services, plus gives the user the ability to
configure most every aspect of TkDesk in a powerful way. The reason
for this is the use of Tcl/Tk as the configuration and (for the
greatest part of TkDesk) implementation language. TkDesk has been
influenced by various other systems and file managers, such as
NeXT, for laying out the file browser windows, Apple Finder, for
the idea of file annotations and, shock horror, Windows 95, for
some other (of course minor and unimportant ;-) inspirations.
This is a brief overview of the most prominent features of TkDesk:
o Arbitrary number of file browsers and file list windows,
o Configurable file-specific popup-menus,
o History of visited directories, opened files, executed commands,
and others, which is automatically saved to disk,
o Find files through their annotation, name, contents, size or age,
o A trash can for safe deletion of files and directories,
o Drag and drop,
o Calculation of disk usage for directory hierarchies,
o All file operations (find, copy, disk usage, etc.) are carried out in
the background,
o Traversal of directory hierarchies through recursive cascaded menus,
o Bookmarks, create menu entries for often used files/directories,
o Online help (not much yet, but this will be extended in future
releases), a postscript version of the online guide can be found
in the doc subdirectory,
o A configurable application bar, with cascaded popup menus for
each button,
o A built-in multi-buffer editor,
o Sound support,
o Powerful configuration of nearly all aspect of TkDesk through Tcl/Tk,
o Free of charge! TkDesk is distributed under the terms of the GPL.
I've been working on TkDesk for over 2 years now. It started out as a
simple toy for learning Tcl/Tk, but over the years I have added more
and more functions, removed useless ones, removed bugs and added new
ones (this does of course not apply to the current version ;-).
Ever since I started with TkDesk, I have been using it myself in every-
day work under Linux. For that reason I believe that the current
version of TkDesk is very mature and stable. I haven't run it much on
Sun systems though, and not at all on any other ones, so I can't say
much about TkDesk on those machines. For this reason, and since I
want TkDesk to be tested by as many people as possible before releasing
the "final" version, I am considering the current version of TkDesk
to be in "Alpha" state. Quite a stable kind of alpha though, I hope.
I would compare it with the 0.99.x Linux kernels before Linux 1.0 was
released, maybe.
See the summary above for where to get TkDesk.
Please check it out!
Christian Bolik (zzh...@rrzn-user.uni-hannover.de)
Heribert Dahms
: Quite a stable kind of alpha though, I hope.
: I would compare it with the 0.99.x Linux kernels before Linux 1.0 was
: released, maybe.
Indeed! My Linux 0.99.13 at home is now up more than 460 days.
Sometimes, I've seen WIN3.1 crashing repeatedly <460 seconds...
[I know it's off topic, but sorry, I could not resist!]
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
binky
blt2.0 have been bundled with tkdesk and these seem to cause problems
during linking.
I've already got itcl, blt2.0 working on my system (and
Tcl7.5b3/Tk4.1b3) and suspect these are causing problems. Tried
linking to my existing libitcl, libblt but couldn't resolve it.
Any ideas - If necessary I will try and capture and post the output
from make but I do all my Internet/E-mail from Windoze 95 not Linux so
this will take time :( (must get round to setting up Linux to talk
to my Internet Provider).
Heeeeeelllllllp please !!!
Much obliged in advance
Julian Loaring
Humberto A. Sanchez II
Humberto
--
--------------------------------------------------------------
The opinions expressed above are entirely my own, although I reserve
the right to deny everything. They are certainly not my employer's.
Chris Sterritt
binky <bi...@bigj.demon.co.uk> wrote:
>I could not get this to build under Linux 1.2.1. [...etc...]
>I've already got itcl, blt2.0 working on my system (and
>Tcl7.5b3/Tk4.1b3) and suspect these are causing problems. Tried
>linking to my existing libitcl, libblt but couldn't resolve it.
Yup, and this is (unfortunately) the problem at hand.
I tried building tkdesk with 7.5/4.1, and it failed in all kinds of
ways, mostly having to do with the ever-changing (aarrgghh!) nature of
tcl/tk.
I had to get the 7.4/4.0 distribution, install it as such (in special
dirs under /usr/local/lib/) and then all went well.
--chris sterritt
Larry W. Virden
According to Chris Sterritt <ster...@mrj.com>:
:I tried building tkdesk with 7.5/4.1, and it failed in all kinds of
:ways, mostly having to do with the ever-changing (aarrgghh!) nature of
:tcl/tk.
John and others,
We all appreciate all the hard work going into improving Tcl. And
I know how much badgering you all get in public about adding this
and that extension.
But this attitude towards Tcl is growing more and more - to the point
that the number of folk who won't have anything to do with Tcl because
every six months or so the interfaces change and major porting efforts
have to be made is increasing dramatically.
I don't think it is unreasonable for folk to expect that backwards compatibility
exist in a language - even if it means that null subroutines are provided
to make it possible.
Perhaps Tcl 7.5 should have been numbered to warn folk of the changes -
except from what it sounds like, the next Tcl version is going to be even
a bigger change (binary data support, compilers, possibly multiple
look and feels, etc.)
I mean, I can pick up a book describing C from 10 years ago or longer and
a contemporary compiler will compile it. Sure I won't get all the prototype
support, but the language still works.
I can use 20+ year old Fortran programs, or COBOL. Smalltalk doesn't
seem to be undergoing these types of changes.
The CLT community needs to be sensitive to the novice, to the folk who
are not programmers but are dealing with source code written elsewhere by
someone else and which now needs to be supported. Let's do our best to
write as detailed helps for moving from version to version of Tcl and Tk,
so that the non-programmers (and even the programmers who have much
more to do than they have time to do it) can keep up to date.
--
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.teraform.com/%7Elvirden/> <*> O-
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
Ken Mcdonald
Well, actually, this thread isn't about TkDesk anymore, it's about
backwards compatibility . . . just wanted to let John Ousterhout and
his group know that I (and I suspect most others) are very impressed
with the ease with which older Tcl/Tk programs migrate to future
versions. (Mind you, I try to code defensively, so maybe I have an
easier time of it . . .). The imcompatibilities that are arising
are unfortunate, but in my mind, well worth it for a true multiplatform
language. Thanks!
One small suggestion (and it's nitpicking, I admit)--would it be possible
to add some aliases to the old Tcl commands that still exist from before
the "general specific" command naming scheme was fully in place? I've
lost track of the number of times I've had errors from typing
"string append" when I meant "append", and likewise for "list append"
and "lappend". I'm just thinking it might be a nice thing to do if it
is really, really easy.
Cheers,
Ken McDonald
mcdo...@cs.sfu.ca
John Ousterhout
In article <4m19hp$t...@srv13s4.cas.org>, lw...@cas.org (Larry W. Virden) writes:
|>
|> According to Chris Sterritt <ster...@mrj.com>:
|> :I tried building tkdesk with 7.5/4.1, and it failed in all kinds of
|> :ways, mostly having to do with the ever-changing (aarrgghh!) nature of
|> :tcl/tk.
|>
|> I know how much badgering you all get in public about adding this
|> and that extension.
|>
|> But this attitude towards Tcl is growing more and more - to the point
|> that the number of folk who won't have anything to do with Tcl because
|> every six months or so the interfaces change and major porting efforts
|> have to be made is increasing dramatically.
|>
|> I don't think it is unreasonable for folk to expect that backwards
|> compatibility exist in a language - even if it means that null subroutines
|> are provided to make it possible.
|>
|> Perhaps Tcl 7.5 should have been numbered to warn folk of the changes -
|> except from what it sounds like, the next Tcl version is going to be even
|> a bigger change (binary data support, compilers, possibly multiple
|> look and feels, etc.)
Some assorted comments:
1. We've tried very hard not to introduce incompatibilities unless they're
absolutely necessary to achieve an important goal. I believe that most of
the recent problems have been with the new I/O system, which has a few
incompatibilities at the C level. If anyone has ideas how to avoid the
incompatibilities we'd be delighted to hear them, but we couldn't find
a way to implement I/O in Tcl that maintained backwards compatibility
while allowing proper event-driven I/O and handling the cross-platform
issues. If the Tcl I/O system is going to work right on Windows and Macs
we simply had to make the changes. I think that it's the consensus of
the Tcl/Tk user community that we should make Tcl and Tk run smoothly on
Macs and PCs. Again, we'd be very happy to hear suggestions for how we
could do this better.
2. The recent releases should not introduce any incompatibilities at the
level of Tcl scripts; the few incompatibilities are all at the level of
C code. This is why we didn't bump the major version numbers of Tcl and
Tk.
3. An ANSI C compiler will detect all of the recent incompatibilties, and
I believe that they're all pretty easy to code around. I realize that this
means that existing code for extensions may have to be modified, but in
most cases it should not take much work to make the modifications.
4. Providing null subroutines for procedures that no longer exist will
probably make things worse. It will allow extensions to compile, giving
the appearance that all is OK, but then they will fail in bizarre ways at
runtime since the null procedures don't have the behavior expected of
them. I think it's better to leave the procedures out so that people
know what they have to fix.
Again, we're very sorry about the incompatibilities, but I think that
they are the lesser of all the evils facing us. We will continue to try
to avoid incompatibilities whenever we possibly can, and we're always
interested to hear your ideas about how to do this.
Heribert Dahms
In <4m5gpj$n...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com
(John Ousterhout) writes:
: 2. The recent releases should not introduce any incompatibilities at the
: level of Tcl scripts; the few incompatibilities are all at the level of
: C code. This is why we didn't bump the major version numbers of Tcl and
: Tk.
:
Maybe I miss something, but how to prevent a dynamic loadable extension
from loading in the wrong tclsh or wish if the major version number isn't
incremented? That will be very important in the future.
Clearly an extension is dependent on C level incompatibilities, so at least
any incompatible changes visible to the 'official' C interface should from
now on force an increment of the major version!
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Chris Sterritt
In article <4m19hp$t...@srv13s4.cas.org>,
Larry W. Virden <lvi...@cas.org> wrote:
>
>According to Chris Sterritt <ster...@mrj.com>:
>:I tried building tkdesk with 7.5/4.1, and it failed in all kinds of
>:ways, mostly having to do with the ever-changing (aarrgghh!) nature of
>:tcl/tk.
>John and others,
>
>We all appreciate all the hard work going into improving Tcl. And
>I know how much badgering you all get in public about adding this
>and that extension.
Hear, hear. Many of us can sympathize with the demanding-user problem :-).
>But this attitude towards Tcl is growing more and more - to the point
>that the number of folk who won't have anything to do with Tcl because
>every six months or so the interfaces change and major porting efforts
>have to be made is increasing dramatically.
Yup. I pretty much gave up on tcl/tk for just this reason -- built a
fairly large 6.x/3.4 application (and *LOTS* of little helper hacks,
which tcl/tk is fantastic for) and then 7.0/4.0 came out, and TONS of
things changed.
Nuts, I thought... well, I can just hang out until it stabilizes, like
perl4 did... maybe someday I'll have a 'wish4' or something for
'newer' apps.
BUT IT NEVER SEEMS TO END... 7.5/4.1 had *major* changes. I looked at
porting tkdesk myself, and there were substantial changes.
>Perhaps Tcl 7.5 should have been numbered to warn folk of the changes -
>except from what it sounds like, the next Tcl version is going to be even
>a bigger change (binary data support, compilers, possibly multiple
>look and feels, etc.)
>The CLT community needs to be sensitive to the novice, to the folk who
>are not programmers but are dealing with source code written elsewhere by
>someone else and which now needs to be supported.
And, darn it, legacy code -- I *really* don't have the time to rewrite
my hacks to accomodate the latest and greatest rewrite. All right,
I'll get down off of my soap box :-).
A possible solution: First of all, can someone please (John?) decide
what tcl/tk is going to be NOW. NOT when it grows up, NOT the one
true ultimate script/app/net language, but something good.
THEN NAIL that spec down, implement it and release it.
THEN, take an approach something like linux: Keep the 'base' spec as a
supported, safe place for development. Then, on the 'other' side
(linux does it by having odd/even numbers for the kernels: 1.x (where
x is even) is the 'safe', bug-fix only world, and (where x is odd) the
'exciting' development, new-stuff side) allow new
syntax/semantics/interfaces.
Let's look also to the Perl community: Perl 4 was a nice,
bug-fix-oriented world WHICH STILL EXISTS. Perl 5 is an exciting,
heady world of changes and progress. And someday, when it's stable
enough :-) I'll bring it onto my machines and get to know it.
Those of us in 'the real world' :-) may be a pain in our own right,
but it's been *REAL* hard to be a tcl/tk advocate lately.
Thanks,
--chris sterritt
Mark Roseman
In article <4m63g4$q...@gecko.mrj.com>, Chris Sterritt <ster...@mrj.com> wrote:
>[stuff about rapid changes deleted]
i think john (presumably from atop a mountain, or at least a berkeley
foothill) had often proclaimed that there was one going to be one major
clean-up release for both tcl and tk. that happened. with the
mac/windows stuff, tcl/tk also had a big change of direction. changes
are going to happen because of that. what can you do? i have to
say that the level of support (in terms of detailed logs of changes,
porting guides, feedback here, etc.) has been great to help people
upgrading.
also keep in mind there's nothing stopping you from using the older
versions. we've kept some of our stuff at 7.4/4.0 and are in no
great hurry to upgrade. some of our "cutting edge" things use the
newer releases, with full expectation that the new features are going
to cause some pain. but we've got the choice.
>A possible solution: First of all, can someone please (John?) decide
>what tcl/tk is going to be NOW. NOT when it grows up, NOT the one
>true ultimate script/app/net language, but something good.
it just can't be done. requirements evolve with usage. a static
spec would be worthless and restrictive.
there's lots of opportunities for the community to help set direction
though: proposals and arguments/discussions here, participating in
the annual workshop, building your own "right way" to do things and
try to promote it in the community.
mark
--
Mark Roseman, Research Associate phone: (403) 220-3532 / 220-7259
Dept. of Computer Science fax: (403) 284-4707
University of Calgary email: ros...@cpsc.ucalgary.ca
Calgary, Alta CANADA T2N 1N4 http://www.cpsc.ucalgary.ca/~roseman
Heribert Dahms
I'm reposting this under a better subject (I hope), since I've seen no other
followups so far and think it will get *really* important. However, I received
one Email from Cameron Laird (cla...@NeoSoft.com) saying: "Good point."
In <4m64rf$p...@nz12.rz.uni-karlsruhe.de> DA...@ifk20.mach.uni-karlsruhe.de
writes:
: In <4m5gpj$n...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com
: (John Ousterhout) writes:
:
: : 2. The recent releases should not introduce any incompatibilities at the
: : level of Tcl scripts; the few incompatibilities are all at the level of
: : C code. This is why we didn't bump the major version numbers of Tcl and
: : Tk.
: :
: Maybe I miss something, but how to prevent a dynamic loadable extension
: from loading in the wrong tclsh or wish if the major version number isn't
: incremented? That will be very important in the future.
: Clearly an extension is dependent on C level incompatibilities, so at least
Martin Andrews
Heribert Dahms wrote:
> : Maybe I miss something, but how to prevent a dynamic loadable extension
> : from loading in the wrong tclsh or wish if the major version number isn't
> : incremented? That will be very important in the future.
> : Clearly an extension is dependent on C level incompatibilities, so at least
> : any incompatible changes visible to the 'official' C interface should from
> : now on force an increment of the major version!
Following this rule, I imagine that there would only be major version
changes
and no minor version changes in the next few releases. Nonethless, I
agree
that dynamic loading makes C-level compatibility critical. Maybe an end
to minor version C incompatibilities should go on the wish list?
--
Martin Andrews and...@ccfadm.eeg.ccf.org
Section of Neurological Computing, Cleveland Clinic Foundation
John Ousterhout
In article <318F45...@ccfadm.eeg.ccf.org>, Martin Andrews <and...@ccfadm.eeg.ccf.org> writes:
|> Heribert Dahms wrote:
|> > : Maybe I miss something, but how to prevent a dynamic loadable extension
|> > : from loading in the wrong tclsh or wish if the major version number isn't
|> > : incremented? That will be very important in the future.
|> > : Clearly an extension is dependent on C level incompatibilities, so at least
|> > : any incompatible changes visible to the 'official' C interface should from
|> > : now on force an increment of the major version!
|>
|> Following this rule, I imagine that there would only be major version
|> changes
|> and no minor version changes in the next few releases. Nonethless, I
|> agree
|> that dynamic loading makes C-level compatibility critical. Maybe an end
|> to minor version C incompatibilities should go on the wish list?
The problem with this approach is that the changes really *are* backward
compatible for Tcl scripts. They're just not compatible for extensions.
Incrementing the major version number for each release will cause problems
for script writers, and there are many more of them than extension writers.
Thus I think it's better to only increment the major version numbers when
there are Tcl-level incompatibilities, and have extension writers require
exact matching in their Tcl_PkgRequire calls.
We'd like not to have C incompatibilities, but realistically, with all the
stuff happening with the ports and compiler, they're going to be very hard
to avoid for the next year or so. After that it should be a lot easier to
keep the C interfaces stable.....
John Ousterhout
In article <4mrca0$g...@nz12.rz.uni-karlsruhe.de>, DA...@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
|> : We'd like not to have C incompatibilities, but realistically, with all the
|> : stuff happening with the ports and compiler, they're going to be very hard
|> : to avoid for the next year or so. After that it should be a lot easier to
|> : keep the C interfaces stable.....
|>
You don't have to wait. Just specify "exact" version matching in C
extensions.
|> If I remember right, someone else has already suggested using the version
|> numbering convention of Linux, where even minor numbers are stable releases
|> intented for building distributions and odd ones are the "on the edge"
|> development versions.
|> So on even numbered only make patches for bug fixes without breaking C
|> interfaces nor Tcl scripts, and play as you like and/or need on odd numbered
|> releases without any compatibility restrictions from release to release.
|> If things have settled, increment odd to even and freeze again.
This sounds complicated; it will be hard to follow the even-odd discipline.
Again, the simplest way is just to specify exact version dependencies for
C code.
|> Does it look now there will be C interface changes in the upcoming patches for
|> 7.5/4.1? If so, please, at least document in the master change logs what is
|> affected. Otherwise I've to compare file by file between releases, no fun!
I believe that virtually all C interface changes in the past would have been
detected by a proper ANSI C compiler. This is one of the reasons why we've
been more permissive about C-level changes; it's much easier to locate the
places to fix than for incompatibilities at the Tcl level. You shouldn't
have to do any file comparisons.
|> I almost forgot the above should apply for prolog.ps also!
|> By chance I noticed yesterday that DrawText lost an argument somewhere
|> between Tk4.1a1 and Tk4.1 instead of just keeping it as a placeholder and
|> popping it off the PostScript stack.
|> Obviously prolog.ps is needed for a canvas item type extensions, therefore it
|> should be considered an official interface and not a private one.
Prolog.ps should be considered private to Tk. If you need macros for your
own canvas item types, you should define them yourself. We're not prepared
to offer any guarantees for the interfaces in prolog.ps. In general, if
something isn't described in a manual page, then you should consider it
private.
Heribert Dahms
In <4mt5m3$g...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com
(John Ousterhout) writes:
: In article <4mrca0$g...@nz12.rz.uni-karlsruhe.de>,
DA...@ifk20.mach.uni-karlsruhe.de (Heribert Dahms) writes:
: |> : We'd like not to have C incompatibilities, but realistically, with all
the
: |> : stuff happening with the ports and compiler, they're going to be very
hard
: |> : to avoid for the next year or so. After that it should be a lot easier
to
: |> : keep the C interfaces stable.....
: |>
: |> I can't wait another year before actually using load/package.
:
: You don't have to wait. Just specify "exact" version matching in C
: extensions.
:
That's no win. I still would have to track any changes to Tcl/Tk and then even
if there happen to be no incompatibilities.
It looks like I have to stop following new Tcl/Tk versions as soon as our
required stuff runs on all needed platforms fast and stable enough, which may
mean folks have to wait really long before I've time to refresh my extension.
: |> If I remember right, someone else has already suggested using the version
: |> numbering convention of Linux, where even minor numbers are stable releases
: |> intented for building distributions and odd ones are the "on the edge"
: |> development versions.
: |> So on even numbered only make patches for bug fixes without breaking C
: |> interfaces nor Tcl scripts, and play as you like and/or need on odd
numbered
: |> releases without any compatibility restrictions from release to release.
: |> If things have settled, increment odd to even and freeze again.
:
: This sounds complicated; it will be hard to follow the even-odd discipline.
: Again, the simplest way is just to specify exact version dependencies for
: C code.
:
: |> Does it look now there will be C interface changes in the upcoming patches
for
: |> 7.5/4.1? If so, please, at least document in the master change logs what is
: |> affected. Otherwise I've to compare file by file between releases, no fun!
:
: I believe that virtually all C interface changes in the past would have been
: detected by a proper ANSI C compiler. This is one of the reasons why we've
: been more permissive about C-level changes; it's much easier to locate the
: places to fix than for incompatibilities at the Tcl level. You shouldn't
: have to do any file comparisons.
:
Then I would have to actually try to build a new Tcl/Tk version. Luckily I was
never bit by any of the bugs fixed in the 3 pairs of patches for 7.4/4.0, so
I tend to read the change notes if it's worth the effort of installing a patch
or new version first. In doubt I look at diffs on the source trees or the
patches itself. (And that on the fly reading from floppies, since on my Linux
box at home the harddisks are always locked at the full state 8-)
And if all extension writers rely on exact matching, I had to FTP all everytime
and build anything anew, all that on at least 4 different platforms and finally
install on a handful of systems. A lot of work and I still haven't upgraded my
own extension! You can guess my boss will say that's not my real work...
To be fair one benefit remains: Building each extension separately and loading
as needed instead of the creating a kitchen sink type wish.
But even that's not trivial; I'm just fighting with HP-UX 9.05 and compilers
to produce PIC (the "dumb" preinstalled cc, c89 and gcc 2.6.3). Who succeeded?
: |> I almost forgot the above should apply for prolog.ps also!
: |> By chance I noticed yesterday that DrawText lost an argument somewhere
: |> between Tk4.1a1 and Tk4.1 instead of just keeping it as a placeholder and
: |> popping it off the PostScript stack.
: |> Obviously prolog.ps is needed for a canvas item type extensions, therefore
it
: |> should be considered an official interface and not a private one.
:
: Prolog.ps should be considered private to Tk. If you need macros for your
: own canvas item types, you should define them yourself. We're not prepared
: to offer any guarantees for the interfaces in prolog.ps. In general, if
: something isn't described in a manual page, then you should consider it
: private.
Then I must have missed what the official hook functions are for placing my
own Postscript definitions in the proper prolog section. Are there any?
What namespace should I use?
AFAIK canvas item type routines are invoked only twice, once for collecting
fonts and then producing final output. Both places seem wrong for adding such
setup things as I understand EPSF conventions. BTW, I have the PS book.
While I'm at it: Can't you optimize away the first pass by specifing fonts
"(at end)"?
P.S. I nevertheless think it's great what you & team have done!
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Donal K. Fellows
In article <4mtt8a$p...@nz12.rz.uni-karlsruhe.de>,
Heribert Dahms <DA...@ifk20.mach.uni-karlsruhe.de> wrote:
> While I'm at it: Can't you optimize away the first pass by specifing fonts
> "(at end)"?
Not all previewers like that (though it isn't as bad as putting the
number of pages at the end). Since postscript generation seems fast
anyway, I'd say keep it the way it is at the moment.
Donal.
--
Donal K. Fellows, (at work) | Donal K. Fellows, (at home)
Dept. of Computer Science, | 6, Randall Place, Heaton,
University of Manchester | Bradford, BD9 4AE
U.K. Tel: ++44-161-275-6137 | U.K. Tel: ++44-1274-401017
fell...@cs.man.ac.uk (preferred) | do...@ugglan.demon.co.uk (if you must)
--------------------------------------------------------------------------
<http://r8h.cs.man.ac.uk:8000/> for my home page
Heribert Dahms
Hi John,
I guess you get bored telling me I should use exact version matching,
so you probably skipped my previous article, but I really want your opinion
on the following [trimmed down]...
In <4mtt8a$p...@nz12.rz.uni-karlsruhe.de> DA...@ifk20.mach.uni-karlsruhe.de
(Heribert Dahms writes:
: In <4mt5m3$g...@engnews2.Eng.Sun.COM> ous...@tcl.eng.sun.com
: (John Ousterhout) writes:
:
: : Prolog.ps should be considered private to Tk. If you need macros for your
: : own canvas item types, you should define them yourself. We're not prepared
: : to offer any guarantees for the interfaces in prolog.ps. In general, if
: : something isn't described in a manual page, then you should consider it
: : private.
:
: Then I must have missed what the official hook functions are for placing my
: own Postscript definitions in the proper prolog section. Are there any?
: What namespace should I use?
: AFAIK canvas item type routines are invoked only twice, once for collecting
: fonts and then producing final output. Both places seem wrong for adding such
: setup things as I understand EPSF conventions. BTW, I have the PS book.
: P.S. I nevertheless think it's great what you & team have done!
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)