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

[java-gnome-hackers] Motion event and eventmask

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

Hi,

I send you the patch implementing the ideas I told you last week, regarding how to expose EventMask.
Instead of requiring developers to retrieve the GdkWindow, and set the event mask there, I have implemented enable/disable events as methods of Widget. Such methods take care of realizing the Widget if needed.

There is, however, a problem with this idea, that was also present previously, in the way VisibilityNotify was handled. 
The problem is that a widget cannot be realized until it is added to its parent. As we automatically realize a widget when needed, if the user connects,  for example,  to VisibilityNotify signal before adding the widget to a parent container, we will get an ugly Gtk-Critical.

So we have 3 alternatives:

a) Document that problem in the methods that can suffer it (enable/disableEvents and connect(VisibilityNotify) afaik), and prevent the Gtk-Critical by checking correctness in advance and throw IllegalStateException or such when needed.

b) Forget about automatically realize Widgets, and expose gdk_window_set_events (maybe as a pair enable/disable methods) in gdk.Window, requiring the user to use the same technique as in pure Gtk. Signals that need it (VisibilityNotify, MotionNotify...) should document how to address this.

c) Another alternative, much more complex, is to internally connect (in Widget) to a signal such as realize-event (is this correct?), and set the event mask there. In this case, events-related functions check if there is a GdkWindow: if not, the changes are stored internally until the realize signal is received.

I am not really conviced of what is the best solution... ideas?

Cheers
Vreixo



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [java-gnome-hackers] Res: MouseButton improvements

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

On Mon, 2009-05-18 at 09:23 +0000, Vreixo Formoso Lopes wrote:
> > Do these
> > ButtonPressEvents not get generated anymore?
> 
> No

> In fact, looking at gdk sources I found this...

Great job doing the research on this.

So definitely go ahead with deprecating them and moving the emphasis to
ScrollEvent.

Cheers!

AfC
Sydney

[java-gnome-hackers] sourceview development branch

[Stefan S. <ste...@gm...>]

Hi,

the sourceview development branch is now available on launchpad. In case
you are interested, you can get it with:

bzr branch lp:~stefan-schweizer/+junk/sourceview

Or have a look at it here:
https://code.launchpad.net/~stefan-schweizer/+junk/sourceview

I hope to get it ready to be merged soon. Comments and patches are of
course welcome!

	Stefan

[java-gnome-hackers] Res: MouseButton improvements

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

Hi!



> 3. I'm not sure that these should to be deprecated. Do these
> ButtonPressEvents not get generated anymore? They still get emitted, *as
> well as* ScrolledEvent, right?

No, afaik. I cannot get a button-press-event for those buttons, for example... 


> 4. What happens if you scroll the mouse wheel in a window without a
> Viewport & Scrollbar? Do you still get ScrollEvent?

Yes, it seems those buttons are always mapped to an scroll-event. In fact, from devhelp documentation:

"The ::scroll-event signal is emitted when a button in the 4 to 7
range is pressed. Wheel mice are usually configured to generate 
button press events for buttons 4 and 5 when the wheel is turned.
"

The second sentence is not clear, as I never receive the button press events. I guess it refers to "mouse wheel is usually configured in X to generate button press events, that we map (in GDK)  to scroll events".

In fact, looking at gdk sources I found this piece of code, that belongs to function "gdk_event_translate" (that I guess it translates X events to GDK events):


  switch (xevent->type)
[....]

    case ButtonPress:
[......]
      
      /* If we get a ButtonPress event where the button is 4 or 5,
     it's a Scroll event */
      switch (xevent->xbutton.button)
        {
        case 4: /* up */
        case 5: /* down */
        case 6: /* left */
        case 7: /* right */
      event->scroll.type = GDK_SCROLL;
       [.............]

        default:
      event->button.type = GDK_BUTTON_PRESS;

[....]
(piece of code from gtk+-2.16.1/gdk/x11/gdkevents-x11.c)
        
So it seems that those buttons always generate scroll events, and only scroll events.
I don't know, however, whether some special configuration can change this behavior, although I don't think so.

Cheers
Vreixo


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [java-gnome-hackers] MouseButton improvements

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

On Sun, 2009-05-17 at 17:56 +0200, Vreixo Formoso wrote:
> I have added constants for mouse buttons 8 (BACK) and 9 (FORWARD), as
> many new mice have such buttons, and not including them causes an
> exception to be thrown. I have not named it EIGHT or NINE

Sure. If you've got a reasonable name for them, that's excellent.

>     /**
> -     * Mouse button <code>4</code>.
> +     * Mouse button <code>4</code>. Do not use this, connect to
> +     * {@link ScrollEvent} instead.
>       */
> +    @Deprecated
>      public static final MouseButton FOURTH = new MouseButton(4,
> "FOURTH");

So,

1. If you're going to mark something deprecated, use the JavaDoc
@deprecated tag please. That way you'll be consistent with everywhere
else in the library.

and,

2. Good of you to say "what to use instead". We don't generate javadoc
for deprecated methods, but it'll be good if someone is hovering over a
deprecated constant.

but,

3. I'm not sure that these should to be deprecated. Do these
ButtonPressEvents not get generated anymore? They still get emitted, *as
well as* ScrolledEvent, right?

Certainly the text about "what you really want is..." and a @link is
excellent.

4. What happens if you scroll the mouse wheel in a window without a
Viewport & Scrollbar? Do you still get ScrollEvent?

Otherwise, yes, this is great.

AfC
Sydney

[java-gnome-hackers] MouseButton improvements

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

Dear all,

I send you this tiny patch that changes MouseButton constant, according
to:

1- I have deprecated constants for mouse buttons 4 and 5 (wheel), as
they, together with buttons 6 and 7, are not mapped to mouse-clicks
events, but to scroll-event, so it makes no sense to treat that as mouse
buttons. Or do you know any case where these constants make sense?

2- I have added constants for mouse buttons 8 (BACK) and 9 (FORWARD), as
many new mice have such buttons, and not including them causes an
exception to be thrown. I have not named it EIGHT or NINE because I
really think that using the name the user expects (in the same way we
have done with LEFT click, MIDDLE, etc) is a better option.

What to you think about these changes? Do you agree? Does any of you
have a mouse with more than 9 buttons? If so, can you provide meaningful
names for those?

Andrew, I'd like to propose this patch for mainline, btw

Cheers
Vreixo
 

Re: [java-gnome-hackers] Little java-gnome contribution

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

Vreixo,

On Fri, 2009-05-15 at 09:24 +0000, Vreixo Formoso Lopes wrote:
> ... Attached bundle is a
> little contribution with several changes ... 
> They correspond to an old branch dedicated to add coverage I needed for
> my chart plot application.

Merged to 'mainline'.

> Anyway, it is nice to contribute again to the project.

It's great to hear from you!

++

Everyone,

Branches of code that don't need architectural discussion or design
review are best submitted by direct email [as this was] or by informing
the maintainer of a branch URL to pull. Unless the code needs discussion
it doesn't seem necessary to clutter the list with bundles. They are,
after all, mostly just a transport.[*]

But once in a while I like to take a moment to publicly acknowledge
people's work, especially when we haven't heard from someone in a while.
So that's all this email was.

There's nothing requiring this, however, and I'm aware that some people
seem to think that code only gets merged if they see an email here.

This is not the case. Often I just merge contributions and call it a
day. If I happen to see the contributor on IRC at the time, then I
usually take the trouble to let them know. But in the end, that's
unnecessary and secondary because the Bazaar history shows it.

So please don't feel bad if the maintainer doesn't write here saying he
merged your branch :)

AfC
Sydney


[*]: if code does need discussion or review, then a diff of the part you
want to talk about + a bundle (or URL) makes a great way to start the
conversation. That way someone else can hack on it if they want to, but
the email focuses on the part that needs input.

-- 
Andrew Frederick Cowie

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

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] How to deal with MotionNotifyEvent?

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

Hi everybody,

I need to expose motion-notify-event Widget signal to use it in an app. 
This event, however, is only received after "activating" it, i.e.,
passing the GDK_POINTER_MOTION_MASK to the gdk_window_set_events, that
of course requires a GdkWindow to be available.

I've seen that for VisibilityNotifyEvent, that also requires similar
procedure, you take care of that internally, hidden for the user. That
is great!

However, for motion notify I don't know if that is a good idea. It
generates a lot of events, while usually you only take care about them
sometimes. For example, in my application I use this event to move a
chart on a cairo drawing area when the user keeps the left button
pressed. However, if the user release the button I do not care about
this event at all. If I enable it when connecting to the signal, I will
receive a lot of events in my app. In my opinion, it is better to allow
users to enable/disable such kind of events when needed.

However, the enable/disable procedure is rather complex, and ugly, as it
requires knowledge about the underlying GdkWindow details. If event
signals are part of Widget, I think enable/disable should be there. My
proposal would be to add a pair of methods to Widget:

enableEvent()
disableEvent()

that take a EventMask as parameter. Such methods would get the
GdkWindow, realizing the widget if needed (as you do in
GtkWidgetOverride for visibility event), and enable/disable the given
events, left the other events untouched. Then, events such as motion
notify should document the procedure. This way, underlying details are
hidden for the user.

In my opinion, that would be much easy to understand for users. However,
it has a problem, too, as if two widget share the same GdkWindow, the
behavior of enable/disable methods could be confusing. Anyway, I think
that good documentation can explain this.

What do you think? Do you like the idea? 

Cheers
Vreixo



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [java-gnome-hackers] added getInverted and setInverted to Range

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

On Sat, 2009-05-09 at 17:29 +0200, Peter Mosseveld wrote:
> I have now reworked my patch to incorporate your comments. I have 
> attached the bundle to my mail.

Merged to 'mainline'

AfC
Sydney

Re: [java-gnome-hackers] added getInverted and setInverted to Range

[Peter M. <Pet...@gm...>]

Hi Andrew,
Thanks for your comments.

I have now reworked my patch to incorporate your comments. I have 
attached the bundle to my mail.

I hope it is now ready to be merged.
Regards Peter

Andrew Cowie wrote:
> On Sat, 2009-05-09 at 12:00 +0200, Peter Mosseveld wrote:
>> I have attached a bundle containing these methods.
> 
> Hey, lovely.
> 
>>  This is my first 
>> patch. So I hope I have done everything right.
> 
> Just some minor details that come under "style" and "consistency"
> 
>> -     * Retreive the value currently indicated by this Range instance.
>> +     * Retrieve the value currently indicated by this Range instance.
> 
> Thanks for fixing the spelling :)
> 
>> +     * Retrieve the current value set by setInverted
> 
> When you need to refer to another method, use a @link tag. In this case,
> 
>         ... yada blah yada {@link #setInverted(boolean) setInverted()}
>         yada yada blah blah...
> 
> 
> As a very high level thing, rather than saying "Get the value" try
> something more specific, perhaps "Get whether or not the rate scale of
> this Range is inverted; see {@link ...}."
> 
> [I have often skipped bothering to write a getter simply because, well,
> you wrote the code, and you know full well whether you changed it from
> the default or not. But that's just me; nothing wrong with exposing a
> getter if you need it and/or are willing to put the work in to offer it]
> 
>> +    /**
>> +     * Inverts the way the value changes when moving the slider
>> +     *
>> +     * Ranges normally move from...
> 
> You need a <p> tag in there if you are trying to start a new paragraph.
> Otherwise the whitespace is swallowed (as you'd expect with HTML as the
> end result).
> 
>> +     * ...higher values at the top or on the right rather than on the
>> +     * bottom or left.
>> +     */
> 
> Please add a @since tag. Assume your patch will be accepted and in the
> next release :) For example, the latest release was 4.0.11; 'mainline'
> says it is 4.0.12-dev right now; assume you'll be in 4.0.12 and put
> 
>         * @since 4.0.12
> 
> This has the wonderful effect of saving the maintainer the trouble of
> adding it for you, and anything that saves the maintainer trouble is
> well regarded :).
> 
> So maybe just touch up those things and then we can merge it!
> 
> AfC
> Sydney
> 
> P.S. I find it a bit easier if you include a bundle as an attachment
> rather than inline, but that's just me.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Re: [java-gnome-hackers] added getInverted and setInverted to Range

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

