Hi Michael,
On Tue, Aug 19, 2008 at 1:38 AM, Antje <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Michael,
thanks a lot for your answer.
On Mon, Aug 18, 2008 at 6:56 AM, Antje
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
Hello,
I try to develop a GUI with gWidgets (TclTk) but I guess my
little
application already starts to be messy...
First question: How shall I handle updates of widgets
triggered by
event handling? So far, I simply took the widget-object I want to
update as a global variable but that's not a good style. Any
suggestions how to handle this?
It's possible to specify a "user" object when registering the
callbacks, I think. The "user data" is then passed as the last
parameter to the handler. Another good way to control the
scoping is nesting environments (e.g. through closures). That
is, your object does not need to be global (in the workspace)
but it can be in a parent environment. In fact, global variables
won't even work when you put your code into a namespaced
pacakge, because the namespace will be locked.
Can you give me a simple example, please? I'm not sure if I
understand correctly how this can work. (Or maybe there is already
some kind of documentation I can check for these possibilities...)
There's documentation and examples in the help for addHandler. It's the
"action" parameter.
And what about the "nesting environments"? I'm not sure if I'm aware of how
this works exactly (I know, that's rather poor... but maybe you can give me a
simple example?)
Second question: What are my possibilities to stay flexible? For
example: I though it makes sense to use a gpanedgroup for a
checkboxgroup with variable number of items (to make it
scrollable
if it's getting too large). But this does not work like I thought
and the items simply disappear at the end of the panel.
I don't think the paned group is what you want here. Split paned
widgets are to allow the user to control the allocation of space
in a GUI, usually in either the horizontal or vertical
directions. If you're GUI is growing too large, you'll need to
make it so that only a portion of the GUI is visible at once.
One way to do that is with scrolled windows. See the
use.scrollwindow parameter for ggroup().
Oh, thanks a lot. I was not aware of the scrolling opportunity if
the ggroup.
Third question: How to structure the GUI? Builing, Sizing,
Arraging,
filling with content (not every object has some initial content).
For example, I realized that I have to set the svalue for the
gpanedgroup after adding the objects.
Well this is an art and depends on your GUI. Split panes are
difficult in that they require one to specify a numeric value
for the split position. This is a similar problem to specifying
the initial size of a window.
Is there anything I can do beside, setting a fixed size with pixel
values?
For example if I'd like to initially maximze the window... (I know
that it's possible with TclTk).
I am not that familiar with tcl/tk but in general UI toolkits require
you specify pixels for positions of things like that. If it's not so
important for the user to be able to adjust the layout, why not just
skip the paned widget? They're rarely very helpful.
Hmm, I will use it for one case (where it's really useful). But currently, I
have problems to "activate" the scrolling for a ggroup...
The simplest way is just to guess a good initial position. This
is usually not too bad. Adjusting the split automatically might
not be a good idea, since it should be under the control of the
user.
Of course, I just set it initially.
Ciao,
Antje
I don't know, but I have the impression to create my GUI quite
unstructured and I'm afraid to loose overview soon...
The small examples for the usage of different components are very
useful but I'm looking for some hints on how to create a more
complex application (what to do when and how).
Thanks a lot for every tip!
Antje
_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
<mailto:R-SIG-GUI@stat.math.ethz.ch>
<mailto:R-SIG-GUI@stat.math.ethz.ch
<mailto:R-SIG-GUI@stat.math.ethz.ch>>
https://stat.ethz.ch/mailman/listinfo/r-sig-gui
_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-gui
