Amazing GUI toolkit with visual designer & Ruby Integration

[H. Simpson]

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

 

[Phil Tomson]

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.

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

 

[Jamey Cribbs]

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.

 

[Joao Pedrosa]

Hi,

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

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



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

 

[Jamey Cribbs]

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

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.

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.

 

[Lothar Scholz]

Hello Jamey,

JC> The good news about this whole thing is that, when it comes to
JC> developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK,
JC> 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.

 

[H. Simpson]

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.

 

[Richard Lyman]

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

 

[Lothar Scholz]

Hello Richard,


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

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

 

[H. Simpson]

Hello Jamey,

JC> The good news about this whole thing is that, when it comes to
JC> developing gui apps in Ruby, we have a choice! Be it FXRuby, Ruby-FLTK,
JC> 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:
http://www.fltk.org/links.php?L+P6

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

 

[H. Simpson]

Hello Richard,


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

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

 

[H. Simpson]

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

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:

http://www.fox-toolkit.org/license.html

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

http://www.fltk.org/COPYING.php

If anyone tells you that GPL and LGPL

 

[David Ross]

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

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

 

[Paul Brannan]

But I did come across a screenshot of FLKT here with something like an
elvish font here:
http://yaroslav-v.chat.ru/russian.html

I think that's called Cyrillic. It's probably closer to Greek than it
is to Tengwar.

Paul

 

[Lyle Johnson]

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?

 

[Sander Jansen]

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:

http://www.fox-toolkit.org/license.html

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

http://www.fltk.org/COPYING.php

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

 

[Lyle Johnson]

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

http://www.fox-toolkit.org/license.html

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

 

[Lyle Johnson]

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!

I think that regarding the licensing issue, he didn't care so much
about releasing his changes to FOX itself.

He believed that the LGPL also required him to release the source code
to his application (as part of the re-linking clause), which is not
the case. The LGPL does require that your application's user is able
to re-link against a different version of the LGPL'd library, but one
acceptable way to satisfy that requirement is to provide the compiled
*object* code for your application.

 

[H. Simpson]

(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

Again, I'm not a lawyer so my translations are simply opinions of an
unqualified stranger on the internet.

The difference is very simple:

A. If you statically link your app to a modified FLTK, your app is
still EXEMPT from the license and only those "changes made to FLTK" must
be comply with the license.

B. But if you statically link to a modified Fox-Toolkit, your app is
NOT EXEMPT and considered a "derivative work of the [LGPL] Library" and
must comply with the terms of the LGPL regarding such work.

If you don't mind the terms of the LGPL regarding "derivative work" then
this discussion is irrelevant to you. But if you don't want your app to
be bound by the terms of LGPL regarding "derivative work" then you
should not statically link your app to a modified Fox-Tookit.

And once again, I state for the record that I don't mind either the
GPL/LGPL approach and the BSD/MIT approach to licencing. I simply
cannot use the GPL/LGPL stuff in some (but not all) of my projects
unless there are sufficient exemptions (like FLTK's exemptions to LGPL).

QUOTE FROM FLTK LICENSE
"3. Static linking of applications and widgets to the FLTK library
does not constitute a derivative work and does not require the author to
provide source code for the application or widget, use the shared FLTK
libraries, or link their applications or widgets against a user-supplied
version of FLTK.

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

MY TRANSLATION: The first paragraph (3) makes apps statically linked to
FLTK exempt from the license. Then the second paragraph states that if
we link to a modified version of FLTK, the "changes to FLTK" must be
provided under the terms of the license. Therefore, the application is
still exempt from the license when linked statically to a modified FLTK
because nothing stated takes the exemption away.

Fox-Toolkit on the other hand, would require the application itself to
also be released under the LGPL. Which has very different consequences
to closed-source projects that which to use Fox-Toolkit and find
themselves needing to tweak Fox-Toolkit. Note the following quote:

QUOTE FROM FOX-TOOLKIT LICENSE RATIONALE:

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

MY TRANSLATION: This means there is no LGPL exemption for static linking
if Fox-Toolkit is modified. The exemption only applies to UNMODIFIED
Fox-Toolkit. Which means if you statically link to a modified version
of FOX-TOOLKIT, then your entire application is considered a derivative
of an LGPL library which means you must comply with LGPL
terms/restrictions for your entire application. See below.

QUOTE FROM LGPL:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

MY TRANSLATION: If you statically link to LGPL library, then your
application is considered a "derivative of the Library" rather than a
"work that uses the library".

 

[Richard Lyman]

Humm..

You said two things...

1. LGPL / GPL / {insert name of license} says...
2. I translate...

... and left out a third...

3. The creators of the license say...

What do Lyle or Jeroen say? (Yes Lyle - _I_'ve read your posts... but
have others?)

-Rich

(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

Again, I'm not a lawyer so my translations are simply opinions of an
unqualified stranger on the internet.

The difference is very simple:

A. If you statically link your app to a modified FLTK, your app is
still EXEMPT from the license and only those "changes made to FLTK" must
be comply with the license.

B. But if you statically link to a modified Fox-Toolkit, your app is
NOT EXEMPT and considered a "derivative work of the [LGPL] Library" and
must comply with the terms of the LGPL regarding such work.

If you don't mind the terms of the LGPL regarding "derivative work" then
this discussion is irrelevant to you. But if you don't want your app to
be bound by the terms of LGPL regarding "derivative work" then you
should not statically link your app to a modified Fox-Tookit.

And once again, I state for the record that I don't mind either the
GPL/LGPL approach and the BSD/MIT approach to licencing. I simply
cannot use the GPL/LGPL stuff in some (but not all) of my projects
unless there are sufficient exemptions (like FLTK's exemptions to LGPL).

QUOTE FROM FLTK LICENSE
"3. Static linking of applications and widgets to the FLTK library
does not constitute a derivative work and does not require the author to
provide source code for the application or widget, use the shared FLTK
libraries, or link their applications or widgets against a user-supplied
version of FLTK.

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

MY TRANSLATION: The first paragraph (3) makes apps statically linked to
FLTK exempt from the license. Then the second paragraph states that if
we link to a modified version of FLTK, the "changes to FLTK" must be
provided under the terms of the license. Therefore, the application is
still exempt from the license when linked statically to a modified FLTK
because nothing stated takes the exemption away.

Fox-Toolkit on the other hand, would require the application itself to
also be released under the LGPL. Which has very different consequences
to closed-source projects that which to use Fox-Toolkit and find
themselves needing to tweak Fox-Toolkit. Note the following quote:

QUOTE FROM FOX-TOOLKIT LICENSE RATIONALE:

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

MY TRANSLATION: This means there is no LGPL exemption for static linking
if Fox-Toolkit is modified. The exemption only applies to UNMODIFIED
Fox-Toolkit. Which means if you statically link to a modified version
of FOX-TOOLKIT, then your entire application is considered a derivative
of an LGPL library which means you must comply with LGPL
terms/restrictions for your entire application. See below.

QUOTE FROM LGPL:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

MY TRANSLATION: If you statically link to LGPL library, then your
application is considered a "derivative of the Library" rather than a
"work that uses the library".