On Fri, 04 May 2001, Philippe Ney wrote:
>
> Hi Micah,
>
> I currently try to improve the display speed.
> And have then the following remarks/questions
>
> 1)handler event
>
> A handler could be attached to a widget only
> with a PG_WE_ACTIVATE flag, that mean we have to
> 'DOWN then UP' on the same widget to activate it
>
> Q: what are the possibility to activate a widget
> with using just a PG_WE_PNTR_DOWN?
This is already possible, and is used to create drop-down menus. For example, here's
an excerpt from menutest.c:
---------8<---------
pgNewWidget(PG_WIDGET_BUTTON,0,0);
pgSetWidget(PGDEFAULT,
PG_WP_TEXT,pgNewString("String"),
PG_WP_SIDE,PG_S_LEFT,
PG_WP_EXTDEVENTS,PG_EXEV_PNTR_DOWN,
0);
pgBind(PGDEFAULT,PG_WE_PNTR_DOWN,&btnMenuFromString,NULL);
---------8<---------
This is to create one of the buttons on the toolbar, used for launching popup menus.
PG_WP_EXTDEVENTS is used to set the button's 'extended events' mask, indicating that
the app wants a pointer-down event. Finally, pgBind binds to PG_WE_PNTR_DOWN instead
of PG_WE_ACTIVATE.
I don't really like this method though. I'd rather have a way for the client library
to tell the server which events are bound automatically. It would also be nice to
have something more generic, rather than coded into the button widget.
>
> 2)button refresh
>
> When a button is selected, it is automatically
> redraw (as the previous selected one).
> But this is necessary only if the used theme
> contain display differences between objects
> button and button.on
>
> Q: what are the possibilities to NOT redraw buttons
> when the selected one change?
> Maybe depending if theme define or not button.on
> Could you also point me to the code that make the
> redraw
Yes, this is something that needs fixing. Another way to see this same problem, is to
press CTRL-ALT-U to clear the screen blue, then put your mouse over a button. It
redraws the button, even if the theme doesn't define it.
Because of the hierarchial nature of the themes, button.on will be defined even if
it's the same. The way to test it is by comparing the handles of button's fillstyle
and button.on's fillstyle.
-- To give you a little background on how the button is redrawn:
The input driver calls dispatch_pointing(), located in widget/widget.c
This function handles the medium-level (between driver and widget) tasks like figuring
out which divnode was clicked in, transforming coordinates, and (hence its name)
dispatching it to the widgets or clients that need to know about it.
dispatch_pointing() calls send_trigger(), also located in widget/widget.c
This is a simple function that does a little sanity checking then passes a 'trigger'
for the input on to the relevant widget's trigger function. (using a function pointer
table)
In this case, it would call button_trigger(), in widget/button.c
button_trigger manages the internal state of the button, and when necessary calls
post_event() to send an event to the client. It decides which theme object to render
from. (it's 'state') In this case it will be PGTH_O_BUTTON, PGTH_O_BUTTON_HILIGHT, or
PGTH_O_BUTTON_ON. Other widgets based on button, like menuitem and checkbox, modify
this.
button_trigger() calls div_setstate(), in theme/memtheme.c
This currently just changes the 'state' variable in the divnode, then triggers the
necessary updates. This means calling div_rebuild() to generate a groplist for the new
state, then if the widget is in the top layer it calls update() to actually draw it to
the screen.
div_rebuild(), in theme/memtheme.c, clears the divnode's current groplist
and calls its 'build' function to generate a new one. In this case, the build function
is build_button(), in widget/button.c. It does many things, including calculating the
position of everything, running the 'bgfill' theme property for the current state
through the fillstyle interpreter, and making gropnodes for the button's text and
bitmap.
update() notices the redraw flags on the button's divnode, and sends its groplist to
the rendering engine.
-- Solution
I finally figured out a workable way to implement this, and I just committed it to
CVS. Here's a comment from div_setstate():
/* Try to determine if the new state and old state look exactly the same,
* and avoid redrawing if possible. This isn't as easy as I thought it would
* be. Simply comparing the fillstyle handle for both state's bgfill
* properties didn't work, as most themes use changes in color, bitmap,
* or other parameters to indicate state changes. The next thing that comes
* to mind is to check whether the theme object is exactly the same. This
* doesn't work either, because due to the hierarchial nature of the theme,
* different theme objects may be used for different properties.
*
* Though I don't think it's optimal, this is the best method I could come
* up with. (and it seems to work pretty well) It uses the trace_thobj()
* function (defined above) to check whether the new theme object is any
* different than the currently selected theme object.
* trace_thobj() finds the theme object as high as possible in the theme
* hierarchy that will act equivalently to the specified theme object.
*/
>
> -philippe
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/pgui-devel
--
To the systems programmer, users and applications server only to provide a
test load.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
