On Tue, Aug 19, 2008 at 1:38 AM, Antje <[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]>> 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. > > >> 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. > > 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> >> https://stat.ethz.ch/mailman/listinfo/r-sig-gui >> >> >> > > [[alternative HTML version deleted]] _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-gui
