[fltk.development] FLTK2.x Styles..
I'm moving a chunk of the Subject: Re: Styles thread
over here from fltk.general that seemed more relevant
to fltk.development, to prevent dev chatter on the general group.
mal content was trying to get Styles working, and I thought I'd
give it a shot just to start to learn about 2.x by dabbling.
Styles doesn't have any example code that I could find, so after
some help from Mikko, we cobbled together a working example that
shows how to change the default fonts/colors for windows and buttons.
The example is shown in Mikko's 04/01/07 06:39 posting in the
Re: Styles thread on fltk.general, which makes use of the
(WidgetType)::default_style
Some things that seemed odd, though. To set the NamedStyle's
parent_ seemed to involve:
snip
int main(..) {
// Set correct parents for styles
G_window_style.parent_ = Window::default_style; // --
G_button_style.parent_ = Button::default_style; // --
snip
Seems a little scary to be doing direct variable assignments
to variables (esp. with underbars). Shouldn't there instead
be something like a .parent() or .setparent() method?
Looking to the code to see if it might have just been undocumented,
I noticed /all/ the variables in Style are in fact public, with
the comment:
// Everything is public for various back-compatability hacks
I figured with Style and FLTK2 being fairly new, there wouldn't
already be legacy to worry about.. shouldn't that all be private?
Also, seems like it would be handy if maybe the NamedStyle
constructor could include a way to set the parent on init, eg:
snip
int main() {
NamedStyle window_style(MyWindowStyle, Window::default_style);
snip
..or is there a reason something like that would be bad?
Finally, is there a way to use styles to affect *all* widget
defaults? ie. if you want to change the default font for all
widgets? It seems as if one might have to make one style instance
for each kind of widget an app uses?
I know Styles are new, maybe I'm 'too soon' to use them,
or more likely, I'm probably missing something by not
knowing where to find good example code.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Global font size offset
matthiasm wrote: On May 1, 2007, at 1:30 AM, Greg Ercolano wrote: There's probably some problems with this, eg. increasing the font sizes won't make menubars, buttons, and input prompts thicker to accommodate larger fonts. But in spite of that, it still might be useful..? I have been thinking about this a lot ever since I got my new laptop. Fluid it not usable due to it micro-fonting in the editor windows. Ya, I first noticed the problem on a modern notebook too. Most of my customers are CG folks with big screens at work, and not using notebooks, so it never was reported to me. Only recently people are starting to bring in hires notebooks to work, and are noticing the problem. On the other hand, if you ever tried to option-cmd-+ on a new generation Mac, you can smoothly scale the whole screen content, which looks bearable. In this case, the window is rendered as always and then smoothly scaled when copied to the desktop. The overall appearance of the application remains the same, but all lines and fonts become fuzzy and washed out. Firefox/linux makes good use of CTRL+ and CTRL- for zooming html content. It also has the min/max fontsize stuff in the Preferences. But then in HTML-land, tables and whatnot automatically resize based on the text content, so it's built well for that. FLTK wasn't really planned for that, so I could see where that might not fly well, as changing a label's font size won't make the widget larger to accommodate it, icons won't scale, etc. In conclusion, what I could imagine working would be an Application scale setting that is applied to all widget coordinates and font sizes, maybe even images, all free-hand drawings (excluding boxtypes), and all mouse coordinates (we would also need to scale screen sizes down..). That way, many applications would look decent (including Fluid). Sounds cool, but sounds like a big project. Maybe taking a smaller bite of just applying a scale to fonts would be good for the short term. I did some tests loading my app in fluid, and after selecting all widgets, interactively slewing the font label sizes around in the Widget Properties to see how much I can get away with, before the fonts started crashing into each other. I found I can bring the fonts up +3 or 4 points, which is enough to make a difference for someone having trouble reading the text. I can also make some small tweaks to my layouts to make that range be larger by making buttons slightly larger. I'm tempted to just hack a few globals into FLTK and apply them to fl_font() and/or fl_draw() just to see what happens. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Some testings, please
gga wrote: Greg Ercolano wrote: OK, found some time this morning to bring up my NT box, and my 2K machine with VS7.0 (haven't seen either of their desktops in a while) and on the 2K machine, tried to build fltk2.0 from svn. This because Rectangle is used without fltk:: in front of it in the UpBox function definition (all other uses are ok), which makes it conflict with Windows' own Rectangle struct. When someone gives the word that svn has been tweaked, and I'll retry.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Compiling FLTK
Chuckk Hubbard wrote: Any idea why the installer might want libfltk.so.1.1, or where I can find it? ..what Maarten de Boer said earlier in this thread: did you configure with --enable-shared ? The libs you have currently are static libs. That only works if your apps expect to build referencing static libs. .so's are shared libraries, .lib's are static libraries. http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html You have to build fltk specifically for one or the other. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Form support (HTML 2.0) in HelpDialog/HelpView?
Joe wrote: Dear Dev team, First of, thanks a bunch on excellent inputs and feedback on this forum! Actually, this Q is a followup to my earlier Q on Gecko; Can anyone confirm that Forms (including radio etc) of HTML 2.0 are not supported by HelpView/HelpDialog of FLTK 2.0? I tried, but I dont get any buttons displayed. Just wanted to confirm... BTW a secondary Q: How to make tables in HelpView/dialog look better? right now, they are displayed with table lines going across the text (similar to striking off a sentence/text) FLTK's html widget only supports a very limited subset of HTML. Forms, CSS, DHTML, etc. are all outside it's current goals. Looking at the Fl_Help_View code in 1.1.x, the only tags it currently appears to support are: ** FONT RELATED ** H1 H2 .. H5 H6 B, I, EM, CODE, TT, KBD, STRONG, VAR FONT FACE|COLOR|SIZE ** MEDIA/LINK RELATED ** IMG [SRC|WIDTH|HEIGHT] A [NAME|HREF] ** HTML FORMATTING/MISC ** HEAD, TITLE, BODY [BGCOLOR|TEXT|LINK] BR, CENTER, P UL, OL, DL, LI, DD, DT, HR, PRE, TABLE [ALIGN CENTER|RIGHT|LEFT] TR, TD, TH, COLSPAN, WIDTH I'm not sure if that's a complete list, but it was built just perusing the 1.1.x Fl_Help_View.cxx code. I believe these limitations are not documented because the widget has been constantly in progress, though now that it is closing in on its design goals, the supported subsets probably should now be documented. Among the url types not supported: http:, https:, ftp:, ipp:, mailto:, news: ..mainly because these would all depend on a cross platform TCP library of some kind, currently outside the scope of FLTK's goals to being 'fast and light'. If you want more support from inside your FLTK app, fire off the user's HTML browser as a separate process to open the link in question. There's some code examples somewhere in the newsgroup archive.. can't remember where. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Form support (HTML 2.0) in HelpDialog/HelpView?
Greg Ercolano wrote: If you want more support from inside your FLTK app, fire off the user's HTML browser as a separate process to open the link in question. There's some code examples somewhere in the newsgroup archive.. can't remember where. Oh right, there's the fl_open_uri() function (in 1.1.8 only), but you can code it yourself. See also: http://fltk.org/newsgroups.php?gfltk.general+v:20105 http://www.magma.ca/~dzimmer/code/fl_open_url.cxx ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #1758: Add methods to Fl_Menu_ to help dynamically manipulate menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1758 Version: 2.0-feature It would be good if some of the functionalities were added to the Fl_Menu_ class: o Clear all items in a named submenu, eg. int clear_submenu(File/Save As/Recent); ..returns -1 if not found. o Find item by index. Similar to the current find_item(), but returns an index instead of an item pointer, eg. int find_index(Edit/Copy); ..returns -1 if not found. Regarding clear_submenu(), the code on this page for ClearItemsBelow() might be of good reference: http://www.seriss.com/people/erco/fltk/#Fl_Menu_Bar Link: http://www.fltk.org/str.php?L1758 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] freetype+fltk
flying wrote: about freetype+fltk how to do thank you Questions like this should be in fltk.general. I'll follow up with the answer there, same subject. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk2 FillSlider.cxx missing
Craig Barnes wrote:
I want a filled slider i.e a progress bar,
and although there is a FillSlider.h there is no corresponding FillSlider.cxx.
Does it need one?
Any thoughts or work around suggestions.
I think you just #include the file.
You don't have to worry about the cxx.
I just built the following.. seems to work fine.
#include fltk/run.h
#include fltk/Window.h
#include fltk/FillSlider.h
int main() {
fltk::Window win(720,486);
win.begin();
fltk::FillSlider prog(10,10,200,25, Progress);
prog.value(0.75);
win.end();
win.show();
return(fltk::run());
}
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Browser mod for ANSI
Greg Ercolano wrote: I have a neat little patch to Fl_Browser to support ANSI codes [..] Should I make an STR for 1.x, or just post the patch here? I forgot to ask, should I patch against Ian's utf8 or svn 1.1.x? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Browser mod for ANSI
matthiasm wrote: And even if it ASCII only, I would very much like to take a look at it. While making a test program (and not just using it in my app), I just noticed I need to modify item_width() to properly calculate widths for strings containing ANSI, so I'll need some time to figure that one out. Meanwhile, here's a screenshot of the test program: http://seriss.com/people/erco/fltk/tmp/Fl_Browser-ansi-test.png ..and here's a 'diff -Naur' against 1.1.x svn current for Fl_Browser.cxx that adds my ANSI stuff (without the item_width() fix) and a separate AnsiMode.H file that it includes: http://seriss.com/people/erco/fltk/tmp/ansi-patch-03-07-2008.txt http://seriss.com/people/erco/fltk/tmp/AnsiMode.H Let me know if anything seems odd. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Double posts
I always wondered what caused the double posts we sometimes see. Apparently it just happened to me.. the cause seemed to be, in my case, hitting 'Reply All' to Matthais' message, and getting two entries in the TO: field: To: Mirror of fltk.development Newsgroup fltk-dev@easysw.com Newsgroup: fltk.development ..so apparently one post goes through the email interface, the other goes through the newgroup interface. Huh. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1926: popup menues dont add by their parents x/y
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1926 Version: 1.3-feature Using the popup code here: http://seriss.com/people/erco/fltk/#PopupMenu ..I can't replicate this either under fedora3. Can't replicate with the 'test/menubar' program either. Would need to see your code, or refer us to the code you used for an example. Also, it's possible this is platform specific, so let us know your platform as well (this bug was logged to all platforms, so we don't know this info so far) Link: http://www.fltk.org/str.php?L1926 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Still won't link in VS2005
1main.obj : warning LNK4217: locally defined symbol [EMAIL PROTECTED]@@SAHXZ (public: static int __cdecl Fl::run(void)) imported in function _main Just focusing on that one error, sounds like it might be a compiler/linker flag issue, eg. DLL vs Static compile. You showed the linker flags, but what were the /compiler/ flags? Then check: how do your flags (compiler and linker) compare to the flags FLTK built its own demos with? Try rebuilding one of the FLTK test programs, and compare the compile/link flags from the build log to your first attempt build log. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [OT] iphone sdk
iPhone SDK development stuff looks kinda cool: http://developer.apple.com/iphone/ You can use your free apple developer's login to download the SDK (free!) and all the how-to videos. Was watching some of the 'getting started' videos. Seems that all the usual unixy stuff is available, including BSD sockets, threads. Noteworthy: Quartz is accessible, which /might/ mean FLTK could possibly be coerced to run on it, not sure. Apparently the SDK includes an iphone emulator so you can test your program even w/out an iphone. The iphone apps are apparently regular Mac 'app bundles'. I have no further details, was just musing about possibly noodling with it. They've certainly taken great efforts to making numerous developer videos which is kinda neat. I still hope to never have to learn Cocoa.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unresolved external symbol___WSAFDIsSetreferenced in function public: static void__cdeclFl::add_fd........
MacArthur, Ian (SELEX GALILEO, UK) wrote: error.. unresolved external symbol ___WSAFDIsSet referenced in .. Fl::add_fd(..) error.. unresolved external symbol _select referenced in fl_wait(..) WSAFDIsSet is a M$ symbol, so must come from one of the platform libraries (not from fltk). I don't know winCE, but on a regular machine ws2_32.lib (for winsock2) or wsock32.lib (for winsock1) would be the right place to look. Right; WSA == Windows Socket Library. Possibly CE doesn't support sockets, in which case you probably want to #ifdef out any WSA* and select() calls in the add_fd() and fl_wait() FLTK code. I think I talked about this in a different thread recently (fltk.general, Subject: Building FLTK without WSOCK32.LIB) which asked if FLTK could be built without the socket libraries. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
Brian wrote: Also arguing that replacing char* by std::string and so on would make FLTK2 more bug free is a complete... Using std::string *would* make fltk2 more bug free. But it would be a mistake. Maybe it could be a compile time option to enable std::string() methods. This way one can compile fltk with the option off if they don't plan on using std stuff in their apps. Supporting it would at least allow strings to be changed at runtime without having to call label() again to change it. (Just invoke a redraw()) This would be handy for internationalization.. just changing the label's string would be all that's needed, no need to have to track down the widget and update its label(). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
[EMAIL PROTECTED] wrote: I'm just sort of thinking out loud here... I do know that on more than one occasion I've wished it were possible to have more than one label on a widget. Hmm, but wouldn't it be better in such a case to create a custom widget, or just an Fl_Group with two Fl_Widgets in it? Then you have more flexible control over label placement, as opposed to having a larger, more complex Fl_Widget which would affect everyone's apps.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6175 -branches/branch-1.3
Fabien Costantini wrote: Knowing you mike, there must be a good reason for that statement, but I recognize I don't understand that one. Seeing this I was intrigued, and posted a short 'my 2 cents' in STR 2028. The patch for the $(basename) doesn't fly on an SGI with the stock bourne shell. IIRC, the $(command) stuff, nice as it is, is I think a relatively newish bash thing, not old style bourne. The V2 patch Alvin submitted seems more portable, using \ instead of '. From the STR: *** Fedora 3 /bin/sh *** sh-3.00# compile=/some/path/Foo Bar.cxx sh-3.00# prog=$(basename $compile .cxx) sh-3.00# echo $prog Foo Bar-- GOOD *** IRIX 6.5 /bin/sh *** # compile=/some/path/Foo Bar.cxx # prog=$(basename $compile .cxx) # echo $prog $(basename /some/path/Foo Bar.cxx .cxx)-- BLARG The V2 patch Alvin posted seems to work on both platforms, eg: # prog=`basename \$compile\ .cxx` # echo $prog Foo Bar ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6175 -branches/branch-1.3
MacArthur, Ian (SELEX GALILEO, UK) wrote: According to Ian, it should also work on IRIX platforms and You probably mean Greg here, I think? I haven't seen an Irix machine in years! Yeah, sometimes I turn it on to heat up the room, or to run soundeditor to record stuff off the radio.. As '' constructs won't work as expected on native bash based platforms, which seems to be a conformity bug(as the first line force the script to be parsed with sh, so mike construction should have worked), I will apply and test the V2 modification (use of \ instead of ', no $(cmd) construction but `cmd` instead.) FWIW, and just to be clear, the original '$compile' (pre-patch) didn't work on Irix either: # compile=/some/path/Foo Bar.cxx # prog=`basename '$compile' .cxx` # echo $prog $compile ..and Mike's example for the Mac gives the same results on Irix: # foo=bar # echo $foo bar # echo $foo bar # echo '$foo' 'bar' # uname IRIX64 I get those results on Fedora3/bash as well.. so those three platforms are all in agreement on that. . ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r6175 -branches/branch-1.3
MacArthur, Ian (SELEX GALILEO, UK) wrote: Yeah, sometimes I turn it on to heat up the room, or to run soundeditor to record stuff off the radio.. You presumably have to record the radio because you can't hear it over the noise of the fans? Yes, it sounds like a vacuum cleaner.. I think of that as an old school power saving feature where its so noisey, you don't want to leave it on for long.. Does the proposed alternate (i.e. \ etc...) play nice? Yes, as described in my comment in the STR, the \ stuff works fine on Irix. Just checked osx 10.4.11, fedora3, irix6.5, Ubuntu 7.04 all fine on those too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFE: Fl_Group::resize() additional methods for fltk 1.x
Looking at the code for Fl_Group::resize(), it tells children
to resize before updating its own size.
This is a problem if the children's resize() code wants to know
what the parent's new size is going to be.
Assuming there's a good reason Fl_Group doesn't set its own XYWH
values before calling the children, would it be possible for
Fl_Group::resize() to record the XYWH it is being resized to
so children's resize() methods can access this if they need it?
For example, a new public method and private data along the lines of:
--- snip
+int* Fl_Group::resize_xywh() const { return(resize_xywh); } //
public
void Fl_Group::resize(int X, int Y, int W, int H) {
+ resize_xywh[0] = X; resize_xywh[1] = Y;
+ resize_xywh[2] = W; resize_xywh[3] = H;
if (!resizable() || W==w() H==h() ) {
[..]
--- snip
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFE: Fl_Group::resize() additional methods for fltk 1.x
Albrecht Schlosser wrote: Greg Ercolano wrote: Looking at the code for Fl_Group::resize(), it tells children to resize before updating its own size. This is a problem if the children's resize() code wants to know what the parent's new size is going to be. Assuming there's a good reason Fl_Group doesn't set its own XYWH values before calling the children, ... I'm not _absolutely_ sure about this, but I'd consider this a bug (calling Fl_widget::resize() after calling resize() for the children), It might be. If so, then just fixing the bug would be the easy solution. Would your code work, if the sizes would be changed before resizing the children? Did you try? I didn't try changing the fltk code around.. I assumed there's a reason the group's resize() happens /after/ the children are resize()ed. But I imagine if I did change it, it would help my situation, but maybe might break Fl_Group's resizing somehow.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC Should CMake be responsible for msvisualtargets generation
MacArthur, Ian (SELEX GALILEO, UK) wrote: I'd be willing to take a stab at making a Makefile.WINDOWS for fltk for the MS compilers if that would be entertaining. Brave man! One thing - can you call it Makefile.MS (or similar) please, as I already have windows makefiles, for non -MS tools... I actually spent an hour on this, and got just about all the fltk libs to build under VS .Net 7.0 with gmake.exe with a simple/small Makefile. Here's a work-in-progress tar file that I have so far: http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles.tar.gz Contents: buildtools.windows/gmake.exe src/Makefile.MICROSOFT src/gmake-fltk-include src/gmake-vsnet-include src/gmake.bat If you have vs7, you should be able to just extract that into the top level fltk-1.3.x directory, and then run it from a VS .NET console as: cd src gmake clean gmake This should build: ..\lib\fltk.lib ..\lib\fltkimages.lib ..\lib\fltkforms.lib ..\lib\fltkgl.lib I'm still working on the other lib targets and haven't gotten to the test dir yet. Once I have this working, I'll try to make it autodetect the compiler, and get it to work with VS Express next. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Starting a new thread here for building fltk with gmake. I find it just too satisfying to build FLTK on Windows using Microsoft's own compiler *without* the IDE. New tar file that can be extracted tot he fltk 1.3.x directory as: http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles-0.20.tar.gz Contents: buildtools.windows/gmake.exe jpeg/Makefile.MICROSOFT jpeg/gmake-vsnet-include jpeg/gmake.bat png/Makefile.MICROSOFT png/gmake-vsnet-include png/gmake.bat src/Makefile.MICROSOFT src/gmake-fltk-include src/gmake-vsnet-include src/gmake.bat zlib/Makefile.MICROSOFT zlib/gmake-vsnet-include zlib/gmake.bat gmake.bat With this, you can just type 'gmake' in the top level directory and it builds all the lib/* files, including fltkjpeg, fltkpng, fltkz, etc. 'gmake clean' at the top cleans all the objs and libs. Just need to add the test program builds.. maybe tomorrow. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Tim Channon wrote: Fabien Costantini wrote: I find it just too satisfying to build FLTK on Windows using Microsoft's own compiler *without* the IDE. My 2 cents comments on that: Did you notice how many files are needed to be _added_ to the distrib and in subdirs of the distrib, we already have unix makefiles, watcom makefiles and now it would add these ones ? I would like to avoid if possible to add more makefiles to the fltk distrib as much as possible. Also, though it is a indeed a brave intiative to achieve that makefiles (and how fast you did it is somewhat spectacular ;-) , it only addresses the release/static lib mode. I guess it would add more trouble if we try to achieve a complete impl. (debug, dll, win64?) Still, I would dream to have such a feature if it could merge _economically_ in a way to the existing Makefiles (at least partially and especially the ones listing the files to be compiled) that we already use for *nix platforms with autoconf/configure/make tools. Just a suggestion, don't know if it is possible. cmake can target nmake. Isn't that VC command line? When I last researched it (years ago) I found nmake to be really limited in its abilities as compared to eg. gmake. Features for #if'ing and slurping up the output of external shell commands into variables that are really useful/essential. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Fabien Costantini wrote: I find it just too satisfying to build FLTK on Windows using Microsoft's own compiler *without* the IDE. My 2 cents comments on that: Did you notice how many files are needed to be _added_ to the distrib A lot less files than the number of project files needed to build in the IDE, I can tell you that ;) For dev purposes, I put gmake.bat in each dir so I could type 'gmake' in each dir to test them separately. Could be avoided if one is mostly running 'gmake' at the top level dir. Also, during development, I've been putting separate gmake-vcnet-include files in each dir (which defines the CXX/CXXFLAGS values) just in case the flags are different for each dir (ie. jpeg flags slightly different than png or fltk src flags) So far the flags seem similar, so they could probably be a single file the others source from. I'm not optimizing yet though, until I get the big picture. and in subdirs of the distrib, we already have unix makefiles, watcom makefiles and now it would add these ones ? I would like to avoid if possible to add more makefiles to the fltk distrib as much as possible. I'd agree. But the files could live in the build directory, and could get pulled out only if someone runs gmake in the top level dir for the first time, so that the files aren't put into the dirs until needed. But there is no comparison to the number of files needed for the IDE. I guess it would add more trouble if we try to achieve a complete impl. (debug, dll, win64?) I think these can be config flags. In one of my earlier posts I was suggesting: gmake configure ..which could have text prompts for debug/release, verbose/silent, static/dll, eg: snip C:\fltk gmake configure *** LIBRARY RELEASE OPTIONS *** R)elease D)ebug Which? [R] r *** BUILD VERBOSITY *** V)erbose S)ilent Which? [S]: s --- OK, you can now run 'gmake clean gmake' to rebuild the library. C:\fltk gmake Compiling Fl_win.cxx... Compiling Fl_Adjuster.cxx... .. snip ..and this could also be CLI oriented, eg: gmake configure RELEASE=DEBUG VERBOSE=SILENT I think most people using the ide only every change the debug/release mode. Is there actually an easy way to change anything else..? Still, I would dream to have such a feature if it could merge _economically_ in a way to the existing Makefiles (at least partially and especially the ones listing the files to be compiled) that we already use for *nix platforms with autoconf/configure/make tools. It could be done where they're merged. But I think initially, until we identify all the things different, it would be better to keep them separate. Certainly I could see the huge lists of .obj vs. .o files to be in a single separate file that gets converted during the initial config stage, then include'ed by the makefile. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC Should CMake be responsible for msvisualtargetsgeneration
Fabien Costantini wrote: Fabien Costantini wrote: The VS Express compiler flags are very different from the other VS compilers. Are the VS build files smart enough to recognize compiler differences? Could you be more specific ? I meant all the new manifest flags needed for Express. If there was one set of project files, they'd have to smart enough to know that if loaded under express, they'd need to add the newer flags. I don't know much about the IDE config files, but I guess they must have the smarts to be able to look at the compiler that's building them, eg. #if EXPRESS use manifest flags, etc. IIRC, the 'cl /?' for express seems to be somewhat different from the old revs of the compiler. For now, what I know is that I build the whole demo (with all its deps) in one go without a problem, it runs flawlessly. Yeah, if one set of project files can handle all the VS releases, that'd be sweet. Is it a matter of needing to have that exact version of the compiler to make changes to that rev of the project files, hand editing in a text editor being the only other option? Please note that this build file initiative should have two objectives : it should simplify the modifications needed everytime we add / remove something in the fltk lib (your proposal address that one), but it should also keep as much as possible the existing features available for vs users with no regression (my proposal tries to address that too). Ya, agreed. My goal is actually to be able to automate the builds of FLTK, so that I don't have to jump into a GUI and have a bunch of text steps I need to go through to click buttons to change things and then build. I'm a command line zealot, what can I say.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fluid /SUBSYSTEM question
I was noticing that (under Windows) when the Visual Studio IDE builds the release version of fltk, fluid.exe is built as a /SUBSYSTEM:WINDOWS app. Isn't that a Bad Thing if one tries to use 'fluid -c' from within a Makefile? I'm probably missing something, but being a /subsystem:windows app, doesn't it just immediately background itself, causing the Makefile to immediately move on to the next build step, thinking fluid is done when it's actually still in progress? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
I've got the whole kaboodle compiling now under VS NET with gmake; the libs, fluid, test programs. Also have a small 'fltk configration' screen (via 'gmake configure') which prompts for debug/release and verbose/silent build options interactively, or can be overridden by supplying NAME=value on the gmake command line. I moved all the Makefiles files into a subdir (buildtools.windows), and there's only a gmake.bat added to the top level directory which, if invoked, will run the configure screen, and install the gmake oriented Makefiles into the source dirs. This, I think, addresses some of Fabien's concerns about too many files being in the source dirs. My technique is to keep the files hidden, and only populate them into the source dirs if gmake.bat is invoked. Also, a 'gmake distclean' would get rid of them all. Will upload a new tarfile within the next day or so, time permitting. The current tar file extracts as follows: gmake.bat buildtools.windows/gmake.exe buildtools.windows/unconfigure.bat buildtools.windows/configure.bat buildtools.windows/Makefiles/fluid/ buildtools.windows/Makefiles/fluid/Makefile.MICROSOFT buildtools.windows/Makefiles/jpeg/Makefile.MICROSOFT buildtools.windows/Makefiles/png/Makefile.MICROSOFT buildtools.windows/Makefiles/src/Makefile.MICROSOFT buildtools.windows/Makefiles/src/gmake-fltk-include buildtools.windows/Makefiles/src/gmake.bat buildtools.windows/Makefiles/test/Makefile.MICROSOFT buildtools.windows/Makefiles/zlib/Makefile.MICROSOFT buildtools.windows/Makefiles/Makefile.MICROSOFT buildtools.windows/Makefiles/gmake-vsnet-include Only the gmake.bat would live in the top level dir, and has the small bit of logic to run the configure.bat script which puts the gmake files into place, and the 'gmake distclean' which uses unconfigure.bat to remove them again. There are several files, but they are small and easy to read, and allow unit testing, so that one can just eg. cd into the jpeg dir and type 'gmake' to build just that lib. Comments welcome.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Michael Sweet wrote: It would be interesting to determine whether we can make the exising makefiles work with VC++ with a new makeinclude and config.h header. I think it could. I think my doing a first pass using DOS will show what the porting issues will be. There are differences in DOS vs Unix for commonly used Makefile commands (like 'rm' vs 'del') that would have to be dealt with. I hate the idea of having to have a unix toolkit come with the distro, and although I think DOS emulation scripts can be made (eg. RM.BAT), this still sucks cause there are so many differences between Unix and Windows (backslashes for DOS commands, DOS's limited string manipulation abilities are not portable across all versions of Windows we support, chown/chmod logic having no equivalent in DOS, etc) makes it messy. Also, this might involve 'dumbing down' the Makefiles to the least common denominator, which would be bad. To me, a route that seems a clear path is to keep the Unix and Windows Makefiles /separate/, but have them 'include' data common to both. Since gmake.exe and make(1) are very compatible within their own syntax, common data like the definition of variables that hold the list of .cxx files that make up fltk.lib / fltk.a could be one of the settings in a single Makefile include, eg: # fltk library object files FLTK_LIB_OBJS= \ vsnprintf.$(OBJEXT) \ screen_xywh.$(OBJEXT) \ scandir.$(OBJEXT) \ numericsort.$(OBJEXT) \ flstring.$(OBJEXT) \ Fl_XPM_Image.$(OBJEXT) \ .. Both Unix and Microsoft Makefiles could include this, leaving all the platform specific code (rm vs. del) in the separate Makefiles where they belong. When FLTK core folks need to add new files to the lib, they only have to modify that one file, instead of having to modify all the Makefiles. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Fabien Costantini wrote: it could make sense to me to try this method and see if the makefiles we currently have could be 'pregenerated' without configure (batch file?) so that win32 users don't have until they install cygwin. Read so that win32 users don't have to run configure they would only have if they install cygwin on win32. Apparently on windows the visualc/config.h is the 'pregenerated' file the IDE uses during builds. It's the same one my Makefiles are referring to. So no config necessary for that. However, I could have my configure.bat tweak values in that file. Currently I create a small 'gmake-configure-include' file that has the DEBUG/RELEASE and VERBOSE/QUIET settings that my other Makefiles.MICROSOFT include in as global makefile variables. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Using gmake to build FLTK 1.3.x with VS .NET
Here's the latest which builds the whole of FLTK using VS .NET. http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles-0.30.tar.gz Just extract it into a copy of fltk-1.3.x, open a VS .NET console, cd into the dir, and run 'gmake'. It should ask you for DEBUG/RELEASE and VERBOSE/SILENT, and then should build the whole thing. Targets to know: gmake configure -- prompts for config options, installs gmake files gmake clean -- cleans libs/exe's/objs gmake distclean -- like 'clean', but removes gmake's files too gmake -- default make (runs configure if needed, builds all) You should be able to run 'gmake distclean' and not have any of the gmake files in the source dirs. Let me know if you have any trouble. Here's the tar file's contents: gmake.bat buildtools.windows/gmake.exe buildtools.windows/unconfigure.bat buildtools.windows/configure.bat buildtools.windows/Makefiles/fluid/Makefile.MICROSOFT buildtools.windows/Makefiles/jpeg/Makefile.MICROSOFT buildtools.windows/Makefiles/png/Makefile.MICROSOFT buildtools.windows/Makefiles/src/Makefile.MICROSOFT buildtools.windows/Makefiles/src/gmake-fltk-include buildtools.windows/Makefiles/src/gmake.bat buildtools.windows/Makefiles/test/Makefile.MICROSOFT buildtools.windows/Makefiles/zlib/Makefile.MICROSOFT buildtools.windows/Makefiles/Makefile.MICROSOFT buildtools.windows/Makefiles/gmake-vsnet-include ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] unicode, utf8, glib, and licensing
matthiasm wrote: I was very excited yesterday to see the first Japanese characters on my FLTK-for-OSX yesterday and I beleive that we are on a good path. I'd be happy to test your build with my commercial app in Japanese. OSX has been the one platform I haven't yet been able to run in Japanese mode. I've been fine using iconv to handle all text string conversion across unix and windows; unix comes with, and iconv seems to compile OK on windows as well. (For instance, my app sometimes needs to convert Japanse SJIS into UTF-8) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
On 10.5, it compiles and links fine. Did you update to the latest svn? Yes, I did an 'svn update' followed by 'make distclean; make', but it still built wrong. HOWEVER: I thought the problem might be I had made customizations to one of the Makefiles earlier in the week to add some testing targets, and I think the 'svn update' didn't overwrite my changes, so the Makefile didn't actually get updated. I did a fresh re-checkout to an empty dir, and THAT compiled fine with just a few warnings: Compiling fl_font.cxx... In file included from fl_font.cxx:41: fl_font_mac.cxx: In constructor `Fl_Font_Descriptor::Fl_Font_Descriptor(const char*, int)': fl_font_mac.cxx:97: warning: assignment to `short int' from `float' fl_font_mac.cxx:97: warning: argument to `short int' from `float' fl_font_mac.cxx:98: warning: assignment to `short int' from `float' fl_font_mac.cxx:98: warning: argument to `short int' from `float' Other than that, it built fine. I compiled my japanese text program against it, and there was one small problem.. sorry I'm only writing about the aberrations ;) the text was unscaled and mirrored (upside down, but correct left-to-right). Here's a pic showing the upside down text in the GUI, and the correct orientation of the japanese text in the terminal window: http://seriss.com/people/erco/fltk/tmp/japanese-mac-test.jpg The upside down thing sounds like a rendering problem (+y vs -y), not sure about the font scaling though.. might be a limitation of the default mac font, not sure. I'll try different set_font() settings to see if I can fix that. But hey, I'm impressed! First time I've seen japanese in fltk on the mac. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
imacarthur wrote: On 11 Sep 2008, at 19:20, Greg Ercolano wrote: On 10.5, it compiles and links fine. Did you update to the latest svn? FWIW, it builds OK on this 10.4.11 mac... Yes, builds fine for me now, too. Hmmm, I just tried it here, and it works out of the box with the Japanese test prog. Not for me.. probably as you say, you might have a slightly different config. Osaka seems good for me Yes! I found by adding: Fl::set_font(FL_HELVETICA, Osaka); ..to the program, then the Japanese text looks as it should, scaled properly and right-side up: http://seriss.com/people/erco/fltk/tmp/japanese-mac-test-2.jpg Great! I've tweaked the program on the website so that it includes that line; you may need to hit 'Reload' if you've viewed this page before: http://seriss.com/people/erco/fltk/japanese-test-utf8.cxx I'll try building my commercial app against this next, just to see how far I can get. That might take me a while, as I have to merge over my hotrodded patches. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
MacArthur, Ian (SELEX GALILEO, UK) wrote: But hey, I'm impressed! First time I've seen japanese in fltk on the mac. Thanks to Ian's efforts, if I understand that correctly. Well, I did the ATSUI patches, but I'm fairly sure that Greg helped, actually. He maybe doesn't remember it, but I have a strong recollection that he helped out with testing this originally... Maybe I am wrong! You're right, I can't remember..! I have some dim memory of digging in deep once to help out with a utf8 font problem, probably on X windows, and maybe even suggesting a patch.. but you're right, I can't remember specifics. I try not to remember anything I learn below the FLTK API.. that's why I use fltk, so I won't have to! ;) In my mind, Oksid made the original fltk/utf8 miracle happen, and he kept it up to date through 1.1.6-3, but then had other things to do, so later Ian picked it up, syncing Oksid's 1.1.6-3 to the latest fltk svn, 1.1.8 IIRC, doing cleanup and fixes on the way. I know I did some testing of Ian's release, and maybe got involved helping with one or two particular problems.. can't recall; those brain cells were re-purposed for remembering router passwords and what day of the week trash day falls on. I don't understand much about Unicode or the native font layers that fltk makes use of. I've dabbled in those APIs, but have no deep understanding of them, and hope I never have to..! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] utf8 preparation done!
D'oh. Double post apparently due to Thunderbird's NNTP news reader.. replying to Ian's message seems to have a Reply-To: [EMAIL PROTECTED] as well as the NNTP post, causing it to send the message both as an NNTP posting /and/ as an email. Mike, I think I'll post a sugg on news.general regarding adding a news.conf option to squelch certain headers when reading via NNTP to help solve this. ___ 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
Michael Sweet wrote:
Greg Ercolano wrote:
Is 1.3.x supposed to break existing apps?
I'd say the goal is to avoid breaking things unnecessarily, but
there might be some side-effects of design changes (UTF-8, this
Fl_Scroll stuff) which may require small code changes.
That said, I don't know how much existing code exists that tries to
directly manipulate the child() array of a Fl_Scroll widget.
Fl_Table does, so I assume it's not a small number.
I'd think any widget deriving from Fl_Scroll that wants
to do anything with children of the group has to know about
skipping over the scrollbars.
And a widget that wants to hide the 'specifics' of Fl_Scroll
underneath has to do things like:
int children() const
{ return(table-children()-2); }// -2: skip Fl_Scroll's h/v
scrollbar widgets
This could break a lot of existing extension libraries and
apps as well.
Many of the extension libs are no longer maintained, so breaking
them would really crimp acceptance of newer fltk releases I think.
It creates a situation where app programmers can 'boxed in' to old
releases; I need utf8, but I also need Fl_SomeExtension which
doesn't support 1.3.x yet..
I'm -1 on modifying base widgets in a way that breaks old apps
for compiling purposes if at all possible.
Can I suggest if API changes are made that affect existing code,
to derive a new widget (eg. Fl_Scroll2, Fl_Scroll_Ex..) or some such?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken?
imacarthur wrote: In both cases I svn up to latest, then did a make distclean, followed by ./configure --enable-quartz --enable-threads, then a make. Seems pretty reproducible. Editing the #if 0 block (around line 1290) to #if 1 to restore the previous behaviour has got me up and running again for now. Have you tried doing a fresh checkout to an empty directory? I had a situation where I'd apparently had a hand-hacked fltk file on my machine, so doing an svn update didn't update that file, leaving my old file in place.. in that case a 'make distclean' didn't help. Anyway, just a thought, since you're probably like me and hand hack fltk from time to time for testing or debugging.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] svn update: force conflicts to be overwritten?
Is there an easy way to do an 'svn update' that *overwrites* all files instead of doing a 'conflict' or 'merge'? ie. more like a tar extraction to write over all the source files with the latest release. The man pages and 'svn help update' don't seem to give an indication. Like many of you, I often hand-tweak fltk to add print statements and stuff just to check things, but if left behind, this messes up an 'svn update' by conflicting the files instead of overwriting them, leaving me with a half-updated fltk, and causes weird bugs that really aren't there. Unless one is particularly vigilant to see that single 'C' (conflict) character go by in the voluminous output of an update, you can miss it, and end up with a partial update that has to be fixed by hand. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2083: Add maximize, minimize caps to FL_Window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2083 Version: 1.3-feature Hmm, one question: why is 'maximized()/minimized()' being suggested instead of 'maximize()/minimize()'? Seems like they should be 'present tense' instead of past tense..? Link: http://www.fltk.org/str.php?L2083 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2083: Add maximize, minimize caps to FL_Window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2083
Version: 1.3-feature
Yes, I'd agree on consistency with what's in FLTK 1.x already
when it comes to naming and int return values.
It seems the FLTK API seems to like to use set_xxx() to set something, and
xxx() to get it, eg:
widget-set_visible(); // make it visible
if ( widget-visible() ) { .. } // check if visible
widget-set_changed(); // change it
if ( widget-changed() ) { .. } // get it
widget-set_modal();// set it
if ( modal() ) { .. } // get it
So to be 'consistent', I guess that's what should be used, if that's the
doctrine to be followed. I don't think the coding standards cover this:
http://fltk.org/cmp.php
..maybe it should. But that does seem to be the dominating method naming
convention used in FLTK. (To find out, I just grepped the FL/*.H files for
'set_' vs. 'is_' and 'ed()'. Lots of hits for set_xxx(), and few at all for
is_xxx() and xxxed())
However, I do like the way the suggestions in this STR read:
window-maximize(); // maximize the window
if ( window-is_maximized() ) { .. } // check if maximized
Also, the suggestion to use -ed() seems fine for differentiating the 'get'
and 'set' methods, as long as the -ed() is only used for 'get', eg:
window-maximize();// maximize the window
if ( window-maximized() ) { .. } // check if maximized
..but again, not many precedents for either of those in FLTK, if any.
Assuming it's even possible to 'get' these minimize/maximize values. I
should point out that since these are 'hints' to the window manager, it is
possible one can't ask the window manager if the window has been
minimized/maximized().
I remember looking at some window manager code in an app that seemed to
first 'ask' if eg. minimize() function was available in the window
manager, and if not, tried to emulate it with its own code.
Link: http://www.fltk.org/str.php?L2083
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] More UTF-8 handling oddities
imacarthur wrote: Whilst investigating STR 2080, I tripped over a feature in WinXP (and possibly also in Vista) described in STR 2086. Can I ask others that have access to WinXP and Vista test systems to try the failure recipe I describe and report whether the fault is reproducible or not? Reproduced on Vista. I don't have the latest checkout, but have a somewhat recent checkout from a week or so ago with the patch applied that fixed the A0 character. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK coding standards RFC
Dejan Lekic wrote: FLTK mostly uses xyz(value) to set, and xyz() to get. And I just _love_ that approach! Seems fine to me. The only way it might get confusing is if xyz is an action verb, like explode, in which case a programmer might accidentally code: // Set rocket to explode rocket-explode(); ..but all it does is return a value, and not do the action without an argument. So the code might read ok, but doesn't actually do what it looks like it does. That said, I'm all for consistency, just document whatever it is in the coding standards so we know when to use set/clear vs the above, and including a quick sentence or two describing the rationale behind the namings, to help programmers remember the naming rule. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1055: Menu tear-off
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1055 Version: 2.0-feature Would be great to have this in 1.3.x as well. I've always loved tearoffs.. use em in gimp all the time. Link: http://www.fltk.org/str.php?L1055 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 text extents patch
MacArthur, Ian (SELEX GALILEO, UK) wrote: How do people feel about my fl_text_extents patch (STR #2076)? Offhand I'm not familiar with the difference between a typographical bounding box and a minimal bounding box. It's probably obvious, and I haven't had my coffee yet. I'm guessing it's something like the vertical difference between the strings Lj and --, where I suppose fl_measure() is returning the same 'height' for both, and fl_text_extents() probably returns '1' as the height of --..? eg: fl_measure: . : ___ : : : : |o : : : : | -- : : : : _|___|| : : : : \_| : : : :..: :...: fl_text_extents: ... : ___ : : |o :.. : | -- :: : : _|___|| ::: : \_| : :.: Is that right? (I hope newsreaders aren't going to mangle my ascii-art underbars into underlined underbars..! Maybe hit 'View Source' if it does..) Is the proposed API acceptable? Does it suitably follow the fltk-style? Seems perfectly fine to me, and what I'd expect. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 text extents patch
imacarthur wrote: On 18 Nov 2008, at 19:00, Torsten Giebl wrote: I would like to have something like this but one that accepts a String and gives back the minimum width and - height. Torsten, can you expand on this? I am not sure I understand what you are asking - is this not what my fl_text_extents function does? Or is there something more that you need? Ya, Torsten, I'm thinking Ian's proposed function does exactly what you're asking for. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk2 Debian package
MacArthur, Ian (SELEX GALILEO, UK) wrote: Not official answers, just my opinion... as you can see at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364295 I'm working on a Debian package for fltk2 (needed by dillo etc...), however I've few questions for you: - are ABI/API stable? Probably not, there are still things that need revised. - will be important ABI/API changes? This is likely to happen. Mine is not official either, but I believe fltk2 is still in development/experimental. So is fltk1.3.x AFAIK. I think the only stable is fltk1.1.9 ATM. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Downloads page -- maybe should have dates on the releases
I think some folks might be downloading eg. 1.0.x instead of 1.1.x because at a quick glance, eg. 1.0.11 might seem like it's newer than 1.1.9 I think if dates were included on the Downloads page next to the releases, this could be avoided. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Downloads page -- maybe should have dates on the releases
Michael Sweet wrote: Greg Ercolano wrote: I think some folks might be downloading eg. 1.0.x instead of 1.1.x because at a quick glance, eg. 1.0.11 might seem like it's newer than 1.1.9 I think if dates were included on the Downloads page next to the releases, this could be avoided. Maybe, but we already list them newest to oldest... Yes, though I've noticed many (eg. gnu) projects list things the other way around, oldest to newest, because version numbered files in raw directory listings show up that way, eg: ftp://mirrors.usc.edu/pub/gnu/binutils So folks used to that are used to quickly scrolling to the *bottom* and grabbing the last file with the highest last digits. Or I believe that to be the cause of some folks grabbing the absolute oldest 1.0.x revs of FLTK by mistake. They'd surely think twice before downloading a file that had a 2001 date stamp. Dates would probably be good to show anyway, for completeness. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 text extents patch
imacarthur wrote: how did I get it to compile on my non-XFT test setup? I need to go back over that build and see what I actually did compile. I was wondering that myself.. I just now compiled that same snapshot on my more recent fedora3 machine with xft disabled (without my fix) and it hit the same error. Maybe you were on another platform during your test (Apple/Windows?) where the X-specific code was #ifdef'ed out? I guess no one had caught this so far because IIRC, xft is now enabled by default. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk-1.3.x-svn questions
Some questions about fltk-1.3.x-svn 1) Which Microsoft compiler(s) are currently supported to build fltk-1.3.x (while its in dev), and what is the correct master project file to load? I've noticed visualc/fltk.dsw no longer exists (which is what README currently recommends), and the vcnet/fltk.sln file can't seem to build most of the test programs under VS2008 express (numerous errors about fl_width and fl_utf8*, and lots of deprecated warnings eg. _sprintf() etc.) Is the sln out of date, or am I missing something? 2) Under unix, the fltk libs are named with underbars, eg. fltk_images.lib whereas under windows (via fltk.sln) the libs are eg. fltkimages.lib (without the underbar separator). Is this the standard naming convention, or will underbars be used for all? 3) fltk_xutf8 -- there used to be a lib by this name (old utf8 patches?) but I don't see it in the fltk-1.3.x stream lately. I take this has gone the way of the dodo, in favor of the utf8 routines getting compiled into fltk, is that correct? Or is there ever a reason we'd see the utf8 stuff show up as a separate lib, and if so, under what circumstances would an app need it? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3.x-svn questions
Thanks Fabien. One of the reasons I asked about the MS compiler was I've been putting together a Makefile kit (for building fltk from the command line with VS 7.0 .NET, something I need for my own purposes) I usually refer to the fltk VS build log to determine which files need to be included in the lib, but was having trouble because it wasn't building. Figured out what I need for the Makefile kit, so I think I'm good. So anyone wanting to build fltk-1.3.x with VS 7 .NET from the DOS CLI might want to look at: http://seriss.com/people/erco/fltk/tmp/README-vsnet-makefile-kit.txt Zip file: http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles-0.50.zip ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3.x-svn questions
Fabien Costantini wrote: Since the beginning you started this work, I have the feeling it could be a great alternative to the ide vs project files, provided that some more (probably tricky) work is achieved. More precisely, it would be great to reuse the existing Makefiles, and use a batch that changes/add the following: - the makeinclude file by a ms vs one with all ms vs tools related defs - a ms_configure.cmd file similar to your existing configure.bat file - the gmake exe tool as you use it now(with some gpl copyright attention). Yes, getting the Makefiles merged would be very tricky though. DOS is very dumb. And combined with its ancient need for backslashes and limited scripting abilities, would really dumb down and corrupt the unix side of the Makefiles. The lack of common unix commands like touch, rm, mv, etc. and the syntactical limitations of DOS make for awkward limitations on common tasks. In my mind it's an (unhealthy) challenge to work within the limited confines of native DOS, to avoid the worse situation of having to depend on a full blown msys/cygwin environment. This is likely why FLTK never supported CLI compiling for Visual Studio; DOS scripting is abhorrent to unix folks, and dumbing down the unix makefiles was surely out of the question. I took this on because a decade of DOS programming in the 80's warped my mind enough that I'd prefer programming Makefiles in DOS to using the Visual Studio IDE. It should definitely be possible to invoke the vs compiler tools with proper gmake variables, then we would truly reuse the existing Makefile's ... Am I dreaming ? Yes, though currently the Makefiles are quite different. Lots of unix specific stuff in the ones that come with FLTK, which is why I had to make them separate. The Makefiles are so different, it's hard to imagine them completely merging. But surely they could share some common files between them. Like the entire contents of my src/gmake-fltk-include.. I could easily see that being common across the platforms. But backslashes always seem to get in the way of this, compounded by DOS's limited string handling. DOS has some 'extensions' that enable some almost bash level string handling within strings, like search and replace (wow), but alas those features are not supported by older revs of Windows that FLTK supports. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Loading GIF Images from memory buffer
Gena Svarovski wrote: Greetings! Not sure if this is correct place for such posting but I didn't find any better, so writing here. I found it useful to keep small GIF images like icons not in external files which are shipped together with application but as static arrays inside binary. I searched for such functionality in FLTK and didn't find any, so I changed Fl_GIF_Image class to support such image loading. I can release it public if people think it would be demanded but then I need advice how to make it more FLTK-way. When in doubt, fltk.general is the place to post. Myself, when I want images in my apps, I use .xpm files and #include them into the code. .xpm files are an interesting format in that they are both an image file format and valid c/c++ code. They are also colormaps, very similar to the gif format. The only problem with xpms is they are not compressed in any way; the data is more or less 'raw', one character per pixel. If you have some code, definitely post it somewhere and point people at it on fltk.general, and you'll surely get some good feedback. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2102: RFE: new FL_ALIGN flags
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2102 Version: 1.3-feature FL_ALIGN seems to have some limitations that prevents certain positions for labels that would should be possible. The following diagram shows the 12 possible positions that really should be achievable. Four of these positions can't currently be achieved (marked with ???'s): TOP|LEFT TOP|CTRTOP|RIGHT __ TOP|LEFT|??? | | RIGHT|TOP|??? | | LEFT|CTR | | RIGHT|CTR | | BOT|LEFT|??? |__| RIGHT|BOT|??? BOT|LEFT BOT|CTRBOT|RIGHT I think an easy way to remedy this would be to make a new FL_ALIGN_SIDE flag, to allow TOP/BOT flags to be overloaded. So FL_ALIGN_SIDE could be used in place of the ???'s above to achieve these positions. This way only /one/ additional FL_ALIGN bit flag is needed. Thing is, it gets pretty hard from the user's point of view to predict the 12 positions just by looking at the FL_ALIGN names. So as a 'part II' to this request, it might be good to add convenience FL_ALIGN_XXX flags that use clock face numbers to represent the 12 positions, eg: 11 12 1 __ 10 | | 2 | | 9 | | 3 | | 8 |__| 4 7 6 5 So to put a label at the 4 o'clock position: FL_ALIGN_4_OCLOCK would be a convenience flag for RIGHT|BOT|SIDE. Link: http://www.fltk.org/str.php?L2102 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Inclusion of PDF file in SVN repo
imacarthur wrote: Gents, Is it intended that the fltk.pdf file be included in the svn repo? I wondered, only because it is quite large and that might be a problem for some users on slow links? Ya, I was wondering that myself. I thought my svn update was freezing up, and was about to hit ^C when I realized it was a big ole 6MB PDF. Maybe that could be a separate download from the source? Fast+Light suddenly very fat and heavy ;) Tis a thing O' beauty though. I imagine LaTeX is behind this somehow. Wow, first 60 pages are just the index! But very pretty. Maybe someday we'll see an actual dead trees book at Borders or Barnes and Noble on FLTK.. ;) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE]STR#2076:Patchforfl_text_extentsmechanism in fltk-1.3.x
Fabien Costantini wrote:
Yes I'm afraid I do,
look at the diff file below needed for fixing current svn ...
- if (c) return fl_text_extents(c, strlen(c), dx, dy, w, h);
[..]
+ if (c) fl_text_extents(c, strlen(c), dx, dy, w, h);
Interesting.. if I gather the gist of the patch correctly,
it looks like the change is to avoid having the void function
return() a function that returns a void.
Which seems to compile OK with 'g++ -Wall' on my linux
systems, eg. no compile errors for this:
void foo() { }
void bar() {
return(foo()); // OK with 'g++ -Wall'
}
Is that maybe no longer allowed on the newer windows compilers?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2113: Fl_Browser: some necessary methods (for derived classes)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2113
Version: 1.3-feature
Fl_Browser is missing a few needed methods for derived classes to work
efficiently with the linked list of items. These appear to be omissions:
1) The existing methods item_first(), item_next(), item_prev() etc. allow
fast walks through the linked list using item pointers. But it's missing a
way to get the text for an item.. we need e.g:
--
// RETURN TEXT FOR 'item'
const char* Fl_Browser::item_text(void*item) const {
return(((FL_BLINE*)(item))-txt);
}
--
Currently a derived class can only access text via a line number, eg:
Fl_Browser::text(int linenum)
..which has to do a linear lookup through the linked list to find linenum,
which is very slow with large lists, esp. when doing bubble sorts.
2) The protected methods item_first(), item_next() and item_prev() have
been provided, but item_last() seems to have been omitted. eg:
void* Fl_Browser::item_last() const {return last;}
..which is needed for starting at the end of the linked list and working
backwards.
3) The following existing protected methods are useful for eg. bubble
sorts in derived classes:
FL_BLINE* find_line(int)
void swap(FL_BLINE*,FL_BLINE*)
etc..
But unfortunately they currently can't be used by a derived classes
because the struct FL_BLINE is defined only in Fl_Browser.cxx, where it
can't be accessed.
Probably best would be to provide void* versions of these methods so
FL_BLINE doesn't need to be referenced.
Or, provide FL_BLINE in the header file so derived classes can access the
definition. (The former is probably a better solution; derived classes
probably shouldn't need to know FL_BLINE's definition at all)
Link: http://www.fltk.org/str.php?L2113
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature It occurs to me that it would be easy to get Fl_Help_Viewer to support http: links, probably with a single line of code, and *without* any TCP libraries, etc. Should be trivial to have http: URI's simply trigger the native web browser using the new fl_open_uri(some_url) function. This, instead of the current error message we get: http://foo.com/ - no handler exists for this URI scheme Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature--- Fl_Help_View.cxx.old2008-12-14 21:47:12.0 -0800
+++ Fl_Help_View.cxx2009-01-19 13:43:56.0 -0800
@@ -62,6 +62,7 @@
#include stdio.h
#include stdlib.h
#include FL/fl_utf8.h
+#include FL/filename.h // fl_open_uri()
#include flstring.h
#include ctype.h
#include errno.h
@@ -3084,14 +3085,17 @@
strncmp(localname, mailto:;, 7) == 0 ||
strncmp(localname, news:;, 5) == 0)
{
-// Remote link wasn't resolved...
-snprintf(error, sizeof(error),
- HTMLHEADTITLEError/TITLE/HEAD
- BODYH1Error/H1
-PUnable to follow the link \%s\ -
-no handler exists for this URI scheme./P/BODY,
-localname);
-value_ = strdup(error);
+char urimsg[256];
+if ( fl_open_uri(localname, urimsg, sizeof(urimsg)) == 0 ) {
+ // Remote link wasn't resolved...
+ snprintf(error, sizeof(error),
+HTMLHEADTITLEError/TITLE/HEAD
+BODYH1Error/H1
+PUnable to follow the link \%s\ -
+%s./P/BODY,
+localname, urimsg);
+ value_ = strdup(error);
+}
}
else
{
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature See attached patch for one way to do it. Cool, web links now work in my FLTK help pages..! Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature Yes, I've been playing around with it a bit, will have a different patch after I do some more testing.. Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature--- Fl_Help_View.cxx2009-01-20 10:53:25.0 -0800
+++ Fl_Help_View.cxx.orig 2009-01-20 10:46:27.0 -0800
@@ -62,7 +62,6 @@
#include stdio.h
#include stdlib.h
#include FL/fl_utf8.h
-#include FL/filename.h // fl_open_uri()
#include flstring.h
#include ctype.h
#include errno.h
@@ -3045,28 +3044,6 @@
char newname[1024]; // New filename buffer
- if (strncmp(f, ftp:, 4) == 0 ||
- strncmp(f, http:, 5) == 0 ||
- strncmp(f, https:, 6) == 0 ||
- strncmp(f, ipp:, 4) == 0 ||
- strncmp(f, mailto:;, 7) == 0 ||
- strncmp(f, news:;, 5) == 0) {
-char urimsg[256];
-if ( fl_open_uri(f, urimsg, sizeof(urimsg)) == 0 ) {
- // Remote link wasn't resolved...
- snprintf(error, sizeof(error),
- HTMLHEADTITLEError/TITLE/HEAD
- BODYH1Error/H1
- PUnable to follow the link \%s\ -
- %s./P/BODY,
- f, urimsg);
- value_ = strdup(error);
- format();
- topline(0);
-}
-return(0);
- }
-
clear_selection();
strlcpy(newname, f, sizeof(newname));
@@ -3097,29 +3074,48 @@
value_ = NULL;
}
- if (strncmp(localname, file:, 5) == 0)
-localname += 5;// Adjust for local filename...
-
- if ((fp = fl_fopen(localname, rb)) != NULL)
- {
-fseek(fp, 0, SEEK_END);
-len = ftell(fp);
-rewind(fp);
-
-value_ = (const char *)calloc(len + 1, 1);
-fread((void *)value_, 1, len, fp);
-fclose(fp);
- }
- else
+ if (strncmp(localname, ftp:, 4) == 0 ||
+ strncmp(localname, http:, 5) == 0 ||
+ strncmp(localname, https:, 6) == 0 ||
+ strncmp(localname, ipp:, 4) == 0 ||
+ strncmp(localname, mailto:;, 7) == 0 ||
+ strncmp(localname, news:;, 5) == 0)
{
+// Remote link wasn't resolved...
snprintf(error, sizeof(error),
-HTMLHEADTITLEError/TITLE/HEAD
-BODYH1Error/H1
+ HTMLHEADTITLEError/TITLE/HEAD
+ BODYH1Error/H1
PUnable to follow the link \%s\ -
-%s./P/BODY,
-localname, strerror(errno));
+no handler exists for this URI scheme./P/BODY,
+localname);
value_ = strdup(error);
}
+ else
+ {
+if (strncmp(localname, file:, 5) == 0)
+ localname += 5; // Adjust for local filename...
+
+if ((fp = fl_fopen(localname, rb)) != NULL)
+{
+ fseek(fp, 0, SEEK_END);
+ len = ftell(fp);
+ rewind(fp);
+
+ value_ = (const char *)calloc(len + 1, 1);
+ fread((void *)value_, 1, len, fp);
+ fclose(fp);
+}
+else
+{
+ snprintf(error, sizeof(error),
+ HTMLHEADTITLEError/TITLE/HEAD
+ BODYH1Error/H1
+ PUnable to follow the link \%s\ -
+ %s./P/BODY,
+ localname, strerror(errno));
+ value_ = strdup(error);
+}
+ }
format();
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] svn 1.3.x r6642: test/help program coredumping on start (fedora3)
Seems the test/help program segfaults under linux (fedora3)
with the current clean checkout of 1.3.x (r6642) and default build.
(Works fine on the mac, though)
Also, the test/help program no longer shows an example
html page anymore, probably because it wants to show
../documenation/main.html which no longer exists (due to Doxygen?).
Maybe help needs to be modified to refer to some example html files
that demonstrate all the features Fl_Help_View currently supports,
and just add html as new features are added.
Here's the (1) config summary, followed by the (2) gdb trace
of running the test/help program:
* * *
Configuration Summary
-
Directories: prefix=/usr/local
bindir=${exec_prefix}/bin
datadir=${prefix}/share
datarootdir=
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${prefix}/man
Graphics: X11+Xft+Xdbe+Xinerama
Image Libraries: JPEG=System
PNG=System
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES
* * *
# gdb test/help
[..]
(gdb) run
Starting program: /usr/local/src/fltk-1.3/test/help
[..]
(gdb) where
#0 0x004f375b in XSetForeground () from /usr/X11R6/lib/libX11.so.6
#1 0x080698de in fl_color ()
#2 0x08057ba8 in Fl_Help_View::format ()
#3 0x0805b2ae in Fl_Help_View::load ()
#4 0x0804cd67 in Fl_Help_Dialog::load ()
#5 0x0804c1ae in main ()
(gdb)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2127: Fl_Help_Viewer: an easy way to implement http: urls
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature OK, the attached patch: Fl_Help_View.cxx-patch3 ..should do more of the right thing, specifically: o Does not clear the screen when an http: link is clicked o Does not change the back/forward history when http: link clicked (because it opens a separate window, it shouldn't) o If the browser can't be opened, and an error msg is displayed, one can hit 'Back' to return to the original page. o This patch is against svn current (r6642), last patch was not. I did not see any behavioral problems with FLTK after clicking the link.. if you notice this, do post OS and behavior details. I should warn there's something wrong with svn 1.3.x current (r6642): a clean checkout and build of r6642 under linux (fedora3), the test/help program *core dumps* immediately -- ie. with or without the attached patch applied, it crashes. So don't let that separate problem confuse your tests for this patch. I reported the problem with r6642 in fltk.development: http://fltk.org/newsgroups.php?gfltk.development+v:7047 The r6642 help program doesn't crash on the mac.. problem might be X specific. Link: http://www.fltk.org/str.php?L2127 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fl_xxx() functions: hard to find in the doxygen docs?
On the new docs page: http://fltk.org/doc-1.3/index.html I see the old docs are on the RHS, and the doxygen docs are on the LHS. I'm curious where to find the complete alphabetical list of all the fl_xxx() functions on the doxygen side? (I know they are under 'Functions' on the old docs page) I was kinda expecting below '(+) Class List' to find a '(+) Functions' link. Would be great if it had /all/ the fl_() functions. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_xxx() functions: hard to find in thedoxygen docs?
imacarthur wrote: Actually, I just (yesterday) checked out 1.3 on a clean win32/mingw box and was surprised that the help-view demo failed when I was running through the test folder. Yes, like you, I think I brought this up on fltk.dev a few weeks ago: http://fltk.org/newsgroups.php?gfltk.development+v:7047 I guess I should have made it an STR; just submitted it now: http://fltk.org/str.php?L2136 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2140: Russian and chinese fonts on FLTK 1.1.8
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2140 Version: 1.3-feature This is a feature request for 1.3.x which already supports UTF8 (Chinese/Russian/etc), so someone's probably going to close this. Strongly suggest compiling your 1.1.8 app against 1.3.x. 1.3.x is very compatible with 1.1.x.. the main reason for the version number jump is ABI changes, not so much code related. The official 1.1.x series never supported UTF8, so you really have to jump to 1.3.x to get it. There is a utf8 patch for 1.1.x floating around, but it is not supported, and I doubt anyone is going to maintain it now that 1.3.x is available. (1.3.x is an 'official' merge of 1.1.x and the utf8 patch) Link: http://www.fltk.org/str.php?L2140 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #749: Enable a right-click copy/paste menu for all Input/Output/Editor/Display widgets
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L749 Version: 1.4-feature FWIW, here's an example of how to implement the copy/paste menu. Or at least, one of probably many ways: http://seriss.com/people/erco/fltk/#PopupCopyPasteMenu Link: http://www.fltk.org/str.php?L749 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 #2148: Use iconv() if provided by glibc
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2148 Version: 1.3-feature Does this take into account compiling on Windows with Visual Studio? I know one can get and compile iconv for windows, but it's sure nice not to have dependencies on non-native external libs.. makes it much easier to build/support fltk. Link: http://www.fltk.org/str.php?L2148 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2076: Patchforfl_text_extentsmechanismin fltk-1.3.x
Albrecht Schlosser wrote: Indeed, the test program attached to the STR might even be added to the test folder, if we wanted to go that far? +1 from me for the program in the test folder. Probably such a program could test multiple fltk functions, so that we don't set a precedent for having one test program for every function in fltk. Maybe the test program could be called draw_functions, and for now it would just test fl_text_extents(), with a tooltip or text description that describes what one should see. Later, other core folks could add similar drawing tests to this program to test other drawing function features. And if the app starts to get cluttered, maybe make a more flexible app that has a browser/chooser on the left for the different test names, and an area at the right for where the tests can be drawn, eg: ___ | | | FLTK drawing tests || | | _ || | | | fl_draw() | || | | | fl_pixel() | || | | | fl_text_extents() | || | | | | | T E S TA R E A | | | | | || | | | | || | | | | || | | | | || | | | | || | | |_| || | | ___ ___ | | | Prev Test | | Next Test | | Exit | | | --- --- | |___| ..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 particular test quickly. I guess Next Test could be an FL_ENTER button, so the enter key can be used to advance through the tests.. Apologies in advance for those of you trying to read the above ascii art with a non-fixed width font ;) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
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 testing. Ah, neat. I stumbled across it once, but was stumped at how it worked. But I poke at it a bit, I see the 1-5 buttons are individual tests, and the and buttons that appear forward/reverse through the tests quickly, M == Menu, etc. 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 up while one cycles through the tests.) I'd be happy to convert it, and port Ian's test program into it to add it as a test. I can submit the result here, and if it seems to work, you guys can check it in. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
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 up while one cycles through the tests.) +1, especially if you are volunteering to do the actual work! Got a template working already, and ported your test into it. Will convert Matt's tests in unittest.cxx over to it as well, then will post when I've got something I'm happy with. I figure each test can be a separate .cxx file, which can all be combined into the single unittest application. I'd be happy to convert it, and port Ian's test program into it to add it as a test. I can submit the result here, and if it seems to work, you guys can check it in. Or Mike could (finally) give you dev access. You've probably been here long enough now... ;-) No thanks -- I'll cause nothing but trouble ;) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] New unittest app suggestion -- RFC
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 up while one cycles through the tests.) +1, especially if you are volunteering to do the actual work! +1: Oh, yeah, sure. I did not care about usability back then. This was just a rough hack, so please, by all means, Greg's approach is so much nicer. As promised: http://seriss.com/people/erco/fltk/tmp/unittests-revised.cxx Should be a standard build. Tested on linux. I basically merged Ian's and Matthais' test programs together, and put a some code at the bottom to handle the app. You should be able to navigate all the tests either with the mouse or the up/down arrow buttons. You can just keep adding more tests.. should be scalable. We could break the test code out into separate .cxx files that are all brought together with a bunch of #include's. I had it that way when I started, but thought for now to merge it all into a single file so that you could try it out easily; we can always split it out later. I can say it's nice to have the tests in separate files; this way if you're the one adding a new test, you're in a file that is all your own code, and not have to be distracted by the other test code. Feel free to tweak. Comments welcome. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New unittest app suggestion -- RFC
matthiasm wrote: No, you guys are correct. Very nice, thank you! Fixed; changed touched - overwritten. Ian, also added a few more extents tests mainly out of curiosity.. I wanted to see what `, -, and _ looked like, as well as some separate text with descenders (gjpq). I basically made a subroutine out of the code that draws the text and boxes; maybe you can double check my work to make sure I didn't drop something out that was important. I've applied the above mods to the website copy at: http://seriss.com/people/erco/fltk/tmp/unittests-revised.cxx ..and added a v0.3 comment at the top, as well as a 1.0 submit: // Fltk unit tests // v0.1 - Greg combines Matthias + Ian's tests // v0.2 - Ian's 02/12/09 fixes applied // v0.3 - Fixes to circle desc, augmented extent tests, fixed indents, added show(argc,argv) // v1.0 - Submit for svn So if you don't see that, hit reload. If all works ok, feel free to check it in. I figure easiest thing is to replace unittests.cxx with the above, to avoid needing to change any Makefiles. ps. I also added a call to mainwin-show(argc, argv); so that the app inherits the window manager's look, the way the other tests do. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK for S60
matthiasm wrote: On 13.02.2009, at 15:18, SA wrote: http://blog-sadysty.ath.cx/?action=articlea=38 Oi, very nice! Hey, if that's fltk1.3, try adding Fl::scheme(gtk+); to the top of your app..! ;) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_Browser: new FL_SORT_ASC/DESC
I noticed these two new defines in Fl_Browser_.H for 1.3.0: #define FL_SORT_ASC0 /** sort browser items in ascending alphabetic order. */ #define FL_SORT_DESC 1 /** sort in descending order */ Before these become 'written in stone' when fltk.1.3.x releases, can they be changed to something more readable, like: FL_SORT_ASCEND FL_SORT_DESCEND ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2169: OSX: Cursor movement in Fl_Text_Editor, Fl_Input
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2169 Version: 1.3-feature [OSX 10.4.x on iBook] In Safari, Firefox, and TextEdit: CLOVERLEAF-LEFT move cursor to beginning of line, CLOVERLEAF-RIGHT move cursor to end of line, CLOVERLEAF-UPmove to top line CLOVERLEAD-DOWN move to end line ..and SHIFT combos with those will select the text from the point out to those positions. This seems to be some sort of standard on Macs, but they don't work in FLTK, but probably should. I really noticed this while trying to use the fluid code editor and the text editor app. Link: http://www.fltk.org/str.php?L2169 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2169: OSX: Cursor movement in Fl_Text_Editor, Fl_Input
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature--- src/Fl_Text_Editor.cxx.orig 2009-03-06 07:16:07.0 -0800
+++ src/Fl_Text_Editor.cxx 2009-03-06 07:20:18.0 -0800
@@ -135,6 +135,14 @@
{ 'c', FL_COMMAND, Fl_Text_Editor::kf_copy },
{ 'v', FL_COMMAND, Fl_Text_Editor::kf_paste },
{ 'a', FL_COMMAND, Fl_Text_Editor::kf_select_all },
+ { FL_Left, FL_COMMAND, Fl_Text_Editor::kf_meta_move },
+ { FL_Right, FL_COMMAND, Fl_Text_Editor::kf_meta_move },
+ { FL_Up,FL_COMMAND, Fl_Text_Editor::kf_meta_move },
+ { FL_Down, FL_COMMAND, Fl_Text_Editor::kf_meta_move },
+ { FL_Left, FL_COMMAND|FL_SHIFT, Fl_Text_Editor::kf_m_s_move },
+ { FL_Right, FL_COMMAND|FL_SHIFT, Fl_Text_Editor::kf_m_s_move },
+ { FL_Up,FL_COMMAND|FL_SHIFT, Fl_Text_Editor::kf_m_s_move },
+ { FL_Down, FL_COMMAND|FL_SHIFT, Fl_Text_Editor::kf_m_s_move },
#endif // __APPLE__
{ 0,0,0 }
@@ -331,6 +339,40 @@
return 1;
}
+/** Moves the current text cursor in the direction indicated by meta key */
+int Fl_Text_Editor::kf_meta_move(int c, Fl_Text_Editor* e) {
+ if (!e-buffer()-selected())
+e-dragPos = e-insert_position();
+ if (c != FL_Up c != FL_Down) {
+e-buffer()-unselect();
+e-show_insert_position();
+ }
+ switch (c) {
+case FL_Up:// top of buffer
+ e-insert_position(0);
+ e-scroll(0, 0);
+ break;
+case FL_Down: // end of buffer
+ e-insert_position(e-buffer()-length());
+ e-scroll(e-count_lines(0, e-buffer()-length(), 1), 0);
+ break;
+case FL_Left: // beginning of line
+ e-insert_position(e-buffer()-line_start(e-insert_position()));
+ break;
+case FL_Right: // end of line
+ e-insert_position(e-buffer()-line_end(e-insert_position()));
+ break;
+ }
+ return 1;
+}
+
+/** Extends the current selection in the direction indicated by meta key c. */
+int Fl_Text_Editor::kf_m_s_move(int c, Fl_Text_Editor* e) {
+ kf_meta_move(c, e);
+ fl_text_drag_me(e-insert_position(), e);
+ return 1;
+}
+
/** Extends the current selection in the direction indicated by control key c.
*/
int Fl_Text_Editor::kf_c_s_move(int c, Fl_Text_Editor* e) {
kf_ctrl_move(c, e);
--- FL/Fl_Text_Editor.H.orig2009-03-06 07:08:08.0 -0800
+++ FL/Fl_Text_Editor.H 2009-03-06 07:20:47.0 -0800
@@ -103,6 +103,8 @@
static int kf_shift_move(int c, Fl_Text_Editor* e);
static int kf_ctrl_move(int c, Fl_Text_Editor* e);
static int kf_c_s_move(int c, Fl_Text_Editor* e);
+static int kf_meta_move(int c, Fl_Text_Editor* e);
+static int kf_m_s_move(int c, Fl_Text_Editor* e);
static int kf_home(int, Fl_Text_Editor* e);
static int kf_end(int c, Fl_Text_Editor* e);
static int kf_left(int c, Fl_Text_Editor* e);
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2169: OSX: Cursor movement in Fl_Text_Editor, Fl_Input
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2169 Version: 1.3-feature text-editor.patch [attached] against 1.3.x should implement the 8 accelerators described above under OSX: Meta Up/Dn/Lt/Rt -- moves cursor Shift-Meta Up/Dn/Lt/Rt -- moves cursor + sets selection state The patch only affects OSX; it should have no effect on other OS's. There was already an #ifdef for OSX-specific accelerators, so I just added to that. I think I kept the spirit of the code, but someone familiar with the editor should give it a once over, as there might be a way to avoid the two new functions kf_meta_move() and kf_m_s_move(). I'll try to follow up with a similar patch for Fl_Input, but no guarantees :/ Link: http://www.fltk.org/str.php?L2169 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2169: OSX: Cursor movement in Fl_Text_Editor, Fl_Input
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature--- src/Fl_Input.cxx.orig 2009-03-06 07:44:18.0 -0800
+++ src/Fl_Input.cxx2009-03-06 07:51:48.0 -0800
@@ -150,9 +150,17 @@
else ascii = ctrl('D');
break;
case FL_Left:
-ascii = ctrl('B'); break;
+ascii = ctrl('B');
+#ifdef __APPLE__
+if (Fl::event_state() FL_COMMAND ) ascii = ctrl('A');
+#endif // __APPLE__
+break;
case FL_Right:
-ascii = ctrl('F'); break;
+ascii = ctrl('F');
+#ifdef __APPLE__
+if (Fl::event_state() FL_COMMAND ) ascii = ctrl('E');
+#endif // __APPLE__
+break;
case FL_Page_Up:
fl_font(textfont(),textsize()); //ensure current font is set to ours
repeat_num=h()/fl_height(); // number of lines to scroll
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Browser: new FL_SORT_ASC/DESC
Before these become 'written in stone' when fltk.1.3.x releases, can they be changed to something more readable, like: FL_SORT_ASCEND FL_SORT_DESCEND I think that does sound better. +1 IMHO, FL_SORT_ASCENDING and FL_SORT_DESCENDING would be even better. Agreed, even better with -ING suffix. I've been writing a widget that uses sorting, and found myself using that too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Mike (or someone), can you add me to svn?
Duncan, if you want, I can join the dox effort.
Maybe even fix a few simple bugs.
If you're still in the initial stages of working out the
dox style, I can hold off, or avoid certain parts you're
still working on. We can synchronize by email.
I'd like to help address some long standing doc omissions,
go through the old 1.1.x User Comments and try to bring in
any obvious stuff from those.
Maybe even add a few small small 2-to-4 line \code examples
that would help users, as some widgets really need it, eg.
Here's an example of how to walk the entire Fl_Browser's array.
Note Fl_Browser's index numbers are 1 based..!
\code
for ( int t=1; t=browser-size(); t++ ) {
printf(item #%d, label='%s'\n, t, browser-text(t));
}
\endcode
Also, probably wouldn't hurt to have two people on the
docs reading the dox manual. I know it'd make me put more
effort into absorbing it.
I'd also be happy to start or assist in the creation of an
FLTK doxygen standards page that describes how docs should
appear, so that new docs follow a certain format.
Such a document should probably describe the rational behind
whether to put dox in .H or .cxx files.. (my guess is they
should be near the implementation, ie. if a method is implemented
in the .H then dox should be there, if in the .cxx, dox go there..)
Would also like to include screenshots of widgets, so that each
widget ends up having a small screenshot showing what it looks like.
eg. Fl_Value_Input has a small screenshot:
http://fltk.org/doc-1.3/classFl__Value__Input.html#_details
All the widgets should probably have one of those at the head
of their descriptions, and maybe even a gallery of these same
images, so one can easily browse for the widget they're looking
for, and then click that widget to see the docs for it.
I'm sure we have to watch that the dox don't get too crazy,
as we don't want it to eclipse the source code with noise.
It's a delicate balance.. maybe someone can shed some light
on what techniques are best. I know I shed a tear when I
started doxifying my tree widget.. was real happy with how
nice and terse the code was, but the dox mixed in really
lost that terse look. For instance, this:
// FIND ITEM THAT WAS CLICKED
const Fl_Tree_Item *find_clicked() const {
if ( ! _root ) return(0);
return(_root-find_clicked());
}
// SET ITEM THAT WAS CLICKED
void item_clicked(Fl_Tree_Item* val) {
_item_clicked = val;
}
..became this:
/// Find the item that was clicked.
/// You probably want to use item_clicked() instead, which is fast.
///
/// This method walks the entire tree looking for the first item that is
/// under the mouse (ie. at Fl::event_x()/Fl:event_y().
///
/// Use this method /only/ if you've subclassed Fl_Tree, and are receiving
/// events before Fl_Tree has been able to process and update
item_clicked().
///
/// \returns the item clicked, or 0 if no item was under the current event.
///
const Fl_Tree_Item *find_clicked() const {
if ( ! _root ) return(0);
return(_root-find_clicked());
}
/// Set the item that was last clicked.
/// Should only be used by subclasses needing to change this value.
/// Normally Fl_Tree manages this value.
///
void item_clicked(Fl_Tree_Item* val) {
_item_clicked = val;
}
Yuck.
I want to see if I can make a vim syntax script that allows
a function key to toggle dimming out dox comments, so one can
just see the raw source code and source comments without all
the noise.
Actually, it'd be really nice to be able to 'collapse' away
all the dox comments from within the editor, so that they're
not even shown at all, so they don't even have to be cursor'ed over.
Duncan Gibson wrote:
Duncan, I noticed you have not finished your hmtl doc modifications,
so I'll probably update the WWW (html+pdf) at the end of the week.
I'm just fiddling about really, trying to get rid of the easier to
fix STRs and bring the bug count down. I hadn't looked at the docs
since before you did the big reorganization. I was waiting for the
dust to settle and ran out of spare time to work. I had forgotten
how much there is still to do on the documentation, removing html
in favour of doxygen, etc. So I might end up fiddling for a while
longer yet. I have a bit of spare time again...
To be pragmatic, I would say that we don't need to update the
1.3.x html pages on the web for every minor typo correction. We
should probably not aim for anything
Re: [fltk.development] Folding out doxygen comments in vi
I had good luck getting vim to do this trick of collapsing dox comments.. Here's a little video to go with it (no sound): http://seriss.com/people/erco/fltk/vim-doxygen-folding/vim-doxygen-folding.htm I never knew about 'folding' in vi.. certainly is a neat feature. BTW, here's a great slide show showing other very neat vim features handy for all programmers: http://www.scribd.com/doc/263139/VIM-for-PHP-Programmers Anyway, back to programming.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Albrecht Schlosser wrote: Personally I don't have problems with comments in the sources. Sometimes I'd like much more comments in the code (not only doxygen, but also some hints what the code is good for). Yes, I agree. Though I sure do like being able to turn off the end user docs during coding. Now that I have that ability (see separate thread), I'm really liking to have that option..! Also, with the doxygen comments turned off, the regular C/C++ comments remain behind, which is nice, since those are for the maintainers of the code, whereas the dox comments are for end users. In fact, when the dox comments are collapsed, the code looks a lot like the html versions of the .H files that doxygen generates in its html directory, eg: http://fltk.org/doc-1.3/Fl__Browser___8H-source.html Compare that listing to to the original Fl_Browser_.H file to see how much easier it is to see the raw code..! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Fabien Costantini wrote: Mike (or someone), can you add me to svn? If it's not done already, just fill the application form on the website, I'm sure you'll get an answer rapidly ;-) Ah, thanks -- didn't know that was there. I see there's a Request Developer Status under 'My Account'.. cool. Duncan, if you want, I can join the dox effort. As the doxygen dox 1.3 initiator, I'd also welcome your efforts in that field. Great; sorry, guess I forgot all the folks involved in the dox push.. quite a Herculean effort, I'm sure..! If you're still in the initial stages of working out the dox style, I can hold off, or avoid certain parts you're still working on. We can synchronize by email. Not sure I understand what you mean here, but I would prefer that you harmonize with existing dox style first which is no looking bad imho. Then any suggestions are welcome to improve it of course. Will do. Wasn't sure if the dox strategy had been stabilized. I'd also be happy to start or assist in the creation of an FLTK doxygen standards page that describes how docs should appear, so that new docs follow a certain format. Great; I'll see if I can give it a start. When/if I do, I'll follow up here in fltk.development. I'll just hit the commenting style stuff based on what I see, then you guys can flesh it out/correct me, as there's probably details re: latex/tex gen that I know nothing about. Regarding actual FLTK doc tweaking, I expect I'll only be enhancing what's already in place.. I take it you all did the heavy lifting of converting the old html over to dox. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
As you have already noticed, there are a lot of places where there are
comments that still hark back to the time when a single comment covered
two or more forms of a function, or multiple functions that all appeared
together. Now doxygen splits these functions apart, and the comment no
longer makes complete sense. These comments usually say the first form
and so on. These need to be teased apart.
Right, I noticed that too for my own stuff, esp. with simple
set/get methods.
At first I tried using grouping.. this is supposed to work
according to doxygen chapter 5.2 on Member Groups:
/*...@{*/
/** Sets/gets the sortorder, used for sorting the tree items. */
void sortorder(Fl_Tree_Sort val) { _sortorder = val; }
FL_Tree_Sort sortorder() const { return(_sortorder); }
/*...@}*/
But the result didn't look any different than commenting
the first and not the second; the methods were not grouped
together, and only the first method had a 'link'.
So I fell back to making separate comments for each,
ie. Sets the sortorder. and Gets the sort order.,
and felt I'd revisit later what the problem was.
But this made the docs really 'busy'; twice as large as
the first form approach. Especially annoying to read
when a class has lots of these.
Where comments were transferred from a central rather than a class page,
e.g. http://www.fltk.org/documentation.php/doc-1.1/drawing.html#drawing
the multi-form comments need to be replaced in the central page with
tagged paragraphs, where the tag gives the link to the class page. I
have not explained it very well; it might make more sense if you check
http://www.fltk.org/doc-1.3/index.html We also need to be careful that
we don't duplicate text between the central and the class pages and we
will probably need to revisit the central pages again in the future.
Yeah, I figured I wouldn't tackle that stuff; I figure the
lead person would set the precedent, and if its a big job,
we can each work on a piece by assigning sections out,
to prevent duplicate effort.
Many of the comments still contain a lot of intrusive html format tags
and corresponding layout. Although doxygen will honour [most of] them,
it can do a better job if the doxygen forms are used. Several examples
come to mind that render well, but are hard to read in the source.
- We don't really need P tags to denote paragraphs any more and
can simply use blank lines and more intelligent formatting of the text.
Right. Blank lines definitely create paragraphs.. I actually
made a point to note that in the standards doc I started writing.
- Many comments that contain lists are poorly laid out and obscured by
UL and LI begin/end tags where \li and better formatting would work.
Yes, or even this seems to work well for lists:
- item one
- item two
- item three
- item four has multiple lines\n
that go on like this
- item five
For more, see Doxygen Chapter 4. It even supports nested lists,
and one can end a list with '.' I've used it, seems to work well.
It's the equiv of li in html; you get the same result.
- There are a lot of places (on the common pages) where things are
highlighted between TT tags, but doxygen would show a link with emphasis
if the correct text were used for the entry.
Yes, that sounds good. dox seems to be good about just recognizing
keywords and assigning them links even when the word appears free-form.
Strictly speaking not a doxygem problem, but at the source level there
are a lot of places where function/method signatures are not specified
in a consistent way, with (int,int,int) for example, or with different
parameter names in different places. We should address these too.
Yes, changing the code to use meaningful variable names.
This is going to be tricky/scary, esp. for single letter names;
very hard to search/replace.. have to be careful.
I think the reason for int,int,int,int might be to avoid
assigning variable names that are unused in the code, as these
would cause warnings from the compiler. SGI's compiler seems to
be pickier about this than linux.
So there is still a lot to do on the doxygen front, never mind bringing
in the comments that have been added to the 1.1 docs on the web site,
and other improvements.
I think I'll just 'fix what I see' to start with.
I figure if there are known problems that you guys know about,
if it's too much to fix, you can assign me a section, and I'll
work on it.
Having a point person 'assign' the work is a good way to prevent
duplicate effort; I did this with taking all the old 1.1 buglist,
and breaking the giant
[fltk.development] Doxygen commenting in fltk
At first I tried using grouping.. this is supposed to work
according to doxygen chapter 5.2 on Member Groups:
/*...@{*/
/** Sets/gets the sortorder, used for sorting the tree items. */
void sortorder(Fl_Tree_Sort val) { _sortorder = val; }
FL_Tree_Sort sortorder() const { return(_sortorder); }
/*...@}*/
But the result didn't look any different than commenting
the first and not the second; the methods were not grouped
together, and only the first method had a 'link'.
Poking at this a little more, apparently setting
DISTRIBUTE_GROUP_DOC to YES in the Doxyfile affects
this behavior, though not in a desirable way.
With YES, links are made for both method, but instead
of grouping the methods together and putting a single
comment below, it still lists the methods separately,
but repeats the same comment under each, making the docs
twice as large.
If anyone knows the right answer to this, I'm all ears..
I hate the idea of twice-as-large docs, as my widget
in particular has lots of these get/set options.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Greg Ercolano wrote:
Strictly speaking not a doxygem problem, but at the source level there
are a lot of places where function/method signatures are not specified
in a consistent way, with (int,int,int) for example, or with different
parameter names in different places. We should address these too.
Yes, changing the code to use meaningful variable names.
This is going to be tricky/scary, esp. for single letter names;
very hard to search/replace.. have to be careful.
Hmm, I just noticed something interesting.
It appears doxygen advertises the variable names in the prototype
in the .H file, and not the declaration in the .cxx
This, even if the docs are in the .cxx.
I noticed that in my .H file I had:
void remove(int t);
..but in my .cxx, where the doxygen docs are, I had:
/// Doxygen comment here..
void remove(int index) { .. }
Note I used 'index' as the parameter in the .cxx file,
but just had 't' as the parameter name in the .H file prototype.
doxygen still used the 'int t' from the .H file prototype,
even though the docs aren't in the .H file.
In a way, this might be good for us, because this way we can change
the .H files to use descriptive names in the prototypes so they'll
show up in the docs, while leaving the source code parameter names
the way they are, avoiding to have to carefully search/replace those
single letter names throughout the old source.
This is may be by design.. I imagine doxygen shouldn't have to force
programmers to use long descriptive variable names in their source code,
just the prototypes.
Or, maybe we should change the source anyway, though that might be
a big job. Traditionally, FLTK uses lots of short variable names..
and I've never found that to be much of a problem for maintenance.
Certainly keeps the code short and readable.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Duncan Gibson wrote: It my mind the problem here isn't long or short names, but consistency. Imagine that the declaration in the *.H has parameters with long names, but the definition in the *.cxx file has short or missing names, and you have to write the doxygen comments in the *.cxx file. It will confuse the next person to come along if you talk about \param windowtop, but the code you see right under it says 'p' ... a la Fl_Slider::scrollvalue() Yep, good point. So I take it during documentation fixing, if the prototype params in the .H file don't match the .cxx and dox, then the .H file should be modified to match the code/dox. I'll keep that in mind if I encounter any of those. Note: doxygen will warn us if \param[in] xxx is used in dox, but doesn't match the parameters in the prototype. So if we use \param[in], that will catch that kind of problem. Of interest: \p xxx does NOT do checking. Maybe \p should be avoided for that reason, because it doesn't appear to do any consistency checks. (Not sure why..) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk.pdf: to commit or not to commit?
Greg Ercolano wrote:
Note: doxygen will warn us if \param[in] xxx is used in dox,
but doesn't match the parameters in the prototype.
So if we use \param[in], that will catch that kind of problem.
Of interest: \p xxx does NOT do checking.
Maybe \p should be avoided for that reason,
because it doesn't appear to do any consistency checks.
(Not sure why..)
Maybe \p shouldn't be avoided, but maybe \param[in] should
at lease be specified additionally, to ensure checks are done.
I'm currently using these doxygen comments in my widget
which comes out nicely and does the name verification:
--- snip
/// Sets the Fl_Pixmap to be used as the default user icon for all
/// newly created items.
///
/// If you want to specify user icons on a per-item basis,
/// use Fl_Tree_Item::usericon() instead.
///
/// \param[in] icon -- The new Fl_Pixmap to be used, or
///zero to disable user icons.
///
void usericon(Fl_Pixmap *icon) {
_prefs.usericon(icon);
redraw();
}
--- snip
The result I get from the doxygen docs is literally:
--- snip
Sets the Fl_Pixmap to be used as the default user icon for all
newly created items.
If you want to specify user icons on a per-item basis, use
Fl_Tree_Item::usericon() instead.
Parameters:
[in] val -- The new pixmap to be used, or zero to disable user icons.
--- snip
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] old C vs C++
Hmm, in trying to fix STR#2174 (SGI fails to compile 1.3.x), most of the problem is to do with C++ style comments in old C file contexts; SGI's native C compiler is strict about not groking C++ comment style by default. Apparently doxygenification and utf8 brought this on. caused some of this. A few items come to mind to solve this: 1) Leave this comment style mix alone, and modify 'configure' to include the CC flag -Xcpluscomm, which allows the C compiler to grok C++ comment syntax. 2) Convert the few C++ style comments to C style. This won't be hard, as there aren't too many. I've already done this, and can check it in if need be. #2 seems the way to go, but thought I'd toss #1 out there just to see if that's preferred. Also: some of the files that probably should be .h files are named .H eg. FL/filename.H is #included by numericsort.c So strictly speaking, anyone working on filename.H won't really have a clue (by the filename extension) that this file needs to be C format compliant. Should filename.H be changed to filename.h? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] old C vs C++
Albrecht Schlosser wrote: 2) Convert the few C++ style comments to C style. This won't be hard, as there aren't too many. I've already done this, and can check it in if need be. +1 for #2: If there is one compiler that doesn't like this, there may be more. Fixing this in an general way for all compilers is better than adding special options for one compiler. Agreed -- will check that in later today. Also: some of the files that probably should be .h files are named .H eg. FL/filename.H is #included by numericsort.c So strictly speaking, anyone working on filename.H won't really have a clue (by the filename extension) that this file needs to be C format compliant. Should filename.H be changed to filename.h? BTW -- just noticed filename.H #includes Fl_Export.H, so Fl_Export.H is in this category as well. If it's wrong, then it should be fixed. IMHO that's all to it. And if we don't decide to change all header files to .h (lower case 'h'), then we should be consistent and have all c header files with .h. Agreed, though I'll bet this impacts other stuff as well.. configure, Makefiles.. I think I'll leave the case/name changing up to folks wiser than I. I'll just handle the comment tweaks, so that SGI will build. The filename extension problem has maybe been in there long enough to qualify as a charming wart..? ;) I'm trying to remember why we use the C compiler at all. I'm naively thinking it should /all/ compile with C++, I must be forgetting something. We don't care about xforms anymore.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] utf8 files -- code standards compliance
The source code in the utf8 dir is all nutty with non-4 space code indents. Thought I'd bring all that into compliance.. any reasons not to? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] #warning excludes [was: [fltk.bugs] [MOD] STR #2174: ... buildfailure on SGI ]
Albrecht Schlosser wrote: #if !defined(WIN32) !defined(sgi) || defined(CYGWIN) #warning FIXME This needs to be UTF aware now #endif I don't think that this is correct, for two reasons: (1) WIN32 is also defined when compiling with gcc under Windows. If we want to exclude the MS VC compilers, as discussed in the STR, then the correct macro would probably be _MSC_VER instead of WIN32. (2) CYGWIN is wrong as well. If used, then it must read __CYGWIN__. OK.. But if we change (1), then we don't need __CYGWIN__, thus the correct solution would be: #if !defined(_MSC_VER) !defined(sgi) #warning FIXME This needs to be UTF aware now #endif This looks much easier and reflects _compilers_ and not platform dependencies. I'm not 100% sure that _MSC_VER is the correct name, but I'm sure that WIN32 would be wrong. That all sounds good. As you noticed, I started with what was there already: #if !defined(WIN32) || defined(CYGWIN) ..and added the !defined(sgi) to that, so I'm assuming what was there worked for the person who added it. And I'm aware that you copied existing code from glut_font.cxx, so it must have been wrong before ... Right. Grepping the code for CYGWIN, I see the more common use is __CYGWIN__, so what was there before may be unintended. But I'm assuming the folks who added the original #if did so to get it to compile on those platforms (as I did for the SGI), so maybe CYGWIN is also valid as an FLTK build time macro? However, I agree with you; CYGWIN - __CYGWIN__ seems more consistent with the rest of the code, even if CYGWIN works too. Targeting _MSC_VER is surely better too, if g++ under windows uses the WIN32 macro. Certainly there are many precedents in the code for the _MSC_VER macro. However, let's wait to see what others say. At worst folks compiling under windows with g++ won't see #warnings, and assuming CYGWIN does work but is not consistent, it might be fine as it is for now. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] #warning excludes [was: [fltk.bugs] [MOD] STR #2174: ... buildfailureon SGI ]
Seems maybe Fabien's the one to ask about the original line; (boning up on my svn skillz): 6235 fabien #if !defined(WIN32) || defined(CYGWIN) 6235 fabien #warning FIXME This needs to be UTF aware now 6235 fabien #endif Fabien, if your watching, does the below sound right to you? If so, we should probably bracket all the #warning's this way to avoid problems compiling 1.3.x across the platform spectrum. (I should add, I don't have cygwin, but I do have VS.) Albrecht Schlosser wrote: [..] (1) WIN32 is also defined when compiling with gcc under Windows. If we want to exclude the MS VC compilers, as discussed in the STR, then the correct macro would probably be _MSC_VER instead of WIN32. (2) CYGWIN is wrong as well. If used, then it must read __CYGWIN__. But if we change (1), then we don't need __CYGWIN__, thus the correct solution would be: #if !defined(_MSC_VER) !defined(sgi) #warning FIXME This needs to be UTF aware now #endif This looks much easier and reflects _compilers_ and not platform dependencies. I'm not 100% sure that _MSC_VER is the correct name, but I'm sure that WIN32 would be wrong. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Doxygen commenting in fltk
Greg Ercolano wrote: Greg Ercolano wrote: I'd also be happy to start or assist in the creation of an FLTK doxygen standards page that describes how docs should appear, so that new docs follow a certain format. Great; I'll see if I can give it a start. BTW, looks like there's already a bit mentioned in the FLTK coding standards already.. Source File Documentation in: http://www.fltk.org/cmp.php#CODING_STANDARDS We obviously want to flesh out from there, but it's a good start. I've always wanted to try out 'google docs' as a way to publicly manage text documents. For info, see: http://docs.google.com/ As a start, I've created a new doc, copying in the doxygen part of the FLTK coding standards, and will add some stuff from this thread, as well as some other notes from the last few days. The google docs editor looks a lot like Word, and has all the usual bold/font changing stuff, and can publish as HTML, PDF, etc. It has a revision tracker too. If nothing else, it'll be fun to see if it works. Later when it's 'done', we can merge the result back into the FLTK coding standards, or as a developer article, or whatever. I just need your Google Account name so I can add you as collaborators, so that we can all participate in editing it. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doxygen commenting in fltk
Greg Ercolano wrote: As a start, I've created a new doc, copying in the doxygen part of the FLTK coding standards, and will add some stuff from this thread, as well as some other notes from the last few days. I've 'published' the doc so that it should be publicly viewable at: http://docs.google.com/Doc?id=dgn42tzv_0fsbjmjgp If you want to be able to edit, just email me your google account name and I'll add you as a collaborator. Or, just tell me what you want changed and I'll add it, but it'd be more interesting to see how the collab works.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
