From: Duncan C. <dun...@wo...> - 2007-11-08 02:11:24
|
Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12.1 is now available from: http://haskell.org/gtk2hs/download/ The source tarball and an installer for Windows are available. Packages for various platforms should become available soon, hopefully including Debian, Fedora, Gentoo, FreeBSD and Darwin. Changes since 0.9.12.1: * builds with GHC 6.8.1 * updated SOE API to match that of the recent SOE release * added status icon binding * added text buffer clipboard functions * fix build issue with recent glib versions * a few minor bug fixes Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 API * support for several additional Gtk+/Gnome modules: * Glade visual GUI builder * cairo vector graphics library * SVG rendering for cairo * OpenGL extension (works with HOpenGL) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * an implementation of the Graphics.SOE API * extensive haddock API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows and Solaris * should also build from source on MacOS X and FreeBSD * builds with GHC 6.4.2 - 6.8.1 * works with Gtk+ version 2.0 through to 2.10 * SVG support requires librsvg version 2.16 or later Please report all problems to gtk...@so... or in our bug tracker http://hackage.haskell.org/trac/gtk2hs Contributions and feedback are also most welcome. Windows release notes: The installer expects GHC 6.8.1 or GHC 6.6.1. Duncan (on behalf of the Gtk2Hs team) |
From: Wolfgang J. <g9k...@ac...> - 2007-11-08 10:33:43
|
Am Donnerstag, 8. November 2007 03:14 schrieb Duncan Coutts: > [=E2=80=A6] > * multi-platform support with native look Really? I thought that GTK+ paints all the widgets by itself and therefore= =20 doesn=E2=80=99t get the native look completely right. Especially not on Ma= c OS X. > * LGPL licence Oh, I didn=E2=80=99t know this. I think, this could be a serious problem. = The LGPL=20 doesn=E2=80=99t allow usage of the library in proprietary software, except = where the=20 library code is only linked with the proprietary code. I suppose that GHC= =20 doesn=E2=80=99t just link different packages but uses information of used p= ackages=20 during compiling. This would mean that it=E2=80=99s not possible to build= =20 proprietary software with Gtk2Hs which would be bad. Please use BSD3 for=20 Haskell libraries! > [=E2=80=A6] Best wishes, Wolfgang |
From: Duncan C. <dun...@wo...> - 2007-11-08 11:35:52
|
On Thu, 2007-11-08 at 11:33 +0100, Wolfgang Jeltsch wrote: > Am Donnerstag, 8. November 2007 03:14 schrieb Duncan Coutts: > > […] > > > * multi-platform support with native look > > Really? I thought that GTK+ paints all the widgets by itself and therefore > doesn’t get the native look completely right. Especially not on Mac OS X. It uses a combination. On Windows it uses the native theming dll to follow the theme, though yes it has to paint the classic theme itself. The native look is not 100% but it's really pretty close these days. Note that I didn't say native look and feel :-) You're right on OSX it's not close. We're waiting for the native (non-X11) GTK+ backend on OSX. That's still in development. > > * LGPL licence > > Oh, I didn’t know this. I think, this could be a serious problem. The LGPL > doesn’t allow usage of the library in proprietary software, except where the > library code is only linked with the proprietary code. I suppose that GHC > doesn’t just link different packages but uses information of used packages > during compiling. This would mean that it’s not possible to build > proprietary software with Gtk2Hs which would be bad. Please use BSD3 for > Haskell libraries! We've used LGPL because that's the license that GTK+ itself uses. If you think it's a major problem we could see about adding a linking exception to allow static linking of the Gtk2Hs library. Obviously the GTK+ C libs are always dynamically linked to satisfying the LGPL there is easy. It's not that easy to change however as there have been many contributers so it's not easy to relicence (or add an exception) as we need their consent. Another alternative (as of GHC version 6.8.x) is to build Haskell libraries as dynamic libs. That would then put us in the same situation as for the GTK+ C libs. Duncan |
From: Peter G. <pg...@gm...> - 2007-11-09 13:35:59
|
On Nov 8, 2007 6:38 AM, Duncan Coutts <dun...@wo...> wrote: > Another alternative (as of GHC version 6.8.x) is to build Haskell > libraries as dynamic libs. That would then put us in the same situation > as for the GTK+ C libs. Does GHC 6.8 support PIC then? I looked in the docs and it still says something about PIC only being supported on PPC64. Or do the docs still need to be updated? Pete |
From: Duncan C. <dun...@wo...> - 2007-11-25 01:41:43
|
On Fri, 2007-11-09 at 08:36 -0500, Peter Gavin wrote: > On Nov 8, 2007 6:38 AM, Duncan Coutts <dun...@wo...> wrote: > > Another alternative (as of GHC version 6.8.x) is to build Haskell > > libraries as dynamic libs. That would then put us in the same situation > > as for the GTK+ C libs. > > Does GHC 6.8 support PIC then? > I looked in the docs and it still says something about PIC only being > supported on PPC64. Or do the docs still need to be updated? The code is in there. I think it's not officially supported in the 6.8.1 release. We might see it mature in 6.8.3. It's supposed to work on x86 (32 and 64 bit) Linux, MacOSX (x86 and ppc) and Windows 32bit. It can build PIC shared object libs and Cabal has some support for it too. Personally I've not tested it yet. Duncan |
From: <ha...@li...> - 2007-11-26 09:56:26
|
Duncan Coutts wrote: > On Fri, 2007-11-09 at 08:36 -0500, Peter Gavin wrote: >> On Nov 8, 2007 6:38 AM, Duncan Coutts <dun...@wo...> wrote: >>> Another alternative (as of GHC version 6.8.x) is to build Haskell >>> libraries as dynamic libs. That would then put us in the same situation >>> as for the GTK+ C libs. >> Does GHC 6.8 support PIC then? >> I looked in the docs and it still says something about PIC only being >> supported on PPC64. Or do the docs still need to be updated? > > The code is in there. I think it's not officially supported in the 6.8.1 > release. We might see it mature in 6.8.3. It's supposed to work on x86 > (32 and 64 bit) Linux, MacOSX (x86 and ppc) and Windows 32bit. It can > build PIC shared object libs and Cabal has some support for it too. > Personally I've not tested it yet. > > Duncan > Note that 6.8.1 does not work on ppc with the new OS X 10.5. http://hackage.haskell.org/trac/ghc/ticket/1843 -- Chris |
From: Wolfgang J. <g9k...@ac...> - 2007-11-09 13:30:51
|
Am Donnerstag, 8. November 2007 12:38 schrieben Sie: > [=E2=80=A6] > We've used LGPL because that's the license that GTK+ itself uses. If you > think it's a major problem we could see about adding a linking exception > to allow static linking of the Gtk2Hs library. Obviously the GTK+ C libs > are always dynamically linked to satisfying the LGPL there is easy. As far as I know, the LGPL always allows linking=E2=80=94be it static or dy= namic. =20 What the LGPL probably not allows is using LGPL-licensed code during=20 compilation of non-GPL/non-LGPL code. So if, for example, the compiler=20 inlines code of Gtk2Hs during compilation of another package, this other=20 package would probably have to be licensed under the GPL or LGPL. > [=E2=80=A6] > Another alternative (as of GHC version 6.8.x) is to build Haskell > libraries as dynamic libs. That would then put us in the same situation > as for the GTK+ C libs. Probably only if compilation is completely separate. But what about .hi=20 files? I don=E2=80=99t know what they contain. Do they contain some code = which can=20 be inlined? And even if not, couldn=E2=80=99t it be that GHC will have suc= h a=20 feature in the future? > Duncan Best wishes, Wolfgang |
From: Peter H. <pe...@sy...> - 2007-11-09 14:07:27
|
Wolfgang Jeltsch wrote: > Am Donnerstag, 8. November 2007 12:38 schrieben Sie: >> […] > >> We've used LGPL because that's the license that GTK+ itself uses. If you >> think it's a major problem we could see about adding a linking exception >> to allow static linking of the Gtk2Hs library. Obviously the GTK+ C libs >> are always dynamically linked to satisfying the LGPL there is easy. > > As far as I know, the LGPL always allows linking—be it static or dynamic. > What the LGPL probably not allows is using LGPL-licensed code during > compilation of non-GPL/non-LGPL code. So if, for example, the compiler > inlines code of Gtk2Hs during compilation of another package, this other > package would probably have to be licensed under the GPL or LGPL. This is not a legal advice. But the above is not true. Even when the code is inlined it does not force you to license your code under GPL or LGPL. The goal of LGPL is to preserve the right of your users to update the LGPL library to a newer version. So you can release your LGPL library dependent code under whatever license you want and it can be inlined, the only catch is that in such a situation you must provide a way to rebuild your proprietary application with a newer version the LGPL code used. Normally this means that you must allow users to download e.g. object files for your proprietary code and a script which can link it with the LGPL stuff ... or just release your proprietary code under license which allows it only to rebuild with a newer versions of the LGPL libs provided the users already have a license of your app, etc... bla bla bla. When a LGPL lib is a dll then the LGPL condition to rebuild your app is trivially fulfilled since your user can just upgrade the library by replacing the dll. This is great for you since you do not have more work to provide a way for LGPL library upgrade. That is the reason why some packages (like e.g. OCAML) which are LGPL licensed provide the exception that you do not need to provide a way to rebuild your app with a newer version of the LGPL code used. This way they rather give up the right of LGPL library upgrade in favor of saving commercial users some hassles. Peter. |
From: Peter G. <pg...@gm...> - 2007-11-09 15:44:30
|
On Nov 9, 2007 9:04 AM, Peter Hercek <pe...@sy...> wrote: > This is not a legal advice. > But the above is not true. Even when the code is inlined it does not > force you to license your code under GPL or LGPL. The goal of LGPL > is to preserve the right of your users to update the LGPL library > to a newer version. So you can release your LGPL library dependent > code under whatever license you want and it can be inlined, the only > catch is that in such a situation you must provide a way to rebuild > your proprietary application with a newer version the LGPL code used. > Normally this means that you must allow users to download e.g. object > files for your proprietary code and a script which can link it with > the LGPL stuff ... or just release your proprietary code under license > which allows it only to rebuild with a newer versions of the LGPL libs > provided the users already have a license of your app, etc... bla bla bla. > When a LGPL lib is a dll then the LGPL condition to rebuild your app > is trivially fulfilled since your user can just upgrade the library by > replacing the dll. This is great for you since you do not have more > work to provide a way for LGPL library upgrade. That is the reason > why some packages (like e.g. OCAML) which are LGPL licensed provide > the exception that you do not need to provide a way to rebuild your > app with a newer version of the LGPL code used. This way they rather > give up the right of LGPL library upgrade in favor of saving > commercial users some hassles. I should note that I would be fine with adding such an exception for my code, as opposed to changing to BSD or similar. That is, unless we actually get PIC and shared libs working properly. Pete |
From: Wolfgang J. <7o2...@ac...> - 2007-11-09 14:22:05
|
Am Freitag, 9. November 2007 15:04 schrieb Peter Hercek: > Wolfgang Jeltsch wrote: > > Am Donnerstag, 8. November 2007 12:38 schrieben Sie: > >> [=E2=80=A6] > >> > >> We've used LGPL because that's the license that GTK+ itself uses. If y= ou > >> think it's a major problem we could see about adding a linking excepti= on > >> to allow static linking of the Gtk2Hs library. Obviously the GTK+ C li= bs > >> are always dynamically linked to satisfying the LGPL there is easy. > > > > As far as I know, the LGPL always allows linking=E2=80=94be it static o= r dynamic. > > What the LGPL probably not allows is using LGPL-licensed code during > > compilation of non-GPL/non-LGPL code. So if, for example, the compiler > > inlines code of Gtk2Hs during compilation of another package, this other > > package would probably have to be licensed under the GPL or LGPL. > > This is not a legal advice. > But the above is not true. Even when the code is inlined it does not > force you to license your code under GPL or LGPL. The goal of LGPL=20 > is to preserve the right of your users to update the LGPL library > to a newer version. When the code is inlined, the user of the proprietary application needs the= =20 source code of this application since inlining is done during compilation a= nd=20 therefore updating the LGPL-licensed library forces the user to recompile t= he=20 application. Or am I missing something? > [=E2=80=A6]=20 Best wishes, Wolfgang |
From: Peter H. <pe...@sy...> - 2007-11-11 19:09:40
|
Wolfgang Jeltsch wrote: > When the code is inlined, the user of the proprietary application needs the > source code of this application since inlining is done during compilation and > therefore updating the LGPL-licensed library forces the user to recompile the > application. Or am I missing something? Yes, but that does not mean you need to provide all your sources (you can create a wrapper which hides the inlined macros for the rest of your app). Also it does not mean that the code you provide will need to have GPL or LGPL license. You can disallow any redistribution, copying (and whatever) of your code and allow its use *only* for recompile with newer version of the LGPL library and only when they have a license for your app. For all the parts of your app which do not use inlined code you can provide only object files. And you must provide a script which links this all with a newer version of the LGPL library. I'm not saying it is not a pain to do ... it may be enough hurdle that you rather decide not to use the LGPL library, since there may be cheaper alternatives ... or you can branch the LGPL library so that it compiles to a dll and just release the branch under LGPL license. Then build your commercial app against the dll branch. I just wanted to point out that when you use LGPL library your code does not need to be GPL or LGPL licensed (as you expected before). If your commercial application is an "in house" application only (i.e. you do not redistribute it) then LGPL does not limit you in any way. Peter. |