Re: [inti] OptionMenu width ?

Bo Lorentsen wrote:

> Jeff Franks wrote:
>
>> Well... I've finished updating the Inti 1.2 source code to the new 
>> changes. This includes separater signal classes, small inline 
>> functione, and of course the big one - using libsigc2. At the moment  
>> I'm working on adding the new GTK 2.4 widgets. If you want to see 
>> what changes I've made to the exisiting code Gtk::Entry is a good 
>> example so I've attached its files. All the other classes follow the 
>> same layout pattern. notice that the signal arguments that you 
>> connect to are now wrapped, and there are no G::Signal0<> and 
>> G::Signal1<> etc. It's all just G::Signal. Notice how if you don't 
>> want to derive your own widget class but instead just connect to a 
>> standard widget, like Gtk::Entry, you don't inherit all the virtual 
>> function bagage from every parent widget in the hierarchy. If you 
>> want to derive your own widget and override one or more of its 
>> virtual signal handlers you have to explicitly inherit from the 
>> widgets signal handler class. For example:
>>
>> class MyEntry : public Gtk::Entry, public Gtk::EntrySignals
>> {
>> ...
>> }
>>
>> Not exactly your idea but it's as close as I could come within the 
>> limits of GTK.
>
>
> I think this will do just fine to remove unnessesary runtime overhead, 
> and it keeps the API simple (smaller), I like it ! But why don't the 
> signal class automaticly connect its signals as part of its 
> constructor ? like this
>
> EntrySignals::EntrySignals( Entry &entry )
> {
>    entry. sig_populate_popup().connect( slot( this, 
> &EntrySignals::on_populate_popup ));
>    entry.sig_activate().connect( slot( this, 
> &EntrySignals::on_insert_at_cursor ));
>    entry.sig_insert_at_cursor().connect( slot( this, 
> &EntrySignals::on_activate ));
>    // disconnect in destructor too !
> }
>
> Why else would I like to use this class ?
>
> Your constructor would then look like this :
>
> MyEntry::MyEntry() : EntrySignals( this ) {}
>
Each widget class has two completely different ways to respond to a GTK 
signal. You can connect to it using the proxy signals (e.g. 
sig_clicked() in Gtk::Button). This method does not require you to 
declare your own class, you can just use one of the standard widget 
classes, "out of the box" so-to-speak. The other way is to derive your 
own class from  a standard widget and override one or more of its 
virtual signal handlers. The thing about these virtual signal handlers 
is that they're already connected. you don't need to explicitly connect 
to them. That's what all the _proxy functions are for in the soucre (cc) 
files. The logic behind moving all the virtual signal handlers into an 
interface class that needs to multiplley inherited is that it removes 
the memory slug for all those widgets that you don't need all those 
virtual functions. If you are going to write this

class MyEntry : public Gtk::Entry
{
};

surely it's not too much effort to write this instead:

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

If you are deriving you own classes then I think you should override the 
virtual signal handlers since they are already hooked into the GTK 
signal emission system. You get them for free.

> Btw. When will you grow tired of using .h af header extention, how 
> about .hpp or .hh or just about anything else ? :-)
>
I've never seen a major library that ever uses this file extension, only 
the odd program. If you remember my reason for not previously using 
inline functions then I suppose there is no reason why I shouldn't use hh.

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