XF vs. Vtcl vs. Tkproe for building screens.
wexfordpress
XF is ancient but seems to be fully functional even with the latest
versions of tcl and tk. The interactive tutorial is superb. It takes
too many steps per widget but you can get the job done it appears. No
balloon help on icons.
Vtcl is the most appealing package but very buggy with the latest tcl/
tk. I modified one file (tkcon.tcl) just to get it to run at all.
Error messages occur apparently at random. But I did get a screen
built. Has two simple tutorials. You can visually resize entry widgets
and realign widgets with the mouse. Has balloon help on icons. Mailing
list has no posts since June 2006. Appears to be unmaintained.
Tkproe: Never got anything done with this one. Didn't act the way the
manual said. No tutorial. No balloon help on icons. Enough different
from XF that skills may not transfer.
Verdict: I'll concentrate on learning use XF unless someone revives
interest in Vtcl. If there are other contenders perhaps their
advocates can chime in.
John Culleton
Gerald W. Lester
> I have spent the day diddling with these three packages.
>
> advocates can chime in.
Komodo
Emacs, VI, Textpad, Psedit, Alpha -- or your text editor of choice.
If you invest the same day in doing Tk by hand, I think you will find that
you can achieve at least a good look (if not better) in the same time or
less -- particularly if you are using Gird and Tile (aka ttk).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Kevin Walzer
>
> If you invest the same day in doing Tk by hand, I think you will find
> that you can achieve at least a good look (if not better) in the same
> time or less -- particularly if you are using Gird and Tile (aka ttk).
>
+1 on this. GUI builders aren't necessary in Tk. In fact, I find them a
hindrance--I've never found one that has worked for me as cleanly as
hand-coding my own GUI's. Tk is that clean and easy to learn.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
wexfordpress
> wexfordpress wrote:
> > I have spent the day diddling with these three packages.
>
> > ... If there are other contenders perhaps their
> > advocates can chime in.
>
> Komodo
>
> Emacs, VI, Textpad, Psedit, Alpha -- or your text editor of choice.
>
> If you invest the same day in doing Tk by hand, I think you will find that
> you can achieve at least a good look (if not better) in the same time or
> less -- particularly if you are using Gird and Tile (aka ttk).
>
>
Gird? Did you mean grid?
And where can I learn about Tile?
John Culleton
suchenwi
wexfordpress schrieb:
> Gird? Did you mean grid?
Yes, I'd think so - the [grid] geometry manager.
> And where can I learn about Tile?
General answer to "where can I learn about (Tcl-related) X?" is
http://wiki.tcl.tk/X
:^)
Aric Bills
[snip]
> And where can I learn about Tile?
> John Culleton
I get the impression that Tile is still a bit under-documented,
although I'm sure this will change as Tcl 8.5 nears production status
and as Tile approaches version 1.0. However, there's quite a bit of
information out there, including the manual pages (http://
tktable.sourceforge.net/tile/doc/index.html), and when you get
stumped, you can always post a specific question here. The Tile team
and others with Tile expertise have an outstanding track record for
timely and helpful replies.
Aric Bills
terribly difficult and you have much finer control over both the
appearance and the behavior of the end result.
Bryan Oakley has lots of good advice on writing Tk code; you may want
to browse his tutorials: http://www.tclscripting.com/articles/index.html
For the past few years, whenever I am working on a GUI of any
complexity (i.e. more than two minutes of programming), I code it up
as a Snit widget (sometimes as a Snit widget composed of Snit
widgets). Snit takes care of a lot of the more tedious GUI stuff and
(I think) provides a framework for keeping my GUI code legible and
organized. Maybe others will disagree; I think Snit's a real
timesaver.
Mark Roseman
> Gerald W. Lester wrote:
> > If you invest the same day in doing Tk by hand, I think you will find
> > that you can achieve at least a good look (if not better) in the same
> > time or less -- particularly if you are using Gird and Tile (aka ttk).
> +1 on this. GUI builders aren't necessary in Tk. In fact, I find them a
> hindrance--I've never found one that has worked for me as cleanly as
> hand-coding my own GUI's. Tk is that clean and easy to learn.
If I can tie this thread somewhat into the currently running 2007
edition of the annual thread on marketing..
You're correct that in the long run building GUI's by hand is a better
approach in Tcl/Tk; in fact, one of the strengths is certainly that "in
the long run" for Tcl/Tk is actually very significantly shorter than in
most other mainstream toolkits.
But for people just starting out, an easy to use GUI builder would be a
real asset. Without it, you ask people to climb a learning curve (basic
Tk programming) by staring at an empty file in their editor, while
trying to dig through books, tutorials, etc. If they had a GUI builder,
they'd have plopped a bunch of widgets on the screen, generated code,
and then had a real batch of code for their application on screen, ready
to be incrementally tweaked.
Either way, both approaches will get a newcomer to the same place in a
day or two. But the learning curve in the first approach is steeper,
and if people can't see some quick results, they're more likely to not
proceed at all. I know for example if I'm trying to find a tool to do
some not too huge job, I'll normally grab five or six tools, make a
cursory evaluation and try them out, and then pick, all in a short
period of time. I'm not going to spend half a day on each to learn
enough to get something simple together.
A GUI builder for Tk serves the same purpose as the "scaffolding" in
Rails does in that environment. Programming directly to the underlying
stuff in Rails is high-level and easy, but the scaffolding, which you
end up throwing away, gets you up and running with something real
quickly. Your "real work" starts by tweaking and modifying a rough
shell of your application, not staring at a blank page. It's an easier
entry point.
Tk having a GUI builder helps break down one of those barriers that
prevent people from going further when they first start out. An
effective GUI builder for Tk really would target newcomers; even those
with a few weeks of experience are less and less likely to use it. But
of course, unless someone with the ability to write a GUI builder is
motivated for "marketing" or other reasons, they're likely past the
point of benefiting from one, so no longer have a personal itch to
scratch to create one.
Mark
suchenwi
> But for people just starting out, an easy to use GUI builder would be a
> real asset. Without it, you ask people to climb a learning curve (basic
> Tk programming) by staring at an empty file in their editor, while
> trying to dig through books, tutorials, etc. If they had a GUI builder,
> they'd have plopped a bunch of widgets on the screen, generated code,
> and then had a real batch of code for their application on screen, ready
> to be incrementally tweaked.
One approach that should be "marketed" much more is the Tk demos:
choose one from the selector, watch it, watch the source, modify,
rerun...
Larry W. Virden
>
> Verdict: I'll concentrate on learning use XF unless someone revives
> interest in Vtcl. If there are other contenders perhaps their
> advocates can chime in.
Check the SVN source repository at http://spectcl.sf.net/ - that's
where ActiveState has loaded their contribution to the community.
Kevin Walzer
> If I can tie this thread somewhat into the currently running 2007
> edition of the annual thread on marketing..
>
> You're correct that in the long run building GUI's by hand is a better
> approach in Tcl/Tk; in fact, one of the strengths is certainly that "in
> the long run" for Tcl/Tk is actually very significantly shorter than in
> most other mainstream toolkits.
+1 on this.
>
> But for people just starting out, an easy to use GUI builder would be a
> real asset. Without it, you ask people to climb a learning curve (basic
> Tk programming) by staring at an empty file in their editor, while
> trying to dig through books, tutorials, etc. If they had a GUI builder,
> they'd have plopped a bunch of widgets on the screen, generated code,
> and then had a real batch of code for their application on screen, ready
> to be incrementally tweaked.
Fair enough, but the OP has reported that most of the available GUI
builders don't meet his needs: most are rough around the edges (TkProE)
or in various stages of bit-rot (VTcl). I'm not sure of his take on
SpecTcl or its ActiveState descendant. From my cursory review,
SpecTcl/AS GUI Builder are far more polished and user-friendly than the
others--not surprising, given that both originated as commercial
products with corporate engineering resources behind them (Sun,
ActiveState). But even the ActiveState tool is inadequate: for instance,
it doesn't support Tile!
> Either way, both approaches will get a newcomer to the same place in a
> day or two. But the learning curve in the first approach is steeper,
> and if people can't see some quick results, they're more likely to not
> proceed at all. I know for example if I'm trying to find a tool to do
> some not too huge job, I'll normally grab five or six tools, make a
> cursory evaluation and try them out, and then pick, all in a short
> period of time. I'm not going to spend half a day on each to learn
> enough to get something simple together.
I did the same thing when I was getting started with Tk programming, and
I found pretty quickly that coding a GUI by hand was *easier* than
learning one of the available GUI-building tools, let alone learning to
work around their quirks, bugs and limitations. I find that even AS's
tool is too limited for my needs.
>
> A GUI builder for Tk serves the same purpose as the "scaffolding" in
> Rails does in that environment. Programming directly to the underlying
> stuff in Rails is high-level and easy, but the scaffolding, which you
> end up throwing away, gets you up and running with something real
> quickly. Your "real work" starts by tweaking and modifying a rough
> shell of your application, not staring at a blank page. It's an easier
> entry point.
I understand the appeal of a visual tool. My first exposure to GUI
programming was using Apple's Interface Builder, which is one of the
slickest GUI design tools on any platform. It makes snapping together a
GUI a breeze.
However, it was quite a revelation to me when I saw what could be done
with two lines of code in Tk:
button .p -text "Push me" -command {tk_messageBox -message "You pushed me!"}
pack .p
By comparison, trying to learn how to do this in VTcl or SpecTcl (the
tools I tried when I was getting started) was surprisingly complex.
Eventually, it just seemed beside the point. So I started coding by hand.
>
> Tk having a GUI builder helps break down one of those barriers that
> prevent people from going further when they first start out. An
> effective GUI builder for Tk really would target newcomers; even those
> with a few weeks of experience are less and less likely to use it. But
> of course, unless someone with the ability to write a GUI builder is
> motivated for "marketing" or other reasons, they're likely past the
> point of benefiting from one, so no longer have a personal itch to
> scratch to create one.
The value of a GUI-building tool is directly proportional to the amount
of pain it saves through its use. NetBeans' new GUI-design tool,
Matisse, is reportedly very slick and has become very popular because
writing a Java Swing GUI by hand is painful. It really does simplify and
streamline the process in measurable ways. However, the opposite is true
with a Tk GUI builder in my view: it adds a needless layer of
complexity. I think that's why none of these GUI builders have much of a
user base, let alone a developer base.
If we are talking about a *marketing* issue, I'd like to see the
simplicity of Tk as a selling point. What other GUI toolkit lets you
draw a working widget with two lines of code?
Mark Roseman
have a good GUI builder right now to offer people, and particularly not
one designed for beginners. Right now starting from code is the best
entry point into Tk; my suggestion is that we could (with much effort)
do better.
Mark
Bryan Oakley
> A GUI builder for Tk serves the same purpose as the "scaffolding" in
> Rails does in that environment. Programming directly to the underlying
> stuff in Rails is high-level and easy, but the scaffolding, which you
> end up throwing away, gets you up and running with something real
> quickly. Your "real work" starts by tweaking and modifying a rough
> shell of your application, not staring at a blank page. It's an easier
> entry point.
Excuse my ignorance, Mark, but is the Rails "scaffolding" a visual
drag'n'drop sort of thing, or are they just templates you fill in? (boy
does that make me feel like I'm behind the times!) The reason I ask it
is seems like an apples-to-oranges comparison you just made, if the
scaffolding is just a bunch of templates.
Maybe the right solution for Tk isn't a GUI builder but rails-like
"scaffolding" the user can use. Instead of a blank screen, let's give
the users a "main.tcl" that has all the scaffolding in place for a
menubar, toolbar, main work area, and statusbar.
There most be dozens of variations of that out there on our personal
disk drives, and I know I re-invent that wheel in my sleep at least once
a year it seems. This wouldn't have to be the end-all be-all of
application frameworks, just a good single-file starting point.
I'd certainly be willing to write such a thing and have it added to the
core if people thought it would be a Good Thing.
As for your other points about the benefits of a GUI builder, I agree.
IF tk shipped with one it would definitely help beginners. The problem,
as you pointed out, is that those with the ability to create such a tool
have moved beyond needing one and lack the desire to create one. At
least in my experience, Tk really is much easier to do by hand than with
a pointy-clicky tool. I too easily forget what it was like to be a
beginner.
If we were to jump up and shout in unison "hey, let's create one! rah!
rah!" it would probably fail like most community projects do because the
scope would quickly grow to gigantic proportions and nothing would ever
get finished. But maybe if we changed what we mean by "gui builder" we
can get something done sooner rather than later.
For example, if we could start with the aforementioned "main.tcl" along
with a simple dialog that let you fill in some blanks to define the
menubar and toolbar, would that be good enough?
In other words, do we really need a full blown GUI builder for the
beginners out there or would something that is greatly scaled back but
still visual be Good Enough?
--
Bryan Oakley
http://www.tclscripting.com
Dennis LaBelle
I maintained the XF application for several years before writing the TKproE
application. I still maintain TKproe and use it almost daily.
I have over 20 years programming experience in various languages yet I still
find using a GUI-based TCL/TK builder quicker and preferable to coding by
hand.
So, here are the reasons I see as to why we don't have a great! GUI builder
for TCL/TK. They are listed in what I think is the order of most relevance.
1) Most TCL/TK programmers find the language so easy that a decent text
editor with language-specific highlighting is good enough. I don't quite
agree with this view point but I think it is a very valid one.
2) I get almost no feed back on what improvements TKproE needs! It works
great for my level of expertise but maybe I also think differently than
other programmers. YOU'VE GOT TO GIVE THE PROGRAMMER A FEW CLUES. Saying
that "we could develop a good GUI-based application builder, if we tried"
is meaningless unless you can effectively tell the programmer WHAT features
to build.
3) There are a fair number of TCL/TK extensions that make it difficult
to produce a GUI-based TCL/TK application builder. Extensions like SNIT,
Itcl or Bwidgets can be very difficult to accommodate in an application
builder. TCL/TK extensions are not necessarily written to make the task of
GUI-based code generation easy. Sometimes, using multiple extensions
together really makes this problem quite bad. And if your GUI-based
application builder doesn't support the extension you need you most likely
end up at reason number 1 again.
Anyone have more thoughts on this?
Dennis LaBelle
Larry W. Virden
> wexfordpress wrote:
>
>
> 1) Most TCL/TK programmers find the language so easy that a decent text
> editor with language-specific highlighting is good enough. I don't quite
> agree with this view point but I think it is a very valid one.
I would expect developers to prefer not to change editors - and in
particular prefer to use one editor for all their work rather than
different ones for each language.
>
> 2) I get almost no feed back on what improvements TKproE needs! It works
> great for my level of expertise but maybe I also think differently than
> other programmers. YOU'VE GOT TO GIVE THE PROGRAMMER A FEW CLUES. Saying
> that "we could develop a good GUI-based application builder, if we tried"
> is meaningless unless you can effectively tell the programmer WHAT features
> to build.
I agree with you. This is one thing that seems to occur even with the
core. It is almost as if developers have to read users minds, then
spend 24 hrs a day, 7 days a week writing new code, fixing old code,
etc.
Where's the community spirit, where everyone chips in, provides
feedback, provides bug fixes and enhancements, etc.?
>
> 3) There are a fair number of TCL/TK extensions that make it difficult
> to produce a GUI-based TCL/TK application builder. Extensions like SNIT,
> Itcl or Bwidgets can be very difficult to accommodate in an application
> builder. TCL/TK extensions are not necessarily written to make the task of
> GUI-based code generation easy. Sometimes, using multiple extensions
> together really makes this problem quite bad. And if your GUI-based
> application builder doesn't support the extension you need you most likely
> end up at reason number 1 again.
>
I wonder if it would be worthwhile to have some sort of published
guidelines - a "contract" of sorts - so that widget writers are
encouraged to provide a certain set of features that work a particular
way for GUI builders.
We might get to the point of "plug and play" like VisualBasic, etc.
then.
tclt...@aol.com
now. We don't really bother how the forms or widgets were created we
concentrate more on scripts that would control or validate entry, etc.
In fact toplevels and widgets are created on the fly by simply
clicking on a database table. We don't really see so much of the code
for the toplevel and widget creation. of course you can always
customize widgets scripts but we rarely bother.
You were all very convincing but can you imagine my situation when I
first tried out tcl/tk? If not for vtcl then life would have been very
miserable for me. I tried out tcl not because I wanted to play w/ it
but I promised a client a mission critical program in 8 weeks written
in tcl/tk.
So I think we should have a choice between hand coding and using a gui
tool.
Uwe Klein
> You were all very convincing but can you imagine my situation when I
> first tried out tcl/tk? If not for vtcl then life would have been very
> miserable for me. I tried out tcl not because I wanted to play w/ it
> but I promised a client a mission critical program in 8 weeks written
> in tcl/tk.
In my experience from watching win* users clicking away at
one of the "* Visual Studio" thingies you never get to
learn programatic placements of widgets.
An astonishing amount of time is consumed via fiddling
with the appearance without much aesthetic gains made in
the process.
Seeing other do Motif based guis had always turned me
away from doing graphics stuff.
Enter TclTk:
I started out with some testwidgets to understand
how tclTK looked at things i wanted to do.
Handplacing them was no issue and gave an easy insight
into the realestate management tk does on the screen.
Nowadays I do gui's table driven like:
set items {
0 1 .awidget entry ::textvar "-width 5 -bg lightgreen"
0 2 .bwidget label ::labelvar "-align right .."
}
foreach {row col widget type var extras} $items {
}
using table from blt (imho nicer)
or grid from the tk core to place the items.
uwe
Adrian Davis
Depending on the type of application you are creating - you may find
GRIDPLUS2 useful (http://www.satisoft.com/tcltk/gridplus2/index.html).
Regards,
=Adrian=
Larry W. Virden
wrote:
> tcltk...@aol.com wrote:
> > You were all very convincing but can you imagine my situation when I
> > first tried out tcl/tk? If not for vtcl then life would have been very
> > miserable for me. I tried out tcl not because I wanted to play w/ it
> > but I promised a client a mission critical program in 8 weeks written
> > in tcl/tk.
>
> In my experience from watching win* users clicking away at
> one of the "* Visual Studio" thingies you never get to
> learn programatic placements of widgets.
> An astonishing amount of time is consumed via fiddling
> with the appearance without much aesthetic gains made in
> the process.
>
It seems to me that what we have, on a regular basis, is this type
exchange:
Developer: I am looking for a way to layout a graphical application
screen - what programs are available?
CLT Respondant 1: vtcl, the GUI Builder from Komodo, xf, tkproe
CLT Respondant 2: Most developers prefer to hand code Tk code rather
than drag and drop
Developer: I really want something like Visual Basic
CLT Respondant 3: No, you really don't. It is so much faster and
easier to just use a text editor and code the Tk lines themselves
Developer: No, I really want an IDE where I can drag and drop stuff
and the program helps me code. I am not confident in my tcl skills,
and I really want command completion, built in help, drag and drop so
I don't have to think about place vs grid vs pack, don't have to worry
about pixels, stacked widgets, etc.
CLT Respondant 4: No, really, trust us, worrying about all that stuff
is so much better than letting some program try to do it and do it
wrong
Developer: But I'm looking for a program that does it right
CLT Respondant 5: Hey, I've been working on SuperWhizBang program for
years - it does it all right
CLT Respondant 6: Nah, it generates 3 lines of code more than
necessary and doesn't get the right to left character display required
by Hebrew or the Chinese character handling right, and it doesn't
recognize three extensions I wrote but never released to the public
and it has 12 bugs and typos that I didn't ever tell you about... it
sucks
and so on...
I wonder whether this exchange would work better?
Developer: I am just beginning to learn tcl and want and IDE like
VisualBasic
CLT Respondant 1: we have no visualbasic interface, but check out
programs a, b, c
CLT Respondant 2: but few of us use them - see this page wiki.tcl.tk/
somePage for why
CLT Respondant 3: contact me if you want to try program d, which I am
developing, and see if it helps
Uwe Klein
> It seems to me that what we have, on a regular basis, is this type
> exchange:
> and so on...
>
> I wonder whether this exchange would work better?
You're right!
I was trying to shoot another bird.
The objective was "mission critical" software.
i.e.
required item
low on errors
low on hidden snags
short term fixable
long time maintainable
no marketing requirements
if you are new to a language
a very moderate inital learning curve
as provided by clicky pointy tools
will be detrimental to the quality
of your work.
Having lots of screws to turn in the
(visually produced) gui will detract
from fixing underlying problems.
uwe
Larry W. Virden
wrote:
>
> if you are new to a language
> a very moderate inital learning curve
> as provided by clicky pointy tools
> will be detrimental to the quality
> of your work.
> Having lots of screws to turn in the
> (visually produced) gui will detract
> from fixing underlying problems.
>
> uwe
It might be worthwhile to write up a page about "why using an
automated code generator is a bad thing" (and perhaps advocates could
write a counter-article, on why using an automated code generator is a
good thing) on the wiki, summarizing all the info. Then when someone
does ask the question, we can
point to the page(s) so they can catch up to the community viewpoints.
wexfordpress
> > I have spent the day diddling with these three packages.
>
>
> > manual said. No tutorial. No balloon help on icons. Enough different
> > from XF that skills may not transfer.
>
> > Verdict: I'll concentrate on learning use XF unless someone revives
> > interest in Vtcl. If there are other contenders perhaps their
> > advocates can chime in.
>
> >JohnCulleton
>
> I maintained the XF application for several years before writing the TKproE
>
> 2) I get almost no feed back on what improvements TKproE needs! It works
> great for my level of expertise but maybe I also think differently than
> other programmers. YOU'VE GOT TO GIVE THE PROGRAMMER A FEW CLUES. Saying
> that "we could develop a good GUI-based application builder, if we tried"
> is meaningless unless you can effectively tell the programmer WHAT features
> to build.
>
OK here is some feedback. I just upgraded my tcl/tk installation to
8.5b1. TkProe blew up on a statement in file Tkcon.tcl because my
current version was not exactly 8.5. So I changed that statement and
now it runs, sort of.
The various icons on the top screen have neither titles nor balloons
telling you what they do.
If I name a label widget e.g. ".Labelex" starting with a capital
letter I get a message
"Window starts with an upper case letter 'Labelx' "
Note that I named the widget .Labelx. The window is . and not Labelx.
After I get a label widget on the screen I want to show it on the
current widget path. So I go to the screen, click on label3 with the
right button, and nothing happens to the widget path.
There is no equivalent to the step-by-step interactive tutorial that
comes with XF.
That is about as far as I got with Tkproe. I remember having better
luck with an earlier version.
Obviously I am making beginner mistakes right and left. I suggest that
the first thing that is needed for Tkproe is to modify the XF tutorial
and include it with the prodduct. And that statement in Tkcon needs
to be fixed so that later versions of Tk will work.
JOhn Culleton
Bryan Oakley
> OK here is some feedback. I just upgraded my tcl/tk installation to
> 8.5b1. TkProe blew up on a statement in file Tkcon.tcl because my
> current version was not exactly 8.5. So I changed that statement and
> now it runs, sort of.
>
> The various icons on the top screen have neither titles nor balloons
> telling you what they do.
>
> If I name a label widget e.g. ".Labelex" starting with a capital
> letter I get a message
> "Window starts with an upper case letter 'Labelx' "
> Note that I named the widget .Labelx. The window is . and not Labelx.
That is a limitation in Tk, not in TkProE. Tk won't let you create
widgets with a capitalized first letter.
Larry W. Virden
>
> That is a limitation in Tk, not in TkProE. Tk won't let you create
> widgets with a capitalized first letter.
Seems like it would be a simple edit, then, for tkproe to not attempt
to create the widget with that name.
wexfordpress
Another comment. Tkproe offers a menubar with Icons for various kinds
of widgets. The documentation does not translate each icon into the
corresponding widget. OTOH
XF provides a menu of widgets by name.
Through trial and error I came up with the following names, from left
to right:
frame
canvas
button
entry
label
message
listbox
text
menubutton
menu
vscale
hscale
vscrollbar
hscrollbar
checkbutton
radiobutton
toplevel
labelframe
spinbox
hpanedwindow
vpanedwindow
(tear off the icon bar and make it vertical)
That's 19 standard widgets.
XF has 15 standard widgets, three additional:
barchart
graph
stripchart
and three templates giving additional choices.
Everything has a name.
Tkproe is of course more modern and has choices not available on XF.
But it is less newbie friendly.
John C.
Dennis LaBelle
TkProE, of course, doesn't create the widget. It gives you an error message
pop-window instead. The program isn't crashing. A controlled error message
is provided. I don't see how checking the case of the widget name then
popping up an error message is any improvement over letting TCL/TK generate
an error message and then presenting it in a dialog box.
Dennis LaBelle
In general, I would like to point out that TkProE comes with a 54 page
manual.
Dennis LaBelle
>
> OK here is some feedback. I just upgraded my tcl/tk installation to
> 8.5b1. TkProe blew up on a statement in file Tkcon.tcl because my
> current version was not exactly 8.5. So I changed that statement and
> now it runs, sort of.
This problem seems to belong to Tkcon.
> The various icons on the top screen have neither titles nor balloons
> telling you what they do.
Pages 11 through 15 of the manual document the icons in detail.
A few hours of program use is usually enough to memorize the meaning of the
icons. Adding labels to the icons would increase the size of the Main
TKproE dialog box and be, I believe, a poor trade-off for the benefit of
labels that a user would need for a few hours.
In my experience, users make very little use of balloon descriptions. Most
users don't even realize that the balloon descriptions are there because
they are too impatient to let the mouse stay on the icon long enough for
the balloon help to appear.
>
> If I name a label widget e.g. ".Labelex" starting with a capital
> letter I get a message
> "Window starts with an upper case letter 'Labelx' "
> Note that I named the widget .Labelx. The window is . and not Labelx.
For most TCL/TK errors TkProE simply displays the error message that TCL/TK
produces. That is the case in this example. The error message displayed is
exactly what TCL/TK produces. With this approach, the user can refer to the
TCL/TK documentation itself for the meaning of the error message.
As far as specifying window names, I usually let TkproE generate the names
automatically. I sometimes assign my own names to toplevel windows but
there aren't a lot of reasons to type in your own window names since much
of the window management is handled through the GUI-builder.
> After I get a label widget on the screen I want to show it on the
> current widget path. So I go to the screen, click on label3 with the
> right button, and nothing happens to the widget path.
>
As described on page 24 of the TkproE manual the proper way of changing the
current widget path is:
"...by pressing and holding mouse button 3 while the mouse is on the Current
widget path button, then releasing the mouse button with the mouse
pointer over the desired widget. When mouse button 3 is released, the
displayed widget path will be updated."
> There is no equivalent to the step-by-step interactive tutorial that
> comes with XF.
This is correct. But let me remind you of the 54 page manual.
> That is about as far as I got with Tkproe. I remember having better
> luck with an earlier version.
These "set backs" don't seem harsh. I suggest you look over the TkproE
manual and some of the TCL/TK documentation to help smooth your ride.
> Obviously I am making beginner mistakes right and left. I suggest that
> the first thing that is needed for Tkproe is to modify the XF tutorial
> and include it with the prodduct.
I'll think about it.
I'll have to see whether the old tutorial adds much to what you get out of
doing the "widget tour" that comes with TK.
My favorite XF tutorial parts are the "examples" where the program generates
and configures widgets and shows the necessary dialog boxes to perform the
actions. The text-only portions don't seem to be more informative than
reading a manual.
wexfordpress
> Please see my responses below on the comments made by John Culleton.
>
> In general, I would like to point out that TkProE comes with a 54 page
> manual.
>
> Dennis LaBelle
>
>
>
> Pages 11 through 15 of the manual document the icons in detail.
>
Well, when it comes to widget icons they don't. The action button bar
is well documented. The drop down menus are well documented. The
widget selection bar isn't.
I found a workaround by selecting each icon, writing down the type of
widget, and then canceling the widget call. My list of the 19 icons
and their translations is in another of my posts written Oct 17:
Through trial and error I came up with the following names, from left
to right:
frame
canvas
button
entry
label
message
listbox
text
menubutton
menu
vscale
hscale
vscrollbar
hscrollbar
checkbutton
radiobutton
toplevel
labelframe
spinbox
hpanedwindow
vpanedwindow
(tear off the icon bar and make it vertical)
So I have solved my problem. It would be helpful for the next newbie
if you documented the widget bar as you did for the action button
bar.
Thanks for all you do.
John Culleton
kenpa...@yahoo.com
> On Oct 4, 6:17 pm, wexfordpress <j...@wexfordpress.com> wrote:
>
>
>
> > Verdict: I'll concentrate on learning use XF unless someone revives
> > advocates can chime in.
>
> Check the SVN source repository athttp://spectcl.sf.net/- that's
> where ActiveState has loaded their contribution to the community.
I was the project leader for VTCL for a short time in 2005/2006.
Unfortunatly I started a very demanding job and was unable to continue
working. I did get alot of fixes and bugs worked out. However, there
are still alot to go. I have been doing some work this weekend. It
would help me out alot if you add to our bugs/feature requests/
patches/ etc to the site. I know it looks like they have been sitting
around for a while but I am working through them right now. We may be
able to revive this project yet. I know there was another developer
that was considering contributing to the project. If any one wants to
join let me know. Also, its best to get the CVS version at
vtcl.sf.net. There was a new release v1.6.1a. It addressed alot of
issues and contained alot of fixes we did when I took over the
project. Again, the CVS version now contains some fixes that might be
of use. Personally, I think part of the problem is that no one wants
to release a version until they think it is perfect. I think if we
have something better then what is out there then we need to release.
Anyways, visit the sf.net project sight. I'm chimeing in. We are still
kicking.