Poll #23

  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Show All Polls | Show Comments | Submit Comment ]

Poll #23

FLTK1 will do a major release jump soon. Keeping in mind that there is a dead FLTK 1.2 and an FLTK 2.1 with an entirely different API, what should the next version of FLTK1 be called?
FLTK 1.2, just replace the existing 1.2 fragments 33 / 7%
FLTK 1.3, so there is no confusion with 1.2 163 / 34%
FLTK 3.0, we need a fresh start 223 / 47%
an entirely new name to end the 1.2/2.1 confusion 23 / 4%
I suggest another name - please see my comment... 4 / 0%
FLTK 1.4, by request 23 / 4%
469 total votes.

User Comments

Submit Comment ]

From dejan, 07:36 Mar 19, 2008 (score=4)

My opinion on this is that the only branch that needs increased version is the FLTK1 branch.

Guys, FLTK 2.0 _is_ FLTK 1 with some new stuff. So talks about merge are pointless, because FLTK 2 is open for any improvement in FLTK1 PLUS it's own improvements.

What I propose that FLTK 2.0 simply continues it's life, and gradually we merge all changes in FLTK1, that are feasible (or we see that it makes sense to mix them), into FLTK 2.0, and continue with FLTK 2, preferably with increased version number.

I definitely believe there is no need for FLTK 3.0. FLTK 1.3 for new FLTK 1 branch, FLTK 2.1 for FLTK 2 branch + all changes in FLTK 1 merged.
Reply ]

From matt, 12:25 Mar 27, 2008 (score=3)

Yes, originally FLTK 2 _was_ FLTK 1 with some very needed improvements. Right now though, FLTK 1 is extremly stable, while FLTK 2 has 107 bugs on its list. It took us over a month and 400 Euros in cash to resolve the last twelve bugs in FLTK 1. How long will it take to resolve 107 bugs and 75 feature requests in FLTK 2?

I agree that it would be great if we all worked on the same code base, but after doing nothing but bug-fixing FLTK1 for the past two years, I am not happy with fixing another 107 in FLTK2. I am sure you'll understand.
Reply ]

From dejan, 17:30 Mar 27, 2008 (score=3)

Sure I understand, as well as You understand that FLTK2 has been developed for nearly 6 years, and it has many things FLTK1 does not have. You definitely understand that there are some people who do not want that work to be forgotten/discarded.

I am not the only person who thinks that FLTK2 has much better design than FLTK1, and if you guys want to continue developing FLTK in the same direction FLTK1 goes, I will definitely continue working on those 107 bugs you mentioned in previous post, instead of sticking to stable FLTK1. In fact, I did not use FLTK1 for 6 years, and have no plans of using it in the future as well.

Sure some discussion about this is very much needed...
Reply ]

From matt, 19:24 Mar 27, 2008 (score=3)

I am not suggesting that anyone is abondoning a branch. FLTK 2 ha no doubt a better structure and a more useful naming scheme. It has a hand full more features in the library, but FLUID1 is quite superior.

Both branches are developed very slowly ATM, and unless one of the branches picks up speed, FLTK will continue to lose popularity.

So what can we do?
Reply ]

From dejan, 09:31 Mar 29, 2008 (score=3)

You are a very smart man and I am definitely sure that You already know what is the best course - we should (IMHO) merge one branch into another, pick all good things from FLTK1, and merge them into FLTK2, and continue with the new (i would increase number then into 2.1 or even 2.2) one.

Yes, I also agree that FLUID1 is much better than FLUID2.
Reply ]

From niwis, 18:34 Mar 17, 2008 (score=4)

This framework is probably one of the best (performance, coding syntax, footprint, stability, etc.), but in my opinion this “strange” thing of maintaining too parallel branches (FTLK 1.x and 2.x) of the same product with conflicting functionality/features is ... at least bizarre.

I would propose to merge the required functionality of the two branches and start from there (FLTK3):

  • Start over with a clean plan and vision.
  • Do not care about backward compatibility (except if have a project of million LOC that depends on FTLK1/2 and earn money from that). I do not mind replacing some headers files and some APIs in some hundreds LOC.
  • Create plan/rules for the core system and for widget submission (not altering the core), and let this project ran with minimal attention.
  • Focus on the missing functionality (table/grid, localization, etc)
  • Focus on the creation of a Designer (FLUID is very limited)
  • Advertise FLTK (attract contributors and maybe companies).

Reply ]

From matt, 19:28 Mar 27, 2008 (score=3)

My personal projects are about 700 thousand lines of code, and Greg and Mike will likely have more in their commercial software. FLTK also has a bunch of "shadow" users who have quite a big code base as well (or at least had big code bases at some point, but unfortunatly they tend to stay in the shadow for various reasons).
Reply ]

From twtang, 01:12 Mar 17, 2008 (score=4)

Just please focus the developers' force to one version, DO NOT splite it to several any more. The vital force of a software come from its update and stability.
Reply ]

From lhj, 06:13 Mar 18, 2008 (score=3)

I agree with twtang now.
 besides I really hope fltk can keep his F and L.
Reply ]

From matt, 12:11 Mar 27, 2008 (score=4)

We will keep the F and L because that is what differentiates us from the Q, the t, and the G, the T, and the K's out there.
Reply ]

