Poll #15

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

Show All Polls | Show Comments | Submit Comment ]

Poll #15

Most important FLTK application that needs to be developed?
Web Browser 580 / 23%
Word Processor 130 / 5%
Spreadsheet 113 / 4%
Presentation 61 / 2%
Collaboration/ Conferencing 67 / 2%
Project Management 125 / 5%
Development Environment 1051 / 43%
All of the above 238 / 9%
Other (post comment) 78 / 3%
2443 total votes.

User Comments

Submit Comment ]

From Engineer xxx, 08:51 Aug 21, 2003 (score=5)

WE NEED REAL TIME TOOLS. Meters, Oscilloscope displays, real-time bar graphs. So we can see what is happening when it is happening. AND DATA COLLECTION TOOLS Sample data, send as UDP packets, display it real-time.
Reply ]

From chinechen, 21:31 Jun 04, 2003 (score=5)

compare to QT, I think we use a cross-platform C++ GUI toolkit, we also have a cross-platform file access toolkit, only cross-platform GUI toolkit can not make application software run cross-platform
Reply ]

From Anonymous, 17:25 Sep 09, 2003 (score=4)

I would like to see a better method for using class method callbacks. The static method limitation is 'kludgy', IMHO. Even a tad more overhead involved with overloading and calling callback(...) would be well worth it in my book, even if fltk::Widget and the rest need to be sub-classed by a small ABC or something like that.

Who knows, perhaps with the majority of code out there the "real" handlers are not compiler-inlined anyway so calling a non-static method directly may allow for better performance in many cases.

It kinda stinks not being able to directly call non-static C++ object event handling methods with a C++ toolkit!

One of the things I've noticed with the current survey is that an IDE is getting a lot of votes. It also seems to me that a RAD type IDE would be much easier to implement (not to mention produce much cleaner code) with direct object.method call backs as well.

I'm VERY impressed by FLTK v2.x so far. I've reviewed most of the rest and am "smitten" by FLTK hands-down except for this static callback thing.

FLTK is very efficient, easy to use, the ability to link with runtime DLL's on windows is huge in my book and it has most of the functionality that I can forsee needing. Those things are exactly what C++ needs to stay in the race with other languages, especially Java (which would be good for both languages - competition is good :).
Reply ]

From Anonymous, 22:06 Aug 30, 2003 (score=4)

Just finish the 2.0 release and leave the application writing to application developers.

I think the closest to an "application" FLTK needs is a high-quality HTML widget, or maybe Mozilla embedding.
Reply ]

From Anonymous, 01:23 Oct 26, 2003 (score=1)

What we need is Fltk2 in progress. With its namespaces and sane stracture. But we will have to dream about it and wait another five years :).
Reply ]

From Rodrigo, 20:47 May 21, 2003 (score=4)

What is realy needed , not only fro fltk but for linux, is a good wyswygt html editor there`s no good licensed with GPL( if anyone is interested to work on it i i`m a volunteer
Reply ]

From Dejan Lekic, 11:59 May 31, 2003 (score=1)

Believe it or not - i have team of few opensource developers willing to start workin on such project after summer (this year)! :)
Reply ]

From Anonymous, 15:57 May 07, 2003 (score=4)

I think the two most important widgets are tree and spreadsheet widgets.  Too bad tree widgets weren't one of the choices in the poll.  I hope there are plans to add them anyways.
Reply ]

From Amanjit Gill (amanjit.gill, 05:35 May 06, 2003 (score=4)

We need something as cool as the

  • Tk Canvas
  • Tk Textedit

Following widgets need to go into standard dist:

  • the fl_table widget
  • a tree widget

Reply ]

From Anonymous, 17:32 Sep 25, 2004 (score=3)

I would like to see a light but feature packed development environment for c++ with fltk development.

Support for regular expressions within the editor.

Scripted code templates similar to those used in kde development tools and visual studio.

Something similar to visual studio's "intellisense" feature would be nice too.
Reply ]

From jpff, 07:05 Oct 09, 2003 (score=3)

What I really need is a terminal emulator, as application or better as class
Reply ]

