Using custom widgets, keeping code in sync with gtkaml XML
AstralStorm
This seems to be a very interesting project, although very early.
I've a few simple questions that aren't answered in the documentation.
Is it possible to have custom widgets specified in the gtkaml code? If
so, how?
What's the best practice for keeping gtkaml XML in sync with the UI
code? Can it update the currently existing UI code, or do I have to
use "Do not touch" tactics, like a separate module for most of the
handlers?
Best regards,
Radoslaw
Vlad Grecescu
Hello,
This seems to be a very interesting project, although very early.
I've a few simple questions that aren't answered in the documentation.
Hello AstralStorm,
Is it possible to have custom widgets specified in the gtkaml code? If
so, how?
The making of custom *composite* widgets is 99% of gtkaml's work.
Every gtkaml file that starts with let's say <VBox> is a widget that derives from Gtk's VBox and has a composite user interface.
Of course, if that widget has public properties it can be re-used in another gtkaml file and you can specify their value as XML attributes.
For example, here we have a widget named MyVBox which can be used in another file just by entering <prefix:MyVBox>, if:
- the definition of MyVBox contains a namespace name (e.g. add class:namespace="myns")
- the file using MyVBox imports that namespace (e.g. add xmlns:prefix="myns") under the name prefix
Pure custom widgets (as opposed to composite ones) can be written directly in Vala (using Gdk, or Cairo etc.) and can of course be used in a gtkaml file.
What's the best practice for keeping gtkaml XML in sync with the UI
code? Can it update the currently existing UI code, or do I have to
use "Do not touch" tactics, like a separate module for most of the
handlers?
The recommended way would be not to modify the output. In fact, the next major gtkaml version will further integrate into Vala's AST so that it will not even output a vala file (you would still be able to check the generated code by using vala's --dump-tree).
That means you have to:
- either write code in the <![[CDATA[ section of the root element (the quickest way)
- or use another vala class as a 'controller' to respond to events or any other way of calling other code that suits you. You would still have to use the code section but only to instantiate a such private member (or you can declare a non-visual instance with <yourprefix:MyVBoxController g:private='controller' g:standalone='true'>)
I have put a test example for this non-visual instance in test3 (nevermind the main is still in a gtkaml file).
Regards,
Vlad
Radoslaw Szkodzinski
> On Sat, Sep 25, 2010 at 6:10 AM, AstralStorm <astra...@gmail.com> wrote:
>>
>> Hello,
>>
>> This seems to be a very interesting project, although very early.
>> I've a few simple questions that aren't answered in the documentation.
>>
I'm retracting this statement. The project is very advanced, though new. :)
>>
>> Is it possible to have custom widgets specified in the gtkaml code? If
>> so, how?
>
> The making of custom *composite* widgets is 99% of gtkaml's work.
> Every gtkaml file that starts with let's say <VBox> is a widget that derives
> from Gtk's VBox and has a composite user interface.
>
> Of course, if that widget has public properties it can be re-used in another
> gtkaml file and you can specify their value as XML attributes.
>
> For example, here we have a widget named MyVBox which can be used in another
> file just by entering <prefix:MyVBox>, if:
> - the definition of MyVBox contains a namespace name (e.g. add
> class:namespace="myns")
> - the file using MyVBox imports that namespace (e.g. add
> xmlns:prefix="myns") under the name prefix
>
This is so good, GtkBuilder has to be replaced or improved to be on-par.
> Pure custom widgets (as opposed to composite ones) can be written directly
> in Vala (using Gdk, or Cairo etc.) and can of course be used in a gtkaml
> file.
What's the syntax to reference one from gtkaml? Just <MyCustomWidget
class:namespace="MyWidgets.MyCustomWidget"...>?
Or is it class:namespace="MyWidgets"? Let's say it's in another module
that has to be included.
>
>>
>> What's the best practice for keeping gtkaml XML in sync with the UI
>> code? Can it update the currently existing UI code, or do I have to
>> use "Do not touch" tactics, like a separate module for most of the
>> handlers?
>>
>
> The recommended way would be not to modify the output. In fact, the next
> major gtkaml version will further integrate into Vala's AST so that it will
> not even output a vala file (you would still be able to check the generated
> code by using vala's --dump-tree).
Hmm. Interesting, but I still like the code, because then you don't
have to port to vala-0.10
for me to be able to use it (maybe with minor modifications to the
generated code, if any).
Although a port would be nice too, but not critical. I've both.
>
> That means you have to:
> - either write code in the <![[CDATA[ section of the root element (the
> quickest way)
And ugly unless I write some advanced XML+Vala syntax highlighting rules.
Could be useful for trivial stuff though. Or the following...
> - or use another vala class as a 'controller' to respond to events or any
> other way of calling other code that suits you. You would still have to use
> the code section but only to instantiate a such private member (or you can
> declare a non-visual instance with <yourprefix:MyVBoxController
> g:private='controller' g:standalone='true'>)
Everyone loves MVC. :)
> I have put a test example for this non-visual instance in test3 (nevermind
> the main is still in a gtkaml file).
I'm going to look at it right now.
Best regards,
Radoslaw
Vlad Grecescu
I'm retracting this statement. The project is very advanced, though new. :)
It looks advanced because it's built around a simple idea:)
> Pure custom widgets (as opposed to composite ones) can be written directlyWhat's the syntax to reference one from gtkaml? Just <MyCustomWidget
> in Vala (using Gdk, or Cairo etc.) and can of course be used in a gtkaml
> file.
class:namespace="MyWidgets.MyCustomWidget"...>?
Or is it class:namespace="MyWidgets"? Let's say it's in another module
that has to be included.
This is one point where the namespace notion from XML and the one from Vala are clashing.
I will use "prefix" from now on for the XML one:
The mechanism to use a widget from another module (let's say Gnome.AppBar from libgnomeui) is to:
- 1. pass "--pkg libgnomeui-2.0" to the compile command (gtkamlc). You will need the .vapi file, this one is already in vala's /usr/share. Of course this is not needed if the widget is in the same compilation unit (in which case it has to be before the gtkaml file - known issue)
- 2. import the Vala namespace and assign it an XML prefix:
<.. xmlns:gnomeui="Gnome" ..> on your top level tag is producing "using Gnome;" at vala source level.
- 3. use the AppBar widget somewhere in the code as <gnomeui:AppBar class:private="myAppBar" />
This produces something like 'private Gnome.AppBar myAppBar;'
- 4. set the construction parameters as attributes too ( .. has-progress='false' has-status='true' interactivity='{PreferencesType.USER}' ..
This produces something like 'myAppBar = new Gnome.AppBar (false, true, PreferencesType.USER);'
- 5. optionally set the other widgets' properties (not in this example)
- 6. optionally set the parameters for the method used to add it to the parent container:
e.g. if the parent container is VBox, you can add the following attributes to your AppBar: expand, fill, padding (as per http://code.google.com/p/gtkaml/wiki/GtkBindings#Box)
(the only exception for the 2nd point is when specifying the http://gtkaml.org/0.2 url as namespace, which means you have defined the gtkaml prefix (usually xmlns:class, xmlns:gtkaml or xmlns:g)
Hmm. Interesting, but I still like the code, because then you don't
have to port to vala-0.10
for me to be able to use it (maybe with minor modifications to the
generated code, if any).
Although a port would be nice too, but not critical. I've both.
The SVN version of gtkaml now compiles under vala 0.10. The problem is I am not sure 100% of the distributions are using vala's "-0.10" program-suffix to make a release now.
Regards,
Vlad