From alvin, 15:36 Mar 14, 2008 (score=4)

Since 1.2 and 2.0 have been around for a long time (years?), I would say going to 1.3. This shows a linkage to the 1.x series of FLTK whereas 2.x has a completely different syntax.

For FLTK 3.0, I would think that would be 1.x + 2.x where they are merge and the benefits/fixes/improvements seen in 1.x are merged with 2.x improvements such as namespaces, styles, etc.

Just my two cents :)
Reply ]

From engelsman, 13:30 Mar 15, 2008 (score=3)

I agree with Alvin, but would go further. I was split between going for 1.3 or jumping to 3.1 but I've just re-read matthiasm's visionary article at: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912

I would vote for 1.3 as the initial next step (1.1.8 + utf8) plus any useful features from the dead 1.2, so that it can really be closed out. Then, keeping the 1.1 style, add new and useful features from 2.0. Once 1.9 is reached, start converting from 1.1 style to 2.0 style and release the result as 3.0.x. After the 1.9 to 3.0 and 2.0 to 3.0 compatibility layers are ironed out, release as 3.1.
Reply ]

From anton146, 23:43 May 25, 2008 (score=3)

I think that along with adding new features it would be good to start to (partially) merge fltk1 and fltk2 through extracting (at least) abstraction layers one-by-one to a separate lib, smth like fltk-base
Reply ]

From anton146, 23:42 May 25, 2008 (score=3)

I think that along with adding new features it would be good to start to (partially) merge fltk1 and fltk2 through extracting (at least) abstraction layers one-by-one to a separate lib, smth like fltk-base
Reply ]

From fabien, 17:19 Apr 13, 2008 (score=3)

I would be glad that we have a unified FLTK3. I would be more than glad that we have mike to care for only one version of the toolkit. Matt, the number of bugs in fltk2 is not the problem, i think you may remember how fast i corrected hundreds of them in few months few years ago before ... hundreds of other bugs were added! But, the truth is, I would not do that today if I'm not a hundred percent sure it's worth it (i.e we issue a rc one day :-)

Because I don't believe fltk2 would finalize without a strong management (like the one you lucky guys have for fltk1) ; I would definitely love to jump on a unique FLTK3 or 1.3 or whatever version, well defined, well arbitrated, where people discuss the important changes before they do it, like it happens to be the case for FLTK1, respectful of the work of each others and with only one clear boss.

Fabien
Reply ]

From rokan, 15:36 Mar 22, 2008 (score=3)

For incremental improvements I would go for 1.3.x (1.4.x , 1.5.x, ... for ABI non-compatible changes) and if (when) fltk2-like API additions will be sufficient (including namespaces and headers in /fltk include directory) we could jump with naming to 3.0 as a "Grand Unification" branch, which would be in reality continuation of 1.x after certrain compatibility with fltk2 is reached.

Roman
Reply ]

From Doodle77, 11:31 Mar 22, 2008 (score=3)

I think the next version should be 1.3, with that being a quick release for utf-8 support and other useful features that wouldn't be too complicated to implement, and then moving most development to 2.x since really works much more nicely imo.
Reply ]

From goodwood, 02:34 Mar 20, 2008 (score=3)

what ever, please just keep 1 branch... It's painful to transplant between fltk1 and fltk2. Many great fltk Libraries also do not support 2 versions.


Reply ]

From Albrecht.Schlosser, 07:27 Mar 17, 2008 (score=3)

I voted for FLTK 1.3, because I think that it would be best to keep the relation to the 1.x series, as long as the 1.x API is used. I.e. do one or more steps keeping the API and adding utf-8, printing support, etc..

This way, making small steps, one after another, FLTK 1 users would be able to follow the release steps, rather than splitting the user community even more (1.1, 2.0, and the new release, whatever it might be).

I'd favor more small steps with changes in the minor version number, to keep people following the versions with as little effort as possible.

Thus, make 1.3 add utf-8 and all the proposed internal changes like long widget coordinates. Let 1.4 add printing support.

Make a new release every half year or so, to let the world know, that FLTK _is_ developing further.

At some time on this way, there may be the name space change/addition, as it was done for FLTK 2.0.

Then, the new FLTK version number should be 3.0 to indicate the fusion of 1.x and 2.0 series.

Albrecht
Reply ]

From yuri, 17:35 Mar 12, 2008 (score=3)

i don't care about the name (number) of release, but imho the main thing that all need is utf-8 support in FLTK1 and normal tree widget. it will be great to see the probability of partial HTMLlike formating in labels: subscripts and superscripts.

if you don't want use 1.2 for next release of FLTK1 use 1.4 (it better than 1.3 :-) )
Reply ]

From lhj, 06:20 Mar 15, 2008 (score=2)

I think ...

  fltk basic:
  unicode support,
  underlaying control,
  nice capability,

  fltk pro:
  using modern c++ tech, base on fltk-basic,
  more functionally,
  more friendly,

sorry for my xnglish, haha
Reply ]

From cb88, 23:32 Apr 06, 2008 (score=3)

well there is lib ede that is being backported to fltk 1.1.7 so you guys definitly need to get together on that... they are trying to move back to the fltk codebase

perhaps libede could become Fltk pro?

cb88
Reply ]

 
 

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