From Anonymous, 14:06 Aug 28, 2003 (score=3)

A IDE that has a form designer like Delphi or C++ Builder. In other words, a RAD envorinment.
Reply ]

From Anonymous, 04:55 Jul 28, 2003 (score=3)

More schemes should be created.
Reply ]

From Anonymous, 22:18 Jun 19, 2003 (score=3)

Whats needed is a lightweight defect tracking system.  Too many developers are resorting to documents and spreadsheets to manage defects and issues.  Bugzilla is great but takes way too much config for a small project.
Reply ]

From Anonymous, 23:10 Sep 09, 2003 (score=2)

Check out CVSTrac.  Intgrates very nicely with CVS and allows links between tickets, CVS checkins and builtin Wiki display/editor.
Reply ]

From Mike Sweet, 14:26 Jun 21, 2003 (score=1)

The FLTK bug report page is available via CVS in the "www" module. Feel free to grab it and use it for your own project (just needs PHP and MySQL...)
Reply ]

From Anonymous, 01:34 May 08, 2003 (score=3)

Perhaps the poll is intended to find out what, in the opinion of FLTK developers, is the FLTK based killer app that would sweep aside GTK, Qt, MFC (and everything else) and leave FLTK as the dominating toolkit on the planet.(:-). How many distros include FLTK in their cd's? AFAIK, only SuSE. While every distro includes Qt, GTK, WxWindows, etc, etc. It's the widgets that make the toolkit, which makes the GUI, which makes the apps. IMHO, this poll will not serve any useful purpose.
Reply ]

From Dejan Lekic, 05:55 May 08, 2003 (score=3)

The main goal of FLTK project is NOT to put 1000 widgets in one huge library, but to have core library that is pretty small, and easilly embeddable, and put other stuff into separate, external libraries... Every developer should keep that in mind. Allthough you said every distribution has Qt, GTK+, and/or some other GUI ToolKit(s), i would like to remind you that FLTK is anyway counted as the third GUI ToolKit that is used widely by opensource developers (i have read it recently on LWN). Any idea why? - Here is the answer - having toolkit inside distro will not help it's popularisation so much, if people KNOW FLTK is good, they will install it upon installation of distribution. P.S. apt-get install fltk is just one command...
Reply ]

From Roman Kantor, 12:11 May 16, 2003 (score=2)

> Perhaps the poll is intended to find out what, in the opinion of FLTK > developers, is the FLTK based killer app that would sweep aside GTK, Qt, MFC

What about "FLTK Server" for remore displaying of fltk programs? I know we have X, but if (when) Fl_Device-like dispathing mechanism will come to fltk core, what about dispatching event delivery (most of Fl class) as well? It would allow not only multi-display X, but making also a remote "FLTK Server" for displaying any fltk application on any platform. The remote FTLK server would be independent application. It would require some caching mechanism (probably double window all the time + pics, tooltips, ...) and would comunicate with client program through, say,  SSH channel. Once you have writen a "fltk-portable" program, you can display it on any platform where FLTK is ported just by "re-linking" it to particular dispatched device. This might be useful for handhelds etc...
Reply ]

From Ashish Ranjan - ashishwave, 09:31 Jul 16, 2003 (score=1)

Thatz a very good idea. Thumbs up! It will be a very good thing to do.
Reply ]

From Anonymous, 13:13 Sep 23, 2003 (score=1)

Evil Entity Linux includes fltk and flek in the standard install, and provides fltk apps as default whenever possible. And FLUID is in the desktop menu. That's 400,000+ users seeing fltk everyday.
Reply ]

From Dejan Lekic, 06:00 May 08, 2003 (score=1)

Another thing that i had to say here is this: All mentioned GUI ToolKit(s) are in so many ways SPONSORED. And i think (but not fully sure) all of them have developers that work full time just on them, right? I can't even imagine what would happen if FLTK project would be sponsored in that way... I am pretty sure that would change a lot of things you've sad above!
Reply ]

From Anonymous, 03:56 Jan 14, 2005 (score=2)

