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

Re: [java-gnome-hackers] An idiom for deprecating things

[Mario T. <ne...@li...>]

Il giorno mar, 29/07/2008 alle 12.15 +1000, Andrew Cowie ha scritto:
> Hello,
> 
> A couple methods needed a signature changes yesterday (renames, as it
> happened). I implemented the correct signature, and then pondered what
> to do with the old one.
> 
> People in the Java land are a lot more clued in about [not using]
> deprecated things that it seems most developers using GTK in C are.
> Tough for them. But part of the problem there is that they weren't
> strongly incented to get on with fixing their code.
> 
> I came up with an idiom that I'm actually really happy with:
> 
>         /**
>          * Original JavaDoc here.
>          *
>          * @since 4.0.8
>          */
>         public void betterMethodName() {
>             GtkHotness.methodName();
>         }
>         
>         @Deprecated
>         public void oldMethodName() {
>             assert false : "Deprecated. Use betterMethodName()";
>             GtkHotness.methodName();
>         }

Hi Andrew.

What we usually do in both the JDK and Classpath (and Escher now) is
something like:


        /**
         * Original JavaDoc here.
         *
         * @since 4.0.8
         */
        public void betterMethodName() {
            oldMethodName();
        }
        
        @Deprecated
        public void oldMethodName() {
            GtkHotness.methodName();
        }
        
This does not break code that override oldMethodName.

Just my 2 cents.
Mario

[java-gnome-hackers] Major API change in signal interface naming

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

Right now, when you connect a signal handler in java-gnome, you do the
following:

        b.connect(new Button.CLICKED() {
            public void onClicked(Button source) {
                // do stuff
            }
        });

        v.connect(new TreeView.ROW_ACTIVATED() {
            public void onRowActivated(TreeView source, TreePath path, TreeViewColumn vertical) {
                // do stuff
            }
        });

given Button b and TreeView v.

This has for some time been the subject of a wee bit of irritation.
Quite evidently, the interfaces which contain our signal handler
callback prototypes are named a bit peculiarly.

The reason it ended up this way is historical; partly the actual signal
names were all caps in java-gnome 2.x (though buried in three layers of
the usual observer pattern Listener/Event verbosity), and partly because
of collisions that occurred when trying to sort out visibility and
naming patterns during the initial java-gnome 4.0 prototype 26 months
ago.

So, for a while now when queried about this my answer was (gee, I'm
happy with the way it is) crossed with "its a bit late to change it now"
seeing as how it was the pattern we inherited from 2.x and have released
in 4.0.

Of course this isn't true; we can change anything we like.

One of the collisions that I had to deal with back when doing the
re-engineering was the problem that there are often methods named the
same as the signal and which cause it to be emitted. An example would be
gtk_button_clicked() which emits the 'clicked' signal, which was
Button's clicked() in our library. So Button.clicked was out as a name
for the signal interface. And it looked ugly too. And since people who
had worked in 2.x were used to 'clicked' being mapped as:

        button.addListener(new ButtonListener() {
            public void buttonEvent(ButtonEvent event) {
                if (event.getType() == Button.Type.CLICKED) {
                     // at last, do something
                }
            }
        });

and for GtkEditable's 'changed' signal:

        entry.addListener(new EntryListener() {
            public void entryEvent(EntryEvent event) {
                if (event.getType() == EntryEvent.Type.CHANGED) {
                    // at last, do something
                }
            }
        });

etc, you can see where the signal name 'clicked' being mapped to a Java
inner type CLICKED came from.

[Those of you new around here be thankful you didn't have to deal with
that mess. Yes it worked, but so painful to write. Completions didn't
work for shit. And trying to navigate the JavaDoc to figure out what
signals were actually available? What a nightmare]

But while Button.CLICKED was something we didn't really trip over, and
indeed provided a nice contrast to the onClicked() method to be
implemented, TreeView.ROW_ACTIVATED just doesn't look right as a Java
type name.

All caps with underscores are _constants_, not types (inner or
otherwise).

++

So you can probably guess where this is going.

With the practise we adopted last year of naming methods that cause a
signal to be emitted with an "emit" prefix, we now have methods like

        b.emitClicked();
        a.emitValueChanged();

for GtkButton's 'clicked' and  GtkAdjustment's 'value-changed'
respectively.

And which really makes it obvious what the java-gnome mapping of the
signal name should have been all along.

[More importantly, the emit prefix mitigates the name collision problem
that I encountered originally...]

++

I am therefore proposing the following API change: signal interface
names in inner types will be the changed to PascalCase matching the Java
conventions for type names.

So we'll now have:

        b.connect(new Button.Clicked() {
            public void onClicked(Button source) {
                // do stuff
            }
        });

        e.connect(new Editable.Changed() {
            public void onChanged(Editable source) {
                // do stuff
            }
        });

        v.connect(new TreeView.RowActivated() {
            public void onRowActivated(TreeView source, TreePath path, TreeViewColumn vertical) {
                // do stuff
            }
        });

taking the examples from above.

The repetition from the first line to the second is _slightly_ annoying
[note 1], but the fact that it clearly and consistently names the signal
is, I think, a massive win.

Before you ask, no, I'm not entirely sure why I didn't consider
Button.Clicked acceptable 2 years ago.

++

You know how these things go. Once you get an idea, you have to try it.
The code generator change was made and a proof of concept done. It
looked pretty damn good. 

And once you get started, it's tough not to finish.

So it's done.

I have a branch called 'signal-name-change' which implements this API
change. The branch is at
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/signal-name-change/

All signals in 'mainline' have been converted. Following the deprecation
convention that I wrote about yesterday, all signals that were included
in releases (ie up to 4.0.7) have been duplicated in their original
form, marked /** @deprecated */ [note 2] and have asserts in their
duplicate connect() methods to encourage migration.

I have made the change in one of my projects already, and it was quite
straight forward. Assuming your IDE does not show deprecated methods,
the code completions are perfect and fixing the warnings to do the port
is a few minutes work at most.

So it looks sound.

