java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 16)
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination
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: Guillaume M. <res...@gm...> - 2009-06-25 16:24:49
|
I'm still stuck with another problem now. A NULL value is killing the example when I try to select a completion possibility.
Exception in thread "main" org.gnome.glib.FatalError: GLib-GObject-WARNING
invalid (NULL) pointer instance
at org.gnome.gtk.GtkMain.gtk_main(Native Method)
at org.gnome.gtk.GtkMain.main(GtkMain.java:57)
at org.gnome.gtk.Gtk.main(Gtk.java:95)
at ExampleEntryCompletion.main(ExampleEntryCompletion.java:205)
By the way, just by curiosity, I add a "printf("Key: %s\n", key);" in emit_match() method and I noticed that the signal is emitted (2 * size_of_completion_list). Does someone know why?
The unit-test class is in progress but I do not know how to use the complete() method. I try it also with pygtk and it doesn't seem to work. Did somebody use this method with another GTK library/binding?
2009/6/25 Andrew Cowie <an...@op...>
On Wed, 2009-06-24 at 21:22 +0200, Guillaume Mazoyer wrote:
> I attach a diff
Could you send a patch bundle? [then other people (like me :))] can
merge your branch into their own branches and try and duplicate the
problem — and maybe even contribute a fix.
While you're at it, please make sure to include the unit test that
you're using to exhibit this problem.
++
The type for NULL terminated strings in GLib is G_TYPE_STRING.
++
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function
> ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’:
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76:
> attention : passing argument 2 of
> ‘gtk_entry_completion_set_match_func’ from incompatible pointer type
I'm guessing this is coming from
> + // call function
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
if so, that means that you've got the signature of emit_match() wrong.
It needs to be (*GtkEntryCompletionMatchFunc) which is
gboolean
something(
GtkEntryCompletion *completion,
const gchar *key,
GtkTreeIter *iter,
gpointer user_data)
{
}
and you have
+gboolean
+emit_match
+(
+ GtkEntryCompletion *source,
+ gchar *key,
+ GtkTreeIter *iter,
+ gpointer instance
+)
So I'd guess that the missing const qualifier is the reason you're
getting a warning.
++
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
Why are passing "self" as the user_data parameter?
I'm guessing the answer to that is that copy & paste has bit you. The
comment "note 2" in GtkTreeModelFilterOverride.c does not apply here.
So you probably want:
gtk_entry_completion_set_match_func(self, emit_match, NULL, NULL);
and then I'm guessing:
g_signal_emit_by_name(source, "match", key, iter, &result);
up above in emit_match(). You will note that what you have now has one
more parameter.
g_signal_emit_by_name(GTK_ENTRY_COMPLETION(instance), "match", source, key, iter, &result);
which would most certainly cause things to break if wrong.
++
It's things like this that make you begin to appreciate just how
amazingly helpful a static strongly-typed language like Java is. We Java
developers tend not to think about it. But when I try to do the "same"
stuff in C, and you realize what one had to put up with trying to get
signatures and function call arguments right, I really start to
appreciate java-gnome proxying all this crap for me.
As I said on IRC, you didn't pick an easy one. This is probably the most
complicated hand-written override we have. That said, you are probably
now getting a glimmer of why I'm so insistent in reusing the signal
handling code path - imagine going through this parameter nonsense by
hand every time you want to callback from C to Java. No thanks.
AfC
Sydney
------------------------------------------------------------------------------
_______________________________________________
java-gnome-hackers mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
--
Guillaume Mazoyer (Respawner) - http://www.respawner.fr/
|
|
From: Andrew C. <an...@op...> - 2009-06-25 01:12:12
|
On Wed, 2009-06-24 at 21:22 +0200, Guillaume Mazoyer wrote:
> I attach a diff
Could you send a patch bundle? [then other people (like me :))] can
merge your branch into their own branches and try and duplicate the
problem — and maybe even contribute a fix.
While you're at it, please make sure to include the unit test that
you're using to exhibit this problem.
++
The type for NULL terminated strings in GLib is G_TYPE_STRING.
++
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function
> ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’:
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76:
> attention : passing argument 2 of
> ‘gtk_entry_completion_set_match_func’ from incompatible pointer type
I'm guessing this is coming from
> + // call function
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
if so, that means that you've got the signature of emit_match() wrong.
It needs to be (*GtkEntryCompletionMatchFunc) which is
gboolean
something(
GtkEntryCompletion *completion,
const gchar *key,
GtkTreeIter *iter,
gpointer user_data)
{
}
and you have
+gboolean
+emit_match
+(
+ GtkEntryCompletion *source,
+ gchar *key,
+ GtkTreeIter *iter,
+ gpointer instance
+)
So I'd guess that the missing const qualifier is the reason you're
getting a warning.
++
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
Why are passing "self" as the user_data parameter?
I'm guessing the answer to that is that copy & paste has bit you. The
comment "note 2" in GtkTreeModelFilterOverride.c does not apply here.
So you probably want:
gtk_entry_completion_set_match_func(self, emit_match, NULL, NULL);
and then I'm guessing:
g_signal_emit_by_name(source, "match", key, iter, &result);
up above in emit_match(). You will note that what you have now has one
more parameter.
g_signal_emit_by_name(GTK_ENTRY_COMPLETION(instance), "match", source, key, iter, &result);
which would most certainly cause things to break if wrong.
++
It's things like this that make you begin to appreciate just how
amazingly helpful a static strongly-typed language like Java is. We Java
developers tend not to think about it. But when I try to do the "same"
stuff in C, and you realize what one had to put up with trying to get
signatures and function call arguments right, I really start to
appreciate java-gnome proxying all this crap for me.
As I said on IRC, you didn't pick an easy one. This is probably the most
complicated hand-written override we have. That said, you are probably
now getting a glimmer of why I'm so insistent in reusing the signal
handling code path - imagine going through this parameter nonsense by
hand every time you want to callback from C to Java. No thanks.
AfC
Sydney
|
|
From: Serkan K. <se...@ge...> - 2009-06-24 20:27:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did you try what we have discussed yesterday a) Defining the signal as having 3 params (I suppose iter is starving at the end of the parameter list) b) Dropping the second Entry param in the signal. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpCjAkACgkQRh6X64ivZaKDMACcDeUJnsYodZ/jsLSJWu/bHYvS mHoAn3qvtK+sEpkRLGBcaOfYf07nmgOC =BX24 -----END PGP SIGNATURE----- |
|
From: Guillaume M. <res...@gm...> - 2009-06-24 19:22:37
|
I'm currently working on an implementation of the gtk_entry_completion_set_match_func() function but it still doesn't work. I got a warning during the code compilation and an error about a TreeIter assertion. Here is the compilation warning: GCC src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’: src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76: attention : passing argument 2 of ‘gtk_entry_completion_set_match_func’ from incompatible pointer type And now the error when I try to use the implemented signal and methods: Exception in thread "main" org.gnome.glib.FatalError: Gtk-CRITICAL gtk_list_store_get_value: assertion `VALID_ITER (iter, list_store)' failed It appends when it tries to build the completion list so when the match_func is called. I attach a diff file to make you able to view my change. Maybe someone will find a way to fix the problem. 2009/6/17 Serkan Kaba <se...@ge...> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It was forgotton because the signal was introduced in 2.12 and our defs > file was outdated. > > - -- > Sincerely, > Serkan KABA > Gentoo Developer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAko4YMIACgkQRh6X64ivZaI3sgCfVUx9NJ0U3DBcMCA6OjuUdvh3 > uVIAn0bog7Zc7HQYpgttBJbxFW3StAoo > =C9TQ > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > 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 > -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-06-23 04:59:38
|
On Tue, 2009-06-23 at 06:36 +0300, Serkan Kaba wrote: > Thanks for the review. Here's the new bundle. Made a few cleanups, then merged to 'mainline'. AfC Sydney |
|
From: Andrew C. <an...@op...> - 2009-06-23 04:30:11
|
On Tue, 2009-06-23 at 06:40 +0300, Serkan Kaba wrote: > Andrew Cowie yazmış: > > Fixed in 'website'. > Really is this forgotten to be committed? No, but I didn't have internet access when I wrote it that email [which is better at store & forward that most things] It's been pushed since then. :) Cheers, AfC Sydney |
|
From: Serkan K. <se...@ge...> - 2009-06-23 03:41:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cowie yazmış: > Fixed in 'website'. Really is this forgotten to be committed? - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpATscACgkQRh6X64ivZaJt4wCfQoY4TIlmdDxNhYWlR3shyRv+ BwUAnijlahyGR4eZBW/IPiDSWy3rIULx =jU21 -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-23 03:37:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the review. Here's the new bundle. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpATdYACgkQRh6X64ivZaIwSgCfZsW/QvOrvKxWZ2mtkJUb5SZL RCAAn3wor+DERQQPSMXX2PQlWhfiEjS3 =UvDF -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2009-06-23 01:00:48
|
On Mon, 2009-06-22 at 21:02 +0300, Serkan Kaba wrote: > + jboolean _scale That's the other thing I was going to suggest. :) Go for it! AfC Sydney |
|
From: Andrew C. <an...@op...> - 2009-06-22 23:23:21
|
On Mon, 2009-06-22 at 20:08 +0300, Serkan Kaba wrote: > I suppose the following dependency in README should be libunique Fixed in 'website'. Thanks, AfC Sydney |
|
From: Serkan K. <se...@ge...> - 2009-06-22 18:02:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a more debuggable *hack* Please review it. Thanks, - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko/xy4ACgkQRh6X64ivZaJH+ACePrgVztX4a3XB92o3d8AO5Ywz tRMAnjx6+TOtCkkp14pDJ17Jqu1Try8x =LyGn -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-22 17:08:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suppose the following dependency in README should be libunique * libnotify `>= 1.0.8` - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko/uosACgkQRh6X64ivZaJTzgCfXMOigh3yoJTOS2fp3k7OlE1H iuIAmwStKMVjW2LpTjvDwS9IC9aTOQJR =P5Bj -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2009-06-22 14:33:16
|
This evening I rolled up a 4.0.12-rc2 tarball and uploaded it. Changes include a first try at some release notes. Review, comment, and contribution welcome, as always. People running fringe distros could make a great contribution if they were to grab this release candidate (or update their checkouts of 'mainline') and make sure ./configure correctly detects the needed prerequisites [or suggests an appropriate action if they're not found]. AfC Sydney -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting, Pty Ltd 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...> - 2009-06-21 23:14:51
|
On Sun, 2009-06-21 at 14:42 +0300, Serkan Kaba wrote:
> Actually attaching the bundle.
Serkan and I chatted about this last night on IRC.
Essentially my feedback to him was "yes, duplication is bad, but hacky
attempts to avoid duplication are worse."
So I'll certainly accept this patch.
++
I just looked at gdk_pixbuf_new_from_stream_at_scale() in devhelp, and
noticed that it takes -1 for width and height.
So maybe we can implement both Pixbuf(byte[]) and Pixbuf(byte[], int,
int, boolean) using the same code path, but using
GdkPixbufOverride.createPixbufFromArrayAtScale(data, -1, -1,
false);
for the original method?
I looked at the code in GTK's gdk-pixbuf/gdk-pixbuf-io.c, however, and
I'm not actually sure that's a good idea. The at scale code paths do
considerable extra work that we'd want to avoid.
But I thought I'd mention the possibility for you to think about.
AfC
Sydney
|
|
From: Serkan K. <se...@ge...> - 2009-06-21 11:43:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually attaching the bundle. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko+HKYACgkQRh6X64ivZaJH2ACdG55esL8kxgaLtKg2UDDRIPLe bhIAmwU1TiQiT5t1gmfYMlFnSUKvsv2s =D4Jr -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-21 11:01:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following bundle adds the mentioned cunstroctor but duplicates most (actually only a single line is changed) of the code from the non-scaling version. Can it be added without code duplication, Martin maybe you have an idea since you introduced its coverage. 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 iEYEARECAAYFAko+EtcACgkQRh6X64ivZaJiSACeMKPzlBJOvXHz7+wZoeXj6cji X6QAnRTMBWn4gFQ/qqVHNSE2gfVsQ2Cc =hZId -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-18 03:31:58
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Cowie yazmış:
> [wow. We really blew it on Entry's 'visibility' property. :) I think
> I'll patch that and mark the old one deprecated]
>
> It looks like certain underlying functions that are asking about state
> (as opposed to a "property") — gdk_window_is_viewable(), for example was
> exposed as isViewable() — are exposed with is. Somehow that seems ok.
>
> {shrug}
>
> So, given that your 'visited' is a GObject property, I think I'd
> continue with a getVisited().
This is also a state whether the button was clicked at least once or
not, with one exception it can also be set manually.
- --
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAko5tSQACgkQRh6X64ivZaJKCQCeI88glSaPFHm+wjf31qyxutGk
zRAAmwZDusc1ZHn6MQqppsDNHfKjhvVC
=hbk5
-----END PGP SIGNATURE-----
|
|
From: Andrew C. <an...@op...> - 2009-06-17 23:54:30
|
On Wed, 2009-06-17 at 20:55 +0300, Serkan Kaba wrote:
> 1) Should I use java.net.URI
Yeah, I think so. Early on we chose that path when we did up
FileChooser{,Button}'s getURI(). Seems to have been the right decision.
> 2) should I use isVisisted or getVisisted for the boolean property
> getter. After a find operation in Eclipse I saw that both isProp and
> getProp is used for boolean getters.
We had a good discussion about that a few years ago.
People seemed to feel that having a consistent (and balanced with set)
completion space on get<COMPLETE> was best for discoverability — at
least so far as "properties" (and property like things) are concerned.
So that's mostly what we do.
[wow. We really blew it on Entry's 'visibility' property. :) I think
I'll patch that and mark the old one deprecated]
It looks like certain underlying functions that are asking about state
(as opposed to a "property") — gdk_window_is_viewable(), for example was
exposed as isViewable() — are exposed with is. Somehow that seems ok.
{shrug}
So, given that your 'visited' is a GObject property, I think I'd
continue with a getVisited().
AfC
Sydney
|
|
From: Serkan K. <se...@ge...> - 2009-06-17 17:56:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just pushed a "linkbutton" branch to add covarage for GtkLinkButton. Although the API is small, I have 2 questions before I proceed. 1) Should I use java.net.URI instread of the underlying String representation. This has a tradeoff between using the *real* java equivalent and converting the parameters back and forth between URI and String 2) should I use isVisisted or getVisisted for the boolean property getter. After a find operation in Eclipse I saw that both isProp and getProp is used for boolean getters. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko5Lh0ACgkQRh6X64ivZaI3wACeNq2fyLV5hsGuBH9mNYXvWLtf aXYAn0BHsbJmwwOKV0EwZDbiZUkwWEGA =yiDf -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2009-06-17 05:14:46
|
I had a bit of fun yesterday and hacked up preliminary coverage for
LibUnique — something I've wanted to do for a while.
Some basic scenarios were easy to explore with unit tests and that's
where I started; it gets harder to test actual inter-process
communication [I didn't really want to fire off other Processes].
Meanwhile I did up a trivial example, and it works:
* an initial instance figures out that it is indeed the first
* a second instance can find out that another is running.
* you can even send messages from a second instance to the unique
one.
so I'd have to say it "works".
Branch is at
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/unique/
++
But it is easy to misuse, it seems.
Back to the unit tests, I tried to see how far I could push matters I
uncovered some strange crashes and/or hangs. So there may be limitations
like "once you've become a unique app you can't talk to other unique
apps" or "can't talk to yourself". Dunno.
The test that I couldn't make work is below. It probably encapsulates
several mistaken assumptions. I have a feeling that once a process is
bound to LibUnique under a given name, that's it, it cannot bind to
another.
It'd be nice to get some clarity here to clean up the docs - otherwise
it's too easy to misuse, and meanwhile it's a bit difficult to construct
a unit test about message payload passing.
AfC
Sydney
|
|
From: Serkan K. <se...@ge...> - 2009-06-17 03:19:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It was forgotton because the signal was introduced in 2.12 and our defs file was outdated. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko4YMIACgkQRh6X64ivZaI3sgCfVUx9NJ0U3DBcMCA6OjuUdvh3 uVIAn0bog7Zc7HQYpgttBJbxFW3StAoo =C9TQ -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-16 17:43:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more issue I found out, the example doesn't terminate upon closure. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko32a4ACgkQRh6X64ivZaKx4QCcDfCwOH44Wa/4WI191BY4W4G8 wYgAn1UCoJ29LdV+kOgaqutyJmEcp9Z0 =dAIt -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-16 17:37:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First of all, I should say that this is *great* work. gtk_entry_completion_set_match_func can be implemented with custom signal just as gtk_tree_model_filter_set_visible_func is implemented. You can examine TreeModelFilter and GtkTreeModelFilterOverride to see how its implemented. Handler for cursor-on-match is also missing, I think you know how to handle the TreeIter by now, so that can also be covered for completeness. By the way the example works on the whole content of the entry. Is it possible to hint for multiple words breaking the text with whitespece characters? - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko32FsACgkQRh6X64ivZaIKFgCdEFCggjgPJ+9tw+B2hNKnrDBD Y2oAnRutpB9S3fa++JmHxBKnACwWmYr3 =fJgw -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2009-06-16 03:12:27
|
Now that GTK 2.16 is starting to be available, someone with it installed might want to take a pass at making sure we can successfully build against a GTK without deprecated symbols, and removing such unnecessary things from java-gnome's .defs data. Try running: $ ./configure strict $ make clean $ make and see how far you can get. I got things started as with previous cycles. This time my branch is called 'deprecated-2.16' and is at: bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/deprecated-2.16/ I got stuck at gtk_action_connect_proxy(). I think someone will need to: a) add an interface Activatable b) implement it in Button etc, c) then figure out some wrapper code to put in Action's connectProxy() that calls the new implementation instead. d) mark that .defs block (deprecated) and that Java method @deprecated. which shouldn't be too difficult. It's just tedious work, really. Once you clear that, move on to the next one... but send us a bundle or a branch URL so others don't try to fix them too! :) ++ Merging this branch to 'mainline' will push us to requiring >= gtk +-2.16; maybe we'll do that during 4.0.13-dev? I think that'd be ok. 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...> - 2009-06-16 02:56:55
|
Guillaume sent me an large piece of work going a long way to exposing EntryCompletion for us. I gave it a first pass and found it surprisingly meaty. I haven't done a detailed review the API being presented, per se, but what I saw looked reasonable. Other experienced java-gnome hackers might care to offer their views. My branch from his work is at bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/entry-completion/ I've used EntryCompletion from pygtk, so this weekend I'll try porting that example to java-gnome and see how it goes. AfC Sydney |
34 messages has been excluded from this view by a project administrator.