Web Browser Mozilla - Firefox Word Processor OpenOffice - AbiWord Spreadsheet OpenOffice Presentation OpenOffice Collaboration/ Conferencing Evolution? Project Management ? Development Environment dev-c++

I think it would best to blaze a new trail.... Those packages are going to be hard to beat, and why there is plenty of other stuff to do.
Reply ]

From John Hendrickson, 13:15 Oct 20, 2003 (score=2)

FLTK is the easiest C IDE for X period!

Definitely we all need a quick GUI builder!

Not exactly "origional" - as very similar tools have been made for a while and are plentiful.  The UI builder doesn't know much about all to many things (ei, builtin help, motif widgets, system calls, X calls).

But the end result is excellent at any rate:

Code and widgets are tied all into a most easily navigated, understandable, and usefull IDE. The auto generated code is immediately compileable.  All these things add up to the easiest and fastest 'quick develop' application I've used - and I've tried many.
Reply ]

From bohan, 19:39 Nov 04, 2003 (score=3)

what i'd like to see in fltk is a canvas group widget similar to what Qt provides.
Reply ]

From Anonymous, 13:13 Oct 09, 2003 (score=2)

CASE tools
Reply ]

From Michael P. Jung, 18:41 Sep 06, 2003 (score=2)

The world needs a fast, easy to use and reliable file browser.
Reply ]

From Anonymous, 03:05 Jun 30, 2003 (score=2)

I liked the scalable font editor and lightweight tabbed console (maybe based on rxvt) ideas.  In general lightweight versions of communication applications and development tools would be nice.

Hmm... Now that Apple made KHTML independent of Qt and there's already the earlier effort at porting KHTML to Flnx (the crummy Fltk v1.0.7(!) port to Microwindows), a better KHTML port to Fltk2 might be appropiate.
Reply ]

From Geoffrey, 04:50 Jun 22, 2003 (score=2)

What about something like Geramik or QTcurve for FLTK? - So one would have the option that the look of the current desktop environment would also be applied for FLTK applications. This would allow to develop smoothly integrated programs that do not rely on QT or GTK, but use our favourite toolkit.
Reply ]

From bandwidthcrunch, 07:02 May 14, 2003 (score=2)

Lets Get something up and running like the PIXIL environment (And dont fork it ) , something like browsers , PIMs, image to be deployed on small footprint budget . Sample applications with source code for references and please keep it GPLed ,  lets do this world some good ...
Reply ]

From Anonymous, 15:11 May 17, 2003 (score=2)

I think there should be more support in fltk for printing and document generation - images as well as text.

Also, fltk should make it easier for the programmer to install custom fonts without using native X and/or psdk function calls.

There is some 3rd party support for utf8 encoded text for fltk which should be examined for possible inclusion with fltk as well as text encoding conversion - at least between different iso8859-n and windows encodings.
Reply ]

From Anonymous, 18:07 May 17, 2003 (score=4)

>I think there should be more support in fltk for printing and document >generation - images as well as text.

Sounds like a good idea to me as long as it's not put in the core lib.

>Also, fltk should make it easier for the programmer to install custom >fonts without using native X and/or psdk function calls.

I like this idea.  This also gives me an idea for a FLTK app:  a font editor--something that could create vector fonts in a cross-platform format.  There aren't too many free font creation apps out there.
Reply ]

From Amanjit Gill (amanjit.gill, 02:34 May 08, 2003 (score=2)

(pre) sorry for starting the thread about widgets, its basically offtopic.

  • a rtf/html style editor would be a killer application! (I would not call that word processor, because of the lacking printing support)
  • a development environment is too critical! Developers are very picky about their (I)DE (at least I am), so it is hard to make that thing work right. Too big of a problem.
  • Anything with graphics would be cool. Lets say some tight imagemagick binding and a picture-viewer with a nice browser would be cool.

Reply ]

From Mister Satan, 16:49 May 07, 2003 (score=2)

If I understand correctly, the poll is about 'applications' as in 'full fledged programs, not widget-like' things, right? Kinda like FLUID: not part of the library itself, only distributed with it.
Reply ]

