wxWindows vs. FLTK

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

wxWindows vs. FLTK

Juergen Fuhrmann
Hi,

>From the WIKI:

>
>Vis Lua Implementation
>
>This is some notes on various issues to do with the implementation of VisLua. 
>
>GUI library
>
>There are hundreds of GUI libraries [1], but few good portable, well maintained ones. Here are some options :- 
>
>    wxWindows [2]. This is quite a big library but had lots of useful widgets and is quite portable. Platforms supported are [3]
>    :-                     ^^^^^^^^^^^^^^^^^^^
Bloat!
>        Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME. 
>        Linux and other Unix platforms with GTK+. 
                                             ^^^^ 
Bloat!
>        Unix with Motif or the free Motif clone Lesstif. 
                                                 ^^^^^^^
Bloat!

So it does _not_ run on top of plain X11R6. We would depend on GTK+ or
Motif/Lesstif to get it ported.  IMHO nearly impossible to get the job
done.

>        Mac OS. 
>        Embedded platforms are being investigated. See the wxUniversal project. 
>        An OS/2 port is in progress, and you can also compile wxWindows for GTK+ or Motif on OS/2. 
>    FLTK [4]. Quite compact and fast, as name implies. Not particularly portable. Platforms :- 
>        X - Unix. 
Just on top of plain X11R6 and glx (for OpenGL) without any additional library. 
Very clean, appearantly works everywhere where C++ and X works, i.e. on every **ix/ux 
>        Win32. 
         Now MacOS. (see www.fltk.org)
Embedded platforms being investigated. See e.g. http://www.ssv-embedded.de/trm/021203gui.htm.

May be  my bloat statements are a  bit drastic, so please  do not take
them personally,  but LuaCheia already  seems to become  quite complex
and we need to keep the ends...

Juergen

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
Re bloat and wxWindows...
maybe one could do a binding to a subset of wxWindows, not like wxLua that tries to include everything wx has to offer... But then, what could be left out? Mainly anything that is not GUI related, as that would/should be coverd by other Luamodules (Sockets, DBI etc)

Just consider a (statically) linked WxWindows app. Filesizes of about 500kb for a simple editor etc.
The complete wxLua binary is arounf 2MB...

-Martin

Juergen Fuhrmann wrote:

Hi,

>From the WIKI:

Vis Lua Implementation

This is some notes on various issues to do with the implementation of VisLua.
GUI library

There are hundreds of GUI libraries [1], but few good portable, well maintained ones. Here are some options :-
  wxWindows [2]. This is quite a big library but had lots of useful widgets and is quite portable. Platforms supported are [3]
  :-                     ^^^^^^^^^^^^^^^^^^^
Bloat!
Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME. Linux and other Unix platforms with GTK+.
^^^^ Bloat!
Unix with Motif or the free Motif clone Lesstif.
                                                ^^^^^^^
Bloat!

So it does _not_ run on top of plain X11R6. We would depend on GTK+ or
Motif/Lesstif to get it ported.  IMHO nearly impossible to get the job
done.

Mac OS. Embedded platforms are being investigated. See the wxUniversal project. An OS/2 port is in progress, and you can also compile wxWindows for GTK+ or Motif on OS/2. FLTK [4]. Quite compact and fast, as name implies. Not particularly portable. Platforms :- X - Unix.
Just on top of plain X11R6 and glx (for OpenGL) without any additional library. Very clean, appearantly works everywhere where C++ and X works, i.e. on every **ix/ux
Win32.
        Now MacOS. (see www.fltk.org)
Embedded platforms being investigated. See e.g. http://www.ssv-embedded.de/trm/021203gui.htm.

May be  my bloat statements are a  bit drastic, so please  do not take
them personally,  but LuaCheia already  seems to become  quite complex
and we need to keep the ends...

Juergen




Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Eero Pajarre-3
In reply to this post by Juergen Fuhrmann
I wrote to this list related to these packages some time ago.
At that time I ended up using wxwindows for two main reasons:

The package had been updated more recently (2002 vs 2001)
Wxwindows interface was under a license more suitable for me.
(lua-fltk was/is under LGPL)

Even though I at the moment use the wxwindows interface, I have
reason to believe that FLTK might be better for my application.
So I could volunteer to work with it. I would need to start
from begining or request the current Lua-FLTK owner to release
it under Lua/MIT license though.



		Eero





Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
Eero Pajarre wrote:
Even though I at the moment use the wxwindows interface, I have
reason to believe that FLTK might be better for my application.
So I could volunteer to work with it. I would need to start
from begining or request the current Lua-FLTK owner to release
it under Lua/MIT license though.

