Discussion:
Gtk Warnings
cyber python
2012-02-05 14:52:36 UTC
Permalink
Hello,
I am writing an application using java-gnome and if a gtk theme that
causes warnings is used the whole application crashes thus I'd like to
know if there is a way to distinguish warnings thrown as Exceptions.

Best regards,
Georgios Migdos.
Guillaume Mazoyer
2012-02-06 00:08:56 UTC
Permalink
Post by cyber python
I am writing an application using java-gnome and if a gtk theme that
causes warnings is used the whole application crashes thus I'd like to
know if there is a way to distinguish warnings thrown as Exceptions.
I never had such a problem.
If the warning are actually generated by the theme then maybe we are
making something wrong.
The warnings that become Exceptions are due to an internal code inside
the bindings. I don't remember where (maybe someone knows where it
is).

Do you have a link where we can download the theme that you think is
causing problem so we can test it?
--
Guillaume Mazoyer - http://respawner.fr/
Andrew Cowie
2012-02-06 05:03:50 UTC
Permalink
Post by cyber python
if there is a way to distinguish warnings thrown as Exceptions.
In general, a WARNING coming from a GNOME library means that it was fed
an illegal value. We're well accustomed in Java land to having those
result in IllegalArgumentExceptions and so that is the behaviour that
java-gnome exhibits - after all, using a stack track from an unchecked
exception helps us zoom in to where our code went wrong is what we do in
Java.

Of course, you're talking about a WARNING that manifestly is not caused
by your code. I agree a stack trace is less useful in that situation,
but I'm not sure we can tell the difference. Maybe we can. I'm open to
ideas; if someone can figure out a way to differentiate stack frames
that came from our (your) code vs not then I'd be happy to merge it.

Otherwise, you'll need to fix the theme to not misuse GTK. That's
probably a good idea anyway.

WARNINGs to some people are CRITICALs to others; either way, after such
a message appears you can be pretty sure the library in question has
washed its hands of any expectation that further processing will be
correct. Indeed, the working definition of CRITICAL I was given some
years back was "from here on, the program is in an undefined
state" (ouch!) and that any further operations would be grunted to
segfault in fairly short order - in other words, you've got half a
chance to put a breakpoint in there and meanwhile your app is going to
thunder in any second now.

In my experience a WARNING message amounts to the same. Of course there
is no consistency about this, which makes our job (a language binding)
difficult.

AfC
Sydney
cyber python
2012-02-06 11:20:21 UTC
Permalink
First of all, thank you for the quick responses. The way I handle this
for now (though it is clearly not a solution) is by ignoring any
FatalError thrown on Gtk.init().

The theme is Adwaita Cupertino SL (
http://gnome-look.org/content/show.php/Adwaita+Cupertino?content=147061
), but there is a great deal of third party gtk themes that cause
exceptions like this (and since the application I am currently writing
is an IDE for an educational language targeted to highschool seniors I
cannot expect them to know anything about gtk themes or why warnings
are generated).

Best regards,
Georgios Migdos.
Serkan Kaba
2012-02-07 03:18:50 UTC
Permalink
Hi,

Sorry but I would say we shouldn't make exceptions for the broken
themes out there. So report a bug against that theme (or even fix it
if you can)

Regards,
Serkan
Post by cyber python
First of all, thank you for the quick responses. The way I handle
this for now (though it is clearly not a solution) is by ignoring
any FatalError thrown on Gtk.init().
The theme is Adwaita Cupertino SL (
http://gnome-look.org/content/show.php/Adwaita+Cupertino?content=147061
), but there is a great deal of third party gtk themes that cause
Post by cyber python
exceptions like this (and since the application I am currently
writing is an IDE for an educational language targeted to
highschool seniors I cannot expect them to know anything about gtk
themes or why warnings are generated).
Best regards, Georgios Migdos.
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
Post by cyber python
The most comprehensive online learning library for Microsoft
developers is just $99.99! Visual Studio, SharePoint, SQL - plus
HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases
when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
java-gnome-developer mailing list
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
Guillaume Mazoyer
2012-02-10 09:02:45 UTC
Permalink
I guess that another interesting topic has been raised here.
The problem (to my mind) is not to know if we should make an exception
for broken themes.
For me, the problem is: should we make "our" applications *crash* if
the theme is broken.
Most applications written for GNOME do not crash when the theme is
broken, shouldn't we do the same (then the question would be "how?")?

Making our applications crash if the theme is broken is ensuring that
applications will only work with themes that do not have any errors.
That is not a bad behaviour but it could be (as we can see) a problem
since themes developers are not error proof (and we are not too).

What I want to say is sometimes themes developers can miss something
making the theme generating warnings. Do we want to make the user pay
for that by making the applications crash?
Sure it is always a good idea to fix the theme blabla but that's just
design to me, making applications crash for design purpose looks like
a broken behaviour to me.
--
Guillaume Mazoyer - http://respawner.fr/
Loading...