From Anonymous, 16:59 May 07, 2003 (score=1)

Doh!  I should have read it more carefully.  Kind of a wierd poll then.
Reply ]

From Mike Sweet, 07:13 May 08, 2003 (score=1)

Weird?  What's weird about asking people what applications they want using their favorite toolkit?
Reply ]

From Anonymous, 11:47 May 08, 2003 (score=1)

It's just a toolkit.  Personally, I don't care what GUI toolkit was used to make a program (and, most of the time, I can't even tell).  As a programmer, I use FLTK because it is easy and, well, fast and light.  This poll is kind of like asking "What C++ program should be developed next".  It's silly because the end user can't even tell how it was made.
Reply ]

From Anonymous, 23:15 Jun 27, 2003 (score=1)

Duh. What better way to advocate, advertise and show off a toolkit than to have a list of applicationas and say "Look, this is built with this."

Therefore it is *very* important. For fun is one thing, but I would never ever choose a toolkit for any serious or commercial project that can't show some real apps for itself. If it can't do that, how do I know if it can handle it? Sure, the examples look good, but maybe it blows up with lots of widgets? I can't tell, and so I pick some other toolkit that has something to show for it.

How hard is that to understand...?
Reply ]

From Hairy, 10:03 May 06, 2003 (score=2)

IMHO the thing that can be done : good table widget (may be some modification of flvw library, it's not supported long long time, and not now compiling with fltk2.0 cvs)
Reply ]

From Dejan Lekic, 18:19 May 06, 2003 (score=3)

But it is planned to be part of FLTK 2.0 . I think all agreed that Greg E. did a good job. :)
Reply ]

From Anonymous, 18:34 May 07, 2003 (score=1)

Greg Ercolano has a good Fl_Table widget but it has no simple means of get/set data to the cells. It is on the todo list in his readme. Won't someone help finish this widget? I'm not a good enough coder myself. In other gui's there are stringgrids(like delphi) that I am thinking would look like  grid[0][0]->value("A")  in fltk. I can only imagine using the STL  vector <vector <object> > (2d vector) container to implement this.
Reply ]

From Mister Satan, 19:33 May 07, 2003 (score=5)

Greg's Fl_Table can be used as a container for widget (as cells), or to draw the data. You can always subclass Fl_Table to manage the data yourself. Check the latest version (2.12), which includes my (very) simple example of a spreadsheet without the overhead of one widget per cell.
Reply ]

From Anonymous, 01:33 May 08, 2003 (score=2)

Thanks M.S., your singleinput.cxx example is just what I was looking for to learn how to use Fl_Table. I am just a beginner so it's going to take me a while to digest it.
Reply ]

From hel420, 05:37 May 11, 2004 (score=1)

i like layout managers in qt and java.
Reply ]

From Yeah yeah coward it is, 19:28 Nov 22, 2003 (score=1)

You want a killer app ? What about emulation layers for both Qt and GTK ? It may sound whacky, but just imagine for a second the possibilities if the two major DEs would be forced to really compete without hiding behind toolkit issues! Plus you get almost all the linux desktop apps google can find for free :-)
Reply ]

From mjr, 10:44 Oct 16, 2003 (score=1)

What i'd like to see in FLTK future:

  • maintain backward compatibility, best both in ABI as well as API. This will massively reduce the effort and cost of software maintenance. As both GTK nor QT maintainers don't do this, garanteed backward compatibility might be a major criterion for choosing FLTK to develop new stuff.

  • support for PALMOS >= 3.x within the limits imposed by that platform

a remark to the file manager thread: there is already a fltk based file manager, part of the xd640 project. What iŽd like to see is a fast lightweigt file manager implementing the feel of the NeXT file manager and supporting DND to, say, the dock/wharf/whatelse of windowmaker/afterstep/blackbox/macosx/windows desktop

the xd640 file manager might be a good starting point, but its speed could be improved (xfiler and FSViewer are faster)

Applications on my personal wishlist:

  • mindmapping tool
  • port of lyx to FLTK (better, FLTK as an alternative to XFORMS and
      QT/KDE in the official lyx source tree)
  • port of xsox to FLTK (are there other xforms based apps worth  
      porting?)
  • notation editor - most of the exiting projects are KDE based and
      therefore heavily bloated.
  • a terminal emulator with configurable buttons to add some "GUI"
      functionality to the shell or menu based terminal applications
      like mutt, elm, microemacs, vi
      i saw something like this on HPUX (elm in hpterm). Without such a
      special feature there are IMHO enough working terminal emulators

Generally spoken, i see the market for FLTK based app not in the office mainstream but in relatively small yet interesting niches.

Michael
Reply ]

From Anonymous, 06:59 Oct 14, 2003 (score=1)

Is my arithmetic wrong or do the percentages really add up to less than 100%?
Reply ]

From Anonymous, 12:28 Oct 14, 2003 (score=2)

It's because shown percentages are rounded down. While I'm writing this, the 22% and 42% should be 22.95% and 42.95%
Reply ]

From Anonymous, 01:23 Oct 15, 2003 (score=3)

Still wrong! The 22% should be 22.85% (480 votes out of 2100), and the 42% should be 42.90% (901 out of 2100).
Reply ]

From Jameth, 11:04 Sep 21, 2003 (score=1)

The most needed app is a file-browser. Currently, all file-browsers with significant power are clunky beasts. On my system (yeah, only a 700 Athlon) none of them load in under a second if I am running anything at all, and they usually don't do so if nothing is running.

File-organization/data-management is one of the core uses of a computer. If it cannot be done quickly, the entire experience suffers.
Reply ]

From Anonymous, 18:42 Sep 28, 2003 (score=2)

I agree that improving the core features of FLTK should be the goal for quite some time.  Like making compiling the library less of a chore.  I've never gotten makefiles that work right out of the box. That would be for win32 (mingw32, borland).  Not everyone has VC++.
Reply ]

From hammadi.mourad1, 07:26 Aug 27, 2003 (score=1)

est ce vous pouvez m'aidez de donner plus de documentation sur le fltk
Reply ]

From Anonymous, 07:42 Aug 07, 2003 (score=1)

Okay, it's not an application, but... FLTK really needs C bindings!  :(
Reply ]

From Anonymous, 10:01 Aug 23, 2003 (score=3)

C bindings would be useful.
Reply ]

From Anonymous, 16:54 Oct 15, 2003 (score=1)

I also agree!! C bindings would be most useful. I think with C bindings FLTK would be a first choice replacement for GTK2.
Reply ]

From Anonymous, 12:07 Aug 18, 2003 (score=1)

Hi! As a new-comer to FLTK it would have been helpful to have the docs section more inter- related, and definitive. I do agree with other comments of the need for a basic print facility that can be built on, especially for use with multiplatforms. However, it is a great tool-kit, and wonder, having come thus far, would we want to fork from it. I've learnt a lot using it. (perhaps that's because the docs are brief and make learners like myself work).
Reply ]

From Greg Ercolano, 14:02 Jul 02, 2003 (score=1)

Development environment? Bah! Fluid rules, baby.

The MS dev environment has totally spoiled programmers into depending on goofy bloated large scale 'environments' that create equally bloated garbage code full of automated code droppings and wacky 'DO NOT REMOVE' comments. Feh!

Maybe all that's needed here is a few little demo videos to show how fluid works. Maybe I'll make some.
Reply ]

From donno, 19:40 Jul 09, 2003 (score=1)

>Development environment? Bah! Fluid rules, baby.

>The MS dev environment has totally spoiled programmers into depending >on goofy bloated large scale 'environments' that create equally ?bloated garbage code full of automated code droppings and wacky 'DO >NOT REMOVE' comments. Feh!

>Maybe all that's needed here is a few little demo videos to show how >fluid works. Maybe I'll make some.

