java-gnome-hackers Mailing List for The java-gnome language bindings project
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: William T. <wil...@gm...> - 2017-03-04 07:36:22
|
Hi all, It's been a long time since I saw any activity on this list, I don't know if anyone else is still hacking on Java Gnome. I've been building and running the Github version ( https://github.com/afcowie/java-gnome) which has been working fine on Ubuntu 12.04. As this is coming out of maintenance soon I've been trying to build on 16.04, but I can't figure out what's going wrong with the build. First oddity is with configure. In general it is happy everything is in place, but in the last few lines of output I get this error: """ Output: - configuration data ok print() on closed filehandle LIBRARY at ./configure line 2303. - native library location ok """ So I ignored this and tried running make, but this fails with complaints about missing Java files, e.g: """ src/bindings/org/gnome/gtk/Widget.java:466: error: package GtkWidget does not exist public interface KeyReleaseEvent extends GtkWidget.KeyReleaseEventSignal """ So it seems the Java bindings generation hasn't worked. Running BindingsGenerator manually, it won't parse .def files which only define methods - honestly I don't understand how this works, is there some preprocessing step to the .def files I'm missing? If anyone could shed some light on this it would be much appreciated. Best regards, Will Temperley |
From: Niranjan R. <nh...@gm...> - 2014-01-10 02:46:10
|
https://github.com/nhrdl/java_gnome Happy to announce webkit2 bindings for java-gnome. You can get the source code from above url. There is a simple browser class included in the code. This class accepts url as command line parameter and displays browser window. If you want to display web pages or html documents, it will work for you. Its still lacking some advance features. I am implementing the features as and when I get time. Some noteworthy points 1. This is still work in progress. Not all the features that webkit supports are implemented. 2. Its not as pretty as original java-gnome code. Most of the code is generated from "GIR" files and compilation errors fixed manually. There are still lot of FIXMEs in the code, but it does work. 3. It has rudimentary support for extensions. If you need to access DOM from webkit2, you have to use extensions. I would have preferred to not to create a separate fork, but did it because 1. I needed support for webkit as soon as possible. 2. I understand that not everyone needs webkit support and in it's current architecture its very difficult to customize build of java-gone library to add optional dependencies. Webkti does add lot of weight to library if you consider other library support required such soup. Most of the distributions may have WebkitGTk1. If you need support for that, please drop me a line and I'll add it to repository. From my perspective, we have much complete support for WebkitGtk1 than WebkitGtk2. I can upload it to github after some cleanup. At the place where I work, this code is in heavy use. Regards, Niranjan |
From: Guillaume M. <res...@gm...> - 2013-12-23 01:09:44
|
Hi, On Thu, Dec 19, 2013 at 1:06 AM, Niranjan Rao <nh...@gm...> wrote: > > I am looking for a recommended/best way to add support for libraries > which java-gnome currently does not support. My primary interest at this > time is webkit-gtk version 2 and libsoup and any other supporting > libraries these two need > Sounds interesting, especially webkit which has already been asked for. > I had a code generator working which will read gnome introspection files > and will generate required java files and defs files. This approach > worked well for Webkit version 1. However for Webkit 2, gtk annotations > are not ready yet. > Oh. I did some work during the last GSoC to make GObject Introspection data usable by the java-gnome code generator. You might be interested by the Git branch [1] My understanding of current architecture is there are finely tuned hand > written classes which are public - e.g. VPaned which in turn direct > calls to protected class (GtkVPaned) which do actual work. If I > introduce new .defs file, I get latter part, but not first part that is > no public classes. > Exactly. The point is to "force" the hacker to write the public API himself to make it more friendly to developer. It lowers the evolution of the bindings but it is an important thing to keep the quality and the consistancy of the API. Exact problems: > You are talking about interesting engineering problems so l'll try to give my opinion and contribute waiting for Andrew's answer (he's the boss here :). 1. Keep my additions as separate as possible if I need to upgrade > java-gnome library versions. > 2. Ideally I would like to load only one JNI library. If I can convince > existing infrastructure to accept new source files while still > maintaining separation at least at code level. > 3. Find easy way to generate public classes - at least for bootstrapping > purposes. > 4. Convince python script "faster" to accept new libraries - either as a > command line parameter or as environment variable > As you probably know, java-gnome is a big monolithic thing. We discussed several months ago about how we could introduce optional dependencies in java-gnome which led to thinking about splitting java-gnome into modules. This has raised interesting topics (about loading multiple JNI libraries, multiple JARs, but we'd like to keep one JAR and one JNI lib, well you can found this in the mailing list archives). IMHO, the thing that we should do is splitting java-gnome core from the actual bindings. What does it mean? It consists of separating the bindings generator code from the bindings themselves. I'd like to see that one day. In this way people could do their own bindings using the powerful java-gnome code generator. If someone is willing to talk about this I'm up for it :) > 1. Extending code generator so that it can accept source directory on > command line > That could be a solution until we found a more viable one. I am not saying it is a bad one but I see this as a temporary solution more than a definitive one. The definitive solution would be the one I have just talked about ;) > 2. Adding code generation part which will generate public classes from > def files. This will give me first cut which can be fine tuned latter if > need arises. > This would violate the current policy about writing the public API by hand. I am not against generating stubs to spend less time writing them though. Any ideas/suggestions/thoughts are appreciated. > I hope my thoughts were useful. [1] https://github.com/respawner/java-gnome/tree/introspection -- Guillaume Mazoyer -- https://respawner.fr |
From: Niranjan R. <nh...@gm...> - 2013-12-19 00:06:28
|
Greetings, I am looking for a recommended/best way to add support for libraries which java-gnome currently does not support. My primary interest at this time is webkit-gtk version 2 and libsoup and any other supporting libraries these two need I had a code generator working which will read gnome introspection files and will generate required java files and defs files. This approach worked well for Webkit version 1. However for Webkit 2, gtk annotations are not ready yet. My understanding of current architecture is there are finely tuned hand written classes which are public - e.g. VPaned which in turn direct calls to protected class (GtkVPaned) which do actual work. If I introduce new .defs file, I get latter part, but not first part that is no public classes. Exact problems: 1. Keep my additions as separate as possible if I need to upgrade java-gnome library versions. 2. Ideally I would like to load only one JNI library. If I can convince existing infrastructure to accept new source files while still maintaining separation at least at code level. 3. Find easy way to generate public classes - at least for bootstrapping purposes. 4. Convince python script "faster" to accept new libraries - either as a command line parameter or as environment variable I am thinking of 1. Extending code generator so that it can accept source directory on command line 2. Adding code generation part which will generate public classes from def files. This will give me first cut which can be fine tuned latter if need arises. Any ideas/suggestions/thoughts are appreciated. Regards, Niranjan |
From: Guillaume M. <res...@gm...> - 2013-08-31 13:19:04
|
Hello, Here is some info about the changes that I have made since the previous email. 2013/8/14 Guillaume Mazoyer <res...@gm...>: > * The GIR files that have been found are passed to the > IntrospectionParser which will parse them and gives Block objects > encapsulated in DefsFile objects like the DefsParser will do. The > DefsFile class may need another name since it is not really DefsFile > now (it is just a Java object representation of what the parser has > found). The GIR parser does not generate DefsFile objects now but returns Block arrays instead it allows to centralize some code in the BindingGenerator class instead of modifying the DefsFile class. Moreover I think that the Block array field of the DefsFile class should not be modifiable. > 1) GObject Introspection data contains a lot of things that we don't > need to know and parse (GRand, GTime, etc… we have well working > corresponding objects in Java). So to avoid them I have created a file > called types.list (see [2]) which contains the list of types that we > care about. What do you think about it? Should we discuss a better > format for such a file? I decided to switch the format of the types.list file to XML since we have all the needed requirements to do so. It is an easy to read and modify file and I have taken the time to make a quick documentation of the XML format to use for this file. > 4) I've chosen to propose some way to override packages names and > types name to match ours these are respectively the > packages-override.properties and the names-override.properties files. > Is it ok for you or should we found a better alternative? The packages-override.properties and the names-override.properties files no longer exist in the last commit. All the information that they used to contain are now located in the types.list file. It avoids to have multiple files to change when adding coverage for a library or doing some changes in the existing ones. > 5) Maybe I will have more questions later :) Yes I do ;) What is the plan to release java-gnome with the GObject Introspection support? I am not a maintainer and I am probably not the right person for this job so I might say some wrong things. I was thinking that we will release java-gnome 4.2.0 to introduce the GObject Introspection based code generator. Of course I need feedback on my code to know if I made the good choices, don't forget that you can easily comment some lines or commit that I have done on GitHub. During the last hangout Andrew and I discussed about merging some part of my 'introspection' branch. I am not sure of what we can merge now. As of today the branch is about 45 commits ahead so if we want to merge some code we probably need to cherry pick. Or maybe we can create a 4.2 branch and merge everything in it and manage 4.1 and 4.2 releases at the same time but it would be probably to hard. Again I am not a maintainer ;). Eventually, I would like to add the coverage for another library. I was thinking about libgweather, or libwebkitgtk or libchamplain. So I propose that you should tell me in what library you are the most interested in. It will help me to also document the process to add the coverage of a library in java-gnome. I would like to write a documentation for this that java-gnome hackers and future contributors can use. Of course we need to validate the work that I have done so far. The GSoC is ending in about 3 or 4 weeks so don't hesitate to give me some feedback, the end will be here pretty soon but I will also continue to contribute to java-gnome after this GSoC ;). -- Guillaume Mazoyer - https://respawner.fr/ |
From: Guillaume M. <res...@gm...> - 2013-08-14 18:42:09
|
Hello, After a Google Hangout with Andrew (AfC) we have noticed that I have not write anything on this list since the beginning of the GSoC. So here is a mail that should fix this and it is a chance to get more people involved. 1) A link[1] where you can find the branch that I am working on. 2) Serkan and I chose to use the XML data generated by the libraries to work with. Why? XML is simple enough to parse in Java (and a lot of API can be used, I've chosen XOM for us) and it is readable by human being to investigating a XML manually is easy enough to debug our new parser. 3) How GIR works in java-gnome for now? * A new configure step has been added to check if the GIR files exist on the system. It tries to look for several files in a given directory for each distros (for now only Debian and its derivatives are supported [because I use it]) so you are welcome to give me patches to add support for your distros. * The branch introduces a new parser for the code generator called IntrospectionParser * The GIR files that have been found are passed to the IntrospectionParser which will parse them and gives Block objects encapsulated in DefsFile objects like the DefsParser will do. The DefsFile class may need another name since it is not really DefsFile now (it is just a Java object representation of what the parser has found). * After the Introspection data parsing, a second parsing is performed using .defs files located in src/overriders. These files can be used to provide data to override GIR data or to add data libraries coverage that don't provide GIR data. So basically it is the "old" DefsParser that does the work so we can still take advantage of it and still use .defs files if we need to. * After all of this the code generator can still work like it does for years. So I've really worked on a new parser. It is getting usable and from today [14th August 2013] java-gnome actually compiles while using GIR data :). So this work is in a good way to bring GObject Introspection in java-gnome soon. We still have choices to make and this is the second part of this mail. Andrew, Serkan, and everyone is welcome to participate of course, here are some questions that we need to answer: 1) GObject Introspection data contains a lot of things that we don't need to know and parse (GRand, GTime, etc… we have well working corresponding objects in Java). So to avoid them I have created a file called types.list (see [2]) which contains the list of types that we care about. What do you think about it? Should we discuss a better format for such a file? 2) Some functions, methods and other things are marked as deprecated in the GIR data, what should we do with them? 3) Should we consider renaming the DefsFile class to something more relevant starting from now? 4) I've chosen to propose some way to override packages names and types name to match ours these are respectively the packages-override.properties and the names-override.properties files. Is it ok for you or should we found a better alternative? 5) Maybe I will have more questions later :) Thanks for your future help. Hope you are enjoying the work that I have done so far. [1] https://github.com/respawner/java-gnome/tree/introspection [2] https://github.com/respawner/java-gnome/commit/c3c772e14ce31c3c6d986e5d4406134e69d93d53 -- Guillaume Mazoyer - https://respawner.fr/ |
From: Niranjan R. <nh...@gm...> - 2013-05-13 19:18:27
|
Greetings, There are somethings I need to do in the idle loop. I have added my handler stub implementing Handler interface - in other words there is no logic in the method apart from return statement. I have noticed that if I add the idle handler, process CPU immediately jumps high and keeps one CPU at 100% according to top command. CPU usage jumps to normal if I don't add the handler. Given that idle method is getting called large number of times, is there anything I can do so that CPU does not jump to 100%? As noted above, I have not yet started with my implementation yet, this is just stub function returning true. Regards, Niranjan |
From: Andrew C. <an...@op...> - 2013-03-22 21:48:39
|
On Thu, 2013-03-14 at 12:14 +0100, Sarah Leibbrand wrote: > Anyway attached is my patch for now for the next release. (I assumed > 4.1.3?) Sarah, Can you get me this branch ASAP? I'd like to do a release this weekend... AfC Sydney |
From: Sarah L. <xa...@gm...> - 2013-03-14 11:23:04
|
Owh I forgot to mention one thing. The patch includes a fix for the enchant test. Which was crashing for me. I still have 1 test crashing on me. for unknown reasons.. dug into it a while ago, never found out why.. Kind regards, Sarah On Thu, Mar 14, 2013 at 12:14 PM, Sarah Leibbrand <xa...@gm...> wrote: > > Not all, I prefer git over bazaar any day really. This makes it really a > lot easier. > > Anyway attached is my patch for now for the next release. (I assumed > 4.1.3?) > > Summary of changes: > > * Exposed getChildAt(int, int) method in Grid. (I LOVE grid.. so much > better then those nasty vbox/hbox mess) > * Exposed getLanguageGuess(String, String) in LanguageManager (renamed > from guessLanguage() in C, didn't make sense to me to just put 'get' > infront of the name). > * Exposed WindowState.FOCUSED which otherwise may give errors when > requesting window state information such as maximized. > * Fixed crash from using accelerators when overwriting existing > accelerators with a nullable field that was not so nullable in the def > file. (see MenuItem.java#193, Action.java#494) > > I plan to look into extended tooltips later. Makes things easier for quick > lists (treeviews) to have extra information visible rather then being very > wide. > > Kind Regards, > > Sarah Leibbrand > > > > > On Thu, Mar 14, 2013 at 11:09 AM, Andrew Cowie < > an...@op...> wrote: > >> On Thu, 2013-03-14 at 10:58 +0100, Sarah Leibbrand wrote: >> > So out of curiosity, since I have a few things to commit. Should i >> > post the patch through bazaar or git now? Either way is fine with me. >> > There is a fix in a def file and some exposed methods that I need. >> >> A a pull request via GitHub would be best, if you don't mind. >> >> AfC >> Sydney >> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> >> _______________________________________________ >> java-gnome-hackers mailing list >> jav...@li... >> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers >> >> > |
From: Andrew C. <an...@op...> - 2013-03-14 10:25:37
|
On Thu, 2013-03-14 at 10:58 +0100, Sarah Leibbrand wrote: > So out of curiosity, since I have a few things to commit. Should i > post the patch through bazaar or git now? Either way is fine with me. > There is a fix in a def file and some exposed methods that I need. A a pull request via GitHub would be best, if you don't mind. AfC Sydney |
From: Sarah L. <xa...@gm...> - 2013-03-14 09:58:59
|
So out of curiosity, since I have a few things to commit. Should i post the patch through bazaar or git now? Either way is fine with me. There is a fix in a def file and some exposed methods that I need. Kind regards, Sarah On Sat, Feb 23, 2013 at 1:00 PM, Andrew Cowie < an...@op...> wrote: > On Fri, 2013-02-22 at 18:36 +1100, Andrew Cowie wrote: > > > P.S. There's a test crash right now, something to do with an image? > > Fixed :) > > AfC > Sydney > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > > |
From: Niranjan R. <nh...@gm...> - 2013-03-01 00:13:20
|
Sorry for the late reply, but here is the tool I wrote. It's not perfect, but will get you started. At least I am able to use webkit libraries reasonably well with little manual tinkering. This null value was one of the problems I was facing. https://github.com/nhrdl/GirToGnomeJava Regards, Niranjan On 02/23/2013 04:04 AM, Andrew Cowie wrote: > On Fri, 2013-02-22 at 18:25 -0800, Niranjan Rao wrote: >> But this was my reply to your query if anyone else like to have >> anything in :) > That's ok. My query was more "if you have a branch you've written that > you'd like to be merged..." kind of question. > > Glad to hear (null-ok) was what you needed. > > I didn't invent the .defs format, by the way; it is what it is. I was > hoping we'd be adding a GIR based data source by now, but the person who > was going to do it as a summer of code project pulled out. It sounds > like you're working on something along those lines; perhaps you'll be > the one to take this on in the future. > > AfC > Sydney > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Serkan K. <se...@ge...> - 2013-02-24 11:28:23
|
Hi, If you want to pick up this year. I'm more than happy to mentor. (This means I need to revamp myself a bit as well) On 02/23/2013 07:07 PM, Guillaume Mazoyer wrote: > Hi, > > 2013/2/23 Andrew Cowie <an...@op... > <mailto:an...@op...>> > > I didn't invent the .defs format, by the way; it is what it is. I > was hoping we'd be adding a GIR based data source by now, but the > person who was going to do it as a summer of code project pulled > out. It sounds like you're working on something along those lines; > perhaps you'll be the one to take this on in the future. > > I was going to re-submit my proposal (the only one) for this year > GSoC (which will be the last one for me). But if something is done > already that cool, if I can help in anyway don't hesitate to tell > me. I an very interested in those GIR things. > > > -- Guillaume Mazoyer - http://respawner.fr/ > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics > Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb > > > > _______________________________________________ java-gnome-hackers > mailing list jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > |
From: Guillaume M. <res...@gm...> - 2013-02-23 18:07:54
|
Hi, 2013/2/23 Andrew Cowie <an...@op...> > I didn't invent the .defs format, by the way; it is what it is. I was > hoping we'd be adding a GIR based data source by now, but the person who > was going to do it as a summer of code project pulled out. It sounds > like you're working on something along those lines; perhaps you'll be > the one to take this on in the future. > I was going to re-submit my proposal (the only one) for this year GSoC (which will be the last one for me). But if something is done already that cool, if I can help in anyway don't hesitate to tell me. I an very interested in those GIR things. -- Guillaume Mazoyer - http://respawner.fr/ |
From: Andrew C. <an...@op...> - 2013-02-23 12:04:17
|
On Fri, 2013-02-22 at 18:25 -0800, Niranjan Rao wrote: > But this was my reply to your query if anyone else like to have > anything in :) That's ok. My query was more "if you have a branch you've written that you'd like to be merged..." kind of question. Glad to hear (null-ok) was what you needed. I didn't invent the .defs format, by the way; it is what it is. I was hoping we'd be adding a GIR based data source by now, but the person who was going to do it as a summer of code project pulled out. It sounds like you're working on something along those lines; perhaps you'll be the one to take this on in the future. AfC Sydney |
From: Andrew C. <an...@op...> - 2013-02-23 12:00:39
|
On Fri, 2013-02-22 at 18:36 +1100, Andrew Cowie wrote: > P.S. There's a test crash right now, something to do with an image? Fixed :) AfC Sydney |
From: Niranjan R. <nh...@gm...> - 2013-02-23 02:25:41
|
But this was my reply to your query if anyone else like to have anything in :) I wanted to this feature in if possible in the next release. Thanks for the information. I'll modify my generator accordingly. Regards, Niranjan On 02/22/2013 04:57 PM, Andrew Cowie wrote: > On Fri, 2013-02-22 at 10:40 -0800, Niranjan Rao wrote: >> Not sure if this is already implemented and I am not aware of the >> syntax. > Hi Niranjan. Please start a new thread for new topics, eh? > >> I am looking for a way to specify in defs file that is null value is >> legal value for a given parameter. > Add (null-ok) to the parameter line. From GtkButton > > (define-method set_image > (of-object "GtkButton") > (c-name "gtk_button_set_image") > (return-type "none") > (parameters > '("GtkWidget*" "image" (null-ok)) > ) > ) > > AfC > Sydney > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Andrew C. <an...@op...> - 2013-02-23 00:57:23
|
On Fri, 2013-02-22 at 10:40 -0800, Niranjan Rao wrote: > Not sure if this is already implemented and I am not aware of the > syntax. Hi Niranjan. Please start a new thread for new topics, eh? > I am looking for a way to specify in defs file that is null value is > legal value for a given parameter. Add (null-ok) to the parameter line. From GtkButton (define-method set_image (of-object "GtkButton") (c-name "gtk_button_set_image") (return-type "none") (parameters '("GtkWidget*" "image" (null-ok)) ) ) AfC Sydney |
From: Niranjan R. <nh...@gm...> - 2013-02-22 18:41:18
|
Not sure if this is already implemented and I am not aware of the syntax. I am looking for a way to specify in defs file that is null value is legal value for a given parameter. I have generator for webkit that generates the defs file from "gir" file. Some webkit functions do accept null values legitimately, but generated code throws exception about value can not be null. So far my (BAD) solution is to change the generated file and remove the offending lines. On 02/21/2013 11:36 PM, Andrew Cowie wrote: > Been away for a while, and the entire time I've been gone I've been > using Git. So, I've finally buckled and ported my branch of java-gnome > to Git and put it up on GitHub. > > https://github.com/afcowie/java-gnome > > Along the way I've attempted to catch up a few patches, notably the > libunique breakage. That alone is long overdue for a release, so 4.1.3 > is imminent; if anyone has anything else they'd like in shout. > > AfC > Sydney > > P.S. There's a test crash right now, something to do with an image? > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Andrew C. <an...@op...> - 2013-02-22 07:36:46
|
Been away for a while, and the entire time I've been gone I've been using Git. So, I've finally buckled and ported my branch of java-gnome to Git and put it up on GitHub. https://github.com/afcowie/java-gnome Along the way I've attempted to catch up a few patches, notably the libunique breakage. That alone is long overdue for a release, so 4.1.3 is imminent; if anyone has anything else they'd like in shout. AfC Sydney P.S. There's a test crash right now, something to do with an image? |
From: Niranjan R. <nh...@gm...> - 2012-10-19 19:47:56
|
Hi there, I am trying to wire webkit's "create-new-view" signal. When I try to to run my code I am getting error Don't know what to do with signal return type WebKitWebView from bindings_java_signal.c I understand that this is more generic problem as c code now needs to map to java object types. Is there some way I can modify the current c code so that I can run my code? In other words, can I put a place holder hack and if so, what should I put there? I think a better solution might be have a callback handle in the application and call that function to return the proper java type. Thanks, Niranjan |
From: Andrew C. <an...@op...> - 2012-08-30 08:32:20
|
The 'mainline' branch now identifies itself as version 4.1.3-dev. AfC Sydney |
From: Guillaume M. <res...@gm...> - 2012-08-25 12:21:43
|
2012/8/25 Andrew Cowie <an...@op...>: > Guillaume uncovered a bug; That's what I do :) > Anyway, if you're working from another thread and need to update your > GTK widgets, you must do so from within the main loop. To get there, you > add an idle handler which will get a callback at some future point. See > http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/glib/Glib.html#idleAdd(org.gnome.glib.Handler) > > It'd really be rather nice if the people with experience with the > toolkit could have a look at this implementation and tell me if it's > done right. In particular, have a look at: > http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/bindings/org/gnome/glib/GMain.c It looks fine to me. I'll test this on a real world application. > Given the massive capability loss this represents, I rather think we > should remove this as 4.2.0; should I mark it deprecated in 4.1.2? I guess that it should be marked as deprecated and remove in 4.2.0. Since GDK/GTK does not take care of this anymore we should get rid of this in a next new major release. > I've also dramatically updated the documentation around the Application > coverage. I _think_ I've got it all squared away now, but perhaps you'll > comment. > http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/gtk/Application.html Nothing to say, great documentation. -- Guillaume Mazoyer - http://respawner.fr/ |
From: Andrew C. <an...@op...> - 2012-08-25 10:01:56
|
Guillaume uncovered a bug; basically the new Application coverage we introduced doesn't work with java-gnome's multi-thread safety because GTK itself is no longer thread safe. While they haven't yet removed what they've deprecated, the new GtkApplication code doesn't release the GDK lock in g_application_run() like gtk_main() does. So, bam, race. Boo. This has been coming for a while, and despite my intense disappointment about it all, will now be like every other GUI toolkit out there: not thread safe. Double Boo. Anyway, if you're working from another thread and need to update your GTK widgets, you must do so from within the main loop. To get there, you add an idle handler which will get a callback at some future point. See http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/glib/Glib.html#idleAdd(org.gnome.glib.Handler) It'd really be rather nice if the people with experience with the toolkit could have a look at this implementation and tell me if it's done right. In particular, have a look at: http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/bindings/org/gnome/glib/GMain.c ++ It's an open question whether we still need our implementation of the GDK lock. The code is all there, and if nothing else it'll show you a deadlock when you've done something you shouldn't have, ie call GTK from another thread. Given the massive capability loss this represents, I rather think we should remove this as 4.2.0; should I mark it deprecated in 4.1.2? ++ I've also dramatically updated the documentation around the Application coverage. I _think_ I've got it all squared away now, but perhaps you'll comment. http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/gtk/Application.html AfC Sydney |
From: Guillaume M. <res...@gm...> - 2012-08-21 15:02:16
|
2012/8/21 Andrew Cowie <an...@op...>: > Thanks to Guillaume Mazoyer and with help from Emmanuele Bassi and Ryan > Lortie, it looks like we have preliminary coverage of GApplication and > GtkApplication in java-gnome. Great news :) > Since my last message I've worked out command-line argument passing. > It's probably not bulletproof (there's a reference count problem) but I > hacked it into my ever-trusty Slashtime and it seems to work > > So I've merged 'application' to 'mainline'. Hurrah. Nice! > The example code included is unfortunately rather useless; a good check > would be to see if someone can take what I did to Slashtime and > refactor / improve the example to be a bit more illustrative. I'll give it a try with GNOME Split in a day or two ;) Thank you very much for taking the lead on the work I have done and taking the time to finish and polish it. I'm glad to see this merged into mainline so we can go forward. -- Guillaume Mazoyer - http://respawner.fr/ |