On Sat, 2009-05-09 at 12:00 +0200, Peter Mosseveld wrote:
> I have attached a bundle containing these methods.

Hey, lovely.

>  This is my first 
> patch. So I hope I have done everything right.

Just some minor details that come under "style" and "consistency"

> -     * Retreive the value currently indicated by this Range instance.
> +     * Retrieve the value currently indicated by this Range instance.

Thanks for fixing the spelling :)

> +     * Retrieve the current value set by setInverted

When you need to refer to another method, use a @link tag. In this case,

        ... yada blah yada {@link #setInverted(boolean) setInverted()}
        yada yada blah blah...


As a very high level thing, rather than saying "Get the value" try
something more specific, perhaps "Get whether or not the rate scale of
this Range is inverted; see {@link ...}."

[I have often skipped bothering to write a getter simply because, well,
you wrote the code, and you know full well whether you changed it from
the default or not. But that's just me; nothing wrong with exposing a
getter if you need it and/or are willing to put the work in to offer it]

> +    /**
> +     * Inverts the way the value changes when moving the slider
> +     *
> +     * Ranges normally move from...

You need a <p> tag in there if you are trying to start a new paragraph.
Otherwise the whitespace is swallowed (as you'd expect with HTML as the
end result).

> +     * ...higher values at the top or on the right rather than on the
> +     * bottom or left.
> +     */

Please add a @since tag. Assume your patch will be accepted and in the
next release :) For example, the latest release was 4.0.11; 'mainline'
says it is 4.0.12-dev right now; assume you'll be in 4.0.12 and put

        * @since 4.0.12

This has the wonderful effect of saving the maintainer the trouble of
adding it for you, and anything that saves the maintainer trouble is
well regarded :).

So maybe just touch up those things and then we can merge it!

AfC
Sydney

P.S. I find it a bit easier if you include a bundle as an attachment
rather than inline, but that's just me.

[java-gnome-hackers] added getInverted and setInverted to Range

[Peter M. <Pet...@gm...>]

Hi,
I was working on my application and noticed that the getInverted and 
setInverted methods of the Range object were not yet implemented.

I have attached a bundle containing these methods. This is my first 
patch. So I hope I have done everything right.

