RE: [fltk.general] FLTK in comparison

[MacArthur, Ian (Selex ES, UK)]

> For my project I have the task of selecting a user interface tool kit
> where we can develop a chip design user interface. In the background it
> uses verification tools, so the user interface is pretty important.
> I considered quite a lot of tools. Most tools I discarded because they
> were either non-free software (causing lack of confidence in the future)
> or were not able to support GUI and 2D in connection with our C++
> modules.

I don't think we can advise you on which TK is best for your application - we don't know enough about your use or needs, and I doubt that I (for one) could give an unbiased view...


> So I ended up with GTK+, WxWidget, Qt and (obviously) FLTK and need to
> make a recommendation on the basis of these three.

Note that fltk has a focus on being small and stable; the other toolkits you mention all provide a much larger and more complete set of functionality, in that they are also providing many components that are not GUI objects, but more related to a general cross-platform runtime.

That might be the sort of issue that makes the deal for you, rather than the GUI toolkit elements - there are questions there you need to answer within your team, I guess.


> Currently my problem is, that I have a pretty good idea of the quality
> of documentation and community of the first 3, but not so much of FLTK.
> For instance when I look up the documentation link on the FLTK apps tab,
> it is empty.

Huh? Where did you look?

http://www.fltk.org/documentation.php is certainly not empty, and I guess you'd want to start with:

http://www.fltk.org/doc-1.3/index.html for your browsing.



> Fortunately I found some tutorials on the links tab. Unfortunately the
> Open University here in the Netherlands teaches java, and understanding
> C++ code from tutorials is a bit of a challenge. One of the other
> project members is a C++ programmer, so our bases are covered.

> What I found (outside the FLTK site) is remarks like:

> "FLTK is lightweight and easy to learn, but limited in widgets"

True, I believe.

> (from a GTK+ and Qt user): "I am content with GTK+ and Qt, but had I
> known about FLTK sooner, I would be using FLTK now" (not a literal
> quote).

Can't comment; I *am* using fltk now...!

> So I thought I might ask the user / dev community what you think.
> 1. How does FLTK stack up against the first 3 I mentioned? Do you know
> of any formal comparisons that I could use?

I'm not aware of any "back to back" comparisons.

Each has its strengths and weaknesses, and I think the only way to determine which is right for your needs is going to be to try it, to be honest.

Some folks find that all the additional "non-GUI" features that QT provides, for example, eases the cross-platform stuff so is worth the extra complexity - but it never panned out for me.

For me, fltk works fine, and my code runs on OSX, WinXX and *nix/X11 with only the odd line of platform specific code here and there to tie it all together; but some folks don’t like that style, so another toolkit might be more comfortable.

<anecdote>
A year or so back, with a colleague, I developed a prototype app for a local educational charity, and we used fltk, of course.