This went from "well, this is something we could do in the future" to
"wow, this is a big API change and is probably going to have to trigger
4.1.0, damn" to "it's done, and I can get this in before 4.0.8 in an API
safe way" remarkably quickly [note 3].

I've already polled a number of the old heads in our community about
this, and the response has been positive. It is, nevertheless,
appropriate for me to ask for comments here before actually deciding on
this change and merging to 'mainline'.

The branch is there if you want to test it yourself or contribute to the
"clean up the typos" hunt.

AfC
Sydney


1: Trivia: I recently switched my syntax highlighting to have method
declarations be bolded black instead of normal black in my IDE; I did it
to help me pick out method starts a bit more clearly, but it's actually
a nice touch in signal handlers too. I threw in a screenshot of what I'm
talking about.

2. I had to switch from @Deprecated to /** @deprecated */ because
`javadoc -nodeprecated` still includes methods that are @Deprecated when
generating HTML docs. This is annoying.

3: where "quickly" was almost 12 straight hours of hacking. You're
welcome. :)

-- 
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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] An idiom for deprecating things

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

Hello,

A couple methods needed a signature changes yesterday (renames, as it
happened). I implemented the correct signature, and then pondered what
to do with the old one.

People in the Java land are a lot more clued in about [not using]
deprecated things that it seems most developers using GTK in C are.
Tough for them. But part of the problem there is that they weren't
strongly incented to get on with fixing their code.

I came up with an idiom that I'm actually really happy with:

        /**
         * Original JavaDoc here.
         *
         * @since 4.0.8
         */
        public void betterMethodName() {
            GtkHotness.methodName();
        }
        
        @Deprecated
        public void oldMethodName() {
            assert false : "Deprecated. Use betterMethodName()";
            GtkHotness.methodName();
        }
        
This is lovely. It means that the old method is still present and
people's programs will still build. But anyone with assertions enabled
(which should be a default, but it depends on what VM you're using;
certainly any developer who runs without -ea on the Java command line
should be shot) will have the code fail. If a user is desperate to run
the thing without fixing their code, then they can always use `java -da`
to disable assertions and thus allow the code to run.

So that's what I did.

++

As has been practise during the 4.0 series, deprecated methods will
remain for one more release only (ie 4.0.8), and will be removed during
the next one (ie before 4.0.9).

The caveat on the website continues to apply until 4.2.

++

Thanks to Kenneth Prugh for his review.

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Create a Nautilus binding

[Jack H. <jac...@gm...>]

Hi Andrew,

On Mon, Jul 28, 2008 at 12:43 AM, Andrew Cowie <
an...@op...> wrote:

> On Mon, 2008-07-28 at 00:13 -0400, Jack Hong wrote:
> > Hi AfC,
>
> You can call me Andrew :)
>
> > 3) the extension module will be a standard nautilus extension module
> > written in C; it shall start a JVM, scan some dirs for Java-based
> > "provider" implementations, load and register them to the Nautilus
> > instance;
>
> So this is a complex area; for some related thoughts on a similar topic,
> see http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1135
>
Thank god the nautilus extension API is not Bonobo based!


> I'll look into the rest of your ideas in the next day or two. Sounds
> like you are barrelling along; if you've got a branch already I'd be
> pleased to start looking at it.
>
I spent a few more hours hacking on my own branch this morning, I'll let you
know as soon as I have something ready for review.  I wrote a simple
implementation of the nautilus extension module piece and some binding
classes.  Now I just need to figure out how to instantiate a subclass of
GObject directly, I'm very close to having a working prototype.  In a common
scenario, a native object is either created by calling the something_new
constructor or retrieved by calling some other functions like
something_copy, etc., the generated part knows how to interact with the
native part and then the developer uses the better looking Java binding
class that calls the generated part.  In other words, you always have the
native object first.  In my case, I have to instantiate a Java object
directly and pass the pointer of the native part of that object to
Nautilus.  Is there an example for this?


>
> >         Coverage of GList* of things is implemented, though you need
> >         to mark up
> >         the .defs data slightly. See Widget's getChildren() and the
> >         corresponding data in  src/defs/GtkWidget.defs
>
> Sorry, I meant Container.

Got it, now my GList* things are correctly generated!


>
>
> AfC
> Sydney
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

Cheers,

Jack

Re: [java-gnome-hackers] Trouble figuring out Screens and Displays

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

On Mon, 2008-07-28 at 09:04 +0200, Stefan Prelle wrote:
> I don't know how to proceed with the Display. I wanted to port a
> Dual-Head Swing application to java-gnome, but it seems GTK identifies
> screens and displays different then Swing does under Linux.
> My setup with one desktop spread over two monitors with Xinerama turned
> on, is identified as two screens under Java Swing and only one (big)
> screen under GTK.

Hm.

I suggest:

a) you hang around in #gtk+ and ask the people there about it,

b) translate your question to the 3-4 GTK C calls you are making and how
they aren't quite doing what you expect and send an email to gtk-list,

c) look at the gtk-list archives and in bugzilla. I distinctly recall
seeing the phrase "size of the glass" vs "size of the Xinerama desktop"
in recent weeks, and

d) Consider the difference between GdkScreen and GdkDisplay. Maybe
you've just got the wrong one.

I mean, Metacity understands individual monitors... It *is* doable.

> So my motivation to keep working on this topic doesn't exist right now,

That is perfectly fine.

I only want people contributing things they are interested in and
successful with.

Do me a favour, though - split your Display,DisplayManager stuff onto a
little branch of its own and send me the bundle. I'll put it online so
we don't lose track of it, and we can fix it up once we learn, someday,
how to use it properly.

[I wish I could help, but I haven't had dual monitors for a year or two
now, sorry]

AfC
Sydney

Re: [java-gnome-hackers] Create a Nautilus binding

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

On Mon, 2008-07-28 at 00:13 -0400, Jack Hong wrote:
> Hi AfC,

You can call me Andrew :)

> 3) the extension module will be a standard nautilus extension module
> written in C; it shall start a JVM, scan some dirs for Java-based
> "provider" implementations, load and register them to the Nautilus
> instance;

