Amazing GUI toolkit with visual designer & Ruby Integration

Discussion in 'Ruby' started by H. Simpson, Aug 4, 2004.

  1. H. Simpson

    H. Simpson Guest

    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
    H. Simpson, Aug 4, 2004
    #1
    1. Advertising

  2. H. Simpson

    Phil Tomson Guest

    In article <aX9Qc.349$>,
    H. Simpson <> wrote:
    >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
    Phil Tomson, Aug 4, 2004
    #2
    1. Advertising

  3. H. Simpson

    Jamey Cribbs Guest

    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.
    Jamey Cribbs, Aug 5, 2004
    #3
  4. H. Simpson

    Joao Pedrosa Guest

    Hi,

    --- Jamey Cribbs <> 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).


    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
    Joao Pedrosa, Aug 5, 2004
    #4
  5. H. Simpson

    Jamey Cribbs Guest

    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... :)
    >
    >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.
    Jamey Cribbs, Aug 5, 2004
    #5
  6. 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.


    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Aug 5, 2004
    #6
  7. H. Simpson

    H. Simpson Guest

    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.
    H. Simpson, Aug 5, 2004
    #7
  8. 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
    <> 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.
    >
    >
    Richard Lyman, Aug 5, 2004
    #8
  9. 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.

    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Aug 5, 2004
    #9
  10. H. Simpson

    H. Simpson Guest

    Lothar Scholz wrote:

    > 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, Aug 5, 2004
    #10
  11. H. Simpson

    H. Simpson Guest

    Lothar Scholz wrote:
    > 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, Aug 5, 2004
    #11
  12. H. Simpson

    H. Simpson Guest

    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
    >
    >
    > On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson
    > <> 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.
    >>
    >>

    >


    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
    H. Simpson, Aug 5, 2004
    #12
  13. H. Simpson

    David Ross Guest

    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"
    <>
    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
    David Ross, Aug 5, 2004
    #13
  14. H. Simpson

    Paul Brannan Guest

    On Fri, Aug 06, 2004 at 04:06:28AM +0900, H. Simpson wrote:
    > 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
    Paul Brannan, Aug 5, 2004
    #14
  15. H. Simpson

    Lyle Johnson Guest

    On Fri, 6 Aug 2004 02:51:39 +0900, H. Simpson
    <> 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 Johnson, Aug 5, 2004
    #15
  16. > 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







    --
    "Nervous hands grip tight the knife
    In the darkness, till the cake is cut"
    - Peter Gabriel
    Sander Jansen, Aug 5, 2004
    #16
  17. H. Simpson

    Lyle Johnson Guest

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

    > 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, Aug 5, 2004
    #17
  18. H. Simpson

    Lyle Johnson Guest

    On Fri, 6 Aug 2004 06:28:25 +0900, Sander Jansen <> wrote:

    > 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.
    Lyle Johnson, Aug 5, 2004
    #18
  19. H. Simpson

    H. Simpson Guest

    Sander Jansen wrote:

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


    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".
    H. Simpson, Aug 5, 2004
    #19
  20. 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



    On Fri, 6 Aug 2004 07:51:27 +0900, H. Simpson
    <> wrote:
    >
    >
    > Sander Jansen wrote:
    >
    > >>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
    > >
    > >

    >
    > 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, Aug 6, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ben Fidge
    Replies:
    0
    Views:
    1,820
    Ben Fidge
    Feb 26, 2006
  2. Mike Painter
    Replies:
    0
    Views:
    424
    Mike Painter
    Nov 2, 2006
  3. Chris Angelico
    Replies:
    1
    Views:
    211
    Wolfgang Keller
    Jun 14, 2012
  4. Dietmar Schwertberger
    Replies:
    5
    Views:
    303
  5. Dietmar Schwertberger
    Replies:
    5
    Views:
    346
Loading...

Share This Page