[Iup-users] Suggestions

Otfried Cheong otfried.iup at ipe.airpost.net
Fri Oct 5 10:05:39 GMT+3 2007


Antonio Scuri wrote:
>   dpy = (Display*)IupGetAttribute(ih, "XDISPLAY");
>   wnd = (Window)IupGetAttribute(ih, "XWINDOW");
>   XGetWindowAttributes(dpy, wnd, &wa);
>   visual = wa.visual;
> 
>   You will need only X, no need for Xt.

This works very well, thanks!

> void IupUpdate(Ihandle* ih)
> {
>   if (ih->handle)
>     XmRedisplayWidget(ih->handle);
> }

This also seems to work - but I'm surprised that it should be necessary 
to use a function from the X Print extension for a normal GUI task? 
I've also tried XClearArea (see 
http://www.faqs.org/faqs/motif-faq/part6/section-2.html), which also 
seems to work but sometimes flickers considerably.

I've started working with IUP about a week ago, and generally found it 
quite pleasant and intuitive - except for the updating of widgets.  This 
is the only thing so far that caused me trouble when porting my 
application to Lua/IUP (from Qt).

In other toolkits, the "update" method only marks the widget as 'dirty' 
and needing a redraw.  In Qt, for instance, "update" only schedules a 
paint event to happen when Qt returns to the main event loop.  Several 
"update" calls therefore generate only one call to the paint callback.

For instance, I have a specialized widget with several methods for 
setting zoom, panning, changing contents, etc.  Each method calls 
"update" internally.  In my client code, I would typically call several 
of these methods, e.g.

   canvas->setZoom(2.0);
   canvas->setPan(300, 400);
   canvas->setPage(...);
   canvas->setZoom(....);

All this only causes one redraw, when the system returns to the main 
loop.  You can imagine how astonished I was that IUP immediately redraws 
the widget inside each of these setXXX methods.  I had to take the 
internal "update" out of each method, and call it from my client code:

   canvas->setZoom(2.0);
   canvas->setPan(300, 400);
   canvas->setPage(...);
   canvas->setZoom(....);
   canvas->update();

Even this is not optimal, since there may be further changes before the 
program returns to the main loop, and unnecessary redraws are done.

Is there a good reason why IUP does it this way?  For instance, why does 
IupUpdate in the Windows driver use the RDW_UPDATENOW flag?  (I tried to 
take it out and my program still seems to work - but perhaps some of the 
extra controls rely on this?)   In any case, it might be a good idea to 
mention this fact in the documentation.

Best wishes,
  Otfried




More information about the iup-users mailing list