Poll #18

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

Show All Polls | Show Comments | Submit Comment ]

Poll #18

What kind of printing features do you want in FLTK 1.2 (please comment on additional features, etc. you want)?
Standard printing dialog with printer properties 415 / 18%
API for printing without a dialog window 183 / 8%
Standard print preview window/widget 155 / 6%
All of the above 1369 / 61%
None of the above 99 / 4%
2221 total votes.

User Comments

Submit Comment ]

From spitzak, 14:24 Mar 31, 2005 (score=3)

Really what fltk needs is some way to create a pipe that you can write PostScript to, and a way to make the drawing functions produce this PostScript.

The rest should be left up to the "desktop environment". Unfortunatly there seems to be zero progress in doing this right, I am following Gnome and KDE, but the closest thing is programs like "kdialog" and they are depreciated.

What should happen is if I want a file chooser, I actually exec() a program called "filechooser". Pipes and command line arguments are used to control it and get responses back. Same for a printing panel. There is no reason for an fltk program to contain a huge library or to implement popup control panels of it's own. Current fltk programs are almost 50% file chooser, which is insane. Windows somewhat has this right in that they provide file choosers and print panels as part of the operating system, but you cannot change them easily. The exec() model would be much more Unix-like and would allow users to replace them easily, for instance if you are running KDE you would get the KDE ones. I think this would instantly put Linux far ahead of Windows or OS/X, because there would be thousands of brilliant ideas contributed to new file/print/etc choosers.

Unfortunatly I am not sure fltk can make this happen. It could be written to exec such programs, using kdialog and gdialog as guides for how to do it, and provide default implementations for such programs, and provide extremely crude fallbacks (such as a one-line text edit for a file chooser). It could even provide KDE/Gnome versions of the programs. But this would mean fltk programs would have to be "installed" to be used correctly. The temptation to just bloat up the fltk library and programs to avoid the "installation" is really strong!
Reply ]

From rokan, 00:50 Apr 03, 2005 (score=3)

Under KDE there is a program called kprinter which am usually piping postscript (using --stdin option). It has limited command-line options but it is useable - it also accepts a configuration file as an option (this is good because your particular application can use specific settings). I believe kprinter is a part of most standard kde installations so I just test  what desktop is running (is there any environmental variable for that? I am testing for KDE_FULL_SESSION=true) You could probably also test for existence of kprinter under KDEDIR/bin/kprinter. I have no idea if there is a GNOME equivalent. Either way if fltk would not find reasonable printing manager program, as a fallback it can ask the user to supply one explicitly (including printing options) or "print to a file". Similar with preview: fire kghostscript or whatever external program is in the preferred desktop/view application...

Roman
Reply ]

From Andreas Tropschug, 04:13 Nov 30, 2004 (score=3)

Highly standardized actions like printing, file opening, directory finding are to be done through standardized GUIs. No one wants to learn how to print a file anew with every program he installs and live with the bugs the developer left in because he didn't really care about something as trivial as printing. You have standard dialogs for those actions in Windoze, I think thats a feature. They wouldn't blow up the source or anything, because its a simple api call. I agree that you have to draw a line somewhere. But printing is quite a basic thing. If it is possible to add a standard dialog and api
 under *nix, without building it if someone doesn't need it, that would be great! Then I would even go for the "All of the above" approach.
Reply ]

From Cristian, 06:05 Dec 05, 2004 (score=1)

I would have to say that the printig api is the most important aspect thow i do agree that a standard printing box would make life easyer for both the developer and the user. So i'd say that the api should have priority , the dialog box can come later , hey if the api is allready there , someone else could create the printig box and give you the time you need for other more important things. I've only just started using fltk (and c++ :) ) but i must say that i'm deeply impressed by it. Cheers!
Reply ]

From andy, 09:54 Nov 14, 2004 (score=3)

about printing: i find that sorta thing somwhat damaging to our forests.  about FLTK: going to try it for our portable zweistein video editor.
Reply ]

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

Printing would be nice and would make fltk that much more useful.

Something else I would like to see is the ability to read and write pixels within a widget in order to make it easier to implement highlighting etc. for non-textual widgets. 

I'd like to see basic support for unicode.  The ability to load and render unicode fonts etc.  UTF8 is nice but difficult to deal with when using eastern character sets due to the fact that a character can be up to 6 octets.  Also, the current UTF8 support branch in the fltk source trees is somewhat limited at present.
Reply ]

From spitzak, 14:30 Mar 31, 2005 (score=3)

FLTK is *not* going to support any character encoding other than UTF-8 with illegal sequences interpreted as ISO-8859-1. That is a final decision and no alternatives will be considered.

The "six octets" argument is wrong. First of all, no assigned Unicode character takes more than 4. Second, even Chinese text will have enough spaces, control characters, digits, and english letters, that any document is smaller in UTF-8 than in UTF-16.
Reply ]

From Anonymous, 00:31 Jul 27, 2004 (score=3)

Do you have any plan to supports directfb, menuetos, svgalib?
Reply ]

