writes:

On Thu, 15 Jul 2010 18:40:05 -0300 Felipe Lessa wrote:

...

...

Questions remain about what GUI lib to bring in, to augment the OpenGL suite.

   * gtk2hs

+1. gtk2hs also comes with cairo which many diagramming packages use.

I would be happy with just cairo...

Agreed! G -- Gregory Collins

Felipe Lessa writes:

Of course I also prefer just cairo over nothing at all. However, if we bundle cairo (and pango, probably) it shouldn't be hard to bundle all of gtk2hs, right? Is there a reason to include just cairo+pango?

Gtk2hs doesn't work very well on OSX or Windows, that's the main reason I think. G -- Gregory Collins

On Sat, 17 Jul 2010 16:56:23 +0200 Axel Simon wrote:

As far as I can see, there is a gradual overhead of C libraries involved here. The Platform could ship the following subsets of Gtk2Hs:

cairo cairo+glib+pango cairo+glib+pango+gio cairo+glib+pango+gio+gtk

It's a question of how big the tar ball is and how much work it is to bundle the C libraries with the Platform.

Cheers,

That's why I voted for including just cairo. it's low overhead, high quality and gives your haskell install access to cross-platform graphics capability.

On Sat, 17 Jul 2010 12:49:25 -0700 Don Stewart wrote:

briand:

...

On Sat, 17 Jul 2010 16:56:23 +0200 Axel Simon wrote:

...

As far as I can see, there is a gradual overhead of C libraries involved here. The Platform could ship the following subsets of Gtk2Hs:

cairo cairo+glib+pango cairo+glib+pango+gio cairo+glib+pango+gio+gtk

It's a question of how big the tar ball is and how much work it is to bundle the C libraries with the Platform.

Cheers,

That's why I voted for including just cairo.

it's low overhead, high quality and gives your haskell install access to cross-platform graphics capability. _______________________________________________

We wouldn't bundle the C source (as we don't e.g. for GL or Regex.c currently)

I understand, but you only need libcairo and some sort of -dev version of libcairo. as you start to lump stuff on top of it, then there's more to install, and you can easily end up in dependency hell where things won't install because of some annoying dependency. For example, the cabal version of gtk2hs installed very smoothly but I think I had to install 2 cabal packages and at least 4 -dev system libs before I was done. really, access to screen graphics of some sort is a wishlist item. Another option would be to include something that generates postscript output only. The nice thing about cairo is that it will do that in addition to giving you a screen display should you desire, and all with the same code :-) Brian

On Sat, 17 Jul 2010 17:47:03 -0300 Felipe Lessa wrote:

On Sat, Jul 17, 2010 at 4:39 PM, wrote:

...

On Sat, 17 Jul 2010 16:56:23 +0200 Axel Simon wrote:

...

As far as I can see, there is a gradual overhead of C libraries involved here. The Platform could ship the following subsets of Gtk2Hs:

cairo cairo+glib+pango cairo+glib+pango+gio cairo+glib+pango+gio+gtk

It's a question of how big the tar ball is and how much work it is to bundle the C libraries with the Platform.

Cheers,

That's why I voted for including just cairo.

it's low overhead, high quality and gives your haskell install access to cross-platform graphics capability.

How useful is cairo without pango?

Good question ! Fonts are still available even without pango, for example freetype fonts are supported. I think there are limitations but I can't remember exactly what. I've been down this road before, and I think that for basic use your good-to-go without pango as long as you don't want to run your text along a spiral path, or something like that. What I can't remember and what some of my example code doesn't reveal, is whether text rotation is possible. As long as you can scale and rotate cairo withot pango would be ok, right ? Brian

On Jul 18, 2010, at 0:06, Vo Minh Thu wrote:

2010/7/17 :

...

On Sat, 17 Jul 2010 17:47:03 -0300 Felipe Lessa wrote:

...

On Sat, Jul 17, 2010 at 4:39 PM, wrote:

...

On Sat, 17 Jul 2010 16:56:23 +0200 Axel Simon wrote:

...

As far as I can see, there is a gradual overhead of C libraries involved here. The Platform could ship the following subsets of Gtk2Hs:

cairo cairo+glib+pango cairo+glib+pango+gio cairo+glib+pango+gio+gtk

It's a question of how big the tar ball is and how much work it is to bundle the C libraries with the Platform.

Cheers,

That's why I voted for including just cairo.

it's low overhead, high quality and gives your haskell install access to cross-platform graphics capability.

How useful is cairo without pango?

Good question ! Fonts are still available even without pango, for example freetype fonts are supported. I think there are limitations but I can't remember exactly what.

I've been down this road before, and I think that for basic use your good-to-go without pango as long as you don't want to run your text along a spiral path, or something like that.

What I can't remember and what some of my example code doesn't reveal, is whether text rotation is possible. As long as you can scale and rotate cairo withot pango would be ok, right ?

Hi,

Cairo is useful without pango: it is a vector drawing library (so this alone is useful) and has basic support for text. (Pango can do complicated stuff like right-to-left layout.)