I would personaly prefer LuaCheia modules to not rely on automatic bindings, as to enable the full power of the Lua language. If you would be willing to look into doing a new FLTK binding, that would be very intersting.

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Eero Pajarre-3
Martin Spernau wrote:

I would personaly prefer LuaCheia modules to not rely on automatic bindings, as to enable the full power of the Lua language.

Could you clarify this?

The current lua-fltk is based on toLua generated interface.
Based on the documentation the usage looks pretty clean.
The wxwindows interface was done (mostly) with a specific
conversion script. I think it also generated a pretty nice
Lua-look-and-feel.




		Eero



Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Juergen Fuhrmann
In reply to this post by Martin Spernau
>  Tue, 11 Feb 2003 16:36:03 +0100
>  Martin Spernau <[hidden email]> wrote:
>
>  Re bloat and wxWindows...
>  maybe one could do a binding to a subset of wxWindows, not like wxLua 
>  that tries to include everything wx has to offer...
>  But then, what could be left out? Mainly anything that is not GUI 
>  related, as that would/should be coverd by other Luamodules (Sockets, 
>  DBI etc)


Well, then we would have to work on a wxWindows core distro...

Juergen

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
In reply to this post by Eero Pajarre-3
From: "Eero Pajarre" <[hidden email]>
> Martin Spernau wrote:
>
> > I would personaly prefer LuaCheia modules to not rely on automatic
> > bindings, as to enable the full power of the Lua language.
>
> Could you clarify this?

What I was reffering to are automatically generated bindings that closely
follow the C-style calling conventions. My own naive efforts with building a
PCRE binding with swig and tolua resulted in such code, and I dumped that
for a handwritten Lua binding (which in the case of PCRE is actually no big
deal).

One thing that binding generators can not provide tho is returning of
multiple results (eg. as tables), here a handwritten binding would much more
build on the power of Lua.
Ans yes, the wxLua bindings are rather clean and nice to use, but they still
follow the C++ style of building a GUI. Lua as a language could provide a
far 'higher level' approach. But then the way it is is easier on the
documentation / example code side, as one can easily transform the sample
C++ coe into Lua code...

I might be mistaken, and will gladly be corrected tho.

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Eero Pajarre-3
Martin Spernau wrote:

One thing that binding generators can not provide tho is returning of
multiple results (eg. as tables), here a handwritten binding would much more
build on the power of Lua.
Ans yes, the wxLua bindings are rather clean and nice to use, but they still
follow the C++ style of building a GUI. Lua as a language could provide a
far 'higher level' approach. But then the way it is is easier on the
documentation / example code side, as one can easily transform the sample
C++ coe into Lua code...


We might actually agree here ;-)

I do want the interface to be Lua-like in using Lua tables
and things like multiple return values where appropriate.
I have also thought the documentation/example issue and I think
that at least on the lowest level it is an advantage if the usage
resembles the C++ bindings. I guess it would be possible to
layer higher lever stuff on that kind of interface.


		Eero










Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
From: "Eero Pajarre" <[hidden email]>
> I have also thought the documentation/example issue and I think
> that at least on the lowest level it is an advantage if the usage
> resembles the C++ bindings. I guess it would be possible to
> layer higher lever stuff on that kind of interface.

Ah... kind of a low-level binding from C++ to Lua and a high-level wrapper
around that written in Lua. That could very well be a good way to
'bootstrap' in the beginning, and build on that later.
One might even expose only the higher-level Lua layer to end-users, and
later do the bindings directly using that 'API'...

-Martin



Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Jay Carlson
In reply to this post by Eero Pajarre-3
FLTK is under the LGPL (with a strange exemption for static linking??!?), so
it seemed reasonable and proper to treat code like the Fltk .h files adapted
for tolua as also being under the LGPL.

How would having Lua-FLTK under the MIT license have an effect on you, given
the FLTK license?

Jay
----- Original Message -----
From: "Eero Pajarre" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, February 11, 2003 10:40 AM
Subject: Re: wxWindows vs. FLTK