From Mike Sweet, 13:53 Aug 28, 2004 (score=3)

I believe there is already some work done for DirectFB, but it hasn't been integrated.

The new device classes will allow for easier porting to other display/input APIs...
Reply ]

From Anonymous, 12:52 Oct 08, 2004 (score=2)

Me, I guess I want the standard API, but of course a printing widget would be also nice to have -- like, maybe, a demo of a typical printing thingy...
Reply ]

From Roliverio, 15:10 Jul 04, 2004 (score=2)

FLTK should have the possibility to use multiple printing Interfaces, including the "direct" one, maybe it's not that important to make one of their own, but a printing preview frontend it's a must no matter what printing API you use, and printing directly to a default printer it's necessary as well, IMHO FLTK developers and mantainers should save the work of doing a complete printing api, and only interact with existing ones, this saves work, and it works...
Reply ]

From Nudge, 15:31 Jun 08, 2004 (score=2)

The advantage of the standard dialog is abstraction - Not every programmer wants to create a specific printer dialog, because the task is clearly defined and only the backend knows what printer is used and how it is set up. And I think that even on MS Win this is no drawback - most probably one uses a SINGLE printer, so the most natural thing is to control a SINGLE printing dialog, system-wide and in every application. If every application used its own dialog, we end up in chaos...who wants to write a thousand man pages...?
Reply ]

From Anonymous, 09:29 Jun 30, 2004 (score=3)

Right, but there has to ba a way to print directly without any dialog. My Company for example has measuing programs which continuesly print values for law reasons.
Reply ]

From z0D, 11:05 Nov 13, 2004 (score=1)

Simpler is better.

With printing API anybody can write what he want. In any case my project have not needed any features other tan API. Incapsulate any of not needed fetures in library in any cases way to produce Huge and Buggy library, like a QT or gnome libs. It is a not unix way. I want API only without anything else.
Reply ]

From Dan, 14:10 Oct 26, 2004 (score=1)

I think best thing is to write an HTML file and then launch a standard web browser to display it. The browser it self know how to print...
Reply ]

From Alexey Parshin, 01:59 Oct 10, 2004 (score=1)

Printing is a must for every toolkit. This is a basic task. On Windows, it's not really a problem, because to draw to memory context is really simple. But, if you need to create a cross-platform application - most likely you have to create a PostScript file. It can be done, of course, but it should be a part of the toolkit, may be as a separate dll/so. Same thing is a good print preview.
Reply ]

From Anonymous, 12:17 Aug 25, 2004 (score=1)

There should be an drag and drop GUI editor! The only thing I need is just that for the moment
Reply ]

From muthu dearestchum, 11:49 Sep 05, 2004 (score=3)

I like FLTK. its got the real thing of lightness, seriously adding printing features,  I think Id have to shift from GTK+ to FLTK. Cheers Muthu
Reply ]

From Sanel Z., 07:43 Aug 03, 2004 (score=1)

Hm, adding printing API will increase FLTK's source size, and compilation time. With this we will get mastadont toolkit (once you add one API, there will come time for adding second etc.), and what you get ? Big toolkits like wxWidgets and Qt. I'm thinking that developers who use FLTK should handle these things. What happened with time when we could put entire FLTK's source on floppy ?
Reply ]

From dejan, 04:43 Feb 23, 2005 (score=3)

"Floppy time" is over Sanel... If we want to follow modern techics, UI design and still be cross-platform etc. we MUST end up with HUGE source tree, and megabytes of source.
Reply ]

From Mike Sweet, 13:56 Aug 28, 2004 (score=3)

Also, the only reason you can't fit the FLTK source on a floppy is because we now also include the JPEG, PNG, and ZLIB libraries for consistent image file support - you can omit these if you like...
Reply ]

From Mike Sweet, 13:55 Aug 28, 2004 (score=2)

That doesn't necessarily follow, as many environments use a common API for both display and printing (only X11 doesn't have this universally)

Also, the printing code, like all other code, will only get linked in if you use it (0 overhead if you don't).
Reply ]

From Anonymous, 13:38 Aug 04, 2004 (score=1)

In reply to Sanel's posting:

We should take care that there are no dependencies from the core to the printing part, so that linking statically will not any extra byte for people who don't use it.

And by the way it's not only the size of FLTK that makes it different, it is also the easy programming style.
Reply ]

From George Garvey, 23:18 Jun 01, 2004 (score=1)

It was difficult to choose on the poll, because things were mutually exclusive. The API is the most important thing. A preview window would be second priority.

If "standard dialogs" are made, please make them customizable by a child widget. Now on MSwin we have our own FLTK dialog using the API instead of the standard dialog-that-does-it-all-for-you-and-take-it-or-leave-it: which isn't easy, because MS seems to assume you won't use the API to make a dialog. On Linux we have a dialog that gets info from CUPS.

I would hate to see FLTK end up like MSW: very hard to make one's own dialog if the need is there. Not predicting that will be the case, just registering a preference.
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'.