"libswt-indie-XXX" (just my proposal) to avoid conflicts with the so-libraries provided by the eclipse-project - they could be installed in /usr/lib or /usr/local/lib without collisions. (The swt-source needs to be patched to accept the different library names).
2) Binary distributions (RPMs).
Structure:
- libswt_indie.rpm ... just the .so libraries of the native swt parts. (need not include the gcj compiled swtXXX.so-library because at the moment it should be linked statically with the application - gcj is changing quite quickly)
- libswt_indie_devel.rpm ... the swtXXX.jar file and .a files for static/shared compilation.
- libswt_indie.srpm ... source rpm
3) "SWT Instant Development Pack" (Sample application)
A little sample application - should provide everything the java-developer needs for writing and packaging swt-applications:
configure, Makefile, rpm-spec file and sample sources which can be compiled with libswt_indie_devel to an application that integrates into the linux desktop (start menu & icon - according to the rules of linuxbase.org and freedesktop.org? and/or the linux distributors).
The Makefile should also enable static compilation (with a switch).
4) Patch for static linking:
I have written a little patch for org.eclipse.swt.internal.Library to enable static linking of the swt native parts (and libgcj).
> Here is my wishlist for the future of libswt:
>
>
> 1) Different library names:
>
> "libswt-indie-XXX" (just my proposal) to avoid conflicts with the
> so-libraries provided by the eclipse-project - they could be installed
> in /usr/lib or /usr/local/lib without collisions. (The swt-source needs
> to be patched to accept the different library names).
>
Actually, people who already have the libs shouldn't need to re-install since th
e source is identical. Is that good enough? And we're only talking about the sup
port libs, right?
> 2) Binary distributions (RPMs).
>
> Structure:
>
> - libswt_indie.rpm ... just the .so libraries of the native swt
> parts. (need not include the gcj compiled swtXXX.so-library because at
> the moment it should be linked statically with the application - gcj
> is changing quite quickly) - libswt_indie_devel.rpm ... the swtXXX.jar
> file and .a files for static/shared compilation. - libswt_indie.srpm
> ... source rpm
>
While I think this is a good idea, I don't really know how to do it. I pretty mu
ch only use source packages. If it's not too hard I will try to do it. If someon
e were to come along and volunteer to do it, that would be great.
>
> 3) "SWT Instant Development Pack" (Sample application)
>
> A little sample application - should provide everything the java-developer
> needs for writing and packaging swt-applications:
>
> configure, Makefile, rpm-spec file and sample sources which can be
> compiled with libswt_indie_devel to an application that integrates
> into the linux desktop (start menu & icon - according to the rules of
> linuxbase.org and freedesktop.org? and/or the linux distributors).
>
> The Makefile should also enable static compilation (with a switch).
This is a really good idea, and of all the things you've listed I will probably
do this first. At least the configure.in, Makefile.am. I'm not too sure about th
e rpm-spec file, and the start menu and icon stuff. I guess I'll try to browse o
n over to linuxbase.org and freedesktop.org.
>
>
> 4) Patch for static linking:
>
> I have written a little patch for org.eclipse.swt.internal.Library to
> enable static linking of the swt native parts (and libgcj).
>
I don't really understand what you are saying here.
> http://www.scheinwelt.at/~norbertf/radiocap_homepage/gcjswtstatic.txt
> (there was a little problem with the gcj include-path also - i don't
> know if this can be resolved inside the configure-script or if this is
> a problem of my Mandrake 9.2 gcj 3.3.1)
>
Are you saying that libswt (this project) had a little problem? If so, can you e
laborate?
> Maybe the "swt_indie" patches should stay out of the original swt-sources
> and get patched during configure.
I am definitely in favor of inluding the patch, one way or another. So I'll eith
er add it to the distribution, but distribute the patched version, or patch duri
ng make. I dont't think I'll patch during configure. How does that sound?
>
>
> 5) jface:
>
> Maybe swt_indie should also provide a (standalone) jface-package.
This is problematic. Do we want to support gtk on windows, or should we just go
with the native version of swt? I think it makes much more sense to use the nati
ve version of SWT. If you are proposing a libswt-win32, I don't have a problem w
ith that. But I am less interested in libswt-gtk on win32.
Hi!
First let me thank you for your libswt package. It was quite useful for building a static binary of this little audio application: http://www.scheinwelt.at/~norbertf/radiocap_homepage/ .
Here is my wishlist for the future of libswt:
1) Different library names:
"libswt-indie-XXX" (just my proposal) to avoid conflicts with the so-libraries provided by the eclipse-project - they could be installed in /usr/lib or /usr/local/lib without collisions. (The swt-source needs to be patched to accept the different library names).
2) Binary distributions (RPMs).
Structure:
- libswt_indie.rpm ... just the .so libraries of the native swt parts. (need not include the gcj compiled swtXXX.so-library because at the moment it should be linked statically with the application - gcj is changing quite quickly)
- libswt_indie_devel.rpm ... the swtXXX.jar file and .a files for static/shared compilation.
- libswt_indie.srpm ... source rpm
3) "SWT Instant Development Pack" (Sample application)
A little sample application - should provide everything the java-developer needs for writing and packaging swt-applications:
configure, Makefile, rpm-spec file and sample sources which can be compiled with libswt_indie_devel to an application that integrates into the linux desktop (start menu & icon - according to the rules of linuxbase.org and freedesktop.org? and/or the linux distributors).
The Makefile should also enable static compilation (with a switch).
4) Patch for static linking:
I have written a little patch for org.eclipse.swt.internal.Library to enable static linking of the swt native parts (and libgcj).
http://www.scheinwelt.at/~norbertf/radiocap_homepage/gcjswtstatic.txt
(there was a little problem with the gcj include-path also - i don't know if this can be resolved inside the configure-script or if this is a
problem of my Mandrake 9.2 gcj 3.3.1)
Maybe the "swt_indie" patches should stay out of the original swt-sources and get patched during configure.
5) jface:
Maybe swt_indie should also provide a (standalone) jface-package.
6) gcj/swt-win32
Mohan Embar of the GCJ-development team is providing Win32 packages of gcj and swt.
http://www.thisiscool.com/gcc_mingw.htm
http://www.mingw.org/download.shtml
The sample application should also provide a Makefile.mingw32.
7) Homepage: Links to other java-projects enabling java-guis on linux/unix:
http://java-gnome.sourceforge.net/
http://gnome-gcj.sourceforge.net/ (stopped?)
http://sourceforge.net/projects/javacurses/
thanks
norbert
Hi!
> First let me thank you for your libswt package. It was quite
> useful for building a static binary of this little audio application:
> http://www.scheinwelt.at/~norbertf/radiocap_homepage/ .
Glad to hear it.
> Here is my wishlist for the future of libswt:
>
>
> 1) Different library names:
>
> "libswt-indie-XXX" (just my proposal) to avoid conflicts with the
> so-libraries provided by the eclipse-project - they could be installed
> in /usr/lib or /usr/local/lib without collisions. (The swt-source needs
> to be patched to accept the different library names).
>
Actually, people who already have the libs shouldn't need to re-install since th
e source is identical. Is that good enough? And we're only talking about the sup
port libs, right?
> 2) Binary distributions (RPMs).
>
> Structure:
>
> - libswt_indie.rpm ... just the .so libraries of the native swt
> parts. (need not include the gcj compiled swtXXX.so-library because at
> the moment it should be linked statically with the application - gcj
> is changing quite quickly) - libswt_indie_devel.rpm ... the swtXXX.jar
> file and .a files for static/shared compilation. - libswt_indie.srpm
> ... source rpm
>
While I think this is a good idea, I don't really know how to do it. I pretty mu
ch only use source packages. If it's not too hard I will try to do it. If someon
e were to come along and volunteer to do it, that would be great.
>
> 3) "SWT Instant Development Pack" (Sample application)
>
> A little sample application - should provide everything the java-developer
> needs for writing and packaging swt-applications:
>
> configure, Makefile, rpm-spec file and sample sources which can be
> compiled with libswt_indie_devel to an application that integrates
> into the linux desktop (start menu & icon - according to the rules of
> linuxbase.org and freedesktop.org? and/or the linux distributors).
>
> The Makefile should also enable static compilation (with a switch).
This is a really good idea, and of all the things you've listed I will probably
do this first. At least the configure.in, Makefile.am. I'm not too sure about th
e rpm-spec file, and the start menu and icon stuff. I guess I'll try to browse o
n over to linuxbase.org and freedesktop.org.
>
>
> 4) Patch for static linking:
>
> I have written a little patch for org.eclipse.swt.internal.Library to
> enable static linking of the swt native parts (and libgcj).
>
I don't really understand what you are saying here.
> http://www.scheinwelt.at/~norbertf/radiocap_homepage/gcjswtstatic.txt
> (there was a little problem with the gcj include-path also - i don't
> know if this can be resolved inside the configure-script or if this is
> a problem of my Mandrake 9.2 gcj 3.3.1)
>
Are you saying that libswt (this project) had a little problem? If so, can you e
laborate?
> Maybe the "swt_indie" patches should stay out of the original swt-sources
> and get patched during configure.
I am definitely in favor of inluding the patch, one way or another. So I'll eith
er add it to the distribution, but distribute the patched version, or patch duri
ng make. I dont't think I'll patch during configure. How does that sound?
>
>
> 5) jface:
>
> Maybe swt_indie should also provide a (standalone) jface-package.
I don't really know anything about jface.
>
>
> 6) gcj/swt-win32
>
> Mohan Embar of the GCJ-development team is providing Win32 packages of
> gcj and swt.
>
> http://www.thisiscool.com/gcc_mingw.htm
>
> http://www.mingw.org/download.shtml
>
> The sample application should also provide a Makefile.mingw32.
This is problematic. Do we want to support gtk on windows, or should we just go
with the native version of swt? I think it makes much more sense to use the nati
ve version of SWT. If you are proposing a libswt-win32, I don't have a problem w
ith that. But I am less interested in libswt-gtk on win32.
>
> 7) Homepage: Links to other java-projects enabling java-guis on
> linux/unix:
>
> http://java-gnome.sourceforge.net/
>
> http://gnome-gcj.sourceforge.net/ (stopped?)
>
> http://sourceforge.net/projects/javacurses/
>
>
> thanks
>
> norbert
Thanks very much for the feedback. It is very much appreciated. I'll try to get
to work on the sample application.
-McKenzie