Re: [Vala] valac crash on recursive struct usage
Done.
Its filed as https://bugzilla.gnome.org/show_bug.cgi?id=614417
--tkk
On Wed, Mar 31, 2010 at 1:30 AM, Marc-André Lureau
wrote:
> Hi
>
> On Wed, Mar 31, 2010 at 1:26 AM, Thomas Kristensen
> wrote:
>> Hi,
>>
>> It seems valac crashes on recursive struct usage, due to stack
>> overflow when trying to compile the following code:
>>
>
> this appear to be still crashing with git master. I suggest you open a ticket.
>
> regards
>
>> namespace test {
>> public struct Test {
>> Test? test;
>> }
>>
>> public struct Test2 {
>> Test test;
>> int i;
>> }
>>
>> static void main () {
>> var l = new List ();
>> stdout.printf ("%d", (int)l.length ());
>> }
>> }
>>
>> Is this a new issue or something that has been fixed since 0.7.10 ?
>>
>> --tkk
>> ___
>> Vala-list mailing list
>> Vala-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
>
> --
> Marc-André Lureau
>
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] valac crash on recursive struct usage
Hi
On Wed, Mar 31, 2010 at 1:26 AM, Thomas Kristensen wrote:
> Hi,
>
> It seems valac crashes on recursive struct usage, due to stack
> overflow when trying to compile the following code:
>
this appear to be still crashing with git master. I suggest you open a ticket.
regards
> namespace test {
> public struct Test {
> Test? test;
> }
>
> public struct Test2 {
> Test test;
> int i;
> }
>
> static void main () {
> var l = new List ();
> stdout.printf ("%d", (int)l.length ());
> }
> }
>
> Is this a new issue or something that has been fixed since 0.7.10 ?
>
> --tkk
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/vala-list
>
--
Marc-André Lureau
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] valac crash on recursive struct usage
Hi,
It seems valac crashes on recursive struct usage, due to stack
overflow when trying to compile the following code:
namespace test {
public struct Test {
Test? test;
}
public struct Test2 {
Test test;
int i;
}
static void main () {
var l = new List ();
stdout.printf ("%d", (int)l.length ());
}
}
Is this a new issue or something that has been fixed since 0.7.10 ?
--tkk
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] gvfs
Hello:
I'm was looking the gio samples to see how to to access to a remote
folder, but with the example in the site don't work .
I search in the web and in the GLib doc, create the next code
but looks like that is not the right way.
Any idea?
public class Main
{
public static int main (string[] args)
{
File f=File.new_for_uri("sftp://10.32.17.245/home/aconsuegra/Webcam1";);
MountOperation mo = new MountOperation();
mo.set_password("user");
mo.set_username("pass");
f.mount_enclosing_volume(MountMountFlags.NONE,mo,null);
if( !f.query_exists(null) ){
try{
f.make_directory(null);
}
catch(Error e){
stderr.printf("%s\n",e.message);
}
}
return 0;
}
}
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Vala does not register string[] properties
On Thu, Mar 25, 2010 at 04:23:02PM +0100, Julian Andres Klode wrote:
> Hi,
>
> string[] properties are not installed via g_object_class_install_property (),
Proposed patch attached.
--
http://www.debian.org - The Universal Operating System
From 8f940dd9f74831a56937162a45a1a45c1c8ef62f Mon Sep 17 00:00:00 2001
From: Luca Bruno
Date: Tue, 30 Mar 2010 12:40:56 +0200
Subject: [PATCH] Support string[] (G_TYPE_STRV) properties for GObject.
---
codegen/valagobjectmodule.vala | 45 +--
codegen/valagtypemodule.vala |3 ++
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/codegen/valagobjectmodule.vala b/codegen/valagobjectmodule.vala
index bf5c94d..1566c7f 100644
--- a/codegen/valagobjectmodule.vala
+++ b/codegen/valagobjectmodule.vala
@@ -189,6 +189,7 @@ internal class Vala.GObjectModule : GTypeModule {
block.add_statement (cdecl);
bool boxed_declared = false;
+ bool length_declared = false;
var cswitch = new CCodeSwitchStatement (new CCodeIdentifier ("property_id"));
var props = cl.get_properties ();
@@ -242,6 +243,17 @@ internal class Vala.GObjectModule : GTypeModule {
} else {
ccall = new CCodeFunctionCall (new CCodeIdentifier ("%s_get_%s".printf (prefix, prop.name)));
ccall.add_argument (cself);
+var array_type = prop.property_type as ArrayType;
+if (array_type != null && array_type.element_type.data_type == string_type.data_type) {
+ // G_TYPE_STRV
+ if (!length_declared) {
+ cdecl = new CCodeDeclaration ("int");
+ cdecl.add_declarator (new CCodeVariableDeclarator ("length"));
+ block.add_statement (cdecl);
+ length_declared = true;
+ }
+ ccall.add_argument (new CCodeUnaryExpression (CCodeUnaryOperator.ADDRESS_OF, new CCodeIdentifier ("length")));
+}
var csetcall = new CCodeFunctionCall ();
if (prop.get_accessor.value_type.value_owned) {
csetcall.call = head.get_value_taker_function (prop.property_type);
@@ -281,6 +293,8 @@ internal class Vala.GObjectModule : GTypeModule {
var cdecl = new CCodeDeclaration ("%s *".printf (cl.get_cname ()));
cdecl.add_declarator (new CCodeVariableDeclarator ("self", ccall));
block.add_statement (cdecl);
+
+ var boxed_declared = false;
var cswitch = new CCodeSwitchStatement (new CCodeIdentifier ("property_id"));
var props = cl.get_properties ();
@@ -311,14 +325,31 @@ internal class Vala.GObjectModule : GTypeModule {
cswitch.add_statement (new CCodeCaseStatement (new CCodeIdentifier (prop.get_upper_case_cname (;
ccall = new CCodeFunctionCall (new CCodeIdentifier ("%s_set_%s".printf (prefix, prop.name)));
ccall.add_argument (cself);
- var cgetcall = new CCodeFunctionCall ();
- if (prop.property_type.data_type != null) {
-cgetcall.call = new CCodeIdentifier (prop.property_type.data_type.get_get_value_function ());
+ if (prop.property_type is ArrayType && ((ArrayType)prop.property_type).element_type.data_type == string_type.data_type) {
+if (!boxed_declared) {
+ cdecl = new CCodeDeclaration ("gpointer");
+ cdecl.add_declarator (new CCodeVariableDeclarator ("boxed"));
+ block.add_statement (cdecl);
+ boxed_declared = true;
+}
+var cgetcall = new CCodeFunctionCall (new CCodeIdentifier ("g_value_get_boxed"));
+cgetcall.add_argument (new CCodeIdentifier ("value"));
+cswitch.add_statement (new CCodeExpressionStatement (new CCodeAssignment (new CCodeIdentifier ("boxed"), cgetcall)));
+ccall.add_argument (new CCodeIdentifier ("boxed"));
+
+var cstrvlen = new CCodeFunctionCall (new CCodeIdentifier ("g_strv_length"));
+cstrvlen.add_argument (new CCodeIdentifier ("boxed"));
+ccall.add_argument (cstrvlen);
} else {
-cgetcall.call = new CCodeIdentifier ("g_value_get_pointer");
+var cgetcall = new CCodeFunctionCall ();
+if (prop.property_type.data_type != null) {
+ cgetcall.call = new CCodeIdentifier (prop.property_type.data_type.get_get_value_function ());
+} else {
+ cgetcall.call = new CCodeIdentifier ("g_value_get_pointer");
+}
+cgetcall.add_argument (new CCodeIdentifier ("value"));
+ccall.add_argument (cgetcall);
}
- cgetcall.add_argument (new CCodeIdentifier ("value"));
- ccall.add_argument (cgetcall);
cswitch.add_statement (new CCodeExpressionStatement (ccall));
cswitch.add_statement (new CCodeBreakStatement ());
}
@@ -721,7 +752,7 @@ internal class Vala.GObjectModule : GTypeModule {
return false;
}
- if (prop.property_type is ArrayType) {
+ if (prop.property_type is ArrayType && ((ArrayType)prop.property_type).element_type.data_type != string_type.data_type) {
return false;
}
diff --git a/codegen/valagtypemodule.vala b/codegen/valagtypemodule.vala
index 21f57b0..d241d17 100644
--- a/codegen/valagtypemodule.vala
+++ b/codegen/valagtypemodule.vala
@@ -1774,6 +1774,9 @@ internal class Vala.GTypeModule : GErrorModule {
cspec.call = new CCodeIdentifier ("g_
Re: [Vala] Locking null references
On Tue, March 30, 2010 11:47, "Andrés G. Aragoneses" wrote: >> decided to use different lock statement semantics compared to C#. The >> only other option would have been to not support lock statements at >> all . > > Well, I'm wondering about a 3rd option which would be a compromise: that > vala translate every lock statement with a minimal null-check first, so > if the condition is not met, an exception is raised? What do you think > about this approach? Utterly, absolutely wrong. As long as it locks the field, it should lock it no matter what value it has. It is not guarding against change in the refered object anyway! >[...] >> Yes, it's unfortunate that we can't properly support lock(this) as >> GObject doesn't support it and we can't just add a mutex field to >> instance structs as this would result in issues when using lock(this) in >> subclasses. Otherwise, I'd probably recommend using lock(this) in most >> cases. Since most objects won't ever need to be used with lock() (in any language), it's IMHO bad design to have a universal lock statement working with anything. Personally I am not sure lock() is a reasonable thing to do. IMHO too many (all) things being lockable just make it easier to forget what should be locked when. For me, using() statement working with Mutexes seems sufficient. Alternatively it should be possible to implement Monitor without needing a member in the synchronized object (I would expect CLR to actually do it that way, because the overhead for having mostly unused mutex in every object would be quite high). A simple idea is to have a collection of the currently locked objects with a condvar. A simple implementation would be slow because of the global lock, but a mostly efficient implementation should be doable (though system-specific). -- - Jan Hudec ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
On Tue, 2010-03-30 at 12:33 +0200, "Andrés G. Aragoneses" wrote: > El 30/03/10 11:58, Jürg Billeter escribió: > > Hi Andrés, > > > > On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote: > >> El 30/03/10 11:35, Jürg Billeter escribió: > >>> On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: > In Vala, I can lock a null reference. Is this by design or a > side-effect? > >>> > >>> It's by design (constrained by GObject). Unlike in C#/.NET, we don't > >>> have a monitor available in every object. Due to this constraint, we've > >> > >> AFAIK, it's not that there's a Monitor available in every object. The > >> lock statement is translated into a Monitor.Enter() call, but note that > >> this is a static function call. > > > > The runtime uses a per instance field to implement Monitor.Enter, as far > > as I know. > > Ok, a private field only available at run-time by the runtime. > But couldn't vala do something similar with the recently added > g_type_class_add_private API? This way there would be a solution for the > lock(this) case. Beware: glib/gobject noob here. We need a field per instance, not a field per class. > >>> decided to use different lock statement semantics compared to C#. The > >>> only other option would have been to not support lock statements at > >>> all . > >> > >> Well, I'm wondering about a 3rd option which would be a compromise: that > >> vala translate every lock statement with a minimal null-check first, so > >> if the condition is not met, an exception is raised? What do you think > >> about this approach? > > > > I fail to see what we would gain by doing that. The semantics would > > still differ significantly from C#. I don't see a reason why the field > > value should ever be relevant with Vala's lock statement semantics. For > > example, you can also lock integer fields where the null check wouldn't > > make any sense. > > How about requiring at compile time that the lock statement uses a > reference-type too, like in C#? Again, I don't see what we would gain by doing that. The semantics would still differ significantly from C#. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
El 30/03/10 11:58, Jürg Billeter escribió: > Hi Andrés, > > On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote: >> El 30/03/10 11:35, Jürg Billeter escribió: >>> On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: In Vala, I can lock a null reference. Is this by design or a side-effect? >>> >>> It's by design (constrained by GObject). Unlike in C#/.NET, we don't >>> have a monitor available in every object. Due to this constraint, we've >> >> AFAIK, it's not that there's a Monitor available in every object. The >> lock statement is translated into a Monitor.Enter() call, but note that >> this is a static function call. > > The runtime uses a per instance field to implement Monitor.Enter, as far > as I know. Ok, a private field only available at run-time by the runtime. But couldn't vala do something similar with the recently added g_type_class_add_private API? This way there would be a solution for the lock(this) case. Beware: glib/gobject noob here. >>> decided to use different lock statement semantics compared to C#. The >>> only other option would have been to not support lock statements at >>> all . >> >> Well, I'm wondering about a 3rd option which would be a compromise: that >> vala translate every lock statement with a minimal null-check first, so >> if the condition is not met, an exception is raised? What do you think >> about this approach? > > I fail to see what we would gain by doing that. The semantics would > still differ significantly from C#. I don't see a reason why the field > value should ever be relevant with Vala's lock statement semantics. For > example, you can also lock integer fields where the null check wouldn't > make any sense. How about requiring at compile time that the lock statement uses a reference-type too, like in C#? Regards, Andrés -- ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Andrés, On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote: > El 30/03/10 11:35, Jürg Billeter escribió: > > On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: > >> In Vala, I can lock a null reference. Is this by design or a side-effect? > > > > It's by design (constrained by GObject). Unlike in C#/.NET, we don't > > have a monitor available in every object. Due to this constraint, we've > > AFAIK, it's not that there's a Monitor available in every object. The > lock statement is translated into a Monitor.Enter() call, but note that > this is a static function call. The runtime uses a per instance field to implement Monitor.Enter, as far as I know. > > decided to use different lock statement semantics compared to C#. The > > only other option would have been to not support lock statements at > > all . > > Well, I'm wondering about a 3rd option which would be a compromise: that > vala translate every lock statement with a minimal null-check first, so > if the condition is not met, an exception is raised? What do you think > about this approach? I fail to see what we would gain by doing that. The semantics would still differ significantly from C#. I don't see a reason why the field value should ever be relevant with Vala's lock statement semantics. For example, you can also lock integer fields where the null check wouldn't make any sense. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Jürg: El 30/03/10 11:35, Jürg Billeter escribió: > Hi Jim, > > On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: >> In Vala, I can lock a null reference. Is this by design or a side-effect? > > It's by design (constrained by GObject). Unlike in C#/.NET, we don't > have a monitor available in every object. Due to this constraint, we've AFAIK, it's not that there's a Monitor available in every object. The lock statement is translated into a Monitor.Enter() call, but note that this is a static function call. > decided to use different lock statement semantics compared to C#. The > only other option would have been to not support lock statements at > all . Well, I'm wondering about a 3rd option which would be a compromise: that vala translate every lock statement with a minimal null-check first, so if the condition is not met, an exception is raised? What do you think about this approach? > In Vala lock(foo) locks the field `foo' and not the instance where `foo` > points to. This means that the current value of the field is completely > irrelevant, and locking a field whose value happens to be null is > perfectly fine. > >> I think this is fine and should be the documented behavior. Because Vala >> only allows locking member variables (and not "this"), being unable to lock >> a nulled reference would require allocating a dummy object to lock against >> or explicitly using a Mutex and forgoing lock(). I find both unappealing. > > Yes, it's unfortunate that we can't properly support lock(this) as > GObject doesn't support it and we can't just add a mutex field to > instance structs as this would result in issues when using lock(this) in > subclasses. Otherwise, I'd probably recommend using lock(this) in most > cases. > > Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
Hi Jim, On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote: > In Vala, I can lock a null reference. Is this by design or a side-effect? It's by design (constrained by GObject). Unlike in C#/.NET, we don't have a monitor available in every object. Due to this constraint, we've decided to use different lock statement semantics compared to C#. The only other option would have been to not support lock statements at all . In Vala lock(foo) locks the field `foo' and not the instance where `foo` points to. This means that the current value of the field is completely irrelevant, and locking a field whose value happens to be null is perfectly fine. > I think this is fine and should be the documented behavior. Because Vala > only allows locking member variables (and not "this"), being unable to lock > a nulled reference would require allocating a dummy object to lock against > or explicitly using a Mutex and forgoing lock(). I find both unappealing. Yes, it's unfortunate that we can't properly support lock(this) as GObject doesn't support it and we can't just add a mutex field to instance structs as this would result in issues when using lock(this) in subclasses. Otherwise, I'd probably recommend using lock(this) in most cases. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] A problem in writing some ValaIde plugin..
Hi On 30.03.2010 14:15:53, Arkadi Viner wrote: valide: symbol lookup error: /usr/local/lib/valide/plugins/terminal/libterminal.so: undefined symbol: vte_terminal_new sounds like underlinked library. You need to add -lvte to the LD_ADD or corresponding construct. Best regards, -- Ildar Mulyukov, free SW designer/programmer email: il...@users.sourceforge.net home: http://tuganger.narod.ru/ ALT Linux Sisyphus ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
El 30/03/10 10:55, "Andrés G. Aragoneses" escribió:
>
> IMHO this shouldn't be allowed, just for the sake of consistency with
> other platforms (i.e. Mono requires a non-null reference in null
> statements).
I meant lock statements.
> And even if we don't consider consistency, let's discuss about the
> technical aspects? In Mono a lock statement is translated to an API call
> (Monitor.Enter()), how does it translate in vala? If it's similar, we
> would be in a situation in which completely different parts of a running
> program (let's say, library A and library B which are used by program C)
> do concurrency blocks between each other if they end up using a null
> object in a lock statement, which doesn't make much sense, right?
>
> Andres
>
>
> El 30/03/10 03:30, Jim Nelson escribió:
>> In Vala, I can lock a null reference. Is this by design or a side-effect?
>>
>> class Xyzzy {
>> private File file = null;
>>
>> public File get_file() {
>> File f;
>> lock (file) {
>> if (file == null)
>> file = File.new_for_path("/tmp");
>>
>> f = file;
>> }
>>
>> return f;
>> }
>> }
>>
>> void main() {
>> Xyzzy x = new Xyzzy();
>> stdout.printf("%s\n", x.get_file().get_path());
>> stdout.printf("%s\n", x.get_file().get_path());
>> stdout.printf("%s\n", x.get_file().get_path());
>> }
>>
>> I think this is fine and should be the documented behavior. Because Vala
>> only allows locking member variables (and not "this"), being unable to lock
>> a nulled reference would require allocating a dummy object to lock against
>> or explicitly using a Mutex and forgoing lock(). I find both unappealing.
>>
>> In other words, I think this is okay because it's locking access to the
>> reference and not locking the object itself. This seems right to me -- but
>> I'd feel better if I knew this won't go away in the future.
>>
>> -- Jim
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Locking null references
IMHO this shouldn't be allowed, just for the sake of consistency with
other platforms (i.e. Mono requires a non-null reference in null
statements).
And even if we don't consider consistency, let's discuss about the
technical aspects? In Mono a lock statement is translated to an API call
(Monitor.Enter()), how does it translate in vala? If it's similar, we
would be in a situation in which completely different parts of a running
program (let's say, library A and library B which are used by program C)
do concurrency blocks between each other if they end up using a null
object in a lock statement, which doesn't make much sense, right?
Andres
El 30/03/10 03:30, Jim Nelson escribió:
> In Vala, I can lock a null reference. Is this by design or a side-effect?
>
> class Xyzzy {
> private File file = null;
>
> public File get_file() {
> File f;
> lock (file) {
> if (file == null)
> file = File.new_for_path("/tmp");
>
> f = file;
> }
>
> return f;
> }
> }
>
> void main() {
> Xyzzy x = new Xyzzy();
> stdout.printf("%s\n", x.get_file().get_path());
> stdout.printf("%s\n", x.get_file().get_path());
> stdout.printf("%s\n", x.get_file().get_path());
> }
>
> I think this is fine and should be the documented behavior. Because Vala
> only allows locking member variables (and not "this"), being unable to lock
> a nulled reference would require allocating a dummy object to lock against
> or explicitly using a Mutex and forgoing lock(). I find both unappealing.
>
> In other words, I think this is okay because it's locking access to the
> reference and not locking the object itself. This seems right to me -- but
> I'd feel better if I knew this won't go away in the future.
>
> -- Jim
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] A problem in writing some ValaIde plugin..
2010/3/30 Arkadi Viner > (by the way the compiler doesn't recognize "throws PluginError" so I > removed it for now... ) > Which way? Simply copy the terminal directory in the plugins directory and execute: $ ./waf configure $ ./waf # ./waf install -- Nicolas Joseph ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] A problem in writing some ValaIde plugin..
Hello Nicolas,
I have downloaded the code you have sent me and the latest Valide source
from SVN (I think it was 511) but still when I try to compile the project
with your example it compiles fine (by the way the compiler doesn't
recognize "throws PluginError" so I removed it for now... ), but when I try
to run Valide I get:
*ark...@arkadi-laptop:~/Projects/valide$ valide
valide: symbol lookup error:
/usr/local/lib/valide/plugins/terminal/libterminal.so: undefined symbol:
vte_terminal_new
*
Maybe you have some another idea?
On Mon, Mar 29, 2010 at 8:09 PM, Nicolas Joseph <
gege2...@redaction-developpez.com> wrote:
> Hello,
>
> I have added, in trunk, the support for specific compilation configuration
> for plugins.
>
> Try the attached sample plugin, I don't have problem.
>
> 2010/3/29 Arkadi Viner
>
>> Hello,
>> I'm trying to write a simple plugin for ValaIde, which is called
>> 'Terminal',
>> which should display a terminal window (or maybe there will be an option
>> to
>> open more then one..) inside the IDE (like in geany IDE for example..).
>> I took most of the code from the TODO plugin and changed it for my needs.
>> My
>> problem is when I try to create a Terminal widget using -
>> this.terminal = new Terminal();
>> , it compiles fine but *when I try to run ValaIde it doesn't start and I
>> get
>> this message:*
>> *ark...@arkadi-laptop:~/Projects/valide$ valide
>> valide: symbol lookup error:
>> /usr/local/lib/valide/plugins/terminal/libterminal.so: undefined symbol:
>> vte_terminal_new *
>>
>> *My plugin's code:*
>>
>> using Valide;
>> using Vte;
>>
>> public class Valide_Terminal : Plugin, Object
>> {
>> private Gtk.ScrolledWindow scrolled_window;
>>
>> Terminal terminal; //with this line only it compiles and run fine
>>
>> public string path { get; construct set; }
>>
>> public Window window { get; construct set; }
>>
>> private bool only_load_active_tab
>> {
>>get
>>{
>> return this.window.config_manager.get_boolean ("Todo",
>> "only-load-active-tab");
>>}
>>set
>>{
>> this.window.config_manager.set_boolean ("Todo",
>> "only-load-active-tab", value);
>>}
>> }
>>
>> construct
>> {
>>this.scrolled_window = new Gtk.ScrolledWindow (null, null);
>>
>>this.scrolled_window.set_policy (Gtk.PolicyType.AUTOMATIC,
>> Gtk.PolicyType.AUTOMATIC);
>>
>>this.terminal = new Terminal(); //with this line it compiles fine but
>> doesn't run...
>>
>>try
>>{
>> Utils.register_icon (Path.build_filename (Config.PIXMAPS_DIR,
>> "plugins",
>>"terminal.png"),
>> "terminal-plugin-icon");
>>}
>>catch (Error e)
>>{
>> debug (e.message);
>>}
>>this.window.add_widget (this.scrolled_window, "terminal-plugin",
>> _("Terminal"),
>>Window.Placement.BOTTOM,
>> "terminal-plugin-icon");
>> }
>>
>> ~Todo ()
>> {
>>this.window.remove_widget (this.scrolled_window);
>> }
>>
>>public Gtk.Widget create_configure_dialog ()
>>{
>> Gtk.VBox vbox;
>> Gtk.CheckButton check;
>>
>> vbox = new Gtk.VBox (true, 0);
>>
>> check = new Gtk.CheckButton.with_label (_("Only load symbols for
>> active tab"));
>> check.set_active (this.only_load_active_tab);
>> check.toggled.connect ((s) => {
>>this.only_load_active_tab = s.get_active ();
>> });
>> vbox.pack_start (check, true, true, 0);
>>
>> return vbox;
>> }
>> }
>>
>> [ModuleInit]
>> public Type register_plugin ()
>> {
>> return typeof (Valide_Terminal);
>> }
>>
>> public Gtk.Widget create_configure_dialog (Valide_Terminal self)
>> {
>> return self.create_configure_dialog ();
>> }
>>
>> Please help..
>>
>> ___
>> Vala-list mailing list
>> Vala-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/vala-list
>>
>>
> --
> Nicolas Joseph
>
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
