Re: [fltk.development] fltk 3.x question
> Just curious: is this what FLTK3 is doing..? > http://www.gamedev.net/page/resources/_/technical/general-programming/the-c-pimpl-r1794 > > I haven't touched FLTK3 yet, and haven't taken the time to figure it out, > but just wondering if that's the "trick.." I came across this technique when I used to follow comp.object and read Herb Sutter's Guru of the Week column in the C/C++ Report. It was also one of the many techniques used by John Lakos to reduce code dependencies and therefore compile times in large C++ projects and I tried to implement it in my code, alongside Robert C. Martin's ideas in http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign My experience, with my own small one-man projects, was that it's a bit of overkill. If you introduce the Pimpl idiom, abstract classes for the Dependency Inversion Principle, and try to isolate the main code from the GUI, you end up with a forest of similarly-named classes spread across 3 or 4 related (sets of) header and source files. However, if you want to maintain a stable set of interfaces, for a large code base, especially one released as a library, then I can see the merit of the Pimpl idiom. For FLTK, I think it would require a lot of implementation details to be moved out of the header files... Cheers D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 3.x question
> I came across this technique when I used to follow comp.object and > read Herb Sutter's Guru of the Week column in the C/C++ Report. It > was also one of the many techniques used by John Lakos to reduce code > dependencies and therefore compile times in large C++ projects and I > tried to implement it in my code, alongside Robert C. Martin's ideas > in http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign Oops! Somehow edited out the link to Lakos' book: http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
> I am in the process of closing down Easy Software Products. As many of > you know, fltk.org is hosted on the easysw.com server. Our current > colocation contract ends in April 2012, and while I might be able to > extend things on a month-to-month basis I can't do so indefinitely out > of my own pocket (costs for 2011 were $250/month or $2500/year). All I can say is thanks for hosting / supporting FLTK all these years. Looks like the current poll about the look/feel of the site is moot :-) D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] GIT for FLTK?
I work with Lunar Linux, which switched from doing its package tracking in subversion to git a few years ago, and I've never really managed to get my head around the new terminology and workflow. git is nice in that anyone can clone the master repository and create local branches to experiment on, but if you want to write back to the master repository you still need to have write access, just like svn. Of course, the big difference is that you can advertise your branches and have other developers, including those working on the master, pull the changes from your branch and merge them back into the master. Or you can email diffs/patches just like you can with svn. Where I find it gets hairy, but maybe it's just my incompetence, is when you cock it up by merging the wrong branch and then needing to back out the mistakes. It's all very well being able to have branches that track other users' remote branches, but it's a fubar in waiting. And then you have to back it all out again using sha1sums... D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Despite there being a "What are the Versions of FLTK?" article to help guide people towards actively developed versions, there are still many new users who want to start new developments on FLTK-2. It would be useful if we could illustrate the Versions article with statistics or graphics showing activity on each version, based on the svn commit logs. Such graphics would only need to be updated weekly or even monthly. I've hacked together a proof of concept python script to extract the info, and a gnuplot command file to generate some graphs. I'm also curious to see whether the Versions article can link to them. Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk.py"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature fltk.py Description: Binary data ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk.gnuplot"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature fltk.gnuplot Description: Binary data ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-1.0.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-1.1.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-1.2.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-1.3.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-2.0.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-3.0.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature w00t! it certainly does! Now I suppose I have to keep them up-to-date. http://www.fltk.org/articles.php?L825 D. Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Yes, maybe you are right that the plots are too big for the article. If I ever update them in the future, I could reduce the height. The best would be to plot the all versions on the same graph, but if we go back to June 1998 there would be too many columns to be readable. And anyway, I haven't found a way of getting gnuplot to do that. All I have been able to manage is successive plots overwriting the first. The alternative is to have separate plots on the same page. I fiddled around with sizes and origins but gnuplot's png output driver does some weird rounding, so it's hard to get the parallel plots to be consistent. Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-all-overwrite.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-all-parallel.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Well, gnuplot has some really neat features, but this ain't one of them. The "with boxes" option gives box outlines rather than filled boxes, and although I could probably overload the line width so that "with impulses" gives something chunkier, I'm not sure how wide it will go, and it may also be dependent on which terminal driver is in use. I don't think I'll have time to tinker with this until later in the week. For info: http://t16web.lanl.gov/Kawano/gnuplot/intro/style-e.html#boxes Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature And all this time I thought that the "not so frequently asked questions" gnuplot tutorial was one of the better ones :-( but then again, maybe the author doesn't use the drivers that support filled boxes. If I have time, I may look at this again later in the week. This was only supposed to be a proof-of-concept anyway, and it would be better if the plots could be generated automatically on the [new] server, otherwise I will have to attach new ones to the STR system each time as well as update the Versions article with the new path(s). Maybe the proposed new *.de server offers something like this as part of the source hosting services. Does anyone know what's available? Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Hmm! looks like I would be better off adapting the "Stacked plot demo" at the bottom of http://gnuplot.sourceforge.net/demo_cvs/layout.html Thanks for reminding me about this set of examples Ian. Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature I do most gnuplot'ing at work where we have CentOS 5.7 with gnuplot 4.0 which dates back to 2004, so I wasn't up-to-date with the latest gizmos. I did wonder whether the plot(s) could be stored on the site, after all there is the Screenshots tab with images so it must be possible, but I have always been worried about screwing up the site with a bad commit. To enable any dev to generate the plot(s), I will need to generate some documentation and tidy up the scripts. I suggest we wait until after I've done that and everyone has had a chance to play with them and comment before we look at whether it's possible to generate plots automatically. Next week is school half-term, so I can only work on this after that... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-all-stacked.gnuplot"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature fltk-all-stacked.gnuplot Description: Binary data ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature Attached file "fltk-all-stacked.png"... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature So the stacked multiplot option does work, and with filled boxes, but unfortunately with the x11 or png drivers setting the boxwidth to 0.8 gives the equivalent of "impulses" and a value of 1.0 (or letting it default) gives an ugly chunky smear. I'm going to leave it there for the next two weeks at least... Link: http://www.fltk.org/str.php?L2806 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughtsfroma frustrated long time FLTK user.
OP described 2 separate issues: 1. slow performance of offscreen overlays, and 2. improving the look/performance of widgets using Cairo > I agree that improving the widget's look is a good idea, > and perhaps it should start with making a new set of parallel > widgets that can easily be used or enabled in parallel with > our current releases. > > I think for the short term, perhaps adding new widgets > that parallel our old ones that get included in FLTK 1.x, > starting with Fl_Widget. > > So for instance, today one of us had a version of just Fl_Widget > that entirely uses Cairo, we could include it in the FLTK 1.x > source as e.g. Fl2_Widget. It could include skinning, styling, > all the stuff we've wanted. It could get enabled only if the > lib is built with Cairo. I would hesitate to add a whole slew of parallel widgets as such, where you would have the original Fl_* widgets and equivalent Fl_Cairo_* ones. IMHO it would be better to keep the Fl_* names as adaptors that either used conditional compilation to use the original or cairo (or whatever) internals, or used some environment variable to choose at run-time. Then people would have the same interface to FLTK and wouldn't have to change their code to use the Cairo (or whatever) alternatives. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughts froma frustrated long time FLTK user.
> I'm the author of several large free-software projects which utilize > FLTK (http://non.tuxfamily.org). These look pretty cool. You should really add a page under the Links tab so that people can see what FLTK is being used for. And the stale links (especially ones where the page update was more than x years ago) should be moved or deleted, but that's another story. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
> I have to say, the FLTK development process is a total > cluster if you guys don't even have a clue that you already have > this in 2.0. Pick a path and stick to it. I don't care a lick about > which damn namespace you pick. Maybe I'll just fork 2.0 and let y'all > fight over which namespace to use... First, as I think I said before, what you have done looks great! But... I don't think you are being fair, as explained in Ian's post, although you aren't the first to say it. There have been several people who have berated everyone here because FLTK 1 and 2 didn't offer what they wanted, who then said that they would fork a copy for themselves and add all of the corrections, fixes, and enhancements that they needed. Whether they did or not is another matter, because we've never heard from them again, and any improvements that they might have made have never been made available to the rest of us. So please don't fork a copy. Please work with the community to help improve the code for everyone. That's the whole point of Open Source, no? You find that someone has already done a lot of work on something that scratches your itch, so that helps you and saves you effort, and in return you help them with code, documentation, or feedback. And it would really really help if you could raise an STR about this, and attach an svn diff patch for the relevant files because then it can be tracked here [at FLTK], in a format that people can work with. Not everyone here is up to speed with git, and once this thread has been faded from short term memories, people won't remember which revision your changes relate to, or even where your git repo resides. To raise an STR, go to http://www.fltk.org/str.php and Submit. Searching for Cairo shows 7 STRs for FLTK2 and 1 for FLTK1. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
> In fact, Cairo works pretty well in fltk2. My application torapp > guilloche designer (www.torapp.info) uses cairo exclusively. Good to know, but see below. > I'm also one of people who is willing to help maintaining fltk2 but > getting a developer status seems too hard for me. Becoming a developer is not difficult, but it is a bit of a chicken and egg situation. You first need to demonstrate some understanding of the code, coding guidelines and development process by providing some patch files for new features or reported problems. One of the existing devs can then check the patch and apply it if appropriate. After a few successful patches you will have demonstrated that you have the understanding, and will probably be given dev access if you apply for it. Of course, there is nothing to stop you supplying patches even if you never become a developer. Developer access and developer are two different things. IIRC, Greg Ercolano was a developer for years before he finally asked for developer access. To get started, you might want to search for the 7 outstanding Cairo STRs in FLTK2 and check whether they are still open. If so, and you can find a fix, attach an 'svn diff' patch file to the STR. It's as easy as that to get started. The other chicken and egg thing is that there don't appear to be any active FLTK2 developers apart from Ben, so it might take a little time before someone looks at your patch, but at least it would be recorded in the system, and could save someone else duplicating the effort. Good luck D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and generalthoughtsfrom a frustrated long time FLTK user.
> > FYI, the only other programs I'm aware of that use FLTK2 are Dillo2 > > (AFAICT an obsolete branch) and Epichord (has not been updated in a > > very long time). > > Yeah, Dillo have ported to fltk-1.3 for their more recent work, AFAIK. > > Can't comment on Epichord, but ISTR that Nuke (and maybe CinePaint) were = > using fltk2 at some point. More recent Nuke versions were moved to QT = > for compatibility with the house standards in their new stable. > No idea about the current state of Cinepaint... I just saw that one of the comments on the current poll said that the FLTK entry on Wikipedia gave a clearer summary than this site, so I just went to look. There are links to all sorts of programs that use FLTK that aren't advertised here either. Not surprising that there are so many rendering applications given FLTK's history. Kudos to all of the guys who have been updating Wikipedia recently. Now if only we could persuade them to submit patches for this site :-) D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Old FLTK2/Cairo poll Was: Re: Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
>>> When was this? I seem to recall Bill was looking at Cairo >>> rendering for some of the fltk-2 experiments, but that must be >>> many years ago now. I can't imagine he's looked at that recently >>> though. If he did anything, it'll be in the fltk-2 svn, ... >> Argh! Indeed! There it is, right in the 'deprecated' 2.0 branch! >> Full Cairo rendering! All you have to do is configure --enable-cairo. >> Nobody bothered to tell me this before I spent a week duplicating >> the effort? I have to say, the FLTK development process is a total >> cluster if you guys don't even have a clue that you already have >> this in 2.0. > *Nobody* knows what is in 2.x. Not even the people who did the work > on it... > > It was worked up by several very bright individuals (with, often, > somewhat conflicting visions of where they were actually going with > it all) who subsequently got distracted by sparkly things elsewhere, > for their various reasons. > ... > So, it appears there is working code for a Cairo backend in the 2.x > tree, but how well tested it is is anyones guess - I'm going to guess > at "not very" but would be delighted to be wrong. My understanding > (such as it was) was that the fltk-2 Cairo code was only a proof-of- > concept and did not actually work in any useful way - does it work > well for you? I must say I am surprised, then, as I didn't believe > we had that at all. I was poking around on the site looking for something else today and came across Poll #20 from 2006 http://www.fltk.org/poll.php?r20 How much should Cairo Graphics be used in FLTK 2? (http://www.fltk.org/articles.php?L622) This is from when there was a bit of a resurgence in FLTK2 development, and I imagine (I don't actually remember) that people were discussing exactly the same things then, but when the poll showed that people were not as enthusiastic for Cairo as had been thought that it was a little demotivating. Of course, Cairo was not as mature then... It would be interesting to know whether a similar poll now would give the same result. And I imagine it would depend on implementation. If the low level drawing code could be factored out into an well-defined interface class that could be substituted at compile/run time by more capable subclasses for Cairo/OpenGL/whatever, then it might just fly. But you have to then wonder about the Fast and Light aspects. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site I updated Article #825 to show fltk-all-stacked.png instead of all of the others, even though it's not been updated since February. Don't know when I will have time to look at this further :-( Link: http://www.fltk.org/str.php?L2806 Version: Web Site ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Wonko's place
> This is what Matthias has been up to lately however. His nickname at > Digital Domain was "Wonko". So Matt and Greg both worked with you at DD. No wonder they are FLTK gurus :-) D ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site Attached file "fltk-commits-2012-04-25.png"... Link: http://www.fltk.org/str.php?L2806 Version: Web Site<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Package 1.1.9 in community devpaks hasproblem
> > Um, you have seen fluid running, right? > > Nope! This leads me to see another problem in FLTK website. You don't > know what to look for when you have no prior knowledge, but your > website doesn't even give the least clue to "great things" like fluid. It's not really possible to fit everything onto the main page, but on the Screenshots tab at the top right you find some nice images of Fluid dialogs. See http://www.fltk.org/shots.php Under the Links tab click on Documentation and you get to the Greg's FLTK Videos http://www.fltk.org/links.php?V228+Q And then there's the Articles&FAQs tab http://www.fltk.org/articles.php which allows you to select FAQs and HOW-TOs. And not forgetting the Documentation tab with a full User Manual. It's all there, and not so hard to find. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Code::block and make -- howto?
> ... > So, is there somewhere we could find a better how-to on how to make > FLTK work with Code::blocks in order to see how "natively" they are > supposed to work together? When I put 'fltk "code::blocks"' into Google it came up with quite a few suggestions which contain links to the following tutorial: http://gintasdx.althirius-studios.com/2011/08/tutorial-codeblocks-with-fltk.html I don't use Windows or Code::Blocks so I've no idea how good this is, or whether it scratches your particular itch. Hope this helps D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Drag and drop a file to awindow
> According to svn, engelsman put this in the docs: > > "FL_DND_* events cannot be used in widgets derived from Fl_Group or = > Fl_Window." > > Is there any specific platform or any reason for this? Or is the = > sentence itself wrong? I don't remember adding it. The same sentence appears in the 1.1 docs http://www.fltk.org/documentation.php/doc-1.1/events.html#events Duncan / engelsman ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site Attached file "fltk-commits-2012-12-16.png"... Link: http://www.fltk.org/str.php?L2806 Version: Web Site<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site Yes, I know that I could have posted the new image directly on the site, but I was under the impression that Mike was looking for a new host for fltk.org, so I've been waiting to see what happens there. PS. I've also been having problems connecting to the forums via http: "Error: 400 Server has too many connections open -- try again later" and this has been getting more frequent over the last few weeks even though access to the rest of the site seems unaffected. Is there some glitch, or is this one of the reasons for Mike's new host request? Link: http://www.fltk.org/str.php?L2806 Version: Web Site ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Access to Forum and STR pages
As mentioned in fltk.bugs, my home box died, and I didn't remember the passord for [this] username from home, nor the subversion write access password. Following Greg's recommendation, I reset the former. I have no idea whether this is the same as the latter. Anyway, I was about to update the commits graph on Article #825, and went to http://fltk.org/site/str.php?L2806 to download the python and gnuplot scripts only to find the attachments all appear to be 0k and then give a Not Found message if I click on them. Anyway, by using the path to the graph Article #825 I was able to download the, and generated a new commits graph, but was then unable to Post File from the user's interface to the STR, and couldn't from the developer's Modify STR interface either. In both cases I got an "Unable to save file to STR!" message. I'm curious whether I can even post this article to fltk.development Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site Attached file "fltk-commits-2013-04-16.png"... Link: http://www.fltk.org/str.php?L2806 Version: Web Site<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2806: Display svn commit activity on the web page
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2806 Version: Web Site Attached file "fltk-commits-2013-04-16a.png"... Link: http://www.fltk.org/str.php?L2806 Version: Web Site<>___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Access to Forum and STR pages
> Anyway, I was about to update the commits graph on Article #825, and > went to http://fltk.org/site/str.php?L2806 to download the python and > gnuplot scripts only to find the attachments all appear to be 0k and > then give a Not Found message if I click on them. > > Anyway, by using the path to the graph Article #825 I was able to > download the, and generated a new commits graph, but was then unable > to Post File from the user's interface to the STR, and couldn't from > the developer's Modify STR interface either. In both cases I got an > "Unable to save file to STR!" message. Typical! After logging out and back in, I was able to post the png to the str only to find I'd forgotten to update the x-axis range, but at least it worked, and was able to download a second. Maybe there's some environment or cookie that isn't set correctly on all paths through the web site. So it looks like it was a glitch or the gremlins. Ignore this thread. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Access to Forum and STR pages
Me: >> Anyway, I was about to update the commits graph on Article #825, >> and went to http://fltk.org/site/str.php?L2806 to download the >> python and gnuplot scripts only to find the attachments all appear >> to be 0k and then give a Not Found message if I click on them. Greg: > Hmm, where did you get that link from? > It's subtly different than what it should be. > (the "/site/" after the domain name seems wrong) > > I looked at article #825 but didn't see that link in there, > so curious where it came from. I just cut and pasted the start of the URL from the firefox address bar so that should be "right". I didn't really think about it. The 2806 is an RFE on the WebSite STR list which I can only ever find via the [developer] WebSite tab or MyAccount after I login, whereas 825 is an article under the FLTK Library tab and is always visible, but only modifiable after I login. So the two come from different parts of the hierarchy. In Article 825 I found the predecessor of the following link worked: http://www.fltk.org/strfiles/2806/fltk-commits-2013-04-16a.png so I used the stem to download fltk.py and fltk-all-stacked.gnuplot Anyway, I managed to update, so don't worry about the PEBCAK this end. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature
I have an application with a colour bar type legend which does not give
the required resolution, so I needed to be able to adjust the low and
high values in an intuitive but minimally invasive way on screen.
I hacked together the following demonstrator, drawing some inspiration
from Fl_Slider. The features I required were:
- a vertical slider
- possibility of setting min and max values of continuous range (no step)
- possibility to move low and high sliders (min <= low < high <= max)
I then hacked it further to fit directly with the rest of my application.
Questions:
1. Does anybody know of a similar widget out there?
2. Is it worth factoring out a separate DoubleValuator base class?
3. Apart from vertical/horizontal what other features are needed?
4. Does it require min/low/high/max fields?
5. Would a floating tooltip with feedback be enough? (eg Greg's TipWin)
I'd be willing to have a go a this, but can't provide any timeframes.
Link: http://www.fltk.org/str.php?L2951
Version: 1.4-feature// test program to demonstrate DoubleSlider concept
//
// compile using 'fltk-config --compile filename.cxx'
#include
#include
#include
#include
#include
// Double slider widget:
// program sets min and max values, and then user can move sliders
// to reduce the high and low values within this range.
//
class DoubleSlider : public Fl_Box
{
// everything is public as this is just a proof-of-concept
public:
int loPos, hiPos; // pixel position of top of low and high sliders
int top, bottom;// pixel position of top and bottom of range
int clickOffset;// difference between top of slider and mouse
bool loClicked, hiClicked; // which slider has been selected
double lolo, lo, hi, hihi; // min, low, high and max values
DoubleSlider(int X, int Y, int W, int H, char* T=0)
: Fl_Box(X, Y, W, H, T)
{
box(FL_DOWN_BOX);
lolo = lo = 0.0;
hihi = hi = 1.0;
loClicked = false;
hiClicked = false;
clickOffset = 0;
top = Y;
bottom = Y + H;
hiPos = Y;
loPos = Y + H - W;
}
~DoubleSlider()
{
}
// draw within the interior of the box
//
void draw(int X, int Y, int W, int H)
{
int upper = top + Fl::box_dy(box());
int lower = bottom - Fl::box_dy(box());
// calculate widget positions of sliders
hiPos = upper + ((lower-upper - W) * (hihi - hi) / (hihi - lolo));
loPos = upper + ((lower-upper - W) * (hihi - lo) / (hihi - lolo));
// draw background line linking sliders
Fl_Color black = active_r() ? FL_FOREGROUND_COLOR : FL_INACTIVE_COLOR;
draw_box(FL_THIN_DOWN_BOX, X+W/2-2, hiPos+W/2, 4, loPos-hiPos, black);
// draw sliders
fl_draw_box(FL_UP_BOX, X, hiPos, W, W, selection_color());
fl_draw_box(FL_UP_BOX, X, loPos, W, W, selection_color());
// add the lines across the middle of the sliders
int xi = X + Fl::box_dx(FL_UP_BOX);
int wi = W - Fl::box_dw(FL_UP_BOX);
fl_color(fl_darker(selection_color()));
fl_rectf(xi, hiPos+W/2-1, wi, 3);
fl_rectf(xi, loPos+W/2-1, wi, 3);
}
void draw()
{
if (damage() & FL_DAMAGE_ALL)
{
draw_box(FL_FLAT_BOX, selection_color());
draw_box(box(), x(), top, w(), bottom-top, selection_color());
}
draw( x() + Fl::box_dx(box()),
top + Fl::box_dy(box()),
w() - Fl::box_dw(box()),
bottom- top - Fl::box_dh(box()));
}
int onPush(int X, int Y, int W, int H, int mX, int mY)
{
if (X < mX && mX < X+W && hiPos < mY && mY < hiPos+W)
{
loClicked = false;
hiClicked = true;
clickOffset = mY - hiPos;
return 1;
}
if (X < mX && mX < X+W && loPos < mY && mY < loPos+W)
{
loClicked = true;
hiClicked = false;
clickOffset = mY - loPos;
return 1;
}
loClicked = false;
hiClicked = false;
clickOffset = 0;
return 0;
}
int onDrag(int X, int Y, int W, int H, int mX, int mY)
{
int upper = top + Fl::box_dy(box());
int lower = bottom - Fl::box_dy(box());
double value;
mY = mY - clickOffset;
if (hiClicked == true)
{
mY = (mY > upper) ? mY : upper;
mY = (mY < loPos-W) ? mY : loPos-W;
value = lolo + (lower-W - mY) * (hihi - lolo) / (lower-W - upper);
if (value != hi)
{
hi = value;
redraw();
}
return 1;
}
if (loClicked == true)
{
mY = (mY
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Oh, I forgot to say: I needed to align the slider with an existing widget, which is itself pretty idiosynchratic, so added the top and bottom members to allow adjusting the alignment after the other had resized itself. Thinking about it afterwards, it would have been better to correct the existing idiosynchratic widget, and rely on the Fl_Box boundary for any alignment. So the top/bottom stuff will likely be removed. D Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
I'm diverting this to fltk.development rather than this specific RFE... Greg wrote: > It occurs to me maybe I should write an article or make a video or > something on how to make an FLTK widget, all the wacky details and > implications. I wish I had one when I was writing Fl_Tree and Fl_Table, > as there's a lot of stuff about keyboard nav and when() that I didn't > know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a "Designing your own widget" page in the documentation. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
Me: >> I'm diverting this to fltk.development rather than this specific RFE... Greg: > Sorry about cluttering up your STR, but I was on a roll. I wanted to keep the 'what about a widget creation guide' separate from the RFE, so I split that part into fltk.development. I'm not sure how to manage a collaborative effort in the design of a new widget. People will need to be disciplined to post via the STR system if we want to keep it all within the RFE itself. If we reply via ordinary messages in fltk.development on the other hand, we can go a bit off-topic without polluting the RFE. Also, I don't maintain my own web page anywhere, so actually sharing any initial development could be tricky. Do I simply upload regular patches to the RFE for people to comment on? Do I develop within the FLTK 1.3.x branch, or do I create a project on sourceforge or wherever and keep it as a separate project until it's ready for adoption? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selectinglow and high values within min/max range
Adding to the fltk.development thread rather than the STR/RFE itself. I just wanted to make a few comments relating to Greg's insights in http://www.fltk.org/newsgroups.php?gfltk.development+v:14629 My "vision", for want of a better word, but it's more like looking through a window with rain on the outside and condensation inside, went as follows. It may change as other people chip in their ideas. I wasn't planning on deriving from Fl_Valuator as such because I thought that some of the concepts don't fit cleanly with having two sliders (eg. how does 'step()' work, which slider moves when you click in the trough, does value() return high or low, etc). I had wondered about a similar Fl_Double_Valuator type base class which provide a smaller interface. Some methods would obviously be similar, such as handle_push(), handle_drag() and handle_release() taking care of when() handling, etc. However, the two classes would be separate, and would not follow the Liskov Substitution Principle. See also http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod The first real on-screen widget would be the basic trough and sliders, as shown in the DoubleSlider example code. The next level(s) up would then add boxes, labels or fields for the display/edit of the min/low/high/max values. Then Greg hit me straight between the eyes with a whole load of things I had never even considered. [I still don't understand what the moving gif is actually doing]. - keyboard/arrow key activation: yes, but needs some consensus on whether to move the low or high slider, or both. Does focus select the widget as a whole, or the last active slider(s)? - clicking in the trough locks the sliders and they move together (with or without an additional graticule) - having a "Date" slider. That's a good one. I think that there should be hooks in the lower levels that allow the programmer to provide conversion between their Date or Foo format and the internal double. A DateSlider could use a Julian Date representation for example. - representing this as a group containing two Fl_Valuator sliders. That's something I haven't got my head around. Are they stalactites and stalagmites, with one growing down representing max to high, and the other growing up representing min to low, with the group drawing between them? Isn't this going to require the group to intervene in the event handling and dynamic widget resizing as the sliders move? - round button sliders on a central rail, or rectangle/triangle combos, or user supplied shapes. Are these not just [extensions to] themes? The need for an Fl_Double_Valuator base class isn't clear to me yet. At the moment I can't see how you would use an Fl_Double_Valuator for anything other than a linear min/low/high/max linear double slider, but maybe someone else has something esoteric in mind. Anyway, that's enough rambling for the moment. I won't have time to actually do anything about this for a while, so there's plenty of scope for discussing ideas. Cheers D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design : How to use type() ?
In Fl_Slider.H there are definitions that are used for "subclasses": // values for type(), lowest bit indicate horizontal: #define FL_VERT_SLIDER 0 #define FL_HOR_SLIDER 1 #define FL_VERT_FILL_SLIDER 2 #define FL_HOR_FILL_SLIDER 3 #define FL_VERT_NICE_SLIDER 4 #define FL_HOR_NICE_SLIDER 5 although the class documentation doesn't mention the first two, it uses the values defined in Fl_Valuator.H instead: // shared type() values for classes that work in both directions: #define FL_VERTICAL 0 ///< The valuator can work vertically #define FL_HORIZONTAL 1 ///< The valuator can work horizontally and indeed Fl_Slider makes use of Fl_Valuator::horizontal() which tests type() against FL_HORIZONTAL. In "Adding and Extending Widgets" it says that type() "is an arbitrary 8-bit identifier" and "you can use it for any purpose you want". It seems to me that if I subclass some existing widgets, such as Fl_Slider, then I am not completely free to overwrite type() with my own arbitrary values. Therefore, are there general guidelines on type(), or do they only apply on widget-by-widget basis? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design : How to use type() ?
Me: >> In "Adding and Extending Widgets" it says that type() "is an >> arbitrary 8-bit identifier" and "you can use it for any purpose >> you want". >> >> It seems to me that if I subclass some existing widgets, such >> as Fl_Slider, then I am not completely free to overwrite type() >> with my own arbitrary values. Greg: > In this case, FL_WINDOW is defined as 0xf0, and the comment > from FL/Fl_Window.H says: > > .../FL/Fl_Window.H:#define FL_WINDOW 0xF0 \ >///< window type id all subclasses have type() >= this > > So it sounds like you can do whatever you want.. but only > with the low order 4 bits if type(). > > And that's if you derive from Fl_Widget. > > type() is actually one of those things I try not to mess with > in favor of using my own type() in my derived classes because > of the above. > ... > I usually try to make my own 'flags' variable in my class, > and make methods that manipulate it, rather than overload type(). I saw the other comment in the docs about type() that it was a hold over from the Forms implementation. I was struggling to relate different uses of type() in different parts of the library to one consistent whole but it never occurred to me that I might not need to use type at all. >> Therefore, are there general guidelines on type(), or do they only >> apply on widget-by-widget basis? > I have a feeling the design is "read the source luke"; > look at how the widget you derive from is implemented, > (i.e. how it makes use of type()) and then design your work > as an extension of that implementation. My problem is that in trying to remain Fast and Light, a lot of the tool kit has avoided using specific enums or class implementations, and as a result there are a lot of uchar and int fields for types, which are initialized to 0 and all sorts of overlapping #defines are called into play in different parts of the library. I suppose that if you are creating a new hierarchy of widgets then you are free to implement RTTI within those widgets in any way you want, as long as you respect the existing use of type(). So would current developer advice be to implement local RTTI ? Or should we be looking at more modern "template" or "prototype" classes where implementation is passed in? [I'm not sure if I'm using the GoF Design Pattern nomenclature correcty here]. Cheers D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selectinglow and high values within min/max range
> Coming to this party late, but I just remembered that Jason Bryan's > FLU widgets have a double-slider widget. > > His pages at OSC.edu appear to be gone but the mirror here still > seems to be working: > > http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/=20 > > His FLU_Dual_Slider might be relevant, to see how what he did > compares. > > He derived a pile of "new" fltk based widgets, so there may be > clues in that work for a template for future derivations? I was going to say that the above link didn't work for me either until I remembered to remove the =20 at the end. This will work: http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ It also reminded me that I had trawled through all of the Links pages a while ago, and weeded out the dead links to come up with: Article #884: What third party widgets are available for FLTK? http://fltk.org/articles.php?L884 So why I hadn't remembered and checked there first I don't know :-( If you go to the Flu_Dual_Slider doxygen page from the link above, the list of public methods is quite limited, so the interface looks to be quite simple. He does allow "overlap" where "low" == "high". He has derived it from Fl_Valuator, which is interesting, because that only supports a single "value" so I would be curious how he has implemented it. However, although he appears to be using the FLTK licence, I don't think we should just base our code on hiswithout understanding our own vision / requirements. Cheers D. PS. I shall update the article to include the link above [Done] ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFE: STR formatting in fltk.bugs
I know I'm not a developer, and don't really have a vote, but... > Moving link and version number to top of STR +1 > The version could even be in the title - it's only five letters. -1 It's a good idea if you receive the STR in the mail, but if reading via the web forums, then long Subjects already cause the browser to scroll, and the Next Message button disappears off the right edge. And if looking at the Roadmap where they are already segregated, is it still useful? And what about separating 1.1.8 from 1.3.r, etc? If reading via the web forums, then long Subjects cause the browser to scroll, and the Next Message button disappears off the right edge. Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to call a class function on a callback
> the Fltk libray is very new for me...and i have some trouble using
> callbacks, i really don't get it.
>
> if we assume that i have a class like that :
>
> class C{
> int property;
>void setProp(int value){property = value;};
> }
>
> I just want from a fl_menu call the function setProp.
> How can i manage to do that ?
This is covered in the FLTK-1.1.x documentation, available online at:
http://www.fltk.org/documentation.php/doc-1.1/common.html#common
Many programmers new to FLTK or C++ try to use a non-static class
method instead of a static class method or function for their
callback. Since callbacks are done outside a C++ class, the this
pointer is not initialized for class methods.
To work around this problem, define a static method in your class
that accepts a pointer to the class, and then have the static
method call the class method(s) as needed. The data pointer you
provide to the callback() method of the widget can be a pointer
to the instance of your class.
class Foo {
void my_callback(Fl_Widget *w);
static void my_static_callback(Fl_Widget *w, void *f) {
((Foo *)f)->my_callback(w);
}
...
}
...
w->callback(my_static_callback, (void *)this);
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] STR #50: fluid: selecting an object in a tab does not bring tab to foreground
I posted a possible patch to solve this feature request yesterday, but didn't see notification of it on my other account. See http://www.fltk.org/str.php?L50 Hope it's up to the required standard and I haven't missed anything. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
>> ... renam[ing] of everything from Fl_/fl_foo to fltk::foo >> seems like a waste of effort. > [...] > I don't think Bill's idea is to rename "Fl_Foo" to "fltk::Foo", > but to use the pristine form: "Foo". > > Yes, it would be a substantial effort, but namespaces are probably > the Right Way(tm), and perhaps are worth the effort. When it comes to actual use, I'm namespace neutral. However, during the process of merging fltk1 and fltk2 I can see that they are a double-edged sword. If fltk1 moves to namespaces early, comparison of code with fltk2 *may* be easier, but the existing fltk1 codebase then can't be used for regression testing, and there will also be a massive jump in the fltk1 code base that will prevent easy backtracking to find bugs, bug fixes and general change points[*]. If fltk1 moves to namespaces late, comparison is hard, but regression and tracebacks are easier. Tough call. Cheers Duncan [*] Just like reformatting all fltk1 code for a new coding standard. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
matthiasm wrote: > enum sucks! Fl_Align is an enum, which would be great to keep > alignment variables type-safe. Always a good thing for the known > reasons. But Fl_Align is not *used* as an enumeration, it is used as a > set of flags, which leads to silly constructs like these: > > > myWidget->align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE ) Isn't there an idiom where you declare a class, but its constructor is not public, and then have instances declared at class level? That way you could have an Fl_Align class, with a limited number of instances, where you also declare the bitwise operators and a value() method. Or have I been reading too many Java code snippets? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
> Isn't there an idiom where you declare a class, but its constructor > is not public, and then have instances declared at class level? A quick search of the Internet for "C++ enumeration class" throws up various possibilities using templates, and also this one: http://www.kolpackov.net/projects/c++/enum/class.xhtml I have only given this a cursory glance, but could something like this form the basis for what you want? D ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Doxygenating sources for 1.3 ?
I'm not an expert on the internals of fltk, but I would quite like to contribute to 1.3 by having a go at the initial doxygenation of the source code. I started to look at this before the summer, before things became a little unclear with the possible change of direction from 1.3 to the common library idea. I'm no doxygen expert, but I found that trying to group methods as they are in the current documentation was not as easy as it looked. That's why I'm only volunteering to do the initial doxygenation for the class reference pages. Does anyone have any tips/guidelines apart from the Coding Standards in the Configuration Management Plan document? Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
> I prefer Doxygen comments in the headers so that headers can be > distributed including the full docs, and no source code is needed. > However, since FLTK is fully OpenSource anyways, and most people seem > to prefer Doxygen comments in the source code instead, let's do it > that way. > > [basic doxygen usage tips removed] I didn't expect anyone to provide the basics of doxygen, but thanks for clarifying those conventions. I was mainly concerned with: 1. the CMP/Coding Standards rules say that the doxygen comments should all go into the header files. IMHO that's fine for a binary-only development kit where the end-user only has access to the headers. For the developers, it's probably better to have the comments with the implementation code so that they are updated together as needed. Your first paragraph now lets me do that (if the other devs agree) 2. getting a basic skeleton in place is something that Duncan Q. User can do without knowing all of the internal details, but needs an agreed framework that the developers can flesh out as the modules are updated. I want to avoid unnecessary rework for others later. 3. the current documentation groups related member functions, such as Fl_Widget's active(), active_r(), activate() and deactivate(), or resize(), position() and size(). In an initial doxygenation these would likely be separated into lexicographic order. Maybe there is a doxygen expert who can explain how to group these during phase II once the basic comments are in place. I started to look at converting Fl_Widget to have the same basic doxygen comments as exist in the current documentation pages, without grouping. Maybe I should concentrate on completing that so that there is something to talk about. After that, people could claim files to work on to avoid duplication, and merge conflicts with ongoing work. Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Question about submitting patch's
> If you have a modification which effects more than one file should > you submit multiple patch files, ie one for each file modified, or > should it be in one big patch file? What I have done in the past for the couple of patches I've made, and nobody complained about it, was to: 1. checkout the latest sources from subversion (see the bottom of the Downloads page for details), 2. edit the files as appropriate, 3. test, 4. run 'svn diff' in the top level directory and attach the output to the STR Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygen 1.3 <
Fabien Costantini wrote: > > I hope we won't regret not to have centralized all doc in one place, > > now that we deal with both H and CXX. matthiasm wrote: > I am aware that this is a compromise. I too hope that we will be fine. > At least we have a defined place, the implementation of whatever is > documented. It was argued that keeping the docs close to the > implementation will make it easier to keep them in sync. It is not > what I do in my projects, but it seems like a strong argument. IMHO, the key thing is that the documentation moves from the separate html files (that may or may not be updated with the code) into a format that allows automatic generation and that lives beside the code (and has a better chance of being kept up to date). In the first instance, whether it is in both .H and .cxx files or just in the .H files is irrelevant. The hard work will be to do the conversion. After that, we can cut'n'paste the doxygen comments back and forth between .H and .cxx as required. As Abraham Lincoln said: "you can please all of the people some of the time, some of the people all of the time, but you can't please all of the people all of the time". Or something like that. Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
Matthias wrote: > Hmm, allright, here is my take on Doxygen: > > I prefer Doxygen comments in the headers so that headers can be > distributed including the full docs, and no source code is needed. > However, since FLTK is fully OpenSource anyways, and most people seem > to prefer Doxygen comments in the source code instead, let's do it > that way. > > 1: Doxygen start with /*, the following lines start with *, the last > line ends in */ . Single line comments start with ///. All commands > start with a backslash. Please do not use any html, or output to PDF > will look silly. Use \e to emphasize (italics), \b to get a bold word, > \c to get a fixed font for the next word, or \code .. \endcode for a > longer fixed font section. \\ outputs a single \, \@ writes a single > @, same with $, #, &, <, and > > > 2: All comments go into the Source Code (not the header files) I've just started doxygenating Fl_Button, and have come across some wrinkles in the code, the guidelines, and doxygen: 1. the "no html" rule. Unfortunately doxygen's \c only sets the next word to a constant width (code) font, and text in \code and \endcode pairs ends up in its own boxed paragraph. To format multiple words inline using a constant width font either requires one \c per word. This is fugly for code such as \c FL_ALT \c | \c (FL_F \c + \c10) which can be handled much more readably within pairs. 2. Fl_Button.H has: Fl_Button(int,int,int,int,const char* =0) Fl_Button.cxx has: Fl_Button(int X, int Y, int W, int H, const char* l) If I place the doxy-comment in Fl_Button.cxx, the .H form is shown in the generated file. Should I then re-include the elided parameter names in the .H file? 3. Fl_Button.html has a description for the ~Fl_Button() descructor, which is an implicit destructor that is not declared in .H or .cxx I intend to leave this out. C++ programmers should grok destructors. OK, back to doxygenating... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
I wrote: > This is fugly for code such as \c FL_ALT \c | \c (FL_F \c + \c10) > which can be handled much more readably within > pairs. Grr! I *knew* that I'd screw it up, whichever way I did it. That sentence should finish "within pairs." Now let's see if that get's through unscathed. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
We should also update copyright dates in the files as we doxygenate. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
> I've just started doxygenating Fl_Button, and have come across some > wrinkles in the code, the guidelines, and doxygen: > [...] 4. I had problems with type() documentation and enumerations because Fl_Widget's type() method isn't overridden in the derived classes. Therefore doxygen doesn't provide a natural place for the "refined" type() and enumeration information that the old documentation/*.html files contain. Does anyone have a suggestion how to handle this? I've added an svn diff patch file to STR2037 for WP3 and would be very grateful if someone with svn write access could merge and commit it for me. Thanks. Cheers Duncan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygenating sources for 1.3 ?
> I've just started doxygenating Fl_Button, and have come across some > wrinkles in the code, the guidelines, and doxygen: > [...] 5. I've just added comments for the fl_color_chooser() functions, and in order to keep them and the general Function Reference information for them together, I created a new doxygen group, and used \ingroup in the three comment blocks. This creates a new Modules page (which may not be what we want) with links to it from the File Members and Fl_Color_Chooser.H pages. It needs a bit more experimentation on my part unless someone already knows how this should be handled. (Maybe we can add it to a functions.dox file that defines a functions group and do that for all of the function documentation?) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)
> I saw that there was an issue with Fluid-generated files requiring an > extra .dox file. Well, there are two solultions to this. > > One can use the "commant block" and just type one (or more) Doxygen > comments into that block. Just start the commant with /** and Fluid > will recognize that and create a correct comment block. It's easier if you use /// at the start of each line in the comment dialog, *but* fluid might move the comment from before the next item, so you may need to be explicit with \class, \fn, etc tags. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6297 - in branches/branch-1.3: FL documentation src
> Author: fabien > Date: 2008-09-18 03:34:22 -0700 (Thu, 18 Sep 2008) > New Revision: 6297 > Log: > Doxygen documentation > + Added new \relatesalso dox command to attach fl_file_chooser(), > fl_color_chooser() to their respective related classes > + corrected copyright date and added lgpl with exceptions in preface > + restored undocumented warnings, changed QUIET mode to yes, this way > we get all warnings/errors and not the long verbose list treated > files. Seems to be a bit faster to run too. Fabien, it's great that you have discovered \relates and \relatesalso. Now the fl_color_chooser() functions appear as Related Functions in the Fl_Color_Chooser class page, but did you realize that fl_color_chooser() has now disappeared from the File Members / Functions listing? Maybe we still need another doxygen command to re-enable that. This \relatesalso, or some other Doxyfile configuration change has also removed the failing "References" and "Referenced by" by links on the fl_color_chooser() modules page, so that must be a Good Thing[tm] ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6297 - in branches/branch-1.3: FL documentation src
> just check that you use doxygen 1.5.6 \relatesalso is a new keyword. That could be it. At work I have CentOS 4.7, with doxygen 1.3.9.1. At home I have Lunar Linux which is a source distro and the Modules page on their web site shows doxygen at 1.5.6, but I'll check later. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6297 - in branches/branch-1.3: FL documentation src
I wrote: > Fabien, it's great that you have discovered \relates and \relatesalso. > > Now the fl_color_chooser() functions appear as Related Functions in the > Fl_Color_Chooser class page, but did you realize that fl_color_chooser() > has now disappeared from the File Members / Functions listing? Maybe we > still need another doxygen command to re-enable that. > > This \relatesalso, or some other Doxyfile configuration change has also > removed the failing "References" and "Referenced by" by links on the > fl_color_chooser() modules page, so that must be a Good Thing[tm] I'm now at home again. I have doxygen-1.5.6 and updated to r6298. Now I can see fl_color_chooser() in the File Members / Functions again. The Fl_Color_Chooser class reference page has a Related Functions section with two fl_color_chooser() entries, neither of which as a return type, but they do work as links. Under the Member Functions section, most/all? of the References and Referenced By linkss to name() fail, whereas the links to class::name() appear to work. In the Fl_Color_Chooser.H page, there are double entries for each of the fl_color_chooser() calls: one with "FL_EXPORT int" and one without. I think that Fabien has shown the way, but we still need to work out the last details. Maybe the reference text for the link needs to be more precis? Maybe it depends on where the link is, inside or outside the class or file? I shall try to look at this later this evening. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6297 - in branches/branch-1.3: FL documentation src
I wrote: > I'm now at home again. I have doxygen-1.5.6 and updated to r6298. > Now I can see fl_color_chooser() in the File Members / Functions. > > The Fl_Color_Chooser class reference page has a Related Functions > section with two fl_color_chooser() entries, neither of which as a > return type, but they do work as links. Under the Member Functions > section, most/all? of the References and Referenced By links to > name() fail, whereas the links to class::name() appear to work. > > In the Fl_Color_Chooser.H page, there are double entries for each of > the fl_color_chooser() calls: one with "FL_EXPORT int" and one without. > > I think that Fabien has shown the way, but we still need to work out > the last details. Maybe the reference text for the link needs to be > more precis? Maybe it depends on where the link is, inside or outside > the class or file? I've been experimenting with this on a much smaller example, and had thought that we were experiencing one of two reported doxygen bugs: you can't add something to more than one group (eg Fl_Color_Chooser class group and the fl_color_chooser function group); and you won't get correct documentation for functions if you \relate it to a class with a member function of the same name. So I had almost given up. But then I've just updated and found that fl_file_chooser() appears to work correctly, so now it's back to hunting down what the difference between the two really is. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6297 - in branches/branch-1.3: FL documentation src
I wrote:
> I've been experimenting with this on a much smaller example, and had
> thought that we were experiencing one of two reported doxygen bugs:
> you can't add something to more than one group (eg Fl_Color_Chooser
> class group and the fl_color_chooser function group); and you won't
> get correct documentation for functions if you \relate it to a class
> with a member function of the same name. So I had almost given up.
>
> But then I've just updated and found that fl_file_chooser() appears
> to work correctly, so now it's back to hunting down what the difference
> between the two really is.
The difference between the new Fl_Color_Chooser and Fl_File_Chooser
pages was that I was trying to migrate the separate function reference
page of the old documentation in addition to doxygen's own function
reference page capabilities. The Fl_File_Chooser pages were limited to
the class and function reference pages provided within doxygen.
So the trick is not to create duplicate entries in a new group, but
to move the function information into the doxygen comments for the
class, and use the navigation links provided. Simply using \relatesalso
as the first doxygen command in the function's comment puts it in the
appropriate place. There is no need to have \defgroup and \ingroup as
well, and indeed they don't work. So, to summarize:
Fl_Color_Chooser.H:
/** \class Fl_Color_Chooser
A widget that you can add to panels.
*/
class Fl_Color_Chooser {
etc
};
extern int fl_color_chooser(...);
Fl_Color_Chooser.cxx:
/** \relatesalso Fl_Color_Chooser
Pops up a color chooser dialog with a Fl_Color_Chooser widget
*/
int fl_color_chooser(...) {}
I shall add this explanation to the development.dox
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6321 - branches/branch-1.3/FL
Fabien, I left the declaration in the header and added a \todo because I only tested by compilation, not an exhaustive search through the code, and wasn't sure whether there was an optional definition in the Windows or Mac specific source files. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6329 - branches/branch-1.3/documentation
> fltk-dev@easysw.com wrote: > > Author: AlbrechtS > > Date: 2008-09-21 03:46:25 -0700 (Sun, 21 Sep 2008) > (1a) The html footer is okay: [ ] > (1b) ... should completely be removed: [ ] > (1c) ... should stay, but modified: [ +1 ] IMHO it would be better without the ugly box around the FLTK, and to be in keeping with other copyright notices in the code should say "FLTK (c) 1998-2008 by Bill Spitzak and others" D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6329 - branches/branch-1.3/documentation
> Added 5 different navigation elements to the bottom of development.dox. > Please check, what you like most (if any). > ... > > (2a) I prefer no Navigation elements: [ ] > (2b) I like most version # (1-5): [ ] [_Back_] [_Up_] [_Next_] _Next_Section_ as the minimum, but I've also sort of got used to the Python document navigation which has an icon level, plus a text level, possibly with truncated titles, e.g. http://docs.python.org/lib/node951.html D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6331 - in branches/branch-1.3: FL src
> doxygen comments for undocumented features of Fl_Color_Browser
> added comment for mode() and enum {M_RGB, ...} but now I can't find
> the latter on the genrated pages. What have I done wrong?
Brain is a bit slow today but I've worked it out - maybe:
Fl_Color_Chooser::mode() is a public method that returns which of
the color chooser faces is currently being displayed and therefore
whether it is showing RGB, hex, byte or HSV values.
However, the anonymous enum { M_RGB, M_HEX, M_BYTE, M_HSV }; appears
in the source file and not the header, which makes me think that they
are not meant to be visible.
So I don't think doxygen can create entries for them. Certainly not
with the \relates and other \command and comments that I've tried.
D.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6335 - branches/branch-1.3/src
> New Revision: 6335 > Log: > added #ifndef FL_DOXYGEN around Flcc_*::methods() to avoid warnings. > > Modified: > branches/branch-1.3/src/Fl_Color_Chooser.cxx Are the Flcc_HueBox, Flcc_ValueBox and Flcc_ValueInput classes really supposed to be part of the FLTK interface? Or are they supposed to be for internal use only? The Fl_Color_Chooser class has private members of the classes above, so these members can't be accessed by the user. But as the code stands, there is nothing to stop the user creating Flcc_* objects and using them in application code. It seems to me that we could add forward declarations for these classes to Fl_Color_Chooser.H, and then change these members to be pointers and then 'new' them in the Fl_Color_Chooser constructor. Then the actual declarations could be moved to Fl_Color_Chooser.cxx where the internal details could be hidden from the user. In this way only the class names would be exposed. Note that Fl_Color_Chooser.cxx already has the hidden ColorChip class that is used by the fl_color_chooser() function. Is it worth adding this as a \todo or an STR ? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
> AlbrechtS and Fabien discussion snipped. I don't think this addresses Albrecht's current need to handle events from outside the current group's boundaries, and maybe it's too much of a change, but for future consideration... Rather than using a Composite (in the Design Patterns sense) would it not be possible to extend the current children idea so that there are "actual" children and "adopted" children. The "actual" children are permanent features within the widget, such as horizonal and vertical scroll bars within a generic scroll widget, or ok and cancel buttons within a generic dialog widget and may be shown or hidden but not removed by the user. The "adopted" children would be the widgets that the user is really interested in, such as the contents of the scroll area or dialog, and could be added and removed as required. This gets round the current situation where some children may be "special" and are expected to be at the start or end of the children() list, or which can't be removed, etc. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
I wrote: > > Rather than using a Composite (in the Design Patterns sense) > > would it not be possible to extend the current children idea > > so that there are "actual" children and "adopted" children. Albrecht replied: > Yes, that's what my implementation does and what I tried to > describe in the other thread. > > [with definitions of "actual" and "adopted" switched] I'm afraid I got lost in the implementation details because I'm not really that familiar with the internals of the different widgets. I just wanted to make the general distinction between "mandatory" and "optional" children in a possible future widget hierarchy. The basic Composite (in the Design Patterns sense) doesn't have this distinction. A component is either a composite with children, or it is a leaf. We really need a modified composite with "fixed" children and "optional" children. Good to know that we are discussing variations on the same theme. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
Fabien Costantini wrote: >> But even then, I reviewed recently the Fl_Group code and fortunately >> for us, the internal attributes to handle children (array_,children_ >> and size_) are all private ; so it could be quite easy to replace >> that 3 attributes internally by only one pointer on a structure >> encapsulating these attributes. When NULL, it would simply means >> that there is no children, when not null the children() would return >> the structure attribute children_. AlbrechtS wrote: > BTW: Fl_Scroll could also be changed to allocate the scrollbars only > when needed, and thus could be much smaller, if there are no scrollbars > (the default when it is created or all widgets fit into it). The next > step would be that every widget can also have scrollbars (if it is a > group, then why not ?). If we set the already existing scrollbar flags > to 0 (no scrollbars), then it would behave like a normal group (or > widget). Maybe I have misunderstood, but this makes me uncomfortable. You want to allow a user to create a widget that initially has no children, but when the users adds X number of children and exceeds the initial width or height of the widget, or a child resizes when a font is changed, you suddenly add one or two scrollbars and the number of children increases and is no longer X. When and where are these scrollbars added? What happens to any index into the children() that the user might have stored? If the user adds more widgets, are they added before or after the scrollbars? I thought you were talking about seperating "fixed" and "optional" children of the same widget? Or is that phase 2? I'm confused. D ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)
> [...], so I decided to add Doxygen support as a feature. Check out
> the current SVN. Opening the function, class, or declaration panel,
> you will find a new field for comments. Just type something and it
> will be placed (hopefully correctly) in the source or header file.
> As a reminder, the first line is repeated in the browser.
>
> The code is mostly untested, so please feel free to comment, and if
> this feature is not liked, I'll be happy to reverse the patch :-)
I've been working through the doxygen warnings so that there are no
undocumented warnings that will hide real problems, and had just got
to Fl_File_Chooser. However, Fl_File_Chooser.[H,cxx] are generated
by fluid, so Fabien has added the doxygen comments to the additional
Fl_File_Chooser2.cxx file. There were warnings about various static
members (e.g add_favorites_label, add_files_label, etc) but try as I
might last night, I couldn't get doxygen to recognise more than one
of them at a time.
I've just experimented with the new, improved fluid and was able to
add the doxygen comments for these static member variables, and then
to generate the html with some test text ("may be changed by the user").
One comment: on my first attempt I typed in the full doxygen comment
with delimiters (i.e. "/** may be changed by the user */" and of course
fluid enclosed this within extra /** and */. So could you change the
tooltip to add "(/** and */ will be added)" or strip /** and */ from
the comment text if needed?
Earlier this summer I experimented with adding doxygen comments using
the normal fluid comment feature, and found that the code generation
doesn't always output the comments in the places where doxygen expects.
This new doxygen comment feature looks much more promising and is a lot
less awkward to use than New {Class, Function, Declaration} followed by
New Comment, and then a lot of F2/F3 to move it in front of where it
was needed.
Cheers
D,
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: FAQ / Build environments / cross compiling
Now that the FLTK-1.3.x documentation is being restructured to use doxygen, would it be worth while to introduce two, or possibly three new chapters or appendices: a. Frequently Asked Questions: Although the web site has an Articles & FAQs page, the interface is a little awkward and it is clear that people don't always search there before they ask questions on the forums/lists. [But, by the same token, many don't read the rest of the documentation either:-(] To avoid the need for continuous update, this section could simply show the questions with links to the existing Articles & FAQs pages. b1.Build environments: One paragraph per build environment or IDE outlining what settings are required for that environment, where libraries should be located, how to handle dynamic/static linking, etc. b2.Cross compiling: [could be a part of build environments] As a minimum, Ian MacArthur's basic guidelines on how to modify the makefiles, comment out fluid, etc to build for another platform. Or are these all subjects that are simply too dynamic for the main documentation and should therefore only be offered via the web pages and forums where people can add comments or discuss them in depth? Are there other subjects that deserve to be covered in more detail in the main documentation? (e.g. Resizing; Raw image data handling) D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FAQ / Build environments /crosscompiling
> > +1 for resizing > > +1 for (raw) image (data) handling > Some howtos already exist for these topics... How easy is it to absorb > them into the doxygen? (I have no knowledge of how doxygen works with > this...) Well that was partly the reason for asking the question. Most of the Articles & FAQs are just plain text or with minimal html, so it shouldn't be too difficult to convert them to doxygen, *BUT* do we really want to do this, or just provide links from the doxygen pages to the relevant Articles & FAQs. The advantage of the Articles & FAQs is that ordinary users can add comments to them, and even submit new ones. Ordinary users won't be able to comment on or update the doxygen user manual pages except indirectly via a forum or an STR. The disadvantage of the Articles & FAQs is that you have to know what you are looking for so that you can search for it, or page through umpteen screens to find it. As a first attempt, I shall look at creating a doxygen page that provides a structured index of links to the existing Articles & FAQs, and then we can review how we proceed from there. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6368 - in branches/branch-1.3: . FL documentation src
Phew! I can't quite work out what Fabien has done, but the number of warning/error messages from doxygen for 1.3.x has suddenly dropped from 197 to just 6, and that's with some changes I have pending. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6368 - in branches/branch-1.3: . FL documentationsrc
I wrote: >> Phew! I can't quite work out what Fabien has done, but the number of >> warning/error messages from doxygen for 1.3.x has suddenly dropped >> from 197 to just 6, and that's with some changes I have pending. > Modified: branches/branch-1.3/documentation/Doxyfile > === > -WARN_IF_UNDOCUMENTED = YES > +WARN_IF_UNDOCUMENTED = NO Aha! I didn't notice that change in the middle of all of the others. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6368 - in branches/branch-1.3: . FL documentationsrc
>>> -WARN_IF_UNDOCUMENTED = YES >>> +WARN_IF_UNDOCUMENTED = NO Fabien wrote: > I switched the undoc off because I believe all important files to > document are done. Also, we should now focus more on other warnings > and on the overall structure of the documentation. Maybe it's just me being picky after using lint, etc. for 25 years, but I always prefer to address, correct or silence the individual warnings rather than disable warnings completely. This has saved me a lot of grief in the past where the really important warning made the difference in solving a problem. So if you don't mind, I'd like to work in the background to clean up the remainder of the warnings. > In particular, > I'd like to get your opinion on the high number of html source > files generated by doxygen as for now. I have to admit that I hadn't thought this far ahead. > I think it is time to think about how to release a maintainable > doxygen doc but IMHO, we have far too many html files to add to > svn for now. Do we really need to save the generated files under svn? > One solution to reduce/limit that amount of files would be to > remove the c++ header source files generated, I'll vote +1 for that. > > Also, I'm not satisfied with the prefixes generated for HTML files > related to classes, functions, enums and other aspects. They are > too long and I prefer the fltk2 documentation HTML files naming. > This said, it seems to me that the naming of HTML files changed in > the 'new' doxygen releases, older doxygen tools were not adding > these ugly prefixes AFAIR. > > I believe we can't afford to let to the user the task of generating > the documentation, as he may not have doxygen, but I may be wrong. > But in the case we should not worry about this, we could neglect the > important amount of generated files. I have to confess that I usually bring up the copy from the FLTK site with the comments and don't usually look at my local copy. What I would suggest is that the generated html is made available via the document links on the site. The full document source would still be available in the tarballs/svn for serious developers who probably would have no problem with downloading and installing doxygen. For casual users, maybe we could look at generating a single file version (doxygen to LaTeX to pdf perhaps?) and to include in the tarball. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3 generated documentation files [was: Re: [Library] r6368- in branches/branch-1.3: . FL documentationsrc]
> For the new doxygen docs, I currently don't know how to generate a > printable (pdf) version, although I know that there are doxygen options > (GENERATE_LATEX and USE_PDFLATEX). I tried them once, but didn't succeed > with my cygwin LaTeX version :-( In principle it's just a question of setting the Doxyfile options: GENERATE_LATEX = YES PDF_HYPERLINKS = YES USE_PDFLATEX = YES running doxygen, and then running 'make' in the latex directory that doxygen creates. However, I've just tried it, and I get an awful lot of LaTeX errors. It still generates a 151 page refman.pdf, but it's clearly incomplete. The chapters seem to be out of order, many of the links don't work, there are no images, and there is no class reference. It could be that there's something missing from my environment, or that I have to tweak some other setting, but we probably would still need to do a lot of other tidying up before we can get this to work. Pity! It would have been a neat solution. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3 generated documentation files [was: Re: [Library] r6368- in branches/branch-1.3: . FL documentationsrc]
> In principle it's just a question of setting the Doxyfile options: > > GENERATE_LATEX = YES > PDF_HYPERLINKS = YES > USE_PDFLATEX = YES > > running doxygen, and then running 'make' in the latex directory > that doxygen creates. > > However, I've just tried it, and I get an awful lot of LaTeX errors. > It still generates a 151 page refman.pdf, but it's clearly incomplete. > The chapters seem to be out of order, many of the links don't work, > there are no images, and there is no class reference. I was experimenting/fighting with this over the weekend and committed two simple changes that make quite a difference: - specify *.dox files in chapter order in the Doxyfile INPUT variable - change the FLTK 1.3.0 Programming Manual entry in the table on the "cover page" to plain old ... The "cover page" table isn't formatted correctly for LaTeX, but I think that we will probably have to change that completely anyway, or have conditional \htmlonly and \latexonly sections. These sections allow you to have 'raw' html or LaTeX commands, rather than try to work out how doxygen will convert either its own commands or the accepted html subset to LaTeX. Doxygen currently generates a LaTeX 'book' document. It's not clear to me whether it is possible to change or customize this. By default this should give us a Table of Contents page for free, so do we really need index.dox and its "cover page" or even the preface.dox listing in the LaTeX / PDF document? I need to brush up on my LaTeX, as it has been about a year since I last used it, only briefly. It should be possible to add the logo and credit/copyright info that is currently on the html "cover page" to the start of the LaTeX / PDF version, but might take me some time. On a negative note, however, I also tried to generate a PDF version of doxygen's own documentation, and that gave lots of errors on my system. I don't remember the details, I just did it out of curiosity. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6392 - in branches/branch-1.3: FL src
> Author: engelsman > Date: 2008-10-07 14:07:12 -0700 (Tue, 07 Oct 2008) > New Revision: 6392 > Log: > doxygen comments for undocumented drawing, clipping and color functions > > added comments in fl_draw.H, fl_color.cxx and fl_rect.cxx so that the > links within drawing.dox can be simplified to allow LaTeX/PDF docs too. The current drawing.dox provides a function reference/tutorial by using a lot of function signatures as HTML H4 headers with embedded anchor names that are linked to from elsewhere. For example, there are full HTML links to Fl_Widget::draw() that point to the named entry on the drawing.dox page. If we follow the doxygen approach, we would simply remove the full HTML links, and just leave 'Fl_Widget::draw()' and let doxygen fill in the details. But then we don't get what we had before. We get a nice link to the Fl_Widget::draw() method on the Fl_Widget class reference page, and not into the drawing.dox page. The same will hold true for a lot of the links within the user manual that currently point in-page rather than to the class reference. How should we proceed? Keep the current in-page links and add explicit links at the end of the paragraph to Reference Page: Fl_Widget::draw()? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6392 - in branches/branch-1.3: FL src
> BTW, while you're looking at this link aspect, it would be nice if we > could also cross-reference the custom pages with the module pages, like: > the Fl event functions discussed in our dox custom page should link to > the event module in Modules because it's more detailed and vice-versa > because it's good for the user to get the essentials of events in the > custom page (which BTW also deals with related enums) while having a > look to the Modules event functions. Yes, this is the main reason why I'm bringing this up. At the moment a lot of the information that should be in the class/function reference pages has been 'commandeered' by the *.dox tutorials pages. There needs to be appropriate reference info on the reference pages, and a suitable amount of description or discussion text in the tutorial pages, with the appropriate links between the two. We now have the reference info in the 'wrong' place, and if we replace the hand crafted HTML anchors in the tutorial pages, the natural doxygen links for Fl_Widget::draw() for example will point from the tutorial pages to the [almost empty] reference pages. So somehow we need to be able to maintain, and also distinguish between, the in-page links in the tutorial pages with the links to the reference. I don't think I'm explaining this very well, so it's probably best to wait for the drawing.dox commit later so you can see what I'm on about. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Links in/to tutorial chapters [was: Re: [Library] r6392 - in branches/branch-1.3:FL src ]
I wrote: >> How should we proceed? Keep the current in-page links and add >> explicit links at the end of the paragraph to Reference Page: >> Fl_Widget::draw()? AlbrectS replied: > I'm not sure, what exactly to do, but I started changing some links > already. My idea was to change the links within the .dox files to > doxygen links by using \section and \subsection commands and set links > to them by using explicit \ref statements. I wrote something about how > to do this in development.dox (short: every (sub)section in one of > these files has a name like filename_(sub)section, with (sub)section > being unique only in that file). We can then remove the HTML anchor > statments. \section will be formatted like H2, \subsection like H3 > (\page like H1). Even though the LaTeX generated contains too many input errors to process completely, I had already wondered whether we would need to do this in order to get a proper table of contents page. At the moment all I get is a ToC header and no ToC because of the errors. This also means we need to decide how we handle the current index.dox page, which is a sort of table of contents, the preface.dox which is also a sort of table of contents, etc. I guess we will need quite a bit of restructuring here. I'd rather not rely on having duplicate \htmlonly and \latexonly sections in the document. Let's let doxygen take the strain and do it all for us. Unfortunately it won't be clear exactly what we can do until we can generate clean LaTeX and then we can start playing around with the document template. > The only problem would be to decide, *what* we want at any given point > in the docs. IMHO, we should use doxygen links to class names and use > the doxygen features everywhere in the source and header files, as if > we wouldn't have the tutorial chapters (unless someone wants to link > to the tutorial chapter explicitly). But we should change the links > to (sub)section links *within* the tutorial chapters. I.e. remove > all (or most) explicit html links from the source and header files > and use \ref statements only to reference to the tutorial chapters, > if really intended at that point. Yes, this is what I think too. Let doxygen go the work for us. Some of the function descriptions in drawing.dox for example should really be moved to the source files, which is what I've started to do, and then the drawing.dox descriptions should be far more general. > Would this work for the LaTeX docs? Yes, I think so, but it's hard to know while the errors interfere with the processing of the complete file. > FWIW: Here is an example from drawing.dox, how we can have both: > > > \section drawing_colors Colors Yes I had noticed these and understood what you were trying to do. > I did this only, because there might have been old links that I > didn't find, but the first (HTML anchor) line could be removed, if > we are sure that there are no more old html links. But I wouldn't > like to do this double work for much more links, i.e. if we decide > to remove all old html references to the html anchor statements, then > I could go on changing the links/sections/subsections within the > tutorial .dox files. I fully agree with trying to use the doxygen infrastructure rather than hand crafting something with HTML and LaTeX commands. Let me complete what I have started with drawing.dox so that I can commit it and we can all see what the problem actually is. Let's hope I can complete it this evening so we can all see the current status and can discuss a way forward. Can you wait 12 hours? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6392 - in branches/branch-1.3: FL src
Duncan said: >> If we follow the doxygen approach, we would simply remove the full >> HTML links, and just leave 'Fl_Widget::draw()' and let doxygen fill >> in the details. But then we don't get what we had before. [...] Fabien replied: > Could you add the pdf/latex doc you get in a ./documentation/pdf > directory in the svn so that we can see this alpha version and help? > [...] > I'm generally open to initiatives that make the doxygen doc. more > doxygen compliant. This said, we are talking about our custom pages > so I need to 'see' what you are talking about to get a more precise > idea before we try to find the best compromise. I fully agree that it would be easier to discuss if you could see the LaTeX/PDF document. However, at this moment there are a lot of places where the HTML used in the *.dox files is a bit more non-standard than doxygen expects, resulting in LaTeX constructs that LaTeX doesn't like. So I haven't got a workable PDF just yet. If I commit my changes to drawing.dox later this evening, you can see the links problem in the generated HTML pages. Can you wait 12 hours? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6397 - branches/branch-1.3/documentation
> Author: engelsman > Date: 2008-10-08 09:53:41 -0700 (Wed, 08 Oct 2008) > New Revision: 6397 > Log: > started simplification of HTML in drawing.dox to allow LaTeX generation > > This is very much a work in progress, with some wierd formatting of H3, > H4 and A tags until they are replaced by doxygen or reworked in html. > The two big questions to come out of this simplification are: > 1. if the function descriptions are moved to the source code and the >reference pages, how much does the tutorial page need to be reworked >and how much information should be duplicated; > 2. how do we distinguish between the doxygen Fl_Widget::draw() links >to the reference page, and the in-page links in the tutorial >Fl_Widget::draw() >This second point is illustrated by the first two bullet points > which are identical text but the links point to different places. OK, managed to get something together in less than 12 hours :-) If you generate the doxygen/HTML and go to the 'Drawing Things in FLTK' chapter, you can see that the Fl_Widget::draw() links in the first two bullets look different, and they point to different places. I propose that we start to add in \section, \subsection and \ref calls instead of the H3 and H4 with named Anchors. I also suggest that we reserve the Fl_Widget::draw() type links for doxygen, and put in \ref calls to the \section and \subsection names. In other words, in-page links will be words or phrases and not code entities. I was also toying with the idea of using \par with a paragraph tag matching the function signature and indented explanations, but I had not got that far with my experimentation yet so I don't know what it will look like or how much work it will be. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Section names [Re: [Library] r6399 - branches/branch-1.3/documentation]
> Good work! > Looks pretty good, the indentation with \par is nice :-) I have to confess that I wasn't sure whether it would work, and whether it could be applied consistently over multiple paragraphs, but it was only after the final round of changes that it really came together. Although \code and \note blocks don't quite fit. > If this works with LaTeX / pdf, then I would vote for this. I've disabled the LATEX generation because it just takes too long to regenerate and verify the results of any experimentation. I shall re-enable it this evening, and submit a couple of new files for the LaTeX document template and title page logo. My limited LaTeX skills are pretty rusty, and I was confused to see a LaTeX code snippet that appeared to pull in a png image file. The doxygen manual implies that the LaTeX side can only handle eps images, but if we can avoid having to convert, and maintain, all the images into two formats, that would save us a lot of work. > I'm very short in time today, therefore only one remark: The section > names are global (you can refer to them from everywhere), thus we > should use names that can easily be made unique. I proposed and > started with using the filename part (without .dox) and an underline > as a prefix to make things unique. I agree. See below... > Before you (or anybody else) start/s more work, we should decide how > to name the sections, because otherwise, we would get difficulties > to get them unique over all files. > > > - > > -Line Dashes and Thickness > > - > > + > > +\subsection ssect_Lines Line Dashes and Thickness > > In this case, this could be drawing_ssect_Lines, but IMHO "ssect_" > would be redundant and could be omitted, or replaced by the section > name. I agree that, ultimately, the "ssect_" part is redundant, but in the meantime I wanted to be sure that I have a unique name without having to search through the dox every time. The goal is to get rid of the html named anchors and links to them, and then we can tidy up again. Note: I think that there is already a link conflict. The fl_frame() in the text is not converted into a link to the reference page, but fl_frame2() is, and I think this has to do with the existing explicit named "fl_frame" anchor. I only spotted this at the last moment and have not had chance to verify yet. > A short rule could be: If you convert the HTML anchors to new doxygen > \section, \subsection, or \subsubsection, use the filename part + an > underscore + the previous anchor name, and we should be unique, and > transforming the referring links would be easy. > > Does this sound reasonable? Sounds good to me, as part of the next phase. > One more to html link formatting: *if* we want to make the html links > *look* like doxygen links, we could add class="el" to the html code. > I did this in a few cases in index.dox, and in the navigation links, > where I had to use html. I think that as long as we are consistent in using 'code()' to link to the reference pages, and 'phrase' to link to the tutorial pages, we probably won't need to tweak the appearance of the links. > And the last: Instead of \ref you can also use \link Any Link > Text \endlink, if you want to "rename" the link, .e.g. > \link ssect_Complex more info here \endlink That's a good trick to know. I had missed that one. Cheers D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6411 - branches/branch-1.3/documentation
> Author: engelsman > Date: 2008-10-11 07:49:33 -0700 (Sat, 11 Oct 2008) > New Revision: 6411 > Log: > more html to doxygen conversion for examples.dox I have now worked through all of the *.dox files[*] and converted the problematic multi-line and multi-anchored headers from html to plain old doxygen. I've changed many UL/LI and OL/LI to use \li or -# tags. And I've simplified other bits. It's still not complete, but it is now possible to generate LaTeX and hence PDF for all of the *.dox parts. Still not possible to generate the complete documentation with doxygen class and function references, table of contents, etc. because there are still problems that need tracking down in the source documentation. So, what's left to do? Well quite a lot! A lot of the tutorial in *.dox contains Fl_Widget::draw() etc inside .. or .. and this obscures the doxygen links. And there are a lot of functions that still need to be documented, e.g. the ones currently in the chapter on Drawing Things in FLTK. As the source is documented the plain text in the tutorial pages should blossom into true doxygen links. We also need to convert the HTML links to doxygen \link and \ref commands. Albrecht: your \link tag alternateText \endlink suggestion does work. I used it for the link to the fluid tutorial in examples.dox. Cheers Duncan [*] except license.dox because I don't know whether this is original text which needs to be maintained "as is" or whether I can convert it to doxygen too ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re: [Library] r6411 - ...]
Albrecht wrote: > But I can't generate the pdf docs because of error messages when > running make in the doc/latex directory. I'll append a shortened > log to this message, maybe you can help? Obviously there are some > missing files, but I don't know ... I'm using a current cygwin > LaTeX (tetex) installation, FWIW. I guess I'm lucky that the LaTeX package that I have installed on my Lunar Linux box at home seems to have more of the optional stuff installed than the default cygwin package. You can probably find the missing macro packages on CTAN if the aren't available directly in cygwin. Don't remember how you go about installing them though off the top of my head. We can also look at changing the default LaTeX template if needed. > ! LaTeX Error: File `a4wide.sty' not found. http://www.ctan.org/tex-archive/help/Catalogue/entries/a4wide.html This package increases the width of the typeset area of an a4 page. > ! LaTeX Error: File `fancyhdr.sty' not found. http://www.ctan.org/tex-archive/macros/latex/contrib/fancyhdr/ Extensive control of page headers and footers in LaTeX2e > ! LaTeX Error: File `float.sty' not found. http://www.ctan.org/tex-archive/macros/latex/contrib/float/ Improved interface for floating objects > ! LaTeX Error: File `times.sty' not found. http:// ? Sets Times as the default font to match PostScript > ! LaTeX Error: File `ifpdf.sty' not found. http:// ? Conditional macros for generating PDF > ! LaTeX Error: File `hyperref.sty' not found. http://www.ctan.org/tex-archive/macros/latex/contrib/hyperref/ Extensive support for hypertext in LaTeX I can maybe check cygwin on my son's Windows box this evening. Cheers D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re: [Library]r6411 - ...]
> I guess I'm lucky that the LaTeX package that I have installed on > my Lunar Linux box at home seems to have more of the optional stuff > installed than the default cygwin package. > .. > I can maybe check cygwin on my son's Windows box this evening. Just installed cygwin from scratch on WinXP and selected the following in total after a couple of attempts: devel: autoconf, automake, gcc, bison, flex, make, doxygen, subversion doc: tetex* checked out fltk-1.3.x, ran doxygen in documentation, then make in doc/latex, hit 'x' at the first error, and could acroread refman.pdf up to page 205. So it looks like you just need a few more of the tetex packages installed. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re:[Library]r6411- ...]
> > Also - the file documentation, all the entries begin > > "/Users/fab/Devl/fltk13/". Is there some way we can reduce that to a > > generic path for the docs? FULL_PATH_NAMES = NO in Doxyfile perhaps? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re:[Library]r6411- ...]
> It seems there's a bug in doxygen because: > changing FULL_PATH_NAMES will only remove the full path names in the > pdf content and html files but not in the pdf TOC that we use in the > acrobat reader... If FULL_PATH_NAMES is left as YES, then there's STRIP_FROM_PATH to give a prefix that can be removed, but we will all have to customize it for our own setup unless we all agree to develop under /home/fltk-1.3 or something. There's also STRIP_FROM_INC_PATH to reduce #include lines in the docs. I haven't played with either of these. BTW, any reason for changing OUTPUT_DIRECTORY from ../doc to . ? D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LaTeX and pdf generation [Re:[Library]r6411- ...]
> but the weird thing with this tex to pdf gen is that you make multiple > passes up to 5, to get the toc in the original doxygen makefile ! Ah! Yes, LaTeX requires multiple passes over the .tex and .aux files to really work out cross referencing and page numbering. I forgot to say because I assumed you already knew that. There's also a flag somewhere to say 'stop after first LaTeX error' instead of waiting for user input. Don't remember where I saw it though. That might also be helpful for generating the docs without intervention. I shall investigate your changes tomorrow evening. D. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