Greg - if FLUID is so good, why are there so many votes for a better "development environment"?  I freely admit I've had a couple of problems with fluid, but I realize that there is a lot about it that I don't "grok".  For UI issues, I really, really prefer that right mouse button gives you a context menu for the currently selected component.  For code generation, fluid formats c++ funny.  I've been looking at c++ reformatting progs just to get over that hump. To be clear, I like the c++ in all the test programs, but fluid c++ looks sort of ugly.

That said, if I was a real coding guru with lots of time, I'd fix fluid or fork it.  I'm really neither, and just want to code up a few things I've dreamt.

regards to all -Donno
Reply ]

From ashishwave, 05:58 Jul 16, 2003 (score=5)

Hi,
 i think that one thing can be done for the scarcity of widgets in fltk.
  (u accept it or not, it is a great hamper in FURTHER progress of acceptance in dev community. Atleast u need good widgets, yaar ) There may be many unofficial libraries supporting many other things like database, filesystem abstraction ,widgets etc., but these are not updated frequently as fltk versions come out. Take the case of Fl_Device itself. We can not apply patch of an older version of fltk on a new version, till Fl_Device's new version comes out. There is no spl comment on Fl_Device, i just gave it just as an example.
  I think that why dont, we make libfltk.a and libfltkx.a ( extra "x" for extended ), here fltk.a will contain the base fltk system and fltkx will contain official extra collection of fltk widgets , filesystem abstraction, fltk light xml interface (just as in wxwindows). If anyone just want to make a simple application from basic widgets then he will simply link it with libfltk.a , but if he wants to use a good collection of widgets, then he will also have to link with libfltkx.a.
  There are many such projects which use such approach, even fltk has libfltk_images.a and so on. Then why just such a small argument of some keeping the fltk based apps small should hamper the need of more widgets and abstraction libs. just keep these official libs in a seperate lib but in the same source code main distribution package.
  And also plz include Fl_Device into core.
  AND "MDI(Multple document interface)" is also needed.
 and what about .fl file format of fluid changed to xml based format.
 whether we can have native look for the widgets also available as an option, for example Windows XP like native look on Windows XP, so that when we make these big apps (about which this poll is there) then do not look separate from other apps by their looks.
 fltk is a **toolkit** , initially it only had core thin **GUI abstract layer**, now it will have extra widgets, THIN abstract filesystem, xml, database connection layers ( just see wxwindows and all other ) as different libs( but built from the same single MAIN OFIICIAL sourcecode distribution), developers can link just to various abstract thin fltk layers which is needed in their apps - I THINK THIS SHOULD BE THE POSITION OF FLTK COMMUNITY FOR FURTHER MARCH.
  i think we should innovate, not stick to a non-furthering cause. Otherwise one unix guy (not needing windows ) could just used motif there was no need for fltk. But fltk exists, because there arose a void and a problem domain, which it filled amicably. Now as world progress the needs is for more thin abstract light layers for more things, which should be part of a fltk-the *light toolkit* of abstract thin portable layers.
     i hope that i will get a reply/comment back from Sweet on every separate point.
Reply ]

From Anonymous, 17:44 Sep 16, 2003 (score=4)

>For code generation, fluid formats c++ funny.  I've been looking at >c++ reformatting progs just to get over that hump. >To be clear, I like the c++ in all the test programs, but fluid c++ >looks sort of ugly.

Why are you editing the FLUID code?  The purpose of FLUID is not to generate pretty code that you can edit, but to write your basic FLTK code for you.  If you modify the FLUID output, and then regenerate your code, you lose the changes. 

The main problem I have with FLUID is that when you write code (e.g., code blocks or widget initialization code) you don't have syntax highlighting, searching, and all the other things we've come to expect from a code editor.
Reply ]

From Anonymous, 02:36 Jun 08, 2003 (score=1)

I think unicode support is very important!!!
Reply ]

From Anonymous, 01:15 May 23, 2003 (score=1)

What could be better than a groovy stripchart for perfmeter ?

  A) tree tool with drag and drop,
  B) configurable network layout widget,
  c) 3 dimensional desktop viewer!

 

  • oom

Reply ]

From Hugues, 05:11 May 14, 2003 (score=1)

