|
|
1234
|
|
> -----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
|
|
|
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]
|
|
|
>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
>
|
|
|
> 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
|
|
|
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]
|
|
|
> 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
|
|
|
> > 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
|
|
|
> 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
|
|
|
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
|
|
|
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?
|
|
|
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
|
|
|
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
>
|
|
|
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
|
|
|
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
|
|
|
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
>
>
|
|
|
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.
|
|
|
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
|
|
|
> 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
|
|
|
> 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
|
Locked
