If some people are interested, i'm gonna tell you why i decided to stop
using TCL
and to start a new adventure with LUA (see
http://www.tecgraf.puc-rio.br/lua/ )
I work with 4 other people in a team developping huge applications (running
under Linux
and OSF1) dedicated to process-control. The core of these applications is
written in C and
uses TK for the GUI and scripting - fast drawing is done thru Xlib.
After 3 years of development with it, we think we 've reached the limits of
TCL:
it s too slow and the GUI doesn't look that great. To get the kind of
functions
clients expect nowadays we have to use all the TK extensions: Itcl, Tix,
BLT,
Bwidget and many others (an incomplete HTML widget, tree widget, ...)
The result ? Un-consistent look & feel, un-consistent API's and so on ...
debugging is often sluggish ( the TCL / C mix is painfull when debugging
embedded TCL code).
Now we have to port all the stuff to Windows. Arg.
Have u ever seen Tix under MS Windows ? Forget that.
There is the Bwidget solution: concentrate on 1 extension and rewrite what's
missing in it.
The look & feel seems right but don't look too close at details ...
And yes, that's 10 layers of script (!) above a Xlib emulation that is now
somewhat faster (?)
under Win32 but after many patches now present in the core distribution
(right ?)
We 'd have to rewrite an important part of the GUI to use BWidget both under
Linux, OSF1
and Win32... And this is some kind of temporary solution in my opinion.
Conclusion ?
I decided to --> FORGET <-- TCL and use LUA.
This is not Lua advocacy but Lua is much faster, the C core is light and
clean,
the scripts are clean. There are builtin debug facilities ( not need of a
poor TclPro).
There are a few ( clean :) ) extensions. Yes clean is the word ...
AND last but not least LUA allows direct mapping of C++ classes (thru an
extension working
in the way SWIG does ...).
And the GUI ? Well i decided to make my own LUA extension based on a
portable
GUI library. I choosed wxWindows / wxGTK (see http://www.wxwindows.org )
The result ? Great perfomances, perfect look & feel under Windows and GTK
(it follows
the themes used in Gnome under Linux) , all the widgets i need and many more
(even a fast html widget : )), DnD support (those never ending discussions
about Dnd in
Tk make me laugh now), no extension needed to read JPG or PNG files ...
It took me 1 month to get (nearly) all the wxWindows stuff work in Lua, plus
some extensions
like a XML parser and database (ODBC + Postgres) support. I think that month
of hard work
was worth it ...
I plan to make all this stuff available soon for all Lua users and perhaps
(?) some interested
TCL users :)
Ok guys tell me what you think BUT I liked TCL, now i love LUA.
Olivier Paquay
> Ok guys tell me what you think BUT I liked TCL, now i love LUA.
Good for you! It's always great to find a new tool that works better than
your old one.
Personally, I'll stick with tcl/tk. :-)
> If some people are interested, i'm gonna tell you why i decided to stop using TCL
> and to start a new adventure with LUA (see http://www.tecgraf.puc-rio.br/lua/ )
>
> I work with 4 other people in a team developping huge applications (running
> under Linux and OSF1) dedicated to process-control. The core of these applications is
> written in C and uses TK for the GUI and scripting - fast drawing is done thru Xlib.
>
> After 3 years of development with it, we think we 've reached the limits of TCL:
> it s too slow and the GUI doesn't look that great. To get the kind of functions
> clients expect nowadays we have to use all the TK extensions: Itcl, Tix, BLT,
> Bwidget and many others (an incomplete HTML widget, tree widget, ...)
>
> Conclusion ?
>
> I decided to --> FORGET <-- TCL and use LUA.
> GUI library. I choosed wxWindows / wxGTK (see http://www.wxwindows.org )
> The result ? Great perfomances, perfect look & feel under Windows and GTK (it follows
> the themes used in Gnome under Linux) , all the widgets i need and many more
> (even a fast html widget : )), DnD support (those never ending discussions about Dnd in
> Tk make me laugh now), no extension needed to read JPG or PNG files ...
Thanks for the information. What you've highlighted is the need for
Tcl/Tk community to support John Ousterhout's OpenTcl inititiative. As
you have described, we (the Tcl/Tk community) have all the parts. We
need to just put them together.
Development of both Tcl and Tk has certainly lagged in the last couple
of years. But with the combination of the talents in the Tcl community
and a truly open Tcl/Tk development process, I see this dramatically
changing.
I wish you success with wxwindows and LUA. But I still think Tcl and Tk
are a better vehicle for application development. And things should
only get better...
--gah
While I found your piece interesting, I notice that you didn't cross post
to comp.lang.lua - oh wait, there is no newsgroup for Lua.
Well, at least you have some wonderful text books like Welch's Practical
Programming, for learning lua, right? Or perhaps a couple or three dozen
other books which use Lua as an implementation language while solving
various problems? And I suspect that Lua has several thousand applications
and almost a thousand extensions and add-ons for taking care of all the
various work you have need to do in the future? And there is probably several
major web sites providing community workspaces for solving problems, helping
users, etc.?
Lua, as well as many other languages, are all likely to be wonderful languages,
for individuals looking for personal solutions. And many of them will evolve
in their own unique and important ways.
Tcl has numerous shortcomings. Your list is an important one - I surely hope
that a number of these catch various developers attention and they work
on solutions to them.
Thanks for sharing your experiences!
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Tcl should be prepared to learn from all other languages that there are. LUA
has some interesting error handling mechanisms similar to Tcl's [unknown]
command handler which bear some looking at.
In philosophy and origin it is very similar to Tcl, however some of the
comparisons in the papers are seriously out of date (papers cannot really be
modified) and a page describing the current situation would be fairer.
As i explained in my first post i decided to use Lua because i could not
find good solutions to my problems
with TK right now. I say TK and not TCL because i use TCL as an extension
langage for scripted GUI
and not as a stand alone langage. As a GUI Toolkit, Tk has too many
limitations in my own opinion.
Besides the core of my applications are written in C/C++ and there are
excellent open source toolkits available
and WxWindows is perhaps the best. What i did is a rebuild of my application
with that library. Since i like
(and i need for my customers ) scripted GUI i made the choice to use Lua
because it s light (i don t need the extra TCL libs since i have them in
C/C++ libs) and VERY easy to use as a script langage.
If TCL is more than an extension langage for your work then OK changing to
Lua is not an ideal solution because
LUA does not have rich libraries, Lua does not have a strong community, the
cool support found in newsgroups
like comp.tcl, there are no O'Reilly books and so on ... But if you need a
scripting langage as an extension base
for your App then Lua has 20 or so commands and it s enough for that work.
I made my extension to fulfill my needs after much reflexion. I never said
"I forgot TCL, u have to forget it too".
If some people are intrested in this particular work, they can contact me.
By the way i decided to make this extension soon available as a TCL
extension because it does not require too much
work to make it.
TCL is great, believe me. I like many aspects like data channels --
fantastic stuff !!!! but i don like TK much.
Olivier Paquay.
PS whatever i wrote i used TCL everyday for little scripts that can t be
done easuly with anything else :)
Good Luck.
Rob Ratcliff
In fact i rewrote the whole Lua extension to work with TCL. wxTCL (i am no
sure of the name i ll give to it) will be a standard extension usable with a
simple "package require". It will offer many widgets found in wxWindows with
the advantage of exact look and feel under Windows and Gnome. The widgets
will work in exactly the same way as the TK widgets. Last but no least you
ll be able to mix wxWindows widgets and Tk ones in the same window :).
I am now in the last debugging phase and i will propose this extension in 1
week or 2 to the TCL community ...
It would be nice if some people could help me test it ... I think this
extension might interest many people who feel that Tk miss some goodies but
like what is great in TK ( text and canvas are great )
I ll make a post as soon as it is good enough. I am very interested by any
advice, encouragment, help proposal for testing ....
Olivier Paquay
"Rob Ratcliff" <rrr...@futuretek.com> a écrit dans le message news:
39A2AA72...@futuretek.com...
I'll be more explicit: Tix is ripe for adoption. I have
heard MANY people say, "what a shame about Tix". All it takes
is one person to say, "what an opportunity all that nearly-
working Tix source represents." One person who seriously
begins to care for Tix will find a lot of helpers pitching
in.
I'm not volunteering. Tix is not for me, at that level.
However, I've contributed small corrections in the past,
and I'd start again, once someone else commits to maintaining
the source in good shape. I'm sure others will do the same.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
And if anyone wants to help out with Tix, you should go
to:
http://sourceforge.net/projects/tix/
--Dan
I do not want to start a "political" and/or "philosophical" discussion, but
being a time where some
are really curious about where Tcl/Tk will go, may be this is worth thinking
about?!
I do not have deep knowledge of Tcl and Tk at all, meaning of all the
"internals". I am using it
to create applications, which are easy to customize, and, at least in the
beginning 5 years ago,
Tk was a great tool to build GUIs. I am not even using the "C-level", only
pure scripting.
My decision at that time was based on the functionality of Tcl and a big pro
was Tk. It took me
a long time to convince my customers.
Now, customers are also grown up (at least a bit) and they also know what
Tcl/Tk is, and, the worst
thing, they also know about the discussions of the last months. AT the
moment, it is difficult to argue for
Tcl/Tk, but here questions like "what about Python and wxWindows?
My feeling is, at lot has been done in Tcl, but almost nothing happend in
Tk!
Building an "up to date" GUI is time-consuming enough, but be honest - Tk
just does not provide the
tools to easily create a GUI for all those (like it or not!) Windows users.
Sorry, but Windows is the
standard, and arguments like "there is a package, which does that and that".
At the moment, I spend
more time in looking for packages, or updates of them, testing them, find
out that they do NOT help,
and end up with trying to produce something of my own, comeing as close as I
can to what people expect.
It is no fun!!
So I playes around with Python (sorry!) and wxPython. I will not switch from
Tcl to Python (for whatever reason)
but I think, it is worth looking at wxWindows. I found all the tools you
need to build a GUI in ONE package,
with good native look and feel and good performance and easy to use!
So I really liked to read Olivier Paquay's message, and I am very much
lookin forward to wxTcl (good name!).
Please implement all the stuff from wxWindows (and please give me a note,
when it is ready for testing!).
I think, the Tcl-Core-Group really should think about it!!
Henning
(a bit frustrated Tcl/Tk user)
eMails:
hen...@3s-hanusa.de
han...@ferber-hanusa.de
home:
www.ferber-hanusa.de
http://ourworld.compuserve.com/homepages/mmg_kraus/tclcornr.htm
Cheers,
Roy
Roy, this is one of the things that _I_ am most frustrated with. Too
many people complain "why doesn't Tk do such and such", and yet, when
you say "oh, here's some software to do that" they then say "I don't
want a package to do that".
Tk is unlikely to ever satisfy every single concept that every single
person conceives. Even Perl and Emacs, two of the world's largest programming
environments, do not ship with EVERYTHING ; they each have huge add on
libraries that one can download and install.
It particularly is offensive to me to hear people complain '"you"
don't support my platform well enough' , when the bottom line is that
in the open source world, the "you" needs to be everyone. Sure, not
everyone is an expert on internals of a language. I suspect that there
are few people developing in the Tcl community who began their time in
the community knowing the internals <smile>. However, the ones who are
contributing back to the community are those who not only ask for things
from the community, but also go out of their way to find SOME place
they can give back. Some do development against the core. Some do open
source application development. Some work on submitting updates to doc,
or writing tutorials, or help manage web sites of useful information,
or provide editorial oversight on material, or write books, or write
course material, or provide constructive detailed bug reports , etc.
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
I agree with H. Hanusa.
I 've read that thousands of people have downloaded TCL/TK. I'd like to know
the part of Windows users
among them. If it corresponds to the part of this OS on the market then i
feel that many people are not
completly satisfied with what they find in TK .... TK lacks many widgets and
TK lacks what is available in
Visual Basic or other scripting langages.
I think the look and feel is honnest with basic TK widgets under Windows.
Others are dull or non-existent. I don't want
an emulated combobox or TIX widgets. TIX widgets are great under Motif,
nowhere else. If u work for a university
or in an academic perspective, that's perfect, look and feel don't matter
much. If (like me) you want to sell it against VB or something else, lower
your prices and find good excuses ... That's the reallity. People know what
exist, want what they saw in common products and want standardized
interfaces. Something they know ...
A TK button is OK. A TK toolbar not a windows toolbar. However i want
scripted GUIs and TCL is good at this so i made my own extension, taking the
best things i found elsewhere (remember TCL is an extensible extension
langage).
TCL is OPEN source ? Ok ... TCL developpers should be OPEN minded, realist,
and see what exists and take or borrow what's good anywhere they can
..TCList are proud to see that Python or Perl borrowed TK, now they can grab
good extensions too. TCL is an extensible extension langage no ? Why not
share the maximum with the rest
of the world. Sometimes i feel that TCL community is focused on ... TCL and
forget that TCL is an extensible extension langage.
I want Apps with perfect look and feel under Windows AND something portable,
something that will look great under
Linux too ... WxWindows is the way for me, not TKGS. It s good to invent
the World when you 're the first.
One day TK was one of the first's. Now the world has been reinvented many
times so why re-invent it again and again ? Make it work with the world ...
That's my opinion. Give me yours.
Olivier Paquay
So, I would be willing to spend some time in the development process of wxTcl. I
don't remember who started this thread (and is working on wxTcl, but whoever it
is, please email me (mailto:lukas.ro...@balcab.ch)....
Lukas
Why does your application only run on Windows?
Tk is quite portable. It runs on Windows, Mac, and
many Unix varients. In addition there are widget
packages that add lots of nice additional widgets.
Tk 8.4 is scheduled to have some much needed new core
widgets (there is already a spinbox in 8.4a1, and there
are plans for several other new widgets.) By Tcl/Tk 8.4
I don't think that Tk will really lack any of the components
that wxWindows has. Currently there are extensions
(BLT, BWidgets, etc.) that add the widgets that it looks like
wxWindows has that Tk doesn't. Additionally, some of the
widgets in the screenshots on the wxWindows site don't look
as polished as the tk widgets or the additional widgets that
are provided as add ons to tk (in my opinion).
I don't think there is anything wrong with having bindings for
multiple widget sets, so you can use wxWindows if you choose,
but I will continue to use Tk.
--Dan
Many many people agree that TK doesn' t look great under Windows.
Look at a standard (Office type or whatever) and run TK application.
If you open yours eyes you ll see ... Are TCL partisans so blind ??
What has TK that wxWindows doesn't have ? (we don't talk about TCL)
A good canvas, a good text widget.
Besides TK has a good event model.
What has wxWindows that TK doesn't have ?
Exact look and feel under Windows for ALL kinds of widgets (they are NATIVE)
Exact look and feel under Gnome/GTK (this is GTK)
So we have Native widgets under windows behaving like windows widgets:
Excellent and complete HTML widget.
Full drag&drop with native OLE
Windows Toolbars ( true ones not imitation)
Windows TreeViews true ones not imitation)
Windows notebooks (true ones not imitation)
Windows comboboxes ( true ones not imitation)
Windows tooltips (true ones not imitation)
Windows controls ... Windows controls (i WANT them allllllllllll )
Html help system.
Calendar widget
And many many others i can t even remember.
That's Windows .... and the APPs are Windows APPs.
I make Windows Apps i want the Windows feeling.
Under Linux ? The same is true: all GTK widgets ... The application respect
the Gnome theme il like that.
I make Gnome Apps i want Gnome.
TK implements some motif stuff, some Mac, some Windows but is none of them.
wxWindows has an abastraction layer that give the best in common, the best
specific (true windows controls :) )
wxWindows has extra widgets above the abstraction layer ...
So i wrote my extension (wxTCL available soon ) which is TCL + wxWindows +
..... TK (TK can be embedded in
wxWindows frames) and ... the API is as simple as the TK one.
Olivier Paquay
PS i like TCL, i like it more when it does look like the defacto standards.
>Cameron Laird wrote:
>> I'll be more explicit: Tix is ripe for adoption. I have
>> heard MANY people say, "what a shame about Tix". All it takes
>> is one person to say, "what an opportunity all that nearly-
>> working Tix source represents." One person who seriously
>> begins to care for Tix will find a lot of helpers pitching
>> in.
>
>And if anyone wants to help out with Tix, you should go
>to:
>
>http://sourceforge.net/projects/tix/
Tix has a home, as Dan says (or http://tix.sourceforge.net). A new
version is forthcoming with CYGWIN compability, added documentation,
all known patches, and a number of cleanups. Tix is a lot more than
nearly working, and many find it essential for professional looking
Tcl applications.
Mike.
Yeah, well, its not orphaned. I have given it loving care for the past
year and a half, at least for the windows environment, and it really is
an amazing piece of work. Unfortunately, I have this bad habit. I like
to eat, and since Tix does not pay any bills....
I have banged the Tix source into quite good shape, I think, and I
expect to get a UNIX stub based source tree up sometime soon. Please,
lets not have so many negative vibs. Or is it just my abrasive
personality??? If so, I will use breath mints!
--
Iain B. Findleton
http://pages.infinit.net/cclients
custom...@videotron.ca
(514)457-0744
Yawn! wxWindows is a magnum opus, but its like fltk and other marvelous
multi-platform toolkits, they require gobs of learning and programming
effort to produce an application. You use Tk to cut by a factor of 10
your development time, to eliminate all of the screwing about with
string parsing and component integration work, and to achieve a
professional looking product that can be maintained rapidly and easily
across the host of platforms that don't have code warrior
implementations (for instance) in an afternoon.
As an aside, having read wxWindows source, and Tcl/Tk/Tix source, I feel
comfortable in saying that my eyes are quite open.....
I can answer this one. We make extensive use of Tcl in our
products, but we don't do much with it on the windows GUI side.
Here are a few quick reasons why:
1. Most customers are running windows.
2. VB and VC++ can make use of all the windows infrastructure.
There are tons of useful packages you can use without
worry. Tcl/Tk may be better than VB, but (if your goal
is writing applications) it's not better than VB + everything
that supports VB.
3. It's easy to find people that can code VB.
4. The infrastructure is already installed on people's
machines. You don't have to worry about installing
Tcl/Tk first, conflicting Tcl/Tk versions, etc.
5. It doesn't quite look like windows. It looks close, but if
it's running next to office (for example), it is just
different enough to look odd.
> but I will continue to use Tk.
Just for the record, I will too... ;-)
Mark.
--
Mark Harrison ma...@usai.asiainfo.com
AsiaInfo Computer Networks http://www.markharrison.net
Beijing / Santa Clara http://usai.asiainfo.com:8080
You could
a) have mentioned gtk and qt equally well besides WxWindows and
b) could have connected WxWindows to Tcl already and presented your
results right here.
Harald Kirsch
--
----------------+------------------------------------------------------
Harald Kirsch | kir...@lionbioscience.com | We make the tools to
LION Bioscience | +49 6221 4038 172 | reverse engineer nature.
*** Please: Never Ever Mail Me Copies Of Your Posts ***
I presume that wxWindows only works on Windows machines.
Tk is not meant to be a Windows only GUI toolkit, it is a cross platform
GUI toolkit and as such will never on its own be as good as a native
Windows GUI toolkit.
I personally find that many of the Windows application GUIs are incredibly
complicated and hard to use. What I am supposed to make of 100s of different
icons on dozens of different toolbars which appear and disappear almost at
random. I only ever use a couple of them and it takes me longer to find it
on a toolbar than in a menu. Maybe it is more effective for power users but
I doubt that they use them all. Then of course you can customise it just
how you like it which just makes it different to everyone else.
Another thing I don't like about the GUIs is that they fundamentally change
from release to release so that you have to start again. Also there is
no real consistency from one application to another, even M$ applications.
If people want an Tcl interface to wxWindows then go ahead and write one,
don't get into a discussion about how bad Tk is on Windows. I would
recommend that wxTcl has an interface similar to Tk's as Tk's interface is
very powerful and simple.
It is always easier to create something which only works on one platform
than it is to create something which works on *all* platforms.
Well, wxWindows is a GUI library that is implemented over the Windows
API and the X API. Perhaps other things as well, but I don't know. You
have to like compiling things to like wxWindows.
My apologies.
I take back all I said, I just went to http://wxWindows.org and it works
on Windows / Unix / Mac. The Unix version works with Motif and GTk.
Everytime I fail to verify that what I am writing is correct whether it be
Tcl code or 'facts' I always get it wrong 8-(.
It certainly seems as though it would be a good idea to have a Tcl
interface to wxWindows, not sure how easy it would be to integrate it
into the Tcl event loop and wxWindows seems to have a lot more in it
than just plain GUI stuff. Threads, mutexes, file system abstraction, ...
The amount of duplication in these cross platform libraries, whether it
be wxWindows, ACE, Tcl, ... is horrendous.
Unfortunately, I am obsessive/compulsive when it comes to programming
projects. There remain some nagging wrinkles that I want to track down
before I publish my source tree. When these get ironed out, I intend to
do something about the world. In the interim, there is the sourceforge
site, on which my release is being built. I do regret being such a
conservative, but I just can't deal with a source base that is in
evolution at this time. As you may be aware, tools that work on Windows
don't always facilitate transparent transfer to UNIX, and vice-versa.
For instance, the diff of my source against the sourceforge base yields
a huge file with CR/LF context changes. This is not a "fin du monde"
thing, but I want to clean it all up before I go public. When I am
satisfied with a UNIX tree, I will let you all know, and as Roy and Dale
used to sing, "Happy trails to you...."
>Tk 8.4 is scheduled to have some much needed new core
>widgets (there is already a spinbox in 8.4a1, and there
>are plans for several other new widgets.) By Tcl/Tk 8.4
>I don't think that Tk will really lack any of the components
>that wxWindows has.
Open your eyes: Tk has had no new development of the widget set in
years. In case people take at face value your bland assertion about
plans for several other new widgets, let me point out that I have
email from John O. dating back to 1997 asserting that most of the
functionality of Tix would be subsumed by new widgets coming out in
the Tk core - in over 3 years not one has (unless you count openFile).
Tix provided the bare minimum for professional looking applications.
Labelled frame widgets, tree browsers, listboxes with headings and
icons, tabbbed notebooks, checklistboxes, help balloons, spinboxes,
options menus, and paned widgets are all essential to a professional
looking applications, yet none of these have been incorporated into Tk
over the last 3 years. It would have been relatively easy to have
standardized an object-oriented mega-widget in Tcl and to have
progressively included much of the code from Tix into the core to
provide this bare minimum functionality, but clearly professional
looking applications have never been a priority at Sunlabs or
Scriptics or Uhjuba. I think this has badly hurt Tcl as a GUI
language.
> Currently there are extensions
>(BLT, BWidgets, etc.) that add the widgets that it looks like
>wxWindows has that Tk doesn't.
Get real: people know what exists, and want what they see in common
products and want standardized interfaces. There are both defacto and
dejure standards for commercial applications (Windows logo
certification, Kde/Cde compliance) . What we are talking about is all
of the above, which were overdue 3 years ago, plus:
Excellent and complete HTML widget.
Full drag&drop with native OLE/Corba/Kde support.
Native Toolbars ( true ones not imitation)
TreeViews with support from the OS for icons if a file browser.
Notebooks comboboxes spinboxes and tooltips (preferably native).
Native support for desktop themes (Gnome, Cde, Kde and Windows).
Tk started along this path with openFile and stopped there.
>I don't think there is anything wrong with having bindings for
>multiple widget sets, so you can use wxWindows if you choose,
>but I will continue to use Tk.
You're missing the point - people are no longer continuing to use Tk.
The need for a modern widget set is critical if Tk/Tcl is to continue
as a GUI language, or else people will vote with their feet. Tk is
woefully behind the times, and needs either a massive improvement to
Tk, or glue to a modern widget set such as wxWindows or the Qt
toolkit,. KDE opted for the Qt toolkit over Tk for obvious reasons -
one is professional looking and the other isn't. So, Tcl is missing
out on this whole rapid growth on the Linux desktop as a result.
But the really sad part is that the strength of Tcl is as a glue, and
is ideally suited to gluing itself to a more modern widget set. What
seems to have been missing is the recognition from Sunlabs or
Scriptics or Uhjuba that this is a problem for commercial
applications, or even that Tcl/Tk is a commerical product for making
professional looking applications. I think this needs to change.
Mike.
Have you looked at the Qt toolkit (the basis for KDE)?
Does it have as many drawbacks as wxWindows in your view?
Mike.
So: I propose that you think about changing the
SourceForge Tix home page to explain that you're
actively working on the sources now.
It's rather mournful to think of how many users
have already given up on Tix.
Tcl and Tk were never commercial products, they have always been
free as an open source language. You could, and still can, purchase
support if you wish from Ajuba as well as several other companies.
Tk still exists on the Mac, but the main Mac maintainer is focusing
strictly on MacOS X compatability now.
> >Tk 8.4 is scheduled to have some much needed new core
> >widgets (there is already a spinbox in 8.4a1, and there
> >are plans for several other new widgets.) By Tcl/Tk 8.4
> >I don't think that Tk will really lack any of the components
> >that wxWindows has.
>
> Open your eyes: Tk has had no new development of the widget set in
> years. In case people take at face value your bland assertion about
> plans for several other new widgets, let me point out that I have
> email from John O. dating back to 1997 asserting that most of the
> functionality of Tix would be subsumed by new widgets coming out in
> the Tk core - in over 3 years not one has (unless you count openFile).
Well you'll be swallowing that statement soon enough. Note that a
spinbox is already in 8.4a1 (quite powerful, yet still easier to use
than any other toolkit). I'm also currently working on a C version
of the mclistbox for the 8.4 core right now. Others are in the works.
...
> Get real: people know what exists, and want what they see in common
> products and want standardized interfaces. There are both defacto and
> dejure standards for commercial applications (Windows logo
> certification, Kde/Cde compliance) . What we are talking about is all
> of the above, which were overdue 3 years ago, plus:
I don't understand people's aversion to using extensions when they
need them. OK, it could be easier, and we're working on that, but
the functionality is there.
> Excellent and complete HTML widget.
tkhtml
> Full drag&drop with native OLE/Corba/Kde support.
tkdnd
> Native Toolbars ( true ones not imitation)
got me there, we just have imitations.
> TreeViews with support from the OS for icons if a file browser.
We have trees, why do we need OS support for icons?
> Notebooks comboboxes spinboxes and tooltips (preferably native).
Not native, but all there.
> Native support for desktop themes (Gnome, Cde, Kde and Windows).
Skin cancer? No thanks.
...
> You're missing the point - people are no longer continuing to use Tk.
The number of downloads per week for Tcl/Tk counter that statement (8000).
In the end, I think it would be nice to see bindings to the other widget
sets (one for gtk is in the works), because overall, if you have the
right set of tools (widgets) for the app you are designing, it is still
much easier to do in Tcl than any other language (add your own salt).
--
Jeffrey Hobbs The Tcl Guy
hobbs at ajubasolutions.com Ajuba Solutions (née Scriptics)
Jeffrey Hobbs schrieb:
> In the end, I think it would be nice to see bindings to the other widget
> sets (one for gtk is in the works),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is good news!
Peter
Why bother when there is a wxGTK version of wxWindows which is just a plugin
replacement ?
>The amount of duplication in these cross
>platform libraries,
>whether it be wxWindows, ACE, Tcl, ... is
>horrendous.
For someone trying to wade their humble
way through the morass of features that
scripting languages (tcl/tk, perl, python,
ruby, rebol, lua....) it's all a little
overwhelming.
The only thing that I've seen that really
makes sense in the long-run is some idea-
ware:
Borneo Programming Language
(Ait-Kaci at Simon-Fraser Univerity, Canada)
http://www.isg.sfu.ca/~hak/Borneo.html
1. many languages (be they based on wildly
different semantics) still share many
concepts (e.g., linear list, lexical scope, heap
data, static data, garbage collectible data,
nesting, pairing maps, structural
or procedural continuations, multi-threading,
etc...). These concepts can be designed as
low-level abstract data types with public
interfaces that ensure their safe and correct
utilization.
2. programming syntax is irrelevant and
arbitrary; detaching semantics from a
particular syntax by linking it to the basic
semantics constructs such as those listed
above is clearly the better alternative.
Then, using a simple but flexible parser
generator, any particular syntax can be
linked to any semantics.
These ideals seem radical but axiomatic.
Is programming moving in this direction?
The first part seems to be a python feature,
i.e. absorb every possible feature.
Jon Fernquest
bayin...@hotmail.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Yes, but the documentation isn't IMHO very good. Perhaps this is just
because I've not immersed myself in it to the point of comprehending
the Karma of Qt...
Donal.
--
"Understanding leads to tolerance, which in turn leads to acceptance. And from
there, it's just a quick hop to speeding in Ohio, chewing peyote, and
frottage in the woods with a family of moose. And I just want to claim my
part of the credit." -- bunnythor <bunn...@uswest.net>
Don't ask me. I didn't mean to imply that I or anyone at Ajuba is
doing it, if that's what came across. The person working on this
(tcl-gtk) can be found in the Tcl FAQ. It's recent work.
I currently use tkhtml in a project of mine, and for an html help facility it
works well. But I wouldn't use it as a browser.
I have high hopes for 8.4... I hope it lives up to those hopes.
And here's the rub. Tk builds on X systems without any other widget set.
wxWindows does not.
If you want wxWindows bound to Tcl, then bind it. Rather than trying to
convince the rest of the world of the superiority of the toolkit and trying
to get them to do the binding, demonstrate it to us.
If it results in a technically superior extension, perhaps people will rush
right off and use it. At the very least, then the argument isn't between
an existing, debugged, established scripting environment (Tcl/Tk) and a
(as far as I am aware) mythical one (Tcl/wxWindows).
this is exactly what I tried to state in my original message.
Building professional applications needs a package for
professionally looking GUIs - and Tk just is out-dated.
I knew, when I wrote my ideas, that a lot of people would yell,
but a lot of contrinutions in the last 2 days show, that i am not allone.
There is a big difference between an application for "in-house" use, with Tk
as a tool for really rapig GUI implementation, and an applicaton which you
try to sell! Tk still is good enough for the first.
Henning
<support @ internetdiscovery.com (Mike Clarkson)> schrieb im Newsbeitrag
news:39a55eeb...@24.0.228.33...
> On Wed, 23 Aug 2000 11:30:38 -0700, Dan Kuchler
> <kuc...@ajubasolutions.com> wrote:
> >Tk is quite portable. It runs on Windows, Mac, and
> >many Unix varients. In addition there are widget
> >packages that add lots of nice additional widgets.
> Tk clearly is no longer supported on the Mac, and if I understand your
> previous postings, Tcl and Tk are no longer a commercial product.
>
> >Tk 8.4 is scheduled to have some much needed new core
> >widgets (there is already a spinbox in 8.4a1, and there
> >are plans for several other new widgets.) By Tcl/Tk 8.4
> >I don't think that Tk will really lack any of the components
> >that wxWindows has.
>
> Open your eyes: Tk has had no new development of the widget set in
> years. In case people take at face value your bland assertion about
> plans for several other new widgets, let me point out that I have
> email from John O. dating back to 1997 asserting that most of the
> functionality of Tix would be subsumed by new widgets coming out in
> the Tk core - in over 3 years not one has (unless you count openFile).
>
> Tix provided the bare minimum for professional looking applications.
> Labelled frame widgets, tree browsers, listboxes with headings and
> icons, tabbbed notebooks, checklistboxes, help balloons, spinboxes,
> options menus, and paned widgets are all essential to a professional
> looking applications, yet none of these have been incorporated into Tk
> over the last 3 years. It would have been relatively easy to have
> standardized an object-oriented mega-widget in Tcl and to have
> progressively included much of the code from Tix into the core to
> provide this bare minimum functionality, but clearly professional
> looking applications have never been a priority at Sunlabs or
> Scriptics or Uhjuba. I think this has badly hurt Tcl as a GUI
> language.
>
> > Currently there are extensions
> >(BLT, BWidgets, etc.) that add the widgets that it looks like
> >wxWindows has that Tk doesn't.
>
> Get real: people know what exists, and want what they see in common
> products and want standardized interfaces. There are both defacto and
> dejure standards for commercial applications (Windows logo
> certification, Kde/Cde compliance) . What we are talking about is all
> of the above, which were overdue 3 years ago, plus:
>
> Excellent and complete HTML widget.
> Full drag&drop with native OLE/Corba/Kde support.
> Native Toolbars ( true ones not imitation)
> TreeViews with support from the OS for icons if a file browser.
> Notebooks comboboxes spinboxes and tooltips (preferably native).
> Native support for desktop themes (Gnome, Cde, Kde and Windows).
>
> Tk started along this path with openFile and stopped there.
>
> >I don't think there is anything wrong with having bindings for
> >multiple widget sets, so you can use wxWindows if you choose,
> >but I will continue to use Tk.
>
> You're missing the point - people are no longer continuing to use Tk.
For the sheer joy of it.
Mark
> If you want wxWindows bound to Tcl, then bind it. Rather than trying to
> convince the rest of the world of the superiority of the toolkit and
trying
> to get them to do the binding, demonstrate it to us.
> If it results in a technically superior extension, perhaps people will
rush
> right off and use it. At the very least, then the argument isn't between
> an existing, debugged, established scripting environment (Tcl/Tk) and a
> (as far as I am aware) mythical one (Tcl/wxWindows).
That's exactly what i am doing ... i don't want to prove anything. I told
what i think and, judging the number of mails i received, many people
agree. Please read my other posts "TCL, wxWindows & TK" and you
will see and i want wxWindows to work with TCL AND TK.
I don't want anybody to make this binding since i made it. My aim is to make
something missing FOR ME and that will perhaps help others.
I have much to prove, let's hope i ll transform mythical to real. But i
would like
to make it with support of the community.
I said what i thought and i said it LOUD. Many people reacted. Well that's
the first positive thing in this story. Perhaps there 'll be another.
Olivier Paquay
I believe Steve Ball is working on a widget 'tkGecko' that allows
the Mozilla/Gecko rendering engine to be embedded into Tk apps.
I would guess that would work better for creating a web browser
--Dan
Screenshots would be nice too.
L
--
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK
Laurent Duperval "Montreal winters are an intelligence test,
and we who are here have failed it."
mailto:laurent....@netergynet.com -Doug Camilli
Penguin Power! ***Nothing I say reflects the views of my employer***
Cool! Here's hoping you can give us a native C combobox real soon, too.
Then my tcl based combobox and mclistbox widgets can go away. That way I
won't feel so guilty for neglecting them. :-|
Bryan Oakley wrote:
Here's just some random praise. I love having the combobox you made.
Congratulations on a great and much-needed bit of code.
What about languages that are not defined using a conventional parser?
Or are you really determined to be anti-Tcl and anti-Forth?
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Anyone using MFC desperatly needs a nasal enigma.
-- David Steuber <tras...@david-steuber.com>
Why? Kindly quantify. It really helps people with the ability to fix
this sort of thing a lot if there is a list of features that you
believe are missing from Tk. Better yet, start a Wiki page on it.
> There is a big difference between an application for "in-house" use,
> with Tk as a tool for really rapig GUI implementation, and an
> applicaton which you try to sell! Tk still is good enough for the
> first.
There's a lot of stuff sold that never should have been...
The last I heard, it was about 60% Windows/40% Unix.
> If it corresponds to the part of this OS on the market then i feel
> that many people are not completly satisfied with what they find in
> TK .... TK lacks many widgets and TK lacks what is available in
> Visual Basic or other scripting langages.
Kindly enumerate that we may refine our wishlists and roadmaps to
include the features you desire. Don't assume that we know what you
are after by telepathy...
> TCL is OPEN source ? Ok ... TCL developpers should be OPEN minded,
> realist, and see what exists and take or borrow what's good anywhere
> they can.
Because of the ease of doing simple stuff with Tcl (embedding
wxWindows into Tcl can be done just by SWIGging the interface, right?)
we have the luxury of being able to focus more on other issues like
the production of interfaces that are very easy to use. Just because
C/C++ does it one way doesn't mean that we have to do it the same way.
> .TCList are proud to see that Python or Perl borrowed TK, now they
> can grab good extensions too. TCL is an extensible extension langage
> no ? Why not share the maximum with the rest of the world. Sometimes
> i feel that TCL community is focused on ... TCL and forget that TCL
> is an extensible extension langage.
I've already mentioned SWIG. Then there's also Ffidl which lets you
take existing object code and make an interface to in Tcl. Given the
existence of such stuff, why on earth should the focus be on getting
everything in as quickly as possible?
> I want Apps with perfect look and feel under Windows AND something
> portable, something that will look great under Linux too ...
That's great.
> WxWindows is the way for me, not TKGS.
I'm glad you've found something that appears to work for you. However
I should warn you that wxWindows support is not universal on Linux;
there are systems out there without Motif and without GTK support, and
yet Tcl/Tk works there like a charm.
> It s good to invent the World when you 're the first. One day TK
> was one of the first's. Now the world has been reinvented many times
> so why re-invent it again and again ? Make it work with the world...
The world is bigger and stranger than you believe...
(How is wxWindows's i18n support?)
Could you email me an example image (GIF, JPEG or PNG preferred) of
the mclistbox so that I can add it to the list of Tk widgets in the
Wiki?
"Donal K. Fellows" wrote:
> In article <39a41032$0$12...@bru5-newsr2.be.uu.net>,
> Olivier Paquay <awak...@yahoo.fr> wrote:
> > I 've read that thousands of people have downloaded TCL/TK. I'd like
> > to know the part of Windows users among them.
>
> The last I heard, it was about 60% Windows/40% Unix.
>
> > If it corresponds to the part of this OS on the market then i feel
> > that many people are not completly satisfied with what they find in
> > TK .... TK lacks many widgets and TK lacks what is available in
> > Visual Basic or other scripting langages.
>
> Kindly enumerate that we may refine our wishlists and roadmaps to
> include the features you desire. Don't assume that we know what you
> are after by telepathy...
(btw, I love the fact that tcl/tk developers are actually willing to listen to
users)
widgets I would love to see:
spinbox
multi-column listbox
dials/knobs
combobox
a more complete tk_messagebox.... include dialog-ability like adding other widgets
to it more easily.
and then, that ever elusive, practically impossible to even mention without
starting a flamewar.... a printing API that is cross-platform. I know that this
may be quite difficult if not impossible. But even a bare one would be nice.
Please don't scorn me for bringing this up... <wince>
[snip]
>
> and then, that ever elusive, practically impossible to even mention
without
> starting a flamewar.... a printing API that is cross-platform. I
know that this
> may be quite difficult if not impossible. But even a bare one would
be nice.
> Please don't scorn me for bringing this up... <wince>
>
A cross-platform printing API is the ONE THING this old amatuer
would really like to see added to the core!
(My $.02)
Steve
--
Steve Offutt
*Learning* to program is my hobby
That's the ratio of downloads, right? I don't think that (necessarily) reflects
the ratio of developers or users. I know I've downloaded Tcl/Tk to my home PC a
few times and not DLed UNIX to work as often. But I spent 4-6x as much time
working on UNIX at work where there are several other developers working on and
with the UNIX versions I've DLed. It's a complicated stat, not easy to
understand or extrapolate from.
Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!
When I was in college I had a program that I
wanted to add cross platform printing
support to. I don't know if it will help
anyone, but at that site we used 'lpr' for
unix printing, and I was able to use the
following code to print to the same printer
'2a' which was hosted on a machine named 'hobbes'
from UNIX and windows. The code I use
to print (this was pure text content):
if {[string compare $platform windows]} {
exec {net use lpt1 \\hobbes\2a}
set printFile [open "lpt1" w]
} else {
set printFile [open "| lpr -P2a" w]
}
puts $printFile "$content"
close $printFile
--Dan
You may find it suprprising but i don't develop wxTCL with SWIG ...
Why ? Simply because i like the easy way of building interfaces if found in
TK
so i try to make an extension with something that 'll in the end TRY to be
as
simple as TK and easy to learn for TK afficionados. False "Object oriented"
interfaces
are pleasant but that would not be "TK like".
Focusing on problems is a concern for anybody working with professional
constraints. I don't want to spend much time trying to grab all the
extensions
needed for my goal, check compatibility issues and so on ... spend time
juggling to get a mid-satisfying "megawidget".
>
> > .TCList are proud to see that Python or Perl borrowed TK, now they
> > can grab good extensions too. TCL is an extensible extension langage
> > no ? Why not share the maximum with the rest of the world. Sometimes
> > i feel that TCL community is focused on ... TCL and forget that TCL
> > is an extensible extension langage.
>
> I've already mentioned SWIG. Then there's also Ffidl which lets you
> take existing object code and make an interface to in Tcl. Given the
> existence of such stuff, why on earth should the focus be on getting
> everything in as quickly as possible?
>
> > I want Apps with perfect look and feel under Windows AND something
> > portable, something that will look great under Linux too ...
>
> That's great.
>
> > WxWindows is the way for me, not TKGS.
>
> I'm glad you've found something that appears to work for you. However
> I should warn you that wxWindows support is not universal on Linux;
> there are systems out there without Motif and without GTK support, and
> yet Tcl/Tk works there like a charm.
wxTcl is not aimed at universal acceptance. First in for me and people i
worked with.
Any interested people 'll be free to use if they find it useful knowing what
it implies.
> > It s good to invent the World when you 're the first. One day TK
> > was one of the first's. Now the world has been reinvented many times
> > so why re-invent it again and again ? Make it work with the world...
>
> The world is bigger and stranger than you believe...
I know that for some time ... How many people have implemented print
support
under Unix ? (this was a subject developped at Linux Expo in Paris). Many.
Too many.
On many under Windows ? Euh Microsoft did it. Where is the complete print
support
in TK roadmap ? wxWindows/wxGTK/wxMac has it (wxWindows uses the print
support known
by any windows user).
> (How is wxWindows's i18n support?)
>
I18n support is built thru catalogs like any modern library ....
I like TCL and make my custom extension so where is the problem ? I made
some provocation but
sometimes it helps further reflexion and make people react. But you've seen
that for years so please
forgive my excessive assertions.
> Donal.
> --
> Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/
fell...@cs.man.ac.uk
> -- Anyone using MFC desperatly needs a nasal enigma.
> -- David Steuber
<tras...@david-steuber.com>
PS: i never used MFC
Errr, in development means not yet screenshort worthy. I'll need a
couple of weeks for that. I've also decided to scratch what I started
with and start anew. The goal is to have LAF like the mclistbox in
Explorer (or like the Netscape newsreader also uses). I'm not sure
how far I'll plug along before deciding I can do it, or chicken out.
Glad to know that I can always serve up your print requests... ;^)
--
Jeffrey Hobb(e)s The Tcl Guy
That assumption could be correct. When we presented these numbers (they
are accurate, more like 56% Win / 39% Unix / 5% Mac), we tried to make
some guesses as to why. All Unix downloads are the *.tar.*, where Win
are the *.exe binaries and *.zip archives, with Mac being the Mac binaries.
Unix people have to get the sources from us and then compile, and many
would compile for an entire installation of people. These numbers also
don't take into account the places that provide binaries for you on
Unix, like sunfreeware (and similar ones for HP, AIX, Linux and IRIX).
Anyway, the big thing is that numbers are healthy. Just as a side note,
Brent presented some numbers in a discussion on where to locate the new
tcltk.org site (we're likely to just rename dev.scriptics.com). Here
are some interesting stats:
We pay for "tier-III" access, which means up to 3Mbit/sec -
or 26 GB/day if I've done my math right, or 777 Gb/month.
Of course, we don't use that maximum.
My hazy memory is that we had 30 minute sustained peaks of between
1 and 2 Mbit/sec. (We have a monitor that gives me details stats, but
I have to get the access codes from our sysadmins.)
Suppose our daily average is .5Mbit/sec, that is still about 130 Gb/month.
Yeah - going back over our FTP logs:
June, 2000, 125 Gb
July, 2000, 118 Gb
August (so far) 112 Gb
That's sustained downloads of just FTP (not HTTP) of 100+GB/month.
Most of that is the Tcl/Tk sources and binaries (we don't have all
that much on our ftp site).
--
Jeffrey Hobbs The Tcl Guy
So if the TCL community runs Unixes and don't make commerical products for
end users, i 'll understand that
they are happy with Tix which has that good old motif look and feel and does
not have performance issues
since performance is only a problem for marginal users relying on an
emulation layer for that good old xlib
(GTK is built on xlib i know but few people use emulated GTK under windows
...).
Well don't ask me why TCL is sometimes despised while the majority (incult
people running VB) has plenty of products for them ...
Your jumping to unsustainable conclusions. It's possible to develop
with Tcl based on the binary distribution alone. It has all the
developer docs and libraries to build extensions. You can download
and install the full binary distribution, download the full tktable
sources and compile without a problem.
2. Wx-Windows is slooow due to it's platform dereferencing (might have
changed this, it's been awhile). It's good to know that some of Tk's
platform dereferencing is due to go away in Tk 8.4 (last I heard
anyway).
3. If you don't like how Tk looks.. GET OFF YOUR BUTT AND FIX IT!
(It would be great if there was a "How to write a Tk widget in C using
the Tk/X-emulation C API".)
Dave LeBlanc
On Wed, 23 Aug 2000 21:02:29 +0200, "Olivier Paquay"
<awak...@yahoo.fr> wrote:
>Sorry Dan BUT OPEN YOUR EYES.
>
>Many many people agree that TK doesn' t look great under Windows.
>Look at a standard (Office type or whatever) and run TK application.
>If you open yours eyes you ll see ... Are TCL partisans so blind ??
>
>What has TK that wxWindows doesn't have ? (we don't talk about TCL)
>
>A good canvas, a good text widget.
>
>Besides TK has a good event model.
>
>What has wxWindows that TK doesn't have ?
>
>Exact look and feel under Windows for ALL kinds of widgets (they are NATIVE)
>Exact look and feel under Gnome/GTK (this is GTK)
>
>So we have Native widgets under windows behaving like windows widgets:
>Excellent and complete HTML widget.
>Full drag&drop with native OLE
>Windows Toolbars ( true ones not imitation)
>Windows TreeViews true ones not imitation)
>Windows notebooks (true ones not imitation)
>Windows comboboxes ( true ones not imitation)
>Windows tooltips (true ones not imitation)
>Windows controls ... Windows controls (i WANT them allllllllllll )
>Html help system.
>Calendar widget
>And many many others i can t even remember.
>
>That's Windows .... and the APPs are Windows APPs.
>I make Windows Apps i want the Windows feeling.
>
>Under Linux ? The same is true: all GTK widgets ... The application respect
>the Gnome theme il like that.
>I make Gnome Apps i want Gnome.
>
>TK implements some motif stuff, some Mac, some Windows but is none of them.
>
>wxWindows has an abastraction layer that give the best in common, the best
>specific (true windows controls :) )
>wxWindows has extra widgets above the abstraction layer ...
>
>So i wrote my extension (wxTCL available soon ) which is TCL + wxWindows +
>..... TK (TK can be embedded in
>wxWindows frames) and ... the API is as simple as the TK one.
>
>Olivier Paquay
>
>PS i like TCL, i like it more when it does look like the defacto standards.
>
>
Dave LeBlanc
On 25 Aug 2000 12:06:37 GMT, fell...@cs.man.ac.uk (Donal K. Fellows)
wrote:
>In article <39a55f95...@24.0.228.33>,
>Mike Clarkson <support @ internetdiscovery.com> wrote:
>> "Iain B. Findleton" <ifind...@videotron.ca> wrote:
>>> As an aside, having read wxWindows source, and Tcl/Tk/Tix source, I feel
>>> comfortable in saying that my eyes are quite open.....
>>
>> Have you looked at the Qt toolkit (the basis for KDE)?
>
>Yes, but the documentation isn't IMHO very good. Perhaps this is just
>because I've not immersed myself in it to the point of comprehending
>the Karma of Qt...
>
>Donal.
>--
>"Understanding leads to tolerance, which in turn leads to acceptance. And from
> there, it's just a quick hop to speeding in Ohio, chewing peyote, and
> frottage in the woods with a family of moose. And I just want to claim my
> part of the credit." -- bunnythor <bunn...@uswest.net>
Dave LeBlanc
On Mon, 28 Aug 2000 10:26:07 -0500, "Bryan Oakley"
<boa...@vignette.com> wrote:
>"Jeffrey Hobbs" <jeffre...@ajubasolutions.com> wrote in message
>news:39A567A7...@ajubasolutions.com...
>>
>> Well you'll be swallowing that statement soon enough. Note that a
>> spinbox is already in 8.4a1 (quite powerful, yet still easier to use
>> than any other toolkit). I'm also currently working on a C version
>> of the mclistbox for the 8.4 core right now. Others are in the works.
>
The other clue that makes this number interesting is the increasing
number of Windows users that post on c.l.t.
Dave LeBlanc
On Tue, 29 Aug 2000 12:19:30 -0400, Christopher Nelson
<ch...@pinebush.com> wrote:
>"Donal K. Fellows" wrote:
>>
>> In article <39a41032$0$12...@bru5-newsr2.be.uu.net>,
>> Olivier Paquay <awak...@yahoo.fr> wrote:
>> > I 've read that thousands of people have downloaded TCL/TK. I'd like
>> > to know the part of Windows users among them.
>>
>> The last I heard, it was about 60% Windows/40% Unix.
>> ...
>
>That's the ratio of downloads, right? I don't think that (necessarily) reflects
>the ratio of developers or users. I know I've downloaded Tcl/Tk to my home PC a
I didn't mean it like that (catalogues are fairly trivial to implement
in any language) but rather how good is it at handling non ISO-8859-1
text? For example, mixed Latin and Cyrillic, or Greek, or Kanji. (I
forget the names for Chinese and Korean texts.) Or, for a really tough
challenge, Latin text intermixed Hebrew or Arabic text.
IOW, this is a serious test of advanced font support (Arabic in
particular requires a lot of ligatures for correct rendering,) UNICODE
support, and mixed text direction support. It is a major challenge, and
as far as I'm aware, not even Tk gets it all correct (I believe it punts
on text direction; you need to handle that by hand. Sure you can do it
with right-aligned tabs and left-gravity marks, but that's a pain!)
Donal (No, I'm not volunteering to fix it in Tk.)
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
(WARNING: There is precisely one error in this message.)
Cross-platform printing is really very difficult indeed (unless you
declare all the world to be a line-printer or a postscript printer, a
tactic that Windows people seem to find unacceptable for some reason.)
I have extremely high hopes that the TkGS project will come to our
rescue here; the aim is to put a device-independent layer underneath all
existing Tk widgets and then redirect from that into whatever device is
currently specified as being the output device. Most notably for this
discussion, this includes both the Windows GDI and a Postscript
generator so printer support should be fairly trivial at that point.
(You'd need to create some dialogs on platforms where there aren't
system supplied ones, and a few other things like that, but none of
these are IMHO major stumbling blocks.)
Donal (who always wanted a scheme for printing *text* widgets, which
this also provides...)
There is no immediate prospect that Trolltech AS will
license commercial development packages at no charge.
Yes, you have to pay $$ to work with Qt under Win*.
... except that there's a sort of loophole that'll
become more public in September. Write me a reminder
around the second week of the month, and I'll post a
follow-up explanation.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Nah - Perl's been doing that for years...
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Hmmm... I always thought they were always willing to listen. Maybe not to
implement but they always listen. Since the code base should be opened to
more developers, hopefully that'll change some.
> widgets I would love to see:
> spinbox
There is one in 8.4a1. It's also available in BWidget.
> multi-column listbox
There is a Tcl-only one available. Jeff Hobbs says he's working on a C
version. Unless he decides to Run... I think thereis one in BWidget but I'm
not sure.
> dials/knobs
The vu widgets have that. Hey Jeff, you porting those to Tk or what?
> combobox
There is a Tcl-only one. BWidget has one.
> a more complete tk_messagebox.... include dialog-ability like adding other widgets
> to it more easily.
>
BWidget has that.
While responding to this, I also had a look at mkWidgets which has a lot of
the above and more.
L
> and then, that ever elusive, practically impossible to even mention without
> starting a flamewar.... a printing API that is cross-platform. I know that this
> may be quite difficult if not impossible. But even a bare one would be nice.
> Please don't scorn me for bringing this up... <wince>
>
>
<flamethrower value=on level=crisp>
Go!
<flamethrower value=off>
:-)
Check out Bryan Oakley's page. I forget what the URL is but you're a big
boy, now, aren't you? :-)
I suspect there will be few Windows improvements until some more actual, real,
hard core Windows programmers start working on Tcl, Tk, etc. There are
a few of you out there doing a yeoman's job - just as there is a very small
number of Mac/VMS/etc. programmers keeping the Mac port alive.
If users of a particular OS port of Tcl/Tk want better support, then they
need to do recruitment of bodies, provide incentives (praise, finances, other),
and contribute towards the support of their platform.
Hopefully some day we will be able to report an increasing number of
new applications, extensions, tutorials, etc. written by Windows
users/developers.
Cameron Laird wrote:
> In article <8ohfnh$dnn$1...@216.39.170.247>, Dave LeBlanc <whi...@oz.net> wrote:
> >Does QT work on Windows? Has it finally stopped being $$ for
> >commercial use?
> .
> .
> .
> Qt works *well* on Windows.
>
> There is no immediate prospect that Trolltech AS will
> license commercial development packages at no charge.
> Yes, you have to pay $$ to work with Qt under Win*.
>
This is why people don't like Qt. (If they don't like it).
BWidget does _not_ have a multicolumn listbox. BWidget's ListBox has a
-multicolumn switch which allows it to wrap its display into multiple
columns, but it is all one column of data.
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html
Bob Techentin wrote:
> Laurent Duperval wrote:
> >
> > > multi-column listbox
> >
> > There is a Tcl-only one available. Jeff Hobbs says he's working on a C
> > version. Unless he decides to Run... I think thereis one in BWidget but I'm
> > not sure.
>
> BWidget does _not_ have a multicolumn listbox. BWidget's ListBox has a
> -multicolumn switch which allows it to wrap its display into multiple
> columns, but it is all one column of data.
>
> Bob
And I love and use Bryan's combobox and mclistbox widgets. However I am not
impressed with the L&F of Tix and others (no offense) that offer some of the
other features. I'm not complaining that these things don't exist at all....
only that I would like to see them in the core and implemented with better L&F
than the extensions seem to have done so far.
And I was commenting on how it's nice that the Tcl/Tk team is *different* from
*other* development teams. They actually respond to users.
I have to say I'm getting rather tired of the over-impassioned Mr
Paquay. As a matter of principle, ethics and morality, we use
Windoze only as a target system, on sufferance, because it is what the
vast majority of users - by definition naive people - have on their
desktops. If there is a better alternative to Tk, it will take off
at such a rate of knots that everyone will know about it. But there
is a rather sad history of orphaned packages and extensions with
insufficient organisational resource behind them to guarantee a
future.
This is a significant issue for the community. Galloping featurism
can be a nightmare if you have real product to support, that is why
Bwidgets has developed such a following, because it is script-level
only. The good thing about open source is that you can, if
necessary, fix it yourself. The bad thing is if you always have to
fix it yourself, and then keep track of different release numbers, and
cope with asynchronously released extensions and so forth.
Would it not be sensible - as was done with Tk - to have a convention
that all extensions and packages bear the release number of the
version of Tcl with which they are compatible? At the cost of a link
on servers, that would mightily ease the plight of developers. I am
getting increasingly concerned that the effort of keeping up with
release histories is becoming a disproportionate part of my
attentional space. Of course one expects there to be occasional
turmoil when a significant bug appears or a major new feature set is
added. But surely what we all want is a stable basis for doing what
we have to do, with backward compatibility as things move forward, and
some confidence that new features, packages and extensions have a
secure future.
--
Steve Blinkhorn <st...@prd.co.uk>
I intend to make sure that one of my tasks as a member of the Tcl Core
Team is to listen to what people want.
> widgets I would love to see:
> spinbox
Already implemented in 8.4a1.
> multi-column listbox
Jeff Hobbs mentioned that he was working on something like this.
Let's hope the effort bears fruit.
> dials/knobs
I always coded those up myself with the aid of the canvas. Some
examples from the Tcl'ers Wiki...
http://purl.org/thecliff/tcl/wiki/569.html
http://purl.org/thecliff/tcl/wiki/877.html
> combobox
I think that's another one that will be done for 8.4, even if it isn't
there yet.
> a more complete tk_messagebox.... include dialog-ability like
> adding other widgets to it more easily.
Why on earth would you want that? You can easily create your own
custom dialogs using [toplevel] and [wm transient], and the
[tk_messageBox] stuff is there to provide access to the system-
-provided dialogs, which are usually not very flexible. One of the
things about Tk is that creating your own completely new custom
version of some dialog is so easy that you don't need all the fancy
templates that other GUI toolkits provide; those things are really an
indication that the toolkit itself is just too hard to use...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- I have to warn you up front that I'm pretty sure you're full of crap, but
it might still be interesting to see your argument.
-- Bill Newman <wne...@netcom.com>
Oh. Right.
The one in 8.4a1 is based off the one in vu. It is different, but more
powerful, than the BWidgets one.
> > dials/knobs
>
> The vu widgets have that. Hey Jeff, you porting those to Tk or what?
Port to Tk? That's where they already work ;^). It's unlikely that
the dial, pie and barchart widgets would go into the Tk core because
they are not widgets that most people would use. However, a multi-column
listbox, notebook, panedwindow, combobox and spinbox are much more
common UI elements today that deserve being put into the core.
> > combobox
>
> There is a Tcl-only one. BWidget has one.
We're hoping that an official 8.4 version will be available.
> > and then, that ever elusive, practically impossible to even mention without
> > starting a flamewar.... a printing API that is cross-platform.
Cross-platform printing is hard to do right. If you just want
screenshots, that's easy. However, most people don't print out
screenshots, they want to print out the full contents of a widget,
for which the widget defines the structure.
For a text widget, you wouldn't want to print out what you see on
one page, but rather the entire contents in the manner that they
are formatted. For a table widget, you may want only a region, but
you probably want the full cell contents printed rather than being
clipped visually as they usually are on screen.
Hey, I consider myself a Windows user/developer. Win2K is my
desktop machine (ok, one of them, but it's the main one), and I
actually enjoy using it more than a Unix wm now. OK, my setup
is unlike most (virtual wm, exceed, x-mouse, ...), but it's
a very effective work environment.
Eric and I have also spent plenty of time focusing on Windows/Tk
wm and menu issues to try and make things look and work as native
as possible on Windows (there still work to be done).
I am really sorry to be over-impassioned . That's true i had excessive
assertions
and i regret that ...
Perhaps i should be impassive but i can't. You 'll be suprprised to read
that but i work
most of the time with UNIX (OSF1), but through a X emulation because i
need so many tools bound to window$ (Outlook, Office Suite and many more)
and have so many commercial contact with people running Window$ that i have
to
behave like naive people (i am one of them for sure).
I try to make my own "best alternative to TK" because i have to port Unix
apps to
Window$. That's a market issue. When customers don't want a Windows system
(we make big process control apps under OSF1), they want M$ Access, M$ Excel
connnected to it ... So i have them on my desktop.
Regards
.
.
.
>> a more complete tk_messagebox.... include dialog-ability like
>> adding other widgets to it more easily.
>
> Why on earth would you want that?
Uhm, not the way to go, D.
> You can easily create your own
> custom dialogs using [toplevel] and [wm transient], and the
> [tk_messageBox] stuff is there to provide access to the system-
> -provided dialogs, which are usually not very flexible. One of the
> things about Tk is that creating your own completely new custom
> version of some dialog is so easy that you don't need all the fancy
> templates that other GUI toolkits provide; those things are really an
> indication that the toolkit itself is just too hard to use...
>
I think the message here is "I don't wanna build'em myself. I want them
given to me as part of the standard widget set."
Laurent Duperval wrote:
That's fair. I make all my own custom dialogs now, it's just, I have to put the
same freaking 6 or 7 lines of code just to have the base of the dialog. With a
dialog creator like tk_messageBox I can get all that in one line. Now if I could
just add a combobox to it, or a text entry, it would be extremely useful and a
big-time time saver.
Oh, don't get me wrong... it ain't high on my list. It would just be nice.
The combobox, OTOH, is a necessity. (I use Bryan's all-Tcl one right now, and I
understand someone is already working on putting it in 8.4)
No need to. We just have to pack it into the sumo / sdk.
--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
<flippant>
Ever hear of the command [proc] ?
</flippant>
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Oh man (he says, with a pout), I would LOVE a piechart widget.
:(
(http://www.eng.auburn.edu/~doug/second.html#cpupie)
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
do...@eng.auburn.edu
You can get the 'vu' widgets package (which includes the pie)
from Jeff's website at:
http://hobbs.wservice.com/tcl/
Follow the "Compiled Extensions" link.
--Dan
"Donal K. Fellows" wrote:
> (I forget the names for Chinese and Korean texts.)
Han Zi and Hangul, respectively.
The 'Zi' should have a 'U'-shaped diacritical mark over the I, but don't
know how to compose that character in this mailer.
:-)
Kevin
One other thing that skews the numbers is that Tcl is included in a number
of Unix distro's, so for instance the Red Hat or SUSE folks downloaded Tcl
once, but it goes out to quite a number of Linux users. Ditto for Tcl only
on MacOS X, and HP-UX last time I looked, though ironically not Solaris...
This is not the case on Windows.
Jim
> The numbers I heard from Jeff Hobbs was 55% of downloads are of the
> zip file - by inference, Windows users.
>
> The other clue that makes this number interesting is the increasing
> number of Windows users that post on c.l.t.
>
> Dave LeBlanc
>
> On Tue, 29 Aug 2000 12:19:30 -0400, Christopher Nelson
> <ch...@pinebush.com> wrote:
>
>> "Donal K. Fellows" wrote:
>>>
>>> In article <39a41032$0$12...@bru5-newsr2.be.uu.net>,
>>> Olivier Paquay <awak...@yahoo.fr> wrote:
>>>> I 've read that thousands of people have downloaded TCL/TK. I'd like
>>>> to know the part of Windows users among them.
>>>
>>> The last I heard, it was about 60% Windows/40% Unix.
>>> ...
>>
>> That's the ratio of downloads, right? I don't think that (necessarily)
>> reflects
>> the ratio of developers or users. I know I've downloaded Tcl/Tk to my home
>> PC a
>> few times and not DLed UNIX to work as often. But I spent 4-6x as much time
>> working on UNIX at work where there are several other developers working on
>> and
>> with the UNIX versions I've DLed. It's a complicated stat, not easy to
>> understand or extrapolate from.
>>
>> Chris
>> --
>> Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!
>
Well I've seen periodic request for it over time. They may not be high
priority but there has been a demand.
>> > combobox
>>
>> There is a Tcl-only one. BWidget has one.
>
> We're hoping that an official 8.4 version will be available.
>
Uhm... I'm not online at the moment. Since 8.4 is supposed to be a
Tk-oriented release, maybe a list of the widgets that *will* make it into
8.4 final is in order. I don't remember if it's listed on the site or not.
- spinbox (done)
- combobox
- notebook
- panedwindow
- multi column listbox
are the ones that are most often mentioned. I think there should be a hard
thinking session before putting out 8.4 without these widgets. Otherwise the
8.4 release will be considered a failure by many users.
Don Porter wrote:
> Darel Finkbeiner <myt...@mailandnews.com> wrote:
> > That's fair. I make all my own custom dialogs now, it's just, I have to
> > put the same freaking 6 or 7 lines of code just to have the base of the
> > dialog. With a dialog creator like tk_messageBox I can get all that in
> > one line.
>
> <flippant>
> Ever hear of the command [proc] ?
> </flippant>
>
actually, right after I wrote that, I looked at it and thought ... "I should
probably head that off at the pass"... oh, well. Work interferes again.
You know, when you write something out like that it actually helps show you
where you could improve sections of your code. Like... say.. just as an
example: writing a proc for laying out the dialog for you... ;-)
The roadmap for 8.4 is still available from:
http://dev.scriptics.com/software/tcltk/8.4.roadmap.html
All the widgets you mention are listed as is the
tree widget.
I don't think this is currently up to date, because I think
Jeff and Eric are each working on one of these widgets currently,
but their names don't appear next to them.
Of course this roadmap is sort of a 'wish list' for 8.4, and if
not enough people volunteer to help out, there is no guarantee
that everything on the list will be done for 8.4
The only awkward thing about building an undo/redo mechanism into the
text widget is coming up with a mechanism to coalesce single character
insertions and deletions into more sensible-sized chunks (words?)
What I meant was: are they going to be Objectified like all the other Tk
Widgets, etc. There was also supposed to be some kind of framework to build
new widgets. Dunno if that'll be ready in time, though.
Is there a way to take what you've done, generalize it, and turn it into
a loadable extension ala tcllib? Perhaps for a tklib type extension?
This is usually down by consolodating multiple same events
(inserts or deletes, but not mixed) based on minimum time slices.
If they type "hello" real fast, it's a contiguous word. If they
finger-peck it, undo would undo it one letter at a time. That's
a common way to handle such, anyway.
This would imply, of course, that each developer would need to
create a new release every time Tk changed ... even if there were no need
for a change (look how seldom Expect has changed, compared to Tcl!).
Only if one assumes that all developers and users are going to be using
the sumo/sdk .
And if you make that assumption, then of course, that distribution is,
effectively, the core.
> > On 29 Aug, Darel Finkbeiner wrote:
> > > and then, that ever elusive, practically impossible to even mention without
> > > starting a flamewar.... a printing API that is cross-platform.
>
There are many others who would like to see it. It has scored
fairly high in the Oustervote at the last two Tcl/Tk conferences.
> Cross-platform printing is hard to do right.
Yes it is.
> If you just want
> screenshots, that's easy. However, most people don't print out
> screenshots, they want to print out the full contents of a widget,
> for which the widget defines the structure.
>
If you want to print out the contents of a single widget, it
might not be too bad, but what if you want to print a frame
that contains a variety of widgets? For example, let's say
you've defined a form that is a combination of text, label
and entry widgets. How would you print that?
> For a text widget, you wouldn't want to print out what you see on
> one page, but rather the entire contents in the manner that they
> are formatted. For a table widget, you may want only a region, but
> you probably want the full cell contents printed rather than being
> clipped visually as they usually are on screen.
>
True. I think the problem is that when people (including myself)
say we want "printing support" we know what we want as a general
concept, but have not thought out the particulars. Perhaps it
would be a good thing if several of us who really want "printing
support" could work with a member of the TCT to better define the
problem and design the solution. Then the TCT (or some qualified
volunteer) could implement the solution into the core.
Thoughts?
Jeff David
jld...@lucent.com
Of course, Darel didn't say "are NOT actually willing to listen..." - perhaps
Darel was trying to distinguish the tcl developers from some other group,
perhaps housed in the far North Western quadrant of the USA...