Amazing GUI toolkit with visual designer & Ruby Integration

Checkout these video tutorials (in shockwave):

  http://seriss.com/people/erco/fltk-videos/

After viewing them (especially the FLUID intro), I tried converting my Fox-Toolkit apps and found myself feeling really stupid for not choosing FLTK in the first place.

What's worse, I had "reviewed" FLTK in the past simply by looking at their website and passed it up as not having enough widgets and the ones they had were ugly. Boy was I wrong... Playing with FLTK+FLUID for a few minutes made me see that I can make dialogs look like Windows or Mac flavors simply by changing properties of widgets (ie. buttons have a wide variety of 2d/3d looks).

The ruby-fltk project appears to require mingw--which is unfortunate since Microsoft released Visual C++ Toolkit 2003 for free download and it has the same optimizing compiler as Visual C++ Professional 2003.

What would TRULY be exciting is a ruby-fluid project which converts fluid .fl files into .rb in the same way fluid converts .fl into .cxx.

My reason for switching from Fox-Toolkit to FLTK was inspired by licensing issues (related to static linking in commercial apps) but now I'm kicking myself for purely technical/productivity issues for not choosing FLTK. And a bit dissappointed that FLTK isn't as popular as Fox in Ruby (perhaps due to the same misperceptions I initially had due to the crappy FLTK website screenshots).

Can some of you ruby experts take a quick glance at fluid .fl files and estimate how much effort it would take to convert them to .rb? After all, they were designed to convert to .cxx and .h so it shouldn't be hard in theory.

Links:

http://www.fltk.org/ home (I got 1.1.5rc2)
http://seriss.com/people/erco/fltk-videos/ video tutorials
http://www.osc.edu/~jbryan/FLU/ utility widgets
http://sptk.tts-sf.com/index.php db-ware, themed widgets

In article <aX9Qc.349$Ha1.85@newssvr17.news.prodigy.com>,

Checkout these video tutorials (in shockwave):

Erco's FLTK Video Tutorials

After viewing them (especially the FLUID intro), I tried converting my
Fox-Toolkit apps and found myself feeling really stupid for not choosing
FLTK in the first place.

What's worse, I had "reviewed" FLTK in the past simply by looking at
their website and passed it up as not having enough widgets and the ones
they had were ugly. Boy was I wrong... Playing with FLTK+FLUID for a
few minutes made me see that I can make dialogs look like Windows or Mac
flavors simply by changing properties of widgets (ie. buttons have a
wide variety of 2d/3d looks).

The ruby-fltk project appears to require mingw--which is unfortunate
since Microsoft released Visual C++ Toolkit 2003 for free download and
it has the same optimizing compiler as Visual C++ Professional 2003.

What would TRULY be exciting is a ruby-fluid project which converts
fluid .fl files into .rb in the same way fluid converts .fl into .cxx.

My reason for switching from Fox-Toolkit to FLTK was inspired by
licensing issues (related to static linking in commercial apps) but now
I'm kicking myself for purely technical/productivity issues for not
choosing FLTK. And a bit dissappointed that FLTK isn't as popular as
Fox in Ruby (perhaps due to the same misperceptions I initially had due
to the crappy FLTK website screenshots).

Can some of you ruby experts take a quick glance at fluid .fl files and
estimate how much effort it would take to convert them to .rb? After
all, they were designed to convert to .cxx and .h so it shouldn't be
hard in theory.

I used Ruby/FLTK a bit on a contract job I had earlier this year. I can
tell you that there were people inside of the company I was working for that
had already done what you're asking - they made Fluid spit out Ruby code.
It worked quite nicely. Unfortunately, for various reasons they haven't
been willing to release their code. No legal issues as far as I could
tell, mostly they were worried that it didn't have enough unit tests and
they didnt' have time to write them (also they're worried about support
issues). I wish they would release their FLTK bindings (which were very
Rubyish due to extensive usage of blocks) and modified Fluid as it would
save someone a lot of work.

The other nice thing about FLTK is how small it is.

Phil

···

H. Simpson <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

H. Simpson wrote:

  And a bit dissappointed that FLTK isn't as popular as Fox in Ruby (perhaps due to the same misperceptions I initially had due to the crappy FLTK website screenshots).

Maybe it's because the latest version of FXRuby is dated July 2004 (which included a Windows binary), while the version of Ruby-FLTK that I found on Sourceforge was dated November 2002 (which did not include a Windows binary).

Maybe I'm too cranky too be writing this today (lack of sleep), but I really don't get some of the bias against Fox/FXRuby that I hear from time to time.