So this is a complex area; for some related thoughts on a similar topic,
see http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1135 

I'll look into the rest of your ideas in the next day or two. Sounds
like you are barrelling along; if you've got a branch already I'd be
pleased to start looking at it.

>         Coverage of GList* of things is implemented, though you need
>         to mark up
>         the .defs data slightly. See Widget's getChildren() and the
>         corresponding data in  src/defs/GtkWidget.defs

Sorry, I meant Container.

AfC
Sydney

Re: [java-gnome-hackers] Create a Nautilus binding

[Jack H. <jac...@gm...>]

Hi AfC,

On Sat, Jul 26, 2008 at 3:55 AM, Andrew Cowie <
an...@op...> wrote:

> On Fri, 2008-07-25 at 23:34 -0400, Jack Hong wrote:
> > Thanks very much Andrew!  It compiles happily if I change the .defs
> > from 'define-interface'
>
> The canonical (and original) interface implementation was
> org.gnome.gtk.FileChooser and GtkFileChooser.defs, which is the
> interface implemented by org.gnome.gtk.FileChooserButton and friends. I
> suggest you look at a method like FileChooserButton's setAction().

I will have a look at the FileChooser impl, thanks!


>
> However, you really need to discuss [with us] what interfaces you are
> trying to represent, how you plan to expose them, and what divergences,
> if any, you are anticipating to make the API more appropriate to Java
> developers.
>
> Arbitrarily changing something from an interface to an object in
> the .defs data sounds wildly inappropriate.
>
I was just telling you by changing it from an interface to an object in the
.defs, the generated .c did have the header file included, I knew that
wouldn't be the solution.  I started reading some code and writing some of
my own from last Friday and have only spent 3 hours so far.  I'm really new
to this project, so what I'm doing and saying may look and sound very silly
to you, please bear with me, your input is greatly appreciated!

Here are some quick thoughts about the nautilus binding that I'd like to
work on.
1) the nautilus binding will consist of 2 pieces: the binding piece and the
extension module;
2) the binding piece will be same as other JG bindings providing Java
interfaces and classes for Java developers to implement any nautilus
"provider" in Java.  All provider interfaces, namely NautilusColumnProvider,
NautilusInfoProvider, NautilusMenuProvider, NautilusPropertyPageProvider and
NautilusLocationWidgetProvider, shall be supported;
3) the extension module will be a standard nautilus extension module written
in C; it shall start a JVM, scan some dirs for Java-based "provider"
implementations, load and register them to the Nautilus instance;


> >  to 'define-object', but I'm not sure whether that's what I should do
> > or not.  I also noticed that some types (GList
>
> Coverage of GList* of things is implemented, though you need to mark up
> the .defs data slightly. See Widget's getChildren() and the
> corresponding data in  src/defs/GtkWidget.defs

I updated my local "mainline" directory but did not find the getChildren()
method you suggested in your email.  Is it not on mainline?


>
> AfC
> Sydney
>
> P.S. Please stop top posting. It is considered poor etiquette in the
> Open Source world. And I _am_ subscribed to the mailing list. You don't
> need to send me my own copy of each email you send.

My apologies.


>
>
> --
> 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. We actively
> carry out research and development in these areas on behalf of our
> clients, and enable successful use of open source in their mission
> critical enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

Cheers,

Jack

Re: [java-gnome-hackers] Create a Nautilus binding

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

On Fri, 2008-07-25 at 23:34 -0400, Jack Hong wrote:
> Thanks very much Andrew!  It compiles happily if I change the .defs
> from 'define-interface'

The canonical (and original) interface implementation was
org.gnome.gtk.FileChooser and GtkFileChooser.defs, which is the
interface implemented by org.gnome.gtk.FileChooserButton and friends. I
suggest you look at a method like FileChooserButton's setAction().

However, you really need to discuss [with us] what interfaces you are
trying to represent, how you plan to expose them, and what divergences,
if any, you are anticipating to make the API more appropriate to Java
developers.

Arbitrarily changing something from an interface to an object in
the .defs data sounds wildly inappropriate.

>  to 'define-object', but I'm not sure whether that's what I should do
> or not.  I also noticed that some types (GList

Coverage of GList* of things is implemented, though you need to mark up
the .defs data slightly. See Widget's getChildren() and the
corresponding data in  src/defs/GtkWidget.defs

AfC
Sydney

P.S. Please stop top posting. It is considered poor etiquette in the
Open Source world. And I _am_ subscribed to the mailing list. You don't
need to send me my own copy of each email you send.

-- 
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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Create a Nautilus binding

[Jack H. <jac...@gm...>]

Thanks very much Andrew!  It compiles happily if I change the .defs from
'define-interface' to 'define-object', but I'm not sure whether that's what
I should do or not.  I also noticed that some types (GList, GFile, etc.) are
generated as FIXME and the function implementations simply throw an error,
please advise what I should do with these unsupported types, thank you.

Jack



On Fri, Jul 25, 2008 at 6:57 PM, Andrew Cowie <
an...@op...> wrote:

> On Fri, 2008-07-25 at 14:11 -0400, Jack Hong wrote:
> > I was thinking about creating a Nautilus binding
>
> Terrific.
>
> > 2) Am I on the right track?
>
> It sounds like it, but without seeing your code, it is rather hard to
> say.
>
> > 3) Why the header file isn't included?
>
> I don't know.
>
>  (import-header "whatever.h")
>
> should work. It does work, or the rest of the library wouldn't build and
> the unit tests wouldn't pass :/
>
> So it's probably not that. You didn't forget to mark something as a
> pointer, did you?
>
> AfC
> Sydney
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

Re: [java-gnome-hackers] Create a Nautilus binding

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

On Fri, 2008-07-25 at 14:11 -0400, Jack Hong wrote:
> I was thinking about creating a Nautilus binding

Terrific.

> 2) Am I on the right track?

It sounds like it, but without seeing your code, it is rather hard to
say.

> 3) Why the header file isn't included?

I don't know.

  (import-header "whatever.h")

