I find the "len" parameter to some functions in GTK2.TextBuffer rather puzzling.
set_text("abcdefghij", 7) - gives 7 characters in the buffer set_text("äbcdefghij", 7) - gives just 6 characters set_text("\u1d8fbcdefghij", 7) - down to 5 characters
This seems like complete nonsense. Why do we require the parameter in the first place?
----- Original Message ----
From: "Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Sat, August 21, 2010 7:35:03 AM Subject: GTK2.TextBuffer
Agreed.
You are all probably right, I should get rid of it. I just did a straight translation from the api.
The Python guys have removed it, we should as well. In a C API, it makes kind of sense, because you may need to do things like
gtk_text_buffer_set_text(b, s+X, Y-X+1)
to insert a string slice. But in Pike (and Python), string slices are part of the language, so you can just type
b->set_text(s[X..Y])
instead.
BTW, the documentation is also wrong, since it claims that you should UTF-8 encode the string before passing it to the method, which is (thankfully) a lie.
Back in version 1.11->1.12, 2009-11-13 13:50:27 (per) line 1:
- require gtk24; + require not_now;
Why was this change made? GTK2.FileChooserDialog works fine, it just requires gtk 2.4. When I change it back to gtk24 from not_now, it compiles fine and the widget is usable.
I would like to reverse this commit, unless someone objects.
Why was this change made? GTK2.FileChooserDialog works fine, it just requires gtk 2.4. When I change it back to gtk24 from not_now, it compiles fine and the widget is usable.
Feel free to. It did not work back then, when I got the 'require' statements working I got compile errors in a few files, amongst them that one.
----- Original Message ----
From: "Per Hedbor () @ Pike (-) developers forum"
To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 10:55:02 AM Subject: gtkfilechooserdialog.pre change
Why was this change made? GTK2.FileChooserDialog works fine, it just requires gtk 2.4. When I change it back to gtk24 from not_now, it compiles fine and the widget is usable.
Feel free to. It did not work back then, when I got the 'require' statements working I got compile errors in a few files, amongst them that one.
Hmm, weird. I re-enabled it and am using it in an application I'm writing currently. Okay, well, I will reverse it.
Thanks -lsd
Speaking of "require"s, could we perhaps export which reqires that are enabled to the cpp somehow, so that you can test for them in the pike code as well? Case in point; the GTK2 version of Tools.PV wants to use GTK2.Widget()->get_window(), which requires gtk 2.14, but I have no way of testing if it exists, which led to the testsuite failing on some xenofarm machine (I forget which) that had an older GTK2.
----- Original Message ----
From: "Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 11:25:02 AM Subject: Re: gtkfilechooserdialog.pre change
Speaking of "require"s, could we perhaps export which reqires that are enabled to the cpp somehow, so that you can test for them in the pike code as well? Case in point; the GTK2 version of Tools.PV wants to use GTK2.Widget()->get_window(), which requires gtk 2.14, but I have no way of testing if it exists, which led to the testsuite failing on some xenofarm machine (I forget which) that had an older GTK2.
I have all those available from pgtk_config.h, up to GTK216. They are defined as HAVE_GTK22, HAVE_GTK24, etc.
But, you should also be able to use the gtk/glib macros GTK_MAJOR_VERSION, GTK_MINOR_VERSION, GTK_MICRO_VERSION.
Oh, hmm, from the pike level, you can probably use has_index(object,"get_window"), but I could probably add the macros also.
----- Original Message ----
From: "Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 3:00:02 PM Subject: Re: gtkfilechooserdialog.pre change
Oh, hmm, from the pike level, you can probably use has_index(object,"get_window"), but I could probably add the macros also.
I can't use has_index(object...) from the pre-processor. That's why I need the macros.
Ah, yes, okay, I'll create those and put it in.
----- Original Message ----
From: Lance Dillon riffraff169@yahoo.com To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 3:15:17 PM Subject: Re: gtkfilechooserdialog.pre change
----- Original Message ----
From: "Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers
forum"
10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 3:00:02 PM Subject: Re: gtkfilechooserdialog.pre change
Oh, hmm, from the pike level, you can probably use has_index(object,"get_window"), but I could probably add the macros also.
I can't use has_index(object...) from the pre-processor. That's why I need the macros.
Ah, yes, okay, I'll create those and put it in.
There is also a GTK2.version(), that returns the versions, but you probably can't use that either.
GTK2 version is now available as a constant with the following:
Pike v7.8 release 469 running Hilfe v3.5 (Incremental Pike Frontend)
GTK2.GTK_MINOR_VERSION;
(1) Result: 0
GTK2.MAJOR_VERSION;
(2) Result: 2
GTK2.MINOR_VERSION;
(3) Result: 20
GTK2.MICRO_VERSION;
(4) Result: 1
GTK2.MicroVersion;
(5) Result: 1
GTK2.MajorVersion;
(6) Result: 2
GTK2.MinorVersion;
(7) Result: 20 Terminal closed.
The version string is sprintf("%d.%d.%d",GTK2.MAJOR_VERSION,GTK2.MINOR_VERSION,GTK2.MICRO_VERSION);
Or GTK2.version(), as an array, although this isn't available at pre-compile time (cpp), whereas I believe the above is (should be tested to make sure).
Are the camel case just redundant copies of the first ones, or do they mean different things?
----- Original Message ----
From: "Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 7:50:02 PM Subject: GTK2 Version
Are the camel case just redundant copies of the first ones, or do they mean different things?
No, they are the same. The pike code generator, build_pgtk.pike, was modified from the one in the GTK module directory. It did that, and I just left it there.
Sorry for not reponding to this for a while.
Pike v7.8 release 469 running Hilfe v3.5 (Incremental Pike Frontend)
GTK2.GTK_MINOR_VERSION;
(1) Result: 0
GTK2.MAJOR_VERSION;
(2) Result: 2
GTK2.MINOR_VERSION;
(3) Result: 20
GTK2.MICRO_VERSION;
(4) Result: 1
Ok, fine, but I can't use that in the preprocessor either. I can do
#if constant(GTK2.MINOR_VERSION)
but that's pretty pointles, because I don't want to know if it _has_ a version, I want to know what the version _is_.
I can not do
#if GTK2.MINOR_VERSION >= 12
because GTK2.MINOR_VERSION is an integer constant, not a macro.
What I need is something like GTK2.GTK212 so that I can do
#if constant(GTK2.GTK212)
to find out if things which "require gtk212" are present or not.
There is also a GTK2.version(), that returns the versions, but you probably can't use that either.
No, and also, GTK2.version() returns the runtime version of the libraries, which may be different. If you have GTK 2.12 when you build pike, features which "require gtk214" will not be compiled in. If you then upgrade the libraries (which are dynamic) to 2.14, GTK2.version() will return 2.14, but the gtk214 stuff will still not be available as it wasn't compiled into pike.
----- Original Message ----
From: "Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Tue, August 31, 2010 6:35:03 PM Subject: Re: gtkfilechooserdialog.pre change
There is also a GTK2.version(), that returns the versions, but you probably can't use that either.
No, and also, GTK2.version() returns the runtime version of the libraries, which may be different. If you have GTK 2.12 when you build pike, features which "require gtk214" will not be compiled in. If you then upgrade the libraries (which are dynamic) to 2.14, GTK2.version() will return 2.14, but the gtk214 stuff will still not be available as it wasn't compiled into pike.
Ah, hmm, that is kind of weird, but off the top of my head, I can't think of a way around it. The compile time constants are probably the best for that.
pike-devel@lists.lysator.liu.se