a) As we told you may times, fltk-bugs is only read by two or three developers.
This is not a mailing list for general use. That's what fltk-general is for.
> With the exception of Erco's work and one other (who no longer works with
> fltk, apparently), most of the s/ware I've seen linked at the fltk forum has
> been, how shall I say?
b) I don't know. Put it any way you like.
> It's like... Like mine. Half baked, incomplete, or just screwy.
c) yes, these are contributions by our users. I don't have the authority to
criticize, modify or fix those. It's like a wiki, or give-a-penny take-a penny.
> Should I make bug reports about other people's work? It's linked here at the
> fltk page. I think not.
d) no, please don't
> But this, I think is your problem. What I want to report is that it took me
> about two hours (so far) to find stuff to play with, ideas to explore,
e) when you download fltk, you get over sixty (count'em) sample and test
programs with it that pretty much handle any perceivable programming issue with
fltk. It's right there.
> But wait! It has been suggested to me that I check my email settings.
>
> I don't WANT email.
f) then don't request EMail. You can browse all our mailing lists with your
browser, or using a news reader. A news reader is pretty much the same as a
"forum", only far superior.
> I don't WANT to be a developer (been there and done that and it's usually a
> bad fit between my crazy exploratory "computer research v. computer science"
> approach. So all I want to do is challenge the developers here... to raise
> questions, suggest new approaches, and DEMONSTRATE the functionality, if not
> the implementation of some of my "mad science".
g) you are pretty far from core developer status at fltk
> 1. We need a better way to get control of subwidgets in new classes. Just
> combining them into a group is not adequate. This may be possible without
> breaking into the main fl_event handler, but I haven't seen how to do it yet,
> somy approach is to really take over the fl_event handler. (Fl::handle(int).)
h) you can derive the handle() function of each individual widget. That's how
you get into the innards if you must.
> 2. We need an easier and BETTER way to draw boxes; one that can be used to
> copy/clone themes from other applications easily. The most straight forward
> way to do this would be to take a screen shot of the other application(s) and
> use those graphics (encoded with alpha) to print box characters (yes, it's
> very retro-- character graphics) which can be accomplished with a simple
> graphic editor and an alpha converter.
i) fltk has a very simple interface for adding your own box styles. It's in the
docs.
> 3. We need a way to easily pass messages to widgets through the timeout loop.
> Some functions won't work until the event loop (Fl::run()) is running.
> (This is not hard, but it should be a documented, standard feature.)
j) read up on Fl::awake(). It's exactly what you ask for.
> 4. We need an icon view.
k) Fl_File_Browser with icons enabled?
> 5. We need something like Erco's treeview widgets, but with a simpler
> interface. Perhaps the ugly part can be hidden somehow -- it's really a very
> very nice implementation with the exception of how keys are (or aren't)
> handled and some limitation on where one can click, which I think also traces
> back to the problem of breaking into the main loop to grab events meant for
> other widgets.
l) tree->add("file"); tree->add("file/open"); tree->add("file/close"); It can't
be any easier.
> 6. We need a way to control widgets (and again the main loop is the suspect)
> so that they can be animated in the fluid designer -- if not connected!! (I
> think it was a terrible mistake for Qt4 to quit animating buttons.)
m) that's what Fl::add_timeout() is for.
> 7. Your email list is too hard to get at. It should be publicly viewable by
> those of us who prefer to remain anonymous, but who want to play with an
> excellently designed toolkit with incredibly simple and easy to understand
> examples, and that shows real-life X windows sample code that you can't find
> anywhere else on the net. (But you need to include debugging info to see it
> work.)
n) publicly viewable like this:
<http://www.fltk.org/newsgroups.php?gfltk.general+T> ?
> 8. So I have one more suggestion. And this may be way off target since I
> don't even use the stock installer or makefiles. There should be an option to
> compile with debug info in one's own home folder. And if you don't want your
> test apps to be a meg each, compile fltk as dso's.
o) like, if you would use "./configure --enable-shared" ?
> That too is what I do, but it's up to you guys. :-) I've got my own plans.
> I'd like to think I can offer some ideas to you guys, but it seems like
> development is pretty much dead on the 1.xx versions. I diffed 1.6x and 1.7x
> or something and there were almost no changes.
p) there is neither a 1.6 nor a 1.7. You are probably referrring to 1.1.6 and
1.1.7. These versions are many years old. 1.1.10 would be the stable version,
1.3 is under development - as the main page clearly states.
> So this raises some questions as well. Where can I get 2.x? Do I even want
> it? (I'm curious about the gtk+ theme but I'll bet it's one of those hand
> drawn things also.)
> Go to the fltk page and see if you can find version 2.x. You've got only 2
> hours... better get started. :-)
q) You could go to http://fltk.org and click on the link confusingly named
"Downloads" and click on the link named "fltk-2.0.x-r6970.tar.bz2" in the
fourth line of text. Or you right away click on that link on our home page.
> And again, I do NOT want to be a developer. You guys have to have pretty
> thick skin to take all this criticism, and I just can't handle the
> negativity... ;-)
r) ...
> In conclusion. BREAK INTO THE MAIN EVENT LOOP. You'll be glad you did.
s) that would be the worst thing to do.
> At least I think so... ;-) I'm going to try to get the combo box clone
> (Input_Choice) to work (and to position and resize correctly) by way of
> reading events (either in the group widget or if necessary, in the main
> fl_event loop).
t) there is a function for that. It is called "resize()" and it gives you all
the information you need.
> And concluding my conclusion: I truly do thank you for this software. It's
> the most fun I've had in years.
My conclusion is that you hop from one issue to the next without going into any
depth. There is plenty of stuff that could be improved in FLTK. Most of what
you listed though is already implemented and documented.
- Matthias
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
