Menu

Hi! Future of libswt - My wishlist

n.f.
2003-11-03
2003-11-05
  • n.f.

    n.f. - 2003-11-03

    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

     
    • McKenzie Keith

      McKenzie Keith - 2003-11-05

      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

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.