==>
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: pm...@xs...-20090509093901-cyme2g226ryy9kpw
# target_branch: ../mainline
# testament_sha1: e8bb6ba9b6eb85f1c8bf7878dce0e0ab552bfdf5
# timestamp: 2009-05-09 11:39:43 +0200
# source_branch: /tmp/additional_methods_range.patch
# base_revision_id: an...@op...-20090504013017-\
#   os042rakj9crt9si
#
# Begin patch
=== modified file 'src/bindings/org/gnome/gtk/Range.java'
--- src/bindings/org/gnome/gtk/Range.java	2008-09-05 14:25:07 +0000
+++ src/bindings/org/gnome/gtk/Range.java	2009-05-09 09:39:01 +0000
@@ -33,7 +33,26 @@
      }

      /**
-     * Retreive the value currently indicated by this Range instance.
+     * Retrieve the current value set by setInverted
+     */
+    public boolean getInverted() {
+        return GtkRange.getInverted(this);
+    }
+
+    /**
+     * Inverts the way the value changes when moving the slider
+     *
+     * Ranges normally move from lower to higher values as the slider
+     * moves from top to bottom or left to right. Inverted ranges have
+     * higher values at the top or on the right rather than on the
+     * bottom or left.
+     */
+    public void setInverted(boolean setting){
+        GtkRange.setInverted(this,setting);
+    }
+
+    /**
+     * Retrieve the value currently indicated by this Range instance.
       *
       * @since 4.0.6
       */

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWRrMLgIAA0RfgGQQUXf//3Ki
UgC//9/6YAZ/HPYAAAAAAAOYBNMAmQwABMEwAAA5gE0wCZDAAEwTAAABqp5pPKYk0AAAAAAA0ABp
Uf6kg00ZNDQ0eo0DQMQADQZDmATTAJkMAATBMAAACqJNCaaNAmTRoJiYjICEyManpP1SqD2b+O3b
1tuuj+P+5pnganB1v5rh1zrj66fZ97NSNhKNKVM89fKq2IjdWVHbfNlW3Sgxa6EGZBoaOk+7OlMz
Mfz+5+KrlihqyqsWMvCjNzb9bp/EDJSxGwo5tAIFASTx9BOxGtzmokIiHkmG0wQaCRB6WYbLWJAo
B8Snm97AYDSgYpfc3QmS4QEe1EiUKJDhqruYX3oAQoeREFqcoU86/RJG9AhJCwpEA+DwYJl5fTd1
Pl3JiPilfbi3HUaAqbUOZ5D8KHqdXat335i2IwQS1vm3n6Hj43UpSw6eVGjRYnMR1a62q6rEpQjv
dtyL/SPdF8RaZ43RgYrcCHFdwLWtZSFpExB22BYjkZMjPK9c7+h7V3FqYURtX/vk9GpzK3avli9E
7LbdGLmUjBYsLS+UKrYplnyfHTcpgWL35N7Wz6M7nLYWOHO/ZCLip5o4M6GtkwL7GKOZrYl8XxGZ
auaY3rW9GMZtrRqXRmcLKmdCx/q5nbrU0c6xgiXNc0tiG1tZK5RcWsMGhWFsXrOSHhG9gwZ0MsDo
3NhnQVvT1cF3CvA2IXysjHbQN61Y4V3DBtXt+hY2xel7JUxXXX2NFqLbmDfGN3YzrkMzs6YcGhsR
0vNzRmhvcr0q450cm5uQtYRqShYtV2Tk0c+ZnW53Oz6Ww4aoYI1EKpDchYojPk1q71hVr18WYvS6
42uZk3O9GqL9Expi1uhtRui3AuiLvmwPuj3JI/RJ9nFlcUUeCim2iY85TJxfM5nvWLlC5Kix8D7o
Mq5RMzCX/J7P31qSiYwS8KKUmM2i1MMIJaPplamXsjix77h0PetS83Y0ux3Pl4vJ23RRY2nahzHr
4IPt2OELRzsd80wcOeX5hYSmbtWsjlpnXQ4d+EPgjDv9NfS61OJ0pUfFsVS9F7qPZu/aXFLyHazu
5ksxQ3uvHZRbn1UcyH2KxojoLToQq+iOD6pi2Y8JhK5upubWqFUS52ZDsyf3vq3eLNeSeLWfTh5d
FE1WVqrKxJurBayecael0IlvWcLXJ2vo3Pc3MTIx5S+CdasRrbclWppZo2y4yjV4r29nsKI1UQvX
rffKzbV0HlhBQmToU2xxNCLpQlYmZf4s+CxlcooQzotc7g+7vdTtWNrsWOSXUZH6vB4vQ7qQ7Za3
qrGKJhGMQmLXwxNj+3oxjiOembmQsiGnup1LVI5ybG5GFnby73TTc6jz9kLmDAvZj3qOtFTV9oic
vCqqvz9y5YxC4zxmDUq00M8dSNhxjBuS2xGx1x5eCMyDQg0o7lx7kcW50rlsQeSay9zBSG7XZgNS
Os+qLzh+rk1udDKi4udZjHFB9V8XO49TDVmi3nlQheaiyLhJVRFERg6zrQX25kJmISj/EO01cDYQ
syz6VLU7YjHOlKDsdS25+SguiyI4uzKHPVG6P/MsWyOVijGOTk5I9rS4jT5P+sz4k5olSJ199GJL
+nejsNEe6gpEfKNy9i2rjzdOCZQ/3pfFewSix6mGHJayGyzgt3CrujMiL5JR+yO+yGGOullV4viq
H9ILVCU+p39Ot8JmfzNqpsPnGkKMEXM5oS8cw1WfGm+2bPerahyjvVVKi9uNcSvWzMotaWkzJItn
6LcrypeuMXs0WlqWiIsRglm4IUKSjaqxTU6XHVDaz6MWpGmE44mkKKBQriiwpWfE/po/h6oL0a1W
l79M1fVFVGpG0oj5Xyc0aMX41+j/4u5IpwoSA1mFwEA=