should work. It does work, or the rest of the library wouldn't build and
the unit tests wouldn't pass :/

So it's probably not that. You didn't forget to mark something as a
pointer, did you?

AfC
Sydney

[java-gnome-hackers] Create a Nautilus binding

[Jack H. <jac...@gm...>]

Hi guys,

I was thinking about creating a Nautilus binding, but couldn't find any
tutorial about how to get started with writing my own binding.  I read some
source code and tried putting some .defs files (created by 'demux
nautilus.defs') in the src/defs directory.  The new files got picked up and
I saw some .c and .java source files created in the 'generated' directory.
First it complained about some nautilus types are not defined, I figured
that 'import-header' was missing from the .defs files.  It seemed that I was
on the right track, but I got stuck at one particular file
'generated/bindings/org/gnome/nautilus/NautilusFileInfo.c' complaining
"NautilusFileInfo undeclared".  I looked at the generated .c file, it
doesn't have the #include line generated for the header file that I added to
its .defs file.  Other generated .c files all have the proper header files
included according to their .defs files, but not this one.  So my questions
are:

1) Is there a tutorial for creating bindings?
2) Am I on the right track?
3) Why the header file isn't included?


Thanks in advance!


Jack Hong

Re: [java-gnome-hackers] Starting to think about the next release

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

Hi!

I have some work in progress, maybe some things could be part of 4.0.8. However, I'll take vacations next week; if you delay release till, say,
15th August, I'll have time to review and submit you some patches. 

I'm thinking mainly about Pango, but maybe we can make some progress with gstreamer or gconf. And, of course, I have several tiny coverage aditions I've been using these months but still lack documentation.

Cheers
Vreixo


--- Em sex, 25/7/08, Andrew Cowie <an...@op...> escreveu:

> De: Andrew Cowie <an...@op...>
> Assunto: [java-gnome-hackers] Starting to think about the next release
> Para: "java-gnome-hackers" <jav...@li...>
> Data: Sexta-feira, 25 de Julho de 2008, 0:58
> Hello all,
> 
> It's been a while since our last release, so I'm
> starting to think about
> cutting java-gnome 4.0.8.
> 
> I have personally been focused on a number of other things
> (ie, _using_
> java-gnome, not just hacking on the library, and more to
> the point, ie
> trying to find work to pay the bills, because this project
> sure as hell
> doesn't) but there are a number of fixes from new
> contributors that are
> on 'mainline' that are probably worth putting out.
> 
> The 'textview' branch that Stefan, Kenneth, and I
> have been working on
> is coming along, but still isn't anywhere near merge
> ready. I had been
> hoping that it would make it into 4.0.8, but I don't
> think that's going
> to happen. Alas.
> 
> Anyway, if someone has a burning desire to see something in
> 4.0.8, then
> now would be a good time to get it cleaned up and
> submitted.
> 
>         {ahem, cough}
> 
>         Srichand, that Cairo work you were telling me
> about...
>         Stefan, that Assistant branch...
>         Vreixo, the Pango text rendering work you said you
> were doing...
> 
>         [Jeesh, if you guys take too long, TextView
> coverage will make
>         it in after all. :)]
> 
> I'm not actually in a rush to make this next release
> (especially if it
> is lacking TextView coverage). That said, 4.0.4 was a point
> release
> without any big headlines, so I guess I shouldn't worry
> about that.
> 
> Doing a release takes a lot of work (API review, testing,
> website
> updates, NEWS entry, more testing, publicity, etc), so
> people nudging me
> to do a release in order to show vibrancy in the project
> would probably
> make me feel better about spending the time on it.
> 
> Who wants to write the NEWS entry for this one?
> 
> 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. We
> actively
> carry out research and development in these areas on behalf
> of our
> clients, and enable successful use of open source in their
> mission
> critical enterprises, worldwide.
> 
> http://www.operationaldynamics.com/
> 
> Sydney   New York   Toronto   London
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers


      Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses

[java-gnome-hackers] Starting to think about the next release

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

Hello all,

It's been a while since our last release, so I'm starting to think about
cutting java-gnome 4.0.8.

I have personally been focused on a number of other things (ie, _using_
java-gnome, not just hacking on the library, and more to the point, ie
trying to find work to pay the bills, because this project sure as hell
doesn't) but there are a number of fixes from new contributors that are
on 'mainline' that are probably worth putting out.

The 'textview' branch that Stefan, Kenneth, and I have been working on
is coming along, but still isn't anywhere near merge ready. I had been
hoping that it would make it into 4.0.8, but I don't think that's going
to happen. Alas.

Anyway, if someone has a burning desire to see something in 4.0.8, then
now would be a good time to get it cleaned up and submitted.

        {ahem, cough}

        Srichand, that Cairo work you were telling me about...
        Stefan, that Assistant branch...
        Vreixo, the Pango text rendering work you said you were doing...

        [Jeesh, if you guys take too long, TextView coverage will make
        it in after all. :)]

I'm not actually in a rush to make this next release (especially if it
is lacking TextView coverage). That said, 4.0.4 was a point release
without any big headlines, so I guess I shouldn't worry about that.

Doing a release takes a lot of work (API review, testing, website
updates, NEWS entry, more testing, publicity, etc), so people nudging me
to do a release in order to show vibrancy in the project would probably
make me feel better about spending the time on it.

Who wants to write the NEWS entry for this one?

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Thoughts on an Applet binding

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

While peeking into a problem [note 1] that Kenneth Prugh encountered
with the TrayIcon shown by Slashtime, I got onto an interesting
discussion about the possibilities and challenges of designing an Applet
API for java-gnome with Tim Retout.

