Poll #20

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Show All Polls | Show Comments | Submit Comment ]

Poll #20

How much should Cairo Graphics be used in FLTK 2? (http://www.fltk.org/articles.php?L622)
Not at all. 327 / 17%
As an option only - keep the existing OS drawing code. 674 / 35%
As an option only, but make it the default. 406 / 21%
Exclusively - drop the existing OS drawing code. 353 / 18%
Don't care. 128 / 6%
1888 total votes.
This poll is closed.

User Comments

Submit Comment ]

From Portale, 13:58 Jun 30, 2006 (score=4)

I think it would be a big opportunity to give fltk developers full cairo power. Small mainstream applications of today want to look fancy, the webdesign look (DHtml/Ajax/Flash) inluenced the look of todays desktop applications. Fltk has a great functionality but probably not yet enough fanciness out of the box (although the plastic scheme in Fltk1 looks quite nice).

Idea of some kind of compromise: would it make sense to enhance the FLTK drawing API by the major Cairo functionality (encapsulating cairo itself) and let the OS drawing just support a small subset of the API? And a style developer can consider that some of the features in his/her style are not rendered if cairo isn't used and make his/her style fallbackable.
Reply ]

From fabien, 03:07 Jul 05, 2006 (score=4)

Yes, it does make sense indeed to support a subset of cairo with portable API. It is already the case now (though still in development). You can test that with the arc demo and compile it with or without cairo, it will work ! Even the new setcolor_alpha() function is written in a way that if no alpha is available then it behaves as setcolor(). But if you want too, you can also use custom cairo api embedded in fltk drawing code (see new cairo.cxx demo) !
Reply ]

From amanjit, 21:04 Jul 06, 2006 (score=3)

My ideas

  • Don't make us pay for something we do not need; With fltk, I can do 2-D linear transformations, have a reasonable feature complete drawig API today and can always resort to platform API.
  • Make cairo an optional rendering backend, so fltk code stays cairo independant.
  • Provide OO-abstractions in fltk for extended cairo functionality _or_ a documented way to do direct cairo calls (probably preferered), in the same way you can do direct win32 stuff at present
  • Always consider rendering performance.
  • do not make any core functionality - like printing - cairo dependant.

I really do not understand the necessity of cairo it probably makes the low level drawing code a lot easier (transparancy etc?). If this is the case why don't we just steal the cairo ideas for things we lack and put it into our low level drawing code.

Thanks for reading
Reply ]

From fabien, 03:46 Jul 10, 2006 (score=3)

1. According to the vote , the option of not compiling with cairo has great chance to still be possible. 2. In other threads, we talk about this possibility of decoupling rendering as a device. Not really trivial to achieve, so would not be done now. 3. Just have a deep look into cairo features and you'll probably understand easily why we don't wish to reinvent the wheel by incorporating cairo-like code in fltk :)
Reply ]

From Anonymous, 02:15 Jul 01, 2006 (score=3)

I have nothing against Cairo, the examples look brilliant, but I am concerned that requiring Cairo will open up the same can of worms that many applications have that require gtk, or qt, or kde libraries. What happens to the developers of applications for hand helds, etc? And if you open the door to Cairo, why not to other drawing libraries?

If anything, fltk should maintain an abstract drawing layer API, and mainstream fltk should continue to use the standard OS drawing layer below it. Cairo, or whichever other enhanced drawing library, should be offered as an fltk-addon that adheres to the same abstract drawing layer API.
Reply ]

From seanzig, 07:31 Jul 18, 2006 (score=4)

I agree that FLTK's niche is well-established.  I write mostly small, self-contained programs with a focused purpose.  Thus, the size, ease-of-use, static "linkability", etc. are all positives in my mind.  Also, I use OpenGL quite a bit, so that functionality is important to me.

I usually find toolkits like Qt and Gtk bloated for my purposes, though they are sometimes more appropriate for large, long term projects.  However, to make FLTK more attractive to both small and large projects, I propose that extra functionality like Cairo be optional add-on's.
Reply ]

From afaltl, 15:00 Aug 14, 2006 (score=3)

Yes, I agree that FLTK should stay independent. Currently I write a demo for a 3D computer aided design program and have quite a bit of the basics working. It's considered to be used as the new GUI for Varkon, and one of the concerns by the original authors is avoidance of library "rat tails". I hate them as well. I spent about 3 weeks reading specs and trying demos before deciding for FLTK and I choose it because it's independent, fast and good C++.

My demo has now 13.5kLOC and starts up in a fraction of a second (I measure that for you if you tell me how - no joke). Please keep it that way! QCad which I use on a regular basis was once comparably fast, and maybe because it's based on Qt has now become a real starting-lamer. Besides my need for 3D I want to get away from it because of that - but where do I get if FLTK changes under my fingers?
Reply ]

From etorres, 13:08 Jul 07, 2006 (score=3)

I think if FLTK will have in its heart another library it will lose all its essence, and FLTK won't be FLTK never again. I think it will be an suicide that will put the FLTK heart on other hands becoming it vulnerable and addicted library. I also think that by default FLTK should be absolutely an independent library...!
Reply ]

From wetoasis, 13:21 Jul 07, 2006 (score=3)

I use fltk for the following reasons. 1) Doesnot depend on other libraries. 2) Small, Fast, and again not bloated. 3) Platform independent, and easy to port from one platform to the other. 4) Can be statically linked

So if these still stay true, you will get my vote unconditionally.

Reply ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.