<==

If you have comments please let me know.
Peter

[java-gnome-hackers] TableAttachOptions to Flags (was Re: ...)

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

On Fri, 2009-05-01 at 08:45 -0400, Jacek Furmankiewicz wrote:
> I'd like to know if the issue with Table AttachOptions that I reported
> a few weeks ago managed to make it in, since I recall you had fixed it
> in a local dev branch.

Hm?

Ah.

That thread, dated 20 March, ended with me asking you to run the code
and write a unit test, since you're the one trying to use it and could
test it actually does what we hope it does.

Stefan and I didn't see anything back from you, so I'm afraid it fell
off the radar. Sorry. Been busy merging code from other people.

Perhaps you'll be able run the code and write a unit test some time
during the 4.0.12 development cycle? That'd be great.

The branch is still 'hackers/andrew/bug-attach-is-flag'. I merged a
current 'mainline' into it to save you the trouble. The relevant work
was committed at revno 626 on that branch.

AfC
Sydney

Re: [java-gnome-hackers] UTF-8 (was Re: ...)

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

On Fri, 2009-05-01 at 16:12 +0300, Serkan Kaba wrote:
> It's just a warning but I made both javac and javadoc forcing UTF-8
> for forces and created a bundle.

(we talked about this on IRC)

Merged.

Obviously your Gentoo package will get more testing than 'mainline' in
the near future; if you hear of a problem with this, feel free to
"reopen" (heh).

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] Libnotify branch

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

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

Andrew Cowie yazmış:
> You've added libnotify to the build script; you'll need to add probes
> for it to the top level configure file.
Added
- --
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknuKHIACgkQRh6X64ivZaLi1ACfWu2FB2TFlX/DVQhmNLKIZCGr
TRIAniiKH7F1I8Ov2fZD1sZfz5zxZhIV
=iGQL
-----END PGP SIGNATURE-----

[java-gnome-hackers] String reuse

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

When you have a TextBuffer, and do something like:

        buffer.insert(iter, "Hello World");

this causes TextBuffer.InsertText to be emitted (as this is where GTK
actually carries out the textual insertion, as it happens).

if you've meanwhile connected to that signal, ie

        buffer.connect(new TextBuffer.InsertText() {
            public void onInsertText(TextBuffer source, TreeIter where, String text) {
                // ...
            }
        });

the text String you get will, of course, have the same "Hello World"
content, but it will be a different String object [since it is created
with NewStringUTF() in bindings_java_signal.c as the signal emission is
marshalled and and the GClosure invoked]. This is fine.

