wxWindows vs. FLTK

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

RE: wxWindows vs. FLTK

CRIBBSJ
> -----Original Message-----
> From: Martin Spernau [[hidden email]]
> Sent: Tuesday, February 11, 2003 5:41 PM
> To: Multiple recipients of list
> Subject: Re: wxWindows vs. FLTK
> 
> 
> > > What is LED? Thanks.
> 
> 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
>

I used it (actually, iuplua) for a couple of small applications.  IMHO, it
blends in VERY well with lua.  It didn't feel like I was using a "grafted
in" binding to a gui library.  It felt more like part of lua itself.  It has
some cool widgets like the table widget, which I used a lot for a
multi-column listbox.

The only real complaint I had about it was that it "looked" a little old.
What I mean by that is that the look of applications (at least on Windows)
looked a little old fashioned.  Of course, that might have been the result
of my inexperience with IUP (or maybe my lack of artistic talent!).  I
understand that they are working on a new version of IUP that will probably
be addressing these issues.

Mark Stroetzel Glasberg, one of the guys working on IUP, was my main point
of contact and he was extremely helpful.  In fact, being "C" illiterate, I
could never get the thing compiled on Windows, so he built me a custom
interpreter with lua, iuplua, luasocket, and luasql. 

What you guys are proposing to create would be great for lua.  One of the
reasons I stopped using lua is that I could never get an interpreter built
with all of the extensions I wanted.  I wish you guys success!

Jamey

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:
> 
> > 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

Interesting, but it doesn't have a Mac port. 
It would prrobably run under X in OS X, though.


-- 
"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
|

[LuaCheia] IUP [was: wxWindows vs. FLTK]

Martin Spernau
In reply to this post by CRIBBSJ
>From what I read from Jamey statement below, we should then try and find out
how hard it is to port IUP to other (further) platforms.
I have the strong feeling that the listed platforms (win32 and *IX) are
'just' those that where needed up to now.
-Martin
From: "CRIBBSJ" <[hidden email]>
> I used it (actually, iuplua) for a couple of small applications.  IMHO, it
> blends in VERY well with lua.  It didn't feel like I was using a "grafted
> in" binding to a gui library.  It felt more like part of lua itself.  It
has
> some cool widgets like the table widget, which I used a lot for a
> multi-column listbox.
>
> The only real complaint I had about it was that it "looked" a little old.
> What I mean by that is that the look of applications (at least on Windows)
> looked a little old fashioned.  Of course, that might have been the result
> of my inexperience with IUP (or maybe my lack of artistic talent!).  I
> understand that they are working on a new version of IUP that will
probably
> be addressing these issues.
>
> Mark Stroetzel Glasberg, one of the guys working on IUP, was my main point
> of contact and he was extremely helpful.  In fact, being "C" illiterate, I
> could never get the thing compiled on Windows, so he built me a custom
> interpreter with lua, iuplua, luasocket, and luasql.
>
> What you guys are proposing to create would be great for lua.  One of the
> reasons I stopped using lua is that I could never get an interpreter built
> with all of the extensions I wanted.  I wish you guys success!
>
> Jamey
>


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Joe Stewart

> Martin Spernau wrote:
> > 
> > >From what I read from Jamey statement below, we should then try 
and find out
> > how hard it is to port IUP to other (further) platforms.
> > I have the strong feeling that the listed platforms (win32 and *IX) 
are
> > 'just' those that where needed up to now.
> 
> Well, there ahave been some requests for LuaChei to also
> run on Mac, but are there any programmers present who can help 
> us there? It's difficult to port to a machine you don't
> have access to.

Not to be a pain in the a**, but is anyone else interested in 
curses/text-only UI as well? How about a HTML user interface... where 
the same description could render a webpage?

-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: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Björn De Meyer
In reply to this post by Martin Spernau
Martin Spernau wrote:
> 
> >From what I read from Jamey statement below, we should then try and find out
> how hard it is to port IUP to other (further) platforms.
> I have the strong feeling that the listed platforms (win32 and *IX) are
> 'just' those that where needed up to now.

