Re: [inti] OptionMenu width ?

Jeff Franks wrote:

> You might have to derive your own menu item class and in this class 
> override the on_size_allocate() and/or on_size_request() methods, 
> setting the size request or allocation to the width of the widest menu 
> item. Have a look at these two signal handlers in the dial example.

Ok, I'll try this next time, and I quess this is a Gtk2 limitation ?

> 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 ) {}

Btw. When will you grow tired of using .h af header extention, how about 
.hpp or .hh or just about anything else ? :-)

I look forward to start using it, anyway !

/BL



-------------------------------------------------------
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