java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 6)
Brought to you by:
afcowie
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(102) |
Sep
(43) |
Oct
(32) |
Nov
(43) |
Dec
(51) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(6) |
Feb
(19) |
Mar
(39) |
Apr
(22) |
May
|
Jun
(11) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(73) |
2004 |
Jan
(88) |
Feb
(141) |
Mar
(116) |
Apr
(69) |
May
(199) |
Jun
(53) |
Jul
(90) |
Aug
(23) |
Sep
(11) |
Oct
(212) |
Nov
(57) |
Dec
(61) |
2005 |
Jan
(88) |
Feb
(17) |
Mar
(21) |
Apr
(50) |
May
(44) |
Jun
(33) |
Jul
(21) |
Aug
(37) |
Sep
(39) |
Oct
(43) |
Nov
(40) |
Dec
(15) |
2006 |
Jan
(21) |
Feb
(69) |
Mar
(23) |
Apr
(6) |
May
(29) |
Jun
(19) |
Jul
(17) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(9) |
Dec
(7) |
2007 |
Jan
(30) |
Feb
(39) |
Mar
(1) |
Apr
(12) |
May
(53) |
Jun
(30) |
Jul
(39) |
Aug
(75) |
Sep
(16) |
Oct
(13) |
Nov
(20) |
Dec
(5) |
2008 |
Jan
(8) |
Feb
(14) |
Mar
(33) |
Apr
(7) |
May
(22) |
Jun
(23) |
Jul
(17) |
Aug
(9) |
Sep
(9) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
2009 |
Jan
(20) |
Feb
(38) |
Mar
(9) |
Apr
(15) |
May
(30) |
Jun
(35) |
Jul
(22) |
Aug
(10) |
Sep
(7) |
Oct
(23) |
Nov
(6) |
Dec
(8) |
2010 |
Jan
(5) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(15) |
Sep
(14) |
Oct
(26) |
Nov
(11) |
Dec
(14) |
2011 |
Jan
(10) |
Feb
(8) |
Mar
(6) |
Apr
(7) |
May
(18) |
Jun
(17) |
Jul
(6) |
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(10) |
2012 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(5) |
Aug
(14) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andrew C. <an...@op...> - 2011-04-05 05:17:30
|
Serkan, I've made good progress on '4.1' The problem you hit with all those classes not compiling was due to a number of other types specifying GtkObject as their parent, or extending org.gnome.gtk.Object on the Java side. That's all sorted now. I made it as far as GtkStyle and then had to stop. Not that GTK 3's styling mechanism is much different but as we didn't have coverage of it in '4.0' we probably don't have much to worry about. AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-03-31 08:12:15
|
2011/3/31 Andrew Cowie <an...@op...>: > I will switch 'mainline' to being '4.1' within a month, once people > running Gentoo, Fedora, and Ubuntu Linux have access to GTK 3.0 packages > (ie when Ubuntu Natty is out). Then we'll have a '4.0' branch around in > case we need it. I'll speak with our Gnome devs to learn the Gentoo schedule for that. I also have a question about reverse dependencies. As long as they stick with non-depracated and already existing API they can work with both series. So what's your plan for example about slashtime. Do you plan to allow depending on both series? Sincerely, Serkan |
From: Andrew C. <an...@op...> - 2011-03-30 21:21:22
|
I've talked about this with most people on IRC, but to summarize: We've been saving an API break called "4.1" for a while. We'll use it to handle GTK 3.0 and GNOME 3. So, in hindsight, "java-gnome 4.0 was the series that works against GTK 2.x" As GTK 3.0 is an ABI and API incompatible change (not to mention things like libnotify) we will use the API break that we have been saving, "java-gnome 4.1 will be series that works against GTK 3.x" Work is currently going on in a '4.1' branch. Fedora needs a 4.1 release within a month because they don't have older stack present. It'd be nice to release a 4.0.20 with everything marked @deprecated that needs to be, but I don't want to see us block on that. The biggest changes have to do with drawing in Widget.Draw rather than Widget.ExposeEvent, and the height for width changes to request / allocation, so we'll make sure we mark the methods and interfaces that are affected there. Finally, I don't really expect us to sustain both in parallel. We will of course backport security fixes. Our 'mainline' is a 4.0.z branch right now, calls itselv 4.0.20-dev. There is a '4.1' branch, calls itself 4.1.1-dev. I will switch 'mainline' to being '4.1' within a month, once people running Gentoo, Fedora, and Ubuntu Linux have access to GTK 3.0 packages (ie when Ubuntu Natty is out). Then we'll have a '4.0' branch around in case we need it. 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 |
From: Andrew C. <an...@op...> - 2011-03-14 00:34:20
|
On Sun, 2011-03-13 at 18:51 +0100, Guillaume Mazoyer wrote: > > Here's a bzr bundle : > > > This bundle looks good for me Thanks Guillaume. Merged to 'mainline' AfC Sydney |
From: Guillaume M. <res...@gm...> - 2011-03-13 17:52:08
|
Hi, > Here's a bzr bundle instead: > > http://mbooth.fedorapeople.org/configure-script-fixmes.patch This bundle looks good for me, I guess it can be merged in 'mainline'. > I hope that's the correct format, I'm not an experienced bazaar user. Yes it is. It is the prefered format when you submit a patch here. ;) Good work. -- Guillaume Mazoyer - http://www.respawner.fr/ |
From: Mat B. <mb...@fe...> - 2011-03-13 13:04:36
|
On 13 March 2011 12:32, Mat Booth <mb...@fe...> wrote: > Hi all, > > When I was attempting to build java-gnome for Fedora, I took the > liberty of correcting a few "FIXME"s in the configure script. > > This patch was done against java-gnome 4.0.19: > > http://mbooth.fedorapeople.org/java-gnome-configure-fedora-fixmes.patch > > Regards, > Mat > Here's a bzr bundle instead: http://mbooth.fedorapeople.org/configure-script-fixmes.patch I hope that's the correct format, I'm not an experienced bazaar user. Regards Mat -- Mat Booth http://fedoraproject.org/get-fedora |
From: Mat B. <mb...@fe...> - 2011-03-13 12:32:46
|
Hi all, When I was attempting to build java-gnome for Fedora, I took the liberty of correcting a few "FIXME"s in the configure script. This patch was done against java-gnome 4.0.19: http://mbooth.fedorapeople.org/java-gnome-configure-fedora-fixmes.patch Regards, Mat -- Mat Booth http://fedoraproject.org/get-fedora |
From: Serkan K. <se...@ge...> - 2011-02-26 09:14:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I already expressed my feeling about the flaw in this particular test before. The test assumes that the user's home directory contains the user name in the path name. I did say that this might not be the case in the real system as well, but this assumption doesn't work with portage either. Portage sets $HOME to somewhere under $PORTAGE_TMPDIR and this test fails. I don't know if we should be removing this or come up with a better test for reading env. var's. Any suggestions? - -- Sincerely, Serkan KABA Gentoo Developer Java/GNOME Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1oxE4ACgkQRh6X64ivZaIARQCfdGujaVJM60YxGEG/erZIuCwh WZEAniDbmdnvBkPL4ifD5vcXcjFce0xG =A4tu -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-02-19 08:28:52
|
On Fri, 2011-02-18 at 04:35 +0200, Serkan Kaba wrote: > Need to set that CFLAGS, I would avoid any forced optimizations in our > build file other than using CFLAGS provided. CFLAGS, if set in a Makefile and also in users environment is overridden by environment, right? Well, it is if you do this: ifndef CFLAGS CFLAGS=-O2 endif So we could have sensible intelligent defaults...? AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-02-18 02:35:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-02-2011 04:14, Andrew Cowie wrote: > Does anyone know why we aren't passing -O2 to gcc when we build > java-gnome'c C files? Need to set that CFLAGS, I would avoid any forced optimizations in our build file other than using CFLAGS provided. - -- Sincerely, Serkan KABA Java/GNOME Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1d2uQACgkQRh6X64ivZaIX5ACcDR8RzjYD9O0EFrZMbs7xmI+4 uvcAn3vxmc05qNA7s1suxxlvrh6BG2Yw =zOqz -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-02-18 02:15:01
|
Does anyone know why we aren't passing -O2 to gcc when we build java-gnome'c C files? worthil ~/workspace/java-gnome $ V=1 make build/faster GCC generated/bindings/org/gnome/gtk/GtkButton.c /usr/bin/gcc-4.4 -g -Wall -fPIC -I/usr/lib/jvm/java-6-openjdk/include -I/usr/lib/jvm/java-6-openjdk/include/linux -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast -Werror-implicit-function-declaration -Wfatal-errors -Isrc/jni -Itmp/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0 -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -I/usr/include/gtksourceview-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/gtkspell-2.0 -I/usr/include/unique-1.0 -I/usr/include/enchant -I/usr/include/librsvg-2.0 -o tmp/objects/org/gnome/gtk/GtkButton.o -c generated/bindings/org/gnome/gtk/GtkButton.c worthil ~/workspace/java-gnome $ We've got -g, should that be -ggdb -O2 instead? AfC Sydney |
From: Andrew C. <an...@op...> - 2011-02-14 06:53:09
|
The 'mainline' branch now identifies itself as 4.0.20-dev, though with any luck the next release will be 4.1.1. Cheers, AfC Sydney |
From: Andrew C. <an...@op...> - 2011-02-10 04:07:26
|
On Fri, 2011-01-21 at 13:33 +1100, Andrew Cowie wrote: > I've done preliminary coverage of Pango's Font object. I've merged this to 'mainline'. > I did a test, ValidatePangoFont, but it's not good enough. I added the test, but not to the UnitTests suite, as it depends on all kinds of fonts being installed. On Debian it's: ttf-dejavu ttf-libertion ttf-mscorefonts-installer ttf-adf-gillius > Maybe someone could have a try $ java -client -ea -Djava.awt.headless=true -classpath tmp/gtk-4.0.jar:tmp/generator/:tmp/tests/:/usr/share/java/junit.jar com.operationaldynamics.junit.VerboseTestRunner org.gnome.pango.ValidatePangoFonts will run the test case. I'm *really* open to suggestions of how this could be done better. AfC Sydney |
From: Andrew C. <an...@op...> - 2011-02-10 03:42:04
|
On Wed, 2011-01-19 at 12:55 +1100, Andrew Cowie wrote: > I've heard rumours that GtkEditable is going away (that, or it got > strengthened and actually used - anyone know?) I talked to Tristan and Editable hasn't gone away. Fine. > when clearly it should just be: > > entry.connect(new Entry.Changed() { > public void onChanged(Entry source) { > source.doSomething(); > } > }); > I am going to add Entry's connect(Entry.Changed) with that signature on the '4.1' branch. That won't break if you were using connect(Editable.Changed), otherwise you'll be able to drop the cast. AfC Sydney > Not the sort of thing we could mess with unless we had a real ABI break > coming, but we do. This is on my list if its actually possible. > Comments? I'm sure you've got things you want to fix too :) > > AfC > Sydney > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers -- 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 |
From: Andrew C. <an...@op...> - 2011-02-10 03:35:31
|
Hey, We'll be doing 4.0.19 shortly so we can get in the next 6 month cycle horizon. If anyone has build fixes or API contributions they wish to make, then please reply here ASAP. AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-01-31 18:07:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-11-2010 16:56, Alexander Boström wrote: > lör 2010-10-30 klockan 19:55 +0200 skrev Andrew Cowie: >> Just a passing comment: as major API changes are happening in GTK >> towards 3.0, useful mailing lists to be subscribed to are: > > Yup, this already happened with the Fedora package in rawhide (the > future F15 release) as libnotify was updated to 0.7.0 and java-gnome > won't build with that. (So I need a snapshot, rc or release which does.) > > Possibly I can provide a patch myself, as the changes seem rather > trivial but it needs to be done in a way that'll still work with older > libnotify releases. > > Is it ok to change the API exposed to the Java side? IIRC java-gnome > isn't declare API stable but it'd be weird to have different APIs > depending on which libnotify version it was compiled with. > > I guess the simplest solution is to change the API for all java-gnome > users regardless of which libnotify it was compiled with... > > >> From: Matthias Clasen <mc...@re...> >> Datum: Mon, 01 Nov 2010 21:12:47 -0400 > >> Here is an overview of the api changes: >> >> notify_notification_new_with_status_icon is gone >> notify_notification_attach_to_status_icon is gone >> notify_notification_attach_to_widget is gone >> notify_notification_set_geometry_hints is gone >> notify_notification_new has lost its widget argument >> >> A typical patch will look like this one: >> https://bugzilla.gnome.org/review?bug=632327&attachment=172525 >> >> For some background on these changes, see >> http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility > > > /Alexander I'm attaching a patch that can be applied to v4.0.18 to nuke all these methods. I'll keep this branch as "to be merged later" (probably until mainline distros have it in their stable versions). Samuli will be testing it for Gentoo (And applying the patch based on libnotify version being linked against). I remember Guillaume hitting the same issue with Debian/Ubuntu packaging in unstable/experimental branch. - -- Sincerely, Serkan KABA Gentoo Developer Java/GNOME Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1G+mIACgkQRh6X64ivZaL8fACeNCkTJB3PJOpIX15M0HRYhFk5 zJcAnRuGGjOP9VJgUY8y5XjnreopgFTa =9kjq -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-01-21 02:33:58
|
I've done preliminary coverage of Pango's Font object. This has a describe() method which allows you to find out information about what font was actually loaded. You get a Font from Context's loadFont(). Thanks to Behdad for his guidance on this one. I did a test, ValidatePangoFont, but it's not good enough. I'm not sure how to articulate a test case for this that doesn't depend on things like the user's desktop font selections and what fonts are installed on the system. Maybe someone could have a try & a think about this. My branch is at: bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/pango-font 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 |
From: Serkan K. <se...@ge...> - 2011-01-19 17:31:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17-01-2011 10:51, Serkan Kaba wrote: > I want to explain the roadmap for libnotify 0.7.0 support here. > > As discussed in release planning thread, 4.0 series will stick with > gtk+/gnome 2. Since libnotify-0.7 depends on gtk3, >=libnotify-0.7.0 > work will be done in 4.1 series, where all gtk3 work is done. Carefully examining configure.ac I see that only tests depend on gtk3 and libnotify 0.7.x depends on >=glib-2.26, is it possible to support glib-2.26 in gtk2 branch? If so I may reconsider removal when gtk2 branch is bumped to glib-2.26 Sorry for misinforming you guys. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk03H9oACgkQRh6X64ivZaIWEgCeJ4cIBvMgvl4CeMpOAUklQ/xb ChMAn1WzaEaQ7a5kase1rYklOSj91YjM =mjZy -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-01-19 04:31:13
|
I've heard rumours that GtkEditable is going away (that, or it got strengthened and actually used - anyone know?) If it's going away that would make me happy; I am getting a little tired of the following entry.connect(new Entry.Changed() { public void onChanged(Editable editable) { final Entry source; source = (Entry) editable; source.doSomething(); } }); entry.connect(new Entry.Activate() { public void onActivate(Entry source) { source.doSomething(); } }; when clearly it should just be: entry.connect(new Entry.Changed() { public void onChanged(Entry source) { source.doSomething(); } }); entry.connect(new Entry.Activate() { public void onActivate(Entry source) { source.doSomething(); } }; Not the sort of thing we could mess with unless we had a real ABI break coming, but we do. This is on my list if its actually possible. Comments? I'm sure you've got things you want to fix too :) AfC Sydney -- Andrew Frederick Cowie | Consulting Engineer | Operational Dynamics ☏ +61 4 1079 6725 | ✍ +1 646 472 5054 | ♖ http://www.operationaldynamics.com |
From: Serkan K. <se...@ge...> - 2011-01-17 16:44:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I forgot to deprecate one method. Here's another bundle that deprecated the last missing method. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk00cfwACgkQRh6X64ivZaJdyQCfZWPF0AryTbWMWUVkeV0agtHV ZPMAnR1ByWV/bcvbKJclzsFeSNWMuVXI =rpOl -----END PGP SIGNATURE----- |
From: Serkan K. <se...@ge...> - 2011-01-17 08:51:43
|
I want to explain the roadmap for libnotify 0.7.0 support here. As discussed in release planning thread, 4.0 series will stick with gtk+/gnome 2. Since libnotify-0.7 depends on gtk3, >=libnotify-0.7.0 work will be done in 4.1 series, where all gtk3 work is done. Regards, Serkan |
From: Andrew C. <an...@op...> - 2011-01-17 00:15:44
|
Serkan, Guillaume, and I had a useful discussion on #java-gnome today. Minus a lot of figuring out that we were all agreeing with each other, it ends up pretty simple: java-gnome 4.0.x will continue to be the stable series; it will depends on (build against) GTK 2.x and other GNOME 2.x libraries. java-gnome 4.1.x will be a new series that will depend on (build against) GTK 3.0 and other newly appearing GNOME 3.0 libraries. We've already been moving in this direction, of course; there is a series of 'deprecated-java' branches that call themselves "4.1" now that Kenneth and I have been working on called where we have made sure that java-gnome builds against the latest GTK etc with GTK_DISABLE_DEPRECATED etc defined. Since most people can't even begin to think about working on GTK 3 coverage until it's actually on their stable systems, it'll be a while before 'deprecated-java' bumps to gtk >= 3.0. As a matter of principle, java-gnome already does not depend on deprecated things from the underlying libraries. As things turn up in GTK 2.24 and other libraries marked for removal then we'll give them @deprecated tags in eg 4.0.19, but java-gnome 4.1 will be an API break since things like drawing in expose events has changed. Anyway, it's all fairly straight forward. I was thinking the website could do with a bit of love. Maybe just drop the "4.0" bit entirely, or move it to doc/api/4.0/ along the lines that library.gnome.org does things. AfC Sydney |
From: Andrew C. <an...@op...> - 2011-01-17 00:07:12
|
On Sun, 2011-01-16 at 22:09 +0200, Serkan Kaba wrote: > I'm attaching a patch that deprecates methods that will be removed when > we link against 0.7.0 and check that libnotify < 0.7.0 exists. Merged to 'mainline' AfC Sydney |
From: Serkan K. <se...@ge...> - 2011-01-16 20:09:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17-11-2010 07:36, Serkan Kaba wrote: > As immediate intervation we should restrict libnotify version in our > configure script to < 0.7.0 and deprecate the removed methods. Then I > may introduce a branch that does the opposite and removes the > deprecated methods. I'm attaching a patch that deprecates methods that will be removed when we link against 0.7.0 and check that libnotify < 0.7.0 exists. Guillaume will be working on libnotify-0.7.0 branch for Debian packaging (Debian unstable has libnotify 0.7.0) But as 0.7.0 is breaking a lot of reverse dependencies, it will take time for it to go mainstream. So this branch will stay experimental for some time and won't be merged to mainline until libnotify 0.7.0 is mainstream. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0zUH4ACgkQRh6X64ivZaIGFwCfd3ke6ASK+Ya2JMbD5NoFTCTV AOAAnj8DabByDt7ZaXW7sxqmjSNQN43K =PAhq -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2011-01-16 09:33:46
|
Has anyone seen this? org.gnome.glib.FatalError: (null)-CRITICAL enchant_is_all_caps: assertion `word && *word' failed at org.freedesktop.enchant.EnchantDict.enchant_dict_suggest(Native Method) at org.freedesktop.enchant.EnchantDict.suggest(EnchantDict.java:82) at org.freedesktop.enchant.Dictionary.suggest(Dictionary.java:110) Sounds like we're doing something rather wrong. It might be related to the fact we've got to pass in an out-parameter array of Strings? The generated code looks ok, though :( For me the word "ISP" is triggering it, but of course writing a test case suggest()ing on that word doesn't crash. {sigh} Anyone have any ideas? AfC Sydney |