java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 4)
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: Guillaume M. <res...@gm...> - 2011-09-03 13:59:51
|
On Wed, Aug 31, 2011 at 09:17:08PM +0900, Andrew Cowie wrote: > Anyone have anything they want merged before we do 4.1.2? I'd like to work on the GtkApplication thing for 4.1.2. I will be able to work on that next week. -- Guillaume Mazoyer |
From: Vreixo F. L. <met...@ya...> - 2011-09-03 13:39:32
|
Hi! I hope to have my GtkBuilder branch ready in 1-2 weeks, but it will need evaluation so... I don't know. If you think we need a release go ahead. Moreover, my branch has the library loading issue, which requires a careful look before being merged. Cheers Vreixo ----- Mensagem original ----- De: Andrew Cowie <an...@op...> Para: java-gnome-hackers <jav...@li...> Cc: Enviadas: Quarta-feira, 31 de Agosto de 2011 14:17 Assunto: [java-gnome-hackers] Release needed? Anyone have anything they want merged before we do 4.1.2? I know quite a few of the people who contribute to java-gnome are unable to use it right now until they get a release of their distro with GTK 3 on their systems so they can build, but if anyone wants something in, please let me know or send to list... Vreixo, this means you :) AfC Tokyo ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers |
From: Andrew C. <an...@op...> - 2011-08-31 12:44:02
|
Anyone have anything they want merged before we do 4.1.2? I know quite a few of the people who contribute to java-gnome are unable to use it right now until they get a release of their distro with GTK 3 on their systems so they can build, but if anyone wants something in, please let me know or send to list... Vreixo, this means you :) AfC Tokyo |
From: Vreixo F. <met...@ya...> - 2011-07-19 14:50:09
|
Hi all! Serkan: > I really like the idea of using dependency injection for ui object. > well done. It is actually a Franco's idea, and yes, I think it is very cool. > Just one thing. Can we add a default constructor to Builder with path > defaulting to cwd? Yeah, sure. Andrew: > So I talked to Vreixo before 4.1.1 and he indicated it wasn't quite > ready for being put up yet, but as soon as he's happy with it we will > certainly merge. I'm hoping it will be a highlight of 4.1.2! I hope to have time in the next weeks, so I plan this to be ready at the end of August. I plan to add support, at least, for: 1. Nested java classes, that is, to map a single UI file to several classes, with a single call to Builder, so developers can split their handling code in several classes. 2. Automatic signal connection by means of annotations (already in Franco's code) 3. Method annotations, so they are invoked at specific times (before ui file injection, before signal connection, after UI mapping, etc). Once I have all this stuff implemented, I hope to talk with you about these and other features that we should include. Cheers, Vreixo |
From: Serkan K. <se...@ge...> - 2011-07-19 03:07:46
|
2011/7/19 Serkan Kaba <se...@ge...>: > I really like the idea of using dependency injection for ui object. well done. > > Regards, > Serkan > Just one thing. Can we add a default constructor to Builder with path defaulting to cwd? |
From: Serkan K. <se...@ge...> - 2011-07-19 03:04:53
|
2011/6/18 Vreixo Formoso Lopes <met...@ya...>: > Hi all! > > I have created a branch with my approach to expose GtkBuilder, available at: > > http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/gtkbuilder/ > > > > I plan to expose GtkBuilder as an annotation-based way of creating user > interfaces, following the approach of Francho Bulgarelli to libglade, submitted > several years ago. In fact, my work is mainly an adaptation of Franco's > implementation, although I also plan to make some changes. I don't want > to follow with my discussion without first thank Franco for his huge > contribution. > > The work in my branch is still in a preliminary stage, but you can already > figure > > out the idea by looking at my code. Please download the branch and focus on > > org.gnome.gtk.Builder > > I have added a tiny demo application in doc/examples/builder, NotesDemo.java, > that shows the possibilities of an annotation-based approach. Further work will > address the signal connection by means of annotation, and many other things. > > I'm aware of the problems of GtkBuilder and similar approaches (that build user > interfaces with an external program and then load them from an XML file), > mainly related with the lack of type-safety (and note, however, that the > annotation-based approach reduces its impact by detecting the possible > problems at load time, without needing to execute all possible code paths). > > Anyway, this method for creating UI is very common in the java world (they > come to my mind web-related frameworks such as JSP/JSTL, Tapestry, > GWT's UiBinder, or the mobile Android platform with his layouts). Many > java developers use to work this way and, indeed, it has several advantages > too. > > I thus think we should offer support for this way of working in java-gnome, and > the annotation-based approach is, in my opinion, the best one. > I hope you take a look at the code and tell me your opinions about it, and any > idea that could improve it. I'll try to provide a good implementation of > GtkBuilder, making it easy for developers by means of the powerful capabilities > of the Java platform. But, at the same time, I'll try to reduce as much as > possible the limitations of the approach. > > If any of you have experience with GtkBuilder (I have not), please tell me what > are the things you want support for in java-gnome, but also the main problems > you've found when working with it, so we can address them the best possible > way. > > Thanks in advance, > > Best regards > Vreixo Formoso > > ------------------------------------------------------------------------------ > 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-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > I really like the idea of using dependency injection for ui object. well done. Regards, Serkan |
From: Mat B. <mb...@fe...> - 2011-07-19 00:30:06
|
On 18 July 2011 23:39, Andrew Cowie <an...@op...> wrote: > I hope you heard that 4.1 has had its first release! > > ++ > > The 'mainline' branch now identifies itself as version 4.1.2-dev. > > If you need the 4.0 series, I've explicitly put a 'release-4.0' branch > up on the server so it's there if someone needs it. You could of course > branch from tag:v4.0.20 too, though obviously any future work on the 4.0 > series won't be in 'mainline'. > > Cheers, > > AfC > Sydney > > > > > ------------------------------------------------------------------------------ > Storage Efficiency Calculator > This modeling tool is based on patent-pending intellectual property that > has been used successfully in hundreds of IBM storage optimization engage- > ments, worldwide. Store less, Store more with what you own, Move data to > the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > > Thanks for your hard work! :-) -- Mat Booth http://fedoraproject.org/get-fedora |
From: Andrew C. <an...@op...> - 2011-07-18 22:39:17
|
I hope you heard that 4.1 has had its first release! ++ The 'mainline' branch now identifies itself as version 4.1.2-dev. If you need the 4.0 series, I've explicitly put a 'release-4.0' branch up on the server so it's there if someone needs it. You could of course branch from tag:v4.0.20 too, though obviously any future work on the 4.0 series won't be in 'mainline'. Cheers, AfC Sydney |
From: Andrew C. <an...@op...> - 2011-07-18 22:13:07
|
On Sat, 2011-06-18 at 14:58 +0100, Vreixo Formoso Lopes wrote: > I have created a branch with my approach to expose GtkBuilder So I talked to Vreixo before 4.1.1 and he indicated it wasn't quite ready for being put up yet, but as soon as he's happy with it we will certainly merge. I'm hoping it will be a highlight of 4.1.2! AfC Sydney |
From: Vreixo F. L. <met...@ya...> - 2011-06-19 15:03:44
|
Hi! I have been reading this thread the last days and I would like to tell you all my opinion, as I don't really agree with many of the options discussed so far. First, I'd think we should distinguish between gnome stuff, that is present in most (if not all) gnome-based distros, and other stuff that only some distros provides (I'm thinking of things like appindicator). In the first case (pure gnome stuff) it MAY BE interesting to java a single jar file and it MAY BE useful to have a single .so. I will discuss about this later. For now, let me focus in the second case: libraries that are not part of gnome or that they are not installed in most distros. In this particular case, in my opinion it MAKES NO SENSE to include it in java-gnome (I mean in the java-gnome jar), neither always nor conditionally by means of a compile time flag. In the first case (always including that sutff) it would be a pain in the ass for users of distros that do not include it. I don't like to install things that require too many dependencies to stuff I'm not going to use, and I think most people don't like it neither. So I think it would be a terrible idea to do so. On the other side, a compile-time flag is also, imho, a bad idea. Distros will surely include different flavours of java-gnome, leading to an inconsistent API across distros. A pain for developers and a terrible approach, too (in fact, it is a terrible solution also in C, although it is very common). Runtime checks like hasModule(xxx) are also a bad idea imho, as aplications will either behave very differently across distros or fail at runtime. If an application feature is going to be enabled only on some distros, it is better to leave that for compile time, not at runtime. But, does this mean that this no-gnome stuff should not be include in java-gnome? Not, at least it shouldn't. I my opinion the best approach is to include it with java-gnome sources (maybe in an /src/opt folder), but never include then in the main java-gnome jar. Instead, we should generate different JARs (and JNI so) for each independient stuff (for example, java-gnome-appindicator, java-gnome-whatever...). A compile-time flag should be used to choose whether to build those optional jars. Then distros can package them separately. In this case, applications that depend on, let's say, appaindicator, should add a dependency to the desired jar, and check for the presence of that jar at compile time. This way we keep a common API, but also offer support for non-gnome stuff. We should provide some way for developers to know with of our classes require additional dependencies, by means of documentation, and maybe naming conventions (for example, including them under an org.gnome.optional package?). So, at this point, let me go back to gnome stuff. In this case, it is good to have a single jar and single API, but we could consider generate separate jars for stuff that is not very commonly used, or stuff that is sometimes used independently of other parts of the library (I think you had mentioned cairo...). But all of them should be compiled and distributed always, for the sake of a common API across distros, and the only purpose of separation is efficiency, memory usage, etc. Some experiments should be carried out in order to check if there is actually a significant impact, anyway. Another idea is to have a single jar, but different .so, that are loaded only when needed. So, what do you think? Any other idea? Best regards, Vreixo |
From: Andrew C. <an...@op...> - 2011-06-19 00:50:38
|
On Fri, 2011-06-17 at 14:52 +0100, William Temperley wrote: > Added @since tags - patch attached. I didn't before as it seemed > presumptuous :) No, quite the contrary. Saves the maintainer the work. That's a good thing :) And more to the point, I want to encourage people to think about what release they're getting their code into, ie the next one, ie soon! (Indeed, 4.0.20 and 4.1.1 are imminent) Will merge. AfC Sydney |
From: Vreixo F. L. <met...@ya...> - 2011-06-18 13:58:20
|
Hi all! I have created a branch with my approach to expose GtkBuilder, available at: http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/gtkbuilder/ I plan to expose GtkBuilder as an annotation-based way of creating user interfaces, following the approach of Francho Bulgarelli to libglade, submitted several years ago. In fact, my work is mainly an adaptation of Franco's implementation, although I also plan to make some changes. I don't want to follow with my discussion without first thank Franco for his huge contribution. The work in my branch is still in a preliminary stage, but you can already figure out the idea by looking at my code. Please download the branch and focus on org.gnome.gtk.Builder I have added a tiny demo application in doc/examples/builder, NotesDemo.java, that shows the possibilities of an annotation-based approach. Further work will address the signal connection by means of annotation, and many other things. I'm aware of the problems of GtkBuilder and similar approaches (that build user interfaces with an external program and then load them from an XML file), mainly related with the lack of type-safety (and note, however, that the annotation-based approach reduces its impact by detecting the possible problems at load time, without needing to execute all possible code paths). Anyway, this method for creating UI is very common in the java world (they come to my mind web-related frameworks such as JSP/JSTL, Tapestry, GWT's UiBinder, or the mobile Android platform with his layouts). Many java developers use to work this way and, indeed, it has several advantages too. I thus think we should offer support for this way of working in java-gnome, and the annotation-based approach is, in my opinion, the best one. I hope you take a look at the code and tell me your opinions about it, and any idea that could improve it. I'll try to provide a good implementation of GtkBuilder, making it easy for developers by means of the powerful capabilities of the Java platform. But, at the same time, I'll try to reduce as much as possible the limitations of the approach. If any of you have experience with GtkBuilder (I have not), please tell me what are the things you want support for in java-gnome, but also the main problems you've found when working with it, so we can address them the best possible way. Thanks in advance, Best regards Vreixo Formoso |
From: William T. <wil...@gm...> - 2011-06-17 13:53:04
|
On 17 June 2011 13:52, Guillaume Mazoyer <res...@gm...> wrote: > Looks good for me. > Just one thing, maybe you could add some @since tag for the javadoc. > -- > Guillaume Mazoyer - http://www.respawner.fr/ > Added @since tags - patch attached. I didn't before as it seemed presumptuous :) Will. |
From: Guillaume M. <res...@gm...> - 2011-06-17 12:53:16
|
Looks good for me. Just one thing, maybe you could add some @since tag for the javadoc. -- Guillaume Mazoyer - http://www.respawner.fr/ |
From: William T. <wil...@gm...> - 2011-06-17 11:52:15
|
Hi - I've attached a patch which adds The Pattern.setFilter(Filter) method to the Cairo bindings, plus the requisite Filter constants. I hope this will be good enough for inclusion. Please let me know if there are any problems. This patch makes it possible to specify the interpolation method used when rendering embedded images in PDFs. This fixes the particular issue I was having with low resolution PNGs being interpolated and blurred. see: http://cairographics.org/manual/cairo-cairo-pattern-t.html#cairo-pattern-set-filter Thanks to Andrew Cowie and Adrian Johnson for pointers here. Best regards, Will Temperley |
From: Andrew C. <an...@op...> - 2011-06-15 07:39:43
|
On Thu, 2011-06-02 at 15:05 +0200, Philipp Heckel wrote: > How about something like this. As you said, > in every optional module Plumbing class, do a static block which loads > the library as you said: > > static { > try { > loadNativeLib(); > available = true; > } catch (...) { > available = false; > } > } > > In the constructor of the class, Careful; Plumbing classes [and their subclasses] never get instantiated. We'd have to manually put in a check somewhere (everywhere?) else. That's doable, but error prone. :( In fact, only place we've done it is in Cairo. [And one of these days I'm going to move the checkStatus() calls down to generated C code. Better stack traces.] > check if available is true. And if it > isn't, throw a ModuleNotAvailableException (extends RuntimeEx..). > To > avoid try/catch blocks for the developer, you could additionally offer > a static moduleAvailable() method to check that beforehand. Yeah, that would be sensible, wouldn't it. We tend to have a "static class" [sic, my own term] that goes with each package. org.gnome.glib.Glib, org.gnome.gtk.Gtk, etc. So we could put moduleAvailable() [or maybe isAvailable()?] there on each of those. [Java behaves a bit funny about static methods with the same name appearing in subclasses. It doesn't do inheritance quite the way that I though, I suspect because the compiler generates an invoke static with a given class name, not invoke virtual]. I'd almost be more tempted to suggest that public isModuleAvailable() work by invoking the code path that leads to the loadNativeLibrary() call. After that, if you have the temerity to call something its either there like it should be or your app is broken like it should be. Hm. > By the way, isn't splitting things into modules "separation of > concerns". I don't see how that can be bad. It's bloody horrible when someone wants to use your libappindicator-java only to discover they've got to install 4 other modules. Java's lack of a dependency system in its shared libraries (which is a different but parallel problem during development and at deployment runtime) is horrible here. Hence the one source project (developers) and [at the moment] one resultant .jar [& .so] (deployment). Anyway. > Besides, if it's just > about Eclipse, you could still create a source directory and symlink > the module folders into it (ugglllyy, but hey ...) :-) Horrid and manual experience for developers. Java is already hard enough. Eclipse for newbies is insane. Costs us people all the time. They show up in #java-gnome wanting to "try it" because "they've heard Eclipse is cool" and an hour later are lost for good. > As you might have guessed, I'm rather new to bzr, so forgive me my > kindergarten mistakes :-) Not at all. Takes time to learn the ins and outs of anything you haven't worked with before. AfC Sydney |
From: Francisco O. <fr...@pu...> - 2011-06-02 15:35:50
|
Continuing with the aside > As an aside, > > On Wed, 2011-06-01 at 14:19 -0300, Francisco Ortiz wrote: > >> - using a factory: its a derivative of the previous one, but cleaner. >> The factory is responsible of provide the correct implementation, it >> will return a class that implements an interface which can be the real >> implementation or the mocked/not supported by the system one. Again , >> its more code but cleaner. > > If we had done an interface based design for 4.0, as I originally > considered, then this would be a snap. But interfaces didn't work out, > and changing our entire public API to interfaces-only at this point > would be ... messy. Like 5.0 messy. > http://java-gnome.sourceforge.net/4.0/doc/design/5a-Architecture.html Its definitely a 5.0 kind of mess. I remember i read that part one year ago and you get stuck with the JavaDoc issue. Did you check the {@inheritDoc} tag?. Check this article: http://firstclassthoughts.co.uk/java/javadoc_documentation_inheritance.html maybe can be useful for that. > My thinking about this has come from the other side. My guess was that > the thing to do would be to put an individual loadNativeLibrary() call > in each package's Plumbing class's static { ... } block, rather than the > single all-encompassing master one down in > org.freedesktop.bindings.Plumbing's. > > That would mean that the only libMODULENAMEjni.so that get loaded would > be those corresponding to modules you actually use as a developer, which > corresponds to the lazy loading of Java classes on the JVM side. Good. > My concern is the case where the user tries to use the java class without the library. Should we create a mocked implementation o throws the runtime exception? > It means more .so shared libraries. Lots more. Some people tell me > that's bad. Other people tell me not to worry about it. > > So I was thinking about our Java package space, but a better level would > presumably be pkg-config space. I didn't check how bad that is, but I think not *all* the dependencies should be modularized, only the optional ones. Anyway need to get my hands in the code to get more answers. |
From: Philipp H. <phi...@gm...> - 2011-06-02 13:05:38
|
Hallo Andrew, > Well, the moment one distro does --enable-something and other distro > does --disable-soemthing in their packages then we have an inconsistent > API for developers. I believe I might have underestimated the impact of a decision like this. Having a library that offers different classes depending on the distro is definitely not a good option. All the more interesting is the idea Francisco suggested. But if you say this is 2yrs work this is not an option for 4.0.x. > My thinking about this has come from the other side. My guess was that > the thing to do would be to put an individual loadNativeLibrary() call > in each package's Plumbing class's static { ... } block, rather than the > single all-encompassing master one down in > org.freedesktop.bindings.Plumbing's. > > That would mean that the only libMODULENAMEjni.so that get loaded would > be those corresponding to modules you actually use as a developer, which > corresponds to the lazy loading of Java classes on the JVM side. Good. I find that so far the best idea, and as far as I see it, it could be implemented with only little changes to the current code and no (?) impact on the current API. Forgive me if I take appindicator as example again, but it's the easiest to imagine for me. How about something like this. As you said, in every optional module Plumbing class, do a static block which loads the library as you said: static { try { loadNativeLib(); available = true; } catch (...) { available = false; } } In the constructor of the class, check if available is true. And if it isn't, throw a ModuleNotAvailableException (extends RuntimeEx..). To avoid try/catch blocks for the developer, you could additionally offer a static moduleAvailable() method to check that beforehand. Applying this to my appindicator example, one could write an application that uses appindicators (if they are available), and statusicons if they are not, something like this: if (Indicator.moduleAvailable()) { Indicator i = new Indicator(...); ... } else { StatusIcon i = new StatusIcon(..); } > It means more .so shared libraries. Lots more. Some people tell me > that's bad. Other people tell me not to worry about it. > [...] > going forward, although that's still very messy for Eclipse. Hm. Don't worry about it :-) By the way, isn't splitting things into modules "separation of concerns". I don't see how that can be bad. Besides, if it's just about Eclipse, you could still create a source directory and symlink the module folders into it (ugglllyy, but hey ...) :-) How much work would it be to externalize a module in a separate .so? Is it feasable to do that for 4.0.x? > P.S. I just checked out your branch, and discovered > ubuntu-appindicator.patch in the root directory. What is that? And then > worse I discovered that you had .so and .jar files added in your > history. Eeek. You don't version control build products and patches :/ I > see that you discovered your mistake, but we're not going to [ever] be > able to merge this branch because it mean bloating everyone's > repositories with this history. Also please fix `bzr whoami` before you > redo these commit(s). > > Please join us in #java-gnome I'm sure someone will be happy to walk you > through using Bazaar. There's a trick with bzr merge and revert that can > compress this all into a single patch which might just be the thing. The ubuntu-appindicator patch is the one Francisco posted in his post a year ago. As you might have guessed, I'm rather new to bzr, so forgive me my kindergarten mistakes :-) Cheers, Philipp |
From: Andrew C. <an...@op...> - 2011-06-02 00:49:23
|
On Wed, 2011-06-01 at 17:58 +0200, Philipp Heckel wrote: > As you might have seen, I've implemented some changes... So if you only need this for your direct use to slim the library down for your situation, then by all means, go for it, and I'm glad its working out. > > Most importantly: my adjustments do NOT change the default behavior. So > the distro versions will not be affected by this. > Well, the moment one distro does --enable-something and other distro does --disable-soemthing in their packages then we have an inconsistent API for developers. And (this is the part that you may not be seeing directly) that's the part we, upstream, get blamed for. A developer doesn't care that the "fault" is two different distros doing things differently. They just know that java-gnome doesn't work. That's a serious piss off for them, and it makes it very difficult for us to support users. Common problem in Open Source, to be sure, but in our little corner of it we've avoided it thus far. Anyway, you get that. I just wanted to be clear that I'm not trying to make life difficult for you on purpose. We just need to figure out the experience we want for users of the library, then the design and engineering that supports that. > > I'd appreciate it if you could take a look at it and tell me whether you > might consider including this in the trunk. > > > - added one directory for each module: So that's an obvious one, now that you say it. Good call. My thinking about this has come from the other side. My guess was that the thing to do would be to put an individual loadNativeLibrary() call in each package's Plumbing class's static { ... } block, rather than the single all-encompassing master one down in org.freedesktop.bindings.Plumbing's. That would mean that the only libMODULENAMEjni.so that get loaded would be those corresponding to modules you actually use as a developer, which corresponds to the lazy loading of Java classes on the JVM side. Good. It means more .so shared libraries. Lots more. Some people tell me that's bad. Other people tell me not to worry about it. So I was thinking about our Java package space, but a better level would presumably be pkg-config space. so, src/defs/gtk-3.0/GtkButton.defs sure maybe. > > - moved the directory "src/bindings" to "src/bindings/core" This worried me, though. Carrying your example further, > > + src/bindings/indicate-gtk > > + src/bindings/appindicator-0.1 and so on. There will be 15 or 20 of these, I'd guess. The catch is that src/bindings/ is a source package root in Eclipse and in the build system. It's bad enough right now that we have src/gnerator/ src/bindings/ tests/generator/ tests/bindings/ tests/screenshots/ tests/prototype/ doc/examples/ all being source packages. So we would need src/bindings/MODULENAME/ tests/bindings/MODULENAME/ for each variation, I guess. That's not very tidy. Maybe we just do src/MODULENAME tests/MODULENAME going forward, although that's still very messy for Eclipse. Hm. Or maybe we don't do that at all, build all the sources regardless, and deal with it at C compile / link time and/or at Plumbing's static {...} . That would save smashing the Java side of the build system so much, at the cost of greater complexity on the C side. ++ We're on the right track, discussing this. It's something we've avoided until now in this project but it's time to figure it out. Lovely to have your interest and involvement. AfC Sydney P.S. I just checked out your branch, and discovered ubuntu-appindicator.patch in the root directory. What is that? And then worse I discovered that you had .so and .jar files added in your history. Eeek. You don't version control build products and patches :/ I see that you discovered your mistake, but we're not going to [ever] be able to merge this branch because it mean bloating everyone's repositories with this history. Also please fix `bzr whoami` before you redo these commit(s). Please join us in #java-gnome I'm sure someone will be happy to walk you through using Bazaar. There's a trick with bzr merge and revert that can compress this all into a single patch which might just be the thing. -- 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: Andrew C. <an...@op...> - 2011-06-02 00:05:00
|
On Wed, 2011-06-01 at 14:19 -0300, Francisco Ortiz wrote: ... > I really like the compile-time flags proposal > ...but not include the java classes in the JAR is BIG problem from > (library) users perspective. You will end up with a non consistent API > from java side, you will have version java-gnome 4.0.20 with the > library or without it and the user will not know it. Or based on the > distro will have it or not. Same java program will throw a > ClassNotFoundException in the platform not supporting the > functionality. Yes, that's my concern exactly. We *did* have that situation in the 2.x days, because we had Cairo bindings that needed PDF support, but at the time some distros were shipping Cairo built with --enable-pdf and some were not. Made it damn near impossible to package libcairo-java at the time. And made it useless to try writing a program against it, because you [the developer] had no idea if your it would work when installed on a users' system... Pain & suffering. [There was a lot of that in the 2.x days. When I inherited java-gnome, there were 9+ upstream modules and 6+ downstream packages (that were alive). Trying to do a point release just to fix an autotools problem and then ship those packages in a distro was insanely painful. Took 9 hours, I kid you not (and people wonder why I hate automake so much)] Anyway. > Putting the topic about including non-pure-gnome dependencies aside, That actually *is* a significant engineering question. I think Serkan wants this too. We should talk about it. I'll start a new thread for that part. AfC Sydney |
From: Philipp H. <phi...@gm...> - 2011-06-01 23:59:24
|
Hey there, I was just wondering, since there is no "best" option in sight ... What's the harm for you guys to add the --with-module=(..) option? It doesn't change the default behavior of the library... Cheers, Philipp On Thu, Jun 2, 2011 at 1:53 AM, Andrew Cowie <an...@op...> wrote: > As an aside, > > On Wed, 2011-06-01 at 14:19 -0300, Francisco Ortiz wrote: > >> - using a factory: its a derivative of the previous one, but cleaner. >> The factory is responsible of provide the correct implementation, it >> will return a class that implements an interface which can be the real >> implementation or the mocked/not supported by the system one. Again , >> its more code but cleaner. > > If we had done an interface based design for 4.0, as I originally > considered, then this would be a snap. But interfaces didn't work out, > and changing our entire public API to interfaces-only at this point > would be ... messy. Like 5.0 messy. > http://java-gnome.sourceforge.net/4.0/doc/design/5a-Architecture.html > > I mean, go ahead if you want, but it's about 2 years work. Just thought > I'd let you know. :) > > AfC > Sydney > > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > > |
From: Andrew C. <an...@op...> - 2011-06-01 23:53:50
|
As an aside, On Wed, 2011-06-01 at 14:19 -0300, Francisco Ortiz wrote: > - using a factory: its a derivative of the previous one, but cleaner. > The factory is responsible of provide the correct implementation, it > will return a class that implements an interface which can be the real > implementation or the mocked/not supported by the system one. Again , > its more code but cleaner. If we had done an interface based design for 4.0, as I originally considered, then this would be a snap. But interfaces didn't work out, and changing our entire public API to interfaces-only at this point would be ... messy. Like 5.0 messy. http://java-gnome.sourceforge.net/4.0/doc/design/5a-Architecture.html I mean, go ahead if you want, but it's about 2 years work. Just thought I'd let you know. :) AfC Sydney |
From: Francisco O. <fr...@pu...> - 2011-06-01 17:19:38
|
Hi all, First of all, thanks Philipp to bring this back, I really love to see the indicator patch in trunk too. Not only for the particular functionality but to reopen the discussion about the optional dependencies. Putting the topic about including non-pure-gnome dependencies aside, Let me give you my point of view (see comments below) > Hi again, > > As you might have seen, I've implemented some changes which I think > solve many of the problems you mention below: only the modules you > define with the "--with-module=" parameter are compiled in the library. > If you leave out a module, the JAR will not contain the Java classes and > the *.so will not be compiled with useless stuff. So no > UnsatisfiedLinkExceptions. I really like the compile-time flags proposal ...but not include the java classes in the JAR is BIG problem from (library) users perspective. You will end up with a non consistent API from java side, you will have version java-gnome 4.0.20 with the library or without it and the user will not know it. Or based on the distro will have it or not. Same java program will throw a ClassNotFoundException in the platform not supporting the functionality. > > I could even imagine something like "--without-module=(..)" so one could > exclude default modules (such as rsvg, or even cairo?!). This is > particularly useful if you don't want to use the whole thing, but only > very limited parts of java-gnome. I believe that could reduce the > filesize (and used memory) drastically. > > Most importantly: my adjustments do NOT change the default behavior. So > the distro versions will not be affected by this. > > I'd appreciate it if you could take a look at it and tell me whether you > might consider including this in the trunk. > > > It's (absurdly) monolithic, but as a > > practical matter is did mean we got on with it over the past 5 years > > instead of wasting time making something that isn't the same for > > everyone, and since the build- & run- time requirement is "a GNOME > > desktop" I still believe it wasn't actually unreasonable to go this way. > > It definitely wasn't. That's why we're talking about /optional/ modules, > because they are not for everyone. Those who want them can hence simply > recompile the library. > > >> In the long run, I would love a dynamic loader that only allows the > >> [..] > > > > So expecting the library to cope with linking to some things and not > > linking to other things is going to get messy. The next matter is pubic > > API: do you *really* want to put a try-catch block around every library > > call? Surely not. But where else is it going to go? Silently fail? I > > don't think so. Uncaught exception? Hardly. So what then? The fact that > > I don't have an answer to that is one of the reasons we didn't do this > > years ago. > > True. That's definitely not how you'd want it. However, I could imagine > something like a "hasModule(..)" method for which an application could > check in the beginning if all required modules are available. If they > are, everything is good. If they aren't, the application exists. That > way, the java-gnome library could indeed simply throw an > UnsatisfiedLinkException if a non-present module if about to be used. > > In my opinion, the build time module inclusion/exclusion is much cleaner. > I was thinking about this for more than a year too. Here are 3 options: - leave it to the user: hasModule() solution Philipp suggested and throw the runtime exception if its invoked anyway (hey, users call) - check on every method call: if dependency is not satisfied continue silently. The problem with this is if the response trigger some condition, and that will depend on the library :( - using a factory: its a derivative of the previous one, but cleaner. The factory is responsible of provide the correct implementation, it will return a class that implements an interface which can be the real implementation or the mocked/not supported by the system one. Again , its more code but cleaner. > > > We don't have #ifdef in Java. I personally consider that a feature, not > > a bug, but regardless it's not up to me; that's just the way it is and > > java-gnome merely conforms accordingly. So enabling or disabling at > > configure time as in the C paradigm is only part of the solution, since > > we also need to decide what to do on the Java side. > > See above. I did address this by simply leaving out both Java and C code > for the modules that are not in the --with-module parameter. > > > Another question is API documentation: "this feature will only be > > available if java-gnome was built with $X feature enabled" in every > > method of the relevant JavaDoc sounds painful - and inelegant. > > That's true if it is method specific, but it is not if you do it for a > whole package (cp. appindicator). > > > Sure, but I think the real issue is that something like appindicator > > that is never going to *be* a part of GNOME and is only available in one > > downstream distro is perhaps not entirely suitable for an upstream > > library like java-gnome. > > [..] > > As an aside, but I think a relevant case: I'd observe in passing that I > > don't have appindicator packages installed on my Ubuntu system. I'm > > running GNOME 3 of course, and have no need of Canonical's Unity stuff. > > I would be quite upset if installing Guillaume's java-gnome package > > suddenly dragged all those packages in. > > That's why I think it should be an optional module. It's in the code, > but only for those who want/need it. > > > > [...] > > So we have some design and engineering issues to consider. What do you > > want to happen if you're on any Linux other than Ubuntu-with-Unity and > > there are no app indicators? > > > > Should the class not exist [which would mean conditionally including or > > not including code in the .jar file. Very hard]? > > > > Should the C code not be emitted [which would mean a call down that code > > path would hit the native declarations and would result in > > UnsatifiedLinkError]? > > I think if the *.so and *.jar is compiled with appindicator support, it > is not the responsibility of java-gnome to make sure that the native > library exists -- it's the responsibility of the application using it. > > Don't you think? I agree the user should check it...or use the mocked version. The problem with the later is big libraries (appindicator is small) will create more code. > > > Whew! > > > > I'm sitting outside at a cafe in the early morning shivvering my ass > > off. :) so I think I'll just send this now. > > :-) > > > I hope I'm not the only one commenting on this thread, since I might > have a different point of view than others. My main goal is to help the > java-gnome library to get more flexible when it comes to optional > functionalities. As I intend to include/use only small parts of it in a > project of mine, it should be able to reduce the file size of both JAR > and SO to a minimum. > > Cheers, > Philipp > Thanks, Fran |
From: Philipp H. <phi...@gm...> - 2011-06-01 15:58:15
|
Hi again, As you might have seen, I've implemented some changes which I think solve many of the problems you mention below: only the modules you define with the "--with-module=" parameter are compiled in the library. If you leave out a module, the JAR will not contain the Java classes and the *.so will not be compiled with useless stuff. So no UnsatisfiedLinkExceptions. I could even imagine something like "--without-module=(..)" so one could exclude default modules (such as rsvg, or even cairo?!). This is particularly useful if you don't want to use the whole thing, but only very limited parts of java-gnome. I believe that could reduce the filesize (and used memory) drastically. Most importantly: my adjustments do NOT change the default behavior. So the distro versions will not be affected by this. I'd appreciate it if you could take a look at it and tell me whether you might consider including this in the trunk. > It's (absurdly) monolithic, but as a > practical matter is did mean we got on with it over the past 5 years > instead of wasting time making something that isn't the same for > everyone, and since the build- & run- time requirement is "a GNOME > desktop" I still believe it wasn't actually unreasonable to go this way. It definitely wasn't. That's why we're talking about /optional/ modules, because they are not for everyone. Those who want them can hence simply recompile the library. >> In the long run, I would love a dynamic loader that only allows the >> [..] > > So expecting the library to cope with linking to some things and not > linking to other things is going to get messy. The next matter is pubic > API: do you *really* want to put a try-catch block around every library > call? Surely not. But where else is it going to go? Silently fail? I > don't think so. Uncaught exception? Hardly. So what then? The fact that > I don't have an answer to that is one of the reasons we didn't do this > years ago. True. That's definitely not how you'd want it. However, I could imagine something like a "hasModule(..)" method for which an application could check in the beginning if all required modules are available. If they are, everything is good. If they aren't, the application exists. That way, the java-gnome library could indeed simply throw an UnsatisfiedLinkException if a non-present module if about to be used. In my opinion, the build time module inclusion/exclusion is much cleaner. > We don't have #ifdef in Java. I personally consider that a feature, not > a bug, but regardless it's not up to me; that's just the way it is and > java-gnome merely conforms accordingly. So enabling or disabling at > configure time as in the C paradigm is only part of the solution, since > we also need to decide what to do on the Java side. See above. I did address this by simply leaving out both Java and C code for the modules that are not in the --with-module parameter. > Another question is API documentation: "this feature will only be > available if java-gnome was built with $X feature enabled" in every > method of the relevant JavaDoc sounds painful - and inelegant. That's true if it is method specific, but it is not if you do it for a whole package (cp. appindicator). > Sure, but I think the real issue is that something like appindicator > that is never going to *be* a part of GNOME and is only available in one > downstream distro is perhaps not entirely suitable for an upstream > library like java-gnome. > [..] > As an aside, but I think a relevant case: I'd observe in passing that I > don't have appindicator packages installed on my Ubuntu system. I'm > running GNOME 3 of course, and have no need of Canonical's Unity stuff. > I would be quite upset if installing Guillaume's java-gnome package > suddenly dragged all those packages in. That's why I think it should be an optional module. It's in the code, but only for those who want/need it. > [...] > So we have some design and engineering issues to consider. What do you > want to happen if you're on any Linux other than Ubuntu-with-Unity and > there are no app indicators? > > Should the class not exist [which would mean conditionally including or > not including code in the .jar file. Very hard]? > > Should the C code not be emitted [which would mean a call down that code > path would hit the native declarations and would result in > UnsatifiedLinkError]? I think if the *.so and *.jar is compiled with appindicator support, it is not the responsibility of java-gnome to make sure that the native library exists -- it's the responsibility of the application using it. Don't you think? > Whew! > > I'm sitting outside at a cafe in the early morning shivvering my ass > off. :) so I think I'll just send this now. :-) I hope I'm not the only one commenting on this thread, since I might have a different point of view than others. My main goal is to help the java-gnome library to get more flexible when it comes to optional functionalities. As I intend to include/use only small parts of it in a project of mine, it should be able to reduce the file size of both JAR and SO to a minimum. Cheers, Philipp |
From: Andrew C. <an...@op...> - 2011-06-01 01:19:12
|
On Tue, 2011-05-31 at 22:40 +0200, Philipp Heckel wrote: > What do you think of that? I think it's all good. I've written down some responses below. My only real interest is helping the project move forward, so please take everything I've written with that in mind. ++ > However, to avoid getting stuck in an endless discussion about how to > implement this, We *do* have to implement $crazy_idea, and hand-waving away engineering problems isn't really facing up to the challenges involved. In almost every aspect java-gnome is the way it is because of such limitations. Foremost, however, is developer experience: what is it like to use java-gnome? Thus far we have provided a unified experience to people using the library; if I write code on Debian you can run it on Gentoo. I've felt that was important for the last 5 years, but other people can say what they think. > many > developers probably only use a fraction of the built-in functionality. By the time you're doing anything non-trivial you rapidly find yourself using the bulk of what's in the library. And that's only going to increase as GNOME 3 brings increasing convergence between the various libraries in the stack. The only real exception I'm aware of are those using it exclusively to do doing drawing with Cairo. ++ >I am referring to the issue of "optional dependencies" discussed in > [1]: I can definitely understand the discussed problems: > Reducing dependencies and having optional dependencies is certainly a > must in big projects like this. Well, it is and it isn't. Sure, I raised this topic because it's been on my mind for a while. And definitely it'd be fantastic to support obscure corner cases. However, the build-time dependency of java-gnome is "the GNOME desktop" and the purpose of the library is to allow people to write applications for the GNOME desktop. Taking that notion and making it the actual code dependency sure as hell saved a lot of complication over the years. As a technical matter, the build system is works by building everything; if there is a declaration for GtkSomething, Java code and C code are emitted and that C code will expect to find gtk_somethin_do_whatever() in headers and at link time. It's (absurdly) monolithic, but as a practical matter is did mean we got on with it over the past 5 years instead of wasting time making something that isn't the same for everyone, and since the build- & run- time requirement is "a GNOME desktop" I still believe it wasn't actually unreasonable to go this way. Anyway, that was then, this is now. > In the long run, I would love a dynamic loader that only allows the > use of classes for which the native libraries are available. For > example, if libappindicate is present, an application may use the > corresponding Java classes. If not, an exception is thrown. That shouldn't be that hard; I can see a number of ways of doing this where the result is UnsatisfiedLinkError. This, however, is not that cool. Consider the current and normal case: you only get that terminal exception thrown if there's some installation problem; your app uses java-gnome and java-gnome can either find its native half or it can't. Very important that it can. So expecting the library to cope with linking to some things and not linking to other things is going to get messy. The next matter is pubic API: do you *really* want to put a try-catch block around every library call? Surely not. But where else is it going to go? Silently fail? I don't think so. Uncaught exception? Hardly. So what then? The fact that I don't have an answer to that is one of the reasons we didn't do this years ago. We don't have #ifdef in Java. I personally consider that a feature, not a bug, but regardless it's not up to me; that's just the way it is and java-gnome merely conforms accordingly. So enabling or disabling at configure time as in the C paradigm is only part of the solution, since we also need to decide what to do on the Java side. Anyway, I daresay that a uncaught runtime exception is what we're going to do. I presume UnsupportedOperationException or something custom parallel to org.gnome.glib.FatalError, maybe org.gnome.glib.UnsatisfiedFeatureError. whatever. That leaves it up to the app developer using the bindings to deal with the feature being present or not? I guess. ++ Another question is API documentation: "this feature will only be available if java-gnome was built with $X feature enabled" in every method of the relevant JavaDoc sounds painful - and inelegant. ++ > That way, if the "default version" in the distros' repositories is not > built with the desired functionality, one could check out the source > of the current stable version (4.0.19) and simply re-compile it > --with-module=... Sure, but I think the real issue is that something like appindicator that is never going to *be* a part of GNOME and is only available in one downstream distro is perhaps not entirely suitable for an upstream library like java-gnome. Note that this is all same engineering challenge as e.g. WebKit, so the discussion isn't wasted at all. But first we need to make some design decisions about what our public API & developer experience is in the face of optional {upstream,downstream} dependencies. ++ As an aside, but I think a relevant case: I'd observe in passing that I don't have appindicator packages installed on my Ubuntu system. I'm running GNOME 3 of course, and have no need of Canonical's Unity stuff. I would be quite upset if installing Guillaume's java-gnome package suddenly dragged all those packages in. For which, of course, there is a standard answer: different packages depend on different dependencies. Sure. This was actually going to be the topic of a "(2)" series of emails, but for now consider a few basic questions: 1. We have the lovely design of only needing the developer to include one .jar file. That's nice. If we have lots of packages we implicitly force developers to include zillions of .jar files. That would suck. 2. What about Gentoo? Unlike Debian, they doesn't build multiple binary packages for a single source package. They do have a wonderful build time optional dependency mechanism though. ++ If the code is present in the library but not to be built, how [this is an implementation issue but a huge one: like I said, right now all the code builds - the list of .java and .c files to be built is simply the result of `find`. There's no manually articulated list of classes. There could be. It's been nice not to have all the bugs that happen because some manual file list is wrong. Perennial nightmare in other projects] ++ > However, in my opinion, an issue like > this should not stand in the way of making progress and including new > functionalities: I agree. > Francisco implemented support for App Indicators over > a year ago [2] and even though is works like a charm, it is still not > in the library. So we have some design and engineering issues to consider. What do you want to happen if you're on any Linux other than Ubuntu-with-Unity and there are no app indicators? Should the class not exist [which would mean conditionally including or not including code in the .jar file. Very hard]? Should the C code not be emitted [which would mean a call down that code path would hit the native declarations and would result in UnsatifiedLinkError]? ++ Whew! I'm sitting outside at a cafe in the early morning shivvering my ass off. :) so I think I'll just send this now. To reiterate what I said at the beginning, I am really happy to be having this discussion. I think you'll agree that the implications are non-trivial. And as long as people are thinking about that, and keeping in mind the experience for developers [our audience], and not forgetting hackers [the people who have to a) do the work now, b) package the resultant mess and c) & d) maintain it in the future], and finally most important of all users [make sure that applications written against java-gnome provide a good experience for the users of those applications] then I'm sure that we'll do the right thing. If people decide that any or all of these concerns are not important, then that's fine by me. AfC Sydney |