As a vector library, anything can be scaled, rotated, clipped, ... included text.

cairo alone does not allow you to set Unicode text. That's what Pango is all about. As a rule of thumb, cairo shouldn't be used if any user- supplied text has to be rendered. If only numbers and simple string constants need to be rendered, cairo can do this. The transformations available for the text are identical for cairo texts and pango texts. Cheers, Axel

bos:

On Thu, Jul 15, 2010 at 9:01 PM, Don Stewart wrote:

Things we might realistically propose to add for 2011.1

   New capabilities:        * Binary parsing: binary + cereal ?

Why both? Their parallel existence and purpose is already confusing, without blessing the two :-)

They cover the full design space: * strict synchronous-error-checking * lazy, asynchronous-errors  

It seems like a very minimal library to have such a canonical name. It's honestly hard for me to imagine that it's been battle tested against much real XML data or that it fulfills many of the ever so slightly esoteric needs that XML users tend to have, given how small it is.

Well, its popular is all. More so than HaXml at this point.  

       * Databases:      HDBC

Is this even maintained any more?

Very much so. But it has the wrong license.

On Fri, Jul 16, 2010 at 1:26 PM, Simon Marlow wrote:

On 15/07/2010 23:53, Bryan O'Sullivan wrote:

...

On Thu, Jul 15, 2010 at 9:01 PM, Don Stewart mailto:dons@galois.com> wrote:

Things we might realistically propose to add for 2011.1

New capabilities: * Binary parsing: binary + cereal ?

Why both? Their parallel existence and purpose is already confusing, without blessing the two :-)

Right, if there are are two competing libraries and it's not clear which one is best, that's a sign that we shouldn't put either in the platform until the differences are resolved. Fight it out and get back to us when you have an answer :-)

Lennart has added a continuation based interface, on top of which the current lazy interface is implemented. The continuation based interface supports a strict interface, with error checking. Whenever that interface is released binary should subsume cereal.

* Unicode: text

...

Abstain :-) I will observe that it needs a tiny bit more API stabilisation, but that's almost done.

+1

I want to see this in HP too but I'll wait until Bryan thinks it's ready.

* Vectors: vector

...

Definitely want.

+1

+1

Hi, Am Freitag, den 16.07.2010, 09:07 -0700 schrieb Don Stewart:

marlowsd:

...

On 15/07/2010 23:53, Bryan O'Sullivan wrote:

...

On Thu, Jul 15, 2010 at 9:01 PM, Don Stewart mailto:dons@galois.com> wrote:

Things we might realistically propose to add for 2011.1

New capabilities: * Binary parsing: binary + cereal ?

Why both? Their parallel existence and purpose is already confusing, without blessing the two :-)

Right, if there are are two competing libraries and it's not clear which one is best, that's a sign that we shouldn't put either in the platform until the differences are resolved. Fight it out and get back to us when you have an answer :-)

They're complimentary. Sometimes you need parsing of streams, sometimes you need synchronous parsing of strict packets.

but it would still be nicer if the two packages could somehow converge more. For example, as a user of the library, I’d like to be able to parse data from a network stream as well as from a local file using similar code, requiring only one instance, and be able to create both kinds of a parser with one instance (or at least with very similar instance). If Johan’s prognosis is right and binary will subsume cereal in the future, maybe we should only add binary to the platform at this time. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

duncan.coutts:

On Fri, 2010-07-16 at 09:07 -0700, Don Stewart wrote:

...

marlowsd:

...

On 15/07/2010 23:53, Bryan O'Sullivan wrote:

...

On Thu, Jul 15, 2010 at 9:01 PM, Don Stewart mailto:dons@galois.com> wrote:

Things we might realistically propose to add for 2011.1

New capabilities: * Binary parsing: binary + cereal ?

Why both? Their parallel existence and purpose is already confusing, without blessing the two :-)

Right, if there are are two competing libraries and it's not clear which one is best, that's a sign that we shouldn't put either in the platform until the differences are resolved. Fight it out and get back to us when you have an answer :-)

They're complimentary. Sometimes you need parsing of streams, sometimes you need synchronous parsing of strict packets.

We can do both with one package once we have the right primitives.

I agree. I hesitate to wait for another year to have binary parsing in the platform, so perhaps we should aim for the integrated binary package in the next 3 months.

niklas.broberg:

...

According to the 2010 download stats, the most popular libs *not* in the Haskell Platform, by category are :

Libs    binary       (rank  5/2200)    utf8-string  (rank  7/2200)    ghc-paths    (rank 15/2200) -- needed by haddock!    hslogger     (rank 16/2200  -- LPGL ...

And haskell-src-exts (rank 10/2200) is considered already in, or what? ;-)

Will it replace haskell-src ? -- Don

niklas.broberg:

...

According to the 2010 download stats, the most popular libs *not* in the Haskell Platform, by category are :

Libs    binary       (rank  5/2200)    utf8-string  (rank  7/2200)    ghc-paths    (rank 15/2200) -- needed by haddock!    hslogger     (rank 16/2200  -- LPGL ...

And haskell-src-exts (rank 10/2200) is considered already in, or what? ;-)

