java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Name overriding)

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While running the generator, I discovered that we didn't use some of the
underlying type names in favor of more meaningful ones. I tried the
following patch and it works? So do you think it's hacky or not
acceptable? Or is it OK?


- -- 
Sincerely,
Serkan KABA
Gentoo Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkydta0ACgkQRh6X64ivZaJAbwCfd5F5Kit0Rqq/G507xv6egRWn
U9gAnR7sNiEYeQE2ZTRXNSRQC2+JkPhZ
=MYSF
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Pixbufs from named Icons?

[Guillaume M. <res...@gm...>]

> Is there a way to get a Pixbuf for a named Icon?
As far as I know, there is no way to do this.

> Seems like there should be a Pixbuf.<init>(Icon) constructor, but I
> can't find a gtk_pixbuf_new... function that fits.
What did make you think this? I searched too and didn't find it anything

> I tried exposing Image's getPixbuf() and using it on a
> Image.<init>(Icon, IconSize) CRASH. [no surprise there; a GtkImage is
> specific to how it was created and a pain in the ass, which is why I
> never exposed any of the getters...]
Image's getPixbuf() can be used when you create an Image using a Pixbuf,
so yeah no surprise.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] [Fwd: [Bug 468672] GTK_POLICY_AUTOMATIC should be the default policy for a GtkScrolledWIndow]

[Andrew C. <an...@op...>]

Default change... could someone change this on a 4.1 branch?

AfC
Sydney

-------- Forwarded Message --------
From: gtk+ <bug...@gn...>
To: an...@op...
Subject: [Bug 468672] GTK_POLICY_AUTOMATIC should be the default policy
for a GtkScrolledWIndow
Date: Wed, 22 Sep 2010 00:18:02 +0000 (UTC)

https://bugzilla.gnome.org/show_bug.cgi?id=468672
  gtk+ | GtkScrolledWindow | 2.90.x

Matthias Clasen <mclasen> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mc...@re...
         Resolution|                            |FIXED

--- Comment #6 from Matthias Clasen <mc...@re...> 2010-09-22 00:17:58 UTC ---
commit 0f88b6808c6fb41e49ff4600e56bc8b2ceb4f49a
Author: Matthias Clasen <mc...@re...>
Date:   Tue Sep 21 20:14:46 2010 -0400

    GtkScrolledWindow: change default policy to 'automatic'

    This change was proposed in bug 468672.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the QA contact of the bug.
You are watching the assignee of the bug.

[java-gnome-hackers] Pixbufs from named Icons?

[Andrew C. <an...@op...>]

Guillaume,

Is there a way to get a Pixbuf for a named Icon?

Seems like there should be a Pixbuf.<init>(Icon) constructor, but I
can't find a gtk_pixbuf_new... function that fits.

I tried exposing Image's getPixbuf() and using it on a
Image.<init>(Icon, IconSize) CRASH. [no surprise there; a GtkImage is
specific to how it was created and a pain in the ass, which is why I
never exposed any of the getters...]

I tried adding a Gtk.renderIcon() overload to take an Icon - NO EFFECT,
returns null

Any suggestions?

AfC
Sydney

Re: [java-gnome-hackers] Problem with static globals

[Andrew C. <an...@op...>]

On Tue, 2010-09-21 at 22:42 +0300, Serkan Kaba wrote:
> Attaching an updated patch. It resolves my issues with the globals, many
> thanks to Andrew

Hey, no problem. I think it's terrific that you're working on all this.
I just wish I could be of more help!

> , this also shows me that I'm still a newbie at C.

Aren't we all :)

The great irony for me is that I started using java-gnome in 2004
because I wanted to write native GTK apps, in Java. But with having to
rewrite the bindings starting 2006, I have subsequently (re)learned
enough C that I could [now] write a GTK program in C.

{sigh}

Oh well. :)

> Currently it still fails in NewObject call in the exact same instance.
> Will try to debug it further.