Except that it's a bit wasteful to have our JNI layer to have to create
a new String when we know full well that a String with equivalent data
already exists. And worse, that we *just* passed such a String across to
the JNI layer where the char[] was converted (copied) into a UTF-8
gchar*.

So while everyone knows that two Strings have to be checked by equals()
rather than by reference ==, the whole point of Strings is that they are
immutable and reusable.

The number of arraycopy() that happens on char[] in the Sun Java library
to preserve the immutable String character is already staggering and a
common hot spot in profiling.

So I'm wondering if we couldn't connive to at least not make it worse.
If we convey the same String to a signal handler as was passed in by the
initiating method, we could save a lot of copying.

The thought I had was to keep a tiny (last 8 or so, though even last 1
would do) cache of gchar* to jstring mappings when we pass Strings
across to JNI. Then during signal emission we could check the last 1 (or
8 or whatever) mappings to see if we've already got a String for that
gchar* there, and if so just return it rather than creating a new one.
Weak references, of course.

It might seem minor, but right now I'm doing a lot of "insert huge block
of text into a TextView, then ignore the InsertText signal because I
know I just inserted it programmatically" .... but I have to ignore the
signal _in_ the handler, and that's after the String copy has been
created for the parameter. So I'm creating lots of Strings that are
being ignored and rapidly thrown away.

And while this falls squarely into the "premature optimization" category
(the app is responsive), it's the sort of thing you like not to do if
you can help it.

Anyway, String reuse in general is an issue I'm thinking about. A
variation on the theme is the possibility of using Direct ByteBuffers
created JNI side and a view to a wrap piece of a native gchar*, rather
than copying the thing into a String all the time with JNI
NewStringUTF(). That would be wizard, except that we can't subclass or
replace java.lang.String. So I'm not sure what good it would actually do
given all our API is String, naturally.

Discussion welcome.


AfC
Sydney


-- 
Andrew Frederick Cowie

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

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] better slackware detection and support on configure script

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

On Tue, 2009-04-14 at 21:39 -0300, Leonardo wrote:
> bundle done :)

Merged to 'mainline'.

Thanks for your contribution!

AfC
Sydney

Re: [java-gnome-hackers] better slackware detection and support on configure script

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

On Tue, 2009-04-14 at 18:55 -0300, Leonardo wrote:
> tested against slackware-current and 12.2+Gnome Slacky.

You diff looks fine. Please go ahead and [commit if you haven't already,
then] send the bundle. We'll include it in 4.0.11 which is imminent.

AfC
Sydney

[java-gnome-hackers] better slackware detection and support on configure script

[Leonardo <som...@gm...>]

=== modified file 'configure'
--- configure	2009-03-05 11:29:51 +0000
+++ configure	2009-04-14 21:38:08 +0000
@@ -143,7 +143,7 @@
 		} elsif ($os eq "solaris") {
 			$str .= "pkgadd";
 		} elsif ($os eq "slackware") {
-			$str .= "installpkg";
+			$str .= "slackpkg install";
 		} else {
 			$str .= "[FIXME fetch and install command for this OS]"; 
 		}
@@ -201,7 +201,7 @@
 		} elsif ($os eq "solaris") {
 			$str .= "pkgadd";
 		} elsif ($os eq "slackware") {
-			$str .= "installpkg";
+			$str .= "slackpkg install";
 		} else {
 			$str .= "[FIXME fetch and install command for this OS]"; 
 		}
@@ -749,6 +749,29 @@
 			"GNOME",
 			"gnome");
 