Well, there ahave been some requests for LuaChei to also
run on Mac, but are there any programmers present who can help 
us there? It's difficult to port to a machine you don't
have access to.



-- 
"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: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Martin Spernau
In reply to this post by Joe Stewart
> Not to be a pain in the a**, but is anyone else interested in
> curses/text-only UI as well? How about a HTML user interface... where
> the same description could render a webpage?

Here!  Here! absolutly!
I've seen such projects for Python I think, but they were not very advanced
and seemed to lack support...

I guess the real problem is 'the least common dominator', as a graphic GUI,
a text-based
UI and a HTML UI have some very different requirements.
And that's not because one is 'dumber' than the other. But I can do things
on a webpage that are difficult or unpractical in a GUI, and if I put the
page-based model into a GUI app, I end up with stupid wizards.

I very much want as many UI options available for LuaCheia, maybe this can
be handled in a flexible way. Have a 'compat' layer that doesn't need to
know what kind of UI it serves, and do UI specific programming if rhe need
arises (Desktop-only app)

-Martin


Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Joe Stewart
In reply to this post by Juergen Fuhrmann

> > Not to be a pain in the a**, but is anyone else interested in
> > curses/text-only UI as well? How about a HTML user interface... 
where
> > the same description could render a webpage?
> 
> Here!  Here! absolutly!
> I've seen such projects for Python I think, but they were not very 
advanced
> and seemed to lack support...
> 
> I guess the real problem is 'the least common dominator', as a 
graphic GUI,
> a text-based
> UI and a HTML UI have some very different requirements.
> And that's not because one is 'dumber' than the other. But I can do 
things
> on a webpage that are difficult or unpractical in a GUI, and if I put 
the
> page-based model into a GUI app, I end up with stupid wizards.
> 
> I very much want as many UI options available for LuaCheia, maybe 
this can
> be handled in a flexible way. Have a 'compat' layer that doesn't need 
to
> know what kind of UI it serves, and do UI specific programming if rhe 
need
> arises (Desktop-only app)

I remember years ago the GEOworks people (remember them) had some 
abstract way to specify a user interface so that mapping to a different 
widget set didn't require the code (object-oriented assembly 
language... I wouldn't want to change it, either) to change. This kind 
of approach might serve us well... any thoughts.

> -Martin
> 
> 
> 

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

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Joe Stewart
In reply to this post by Juergen Fuhrmann
This seems to be a pretty comprehensive list of existing UI libraries:

http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

-j

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] IUP [was: wxWindows vs. FLTK]

Joe Stewart
In reply to this post by Juergen Fuhrmann

> This seems to be a pretty comprehensive list of existing UI libraries:
> 
> http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

Sorry to respond to myself, but scanning the above list, GraphApp 
looked appealing to me from a simplicity standpoint. The author has 
taken a lowest-common-denominator approach. I'll see it I can make a 
lua4 binding this weekend.

> -j
> 
> 

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

Reply | Threaded
Open this post in threaded view
|

Re: [LuaCheia] IUP [was: wxWindows vs. FLTK]

rhq093
In reply to this post by Björn De Meyer
 One possible consideration when choosing UI toolkit might be SVG. The vector 
graphics standard from W3C. I do believe that it is considered for use in Linux 
desktop UI systems. How hard it is to implement I don't know. But it is an ironclad 
standard. And seems to be very well received by the industry.

MvH Dan Andersson

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Will Leshner
In reply to this post by Björn De Meyer
Yes. It works very well. I just tested it both with the supplied CodeWarrior projects as well as with configure/make in Terminal.

On Tuesday, February 11, 2003, at 02:27 PM, Björn De Meyer wrote:

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?


Reply | Threaded
Open this post in threaded view
|

Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Antonio Scuri
In reply to this post by CRIBBSJ

The last time I update my interface toolkits survey I noticed that there are 3 major free toolkits among others: GTK, FLTK and WxWindows.

Almost all toolkits are in C++, but using C could be an advantage since lots of classes can be confusing. Many have Mac ports (not considering using X-Windows on MacOs X). When developing professional applications native look and feel is very important, in UNIX many commercial toolkits and several free toolkits have a Motif port as a "Native" standard for X-Windows based applications. Open Motif is an important effort to keep Motif alive.

