[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UIControl draft implementation
From: |
John Swensen |
Subject: |
Re: UIControl draft implementation |
Date: |
Mon, 1 Nov 2010 11:11:12 -0400 |
On Oct 31, 2010, at 2:07 PM, Michael Goffioul wrote:
> Hi,
>
> In attachment, you'll find a draft implementation of UIControl support.
> Note that this is only about the required support in octave itself. A big
> part of the job is to be done in the backend, and this patch does *not*
> implement the FLTK part (I'm using the GTK+ backend as test backend).
>
> This patch still requires some additional dev work (changelog entries,
> user-level uicontrol function...), but this will take time as I need to rebase
> my patch against current octave and recompile the whole stuff. So I post
> the patch mainly to get feedback and comments, in case I'd need to
> rework other parts.
>
> The main ideas of this patch are:
> 1) add uicontrol class
> 2) let a backend decide which objects it is interested in (return value
> of base_graphics_backend::initialize())
> 3) add event-specific mutex in gh_manager to avoid dead-lock between
> octave and a threaded backend
> 4) add more threading code to support a threaded backend
>
> Michael.
> <uiobject>
I looked over this patch, but before I patch and build, I have a few questions:
1) How does this mesh with the recent discussion and work done to make uimenu
work with the FLTK backend? Is there some duplicate work, or conflicting
portions of the two implementations? It seems that the patch you are proposing
is quite generic and intended to work with any backend?
2) How does one go about testing this patch without a backend that implements
these ui* objects? Do you have a "fake" backend that lets you simulate events
for calling back into octave from the backend?
John Swensen
- Re: UIControl draft implementation,
John Swensen <=