java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 2)
Brought to you by:
afcowie
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(102) |
Sep
(43) |
Oct
(32) |
Nov
(43) |
Dec
(51) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(6) |
Feb
(19) |
Mar
(39) |
Apr
(22) |
May
|
Jun
(11) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(73) |
2004 |
Jan
(88) |
Feb
(141) |
Mar
(116) |
Apr
(69) |
May
(199) |
Jun
(53) |
Jul
(90) |
Aug
(23) |
Sep
(11) |
Oct
(212) |
Nov
(57) |
Dec
(61) |
2005 |
Jan
(88) |
Feb
(17) |
Mar
(21) |
Apr
(50) |
May
(44) |
Jun
(33) |
Jul
(21) |
Aug
(37) |
Sep
(39) |
Oct
(43) |
Nov
(40) |
Dec
(15) |
2006 |
Jan
(21) |
Feb
(69) |
Mar
(23) |
Apr
(6) |
May
(29) |
Jun
(19) |
Jul
(17) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(9) |
Dec
(7) |
2007 |
Jan
(30) |
Feb
(39) |
Mar
(1) |
Apr
(12) |
May
(53) |
Jun
(30) |
Jul
(39) |
Aug
(75) |
Sep
(16) |
Oct
(13) |
Nov
(20) |
Dec
(5) |
2008 |
Jan
(8) |
Feb
(14) |
Mar
(33) |
Apr
(7) |
May
(22) |
Jun
(23) |
Jul
(17) |
Aug
(9) |
Sep
(9) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
2009 |
Jan
(20) |
Feb
(38) |
Mar
(9) |
Apr
(15) |
May
(30) |
Jun
(35) |
Jul
(22) |
Aug
(10) |
Sep
(7) |
Oct
(23) |
Nov
(6) |
Dec
(8) |
2010 |
Jan
(5) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(15) |
Sep
(14) |
Oct
(26) |
Nov
(11) |
Dec
(14) |
2011 |
Jan
(10) |
Feb
(8) |
Mar
(6) |
Apr
(7) |
May
(18) |
Jun
(17) |
Jul
(6) |
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(10) |
2012 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(5) |
Aug
(14) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andrew C. <an...@op...> - 2012-08-21 09:23:07
|
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. 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. 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. Perhaps you'll give it a try. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-16 01:30:19
|
On Tue, 2012-08-14 at 15:35 +1000, Andrew Cowie wrote: > Can we make another one that shadows the one in [org.gnome.glib] > Application? Done. > Initialization > -------------- > > So this is an interesting question. The documentation for > gtk_application_new() says it calls gtk_init() for you. Hm. Translated, > that implies that {java-gnome-}developers should not be calling > Gtk.init() anymore, which of course is **absolutely obligatory** at the > moment because it causes all the C side JNI setup to be done. > The docs for gtk_application_new() allow that it's ok that gtk_init() would have been called already. We'll need to refine this, but we can get away with it for now. > I've done some minor documentation changes and cleanup; if you could > merge from 'hackers/andrew/application' that would be good. Pushed to bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/application/ Further, I've taken a stab at porting Slashtime to use this GtkApplication coverage. If you want to test it, see bzr://research.operationaldynamics.com/bzr/slashtime/application Comments? AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-14 05:35:40
|
On Mon, 2012-07-23 at 13:29 +0200, Guillaume Mazoyer wrote: > deprecating libunique and replace it with the new (well, not so new) > GtkApplication class. It is actually a thing that we *have to* do [1]. > I have started a branch about it and you can find it at > `hackers/guillaume/gtk-application' [2]. Ok, we have a working test suite again, so at last I've been able to start reviewing your branch. Fantastic of you to have undertaken getting this code going. Namespaces ---------- This is a bit unfortunate: a.connect(new Application.Activate() { public void onActivate(org.gnome.glib.Application source) { System.out.println("Activated"); } }); Can we make another one that shadows the one in [org.gnome.glib] Application? My inclination is actually to go a bit further, and make the methods in [org.gnome.glib] Application protected, and publicly exposed on [org.gnome.gtk] Application. Sure you can use GApplication by itself, but would you ever really? Maybe someone can say, but my sense of it is that you're only supposed to use GtkApplication in practice. The documentation for GApplication says "In general, you should not use this class outside of a higher level framework." so I think I'm on the right track. Initialization -------------- So this is an interesting question. The documentation for gtk_application_new() says it calls gtk_init() for you. Hm. Translated, that implies that {java-gnome-}developers should not be calling Gtk.init() anymore, which of course is **absolutely obligatory** at the moment because it causes all the C side JNI setup to be done. I imagine we'll need to adjust that somewhat, but to what? Maybe we change the manual call to "gtk_init()" [which has all kinds of gumpf in it] to (effectively) bindings_java_init(). Then we can even have that called by a static block somewhere. Presumably Gtk.init() still has to work for people not using GtkApplication. Branch ------ I've done some minor documentation changes and cleanup; if you could merge from 'hackers/andrew/application' that would be good. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-13 23:19:37
|
On Mon, 2012-08-13 at 17:14 +0200, Sarah Leibbrand wrote: > Ok so I ran the `make test` command and got it down to 3 errors within > 2 test cases. > It is kinda silly but my Enchant library doesn't know the 'en' > dictionary. Instead it finds 6 en_XX (e.g. en_GB) dictionaries. Hm. I think that must have to do with what back ends are actually installed on the system. For whatever reason I have an "en" (in addition to "en_CA", "en_GB", etc). - if (tag.equals("en")) { + if (tag.equals("en") || tag.startsWith("en_")) { Just change this to if (tag.startsWith("en")) { should cover all the bases. But before we change - result = Enchant.existsDictionary("en"); + result = Enchant.existsDictionary("en") || Enchant.existsDictionary("en_GB") || Enchant.existsDictionary("en_US"); I'd really like to know why you're not finding "en". It's supposed to be provided by something if there is an English dictionary present. And as for this test case, the point was "a dictionary known to exist" and asking for four options like that is messy. If we *do* have to do that, then it should probably be in a helper function like: result = Enchant.existsDictionary("en"); if (result != null) { return result; } result = Enchant.existsDictionary("en_GB"); if (result != null) { return result; } ... fail("Known good dictionary not found"); Still want to know why I have an "en" and you don't. AfC |
From: Andrew C. <an...@op...> - 2012-08-13 00:53:40
|
On Mon, 2012-08-13 at 09:28 +1000, Andrew Cowie wrote: > That one is starting to get on my nerves. I've tried running > ValidateInternationalization as a test by itself and the test case > *passes*. > > I run it in as the UnitTests suite, and it *fails*. Ok, I've made some tentative progress. The relevant commit message: Force static initalizers and/or library initialization code in setUp() Move initializers, being run once in an initial test case, to a setUp() block. I'm a bit vague as to why this is necessary; it would seem that JUnit or Java 7 is being stricter about its classloading, so we need to force the static initializers to run every test. This is somewhat surprising, but seems a workaround. It's more "correct" JUnit in any event. Go figure. Anyway, the test suite is passing for me now, although I also had to do === modified file 'tests/bindings/org/gnome/gtk/ValidateEntry.java' --- tests/bindings/org/gnome/gtk/ValidateEntry.java 2010-05-14 23:50:09 +0000 +++ tests/bindings/org/gnome/gtk/ValidateEntry.java 2012-08-12 23:12:22 +0000 @@ -26,7 +26,7 @@ */ public class ValidateEntry extends GraphicalTestCase { - public final void testEntryIcon() { + public final void skipEntryIcon() { final Entry entry; entry = new Entry(); because that test depends on GTK 3.4.4 which has the fix for https://bugzilla.gnome.org/show_bug.cgi?id=679537 which I don't have at the moment. Should I commit that to 'mainline'? Doesn't seem so, but you'll need it... AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 23:30:09
|
On Mon, 2012-07-23 at 13:29 +0200, Guillaume Mazoyer wrote: > Well you can take a look at the current branch and give me some > feedback so it can be improved to be pushed in mainline. I want to review this branch, but I can't get java-gnome to pass its test suite at the moment; a green bar is really kinda prerequisite to merging new development :( If anyone has suggestions, your help would be really appreciated. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 23:28:35
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > Number of tests seem to want to write to a directory that does not > exist, and thus error out.. Ah. Yeah, that makes sense; you need to have run `make test` at least once before testing from your IDE. That will compile the message catalogue to tmp/locale/en_US/LC_MESSAGES/unittest.mo. > 2 silly ones that I am not quite sure of, getting Login/Logoff > instead of Hello/Goodbye. That one is starting to get on my nerves. I've tried running ValidateInternationalization as a test by itself and the test case *passes*. I run it in as the UnitTests suite, and it *fails*. I don't know if anyone has any time to look at this, but Vreixo? Serkan? Guillaume? I sure could use your help on this one. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 23:24:52
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > `doc/examples` as a source directory. the class textview.LoremIpsum > was used in 2 tests and is present in there. Why ?! I fail to see the > point to set it there when needed in the tests. Hm. Well, it's not part of the unit tests. The constant text there _is_ used in the Snapshot code that generates images for the API documentation. Anyway, I'd just add doc/examples/ as one of the source trees in your IDE's project. `make test` does the right thing. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-08-12 10:35:33
|
On Fri, 2012-08-10 at 11:07 +0200, Sarah Leibbrand wrote: > Below are the unit tests results. Thanks. I'm getting similar failures, but what's driving me nuts is that they are appearing and not appearing depending on whether I run from Eclipse, or from command line. Worse, at least one test when run individually passes, but when run in the suite fails. My initial guess is that something different is happening in the class loader, but I can't even begin to guess what that might be. AfC Sydney |
From: Sarah L. <xa...@gm...> - 2012-08-10 09:07:29
|
Heya all On the request of the AfC I ran the unit tests and got 5 failures + 5 errors. However for them to run I had to add the directory `doc/examples` as a source directory. the class textview.LoremIpsum was used in 2 tests and is present in there. Why ?! I fail to see the point to set it there when needed in the tests. Kinda defeats the point of being a class for tests or examples, as it seems to be used by both. I think it should be relocated. Below are the unit tests results. I do use the IDE netbeans here. Number of tests seem to want to write to a directory that does not exist, and thus error out.. 2 silly ones that I am not quite sure of, getting Login/Logoff instead of Hello/Goodbye. Anyway I hope this output is useful at least. Kind Regards, Thijs Leibbrand Testsuite: UnitTests Tests run: 267, Failures: 5, Errors: 5, Time elapsed: 11.01 sec Testcase: testInitialization(org.freedesktop.bindings.ValidateInternationalization): Caused an ERROR The supplied locale base dir "tmp/locale" is not found org.freedesktop.bindings.FatalError: The supplied locale base dir "tmp/locale" is not found at org.freedesktop.bindings.Internationalization.init(Internationalization.java:550) at org.freedesktop.bindings.ValidateInternationalization.testInitialization(ValidateInternationalization.java:83) Testcase: testTranslation(org.freedesktop.bindings.ValidateInternationalization): FAILED expected:<[Hello]> but was:<[login]> junit.framework.ComparisonFailure: expected:<[Hello]> but was:<[login]> at org.freedesktop.bindings.ValidateInternationalization.testTranslation(ValidateInternationalization.java:87) Testcase: testStaticWrapper(org.freedesktop.bindings.ValidateInternationalization): FAILED expected:<[Goodbye]> but was:<[logoff]> junit.framework.ComparisonFailure: expected:<[Goodbye]> but was:<[logoff]> at org.freedesktop.bindings.ValidateInternationalization.testStaticWrapper(ValidateInternationalization.java:95) Testcase: testUsingMimeDataViaPattern(org.freedesktop.cairo.ValidateCairoInternals): Caused an ERROR You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType2.svg java.io.IOException: You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType2.svg at org.freedesktop.cairo.SvgSurface.<init>(SvgSurface.java:80) at org.freedesktop.cairo.ValidateCairoInternals.testUsingMimeDataViaPattern(ValidateCairoInternals.java:195) Testcase: testUsingMimeDataExplicit(org.freedesktop.cairo.ValidateCairoInternals): Caused an ERROR You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType1.svg java.io.IOException: You cannot write to file tmp/tests/org/freedesktop/cairo/MimeType1.svg at org.freedesktop.cairo.SvgSurface.<init>(SvgSurface.java:80) at org.freedesktop.cairo.ValidateCairoInternals.testUsingMimeDataExplicit(ValidateCairoInternals.java:132) Testcase: testCovertCoordinatesRoundTrip(org.gnome.gtk.ValidateTextViewBorderWindows): FAILED null junit.framework.AssertionFailedError at org.gnome.gtk.ValidateTextViewBorderWindows.testCovertCoordinatesRoundTrip(ValidateTextViewBorderWindows.java:103) Testcase: testWidthAndHeightNormalization(org.gnome.pango.ValidatePangoTextRendering): Caused an ERROR Cairo reports it cannot open tmp/tests/org/gnome/pango/ValidatePangoTextRendering.pdf for writing java.io.IOException: Cairo reports it cannot open tmp/tests/org/gnome/pango/ValidatePangoTextRendering.pdf for writing at org.freedesktop.cairo.PdfSurface.<init>(PdfSurface.java:101) at org.gnome.pango.ValidatePangoTextRendering.testWidthAndHeightNormalization(ValidatePangoTextRendering.java:111) Testcase: testListAllDictionaries(org.freedesktop.enchant.ValidateEnchantInternals): FAILED Needed to find at least "en" as a dictionary! junit.framework.AssertionFailedError: Needed to find at least "en" as a dictionary! at org.freedesktop.enchant.ValidateEnchantInternals.testListAllDictionaries(ValidateEnchantInternals.java:57) Testcase: testDictionaryKnownToExist(org.freedesktop.enchant.ValidateEnchantInternals): FAILED null junit.framework.AssertionFailedError at org.freedesktop.enchant.ValidateEnchantInternals.testDictionaryKnownToExist(ValidateEnchantInternals.java:64) Testcase: testHandleRendering(org.gnome.rsvg.ValidateVectorIllustrations): Caused an ERROR You cannot write to file tmp/tests/org/gnome/rsvg/Linux_Tux.png java.io.IOException: You cannot write to file tmp/tests/org/gnome/rsvg/Linux_Tux.png at org.freedesktop.cairo.Surface.writeToPNG(Surface.java:118) at org.gnome.rsvg.ValidateVectorIllustrations.testHandleRendering(ValidateVectorIllustrations.java:110) Test UnitTests FAILED test: Deleting: /tmp/TEST-UnitTests.xml BUILD SUCCESSFUL (total time: 17 seconds) |
From: Guillaume M. <res...@gm...> - 2012-07-23 11:30:16
|
Hi, Since several weeks (months) we have started to think about deprecating libunique and replace it with the new (well, not so new) GtkApplication class. It is actually a thing that we *have to* do [1]. I have started a branch about it and you can find it at `hackers/guillaume/gtk-application' [2]. I have to chosen to not expose the open-files and command-line signals. I think that we can live without for now but we still need to think about all of this in a near future. Well you can take a look at the current branch and give me some feedback so it can be improved to be pushed in mainline. [1] https://bugzilla.gnome.org/show_bug.cgi?id=658400 [2] http://research.operationaldynamics.com/bzr/java-gnome/hackers/guillaume/gtk-application/ -- Guillaume Mazoyer - http://respawner.fr/ |
From: Serkan K. <se...@ge...> - 2012-07-21 20:35:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I might be sounding too "enterprise" but I don't think we should enforce 7 unless there's a real valid reason. Not like "Go use the latest version you fool". But I agree that we should opt out 5 since Sun has EOLed it. Regards, Serkan On 07/17/2012 04:47 AM, Andrew Cowie wrote: > On Tue, 2012-07-17 at 00:38 +0200, Serkan Kaba wrote: >> I would immediately need a patch for Gentoo if we follow this >> path. Build system must ensure that it builds bytecode targeted >> for oldest version possible. If we don't supply these parameters >> we can't guarantee that this is the case. > > That's what I thought. We'll leave those two parameters in then. > >> But this doesn't mean we can bump the oldest version we support >> by changing these numbers. > > Ok. > > So should we say "Java 7 is minimum" now, or is someone going to > say that we should be resting on 6? > > AfC Sydney > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ java-gnome-hackers > mailing list jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlALEpQACgkQRh6X64ivZaLHVwCfYxofY+Xc7t+LmDPOGGV1y72K kcEAnAqc1KCOwAXFgjkv5U8HAz7qOcaL =Qp0i -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2012-07-17 02:47:27
|
On Tue, 2012-07-17 at 00:38 +0200, Serkan Kaba wrote: > I would immediately need a patch for Gentoo if we follow this path. > Build system must ensure that it builds bytecode targeted for oldest > version possible. If we don't supply these parameters we can't > guarantee that this is the case. That's what I thought. We'll leave those two parameters in then. > But this doesn't mean we can bump the oldest version we support by > changing these numbers. Ok. So should we say "Java 7 is minimum" now, or is someone going to say that we should be resting on 6? AfC Sydney |
From: Serkan K. <se...@ge...> - 2012-07-16 22:38:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would immediately need a patch for Gentoo if we follow this path. Build system must ensure that it builds bytecode targeted for oldest version possible. If we don't supply these parameters we can't guarantee that this is the case. But this doesn't mean we can bump the oldest version we support by changing these numbers. Regards, Serkan On 07/02/2012 10:50 AM, Andrew Cowie wrote: > For a long time we're added > > -source 1.5 -target 1.5 > > to the compiler line; this was largely based on our experiences in > Gentoo land where different bytecode versions really weren't as > forward-compatible as you'd think. > > Here we are in the era of Java 7; should we be dropping these > flags entirely and just letting the distro build environment do > what it thinks best? I'm inclined to, but we [or more to the point, > our developers] have been burned by this in the past. > > AfC Sydney > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions will include endpoint security, mobile security and the > latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ java-gnome-hackers > mailing list jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAEl+AACgkQRh6X64ivZaJKwACdGGckdgUXjMdYtqmIwgNZlgDc K3AAn0ZLFkK4K13QaAfRtBgDLuvrLy7s =8s+H -----END PGP SIGNATURE----- |
From: Andrew C. <an...@op...> - 2012-07-02 08:50:27
|
For a long time we're added -source 1.5 -target 1.5 to the compiler line; this was largely based on our experiences in Gentoo land where different bytecode versions really weren't as forward-compatible as you'd think. Here we are in the era of Java 7; should we be dropping these flags entirely and just letting the distro build environment do what it thinks best? I'm inclined to, but we [or more to the point, our developers] have been burned by this in the past. AfC Sydney |
From: Andrew C. <an...@op...> - 2012-05-27 10:21:14
|
We're going to release 4.1.2 this week. If anyone has a patch they'd like in, please give us a shout. AfC Sydney |
From: Georgios M. <cyb...@gm...> - 2012-04-04 16:29:31
|
On 04/04/2012 06:26 PM, Andrew Cowie wrote: > On Tue, 2012-04-03 at 23:03 +0300, Georgios Migdos wrote: >>> Merged to 'mainline' >>> > And so it was; if you'd done > > $ bzr missing --line bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ > > you'd have seen your patch was there. > > In this case, sorry, after pushing I have to manually do `bzr update` on > the working copy checkout on that server; `bzr push` doesn't do that > automatically [which I find annoying, alas]. Sometimes I haven't quite > managed to get around to it. Thanks for checking. > > AfC > Sydney > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers Thanks for the quick reply! |
From: Andrew C. <an...@op...> - 2012-04-04 15:53:52
|
On Tue, 2012-04-03 at 23:03 +0300, Georgios Migdos wrote: > > Merged to 'mainline' > > And so it was; if you'd done $ bzr missing --line bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ you'd have seen your patch was there. In this case, sorry, after pushing I have to manually do `bzr update` on the working copy checkout on that server; `bzr push` doesn't do that automatically [which I find annoying, alas]. Sometimes I haven't quite managed to get around to it. Thanks for checking. AfC Sydney |
From: Georgios M. <cyb...@gm...> - 2012-04-03 20:03:26
|
On 02/13/2012 02:28 AM, Andrew Cowie wrote: > On Tue, 2012-02-07 at 05:09 +0100, Guillaume Mazoyer wrote: >> Here is the patch that I would actually propose. > Merged to 'mainline' > > AfC > Sydney Hello everyone! I was browsing through the code in mainline ( http://research.operationaldynamics.com/bzr/java-gnome/mainline/src ) using the web interface and it seems that the patch has not been applied. |
From: Andrew C. <an...@op...> - 2012-02-13 00:28:57
|
On Tue, 2012-02-07 at 05:09 +0100, Guillaume Mazoyer wrote: > Here is the patch that I would actually propose. Merged to 'mainline' AfC Sydney |
From: Guillaume M. <res...@gm...> - 2012-02-07 04:10:02
|
Here is the patch that I would actually propose. -- Guillaume Mazoyer - http://respawner.fr/ |
From: Guillaume M. <res...@gm...> - 2012-02-07 04:08:41
|
---------- Forwarded message ---------- From: cyber python <cyb...@gm...> Date: 2012/2/6 Subject: Re: [java-gnome-hackers] Style schemes for GtkSourceview To: Guillaume Mazoyer <res...@gm...> I think I've got it right this time. See the attachment for the patch. On Mon, Feb 6, 2012 at 1:38 PM, Guillaume Mazoyer <res...@gm...> wrote: > This patch looks ok to me. > Just a couple of things that you could fix easily. > > 1. re-run the code formatter (some javadoc comments are not well indented) > 2. for the classes where you do not define a public constructor maybe > you should make the default constructor "private" to avoid someone to > do "new Something()". > > Once these things fixed, the patch would be mergeable :) > > -- > Guillaume Mazoyer - http://respawner.fr/ > > ------------------------------------------------------------------------------ > 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-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers -- Guillaume Mazoyer - http://respawner.fr/ |
From: Guillaume M. <res...@gm...> - 2012-02-06 11:38:58
|
This patch looks ok to me. Just a couple of things that you could fix easily. 1. re-run the code formatter (some javadoc comments are not well indented) 2. for the classes where you do not define a public constructor maybe you should make the default constructor "private" to avoid someone to do "new Something()". Once these things fixed, the patch would be mergeable :) -- Guillaume Mazoyer - http://respawner.fr/ |
From: cyber p. <cyb...@gm...> - 2012-02-06 11:27:55
|
Hello again, I would like to ask for some feedback on this patch (do I have to fix something to have it accepted ?). Best regards, Georgios Migdos. On Wed, Feb 1, 2012 at 4:26 PM, cyber python <cyb...@gm...> wrote: > Hello, > > I have just added coverage for style scheme use in GtkSourceView. > > In the attachment, you will find the associated patch. > > Best regards, > Georgios Migdos. |
From: Guillaume M. <res...@gm...> - 2012-02-06 00:05:33
|
Hello, Here is a quickly made branch that add the coverage of GtkLicense. The covered constants are used to specify the license of an application with the related GtkAboutDialog method. The branch covers the GtkLicense constants and the related GtkAboutDialog methods. It can be found at: hackers/guillaume/gtk-license/ Cheers, -- Guillaume Mazoyer - http://respawner.fr/ |