I'll grab your branch tonight, but I'll be flying so off the list for a
little while.

AfC
Sydney

Re: [java-gnome-hackers] Problem with static globals

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Finally got it working, forgot to add global references for jclass's.

- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyZeoUACgkQRh6X64ivZaJjJgCdFthHrlf7c4JA5chgIQ8XX1Y0
A74AnRqJf382jL/2pm88T6+LCMe4tiAO
=+22a
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Problem with static globals

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Attaching an updated patch. It resolves my issues with the globals, many
thanks to Andrew, this also shows me that I'm still a newbie at C.

Currently it still fails in NewObject call in the exact same instance.
Will try to debug it further.
- ---Trace output---
***Here 7 GObjectInfo 1075235568 1075212880 AppLaunchContext
Here 7 GObjectInfo
***Here 3 GStructInfo 1075235600 1075212856 AppLaunchContextClass
Here 3 GStructInfo
***Here 3 GStructInfo 1075235600 1075212856 AppLaunchContextPrivate
Here 3 GStructInfo
***Here 3 GStructInfo 1075235600 1075212856 Atom
Here 3 GStructInfo
***Here 5 GEnumInfo 1075235520 1075212864 AxisUse
Here 5 GEnumInfo
***Here 3 GStructInfo 1075235600 1075212856 Bitmap
Here 3 GStructInfo
***Here 5 GEnumInfo 1075235520 1075212864 ByteOrder
Here 5 GEnumInfo
***Here 5 GEnumInfo 1075235520 1075212864 CapStyle
Here 5 GEnumInfo
***Here 3 GStructInfo 1075235600 1075212856 Color
Here 3 GStructInfo
***Here 7 GObjectInfo 1075235568 1075212880 Colormap
Here 7 GObjectInfo
***Here 3 GStructInfo 1075235600 1075212856 ColormapClass
Here 3 GStructInfo
***Here 5 GEnumInfo 1075235520 1075212864 CrossingMode

- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyZCroACgkQRh6X64ivZaJ04QCfZ0Ne60NYYR/7BPL7AijJyrOA
ISoAnjm7CLRvqzN52sPFcnfJYZHIyPBX
=2hCs
-----END PGP SIGNATURE-----

[java-gnome-hackers] Problem with static globals

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After writing excessive ugly code for GInfo and GInfo[] creation, I just
had the idea of caching needed jclass and jmethodID instances in a
global array, but unfortunately I couldn't make it work.

After applying the attached patch, generator halts with
ERROR:src/generator/util.c:83:create_java_ginfo: assertion failed:
(classes[type] != NULL)

I guess, I'm doing something terribly wrong. Can you help?

- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyYGMgACgkQRh6X64ivZaJOhACbBeINh89Kek6DO3GrBzf888s+
dNUAn03ws7AEyLQsJhrH7EJssM0TADt7
=9cKL
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Rewrite of Code generator using GIR

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's my blog post on current status.
http://skaba.wordpress.com/2010/09/20/status-of-gobject-introspection-for-java-gnome/

Regards,
Serkan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyWhnYACgkQRh6X64ivZaKzzwCfWrr7W51kz92TmjXlsoeARYEd
rI4An2WwYFelGjs7O42IWMANVlSAW5sm
=Ekis
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] null constant?

[Andrew C. <an...@op...>]

On Sat, 2010-09-18 at 12:18 +0200, Guillaume Mazoyer wrote:
> > Is that acceptable? I'm not sure. Maybe this is a special case, but
> > *nowhere* else in java-gnome is one of the constant fields null (!) -
> > they're all initialized to Constant Objects.

> I don't think that is really acceptable. That means that developers will
> have to check if the constant is "!= null" before using it. 

I agree, that would be awful.

> I guess it is a special case but what do we with it? Ignore it? Try to
> deal with it?

So it turns out that Window's setCursor() accepts null which stands for
"revert to Window default". So if you pass in Cursor.WORKING and it's
null then it'll be ok.

