Re: [fltk.development] [RFE] STR #2076:Patchforfl_text_extentsmechanism in fltk-1.3.x

Indeed - I can write the words, and generate a screenshot, but have no idea how to get them into the docs... Writing the doxygen docs is not that difficult. There are enough examples, and there are some hints in the developer section of the docs. In this special case however I'm

Re: [fltk.development] [RFE] STR #2076:Patchforfl_text_extentsmechanismin fltk-1.3.x

On 11.02.2009, at 09:39, MacArthur, Ian (SELEX GALILEO, UK) wrote: ..so that one can easily just run through all the tests quickly just by clicking the 'Next Test' button, and it just selects the next item in the browser. Or just clicking in the browser will run that

Re: [fltk.development] RFC: STR #1306: automated safe widget deletion inside the library

Albrecht Schlosser wrote: ... P.S.: I'm wondering why the discussion of STR #1306 doesn't show up in fltk.development... Once assigned, bug updates don't show up on fltk.bugs or fltk.development until they are closed. -- __

Re: [fltk.development] [RFE] STR#2076:Patchforfl_text_extentsmechanismin fltk-1.3.x

matthiasm wrote: When I ported FLTK to the Mac, I started exactly that. The source code is still in test/unittest.cxx. The goal was to be able to verify rendering on every available platform. I wanted to render markers first and then overwrite them with whatever drawing function I was

[fltk.development] Votes please: Should STR updates always be mirrored to fltk.bugs or fltk.development ?

A question to all developers: (1) History / current state: Michael Sweet wrote: Albrecht Schlosser wrote: ... P.S.: I'm wondering why the discussion of STR #1306 doesn't show up in fltk.development... Once assigned, bug updates don't show up on fltk.bugs or fltk.development until

Re: [fltk.development] [RFE]STR#2076:Patchforfl_text_extentsmechanismin fltk-1.3.x

MacArthur, Ian (SELEX GALILEO, UK) wrote: I think the browser idea might be a bit clearer and easier to navigate, so that it's always clear what all the tests are by name, and both keyboard or mouse could navigate the tests consistently. (The browser would simply remain

Re: [fltk.development] RFC: STR #1306: automated safe widgetdeletion inside the library

If it's going to be public, I'd suggest avoiding Smart Pointer, because that phrase historically suggests something a bit different, namely smart_pointer p = new Thing; // this will be deleted automatically Yup, fair point... SELEX Sensors and Airborne Systems Limited Registered

Re: [fltk.development] Votes please: Should STR updates always be mirrored to fltk.bugs or fltk.development ?

(4) My vote: +1 for always mirroring STR updates to the newsgroups for consistency. +1, traffic would be ok http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev