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

Re: [java-gnome-hackers] Does junit-4 provide the JUnit 3 API?

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

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

I had no issues running it them from command line with our custom
TestRunner. But after replacing Junit3 with Junit4 in classpath. I get
VM crashes in ValidateFileChoosing.testSettingFilename() . Running it
with Junit3 runner causes IllegalStateException(Gtk already initialized)
in TestCaseGtk.init and a VM crash. Running it with Junit4 runner causes
only a crash. I'm attaching the crash logs. I suspect that our tests
aren't run in order that we expect to.

Thanks in advance.

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

iEYEARECAAYFAko1ECkACgkQRh6X64ivZaK1tQCeLvR/VJsAE6sIh7LcGxdoKAXY
3HQAni7j+ZA3UlwRoC2oUF6ZXAa8yhNb
=x8nN
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Does junit-4 provide the JUnit 3 API?

[Nat P. <nat...@gm...>]

Yes.  The JUnit 4 JAR also contains the JUnit 3.8.1 classes.

--Nat

2009/6/14 Andrew Cowie <an...@op...>:
> The other day someone ran into a strange situation that they had junit-4
> installed but not junit[-3]. We of course probe for JUnit 3.8 and quite
> correctly didn't accept what she did have because they didn't had there.
>
> A bit later, someone suggested that junit 4.x can run tests written to
> the junit 3.8 API; Thijs, Kenneth, and I looked around and saw lots of
> people complaining that this would have a bad ending. And certainly most
> build & packaging systems I know of go to quite some trouble to identify
> and ship them separately. Based on that alone I would have expected
> junit-4 to not be a strict upgrade from junit.
>
> On the other hand, I was fairly sure that JUnit 4.x ships classes that
> allow you to run original tests against it. Just for the heck of it I
> manually changed my build to use junit-4 for a moment and it compiled
> and then executed the tests fine.
>
> So if someone who knows can comment authoritatively, perhaps we can
> accept the presence of junit-4 (should it be available without finding
> junit) to satisfy our test infrastructure requirement when probing?
>
> Anyway, until and unless the answer to this comes up "yes, it's fine",
> java-gnome depends on junit-3.8, as it has since the beginning.
>
> [Our tests will continue to be written to the original JUnit 3 API. It's
> more than fine for our purposes, and we have no need to depend on
> junit-4 as a result]
>
> AfC
> Sydney
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>



-- 
http://www.natpryce.com

[java-gnome-hackers] Does junit-4 provide the JUnit 3 API?

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

The other day someone ran into a strange situation that they had junit-4
installed but not junit[-3]. We of course probe for JUnit 3.8 and quite
correctly didn't accept what she did have because they didn't had there.

A bit later, someone suggested that junit 4.x can run tests written to
the junit 3.8 API; Thijs, Kenneth, and I looked around and saw lots of
people complaining that this would have a bad ending. And certainly most
build & packaging systems I know of go to quite some trouble to identify
and ship them separately. Based on that alone I would have expected
junit-4 to not be a strict upgrade from junit.

On the other hand, I was fairly sure that JUnit 4.x ships classes that
allow you to run original tests against it. Just for the heck of it I
manually changed my build to use junit-4 for a moment and it compiled
and then executed the tests fine.

So if someone who knows can comment authoritatively, perhaps we can
accept the presence of junit-4 (should it be available without finding
junit) to satisfy our test infrastructure requirement when probing?

Anyway, until and unless the answer to this comes up "yes, it's fine",
java-gnome depends on junit-3.8, as it has since the beginning.

[Our tests will continue to be written to the original JUnit 3 API. It's
more than fine for our purposes, and we have no need to depend on
junit-4 as a result]

AfC
Sydney

[java-gnome-hackers] Release candidate

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

I cut a 4.0.12-rc1 tarball and uploaded it.

The configure probes for the new prerequisites are going to need some
polish for people on other distros. Gentoo works. We had someone
contribute the Debian bits (which I would appreciate if someone could
double check). Arch, Fedora and others will need some love.

AfC
Sydney

Re: [java-gnome-hackers] Proposal for signal disconnect

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

On Fri, 2009-06-05 at 13:55 +0000, Vreixo Formoso Lopes wrote:
> Attached you can find my proposal for signal disconnect support, 

I haven't forgotten about this; just haven't had time to look at it
personally, sorry. Perhaps someone else can comment?

Signal disconnection came up because Serkan needed it for his libnotify
branch; since he found another way to do what he wanted this is
(relative to that need) less urgent.

AfC
Sydney

[java-gnome-hackers] Proposal for signal disconnect

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