FXRuby is a great gui library that is constantly being improved, well maintained, extremely stable, well documented, easy to use, well performing, and looks great (at least on Windows which is where I use it). And, using exerb (and EZexerb), you can VERY easily create a stand-alone windows binary of your app that is less than 2mb in size.

I know that there are things that Ruby/GTK, WxRuby, and Ruby-FLTK offer that FXRuby doesn't have, but, for the reasons I mentioned above, FXRuby is a pretty compelling choice for gui app development.

I am putting the finishing touches on a good-sized FXRuby/Oracle database app that I am developing for work. Even though I am using an alpha version of FXRuby 1.2, it has been rock-solid and, to me, it looks great.

I am deeply grateful to Lyle and Jeroen for all of the work they have done. It allows me to program in a great language, using a great gui toolkit, all for free.

Ok, I will the end the rant here. Just wanted to put a plug in for FXRuby, "The Other Ruby Gui Toolkit" (idea blatantly ripped off from a series of US ads for that other white meat).

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.

Hi,

H. Simpson wrote:

> And a bit dissappointed that FLTK isn't as
popular as Fox in Ruby
> (perhaps due to the same misperceptions I
initially had due to the
> crappy FLTK website screenshots).

Maybe it's because the latest version of FXRuby is
dated July 2004
(which included a Windows binary), while the version
of Ruby-FLTK that I
found on Sourceforge was dated November 2002 (which
did not include a
Windows binary).

And, maybe ('cause I don't know... just guessing), the
excitement for FLTK is due to a GUI designer. Ah, GUI
designers... :slight_smile:

There is one thing that complicates too much the
creation of GUI designers that is the use of layout
managers. I don't think that Glade is the ultimate GTK
GUI designer, but it is the only one we have, guess
why?

I want to believe that a good GUI library coupled with
a great language is enough to make a GUI designer less
needed, though the successful examples from history
(Delphi, VB, Access) have always had GUI designers.
What's gonna be next? The same old stuff in new
clothes?

Anyway, this isn't directed at anyone. Sorry for the
noise.

Cheers,
Joao

···

--- Jamey Cribbs <cribbsj@oakwood.org> wrote:

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

While I'm grateful for Fox-Toolkit and FXRuby too, I cannot use it due to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK due initially to licensing reasons on a commercial project.

I don't mind giving away changes I make to Fox-Toolkit but being required to give away the commercial application source that statically links to a modified Fox-Toolkit is something that bars me from using it. I'm not saying the license is stupid or wrong--I just cannot use it under those terms on my non-hobby projects.

I found issues/limitations that require me to modify Fox-Toolkit (not just subclasses) on Windows platforms. With FLTK, I found that I don't need to make changes to FLTK itself. And even if I did later on, I don't have to give away commercial applications that statically link to the modified FLTK--I only need to give back the changes I make to FLTK (if any) which is nice.

On my non-commercial project, the reasons for switching have nothing to do with licensing. I simply find myself MUCH more productive, having fun doing GUI work with FLTK--something that ruby does for me compared to other languages. Just like ruby, there are people who will have more fun and be more productive with other tools so I can't say whether anyone else should switch.

Most of us passionate about Ruby don't go around bashing other languages (yes some do). But those of use who sing Ruby's praises certainly don't want to be misunderstood as claiming "everything else sucks". The same holds true here: I'm simply singing the praises of a wonderful GUI toolkit+designer I recently started using after passing it up initially due to misperceptions. I'm not bashing the alternatives or my previous choice.

Joao Pedrosa wrote:

And, maybe ('cause I don't know... just guessing), the
excitement for FLTK is due to a GUI designer. Ah, GUI
designers... :slight_smile:

I want to believe that a good GUI library coupled with
a great language is enough to make a GUI designer less
needed, though the successful examples from history
(Delphi, VB, Access) have always had GUI designers.
What's gonna be next? The same old stuff in new
clothes?

Point taken. However (and I know that this has been debated on this list before), I personally prefer to hand-code my app's gui rather than use a gui designer.

To me, when evaluating gui library's, several things take precedence over a gui designer, including:

* Does it have the widget's I need (since I do a lot of database development, a good multi-column listbox is very important)?

* Does it run on both Windows and Linux (and does it have a Windows binary readily available, since I am a C novice)?

* Does it look good?

* Is it stable?

* Is there enough documentation for me to figure out how to use it?

* Is it being maintained?

* Can I easily distribute apps I develop in it?