This case arises because I tried to be cute and come up with singletons
for each of the major cursors that you'd ever want, to prevent people
[me :)] from endlessly creating new ones over and over again in signal
handlers. I think that was a good idea, but clearly the class needs to
complete initalization.

Serkan mentioned other possibly similar cases (Stock icons) but I think
we'll leave them alone. In general, the requirement is that GNOME be
installed. If someone can make the case that their install is reasonably
lacking something then we'll work around it, but that's the dependency.
Although incredibly common, Yaakov points out that he had X's
font-cursor-misc installed which lacks "left_ptr_watch". So it's our
attempt at being convenient that's breaking things for him. We can put
this in as a special case bug fix.

AfC
Sydney

Re: [java-gnome-hackers] null constant?

[Guillaume M. <res...@gm...>]

> We can change the code to initialize that constant to Java null if it's
> not found.
Yes we can.

> Is that acceptable? I'm not sure. Maybe this is a special case, but
> *nowhere* else in java-gnome is one of the constant fields null (!) -
> they're all initialized to Constant Objects.
I don't think that is really acceptable. That means that developers will
have to check if the constant is "!= null" before using it. And I think
that it is not how we should use a constant.

I guess it is a special case but what do we with it? Ignore it? Try to
deal with it?

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] null constant?

[Andrew C. <an...@op...>]

https://bugzilla.gnome.org/show_bug.cgi?id=629852

I wrote there,

...this is only a problem if you don't have the "left_ptr_watch" named
cursor in
your cursor theme. I don't know why you wouldn't, but obviously you
don't, and
we should probably be robust against such a case.

We can change the code to initialize that constant to Java null if it's
not found.

Is that acceptable? I'm not sure. Maybe this is a special case, but
*nowhere* else in java-gnome is one of the constant fields null (!) -
they're all initialized to Constant Objects.

I have a patch that does this, but I wanted to ask what people think
about Cursor.WORKING being null sometimes. That strikes me as freaky.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Cairo Contexts clipped to expose region

[Andrew C. <an...@op...>]

