Re: QtHandles: Qt-based toolkit with uicontrol/uipanel support

[Michael Goffioul]

2011/10/10 Jordi Gutiérrez Hermoso <address@hidden>:
>> I admit this is not very elegant, but this was the most straightforward
>> solution. Storing/retrieving pointers is localised in a single file and not
>> exposed outside of it. There was code to support 32bits and 64bits
>> platform, which probably consists of all relevant platforms for octave.
>
> People compile Octave on a lot more than just 32 and 64 bit Intel
> architectures. At least on Debian, we compile it on 11 architectures
> and counting (probably like 14 for the next Debian release).

I was not specifically targeting Intel. Out of curiosity, how many of these
architectures at not 32 or 64 bits?

>> octave_ptr<T> would fine. octave_mem can be viewed as octave_ptr<void>.
>> Besides the graphics system, such object might be useful when implementing
>> wrappers for external libraries in octave (where you often need to
>> hold a pointer
>> to a foreign object).
>
> Okay, I'll write this class within the next couple of days. Sorry
> about the recompilation. I also fear Octave recompilations.
>
> Unless jwe really objects and wants the other more general class
> instead, but I don't really get all the details in my head about how
> such a class should be made.
>
> The whole point of such a class is to store pointers in graphics
> objects, right? Do you see other long-term  benefits?

For instance, when you want to integrate a foreign library with octave.
Typically, you'd create an octave class holding a pointer to a foreign
object. Such octave_value type could then be useful.

Though if it's only to be used for the graphics system, maybe I should
just use an internal handle/object mapping as is done in the FLTK
backend. It's a performance penalty, but is much more portable.

Michael.