All the 3 mentioned toolkits are active and have good references. But all of them have their weakness considering the comments above.

GTK is in C. It is primarily for X-Windows, Win32 is an external project, and no Mac port that I know. Also no native controls.

  FLTK has all the ports, but no native controls.

WxWindows is complete with native controls and much more. But they put everything together, it is a lot more than an interface toolkit. If there were several small libraries will be far the best option.

So, there is no "Best Option". Depends on the application, the development team, the development main platform, and so on.

  That´s why we decided to keep IUP alive.

IUP is in C and has a very simple API. It had a Mac port, but our Mac got old because our projects concentrate on Win32/Motif. The old MacOs also has a terrible memory management, only after MacOs X we fell motivated to start again, but no time and no Mac around... Also IUP uses native controls in Windows and Motif in UNIX.

The big problem is how we are going to maintain a very complex library with a small team that usually is involved with other projects?

The fact is that we solve the important bugs, evolve a little bit and got trapped in a source code that needs updates. Meanwhile we tried to develop a new version, but after 3 prototypes we were not satisfied and the need for compatibility for our applications that are already in IUP (about a dozen large and important apps) directed us to a new path.

We are now analyzing the old code to start an incremental update from the core. This seems to be even harder but it will help to keep the compatibility at a controlled level. One of our objectives is to allow an easy way to add new controls, including native controls. The actual API allows only the addition of owner draw controls using our drawing library CD - Canvas Draw (which also has a Lua binding).

We also have another problem, our applications use Lua 3.2. So we decided to wait for Lua 5 to make any effort in porting those applications.

  Well as I said before, there is no "Best Option".

If I don´t have IUP I really don't know what I will be using. WxWindows has to be cropped to be useful, is this crop easy to make? If I need a Mac port right now I should choose FLTK over GTK.

So for the LuaCheia project with the features pointed in other messages I would suggest FLTK. But IUP could be a good option in the future.

Maybe the "Best Option" is to develop an independent Lua GUI toolkit that could be implemented using FLTK, GTK, IUP or any other toolkit.

scuri


Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Sean Middleditch
On Tue, 2003-02-11 at 23:24, Antonio Scuri wrote:

<snip/>

>    GTK is in C. It is primarily for X-Windows, Win32 is an external 
> project, and no Mac port that I know. Also no native controls.
> 
>    FLTK has all the ports, but no native controls.
> 
>    WxWindows is complete with native controls and much more. But they put 
> everything together, it is a lot more than an interface toolkit. If there 
> were several small libraries will be far the best option.
> 
>    So, there is no "Best Option". Depends on the application, the 
> development team, the development main platform, and so on.

This "native controls" argument is completely stupid.  Even if you have
"buttons that look alike," that does nothing for feel or tie-in to a
desktop.  Good Mac apps look nothing like good Windows apps, and the
same goes for GNOME or KDE apps (why people think Motif is a good GUI is
beyond me - it's a crap user experience, and if you don't care about
user experience, what's the point of worrying about what the fricking
buttons *look* like?).

You're much better off worrying about more relevant criteria, for
example how portable (which you are), speed/size, etc.

And, simply as another point of view (unrelated to the toolkit chosen),
calling Motif native-UNIX is pretty bad.  ~,^  That toolkit should die,
and soon.  It's out-dated, doesn't work well with modern desktop
environments (HP-UX and Solaris are switching to GNOME, iirc, Linux/BSD
already use mostly KDE or GNOME, they are *real* GUI environment, and
tying into their look *and* feel would be a much brighter move for new
applications, instead of the UI nightmare of old Motif UNIX apps).

That's one point up for using WxWindows, since not only does it use an
actually modern toolkit under UNIX, it gives a choice between GTK and Qt
(or will, when Qt port is done).  Of course, cross-platform UI's always
suck anyways, since 99% of the time they always feel and act like
Windows apps, even tho that is *completely* incorrect UI-wise on a Mac,
or even GNOME.  I know for a fact in GNOME, it's painfully obvious when
even other GTK apps don't follow the HIG or closely use GNOME
technologies - they do not fit in cleanly at all.  (For example, the
GIMP, even tho the CVS version follows the HIG, the lack of use of
GNOME-VFS or GConf stands out rather clearly in many situations.)  Point
of this whole paragraph: "native widgets" is a completely pointless
criteria.  ^,^