Anyway, I really didn't mean my comments to start a Ruby gui toolkit debate. I was just trying to answer H. Simpson's question, "Why is FXRuby a more popular Ruby gui toolkit than Ruby-FLTK?".

The good news about this whole thing is that, when it comes to developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK, Ruby/Gtk, or wxRuby. That, to me, is the best news of all.

Now, I think we should all join hands and sing Kumbaya. :slight_smile:

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.

Would you mind me asking what changes had to be made that required
modification of the library?

It seems that that is the greatest thing stopping you from using FOX -
a clause in the license about a modified library.

(As a side note - you do know that FOX has an addendum to the LGPL...
you'd still get caught with the 'modified copy of the library' clause,
but that's why I'm asking how vital it really is to modify the
library)

The reason I ask is because I myself am unsure of the 'details' of the
modified LGPL that FOX is released under, and would be worried if I
ever wanted to modify the FOX library to sell a product.

I've asked Jeroen and Lyle before, and they've said that all they
would require of me was to credit the creators (them) and reference
their products (URL) in my applications (which I do) - and I could
build applications using FOX and FXRuby to be sold without legal
concerns.

I believe Jeroen and Lyle both have the rights to their respective
pieces of software, and could then give you special permission to
violate the license... couldn't they? (Not that they would, but they
could...)

From a freely admitted slightly ignorant LGPList,
-Rich

···

On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

While I'm grateful for Fox-Toolkit and FXRuby too, I cannot use it due
to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK due initially to
licensing reasons on a commercial project.

I don't mind giving away changes I make to Fox-Toolkit but being
required to give away the commercial application source that statically
links to a modified Fox-Toolkit is something that bars me from using it.
   I'm not saying the license is stupid or wrong--I just cannot use it
under those terms on my non-hobby projects.

I found issues/limitations that require me to modify Fox-Toolkit (not
just subclasses) on Windows platforms. With FLTK, I found that I don't
need to make changes to FLTK itself. And even if I did later on, I
don't have to give away commercial applications that statically link to
the modified FLTK--I only need to give back the changes I make to FLTK
(if any) which is nice.

On my non-commercial project, the reasons for switching have nothing to
do with licensing. I simply find myself MUCH more productive, having
fun doing GUI work with FLTK--something that ruby does for me compared
to other languages. Just like ruby, there are people who will have more
fun and be more productive with other tools so I can't say whether
anyone else should switch.

Most of us passionate about Ruby don't go around bashing other languages
(yes some do). But those of use who sing Ruby's praises certainly don't
want to be misunderstood as claiming "everything else sucks". The same
holds true here: I'm simply singing the praises of a wonderful GUI
toolkit+designer I recently started using after passing it up initially
due to misperceptions. I'm not bashing the alternatives or my previous
choice.

Finally someone else that cares about license issues.
I have used FLTK in the past, right now I use
WideStudio(just because its completely free). And has
a gui designer. Have you used FLTK in the past, and
have they added in anything interesting since then?
Good luck with using FLTK, it is a neat toolkit.
--David Ross
--- "H. Simpson"
<nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com>
wrote:

···

While I'm grateful for Fox-Toolkit and FXRuby too, I
cannot use it due
to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK
due initially to
licensing reasons on a commercial project.

I don't mind giving away changes I make to
Fox-Toolkit but being
required to give away the commercial application
source that statically
links to a modified Fox-Toolkit is something that
bars me from using it.
   I'm not saying the license is stupid or wrong--I
just cannot use it
under those terms on my non-hobby projects.

I found issues/limitations that require me to modify
Fox-Toolkit (not
just subclasses) on Windows platforms. With FLTK, I
found that I don't
need to make changes to FLTK itself. And even if I
did later on, I
don't have to give away commercial applications that
statically link to
the modified FLTK--I only need to give back the
changes I make to FLTK
(if any) which is nice.

On my non-commercial project, the reasons for
switching have nothing to
do with licensing. I simply find myself MUCH more
productive, having
fun doing GUI work with FLTK--something that ruby
does for me compared
to other languages. Just like ruby, there are
people who will have more
fun and be more productive with other tools so I
can't say whether
anyone else should switch.

Most of us passionate about Ruby don't go around
bashing other languages
(yes some do). But those of use who sing Ruby's
praises certainly don't
want to be misunderstood as claiming "everything
else sucks". The same
holds true here: I'm simply singing the praises of
a wonderful GUI
toolkit+designer I recently started using after
passing it up initially
due to misperceptions. I'm not bashing the
alternatives or my previous
choice.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

