[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Vala] gtk widget bindings complete
- From: Sam Liddicott <sam liddicott com>
- To: gege2061 <gege2061 redaction-developpez com>
- Cc: vala-list gnome org
- Subject: Re: [Vala] gtk widget bindings complete
- Date: Wed, 25 Jun 2008 20:26:40 +0100
I fear I don't understand the second suggestion. Please could you provide a small example.
Thanks
Sam
-----Original Message-----
From: gege2061 <gege2061 redaction-developpez com>
Sent: 25 June 2008 18:39
To: Sam Liddicott <sam liddicott com>
Cc: vala-list gnome org
Subject: Re: gtk widget bindings complete
> After analyzing the generated code, I have some proposals :
> * Use abstract class,
>
>
> you're probably right. It's just sugar, but sugar is important.
Of course, it's just a proposal, for v2...
> * Create abstrat method for signal,
>
>
> I considered this. I'm not certain of the benefits.
> There are lots of signals, most of which exist of exist for each widget.
>
> Often there is a different signal handler for the same signal for different
> widgets.
>
> So what would these abstract methods be? Dispatchers? Based on what info?
>
> Only the developer knows what signals he wants to catch and how, so I left
> these to be done in the subclass, but at least the developer only has to get
> the name right and the rest happens automatically.
Sorry I wanted to say : signal callback, defined in XML, to force
developers to implement it in sub-classe (hence my first proposal).
> * Use verbatim string for XML (see my example).
>
>
> I don't like this because the xml may actually contain """ and there is no
> way to escape it.
> I did have it set to close the string on \n and start a new line and open
> the string again, but vala doesn't support const string concatenation yet
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]