java-gnome-developer Mailing List for The java-gnome language bindings project (Page 4)
Brought to you by:
afcowie
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(37) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(2) |
Feb
(20) |
Mar
(20) |
Apr
(8) |
May
|
Jun
(1) |
Jul
(6) |
Aug
(39) |
Sep
(37) |
Oct
(34) |
Nov
(50) |
Dec
(22) |
2002 |
Jan
(7) |
Feb
(13) |
Mar
(32) |
Apr
(16) |
May
(26) |
Jun
(20) |
Jul
(32) |
Aug
(7) |
Sep
(2) |
Oct
(11) |
Nov
(3) |
Dec
(35) |
2003 |
Jan
(11) |
Feb
(3) |
Mar
(8) |
Apr
(3) |
May
(11) |
Jun
(20) |
Jul
(11) |
Aug
(29) |
Sep
(13) |
Oct
(91) |
Nov
(185) |
Dec
(207) |
2004 |
Jan
(108) |
Feb
(171) |
Mar
(207) |
Apr
(113) |
May
(22) |
Jun
(53) |
Jul
(69) |
Aug
(43) |
Sep
(34) |
Oct
(182) |
Nov
(101) |
Dec
(61) |
2005 |
Jan
(86) |
Feb
(45) |
Mar
(106) |
Apr
(67) |
May
(70) |
Jun
(47) |
Jul
(19) |
Aug
(34) |
Sep
(24) |
Oct
(45) |
Nov
(20) |
Dec
(58) |
2006 |
Jan
(21) |
Feb
(21) |
Mar
(16) |
Apr
(24) |
May
(24) |
Jun
(47) |
Jul
(20) |
Aug
(8) |
Sep
(13) |
Oct
(7) |
Nov
(23) |
Dec
(2) |
2007 |
Jan
|
Feb
(14) |
Mar
(3) |
Apr
(11) |
May
(1) |
Jun
(15) |
Jul
(2) |
Aug
(5) |
Sep
(10) |
Oct
(5) |
Nov
(1) |
Dec
|
2008 |
Jan
|
Feb
(13) |
Mar
(13) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(2) |
Oct
(14) |
Nov
(11) |
Dec
(12) |
2009 |
Jan
(30) |
Feb
(4) |
Mar
(16) |
Apr
(9) |
May
(9) |
Jun
(7) |
Jul
(6) |
Aug
(3) |
Sep
(14) |
Oct
(8) |
Nov
(12) |
Dec
(9) |
2010 |
Jan
(4) |
Feb
(27) |
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(15) |
Oct
(12) |
Nov
(11) |
Dec
(9) |
2011 |
Jan
(12) |
Feb
(11) |
Mar
|
Apr
(3) |
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(8) |
Nov
(1) |
Dec
|
2012 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(2) |
Sep
(7) |
Oct
(7) |
Nov
|
Dec
(4) |
2013 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(3) |
Jun
(3) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Pablo Z. <pab...@ho...> - 2012-02-22 01:54:20
|
Hi! I’d like to use Java with GTK in Microsoft Windows, do you have any information or advice about this? Some (incompatibility) problem could occur? Thank you very much |
From: Guillaume M. <res...@gm...> - 2012-02-10 09:03:59
|
I guess that another interesting topic has been raised here. The problem (to my mind) is not to know if we should make an exception for broken themes. For me, the problem is: should we make "our" applications *crash* if the theme is broken. Most applications written for GNOME do not crash when the theme is broken, shouldn't we do the same (then the question would be "how?")? Making our applications crash if the theme is broken is ensuring that applications will only work with themes that do not have any errors. That is not a bad behaviour but it could be (as we can see) a problem since themes developers are not error proof (and we are not too). What I want to say is sometimes themes developers can miss something making the theme generating warnings. Do we want to make the user pay for that by making the applications crash? Sure it is always a good idea to fix the theme blabla but that's just design to me, making applications crash for design purpose looks like a broken behaviour to me. -- Guillaume Mazoyer - http://respawner.fr/ |
From: Serkan K. <se...@ge...> - 2012-02-07 03:19:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Sorry but I would say we shouldn't make exceptions for the broken themes out there. So report a bug against that theme (or even fix it if you can) Regards, Serkan On 02/06/2012 12:20 PM, cyber python wrote: > First of all, thank you for the quick responses. The way I handle > this for now (though it is clearly not a solution) is by ignoring > any FatalError thrown on Gtk.init(). > > The theme is Adwaita Cupertino SL ( > http://gnome-look.org/content/show.php/Adwaita+Cupertino?content=147061 > > ), but there is a great deal of third party gtk themes that cause > exceptions like this (and since the application I am currently > writing is an IDE for an educational language targeted to > highschool seniors I cannot expect them to know anything about gtk > themes or why warnings are generated). > > Best regards, Georgios Migdos. > > ------------------------------------------------------------------------------ > > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft > developers is just $99.99! Visual Studio, SharePoint, SQL - plus > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases > when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8wmBoACgkQRh6X64ivZaKsIQCfc68NtH/61BDkWo4M0NaiHVG+ IZUAnAlj3GJ5MX2T24y+mOA1S3cXNP1k =R51K -----END PGP SIGNATURE----- |
From: lameire a. <ale...@ho...> - 2012-02-06 18:11:44
|
thanks for your help but the use of DataColumnPixbuff make another problem The ListStore::setValue with the usage of DataColumnPixbuff need the usage of a Pixbuff but to optain it, I must draw it with caro. Cara Context class don't provide any constructor using a Pixbuff to draw into it, In this case i don't know witch classes use and no example describe it? How to solve it, Must I use another classes of Caro ? Thanks for you future respons. Alexis Lameire Le lundi 06 février 2012 à 18:19 +0200, cyber python a écrit : > You can use DataColumnPixbuf, and a CellRendererPixbuf to display an > image (you can create one with ImageIO) filled with the desired color. > To store a reference to the color object you can use > DataColumnReference<Color>. Just remember that the model of the > treeview is meant to be used only for presentation purposes and not to > store your application's model. |
From: cyber p. <cyb...@gm...> - 2012-02-06 16:20:04
|
You can use DataColumnPixbuf, and a CellRendererPixbuf to display an image (you can create one with ImageIO) filled with the desired color. To store a reference to the color object you can use DataColumnReference<Color>. Just remember that the model of the treeview is meant to be used only for presentation purposes and not to store your application's model. On Mon, Feb 6, 2012 at 3:03 PM, lameire alexis <ale...@ho...> wrote: > Hi, > I understood the way to use the model view of treeview widget but i need > a custom use of this widget. > I would like to store in the model a color, that must be shown in the > treeview. > To make this I need first to create my own CellRenderer, i would like to > know how to do this. > Secondly to store my color into the model i need to know how to make my > own DataColumn and finally, how to use it in the listStore model. > > Thanks for your attention > Alexis Lameire > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer |
From: lameire a. <ale...@ho...> - 2012-02-06 13:07:52
|
Hi, I understood the way to use the model view of treeview widget but i need a custom use of this widget. I would like to store in the model a color, that must be shown in the treeview. To make this I need first to create my own CellRenderer, i would like to know how to do this. Secondly to store my color into the model i need to know how to make my own DataColumn and finally, how to use it in the listStore model. Thanks for your attention Alexis Lameire |
From: cyber p. <cyb...@gm...> - 2012-02-06 11:20:31
|
First of all, thank you for the quick responses. The way I handle this for now (though it is clearly not a solution) is by ignoring any FatalError thrown on Gtk.init(). The theme is Adwaita Cupertino SL ( http://gnome-look.org/content/show.php/Adwaita+Cupertino?content=147061 ), but there is a great deal of third party gtk themes that cause exceptions like this (and since the application I am currently writing is an IDE for an educational language targeted to highschool seniors I cannot expect them to know anything about gtk themes or why warnings are generated). Best regards, Georgios Migdos. |
From: Andrew C. <an...@op...> - 2012-02-06 05:20:22
|
On Sun, 2012-02-05 at 16:52 +0200, cyber python wrote: > if there is a way to distinguish warnings thrown as Exceptions. In general, a WARNING coming from a GNOME library means that it was fed an illegal value. We're well accustomed in Java land to having those result in IllegalArgumentExceptions and so that is the behaviour that java-gnome exhibits - after all, using a stack track from an unchecked exception helps us zoom in to where our code went wrong is what we do in Java. Of course, you're talking about a WARNING that manifestly is not caused by your code. I agree a stack trace is less useful in that situation, but I'm not sure we can tell the difference. Maybe we can. I'm open to ideas; if someone can figure out a way to differentiate stack frames that came from our (your) code vs not then I'd be happy to merge it. Otherwise, you'll need to fix the theme to not misuse GTK. That's probably a good idea anyway. WARNINGs to some people are CRITICALs to others; either way, after such a message appears you can be pretty sure the library in question has washed its hands of any expectation that further processing will be correct. Indeed, the working definition of CRITICAL I was given some years back was "from here on, the program is in an undefined state" (ouch!) and that any further operations would be grunted to segfault in fairly short order - in other words, you've got half a chance to put a breakpoint in there and meanwhile your app is going to thunder in any second now. In my experience a WARNING message amounts to the same. Of course there is no consistency about this, which makes our job (a language binding) difficult. AfC Sydney |
From: Guillaume M. <res...@gm...> - 2012-02-06 00:09:19
|
2012/2/5 cyber python <cyb...@gm...>: > I am writing an application using java-gnome and if a gtk theme that > causes warnings is used the whole application crashes thus I'd like to > know if there is a way to distinguish warnings thrown as Exceptions. I never had such a problem. If the warning are actually generated by the theme then maybe we are making something wrong. The warnings that become Exceptions are due to an internal code inside the bindings. I don't remember where (maybe someone knows where it is). Do you have a link where we can download the theme that you think is causing problem so we can test it? -- Guillaume Mazoyer - http://respawner.fr/ |
From: cyber p. <cyb...@gm...> - 2012-02-05 14:52:42
|
Hello, I am writing an application using java-gnome and if a gtk theme that causes warnings is used the whole application crashes thus I'd like to know if there is a way to distinguish warnings thrown as Exceptions. Best regards, Georgios Migdos. |
From: Guillaume M. <res...@gm...> - 2011-11-04 16:47:28
|
Hello, Several Ubuntu and Debian users reported the crasher due to a ClassCastException with the Box inside a Dialog. The fix now lands in mainline but the package in the Debian and Ubuntu repository doesn't contain this fix. So I have backported that fix in new package in the PPA[1] in this way the Ubuntu users will be able to get the crasher fixed. For Debian this will have to wait for the 4.1.2 release ;) Cheers, [1] https://launchpad.net/~java-gnome/+archive/ppa -- Guillaume Mazoyer |
From: William T. <wil...@gm...> - 2011-10-24 11:20:39
|
On 23 October 2011 15:55, Vreixo Formoso Lopes <met...@ya...> wrote: > Hi all, > > please correct me if I'm wrong, I haven't looked at this since one or two years, but I am pretty > > sure about the reason for the leak in the test code. As it never enters gtk main loop, our reference > to the underlying GdkPixbuf object is never released. That is because we release it in a g_idle > function that is only executed inside the gtk main loop. So just doing: > > > while (Gtk.eventsPending()) { > Gtk.mainIterationDo(false); > } > > after Pixbuf creation will solve the memory leak. I've tested it and it works. > > Thanks very much indeed Vrexio, I can confirm running this code after this fixes the issue in the test and my application. My app is unusual as it does not have a Gtk.main() loop, presumably I would not have seen this issue if it did. Best regards, Will Temperley |
From: Vreixo F. L. <met...@ya...> - 2011-10-23 14:55:19
|
Hi all, please correct me if I'm wrong, I haven't looked at this since one or two years, but I am pretty sure about the reason for the leak in the test code. As it never enters gtk main loop, our reference to the underlying GdkPixbuf object is never released. That is because we release it in a g_idle function that is only executed inside the gtk main loop. So just doing: while (Gtk.eventsPending()) { Gtk.mainIterationDo(false); } after Pixbuf creation will solve the memory leak. I've tested it and it works. *** Details hereafter, you can skip this unless you understand our memory management system. Please note I may be forgetting something, it was a long time ago since the last look I took at this stuff. **** So, let's start. When the Pixbuf is created, a native gdk function is invoked, which in turn returns a GObject WE OWN. When the Proxy is created, java side, in org.gnome.glib.Object we invoke GObject.addToggleRef. This adds a new gtk ref (toggle ref) together with a strong ref in java. At this moment, we hold two native ref to the GdkPixbuf (the original plus the toggle) and two java refs (the one corresponding to the pb ref in our code plus the internal one). All this happens in bindings_java_memory_ref. Of course, our original ref is no longer needed (we already hold the toggle ref) so we dispose it. However, we do that in a g_idle function, to avoid the toggle ref for being "toggled" unnecessarily (ok, unnecessarily in most cases, where the object is right next added to a container). In this case, as the main loop was never executed, the original ref was never removed. Back in our code, after one loop step, the pb var is out of scope. However, we still keep the additional java ref, so the Pixbuf object never goes out of scope java side, so the GC never collects it. Note that this extra ref is released (actually turned weak) after the toggle ref is the last one, which happens when both the main loop is executed (and thus original ref is removed), and pb goes out of scope. I hope I have explained it properly, just comment here if you need more details. Cheers Vreixo PS: AfC, I think I need a chat with you this week about builder related stuff. I hope we both have time for that. ----- Mensagem original ----- De: William Temperley <wil...@gm...> Para: java-gnome-developer <jav...@li...> Cc: Enviadas: Quarta-feira, 19 de Outubro de 2011 19:01 Assunto: [Java-gnome-developer] Pixbuf memory leak Hi all, I've come across a memory leak with Pixbuf - whenever I construct one, lots of memory is leaked. The test below leaks ~200MB when loading a 6kb image 10,000 times. Commenting out the Pixbuf construction leads to steady memory use. This memory usage isn't reported by the JVM. I've come across this behaviour with 4.0.19 and 4.1.1. Whilst I'd love a proper solution to this, I wonder if anyone has a quick and dirty workaround for freeing up this memory? I'm doing a production run of approximately 6000 maps for a website, which grinds to a halt after 100 or so maps, using all 8GB of RAM. Thanks Will Temperley @Test public void itLeaks() throws IOException { Gtk.init(null); for (int i = 0; i < 10000; i++) { System.out.println(i); BufferedImage b = ImageIO.read(new File("/tmp/x.png")); ByteArrayOutputStream bos = new ByteArrayOutputStream(); ImageIO.write(b, "PNG", bos); byte[] arr = bos.toByteArray(); //comment out and memory usage remains steady Pixbuf pb = new Pixbuf(arr); } } ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ java-gnome-developer mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-developer |
From: Andrew C. <an...@op...> - 2011-10-23 09:01:21
|
On Fri, 2011-10-21 at 10:09 +0100, William Temperley wrote: > I'm fairly sure it's Pixbuf that's causing this. For a bit of > background, I do a lot of drawing hefty polygons onto Cairo canvases > and draw images using the Pixbuf. Hm. Have you considered using a Cairo ImageSurface? You can write images with that. AfC Mount Wilson |
From: William T. <wil...@gm...> - 2011-10-21 09:09:50
|
On 20 October 2011 01:46, Andrew Cowie <an...@op...> wrote: > On Wed, 2011-10-19 at 18:01 +0100, William Temperley wrote: >> I wonder if anyone has a >> quick and dirty workaround for freeing up this memory? I'm doing a >> production run of approximately 6000 maps for a website, which grinds >> to a halt after 100 or so maps, using all 8GB of RAM. > > Eek. That's no good. > I've had to resort to scripting the app with Python to do batches - ugly but works! > > The problem, I think is: > > a) that GLib allocated memory is outside the visibility of the JVM > > cross product > > b) the JVM garbage collector only runs when *it* thinks that it is out > of memory. > > This second point is somewhat counter to expectation, but of late I've > noticed that Java doesn't "waste" time with full GC (let alone actual > page release back to host OS) until it thinks it is a last resort. I've found that Linux has been killing my large process when all memory and virtual memory has gone. I guess this could be due to either the JVM not knowing the proxy objects are huge and should be cleaned up, or the memory has been leaked by the proxies. > Anyway, the side effect of (a) × (b) is that our GObjects don't get > free'd until Java processes the Proxy object being out of scope and they > are finalized; that doesn't happen until the GC has done its thing. The > objects *will* get freed, but when is open to question. > > So as an immediate debug, I would ask what the effect of sticking a > System.gc() in right after your Pixbuf goes out of scope. I know we've > all been trained out of making that call over the years, but it might be > worth offering the hint. I've just tried that and I'm still seeing the same memory increases unfortunately. This didn't work in > > If that doesn't work, we'll look deeper. If it does work, we'll look > deeper. > I'm fairly sure it's Pixbuf that's causing this. For a bit of background, I do a lot of drawing hefty polygons onto Cairo canvases and draw images using the Pixbuf. When isolating the leak by commenting out code (having had no luck with profilers as they don't see the allocated native memory) I ran the app with Pixbufs being constructed but not used and got massive memory use. Commenting out the construction of the Pixbuf - i.e. just one line - lead to steady memory usage. OTOH, The good news is I've been doing some fairly hefty work creating and destroying hundreds of Cairo canvases and drawing massive polygons on them (some with over 60,000 vertices) and I've not seen leaks with these. Will |
From: Andrew C. <an...@op...> - 2011-10-20 01:13:18
|
On Wed, 2011-10-19 at 18:01 +0100, William Temperley wrote: > I wonder if anyone has a > quick and dirty workaround for freeing up this memory? I'm doing a > production run of approximately 6000 maps for a website, which grinds > to a halt after 100 or so maps, using all 8GB of RAM. Eek. That's no good. So after 6+ years at this, we're all starting to hit production usage where we stress the memory management system. Java's behaviour hasn't always been pretty. The problem, I think is: a) that GLib allocated memory is outside the visibility of the JVM cross product b) the JVM garbage collector only runs when *it* thinks that it is out of memory. This second point is somewhat counter to expectation, but of late I've noticed that Java doesn't "waste" time with full GC (let alone actual page release back to host OS) until it thinks it is a last resort. (in other words, there's sorta an enterprise-y assumption that it's the only big thing running, so it doesn't need to be in a rush to return resources. If OOM killer comes along and asks for pages then the JVM has lots to offer, but until then you just get enormous VSZ sizes. I'm not über thrilled about this.) Anyway, the side effect of (a) × (b) is that our GObjects don't get free'd until Java processes the Proxy object being out of scope and they are finalized; that doesn't happen until the GC has done its thing. The objects *will* get freed, but when is open to question. So as an immediate debug, I would ask what the effect of sticking a System.gc() in right after your Pixbuf goes out of scope. I know we've all been trained out of making that call over the years, but it might be worth offering the hint. If that doesn't work, we'll look deeper. If it does work, we'll look deeper. AfC Sydney |
From: William T. <wil...@gm...> - 2011-10-19 17:02:02
|
Hi all, I've come across a memory leak with Pixbuf - whenever I construct one, lots of memory is leaked. The test below leaks ~200MB when loading a 6kb image 10,000 times. Commenting out the Pixbuf construction leads to steady memory use. This memory usage isn't reported by the JVM. I've come across this behaviour with 4.0.19 and 4.1.1. Whilst I'd love a proper solution to this, I wonder if anyone has a quick and dirty workaround for freeing up this memory? I'm doing a production run of approximately 6000 maps for a website, which grinds to a halt after 100 or so maps, using all 8GB of RAM. Thanks Will Temperley @Test public void itLeaks() throws IOException { Gtk.init(null); for (int i = 0; i < 10000; i++) { System.out.println(i); BufferedImage b = ImageIO.read(new File("/tmp/x.png")); ByteArrayOutputStream bos = new ByteArrayOutputStream(); ImageIO.write(b, "PNG", bos); byte[] arr = bos.toByteArray(); //comment out and memory usage remains steady Pixbuf pb = new Pixbuf(arr); } } |
From: <pab...@gm...> - 2011-10-11 18:08:33
|
Hi all, how are you? I'm trying to access e-d-s contacts from a Java application, but I haven't found any way of doing it and I was wondering whether there's any wrapper for libecal or something like that. Any help would be appreciated. Thanks in advance. Pablo. |
From: George C. <y29...@gm...> - 2011-10-09 19:25:34
|
Why is GObject class only accessible from within the package? |
From: Guillaume M. <res...@gm...> - 2011-09-03 14:40:30
|
After releasing the last version of my program[1] a user reported a strange bug caused by the interruption of the GTK main loop. Basically, my program provides an Assistant so the user is guided to split or merge files. In the last page of the assistant, when confirming the split/merge the main window is refreshed with some new data and a thread is started to proceed to the requested action. The tricky point is that the window *must* be fully refreshed before the thread starts. So when the interface is not fully refreshed an error message is displayed and the action is canceled. The origin of the bug I had was just this. The thread interrupted and started before the GTK main loop finish the refresh of the UI. It is invisible to the user because all of this occurs pretty quickly. I finally found a fix for that using 2 recently exposed methods: - Gtk.eventsPending() - Gtk.mainIterationDo() You can take a look at the fix by following this link: - http://trac.gnome-split.org/changeset/265 or by grabbing the code. This fix forces the GTK main loop to run until there is no more things to proceed. What do you think about this fix? -- Guillaume Mazoyer |
From: Andrew C. <an...@op...> - 2011-07-11 04:46:17
|
There's a new version of java-gnome! Release notes http://java-gnome.sourceforge.net/NEWS.html#4.1.1 Tarball http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.1/java-gnome-4.1.1.tar.bz2 The java-gnome 4.1 series depends on GNOME 3. ++ Simultaneously there has also been the release of 4.0.20, It is meant as a porting aide to help you cross from GTK 2.x to GTK 3.x. If your code builds cleanly against 4.0.20 then you should be ok when your system upgrades to GTK 3.0 and you install java-gnome 4.1 which builds against it. We're not really planning on making any more releases in the 4.0 series, but if someone backports an improvement or serious bugfix then of course we'll do our best to merge it. ++ Meanwhile, new development in the '4.1' series is welcome. See HACKING :) AfC Sydney |
From: Andrew C. <an...@op...> - 2011-06-20 03:44:05
|
We've got an API break coming up, and to support that I've completed a minor refactoring of the java-gnome website. What used to be http://java-gnome.sourceforge.net/4.0/lists/ is now http://java-gnome.sourceforge.net/lists/ This was a good idea because we're about to have 4.1 API documentation and I wanted it to be available in parallel with the [old] 4.0 API documentation, ie instead of http://java-gnome.sourceforge.net/4.0/doc/api/ we now have http://java-gnome.sourceforge.net/doc/api/4.0/ and http://java-gnome.sourceforge.net/doc/api/4.1/ Thought you might want to know. There's a redirect in place. 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/ |
From: Waldemar B. <wb...@gm...> - 2011-06-18 14:42:01
|
File f = new File("file.glade"); FileInputStream fis = new FileInputStream(f); .... Just the usual stuff ;) Am 18.06.2011 16:31, schrieb RAGHAVENDRA T: > Java_Gnome Library classes appears to parse only the libglade files. > Is there a method to use the Glade glade file generated by Glade 3.6. > The file generated by Glade 3.6 is compatible without parsing. > > So is there a method to load a file without parsing it. > > Thanks > Raghavendra > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > > > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer |
From: RAGHAVENDRA T <tra...@gm...> - 2011-06-18 14:31:13
|
Java_Gnome Library classes appears to parse only the libglade files. Is there a method to use the Glade glade file generated by Glade 3.6. The file generated by Glade 3.6 is compatible without parsing. So is there a method to load a file without parsing it. Thanks Raghavendra |
From: Andrew C. <an...@op...> - 2011-04-28 13:50:08
|
On Tue, 2011-04-26 at 11:08 -0600, Adam Balan wrote: > My issue is that when I close one window I don’t want all my windows > to close. Current I am using Gtk.mainQuit(); to close windows. To force a Window to "close", call Widget's hide() on the Window you're finished with. // I'm done window.hide(); http://java-gnome.laptop/4.0/doc/api/org/gnome/gtk/Widget.html#hide() java-gnome takes care of the interaction between the underlying GObject and our Java Proxy object; actual disposal of the Window won't happen until all your Java references to the Window go out of scope (else you could resurrect it with show(), right?) AfC Ko Phi Phi P.S. Hackers: it is probable that Widget's destroy() method newly available in 4.0.20 will have the same effect; someone needs to enable reference management debugging and test the has-user-ref interaction. See src/bindings/org/gnome/gtk/GtkWindowOverride.c |