With his permission, and with only minor cleanups, I have paraphrased
that IRC conversation below, converting it to email form.


        (if you haven't a clue what I'm talking about,
        http://research.operationaldynamics.com/projects/slashtime/ It's just a fun little program that I once wrote, first as a command line Perl script, later in GUI form with java-gnome 2.x, and then ported to java-gnome 4.0; just a diversion from more important things. It's not anywhere near big enough to be regarded as a "real" application and it does not exhibit proper layering or enterprise application design; I therefore do *not* hold it up as the ultimate java-gnome example or anything like that. It is, however, done all the way to `make install` and has a solid UI, and mostly correct HIGginess, and is now packaged on Gentoo. Yeay for small programs that do their job well)


Slashtime was originally intended  to be an applet (a clock applet
replacement that would do things the way I wanted), but that's just Too
Hard™ right now. Partly because GNOME's applet APIs are insane, and
partly because they are so impossible to debug [or more to the point,
hack on and develop])

> Hehe, I take it bonobo doesn't have bindings.

That's part of the problem. Bonobo being deprecated is a bigger part of
the problem. Bonobo being a CORBA disaster puts the bigger problem into
some clarity. GNOME now using DBus for IPC now doesn't really change
anything. Especially since the panel is still Bonobo based. And since
the only person working on it is long lost off in deeply recursed land.

> Is the new panel applet api still happening sometime soon? It always
> seems to be somewhere in the future.

Yeah (and what I saw from Ryan in Berlin in March did not lend me any
encouragement [note 2])

> :/

Frankly, I haven't given up all hope to do something with the existing
panel applet implementation. I actually wonder if we couldn't come up
with a pretty bloody good wrapper. I also wonder that since all the
xml .server files etc etc etc used to drive applets are ultimately
information used to configure the CORBA interfaces,

a) couldn't we just use CORBA instead of Bonobo [noting that there is a
CORBA engine in core Java] and separately, and/or

b) couldn't we just dynamically generate (based on the result of
initializing an object in Java and setting various properties on it) all
the .server and factory information and dynamically register the applet
at runtime?

[as opposed to having to put it on disk and worse install it to /usr to
be able to see it work] Again, somewhat orthogonally, there is the
question of establishing a factory from which instances will run. Java
actually could be pretty good for that; bloated it may be off the marks,
but it's every good at efficient use of resources amortized over long
running.

I suspect that a middle road in the above would be to write a generic
Java applet server that we could then hook clients to. But that might be
just as much work as figuring it out dynamically.


> If it could be done, it would be great, but it sounds quite
> ambitious. :)

Yes. In fact, it would be *exceedingly* cool.

And yes, it would be ambitious. More to the point, it will take someone
who is well versed in CORBA [or at least the Java APIs for same] and
someone who know a fair bit about the GNOME Applet APIs +
infrastructure.

(or s/CORBA/do a Bonobo binding/).

> Yes.

I've studied the Applet part a fair bit, but I don't know if I know
enough.

Like I said, the only approach that makes any sense to me as an end
result is something that can dynamically register server and menu
information. (obviously a hard wired intermediate would be a step along
the way, but I don't really want to try and expose that as an API) It's
something I think about from time to time.

But I'm not likely to be able to get to it any time soon. Would love to
collaborate with someone on it. I almost got Srichand interested in
doing it last year :)


> The .server files are used to start a factory, so registering at
> runtime would present a bootstrapping problem, no? As in, it wouldn't
> show up in the "Add to panel" list until you ran it.

Yes. I am postulating that since they too are ORB data (or at least,
they look bloody suspiciously like it) and if so, that said data would
therefore be marshalled over the wire, and so potentially "Add to Panel"
could be conn'd into thinking that there is an applet it could add.

But yes it's a bootstrapping problem.

> Heh, I wonder if that would need changes to the existing code. :)
> Probably.

Actually, it's this: When the panel starts up, where does it get factory
[binary] names from? But the reason I am so excited about the
possibilities that arise from being dynamic about it is that the much
harder problem is "how the fuck do you develop one of these things?"

> Yeah, you have to mess about with installing the .server file, running
> and killing, then start from console...

Frankly, the fact that I have to populate a .server file (etc)
into /usr/whatever before I can even test my Hello World applet...

...yes, ok you've read the same stuff I have. It seems insane. I mean, I
understand why it is that way at present, but I cannot imagine inviting
someone who wants to do "something quick" to be all impressed with GNOME
and java-gnome as a result to follow such instructions.

"Hijack an applet that you're not using, say modem lights, and point it
at your test case."

I cannot conceive of writing that down in our JavaDoc for a prospective
java-gnome developer to read.

So.

>  that sounds nasty

The other hypothetical possibility is to write your applet program, run
it, [have it magically register factory, etc], so you can then add to
panel and play with it...

The fact that "making it permanent" would take a different strategy is
evident. Obviously the old heads in GNOME would sternly say "that's not
how it's done"

> :)

but it sure would be a better development experience. Actually, since
Applet development at present is so arcane, I would go so far as to say
at present it is de facto impossible. And that's bad for GNOME. So, I'd
love to see if we can fix that.

Because, "Subclass org.gnome.panel.Applet, set the following minimum
list of properties (name, blah blah blah) and then run your program."
+ either a) "then Add to Panel" or b) some debug only harness for applet
development which causes your applet to instantly appear somewhere on a
panel, assuming you've already Add to Panel the debug harness [that's
the intermediate step I was talking about]

... is a shitload more palatable that the present applet development
paradigm.


> It would be simple to have a method to generate a .server file in
> that class, as well. For the permanent approach later, I mean.

Yes, that's a possibility. As you point out, the chicken and egg factor
is a bit ugly, but let me put it this way.

Take my little slashtime almost-applet. I developed that over a long
period of time. [Happened to rewrite java-gnome along the way, kinda put
it on pause :)]

> Heh.

