[cp-patches] X/Escher peers
The X/Escher peers for inclusion in Classpath. After some email exchange with Mark I think it would be best to handle the dependency on Escher just as we handle other dependecies on external libs (GTK, Qt). The only problem beeing this lib is Java, and I have no clue how to teach that to the autotools. Maybe someone has an idea? A --with-escher-jar=/path/to/escher.jar option would be a start. Also, we need to exclude the X peer classes from build when no such jar is found. Trying out the peers: Escher needs to be in the bootclasspath. The current JAR can be found here (older versions won't work): http://kennke.org/~roman/escher-0.2.3-pre.jar Before you start you might have to: xhost +localhost I think authentication doesn't work right now with Escher. My script for starting the X/Escher peers looks like this: #!/bin/bash cacao -Xbootclasspath/p:/home/roman/workspace/escher \ -Dawt.toolkit=gnu.java.awt.peer.x.XToolkit $@ Have fun. (I'll write a ChangeLog when I other somebody else figured out the autoconf mess). When hitting any immediate problems, please ping me. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake xescher.tar.gz Description: application/compressed-tar signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] X/Escher peers
Hi again, > Trying out the peers: Forgot to mention, you need to either --enable-local-sockets, or say -Dgnu.xawt.no_local_sockets at runtime. Makes things a little slower though and you need X accept connections on TCP. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] X/Escher peers
On Jun 28, 2006, at 8:35 AM, Roman Kennke wrote: The X/Escher peers for inclusion in Classpath. After some email exchange with Mark I think it would be best to handle the dependency on Escher just as we handle other dependecies on external libs (GTK, Qt). The only problem beeing this lib is Java, and I have no clue how to teach that to the autotools. Maybe someone has an idea? There's this: http://ac-archive.sourceforge.net/Java_Support/ ac_check_class.html A few GNU Java projects I've run into use these macros (my projects included). I don't think they're ideal, but should suffice. The main page is http://ac-archive.sourceforge.net/Java_Support/ PGP.sig Description: This is a digitally signed message part
Re: [cp-patches] X/Escher peers
On Jun 28, 2006, at 8:35 AM, Roman Kennke wrote: The X/Escher peers for inclusion in Classpath. After some email exchange with Mark I think it would be best to handle the dependency on Escher just as we handle other dependecies on external libs (GTK, Qt). The only problem beeing this lib is Java, and I have no clue how to teach that to the autotools. Maybe someone has an idea? A --with-escher-jar=/path/to/escher.jar option would be a start. Also, we need to exclude the X peer classes from build when no such jar is found. Trying out the peers: Escher needs to be in the bootclasspath. The current JAR can be found here (older versions won't work): http://kennke.org/~roman/escher-0.2.3-pre.jar Oh, and also, why can't we include the Escher source in external/? It sounds to me like it needs to be forked anyway (especially if it's going to get Xauthority handling, which it definitely needs). Is the author even working on it any more? PGP.sig Description: This is a digitally signed message part
Re: [cp-patches] X/Escher peers
Hi Casey, > Oh, and also, why can't we include the Escher source in external/? It > sounds to me like it needs to be forked anyway (especially if it's > going to get Xauthority handling, which it definitely needs). Is the > author even working on it any more? Escher is an external library, just like GTK or Qt. Only that it happens to be programmed in Java. The original author isn't actively working on it atm. BUT I do, and he made me co-maintainer of Escher. I already did a couple of fixes to get the X peers working and will do a realease soon. I agree, having this in external/ would make things easier, but it seems a cleaner approach to handle it like other libs that we depend on. What do others think? Cheers, Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] X/Escher peers
On Jun 29, 2006, at 2:35 AM, Roman Kennke wrote: Hi Casey, Oh, and also, why can't we include the Escher source in external/? It sounds to me like it needs to be forked anyway (especially if it's going to get Xauthority handling, which it definitely needs). Is the author even working on it any more? Escher is an external library, just like GTK or Qt. Only that it happens to be programmed in Java. The original author isn't actively working on it atm. BUT I do, and he made me co-maintainer of Escher. I already did a couple of fixes to get the X peers working and will do a realease soon. I agree, having this in external/ would make things easier, but it seems a cleaner approach to handle it like other libs that we depend on. What do others think? I'd agree that treating it like just another library is a good option, but it's just that I don't think Java library installation handling is quite as consistent as shared libraries. I mean, it's been a while since I've done a lot of user-level Java stuff on Linux, but my understanding was that each distribution still had its own bizarre way of installing Java libraries. And, I'm a little concerned that few people will have Escher installed, or will be able to install it through their distribution, whereas GTK or Qt are things that a user rarely has to worry about, because they're a part if his system. I mean, if there aren't any fatal issues with including Escher in external/, then why not do so? PGP.sig Description: This is a digitally signed message part
Re: [cp-patches] X/Escher peers
On Thu, 2006-06-29 at 15:09 -0700, Casey Marshall wrote:
> On Jun 29, 2006, at 2:35 AM, Roman Kennke wrote:
>
> > Hi Casey,
> >
> >> Oh, and also, why can't we include the Escher source in external/? It
> >> sounds to me like it needs to be forked anyway (especially if it's
> >> going to get Xauthority handling, which it definitely needs). Is the
> >> author even working on it any more?
> >
> > Escher is an external library, just like GTK or Qt. Only that it
> > happens
> > to be programmed in Java. The original author isn't actively
> > working on
> > it atm. BUT I do, and he made me co-maintainer of Escher. I already
> > did
> > a couple of fixes to get the X peers working and will do a realease
> > soon.
> >
> > I agree, having this in external/ would make things easier, but it
> > seems
> > a cleaner approach to handle it like other libs that we depend on.
> > What
> > do others think?
> >
>
> I'd agree that treating it like just another library is a good
> option, but it's just that I don't think Java library installation
> handling is quite as consistent as shared libraries. I mean, it's
> been a while since I've done a lot of user-level Java stuff on Linux,
> but my understanding was that each distribution still had its own
> bizarre way of installing Java libraries.
>
> And, I'm a little concerned that few people will have Escher
> installed, or will be able to install it through their distribution,
> whereas GTK or Qt are things that a user rarely has to worry about,
> because they're a part if his system.
>
> I mean, if there aren't any fatal issues with including Escher in
> external/, then why not do so?
I second that. Putting it in external/ would be best, at least until
the distributions pick up on it and start including it in a uniform way.
--
Andrew :-)
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
Re: [cp-patches] X/Escher peers
On Thu, Jun 29, 2006 at 11:28:52PM +0100, Andrew John Hughes wrote: > I second that. Putting it in external/ would be best, at least until > the distributions pick up on it and start including it in a uniform way. I second that too. But please do it in a way where distros can decide the use the one in external/ or the system installed escher. Michael -- http://www.worldforge.org/