</spiel>

>    Maybe the "Best Option" is to develop an independent Lua GUI toolkit 
> that could be implemented using FLTK, GTK, IUP or any other toolkit.

This actually might be a decent option - a very lite-weight and clean
API that builds on any number of toolkits.  The simpler the API the
better, as well, since a call like "CreateAlertDialog(...)" is a lot
more likely to produce the correct platform output (icon usage,
spacing/margins, button ordering, etc.) than an API that requires the
programmer to hand-construct even simple dialogs.  This is one of my
beefs with GTK (programmers have to do a lot of extraneous work to get
the effects that should be default, as per the GNOME HIG), but that's
another and wholly unrelated story.. ;-)

> 
> scuri
> 


Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Enrico Colombini
In reply to this post by Antonio Scuri
On Wednesday 12 February 2003 05:24, Antonio Scuri wrote:
> Maybe the "Best Option" is to develop an independent Lua GUI toolkit
> that could be implemented using FLTK, GTK, IUP or any other toolkit.

I've been thinking for a long time about a pure Lua-based GUI toolkit; it 
would have a number of advantages over a static language toolkit (e.g. 
personalize a widget's appearance or behaviour without definign a new widget 
type, do away with static callbacks, etc.).

My design would be based (as its ancient C++ DOS ancestor was) on a bare-bone, 
portable 2D graphics library written in plain C... which is very slowly 
progressing due to lack of time.
Unfortunately I'm just starting on a new line of work and I can't presently 
afford time for interesting things such as Lua (a temporary situation, I 
hope). I am not even able to promise cooperation for LuaCheia :-(

Anyway, I don't think there is currently much of a need for a specific Lua 
GUI; in Lua style, different GUI should be loadable as modules according to 
the user's taste or needs.

  Enrico


Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Martin Spernau
Enrico Colombini wrote:

Anyway, I don't think there is currently much of a need for a specific Lua GUI; in Lua style, different GUI should be loadable as modules according to the user's taste or needs.
Well, yes modularity and choice is the idea.
But still I'd very much like to see a Lua-native GUI based on dimple primitives that can be 'displayed' by any number of toolkits. That way the 'description' could be general, and the 'look&feel' would be handled by the GUI in question (native win32, MACOS, GTK, DHTML, ncurses, whatever)

But I guess it is simply to much work to do for a practical project...

-Maritn



pau
Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

pau
well, I've got a GPL project at

http://www.gime.org/twiki/bin/view/Gime/GraphicFrontend

which provides a very thin graphics layer written in C, and the
entire GUI stuff is implemented in pure Lua. It even comes with
a GUI editor to assemble widgets visually and later export them
into Lua scripts.

Unfortunately, I've got not enough time to polish it up (clean
up code mess, document it with tutorials, etc). It is still quite
a toy. But nevertheless, people interested in implementing Lua
GUI may take a look. The code base is small enough to get hands
on in an afternoon ;-)

Regards,
.paul.

On Wed, Feb 12, 2003 at 12:37:06PM +0100, Martin Spernau wrote:
> Enrico Colombini wrote:
> 
> >Anyway, I don't think there is currently much of a need for a specific Lua 
> >GUI; in Lua style, different GUI should be loadable as modules according 
> >to the user's taste or needs.
> > 
> >
> Well, yes modularity and choice is the idea.
> But still I'd very much like to see a Lua-native GUI based on dimple 
> primitives that can be 'displayed' by any number of toolkits.
> That way the 'description' could be general, and the 'look&feel' would 
> be handled by the GUI in question (native win32, MACOS, GTK, DHTML, 
> ncurses, whatever)
> 
> But I guess it is simply to much work to do for a practical project...
> 
> -Maritn
> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Martin Spernau
Hi Paul,
Well that's just the kind of thing I was looking for some time ago. I
was looking at PyGUI, which builds on PyGame, and also uses SDL as base.
I was thinking: 'Someone do that in Lua, damit!' *g*