I've introduced a new [org.freedesktop.cairo] Context constructor,
taking an [org.gnome.gdk] EventExpose as obtained during a
Widget.ExposeEvent signal handler. Before you did:

    d.connect(new Widget.ExposeEvent() {
            public boolean onExposeEvent(Widget source, EventExpose event) {
                final Window underlying;
                final Context cr;

                underlying = source.getWindow();
                cr = new Context(source);
                ...

Now you can do

    d.connect(new Widget.ExposeEvent() {
            public boolean onExposeEvent(Widget source, EventExpose event) {
                final Context cr;

                cr = new Context(event);
                ...


(it turns out GtkEventExpose has the needed GdkWindow in it, hence
making it possible for this to be even simpler)

Down in the C code this calls gdk_cairo_region() and then cairo_clip(),
meaning that Cairo will only actually draw that which is actually
damaged and exposed, not the entire XWindow. yeay.

Thanks to Benjamin Otte for his help, notably in this thread
http://lists.cairographics.org/archives/cairo/2010-August/020596.html
and on IRC.

AfC
Sydney

[java-gnome-hackers] Style properties

[Andrew C. <an...@op...>]

I just landed a branch that, among other things, exposes a "style
property" for the first time.

Style properties are a bit weird; to us as programmers they are
read-only¹. But sometimes you want to know what they are set to for your
own drawing purposes, and so I figured out how to expose the
"scrollbar-spacing" style property from ScrolledWindow. As with other
properties, it is just

        public int getScrollbarSpacing()

Widget has a gtk_widget_style_get_property() that uses a GValue as an
out-parameter, so I was able to use most of our existing GValue
infrastructure in an analogous fashion [org.gnome.glib] Object's
protected getPropertyInteger() etc. This one uses Widget's protected
getStylePropertyInteger().

AfC
Sydney



¹ Actually, they CAN be changed, care of the .gtkrc file system. I've
been trying to figure that one out for ages. If you follow the
documentation around, we could create Widget's getStyle() returning a
GtkStyle, except that you're not supposed to use that. Meanwhile,
there's GtkRcStyle, but you create those by reading a file... weird.

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] UNSUBSCRIBE

[Smith, N. E C. <nic...@na...>]

UNSUBSCRIBE

Re: [java-gnome-hackers] Fwd: TreeView & TreeViewColumn bundle

[Andrew C. <an...@op...>]

On Fri, 2010-08-13 at 10:13 -0300, Douglaz wrote:
>    Attached follows a tiny bundle with some changes on the code to
> match the java-gnome code style.

Thank you for your first contribution! Your patch has been merged to
'mainline'. :)

Please don't cut and paste [in this case, pygtk's] documentation. If you
look at the changes I made to the JavaDoc for getCellArea() you'll get
the idea of what we try to do for java-gnome.

>    I did write a new test case file for the TreeViewColumn class

So ordinarily I would hold up a patch pending test coverage, but in this
case I wanted to give you a chance to see your code accepted :)

Send along the test code you wrote as a separate bundle, and perhaps
someone will help you fix it up.

AfC
Sydney

Re: [java-gnome-hackers] TreeView & TreeViewColumn bundle

[Douglaz <do...@gm...>]

Hello everyone!

   Attached follows another (2nd and hopefully final) bundle with a test
case for the new functions exposed on TreeViewColumn.

   The Last bundle I mailed contains comments in 2 unrelated test case files
(I made the comments as a temporary mods, as I could not get the test cases
to work on my environment, and then later on I forgot to remove before
creating the my bundle). This bundle only removes the improperly commented
lines.

Best regards,
Douglas

2010/8/13 Douglaz <do...@gm...>

> Hello everyone!
>
>    Attached follows another bundle with a test case for the new functions
> exposed on TreeViewColumn.
>
> Best regards,
> Douglas
>
> 2010/8/13 Douglaz <do...@gm...>
>
> Hello everyone!
>>
>>    Attached follows a tiny bundle with some changes on the code to match
>> the java-gnome code style.
>>
>>    I did write a new test case file for the TreeViewColumn class, however
>> i could not make it run the tests with the 'make test' command, so it's not
>> included in this patch. If I figure out a way to make it work, I can
>> generate another bundle.
>>
>> Best regards,
>> Douglas
>>
>>
>> ---------- Forwarded message ----------
>> From: Douglaz <do...@gm...>
>> Date: 2010/8/12
>> Subject: TreeView & TreeViewColumn bundle
>> To: jav...@li...
>>
>>
>> Hello everyone!
>>
>>     I'm sending a tiny bundle with a few methods:
>>     TreeViewColumn.setVisible
>>     TreeViewColumn.getVisible
>>     TreeViewColumn.setWidget
>>     TreeViewColumn.getWidget
>>     TreeView.getCellArea
>>
>>     I'm attaching a small test program as well.
>>
>>     Please let me know if you need anything changed or something.
>>
>> Best regards,
>> Douglas
>>
>>
>

Re: [java-gnome-hackers] TreeView & TreeViewColumn bundle

[Douglaz <do...@gm...>]

Hello everyone!

   Attached follows another bundle with a test case for the new functions
exposed on TreeViewColumn.

Best regards,
Douglas

2010/8/13 Douglaz <do...@gm...>

> Hello everyone!
>
>    Attached follows a tiny bundle with some changes on the code to match
> the java-gnome code style.
>
>    I did write a new test case file for the TreeViewColumn class, however i
> could not make it run the tests with the 'make test' command, so it's not
> included in this patch. If I figure out a way to make it work, I can
> generate another bundle.
>
> Best regards,
> Douglas
>
>
> ---------- Forwarded message ----------
> From: Douglaz <do...@gm...>
> Date: 2010/8/12
> Subject: TreeView & TreeViewColumn bundle
> To: jav...@li...
>
>
> Hello everyone!
>
>     I'm sending a tiny bundle with a few methods:
>     TreeViewColumn.setVisible
>     TreeViewColumn.getVisible
>     TreeViewColumn.setWidget
>     TreeViewColumn.getWidget
>     TreeView.getCellArea
>
>     I'm attaching a small test program as well.
>
>     Please let me know if you need anything changed or something.
>
> Best regards,
> Douglas
>
>

[java-gnome-hackers] Fwd: TreeView & TreeViewColumn bundle

[Douglaz <do...@gm...>]

Hello everyone!

   Attached follows a tiny bundle with some changes on the code to match the
java-gnome code style.

   I did write a new test case file for the TreeViewColumn class, however i
could not make it run the tests with the 'make test' command, so it's not
included in this patch. If I figure out a way to make it work, I can
generate another bundle.

Best regards,
Douglas

---------- Forwarded message ----------
From: Douglaz <do...@gm...>
Date: 2010/8/12
Subject: TreeView & TreeViewColumn bundle
To: jav...@li...


Hello everyone!

    I'm sending a tiny bundle with a few methods:
    TreeViewColumn.setVisible
    TreeViewColumn.getVisible
    TreeViewColumn.setWidget
    TreeViewColumn.getWidget
    TreeView.getCellArea

    I'm attaching a small test program as well.

    Please let me know if you need anything changed or something.

Best regards,
Douglas

[java-gnome-hackers] TreeView & TreeViewColumn bundle

[Douglaz <do...@gm...>]

Hello everyone!

    I'm sending a tiny bundle with a few methods:
    TreeViewColumn.setVisible
    TreeViewColumn.getVisible
    TreeViewColumn.setWidget
    TreeViewColumn.getWidget
    TreeView.getCellArea

    I'm attaching a small test program as well.

    Please let me know if you need anything changed or something.

Best regards,
Douglas

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Vreixo F. <met...@ya...>]

Hi!

Andrew:
> What would happen if fired off a tiny little worker thread inside our
> run()? 
> 
> [...]
> So I'm wondering if it'd help here... Inside run() 
> 
> 1. fire off a worker thread, 
> 2. have that worker thread be what calls 
> 
> maybe in some combination with Thread's join()...?

I guess the new thread would block when attempting to enter the
synchronized block in the translation layer, as the lock is held by the
original thread in the signal handler. As that thread is waiting for the
new (in the join()) I guess that will cause a deadlock.


> There are about 57 manually written synchronized () blocks in our
> code.
> So catching them all will take a bit of work.

With some luck, a regular expression hacking and eclipse replace feature
will do the job for us... I could try.


> More pertinently, that would be a LOT of effort to essentially make
> *1*
> method work. I don't want to say "we don't have coverage of Dialog's
> run()" but...


Yeah, I agree with you... This might better be job for the future, there
are more interesting things to do. In the mean time, we could just warn
about this ugly feature of our run. Another approach is to add a second
run(), maybe called runWithoutBlock() to be called inside signal
handlers, but it does not fix the 3-level lock neither.

Anyway, it is currently not so bad, anybody can use the Response signal
if it needs multi-threading working with run()... Note I have been
writing this kind of apps for years and never found that problem until
this week.

Cheers
Vreixo

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Andrew C. <an...@op...>]

