java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 28)
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: Vreixo F. L. <met...@ya...> - 2008-02-29 10:37:57
|
--- Andrew Cowie <an...@op...>
escreveu:
> For a while now you've been interested in GTK 2.12,
> so if I could offer
> a suggestion I'd like to encourage you to work out
> what .defs data is
> needed to finish bringing us up to GTK 2.12.
Yes, good idea. I will put my efforts on it.
> All that said, there aren't that many 2.12 / 2.13
> features that I'm
> bursting to add coverage for. We've already got
> FileChooser's FILE_SET
> signal in use and a wrapper in Widget representing
> the new Tooltips API,
> but I'm sure there are other things that you might
> think important. In
> any case, what coverage we expose is a separate set
> of decisions and
> largely dependant on what people wish to contribute.
Sure. But anyway all new features should be present in
our .defs data, we would then choose what features
actually expose.
Cheers,
Vreixo
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/
|
|
From: Andrew C. <an...@op...> - 2008-02-29 09:56:25
|
Vreixo, On IRC the other night you asked what directions we were going in and you might contribute to. For a while now you've been interested in GTK 2.12, so if I could offer a suggestion I'd like to encourage you to work out what .defs data is needed to finish bringing us up to GTK 2.12. I placed the tag 'pygtk' when we irrevocably branched from their data stream. If you branch from there and use the import tools we developed, you should be able to merge their changes. AYou can use h2defs.py etc instead and manually create the new data, but I'd recommend working from the upstream data we started from in the first place. All that said, there aren't that many 2.12 / 2.13 features that I'm bursting to add coverage for. We've already got FileChooser's FILE_SET signal in use and a wrapper in Widget representing the new Tooltips API, but I'm sure there are other things that you might think important. In any case, what coverage we expose is a separate set of decisions and largely dependant on what people wish to contribute. Just a suggestion. Cheers, AfC Sydney |
|
From: Bruno D. <bdu...@be...> - 2008-02-25 09:54:12
|
On Mon, 25 Feb 2008 15:29:28 +1100 Andrew Cowie <an...@op...> wrote: > Hey Manu, > > On Thu, 2008-02-21 at 12:47 +0530, Manu Mahajan wrote: [...] > > Packaging is tough. A lot tougher than most people give it credit for. > I'm pleased to hear you making progress. > Yes, it's tough, especially in domain like Java when you have this "alternatives" system. > > Next, I will try and create a chroot environment and test it if all > > the dependencies are resolved... > > Isn't that what "pbuilder" is for? I haven't run Debian in about 6 > years, but some of my partners do packaging for Debian and have > mentioned it. Might want to ask around about it. > Yes, indeed, that's why pbuilder is for. http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#introduction > AfC > Sydney > -- Bruno Dusausoy |
|
From: Andrew C. <an...@op...> - 2008-02-25 05:42:12
|
On Mon, 2008-02-18 at 16:28 +0100, Bruno Dusausoy wrote: > Since I'd like to participate - even a little - to Java-Gnome > development, I had the idea of converting the Gtk+ tutorial into Java, No one can tell you "no" in the Open Source world. If you want to go to the effort of doing that, go ahead. I do want to suggest you do otherwise, however, so I've written at some length my thoughts on this topic. ++ My personal view is that the original GTK tutorial is not very well written. I do recall that I didn't find it any help whatsoever when I was originally trying to learn GNOME programming, which further sours my opinion of it. That doesn't mean that the people who wrote it so long ago didn't work hard on it - just that I didn't find it worked for me. Tutorials are hard to write because you have to put yourself in the position of the person learning for the first time, figuring out what they DO know (their context), what they need to know, how to explain it to them, and how to get them to the point where they can take over learning for themselves. Have a careful read of the definition of "approachability" at http://java-gnome.sourceforge.net/4.0/objectives.php and in the original discussion of audience in the doc/design/ documents you'll see what I mean. > just like PyGtk did. Rather than just complaining, one should note alternatives. Here are two things to think about: 1) the Cairo tutorial is *FANTASTIC*. For one thing it was written with translation into other [computer] languages [binding Cairo] in mind. More importantly, it's *well written* and interesting. Even if you have no interest in drawing things, go read it. It's really well presented. So are their "samples" which is the calibre level I've aimed for in our doc/examples/ section, though we've still a ways to go. [Incidentally, a really excellent conversion project for someone would be translating the Cairo tutorial document, using it as a guideline to inspire them to get on with exposing what needs exposing in java-gnome] 2) The other stylistic source would be the "Writing Really Rad GNOME Applications in GTK using C, Java, and Python" tutorial presentation that Davyd Madeley and I wrote give fairly regularly. Since I have explained GTK fundamentals to people on numerous occasions, I have fairly strong ideas about what needs to be covered and how to go about it. I've started converting that to written form, but frankly, giving that talk at conferences is more fun. [And frankly, the topic needs treatment at book length. As it happens, I've already started down that road, which is why I've been spending so much effort on publishing toolchains lately] That doesn't mean that you can't work on something of your own. But if you haven't got a fair bit of experience a) explaining what defines the GNOME Desktop, b) teaching people how to use GTK, and c) detailed knowledge of how java-gnome works these days, then I would recommend holding off and instead concentrate on working on applications of your own [or working with someone like me on one of mine :) :)] and then helping others get going with our bindings of GNOME so as to gain that experience. > So, my question(s) is(are) : Does this kind of project already exist ? > Is there a argument against this idea (API changes or whatever blocker > may be) ? No, just the stylistic issues I have observed above. I don't think that the GTK tutorial which was written 8-10 years ago is very well done, and so personally am not than impressed by the idea of converting it. Most importantly, the material there is dated, and doesn't really talk about what it takes to make a good GNOME application, and that's the most important part. ++ Thinking back to approachability, it's possible that a better approach than converting that monster book might be to make (much) shorter tutorials targeting more specific audiences. For instance, (and I'm just brainstorming here): - Considerations involved in switching to GNOME programming if you've been using Swing - Considerations involved in switching to GNOME programming if you've been using SWT [I have no interest myself in writing such a document, but it basically boils down to the tasks of teaching them to let go of the bad habits the limitations of those toolkits might have forced them to pick up. More importantly, GNOME is a different approach to human machine interface, and so the real challenge is to help people let go of the insane compulsion to micromanage layout design and instead to embrace the malleable user interfaces that result from embracing our approach to these things, rather than fighting against it] - Notes on using GTK in Java for those used to writing GTK applications in C [as I've observed elsewhere, such people are wizards. The challenge here is partially to explain how to do reasonably good Java programming (because they probably don't know, for example, the layering and structure patterns that pay off in Java), and how the conventions that they might have taken to be part of GTK (which aren't, they're just what you do in C 'cause you're in C) have translated to Java. All in all it's another case of "letting go"] As you can see, both these cases have very different audiences, but in each certain things can be taken for granted.(ie, in these cases, people already have some idea about how event driven programming works). If someone is going to work on a document along the above lines, by all means, and I invite people to have some fun pointing out how things work and how they're not a pain in the ass like they are elsewhere :). There is not holy writ saying that Java is better. Far from it. Unless you are already quite proficient in IDE toolchains and in how we do things, then something like pygtk is an order of magnitude "easier" at the start. I can (and frequently do) construct an argument about why Java is a sound choice for projects which are going to scale into the hunderds of thousands of lines of code, but frankly, unless someone is already been down that road, they're not going to listen. Most of all, I have no interest whatsoever in tit-for-tat evangelism. We have made everything in java-gnome the way it is for a reason. In cases where you are attempting to "convert" someone, then we have to drag ourselves through the morass of people whining about "why is it like this" or "why isn't it like that". The answer is "because this is the design we arrived at after 22 months of careful research and engineering (in the case of the 4.0.x series) or, in some cases, greater than 10 years (in the case of the project as a whole) of work, and so that's the way it is". Which is why "convert" is really the wrong word. If someone is giving the library a try and needs a nudge in the right direction, by all means. But you don't want to get sucked into an defencive argument online about "why yours is better", and I want to make sure a similarly defencive tone doesn't make it into any documentation (tutorial or otherwise) we add to the project. It doesn't do anyone any good. So have fun, be precocious, but above all be knowledgeable and positive. ++ As a final thought, I will make the following observation about our API documentation. It's has been winning an unbelievable amount of praise from people. The GNOME hackers in the room last year at GUADEC last year were *stunned* when I showed the quality of documentation that results from the particular style of JavaDoc that I have enforced. I have described it from the beginning as "tutorial style" and in most places it is just that. While that is not a substitute for whatever is ultimately going to live in doc/tutorial/, our API docs are already a good source of tutorial information about _how_ to use java-gnome, and so anyone with an urge to contribute and who has knowledge with the underlying GNOME libraries is more than welcome to do so by offering patches to improve the JavaDoc further. ... if you ever have a question about how to use something, and the help hovering over your cursor in a tooltip doesn't explain it, then the bug isn't fixed until the JavaDoc *does* explain it. That's a wonderful place to contribute. bzr branch, baby. AfC Sydney P.S. Anyone who read this far wins a hero biscuit! -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting, Pty Ltd Sydney +61 2 9977 6866 New York +1 646 472 5054 Toronto +1 647 477 5603 London +44 207 1019201 We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ |
|
From: Andrew C. <an...@op...> - 2008-02-25 05:42:08
|
Hey Manu, On Thu, 2008-02-21 at 12:47 +0530, Manu Mahajan wrote: > Last night I was successfully able to create a test package. I > need to test it now and hopefully get it reviewed by someone who > [knows what they're doing] > That's tougher than it seems - lots of people will wave their hands and say "oh, making debs is easy" without having had to deal with the intricacies of making something _new_ and which corresponds to [in this case, Debian's] Policy. On Mon, 2008-02-25 at 01:43 +0530, Manu Mahajan wrote: > The package was not installing correctly so I spent some time debugging > that. And the good thing is that it finally seems to be working now. Packaging is tough. A lot tougher than most people give it credit for. I'm pleased to hear you making progress. > Next, I will try and create a chroot environment and test it if all the > dependencies are resolved... Isn't that what "pbuilder" is for? I haven't run Debian in about 6 years, but some of my partners do packaging for Debian and have mentioned it. Might want to ask around about 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. 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 |
|
From: Andrew C. <ca...@re...> - 2008-02-22 18:22:38
|
FYI, I've created a maintenance only branch for the gj2 libgtk-java bindings; it is for occasional critical fixes such as memory smashes. This lets us [frysk] and various distros such as Fedora more easily share our back ported fixes. We're also looking forward to the opportunity to finally upgrade our Frysk bindings. Andrew |
|
From: Bruno D. <bdu...@be...> - 2008-02-18 15:27:09
|
Hi all, I don't know if this is the right list to ask to; if it's the case, please tell me nicely ;) Since I'd like to participate - even a little - to Java-Gnome development, I had the idea of converting the Gtk+ tutorial into Java, just like PyGtk did. So, my question(s) is(are) : Does this kind of project already exist ? Is there a argument against this idea (API changes or whatever blocker may be) ? Regards. -- Bruno Dusausoy <bdu...@be...> thx1138 on FreeNode |
|
From: Andrew C. <an...@op...> - 2008-02-12 10:34:07
|
Pleased to announce the release of java-gnome 4.0.6. Release notes: http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.6 Download from: http://ftp.gnome.org/pub/GNOME/sources/java-gnome/4.0/ Or better: $ bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/mainline Cheers, AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and change management procedures. We carry out research and development on behalf of our clients and enable successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Manu M. <man...@co...> - 2008-02-11 08:26:36
|
Hello Just wanted to say that I'm able to compile mainline successfully on Ubuntu 7.10. Additionally I use the following commands to set Sun's jvm and jdk as the default in case that's what's causing the problem. sudo update-alternatives --config java sudo update-alternatives --config javac Hope this helps. Manu -----Original Message----- From: jav...@li... [mailto:jav...@li...] On Behalf Of Andrew Cowie Sent: Monday, February 11, 2008 12:26 PM To: java-gnome-hackers Cc: java-gnome-developer Subject: [Java-gnome-developer] 'mainline' vs 4.0.5 Ubuntu build problem? Somebody who goes by the nick "Lantash" has been popping into #java-gnome indicating that they are having a problem building 'mainline' but not 4.0.5 as released on Ubuntu. This person has, unfortunately, never been around when I've been, so I've not been able to talk to them. The report is a bit weird, seeing as how nothing Ubuntu related has changed since then $ bzr diff -r tag:v4.0.5 configure which makes me suspect that something in this person's environment or system has changed that we are now running afoul of. That's bad, of course, and just the sort of thing that we'd love to see fixed before we cut another release tarball. So, to the person whom I look forward to meeting, please either reply to this or do hang around for more than two minutes and perhaps we can work out together what is troubling you. Otherwise, I am ready to release 4.0.6, and have an itchy trigger finger. I've already moved on to working on post-4.0.6 features, so if someone cares to report a problem, now would be a good time. ++ I should probably note that most of the Ubuntu people I know have been using the $ ./configure jdk=/path/to/whatever/their/java/home/is/ way of specifying where the JVM was. That's largely because the Debian related detection logic was written before the DLJ licence, and so no one has suggested what the appropriate actual packaged location of a [Sun] Java VM would be. If someone could send a bundle with that fixed I'm sure we would all be very grateful. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures. Most of all, we enable successful use of open source in mission critical enterprises, with clients worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Andrew C. <an...@op...> - 2008-02-11 06:55:50
|
Somebody who goes by the nick "Lantash" has been popping into #java-gnome indicating that they are having a problem building 'mainline' but not 4.0.5 as released on Ubuntu. This person has, unfortunately, never been around when I've been, so I've not been able to talk to them. The report is a bit weird, seeing as how nothing Ubuntu related has changed since then $ bzr diff -r tag:v4.0.5 configure which makes me suspect that something in this person's environment or system has changed that we are now running afoul of. That's bad, of course, and just the sort of thing that we'd love to see fixed before we cut another release tarball. So, to the person whom I look forward to meeting, please either reply to this or do hang around for more than two minutes and perhaps we can work out together what is troubling you. Otherwise, I am ready to release 4.0.6, and have an itchy trigger finger. I've already moved on to working on post-4.0.6 features, so if someone cares to report a problem, now would be a good time. ++ I should probably note that most of the Ubuntu people I know have been using the $ ./configure jdk=/path/to/whatever/their/java/home/is/ way of specifying where the JVM was. That's largely because the Debian related detection logic was written before the DLJ licence, and so no one has suggested what the appropriate actual packaged location of a [Sun] Java VM would be. If someone could send a bundle with that fixed I'm sure we would all be very grateful. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures. Most of all, we enable successful use of open source in mission critical enterprises, with clients worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Sean M. <sm...@gm...> - 2008-02-08 15:56:32
|
Hi, With this patch, if the $java_gnome local is evaluated to /usr, then the $jni_include variable will not be set to -I/usr/include -I/usr/include/linux. This fixes rampant build errors in the JNI code, encountered on e.g. Ubuntu when this is the case. Since the existing code already omits the $jni_include variable when jni.h is in /usr/include, I surmise that this additional check will not break any existing setups where it currently works. Testing is desired, as are attempts to break it. What would happen if $java_gnome is "/usr/lib/jdk_1.6.0_03/../../"? Well, it'd evaluate to /usr/ again, and the compiler would eventually be fed -I/usr/lib/jdk_1.6.0_03/../../include/linux, which evaluates to -I/usr/include/linux, which breaks the build. So no, this method is not bullet-proof. It would be even more robust if we could evaluate $jni_include as a path and see if that path equals /usr. But I am not proficient in perl so I do not know how to pull this off. Sorry... Anyway, this fixes my build error and seems relatively safe, since the script pretty much assumes that when you compile something that does #include <stdio.h> without any -I flags, it'll resolve it to "/usr/include/stdio.h". If we want to abstract away from reliance on /usr/include, I'd be happy to look into this further -- but the end result is that I want to guarantee that -I/usr/include and -I/usr/include/linux do NOT appear in my cflags, since this breaks the build. Maybe there's an even easier post-processing way to do this? If we were using the Perl equivalent of a Java StringWriter, we could grab the final output to the file just before writing .config.tmp and nuke all occurrences of -I/usr/include -I/usr/include/linux. Finally, for the record: sean@vk5rms:~/java-gnome/missing$ echo $JAVA_HOME sean@vk5rms:~/java-gnome/missing$ I haven't investigated why this script determines that my $java_home is "/usr". Thanks, Sean McNamara |
|
From: Andrew C. <an...@op...> - 2008-02-03 09:25:25
|
On Wed, 2007-11-28 at 08:14 +0000, Nat Pryce wrote:
> On 27/11/2007, Andrew Cowie <an...@op...> wrote:
> > ... I am tempted to present all such methods with their own prefix to
> > make their relationship to the signal clear.
> >
> > Inspired by the "on" Owen Taylor suggested that led to the onClicked()
> > in design of the Button.CLICKED interface for 'clicked' signals, I'm
> > thinking:
> >
> > doClicked()
> > doRowActivated()
> >
> > etc
> If you're going to change the names away from the Gtk conventions I
> personally would like to see the new names follow Java norms. In Java
> libraries, the "fire" prefix is usually used to send event callbacks
> to listeners. E.g. "fireClicked()" and "fireRowActivated()" would
> send "clicked()" and "rowActivated()" callbacks respectively.
That's a nice suggestion.
> However, "fire" methods are usually protected,=20
Ok, so much for that.
> to ensure that events
> are not announced except when the object actually makes the state
> change that is being announced. Public methods that result in events
> being fired are conventionally in the imperative mood but relate to
> the object's responsibilities, not to its event-firing mechanism.
Yeah, that bothered me a bit too, but given that some signals are named
with a word that can be taken as being in the imperative tense, and some
are in other tenses, it's kinda hard to normalize.
Having been grubbing around down in the C side guts a bit lately, the
"faithful to GTK" aspect is actually that methods like
gtk_button_clicked() are actually convenience wrappers around what is
effectively g_signal_emit('clicked').
So we'll stick with mapping the signal name as is (without attempting to
normalize the tense or tone or mood of the name), but use the word
"emit" as a prefix. I've just committed emitClicked() to Button.
Thanks to everyone for your input.
AfC
Melbourne
|
|
From: Andrew C. <an...@op...> - 2008-02-01 03:43:41
|
I've done another release candidate for 4.0.6 Doing RCs is a bit new. There's nothing requiring it; but I wanted to get a tarball out there for people to use before Davyd and I gave the GTK & GNOME tutorial at LCA the other day, and haven't had time to do NEWS files and whatnot. http://ftp.gnome.org/pub/GNOME/sources/java-gnome/4.0/java-gnome-4.0.6-rc2.= tar.bz2 4.0.6 has got some great coverage additions, and although I haven't actually merged any of the experimental branches I said I was going to, it's looking like there is enough new work that it'll be worth pushing out on its own merits. I might get to those merges next week, might not. Cheers, AfC Melbourne --=20 Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Mark H. <mh...@ti...> - 2008-01-25 08:26:56
|
The java code for this looks kindof klunky - the 'signal' is really an internal detail of TreeModelFilter rather than an external signal. Would it be possible to define TreeModelFilter as an abstract class with an abstract boolean isVisible(row) method. Implementations of custom tree model filters would be concrete implementations of this. I don't have time to investigate the implementation unfortunately, but a simple hack might be to use the current signal mechanisms but with a single handler for the signal in TreeModelFilter which delegates to the abstract method? On Jan 24, 2008 10:30 PM, Andrew Cowie <an...@op...> wrote: > GtkTreeModelFilter revolves around using > gtk_tree_model_filter_set_visible_func() to register a callback to a > function of signature (*GtkTreeModelVisibleFilterVisibleFunc). As most > of you know, we don't have a general mechanism for handling function > pointers, and indeed blacklist any method with one as an argument. > > We already have a very powerful C to Java callback mechanism, and that's > the marshaling code used to deal with GObject signals. I've long had > bigger plans for that code, because it works well, and doing the C to > Java thing is ninja voodoo as it is, and nasty when you consider it in > the general case. > > That observed, my general strategy for some time for dealing with non > signal callbacks has been to merely find a way to turn it into a signal > emission and then deal with it down the existing code path. > > It took a lot of futzing to find the magic incantation necessary, but > I've worked something out for TreeModelFilter which C side registers a > custom signal and then the function which meets > (*GtkTreeModelVisibleFilterVisibleFunc) "simply" emits the signal. > > It's all done by hand, of course, and I'm not sure how amenable this > will be to code generation (indeed, we don't have the required > signatures in our .defs data), but it seems to work fairly well. The > public API Java side looks right: > http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeModelFilter.html > > and here is the implementing C code: > http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/bindings/org/gnome/gtk/GtkTreeModelFilterOverride.c > > The real trick was the insight that we didn't need to figure out the > marshaling function when registering the signal after all - which is > where I'd been stuck before, because there wasn't an existing > BOOLEAN:OBJECT,BOXED marshaller. > > AfC > Sydney > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > > |
|
From: Andrew C. <an...@op...> - 2008-01-24 22:30:35
|
GtkTreeModelFilter revolves around using gtk_tree_model_filter_set_visible_func() to register a callback to a function of signature (*GtkTreeModelVisibleFilterVisibleFunc). As most of you know, we don't have a general mechanism for handling function pointers, and indeed blacklist any method with one as an argument. We already have a very powerful C to Java callback mechanism, and that's the marshaling code used to deal with GObject signals. I've long had bigger plans for that code, because it works well, and doing the C to Java thing is ninja voodoo as it is, and nasty when you consider it in the general case. That observed, my general strategy for some time for dealing with non signal callbacks has been to merely find a way to turn it into a signal emission and then deal with it down the existing code path. It took a lot of futzing to find the magic incantation necessary, but I've worked something out for TreeModelFilter which C side registers a custom signal and then the function which meets (*GtkTreeModelVisibleFilterVisibleFunc) "simply" emits the signal. It's all done by hand, of course, and I'm not sure how amenable this will be to code generation (indeed, we don't have the required signatures in our .defs data), but it seems to work fairly well. The public API Java side looks right: http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeModelFilter= .html and here is the implementing C code: http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/binding= s/org/gnome/gtk/GtkTreeModelFilterOverride.c The real trick was the insight that we didn't need to figure out the marshaling function when registering the signal after all - which is where I'd been stuck before, because there wasn't an existing BOOLEAN:OBJECT,BOXED marshaller. AfC Sydney |
|
From: Andrew C. <an...@op...> - 2008-01-15 05:59:01
|
There's about 8 weeks of work pending in 'mainline' right now. It's mostly all little stuff, but it represents additional coverage across a wide range of classes and not a few bug fixes, so we should probably push it out as 4.0.6 sooner rather than later. I've already landed a rather monster branch called 'missing', so I'm pretty pleased overall at where things are at. There are a few things pending on my list: I'm going to merge the stubs from the 'cairo' branch, and also merge a few things I have lurking here and there on local branches. I also am very close to merging the 'generics' branch. It's high time we pushed the minimum version to Java 1.5. There's also GTK 2.12 .defs data to go in, which I would appreciate if someone would take care of. I'd also like to see if we can get the configure glitches that Wouter observed some time back sorted, but that'll probably slide again. I'm running "Eclipse Europe" these days as my IDE; I noticed it made some changes to the .project files, etc and I'm not sure how backwards compatible that is, and while I don't want to screw anyone up, I should probably commit the metadata in its current form. Anyway, as usual, if you've got something you want to see in, now is the time. I intend to cut the release this weekend or early next week at the latest so that I can focus on my clients and also on getting ready for LCA. AfC Sydney |
|
From: Andrew C. <an...@op...> - 2008-01-15 00:52:06
|
On Mon, 2008-01-14 at 20:39 +0530, Manu Mahajan wrote: > Hi >=20 > Here is the file with the changes that I had made today. The configure=20 > file was running correctly but was reporting incorrect package names. Merged to 'mainline' AfC=20 Sydney P.S. You don't need to tar and compress a bundle - just send the output of `bzr bundle` inline or as an attachment - and that makes it easier at my end. If your patch is "too" big that it "won't fit", then there are other ways to convey the data like posting it somewhere, creating a branch on our R&D server, etc |
|
From: Andrew C. <an...@op...> - 2008-01-14 13:54:18
|
On Mon, 2008-01-07 at 19:40 +0100, Timm Preetz wrote:
> since 4.0.5 it should be possible to build the docs with graphics, but
> that doesn't work here.
>=20
> Is there any (hidden) option I have to trigger besides "make doc"?
Nothing hidden, but it's not hooked up to anything yet. You're looking
for Harness in tests/screenshots/. Sorry, I thought I mentioned that
somewhere. Either run it from Eclipse, or from the command line
something like=20
/opt/sun-jdk-1.5.0.13/bin/java -client \
-classpath tmp/tests:tmp/gtk-4.0.jar \
-Djava.library.path=3Dtmp \
-ea
Harness
=20
ought to do it.
It's not hooked up to `make doc` yet partially because I've been meaning
to move that target to build/faster and haven't gotten around to it, but
mostly because it's not *that* reliable yet. Lots of paths are hard
coded, that sort of thing. And the whole Xvfb invocation is *really*
fragile. Fixing all that is going to take a lot of work, and I have more
important things to do.
We should add it, but I'm not sure I want to deal with bugs from people
complaining `make doc` doesn't work for them. The thing _is_ a rather
ugly hack still.
[It's also rather slow, so for now I don't really want `make doc`
blocking on it. What would be really cool would be a javadoc doclet that
didn't generate crap output when run incrementally. Then it could be
driven by the build engine and only those .html and .png files actually
needed could be done as necessary]
> In related news: Is it normal to get _very_ much output in the form of
> warning that packages don't exist or "Tag @link: can't find modifyXYZ"?
Yes, although obviously we want the list to drop to zero over time.
Contributions to add the coverage so that those dangling cross
references are resolved would, of course, be more than welcome.
Still, better to have the links to things that we know are going to be
there "soon" than not having the cross references at all and never
thinking to add them in the future.
AfC
Sydney
|
|
From: Timm P. <ti...@pr...> - 2008-01-07 18:40:37
|
Hi, since 4.0.5 it should be possible to build the docs with graphics, but that doesn't work here. Is there any (hidden) option I have to trigger besides "make doc"? In related news: Is it normal to get _very_ much output in the form of warning that packages don't exist or "Tag @link: can't find modifyXYZ"? Thanks for any hints, Timm |
|
From: Andrew C. <an...@op...> - 2008-01-07 01:12:27
|
On Sun, 2008-01-06 at 13:01 +0100, Timm Preetz wrote: > the java-gnome package is now in arch's community repos, so installation > got very easy. Great! > Strangely I couldn't find my first version of the arch-page in the repo, > so I hope this patch works fine for you. It was indeed merged, but is on the 'website' branch (which has to otherwise stay at the last release so the published API documentation remains correct. I periodically merge 'website' up to 'mainline' to pull up such changes when there is a reason to do so. I'll do that again right now. The trick is that I can only go the other direction when we do a release). Anyway, thanks for your patch. Conflicts resolved and patch merged to 'website' branch. Revisions also merged to 'mainline'. Website updated. AfC Hobart --=20 Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Timm P. <ti...@pr...> - 2008-01-06 12:01:08
|
Hi, the java-gnome package is now in arch's community repos, so installation got very easy. Strangely I couldn't find my first version of the arch-page in the repo, so I hope this patch works fine for you. Regards, Timm |
|
From: Andrew C. <an...@op...> - 2007-12-13 04:43:03
|
On Sun, 2007-12-09 at 15:03 -0500, Behdad Esfahbod wrote:
> On Sun, 2007-12-09 at 17:58 +0530, Andrew Cowie wrote:
> >=20
> > After doing all that for Pattern and being fairly satisfied with it, I
> > attempted to start testing it only to not be able to find a Cairo
> > function that returns a cairo_pattern_t that's not a constructor [If
> > someone can suggest one, I'd be grateful] so I couldn't actually write
> > a test to exercise this code. Grumble.
>=20
> cairo_get_source().
Thanks Behdad! I specifically needed something that would fetch a native
entity that had not been explicitly instantiated on the Java side, and
Context cr;
ImageSurface s;
Pattern p;
s =3D new ImageSurface(Format.ARGB32, 100, 100);
cr =3D new Context(s);
cr.setSourceRGBA(0.0, 0.0, 1.0, 1.0);
p =3D cr.getSource();
was a perfect example to use in a unit test validating the code paths
for Pattern. Cheers,
AfC
Sydney
|
|
From: Behdad E. <be...@be...> - 2007-12-09 20:03:39
|
On Sun, 2007-12-09 at 17:58 +0530, Andrew Cowie wrote: > > After doing all that for Pattern and being fairly satisfied with it, I > attempted to start testing it only to not be able to find a Cairo > function that returns a cairo_pattern_t that's not a constructor [If > someone can suggest one, I'd be grateful] so I couldn't actually write > a test to exercise this code. Grumble. cairo_get_source(). -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh |
|
From: Andrew C. <an...@op...> - 2007-12-09 12:55:27
|
Srichand, I spent the afternoon cleaning up the patches I had lying about on the 'cairo' branch and committing them. What I'd been working on when I last hacked on this was working out what internals would be necessary to make the Plumbing.proxyFor() equivalent work for the Cairo types. With Surface and now Pattern we've got concrete subtypes for each of the various cairo_surface_t and now cairo_pattern_t that you can have. The trick is that there's no g_type_name() equivalent to figure out the type for an arbitrary pointer, so we have to do a bit of switching Java side to figure out which of the base Cairo types it is, then hand off to the C side to do a switch over the various type constants to finally know which Class to actually instantiate. Luckily I think we know enough between generation (for the resultant Class constant being requested in entityFor()) at runtime (the various _get_type() functions to make the right calls. After doing all that for Pattern and being fairly satisfied with it, I attempted to start testing it only to not be able to find a Cairo function that returns a cairo_pattern_t that's not a constructor [If someone can suggest one, I'd be grateful] so I couldn't actually write a test to exercise this code. Grumble. Nevertheless, the real point of the work was to figure out the design pattern that would be used for getting Proxies for arbitrary pointers in the Cairo library, and I think that's more or less sorted. Let me know what you think as you poke away at whichever bit of Cairo interested you. AfC Bangalore |
|
From: Srichand P. <sri...@gm...> - 2007-12-08 16:34:00
|
On Dec 8, 2007 8:25 AM, Andrew Cowie <an...@op...> wrote: > On Sat, 2007-12-08 at 16:29 +0530, Manu Mahajan wrote: > > This is a patch to run the configure script on open suse. > > > > Please review and advise. > > Merged to 'mainline'. A new distribution, a new contributor. Awesome! Srichand Mont. Ripley -- Srichand Pendyala http://srichand.net.in/ |
34 messages has been excluded from this view by a project administrator.
