Re: [inti] OptionMenu width ?

Bo Lorentsen wrote:

>
> Hmm, ok so connecting the proxy classes, are not the most expensive 
> thing to do, I agree.

Not proxy classes, static proxy functions. The proxy classes are those 
things returned by calls to one of the sig_something() functions.

>
> About the cost ! When I make a new Inti Widget I also make a 
> WidgetClass instance too. 

No you don't. A WidgetClass is never instantiated, not by the library 
and not by an application. Only the static functions declared in the 
WidgetClass are used, in the same way as if they were in a namespace. I 
could replace "class WidgetClass" with "namespace WidgetClass" and the 
result would be the same. No overhead incurred.

> This does not include unused virtual tables anymore, nor the cost of 
> calling these, nice !
>
> But, the _proxy functions now do a "dynamic_cast" (on each signal)

Yes, but only on the signals you explicitly inherit from. For example:

class MyEntry : public Gtk::Entry, public Gtk::EntrySignals
{
};

I sent you the new entry files. In EntrySignals there are only three 
virtual functions. That's it. If you don't inherit from WidgetSignals 
also then your over head is maximum of three dynamic_casts but not all 
the signals will be emitted at the same time. The only one emitted over 
and over in Entry is "insert_at_cursor".

The reason I moved the virtual signal handlers out of the widget classes 
was this - most of the time you connect widgets to signals inside the 
parent window's or container's constructor using the sig_something() 
functions. These connection functions have nothing to do with the 
virtual signal handlers. They're a completetly separate entity. The only 
reason the override a virtual signal handler is when you want implement 
some custom behaviour and need to derive your own class. It seemed a bit 
excessive to me having all those virtual functions in a huge virtual 
function table (one for every widget) when usually you wont use many of 
them at all. Now, you can  use only those few you actually need and 
disregard the rest.

I guess it is a design issue. Your original idea was to only use those 
signals you need, and you mentioned Java and inheritance. The only way I 
could implenment anything remotely like that was like this. If it turns 
out that I was wrong, and it actually slows things down or increases an 
applications memory footprint I will get rid of them. From my testing 
though, compiling and running applications does seem faster.

>  including all the RTTI mombo jumbo, and the "default" action code, 
> ends up as redundant code (both in the Signals and Class functions) 
> :-( Or, have I again failed to understand ?
> As a last detail. If I liked to make a common Buttom action handler 
> (no good reason comes to my mind, yet), for more than one buttom at 
> the same time, I need to connect my own function and not using the 
> Signals class, so tricks like this will not work :
>
> class MyModal : public Dialog, ButtonSignals
> {
>    Button m_bnt1, m_btn2:
>
>    void on_activate( void ) {
>       cout << "A buttom have been pressed" << endl;
>    }
> }
>
No it wont. But that's the point  I made above.  You should only 
override a virtual signal handler when you want to modify default 
behaviour, like the GDK events on_configure() and on_expose(). Whether 
you modify default behaviour through your own signal handlers or by 
overriding virutal signal handlers is an application design issue. I 
guess I would do it like this. If I was implementing some new behaviour 
in my own derived widget I would tend to override virtual signals 
handlers. When I was using this widget I would connect to signals 
through the sig_something() functions.

BTW the signal classes are only meant to be inherited by the associated 
widget. Only a Button can inherit from ButtonSignals. A dialog is not a 
button.

Jeff Franks.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click