On Wed, 2010-08-11 at 15:02 +0200, Guillaume Mazoyer wrote:
> 
> Exception in thread "main" java.lang.IllegalArgumentException: You
> asked
> for ordinal 0 which is not known for the requested Constant type
> org.gnome.gtk.ResponseType 
> 
Yeah, oops. I've [now] seen that a few times too.

On Wed, 2010-08-11 at 16:42 +0200, Vreixo Formoso wrote:
> > Attached is a bundle, so if you want to merge & try it, go ahead :)
> 
> I'm getting the same error as Guillaume.

Ok

>  The problem is the stop
> condition in the while. 

The usual way to do that is

while (Gtk.eventsPending()) {
	Gtk.mainIterationDo(false);
}

where "true" makes it blocking. I've never tried it with true. But
anyway.


> You also need a this.present() so the Dialog is actually shown.

Yeah, I realized that when I was out running yesterday afternoon and
thinking about this... :)

> Ok once I fixed this I tested it, but it doesn't work either.

Oh well

>  The reason
> is the same as in the original problem.

That's what I figured.

> When native
> gtk_main_iteration_do() is called, we hold a 2-level nested lock: the
> one of the signal handler, plus the one in GtkMain.mainIterationDo(). 
> 
> I really think the easier approach is...

Ok, before we go back to that, one more thought:

The reason I roughed up that patch was to give me a starting point to
suggest something else. I don't know if it helps, but:

What would happen if fired off a tiny little worker thread inside our
run()? 

I mention this because I used to do that a lot in my 2.x days — [what
are now called]  Button.Clicked handlers almost always started their own
worker thread to do other things.

So I'm wondering if it'd help here... Inside run() 

1. fire off a worker thread, 
2. have that worker thread be what calls 

maybe in some combination with Thread's join()...?

Anyway.

>  to replace the synchronize blocks
> with another kind of Lock, as I have described in my previous mail.


Yeah, that's what we had from January as the likely necessary change.

There are about 57 manually written synchronized () blocks in our code.
So catching them all will take a bit of work.

More pertinently, that would be a LOT of effort to essentially make *1*
method work. I don't want to say "we don't have coverage of Dialog's
run()" but...

++

I wanted to have another look at the deadlock. Here it is:


"Thread-0" prio=10 tid=0x0000000001643800 nid=0x7416 waiting for monitor entry [0x00007ff241449000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.gnome.gtk.GtkProgressBar.pulse(GtkProgressBar.java:70)
	- waiting to lock <0x00007ff282b63bf0> (a org.gnome.gdk.Gdk$Lock)
	at org.gnome.gtk.ProgressBar.pulse(ProgressBar.java:137)
	at DialogDeadlock$Worker.run(DialogDeadlock.java:124)
	at java.lang.Thread.run(Thread.java:636)

"main" prio=10 tid=0x000000000146f000 nid=0x740b runnable [0x00007ff29d044000]
   java.lang.Thread.State: RUNNABLE
	at org.gnome.gtk.GtkDialog.gtk_dialog_run(Native Method)
	at org.gnome.gtk.GtkDialog.run(GtkDialog.java:228)
	- locked <0x00007ff282b63bf0> (a org.gnome.gdk.Gdk$Lock)
	at org.gnome.gtk.Dialog.run(Dialog.java:244)
	at DialogDeadlock$1.onClicked(DialogDeadlock.java:65)
	at org.gnome.gtk.GtkButton.receiveClicked(GtkButton.java:392)
	at org.gnome.gtk.GtkMain.gtk_main(Native Method)
	- locked <0x00007ff282b63bf0> (a org.gnome.gdk.Gdk$Lock)
	at org.gnome.gtk.GtkMain.main(GtkMain.java:82)
	at org.gnome.gtk.Gtk.main(Gtk.java:119)
	at DialogDeadlock.main(DialogDeadlock.java:91)


Hm.

[actually I added the second "locked" line, because I know it's there;
Java's thread dump doesn't show it because it was taken with
MonitorEnter() not synchronized()]

Now that I look at this, I'm not sure that manually letting the entire
lock go is the right thing.

Back to basics:

The whole point of GTK's thread awareness is the requirement that only 1
thread by accessing GTK at a time. Fine. What that means is "one thread
can make a call (that has a cascading effect, emits signals, etc etc,
but that there's only one processing chain until that cascade is done".
That way, between cascades, GTK is in a safe state.

The complication is the main loop.

gtk_main() actually releases the lock when it's idle. They don't really
tell you that, but this mimics the behaviour of Object's wait() which
also relinquishes its lock, then later tries to reacquire it.

So my thought is that that is the only known safe point: when the main
loop thinks it is ok to relinquish the lock, then something else can
grab it and do GTK calls.

Now you'll remember that we have access to the gdk_threads_enter()
gdk_threads_leave() functions. We override them.

But maybe, just maybe, that means that if we *also* do our own main loop
iteration, then we can control the safe point ourselves, rather than it
being magic.

The point is "not do I have the lock" but "is GTK at a safe point where
another thread can take over?"

Interesting.

++

This is all just speculation.

But if you go and fire off a nested main loop (which is what
gtk_dialog_run() does, which is what calling gtk_main() a second time
does) and you are *inside* a signal handler already, then ... what?

Hm.

AfC
Sydney

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Vreixo F. <met...@ya...>]

Hi,

Andrew:
> Maybe that alone will help? Someone with a threaded program that
> demonstrates the bug will need to test that...
> 
> Attached is a bundle, so if you want to merge & try it, go ahead :)

I'm getting the same error as Guillaume. The problem is the stop
condition in the while. You need to use:


            while (!GtkMain.mainIterationDo(true)) {
                   ^  
                if (quit) {
                    break;
                }
            }

(And it will thrown the exception anyway if Gtk.mainQuit() is called, I
guess).

You also need a this.present() so the Dialog is actually shown.

Ok once I fixed this I tested it, but it doesn't work either. The reason
is the same as in the original problem. When native
gtk_main_iteration_do() is called, we hold a 2-level nested lock: the
one of the signal handler, plus the one in GtkMain.mainIterationDo(). 

I really think the easier approach is to replace the synchronize blocks
with another kind of Lock, as I have described in my previous mail.

Cheers
Vreixo

> 
> > Or maybe
> > 
> > 4. Write our own run()
> 
> 
> I had a preliminary try at it; see attached.
> 
> The idiom is pretty common; little inner class handler with a field so
> we can capture a value and return it.
> 
> By itself, this doesn't fix our lock problem. But I thought I'd show
> it
> to you in case it caused you to think of anywhere interesting to go
> from
> here.
> 
> Obviously the fact that we are iterating the real [outer] main loop
> rather than creating a(n implicit) new inner one is what is different
> compared to the real gtk_dialog_run().
> 
> Maybe that alone will help? Someone with a threaded program that
> demonstrates the bug will need to test that...
> 
> Attached is a bundle, so if you want to merge & try it, go ahead :)
> 
> AfC
> Sydney

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Guillaume M. <res...@gm...>]

> Someone with a threaded program that
> demonstrates the bug will need to test that...
I sure can do that. I also wrote a prototype to prove a deadlock.
You can merge the bundle and test it too.

I did test the workaround and it seems that it does not work.
Here is the first line of the stacktrace.

Exception in thread "main" java.lang.IllegalArgumentException: You asked
for ordinal 0 which is not known for the requested Constant type
org.gnome.gtk.ResponseType

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Andrew C. <an...@op...>]

On Wed, 2010-08-11 at 10:44 +1000, Andrew Cowie wrote:

> Or maybe
> 
> 4. Write our own run()


I had a preliminary try at it; see attached.

The idiom is pretty common; little inner class handler with a field so
we can capture a value and return it.

By itself, this doesn't fix our lock problem. But I thought I'd show it
to you in case it caused you to think of anywhere interesting to go from
here.

Obviously the fact that we are iterating the real [outer] main loop
rather than creating a(n implicit) new inner one is what is different
compared to the real gtk_dialog_run().

Maybe that alone will help? Someone with a threaded program that
demonstrates the bug will need to test that...

Attached is a bundle, so if you want to merge & try it, go ahead :)

AfC
Sydney