FOX's license absolutely does *not* require you don't have to give
away the source code to your commercial application(s) that link to it
(statically or otherwise). I know for a fact that this was not
Jeroen's intent. To help clear things up, could you point me to the
part(s) of FOX's license that led you to believe this was the case?

···

On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

While I'm grateful for Fox-Toolkit and FXRuby too, I cannot use it due
to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK due initially to
licensing reasons on a commercial project.

I don't mind giving away changes I make to Fox-Toolkit but being
required to give away the commercial application source that statically
links to a modified Fox-Toolkit is something that bars me from using it.

Hello Jamey,

The good news about this whole thing is that, when it comes to
developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK,
Ruby/Gtk, or wxRuby. That, to me, is the best news of all.

Okay i give you my impression (based on an older 1.1.X version)

Ruby-FLTK is good and easy to use for In-House applications.
This is where people want something that is working and they want it
as fast as possible. Most of them are (very) small applications - i
mean logic not the dataset.

If you want to deliver to clients FLTK is often no good option and it
is absolutely not good for mass market applications:

- No Tab movement and bad accelerator key handling.
  Making apps hard to use for Joe Average Poweruser.

- Ugly.
  Yes it always had 16 different 3D looks, many colors. Nothing in the
  video was new stuff for those who looked at the toolkit 5 years ago.
  (i did it in 1999 and in 2002).
  But adding more colors does not make applications more standard or
  more beautiful (for those who don't need to conform to standards)

- Very Basic Widgets
  For example the text widget. There is a good multicolumn widget for
  DB Apps in FTLK. But thats all. This is one of the reason's why it
  is so small.

- Very basic support for Fonts and Images.
  You can only use 16(?) predefined fonts. Images are always keept in
  RGB format in memory and BitBlit'ed to the drawing surface. Thats
  all.

- No support for Drag and Drop.

- No I18N, no L10N
  (the 2.0 CVS version has UTF-8)

- Very small development
  So it's easy to run into bugs when you do non usual things and
  improvements are very very slow. How long is 2.0 in the CVS, what
  happened to the 1.1.X base in since 1999. Grab the source codes of
  2 released versions and look at the diffs to see what i mean.

- Very unpowerfull callback system.
  Only one callback per widget for all events.

- Impossible to customize.
  Since the callback system is so weak it makes no sense to try to
  customize the existing widgets to your needs. You must rewrite them.

- No layout manager.
  Thats the reason for fluid. Yes, its hard to get a good compromise
  between using layout managers and GUI builders.

As a said i think there are application areas where FLTK is not a bad
choise but because of this different domain range it is not in competition
to Toolkits like GTK, QT, FOX or WxWidgets which are General Purpose
Toolkits.

By the way, i don't know why the CinePack people decided to use FLTK.
Moving away from GTK seems to be a bad move for me.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Hello Richard,

The reason I ask is because I myself am unsure of the 'details' of the
modified LGPL that FOX is released under, and would be worried if I
ever wanted to modify the FOX library to sell a product.

I've asked Jeroen and Lyle before, and they've said that all they
would require of me was to credit the creators (them) and reference
their products (URL) in my applications (which I do) - and I could
build applications using FOX and FXRuby to be sold without legal
concerns.

If you modify the fox source everything you should need to do is do a
"diff -r fox-1.3.7 myfox-1.3.7 > patch.diff" und put the patch.diff
on your website. Neither the LGPL or the GPL makes it necessary to
give away a complete and working build system etc.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Richard Lyman wrote:

Would you mind me asking what changes had to be made that required
modification of the library?

It seems that that is the greatest thing stopping you from using FOX -
a clause in the license about a modified library.

(As a side note - you do know that FOX has an addendum to the LGPL...
you'd still get caught with the 'modified copy of the library' clause,
but that's why I'm asking how vital it really is to modify the
library)

The reason I ask is because I myself am unsure of the 'details' of the
modified LGPL that FOX is released under, and would be worried if I
ever wanted to modify the FOX library to sell a product.

I've asked Jeroen and Lyle before, and they've said that all they
would require of me was to credit the creators (them) and reference
their products (URL) in my applications (which I do) - and I could
build applications using FOX and FXRuby to be sold without legal
concerns.

I believe Jeroen and Lyle both have the rights to their respective
pieces of software, and could then give you special permission to
violate the license... couldn't they? (Not that they would, but they
could...)

From a freely admitted slightly ignorant LGPList,
-Rich

While I'm grateful for Fox-Toolkit and FXRuby too, I cannot use it due
to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK due initially to
licensing reasons on a commercial project.

