As I got fed up with manual placement with the gridder it came to my mind
that I once used SpecTcl for that purpose so I went over to
http://spectcl.sourceforge.net just to find out that I was not able to
download the code nor browse the cvs tree nor check it out.
Does anybody here have any knowledge what happened and how this can be
solved? Or if anybody has one of the tar.gz files available he or she would
do me a favour by making it available for download for a short period of
time.
Regards,
--
Svenn
Michael
Out of curiosity, what is it you find difficult about using grid?
Perhaps there is a hurdle we can help you overcome.
--
Bryan Oakley
http://www.tclscripting.com
Bryan Oakley wrote:
> Michael Schlenker wrote:
>> Svenn Are Bjerkem schrieb:
>>
>>> Hi,
>>>
>>> As I got fed up with manual placement with the gridder ...
>
> Out of curiosity, what is it you find difficult about using grid?
> Perhaps there is a hurdle we can help you overcome.
>
I'll agree with Bryan here, I fond that using the shorthand
notation for gridding the display in one block after all widget
creation is simple and straightforward, and provides a somewhat
self document ascii version of your layout right in the code itself
Bruce
> As I got fed up with manual placement with the gridder it came to my
> mind that I once used SpecTcl for that purpose so I went over to
> http://spectcl.sourceforge.net just to find out that I was not able
> to download the code nor browse the cvs tree nor check it out.
CVS doesn't seem to work, but I downloaded the tarball
(SpecTcl1.2a3.tar.gz) fine. No idea whether it still works, but it
probably does.
> Hi,
>
> As I got fed up with manual placement with the gridder it came to my mind
> that I once used SpecTcl for that purpose so I went over to
> http://spectcl.sourceforge.net just to find out that I was not able to
> download the code nor browse the cvs tree nor check it out.
Alternatively, you can download SpecTcl's extension to include Tix
widgets, called SpecTix. It is available here:
http://starship.python.net/crew/mike/src/Spectix/Spectix.html
It allows to do the same things as SpecTcl. Only the look changed a bit.
HTH
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
> CVS doesn't seem to work, but I downloaded the tarball
> (SpecTcl1.2a3.tar.gz) fine. No idea whether it still works, but it
> probably does.
Which sourceforge mirror did you use? The ones that I tried just restarts
and restarts and in the URL there is something about a malfunctioning
mirror.
--
Svenn
> Out of curiosity, what is it you find difficult about using grid?
> Perhaps there is a hurdle we can help you overcome.
>
Hi Bryan,
nice of you to ask. I don't find the way grid is working difficult. I find
_remembering_ how grid is working difficult. This does not isolate to grid,
but becasue I use it less often than the packer, I tend to forget more
easily.
If you can help me remember how the grid command is working so that I do not
have to read the manual every time I want to compose a GUI it would be
fine. I think the user manual is pretty useless as a memory aid as it does
not contain many working examples. I do not have access to the net all the
time and cannot rely on the wiki. (which is about to have too much info to
be able to do a quick search and get useful answers, but this is a
different topic)
Contrary to many hard-core Tcl'ers on this group, I like to use tools to lay
out a GUI, and I like them to keep their data separate from my code.
Simply because it is a help to remember and get things done. The Qt
designer is a nice example, can also be used with PyQt and then there is
Eclipse which give a more or less standardized programming interface
between quite a few programming languages. I am working as an electronics
engineer and am not paid for programming even if I feel I am. I have to
program or understand programs (because of bad documentation) in: perl,
python, tcl, lisp, c, bash, csh , java and then there is VHDL and Verilog
in both digital and AMS versions, then there are a well of simulator
control languages not standardized to anything.
If I can have a graphical tool that help me organize at least one of these,
I would be happy. I am a great believer of David Allen and his Get Things
Done and I feel that as soon as I can let some specific knowledge go,
because I know how to reproduce it safely after some time without the need
of keeping this in my head, I can concentrate a lot better on my core task
which is circuit design.
Is this a reason that sounds reasonable to you?
--
Svenn
> Bruce Stephens wrote:
>
>> CVS doesn't seem to work, but I downloaded the tarball
>> (SpecTcl1.2a3.tar.gz) fine. No idea whether it still works, but it
>> probably does.
>
> Which sourceforge mirror did you use?
Kent.
> The ones that I tried just restarts and restarts and in the URL
> there is something about a malfunctioning mirror.
Probably that mirror is broken, then.
In the past there have been discussions from people who were going to
submit updates to specific man pages providing examples where they were
most needed. I wonder whether anyone has considered doing this for
grid.
Another useful idea might be to provide some additional demo examples,
or possibly information towards a Tk tutorial that would really be
useful to include in the Tk extension.
In a different discussion, but branching from your remarks, you say:
> [...] I like them to keep their data separate from my code.
Can you describe what you have in mind here? I'm curious about the
behavior you would find useful.
Finally, you mention that you find locating things on
http://wiki.tcl.tk/ difficult.
http://wiki.tcl.tk/4056 is a place where people have been gathering
information on tools for building GUIs. I don't know if all relevant
tools are listed there, but there are a dozen or so there.
Ah! On that point I can commiserate. When grid first came out I was in
the same boat. It's only in the past year or so that I started regularly
using grid. I don't know why, but something about grid makes it hard
for me to remember. Or maybe I just didn't like to have to grid
something in one statement and then add a bunch of columnconfigure and
rowconfigure commands.
Now I have no problem with it, but for whatever reason I was slow to
pick it up. I still find myself re-reading the man page from time to
time. Weird.
> If you can help me remember how the grid command is working so that I do not
> have to read the manual every time I want to compose a GUI it would be
> fine.
Practice, practice, practice
The only thing that worked for me is to start to use grid more frequently.
> I think the user manual is pretty useless as a memory aid ...
> Contrary to many hard-core Tcl'ers on this group, I like to use tools to lay
> out a GUI, ...
> If I can have a graphical tool that help me organize at least one of these,
> I would be happy...
>
> Is this a reason that sounds reasonable to you?
Absolutely.
"I'm fed up with grid" could have meant a lot of things. It could have
meant "I just don't understand it" or "I have trouble laying things out
in grids" or "I find the man page confusing". Those we can help with. In
your case you meant "it's just not the way I want to work", which is a
very good reason to search out automated tools.
> Hi Bryan,
snip..snip
.
.
> Contrary to many hard-core Tcl'ers on this group, I like to use tools to
> lay out a GUI, and I like them to keep their data separate from my code.
> Simply because it is a help to remember and get things done. The Qt
> designer is a nice example, can also be used with PyQt and then there is
> Eclipse which give a more or less standardized programming interface
> between quite a few programming languages. I am working as an electronics
> engineer and am not paid for programming even if I feel I am. I have to
> program or understand programs (because of bad documentation) in: perl,
> python, tcl, lisp, c, bash, csh , java and then there is VHDL and Verilog
> in both digital and AMS versions, then there are a well of simulator
> control languages not standardized to anything.
>
> If I can have a graphical tool that help me organize at least one of
> these, I would be happy. I am a great believer of David Allen and his Get
> Things Done and I feel that as soon as I can let some specific knowledge
> go, because I know how to reproduce it safely after some time without the
> need of keeping this in my head, I can concentrate a lot better on my core
> task which is circuit design.
>
Go to http://tkproe.sourceforge.net/ and take a look at TKproE. It's an
interactive GUI builder for TCL/TK written in TCL/TK. It reads existing
TCL/TK programs and generates TCL/TK output.
I played with it for one project and finally got it to work. It's definitely
got some quirks, but the big thing was that it seems very oriented towards
posting multiple top-levels. I may have missed something, but it was finally
easier to lay all my screens out as separate top-levels and make sure they
popped into the same space than adjusting the contents of one main window
as I had really wanted.
Ted
>> [...] I like them to keep their data separate from my code.
>
> Can you describe what you have in mind here? I'm curious about the
> behavior you would find useful.
Ok. Take for example vtcl, the attempt to create a visual application
builder. The application code also contains stuff that vtcl needs to work
in such an extent that I hardly recognize my own parts. And the biggest
problem is that vtcl does not solve my problem.
When I recall spectcl correctly, it keeps its data in a file separate from
the resulting tcl script. This has the drawback that you need to have the
original *.ui file and spectcl in order to modify the UI, but you don't
have to. A quick fix can still be done in the resulting tcl file and later
the *.ui can be updated. When looking at the way Qt-based gui building
works, the use of *.ui files is no serious set-back, otherwise there would
be a lot less applications using this approach.
And there are a lot of examples on the wiki on ways to generate guis from
file, which is nothing different. The question is just how these gui
description text files are generated. I expect it to be difficult to take a
Qt *.ui file and translate it into Tk widgets as the widgets are so
different, but the *.ui is XML and Tcl is good at XML ...
It is very easy to write user interfaces directly in Tk. With little code a
lot can be done, but as with any code, sooner or later organizing and
re-organizing becomes a hassle.
>
> Finally, you mention that you find locating things on
> http://wiki.tcl.tk/ difficult.
> http://wiki.tcl.tk/4056 is a place where people have been gathering
> information on tools for building GUIs. I don't know if all relevant
> tools are listed there, but there are a dozen or so there.
I regularly look at the gui builders page. I regularly try out the tools
just to make sure that I haven't overlooked anything.
Kind regards,
--
Svenn
> Practice, practice, practice
>
> The only thing that worked for me is to start to use grid more frequently.
>
I guess that is the only real solution to any problem, but programming isn't
my main job so I don't get refreshed often enough.
>> I think the user manual is pretty useless as a memory aid ...
>> Contrary to many hard-core Tcl'ers on this group, I like to use tools to
>> lay out a GUI, ...
>> If I can have a graphical tool that help me organize at least one of
>> these, I would be happy...
>>
>> Is this a reason that sounds reasonable to you?
>
> Absolutely.
>
> "I'm fed up with grid" could have meant a lot of things. It could have
> meant "I just don't understand it" or "I have trouble laying things out
> in grids" or "I find the man page confusing". Those we can help with. In
> your case you meant "it's just not the way I want to work", which is a
> very good reason to search out automated tools.
I see that being fed up has more meanings. Maybe I was also a bit "emotially
upset" about having to read something that I know I have already read.
--
Svenn
> Go to http://tkproe.sourceforge.net/ and take a look at TKproE. It's an
> interactive GUI builder for TCL/TK written in TCL/TK. It reads existing
> TCL/TK programs and generates TCL/TK output.
I have been using this from time to time, but it take some time to get used
to it. I also did not get along with XF for some reason. I will surely give
it a try from time to time.
Kind regards,
--
Svenn
> Larry W. Virden wrote:
>
>>> [...] I like them to keep their data separate from my code.
>>
>> Can you describe what you have in mind here? I'm curious about the
>> behavior you would find useful.
>
> Ok. Take for example vtcl, the attempt to create a visual application
> builder. The application code also contains stuff that vtcl needs to work
> in such an extent that I hardly recognize my own parts. And the biggest
> problem is that vtcl does not solve my problem.
>
I also found the "extra" code generated by GUI builders such as vtcl and XF
distracting. I wrote TKproE so that this kind of code is almost
non-existent in the TKproE generated output.
>>
>> Finally, you mention that you find locating things on
>> http://wiki.tcl.tk/ difficult.
>> http://wiki.tcl.tk/4056 is a place where people have been gathering
>> information on tools for building GUIs. I don't know if all relevant
>> tools are listed there, but there are a dozen or so there.
>
> I regularly look at the gui builders page. I regularly try out the tools
> just to make sure that I haven't overlooked anything.
However, the tools will not get much better if you don't give some specific
feedback to the developers.
As the developer of TKproE, I am amazed at how little feedback I have
received on the program.
I would be interested in knowing any difficulties you have had with TKproE.
Dennis LaBelle
As the author of TKproE, I would be interested in having you describe what
you consider to be quirks in the program. It would be helpful in creating a
better product.
Have you looked at the "forget" option for the pack, grid and place
commands. Each of the geometry managers allow you to hide and redisplay
complex widget hierarchies. This would allow you to manage the contents of
a single single window fairly easily. I have used this technique myself
several times.
Dennis LaBelle
Hmm, it's been a while at this point. I see that I had a problem with
TP_InfoGetHomeDir, and finally just edited it manually to return the dir
where I had extracted the zip file. Also I seem to remember that the
files being in DOS CR/LF format caused me some problem on FreeBSD though
I can't remember why right now.
I seem to remember that when my functions got saved, the formatting got
changed from what I had originally used and that there was some sort of
problem where I had to add an extra line or what I entered wouldn't be
saved.
Sorry to be so vague, as I say, it eventually did do the trick for me,
and doubtless some of my problems were headspace on my part.
Ted
> However, the tools will not get much better if you don't give some
> specific feedback to the developers.
I can perfectly understand. I have very little to contribute with right now.
I once experienced with vtcl that the development just stopped during the
phase when I was trying to learn to use it.
>
> As the developer of TKproE, I am amazed at how little feedback I have
> received on the program.
I think the reason for my part is simple: I gave up too early because it is
too easy to write quick-and-dirty code directly in tcl.....
>
> I would be interested in knowing any difficulties you have had with
> TKproE.
>
I'll stop talking, pick it up and use it for some time.
--
Svenn
Robert
From what I understand ActiveState's GUI Designer (based on SpecTcl) is
a proprietary project. The sources aren't available.
BTW SF has been having cvs problems.
-George
SpecTcl seems to be alive and well at http://spectcl.sourceforge.net/.
I use it all the time.
> SpecTcl seems to be alive and well at http://spectcl.sourceforge.net/.
> I use it all the time.
Yes, when I changed to the kent mirror, I was able to download it. Still a
nice piece of software.
--
Svenn