Thanks, Martin
P.S. could you maybe supply some screenshots or such?

[hidden email] wrote:
> well, I've got a GPL project at
> 
> http://www.gime.org/twiki/bin/view/Gime/GraphicFrontend
> 
> which provides a very thin graphics layer written in C, and the
> entire GUI stuff is implemented in pure Lua. It even comes with
> a GUI editor to assemble widgets visually and later export them
> into Lua scripts.
> 
> Unfortunately, I've got not enough time to polish it up (clean
> up code mess, document it with tutorials, etc). It is still quite
> a toy. But nevertheless, people interested in implementing Lua
> GUI may take a look. The code base is small enough to get hands
> on in an afternoon ;-)
> 
> Regards,
> .paul.


Reply | Threaded
Open this post in threaded view
|

Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

Andre Costa-2
In reply to this post by Sean Middleditch
Hi Sean,

On Tue, 11 Feb 2003 23:55:28 -0500
Sean Middleditch <[hidden email]> wrote:

> This "native controls" argument is completely stupid.  Even if you
> have"buttons that look alike," that does nothing for feel or tie-in to
> a desktop.  Good Mac apps look nothing like good Windows apps, and the
> same goes for GNOME or KDE apps (why people think Motif is a good GUI
> is beyond me - it's a crap user experience, and if you don't care
> about user experience, what's the point of worrying about what the
> fricking buttons *look* like?).

I believe you got Scuri's arguments wrong. Definitely, Mac apps look
different from Windows apps, and, if we're talking about different apps
then there's hardly basis for comparison.

However, if we're talking about a same app ported to both systems (i.e.
GUI design is essentially the same for both versions), differences are
mainly (if not exclusively) due to widgets' look & feel -- after all,
the developer wouldn't want user experience to differ radically on each
environment.

So, at the end of the day, using native controls increases significantly
the feeling it is a "native app", making the fact that there is an
intermediate layer (like a cross-platform GUI toolkit) completely
transparent to the user. I guess this is why Scuri thought relevant to
consider the characteristic of supporting native widgets. Portability
and complexity of a GUI toolkit definitely vary if it uses native
widgets or not, and so varies the user experience.

Just for the record: I am not saying we should or shouldn't go for
native widgets look & feel when chosing a GUI toolkit for these new Lua
projects; as you properly say below, other (probably more relevant)
issues have to be considered as well. I just wanted to add my $0.02 to
your argument above.

Best,

Andre

-- 
Andre Oliveira da Costa

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Juergen Fuhrmann
In reply to this post by Björn De Meyer
>  Tue, 11 Feb 2003 23:27:28 +0100
>  Björn De Meyer <[hidden email]> wrote:
>
>  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,...
>  

Exactly my  opinion. IMHO, we  should go with  fltk. IUP also  has the
drawback that it needs Motif/Lesstif.

Several postings mentioned tha LuaCheia should be able to install "out
of the  box" on a typical Windows/Mac/***x  machine without installing
any additional  package. I very much would  like to see this  as a the
top priority paradigm of the whole thing.

On UNIX,  the native API for  graphics emerged to be  X, but basically
there  is no  "native" GUI  which one  can canonically  rely  on.  So,
fltk/luafltk packaged  with LuaCheia could do the  job.  Concerning an
own-rolled GUI, I  am sceptical, this would need  some time to evolve,
and  we  would get  a  discussion  on what  to  put  in  and what  not
(e.g. OpenGL support would be a "must" for me...).


Juergen

Reply | Threaded
Open this post in threaded view
|

Re: wxWindows vs. FLTK

Jay Carlson
In reply to this post by Björn De Meyer
> 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.

I'm willing to license under the same terms as FLTK; in fact, that was my
original intent: license compatibility.

What puzzles me is---why the hell are they using the LGPL anyway?  With this
exception, the total licensing terms look like the MIT license, except with
a giant heaping helping of FUD to wade through.

Jay


1234