I don't mind giving away changes I make to Fox-Toolkit but being
required to give away the commercial application source that statically
links to a modified Fox-Toolkit is something that bars me from using it.
  I'm not saying the license is stupid or wrong--I just cannot use it
under those terms on my non-hobby projects.

I found issues/limitations that require me to modify Fox-Toolkit (not
just subclasses) on Windows platforms. With FLTK, I found that I don't
need to make changes to FLTK itself. And even if I did later on, I
don't have to give away commercial applications that statically link to
the modified FLTK--I only need to give back the changes I make to FLTK
(if any) which is nice.

On my non-commercial project, the reasons for switching have nothing to
do with licensing. I simply find myself MUCH more productive, having
fun doing GUI work with FLTK--something that ruby does for me compared
to other languages. Just like ruby, there are people who will have more
fun and be more productive with other tools so I can't say whether
anyone else should switch.

Most of us passionate about Ruby don't go around bashing other languages
(yes some do). But those of use who sing Ruby's praises certainly don't
want to be misunderstood as claiming "everything else sucks". The same
holds true here: I'm simply singing the praises of a wonderful GUI
toolkit+designer I recently started using after passing it up initially
due to misperceptions. I'm not bashing the alternatives or my previous
choice.

I'm not a lawyer so this post is just an opinion from an unqualified stranger.

GPL and LGPL is very dangerous to closed-source commercial projects unless you fully understand the license and know exactly what you are doing.

Regarding Fox-Toolkit, look at the bottom of their license page and read the explanation the Fox-Toolkit LGPL Addendum:

   Download

   "Static linking with a modified copy of the Library, however, would deny the community the benefit of these modifications, as these modifications would now be locked up inside a closed binary executable, so therefore we must insist on the original GNU Lesser General Public License when the Library has been modified."

*TRANSLATION:* if you modify Fox-Toolkit and statically link it to your multi-million dollar commercial application, then you must release not only the changes to Fox-Toolkit but your commercial application too in order to comply with the terms of the license!

Now for comparison, look at the FLTK exceptions to their LGPL license:

   FLTK License Agreement - Fast Light Toolkit (FLTK)

If anyone tells you that GPL and LGPL

···

On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson > <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

Lyle Johnson wrote:

While I'm grateful for Fox-Toolkit and FXRuby too, I cannot use it due
to licensing issues.

To clarify, I'm switching from Fox-Toolkit to FLTK due initially to
licensing reasons on a commercial project.

I don't mind giving away changes I make to Fox-Toolkit but being
required to give away the commercial application source that statically
links to a modified Fox-Toolkit is something that bars me from using it.

FOX's license absolutely does *not* require you don't have to give
away the source code to your commercial application(s) that link to it
(statically or otherwise). I know for a fact that this was not
Jeroen's intent. To help clear things up, could you point me to the
part(s) of FOX's license that led you to believe this was the case?

Lyle, thanks for clarifying.

From SECTION 6 of LGPL which applies to any application that is statically linked to a modified version of the Fox-Toolkit:

"[...] and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."

The terms of the LGPL does not allow software that are derivatives of LGPL libraries to prohibit reverse engineering.

Selling software usually means licensing it. And the terms of the license almost always explicitely prohibit reverse engineering. There have been landmark court cases where that particular clause about reverse engineering was very crucial in the outcome of disputes between companies.

To me, if I cannot lawfully prohibit customers from reverse-engineering my product in my license agreement or terms of sale, it is practically the same as giving them my source code. I don't mind giving away the source code on my hobby projects but I cannot do so on commercial products that I depend on to pay my family's rent and food. With programming jobs being shipped overseas and so-called "free trade" agreements designed to provide *access to cheaper labor* (rather than "opening overseas markets to USA" as advertised to the misinformed public), we simply don't have the luxury to share as much as we'd like under different circumstances.

Further, there is no way I wish to be bound by the remaining portions of LGPL Section 6(a, b, c, d, or e) when there is an alternative product that not only frees me from ANY such obligations on my app, but makes me more productive, have more fun coding AND produces a smaller executable to boot.

···

On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson > <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

Lothar Scholz wrote:

Hello Jamey,

> The good news about this whole thing is that, when it comes to > developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK,
> Ruby/Gtk, or wxRuby. That, to me, is the best news of all.

Okay i give you my impression (based on an older 1.1.X version)

Ruby-FLTK is good and easy to use for In-House applications.
This is where people want something that is working and they want it
as fast as possible. Most of them are (very) small applications - i
mean logic not the dataset.

