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

Re: [java-gnome-hackers] GtkAssistant, forward page callback

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

On Wed, 2010-10-27 at 18:06 +0200, Guillaume Mazoyer wrote:
> Here is the bundle with the working code :)

Merged (your branch as subsequently discussed on IRC) to 'mainline'.

AfC
Granada

Re: [java-gnome-hackers] GtkAssistant, forward page callback

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

Fixed. Thank you for your help.

Here is the bundle with the working code :)

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

Re: [java-gnome-hackers] GtkAssistant, forward page callback

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

On Wed, 2010-10-27 at 08:49 +0200, Guillaume Mazoyer wrote:
>    org.gnome.glib.FatalError: (null)-CRITICAL
> Don't know what to do with signal return type gint

That's coming out of our code, src/jni/bindings_java_signal.c line 475

So you need to add G_TYPE_INT¹ there, except that right now 'I' is being
used to mark an enum return. So maybe change that returnType to 'E' or
something, and make 'I' your gint

You'll also need to change the code at line 571. Start there, in fact.

AfC
Granada


¹ but also see
        
        bindings_java_type_lookup() in src/jni/bindings_java_type.c

and
        
        bindings_java_typeToSignature() in  src/jni_bindings_java_util.c

for other handling of GType to Java type conversions. And note that Java
long is GType G_TYPE_INT64

Re: [java-gnome-hackers] GtkAssistant, forward page callback

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

Here is the error / exception thrown:

Encoutered an error at ValidateAssistant.java:152
The following exception was thrown:

   org.gnome.glib.FatalError: (null)-CRITICAL
Don't know what to do with signal return type gint

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

[java-gnome-hackers] GtkAssistant, forward page callback

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

Hi,

I'm trying to cover the GtkAssistant forward page callback
(*GtkAssistantPageFunc). I would like to see this work in the 4.0.17
release but I'm stuck with a problem. When I try to use the code that
I've written, an error occurs.

If I understood what the error says, it seems that GTK doesn't know what
to do with a signal that returns a "gint".

I attached a .diff file so that you can see what change I did. I also
wrote a test case. So if you want to see the error, apply the patch and
run the tests.

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

[java-gnome-hackers] Fwd: [Java-gnome-developer] Create a custom GTK RoundedFrame in Java Gnome

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

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

Forwarding to -hackers. Since future development discussions take place
there.

Personally this has always been my dream, as well as being able to
create widget's in pure Java (like being able to write rendering code in
pure Java) but afair it's not currently possible?

Does anybody have any idea how much work this needs and where the
changes need to be?

Regards,
Serkan

- -------- Original Message --------
Subject: [Java-gnome-developer] Create a custom GTK RoundedFrame in
Java	Gnome
Date: Wed, 20 Oct 2010 16:15:26 +0200
From: bob <loi...@pa...>
To: jav...@li...

When I'm reading the banshee source (C# language), I found how to create
a custom component in C#. It's very simple, the developer had to extend
the Gtk.Bin Object.

I search to do the same thing in Java but I don't found any "simple"
solution, we couldn't extends the Bin object.

I think it is possible to create this component in C and create binding
like all object in java-gnome but it's not very simple (add C code and
add Java binding working with java-gnome).

There is a solution to create a custom widget in Java ? Could you update
the java-gnome library to do it ?

//
// The custom GTK widget RoundedFrame
//

namespace Hyena.Widgets
{
    public class RoundedFrame : Bin
    {
        private Theme theme;
        protected Theme Theme {
            get { return theme; }
        }

        private Widget child;
        private Gdk.Rectangle child_allocation;
        private bool fill_color_set;
        private Cairo.Color fill_color;
        private bool draw_border = true;
        private Pattern fill_pattern;
        private int frame_width;

        // Ugh, this is to avoid the GLib.MissingIntPtrCtorException
seen by some; BGO #552169
        protected RoundedFrame (IntPtr ptr) : base (ptr)
        {
        }

        public RoundedFrame ()
        {
        }

        public void SetFillColor (Cairo.Color color)
        {
            fill_color = color;
            fill_color_set = true;
            QueueDraw ();
        }

        public void UnsetFillColor ()
        {
            fill_color_set = false;
            QueueDraw ();
        }

        public Pattern FillPattern {
            get { return fill_pattern; }
            set {
                fill_pattern = value;
                QueueDraw ();
            }
        }

        public bool DrawBorder {
            get { return draw_border; }
            set { draw_border = value; QueueDraw (); }
        }

#region Gtk.Widget Overrides

        protected override void OnStyleSet (Style previous_style)
        {
            base.OnStyleSet (previous_style);
            theme = Hyena.Gui.Theming.ThemeEngine.CreateTheme (this);
            frame_width = (int)theme.Context.Radius + 1;
        }

        protected override void OnSizeRequested (ref Requisition
requisition)
        {
            if (child != null && child.Visible) {
                // Add the child's width/height
                Requisition child_requisition = child.SizeRequest ();
                requisition.Width = Math.Max (0,
child_requisition.Width);
                requisition.Height = child_requisition.Height;
            } else {
                requisition.Width = 0;
                requisition.Height = 0;
            }

            // Add the frame border
            requisition.Width += ((int)BorderWidth + frame_width) * 2;
            requisition.Height += ((int)BorderWidth + frame_width) * 2;
        }

        protected override void OnSizeAllocated (Gdk.Rectangle
allocation)
        {
            base.OnSizeAllocated (allocation);

            child_allocation = new Gdk.Rectangle ();

            if (child == null || !child.Visible) {
                return;
            }

            child_allocation.X = (int)BorderWidth + frame_width;
            child_allocation.Y = (int)BorderWidth + frame_width;
            child_allocation.Width = (int)Math.Max (1, Allocation.Width
- - child_allocation.X * 2);
            child_allocation.Height = (int)Math.Max (1,
Allocation.Height - child_allocation.Y -
                (int)BorderWidth - frame_width);

            child_allocation.X += Allocation.X;
            child_allocation.Y += Allocation.Y;

            child.SizeAllocate (child_allocation);
        }

        protected override void OnSetScrollAdjustments (Adjustment hadj,
Adjustment vadj)
        {
            // This is to satisfy the gtk_widget_set_scroll_adjustments
            // inside of GtkScrolledWindow so it doesn't complain about
            // its child not being scrollable.
        }

        protected override bool OnExposeEvent (Gdk.EventExpose evnt)
        {
            if (!IsDrawable) {
                return false;
            }

            Cairo.Context cr = Gdk.CairoHelper.Create (evnt.Window);

            try {
                DrawFrame (cr, evnt.Area);
                if (child != null) {
                    PropagateExpose (child, evnt);
                }
                return false;
            } finally {
                CairoExtensions.DisposeContext (cr);
            }
        }

        private void DrawFrame (Cairo.Context cr, Gdk.Rectangle clip)
        {
            int x = child_allocation.X - frame_width;
            int y = child_allocation.Y - frame_width;
            int width = child_allocation.Width + 2 * frame_width;
            int height = child_allocation.Height + 2 * frame_width;

            Gdk.Rectangle rect = new Gdk.Rectangle (x, y, width,
height);

            theme.Context.ShowStroke = draw_border;

            if (fill_color_set) {
                theme.DrawFrameBackground (cr, rect, fill_color);
            } else if (fill_pattern != null) {
                theme.DrawFrameBackground (cr, rect, fill_pattern);
            } else {
                theme.DrawFrameBackground (cr, rect, true);
                theme.DrawFrameBorder (cr, rect);
            }
        }

#endregion

#region Gtk.Container Overrides

        protected override void OnAdded (Widget widget)
        {
            child = widget;
            base.OnAdded (widget);
        }

        protected override void OnRemoved (Widget widget)
        {
            if (child == widget) {
                child = null;
            }

            base.OnRemoved (widget);
        }

#endregion

    }
}


-
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

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

iEYEARECAAYFAky/PPEACgkQRh6X64ivZaKVAQCcCuBX8EpU1NrvgsAZTW51cz7I
8IsAn0DuVFkLmo4EE3JDXUwT0WsY5rE2
=t/nb
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Release imminent

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

On Fri, 2010-10-15 at 14:17 +0200, Andrew Cowie wrote:
> On Fri, 2010-10-08 at 12:36 -0400, Andrew Cowie wrote:
> > We'll be doing 4.0.17 pretty soon. If anyone has anything they want in,
> > please let us know!
> 
> I uploaded a release candidate, java-gnome 4.0.17-rc1. If anyone has any
> comments please let me know.

Just for fun, I installed JamVM and tried `./configure runtime=jamvm`
followed by `make test`.

It didn't do anything.

Huh?

(using -verbose:class -verbose:jni I see it get as far as gtk_init()
then appears to almost throw a FatalError, except that no stack trace
comes out)

Can someone else give this a try?

AfC
Barcelona

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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

I want to summarize the problems I have currently in the defscleanup
branch and gir branch.

* GdkBitmap (Bitmap) and GdkPixbufFormat (PixbufFormat) are interpreted
as boxed's but in the public API they're not.

* When a field and a getter/setter for that field exists, they collide
since Accessor blocks and Method blocks generate duplicate Java methods.
I don't know if sealing will address this in Gtk3.

* A problem where I over came with defs, var-args methods are considered
to be unsuitable for bindings and as a design decision not
introspectable and we use some of them in the public API (especially
some constructors where no non-var-arg constructors exist-See Gnome bug
#141004[1])

* Generation of parameter and return types is hacky and makes
assumptions (See GTypeInfo.c) I filed a bug[2] for inclusion of this in
typelib (it's in GIR XML files but not compiled into typelibs)

* Andrew is uncomfortable with some of the deprecated stub API I
introduced to src/bindings Examining the Gtk-2.0.gir file (the one he
sent) it seems that deprecated flag is not used in type level but
function/signal level only. GIR API has isDeprecated() defined in
GIBaseInfo which applies to all blocks. I don't know if this issue is
just because they're not annotated as deprecated in source code. Maybe
Gtk3 will resolve these as well.

1: https://bugzilla.gnome.org/show_bug.cgi?id=141004
2: https://bugzilla.gnome.org/show_bug.cgi?id=628812

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

iEYEARECAAYFAky4rWcACgkQRh6X64ivZaJXtACfbhy17TmPqE2f8QWJC8fg8GvQ
pA0An1Z4sbA4aNztjrvnCeLgppN+Y0qr
=9VgE
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Release imminent

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

On Fri, 2010-10-08 at 12:36 -0400, Andrew Cowie wrote:
> We'll be doing 4.0.17 pretty soon. If anyone has anything they want in,
> please let us know!

I uploaded a release candidate, java-gnome 4.0.17-rc1. If anyone has any
comments please let me know.

Meanwhile, if anyone wants to contribute something to the NEWS entry, go
ahead and grab the 'website' branch...

AfC
Barcelona

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

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

Here is the bundle to patch the Dialog's run() Javadoc.
I put the warning right after the first paragraph.

Please review it before pushing it into mainline. You know that my
English can be bad sometime ;)

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

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

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

On Sun, 2010-10-10 at 13:29 +0200, Guillaume Mazoyer wrote:
> > Be my guest :)
> Well, how should I do that then?
> Only by writing some Javadoc to explain the problem and giving the
> workaround?

Yeah, that'd be more than fine. We won't mark it @deprecated because it
isn't, but we can mark that it is (due to a bug) unsuitable for use in
threaded programs.

AfC
New York

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

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

> Be my guest :)
Well, how should I do that then?
Only by writing some Javadoc to explain the problem and giving the
workaround?

I want to do it quickly, then you will be able to release 4.0.17
quickly.

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

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

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

On Sat, 2010-10-09 at 09:14 +0200, Guillaume Mazoyer wrote:
> > I'll write a patch to his effect if people agree.
> Agreed. I can also write the patch ...

Be my guest :)

AfC
New York

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

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

> I'll write a patch to his effect if people agree.
Agreed. I can also write the patch since I'm the one that discovered the
bug in the first place :)

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

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

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

On Thu, 2010-08-12 at 03:00 +0200, Vreixo Formoso wrote:
> 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.

So I think we should put a big fat warning on Dialog's run() during this
release. This issue is something we need to address, but we don't have a
patch yet and I think it'll take some serious engineering to address
well. Until then, we should encourage people to connect to
Dialog.Reponse, I think.

I'll write a patch to his effect if people agree.

AfC
New York

[java-gnome-hackers] Release imminent

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

We'll be doing 4.0.17 pretty soon. If anyone has anything they want in,
please let us know!

AfC
New York

-- 
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

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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

On 06-10-2010 20:18, Andrew Cowie wrote:

> So something seems to have gone way off the rails here. Your bundle
> removes a ton of .defs files [which makes me nervous, because lots of
> those files contain a lot of improvements like which classes are
> deprecated and return types and occasional customizations that were
> necessary to make java-gnome work at all] but fine,
The ultimate purpose is to determine what custimizations we did, and
resurrect needed blocks, that's why I didn't commit this in the gir branch.
> 
> and then, it introduces a huge number of public stubs. Ok, new types,
> great! Until I noticed you adding org.gnome.gtk.CList. What!
> 
> That's been deprecated since GTK 1.2; java-gnome goes to a lot of
> trouble to not expose things like that. There are quite a number of
> other things there that are longs since discarded.
> 
I currently expose isDeprecated in GIR API but I'm not using it in
parsing, I may add this in this branch and see if it complicates things
up (we may be exposing deprecated api in the public layer which will not
be generated if marked as deprecated)
- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkysxwMACgkQRh6X64ivZaJcQQCfWRC+zmrRsDe6DLZ1QMdZ8F/U
mXcAn2tY7HRZXdko0CvNfTrJwhVG49az
=8Kix
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

On Sun, 2010-10-03 at 09:32 +0300, Serkan Kaba wrote:
> >> Forgot attaching the patch, here it is.
> > 
> > This isn't a bundle, so we can't create a Bazaar branch from it. Do you
> > have this uploaded somewhere?
> Here's a bundle

Hm.

So something seems to have gone way off the rails here. Your bundle
removes a ton of .defs files [which makes me nervous, because lots of
those files contain a lot of improvements like which classes are
deprecated and return types and occasional customizations that were
necessary to make java-gnome work at all] but fine,

and then, it introduces a huge number of public stubs. Ok, new types,
great! Until I noticed you adding org.gnome.gtk.CList. What!

That's been deprecated since GTK 1.2; java-gnome goes to a lot of
trouble to not expose things like that. There are quite a number of
other things there that are longs since discarded.

As you know, we've spent a lot of effort over the past 4 years trying to
make our public API clean and not present meaningless or obsolete
classes.

I'm not sure what you doing that required you to add stubs for all these
types, but clearly we should not be generating code for them. I assume
what happened is that you just ran the generator and produced code for
everything ever in GTK.

I'm not sure where to go from here.

AfC
Montreal

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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



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

iEUEARECAAYFAkyoZ0IACgkQRh6X64ivZaJw+gCVHvZNPu6VpEPMLtqcRkRlVp8j
dQCfYr2o1+JmaYA3UON5iNHUFxyQZeY=
=zGD2
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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

On 02-10-2010 20:13, Andrew Cowie wrote:
> On Sat, 2010-10-02 at 06:09 +0300, Serkan Kaba wrote:
>> Forgot attaching the patch, here it is.
> 
> This isn't a bundle, so we can't create a Bazaar branch from it. Do you
> have this uploaded somewhere?
Here's a bundle against mainline, which I didn't update lately due to
being stuck at glib-2.22

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

iEYEARECAAYFAkyoI3kACgkQRh6X64ivZaLjpwCfaZIv0Q3V4c4vP7K4QTaDUM+i
IMYAnR7TREWA+AOzD7zN5gHBI1s36k4l
=VDGO
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

On Sat, 2010-10-02 at 06:09 +0300, Serkan Kaba wrote:
> Forgot attaching the patch, here it is.

This isn't a bundle, so we can't create a Bazaar branch from it. Do you
have this uploaded somewhere?

AfC
Kingston

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

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

On Sat, 2010-10-02 at 06:01 +0300, Serkan Kaba wrote:
> I applied this logic but using properties file format which was cleaner
> to code. (Built in parser)

That makes sense.

The typeMapping.properties file we generate and include in the .jar is
similar, and we likewise use Properties's load() to parse it.

AfC
Kingston

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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

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

iEYEARECAAYFAkymol0ACgkQRh6X64ivZaIETQCfZN+aJV7V4cQVQ4bo3ZMUzA/2
kP4AoIEd5TT59q9u5z/Wawf/5AUyMpmX
=YzSn
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Rewrite of Code generator using GIR (Using GIR as basis)

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

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

On 20-09-2010 00:53, Serkan Kaba wrote:

I tried cleaning up defs files in Gdk, GdkPixbuf and Gtk namespaces
(with the exception of ones where we need to keep as an override) and
modified the parser to override DefsFile's created from gir in block level.

Most of the problems I'm getting are caused by GdkBitmap (Bitmap) and
GdkPixbufFormat (PixbufFormat), running boxedFor/fillBoxedArray with
them and duplicate methods generated by accessors (when the boxed has
both a field and an accessor method with the same name)

Can anybody help me debug the first issue, I'm stuck :(

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

iEYEARECAAYFAkymog4ACgkQRh6X64ivZaIJnQCfR9GUm9xIOLWx+XPt54d1gDp4
91AAnj0e1JOCvTscgKvCNS0XTuxXwOG2
=of9X
-----END PGP SIGNATURE-----

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

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

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

On 25-09-2010 11:41, Serkan Kaba wrote:
> 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?
> 
> 
I applied this logic but using properties file format which was cleaner
to code. (Built in parser)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkymoJ4ACgkQRh6X64ivZaLRTgCeMn87wrGjyjaybNnlVauOGC+9
HmIAn1V0U3vF1teY9iUM5/1fnI8mLnnu
=cOz6
-----END PGP SIGNATURE-----