[GUI] Packaging, and GUIs

[Adrian Hey]

Hello

It's interesting to see that his ideas for GUI development
seem pretty much identical to mine except I've decided to
use SDL for now (and Haskell of course :-)

Regards
--
Adrian Hey

On Wednesday 23 July 2003 08:27, Simon Peyton-Jones wrote:
> Dear Haskell library and GUI folk,
>
> Here's an interesting message from the Caml mailing list, largely
> focusing on
> 	a) packaging
> 	b) GUIs
>
> Interestingly, the very two topics on which we have active groups
> working!  I wonder if it'd be a good time for a status report from both
> efforts?  Both have been very quiet of late, but I see that Daan and
> Krasimir have both published new GUI libraries recently, so GUI stuff is
> still going on.
>
> Simon
>
> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Clearwater
> Sent: 18 July 2003 22:21
> To: caml-list@inria.fr
> Subject: [Caml-list] Roadplan for world domination (or constructive
> criticism of ocaml facilities)
>
>     I have come across the Ocaml language several months ago and after
> much
> investigation and trial coding I have come to several conclusions. Most
> importantly I think Ocaml is a wonderful language to program in. It has
> all
> the features I would expect from a modern language and on top of that
> it's
> compiled native code appears to rival that of C in many areas. It truly
> is
> the language of the future. Now that I have expressed how much I am
> growing
> to love Ocaml I would like to share with you my initial experiences as a
> new
> user. First I would like to single out some issues that I believe
> threaten
> Ocaml from being taken seriously and then i would like to offer some
> solutions that would improve the usability of ocaml greatly.
>
> - Support on win32 could certainly be much better
> - Compiling and distributing Ocaml source is a very delicate process
> - There exists much fragmentation among usage of different GUI toolkits
>   and they are limited to C/C++ conventions. (Is it possible to create
> your
>   own custom GTK widgets within ocaml?)
>
> And without further ado I present to you 10 steps to world domination:
>
> 1) Support for Ocaml on win32 (both as a development and target
> enviroment) is
> very crucial for the adoption and practicality of Ocaml. For example,
> look at
> the trouble some developers must go through to get their application
> running
> under win32: http://groups.yahoo.com/group/unison-hackers/message/31.
> Forutnately this doesn't have to be the case. The mingw32 toolset allow
> compilation and linking to be done very similarily to how it is done on
> Unix.
> Also, it enables one to develop win32 apps without shelling out hundeds
> of
> dollars to Microsoft:
> http://msdn.microsoft.com/visualc/howtobuy/pricing.aspx
> I propose mingw32 be made the default compiler/linker for native win32
> binaries
> (or even drop MSVC support entirely).
>
> 2) Take the idea of ocamlmklib further to generalize the compilation of
> both
> Ocaml programs and libraries into a module called "Ocamlmake". Also
> create a
> binary of ocamlmake which makes use of the module for command line
> compiling
> and include these in the standard distribution on all platforms.
>
> 3) Now that we have a easy cross-platform way to compile ocaml
> applications we
> can just distibute our code with Makefiles that call ocamlmake! WRONG.
> Makefiles suck. Now we standardize on the idea of an Ocaml "package".
> Each
> package would include in it's toplevel directory a file called setup.ml
> (This
> is starting to resemble python's distutils indeed). setup.ml would make
> use of
> the Ocamlmake module by building a record and passing it to
> Ocamlmake.setup.
> This record might be static or it might be created by
> self-configuration.
> For example, the ocamlsdl package would call sdl-config to retrieve some
> compilation flags. You _would_ rather configure in ocaml than "portable
> shell
> script", right? Then to build the application you would execute
> "ocamlrun
> setup.ml build" and "ocamlrun setup.ml install" to install it. Also the
> record
> would contain meta-information such as the author, copyright, etc.
>
> 4) Change the ocaml distribution to compile using Ocamlmake :) (except
> for
> bootstrapping if you dont already have a previous version of ocaml
> installed)
>
> 5) Create a module called Framebuffer which parallels the primtives
> found in
> OpenGL/DirectX. The Graphics module is close, but the design doesn't
> match
> well with these two APIs (We want hardware acceleration). Implement for
> each
> platform a Framebuffer module (DirectX or OpenGL where available, Xlib
> or
> other native graphics system otherwise). Include this in the standard
> distribution.
>
> 6) Create a cross-platform Event module. Include this in the standard
> distribution.
>
> 7) Create a cross-platform Font module (wrap freetype or create an Ocaml
> implementation). Include this in the standard distribution.
>
> 8) Create a GUI on top of the Framebuffer, Event, and Font modules,
> implemented in Ocaml :) Include this in the standard distribution.
>
> 9) Now the big payoff, we write a standard Ocaml IDE, to be included
> with the
> Ocaml distribution. It would be well integrated with the distribution.
> Ocamlmake
> module for compiling, the ocaml lexer for syntax highlighting, exporting
> packages
> (setup.ml). This would make it incredably easy to get started creating
> cross-platform libraries and modules. Realating to point #1, now a win32
> user
> need only grab the mingw32 and Ocaml distributions and they are set.
> They can
> even easily export their code to a ocaml package for distribution.
> Obviously the
> benefit extends to all other platforms as well.
>
> 10) World domination.
>
> I would greatly appreciate any feedback.
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>
>
> _______________________________________________
> GUI mailing list
> GUI@haskell.org
> http://www.haskell.org/mailman/listinfo/gui