Tcl/Tk - Observations from a newbie.
USCode
impressed by it's all-around capabilities, community support, etc. IMHO I
feel there are some things, in the Tk toolkit in particular, that could be
improved and which would make Tcl/Tk attractive to a wider range of
developers (particularly Windows developers as they're the biggest crowd out
there), hopefully bringing others into the Tcl/Tk fold.
In my observations I've noticed a few things that as an newbie immediately
caught my attention. I would like to present them here as suggestions for
improvement, possibly for the next version currently in development (8.5)?
I'll first list them out then give more detailed explanations below.
As I am very new to Tcl/Tk I realize I could be way off on many of these
and/or many have probably already been suggested.
- Suggestions -
TK
1 - Add tk_chooseFont command
2 - Add tk_choosePrinter command
3 - Add combobox widget
4 - Add tree control widget
5 - Add notebook/tab widget
6 - Add progressbar widget
7 - Add toolbar widget
8 - Add statusbar widget
9 - Enhance the *nix widgets to look more GTK2-like, or at least more
sharp/modern.
10- Enhance listbox widget to support multiple columns
11- Enhance button widget to support "flat" style
12- Rename tk_getOpenFile to tk_chooseFile
13- Rename tk_optionMenu to optionMenu
14- Rename tk_setPalette to setPalette
15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to focusNext,
focusPrev and focusFollowsMouse.
TCL
16 - Rename concat to lconcat
17 - Rename join to ljoin
18 - Rename split to lsplit
MISC
- I thought of asking to add the excellent tktable widget to the Tk core but
tables/grids tend to be a personal preference for many folks and Jeff does a
fantastic job of developing/supporting it as an extension so it might be
best to leave out of the Tk core for now.
- Details -
TK
1,2 - Windows and OS X offer native versions of Font and Printer choosers
which should be utilized. I believe Donal is working on a tk_chooseFont
command right now. A tk_choosePrinter would be nice as well but understand
there are issues on *nix. For *nix, a TCL/TK version of tk_chooseFont could
be provided, not sure what to do about tk_choosePrinter on *nix (CUPS?) but
it's a must-have to Windows and OS X developers.
3 - This is a must-have and is supported natively on Windows and OS X. I
believe there are some other excellent Tcl/Tk comboboxes out there that
could be used for *nix.
4 - The excellent treectrl extension should be part of the Tk core, it is
just excellent IMHO and ready to go.
5, 6 - I believe both Windows and OS X have native API implementations of
the notebook/tab widget. I've seen many other excellent Tcl/Tk ones that
could be used for *nix. The progress bar isn't as critical but very common.
7,8 - Very common widgets in today's applications. Perhaps these could be
simulated with the existing Frame widget but I believe Windows and OS X
offer native implementations and there are Tcl/Tk versions available for
*nix.
9 - The *nix widgets all need a facelift to look more modern and sharp. I
think others have already done some work in this area.
10 - Pretty self-explanatory though the excellent treectrl could be used to
support this functionality as-is!
11 - The flat button-style is pretty common in most new apps these days and
would help give a Tcl/Tk application that modern look, particularly on
toolbars.
12,13,14,15 - For consistency with other related commands, these commands
could be renamed as suggested. The existing commands should be kept around
for backwards compatibility, deprecated. To me there didnt seem to be any
consistency as to when "tk_" was used or not?
TCL
16,17,18 - Seems like all the other commands that work on Lists start with
an 'l' (lowercase L) except these. The existing commands should be kept
around for backwards compatibility, deprecated.
Once again, kudos to all the dedicated maintainers, contributers and
community of Tcl/Tk.
Thanks for listening! =)
Jeff Hobbs
> I've only been investigating Tcl/Tk for a short while but have been very
> impressed by it's all-around capabilities, community support, etc. IMHO I
> feel there are some things, in the Tk toolkit in particular, that could be
> improved and which would make Tcl/Tk attractive to a wider range of
> developers (particularly Windows developers as they're the biggest crowd out
> there), hopefully bringing others into the Tcl/Tk fold.
Thanks for the insightful comments. Some further questions ...
> In my observations I've noticed a few things that as an newbie immediately
> caught my attention. I would like to present them here as suggestions for
> improvement, possibly for the next version currently in development (8.5)?
> I'll first list them out then give more detailed explanations below.
>
> As I am very new to Tcl/Tk I realize I could be way off on many of these
> and/or many have probably already been suggested.
Why suggestions to rename things? They seem somewhat arbitrary,
and one thing that is important as we go forward is to not lose
compatability for trivial things. You can always set up aliases
yourself like so:
interp alias {} tk_chooseFile {} tk_getOpenFile
> - Suggestions -
> TK
> 1 - Add tk_chooseFont command
> 2 - Add tk_choosePrinter command
> 3 - Add combobox widget
> 4 - Add tree control widget
> 5 - Add notebook/tab widget
> 6 - Add progressbar widget
> 7 - Add toolbar widget
> 8 - Add statusbar widget
While I've seen many implementations of tree, notebooks and
progressbars, I'd be interested if you could elaborate on
toolbar and statusbar in detail.
> 9 - Enhance the *nix widgets to look more GTK2-like, or at least more
> sharp/modern.
> 10- Enhance listbox widget to support multiple columns
This would most likely be a new widget. Note that the treectrl
widget does multicolumn trees quite well. You can see this put
to use in the Tcl Dev Kit VFS Explorer.
> 11- Enhance button widget to support "flat" style
Eh? Aside from -relief flat -overrelief raised -bd 1?
> MISC
> - I thought of asking to add the excellent tktable widget to the Tk core but
> tables/grids tend to be a personal preference for many folks and Jeff does a
> fantastic job of developing/supporting it as an extension so it might be
> best to leave out of the Tk core for now.
This is actually a widget targetted for the core. There are good
reasons for being in the core rather than just being a
well-maintained extensions. In the core, to say you have Tk then
means you have a full-featured table widget. It is also useful
for people who use Tk from other languages.
The tk_* commands are for dialogs for the most part, with some
helper commands tossed in that are implemented in Tcl.
> TCL
> 16,17,18 - Seems like all the other commands that work on Lists start with
> an 'l' (lowercase L) except these. The existing commands should be kept
> around for backwards compatibility, deprecated.
They operate on strings just as well as lists. They have some
special behaviors on pure lists, but it doesn't really change
their basic operation.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Victor Wagner
> interp alias {} tk_chooseFile {} tk_getOpenFile
I'd rather suggest that there is need for third filechooser command
Now we have tk_getOpenFile, which allows to open only EXISTING files.
We also have tk_getSaveFile, which pops up annoying confirmation dialog
when user chooses to open existing file, assuming that application is
going to overwrite it.
But there is wide enough class of applications, which can transparently
for user handle both existing and new files. Imagine for example text
editor, which creates a new file, when user chooses new file name and
displays content of existing file when user chooses existing file.
Unfortunately Tk doesn't provide version of file dialog which allows to
select both existing and not existing file and handle with their existense
later. Really option -confirmoverwrite boolean for tk_getSaveFile would suffice.
By default it would be set to yes, so no existing script would be
broken. But if programmer choose to set it to no, he would receive
filename from user without additional (sometimes misleading) dialog
boxes.
--
Portability should be the default.
-- Larry Wall in <1997110722...@wall.org>
USCode
>
> Why suggestions to rename things? They seem somewhat arbitrary,
> and one thing that is important as we go forward is to not lose
> compatability for trivial things. You can always set up aliases
> yourself like so:
>
> interp alias {} tk_chooseFile {} tk_getOpenFile
>
I don't know if I'd consider consistency trivial, especially for the new
users I would assume we're trying to attract. I definitely think we should
keep the old commands around for backwards compability though. These were
just my observations as someone new to the language.
>
> While I've seen many implementations of tree, notebooks and
> progressbars, I'd be interested if you could elaborate on
> toolbar and statusbar in detail.
>
I believe both toolbar and status bar are available through the Win32 API
via the comctl32.dll. I believe OS X has something similar. As I have in
my Details section of my original post, I think using the Frame widget we
could implement toolbars and statusbars and so I wouldn't consider these 2
high priority.
>
> This would most likely be a new widget. Note that the treectrl
> widget does multicolumn trees quite well. You can see this put
> to use in the Tcl Dev Kit VFS Explorer.
>
I agree and made the same comment in my Details section. The treectrl in
the core would more than cover for a dedicated multicolumn listbox.
> > 11- Enhance button widget to support "flat" style
>
> Eh? Aside from -relief flat -overrelief raised -bd 1?
>
Excellent, thanks! Didn't see that!
>
> This is actually a widget targetted for the core. There are good
> reasons for being in the core rather than just being a
> well-maintained extensions. In the core, to say you have Tk then
> means you have a full-featured table widget. It is also useful
> for people who use Tk from other languages.
>
I certainly wouldn't complain about tktable being in the core, I think it
would make a terrific addition!
>
> They operate on strings just as well as lists. They have some
> special behaviors on pure lists, but it doesn't really change
> their basic operation.
>
Makes sense to me, thanks.
Thanks for taking the time to respond to my post and your feedback Jeff.
Victor Wagner
>>
> I don't know if I'd consider consistency trivial, especially for the new
> users I would assume we're trying to attract. I definitely think we should
Why would you assume such a silly idea? Tcl/Tk is mature enough both as
language and as community. I think that most valued goal is not to scare
away old users, rather than attract new ones.
Fortunately, Tcl community is not commercial software vendor which would
go bancrupt without stream of revenues from new users and doesn't care
much about old ones, which are no better than new ones from the point of
view of marketing department.
As far as I can understand, new features appear in Tcl/Tk when someone
already experienced in Tcl programming need them to solve new problem or
deploy Tcl in new area.
> I believe both toolbar and status bar are available through the Win32 API
> via the comctl32.dll. I believe OS X has something similar. As I have in
I believe that Windows is not a most important platform for Tcl/Tk.
It should be there, because people want windows ports of apps, and it is
pain to develop them in such developer-hostile environment as Windows.
Uniqueness of Tcl/Tk is that it allows to develop application in
developer-friendly environment of Unix, and then deploy them on Windows
without even recompilation.
--
echo "Congratulations. You aren't running Eunice."
-- Larry Wall in Configure from the perl distribution
USCode
> USCode <usc...@dontspam.me> wrote:
>
> Why would you assume such a silly idea? Tcl/Tk is mature enough both as
> language and as community. I think that most valued goal is not to scare
> away old users, rather than attract new ones.
>
users to Tcl/Tk?
> Fortunately, Tcl community is not commercial software vendor which would
> go bancrupt without stream of revenues from new users and doesn't care
> much about old ones, which are no better than new ones from the point of
> view of marketing department.
>
Why can't we attract new users AND keep old users at the same time?
> As far as I can understand, new features appear in Tcl/Tk when someone
> already experienced in Tcl programming need them to solve new problem or
> deploy Tcl in new area.
>
I think the TCT is open to suggestions and new features can also appear in
Tcl/Tk by suggestions to them from the community.
>
> I believe that Windows is not a most important platform for Tcl/Tk.
> It should be there, because people want windows ports of apps, and it is
> pain to develop them in such developer-hostile environment as Windows.
>
Never said it was the most important platform. But IMHO there is a large
pool of Windows developers that would be interested in Tcl/Tk with a few
enhancements that could also be useful to users of Tcl/Tk on all platforms.
> Uniqueness of Tcl/Tk is that it allows to develop application in
> developer-friendly environment of Unix, and then deploy them on Windows
> without even recompilation.
>
Or vice-versa, no?
Darren New
> I believe that Windows is not a most important platform for Tcl/Tk.
I disagree. Lots of people use Windows to both develop and deploy Tcl
apps and Tk apps.
> It should be there, because people want windows ports of apps, and it is
> pain to develop them in such developer-hostile environment as Windows.
Not sure what you find painful about it, really. It isn't UNIX,
certainly, but <Balmer>Developers, Developers, ...</Balmer> it isn't
painful.
> Uniqueness of Tcl/Tk is that it allows to develop application in
> developer-friendly environment of Unix, and then deploy them on Windows
> without even recompilation.
Interestingly enough, I usually go the other way around.
I just wish the Windows X emulation would get fixed so changing screen
resolution doesn't make Wish stop painting properly. :-)
Victor Wagner
>> Why would you assume such a silly idea? Tcl/Tk is mature enough both as
>> language and as community. I think that most valued goal is not to scare
>> away old users, rather than attract new ones.
>>
> I'm not clear on what part you consider "silly" ? Trying to attract new
> users to Tcl/Tk?
Trying to set up development priorities looking to new users.
Development priorities should be set to achieve technological
superiority. If there would be techological superiority, new users would
came anyway and learn any language we, old users, are used to.
>> Fortunately, Tcl community is not commercial software vendor which would
>> go bancrupt without stream of revenues from new users and doesn't care
>> much about old ones, which are no better than new ones from the point of
>> view of marketing department.
>>
> Why can't we attract new users AND keep old users at the same time?
Because ways to attract new users, you are suggesting are marketing
crap. Old users would be scared away with it.
>> As far as I can understand, new features appear in Tcl/Tk when someone
>> already experienced in Tcl programming need them to solve new problem or
>> deploy Tcl in new area.
>>
> I think the TCT is open to suggestions and new features can also appear in
> Tcl/Tk by suggestions to them from the community.
You just think. I have some experience. If you want your suggestion to
be accepted, you have to write a patch. Moreover, you have to follow
coding style, and make sure that no other people's code breaks.
Otherwise you can seat there forever and wait for someone to implement
your suggestion.
Of course it can happen that some of TCT would kick himself at forehead
reading your suggestion, and cry "How I couldn't think of this before".
This is only way how just suggestion can make into next release - at
least one of active project members would find your suggestion
excellent, and make it into runnable code.
>>
>> I believe that Windows is not a most important platform for Tcl/Tk.
>> It should be there, because people want windows ports of apps, and it is
>> pain to develop them in such developer-hostile environment as Windows.
>>
> Never said it was the most important platform. But IMHO there is a large
You suggested to look into some silly DLLs for implementation of some
silly controls. Since source code of these DLLs is not published,
only way to use them is use system they are part of.
BTW, I'm programming GUI for fifteen years and I sincerely don't
understand what is so cool in toolbars.
First of all, what is so special in the toolbar? Why have it be a
separate widget? What the difference
between just frame with row of iconic buttons and thing which is called
toolbar?
And every time I see a toolbar in somebody else's application, it looks
very cryptic. It is much harder to associate these 16x16 icons with
their function than to remember appropriate number of keyboard
shortcuts.
> pool of Windows developers that would be interested in Tcl/Tk with a few
Sincerely, I'd rather sentence all those developers to not to touch
anything containing microprocessor for the rest of life.
They do not understand basic principle of programmable equipment - USER
SHOULD NEVER FORCED TO DO ANYTHING BY HAND. If program allows to do
something using keyboard or mouse clicks, it should always allow to do
same thing programmatically, so if user finds out that he have to repeat
same sequence of action more than twice, he can turn it into macro.
Second basic principle which is often violated by Windows application
(and things like Gnome/KDE too) - never try to attract user attention
more than problem deserves. User has other important things to do than
repeatedly click only button in your system-modal dialogs.
--
Actually, typing random strings in the Finder does the equivalent of
filename completion.
-- Discussion on file completion vs. the Mac Finder
Jeff Hobbs
> Victor Wagner wrote:
>> I believe that Windows is not a most important platform for Tcl/Tk.
>
>
> I disagree. Lots of people use Windows to both develop and deploy Tcl
> apps and Tk apps.
I would say that one of Tk's key strengths is how easy it is to
create x-platform apps, and you can even make it look good across
multiple platforms with a small amount of coding effort.
> I just wish the Windows X emulation would get fixed so changing screen
> resolution doesn't make Wish stop painting properly. :-)
wish doesn't have a problem with changing screen resolution on
Windows, it has an issue with changing screen depth. The problem
is that Tk caches the colormaps for performance reasons. Someone
needs to look how to force a refresh of the colormaps on the
Windows screen depth change. If someone is interesting in looking
into this, I can point the way.
Victor Wagner
> Not sure what you find painful about it, really. It isn't UNIX,
I find painful that I have to do things by hand which are better done
by programs. Problem is that I cannot redirect output of GUI program
into filter. Also it is much harder to feed input into GUI program than
I can feed input into text-based program using, say, expect.
I find painful to learn API which consist of more than couple of
hundreds system calls, and most calls have two version - with A and with
U at the end.
I find painful that system uses two different character encodings at the
same time. Of course, in Unix I often run programs with four different
locales at the same time. But it is due to nature of processed data, not
due to some system internal reasons.
I find painful that I cannot copy/paste everywhere using just mouse.
> Interestingly enough, I usually go the other way around.
> I just wish the Windows X emulation would get fixed so changing screen
> resolution doesn't make Wish stop painting properly. :-)
I wish this too. Although I don't understand why user want to change
screen resolution and color depth. I typically set best one particular
display can support, and never play with it, especially having some
application with unsaved data running. But Windows users do.
--
I read the newspaper avidly. It is my one form of continuous fiction.
-- Aneurin Bevan
Darren New
> I find painful that I have to do things by hand which are better done
> by programs. Problem is that I cannot redirect output of GUI program
> into filter.
I never had a problem with this on my own programs.
> Also it is much harder to feed input into GUI program than
> I can feed input into text-based program using, say, expect.
You're not supposed to do that. You're supposed to use the right
interfaces to drive the program, instead of pretending to type at them.
> locales at the same time. But it is due to nature of processed data, not
> due to some system internal reasons.
Well, due to compatibility, I expect.
> I find painful that I cannot copy/paste everywhere using just mouse.
Tcl doesn't do this quite right, seeming to use the X model for
copy/paste too, but I don't have problems cutting and pasting with the
mouse in any other program.
> I wish this too. Although I don't understand why user want to change
> screen resolution and color depth.
Wehn you've left a program running on the screen, and you now want to
log in remotely and pick it up from another screen. Of course, I don't
think you can do this in X, so it probably doesn't come up as often.
USCode
[snip]
>
> Of course it can happen that some of TCT would kick himself at forehead
> reading your suggestion, and cry "How I couldn't think of this before".
> This is only way how just suggestion can make into next release - at
> least one of active project members would find your suggestion
> excellent, and make it into runnable code.
>
That's all these were Victor, just suggestions ...
David N. Welton
> Because ways to attract new users, you are suggesting are marketing
> crap. Old users would be scared away with it.
What is "marketing crap" for you is someone else's wisdom. Instead of
shunning it, try and see the value in it.
Also, there is marketing, and there is marketing. Tcl could use a bit
of the good sort.
--
David N. Welton
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Photos: http://www.dedasys.com/photos/
David N. Welton
> Victor Wagner wrote:
> > I believe that Windows is not a most important platform for Tcl/Tk.
> I disagree. Lots of people use Windows to both develop and deploy
> Tcl apps and Tk apps.
I can't stand windows, and avoid it like the plague.
But you know what's really cool? Tcl/Tk let me write an app on my
Linux box, do some minimal testing and tweaking on a windows machine,
and then hand it off to a client! It was so cool to see it 'just
work'.
Sektor van Skijlen
> Unfortunately Tk doesn't provide version of file dialog which allows to
> select both existing and not existing file and handle with their existense
> later. Really option -confirmoverwrite boolean for tk_getSaveFile would
> suffice.
Huh :)
The Qt library, for example, does not ask for overwriting the file at all
(QFileDialog::getSaveFileName). You have to verify it on your own. Accustomed
to that I just verified after the file has been chosen and was only astonished
that the "ask for overwrite" occurs twice.
I think this is better solution - however adding a boolean option whether to
ask for overwriting is definitely the best solution.
I would even propose that there be just "tk_chooseFile" and if to save or to
open or just choose, it be selected by another option.
Since I mentioned Qt and its getSaveFileName, one more thing, by the way. This
function has also a boolean option deciding about automatic resolving
symlinks. When this option is on (by default), any symbolic links to
directories are replaced with their targets. If off - they are treated as
regular directories.
AFAIR, there's no such option in tk_getOpenFile and symbolic links are
resolved as well. This disturbs sometimes; last time, when I made a simple
application for editing a configuration file, there were written paths to
files inside. They, unfortunately, must have been long, because "short paths"
were only as long as you regard symbolic links. When a symbolic link was
resolved, the name became "original", very long path. I think something like
"-nosymlinks" would be also good.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
Donald Arseneau
[concat, join, split]
> They operate on strings just as well as lists.
These used to be documented as operating on lists, period.
More recent documentation reflects their actual behavior
of joining strings, with regular spacing.
Donald Arseneau as...@triumf.ca
Sektor van Skijlen
>> I believe both toolbar and status bar are available through the Win32 API
>> via the comctl32.dll. I believe OS X has something similar. As I have in
> I believe that Windows is not a most important platform for Tcl/Tk.
You're wrong. Maybe it is still not the most important platform, but it is at
least the same important as Unices, for example.
I would definitely agree that saying that somthing is available in comctl32
makes adding widgets directly to Tk unnecessary, is wrong. Especially if the
matter is about widgets, new features have to work on every plaftform, which
Tk is available on.
> It should be there, because people want windows ports of apps, and it is
> pain to develop them in such developer-hostile environment as Windows.
You are completely wrong. I develop applications on such environment, on which
it is for me most comfortable. If I used Unix, I would use many popular unix
tools and vim (gvim) as an editor. While I'm using a Windows system, I install
Cygwin and use also gvim (native) for Windows (sometimes also gvim for Cygwin,
especially if I need vim to use Cygwin paths). I use gvim for Windows mostly
because it is much faster than any editor I could use in a Unix environment
(regarding that Unix is on the server, not on my machine).
> Uniqueness of Tcl/Tk is that it allows to develop application in
> developer-friendly environment of Unix, and then deploy them on Windows
> without even recompilation.
Really? I don't think so.
Last time I developed an application in Tk. I used - as I told - gvim for
Windows to write the code, because this was the fastest programmer's editor in
my environment. However this application was targeted on Unix, because it was
a configurator for a configuration file, where paths should accord to the
local file system. Obviously could I run this application on Windows! But what
for - I could not update paths in this configuration file, because paths on
windows, even for the same resources, look totally different. Of course, Tk
proved quite good portability, but what does the portability matter, when your
application contains environment specific features?
Donald Arseneau
> I wish this too. Although I don't understand why user want to change
> screen resolution and color depth. ... But Windows users do.
Given the keyboard shortcuts to cycle through X screen resolutions,
n*x users do too!
Donald Arseneau as...@triumf.ca
Kaitzschu
> Wehn you've left a program running on the screen, and you now want to
> log in remotely and pick it up from another screen. Of course, I don't
> think you can do this in X, so it probably doesn't come up as often.
Well, we do have libdisplaymigration... Although, I don't think anything
uses it quite yet.
--
-Kaitzschu
echo "\|/ ____ \|/>\"@'/ ,. \\\`@\">/_| \__/ |_\> \__U_/" | sed -e "s/>/\n/g"
Darren New
> Well, we do have libdisplaymigration... Although, I don't think anything
> uses it quite yet.
This must be relatively new. I heard a talk by some folks at Xerox
trying to do ubiquitous computing platforms complaining that X11R6
didn't actually keep enough state that you could basically move all the
windows from one display server to another and manage to pick up where
you left off. So if you were working on your laptop, and walked back to
your office, you couldn't just log into your desktop machine and have
all the windows from your laptop show up on your desktop, without
modifying the protocol. Perhaps that's been done since then.
Sektor van Skijlen
> 3 - Add combobox widget
I hope you mean combobox with edition field, because rest of its properties
the menubutton has.
> 7 - Add toolbar widget
Toolbar widget can be implemented with a frame, containing buttons created
with -bitmap option. There could be created some "shorter" way to provide the
same, but there still must be some way to identify them. And still the bitmaps
and slots to execute on button click should be somehow provided. I don't think
there can be created some reasonable shourtcut for these operations.
I'd rather propose somethink like "actions" in Qt, that is, objects, which
bind the keyboard shortcut, menu entry and toolbar button.
> 8 - Add statusbar widget
I think "label" with "-textvariable" quite well matches the needs.
> 9 - Enhance the *nix widgets to look more GTK2-like, or at least more
> sharp/modern.
That's good. It would be probably nice to provide something like "styles",
where widgets can have many different "look-and-feel"-s (of course, set
globally for all widgets :).
> 12- Rename tk_getOpenFile to tk_chooseFile
> 13- Rename tk_optionMenu to optionMenu
> 14- Rename tk_setPalette to setPalette
> 15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to focusNext,
> focusPrev and focusFollowsMouse.
Why not tk::optionMenu and so on?
> 16 - Rename concat to lconcat
> 17 - Rename join to ljoin
> 18 - Rename split to lsplit
and rename open to fopen, close to fclose and so on (or even make them the
subcommand of "file"). I don't think it is possible to "rename" something,
because it would destroy existing applications - rather make aliases. I also
think renaming close to something more aligned to "file" category would be
especially good for expect, which has its own "close" command (I know, renamed
to exp_close).
> 7,8 - Very common widgets in today's applications. Perhaps these could be
> simulated with the existing Frame widget but I believe Windows and OS X
> offer native implementations and there are Tcl/Tk versions available for
> *nix.
Maybe, but it probably needs more work on systems, which do not support it
natively. Of course, I didn't try to imagine, if the "frame with buttons"
looks a bit close to Windows "native" toolbars :)
> 9 - The *nix widgets all need a facelift to look more modern and sharp. I
> think others have already done some work in this area.
I think "styles" is the best solution. Let's add styles to Tk and let people
create their own styles. So far, both Qt and Gtk support styles.
> 12,13,14,15 - For consistency with other related commands, these commands
> could be renamed as suggested. The existing commands should be kept around
> for backwards compatibility, deprecated. To me there didnt seem to be any
> consistency as to when "tk_" was used or not?
I think it is best to move them into some namespace.
> TCL
> 16,17,18 - Seems like all the other commands that work on Lists start with
> an 'l' (lowercase L) except these. The existing commands should be kept
> around for backwards compatibility, deprecated.
I agree, but I think the same situation is about "open", "close" and so on;
they could even be subcommands of 'file' (file open sounds much better than
just "open", which is much ambiguous).
USCode
>
> I would definitely agree that saying that somthing is available in
comctl32
> makes adding widgets directly to Tk unnecessary, is wrong. Especially if
the
> matter is about widgets, new features have to work on every plaftform,
which
> Tk is available on.
>
I absolutely NEVER said anything to imply this at all. I was merely
answering a direct question from Jeff.
USCode
> > 3 - Add combobox widget
>
> I hope you mean combobox with edition field, because rest of its
properties
> the menubutton has.
>
Absolutely, thanks for the clarification.
> > 7 - Add toolbar widget
>
> Toolbar widget can be implemented with a frame, containing buttons created
> with -bitmap option. There could be created some "shorter" way to provide
the
> same, but there still must be some way to identify them. And still the
bitmaps
> and slots to execute on button click should be somehow provided. I don't
think
> there can be created some reasonable shourtcut for these operations.
>
I agree, please see my details section and other responses in this thread.
> I'd rather propose somethink like "actions" in Qt, that is, objects, which
> bind the keyboard shortcut, menu entry and toolbar button.
>
> > 8 - Add statusbar widget
>
> I think "label" with "-textvariable" quite well matches the needs.
>
Yep, or maybe as you suggested earlier, a frame with a label.
> > 9 - Enhance the *nix widgets to look more GTK2-like, or at least more
> > sharp/modern.
>
> That's good. It would be probably nice to provide something like "styles",
> where widgets can have many different "look-and-feel"-s (of course, set
> globally for all widgets :).
>
> > 12- Rename tk_getOpenFile to tk_chooseFile
> > 13- Rename tk_optionMenu to optionMenu
> > 14- Rename tk_setPalette to setPalette
> > 15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to
focusNext,
> > focusPrev and focusFollowsMouse.
>
> Why not tk::optionMenu and so on?
>
> > 16 - Rename concat to lconcat
> > 17 - Rename join to ljoin
> > 18 - Rename split to lsplit
>
> and rename open to fopen, close to fclose and so on (or even make them the
> subcommand of "file"). I don't think it is possible to "rename" something,
> because it would destroy existing applications - rather make aliases. I
also
> think renaming close to something more aligned to "file" category would be
> especially good for expect, which has its own "close" command (I know,
renamed
> to exp_close).
>
"Renaming" probably wasn't a good choice of words on my part, but just
providing more consistent naming was the goal. As I said in my original
post, the old commands should still exist for backwards compatibility.
Yep.
Gerald W. Lester
> ...
> I believe that Windows is not a most important platform for Tcl/Tk.
Jeff can correct me if I'm wrong, but last I heard the Windows downloads
and usage out weighed the other platforms.
That being said, Tcl/Tk appeal is that you can write an application and
move it to another platform with little or no work (assuming your
application is written correctly and is not platform specific -- like
editing the registry on Windows or configuration files on *nix).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+
Robert Seeger
stings, and join only worked on lists... and if you used them on
something else they'd need to convert it to the respective form first
anyways.
At what point was split documented to work on lists? Or was it only part
of list by mistake?
Rob Seeger
Schofield
[...]
>
> Toolbar widget can be implemented with a frame, containing buttons created
> with -bitmap option. There could be created some "shorter" way to provide the
> same, but there still must be some way to identify them. And still the bitmaps
> and slots to execute on button click should be somehow provided. I don't think
> there can be created some reasonable shourtcut for these operations.
>
> I'd rather propose somethink like "actions" in Qt, that is, objects, which
> bind the keyboard shortcut, menu entry and toolbar button.
http://wiki.tcl.tk/actions
There are things out there that implement this, but nothing in the core.
[...]
--bryan
Schofield
[...]
> So if you were working on your laptop, and walked back to
> your office, you couldn't just log into your desktop machine and have
> all the windows from your laptop show up on your desktop, without
> modifying the protocol. Perhaps that's been done since then.
For old school user, you could just issue a
screen -R
Of course, you would probably be running
emacs -nw
too. Man I love terminals... I'm gonna start a anti-windowing-system
movement! No more comboboxes, tables, or trees.
Console! Console! Console!
:-P
-- bryan
Victor Wagner
>> I find painful that I have to do things by hand which are better done
>> by programs. Problem is that I cannot redirect output of GUI program
>> into filter.
> I never had a problem with this on my own programs.
How large is percent of your own program among those you use every day
in the development process? Do you run your own text editor, your own
debugger, your own coverage analyzer? If so, and if they are all
written on Tcl/Tk, probably OS kernel beneath them doesn't matter for
you at all.
> > Also it is much harder to feed input into GUI program than
>> I can feed input into text-based program using, say, expect.
> You're not supposed to do that. You're supposed to use the right
> interfaces to drive the program, instead of pretending to type at them.
O! You've found an exact word. I'm "not supposed to". This is thing which
annoys me most. I'm not supposed to do that, I'm not supposed to do
this. I'm supposed to seat at the very same computer program runs at.
And if I purcashe very expensive program which allows not to do this,
most windows applications break, and even MS Office requires additional
tools to be downloaded to work properly in terminal server setup.
BTW, we are talking about development. If I'm not supposed to feed
program with input automatically, how the hell I would TEST it?
>> locales at the same time. But it is due to nature of processed data, not
>> due to some system internal reasons.
> Well, due to compatibility, I expect.
>> I find painful that I cannot copy/paste everywhere using just mouse.
> Tcl doesn't do this quite right, seeming to use the X model for
> copy/paste too, but I don't have problems cutting and pasting with the
> mouse in any other program.
But how? There is no "Paste" button in Windows. You have to use keyboard
shorcuts for paste to any window which doesn't have menu. (BTW, using
menus are much worse than using keyboard shortcuts).
And may be you'll enlighten me and teach how to copy long command line
(longer than window width) from one console window to another such way
that it would remain one line?
>> I wish this too. Although I don't understand why user want to change
>> screen resolution and color depth.
> Wehn you've left a program running on the screen, and you now want to
> log in remotely and pick it up from another screen. Of course, I don't
> think you can do this in X, so it probably doesn't come up as often.
No, it is not a problem. Typically, you cannot log in remotely in
Windows at all. You have to purcashe special license.
All my bug reports
come from users which do not login remotely. They just click right
button on the desktop and play with its properties.
--
Footnotes are for things you believe don't really belong in LDP manuals,
but want to include anyway.
-- Joel N. Weber II discussing the 'make' chapter of LPG
Victor Wagner
> too. Man I love terminals... I'm gonna start a anti-windowing-system
> movement! No more comboboxes, tables, or trees.
What prevents you from using comboboxes, tables and trees in cures-based
program running on terminal? Yes, existing ports of tk to character
based environment do not provide them (but so does core Tk).
--
"How do you pronounce SunOS?" "Just like you hear it, with a big SOS"
-- dedicated to Roland Kaltefleiter
Victor Wagner
> I can't stand windows, and avoid it like the plague.
> But you know what's really cool? Tcl/Tk let me write an app on my
> Linux box, do some minimal testing and tweaking on a windows machine,
> and then hand it off to a client! It was so cool to see it 'just
> work'.
This is very thing I've mentioned in the my post.
I know that I'm not only in this camp and would be very glad to exchange
some experiencies.
But there are few problems I've encounter, which makes amount of testing
on target platform not-so-minimal.
I ought to grep my sources for switch {$::tcl_platform(platform)} to
make exact list of this glitches, but from memory:
1. Problem with character sets. Of course, it is much less annoying for
people who use us-ascii which is subset of all windows and unix
character sets.
2. Quite different directory layout. Most interesting problem is that
Windows DO have statdard directories for such things as program code,
configuration files and data files, and kindly places their names into
environment. But some users for whatever reason expect program to broke
this layout and put all the data files into its program directory. May
be because so many 3rd-party programs do so.
3. Registry. Well-behaved Windows program have to deal with registry.
4. Inter process communication. What do you use instead of send to debug
on Windows?
5. System color scheme. Yes, Tk provides way to use system colors. But
again it is platform specific. And Tk requires application to be
restarted after system color scheme was changed.
--
Just don't make the '9' format pack/unpack numbers... :-)
-- Larry Wall in <1997100914...@wall.org>
Victor Wagner
> I'd rather propose somethink like "actions" in Qt, that is, objects, which
> bind the keyboard shortcut, menu entry and toolbar button.
This can be quite easily implemented in pure Tcl. I've written something
alike for my last project.
There was a concept of "operation" which have name, command and keyboard
shortcut as properties. Operations can be enabled and disabled.
If you want to add operation to menu, just say
operationMenu $menu and it would perform $menu add command with all
appropriate parameters, and also remember than this menu entry should be
enabled/disabled along with entire operation.
Same thing with operationButton command, which allows to specify
alternate (typically shorter) text, and/or image.
If either of them is specifed, full name of operation is used as tooltip
for button.
There is also commands to disable/enable groups of operations.
May be I should polish this code and submit it to something like tklib.
--
As pointed out in a followup, Real Perl Programmers prefer things to be
visually distinct.
-- Larry Wall in <1997101618...@wall.org>
Donal K. Fellows
> But there is wide enough class of applications, which can transparently
> for user handle both existing and new files. Imagine for example text
> editor, which creates a new file, when user chooses new file name and
> displays content of existing file when user chooses existing file.
For what it's worth, the current most-common way of handling this thing
is to use separate "New" and "Save As..." items on the menu. This
transforms things into a more document-centric view, and (along with the
current configuration of warning messages) helps stop inadvertent
overwriting of files. It happened to me *twice* when I was an
undergraduate (I was using the old Athena-based xedit at the time) and
the pain of it was so bad I switched to (and learned) a proper text
editor instead.
It is explicitly intended that tk_getOpenFile is a mechanism for
selecting existing files to edit or read from, and tk_getSaveFile is a
mechanism for selecting a file that will written to in the immediate
future (and hence the selection of an existing file triggers a warning
confirmation dialog). This also closely models the behaviour you get on
Windows (where we use the std dialogs) and (IIRC) OSX too, and it
definitely saves users' bacon...
[Non-portable suggestion elided]
Donal.
Donal K. Fellows
> Since I mentioned Qt and its getSaveFileName, one more thing, by the way. This
> function has also a boolean option deciding about automatic resolving
> symlinks. When this option is on (by default), any symbolic links to
> directories are replaced with their targets. If off - they are treated as
> regular directories.
Are you talking about resolving the resulting file's symlinks or the
treatment of symbolic links (to directories) as (special) files instead
of directories? If the first, just [file normalize] the output. If the
second, well, perhaps that's something someone could add. (It'd be a
UNIX-only feature, which means that it's open to anyone who can hack a
Tcl script; the file you are looking for in your friendly local CVS
checkout is tk/library/tkfbox.tcl (and tk/library/xmfbox.tcl if you're
feeling energetic!) But if we were going to port those changes back to
the core, I'd love to hear about some use cases for the feature...
Donal.
Victor Wagner
: For what it's worth, the current most-common way of handling this thing
: is to use separate "New" and "Save As..." items on the menu. This
: transforms things into a more document-centric view, and (along with the
Unfortunately, not all files, which application wants to open, are
documents. Document-centric model is powerful enough for GUI apps intended to be used by infants and housewives, but sometimes we just want some more flexibility.
: current configuration of warning messages) helps stop inadvertent
: overwriting of files. It happened to me *twice* when I was an
I completely agree, that DEFAULT behavoir (isn't default behavoir is the
thing which should protect users from faults) of tk_getSaveFile should
remain the same as it is now.
But there should be OPTION for application developer to change this
behavoir if for some reason he wants to.
: It is explicitly intended that tk_getOpenFile is a mechanism for
: selecting existing files to edit or read from, and tk_getSaveFile is a
: mechanism for selecting a file that will written to in the immediate
: future (and hence the selection of an existing file triggers a warning
: confirmation dialog). This also closely models the behaviour you get on
: Windows (where we use the std dialogs) and (IIRC) OSX too, and it
It doesn't model behavoir of windows std dialog. It explicitely
RESTRICTS this behavoir to subset of it which was choosen by someone.
If you'll look into tkWinDialog.c, line 674 (in 8.4.7) you'll see that
flag OFN_OVERWRITEPROMPT is explicitly and unconditionally set.
I propose adding an option which would allow programmer to willingly
set or unset value of this flag. By default it should be set. If
application writer wants to just get name of file to save document into
it is the right thing.
But there are few other cases. May be we should consider it function of
tk_getOpenFile, not tk_getSaveFile (it first occured to me that it is
simplier just to strip away unneeded dialog, but now looking to the code
I see that it is equally simplier to do this both way), and add option
-allownonexisting to the tk_getOpenFile.
Consider example when application asks user to provide file name for
some auxillary data, such as encryption keys. If user don't have keys,
application may generate new ones for him, but they would have be stored
somewhere. If there is existing ones, they should be used.
User don't care much about key storage. He cares about documents to be
encrypted/decrypted/digitally signed. Key storage is just one of many
configuration options. But because it is file, application should
provide nice file dialog to set this option.
Consider also files, which can be created if they not exist or appended
if they exist, such as log files.
--
Vince Darley
> wish doesn't have a problem with changing screen resolution on
> Windows, it has an issue with changing screen depth.
Not quite: '[winfo screenwidth]' doesn't respect screen resolution changes.
http://sourceforge.net/tracker/?func=detail&aid=927492&group_id=12997&atid=112997
> The problem
> is that Tk caches the colormaps for performance reasons. Someone
> needs to look how to force a refresh of the colormaps on the
> Windows screen depth change. If someone is interesting in looking
> into this, I can point the way.
Of course this is the more serious problem.
Vince.
Donal K. Fellows
> Given the keyboard shortcuts to cycle through X screen resolutions,
> n*x users do too!
I thought that was usually implemented as "keeping the virtual screen
resolution the same and using a moving porthole the size of the physical
screen"...
Donal.
Victor Wagner
: wish doesn't have a problem with changing screen resolution on
: Windows, it has an issue with changing screen depth. The problem
: is that Tk caches the colormaps for performance reasons. Someone
: needs to look how to force a refresh of the colormaps on the
: Windows screen depth change. If someone is interesting in looking
: into this, I can point the way.
Why not publish this way somewhere. If not in the newsgroup, then in sourceforge tracker in the discussion about appropriate bug?
--
Donal K. Fellows
> 16,17,18 - Seems like all the other commands that work on Lists start with
> an 'l' (lowercase L) except these. The existing commands should be kept
> around for backwards compatibility, deprecated.
Actually [split] operates on lists and produces a list, so I'd call it
[string split] if I was doing everything again, but I'd agree with you
on [join]. However, [concat] is... odd in it behaviour. Renaming
[concat] to [lconcat] would imply something that is definitely not true;
it is really very very strange indeed when you look at it, and has to
stay that way for reasons that get discussed here maybe once a year? :^/
In Tcl 8.5, you will be able to simulate the effects of a real
list-oriented concatenation operator with [list] and the new {expand}
syntax, like this:
# Instead of: set foo [lconcat $bar $boo $spong]
set foo [list {expand}$bar {expand}$boo {expand}$spong]
Looking at that, I'd say that anyone who wants to write a small TIP to
introduce an [lconcat] command would have a slam-dunk new feature for
the core. :^D And it would be really easy C coding too...
Donal.
Robert Heller
In a message on 22 Aug 2004 14:52:53 -0700, wrote :
DA> vi...@45.free.net (Victor Wagner) writes:
DA>
DA> > I wish this too. Although I don't understand why user want to change
DA> > screen resolution and color depth. ... But Windows users do.
DA>
DA> Given the keyboard shortcuts to cycle through X screen resolutions,
DA> n*x users do too!
Only spacial resolution, not color depth. At least with XFree's X
servers, color depth can only be changed by exiting from the X server
and restarting it with a different color depth option.
DA>
DA> Donald Arseneau as...@triumf.ca
DA>
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Robert Heller
In a message on Sun, 22 Aug 2004 20:33:09 -0500, wrote :
"WL> Victor Wagner wrote:
"WL> > ...
"WL> > I believe that Windows is not a most important platform for Tcl/Tk.
"WL> > ...
"WL>
"WL> Jeff can correct me if I'm wrong, but last I heard the Windows downloads
"WL> and usage out weighed the other platforms.
This might be misleading, if you are counting downloads from
sourceforge or ActiveState. Most *Linux* users don't *need* to
download Tcl/Tk, since it is bundled with virtually ALL Linux distros.
"WL>
"WL> That being said, Tcl/Tk appeal is that you can write an application and
"WL> move it to another platform with little or no work (assuming your
"WL> application is written correctly and is not platform specific -- like
"WL> editing the registry on Windows or configuration files on *nix).
"WL>
"WL> --
"WL> +--------------------------------+---------------------------------------+
"WL> | Gerald W. Lester | "The man who fights for his ideals is |
"WL> | Gerald...@cox.net | the man who is alive." -- Cervantes |
"WL> +--------------------------------+---------------------------------------+
"WL>
Donal K. Fellows
> 1 - Add tk_chooseFont command
Good idea, and a formal proposal is in progress. (TIP#213)
> 2 - Add tk_choosePrinter command
Requires the rest of a printing infrastructure to be useful, and so a
very large job. (Plus, have you any idea just how complex a non-CUPS
UNIX printer configuration is? Scary stuff!)
> 3 - Add combobox widget
Doesn't the Tile project have one of these?
http://tktable.sf.net/tile/
> 4 - Add tree control widget
If only tktreectrl's API wasn't quite so funky...
> 5 - Add notebook/tab widget
> 6 - Add progressbar widget
The Tile project *definitely* has these. (If only the WinXP native
progressbar wasn't so awful for actually seeing anything change, but
that's hardly our fault. Blame Microsoft...)
> 7 - Add toolbar widget
TIP#125 addresses this, but there are a number of non-trivial aspects on
some platforms. If you don't want tear-offs (a feature that some people
seem to love, and others just despise) then you can do it pretty well
right now. The Tile demo illustrates this.
(Is there anything in tklib that makes setting this sort of thing up
easier to do?)
> 8 - Add statusbar widget
I've never needed one; the [label] has quite sufficient tricks in this
area for my apps. OTOH, if someone did new [dialogtoplevel] and
[applicationtoplevel] megawidgets which included a lot of the
pre-attached bits and pieces that people expect, that'd be really neat.
They could be done using scripts of course.
If anyone does this, please make the window title and iconname into
things you set with [$w configure]!
> 9 - Enhance the *nix widgets to look more GTK2-like, or at least more
> sharp/modern.
Yet again, the Tile project... :^)
> 10- Enhance listbox widget to support multiple columns
The problem with doing this is that it makes the data model much more
complex to work with. But if someone comes up with a sensible API for
making it happen, coding it up shouldn't be too big a challenge.
> 11- Enhance button widget to support "flat" style
It already does. We're ahead of you on this one! :^D
> 12- Rename tk_getOpenFile to tk_chooseFile
> 13- Rename tk_optionMenu to optionMenu
> 14- Rename tk_setPalette to setPalette
> 15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to focusNext,
> focusPrev and focusFollowsMouse.
I think I'll just respectfully disagree with you here; the pain of
altering an API name and getting everyone to switch to the new name
(published documentation/books are the biggest problems) exceeds the
likely benefits. FWIW, the naming is the way it is with these commands
because they are implemented (on some platforms) using procedures
instead of directly in C (back in the days before *real* namespaces.)
Tcl and Tk have quite a history; sometimes that's led us into
non-optimal design decisions that it isn't worthwhile backing out of...
> - I thought of asking to add the excellent tktable widget to the Tk core but
> tables/grids tend to be a personal preference for many folks and Jeff does a
> fantastic job of developing/supporting it as an extension so it might be
> best to leave out of the Tk core for now.
What counts as "in the core" is an interesting topic in itself. I'll try
to leave that inevitable thread to its own devices though... ;^)
Anyway, thanks for your input. It is *very* appreciated, and in a number
of cases validates things that are going on anyway. :^)
Donal.
Robert Seeger
model doesn't work? I can't think of one off the top of my head.
Rob Seeger
WL
Robert Seeger <rob...@rkseeger.net> wrote:
>
>Victor Wagner wrote:
>
>> Donal K. Fellows <donal.k...@man.ac.uk> wrote:
>>
>> : For what it's worth, the current most-common way of handling this thing
>> : is to use separate "New" and "Save As..." items on the menu. This
>> : transforms things into a more document-centric view, and (along with the
>>
>> Unfortunately, not all files, which application wants to open, are
>> documents. Document-centric model is powerful enough for GUI apps intended to be
>> used by infants and housewives, but sometimes we just want some more flexibility.
Gee, I must be an infant housewife, and not a real,
hardcore computer user...
>Can you give an example of a situation where the Open/New/Save/SaveAs
>model doesn't work? I can't think of one off the top of my head.
Some graphic manipulation programs have a "Open As" menu
item. It's essentially a shortcut for Open and an
immediate Save As.
A variation of that is "Open As New" which opens an
existing file as if it is a ``template:'' the file name
is set to Untitled, accelerator+s will pop up a save
dialogue prompt, etc. I've also seen this as "New ____
using..."
Both helps the user make incremental changes to an existing
file without accidentally changing the original. Some
software has an explicit ``template'' file type/format
(word, OO, etc), while classic MacOS seems to treat it
as metadata (the template checkbox in the File Info
dialogue box).
WL
--
real mail: wliao at sdf loSnPesAtarM org
(remove the uppercase letters...)
USCode
>
> Anyway, thanks for your input. It is *very* appreciated, and in a number
> of cases validates things that are going on anyway. :^)
>
> Donal.
Thanks for responding to my post Donal! Sounds like things are moving ahead
nicely.
One clarification though. In my original post I used the term "rename" for
some commands and perhaps that was too strong of a term. Perhaps we could
just add alternate command names for those that provide more consistency,
but retain the old commands for backwards compatibility? Just a thought.
Darren New
> How large is percent of your own program among those you use every day
> in the development process?
Not many.
>>You're not supposed to do that. You're supposed to use the right
>>interfaces to drive the program, instead of pretending to type at them.
>
> O! You've found an exact word. I'm "not supposed to". This is thing which
> annoys me most. I'm not supposed to do that, I'm not supposed to do
> this.
Well, if you want to drive a GUI program, use the appropriate interface
to do so, is all. If you want to drive a text program, it's not that
hard. It's not so much really that you're "supposed to" use use the
right interfaces, as much as that there *are* interfaces that work, and
they're available to anyone who wants them, and you're complaining that
the interfaces designed for textual UNIX terminals doesn't work on
Windows GUI apps. It's as if I complained I couldn't get Expect to work
without PTYs on my Unix box, you'd say "No, you're supposed to use PTYs."
> I'm supposed to seat at the very same computer program runs at.
Uh, no? I spend a lot of time logged into Windows servers at the co-lo
or logged into my work machine from home.
> And if I purcashe very expensive program which allows not to do this,
> most windows applications break, and even MS Office requires additional
> tools to be downloaded to work properly in terminal server setup.
Not in my experience.
> BTW, we are talking about development. If I'm not supposed to feed
> program with input automatically, how the hell I would TEST it?
You *can* feed it input automatically. There are a number of Windows
programs that let you do that. You apparently just don't know about them.
What you're really complaining is not that Windows is a bad development
environment, but something about GUI programs. Is it any easier to use
Expect to run a GUI program under X than it is under Windows?
> But how? There is no "Paste" button in Windows.
Right click where you want to paste, and pick "paste" off the menu that
pops up. Or bind the middle mouse button to "paste". Either way.
> No, it is not a problem. Typically, you cannot log in remotely in
> Windows at all. You have to purcashe special license.
Here, you're just mistaken.
Andreas Leitgeb
> Can you give an example of a situation where the Open/New/Save/SaveAs
> model doesn't work? I can't think of one off the top of my head.
If you had read his article till end, you'd have noticed that
he gave even a few examples.
It usually boils down to files that are not user's main focus,
but necessary, anyway. e.g. log-files for which the user doesn't
necessarily care if he wants to save it to a new file, or append
it to an existing one. At least, this distinction doesn't always
justify two separate buttons/menuentries, like one for "append"
and one for "new".
I wouldn't say that Document-centric apps are just for computer-
illiterates (macho-ism removed), but I surely understand demand
for something outside this pattern.
Especially if it seems so easy to get to, principially.
Sektor van Skijlen
> Sektor van Skijlen wrote:
>> Since I mentioned Qt and its getSaveFileName, one more thing, by the way. This
>> function has also a boolean option deciding about automatic resolving
>> symlinks. When this option is on (by default), any symbolic links to
>> directories are replaced with their targets. If off - they are treated as
>> regular directories.
> Are you talking about resolving the resulting file's symlinks or the
> treatment of symbolic links (to directories) as (special) files instead
> of directories? If the first, just [file normalize] the output. If the
> second, well, perhaps that's something someone could add.
Hmm... I am not clear on any of given alternatives, so I'm going to try to
explain it more clearly.
Let's say, I have such a directory:
/usr/home/jsmith/resources/elt
and I have a symbolic link:
/etl
which points to this directory.
I open the tk_getOpenFile dialog box. I enter the /elt directory and choose
some file (let's name it main.rc). I'd expect that this command return me
/etl/main.rc, however it returns /usr/home/jsmith/resources/elt/main.rc
Looxlike this link is being resolved "on the fly", that is, if I choose /etl
directory, it directly moves me into this /usr/home... etc.
I need an option, which will make this dialog treating symlinks as regular
directories.
> (It'd be a
> UNIX-only feature, which means that it's open to anyone who can hack a
> Tcl script; the file you are looking for in your friendly local CVS
> checkout is tk/library/tkfbox.tcl (and tk/library/xmfbox.tcl if you're
> feeling energetic!) But if we were going to port those changes back to
> the core, I'd love to hear about some use cases for the feature...
Huh... probably it would be also nice to treat Windows links (.lnk files) as
if they were directories, returning paths containing them... however paths
with "something.lnk" would look strange and it wouldn't be convenient to use
name "without extension" instead, because you can create x.lnk file and x
directory as separate entries.
However, symlinks are rather filesystem-specific feature rather than system
specific - a system can just either support them naturally or not (for example
the ClearCase's VFS uses symbolic links and this link looks like a symbolic
link on Solaris, but on Windows it looks like a regular directory; the same is
with Unix filesystems visible on Windows thru Smb).
In this case, this option can be said it has no effect on systems, which do
not support symbolic links.
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
Donal K. Fellows
> I open the tk_getOpenFile dialog box. I enter the /elt directory and choose
> some file (let's name it main.rc). I'd expect that this command return me
> /etl/main.rc, however it returns /usr/home/jsmith/resources/elt/main.rc
>
> Looxlike this link is being resolved "on the fly", that is, if I choose /etl
> directory, it directly moves me into this /usr/home... etc.
OK, something is doing [file normalize] and you don't like it that way.
> Huh... probably it would be also nice to treat Windows links (.lnk files) as
> if they were directories, returning paths containing them... however paths
> with "something.lnk" would look strange and it wouldn't be convenient to use
> name "without extension" instead, because you can create x.lnk file and x
> directory as separate entries.
Actually Win has real links as well, but they're NT/NTFS only.
Donal.
Darren New
> Actually Win has real links as well, but they're NT/NTFS only.
*And* symlinks, which .lnk files are not. And all kinds of other nifty
links like "offline links", and a whole general infrastructure for
adding new kinds of symbolic links that invoke programs when you try to
open them. :-)
Victor Wagner
> Can you give an example of a situation where the Open/New/Save/SaveAs
> model doesn't work? I can't think of one off the top of my head.
I've given two of them at the end of posting
1. Configuration file. If it already exists (for example, from previous
installation) it will be used. If it doesn't exist, it will be created
and filled with default values.
2. Log file. If it does exist, program would write to the end. If it
doesn't exist, program would create it.
3. some database file, like address book. Problem is that user doesn't
specially open address book. He just sets up name of addressbook file in
the configuration dialog. And expect that he would be allowed to create
new address book without additional question "open existing or select
new"
--
Though I'll admit readability suffers slightly...
-- Larry Wall in <29...@jato.Jpl.Nasa.Gov>
Victor Wagner
> I wouldn't say that Document-centric apps are just for computer-
> illiterates (macho-ism removed), but I surely understand demand
> for something outside this pattern.
> Especially if it seems so easy to get to, principially.
It turns to be two lines for Unix and 10-15 for Windows (just because
for Windows it is C, not Tcl code).
Convinced with Donal's arguments I've done it as option
-allownonexistent for tk_getOpenFile and not -confirmoverwrite for
tk_getSaveFile. In all situations where I really need this
functionality, this is really choosing a file to open (as something
supplemental), not saving, so ability to open nonexistent file seems
more natural and less error-prone than ability to silently overwrite
(even with explicit consent of programmer) file when saving.
Unfortunately we got some connection problem in our office this evening,
and patch is left on my computer there.
I'll publish this patch on sf.net when I'll test it on Windows.
Unfortunately, I don't have any Mac handy, and I cannot provide an
implementation for either Macos classic or Macos X.
--
And Bruce is effectively building BruceIX
-- Alan Cox
Victor Wagner
> What you're really complaining is not that Windows is a bad development
> environment, but something about GUI programs. Is it any easier to use
I'm really complaining that Windows has quite a poor user interface.
And if I do development, it means that I spend whole day at the computer
and do something with it.
> Expect to run a GUI program under X than it is under Windows?
In Unix I don't NEED GUI. Almost everything except image editing
(for which GUI is natural) is possible to be done with text based tools.
On Windows most trivial tasks require some GUI apps.
Moreover, Windows comes barebones. Everything started from usable text
editor and ending with compiler have to be purchashed separately.
Typical Unix distribution, such as Solaris (if we count Software
Companion disk) includes almost everything.
> Right click where you want to paste, and pick "paste" off the menu that
> pops up. Or bind the middle mouse button to "paste". Either way.
Doesn't work in half of situations. For instance, doesn't work when I'm
editing shortcut on the desktop.
--
I'm telling you that the kernel is stable not because it's a kernel,
but because I refuse to listen to arguments like this.
-- Linus Torvalds
Darren New
> On Windows most trivial tasks require some GUI apps.
Err, not really. Not for developing.
> Moreover, Windows comes barebones. Everything started from usable text
> editor and ending with compiler have to be purchashed separately.
Or downloaded for free.
> Doesn't work in half of situations. For instance, doesn't work when I'm
> editing shortcut on the desktop.
Funny. I just tried it and it works for me.
Robert Heller
In a message on Mon, 23 Aug 2004 17:54:25 +0000 (UTC), wrote :
VW> Darren New <dn...@san.rr.com> wrote:
VW> > What you're really complaining is not that Windows is a bad development
VW> > environment, but something about GUI programs. Is it any easier to use
VW>
VW>
VW> I'm really complaining that Windows has quite a poor user interface.
VW> And if I do development, it means that I spend whole day at the computer
VW> and do something with it.
VW>
A GUI-only environment (which MS-Windows esentually is, despite the 'DOS
Window'), is inherently limited -- 'What You See Is All You Get'.
VW>
VW>
VW>
VW> > Expect to run a GUI program under X than it is under Windows?
VW>
VW> In Unix I don't NEED GUI. Almost everything except image editing
VW> (for which GUI is natural) is possible to be done with text based tools.
And with ImageMagick, even image editing is doable with text based
tools, strange as that sounds -- you can do all sorts of fun & games
with convert & friends. Such as make a batch of icons for a directory
full of random images.
VW>
VW> On Windows most trivial tasks require some GUI apps.
VW> Moreover, Windows comes barebones. Everything started from usable text
VW> editor and ending with compiler have to be purchashed separately.
VW>
VW> Typical Unix distribution, such as Solaris (if we count Software
VW> Companion disk) includes almost everything.
And virtually *all* Linux distros do include *everything* (from text
editors, to all flavors of compilers, build tools, scripting, server
daemons, etc.). About the *only* Linux distro that does NOT include
everything is Tom's Boot, for obvious reasons.
VW>
VW>
VW>
VW> > Right click where you want to paste, and pick "paste" off the menu that
VW> > pops up. Or bind the middle mouse button to "paste". Either way.
VW>
VW> Doesn't work in half of situations. For instance, doesn't work when I'm
VW> editing shortcut on the desktop.
VW>
VW>
VW> --
VW> I'm telling you that the kernel is stable not because it's a kernel,
VW> but because I refuse to listen to arguments like this.
VW> -- Linus Torvalds
VW>
lvi...@gmail.com
According to USCode <usc...@dontspam.me>:
:IMHO I
:feel there are some things, in the Tk toolkit in particular, that could be
:improved and which would make Tcl/Tk attractive to a wider range of
:developers (particularly Windows developers as they're the biggest crowd out
:there), hopefully bringing others into the Tcl/Tk fold.
If there are any developers in the community looking for a way to
contribute , perhaps a TIP and code contribution in one of the areas
metioned might be your means to fame, fortune, riches, power, and glory!
:TK
:1 - Add tk_chooseFont command
:2 - Add tk_choosePrinter command
:3 - Add combobox widget
:4 - Add tree control widget
:5 - Add notebook/tab widget
:6 - Add progressbar widget
:7 - Add toolbar widget
:8 - Add statusbar widget
:9 - Enhance the *nix widgets to look more GTK2-like, or at least more
:sharp/modern.
:10- Enhance listbox widget to support multiple columns
:11- Enhance button widget to support "flat" style
:12- Rename tk_getOpenFile to tk_chooseFile
:13- Rename tk_optionMenu to optionMenu
:14- Rename tk_setPalette to setPalette
:15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to focusNext,
:focusPrev and focusFollowsMouse.
:
:TCL
:16 - Rename concat to lconcat
:17 - Rename join to ljoin
:18 - Rename split to lsplit
:
:MISC
:- I thought of asking to add the excellent tktable widget to the Tk core but
:tables/grids tend to be a personal preference for many folks and Jeff does a
:fantastic job of developing/supporting it as an extension so it might be
:best to leave out of the Tk core for now.
:
:- Details -
:TK
:1,2 - Windows and OS X offer native versions of Font and Printer choosers
:which should be utilized. I believe Donal is working on a tk_chooseFont
:command right now. A tk_choosePrinter would be nice as well but understand
:there are issues on *nix. For *nix, a TCL/TK version of tk_chooseFont could
:be provided, not sure what to do about tk_choosePrinter on *nix (CUPS?) but
:it's a must-have to Windows and OS X developers.
Certainly we already have one or more extensions that are platform specific
so perhaps if you were to write up a TIP to propose a tk_choosePrinter for
the platform(s) of choice for you, you could get it in there.
As for *nix - well, I see apps with printer choosers every now and then...
I believe things like FrameMaker or some such thing. Generally, they
seem to use either one of the printer status commands, or some /etc
file, etc. Since there is no truly cross platform solution, coming
up with a a cross-platform API seems like the next best thing; then
let people on the various platforms implement the code as need be.
:3 (Add combobox widget) - This is a must-have and is supported natively on Windows and OS X. I
:believe there are some other excellent Tcl/Tk comboboxes out there that
:could be used for *nix.
Certainly there are - the reason there isn't one in Tk to date seems to be
that no one has wanted it badly enough to write up the TIP and do the work
necessary to get it in. In fact, that's the reason for nearly all the
things you list. As soon as someone wants it enough to work on it, I
suspect things will move along rather quickly. There's still time for
all that fame and glory, kids!
:9 - The *nix widgets all need a facelift to look more modern and sharp. I
:think others have already done some work in this area.
However, I _disagree_ that the widgets should look more like gTk. Remember -
Unix has a variety of desktops, so picking one to use just alienates everyone
else on the other platforms. I can certainly see small tweaks being added,
but I myself would rather not see any major look and feel changes unless
the change centered around a system whereby one could somehow define
the entire look and feel via maybe options or a bit of callback type code
or something ... some sort of configuration layer that would let one
craft FLTK, gTk, KDE, Motif, OpenWindows, Athena, NeXTStep or whatever
other look and feel one wanted. And I don't see anyone with that
much time available...
:12,13,14,15 - For consistency with other related commands, these commands
:could be renamed as suggested. The existing commands should be kept around
:for backwards compatibility, deprecated. To me there didnt seem to be any
:consistency as to when "tk_" was used or not?
I don't know that I particularly like the proffered name changes. Perhaps
it would be better to make them commands within the tk:: name space
instead. As to the specific names, let the naming lawyers fight till
the death on the proper naming of the widgets... a few less lawyers
probably wouldn't be a bad thing <wink>...
:TCL
:16,17,18 - Seems like all the other commands that work on Lists start with
:an 'l' (lowercase L) except these. The existing commands should be kept
:around for backwards compatibility, deprecated.
Frankly, I'd rather see all the l* commands moved into a list:: namespace.
the names just seem awkward to me.
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Jeff Hobbs
> Dnia Sat, 21 Aug 2004 22:09:45 -0700, USCode skrobie:
>>8 - Add statusbar widget
>
A statusbar is a lot more than that. It often has multiple status
fields. For example, in this mozilla edit window, I have a field of
images (to launch some other Mozilla component), a standard status
field, some other status field (empty), an image which indicates
connectivity status, and the resize control.
> and rename open to fopen, close to fclose and so on (or even make them the
> subcommand of "file"). I don't think it is possible to "rename" something,
See http://www.tcl.tk/cgi-bin/tct/tip/208.html. These do not belong
as subcommands of 'file' (or rather, at least close doesn't).
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Jeff Hobbs
>> 3 - Add combobox widget
>
> Doesn't the Tile project have one of these?
> http://tktable.sf.net/tile/
Yes, a nice one. It still has the issue (on Windows) that when
the toplevel drops down, the host toplevel loses focus. Note
that this doesn't happen with the win32 combobox control. I'm
not 100% sure how they manage this trick (I have a few guesses,
but am not sure).
>> 4 - Add tree control widget
>
> If only tktreectrl's API wasn't quite so funky...
I think this widget should be tracked for 8.5, but I agree that
an API review should be done on it. It should be compared
against the canvas widget and other tree implementations.
>> 8 - Add statusbar widget
>
> I've never needed one; the [label] has quite sufficient tricks in this
> area for my apps. OTOH, if someone did new [dialogtoplevel] and
Note that you have to be careful to limit a 'label' when used
as a status widget to not have it suck up all space (IOW, give
it -width 1 in a space where the gm can expand it).
>> 10- Enhance listbox widget to support multiple columns
>
> The problem with doing this is that it makes the data model much more
> complex to work with. But if someone comes up with a sensible API for
> making it happen, coding it up shouldn't be too big a challenge.
IMO this is a separate widget.
Ralf Fassel
| >> 10- Enhance listbox widget to support multiple columns
| > The problem with doing this is that it makes the data model much more
| > complex to work with. But if someone comes up with a sensible API for
| > making it happen, coding it up shouldn't be too big a challenge.
|
| IMO this is a separate widget.
I'd like to mention Csaba Nemethi's tablelist here: an excellent
example for a multi-column listbox with a very useful API.
http://wiki.tcl.tk/5527
http://www.nemethi.de/
R'
Donal K. Fellows
> some sort of configuration layer that would let one
> craft FLTK, gTk, KDE, Motif, OpenWindows, Athena, NeXTStep or whatever
> other look and feel one wanted.
Two comments:
a) That's what the Tile stuff is all about, and it is *good*.
b) Someone wants the Athena L&F? What are they smoking?
Donal.
Donal K. Fellows
> A statusbar is a lot more than that. It often has multiple status
> fields. For example, in this mozilla edit window, I have a field of
> images (to launch some other Mozilla component), a standard status
> field, some other status field (empty), an image which indicates
> connectivity status, and the resize control.
The empty field is a progress bar.
I've also seen applications that don't take input but which still have a
status bar that indicates the status of all the various lock keys (why,
I really couldn't say). IMO, the right things to put on status bars are
application-specific, and so we can't really solve all the problems in
this area in one fell swoop...
Donal.
lvi...@gmail.com
According to Victor Wagner <vi...@45.free.net>:
:Trying to set up development priorities looking to new users.
:Development priorities should be set to achieve technological
:superiority.
Now, in my experience, the term "development priorities" applied
to organized (at least semi-organized) groups who needed to
determine where the focus of work should apply.
Note that for Tcl, this isn't really a relevant term. There is no
limited resource group doing development along the lines of
'what is most important'. The evolution of tcl depends on a rag-tag
team of cowboy (and girl...) programmers out to improve their corner
of the world (with the occasional appearance of the benevolent
developer who programs new features purely from an altruistic point
of view).
So if someone wants a feature badly enough, they brain storm about
how they want something to work, then either start coding, or start
emailing solititations to coders for assistance.
A thousand - nay, a million or more ! - points of light
from these developers can exist simultaneously. Of course,
the more there are, the more likely two or more will be working on
overlapping or conflicting evolutionary (or even revolutionary)
changes, and so it becomes even more critical that, as early in the
process as possible, a TIP be formulated and submitted so that
people have the possibility of knowing what is being considered,
and provide feedback.
lvi...@gmail.com
:alike for my last project.
:May be I should polish this code and submit it to something like tklib.
Victor, that would be wonderful. I suspect that there are many people
out there who have developed useful procs and entire modules of useful
code that, with some doc and test cases, would make wonderful add-ons
to tklib or tcllib .
USCode
>
> A statusbar is a lot more than that. It often has multiple status
> fields. For example, in this mozilla edit window, I have a field of
> images (to launch some other Mozilla component), a standard status
> field, some other status field (empty), an image which indicates
> connectivity status, and the resize control.
>
want using existing widgets and a frame, couldn't we? Frames within frames
with different reliefs, buttons and images within those frames, etc.? I'll
have to do some experimentation, others probably have this all figured out!
If we can achieve status bars, toolsbars, etc. without adding additional
widgets and further enlarging Tk... isn't that a good thing?
> > and rename open to fopen, close to fclose and so on (or even make them
the
> > subcommand of "file"). I don't think it is possible to "rename"
something,
>
> See http://www.tcl.tk/cgi-bin/tct/tip/208.html. These do not belong
> as subcommands of 'file' (or rather, at least close doesn't).
>
This is a great TIP! The fewer commands the better IMHO and the chan
command keeps the language clean and flexible/expandable.
lvi...@gmail.com
According to Donal K. Fellows <donal.k...@man.ac.uk>:
:lvi...@gmail.com wrote:
:> some sort of configuration layer that would let one
:> craft FLTK, gTk, KDE, Motif, OpenWindows, Athena, NeXTStep or whatever
:> other look and feel one wanted.
:
:Two comments:
: a) That's what the Tile stuff is all about, and it is *good*.
Wonderful! That's much more critical than making Tk look like
some particular widget set - because the look du jour is going
to evolve over time, and given the appropriate layer, tk can
evolve with them with hopefully minimal pain.
: b) Someone wants the Athena L&F? What are they smoking?
Well, I've not heard anyone stop by asking for it - but I HAVE
heard people lament over the loss of 'the good old days' when
GUIs were much lighter in weight, etc.
Me - I just wish that look and feel would get past the flash and back
to substance.
Jeff Hobbs
> b) Someone wants the Athena L&F? What are they smoking?
This is essentially what you get with a PocketPC nowadays, so
it's not unreasonable.
Victor Wagner
>> Actually Win has real links as well, but they're NT/NTFS only.
> *And* symlinks, which .lnk files are not. And all kinds of other nifty
As far as I can understand, it does not. This strange thing which is
positioned as equivalent of symlink on W2K/WXP really works on
directories only.
> links like "offline links", and a whole general infrastructure for
> adding new kinds of symbolic links that invoke programs when you try to
> open them. :-)
Links are not for invoking programs. Links are for accessing files.
There are many reason for accessing files, and very few of them result
in invoking new program. Idea that accessing file means invoking program
on it is from document-centric model.
In real life you ten times more often access file from program which is
already running. For example in Tcl you typically start one script and
source from it (either explicitely or using autoloading) dozen of
others, and load couple of dynamic libraries.
As far as I can understang, LoadLibrary system call doesn't support both
.lnk files and NTFS 5.0 symlinks, when on Unix shared objects almost
never accessed via their hard links, because they include too many
digits of version number in them. Most programs specify just library.so
or library.so.major_version, and some system utility, often named
ldconfig takes care to create symlink from library.so.major.minor to
library.so.major and library.so.
--
Vini, vidi, Linux!
-- Unknown source
Victor Wagner
> VW> I'm really complaining that Windows has quite a poor user interface.
> VW> And if I do development, it means that I spend whole day at the computer
> VW> and do something with it.
> VW>
> A GUI-only environment (which MS-Windows esentually is, despite the 'DOS
> Window'), is inherently limited -- 'What You See Is All You Get'.
I think that at least since NT 4.0 (never worked with NT 3.x) there is
HUGE difference between "NT Console" in real Windows system, and "DOS
window" in Win9x, which is essentially GUI on top of DOS 8.0.
Moreover, there are also "services"
> And with ImageMagick, even image editing is doable with text based
> tools, strange as that sounds -- you can do all sorts of fun & games
> with convert & friends. Such as make a batch of icons for a directory
> full of random images.
I prefer netpbm, or GIMP in batch mode.
With NetPBM you can split your image transformation into small and
simple to understand part and name each of them with command name.
Since tk 8.4.7 where photo images can be created from PPM data without
creating intermediate file, using netpbm in conjunction with Tcl/tk
script is piece of cake.
GIMP can be just programmed on Tcl, although I typically don't keep
GIMP-tcl installed and use GIMP's builtin Scheme to program batch files
for GIMP.
> VW> Typical Unix distribution, such as Solaris (if we count Software
> VW> Companion disk) includes almost everything.
> And virtually *all* Linux distros do include *everything* (from text
And FreeBSD has ports collection which includes *everything* too.
>
--
MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development.
-- dmeg...@aix1.uottawa.ca
Victor Wagner
:>>8 - Add statusbar widget
:>
:> I think "label" with "-textvariable" quite well matches the needs.
: A statusbar is a lot more than that. It often has multiple status
: fields. For example, in this mozilla edit window, I have a field of
: images (to launch some other Mozilla component), a standard status
: field, some other status field (empty), an image which indicates
: connectivity status, and the resize control.
But, most of these things are application-specific. So I'm not sure that
standard statusbar widget would be of any use. It would be just another
container widget (i.e. frame) packed or gridded at the bottom of main
window.
--
Darren New
> Links are not for invoking programs. Links are for accessing files.
> There are many reason for accessing files, and very few of them result
> in invoking new program. Idea that accessing file means invoking program
> on it is from document-centric model.
No, it means you can do things like restore the file from where you
offloaded it onto your automated tape library automatically when a
program tries to open it.
This has nothing to do with editing or displaying the file, any more
than something like setuid has.
Victor Wagner
> : b) Someone wants the Athena L&F? What are they smoking?
> Well, I've not heard anyone stop by asking for it - but I HAVE
> heard people lament over the loss of 'the good old days' when
> GUIs were much lighter in weight, etc.
So, this is Athena weight and startup time they are whinning about, not
Athena look and feel.
Although I don't understand what is wrong with look and feel of, say gv,
or xfig which is most often used by me Athena programs.
> Me - I just wish that look and feel would get past the flash and back
> to substance.
I'm not sure that wish with Athena scheme would have comparable startup
time. There are many things to initalize even without tile...
--
Hey, if pi == 3, and three == 0, does that make pi == 0? :-)
-- Larry Wall in <1997110119...@wall.org>
Jeff Hobbs
> 2. Quite different directory layout. Most interesting problem is that
> Windows DO have statdard directories for such things as program code,
> configuration files and data files, and kindly places their names into
> environment. But some users for whatever reason expect program to broke
> this layout and put all the data files into its program directory. May
> be because so many 3rd-party programs do so.
With the LSB becoming more common, it actually has some notion
of where files should be placed. Of course, while the distros
are adhereing to this standard at varying levels, not many
general apps do that I know of.
> 4. Inter process communication. What do you use instead of send to debug
> on Windows?
IPC isn't the only way to debug. One nice thing about Tcl is
that the level of abstraction for IPC is so good that the exact
same code will work across platforms and provide a high level of
functionality. As for debugging, I think send got reintroduced
into Tk for 8.5 by Pat Thoyts (COM based), but one of my
favorite tricks is embedding tkcon into my apps (or starting
them from tkcon). I often add a switch as well that sets up a
comm port that I can connect to with TDK Inspector, which is
handy for general UI debugging.
> 5. System color scheme. Yes, Tk provides way to use system colors. But
> again it is platform specific. And Tk requires application to be
> restarted after system color scheme was changed.
Yes, I consider that a bug, but it really can't be resolved
until we have named colors in 8.5, because while the underlying
color for "SystemWindow" may change, there is currently no way
to propagate this event to all windows that may be using that
color.
USCode
follow up with some *comments on my original list:
> 1 - Add tk_chooseFont command
*Currently being addressed by TIP#213.
> 2 - Add tk_choosePrinter command
*RETRACTED. Lots of cross-platform issues here, nothing is going to happen
anytime soon.
> 3 - Add combobox widget
*Would be a handy and popular addition to the core, native versions provided
by Windows and OS X, lots of other fine pure Tcl versions exists for
platforms w/o native support.
> 4 - Add tree control widget
*With some API work, the excellent treectrl would be a nice, flexible
addition and would also provide a multiple-column listbox in the same
widget.
> 5 - Add notebook/tab widget
Would be a handy and popular addition to the core, native versions provided
by Windows and OS X, other pure Tcl versions exists for platforms w/o native
support.
> 6 - Add progressbar widget
*RETRACTED. This can be easily simulated by existing widgets without
bloating the core.
> 7 - Add toolbar widget
*RETRACTED. This can be easily simulated by existing widgets without
bloating the core.
> 8 - Add statusbar widget
*RETRACTED. This can be easily simulated by existing widgets without
bloating the core.
> 9 - Enhance the *nix widgets to look more GTK2-like, or at least more
> sharp/modern.
*I believe there in concensus on this but how to achieve it is the
challenge.
> 10- Enhance listbox widget to support multiple columns
*RETRACTED. Would be nicely addressed by the addition of the treectrl
without further bloating the core.
> 11- Enhance button widget to support "flat" style
*RETRACTED. Already covered by -relief Flat -overrelief raised options. =)
> 12- Rename tk_getOpenFile to tk_chooseFile
*RETRACTED. Current naming scheme makes sense.
> 13- Rename tk_optionMenu to optionMenu
*RETRACTED. This is a pure Tcl/Tk widget, thus the tk_ prefix.
> 14- Rename tk_setPalette to setPalette
> 15- Rename tk_focusNext, tk_focusPrev and tk_focusFollowsMouse to
> focusNext,
> focusPrev and focusFollowsMouse.
*RETRACTED. These also appear to be pure Tcl/Tk commands, hence the tk_
prefix.
> TCL
> 16 - Rename concat to lconcat
> 17 - Rename join to ljoin
> 18 - Rename split to lsplit
*These commands all also work on strings, not just lists, so these names
make sense.
> MISC
> - I thought of asking to add the excellent tktable widget to the Tk core
> but
> tables/grids tend to be a personal preference for many folks and Jeff does
> a
> fantastic job of developing/supporting it as an extension so it might be
> best to leave out of the Tk core for now.
*Per Jeff, this is already targetting for the core.
lvi...@gmail.com
According to USCode <usc...@dontspam.me>:
:After reading all the comments, digging more into Tcl/Tk, I thought I'd
:> 2 - Add tk_choosePrinter command
:*RETRACTED. Lots of cross-platform issues here, nothing is going to happen
:anytime soon.
However, this does not mean that it would be useless for someone who
needs a cross-platform solution to begin discussing and documenting
requirements, etc.
:> 3 - Add combobox widget
:*Would be a handy and popular addition to the core, native versions provided
:by Windows and OS X, lots of other fine pure Tcl versions exists for
:platforms w/o native support.
Again, having a set of cross platform API requirements would be a useful
contribution from the community.
:> 4 - Add tree control widget
:*With some API work, the excellent treectrl would be a nice, flexible
:addition and would also provide a multiple-column listbox in the same
:widget.
see above...
:> 5 - Add notebook/tab widget
:Would be a handy and popular addition to the core, native versions provided
:by Windows and OS X, other pure Tcl versions exists for platforms w/o native
:support.
see above...
:> 6 - Add progressbar widget
:*RETRACTED. This can be easily simulated by existing widgets without
:bloating the core.
This would be a useful contribution to tklib.
:> 7 - Add toolbar widget
:*RETRACTED. This can be easily simulated by existing widgets without
:bloating the core.
This would be a useful contribution to tklib.
:> 8 - Add statusbar widget
:*RETRACTED. This can be easily simulated by existing widgets without
:bloating the core.
This would be a useful contribution to tklib.
Donal K. Fellows
> According to USCode <usc...@dontspam.me>:
[...]
> :> 3 - Add combobox widget
> :*Would be a handy and popular addition to the core, native versions provided
> :by Windows and OS X, lots of other fine pure Tcl versions exists for
> :platforms w/o native support.
>
> Again, having a set of cross platform API requirements would be a useful
> contribution from the community.
There is already a solution in Tile which has a high likelihood of going
into the core. Several platform-native themes are part of Tile.
> :> 6 - Add progressbar widget
> :*RETRACTED. This can be easily simulated by existing widgets without
> :bloating the core.
>
> This would be a useful contribution to tklib.
There is already a solution in Tile which has a high likelihood of going
into the core. (Correct display requires platform-specific rendering,
but otherwise it is trivial.)
> :> 7 - Add toolbar widget
> :*RETRACTED. This can be easily simulated by existing widgets without
> :bloating the core.
>
> This would be a useful contribution to tklib.
There are aspects of this that are the subject of current draft TIPs,
other aspects which appear to be part of Tile too (have you tried it
yet, Larry?) Given that, I do not know how much work would need to be
done inside tklib to make this happen.
Donal.
Larry W. Virden
TIPs, other aspects which appear to be part of Tile too (have you tried
it yet, Larry?)
Not yet Donal. I've seen the traffic on it. But given my limited Tk
experience, I hadn't taken on the task of learning about Tile.
But, if the solutions are in process, then that sounds great to me!
USCode
[snip]
>
> There is already a solution in Tile which has a high likelihood of going
> into the core. Several platform-native themes are part of Tile.
>
Not sure if I 100% know all that Tile give us ... but from what I
understand, Tcl/Tk applications will be themable seperately from the current
OS theme, correct? That might be handy for some applications but it seems
to me that most user's want all their applications to match the current look
and feel of all their other applications and the current OS theme...
Given that, might Tile be better remaining as a seperate extension and not
as part of the Tk core?
Many of us prefer to package and deliver our Tcl/Tk applications as single
executables (i.e. Freewrap and Starkits, etc.) and as I would have no use
for Tile theming seperate from the OS theming, it would be just added bloat
to my application.
Or am I confused as to what Tile is? Or am I maybe confused as to what
being part of the "core" means???
Thanks!
Bryan Oakley
> Not sure if I 100% know all that Tile give us ... but from what I
> understand, Tcl/Tk applications will be themable seperately from the current
> OS theme, correct? That might be handy for some applications but it seems
> to me that most user's want all their applications to match the current look
> and feel of all their other applications and the current OS theme...
Correct
>
> Given that, might Tile be better remaining as a seperate extension and not
> as part of the Tk core?
>
Not necessarily. I'm tempted to say "no", but I'm sure there are people
who want the smallest possible tk even if that means they only get the
current look and feel on all platforms.
Right now tk can't "match the current look and feel" on all platforms.
At least, not without a lot of one-off work unique to each platform
(witness AquaTk). To reach that lofty goal we need something like tile.
Many apps may not choose to expose to the user the ability to switch
themes, but the app itself (if designed to work on multiple platforms)
needs the ability internally to switch to the theme that most closely
matches the platform on which it runs.
So, while a user may not need multiple themes, they certainly need a
distinct theme for their current platform.
> Many of us prefer to package and deliver our Tcl/Tk applications as single
> executables (i.e. Freewrap and Starkits, etc.) and as I would have no use
> for Tile theming seperate from the OS theming, it would be just added bloat
> to my application.
You will no doubt be free to remove all themes except the OS theme(s)
from your distribution. Given that in the current incarnation themes
take up only a couple K, it's arguably not much of a space savings.
USCode
"Bryan Oakley" <oak...@bardo.clearlight.com> wrote in
[snip]
>
> Not necessarily. I'm tempted to say "no", but I'm sure there are people
> who want the smallest possible tk even if that means they only get the
> current look and feel on all platforms.
>
> Right now tk can't "match the current look and feel" on all platforms. At
> least, not without a lot of one-off work unique to each platform (witness
> AquaTk). To reach that lofty goal we need something like tile. Many apps
> may not choose to expose to the user the ability to switch themes, but the
> app itself (if designed to work on multiple platforms) needs the ability
> internally to switch to the theme that most closely matches the platform
> on which it runs.
>
> So, while a user may not need multiple themes, they certainly need a
> distinct theme for their current platform.
>
>> Many of us prefer to package and deliver our Tcl/Tk applications as
>> single executables (i.e. Freewrap and Starkits, etc.) and as I would have
>> no use for Tile theming seperate from the OS theming, it would be just
>> added bloat to my application.
>
> You will no doubt be free to remove all themes except the OS theme(s) from
> your distribution. Given that in the current incarnation themes take up
> only a couple K, it's arguably not much of a space savings.
Thanks Bryan. But just to clarify; Suppose I deliver an application with a
theme which closely resembles the native theme for the given OS. However
the user then decides to change to some other OS theme ... my application
would still show the default theme as it has no knowledge of the OS theming
?
I guess the only way around that is, as you stated, to strictly use native
widgets for the given platform. Aren't most of the Tk widgets native
widgets these days anyways (on Windows and OSX) if they're available?
Bryan Oakley
>
> Thanks Bryan. But just to clarify; Suppose I deliver an application with a
> theme which closely resembles the native theme for the given OS. However
> the user then decides to change to some other OS theme ... my application
> would still show the default theme as it has no knowledge of the OS theming
> ?
I think the answer is "that depends". It is my understanding that some
of the windows themes will use native window API calls, so I'm guessing
on XP at least, if the user changes the theme the tk app will follow suit.
On *nix, that's another story. I'm not sure what the plan is there; the
tile demo shows it's at least conceptually possible to import external
themes. This is where we really need theming support; without tile
you're completely out of luck. With tile there's hope that most common
themes will be supported by tk.
Note that I'm making educated guesses here; I'm not involved in the
development of tile. I'm just a big cheerleader.
> I guess the only way around that is, as you stated, to strictly use native
> widgets for the given platform. Aren't most of the Tk widgets native
> widgets these days anyways (on Windows and OSX) if they're available?
I would say "some widgets" rather than "most widgets".
At this point I'm guessing my own personal implementation strategy will
be to use themes that use native widgets if at all possible. If that's
not possible, we'll probably ship whatever themes are available and let
the user pick.
USCode
>
> I think the answer is "that depends". It is my understanding that some of
> the windows themes will use native window API calls, so I'm guessing on XP
> at least, if the user changes the theme the tk app will follow suit.
>
> On *nix, that's another story. I'm not sure what the plan is there; the
> tile demo shows it's at least conceptually possible to import external
> themes. This is where we really need theming support; without tile you're
> completely out of luck. With tile there's hope that most common themes
> will be supported by tk.
>
> Note that I'm making educated guesses here; I'm not involved in the
> development of tile. I'm just a big cheerleader.
>
I think I'm starting to get it now... so essentially with tile, using the
native widgets IS a theme?
Bryan Oakley
>
> I think I'm starting to get it now... so essentially with tile, using the
> native widgets IS a theme?
>
>
Yes, there are platform-dependent themes that use native widgets. Look
at the information at http://tktable.sourceforge.net/tile/
USCode
"Bryan Oakley" <oak...@bardo.clearlight.com> wrote in
>
Bryan Oakley
> So would the OS X tile theme make TclTkAqua redundant?
>
I think the tile and/or TclTkAqua implementors will have to answer that
question.
USCode
has lots of precompiled extensions, etc. but the it sounds like they're both
ports of Tk to Aqua?
"Bryan Oakley" <oak...@bardo.clearlight.com> wrote in message
news:54t%c.8875$yp2....@newssvr30.news.prodigy.com...
Joe English
>USCode wrote:
>> Thanks Bryan. But just to clarify; Suppose I deliver an application with a
>> theme which closely resembles the native theme for the given OS. However
>> the user then decides to change to some other OS theme ... my application
>> would still show the default theme as it has no knowledge of the OS theming
>
That's absolutely correct! :-)
To clarify further: on Windows, the "xpnative" theme uses the XP
Visual Styles API if available and enabled, otherwise it falls
back to the "winnative" theme which uses older GDI routines
like DrawFrameControl(). The Tile widgets automatically adjust
to most desktop settings, including "XP" vs "Windows 98" style,
color schemes, and element sizes (the main exceptions being fonts
and screen depth).
On OSX, the "aqua" theme uses Apple's Appearance Manager API,
so it automatically adjusts to the user's selected desktop theme
here as well.
On Unix, we're still looking into it. This is pretty complicated,
since there's (at least!) Gnome, KDE, and CDE to think about.
>On *nix, that's another story. I'm not sure what the plan is there; the
>tile demo shows it's at least conceptually possible to import external
>themes. This is where we really need theming support; without tile
>you're completely out of luck. With tile there's hope that most common
>themes will be supported by tk.
If anyone has any particular Gnome or KDE themes they'd like to see
supported, please let me know -- I'd like to get a feel for what people
are looking for here.
--Joe English
USCode
>
> That's absolutely correct! :-)
>
> To clarify further: on Windows, the "xpnative" theme uses the XP
> Visual Styles API if available and enabled, otherwise it falls
> back to the "winnative" theme which uses older GDI routines
> like DrawFrameControl(). The Tile widgets automatically adjust
> to most desktop settings, including "XP" vs "Windows 98" style,
> color schemes, and element sizes (the main exceptions being fonts
> and screen depth).
>
> On OSX, the "aqua" theme uses Apple's Appearance Manager API,
> so it automatically adjusts to the user's selected desktop theme
> here as well.
>
> On Unix, we're still looking into it. This is pretty complicated,
> since there's (at least!) Gnome, KDE, and CDE to think about.
>
This sounds fantastic, thanks for all your efforts Joe and it definitely
sounds "core worthy"! ;-)
David N. Welton
> If anyone has any particular Gnome or KDE themes they'd like to see
> supported, please let me know -- I'd like to get a feel for what
> people are looking for here.
A good start would be:
whatever GTK themes Redhat, Suse and Debian default to, with Mandrake
and Gentoo thrown in for good measure. KDE would be an added bonus if
the licensing isn't a problem.
--
David N. Welton
Personal: http://dedasys.com/davidw/
Apache Tcl: http://tcl.apache.org/
Free Software: http://dedasys.com/freesoftware/
Linux Incompatibility List: http://leenooks.com/
Jeff Hobbs
> Joe English <add...@invalid.sorry> writes:
>
>
>>If anyone has any particular Gnome or KDE themes they'd like to see
>>supported, please let me know -- I'd like to get a feel for what
>>people are looking for here.
>
>
> A good start would be:
>
> whatever GTK themes Redhat, Suse and Debian default to, with Mandrake
> and Gentoo thrown in for good measure. KDE would be an added bonus if
> the licensing isn't a problem.
IMO the emulation of Gtk/KDE themes is a far second in priority
after getting the basic set of themed widgets finished with a
good set of features, and having a basic updated look for Tk on
unix that is "sharp", regardless of wm. FWIW, Gtk themes may
actually be more onerously licensed. For example, Pat has done
some work to support Gtk pixmap themes, but we can't include a
Gtk example since it's viral GPL (there are some pointers to
where you can get the pixmaps yourself).
Victor Wagner
: IMO the emulation of Gtk/KDE themes is a far second in
priority
May be better to spend time for creating complete Tk-based desktop suite
and compete with GNOME/KDE (you have either say Gtk/Qt, or GNOME/KDE in
most cases, not gtk/kde).
--
David N. Welton
> Jeff Hobbs <je...@removethis.activestate.com> wrote:
> : IMO the emulation of Gtk/KDE themes is a far second in
> : priority
Whichever gets us something nice looking ASAP. You're probably right
that doing a default 'improved' look with Tile would be fastest.
> May be better to spend time for creating complete Tk-based desktop
> suite and compete with GNOME/KDE (you have either say Gtk/Qt, or
> GNOME/KDE in most cases, not gtk/kde).
Victor, do you have any idea how many bazillions of lines of code that
is? You are orders of magnitude outside the realm of reality here:-)
Jeff Hobbs
>>May be better to spend time for creating complete Tk-based desktop
>>suite and compete with GNOME/KDE (you have either say Gtk/Qt, or
>>GNOME/KDE in most cases, not gtk/kde).
>
>
> Victor, do you have any idea how many bazillions of lines of code that
> is? You are orders of magnitude outside the realm of reality here:-)
I predict that it is less than one bazillion ... ;)
Victor Wagner
: > May be better to spend time for creating complete Tk-based desktop
: > suite and compete with GNOME/KDE (you have either say Gtk/Qt, or
: > GNOME/KDE in most cases, not gtk/kde).
: Victor, do you have any idea how many bazillions of lines of code that
: is? You are orders of magnitude outside the realm of reality here:-)
I have. And I have an idea that 95% of these lines is useless C++ crap.
About 70% of these is duplication of what we already have in the Tcl/Tk,
because authors of Gtk/Qt ignore, for instance options database, which
Tk use, and have to reinvent it. Poorly.
--
David N. Welton
Why don't you start with a browser that has roughly the same features
of Konqueror or Mozilla Firefox, then we'll talk about all the other
components of the system.
Donal K. Fellows
> Not yet Donal. I've seen the traffic on it. But given my limited Tk
> experience, I hadn't taken on the task of learning about Tile.
I was just really suggesting downloading the demo and giving it a whirl
(or even just looking at the screenshots on http://tktable.sf.net/tile,
most of which could have been taken using the same running instance of
Tcl/Tk/Tile). And then picking your jaw up off the floor where it fell
in amazement. :^D
I'm absolutely certain it is not production-quality yet, but that's just
because we have very high standards. If it was commercial, it would have
been shipped to customers ages ago!
> But, if the solutions are in process, then that sounds great to me!
Which is the main point in all this. Almost everything listed in the
message that started this thread comes under three headings:
1) We're working on it!
2) We think it's not worthwhile working on it.
3) It's in an extension or dead easy to script.
Things that don't come under those headings are opportunities for people
to get involved!
Donal.
Victor Wagner
: Why don't you start with a browser that has roughly the same features
: of Konqueror or Mozilla Firefox, then we'll talk about all the other
Mozilla FireFox is not GNOME app. It uses its own XUL-based interface.
So, GNOME desktop lives happily without its own browser.
BTW, there was some projects related to creating Tk bindings to Gecko
rendering engine, so part of work is already done.
--
David N. Welton
> David N. Welton <dav...@dedasys.com> wrote:
> : > database, which Tk use, and have to reinvent it. Poorly.
> : Why don't you start with a browser that has roughly the same features
> : of Konqueror or Mozilla Firefox, then we'll talk about all the other
> Mozilla FireFox is not GNOME app. It uses its own XUL-based interface.
Sure, but on Linux that's built on top of Gtk:
@ashland [~] $ ldd /usr/lib/mozilla-firefox/firefox-bin
libmozjs.so => not found
libxpcom.so => not found
libplds4.so => /usr/lib/libplds4.so (0x0ffdc000)
libplc4.so => /usr/lib/libplc4.so (0x0ffb6000)
libnspr4.so => /usr/lib/libnspr4.so (0x0ff5c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0feeb000)
libdl.so.2 => /lib/libdl.so.2 (0x0fec8000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0fb93000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x0faf5000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x0fab5000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x0fa7d000)
libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x0fa57000)
libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x0fa2a000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x0f9cf000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x0f96f000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x0f94b000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0f89f000)
libm.so.6 => /lib/libm.so.6 (0x0f80b000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0f722000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0f6f4000)
libc.so.6 => /lib/libc.so.6 (0x0f596000)
/lib/ld.so.1 => /lib/ld.so.1 (0x30000000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0f49d000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x0f479000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x0f450000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0f41e000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x0f3eb000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0f350000)
libz.so.1 => /usr/lib/libz.so.1 (0x0f31d000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x0f2cf000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x0f2a4000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x0f27a000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x0f233000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x0f1ee000)
(and lots and lots of other things, too;-)
lvi...@gmail.com
According to USCode <usc...@dontspam.me>:
:Perhaps redundant wasn't the right word. The TclTkAqua BI distribution also
:ports of Tk to Aqua?
It is my understanding (and I'm certain that someone in the know can
correct my limited understanding) that Tk is another step towards providing
a developer with the APIs necessary to generate a theme in Tk. Aqua,
on the other hand, is an entire windowing system. So Tk Aqua is going to
always be necessary. What might be the case, however, is that Tk Aqua
will be able to take advantage of the work done in Tile to their advantage.
lvi...@gmail.com
According to Donal K. Fellows <donal.k...@man.ac.uk>:
:Larry W. Virden wrote:
:> Not yet Donal. I've seen the traffic on it. But given my limited Tk
:> experience, I hadn't taken on the task of learning about Tile.
:
:I was just really suggesting downloading the demo and giving it a whirl
:(or even just looking at the screenshots on http://tktable.sf.net/tile,
:most of which could have been taken using the same running instance of
:Tcl/Tk/Tile). And then picking your jaw up off the floor where it fell
:in amazement. :^D
Alas, I looked at the screen shots and didn't see a whole lot of difference.
Maybe I'm not a visual enough person to see the deal. And certainly
I'm not in the pro-theme camps anyways - I seldom if ever change themes,
etc. so it's not a passion for me.
: 2) We think it's not worthwhile working on it.
: 3) It's in an extension or dead easy to script.
:
:Things that don't come under those headings are opportunities for people
:to get involved!
And my point was that if it is something in 2 or 3, and someone
does want it, then they should go ahead, write it up, and contribute it to
tklib or something similar. Don't let the fact that one group doesn't
see something as a priority prevent someone else from contributing.
I know that everyone I've talked to in the years that tcl has been
around wants more of you out there to contribute what you can - report
typos, patches for improving docs, demo programs, bug reports, enhancements,
personal favorite procs, etc.
Donald Arseneau
> > Mozilla FireFox is not GNOME app. It uses its own XUL-based interface.
>
> Sure, but on Linux that's built on top of Gtk:
So? They also both use the X11 libraries.
Donald Arseneau as...@triumf.ca
David N. Welton
> dav...@dedasys.com (David N. Welton) writes:
> > > Mozilla FireFox is not GNOME app. It uses its own XUL-based
> > > interface.
> > Sure, but on Linux that's built on top of Gtk:
> So? They also both use the X11 libraries.
Which do not provide integration into the Gnome desktop system.
Anyway, the point is that no one is going to be competing with Gnome
or KDE using Tk anytime soon. People aren't even maintaining a lot of
existing Tcl code, let along huge new projects.
Let's concentrate on making Tk look good so that it's more appealing.