The choices in the poll already have multiple free implementation using various widget sets, OpenOffice being the most advanced by a long way, so what's the point?

A "killer" application for FLTK would have to be relatively small and incredibly useful -- ie, not an office component, which fails both requirements (my bias, sorry).

Some time in the past I was hoping that the GUI for LyX could be relatively easily re-done with FLTK, thanks to the compatibility layer with Forms, but they've gone with Qt.

For me: maybe a mail client that supports MH correctly (I'd kill for an exmh replacement), a lightweight tabbed console (great for Windows!), a better time-tracking tool (than titrax).

Something hard to do that doesn't exist yet would be a PS/PDF editor (not just a viewer), to replace the full version of Acrobat.
Reply ]

From Anonymous, 04:06 May 06, 2003 (score=1)

I'm using FLTK to develop a software to handle 3d object (3DS)
Reply ]

From Anonymous, 21:47 May 05, 2003 (score=1)

I'm not following the list right now, but I'm not sure I understand this question. I thought FLTK was a fast light *tool kit*. As tool kits go I see a few things that would be nice to have, some of which have been partly developed by others:

1) database integration (SPTK) perhaps with a reporting facility 2) a sorted column list widget 3) a grid widget - as for spreadsheets 4) device indpendent output (e.g. Fl_Device w/ a Win32 printer
   driver, as well as html and pdf) 5) better plotting widgets with a consistent interface (starting w/
   Cartesian perhaps) 6) 3rd party widget integration in Fluid (a plugin architecture) 7) consistent scripting language interfaces delivered with the source
   (pyFLTK)

plus all the goodies in FLTK 2.0.
Reply ]

From Anonymous, 15:53 May 07, 2003 (score=4)

I've always thought of FLTK as a graphical user interface toolkit.  I personally think all other things should be left to other libraries. 

>1) database integration (SPTK) perhaps with a reporting facility

What does this have to do with GRAPHICAL user interfaces?

>4) device indpendent output (e.g. Fl_Device w/ a Win32 printer >   driver, as well as html and pdf)

(Same comment as for 1)

>6) 3rd party widget integration in Fluid (a plugin architecture) I'm not sure how you envision this "plugin architecture" working, but you can already already incorporate new widgets into FLUID.  The only problem is you can't see what they will look like in FLUID.  I think writing a plugin for each new widget violated the KISS principle. 

>7) consistent scripting language interfaces delivered with the source >   (pyFLTK) Once again: what's this got to do with GUIs?

If we start adding things like this to FLTK, it might as well be renamed "Slow Bloated Toolkit".
Reply ]

From Anonymous, 13:01 May 09, 2003 (score=1)

-I've always thought of FLTK as a graphical user interface toolkit.  -I personally think all other things should be left to other -libraries. 

>1) database integration (SPTK) perhaps with a reporting facility

-What does this have to do with GRAPHICAL user interfaces?

It doesn't have anything to do with GUIs. I've noticed that a lot of people are partial to DBs. It seems that they are really good at holding data and getting back the data you need when you ask for it. It happens that a lot of people like to ask these questions via a GUI, they like to see the response in the same GUI.

This is such a common operation that many other toolkits or frame- works provide this support.

FLTK already contains libs that are not part of the core but can be linked in as needed, like the image lib. Is the display of multiple different graphical file formats really required? No, but it is nice to be able to handle them when required by adding in the image lib.

I think it is useful to package nice well-tested widgets with the main distribution so that they have consistent documentation and are maintained with the main line releases.

>4) device indpendent output (e.g. Fl_Device w/ a Win32 printer >   driver, as well as html and pdf)

-(Same comment as for 1)

Applying the same logic to the graphical display and the printed output is extremely useful and efficient use of code. I see little reason not intercept the abstract drawing commands and send them off to an alternate renderer. These alternate renderers would be extra libraries at link time, so again if it's not used the cost is limited only the main line changes.

>6) 3rd party widget integration in Fluid (a plugin architecture) -I'm not sure how you envision this "plugin architecture" working, -but you can already already incorporate new widgets into FLUID.  -The only problem is you can't see what they will look like in -FLUID.  I think writing a plugin for each new widget violated the -KISS principle.