Hi all,

Attached you can find my proposal for signal disconnect support, 
that seems needed in some cases. Note that the code is purely 
experimental and not tested at all. It's just for discussion.

The implementation details follow.

First, just remember you we had a handlers list in glib.Object, list
that was needed so the last strong ref to a handler is stored java side,
not JNI side, so GC could detect reference cycles.

So, I have modified that list, in order to store not just a reference to
the handler, but also the signal name, and the opaque handlerId we get
form glib when the signal is connected. This info is stored in a new
package-visible class SignalHandlerInfo.

So, when user connects to a signal, we store that reference in the
Object. This way, we can later retrieve the handler id and disconnect
it. Moreover, before connecting to the signal, we check if the handler
is not already connected. If it is, I just return without connecting it
again (we may want to change this later...).

Internally, SignalHandlerInfo are stored in an unsorted LinkedList, not
a map. It might seem ugly (we need to transverse the list during
searches), but it has less memory pressure than a HashMap, and the look
up penalty do not actually happen as: a) the number of handlers tend to
be small (few handlers per object), so a list is fast enough, and b) you
usually do not continuously connect/disconnect from signals.

Finally, notice that the key method is Plumbing.disconnectSignal(Object,
Signal,String), that allows you to disconnect a handler from a given
signal, by signal name.


Cheers
Vreixo


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

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

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

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

Serkan Kaba yazmış:
> org.freedesktop.bindings.ValidateInternationalization
>  - testInitialization()                                               ok
> 
>  - testTranslation()
> failed
> 
> Unit test failed at ValidateInternationalization.java:69,
> "expected:<[Hello]> but was:<[login]>"
> 
> 
> Hi,
> 
> As in above paste the test failed here in Turkish locale. This happens
> because it looks for the Turkish translation and falling back to msgid.
> The tests were supposed to handle the issue by setting the locale to
> English and reverting it at the end but the handling is insufficient. So
> I made a bundle that does the same for LANGUAGE and LANG as well. This
> way the tests pas in Turkish locale.
> 
> So people,especially people with non English locales, can you test if
> i18n tests pass with it.
> 
> Thanks in advance.
> 

Just a follow-up on the issue. Pardus distro includes the following
patch taht prints LANGUAGE env. var. as well. I'll investigate it
further for Gentoo.

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

iEYEARECAAYFAkomzskACgkQRh6X64ivZaI+UwCdEN57Mq1fdCI+2mBhg7I0FRr3
YGEAnjKJ782CKn6F6P/3xF2r73B2iLc2
=5bCN
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Libnotify branch

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

On Tue, 2009-06-02 at 20:25 +0300, Serkan Kaba wrote:
> The branch is now merged to mainline. Thanks to all the people who
> helped in development and testing.

As an aside,

It would be lovely if people using distros other than Gentoo or Debian
could figure out what prerequisite [devel] packages need to be installed
in order to build against libnotify and gtksourceview.

Then we can probe for them in configure and thereby advise people who
don't have those devel packages what they need to install in order to be
able to build java-gnome.

Thanks,

AfC
Sydney

Re: [java-gnome-hackers] Libnotify branch

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

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

The branch is now merged to mainline. Thanks to all the people who
helped in development and testing.

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

iEYEARECAAYFAkolYKEACgkQRh6X64ivZaJfHwCcDUaD24ZqOPhVTzP9k094gSr8
c78AniRW77QbQcN9GahB0EiOo+LVg1TK
=Otoe
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] Compilation error after sourceview merging

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

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

Vreixo Formoso yazmış:
> After  merging sourceview branch, java-gnome failed to compile on my
> system. The reason is that I have not installed the
> libgtksourceview2.0-dev package. Once it is installed, it works ok.
Which distro?
> However, I think ./configure should check that it is installed properly,
> and warn about it if not. Can anybody take care of this? Thanks.
You can add it for your distro and send a bundle.
> Cheers
> Vreixo
- --
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkogrsEACgkQRh6X64ivZaIRagCdHPNErSZ4CbF6zo1Gv4jtU6f2
j88An0WqysBwkCYYFpqIPNpEonzxFEVP
=DFkQ
-----END PGP SIGNATURE-----

[java-gnome-hackers] Compilation error after sourceview merging

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

Hi all,

After  merging sourceview branch, java-gnome failed to compile on my
system. The reason is that I have not installed the
libgtksourceview2.0-dev package. Once it is installed, it works ok.

However, I think ./configure should check that it is installed properly,
and warn about it if not. Can anybody take care of this? Thanks.

Cheers
Vreixo

Re: [java-gnome-hackers] sourceview development branch

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

On Sun, 2009-05-24 at 11:26 +0200, Stefan Schweizer wrote:
> > Yes, a no-arg constructor would be nice. Will have a look at that.
> 
> I just added that constructor. To do that, I added an additional
> constructor to TextBuffer and made TextTagTable.getDefaultTable()
> public. I hope that's OK.

I have long wished that Java had a "library" visibility between public
and package. Oh well.

So what you did worked, but instead I think we'll keep it out of public
by moving getDefaultTable() from TextTagTable to TextBuffer and making
protected there so SourceBuffer can see it.

I've done this; see 'hackers/andrew/sourceview'.

++

I'm going to play with some strongly typed constants a bit, to see if I
can come up with an idiom that doesn't seem too out of control, but
other than that, this branch is acceptable for merging.

AfC
Sydney

Re: [java-gnome-hackers] sourceview development branch

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

On Sat, 2009-05-23 at 17:56 +0200, Stefan Schweizer wrote:
> On Sat, 2009-05-23 at 18:37 +1000, Andrew Cowie wrote:
> > As I was reading through this branch this afternoon, I noticed that
> > you
> > don't have a no-arg SourceBuffer constructor.
> 
> Yes, a no-arg constructor would be nice. Will have a look at that.

I just added that constructor. To do that, I added an additional
constructor to TextBuffer and made TextTagTable.getDefaultTable()
public. I hope that's OK.

Re: [java-gnome-hackers] sourceview development branch

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

On Sat, 2009-05-23 at 18:37 +1000, Andrew Cowie wrote:
> As I was reading through this branch this afternoon, I noticed that
> you
> don't have a no-arg SourceBuffer constructor.

Yes, a no-arg constructor would be nice. Will have a look at that.

> Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
> org.gnome.gtk's PaperSize.A4 and friends.

I am not sure about the constants. GtkSourceView supports 70 languages
or so and they may not always be available because the search path can
be changed. There is a method to do that in LanguageManager (not exposed
yet). This could be useful for special-purpose language files that are
shipped with a java-gnome application.

> Weighing against all of this is "we only diverge the API mapping if
> we've got a good reason to" but avoiding intermediate factory classes
> that don't do anything are in the category of good reason, IMHO.
> 
> Failing all that, it seems like the static method could simply be on
> Language, leaving LanguageManager out of it entirely. Again - if
> there's
> more purpose for that class, fine, but it sure doesn't seem that way.

There are more things in LanguageManager that I did not (yet?) expose:
the already mentioned method to change the search path for language
files and there is a method to guess the language from a given file. So,
I do not think LanguageManager is useless.

	Stefan

Re: [java-gnome-hackers] sourceview development branch

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

On Sat, 2009-05-23 at 15:07 +0300, Serkan Kaba wrote:
> Predefining constants for languages will hinder
> this extensibility.

Only if developers can't create their own constants.

Which is exactly what they *can* do with Stock, Keyval, etc.

AfC
Sydney

Re: [java-gnome-hackers] sourceview development branch

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

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

Andrew Cowie yazmış:
I don't know how common it is but users are always able to add custom
language definitions. Predefining constants for languages will hinder
this extensibility.

> Normally I'm pretty obsessive about strong typing, and the idea of
> strongly-typed Language instances seems fine. Fair bit of work to get
> at, as we've seen. So part of me wonders if we couldn't compress that a
> bit.
> 
> If it wasn't for the fact that I just asserted how important strong type
> safety is, I'd almost be tempted to suggest:
> 
>         buffer.setLanguage("java");
> 
> but... no.
> 
> Hm.
> 
> Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
> org.gnome.gtk's PaperSize.A4 and friends. So have a look at that, have a
> look at the no-arg TextTag() and no-arg TextBuffer() constructors. While
> you're at it, see org.gnome.gtk's Statusbar for an example of where we
> just engineered around something that was silly.
> 
> See if any of these spawn any bright ideas.
> 
> [obviously the risk with preconfigured constants is we don't want to
> force GtkSourceView to load all kinds of stuff if we aren't going to
> need it, and initializing constants has a tendency to do that unless
> you're careful about being lazy]
- --
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoX5xIACgkQRh6X64ivZaIR6wCfUCyU71JNun2ZTshCn3uKKd2c
iccAn2Zu2siqLvdBTi3xrHg5Fw6sR+kX
=POPh
-----END PGP SIGNATURE-----

[java-gnome-hackers] Singleton implementation in java (was Re: sourceview development branch)

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

Hi!

> > > The only thing that really caught my eye so far was
> > > LanguageManager.getDefault(); 
> 
> [...]
> 
> > Another option would be to turn LanguageManager into a real
> singleton [...]. The
> > LanguageManager would then be accessed like this:
> > LanguageManager.getInstance(); that does not remove the static
> method but would make it more explicit that you are using one. Maybe
> that would fit better?
> 
> Nah, not really.
> 

I also hate singleton pattern in the way it is teached (and commonly
used) in Java language. I'm now using an alternative that is much
better, imho: expose instance methods as static. I mean, if you have a
LanguageManager singleton, with a method getLanguage(), as in your
example instead of calling:

LanguageManager.getDefault().getLanguage("java")

you write:

LanguageManager.getLanguage("java")

Internally, LanguageManager keeps a reference of the single instance,
and delegates all methods in that instance. It could be something like
this:

public final class LanguageManager {

    // single instance
    private static final LanguageManager instance = new
LanguageManager();


    // private constructor
    private LanguageManager() {
    }

    // private instance methods
    private XXX getLanguage(String l) {
	....
    }

    // and public static methods...
    public static XXXX getLanguage(String l) {
	//... that delegate on the instance
	return instance.getLanguage(l)
    }

}


In my opinion this creates clear code, but I know everybody is using the
getInstance() traditional approach...

Cheers
Vreixo

Re: [java-gnome-hackers] sourceview development branch

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

On Thu, 2009-05-21 at 10:03 +0200, Stefan Schweizer wrote:
> On Thu, 2009-05-21 at 09:48 +1000, Andrew Cowie wrote:
> > The only thing that really caught my eye so far was
> > LanguageManager.getDefault(); my *personal* taste is that I dislike
> > static functions anywhere other than library initialization.
> 
> Another option would be to turn LanguageManager into a real singleton
> and only call that function when the singleton instance is created. The
> LanguageManager would then be accessed like this:
> LanguageManager.getInstance(); that does not remove the static method
> but would make it more explicit that you are using one. Maybe that would
> fit better?

Nah, not really.

The whole "here's a class which has a factory method which you use to
get the only instance of the class which you then use to lookup an item
in the group that that class manages" thing is fairly common Java and
what I hate so much about most Java libraries. I'm a bit saddened to see
that we're forced to deal with this coming from a GNOME library.

Oh well.

++

As I was reading through this branch this afternoon, I noticed that you
don't have a no-arg SourceBuffer constructor.

So here's something you might look at: punch up TextBuffer and TextTag
have a look at how we able to avoid people having to use TextTagTables
if they don't really feel like it.

Because

        buffer.setLanguage(LanguageManager.getDefault().getLanguage("java"));

is moderately horrid, even when written more clearly as

        manager = LanguageManager.getDefault()
        java = manager.getLanguage("java");
        buffer.setLanguage(java);
        
it still seems a lot of work.

[Admittedly GUI programming is always a lot of work, but nevertheless]

The real question that is bothering me is "would you ever have any
reason to have a LanguageManager other than the default one?" My guess
is no.

So let's see.

Normally I'm pretty obsessive about strong typing, and the idea of
strongly-typed Language instances seems fine. Fair bit of work to get
at, as we've seen. So part of me wonders if we couldn't compress that a
bit.

If it wasn't for the fact that I just asserted how important strong type
safety is, I'd almost be tempted to suggest:

        buffer.setLanguage("java");

but... no.

Hm.

Dare I suggest preconfigured constants, ie Language.JAVA maybe? See
org.gnome.gtk's PaperSize.A4 and friends. So have a look at that, have a
look at the no-arg TextTag() and no-arg TextBuffer() constructors. While
you're at it, see org.gnome.gtk's Statusbar for an example of where we
just engineered around something that was silly.

See if any of these spawn any bright ideas.

[obviously the risk with preconfigured constants is we don't want to
force GtkSourceView to load all kinds of stuff if we aren't going to
need it, and initializing constants has a tendency to do that unless
you're careful about being lazy]

++

Weighing against all of this is "we only diverge the API mapping if
we've got a good reason to" but avoiding intermediate factory classes
that don't do anything are in the category of good reason, IMHO.

Failing all that, it seems like the static method could simply be on
Language, leaving LanguageManager out of it entirely. Again - if there's
more purpose for that class, fine, but it sure doesn't seem that way.

++

Other than this API question, the branch is in *excellent* shape and I
am prepared to accept it into java-gnome. Fantastic work.

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] Motion event and eventmask

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

On Wed, 2009-05-20 at 09:16 +0000, Vreixo Formoso Lopes wrote:
> for example,  to VisibilityNotify signal before adding the widget to a
> parent container, we will get an ugly Gtk-Critical.

There are quite a few things in GTK that don't work if you do them in
the wrong order, and not having a child in a parent comes up quite a
bit.

Maybe we just have to tell people to make sure they pack their child
into a parent before connecting to this signal?

AfC
Sydney

Re: [java-gnome-hackers] Motion event and eventmask

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

Hi,

Attached you can find an improved implementation of enable/disable events.
I've finally implemented the option c), i.e., caching the event mask changed until the Widget is realized.
Please take a look at it.
The patch also includes my previous commit, this way you can compare both solutions, and the original will remain under revision control.
If nobody has any opinion against the idea of exposing event masks in Widget instead of gdk.Window, I'd like to propose this for merging into mainline.

Cheers
Vreixo



----- Mensagem original ----
De: Vreixo Formoso Lopes <met...@ya...>
Para: Java-Gnome Hackers <jav...@li...>
Enviadas: Quarta-feira, 20 de Maio de 2009 11:16:54
Assunto: [java-gnome-hackers] Motion event and eventmask

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


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

Re: [java-gnome-hackers] sourceview development branch

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

On Fri, 2009-05-22 at 23:31 +1000, Andrew Cowie wrote:
> A few of us tried running the Example, but it threw 
> 
> Exception in thread "main" java.lang.NullPointerException
>         at
> sourceview.ExampleEditor.updateButtons(ExampleEditor.java:156)
>         at sourceview.ExampleEditor.<init>(ExampleEditor.java:79)
>         at sourceview.ExampleEditor.main(ExampleEditor.java:186)
> 
> 
> I assume it works for you, so we'll need some help to figure that out.

Sorry! That of course never worked. I just pushed a fix to the
development branch.

	Stefan

Re: [java-gnome-hackers] sourceview development branch

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

On Wed, 2009-05-20 at 22:45 +0200, Stefan Schweizer wrote:

> There is an example editor in sourceview.ExampleEditor.java that
> showcases the exposed features.

A few of us tried running the Example, but it threw 

Exception in thread "main" java.lang.NullPointerException
	at sourceview.ExampleEditor.updateButtons(ExampleEditor.java:156)
	at sourceview.ExampleEditor.<init>(ExampleEditor.java:79)
	at sourceview.ExampleEditor.main(ExampleEditor.java:186)


I assume it works for you, so we'll need some help to figure that out.

AfC
Sydney

Re: [java-gnome-hackers] sourceview development branch

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

On Thu, 2009-05-21 at 09:48 +1000, Andrew Cowie wrote:
> The only thing that really caught my eye so far was
> LanguageManager.getDefault(); my *personal* taste is that I dislike
> static functions anywhere other than library initialization.

Another option would be to turn LanguageManager into a real singleton
and only call that function when the singleton instance is created. The
LanguageManager would then be accessed like this:
LanguageManager.getInstance(); that does not remove the static method
but would make it more explicit that you are using one. Maybe that would
fit better?

Re: [java-gnome-hackers] sourceview development branch

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

On Wed, 2009-05-20 at 22:45 +0200, Stefan Schweizer wrote:
> I made good progress with that branch over the last days and it would be
> nice if somebody could review it in more detail.

I glanced at it early yesterday and I was quite impressed. It already
seems close to being mergeable which is awesome.

The broader question is whether the API being presented is wise. Because
I'm not [needing to] use this personally it's harder for me to say.

The only thing that really caught my eye so far was
LanguageManager.getDefault(); my *personal* taste is that I dislike
static functions anywhere other than library initialization.

        [I find that in the midst of a whole bunch of instance variable
        usage that they seem out of place. This is why a)
        Screen.getDefault() is still quiet and b) various functions are
        exposed as static methods on classes Glib, Gtk, and Glade]

But a function is a function and this probably the best way to expose
it. I welcome anyone to suggest alternative ideas.

Other than that, my first impression is that this looks great. I'll pull
your latest work later today I'll have a proper review then, but we will
definitely feature this in 4.0.12 :)

AfC
Sydney

Re: [java-gnome-hackers] sourceview development branch

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

On Mon, 2009-05-18 at 13:33 +0200, Stefan Schweizer wrote:
> 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!
> 

I made good progress with that branch over the last days and it would be
nice if somebody could review it in more detail.

I focused on SourceView and SourceBuffer and exposed the methods that
seemed useful for me. I did not touch Styles, Marks and some other
things.

There is an example editor in sourceview.ExampleEditor.java that
showcases the exposed features.

	Stefan