+} elsif ($os eq "slackware") {
+	# on slackware gdk-2.0 and gtk+-unix-print-2.0 are part of gtk+-2.0
+	# use http://packages.slackware.it/ for more details. 
+	check_system_library(@gnomedev_libs,
+			"gtk+-2.0 >= 2.14",
+			"GTK+",
+			"gtk+2");
+
+	check_system_library(@gnomedev_libs,
+			"pango >= 1.22",
+			"Pango",
+			"pango");
+
+	check_system_library(@gnomedev_libs,
+			"atk",
+			"ATK",
+			"atk");
+
+	check_system_library(@gnomedev_libs,
+			"libglade-2.0",
+			"LibGlade",
+			"libglade");
+
 } elsif ($os eq "debian") {
 	check_system_library(@gnomedev_libs,
 			"gtk+-2.0 >= 2.14",

Re: [java-gnome-hackers] Libnotify branch

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

2009/4/6 Andrew Cowie <an...@op...>:

> An Example demonstrating [how to use] this functionality would not go
> amiss...
Added and pushed.
> Files newly created and not obviously copying from something existing
> can simply be (c) 2009.
Fixed.

Thank you for your suggestions. I'll try to fix the remaining points
and make it ready for 4.0.11 (hopefully). Of course, further covarage
will follow.

Sincerely,
Serkan KABA

[java-gnome-hackers] java-gnome 4.0.11 imminent

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

We found a few critical bugs (ie, VM crashes) in the Pango Attribute
coverage. They're fixed, but along the way we made a few minor API
changes, so I think rather than a micro release of 4.0.10 we'll quickly
gear up and do a proper 4.0.11 release.

It'll be this week, based of course on what's in 'mainline' at present.

There aren't any build system changes so your 4.0.10 packages should be
easily bumped when the time comes.

If you've got something you want in, asap would be good [Martin, this
means you :)].

AfC
Sydney

Re: [java-gnome-hackers] Libnotify branch

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

2009/4/6 Andrew Cowie <an...@op...>:
I just forgot to mention that I withdrew my idea on overloading icons
with Stock since non-stock items are valid as well (tested with
messagebox_warning)

Sincerely,
Serkan KABA

Re: [java-gnome-hackers] Libnotify branch

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

On Sun, 2009-04-05 at 19:19 +0300, Serkan Kaba wrote:
> I started working on covering libnotify


Outstanding.

> finally the coverage is just enough to be
> usable (can create and display) notifications.

This branch is already acceptable for merging style-wise, which is
excellent. A few minor notes:

An Example demonstrating [how to use] this functionality would not go
amiss...

You've added libnotify to the build script; you'll need to add probes
for it to the top level configure file.

Files newly created and not obviously copying from something existing
can simply be (c) 2009.

When writing documentation, _what_ something does is nice, but _when_
and _why_ you would [or would not] use something is really what needs to
be explained... if you know, of course (and since we really shouldn't be
exposing something if we don't know, most of the time we can do this).

> ideas, especially on org.gnome.notify.Notify and its inheritance.

I'll check that part closely tomorrow, but my first impression reviewing
the diff was that everything is on the right track.

AfC
Sydney

-- 
Andrew Frederick Cowie

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

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Libnotify branch

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

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

Hail to all Java-GNOME Hackers,

I started working on covering libnotify 3 weeks ago to be used in my own
application, JKota[1], and finally the coverage is just enough to be
usable (can create and display) notifications) but the detailed coverage
is missing. Before proceeding with further development; I want to hear
your ideas, especially on org.gnome.notify.Notify and its inheritance.

I pushed the branch[2] to my hacker space and committed JKota
revision[3] using it to its GTK branch.

Thanks in advance.

1: http://jkota.googlecode.com
2:
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/libnotify/
3: http://code.google.com/p/jkota/source/detail?r=143

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

iEYEARECAAYFAknY2g4ACgkQRh6X64ivZaI18wCcDoT9kiwF40EUt0qrz/B2UTZ0
6dwAnR2bD/S6Tm97cAvxq1/KWun39nMs
=yNeW
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] About i18 tests

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

Merged to 'mainline'

AfC
Sydney