If you want to deliver to clients FLTK is often no good option and it
is absolutely not good for mass market applications:

- No Tab movement and bad accelerator key handling.
  Making apps hard to use for Joe Average Poweruser.

- Ugly.
  Yes it always had 16 different 3D looks, many colors. Nothing in the
  video was new stuff for those who looked at the toolkit 5 years ago.
  (i did it in 1999 and in 2002).
  But adding more colors does not make applications more standard or
  more beautiful (for those who don't need to conform to standards)

- Very Basic Widgets
  For example the text widget. There is a good multicolumn widget for
  DB Apps in FTLK. But thats all. This is one of the reason's why it
  is so small.

- Very basic support for Fonts and Images.
  You can only use 16(?) predefined fonts. Images are always keept in
  RGB format in memory and BitBlit'ed to the drawing surface. Thats
  all.

- No support for Drag and Drop.

- No I18N, no L10N
  (the 2.0 CVS version has UTF-8)

- Very small development
  So it's easy to run into bugs when you do non usual things and
  improvements are very very slow. How long is 2.0 in the CVS, what
  happened to the 1.1.X base in since 1999. Grab the source codes of
  2 released versions and look at the diffs to see what i mean.

- Very unpowerfull callback system.
  Only one callback per widget for all events.

- Impossible to customize.
  Since the callback system is so weak it makes no sense to try to
  customize the existing widgets to your needs. You must rewrite them.

- No layout manager.
  Thats the reason for fluid. Yes, its hard to get a good compromise
  between using layout managers and GUI builders.

As a said i think there are application areas where FLTK is not a bad
choise but because of this different domain range it is not in competition
to Toolkits like GTK, QT, FOX or WxWidgets which are General Purpose
Toolkits.

By the way, i don't know why the CinePack people decided to use FLTK.
Moving away from GTK seems to be a bad move for me.

Lothar,

Those are the exact misperceptions that led me to initially avoid FLTK. Some of it is simply pure FUD or no longer applicable and some of it is due to really awful screenshots of GUI done by people with no taste.

List of 3rd-Pary opensource widgets based on FLTK is at:
   Links: By Category - Links - Fast Light Toolkit (FLTK)

For people that want extras not included in FLTK 1.1, they can use one of these fine FLTK-based projects which are very active:

   FLU - FLTK Utility Widgets (v2.13 released few days ago)
   http://www.osc.edu/~jbryan/FLU/

   SPTK - Simply Powerful Toolkit (v2.2 released yesterday)
   Database-aware and themed widgets with *logical layout control*
   http://sptk.tts-sf.com/index.php

For an example of an entire GUI framework based on FLTK 1.1 see:
   National Center for Biotechnology Info (NCBI)
   FLTK-based GUI framework (released for all to use)
   http://www.ncbi.nlm.nih.gov/books/bv.fcgi?rid=toolkit.chapter.ch_gui

To combat the pure FUD of FLTK not being active see these facts (and note the release dates of the latest FLU and FLTK):

   FLTK 1.1.5rc2 (released July 27), with 1.1.5 expected on August 10 unless new critical bugs are discovered and confirmed.

   FLTK 1.2 is currently active in CVS, release date is not announced yet but expected to be within a few months.

   FLTK 2.0 is to FLTK 1.x what Ruby 2.0 is to Ruby 1.x. It is a big departure that won't be compatible. FLTK 2.0 is claimed to be usable right now but shouldn't be used in production because the API isn't frozen yet.

Logical layout manager - available in SPTK.

Different callback mechanisms - available in several projects if you don't like the one included with FLTK.

I18N - there's an I18N dialog box in FLUID but I haven't played with it--I'm guessing its there for a reason. But I did come across a screenshot of FLKT here with something like an elvish font here:
   http://yaroslav-v.chat.ru/russian.html

Accelerator keys - I'll find out today. If this isn't in FLTK 1.1.5, then its probably provided by one of the above FLTK projects. If not, I'll look into using the keyup even on the window and share the code.

Callbacks - I like the simplicity/flexibility of the default callback mechanism but there are several alternative extensions to FLTK. If you don't like the default callback mechanism in FLTK 1.1, then you'll be able to find several different projects that do it differently--including one designed for massively parallel applications.

Ugly - only if you rely on screenshots done by people with no taste. This was what led me to avoid FLTK in the first place. I tried it out and changed my mind about this when I was able to create very polished-looking dialogs like I did with Delphi. Only minor issues:
   - default greyish backgrounds (solved by typing in my preferred RGB value I grabbed from my Windows 2000 desktop properties).
   - Fl_Chooser looks bad when clicked (solved by using flu_combobox from FLTK Utility Widgets 2.13 - aka FLU 2.13)
   - Fl_Group doesn't look good so I use FLU_Simple_Group from FLU 2.13

DND - I saw examples of drag-n-drop. Perhaps it was provided by FLU or SPTK but its available.

I'm sure some will argue that they won't use the extended FLTK widgets or logical layout managers or alternative callback mechanisms unless they are included in the FLTK project itself. They're probably the same folks who use perl without taking advantage of anything in CPAN, or use Ruby without grabbing anything extra from RubyForge.

Also, you can believe the FUD put out about FLTK not being actively developed, or you can simply look at the FLTK CVS commit activity here (as well as noting the August 2004 release dates of FLU and SPTK, the two most popular widget sets for FLTK):
   news://news.easysw.com/fltk.cvs

Lothar Scholz wrote:

Hello Richard,

> The reason I ask is because I myself am unsure of the 'details' of the
> modified LGPL that FOX is released under, and would be worried if I
> ever wanted to modify the FOX library to sell a product.

> I've asked Jeroen and Lyle before, and they've said that all they
> would require of me was to credit the creators (them) and reference
> their products (URL) in my applications (which I do) - and I could
> build applications using FOX and FXRuby to be sold without legal
> concerns.

If you modify the fox source everything you should need to do is do a
"diff -r fox-1.3.7 myfox-1.3.7 > patch.diff" und put the patch.diff
on your website. Neither the LGPL or the GPL makes it necessary to
give away a complete and working build system etc.

Lothar, when you look up at the sky, what color is it? Surely you live in a different universe than I...

So you want to add an ABOUT box or splash screen to your massive closed-source application you spent your entire life-savings building?

1. Download Fox-Toolkit.
2. Make a few changes to it Fox-Toolkit to make it work the way you want.
3. Statically link it to your multi-million dollar application.
4. Try to sell your app to investors.
5. Watch investors tell you to go fuck yourself during due-diligence when they see that you statically linked to an LGPL or GPL project.
6. Congratulations, you can point to the wonderful advice given by Lothar on the internet and watch the investors laugh at you.

I'm sorry to be harsh but you can seriously screw people up financially with really bad advice. Especially if they trust your advice and don't follow up with qualified attorney about legal matters...

You seem very smart about other things so maybe someone gave you bad advice about LGPL and GPL--perhaps you should read them and find out the truth.

I'm not a lawyer so this post is just an opinion from an unqualified
stranger.

GPL and LGPL is very dangerous to closed-source commercial projects
unless you fully understand the license and know exactly what you are
doing.

Regarding Fox-Toolkit, look at the bottom of their license page and read
the explanation the Fox-Toolkit LGPL Addendum:

   Download

   "Static linking with a modified copy of the Library, however, would
deny the community the benefit of these modifications, as these
modifications would now be locked up inside a closed binary executable,
so therefore we must insist on the original GNU Lesser General Public
License when the Library has been modified."

*TRANSLATION:* if you modify Fox-Toolkit and statically link it to your
multi-million dollar commercial application, then you must release not
only the changes to Fox-Toolkit but your commercial application too in
order to comply with the terms of the license!

Now for comparison, look at the FLTK exceptions to their LGPL license:

   FLTK License Agreement - Fast Light Toolkit (FLTK)

If anyone tells you that GPL and LGPL

(correct me if I'm wrong)

So whats the difference? You still have to follow the LGPL:

(FLTK license)
If you link the application or widget to a modified version of FLTK, then the
changes to FLTK must be provided under the terms of the LGPL in sections 1,
2, and 4.

Which means:

if you modify FLTK and statically link it to your
multi-million dollar commercial application, then you must release not
only the changes to Fox-Toolkit but your commercial application too in
order to comply with the terms of the license!

  Sander

···

--
"Nervous hands grip tight the knife
In the darkness, till the cake is cut"
  - Peter Gabriel

Regarding Fox-Toolkit, look at the bottom of their license page and read
the explanation the Fox-Toolkit LGPL Addendum:

   Download

"Static linking with a modified copy of the Library, however, would
deny the community the benefit of these modifications, as these
modifications would now be locked up inside a closed binary executable,
so therefore we must insist on the original GNU Lesser General Public
License when the Library has been modified."

Yes. If you're statically linking your application, which is a "work
based on the library", FOX's license reverts to the terms of the
original LGPL.

*TRANSLATION:* if you modify Fox-Toolkit and statically link it to your
multi-million dollar commercial application, then you must release not
only the changes to Fox-Toolkit but your commercial application too in
order to comply with the terms of the license!

No. See point 6, especially point 6(a), of the LGPL. You must provide
your user with the ability to re-link, but you can provide your "work
that uses the library" as object code and not source code.

···

On Fri, 6 Aug 2004 04:41:28 +0900, H. Simpson <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

The terms of the LGPL does not allow software that
are derivatives of
LGPL libraries to prohibit reverse engineering.

One of the main reasons I don't use GPL/LGPL toolkits
anymore. I like my anti-debugging/disassembler code in
my applications. People are 1) blind and dont think
about this or 2) don't care for software piracy. One
of the better ways in getting piracy reports is making
"ET phone home" to servers :slight_smile:

To me, if I cannot lawfully prohibit customers from
reverse-engineering
my product in my license agreement or terms of sale,
it is practically
the same as giving them my source code. I don't
mind giving away the
source code on my hobby projects but I cannot do so
on commercial
products that I depend on to pay my family's rent
and food. With
programming jobs being shipped overseas and
so-called "free trade"
agreements designed to provide *access to cheaper
labor* (rather than
"opening overseas markets to USA" as advertised to
the misinformed
public), we simply don't have the luxury to share as
much as we'd like
under different circumstances.

Its like the LGPL welcomes program cracking. It is
very easy to do if you know assembly. A bit difficult
if there is a generator for a registration box though.
This point is very good. Software piracy is a big
issue. So.. /me *hugs* BSD/MIT/PD licensed libraries.

--David Ross

···

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Lyle, thanks for clarifying.

From SECTION 6 of LGPL which applies to any application that is
statically linked to a modified version of the Fox-Toolkit:

"[...] and distribute that work under terms of your choice, provided
that the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications."

The terms of the LGPL does not allow software that are derivatives of
LGPL libraries to prohibit reverse engineering.

True.

Selling software usually means licensing it...

<snip>

OK, and these are perfectly reasonable objections on your part. The
only reason I expended all of this effort was a previous statement
(many posts past now) in which you said, "I don't mind giving away
changes I make to Fox-Toolkit but being required to give away the
commercial application source that statically links to a modified
Fox-Toolkit is something that bars me from using it."