but irrespective of that, I developed the application first. Later I
created the StatusIcon to go in the notification area (which is mostly a
workaround for the fact that it's not a real applet. Bad™) but only a
few months ago (weeks even) did I create the .desktop file so it would
appear in GNOME menus when installed and supporting project metadata
files (README and friends). Not to mention a `make install` step, etc.

In other words, proof of concept comes first. Then serious development.
Only at the end does installation infrastructure and supporting system
metadata get created.

Applets fuck that up. Get it completely backwards

Actually, the case of the tray icon is an interesting one. They work
because an applet has ALREADY been added to panel - the "Notification
Area" applet. Once that is there, then starting my program causes icon
to appear. Terminating it, icon disappears.

> Mmm.

Quite sensible. One doesn't really think about it. If you are creating a
program that lives in one or more Windows, well, run program, Window
appears. Terminate program, poof. That's _development_. So while there
is a non trivial transform to get from development to system-installed
(usually via being packaged, but `/usr/local` is a variation and really
makes a mess of the option space as anyone who has written a `make
install` target knows), ease of development has to come first.

Really, this is all just a case study in the cornerstone principle I
rewrote java-gnome on: Approachability.

Anyway, your point about writing out a .server file is well made. It's a
quite sensible possibility. I note, however, that the user needing write
access to /usr/lib/bonobo/servers/ in order to create and test a Hello
World applet is patently ridiculous. So it needs something else. If
a .server is needed for the long term system-install & packaging, then
writing one out would be useful.


> Staring at gnome-panel code hasn't immediately made it obvious
> whether a generic corba interface is possible.

I'm not sure. It's all very hard wired. (So, perhaps a hard wired Bonobo
binding, ok, {shrug}. It's the generic Bonobo binding I don't want to
write). But Bonobo takes that data and does something over the wire. I'm
betting we can do so too.


> Anyway, I'd better go to bed. This is all very interesting...

> For applets, you just need a very limited interface. Not even the C
> applets use more than one macro wrapping it all.

That's what is so frustrating. The end result developer experience could
be extraordinarily good. Applets should be easy!

Good night.

AfC
Sydney

Footnotes
---------

*1 Ken's bug was due to him not running GNOME. He doesn't even run a
Desktop Environment. Arghhhh! ENOTOURTARGETAUDIENCE! (People who hang
out in #java-gnome who are not passionate about wanting to develop GNOME
applications are completely mind-boggling to me. Jeffery and I talked
about this a few years ago; he encountered the same thing when he was
running the project. THAT SAID, what I remarked to Ken at the time was
"I'm glad you are finding a way to use our software in an setting other
than what we designed it for. I can't say as how that is 'supported' but
[being able to] do things with software [unanticipated by the original
authors] is what Open Source is all about).

*2 Don't get me wrong. Ryan is hard at work on infrastructure a number
of layers down that could well be the foundation for an exciting new
technology to help facilitate GNOME applications' settings and data
interchange. And it all started because he was trying to do a next
generation Panel Applet API, and encountered  limitations he needed to
fix in the underlying infrastructure. That led to deeper problems he
wanted to address. And so on. **Deeply recursed**. I appreciate his hard
work.

java-gnome is a deep recursion for me; I am about 5 levels below where I
should be focusing my energies. Needless to say, when Naba asked me to
work on adding Java support in Anjuta [GNOME's IDE], I freaked. I'd
_love_ to help, and having Java in Anjuta would make java-gnome even
more well rounded for people, but I'm not sure working on an IDE at this
point is a going to help me pop back out of the stack at all :)

I know of a guy who started his computing career by filing a bug
(against Debian, I believe). Then he got more involved, both as a sys
admin and as a Debian packager. Then he started filing bugs in an
upstream project and programming... some time later he was writing Linux
kernel device drivers ... fast forward, last I heard of him, he was
doing VLSI chip design.

When you recurse lower into the stack, it can be hard to get back again.
Nothing wrong with that if doing something that has caught your interest
and imagination...  unless there was something higher level you needed
to get done :)

I wonder if the bug he filed ever got fixed.


-- 
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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] [Java-gnome-developer] Access to gnome keyring from java

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

On Wed, 2008-07-02 at 20:44 -0500, Srichand Pendyala wrote a reply to a
message on the java-gnome-developer mailing list; I have sent my reply
and invited follow ups to java-gnome-hackers:

> Just a thought:
> 
> The gnome-keyring API is still in flux, as is mentioned at
> http://live.gnome.org/GnomeKeyring/StoringPasswords . Although the API
> is nice and small (3 meaty methods!)

From a first glance at the API pages, it seems that the real problem
would be working out how to handle all the async callbacks. We don't
have a terribly good mechanism for that at the moment

