Gdk::GC

I just installed Ruby-gnome2-0.18.0, and I attempted to run a program I
was writing, which uses a Gdk::GC, and the program returned an error:
“uninitialized constant Gdk::GC”. Now, this worked in previous
versions, and according to the documentation, I do believe this object
is still used.

I used the Gdk::Drawable#draw_line function with it to draw a little
over 50 lines, as it seems faster than using Cairo.

Hi,

In [email protected]
“[ruby-gnome2-devel-en] Gdk::GC” on Wed, 01 Oct 2008 15:09:09 -0400,
Andrew S. [email protected] wrote:

I just installed Ruby-gnome2-0.18.0, and I attempted to run a program I
was writing, which uses a Gdk::GC, and the program returned an error:
“uninitialized constant Gdk::GC”. Now, this worked in previous
versions, and according to the documentation, I do believe this object
is still used.

I’m sorry. That is a Ruby/GTK2’s bug. It’d been fixed in
trunk.

Here is a patch:
Index: gtk/src/makeinits.rb

— gtk/src/makeinits.rb (revision 3338)
+++ gtk/src/makeinits.rb (revision 3339)
@@ -14,7 +14,7 @@
value_index = sorted_array.index(value)
next if value_index.nil?
sorted_array.delete(value)

  •    sorted_array[key_index - 1, 1] = value
    
  •    sorted_array[key_index - 1, 0] = value
       key_index = sorted_array.index(key)
     end
    
    end

Thanks,

kou

On Sun, Oct 5, 2008 at 2:38 AM, Kouhei S. [email protected] wrote:

is still used.

I’m sorry. That is a Ruby/GTK2’s bug. It’d been fixed in
trunk.

Hmm, this problem will probably break many of non trivial rg2 programs

  • for example, it breaks mine (booh). Is it not as important as the
    memoryleak of 0.17.0 hence deserves a new release quite soon?

Does it deserve a new autotest file?

cat gtk/test/test_gdk_gc.rb

class TestGdkGC < Test::Unit::TestCase
include GtkTestUtils

def test_constant
assert_nothing_raised do
foo = Gdk::GC::LINE_ON_OFF_DASH
end
end
end


Guillaume C. - http://zarb.org/~gc/

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Gdk::GC” on Wed, 22 Oct 2008 13:12:12
+0200,
“Guillaume C.” [email protected] wrote:

versions, and according to the documentation, I do believe this object
is still used.

I’m sorry. That is a Ruby/GTK2’s bug. It’d been fixed in
trunk.

Hmm, this problem will probably break many of non trivial rg2 programs

  • for example, it breaks mine (booh). Is it not as important as the
    memoryleak of 0.17.0 hence deserves a new release quite soon?

I’ll be busy in the next weekend.
I’ll release in the first weekend of November.

I hope someone helps our release work.

end
end

Please add.

Thanks,

kou

Hmm, this problem will probably break many of non trivial rg2 programs

  • for example, it breaks mine (booh). Is it not as important as the
    memoryleak of 0.17.0 hence deserves a new release quite soon?

I’ll be busy in the next weekend.
I’ll release in the first weekend of November.

I hope someone helps our release work.

I propose something to increase release quality: when you are ready
for a new release, release it
as as release candidate, something like 0.19.0rc1, and tell in this
list (or in a new dedicated list) that
all people writing rg2 applications do test again their application.
After one week, for example, we can
release 0.19.0 if no problems were reported. Hopefully, it might help
isolating regressions (but it needs
not to become months of delay as release candidate as 0.17.0 this
summer!).

That makes me think: why not adding a new page “rg2 applications” on
rg2 website, linking to all rg2
applications? It might help publicize rg2 because we see it’s actually
used for real programs!


Guillaume C. - http://zarb.org/~gc/

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Gdk::GC” on Wed, 22 Oct 2008 16:55:19
+0200,
“Guillaume C.” [email protected] wrote:

I propose something to increase release quality: when you are ready
for a new release, release it
as as release candidate, something like 0.19.0rc1, and tell in this
list (or in a new dedicated list) that
all people writing rg2 applications do test again their application.
After one week, for example, we can
release 0.19.0 if no problems were reported. Hopefully, it might help
isolating regressions (but it needs
not to become months of delay as release candidate as 0.17.0 this summer!).

We will use odd release number as development release from
the next 0.19.x release. OK?

That makes me think: why not adding a new page “rg2 applications” on
rg2 website, linking to all rg2
applications? It might help publicize rg2 because we see it’s actually
used for real programs!

If you can maintain the list, you can crate a page for that
in the Hiki.

Thanks,

kou

Maybe it could be linked also from the left menu bar? It is something
that could be good for “large/immediate” exposure on frontpage.

I think this is really a cool idea. I am reading “fantasdic’s” source
code right now to find out how he got the information viewed from
dict.leo.org :slight_smile: in other words it helps to learn ruby-gnome too in my
opinion.

We will use odd release number as development release from
the next 0.19.x release. OK?

Why not, though I think it will not improve release quality, as my
proposal could. For example, 0.18.1 maybe has some more important bug.
Developers don’t always test their applications with latest HEAD
code…

That makes me think: why not adding a new page “rg2 applications” on
rg2 website, linking to all rg2
applications? It might help publicize rg2 because we see it’s actually
used for real programs!

If you can maintain the list, you can crate a page for that
in the Hiki.

I can do that. I’ve created the page and listed in the Contents
section of the Frontpage

http://ruby-gnome2.sourceforge.jp/hiki.cgi?Applications

Maybe it could be linked also from the left menu bar? It is something
that could be good for “large/immediate” exposure on frontpage.

I’ll post a new message to collect the applications list.


Guillaume C. - http://zarb.org/~gc/

style releasing. Did I misunderstand what you mean…?
Ah, ok. I assumed it would be like Linux, e.g. a series of 0.19.x of
unstable quality, then a series of 0.20.x of stable quality - e.g.
0.20.0 then 0.20.1 then 0.20.2. My point with in that situation, it is
not good for testing 0.20.2 and avoiding regressions.

If there is always a 0.19.x before 0.20.x, then your proposal is good, I
agree!

http://ruby-gnome2.sourceforge.jp/hiki.cgi?Applications

Thanks!!!

np.

Maybe it could be linked also from the left menu bar?

Please do!

Sorry, I don’t know how to edit the left menu bar!


Guillaume C. - http://zarb.org/~gc/

hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Gdk::GC” on Thu, 23 Oct 2008 16:40:36
+0200,
“Guillaume C.” [email protected] wrote:

We will use odd release number as development release from
the next 0.19.x release. OK?

Why not, though I think it will not improve release quality, as my
proposal could.

We don’t have a space for ‘rcX’. (We only have
RBGLIB_{MAJOR,MINOR,MICRO}_VERSION.)

            For example, 0.18.1 maybe has some more important bug.

Developers don’t always test their applications with latest HEAD
code…

I couldn’t understand why RC style releasing can fix the
problem but odd release number as development releasing
(GTK+'s release style) cannot fix the problem.

 stable release: 0.18.0 -> 0.18.1 -> ............. -> 0.20.0

development release: 0.19.0 -> 0.19.1 -> … -> 0.19.x ^
trunk: ^ …^ …^…^ …

I think if we say “0.19.x will be 0.20.0 if no problem” in
0.19.x release announce, we will get same benefit of RC
style releasing. Did I misunderstand what you mean…?

http://ruby-gnome2.sourceforge.jp/hiki.cgi?Applications

Thanks!!!

Maybe it could be linked also from the left menu bar?

Please do!

Thanks,

kou

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Gdk::GC” on Mon, 27 Oct 2008 11:04:13
+0100,
“Guillaume C.” [email protected] wrote:

Maybe it could be linked also from the left menu bar?

Please do!

Sorry, I don’t know how to edit the left menu bar!

You can edit this page:
http://ruby-gnome2.sourceforge.jp/?SideMenu

Thanks,

kou

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs