java-gnome-developer — For people using the bindings to write their own applications

[Java-gnome-developer] UIManager crash with sun java 1.5, and patch

[Khiraly <khi...@gm...>]

(I have sended this email few day ago, but didnt show up on the mailing list)

Hi!

The UIManagerExample.java crash the sun 1.5 jvm when I click on a toggle
item on the menubar (so it cant handle the RadioActionEntry[])
So it crash when I click on:
Preferences->color->Red
Preferences->color->Green
Preferences->color->Blue
Preferences->Shape->Square
Preferences->Shape->Rectangle
Preferences->Shape->Oval

The error report files is attached. (3 crashes)
It is reproducable.

There is a (related) crash(hs_err_pid6153), when I click Ctrl-B to
toggle the 
Preferences->Bold button. 

Is it a java-gnome bug, or should I report to sun's bugzilla?

----
Other:
There is a missing toolbar in the UIManagerExample.java. So there are
toolbar entry in the uiInfo string, but there is not added to the
window. However there are a 'Sepq' (line 116) item, which is not in the
entries array. So there is an error message when I launch the program:

java.lang.Exception: Sepq: missing action
    at org.gnu.glib.GObject.printStackTrace(GObject.java:692)
    at org.gnu.gtk.UIManager.gtk_ui_manager_get_widget(Native Method)
    at org.gnu.gtk.UIManager.getWidget(UIManager.java:77)
    at uimanager.UIManagerExample.<init>(UIManagerExample.java:157)
    at uimanager.UIManagerExample.main(UIManagerExample.java:217)

I have created a patch which is:
1. add a Sepq item to the toolbar (why is this btw?)
2. pack the toolbar to the Vbox

The patch(also attached too):

--- uimanager/UIManagerExample.java	2006-03-21 01:45:51.000000000 +0100
+++ uimanager-modified/UIManagerExample.java	2006-05-13 00:04:41.000000000 +0200
@@ -56,6 +56,7 @@
             new ActionEntry("ColorMenu", null, "_Color"),
             new ActionEntry("ShapeMenu", null, "_Shape"),
             new ActionEntry("HelpMenu", null, "_Help"),
+            new ActionEntry("Sepq", null, "_Sepq", null, null, this),
             new ActionEntry("New", GtkStockItem.NEW.getString(), "_New",
                     "<control>N", "Create a new file", this),
             new ActionEntry("Open", GtkStockItem.OPEN.getString(), "_Open",
@@ -155,7 +156,8 @@
 
         // add the menu bar from the ui by specifying the path
         box1.packStart(ui.getWidget("/MenuBar"), false, false, 0);
-
+        box1.packStart(ui.getWidget("/ToolBar"), false, false, 0);
+        
         Label label = new Label("UIManager\nExample\nApplication");
         label.setMinimumSize(200, 200);
         label.setAlignment(0.5, 0.5);

[Java-gnome-developer] UIManager crash with sun java 1.5, and patch

[Khiraly <khi...@gm...>]

Hi!

The UIManagerExample.java crash the sun 1.5 jvm when I click on a toggle
item on the menubar (so it cant handle the RadioActionEntry[])
So it crash when I click on:
Preferences->color->Red
Preferences->color->Green
Preferences->color->Blue
Preferences->Shape->Square
Preferences->Shape->Rectangle
Preferences->Shape->Oval

The error report files is attached. (3 crashes)
It is reproducable.

There is a (related) crash(hs_err_pid6153), when I click Ctrl-B to
toggle the 
Preferences->Bold button. 

Is it a java-gnome bug, or should I report to sun's bugzilla?

----
Other:
There is a missing toolbar in the UIManagerExample.java. So there are
toolbar entry in the uiInfo string, but there is not added to the
window. However there are a 'Sepq' (line 116) item, which is not in the
entries array. So there is an error message when I launch the program:

java.lang.Exception: Sepq: missing action
    at org.gnu.glib.GObject.printStackTrace(GObject.java:692)
    at org.gnu.gtk.UIManager.gtk_ui_manager_get_widget(Native Method)
    at org.gnu.gtk.UIManager.getWidget(UIManager.java:77)
    at uimanager.UIManagerExample.<init>(UIManagerExample.java:157)
    at uimanager.UIManagerExample.main(UIManagerExample.java:217)

I have created a patch which is:
1. add a Sepq item to the toolbar (why is this btw?)
2. pack the toolbar to the Vbox

The patch(also attached too):

--- uimanager/UIManagerExample.java	2006-03-21 01:45:51.000000000 +0100
+++ uimanager-modified/UIManagerExample.java	2006-05-13 00:04:41.000000000 +0200
@@ -56,6 +56,7 @@
             new ActionEntry("ColorMenu", null, "_Color"),
             new ActionEntry("ShapeMenu", null, "_Shape"),
             new ActionEntry("HelpMenu", null, "_Help"),
+            new ActionEntry("Sepq", null, "_Sepq", null, null, this),
             new ActionEntry("New", GtkStockItem.NEW.getString(), "_New",
                     "<control>N", "Create a new file", this),
             new ActionEntry("Open", GtkStockItem.OPEN.getString(), "_Open",
@@ -155,7 +156,8 @@
 
         // add the menu bar from the ui by specifying the path
         box1.packStart(ui.getWidget("/MenuBar"), false, false, 0);
-
+        box1.packStart(ui.getWidget("/ToolBar"), false, false, 0);
+        
         Label label = new Label("UIManager\nExample\nApplication");
         label.setMinimumSize(200, 200);
         label.setAlignment(0.5, 0.5);

[Java-gnome-developer] Glade.XML.CustomHandler is implemented?

[Khiraly <khi...@gm...>]

Hi!

Is Glade.XML.CustomHandler implemented?
I want to port an application to what is written in C# and glade and
using custom widgets.

I have looked into the libglade-java source and not found anything
related to this method.

Here are some C# sourcecode what is using this glade method call:
http://svn.myrealbox.com/source/trunk/stetic/stetic/Stetic.cs
http://svn.navi.cx/misc/trunk/fyre/src/PipelineEditor.cs

There is a workaround for this?

Best regards, 
  Khiraly

ps:
And the sourcecode what Im looking in:
/*
 * Copyright (C) 2006 Eskil Bylund <es...@le...>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */

using System;

using Gtk;
using Mono.Unix;

namespace DCSharp.GUI
{
    public class GUI
    {
        #region Constructors
        
        static GUI()
        {
            Application.Init();
            
            string localeDir = Environment.GetEnvironmentVariable("DCSHARP_LOCALE");
            if (localeDir == null)
            {
                localeDir = "./locale";
            }
            
            Catalog.Init("dcsharp", localeDir);
            InitIcons();
            
#if GNOME
            Gnome.Vfs.Vfs.Initialize();
            AboutDialog.SetUrlHook(OpenUrl);
#endif
            
            Glade.XML.CustomHandler = new Glade.XMLCustomWidgetHandler(CustomWidgetHandler);
        }
        
        public GUI()
        {
            mainWindow = new MainWindow();
            mainWindow.Show();
        }
        
        #endregion
        
        #region Properties
        
        private MainWindow mainWindow;
        
        public MainWindow MainWindow
        {
            get
            {
                return mainWindow;
            }
        }
        
        #endregion
        
        #region Methods
        
        public void Run()
        {
            Application.Run();
        }
        
        private static void InitIcons()
        {
            Invisible widget = new Invisible();
            
            //Window.DefaultIcon = Gdk.Pixbuf.LoadFromResource("Logo.png");
            Window.DefaultIconList = new Gdk.Pixbuf[] {
                widget.RenderIcon(Stock.Network, IconSize.Menu, null),
                widget.RenderIcon(Stock.Network, IconSize.Dialog, null)
            };
            
            IconFactory iconFactory = new IconFactory();
            string[] icons = {"user-online", "user-offline", "user-passive"};
            
            foreach (string icon in icons)
            {
                IconSource source = new IconSource();
                source.Pixbuf = Gdk.Pixbuf.LoadFromResource(icon + ".png");
                
                IconSet iconSet = new IconSet();
                iconSet.AddSource(source);
                
                iconFactory.Add(icon, iconSet);
            }
            iconFactory.AddDefault();
        }
        
#if GNOME
        private static void OpenUrl(Gtk.AboutDialog about, string url)
        {
            Gnome.Url.Show(url);
        }
#endif
        
        private static Widget CustomWidgetHandler(Glade.XML xml,
            string funcName, string name, string string1, string string2,
            int int1, int int2)
        {
            switch (funcName)
            {
                case "ChatView":
                    return new ChatView();
                
                case "HistoryEntry":
                    return new HistoryEntry();
                
                case "SearchFileTypeComboBox":
                    return new SearchFileTypeComboBox();
                
                case "SearchResultView":
                    return new SearchResultView();
                
                case "UserView":
                    return new UserView();
                
                default:
                    return null;
            }
        }
        
        #endregion
    }
}

Re: [Java-gnome-developer] Notebook example code WITH close button on each tab

[Khiraly <khi...@gm...>]

Hi!

> It can be compiled, and runs fine. What is MISSING:
> 
> 1. Global keybindings (lin 43 - 51)
> 2. It cant dinamically calcule the icon size from the theme (line 85-87)
> 3. the close button remove always the actual page, and not where it was
> clicked (line 148)

Finally all of the above issues was resolved, many thanks for all the
java-gnome people at #java-gnome channel (AfC, ajocksch, rcjsuen,
ijuma).

To resume:
Notebook example program whith close button on each tab*.
Global keybindings added:
Ctrl-t - new notebook page
Ctrl-w - close current notebook page
Ctrl-q - quit application

Screenshot:
http://img205.imageshack.us/img205/3049/notebookwithclosebutton0xk.png
Sourcecode: http://pastebin.com/699104

Any comment, suggestion is really wellcome.

*: the firefox way seams to be unimplementable. Where is only one close
button after the tabs. There is no GTK app, what is able to do this. 

===

This application generated two bugreport: 
http://bugzilla.gnome.org/show_bug.cgi?id=340671
http://bugzilla.gnome.org/show_bug.cgi?id=340675

I've added on the hintsAndTips page about global keybindings (thx to
ajocksch):
http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/GlobalKeybindings

I have added this NotebookExample code to the hintsAndTips page:
http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/HowToNotebook

Best regards, 
 Khiraly

Re: [Java-gnome-developer] Global keybindings (unimplemented?)

[Adam J. <ajo...@re...>]

Khiraly wrote:
> Hi!
>
> I have this python code:
>
> # key accelerators
> self.accel_group = gtk.AccelGroup()
> self.accel_group.connect_group(ord('q'), 
>                  gtk.gdk.CONTROL_MASK, 
>                  gtk.ACCEL_LOCKED, 
>                  self.delete)
> self.accel_group.connect_group(ord('w'), 
>                  gtk.gdk.CONTROL_MASK, 
>                  gtk.ACCEL_LOCKED, 
>                  self.remove_current_book)
> self.accel_group.connect_group(ord('t'), 
>                  gtk.gdk.CONTROL_MASK, 
>                  gtk.ACCEL_LOCKED, 
>                  self.add_new_book)
>
> This python code is implementing global keybindings:
> Ctrl-Q - quit the application
> Ctrl-W - close the active notebook page
> Ctrl-T - add a new notebook page
>
> Can somebody help me to port this to java?
> Im not finding any connect_group/connectGroup method anywhere.
>   
In order to use keyboard accelerators, you should create an Action 
object and then assign the keyboard shortcut to that. Here's an example:
        // Close action
        AccelGroup ag
        this.close = new Action("close", "Close", "Close Window",
                GtkStockItem.CLOSE.getString());
        this.close.setAccelGroup(ag);
        this.close.setAccelPath("<myWin>/File/Close");
        this.close.addListener(new ActionListener() {
            public void actionEvent(ActionEvent action) {
                myWindow.this.destroy();
            }
        });
        AccelMap.changeEntry("<myWin>/File/Close", KeyValue.x,
                ModifierType.CONTROL_MASK, true);
        this.close.connectAccelerator();
You will also have to set the accelerator group for the window you want 
the keyboard shortcut to be active in by using 
org.gnu.gtk.Window.addAccelGroup(). You can find more information about 
Actions in the online javadocs at 
http://java-gnome.sourceforge.net/docs/javadoc/index.html

Hope this helps,

Adam Jocksch

[Java-gnome-developer] Notebook example code WITH close button on each tab

[Khiraly <khi...@gm...>]

Hi!

I've developped a notebook example program in python, with global
keybindings and close button on each tab.
Screenshot:
http://img205.imageshack.us/img205/3049/notebookwithclosebutton0xk.png

The program has the following features:

- Close button on each tab
- Global keybindings (Ctrl-q - quit, Ctrl-w - close the actual tab,
Ctrl-t - add a new notebook tab)

The sourcecode: http://pastebin.com/690534

Im porting this python code to java. I want to make working the same
features. And really want to make included this example code in the
documentation.

The current code can be found here: http://pastebin.com/697738

It can be compiled, and runs fine. What is MISSING:

1. Global keybindings (lin 43 - 51)
2. It cant dinamically calcule the icon size from the theme (line 85-87)
3. the close button remove always the actual page, and not where it was
clicked (line 148)

I have trouble with the 3. point (some java help really appreciated),
for the 1-2 have no idea (I think its unimplemented).

Thanks for any help!

Best regards, 
 Khiraly

[Java-gnome-developer] Global keybindings (unimplemented?)

[Khiraly <khi...@gm...>]

Hi!

I have this python code:

# key accelerators
self.accel_group = gtk.AccelGroup()
self.accel_group.connect_group(ord('q'), 
                 gtk.gdk.CONTROL_MASK, 
                 gtk.ACCEL_LOCKED, 
                 self.delete)
self.accel_group.connect_group(ord('w'), 
                 gtk.gdk.CONTROL_MASK, 
                 gtk.ACCEL_LOCKED, 
                 self.remove_current_book)
self.accel_group.connect_group(ord('t'), 
                 gtk.gdk.CONTROL_MASK, 
                 gtk.ACCEL_LOCKED, 
                 self.add_new_book)

This python code is implementing global keybindings:
Ctrl-Q - quit the application
Ctrl-W - close the active notebook page
Ctrl-T - add a new notebook page

Can somebody help me to port this to java?
Im not finding any connect_group/connectGroup method anywhere.

The first line, its simple:
AccelGroup accelGroup = new AccelGroup();
But the others not. 

Any help is really appreciate!

Khiraly

[Java-gnome-developer] gtk.icon_size_lookup_for_settings

[Khiraly <khi...@gm...>]

Hi!

What is the java equivalent for the icon_size_lookup_for_settings
function call?

Here is a code (in python), what I want to port to java:

settings = gtk.Widget.get_settings (button)
    (w,h) = gtk.icon_size_lookup_for_settings (settings,
gtk.ICON_SIZE_MENU)
    gtk.Widget.set_size_request (button, w + 4, h + 4)


Thx in advance, 
 Khiraly

[Java-gnome-developer] Architecture Question II.

[Cam B. <ca...@gm...>]

Hello,

So I got my development environment straightened out, read the 
documentation and designed my gui. The problems that I had before was 
because of misconfiguration of java.library.path.

I like to make a graph visualization application using prefuse toolkit. 
(prefuse.sourceforge.net) I have not been able to compile prefuse with 
gcj, so I am hanging out with sun-jvm, which works
without problem.

The question is this: The main visualization component in prefuse is 
Display, which extends JComponent, and uses lots of swing and awt. Can I 
embed this component inside the glade generated GUI?
Since the whole thing works on suns jvm, I don't exactly see why it 
could not be done. Like inside a small window I like to show my 
visualization.

If there is no way around it, or performance is issue, then I will just 
go with a Macintosh style application. (menu on top, controls in some 
window, and prefuse display in another)

Thanks a bunch for any ideas/recommendation.

Best Regards,
C. Bazz

Re: [Java-gnome-developer] Result of yesterdays IRC meeting

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

On Sun, 2006-04-30 at 21:06 -0400, Andrew Cagney wrote:
> - topic 3: autogeneration
> ??? from pygtk invited; very helpful on what they do;

That was Johan Dahlin - jdahlin. You can usually find him in
#gnome-hackers. Come to think of it, you can usually find most of us
there :)

>  My take is that 
> everyone agreed it was a good idea and that pygtk (even though it was 
> using !^*(@!)$^&* lisp) was going to be the best source for input files 
> as it had the most complete coverage;

The fact that it's in Lisp doesn't bother me per-se...

<anecdote>
Lisp never made sense to me, and the fact that many of the DocBook
formatting engines used Scheme markup to express stylesheets totally
bamboozled me. But about 18 months ago I had cause to learn XSLT and
although that is ALSO voodoo, it conveyed to me the idea of selecting
nodes and processing directives based on sets of nodes so isolated. Just
the other day I was reading the DocBook book 2.0 preprint and suddenly
the mushy DSSSL goo involved in selecting nodes and applying formatting
made sense to me. So I'm slightly less averse to Lisp than I once was.
</anecdote>

... but the fact that it is in Lisp is tertiary to the fact that they
seem to have formed a remarkably degree of completeness in their
articulation of the underlying GTK classes, functions, parameters and
return types.

I said tertiary because that in turn is secondary to the fact that it is
already done AND IN USE by another project. Assuming we were to go down
this road, to me the real win would be that we and the python bindings
could share the same set of meta data about GTK and friends. Yes this
would reduce overlap but I think even better it would improving the
number of eyes-on to the subsequent benefit of both projects.

It would have to be moved to a common module that could be in turn
depended on by both (for example) pyGTK and libgtk-java, but Johan
didn't think this was beyond the pale.

++

[There is still the huge issue of figuring out how to get our Java code
to align with such a theoretically generated JNI layer, but while not
completely orthogonal it is somewhat a separate question]

Follow up to java-gnome-hackers, I think.

AfC
Sydney

Re: [Java-gnome-developer] Result of yesterdays IRC meeting

[Igor F. <if...@re...>]

On Sat, 2006-04-29 at 09:57 +1000, Andrew Cowie wrote:
> On Fri, 2006-04-28 at 12:28 +0200, Trond Andersen wrote:
> > I didn't have the opportunity to participate at yesterday's IRC
> > meeting, but I'm curious about the result of the meeting.
> 
> One of the participants said he would post an IRC log; I can probably
> manage that as well if it doesn't work out for him, but spread the love
> and all that.
> 
> As for conclusions, I will probably email or blog about that next week.
> 
Since it hasn't been posted yet, here's my log. I've taken out most
of the channel join/leave/op actions, my apologies if I missed 
anything.

Might be nice if someone can put this up on the wiki.

Apr 27 16:55:03 Nafai	Hey
Apr 27 16:55:13 Nafai	AfC: I can post a meeting log somewhere if you like.
Apr 27 16:55:29 AfC	Nafai: if you like
Apr 27 16:55:39 Nafai	AfC: Who do I talk to about changing the Java Gnome website?  I want to add something to the page on using Eclipse
Apr 27 16:55:53 AfC	Nafai: it's a wiki - go ahead
Apr 27 16:56:47 Nafai	Ah, I'll do that.
Apr 27 17:00:12 rcjsuen	cagney: Sorry, I was, but I'm sure you've realized I no longer am.
Apr 27 17:00:52 AfC	Well
Apr 27 17:01:00 AfC	heraldTheMoose: op me please
Apr 27 17:01:10 ijuma_home	rcjsuen: why not?
Apr 27 17:01:25 AfC	mode +o ajocksch cagney ifoox ijuma_home rcjsuen sami
Apr 27 17:01:31 rcjsuen	ijuma_home: because I'm done with my editing ;)
Apr 27 17:02:13 rcjsuen	good ol' right-click in XCha
Apr 27 17:02:20 ijuma_home	rcjsuen: maybe i misunderstood what you were talking about :)
Apr 27 17:02:24 ajocksch	 /op works just as well :)
Apr 27 17:02:40 rcjsuen	ijuma_home: ^ cagney: rcjsuen, ping, are you editing the agenda?
Apr 27 17:02:48 ijuma_home	i'm not
Apr 27 17:03:24 AfC	That everybody? It's just for show anyway.
Apr 27 17:03:25 ijuma_home	rcjsuen: i thought you were actually saying that you were going to give a presentation, but not anymore :)
Apr 27 17:03:31 rcjsuen	lol
Apr 27 17:04:16 AfC	It's way too early in the morning to be up typing. I wish the cafe I hang out at down by the beach had internet. I need a cappuccino :)
Apr 27 17:04:19 sami	i am here :)
Apr 27 17:04:22 cagney	burp
Apr 27 17:04:30 AfC	'Morning boys
Apr 27 17:04:44 ajocksch	morning, evening, it's all the same online :)
Apr 27 17:04:46 cagney	cogh, warning glance at AfC
Apr 27 17:05:11 AfC	cagney: I said I'd give it a few minutes for people to straggle in.
Apr 27 17:05:17 pmuldoon	hi
Apr 27 17:05:18 AfC	cagney: but that's enough.
Apr 27 17:06:18 cagney	rcjsuen, don't worry
Apr 27 17:06:40 AfC	So we definitely have some people here who don't normally hang with us, so a big hello to jdahlin and vuntz 
Apr 27 17:07:07 cagney	AfC, are you controlling the agenda?  As well as the autogen, another topic would be simplifying the handle stuff to just use long
Apr 27 17:07:24 AfC	I am aware that people want to get home | go to bed, so we won't drag this out necessarily.
Apr 27 17:07:49 AfC	cagney: I'm actually not wedded to the agenda at all
Apr 27 17:08:16 AfC	cagney: but if anyone has a screenshot of something they're doing, feel free to post it in as we're talking. A few simultaneous conversations won't kill us.
Apr 27 17:09:23 *	AfC has changed the topic to: This channel is not moderated... so go ahead and say your say.
Apr 27 17:10:56 ifoox	so do you guys want to start?
Apr 27 17:11:05 ajocksch	lets :)
Apr 27 17:11:29 jdahlin	hi again
Apr 27 17:11:45 AfC	So... for those of you not from 'round these parts, cagney, ajocksch, ijuma, sami_laptop came out of nowhere about a year ago with a little project they wanted to do called "frysk"
Apr 27 17:12:23 *	cagney edits agenda
Apr 27 17:12:34 AfC	As usual, I'm sure Red Hat got more than they bargained for :) but seeing as how I'm here just because I want to have Java bindings to use 
Apr 27 17:13:03 AfC	I was super thrilled to see some experienced hackers come along and start nailing huge swaths of bugs and coverage issues.
Apr 27 17:13:22 ijuma	eh?
Apr 27 17:13:32 AfC	ijuma has been hacking on java-gnome for years
Apr 27 17:13:42 ijuma	I am not involved in frysk for the record :)
Apr 27 17:13:47 AfC	and without whom none of us would have a clue
Apr 27 17:13:49 ajocksch	and pmuldoon is :)
Apr 27 17:13:51 AfC	ijuma: (oops)
Apr 27 17:13:58 AfC	yeah yeah
Apr 27 17:14:12 ijuma	and I've been hacking on JG for about a year. ;)
Apr 27 17:14:22 ijuma	ok, that's the facts related to me :)
Apr 27 17:14:39 AfC	Good enough. Let's move on to issues since otherwise we'll loose people's attention
Apr 27 17:15:30 AfC	rcjsuen, ijuma: you guys have been talking extensively about what it would take to move org.gnu.glib from libgtk-java to glib-java. Where do we stand on that?
Apr 27 17:16:02 Asthoth	hello
Apr 27 17:16:10 AfC	Asthoth: hey there
Apr 27 17:16:43 Asthoth	i have a question, if a want to put an image and write some points at it , what is the best widget to use ?
Apr 27 17:16:52 *	AfC has changed the topic to: Migrate org.gnu.glib code from libgtk-java to glib-java
Apr 27 17:17:33 ijuma	AfC: I think what was agreed was that all gtk+ files would call a getGtkObjectHandle that is just like getGObjectHandle and getGObjectHandle would not have the GtkObject check
Apr 27 17:17:38 ijuma	or something to that effect anyway
Apr 27 17:17:40 rcjsuen	Well, we have the Pixbuf dependency that we need to resolve. For the C side, I believe the plan is to just dupe the code per se, renaming getGObjectHandle to getGtkObjectHandle in gtk_java.c and have a duped copy in jg_jnu.c.
Apr 27 17:18:37 *	cagney has changed the topic to: Java-GNOME Meeting: Migrate org.gnu.glib code from libgtk-java to glib-java
Apr 27 17:19:10 AfC	I can certainly do the search and replace across the code base - not all that different from when we renamed it from org.javagnome to org.gnu.glib.Handle; Remy, if you can spare an hour or two to help me with the C part we should be able to do that pretty quickly.
Apr 27 17:19:29 cagney	rcjsuen, would that be necessary (sounds garish), perhaphs the gobject base can better encapsulate it locally?
Apr 27 17:19:45 AfC	ijuma: This obviously falls into the category of "workable solution" but is there a better idea that you'd rather pursue? What Andrew just said, perhaps?
Apr 27 17:21:06 ijuma	AfC: there are probably better solutions. But that is the easiest one as far as I can see. I would not mind someone coming up with something more sophisticated though.
Apr 27 17:21:24 ijuma	cagney: do you have anything more concrete?
Apr 27 17:22:10 cagney	ijuma, no; just the unfortunate gut feeling of this doesn't feel right; what to other bindings do?
Apr 27 17:22:28 cagney	ijuma, however, if it's all properly hidden then technically it isn't a problem
Apr 27 17:22:39 ijuma	btw, not a duped copy in jg_jnu_c
Apr 27 17:22:55 ijuma	similar is the correct word
Apr 27 17:23:03 rcjsuen	ijuma: Well, duped minus the Gtk checks.
Apr 27 17:23:36 ijuma	cagney: Most bindings do auto-generation of many parts of their codebase :)
Apr 27 17:23:37 AfC	cagney: that's a good question. My guess is that being one library instead of 9 probably helps them get around this issue - if they expose a set PixBuf property at all.
Apr 27 17:23:43 ijuma	so, it's difficult to compare
Apr 27 17:23:50 ijuma	btw
Apr 27 17:24:08 ijuma	what are we talking about here? the pixbuf bit of the getGObjectHandle bit?
Apr 27 17:24:15 seanc	unfortunately; i'm not fully aware of the ins and outs of the Pixbuf dependency problem - but is there an initial sweep that could be made before this problem is met?
Apr 27 17:24:30 rcjsuen	seanc: sweep?
Apr 27 17:24:31 ijuma	s/of/or
Apr 27 17:24:55 rcjsuen	seanc: Basically, GObject is in org.gnu.glib, but there is a setPixbufProperty (or setPixbuf, I forgot) method, which takes org.gnu.gdk.Pixbuf as a parameter.
Apr 27 17:24:59 jdahlin	python does plenty of code generation and intro spection, as does gtk#
Apr 27 17:25:08 jdahlin	gtkmm does some code generation, but less
Apr 27 17:25:12 rcjsuen	So now glib magically has gdk (as in gtk+) as a dependency.
Apr 27 17:25:40 jdahlin	rcjsuen: that seems very broken
Apr 27 17:25:44 AfC	seanc: so for historical reasons (50% that there used to be just java-gtk and java-gnome) org.gnu.glib is [still] in libgtk-java. You and others have suggested that we clean up that nastiness, but GObject has a setPixbufProperty() or whatever.
Apr 27 17:25:46 ijuma	jdahlin: it is :)
Apr 27 17:25:56 rcjsuen	jdahlin: sadly :x
Apr 27 17:26:34 jdahlin	rcjsuen: do you have a way of convertion a native java object to/from a GValue ?
Apr 27 17:26:40 jdahlin	converting, sorry
Apr 27 17:27:16 cagney	does being able to read the long|int of a Handle matter?  It's seeting it that needs the paranoia right?
Apr 27 17:27:29 cagney	s/seeting/setting
Apr 27 17:28:17 rcjsuen	jdahlin: I believe we take the object then we place it in a (G)Value, then we have the value set its type as a pixbuf.
Apr 27 17:28:19 AfC	So I opened http://bugzilla.gnome.org/show_bug.cgi?id=337453 a little while back; as I Was doing so I realized that *nothing in our code base actually uses this method*... so just
Apr 27 17:28:36 AfC	removing it and movind GObject goes a long way to making me happy.
Apr 27 17:29:03 ijuma	that method is just a convenience method
Apr 27 17:29:12 ijuma	i don't understand why it was added there, but it was...
Apr 27 17:29:40 ijuma	and none of the people who did it are here atm, so we can't even complain to them ;)
Apr 27 17:29:43 cagney	ijuma, sounds like "oops"
Apr 27 17:29:45 AfC	But the real issue is the C code for getGObjectHandle() not having a GTK specific object check?
Apr 27 17:29:47 cagney	:-)
Apr 27 17:29:56 ijuma	cagney: hehe
Apr 27 17:31:16 AfC	[Not wanting to jump ahead, but if Handle was a parent class of everything (as opposed to used as a delagate to throughout) would that give us a different way to approach this?]
Apr 27 17:31:33 >sami_laptop<	yo, I'm gonna take off, so if anybody wants something from me tell them I left :)
Apr 27 17:31:39 ijuma	cagney: I trust you know more about 64-bit issues than I do, so I'll just take your word for it :)
Apr 27 17:31:57 cagney	ijuma, ignore 64-bit :-)
Apr 27 17:32:20 ijuma	heh
Apr 27 17:32:23 seanc	ok, i understand now - so the proposal is to creating a GTKObject extending GObject which has the setPixbufProperty and then move GObject over... the only problem being anyone who might be using setPixbufProperty on GObject itself. well I for one just did a complete search across all my projects and dont use it. Is the question - are we comfortable making this slight slight break?
Apr 27 17:32:52 AfC	seanc: in a word, yes :)
Apr 27 17:32:57 ajocksch	I'm fine with it
Apr 27 17:33:15 AfC	seanc: one of these days we'll need to bump the major version number, but whatever.
Apr 27 17:33:34 ajocksch	(I've seen set<blah> used in C a few times, as a way to extend a widget. Seems to me that's mostly useless since you can do that on the java side)
Apr 27 17:34:07 seanc	AfC: well, i'd certainly way in and so go for it - especially since no one to date can be found that uses it :)
Apr 27 17:34:14 cagney	AfC, if the pointer is guarenteed (by other means) to point to the claimed object then why the check?
Apr 27 17:34:14 AfC	seanc: ... and then there turns out to be a problem holding us back down in the JNI layer somewhere
Apr 27 17:34:28 AfC	cagney: [I didn't write it :)]
Apr 27 17:35:52 ijuma	cagney: what check?
Apr 27 17:36:38 AfC	ijuma: presumably the check that you wanted to keep resulting in a need create a getGtkObjectHandle() instead of just using getGObjectHandle() ?
Apr 27 17:36:57 cagney	ijuma, Afc disclaimed: [Not wanting to jump ahead, but if Handle was a parent class of everything (as opposed to used as a delagate to throughout) would that give us a different way to approach this?]
Apr 27 17:37:12 ijuma	that check is needed because you want to do a different thing if it's a GtkObject because it has a floating reference
Apr 27 17:37:23 AfC	[This is indeed a fairly small issue, but it's warming up our brains well :)]
Apr 27 17:37:30 AfC	cagney: why don't we move to that then?
Apr 27 17:37:31 ijuma	or _may_ have one
Apr 27 17:37:34 cagney	ijuma, ok
Apr 27 17:38:29 AfC	cagney: so you want to talk about switching us [back to] long instead of using a Handle object?
Apr 27 17:38:39 ijuma	i think int was used before
Apr 27 17:38:44 cagney	AfC, is ^^ resolved?
Apr 27 17:38:45 ijuma	even though i wasn't around then
Apr 27 17:39:12 AfC	cagney: no, but let's see if this discussion changes the shape of the GObject|GTKObject question
Apr 27 17:39:26 ijuma	the Handle as a superclass doesn't give us anything really
Apr 27 17:39:33 ijuma	in that case, we may as well just have a long field
Apr 27 17:39:33 AfC	[ie, go ahead and talk about one, the other, or both]
Apr 27 17:39:54 ijuma	the point of having the delegate is that the correct subclass is created in the jni side
Apr 27 17:39:55 AfC	ijuma: wouldn't we still need something to be the superclass to hold said long?
Apr 27 17:40:04 ijuma	AfC: that could be Struct
Apr 27 17:40:09 cagney	ijuma, well (yes I'll regret saying this), if the Gtk Object did super(Handle) then it might
Apr 27 17:41:07 ijuma	i'm not sure i understand, we already have a top class that can hold a pointer
Apr 27 17:41:33 AfC	[It's too bad - Struct seems such a bad name for the top of a class hierarchy :)]
Apr 27 17:41:39 cagney	ijuma, right, instead of a pointer, hold a long
Apr 27 17:41:55 ijuma	cagney: yeah, i'm just saying that you do _not_ need any other class for that
Apr 27 17:42:05 ijuma	just put it at the top class in the hierarchy atm
Apr 27 17:42:25 cagney	    /** Holder for the raw object pointer. */
Apr 27 17:42:25 cagney	    private Handle handle = null;
Apr 27 17:42:32 ijuma	yeah
Apr 27 17:42:43 ijuma	change that to private long handle, right?
Apr 27 17:42:45 *	cagney realiases we're violently agreeing :-)
Apr 27 17:42:46 AfC	cagney: you know, it's funny - when we met in Toronto last April, fitzsim and I both suggested we just go to a long (on the grounds that > 64 bit systems weren't likely to bother us in the next year or two) but Jeffery had *just* finished ripping *everything* to Handle from int and so that was that
Apr 27 17:42:52 cagney	ijuma, yep
Apr 27 17:43:21 ijuma	cagney: yeah, we are in agreement there then.
Apr 27 17:43:22 cagney	AfC, oops :-)
Apr 27 17:43:42 AfC	Does everything that need to extend Struct? I'm thinking of the not-GObject stuff like Enum and Boxed and what not. 
Apr 27 17:43:44 *	AfC pulls up Eclipse
Apr 27 17:43:59 ijuma	ok, so if you were to use longs, what measures would have to be taken to make sure it worked fine on 32 bit systems?
Apr 27 17:44:14 cagney	AfC, I can think of one reason for having the handle - it lets you safely pass it around from within java; publish a java method that takes a long as a parameter and crash-n-burn :)
Apr 27 17:44:23 ijuma	AfC: yeah, you better check that. It's been a while since i actually looked at the code ;)
Apr 27 17:44:56 AfC	... but it would save us having to pass the Handle on *every* bloody native method call. That would be nice.
Apr 27 17:45:03 AfC	ijuma: coming up now
Apr 27 17:45:36 cagney	ijuma, not sure what you mean, this code:
Apr 27 17:45:43 cagney	void*
Apr 27 17:45:43 cagney	getPointerFromHandle (JNIEnv* env, jobject handle)
Apr 27 17:45:43 cagney	{
Apr 27 17:45:43 cagney	  void* pointer;
Apr 27 17:45:43 cagney	  if (!handle)
Apr 27 17:45:44 cagney	    return NULL;
Apr 27 17:45:46 cagney	  jfieldID pointerField = getPointerField (env);
Apr 27 17:45:48 cagney	  if (pointerField == NULL)
Apr 27 17:45:50 cagney	    return NULL;
Apr 27 17:45:52 cagney	  pointer = (void*)(*env)->GET_POINTER_FIELD(env, handle, pointerField);
Apr 27 17:45:54 cagney	  return pointer;
Apr 27 17:45:58 cagney	}
Apr 27 17:46:15 cagney	(and the corresponding equivalent in libgtk-java would get simplified, can instead pull the handle from the original pointer
Apr 27 17:46:26 *	AfC has changed the topic to: Java-GNOME Meeting: Migrate org.gnu.glib code from libgtk-java to glib-java... which raises the question of how we handle pointers to the native bits
Apr 27 17:47:09 cagney	AfC, [but it would save us having to pass the Handle on *every* bloody native method call] ajocksch sami_laptop and I encountered that one when fixing 64-bit not plesant
Apr 27 17:47:12 AfC	org.gnu.glib.Enum extends Object. That's one we'd have to fix...
Apr 27 17:47:52 ijuma	cagney: I personally don't see much of a benefit. You still have to extract the pointer from the object
Apr 27 17:47:55 AfC	cagney: as in "refactoring at that point is not pleasant to contemplate" or as in "it's a pain in the ass now, please change it!"
Apr 27 17:48:42 cagney	ijuma, I see the following: half as many objects allocated (that means half the load on the poor*1000 GCJ garbage collector); ...
Apr 27 17:49:08 ajocksch	AfC, for the most part aren't the classes that extend Enum just collections of object-encapsulated integers with a factory method?
Apr 27 17:49:09 AfC	cagney: [that's the benefit of not passing them in all the native methods, yeah?]
Apr 27 17:49:16 ijuma	well, you don't allocate a handle every time
Apr 27 17:49:18 ijuma	it gets reused
Apr 27 17:49:27 AfC	ijuma: it's still a reference...
Apr 27 17:49:34 ijuma	there's only _one_ handle per native object
Apr 27 17:49:37 cagney	ijuma, less cpu load: a single 64-bit read then cast to 32-bit is cheaper and less cache smashing than a de-reference (but that's hard to truely prove)
Apr 27 17:50:22 AfC	ajocksch: I'm just looking for things that might have references to underlying Glib|GTK code (ie, use Handle) that don't presently extend Struct.
Apr 27 17:50:26 ijuma	I personally am not a fan of hard to prove theories. Benchmarks are good though ;)
Apr 27 17:50:29 cagney	ijuma,  [it's still a reference...] yes and it's two objects for every gtk object
Apr 27 17:50:49 *	AfC looks at the C side of Enum
Apr 27 17:50:52 ajocksch	AfC: Enums don't use Handle AFAIK
Apr 27 17:51:13 AfC	Oh! There isn't a C side there. Lovely :)
Apr 27 17:51:14 ijuma	like, if you go the long route, the benefit is clear, but still passing an object and extracting in the jni is not that good
Apr 27 17:51:23 ijuma	you still have to make jni calls to get the long from the object
Apr 27 17:51:39 rcjsuen	ajocksch: Right, Enums and Flags don't. Enums and Flags are also practically identicaly, I don't see why we need both.
Apr 27 17:51:49 ijuma	rcjsuen: they're different
Apr 27 17:52:02 ijuma	flags have the whole or, and and things like that
Apr 27 17:52:20 seanc	on the point of passing through handle everywhere, could one not just, from jni, make another call back to the object calling getHandle().getPointer() ? (i might be missing the overall point)
Apr 27 17:52:20 rcjsuen	If you diff the two, it's pretty much the same thing.
Apr 27 17:52:24 ajocksch	rcjsuen, what ijuma said. similar in impelementation, different in goal :)
Apr 27 17:52:31 AfC	ijuma: You're suggesting that using the JNI function to get a field value is [much] greater cost than using getPointerFromHandle() on the passed jobject Handle?
Apr 27 17:52:41 ijuma	not greater
Apr 27 17:52:44 ijuma	just not better
Apr 27 17:52:49 AfC	ah
Apr 27 17:52:55 ijuma	i'm saying that you may as well pass the long
Apr 27 17:52:56 cagney	ijuma, right, cut out the de-reference step, before entering jni code (and for that matter all those extra arguments :-) ( another bug ajocksch sami_laptop and I had was figuring out what handle went where :-)
Apr 27 17:53:06 rcjsuen	ajocksch, ijuma: Okay, I see what you two mean now. I guess the class is the same but those that don't extend Enum don't have an or method (I guess).
Apr 27 17:53:46 rob	nite
Apr 27 17:53:59 rcjsuen	rob: see you!
Apr 27 17:54:01 ajocksch	rcjsuen: And more importently there's a logical distinction between an enumeration (a collection of constants) and a flag (a bunch of toggles, of which some/none/all my be active)
Apr 27 17:54:19 ijuma	JNI is not pleasant and I don't think it can be.
Apr 27 17:54:22 rcjsuen	ajocksch: Good point.
Apr 27 17:54:34 cagney	ijuma, true, to pull and pass the pointer means making it more visible, and trusting that nothing extending it lies to jni code
Apr 27 17:54:38 AfC	So for me the elegance [er, value for effort] would come from not having to pass Handle (or long) at all on each native call. Wholesale removing that first parameter across the board, and instead getting the pointer from super.[super.[super.[super].... Struct's "long handle" field that we were suggesting.
Apr 27 17:54:47 cagney	s/pointer/long/
Apr 27 17:54:48 rcjsuen	We should put the or/and/xor code in Flags then. Since right now I'm seeing those methods in Enum extensions too.
Apr 27 17:55:21 AfC	rcjsuen: could you note that down somewhere - we might loose track of it in the current discussion.
Apr 27 17:55:43 rcjsuen	AfC: k
Apr 27 17:55:50 AfC	cagney: if it is private long handle then nothing can extend if Java side...
Apr 27 17:56:23 cagney	AfC, right, there was a suggestion on the table to s/Handle/long/ as the extra parameter
Apr 27 17:56:24 AfC	cagney: but a nice C side getPointerFromErTheStructThatIAm()
Apr 27 17:56:34 cagney	ajocksch, yes
Apr 27 17:56:42 cagney	s/ ajocksch / AfC 
Apr 27 17:56:44 ijuma	but the issue here is that you will still have lots of jobject parameters
Apr 27 17:56:49 ijuma	instead of handle parameters
Apr 27 17:56:57 ijuma	so it's not much easier to understand anyway
Apr 27 17:57:25 *	cagney resists temptation to suggest rewriting in CNI (no I'm not serious!!!)
Apr 27 17:57:26 ijuma	but i don't have a strong opinion
Apr 27 17:57:37 ijuma	cagney: heh
Apr 27 17:57:47 cagney	ijuma, so, "show us the money?"
Apr 27 17:57:49 AfC	So there are two suggestions at play:
Apr 27 17:57:55 cagney	(you're asking us :-)
Apr 27 17:58:02 ijuma	cagney: yeah :)
Apr 27 17:58:23 ijuma	in an idea world people would do some tests and show that making such change would actually make a difference
Apr 27 17:58:27 AfC	1) refactor Handle to long as the first parameter in all the native methods to reduce reference pressure a bit. +side is avoids a dereference. - side is it doesn't really change the code.
Apr 27 17:58:32 ijuma	at least on a small scale
Apr 27 17:58:53 AfC	taking a much greater leap of the deep end
Apr 27 17:59:37 AfC	2) refactor everything so that Struct holds the "Handle" (long presumably) and remove the 1st Handle parameter from every native method out there.
Apr 27 18:00:23 AfC	+ side is it reduces Handle reference creation by a factor of 2. - side is it's a pretty huge refactoring
Apr 27 18:00:31 AfC	That a good summary?
Apr 27 18:00:50 cagney	AfC, 1) is dangerous - java code can pass the native code the result of C.random()
Apr 27 18:01:05 cagney	AfC, but yes summary I think is ok
Apr 27 18:01:33 ijuma	i don't buy that. I mean the c side can do nasty things to
Apr 27 18:01:38 ijuma	too*
Apr 27 18:01:51 ijuma	as long as you protect your native methods you're fine
Apr 27 18:01:52 cagney	ijuma, agreed
Apr 27 18:02:06 ijuma	as fine as you can be anyway :)
Apr 27 18:02:09 AfC	cagney: so which course of action (or a #3) meets the need you expressed?
Apr 27 18:02:47 cagney	ijuma, protect == package-local or private I assume
Apr 27 18:02:48 seanc	i think the concrete benefits of doing this might not outweigh the amount of risk and effort involved... whats the general feeling?
Apr 27 18:02:52 pmuldoon	AfC, by what factor is option #2 more work tht #1 (putting it in a time frame of reference)
Apr 27 18:03:29 cagney	AfC, I don't think #1 buys much; #3 is 1+2 ...?
Apr 27 18:03:29 ijuma	cagney: i've even say private. It's very rare that a native method has to be called from outside its class
Apr 27 18:04:01 AfC	cagney: sure
Apr 27 18:04:08 ijuma	cagney: #1 as far as I see would imply not having any handles anymore
Apr 27 18:04:11 cagney	ijuma, hmm, that's even more agressive than I was thinking :-)
Apr 27 18:04:12 ijuma	maybe i wasn't clear
Apr 27 18:04:20 ajocksch	ijuma, or even from a subclass for that mater
Apr 27 18:04:27 ijuma	you'd store the long in the Struct
Apr 27 18:04:28 cagney	ijuma, ah
Apr 27 18:04:34 ijuma	but pass the long field to jni
Apr 27 18:04:38 ijuma	saving the jni to java call
Apr 27 18:04:49 ijuma	that's the most performance oriented way i can see
Apr 27 18:05:18 ijuma	but you'd be getting these longs instead of jobjects
Apr 27 18:05:50 ijuma	which can be somehow bad i guess, but in practical terms i think it's the same
Apr 27 18:05:51 cagney	I kind of like my objects
Apr 27 18:05:53 AfC	pmuldoon: mulling over the answer to that. All these variants are big invasive changes.
Apr 27 18:06:01 ijuma	you can always add some code in the java side to see what you're passing
Apr 27 18:06:26 ijuma	cagney: you do? we never do _anything_ with the jobjects apart from getting the int/long from them
Apr 27 18:06:36 ijuma	well, 90% of the time
Apr 27 18:07:00 cagney	ijuma, #1 change would mean that the methods are native+static; #2 the methods are bound to an instance
Apr 27 18:07:09 cagney	(observation not opinion)
Apr 27 18:07:12 ijuma	cagney: that's true
Apr 27 18:07:18 ijuma	does that make a difference?
Apr 27 18:08:13 cagney	ijuma, it would, would it matter I don't know
Apr 27 18:08:32 ijuma	anyway, swt does something similar to what i am saying but they use a pre-processor
Apr 27 18:08:44 ijuma	that converts int to long in the source code
Apr 27 18:08:58 ijuma	so they actually use an int for 32-bit builds and long for 64 bit builds
Apr 27 18:09:16 ajocksch	personally I like #1
Apr 27 18:09:46 AfC	So what's so wrong with accessing a handle field on Struct from the JNI side?
Apr 27 18:10:06 ijuma	AfC: it's slow
Apr 27 18:10:15 ijuma	jni to java and java to jni is slow
Apr 27 18:10:39 ijuma	how slow depends on the implementation
Apr 27 18:11:00 ijuma	but that is a bigger problem in the sun vm for example than short-lived objects
Apr 27 18:11:06 AfC	ijuma: but no slower than what we're doing now passing Handle and doing java -> jni?
Apr 27 18:11:12 ajocksch	Also it requires the call (right now getPointerFromGObject) that obfuscates the JNI a little
Apr 27 18:11:25 ijuma	ajocksch: good point
Apr 27 18:11:38 ajocksch	passing the pointer seems cleaner
Apr 27 18:11:44 ijuma	AfC: sure, but if you're going to go for a performance-oriented version, you may as well do it right
Apr 27 18:11:45 AfC	ajocksch: that's my point - we have that [code|cost] now.
Apr 27 18:11:49 cagney	ijuma, for swt doesn't that effectively make things non-portable?
Apr 27 18:11:51 AfC	ijuma: true
Apr 27 18:12:15 *	cagney wishes gnu.gcj.RawPointer was part of standard
Apr 27 18:12:22 ijuma	cagney: in what way? they just have to have a platform-specific binaries.
Apr 27 18:12:36 ijuma	the build system takes care of the rest
Apr 27 18:12:40 cagney	ijuma, and platform specific .jar's?
Apr 27 18:12:45 ijuma	but yeah, it's error-prone
Apr 27 18:13:05 ijuma	cagney: you mean the source code? well, if you don't want to run the pre-processor, yes (for 64 bit)
Apr 27 18:13:27 ijuma	i've had many cases where eclipse just crashed because they failed to annotate some field
Apr 27 18:13:46 ijuma	they don't test very well on 64 bit unfortunately
Apr 27 18:13:56 ijuma	not a supported platform
Apr 27 18:14:13 cagney	ijuma, if swt is doing s/POINTER/int|long/ in java files then doesn't end up with two different .class files dependant on the expansion; hence a .jar will only run with a specific .jni? (But I'mgetting off topic)
Apr 27 18:14:24 AfC	Can't we do a bitwise check on a long to make sure it isn't larger than 2^32 and carry on?
Apr 27 18:14:41 ijuma	cagney: you're right, that's true.
Apr 27 18:15:21 ijuma	i guess it's not a big deal though. If you have to release a different native library, it's not a problem to release a different jar too i guess
Apr 27 18:15:31 AfC	yeah
Apr 27 18:16:15 AfC	It seems we're not going to reach closure on this one today. That's fine. cagney, perhaps you'd mull the issue over some more. We can talk about it again further here.
Apr 27 18:16:18 ijuma	cagney: so what would you have to do on the long to have it work correctly in a 32 bit environment? i think you have the best knowledge in this area
Apr 27 18:16:28 pmuldoon	ijuma, wandering into the woods, but SWT uses the concepts of fragments to do that.
Apr 27 18:16:41 ijuma	pmuldoon: yeah
Apr 27 18:17:31 pmuldoon	It's a shame Andrew Haley is not around as he did the 64 bit port of SWT and really went deeply into this area
Apr 27 18:17:39 AfC	As for the org.gnu.glib switch, it seems like we're all set for that. I'll hold off on it a bit yet to see if anything else emerges.
Apr 27 18:18:01 AfC	pmuldoon, cagney: maybe you two could chat with him about it and see what he has to recommend to us.
Apr 27 18:18:18 ijuma	pmuldoon: oh, was it Andrew Haley?
Apr 27 18:18:33 ijuma	i thought it was some of the swt guys
Apr 27 18:18:35 ijuma	interesting
Apr 27 18:18:49 AfC	Next topic?
Apr 27 18:18:50 pmuldoon	ijuma, it was years ago, back in the Eclipse 2.x days
Apr 27 18:19:06 ijuma	pmuldoon: yeah i know. I read the bug report.
Apr 27 18:19:22 AfC	Someone added "gtk+ 2.10 branch"
Apr 27 18:19:28 pmuldoon	ijuma, I'll see if I can find the patches with my bugzilla fu ;)
Apr 27 18:19:31 rcjsuen	AfC: So we're going to just break api and remove the getPixbuf methods? ^That was me
Apr 27 18:19:37 ijuma	it's quite a pain to have to do /*long*/ int for _all_ pointers though
Apr 27 18:19:51 ijuma	and if you forget... crash and burn ;)
Apr 27 18:19:53 AfC	I opened a bug a while back to remind me to do it when the time comes. Is it that time now?
Apr 27 18:20:32 AfC	[I'm happy with multiple conversations... keep going on other topic if you like]
Apr 27 18:20:41 ijuma	AfC: probably, if people are actually going to make some of these changes
Apr 27 18:21:29 AfC	rcjsuen: no one is using them, so yes.
Apr 27 18:21:31 ajocksch	If we're going to slaughter API/ABI compatability, might as well (or at least go to 2.9 so we're signalling we're moving towards 2.10)
Apr 27 18:21:41 AfC	ajocksch: that's also fair
Apr 27 18:21:56 ajocksch	AfC, and probably more accurate, since 2.10 implies a stable release
Apr 27 18:22:10 AfC	yeah. I actually would have put it differently -
Apr 27 18:22:24 cagney	AfC, ijuma I got the feeling that static-native methods and passing the long was it - at least that way we keep our portable binary claim (and get to laugh at SWT) 
Apr 27 18:22:29 pmuldoon	ijuma, https://bugs.eclipse.org/bugs/show_bug.cgi?id=37775
Apr 27 18:22:36 AfC	Usually we have branched off stable and had HEAD on current development. 
Apr 27 18:23:14 ajocksch	AfC, right, same difference, just bump the autoconf version number in HEAD :)
Apr 27 18:23:21 ijuma	ok, i thought we'd have to do some sort of conversion
Apr 27 18:23:35 ijuma	if it just works, then even better
Apr 27 18:23:42 AfC	But we can do a branch for unstable instead... that means merging later which is hard with CVS.
Apr 27 18:23:48 ijuma	pmuldoon: that's the one
Apr 27 18:24:19 ajocksch	AfC, I'm all for simplicity. Let's let HEAD be development, and cut 2.9.x snapshots from it periodically until we feel 2.10 is ready
Apr 27 18:24:29 AfC	ajocksch: good show
Apr 27 18:25:01 ijuma	the relevant comment from that bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=37775#c16
Apr 27 18:25:06 *	AfC has changed the topic to: Java-GNOME Meeting: How we handle pointers to the native bits | When do we branch stable off?
Apr 27 18:25:42 AfC	I have http://bugzilla.gnome.org/show_bug.cgi?id=334840 open on the topic of branching.
Apr 27 18:27:19 AfC	Shall we tackle the bindings generation issue?
Apr 27 18:27:29 AfC	jdahlin: ping
Apr 27 18:27:31 *	cagney runs
Apr 27 18:27:39 *	cagney hides
Apr 27 18:27:41 jdahlin	sure
Apr 27 18:27:54 AfC	jdahlin: you maintain pyGTK, right?
Apr 27 18:28:07 jdahlin	AfC: that's right
Apr 27 18:28:19 jdahlin	I'm not sure if you are familiar with the way python bindings are generated
Apr 27 18:28:28 AfC	No, please go ahead
Apr 27 18:28:49 jdahlin	I collected some numbers a couple of minutes ago
Apr 27 18:29:04 jdahlin	there are about 220 classes and 3800 functions or methods wrapped
Apr 27 18:29:16 jdahlin	about 80% of them are generated by a code generator
Apr 27 18:29:29 jdahlin	the rest of them are manually _overridden_ as we say in pygtk-speak
Apr 27 18:30:06 jdahlin	if the java gnome were to adopt a similar scheme, you would be likely to save at least that work
Apr 27 18:30:20 jdahlin	+much
Apr 27 18:30:57 AfC	jdahlin: do you the introspection | generation at runtime or ahead of time to some static-ish library? I realize that python is very dynamic so I'm curious where the comparability might break down.
Apr 27 18:31:03 cagney	jdahlin, it's described in XML right
Apr 27 18:31:14 jdahlin	oh, I forgot to mention one thing
Apr 27 18:31:15 pmuldoon	jdahlin, how are you auto-generating  80% of the bindings (some along the concept of swig?)
Apr 27 18:31:46 jdahlin	we parse all the public headers of the libraries we wrap and save them in a big file full of s-expressions (lisp)
Apr 27 18:32:02 *	AfC has changed the topic to: Java-GNOME Meeting: Considering code generation possibilities 
Apr 27 18:32:09 jdahlin	AfC: we do introspection of signals and properties. Not sure if that is possible in Java.
Apr 27 18:32:27 jdahlin	pmuldoon: we use a custom code generator that james henstridge wrote a couple of years ago
Apr 27 18:32:28 *	cagney wonders what chance there would be for the bindings people to make the C people specify their bindings in XML
Apr 27 18:32:57 jdahlin	cagney: that's part of the plan for gobject introspection
Apr 27 18:33:06 AfC	Anyone have any idea what the GTK# folks are up to?
Apr 27 18:33:18 *	cagney I can never find their source code
Apr 27 18:33:25 jdahlin	kind of, I have not looked in detail at it
Apr 27 18:33:28 AfC	(in respect of this issue)
Apr 27 18:33:35 jdahlin	I know the store the information in xml and generate code
Apr 27 18:33:53 cagney	ah maybe that's whos code I looked at
Apr 27 18:34:04 ijuma	jdahlin: that gobject instrospection stuff is still ongoing? development seemed to have stopped at some point.
Apr 27 18:34:05 cagney	I know someone used xml
Apr 27 18:34:22 jdahlin	ijuma: It has sort of stopped recently yes. I hope mattias gets around to pick it up at some point
Apr 27 18:34:26 AfC	One of the things that ... troubles, no that's not the word. Things are always trade offs... but with something like Java we want to be able to get things into the generated code. JavaDoc if nothing else.
Apr 27 18:34:59 ijuma	jdahlin: Right.
Apr 27 18:35:02 rcjsuen	AfC: I think Gtk# has some Widget.cs.custom files that they inject things into the generated .cs file.
Apr 27 18:35:09 jdahlin	cagney: you can find it here http://svn.myrealbox.com/viewcvs/trunk/gtk-sharp/gtk/?rev=60018
Apr 27 18:35:16 cagney	jdahlin, tks
Apr 27 18:35:20 AfC	I've seen many approaches, ranging from "too bad, forget it" all the way up to using Interfaces that are hand specified with all the nice comments and then  classes generated and used as concrete instances.
Apr 27 18:35:24 rcjsuen	I never see their /// <xml> documentation in those files though, so I'm not sure what they do there.
Apr 27 18:35:47 jdahlin	AfC: that can be specified in the metadata format, or in a separate file
Apr 27 18:35:57 cagney	AfC, w,r,t, JavaDoc, good point
Apr 27 18:35:58 jdahlin	there are no real issues of integrating documentation which javadoc can pick up
Apr 27 18:36:37 jdahlin	AfC: I'd suggest that you reuse the .defs file in pygtk or the .xml files from Gtk#, that'll save you some additional work
Apr 27 18:37:09 AfC	jdahlin: big time. Someone, rcjsuen I think, suggested that about a year ago.
Apr 27 18:37:17 jdahlin	here is a simple example of the GladeXML description: http://cvs.gnome.org/viewcvs/gnome-python/pygtk/gtk/libglade.defs?view=markup
Apr 27 18:37:45 rcjsuen	AfC: Actually, I believe jvic brought those xml files to the table.
Apr 27 18:38:02 jdahlin	I should also mention that python has probably the most complete bindings for gnome
Apr 27 18:38:06 AfC	rcjsuen: ah, there we go. Credit where it's due.
Apr 27 18:38:18 jdahlin	and we're basically only 2 guys maintaining the whole stack, with occasional contributors of course
Apr 27 18:38:29 pancake	night all :) hope to end reading these lines somewhere tomorrow
Apr 27 18:38:40 rcjsuen	pancake: g'nite pancake, thx for dropping by
Apr 27 18:39:20 pancake	i was unable to participate, so, i need to sleep, it was a hard day for me
Apr 27 18:39:22 jdahlin	there's lots of effort and quality to gain by moving to using a code generator
Apr 27 18:39:47 pancake	have a nice talk!
Apr 27 18:42:23 ijuma	jdahlin: i agree with that
Apr 27 18:42:29 AfC	ijuma: I believe your suggestion all along has been to generate at least the JNI layer. Would you go further and generate the Java code too?
Apr 27 18:43:25 AfC	jdahlin: I'm not much for lisp, but I like what I see in your .defs files.
Apr 27 18:43:26 ijuma	AfC: if that could be done correctly, then why not? But the jni side would already be a huge improvement.
Apr 27 18:43:41 jdahlin	AfC: what sort of information is kept in jni and java code? why not do everything in jni?
Apr 27 18:43:57 seanc	with these things; a phased approach usually works well right? find the area the gains you the more with the least amount of effort - if that's the jni code... then....
Apr 27 18:44:02 jdahlin	AfC: it was the format decided by some gnome guys a long time ago
Apr 27 18:44:15 jdahlin	AfC: it's easy to parse, that's the main idea behind it
Apr 27 18:44:20 ijuma	the java side simply presents a java API to users
Apr 27 18:44:39 ijuma	it doesn't really do much apart from some error checking and such
Apr 27 18:44:55 jdahlin	we used do to it in two phases in python, but today we're only generating Python/C code (similar to jni)
Apr 27 18:45:16 ijuma	jdahlin: i think python integrates better with c though, doesn't it?
Apr 27 18:45:47 jdahlin	ijuma: I don't know so much about jni, so I'm not sure what's possible and what's not
Apr 27 18:45:59 ijuma	right
Apr 27 18:46:03 jdahlin	ijuma: from the c api in python you can do anything, quite easily
Apr 27 18:46:04 cagney	turing complete ...
Apr 27 18:46:30 AfC	jdahlin: there are a not inconsiderable number of places where our APIs diverge a touch, so it's not a 1-1 transform. And the event-signal system is mostly on the Java side.
Apr 27 18:47:27 AfC	jdahlin: it's pretty voodoo code.
Apr 27 18:47:36 jdahlin	an example of output from the pygtk code generator http://www.gnome.org/~johan/atk.c
Apr 27 18:47:50 jdahlin	about 95% of that is generated
Apr 27 18:48:06 jdahlin	search for override for the parts which aren't
Apr 27 18:48:17 AfC	jdahlin: and then you have (hand coded?) matching Python files for every class, or the py/C code is sufficient?
Apr 27 18:48:50 jdahlin	AfC: the Python/C code is enough, you have the classes, functions etc defined in there
Apr 27 18:50:13 ajocksch	ok everyone, I have to take off too at this point. I look forward to reading the logs :)
Apr 27 18:50:33 AfC	ajocksch: thanks for staying alte
Apr 27 18:50:39 rcjsuen	ajocksch: see you
Apr 27 18:50:47 ajocksch	AfC, no worries. Looks like we're making good progress :)
Apr 27 18:50:49 ajocksch	later all!
Apr 27 18:50:50 *	AfC is conscious of the time for Ismael too. We'll finish up shortly.
Apr 27 18:51:06 ijuma	AfC: no worries, i generally sleep late
Apr 27 18:52:01 AfC	jdahlin: Hm. We have to go to an extra layer. JNI is beastly. In one's Java code you have to express the names of methods you want to call. Then you run a prototype generator over that to get C header files, prototypes which you then implement with the code necessary to call whatever C library you're calling.
Apr 27 18:52:27 AfC	Say... can you define classes dynamically at runtime in Java from JNI?
Apr 27 18:53:08 ijuma	you can create a dynamic proxy, but i don't want to think how cumbersome it would be to do that from jni (if possible at all)
Apr 27 18:53:41 *	cagney head explodes :-)
Apr 27 18:53:44 AfC	So short answer, no
Apr 27 18:53:52 jdahlin	AfC: okay, I guess it's fine to do it two steps then
Apr 27 18:53:53 pmuldoon	It would be somewhat naughty to do so, even if you could ;)
Apr 27 18:53:58 jdahlin	anything that makes it easier to implement
Apr 27 18:54:11 AfC	pmuldoon: yeah. The compile time contracts would go right out the window.
Apr 27 18:54:35 AfC	jdahlin: on the up side, being strongly typed means that in an environment like Eclipse, code completion works beautifully
Apr 27 18:54:42 AfC	{shrug} it is what it is.
Apr 27 18:54:52 jdahlin	AfC: true, that is not really possible using PyGTK as it is right now
Apr 27 18:55:28 AfC	So one of the questions I'd have is how we would deal with generating C code on the one side and making sure it aligned with the JNI header files on the other.
Apr 27 18:56:08 AfC	That seems like a recipie for disaster. Which would seem to imply also generating Java code, or... 
Apr 27 18:56:17 *	AfC also has an exploding brain
Apr 27 18:56:22 cagney	AfC, didn't that get fixed; when 64-bittering "we" changed evertyhing to generate and include headers from the Java code
Apr 27 18:56:39 AfC	cagney: yes it did
Apr 27 18:56:52 AfC	cagney: so you're saying we could just let the C compile detect mismatches?
Apr 27 18:57:03 AfC	[were we to generate the JNI layer]
Apr 27 18:57:10 *	cagney wonders if -Werror was a topic for another day :-)
Apr 27 18:57:18 cagney	AfC, yes
Apr 27 18:57:21 pmuldoon	heh
Apr 27 18:59:11 cagney	looking over the file jdahlin threw at us; it isn't that far from Java except half the stuff lives in the generated .c file and half in the .java file (in a different format)
Apr 27 19:00:07 AfC	cagney: yeah. I'm mulling that over too. I wonder... 
Apr 27 19:00:12 pmuldoon	cagney, at atk.c? (is that what you are looking at)?
Apr 27 19:00:30 *	cagney googles for lisp2xml
Apr 27 19:01:19 cagney	AfC, benk just asked me if the logs will be posted?
Apr 27 19:01:25 AfC	So the question is how can we get what we can generate into .java form? A single generated .java file with ALL the native methods on it? A completely generated bindings, a la SWIG?
Apr 27 19:01:53 jdahlin	cagney: it would be quite nice to actually use the same source files
Apr 27 19:02:01 AfC	cagney: sure... Nafai said he was going to do so... or I can arrange something
Apr 27 19:02:57 AfC	jdahlin: you mean for us to just use the .defs files?
Apr 27 19:03:06 jdahlin	AfC: right
Apr 27 19:03:26 cagney	jdahlin, agreed
Apr 27 19:03:29 Nafai	Yeah, I can do so when the meeting is over
Apr 27 19:04:04 jdahlin	cagney: seems like jigsaw has a s-expression parser
Apr 27 19:04:05 pmuldoon	cagney, <<cagney googles for lisp2xml >> ... suprisingly there was a hit for it ;)
Apr 27 19:04:27 AfC	jdahlin: yeah, that would be smart. I don't suppose they are in a common packages somewhere?
Apr 27 19:05:33 jdahlin	AfC: I could only find the packages at http://www.w3.org/Jigsaw/
Apr 27 19:08:09 AfC	jdahlin: Oh, I meant "are the .defs files centrally packaged somewhere, or are they in pyGTK", heading towards
Apr 27 19:08:16 jdahlin	AfC: oh, sorry
Apr 27 19:08:32 jdahlin	AfC: not that I am aware of, but I think it could be arranged
Apr 27 19:08:38 AfC	jdahlin: would we have to clone and import those files periodically and update them, or could pkg-config find them for us
Apr 27 19:09:23 AfC	jdahlin: that might really help.
Apr 27 19:10:07 jdahlin	AfC: there is lots of tiny details there that are really useful, such as if the caller or the function is the owner of a return variable
Apr 27 19:10:37 AfC	jdahlin: that bites us all the time (or at least, we wonder about it often enough)
Apr 27 19:12:05 pmuldoon	Have to run, look forward to reading the minutes later tonight *waves*
Apr 27 19:12:20 AfC	Well this is definitely food for thought.
Apr 27 19:12:37 jdahlin	I need to run
Apr 27 19:12:41 AfC	I don't think we're going to get as far as deciding to embark on a major overhaul
Apr 27 19:12:53 AfC	but we've got some new ideas to work with
Apr 27 19:12:57 AfC	jdahlin: thanks for your imput
Apr 27 19:12:58 jdahlin	if you decide to use code generators, I'll be happy to answer questions
Apr 27 19:12:59 AfC	input
Apr 27 19:13:04 jdahlin	I'll be around here, just poke me
Apr 27 19:13:07 jdahlin	you're welcome
Apr 27 19:13:14 jdahlin	good luck :)
Apr 27 19:13:49 AfC	Well, two hours of this is about as much as I can handle. Adam wanted to talk about code formatting on the C side; we can pick that up another day.
Apr 27 19:14:23 rcjsuen	a'ite
Apr 27 19:14:43 ijuma	AfC: Go and have your coffee ;)
Apr 27 19:15:02 AfC	ijuma: I've got a lot of work to do as yet.
Apr 27 19:15:38 AfC	ijuma: any comments or conclusions? cagney, same question
Apr 27 19:16:14 *	AfC has changed the topic to: Java-GNOME Meeting: Conclusions?
Apr 27 19:17:20 cagney	no questions
Apr 27 19:17:22 ijuma	Well, I think that generating the bindings is the best way to keep up to date with changes in gtk+ and it would make sweeping changes a lot easier.
Apr 27 19:17:29 ijuma	that's about it really.
Apr 27 19:18:49 AfC	It would be really cool if we could share metadata with another bindings project.
Apr 27 19:18:56 ijuma	definitely
Apr 27 19:19:14 AfC	That would reduce the level of effort. We have to be smart about it though - the Java/JNI/C environment is non-trivial.
Apr 27 19:20:15 AfC	We didn't really get to this issue, but questions of API design also remain, for instance, how do we articulate a good event-signal design? No doubt our present API is clumsy, but this is somewhat orthogonal to whether or not the GTK C side of our bindings is generated.
Apr 27 19:21:24 ijuma	yeah
Apr 27 19:23:36 AfC	cagney: thanks for your time tonight.
Apr 27 19:23:42 AfC	ijuma: thanks for staying up so late
Apr 27 19:23:51 cagney	AfC, noworriesmate
Apr 27 19:23:53 AfC	And to everyone, thanks for contributing
Apr 27 19:24:04 ijuma	np
Apr 27 19:24:23 rcjsuen	np
Apr 27 19:25:10 AfC	I would like to see us embark on some of these projects. I realize that resources are limited, but on the other hand we've all invested a huge amount of time and energy getting to the point where we can consider and make decisions about these issues. If we can manage to execute on them then we'll really have accomplished something.
Apr 27 19:26:18 ijuma	AfC: If only time could be manufactured :)
Apr 27 19:26:50 cagney	AfC, google summer of code
Apr 27 19:27:08 seanc	cagney: good idea
Apr 27 19:30:36 rcjsuen	We seem to have a lot of gdk_thread function calls in org_gnu_glib_GObject.c.
Apr 27 19:31:37 seanc	Well, at meetings end - I'd like to quickly shout that my evolution data server libraries are ready for beta testing if anyone's interested - http://www.thecentric.com/resources/libeds-java-0.5.tar.gz
A

Re: [Java-gnome-developer] Re: architecture question

[Sandor Bodo-M. <sbo...@gm...>]

On 01 May 2006 09:27:39 -0600, Tom Tromey <tr...@re...> wrote:
>
> >>>>> "Andrew" =3D=3D Andrew Cowie <an...@op...> write=
s:
>
> Andrew> I'm not sure how well GTK and AWT will play together. There was a
> Andrew> conversation in #classpath on freenode the other day to the effec=
t
> that
> Andrew> because both would have to talk to the X server simultaneously th=
e
> Andrew> answer was "not very well".
>
> Yeah -- this is actually a problem unique to the free VMs because they
> use Gtk to implement AWT.  The use of Gtk in AWT and the use of Gtk
> in SWT clash, causing crashes :-(
>
> Tom
>
>
A while back i just wished that i could mix somehow the gnu classpath and
java-gnome in the sense that i can manipulate the same Gtk widget from two
different API - awt/swing from once and java-gtk from other.
If Gnu classpath is relying on Gtk - would it be sensible to export an
interface to the underlying Gtk widgets to make it more usable with swt and
java-gnome.
Of course this would mean that it has to extend the java specs ....

Just my 2 cent for this topic

Sanyi

PS - i managed to mix swing with java-gnome, but i needed to restore the X
IO error handlers of swing - otherwise hard crashes happened.

Re: [Java-gnome-developer] Re: architecture question

[Andrew O. <ove...@re...>]

* Tom Tromey <tr...@re...> [2006-05-01 11:42]:
> >>>>> "Andrew" == Andrew Cowie <an...@op...> writes:
> 
> Andrew> I'm not sure how well GTK and AWT will play together. There was a
> Andrew> conversation in #classpath on freenode the other day to the effect that
> Andrew> because both would have to talk to the X server simultaneously the
> Andrew> answer was "not very well".
> 
> Yeah -- this is actually a problem unique to the free VMs because they
> use Gtk to implement AWT.  The use of Gtk in AWT and the use of Gtk
> in SWT clash, causing crashes :-(

I heard that Sun's Gtk LAF has the same problem.

Andrew

[Java-gnome-developer] Re: architecture question

[Tom T. <tr...@re...>]

>>>>> "Andrew" == Andrew Cowie <an...@op...> writes:

Andrew> I'm not sure how well GTK and AWT will play together. There was a
Andrew> conversation in #classpath on freenode the other day to the effect that
Andrew> because both would have to talk to the X server simultaneously the
Andrew> answer was "not very well".

Yeah -- this is actually a problem unique to the free VMs because they
use Gtk to implement AWT.  The use of Gtk in AWT and the use of Gtk
in SWT clash, causing crashes :-(

Tom

Re: [Java-gnome-developer] architecture question

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

On Mon, 2006-05-01 at 03:06 +0300, Cam Bazz wrote:
> This sounds cool and nifty, but do we have to run with gcj, or can we 
> use sun's stock jvm???

It works in both. In fact, it's the other way around - it is
considerable effort to build the parallel shared libraries suitable for
use by GCJ in addition to building the Java classes and necessary JNI
libraries that go with a typical binding.


> I found libglade-java while searching for an gui builder for java. 

To be precise, libglade-java is a Java language binding around GNOME's
LibGlade library which allows you to instantiate Windows and Dialogs at
runtime based on UI descriptions created in the Glade interface
designer.

... but yes, using libglade-java and Glade does indeed give you a GUI
builder. Glade was originally a prototype builder which created stubs in
C which you could then implement, but LibGlade was developed to do it
dynamically at runtime, which is very cool - and widely used throughout
GNOME.

> There are some visualization libraries that I use that are dependent on 
> awt

I'm not sure how well GTK and AWT will play together. There was a
conversation in #classpath on freenode the other day to the effect that
because both would have to talk to the X server simultaneously the
answer was "not very well".

> so if it is possible to use libglade-java without 
> these, it would be great!

libglade-java is a tool to use when creating GTK applications, not
really anything to do with using libraries built with AWT. On the other
hand, porting those libraries to use GTK (via java-gnome's libgtk-java
and perhaps cairo-java underneath) shouldn't be too hard and would be a
terrific contribution to the community at large.

AfC
Sydney

-- 
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting Pty Ltd

http://www.operationaldynamics.com/
Management Consultants specializing in strategy,
organizational architecture, procedures to survive
change, and performance hardening for the people
and systems behind the mission critical enterprise.

Worldwide:

Sydney    +61 2 9977 6866
New York  +1 646 472 5054
Toronto   +1 416 848 6072
London    +44 207 1019201

Re: [Java-gnome-developer] architecture question

[Remy S. <rem...@gm...>]

I think I screwed something up, I hope I'm not sending this a second time t=
o
the list.

-------------------

What exactly went wrong when you tried with Sun's VM? What distro are you
on? What is the version number of the packages you are using?

Please provide more detailed information as applicable. Feel free to drop b=
y
our irc channel in #java-gnome on irc.gimp.net to ask for help directly.

Regards,
Rem

On 4/30/06, Cam Bazz <ca...@gm...> wrote:
>
> Hello;
>
> This sounds cool and nifty, but do we have to run with gcj, or can we
> use sun's stock jvm???
> I tried a basic example, and it did not go well, so I am asking.
>
> I found libglade-java while searching for an gui builder for java. all
> of them were buggy, slow,
> and I did not like them.
>
> There are some visualization libraries that I use that are dependent on
> awt, and these did not
> compile well with GCJ, so if it is possible to use libglade-java without
> these, it would be great!
>
> Thanks in advance for any recommendation/ideas/help.
>
> -C.B.
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>

Re: [Java-gnome-developer] Result of yesterdays IRC meeting

[Andrew C. <ca...@re...>]

These are my notes (so have my spin :-):

- topic 1: fix the glib vs gtk stuff - things need to be moved to glib 
so that it can beused independant of gtk
All agreed; "just do it".

- topic 2: simplify handle code
Agreement was to change native methods to:
-- native private static final native_method (long handle, ....)
so that the java side can pull the dummy values out
-- eliminate Handle{,32,64} putting the handle in the Struct
eliminates 2for1 memory allocation;
both of these make things a lot lighter

- topic 3: autogeneration
??? from pygtk invited; very helpful on what they do; My take is that 
everyone agreed it was a good idea and that pygtk (even though it was 
using !^*(@!)$^&* lisp) was going to be the best source for input files 
as it had the most complete coverage; recommendation is to use this for 
all new bindings and then work backwards

Many other topics weren't covered; should be added to next interaction.

Andrew


Andrew Cowie wrote:
> On Fri, 2006-04-28 at 12:28 +0200, Trond Andersen wrote:
>   
>> I didn't have the opportunity to participate at yesterday's IRC
>> meeting, but I'm curious about the result of the meeting.
>>     
>
> One of the participants said he would post an IRC log; I can probably
> manage that as well if it doesn't work out for him, but spread the love
> and all that.
>
> As for conclusions, I will probably email or blog about that next week.
>
> AfC
> Sydney
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>   

[Java-gnome-developer] architecture question

[Cam B. <ca...@gm...>]

Hello;

This sounds cool and nifty, but do we have to run with gcj, or can we 
use sun's stock jvm???
I tried a basic example, and it did not go well, so I am asking.

I found libglade-java while searching for an gui builder for java. all 
of them were buggy, slow,
and I did not like them.

There are some visualization libraries that I use that are dependent on 
awt, and these did not
compile well with GCJ, so if it is possible to use libglade-java without 
these, it would be great!

Thanks in advance for any recommendation/ideas/help.

-C.B.

Re: [Java-gnome-developer] Result of yesterdays IRC meeting

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

On Fri, 2006-04-28 at 12:28 +0200, Trond Andersen wrote:
> I didn't have the opportunity to participate at yesterday's IRC
> meeting, but I'm curious about the result of the meeting.

One of the participants said he would post an IRC log; I can probably
manage that as well if it doesn't work out for him, but spread the love
and all that.

As for conclusions, I will probably email or blog about that next week.

AfC
Sydney

Re: [Java-gnome-developer] auto-scroll in ScrolledWindow

[Remy S. <rem...@gm...>]

The method _is_ listed in the Gtk api (
http://developer.gnome.org/doc/API/2.0/gtk/GtkContainer.html), so this extr=
a
voodoo business won't be needed once we expose it with public methods.

Regards,
Rem

On 4/28/06, pancake <pa...@ph...> wrote:
>
> great! :)
>
> Type a tutorial or document't in the web page. I think is the better way
> to share knowledge.
>
> --pancake
>
> On Fri, 28 Apr 2006 16:54:23 +0200
> Manuel Clos <ll...@us...> wrote:
>
> > Hi all,
> >
> > Here is how I got auto-scroll working. By auto-scroll, I mean the
> > (vertical) scrollbar automatically move when a hidden widget gets focus=
,
> > so you can *automatically* view that widget instead of manually doing
> > the scroll.
> >
> > How it should work:
> >
> > vbox.setFocusVAdjustment(scrolledWindow.getVAdjustment());
> >
> > setFocusVAdjustment() is missing in java-gnome (Container class).
> >
> >
> > This is clumsy, but it works _now_:
> >
> > // since the method is protected, extend the class to reveal it
> > public class Container2 extends Container {
> >
> >     // constructor ignored
> >
> >     public static void gtk_container_set_focus_vadjustment2(Handle a,
> > Handle b) {
> >         gtk_container_set_focus_vadjustment(a, b);
> >     }
> > }
> >
> >
> > // code in the program
> > Container2.gtk_container_set_focus_vadjustment2(vbox1.getHandle(),
> > scrolledWindow.getVAdjustment().getHandle());
> >
> >
> > ... and it works! really ;)
> >
> > Hope it helps!
> >
> >
> >
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services,
> security?
> > Get stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>

Re: [Java-gnome-developer] auto-scroll in ScrolledWindow

[pancake <pa...@ph...>]

great! :)

Type a tutorial or document't in the web page. I think is the better way to share knowledge.

--pancake

On Fri, 28 Apr 2006 16:54:23 +0200
Manuel Clos <ll...@us...> wrote:

> Hi all,
> 
> Here is how I got auto-scroll working. By auto-scroll, I mean the
> (vertical) scrollbar automatically move when a hidden widget gets focus,
> so you can *automatically* view that widget instead of manually doing
> the scroll.
> 
> How it should work:
> 
> vbox.setFocusVAdjustment(scrolledWindow.getVAdjustment());
> 
> setFocusVAdjustment() is missing in java-gnome (Container class).
> 
> 
> This is clumsy, but it works _now_:
> 
> // since the method is protected, extend the class to reveal it
> public class Container2 extends Container {
> 
>     // constructor ignored
> 
>     public static void gtk_container_set_focus_vadjustment2(Handle a,
> Handle b) {
>         gtk_container_set_focus_vadjustment(a, b);
>     }
> }
> 
> 
> // code in the program
> Container2.gtk_container_set_focus_vadjustment2(vbox1.getHandle(),
> scrolledWindow.getVAdjustment().getHandle());
> 
> 
> ... and it works! really ;)
> 
> Hope it helps!
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] auto-scroll in ScrolledWindow

[Manuel C. <ll...@us...>]

Hi all,

Here is how I got auto-scroll working. By auto-scroll, I mean the
(vertical) scrollbar automatically move when a hidden widget gets focus,
so you can *automatically* view that widget instead of manually doing
the scroll.

How it should work:

vbox.setFocusVAdjustment(scrolledWindow.getVAdjustment());

setFocusVAdjustment() is missing in java-gnome (Container class).


This is clumsy, but it works _now_:

// since the method is protected, extend the class to reveal it
public class Container2 extends Container {

    // constructor ignored

    public static void gtk_container_set_focus_vadjustment2(Handle a,
Handle b) {
        gtk_container_set_focus_vadjustment(a, b);
    }
}


// code in the program
Container2.gtk_container_set_focus_vadjustment2(vbox1.getHandle(),
scrolledWindow.getVAdjustment().getHandle());


... and it works! really ;)

Hope it helps!

[Java-gnome-developer] Result of yesterdays IRC meeting

[Trond A. <tro...@gm...>]

I didn't have the opportunity to participate at yesterday's IRC
meeting, but I'm curious about the result of the meeting.

Would anyone give a short summary?



------- Trond

[Java-gnome-developer] Result from IRC meetup

[Trond A. <tro...@gm...>]

I didn't have the opptunity to participate in yesterdays meeting, but
I'm a bit curious about the result of the meetup. Anyone interested in
sharing?


-------- Trond

[Java-gnome-developer] encoding problems

[pancake <pa...@ph...>]

I've some encoding problems with gdvb.

So, i must read some MessageBundled files, Properties files and some other "plain" files created by other external programs (scan (from linuxtv-dvb)), but looks that non-ascii chars are not pretty-printed in the GTK frontend.

How can I autodetect the encoding of a file? Do I've to convert every string into the correct encoding before writting them into the GUI?

If someone has solved this problem would be good to have a tutorial about how to fix this kind of problems.

--pancake