It might be a good goal to have haskell-src-exts replace haskell-src by the time of the next major release, http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable Which means a proposal, after the release next week: http://trac.haskell.org/haskell-platform/wiki/AddingPackages Similarly for text, vector, binary. -- Don

Simon Marlow writes:

So I suggest we leave the GUI library as an add-on, but explain clearly how people can get up and running with *some* GUI library quickly, with pointers to instructions for their platform.

Is it possible to have other sets of similar libraries? For example, even more than the category section of Hackage, we could have "semi-blessed" Haskell packages listed on the platform for web-development (happstack and snap), documents (pandoc), etc. to indicate packages which are considered to be of good/high quality but with no obvious preference to put into the "batteries included" Platform package. As such, the actual Platform install becomes an initial starting point, with pointers given to specific sub-fields. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Hi Don, Heinrich, On Jul 18, 2010, at 9:58, Heinrich Apfelmus wrote:

Henk-Jan van Tuyl wrote:

...

...

Questions remain about what GUI lib to bring in, to augment the OpenGL suite.

* gtk2hs * wxHaskell I tried GTK+ (with gtk2hs) a few years ago, together with Glade (the windows designer for GTK+), and found many serious bugs in a short time. I decided not to use it. It might just have been the Windows port that has these bugs; SourceForge showed that only one

Don Stewart wrote: person was working on that port. That is not the only downside: it has an LGPL license.

I have tried to maintain Gtk2Hs for decade now and saw various people come and go. I admit that I don't write much GUI code myself and don't know how complete the API is and how many bugs are still lurking in the code. I've spend most of my time working around various build bugs and the adaption to the various Gtk+ and ghc versions. Also, I don't know if the bugs you found relate to Gtk+ or to Gtk2Hs. I guess that distinction doesn't really matter to the end user, but I think it matters to the decision of blessing Gtk2Hs as some sort of default GUI toolkit. With respect to the license: Gtk+ is LGPL and we simply used the same license. I think I can convince the relevant contributors to change the license of Gtk2Hs to BSD or whatever is more convenient. wxWidgets is "essentially LGPL with an exception stating that derived works in binary form may be distributed on the user's own terms". So if this "downside" you're talking about has to do with shipping commercial Haskell GUI applications, I think we can easily find satisfactory solution. After all, wxWidget uses the LGPL'd Gtk+ toolkit on Linux.

I'm on MacOS and it's similar for me. GTK just keeps crashing randomly or behaving weirdly, reducing the utility of cool tools like hp2any .

The same question: do you mean Gtk2Hs or Gtk+? If it's the former, then we should fix the bugs. We are about to release Gtk 0.11.1 which has hopefully now all the concurrency bugs ironed out. Having cabalized Gtk2Hs, I hope users find the libraries more inviting to send in patches since it's now fairly simple to understand how to build the beast.

Even if it's not a native GUI on MacOS, I'd at least accept gtk2hs if it were bundling a precompiled version of the GTK libraries that just works (tm).

I hope that the Aqua port of Gtk+ will mature eventually and that Gtk+ reaches a similar look-and-feel as Qt on the major three platforms. It will never be perfect, but if there's some sort of abstraction for the menu bar and some good themes, then it might be acceptable to most people. Having Gtk2Hs in the platform would then be very convenient as it would relieve the user from the burden of installing all those different binary libraries. I am not willing to invest the time to provide a Mac and Windows installer just for Gtk2Hs since then I always have to track the ghc and platform releases and opens a lot of different platform problems that cabal currently abstracts for me. Cheers, Axel

Heinrich Apfelmus schrieb:

Axel Simon wrote: [...]

...

I hope that the Aqua port of Gtk+ will mature eventually and that Gtk+ reaches a similar look-and-feel as Qt on the major three platforms. It will never be perfect, but if there's some sort of abstraction for the menu bar and some good themes, then it might be acceptable to most people.

For me, it's mostly a question of stability and "zippiness". I accept Gimp but I don't like Inkscape, for example.

...

Having Gtk2Hs in the platform would then be very convenient as it would relieve the user from the burden of installing all those different binary libraries. I am not willing to invest the time to provide a Mac and Windows installer just for Gtk2Hs since then I always have to track the ghc and platform releases and opens a lot of different platform problems that cabal currently abstracts for me.

Ah, using cabal for Gtk2Hs is fine, the Haskell side usually works very well. What I had in mind is that it ships a compiled version of the corresponding Gtk+ libraries, because the real pain on MacOS is to install those. There was a precompiled Gtk+ framework if I remember correctly, but that one seems to be unsupported nowadays; or one can install from source but that takes hours and then you'll run into at least one compilation error and throw up your arms in desperation.

We (still) use http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets... that I originally obtained from http://r.research.att.com/. (They ship http://r.research.att.com/libs/GTK_2.18.5-X11.pkg now) Note: gtk2-framework.dmg is non-Aqua and relies on X11. HTH Christian