[and have only done it manually once - the hack that made
TreeModelFilter's setVisibleCallback() work by turning it into a signal]

so perhaps it's time that we worked that out in the architecture and
then extruded that design via the code generator.

>  and could probably be re-written to
> match the upstream API as and when it changes,

Sure.

>  would it make sense to
> hold off binding it until its a little more mature? 

It's probably hardening. The degree of arterial sclerosis that occurs
once a library has been released out into the wilds is fairly insane.

While I have no objection at all to binding against unstable libraries,
the changing signature problem could cause us to have link failures if
the underlying library in question is iterating too fast.

{shrug}

That's life in the big city; and as I'm not into having java-gnome
support ancient versions of underlying libraries but rather have
stipulated the dependency as latest releases (ie, GTK 2.12, Cairo 1.6.4,
and for that matter, GNOME 2.22, etc) we shouldn't have too much problem
when the time comes.

AfC
Sydney

Re: [java-gnome-hackers] Patch bundle for java-gnome, CellRendererToggle

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

On Wed, 2008-06-25 at 17:47 +0200, Andreas Kühntopf submitted a patch in
an email where he wrote:

> I have not written a test case for it, but i use it in a small app and
> it seems to work fine.

No doubt. However, if *I* don't have an app using it, it is a bit harder
for me to establish the same level of confidence. Nothing personal.

[This is where snapshots have proved so useful; not only do they improve
our documentation but they also act as a form of test coverage and a
demo (for hackers' review purposes) as well]

> Please let me know if this patch doesn't meet your quality standards
> or
> if you need something else.
> Any feedback is appreciated.

Sure. It looks pretty close. Let's see.


> === modified file 'src/bindings/org/gnome/gtk/CellRendererToggle.java'
> --- src/bindings/org/gnome/gtk/CellRendererToggle.java	2008-04-03
> 06:13:03 +0000
> +++ src/bindings/org/gnome/gtk/CellRendererToggle.java	2008-06-25
> 15:30:42 +0000
> +    /**
> +     * Indicate the appearance of this CellRenderer. If
> +     * this is set to true a radio button is used instead of
> +     * the default check box.
> +     */
> +    public void setRadio(boolean radio) {
> +        GtkCellRendererToggle.setRadio(this, true);                
> +    }

You noted that you had not included any unit tests. While I am not
compulsive at insisting that there must be a unit test for every last
setter or getter (finding that a bit pedantic) I cannot help but notice
that having a test of this one would have helped you notice something
wrong here...


> +
> +    /**
> +     * Indicate if the CellRenderer's toggle button
> +     * should be active.
> +     * 
> +     * <p>
> +     * If you want to bind the state of the toggle button
> +     * to a DataColumn you might want to use the overloaded method
> +     * {@link #setActive(DataColumnBoolean) setActive()}
> +     */
> +    public void setActive(boolean active) {
> +        GtkCellRendererToggle.setActive(this, active);
> +    }
> +    
> +    /**
> +     * Get the current state of the toggle button
> +     */
> +    public boolean getActive() {
> +        return GtkCellRendererToggle.getActive(this);
> +    }
> +    
> +    /**
> +     * Indicate the DataColumn the state of the CellRendererBoolean
> is
> +     * bound to. This is the mapping method you should use if you
> want to bind
> +     * the toggle button's state to a DataColumn's value.      
> +     */
> +    public void setActive(DataColumnBoolean column) {
> +        GtkCellLayout.addAttribute(vertical, this, "active",
> column.getOrdinal());       
> +    }
> +       

 
> +    /**
> +     * Event generated after user toggles the renderered 
> +     * toggle button in a Cell.

"Event" has particular meaning in GTK, so we have to be kind of careful
about using the word. An "event signal" is a signal that is emitted as a
result of an event coming out of GDK [which, as far as I understand it,
is more or less a 1:1 mapping of events coming out of the X server].

So "The signal emitted..." tends to be the prose we have been using,
though we have been sloppy in a few places, especially on Widget where
the signals are events :)

> +     * Note that the act of toggling the cell does not cause a 
> +     * change in the underlying model.

That is EXACTLY the sort of knowledge that needs to be incorporated into
our API documentation. Well done.


> +     * 
> +     * @author Andreas Kuehntopf
> +     */

When proposing a patch for merging to mainline, please include @since
tags on all classes and methods.

Actually, unless it's just a diff fragment for conceptual review, always
put @since tags in; you can assume that if accepted your code will be in
the next release. That's the whole idea, after all.

[If a branch we're collaborating on doesn't get merged before a release
we just bump the tags when we next work on it]


> +     * renderer.setActive(column);
> +     * renderer.setEditable(true);

From the example snippet you wrote. You have to set a CellRendererToggle
editable to make it toggleable? I suppose that is understandable, but I
wouldn't have thought of that as the fix if wondering why my
CellRendererToggle wasn't working. It would be good to add a paragraph
about that to the class comment.


> +    /*
> +     * Helper class to convert second parameter from String to
> TreePath
> +     */

Great.

Code formatting applied;*
@since tags added;
Test cases added and bug fixed;
More test cases;
Spelling;
Documentation touch ups.

Merged to 'mainline'.

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Annotation-based glade parsing patch

[FL B. <fl_...@ya...>]

Hello!

This is my first post to the list.
During the last few weeks I have been working on an application for the 
gnome desktop written in Java, with the java-gnome bindings as the GUI 
toolkit. In order to make the windows and dialogs designing easier, 
instead of building them programatically, I used the Glade designer, and 
accessed them via libglade and two simple libraries I developed to make 
gnome developing faster. One of them, is a set of annotations which 
binds the glade files and the ui code.

Now this annotations  (and the app itself) are pretty stable and usable, 
I thought  It would be a good idea to release this tiny library under a 
GPL. But then I noticed there was a post in this list were some 
annotations with similar functionality (an even names) were proposed and 
implemented two months before.

However, I still would like to share them, because they have some 
features that could be found useful.

This are the features similar to the yet existing annotations:

*annotate widget attributes as @Widget,  in order to retrieve them from 
the glade file with an EJB fashion. If no name is specified, the 
attribute name is used to get them from the glade XML.
*annotate methods as @Handler, for defining signal handlers which listen 
to certain signals from certain widgets
*Classes wich want to use them must extends a Connector abstract class.
*annotations can be applied to private fileds

And this is are the extra features:

*signal handlers are methods instead of inner classes, which makes the 
code cleaner. The handler classes are generated at runtime. This methods 
are quite flexible in what return and parameter types refer.
*there is no jni code to access private fileds, is pure java.
*The need to extend a certain class could be a problem in Java (because 
of the lack of multiple inheritance), so the Conncetor class offers 
static methods which let any class to use this annotations even if they 
extend another class.
*offer a flexible error handling mechanism, which I believe is the most 
important feature. Normally, if an unhecked exception is thrown in a 
common singal handling  method, the gtk thread dies and the app crashes. 
This is really awful, because apps should at least inform about he bug, 
let the user sava his or her work, and quit normally. There are several 
ways to avoid this by hand: surrounding all methods with try-catch 
blocks or dispatching events in a separate thread.
Because of that, annotated methods have error handlers and associated. 
Depending on an optional attribute in @Handler annotations, you can set 
an ErrorHanndling Policy which logs, displays messages or performs 
custom code -using a third annotation @ErrorHandler - when unhandled 
exceptions are thrown. Obviously, this behaviour can be disabled if you 
prefer.

If you are interested in this library, write me, please. I would be glad 
of contributing to the java-gnome project.

Re: [java-gnome-hackers] Deprecated APIs

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

On Thu, 2008-06-19 at 18:51 +1000, Andrew Cowie wrote:
> If someone wants to go through and patch the .defs data to add
> (deprecated...) lines to each of the blocks corresponding to these
> functions, it'd be a nice contribution.

Murray was very helpful to point out that #defining things like
GTK_DISABLE_DEPRECATED will cause your code to break if you try to use a
deprecated API. Excellent.

I got to work on a branch to get going along these lines and made a bit
of progress. Notably, I added the appropriate flags to the gcc compiler
line so that the build will fail when it hits something that we
shouldn't be including.

If you want to chip in, a branch is up at
http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/deprecated
I won't be working on it again any time soon, so feel free to take it
from here.

[If you're going to hack away at this further I'd suggest making sure
you're in #java-gnome to make sure you don't duplicate effort with
someone else]

AfC
Sydney

Re: [java-gnome-hackers] Cairo threading

[Behdad E. <be...@be...>]

On Thu, 2008-06-19 at 18:22 +1000, Andrew Cowie wrote:
> 
> [1]: following the hypothesis that such a things are actually allowed
> in Cairo. It certainly isn't with gdk-pixbuf but that's a different
> library and GDK has clear rules about this stuff. See also
> http://bugzilla.gnome.org/show_bug.cgi?id=534573

Cairo's MT-safe as long you don't use/modify the same cairo_t,
cairo_surface_t, cairo_pattern_t, or cairo_font_options_t concurrently
from multiple threads . That is, the font objects that are reasonably
shared are MT-safe, the rest are not.


-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759

[java-gnome-hackers] Deprecated APIs

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

Martyn Russell posted a list of all the deprecated APIs in GTK. Since
they're all going to disappear pretty soon, and more to the point, we
don't present deprecated APIs in underlying libraries, we certainly
don't need to have any of them in our generated translation and JNI
layers.

I did this:

$ cd generated/bindings/org/gnome/gtk/
$ for i in `cat ~/Desktop/deprecated-apis.txt`
  do
      grep $i *.c
  done

and was quite unimpressed with how much we have in our generated code
that we don't need. What a waste of space in our .jar and .so!

I had thought that most of the stuff that was obscelete was marked with
(deprecated ...) lines [or, in the case of deprecated classes, removed
entirely] but I guess not.

If someone wants to go through and patch the .defs data to add
(deprecated...) lines to each of the blocks corresponding to these
functions, it'd be a nice contribution.

Martyn's original lists are attached [I'm not sure what he used to
generate these, so you will, of course, need to quality control the
information before acting].

AfC
Sydney



-------- Forwarded Message --------
From: Martyn Russell <ma...@im...>
Cc: gtk...@gn..., gtk...@gn...
Subject: Re: GTK 3.0: an app developer's view
Date: Tue, 17 Jun 2008 10:05:28 +0100


I just put together quickly a few lists of ALL things marked as
deprecated right now....

[java-gnome-hackers] Cairo threading

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

Srichand,

Just following up what we were talking about earlier,

If you read the comment at line 24 of
src/bindings/org/freedesktop/cairo/Plumbing.java, you'll see where I
mentioned that having this slaved to be the same object as Gdk.lock is
probably unnecessary and in the way of us using Cairo from multiple
threads simultaneously[1]. 

However, note that if you're doing drawing to write to screen or
otherwise do a Widget, you'll be doing so in the EXPOSE_EVENT handler
hooked up for that Widget, and **that will occur within the GDK lock**
anyway. So really, concurrency is all a non-starter insofar as Widget
drawing is concerned.

HOWEVER, almost every widget in every application on your desktop calls
Cairo to do its drawing in its 'expose-event', and gee, guess what,
everything is fine. Computers are fast at some things. More to the
point, the people who wrote Cairo know what they're about.

All in all this is probably not worth worrying about at the moment,
certainly in view of the serious bit of engineering that would be
necessary to make the code generator write synchronized blocks
conditionally. So you can concentrate on transforms and such if it
interests you.

AfC
Sydney

[1]: following the hypothesis that such a things are actually allowed
in Cairo. It certainly isn't with gdk-pixbuf but that's a different
library and GDK has clear rules about this stuff. See also
http://bugzilla.gnome.org/show_bug.cgi?id=534573

-- 
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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

On Tue, 2008-06-17 at 13:39 +0000, Vreixo Formoso Lopes wrote:
> > That would be overkill.
> 
> No really... we only need to expose exceptions we really need. As a
> future task, we can even modify the codegen and .defs data to report
> (as a throws WhateverException) the exceptions a concrete method can
> throw...

Don't do that.

You'd have to do add FindClass() on the JNI side for each Exception
you'd created.

And further, if it's "file not found" then the right Exception will be
FileNotFoundException. Etc.

Keep it on the Java side.

AfC
Sydney

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

--- Em ter, 17/6/08, Andrew Cowie <an...@op...> escreveu:

> On Mon, 2008-06-16 at 15:45 +0000, Vreixo Formoso Lopes
> wrote:
> > mmm, I thinking about a [maybe better] alternative.
> Currently for
> > functions that take a GError* we throw a GlibException
> from JNI side
> > when needed. Maybe we can create our own hierarchy
> based on
> > GlibException, and modify the JNI code to throw the
> speficic exception
> > based on the GError code.
> 
> That would be overkill.

No really... we only need to expose exceptions we really need. As a future task, we can even modify the codegen and .defs data to report (as a throws WhateverException) the exceptions a concrete method can throw...

Cheers
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

On Mon, 2008-06-16 at 15:45 +0000, Vreixo Formoso Lopes wrote:
> mmm, I thinking about a [maybe better] alternative. Currently for
> functions that take a GError* we throw a GlibException from JNI side
> when needed. Maybe we can create our own hierarchy based on
> GlibException, and modify the JNI code to throw the speficic exception
> based on the GError code.

That would be overkill.

AfC
Sydney

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

--- Em seg, 16/6/08, Andrew Cowie <an...@op...> escreveu:

> [Also, keep in mind that the Constants need to be
> registered, but there
> is nothing that says they need to be public. The typed
> Exception being
> thrown takes care of that]

mmm, I thinking about a [maybe better] alternative. Currently for functions that take a GError* we throw a GlibException from JNI side when needed. Maybe we can create our own hierarchy based on GlibException, and modify the JNI code to throw the speficic exception based on the GError code.

As long as GError codes are unique along all functions -Am I right?-, this simplifies the implementation of new coverage.

Cheers
Vreixo





      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/