> I wrote to this list related to these packages some time ago.
> At that time I ended up using wxwindows for two main reasons:
>
> The package had been updated more recently (2002 vs 2001)
> Wxwindows interface was under a license more suitable for me.
> (lua-fltk was/is under LGPL)
>
> Even though I at the moment use the wxwindows interface, I have
> reason to believe that FLTK might be better for my application.
> So I could volunteer to work with it. I would need to start
> from begining or request the current Lua-FLTK owner to release
> it under Lua/MIT license though.
>
>
>
> Eero
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: wxWindows vs. FLTK

Nick Trout-5
In reply to this post by Juergen Fuhrmann

> From: [hidden email] 
> [[hidden email]] On Behalf Of Martin Spernau
> Sent: February 11, 2003 10:21 AM
> To: Multiple recipients of list
> Subject: Re: wxWindows vs. FLTK
> 
> 
> From: "Eero Pajarre" <[hidden email]>
> > I have also thought the documentation/example issue and I think
> > that at least on the lowest level it is an advantage if the usage
> > resembles the C++ bindings. I guess it would be possible to
> > layer higher lever stuff on that kind of interface.
> 
> Ah... kind of a low-level binding from C++ to Lua and a 
> high-level wrapper
> around that written in Lua. That could very well be a good way to
> 'bootstrap' in the beginning, and build on that later.
> One might even expose only the higher-level Lua layer to 
> end-users, and
> later do the bindings directly using that 'API'...

I think this is the approach that was discussed last time this module
project was discussed.

http://lua-users.org/lists/lua-l/2002-02/msg00047.html

This is the approach I have taken in doris.sf.net. eg. I wrapped the
GLUI C++ tolua binding so I can use Luas nice table syntax. If the
library interface looked like C++, why not just use C++? eg.


-- Create our window and specify a name and window rendering function
wmain = Window:create{
   title="Doris: Light example",
   render=RenderScene
}

-- Put a sub window at the bottom of the screen
sw = SubWindow{ parent=wmain, side="bottom" }

-- Add an object rotator to the bottom of the screen that
-- manipulates the matrix we created.
Rotator{ parent=sw, text="Rotate teapot",
             value=rotatemat, line="|", spin = .9
}

-- Some spinners to manipulate the colour...
Spinner{ parent=sw, text="Red", 
     value=colour[1], type="float", limits={0,1}, 
     update=function(c) 
         colour[1]=c
         glLight(GL_LIGHT0, GL_AMBIENT, colour)
     end
}
...





Reply | Threaded
Open this post in threaded view
|

RE: wxWindows vs. FLTK

Joe Stewart
In reply to this post by Juergen Fuhrmann
Warning... preachy, editorial follows?

Is LED just not a viable option?

The reason I ask this is because my aversion to C++.

Is it possible to have an abstraction layer between Lua and the widget 
set such that it wouldn't matter whether one used WxW, FLTK, or a home-
spun GUI (somewhat like SDL, but for GUI)?

I imagine that would make things easier for OS X users (and 
curses/Amiga/BeOS/RiscOS/etc) users as well.

One of the appealing things about Lua is how easy it is to compile with 
a bare-bones ANSI C-compiler.

I'd like for us to strive to achieve the same thing for the UI library.

"Thanks for all the cool toys!"

-joe

-- 
Continuous Computing
http://www.ccpu.com

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Eero Pajarre-3
In reply to this post by Jay Carlson
Jay Carlson wrote:
FLTK is under the LGPL (with a strange exemption for static linking??!?), so
it seemed reasonable and proper to treat code like the Fltk .h files adapted
for tolua as also being under the LGPL.

How would having Lua-FLTK under the MIT license have an effect on you, given
the FLTK license?


It is the exceptions, which matter. As I have read them, they make it possible
to use FLTK in an application without the need to make everything DLL based
(on Windows) and without providing source code or object modules of the application
to the end user.

I want to avoid going into that process, so unless a very good reason comes up,
I am going to stay LGPL free in my code.


		Eero





Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
In reply to this post by Nick Trout-5
From: "Nick Trout" <[hidden email]>
> > Ah... kind of a low-level binding from C++ to Lua and a
> > high-level wrapper
> > around that written in Lua. That could very well be a good way to
> > 'bootstrap' in the beginning, and build on that later.
> > One might even expose only the higher-level Lua layer to
> > end-users, and
> > later do the bindings directly using that 'API'...
>
> I think this is the approach that was discussed last time this module
> project was discussed.
>
> http://lua-users.org/lists/lua-l/2002-02/msg00047.html
>

As I mentioned before, I'm aware that very little of what ideas are
discussed for LuaCheia are in any way new ideas.
My goal was to collect all the ideas, and maybe rediscover some that are a
little buried by time :)

