Re: Commit: abiwidget stuff

From: Martin Sevior <msevior_at_physics.unimelb.edu.au>
Date: Tue Dec 12 2006 - 01:32:56 CET

On Mon, 2006-12-11 at 18:29 -0500, Dominic Lachowicz wrote:
> > *) We emit a lot of signals. We should streamline abi and/or the
> > widget such that it doesn't emit 20 GTK+ signals every time you type a
> > character or move left/right.
>
> I have an idea for how to do this. Martin and I discussed it on IRC
> yesterday, but I'll flesh it out here.
>
> Emitting a GTK+ signal is pretty expensive. Emitting 40+ of them each
> time the cursor moves is *really* expensive, and really isn't
> indicative of how signals are supposed to work.
>
> What I think we should do is write a class that wraps the
> FL_DocListener.

I think you mean AV_listener (see "src/af/xap/xp/xav_Listener.h")

This is a good idea. It would be nice if we could work out a way to
reuse all the menu and toolbar ID's instead of writing a function for
each, but I can't think of how to do that.

Cheers

Martin

> This class will have a lot of virtual methods to have
> a subclass override, such as "virtual void bold(bool value) {}". It
> will also store AbiWord's state at the current position. I.e. "is it
> bold now?" "what is the font size", and etc.
>
> When we get a FL_DocListener signal, we will see what AbiWord's state
> is vs. our listener's internal state. We'll update the listener's
> state, and then fire those virtual methods as necessary. Our subclass
> will convert this into a GTK+ signal emission, thus minimizing the
> number of GTK+ signals sent.
>
> If I have some spare time in the next few days, I'll implement this.
> If not, don't let this stop you from helping out. This should
> initially be kept private to the AbiWidget, but once it gets a little
> bit of testing, we can hook this up to the menus and toolbars too to
> cut down on the number of times we update the widgets.
>
> Best,
> Dom
Received on Tue Dec 12 01:38:23 2006

This archive was generated by hypermail 2.1.8 : Tue Dec 12 2006 - 01:38:24 CET