As I and others have noted, statically linking a commercial
application to an LGPL'd library does *not* require you to give away
the source code for that commercial application. You are, however,
absolutely correct to note (in your follow-up posts) that the LGPL
does require some degree of reverse-engineering which may be
unacceptable.

Thanks for letting me clarify my position (and for expanding on
yours). Best of luck with your project(s).

···

On Fri, 6 Aug 2004 08:21:26 +0900, H. Simpson <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> wrote:

We all have our opinions but in the end, facts are all that matters. FLTK might be ugly to you, which is fine, but some of the other things you posted don't make any sense when compared to easily verifiable facts.

IMHO, I don't think FLTK is any uglier than other toolkits:

http://www.easysw.com/htmldoc/shots.php
http://www-timc.imag.fr/Yves.Usson/personnel/FLE/calcsci1.png
http://www.osc.edu/~jbryan/VolSuite/images/screenshot.png

Lothar Scholz wrote:

Hello Jamey,

> The good news about this whole thing is that, when it comes to > developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK,
> Ruby/Gtk, or wxRuby. That, to me, is the best news of all.

Okay i give you my impression (based on an older 1.1.X version)

Ruby-FLTK is good and easy to use for In-House applications.
This is where people want something that is working and they want it
as fast as possible. Most of them are (very) small applications - i
mean logic not the dataset.

If you want to deliver to clients FLTK is often no good option and it
is absolutely not good for mass market applications:

- No Tab movement and bad accelerator key handling.
  Making apps hard to use for Joe Average Poweruser.

WRONG. What motivates you to write incorrect things about FLTK--especially when it is so easy to verify as being incorrect?

Tab movement works fine. I just downloaded FLTK 1.1.5rc2 and created dialogs where I could TAB forwards and backwards thru the widgets.

What exactly is wrong with accelerator key handling? In FLTK when you can set the Fl_Widget::shortcut() to be something like:

         mywidget.shortcut(FL_ALT+'f'); // ALT-F
         mywidget.shortcut(FL_CTRL+'x'); // CTRL-X

> [SNIP]

Stating your opinion is fine but if you present something as fact, perhaps you should verify it before you post.