Sorry if I was maybe 'thinking out loud' too much, but I have the impression
that it sometimes pays to re-state ideas that have been there before.

Nick: would you be willing to exand the Rio base for LuaCheia?

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Björn De Meyer
In reply to this post by Juergen Fuhrmann
Juergen Fuhrmann wrote:
> 
/snip
> May be  my bloat statements are a  bit drastic, so please  do not take
> them personally,  but LuaCheia already  seems to become  quite complex
> and we need to keep the ends...
> 
> Juergen

Well, I don't want to make it a flame war BUT:
* To my understanding FLTK does work on MAC (at least under X,
possibly natively) Can ny MAC developer please confirm?

* FLTK is tiny compared to WXWindows. It has much less dependencies. 
That alone makes it more suitable, even though it's less functionally 
complete than WXWindows.... 

* IIRC, someone has made Lua/FLTK bindings already,...


-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Björn De Meyer
In reply to this post by Eero Pajarre-3
Eero Pajarre wrote:
> 
> I wrote to this list related to these packages some time ago.
> At that time I ended up using wxwindows for two main reasons:
> 
> The package had been updated more recently (2002 vs 2001)
> Wxwindows interface was under a license more suitable for me.
> (lua-fltk was/is under LGPL)
> 
> Even though I at the moment use the wxwindows interface, I have
> reason to believe that FLTK might be better for my application.
> So I could volunteer to work with it. I would need to start
> from begining or request the current Lua-FLTK owner to release
> it under Lua/MIT license though.
> 
>                 Eero

The authors have already agreed to a general exception that statically 
linked versions of FLTK don't make the wjhole program fall under the
GPL.
Just take a look at the webpage. As for dynamic linking, the LGPL allows 
that already, even to proprietary programs.

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Joe Stewart
In reply to this post by Juergen Fuhrmann

> Joseph Stewart wrote:
> > 
> > Warning... preachy, editorial follows?
> > 
> > Is LED just not a viable option?
> > 
> 
> What is LED? Thanks.

Oops... sorry to be obscure.

I should have said IUP/LED which is tecgraf's "portable user 
interface". Read about it at:

http://www.tecgraf.puc-rio.br/iup

-joe

> 
> -- 
> "No one knows true heroes, for they speak not of their greatness." -- 
> Daniel Remar.
> Björn De Meyer 
> [hidden email]
> 
> 

-- 
Continuous Computing
http://www.ccpu.com

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Martin Spernau
> > What is LED? Thanks.
>
> Oops... sorry to be obscure.
>
> I should have said IUP/LED which is tecgraf's "portable user
> interface". Read about it at:
>
> http://www.tecgraf.puc-rio.br/iup

Does anybody here have real exerience using it?
I had a look some time ago and couldn't really figure it out, which might be
due to the fact that I wasn't really deep into Lua by that time.

It being c-based and having a real close connection to Lua anyway (license)
would be a nice factor.

-Martin


Reply | Threaded
Open this post in threaded view
|

RE: wxWindows vs. FLTK

Nick Trout-5
In reply to this post by Juergen Fuhrmann

> From: [hidden email] 
> [[hidden email]] On Behalf Of Martin Spernau
> Sent: February 11, 2003 1:25 PM
> To: Multiple recipients of list
> Subject: Re: wxWindows vs. FLTK
> 
> As I mentioned before, I'm aware that very little of what ideas are
> discussed for LuaCheia are in any way new ideas.
> My goal was to collect all the ideas, and maybe rediscover 
> some that are a
> little buried by time :)

I wasn't criticising, there may be a lot of useful material to you in
the lua-l archive around the pointer I gave you.

> Sorry if I was maybe 'thinking out loud' too much, but I have 
> the impression
> that it sometimes pays to re-state ideas that have been there before.

Its nice to see a buzz of excitement. Lets hope something comes of this.
(Lets hope that SF project appears soon - and a new mailing list appears
:)

> Nick: would you be willing to exand the Rio base for LuaCheia?

I can share some ideas with you and tell you what my intentions were
(rio is unfinished). I have very limited spare time and other priorities
so I cant promise to contribute a great deal. I don't want to take over
your new project and not contribute either! :) 

Nick







Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Björn De Meyer
In reply to this post by Joe Stewart
Joseph Stewart wrote:
> 
> Warning... preachy, editorial follows?
> 
> Is LED just not a viable option?
> 

What is LED? Thanks.

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

1234