[Gambas-devel] New GTK+ features

[Brandon Bergren]

On Fri, 4 Mar 2005, Benoit Minisini wrote:

> On Thursday 03 March 2005 13:44, Daniel Campos wrote:
>> Hi:
>>
>> Here's gb.gtk 050303. Two new features added:
>>
>> 1) I've implemented then "MovieBox" widget, it is fully functional, so
>> MovieBox could be removed from gb.qt.ext and added to gb.qt.
>>
>
> Cool.
>
>> 2) I've added a new (experimental) feature, that I think is very important,
>> trying to make it as simple and intuitive as possible:
>>
>> I've added a new widget called "Plugin" which embeeds a X-window (mainly
>> from
>> another process, but could be from the same process). This has been done
>> using the XEMBED protocol specification, which is managed by the
>> GtkPlugin and
>> GtkSocket classes when using GTK+, and can be easily implemented with
>> QtXembedContainer and QtXembedClient (
>> http://www.trolltech.com/products/solutions/catalog/Widgets/qtxembed/ )
>> when using QT ... Benoît?
>
> Cool yet :-)
>
> A few remarks:
>
> * This feature is not included in the standard qt library, and that it is an
> X11 only feature.
>
> * You should use GB.Alloc(), GB.Realloc() and GB.Free() instead of malloc(),
> realloc() and free(). This way, you can easily debug memory leaks.

Benoit, this is actually possible on Windows too.
I've been banging my head against the wall (figuratively) learning how 
window handles on Win32 work, and it's actually quite straightforward 
(once you know what the @#$!$# handle is, that is.)
XIDs can basically be mapped to win32 HWNDs.
I'm having problems getting Cygwin to give me a window handle, though. I 
suspect it's a subsystem:windows versus subsystem:console issue.

You Unix guys have it easy ;P

(I actually like Unix/POSIX systems better than Windows, but I find Win32 
porting more sporting. It certainly can be more difficult at times.)

>
>> Thanks to the XEMBED protocol, both client
>> (plugin) and
>> server (main application) can work together, without the problems of the
>> old system:
>> just using a remote XID without any coordination between the two apps:
>>
>> A plugin is just a Form. Now gb.gtk forms have an optional parameter
>> called "Plug". If you load
>> a Form using the "normal way":
>>
>>
>> Form1.Load()
>> Form1.Show()
>>
>>
>> Form is shown as usual, allowing to work with the plugin as a
>> stand-alone application, and to
>> debug the program without problems. But if you ser the "Plug" parameter:
>>
>> Form1.Load(NULL,true)
>> Form1.Show()
>>
>> The Form is hidden (it is really a GtkPlug window instead of a main
>> window).
>
> As, in the future, the IDE will be able to manage different types of form
> (Form, WebForm, ReportForm, ...), wouldn't it be possible to make a class
> named "Plugin", like "Form", that would inherit "Window", instead of one
> extra argument to Window constructor ?
>
>> Then we obtain
>> the Form ID:
>>
>> PRINT Form1.ID
>>
>> (We print it on stdout, or we can write in a file, or send it using a
>> Socket, or whatever)
>>
>> We receive the ID in the main application, and we pass the Form ID from
>> the plugin application to
>> the "Plugin" widget:
>
> Shouldn't the "Plugin" widget named something like "Plugger" instead ? If I
> understand well what is plugged in what of course :-)
>

How about using "widget source" and "widget sink"?

Widget sink is the container, widget source diddles around in sink. Right?

>>
>> ...
>> READ #hProcess,Id,-255
>> ...
>> MyPlugin.Plug (Id)
>> ...
>>
>> Then, the Plugin widget shows the Form embeed into the main application.
>>
>> "Plugin" has two signals: "Plugged" when a remoted XID is sucessfully
>> loaded, and "Unplugged" when
>> the plugin application frees or closes then Form.
>>
>> Then, the programmer can create any communication system between both
>> applications.
>>
>> As XEMBED protocol is a standard, you can even mix GTK+,QT, Motif,
>> FOX... applications, written in
>> any programming language (python, for example).
>>

on X at least.

On windows, it's easier. You just hijack the window handle, bugger the 
host app. ;P

I kid you not, all you have to do is grab the window handle, Windows 
doesn't care WHAT is doing drawing calls against the handle.

Why do you think virus writers love windows? ;P

Proof yet again that Windows wasn't designed to be a multi-user system.

Heck, if you hijack a MFC CWND handle you can even do stuff like make all
MFC level buttons flash red and green...

Anyway, shouldn't be too much pain to do this on Windows, at least when I 
get the basic stuff working.

>> This feature would allow to write, for example, a control panel adding
>> new features using plugins,
>> (writting plugins for the Mandrake control center?), and to work with
>> these plugins as stand-alone
>> applications when you do not want to use the centralized control panel.
>> This would allow also to
>> run applications from different computers (that are using the same
>> X-Server), and to show them
>> as one big application to the user.
>>
>> I send a little example, with a little communication system. You've
>> create a "plugintest" folder into
>> your home folder. Then compile and place there the "Plugin1" and
>> "Plugin2" applications. Now
>> run the "MainApplication" and enjoy! (do not place "MainApp" at plugins
>> folder, it will not run!)
>
> I tried them. The focus behaves strangely. It works, but sometimes I don't see
> the mouse, or the focus rectangle. Strange...
>
> I saw by using these examples that message boxes are not modal. This is a
> problem, they must be!
>
>>
>> Regards,
>>
>> D. Campos
>
> Regards,
>
> -- 
> Benoit Minisini
> mailto:gambas at ...1...

73,

--Brandon B.