With our prototype, they secured some funding to have the app built "properly", but after some to-ing and fro-ing, the house they contracted to do the work (I wasn't interested) decide to port to WxWidgets (it was what they were familiar with.)

Worked for them, final app was OK (though I don't think they improved all that much on the prototype to be honest).

So either can work.

Only observation is that, for reasons I can't explain, the WxWidgets based binary was getting on for 20MB, our prototype was only about 2.5MB.
I have no idea if that's normal for WxWidgets apps, or if it was peculiar to this particular usage though.
</anecdote>

> 2a. How large is the development and user community?

Development team is small and pretty fluid. But there are folks here who have been around since the last century and are still here. Size may not be a robust indicator.

No one has a clue how big the user community is; we have never attempted to track it.

> 2b. Is it large enough to inspire confidence in the future?

To be honest, I'm not sure this question makes a lot of sense; as noted above, community size is not a robust indicator of stability or longevity.





Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[A.J. Bonnema]

Thanks Ian,

You actually helped me a lot. Of course I know you cannot decide or even consider for me, as the project is unknown to you. Still, what you did say is valuable.

You are right: community size does not equate to longevity or stability (this was my underlying assumption).
About WxWidget, I forgot they usually have very big binaries. I have heard that before. It seems to be inherent to WxWidget programs.

"the other toolkits you mention all provide a much larger and more complete set of functionality, in that they are also providing many components that are not GUI objects, but more related to a general cross-platform runtime"

Finally, this remark hit the mark. It seems to be the main difference. I believe in terms of GUI widget development the differences are minor.

The only reservation I have right now is how much platform specific stuff we will have to program. Other than that and some 2D knowledge I lack I do not see any issues with FLTK and I feel that a choice is really hard.
I do have a few specific queries:

1. Does FLTK  assist in 2D programming? The program we will build supports chip design, so 2D drawing is an issue. We need to define small primitives that represent either a singular chip component (like a join or a source or a sink) or a set of chip components (a combi primitive). I noticed that support for cairo is experimental (I read it somewhere, but it could have been outdated).
2. Does FLTK assist in some sort of observer pattern where a verifier could process a chip network and return its results to the user interface thread? We intend to run verifiers concurrently (on request) and have them return results that we show on the user interface.

I realize I have to dig deeper into the docs to find this stuff, and I will. Just maybe you already know what I am looking for. Thanks for your effort and advice.

Kind regards, Guus.

[A.J. Bonnema]

I missed one of your remarks earlier:

> Currently my problem is, that I have a pretty good idea of the quality
> of documentation and community of the first 3, but not so much of FLTK.
> For instance when I look up the documentation link on the FLTK apps tab,
> it is empty.

Huh? Where did you look?

Well, I looked at the tab of FLTK Applications and the sub-tab documentation, which states it has nothing. However, I should have looked at the links you provided. They are pretty useful.
As far as I can see, FLTK indeed supports 2D programming. But I am still looking. Maybe the signals etc will pop up somewhere.

Regards, Guus.

[MacArthur, Ian (Selex ES, UK)]

>>> Currently my problem is, that I have a pretty good idea of the quality
>>> of documentation and community of the first 3, but not so much of FLTK.
>>> For instance when I look up the documentation link on the FLTK apps tab,
>>> it is empty.

>> Huh? Where did you look?

> Well, I looked at the tab of FLTK Applications and the
> sub-tab documentation, which states it has nothing.

Ah, no. That's the wrong place; you want the "FLTK Library" tab, then go to the docs from there.

There are no fltk apps!
There is only the fltk library...

> However, I should have looked at the links you provided.
> They are pretty useful.
> As far as I can see, FLTK indeed supports 2D programming.

It has a 2D drawing API that is kinda like PS, that you can use to draw into your widget.

Or you can create an Fl_GL surface and use GL to do your drawing - for complex scenes this will usually be (much) faster, and allow for anti-aliasing, compositing, etc. more readily than fltk's internal 2D API does.

I've also used Cairo to render into fltk windows (I was looking for better anti-aliasing, and trying not to use GL!) and others have used AGG similarly. I can’t comment on AGG, but for me Cairo was painfully slow and I have heard that AGG is also very slow. (They both do a Very Nice Job though.)

So if you need to render a complex scene with fancy blending, use GL.

If it is just a 2D API you need, try the fltk API.

Others have passed this way before (chip layouts in fltk etc.) so there may be interesting stuff in the mail archives.

And I guess Greg's node graph demo might be somewhat pertinent.
http://www.seriss.com/people/erco/fltk/Fl_OpDesk/

> But I am still looking. Maybe the signals etc will pop up
> somewhere.

[MacArthur, Ian (Selex ES, UK)]

> 1. Does FLTK assist in 2D programming? The program we will build
> supports chip design, so 2D drawing is an issue. We need to define small
> primitives that represent either a singular chip component (like a join
> or a source or a sink) or a set of chip components (a combi primitive).
> I noticed that support for cairo is experimental (I read it somewhere,
> but it could have been outdated).

You can probably use the fltk 2D API for this, or GL.
Embedding Cairo is fairly trivial, either using the hooks or directly (though I find Cairo to be slow.) Others have embedded other rendering libs like AGG, SDL, etc...
(Fltk is pretty easy to use with other rendering libs.)

If you are doing anything even vaguely complicated, I'd probably look at using a GL drawing surface, as that is more likely to be hardware accelerated...

> 2. Does FLTK assist in some sort of observer pattern where a verifier
> could process a chip network and return its results to the user
> interface thread? We intend to run verifiers concurrently (on request)
> and have them return results that we show on the user interface.

That question is a bit too high level for fltk; it operates at a pretty low level. You can use the fltk capabilities to implement that sort of pattern (or indeed many others) but fltk itself does not work at that level of abstraction really.

[A.J. Bonnema]

On Monday, 10 November 2014 16:33:53 UTC+1, MacArthur, Ian (Selex ES, UK) wrote:

> However, I should have looked at the links you provided.
> They are pretty useful.
> As far as I can see, FLTK indeed supports 2D programming.

It has a 2D drawing API that is kinda like PS, that you can use to draw into your widget.

Or you can create an Fl_GL surface and use GL to do your drawing - for complex scenes this will usually be (much) faster, and allow for anti-aliasing, compositing, etc. more readily than fltk's internal 2D API does.

I've also used Cairo to render into fltk windows (I was looking for better anti-aliasing, and trying not to use GL!) and others have used AGG similarly. I can’t comment on AGG, but for me Cairo was painfully slow and I have heard that AGG is also very slow. (They both do a Very Nice Job though.)

So if you need to render a complex scene with fancy blending, use GL.

If it is just a 2D API you need, try the fltk API.

Others have passed this way before (chip layouts in fltk etc.) so there may be interesting stuff in the mail archives.

And I guess Greg's node graph demo might be somewhat pertinent.
http://www.seriss.com/people/erco/fltk/Fl_OpDesk/

Wow! That is some application. Reminds me of FBP (Flow Based Programming) where you connect arbitrary components (with the right channels between them ofcourse) and get a working program. Only FBP is a concept (JP Morrison), not a program. Thanks for your pointers. I will delve into them for sure!

I do have a C++ newbie question though: why do the header files have uppercase H as suffix in stead of lowercase h? Why do the file name have uppercase at all? The FAQ doesn't show this query so I am probably the only one wondering about it.

Kind regards, Guus.

[Albrecht Schlosser]

On 10.11.2014 15:29 A.J. Bonnema wrote:

> Thanks Ian,
>

> You actually helped me a lot. [...]

... so I can trim your questions and reply only to a few of them.

> The only reservation I have right now is how much platform specific
> stuff we will have to program.

There's usually no need to use platform specific code, unless you're
trying to do platform specific stuff like reading files, synchronizing
with other processes, or maybe using threads (something you mentioned).
For the latter there's a simple working example in the FLTK test directory.

The GUI should work across platforms w/o platform specific code. That's
what FLTK is designed for.

> I do have a few specific queries:
>

> 1. Does FLTK assist in 2D programming? The program we will build
> supports chip design, so 2D drawing is an issue. We need to define small
> primitives that represent either a singular chip component (like a join
> or a source or a sink) or a set of chip components (a combi primitive).

A good start for looking at examples and tutorials is always "Erco's
FLTK Cheat Page". There you can also find some video tutorials.

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

Looking at what you want to achieve, you might particularly be
interested in two example programs (but there are a lot more than that):

http://seriss.com/people/erco/fltk/#DraggableBoxes
http://seriss.com/people/erco/fltk/Fl_OpDesk/

> I realize I have to dig deeper into the docs to find this stuff, and I
> will. Just maybe you already know what I am looking for. Thanks for your
> effort and advice.

You may want to do a test installation of FLTK 1.3.3, the latest
release, as of Nov 3, 2014. There is a lot of working test and example
code in the directories 'test' and 'examples'.

[Hannu Vuolasaho]

I have played few weeks with FLTK and solved many own problems with it.

My impressions are that FLTK is really simple to use. Think what you want,
what you already have and derive from it and write the needed again.

It feels like FLTK works for me, not that I'm working for framework like I did in QT.

My route to FLTK was through java swing and QT.

One thing I wish to see more is use of Fluid. It is very capable, but the one chapter
in docs doesn't really make you a pro user.

On Monday, November 10, 2014 7:52:53 PM UTC+2, Albrecht Schlosser wrote:

On 10.11.2014 15:29 A.J. Bonnema wrote:


The GUI should work across platforms w/o platform specific code. That's
what FLTK is designed for.

One point where FLTK beats QT is portable apps. I have USB stick and static binaries for windows,
linux and OSX. It consumes 100MB of space but there are docs also. I can run it from there.
 

A good start for looking at examples and tutorials is always "Erco's
FLTK Cheat Page". There you can also find some video tutorials.

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

You may want to do a test installation of FLTK 1.3.3, the latest
release, as of Nov 3, 2014. There is a lot of working test and example
code in the directories 'test' and 'examples'.

 

Those three places  are good. Even if something isn't documented thoroughly,
usually it can be tested with tests or examples within minutes.

Best regards,
Hannu Vuolasaho

[Michael Surette]

On 2014-11-10 12:52 PM, "A.J. Bonnema" wrote:
>
> I do have a C++ newbie question though: why do the header files have uppercase H as suffix in stead of lowercase h? Why do the file name have uppercase at all? The FAQ doesn't show this query so I am probably the only one wondering about it.

Traditionally uppercase H files are used for c++ headers, although the practice seems to have faded somewhat.

As a member of the FLTK user community who has also used Wx and QT I would like to say there is much to like in FLTK.  It does one thing, GUIs, and it does it well.  It doesn't clutter up its code base with networking code or database code, or whatever.  If you need those things, there are other places you can get them.  For example I use soci for database access and boost signals2 for that observer pattern you want.  I'm a fan of boost.  It does many things, all cross platform.  Everything I do is cross platform without any platform specific code on my part.  What's not to like about that.

One of the great things about FLTK though is if you run into a problem the group is a great resource.  I see that it took about two hours for one of the devs to answer your original question.  That's not unusual.

That's not to say the other toolkits you mention don't have their good points.  I learnt the observer pattern through Qt's signals and slots and built my first MVC project using Wx.  Neither of those are included in FLTK.  Still if I understand what your application is, FLTK is definitely worth a close look.

[MacArthur, Ian (Selex ES, UK)]

> One thing I wish to see more is use of Fluid. It is very
> capable, but the one chapter in docs doesn't really make
> you a pro user.

There's always Greg's video of course:

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

And Robark's tutorial.

http://www3.telus.net/public/robark/

Both are a bit dated now, but the essence is still the same...

[A.J. bonnema]

On 11-11-14 10:28, MacArthur, Ian (Selex ES, UK) wrote:
>> One thing I wish to see more is use of Fluid. It is very
>> capable, but the one chapter in docs doesn't really make
>> you a pro user.
> There's always Greg's video of course:
>
> http://www.seriss.com/people/erco/fltk-videos/

Thank you for these posts. I checked out the videos and I now understand
why FLTK has the rep of being easy to learn.
In the Fluid video Greg refers to an advanced video, but it wasn't
there: I assume he never got around to it ... Pity though.

Fltk does seem to work a lot with c-structure objects as opposed to c++
structures. Although we do use objects, but also fltk uses c-strings and
(void *) pointers. Looking at the book I just bought (C++ primer) both
seem to be "evil". Is this a remnant of the past? Will it change in future?

Kind regards, Guus.

[Georg Potthast]

I don't think that even a "goto" is evil.

[Albrecht Schlosser]

On 13.11.2014 13:25, A.J. bonnema wrote:

> Fltk does seem to work a lot with c-structure objects as opposed to c++
> structures.

There's not really a difference. Or do you mean struct vs. class? Indeed
they are also very similar in C++, so there's nothing wrong with using
(C-)struct's internally.

> Although we do use objects, but also fltk uses c-strings and
> (void *) pointers. Looking at the book I just bought (C++ primer) both
> seem to be "evil".

There's nothing really "evil" in programming. Other more high-level
programming features are sometimes less error-prone, but they also mean
more overhead. FLTK strives to be a F(ast) and L(ight), so we use
pointers and C-strings.

> Is this a remnant of the past?

Yes, kinda, but there are other reasons. See above.

> Will it change in future?

That's not likely to change. FLTK is designed to run on embedded systems
with constrained memory and old runtime systems as well as today's Unix
and Linux systems with large memory, and for best portability we don't
use C++ strings and others (STL) internally.

You are free, however, to use all these features in your program.

[A.J. bonnema]

Thanks for your swift reply. I understand. Also, it pays off. I have
recommended FLTK for the project. It is now a team decision whether they
go with it or not.
We will see.

Thanks all for your advice.

Kind regards, Guus.

[Greg Ercolano]

On 11/13/14 08:19, Albrecht Schlosser wrote:
>> but also fltk uses c-strings

> You are free, however, to use all these features in your program.

Right, STL strings (std::string) can easily be passed to FLTK
via std::string's simple c_str() method.

And std::string can ingest c-strings since it handles quoted text
strings (which are themselves c-strings).

[A.J. bonnema]

I would like to thank everyone for their opinions and explanations. I
actually learned a thing or two.
I have advised to start using FLTK for the project we are working on. I
will continue to use this group for queries. The other one is for
development of the library, not development with the library, right?

Thanks everyone.

Guus Bonnema.

[Albrecht Schlosser]

On 22.11.2014 09:40 A.J. bonnema wrote:

> I would like to thank everyone for their opinions and explanations. I
> actually learned a thing or two.
> I have advised to start using FLTK for the project we are working on.

Welcome to the FLTK community!

> I will continue to use this group for queries. The other one is for
> development of the library, not development with the library, right?

Yup.

> Thanks everyone.

You're welcome.