KISS is useful concept and FLUID is a nice tool, but it could be better.

My fantasy is a common widget template that could be used to develop new widgets. The resulting widgets would placed in some location known to fluid. When the user wants to add a widget they could select a class from the repository. The widget would contain minimal information on how to draw itself into its bounding box and perhaps change its widget level parameters (i.e. color and perhaps fonts, maybe the overall style info for FLTK 2.0). Ideally the widget template, whatever its form, would also contain some autotesting and example code for each of its features. FLUID might dump this code as needed to a file or into a code block. FLUID should also make the creation of these template widgets as easy as possible.

A clever FLUID may be able to parse widget code from a regular source file without any need for pluggable code.

I don't think a "property sheet" style development tool is required for every new object, but it would be nice to easily integrate new widgets.

>7) consistent scripting language interfaces delivered with the source >   (pyFLTK) -Once again: what's this got to do with GUIs?

Again this is outside of libfltk, but it would be nice if the bindings were consistent with each release and well documented.

Why shouldn't FLTK be able to replace TK as the GUI of choice for scripting?

What new things would be possible if FLUID supported scripting? Perhaps the widget template parsing suggested above would be easier in such a dynamic runtime environment.

What if callbacks or other code blocks could be easily tied to python or ruby scripting fragments, with FLUID generated code including all the goodies to embed the scripting language of choice.

-If we start adding things like this to FLTK, it might as well be -renamed "Slow Bloated Toolkit".

Many of the technologies above have already been invented (SPTK, Fl_Device, pyFTLK) and work without a lot of impact on the FLTK core.

Perhaps the FLTK fork into FLTK and eFLTK reflects attitude and perhaps eFLTK is the better avenue for such "enhanced" features.

It would be nice if code could transparently compile if moved from the core FLTK to the superset eFLTK as additional features are required.

I'm afraid that without some coordination the different variants may not stay consistent (FLTK 1.1, FLTK 2.0, eFLTK).

I'd much rather see just one strong project.

-Don (also author of the first post)

P.S. -- I'd also like to see a tree widget.
Reply ]

From Anonymous, 15:19 May 12, 2003 (score=1)

I misunderstood what you said about the scripting language interfaces; I thought you were saying FLTK should have its own built-in scripting language interpreter.  Now, I see your point.  I can also see how device-independent output could be useful, since this is closely linked to displaying graphics. 

-Anonymous (also author of the reply to the first post)
Reply ]

From MacSteve, 15:39 May 27, 2003 (score=1)

Hi,

I like fltk gui toolkit, because this is smart, fast and really multiplatform. But, when I try to use eFltk under windows (dev-cpp: eFltk.devpack) and linux, these versions aren't consistent. EDE project seems good, but I think, it is just for linux (or unix).

Because I use both of windows and linux, I'd like to see these projects under these OSs (at my work I must use windows, but at home I use linux).

Fltk 1.1.x the best choice, because I can use it without modify source code. eFltk cause some problem to me. Using other libraries (like sptk) is very difficult or impossible to me. If I will make an application, I want to run under windows and unix. This is useful, because in a heterogeneous environment I don't have to make two different application.

For example, I need some additional libraries to reach postgresql server with window$ and linux clients (at this time I don't want to learn php-java-html :)

If somebody want to answer me, plz email me (macsteve@freemail.hu).

Best wishes and thank you for your toolkit :)

MacSteve
Reply ]

From Carl, 21:53 Jul 29, 2003 (score=1)

Good replies so far.  I'm glad there's support in the development community for people to get direct and important answers right away.  To the original poster: what you're suggesting leads to building your own operating system very quickly.

We need to decide at what level of complexity our applications should interact.  How much processing of which kind of data is done locally or remotely.  For instance, I would like to program a network-enabled bottom end for a simple fltk gui that would communicate with another program I've written and control it remotely through dedicated input and output data streams.  This path leads to a collection of individual processes running simultaneously under the same simple gui control, with each module being maintained by a seperate individual or group.
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'.