Re: [fltk.development] When trying compile fltk with vc++ 2008 express
On 19.01.2011 22:33, Domingo Alvarez Duarte wrote: It seems that the supplied ide/projects aren't updated to include FL_INTERNAL of FL_LIBRARY, because defining one of then make it works. Thanks, I thought that they had it already (grep found some hits), but I didn't verify. I'm going to update the project files now... FYI: FL_LIBRARY is the correct definition, and the *dll project have it already. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] When trying compile fltk with vc++ 2008 express
On 19.01.2011 22:33, Domingo Alvarez Duarte wrote: It seems that the supplied ide/projects aren't updated to include FL_INTERNAL of FL_LIBRARY, because defining one of then make it works. This should be solved now in svn r 8293, although there are still some problems with generation of .cxx and .h files from .fl files in the test directory with VC 2008. I didn't touch (yet) the VisualC6 files. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] How to setup VC++ 6.0
On 19.01.2011 19:57, Giau P wrote: I have trouble setting VC++ 6.0. VC++ 6.0 is really old. We're only partly supporting this for compatibility. If you can, you should use VC++ 2008 or later. I followed the compiling programs with microsoft visual c++ to run hello.cxx sample program, from this link: http://www.fltk.org/doc-1.0/basics.html, but I am not sucessful in setting up the working environment. This link is from FLTK 1.0 and must not be used for FLTK 1.3. The corresponding link for FLTK 1.3 is currently http://www.fltk.org/doc-1.3/basics.html, but this is not up-to-date and will probably be moved when FLTK 1.3.0 is released. If you need the newest docs, please download the latest RC (currently RC3) from: http://www.fltk.org/software.php?VERSION=1.3.0rc3 or a later version from http://www.fltk.org/software.php. It says: In Visual C++ you will need to tell the compiler where to find the FLTK header files. This can be done by selecting Settings from the Project menu and then changing the Preprocessor settings under the C/C++ tab. You will also need to add the FLTK and WinSock (WSOCK32.LIB) libraries to the Link settings. I have set the additional include directory to C:\Programs\FLTK\fltk-1.3.x-r7677. I also add wsock32.lib to Object/Library modules under the Link tab. What I dont understand is which fltk libraries I need to add? and where they are? Please do NOT add wsock32.lib to the linker settings. FLTK 1.3 uses winsock2 (ws2_32.lib), but you don't need to add it, unless you use it yourself. Please help and direct me to this. Thanks, You got another reply that should help you, please see there. HTH Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] undefined reference to `Fl::gl_visual(int, int*)'
On 18.01.2011 06:15, Ish wrote: undefined reference to `Fl::gl_visual(int, int*)' I believe that error means its implementation is missing. I haven't checked the source yet to confirm that. It isn't virtual from what I understand in the source code. using Fltk 1.3 Which exakt FLTK version (RC?, svn rev.?), OS, compiler, please? Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Posting to fltk.bugs
On 14.01.2011, at 18:38, Michael Sweet wrote: I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes in the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs directly, for example) but nothing we can't handle. Mike, we've got at least three positive votes (3:0), and I guess you and Matt would also agree to make fltk.bugs read-only, with appropriate measures for direct mails to fltk.bugs (reject message). Would you please ... ? TIA Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Windows [args] problem?
On 18.01.2011, at 15:14, Paul R wrote: The program only runs from args when a file is double clicked or if the user know about such things 'dragged and dropped' onto the exe, both of which things result in argc = 2, any higher and i have fails in place, argc = 1 is ignored as i am using the GetModuleFileName (i think thats what it was called) now. The thing is aside from the error pop up, using show-(argc, argv) threw up a bug regarding file loading or memeory allocation (based on file data loaded) somwhere in the program, which i was about to trace until i found that it was due to -show(argc,argv). i say 'due to' i mean that all my file loading and parsing is now structured without those parameters in mind directly so i will have to go and rewind the command line stuff a-g-a-i-n if i include it! either that or risk no icons i suppose. There are also other reasons to use show(argc,argv) for the *first* window shown, e.g. loading of system colors and such. But (and this is untested) you can always show your first window with win-show(1, argv); // note: argc is 1 or even set up your own argument vector, thus losing all FLTK default switches, but if you don't care... Note that this is untested, but it should work IMHO. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [Library] r8273 - branches/branch-1.3/src
On 14.01.2011 13:19, Albrecht Schlosser wrote:
On 13.01.2011, at 21:05, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2011-01-13 12:05:32 -0800 (Thu, 13 Jan 2011)
New Revision: 8273
Log:
Fixed WIN32 crash when printing with the test/mandelbrot demo.
Modified: branches/branch-1.3/src/fl_draw_image_win32.cxx
===
--- branches/branch-1.3/src/fl_draw_image_win32.cxx 2011-01-13
17:03:49 UTC (rev 8272)
+++ branches/branch-1.3/src/fl_draw_image_win32.cxx 2011-01-13
20:05:32 UTC (rev 8273)
@@ -184,7 +184,7 @@
if (size buffer_size) {
delete[] buffer;
buffer_size = size;
- buffer = new U32[(size+3)/4];
+ buffer = new U32[(int)(1.02* (size+3)/4)]; // some extra memory
needed when printing
Hmm, I don't know why there is the need for more memory, but
looking at the code and the intention of proper rounding, shouldn't
this be:
+ buffer = new U32[(int)(((1.02*size)+3)/4)]; // some extra memory
needed when printing
Well, reading this again, this would probably be better (correct):
buffer = new U32[((int)(1.02*size)+3)/4];
Manolo ?
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Window dissapearing
On 17.01.2011 11:27, MacArthur, Ian (SELEX GALILEO, UK) wrote: quote-from-msdn Alternatively, you can use the following compile options, which also produces the expected behavior. Make sure that you use either main or wmain, depending on which character set is used. cl /clr sample.cpp /link /ENTRY:main /SUBSYSTEM:WINDOWS /quote-from-msdn FYI: I don't know the context of this quote, but for FLTK apps you should probably not use /ENTRY:main, because FLTK does this for you (cited off the top of my head). This means that FLTK provides a WinMain() function that calls main() with the correct arguments. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
On 17.01.2011 11:42, Denton Thomas wrote: Will do. I can't get the weekly (8276) for a test right now, though - looks like the domain is in transition ... and caught due to MLK day. It's working (again) for me. There were DNS problems last Saturday, but they are fixed at least since Sunday morning/midnight (UTC). Maybe your provider still needs a DNS refresh... Alternatively you can temporarily fix it by putting the following IP addresses into your local host table (but don't forget to remove them later): 208.96.52.100 news.easysw.com 208.96.52.101 svn.easysw.com 208.96.52.102 www.fltk.org HTH Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Window dissapearing
On 17.01.2011 13:32, MacArthur, Ian (SELEX GALILEO, UK) wrote: So, if the OP shoul djust need to add /SUBSYSTEM:WINDOWS To the linker options, then? That's what I believe, yes. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Posting to fltk.bugs
On 14.01.2011 18:38, Michael Sweet wrote: On Jan 14, 2011, at 1:59 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: There seem to have been quite a few posts direct to fltk.bugs recently by users unfamiliar with our ways... Some of these even seem to have been of some merit (so it's good that Matt reads them!) However, I still wonder why fltk-bugs is not just made read only so that only the STR stuff goes there, and forcing users and contributors to post to fltk.general or fltk.dev instead… I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes in the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs directly, for example) but nothing we can't handle. +1 with a reject message for mails to fltk-bugs, as suggested in your other post. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] news.easysw.com currently unreachable
FYI: I just noticed that the FLTK news server news.easysw.com is unreachable. I sent a mail to Mike, and I hope that he can fix this when the night is over in the US. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] news.easysw.com currently unreachable
On 15.01.2011 12:21, Albrecht Schlosser wrote: FYI: I just noticed that the FLTK news server news.easysw.com is unreachable. I sent a mail to Mike, and I hope that he can fix this when the night is over in the US. You can fix this temporarily by using the IP address 208.96.52.100 instead of the host name news.easysw.com, but be aware that your news reader might see all messages as new instead of read. Thunderbird asked me to download all or a limited number of new headers, and downloading only 150 helped. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] news.easysw.com currently unreachable
On 15.01.2011 21:09, imm wrote: Right now, I can't access fltk svn or the fltk.org web-pages, and it looks as if the easysw.com domain is unreachable too, so I guess that the DNS is messed up somewhere. You're right, it was a DNS problem, and I got Mike's confirmation that it's fixed. News and svn work again for me. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2522: Hiding the Fl_X class under WIN32
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2522 Version: 1.3.0 -1 on using FL_LIBRARY for Windows, i.e. we should change FL_LIBRARY to another name for this purpose, as discussed in fltk.development, and this should be done for *all* platforms, IMHO. Sorry for the inconvenience, but I don't think that it would be wise to use FL_LIBRARY now that we know that it can make problems. All VisualC projects should be modified also to define FL_LIBRARY when compiling libfltk, libfltk_gl and libfltk_images, but not for any other target (not even fluid). That should already be so, since this was the original purpose of FL_LIBRARY (together with FL_DLL) for the Windows shared (aka DLL) VisualC version. Could someone commit these changes and modify MSWin IDE projects accordingly ? -1, please wait a moment. I'll have a look at it and propose a change later tonight. Did I understand well that, with VisualC, application programs compiled with -DFL_LIBRARY to get access to the Fl_X class would fail at link time or run time ? Yes, that would be the case when building the DLL versions, for the lib itself as well as the user programs. You must define FL_DLL if you want to build a user program that links to the FLTK dll when building with VisualC to get the correct name mangling or whatever to find the dll functions. This does not work if a user program defines FL_LIBRARY. I believe that this can be done better by defining another Macro. e.g. FL_INTERNALS, or FL_USE_XID or similar, and that we expose Fl_X if either FL_LIBRARY or the user-defined Macro requests it. I'll make a proposal later... Link: http://www.fltk.org/str.php?L2522 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Fl_X not exported on mac in 1.3
Michael Sweet wrote: Perhaps we could also allow defining FL_UNSTABLE or FL_UNPORTABLE to get the OS-specific definitions then? Or FL_OS_SPECIFIC or FL_INTERNALS ? Yes, something like that maybe. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Posting to fltk.bugs
MacArthur, Ian (SELEX GALILEO, UK) wrote: There seem to have been quite a few posts direct to fltk.bugs recently by users unfamiliar with our ways... Some of these even seem to have been of some merit (so it's good that Matt reads them!) However, I still wonder why fltk-bugs is not just made read only so that only the STR stuff goes there, and forcing users and contributors to post to fltk.general or fltk.dev instead... Anyone? +1, but _maybe_ with one exception: developer status enabling posting to fltk.bugs seems like a good idea to me. Sometimes we're posting comments that are not intended for the STR as side notes or for extended conversation. But this could probably also be done in fltk.development, as it is done for fltk.commit: there is a header Followup-To: fltk.development included. Okay, my final(? ;-)) suggestion: make it read-only and set Followup-To header to fltk.development. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_X not exported on mac in 1.3
MacArthur, Ian (SELEX GALILEO, UK) wrote: Some sort of FL_low_level_feature_here_be_dragons... option sounds like a good idea, and we separate the Fl_X stuff from the FL_LIBRARY option, resolving Albrecht's point. Though if we are doing that, I guess we'd need to do it before 1.3.0 goes final. Yep, but that's not a big deal. Documentation is probably the biggest problem here. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r8273 - branches/branch-1.3/src
On 13.01.2011, at 21:05, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2011-01-13 12:05:32 -0800 (Thu, 13 Jan 2011)
New Revision: 8273
Log:
Fixed WIN32 crash when printing with the test/mandelbrot demo.
Modified: branches/branch-1.3/src/fl_draw_image_win32.cxx
===
--- branches/branch-1.3/src/fl_draw_image_win32.cxx 2011-01-13 17:03:49 UTC
(rev 8272)
+++ branches/branch-1.3/src/fl_draw_image_win32.cxx 2011-01-13 20:05:32 UTC
(rev 8273)
@@ -184,7 +184,7 @@
if (size buffer_size) {
delete[] buffer;
buffer_size = size;
-buffer = new U32[(size+3)/4];
+buffer = new U32[(int)(1.02* (size+3)/4)]; // some extra memory needed
when printing
Hmm, I don't know why there is the need for more memory, but
looking at the code and the intention of proper rounding, shouldn't
this be:
+buffer = new U32[(int)(((1.02*size)+3)/4)]; // some extra memory needed
when printing
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Assign icons to the window border
Paul R wrote: Well ian you had it right in the first place...i was referring to the little icon you see in the top left of a windows box, like for example using internet explorer you see the little 'e' icon in top left. ... So i think i should look at the sudoku example you mentioned.. There is also a (short) description in the OS Issues chapter of the docs. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Linker Warnings Building FLTK1.3.0rc3 withVisualC++V6
On 14.01.2011 14:55, Brian Tilley wrote: Ian wrote That looks weird - looks like the fltk_jpeg lib somehow incorporates duplicates of the entire fltk.lib... Must be a linker misconfig or something, I guess? Looks like you were right Ian, I think I've sorted all the problems now. I've modified all the .dsp files to replace the $(ProjectName) part of the path with the individual Project name. So for Fluid (for example) # PROP Output_Dir Release/Fluid I've checked the .dsp files for single programs, and they seem to be okay, as far as I can see with diff and such. Then I've modified fltk_images.dsp to remove fltk.lib from the dependencies as this was clashing with the same dependency in fltk_jpeg.lib which it was also dependent on. What you describe (how it was) looks indeed wrong, but your solution seems to be wrong as well, if I understood what you did. fltk_jpeg.lib should not depend on anything, it's standalone. fltk_zlib.lib should not depend on anything, it's standalone. fltk_png.lib depends on fltk_zlib.lib. fltk_images.lib depends on fltk_jpeg.lib, fltk_png.lib, and fltk.lib. The same for the DLL versions, of course. I don't have the MS IDE here, but I can run a test later tonight or tomorrow with VC 2008. I've attached a ZIP file to the STR containing all the ide files for VisualC++ V6. I've included the Build Logs for the Libraries and Fluid for evidence. I didn't look at the build logs (yet). Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Help_Dialog problems
Paul R wrote: undefined reference to png_create, read_struct undefined reference to jpeg std error undefined reference to jpeg finish decompress etc I had been advised to add the fltk library 'before' fltk.a so i did this, same problems i added the fltk_z.a library as i thought that was to do with decompression, I have changed the order of the libraries a few times, trying to get lucky! presently i am using png.a, fltk.a, images.a, _z.a These names are really strange. Please post real command lines so that we can help you better. Try this order: fltk_images, fltk, jpeg, png, zlib, or fltk_images, jpeg, png, zlib, fltk. Both should work (together with your other options). See also my other post ( 2hr ago): Re: Linker Warnings Building FLTK1.3.0rc3 withVisualC++V6 for library dependencies. HTH Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] re help dialog problems
On 14.01.2011 20:40, Matthias Melcher wrote: lbfltk_png is just the interface between fltk and png, You still have to link with libpng. png then again depends on zlib, so you have to link that as well. And while you are at it, ling libjpeg as well. libfltk_png *is* libpng, if you use the bundled libs. dto. for libfltk_jpeg and zlib. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2518: Compiler warnings from Fl_Browser_.H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2518 Version: 1.3.0 Unfortunately your modification doesn't work well with our doxygen documentation. We need the argument names for it to work. Sorry, I don't see a solution. If nobody has another idea, this STR will be closed w/o resolution... Link: http://www.fltk.org/str.php?L2518 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2519: Problems building FLTK-1.3.0rc3 in VisualC++ V6
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2519 Version: 1.3.0 The VisualC2008 project builds well with VC 2008 Express, and since they use the same source files, I tend to say that it's a bug in the old VC6 compiler. I don't see a reason why a *comparison* shouldn't be allowed here (taking into account that the later compiler version doesn't complain). As Greg posted in fltk.general, a simple cast can fix this... Link: http://www.fltk.org/str.php?L2519 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2520: Fl_JPEG_Image constructor inconsistency
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 FLTK 1.3 adds a new Fl_JPEG_Image constructor that loads images from memory: Fl_JPEG_Image::Fl_JPEG_Image (const char *name, const unsigned char *data) The documentation of parameter name specifies that a unique name should be provided, but it is not used in the constructor. Do we need the image name (maybe for Fl_Shared_Image support?). If yes, this should be fixed. Otherwise, if the image name is not needed: should the c'tor be changed to: Fl_JPEG_Image::Fl_JPEG_Image (const unsigned char *data) by removing the first argument? Otherwise a simple fix would be to change the docs. Note: Priority is high, because this would change the API and ABI if we changed the c'tor later. Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2519: Problems building FLTK-1.3.0rc3 in VisualC++ V6
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2519 Version: 1.3.0 Fine, thanks. Although my suggestion would be Fl_Text_Display*, but I'm okay with both. Do what you like more. Link: http://www.fltk.org/str.php?L2519 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2520: Fl_JPEG_Image constructor inconsistency
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 To Matt: I see... I didn't realize the potential char * vs. unsigned char *, so it is clear that we need both parameters. Thus, the only thing we must do is to change the docs, as you suggested. I'll see if I can do it on Saturday, unless someone else beats me to it. Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2520: Fl_JPEG_Image constructor inconsistency
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 Domingo, your proposal is interesting, but please file this as a separate STR so that it won't get lost and we can close *this* STR. Thanks. Link: http://www.fltk.org/str.php?L2520 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Fl_X not exported on mac in 1.3
On 13.01.2011 21:40, Michael Sweet wrote: Document the workaround (define FL_LIBRARY) and note that such code will likely not be portable to future versions of FLTK. That's a good idea, and I believe such a warning is in the docs anyway, so we can surely go that route. OTOH, FL_LIBRARY is *meant* to be used only when compiling the lib itself, and on Windows this has side effects that would prohibit such a use [1]. But with the appropriate warning... We should definitely think about this again for FLTK 3. Albrecht [1] With MS-tools this means that FL_EXPORT is either __declspec(dllexport) or __declspec(dllimport). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Problems displaying text in Text Editor.
On 13.01.2011 15:35, Brian Tilley wrote: I've been having trouble with a Text Editor when attempting to look at files containing around 330,000 bytes of text (7400 lines). Basically, when I load the file it appears to load OK, but when displayed, I don't seem to be able to scroll down to the bottom of the file. It stops around 85% from the bottom. For reasons I won't go into I've been using fltk 1.1.7... You mean, you see this effect in FLTK 1.1.7? Does your editor use wrap mode? Did you also *try* FLTK 1.1.10 (or the newest subversion - 1.1.11)? The reason I'm asking these questions is that ISTR that there was a bug fix concerning scrolling when wrap mode was active, but I don't know exactly in which version. Might have been before 1.1.7, though. If you give us more information, I may be able to find the specific patch that would help. OTOH, if the file you mention doesn't contain secret data, could you put it on a server somewhere so that we can download it for testing? Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Problems building FLTK-1.3.0rc3 in VisualC++ V6
On 13.01.2011 16:31, Greg Ercolano wrote: Albrecht Schlosser wrote: Wouldn't it be better to use (Fl_Widget *) or maybe better yet (Fl_Text_Display *)? I decided on void* cause I was torn which of the two to choose, and being a maverick, I thought: neither! ;) But yes, probably Fl_Widget* would be the right one to keep both sides of the equality balanced. Balanced, yes, but then we have an explicit cast for 'this' that is not obvious (of course it is okay, because Fl_Text_Display is a Fl_Widget). If we used Fl_Text_Display*, this would only cast the 'const' away, and the further cast to Fl_Widget* for comparison would be done by the compiler, and this would be type-safe. Might be nit-picking, but I'd prefer the latter. But I don't like either - for me this should simply work. Should we put it in #if _MSC_VER = with = VC6-version-no. ? ;-) Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Problems displaying text in Text Editor.
On 13.01.2011 16:41, Brian Tilley wrote: The problem I have with upgrading, in the environment in which I work, is that the entire application would need to be regression tested if I update FLTK. (Our QA are not very trusting of this sort of update). Would this also apply, if you patch only Fl_Text_Display? If you could do this, and if you answered my question whether you used wrap mode, and if you tried FLTK 1.1.10 (for testing only), I might be able to help to find a small patch. Maybe. I can't give you the full application, but if I can find time I'll produce a cutdown app and see if that contains the same problem. I didn't mean the application, but only the file that produces the error, but a test app would be even better. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Assign icons to the window border
On 13.01.2011 23:52, Greg Ercolano wrote: Right. One thing you can do is make your application /borederless/, and then draw the entire window border and buttons and behavior yourself. It will then be up to you to handle making the 'close' and 'iconify' buttons as well as window dragging and resizing behavior. I don't have an example of this (other than my nixieclock app which is entirely borderless, but allows you to drag the clock around by clicking anywhere on it and dragging). It would certainly make for an interesting demo, and the demo would look and work 'consistently' across all platforms. Your flruler is also a nice example for dragging and changing a borderless window, and a very useful one (for GUI developers) as well! BTW.: Big thanks for this and all your other example progs. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [HIGH] STR #2515: Keyboard FL_Delete, FL_Up and FL_Down are not working on Fl_Input fields
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2515 Version: 1.3-current Tested, and it works *somehow* (for some value of somehow ;-) ). Now, with this version (r8259), I can type dead keys, but they show immediately in the buffer. Then, when I type the next key, they are replaced with the composed key, i.e.: type: ` shows: `, then type: e, replaces: ` with: è. That is _really_ unusual and not as in other Windows apps (e.g. while I was typing this in firefox). Normal behavior would be that dead keys are dead keys ;-) - they don't show until repeated or combined with the next different character. If this (r8259 behavior) is what you intended to do, then: I /don't/ like it and vote -1 for this behavior. FYI: I tested also with r8204, and dead keys worked as usual. So, what did you want to fix with this change in r8205 in the first place? Unfortunately there was no comment in the svn log about it :-( Link: http://www.fltk.org/str.php?L2515 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Fl_X not exported on mac in 1.3
On 11.01.2011 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote: One for Manolo I guess. Though... There is the bigger question of whether Fl_X should be exposed or not. What do folk think? I'd say don't expose, because it's internal and can be changed. If we really need to expose some of the internals that are not available now, then we should write accessor methods that do it in a defined way. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doc file missing from RC3 tarball
On 11.01.2011, at 18:15, Greg Ercolano wrote: Albrecht Schlosser wrote: Thus, we shouldn't bother to provide a main.html file, but rather add a sample html page for the html viewer test (as Greg volunteered to do already) and add appropriate browser links where needed. Mike might have a point about making separate simple fluid docs that can be used as a 'test' for the help program. I read it, sounds good. +1 These we'd write ourself, and these could limit themselves to the HTML subset our widget supports. In that doc it could link to the local and/or website docs, eg: FLTK Docs:A HREF=file://path/to/localdocs/html/index.html(local)/A The above would be an autoconfigured path, or optional an expanded environment variable? A HREF=http://fltk.org/path/to/fltkdocs;(website)/A I guess, this would be fix for a particular FLTK version... That all sounds very good, especially since I detected the changed layout in doxygen 1.7.3 (no internal non-frame version, i.e. no main.html file, using XHTML, lots of css and I don't know what else ...). We simply shouldn't rely on our help viewer to be able to open a doxygen'erated file. You said that you wanted to write such a simple HTML file, right? I'd say: go ahead, so that we have at least the 'head' file(s) that can be almost empty for 1.3.0, maybe only containing the links and some text that this is work in progress. Or whatever you can manage to do... TIA. +1 Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: Versioning FLTK 1.3.x online docs
I'm thinking of making the online docs version-specific, i.e. instead of having http://www.fltk.org/doc-1.3/index.html we should probably have http://www.fltk.org/doc-1.3.0/index.html http://www.fltk.org/doc-1.3.1/index.html ... Reasoning: The doxygen'erated HTML docs change their file names from time to time (new doxygen versions or changed contents). With this in mind, we will probably have stale links in the near future for all links that are posted somewhere on the net or in the news groups or mailing lists. If we moved /doc-1.3/ to /doc-1.3.0/ immediately after the release of FLTK 1.3.0 and keep this _unchanged_ in the future, then all links would stay stable. The next version 1.3.1 (or 1.4.0 / 3.0.0) would then have its own documentation directory. The documentation page could then link to the current (newest) version, but also to any older version, as long as we like. This should be easy to do (I can do it), but the question is: would this be useful to do? Better ideas? Mike, what about server space and... ? Any opinions? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.0 RC 3 released!
On 10.01.2011 19:35, Boris Mayer-St-Onge wrote: I did some test on Fedora 10 and 14 with current svn(8241). No major problem. Thanks. Here are some suggestions: 1- When compiling fltk, at the end one have === making documentation === This making ... specifies the directory that is 'made', and it is documentation in this case. Formatting src/fltk.man... 5 mores man files Suggestion: change to === making man pages ===. For me, making documentation is within the documentation folder. It is. The man pages are part of the documentation, but we don't generate the doxygen docs automatically, so this is not likely to be changed. 2- Into documentation folder, make pdf-dist doesn't works. There's no rule into the Makefile. Suggestion: change the Makefile or the README file. The README file has been changed. Thanks for the report. 3- When we open the index.html file, there is a 1.3.x above the gray box. Maybe change it to 1.3.0. Done. Also, there is 2 copyright in this page with year 2010. Maybe change it to 2011? Sigh. We just changed all copyright dates to 2010, but now it's already 2011. Time goes by... I'll see what I can do for the docs at least. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doc file missing from RC3 tarball
On 11.01.2011 18:48, Greg Ercolano wrote: Greg Ercolano wrote: Michael Sweet wrote: Would it make sense to provide a separate help file for FLUID, and then use that as the test file for the help_viewer demo? That sounds good, as I don't think the FLTK doxygen docs cover fluid anyway. ..or I guess I never read them! Well bite my tongue, apparently there /are/ doxygen fluid docs: http://fltk.org/doc-1.3/fluid.html So I suppose a small intro page that links to that would work. Maybe a pre-written index-fluid.html in the documentation dir that would have the links in it, and fluid-help-Manual could link to that. +1 I still like the idea of having separate links for local/website docs, so that even if the user doesn't have the local docs built, it would still work. +1 for separate links. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.0 RC 3 released!
On 11.01.2011 21:05, Albrecht Schlosser wrote: On 10.01.2011 19:35, Boris Mayer-St-Onge wrote: Also, there is 2 copyright in this page with year 2010. Maybe change it to 2011? Sigh. We just changed all copyright dates to 2010, but now it's already 2011. Time goes by... I'll see what I can do for the docs at least. Done. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] documentation FLTK 1.3.0.rc3
On 11.01.2011, at 09:48, Rainer Rinke wrote: 1. There is no �fltk.pdf� in the documentation subdir bundled with the FLTK software, although it is announced in the README (as far as I understood). Thanks for the report, this is fixed now (svn r8256). Your points 2. and 3. have been answered by Ian. Thanks for the good job you all did ! You're welcome :-) Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Doc file missing from RC3 tarball
MacArthur, Ian (SELEX GALILEO, UK) wrote: Just thought you should know that the file main.html is missing from the RC3 documentation tarball. Yes - this one is a puzzle to me: - In the fltk-1.1 docs, the entry point was index.html. - in the 1.3-rc2 tarball docs the entry point was main.html. - in the 1.3-rc3 tarball docs the entry point is index.html. Fluid in 1.3 expects to find main.html, whilst fluid in 1.1 looks for index.html. So, um... What's going on with this? I'd guess that index.html is the natural place for the docs to start, why did we change it to main.html? And what has it (partly) changed back? I'm in a hurry, so this is only quick and short answer and needs to be checked (will do later). I think that ... - main.html is the non-frame version (see online docs). - index.html is the version with frames (see online docs). - rc2 was probably wrong, since it may have had the non-frame docs (only). - 1.1 was different (you know). - fluid and help-view should probably use the non-frame version. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] display DPI
On 09.01.2011 18:10, nigo wrote:
The fix consists on calling SetProcessDPIAware() as soon as possible during program
initialization. It disables the fake dpi results and the built in
magnification so applications look sharp again and, smaller.
Thanks for the code. I tested this using the code you provided, but the
result is the same for me (Windows 7, correct dpi value about 89-90,
result 96). That's the same as without calling SetProcessDPIAware.
I'll attach my test code to this post, maybe you have an idea what's
wrong with it. You can include it as shown in the usage note at the
beginning.
Additionally, since apps now look smaller, I fix the default widget font size
and scrollbar sizes to match all other native apps, but now we are getting into
properly fixing fltk for dpi awareness. Thats harder since there are hardcoded
font sizes into fl_browser @codes rather than using multiples of FL_NORMAL_SIZE
for large, small and so on.
In any case, if you are interested in going a full fix route before release,
here is the code I use at theme initialization:
I used your code and found that I got a smaller font size (12 vs. 14),
but wider scrollbars (17 vs. 16).
Why are you using lfMenuFont ? Isn't the menu font always smaller than
normal (text) fonts? What would be a better font?
Running my code in test/hello results in:
set_show_dpi(81): size=14, scrollbar_size=16
set_dpi_aware() returned: 1
init_theme(57): size=-12
init_theme(74): size=12, scrollbar_size=17
set_show_dpi(95): size=12, scrollbar_size=17
Screen 0 (1680, 0,1680,1050) res. is 96.000 x 96.000 ppi
Screen 1 ( 0, 0,1680,1050) res. is 96.000 x 96.000 ppi
The numbers in brackets are the line numbers of dpi.h.
Any idea what's wrong with it ?
Albrecht
/*
file: dpi.h
usage:
#include dpi.h
int main(int argc, char **argv) {
set_show_dpi(argc, argv);
...
Then run your program with at least 1 (dummy or real) argument.
*/
#if defined(WIN32) || defined(__CYGWIN__)
# define WIN_HOST
#else
# undefine WIN_HOST
#endif
#ifdef WIN_HOST
#include Windows.h
static int set_dpi_aware() {
int ret = 0;
// Disable DPI magnification under Vista/Win7 and above
// The function is not available before Vista
HMODULE handle_dll = LoadLibrary(user32.dll);
typedef BOOL (*DPIFunc)();
DPIFunc pf_SetProcessDPIAware;
pf_SetProcessDPIAware =
(DPIFunc)GetProcAddress(handle_dll,SetProcessDPIAware);
if (pf_SetProcessDPIAware) {
ret = pf_SetProcessDPIAware();
}
FreeLibrary(handle_dll);
return ret;
}
static void init_theme(void) {
int size = 0;
int sb_size;
// Get native default font size for current dpi
if (LOBYTE(LOWORD(GetVersion()))=0x05) {
NONCLIENTMETRICS mt;
mt.cbSize = sizeof( mt );
if ( SystemParametersInfo(SPI_GETNONCLIENTMETRICS,
sizeof(mt), // *** changed according to MS docs ***
mt , 0) ) {
size = mt.lfMenuFont.lfHeight;
printf (%s(%d): size=%d\n,
__FUNCTION__,__LINE__,size);
if (size0) {
HDC dc = GetDC(NULL);
size = MulDiv( size, GetDeviceCaps( dc, LOGPIXELSY), 72);
ReleaseDC( NULL, dc );
} else {
size = -size;
}
if (size0) FL_NORMAL_SIZE = size;
}
}
// Set default scrollbar size to match native applications
Fl::scrollbar_size( (int) GetSystemMetrics(SM_CXVSCROLL) );
sb_size = Fl::scrollbar_size();
printf (%s(%d): size=%d, scrollbar_size=%d\n,
__FUNCTION__,__LINE__,size,sb_size);
}
#endif // WIN_HOST
static void set_show_dpi(int argc, char** argv) {
printf (%s(%d): size=%d, scrollbar_size=%d\n,
__FUNCTION__,__LINE__,FL_NORMAL_SIZE,Fl::scrollbar_size());
#ifdef WIN_HOST
if (argc1) {
int dpi_aware = 0;
dpi_aware = set_dpi_aware();
printf (set_dpi_aware() returned: %d\n,dpi_aware);
if (dpi_aware)
init_theme();
fflush(stdout);
}
#endif
printf (%s(%d): size=%d, scrollbar_size=%d\n,
__FUNCTION__,__LINE__,FL_NORMAL_SIZE,Fl::scrollbar_size());
fflush(stdout);
float ppi_h, ppi_v;
int x,y,w,h;
int n = Fl::screen_count();
for (int i=0; in; i++) {
Fl::screen_xywh(x,y,w,h,i);
Fl::screen_dpi(ppi_h, ppi_v, i);
printf(Screen %2d (%4d,%4d,%4d,%4d) res. is %7.3f x %7.3f ppi\n,
i, x,y,w,h, ppi_h, ppi_v);
}
fflush(stdout);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] display DPI
On 09.01.2011 21:30, nigo wrote: Your code works well on my PC with a 24 monitor at 1920x1080 and DPI manually adjusted to 144. Here is the output of both codepaths: D:\home\dpitest set_show_dpi(81): size=14, scrollbar_size=16 set_show_dpi(95): size=14, scrollbar_size=16 Screen 0 ( 0, 0,1280, 695) res. is 96.000 x 96.000 ppi D:\home\dpitest 1 set_show_dpi(81): size=14, scrollbar_size=16 set_dpi_aware() returned: 1 init_theme(57): size=-18 init_theme(74): size=18, scrollbar_size=26 set_show_dpi(95): size=18, scrollbar_size=26 Screen 0 ( 0, 0,1920,1042) res. is 144.000 x 144.000 ppi Thanks for the code. I tested this using the code you provided, but the result is the same for me (Windows 7, correct dpi value about 89-90, result 96). That's the same as without calling SetProcessDPIAware. Have *YOU* actually changed your dpi on the screen properties panel? If you havent, then there is nothing to adjust for and the results will be the same. I dont think Win7 is polling EDID info from the monitor and adjusting automatically. No, I had not changed it. I found out myself looking aroung how to do it and found it. With adjustment (120%) I get: $ ./tabs set_show_dpi(84): size=14, scrollbar_size=16 set_show_dpi(98): size=14, scrollbar_size=16 Screen 0 (1402, 0,1403, 877) res. is 96.000 x 96.000 ppi Screen 1 ( 0, 0,1402, 838) res. is 96.000 x 96.000 ppi $ ./tabs xxx set_show_dpi(84): size=14, scrollbar_size=16 set_dpi_aware() returned: 1 init_theme(60): size=-14 init_theme(77): size=14, scrollbar_size=20 set_show_dpi(98): size=14, scrollbar_size=20 Screen 0 (1680, 0,1680,1050) res. is 115.000 x 115.000 ppi Screen 1 ( 0, 0,1680,1004) res. is 115.000 x 115.000 ppi Why are you using lfMenuFont ? Isn't the menu font always smaller than normal (text) fonts? What would be a better font? On Windows XP it worked better using the menus than the dialog or normal text font since WinXP dpi handling is broken. I guess you could poll all of them and get the highest, but definitely NOT the average as you will usually get a lot of unchanged stock font sizes and only one changed to actual useful size. In the default setup, all fontsizes I tested (meanwhile) were the same. I didn't test different with adjusted magnification. It seems my heuristic (menu size) is failing on your configuration. I see. Your results for scrollbar width seem ok, since fltk has always used scrollbars that are too thin for windows standards. Yes, with adjustment I get bigger scrollbars. By the way, you should NOT condition the call to init_theme to the success of SetDPIAware() since you still want your apps to adapt to user dpi configuration on winXP. Thanks, my code was just a quick hack for testing, not for final production code. Most users never touched it in the past, but as users get higher resolution monitors the text starts to look too small to read comfortablyand they begin to adjust it. The informed ones, that is. Many just run their LCDs in a lower resolution mode to solve the size problem. On a different note, I provided the init_theme function for you to play with, not to directly include into fltk codebase to fix dpi since it will break existing apps looks. Widgets are placed using fixed positions and sizes and bigger font sizes will make the text overflow and labels wont line up properly as compared to fluid. Yes, that's clear, but it was a great help for testing. I do even think that we should not include the dpi_aware setting unconditionally in FLTK. It should be a user option, or maybe a function that can be called just at the start of main(). I usually create my widgets using multiples of FL_NORMAL_SIZE with the following heuristic, that seems to be good enough for the general case: widget_width = (FL_NORMAL_SIZE+2) * desired_text_columns; widget_height = ( desired_text_rows * FL_NORMAL_SIZE * 45 )/ 100; // char width = 45% height Nice. FLTK needs a layout system, but you already know it :) Yes, I know people ask for it. ;-) My app scales and resizes all fonts dynamically, and we use server-generated (hand-made) forms, so that I personally don't need such a thing. However, we use group-relative coordinates that are transformed internally, and that makes life much easier. But FLTK 3 is coming... ;-) Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #1691: Effect of NORMAL_INPUT_MOVE is not as described
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1691 Version: 1.3.0 Fix Version: 1.3.0 (r8035) Fixed in Subversion repository. This is now a user setting in FLTK 1.3. The NORMAL_INPUT_MOVE macro is now used as a shortcut for this user setting: Fl::option(Fl::OPTION_ARROW_FOCUS). Therefore this STR is now solved. Closing. Link: http://www.fltk.org/str.php?L1691 Version: 1.3.0 Fix Version: 1.3.0 (r8035) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1760: Fl_Menu_Bar should require Alt+shortcut
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1760 Version: 1.4-feature Fix Version: 1.3.0 (r7816) I consider this STR as solved. Please see also STR #2243 and #2199. Top level menus in Fl_Menu_Bar require the ALT key now. Matt, what about the Mac OS X concerns? Can this be closed, or is this still an issue? I left Software Version at 1.4-feature. If you close this, please set the Version to 1.3. Thanks. Link: http://www.fltk.org/str.php?L1760 Version: 1.4-feature Fix Version: 1.3.0 (r7816) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1760: Fl_Menu_Bar should require Alt+shortcut
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1760 Version: 1.3.0 Fix Version: 1.3.0 (r7816) So I guess that we should modify line #345 in src/fl_shortcut.cxx to be different on OS X? #ifdef __APPLE__ if (require_alt do_the_right_thing_here ) return 0; #else if (require_alt Fl::event_state(FL_ALT)==0) return 0; #endif Does this sound feasible? If yes, would you please do it since I'm not a Mac expert? Link: http://www.fltk.org/str.php?L1760 Version: 1.3.0 Fix Version: 1.3.0 (r7816) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1760: Fl_Menu_Bar should require Alt+shortcut
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1760 Version: 1.3.0 Fix Version: 1.3.0 (r7816) Matt and Manolo: this STR is assigned to me, but since you are the Mac experts, please feel free to take it and do the appropriate changes. Thanks Link: http://www.fltk.org/str.php?L1760 Version: 1.3.0 Fix Version: 1.3.0 (r7816) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter badUTF-8 characters
On 07.01.2011 10:24, Manolo Gouy wrote:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
Fix Version: 1.3.0 (r8208)
Fixed in Subversion repository.
Not yet... ;-)
We both missed an _important_ point. Currently we're converting
the string almost always twice! That's what we wanted to avoid by
pre-allocating and keeping the buffer around, didn't we?
See my commit in r 8211.
BTW.: I tested the mechanism by using a few printf's, and it looks
like the buffer gets allocated with only a few hundred characters,
if at all (normal widgets like in [test/] hello.cxx, valuators.cxx,
and tabs.cxx use slightly more than 100. The longest I found is
test/editor that allocates a buffer for the longest line that is
displayed (even if it is clipped), but I think that doesn't matter
at all.
Thanks Albrecht for this lesson of Cygwin that's was very useful
for me.
You're welcome. Thanks for your continuing work on really difficult
internal issues (OS X, X11, Windows GDI). That's amazing!
Could Xft be processed under Cygwin as it is under X11 ?
generally, yes, I think so, but wait a moment...
That is, if one does, in fl_utf.c:
unsigned fl_utf8towc(const char* src, unsigned srclen,
wchar_t* dst, unsigned dstlen)
{
#if defined(WIN32) !defined(__CYGWIN__)
return fl_utf8toUtf16(src, srclen, (unsigned short*)dst, dstlen);
#else
...
#endif
}
and removes the cygwin-special cases in Fl_Xlib_Graphics_Driver::draw
and utf8extents() of fl_font_xft.cxx,
would that run OK on cygwin ?
I'll take a look at this (and maybe test on Cygwin whatever I find)
and let you know...
Albrecht
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2505 Version: 1.3.0 Fix Version: 1.3.0 (r8211) For the record: the above-mentioned commit was in r8208. Further improvement (removed double string conversion) in svn r 8211. Link: http://www.fltk.org/str.php?L2505 Version: 1.3.0 Fix Version: 1.3.0 (r8211) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] UTF-8 conversions [was: STR #2505: Xft backend doesn't filter badUTF-8 characters]
On 07.01.2011 10:24, Manolo Gouy wrote:
[part 2 to this question:]
Could Xft be processed under Cygwin as it is under X11 ?
That is, if one does, in fl_utf.c:
unsigned fl_utf8towc(const char* src, unsigned srclen,
wchar_t* dst, unsigned dstlen)
{
#if defined(WIN32) !defined(__CYGWIN__)
return fl_utf8toUtf16(src, srclen, (unsigned short*)dst, dstlen);
#else
...
#endif
}
and removes the cygwin-special cases in Fl_Xlib_Graphics_Driver::draw
and utf8extents() of fl_font_xft.cxx,
would that run OK on cygwin ?
No, that wouldn't work, because fl_utf8towc() would still write a
wchar_t array, and wchar_t is 2 bytes on Windows. I had to change
it the other way around, and I was really surprised when I looked
closer at the code. The old code was:
#ifdef WIN32
return fl_utf8toUtf16(src, srclen, (unsigned short*)dst, dstlen);
#else
...
My first thought was: ooh, that's *wrong*, it must be
#if defined(WIN32) || defined(__CYGWIN__)
...
But how could it have worked before, if fl_utf8towc() would have
returned a string (array) of 4 bytes for each character (UCS-4)?
The solution is simple, but surprising in the first place. Despite
the comment (except on win32...) the code _tried_ to convert to
UCS-4, but then assigned the resulting UCS-4 byte to a wchar_t,
and thus truncated it to a 2-byte value:
... unsigned ucs = fl_utf8decode(p,e,len);
... dst[count] = (wchar_t)ucs;
This works well, as long as there is no need to use surrogate
pairs (ucs = 0xd800 ...), so it went undiscovered until now.
Thanks for the hint, so that I looked at it.
I changed a few more occurrences of WIN32 to WIN32 || __CYGWIN__
(or the reverse logic), but I didn't touch anything beyond pure
UTF-8 string conversions.
I'm not sure what (if anything) to do with fl_utf8locale(),
because this is more something like OS handling, and in this
case __CYGWIN__ means POSIX compatibility, and we should leave
this to the Cygwin/POSIX layer (hence only #ifdef WIN32).
But then there are:
- unsigned fl_utf8to_mb() and
- unsigned fl_utf8from_mb()
According to the comments, they are used for filename conversions
for OS-specific functions (they are used in filename_list.cxx).
I decided not to touch them, because I don't know what would be
correct. I remember that we recently had a patch concerning file
name handling, so I hope that this is all okay.
Albrecht
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Xinerama
On 07.01.2011 10:38, Matthias Melcher wrote: I don't know much about X11 and much less about Xinerama, but I tried to get the DPI code running on X yesterday, and all my virtual machines (3 Linux variants) fell back to X11 (no Xinerama). After investigating a little more, I found that there is no libXinerama.so, but there are libXinerama.1.so and libXinerama.1.0.so or similar. Shouldn't there be a symbolic link? Or is that only generated if one actually has multiple displays? I have on Linux (Ubuntu 9.x), in a Virtualbox VM: lrwxrwxrwx 1 ... /usr/lib/libXinerama.so.1 - libXinerama.so.1.0.0 -rw-r--r-- 1 ... /usr/lib/libXinerama.so.1.0.0 ... and on Cygwin (Windows 7): -rw-r--r-- 1 ... /usr/lib/libXinerama.a -rwxr-xr-x 1 ... /usr/lib/libXinerama.dll.a* -rwxr-xr-x 1 ... /usr/lib/libXinerama.la* I know the latter is not relevant here, but anyway. Configure finds Xinerama only on my Cygwin system, but not on Linux. I don't know whether it depends on the (missing?) link or maybe missing headers, though. And even though configure has not found Xinerama, it is still listed in the summary of the script. That can't be good? That's probably only a wrong display in configure and harmless. I just verified that HAVE_XINERAMA is set correctly in config.h (always #define'd, but with 0 or 1, resp.). BTW.: I'm just fixing a bug WRT Xinerama and dpi for Cygwin/X11 or maybe generally for X11: As it is on my system, configure finds Xinerama, but it is not active with my X server configuration, i.e. XineramaIsActive(fl_display) returns false... Please don't submit RC3 before this is committed. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 build warnings on win32
On 07.01.2011 14:23, MacArthur, Ian (SELEX GALILEO, UK) wrote: A few new warnings being seen now on my win32 builds (Msys/mingw based build...) that were not present a few days ago. ... The next seems to be a side effect of the recent DPI stuff, I guess... Compiling screen_xywh.cxx... screen_xywh.cxx:59: warning: converting to `int' from `float' screen_xywh.cxx:59: warning: converting to `int' from `float' screen_xywh.cxx: In function `BOOL screen_cb(HMONITOR__*, HDC__*, tagRECT*, LPARAM)': screen_xywh.cxx:76: warning: converting to `int' from `float' screen_xywh.cxx:77: warning: converting to `int' from `float' I just committed r 8210 that fixed a type mismatch, could you please check r 8210 or a later version, or did you use this already? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Xinerama
On 07.01.2011 13:34, Matthias Melcher wrote: BTW.: I'm just fixing a bug WRT Xinerama and dpi for Cygwin/X11 or maybe generally for X11: As it is on my system, configure finds Xinerama, but it is not active with my X server configuration, i.e. XineramaIsActive(fl_display) returns false... Please don't submit RC3 before this is committed. FWIW, I'm done with it, but it doesn't work as expected (unless we expect after recent discussions that it doesn't work 8-] ). Some values, all on the same PC (Win 7) with a Linux VM on the second screen. Both screens are identical (22, 16x10, about 90 ppi). Windows7 test/hello Screen 0 (1680, 0,1680,1050) res. is 96.000 x 96.000 ppi Screen 1 ( 0, 0,1680,1010) res. is 96.000 x 96.000 ppi Ubuntu test/hello Screen 0 ( 0, 25,1680, 935) res. is 96.108 x 91.342 ppi Cygwin/X11 test/hello Screen 0 ( 0, 0,3360,1050) res. is 0.000 x 0.521 ppi Note that the screen dimensions are reported correctly according to the Windows/X server setup (I'm not absolutely sure about the Linux VM's hight value, however: 935 is the desktop's height value w/o WM areas). This is the responsible code in screen_xywh.cxx: int mm = DisplayWidthMM(fl_display, fl_screen); dpi[0] = mm ? Fl::w()*25.4f/mm : 0.0f; mm = DisplayHeightMM(fl_display, fl_screen); dpi[1] = mm ? Fl::h()*25.4f/mm : dpi[0]; Both functions Display*MM return _nonsense_ results on Cygwin/X11 (0 and 51200, resp.). No, I'll wait until tonight (probably 2100 CET). We will still need another RC with the new jpeg, png, and z lib. Okay, I think I'm ready for today. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: Developer and user documentation of FLTK's usage of #define's
I don't think that we currently have a clear documentation of FLTK's usage of compiler, OS, and FLTK's own #define's. Should I (we) try to write such docs, and where would be a useful place? Maybe in the OS-specific documentation chapter ? Or in the developer section? Here are some first thoughts: WIN32 is defined on Windows (32- and 64-bit) systems by FLTK, except if configured with --enable-cygwin --enable-x11. It is a synonym for we use GDI for drawing. __CYGWIN__ means that configure used --enable-cygwin. The resulting programs must be linked with the Cygwin dll (currently cygwin1.dll) and can use Cygwin's POSIX layer emulation on Windows. This is free for personal/internal use, but you need a special license from Redhat if you want to distribute your programs. __CYGWIN__ can be combined with WIN32, which means that FLTK still uses GDI for drawing. _WIN32 is defined by all (?) Windows compilers when compiling programs for Windows. The Cygwin (MinGW) compilers do also define it if you compile with -mno-cygwin (gcc 3) or use the MinGW cross compilers (gcc 4.x and later). It is not defined when compiling under Cygwin for use with the POSIX layer (Cygwin dll). _WIN64 is defined by all (?) Windows compilers when compiling programs for Windows for a 64-bit target. This can be combined with _WIN32 (for backwards compatibility). I don't know whether Cygwin defines this off the top of my head (I can check it). FLTK 1.3 always defines USE_X11 as 0 or 1, depending on the usage of X11 or not (in config.h). This is not defined in FLTK 1.1. More about __APPLE__, _MSC_VER, ... and its usage... Maybe also FLTK_HAVE_CAIRO, FLTK_USE_CAIRO, other HAVE_* ... Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Switch Fl_Secret_Input to Fl_Input
On 07.01.2011 18:05, Brad wrote: I am using Fl_Secret_Input to provide a field where users can type password sentences. I have a Fl_Button named 'View Sentence' that allows users to see (but not edit) the sentence they have typed. When they click 'View Sentence', a fl_message displays the sentence. I would like to toggle the Fl_Secret_Input field to a Fl_Input field so the user could more easily see and edit the sentence upon input errors. I've tired putting Fl_Secret_Input and Fl_Input in the same location and switching between them, but that does not seem to work. I thought someone on this list may have implemented something similar, so I wanted to ask here. Good idea to ask ;-) It's much easier than you thought. Fl_Secret_Input is derived from Fl_Input_, and you can set the type() to change its behavior. Here are the type definitions from the FLTK 1.3 docs (FLTK 1.1 is identical): #define FL_NORMAL_INPUT 0 #define FL_FLOAT_INPUT 1 #define FL_INT_INPUT 2 #define FL_MULTILINE_INPUT 4 #define FL_SECRET_INPUT 5 #define FL_INPUT_TYPE7 #define FL_INPUT_READONLY8 #define FL_NORMAL_OUTPUT (FL_NORMAL_INPUT | FL_INPUT_READONLY) #define FL_MULTILINE_OUTPUT (FL_MULTILINE_INPUT | FL_INPUT_READONLY) #define FL_INPUT_WRAP16 #define FL_MULTILINE_INPUT_WRAP (FL_MULTILINE_INPUT | FL_INPUT_WRAP) #define FL_MULTILINE_OUTPUT_WRAP (FL_MULTILINE_INPUT | FL_INPUT_READONLY | FL_INPUT_WRAP) Basically you must set one of the type values in [0-5] and or this with FL_INPUT_READONLY if you need it. Just change the type() accordingly and call redraw(). You need only one widget. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2510: 'fluid -help' doesn't show anything on windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current FWIW, here are some interesting links: http://msdn.microsoft.com/en-us/library/ms682528%28v=vs.85%29.aspx http://www.halcyon.com/~ast/dload/guicon.htm The latter shows code how to create a console window and redirect standard i/o to the console. Such a solution could maybe be used for fluid -help Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
Manolo, unfortunately your patch doesn't work on Windows with Cygwin/X11
(configure --enable-x11).
fl_utf8towc() does /not/ convert to an array of unsigned, but wchar_t, and
this is only 2 bytes on Windows. Therefore we need the 16-bit variants of
the Xft-specific functions. I modified your patch (see attached file
fl_font_xft_as.diff), so that it takes care of this (I used wchar_t
instead of unsigned). Instead of the OP's sizeof() check I used
__CYGWIN__, because this is the only platform that (currently?) supports
X11 on Windows (and we can't use WIN32 here).
There's another case in utf8reformat() where your patch returns NULL, if
n==0. I don't think that we should return NULL here, because the returned
pointer would be used later (although this might never happen, but
anyway). My patch returns a pointer to an empty wchar_t string instead.
I tested my patch both on Windows (Cygwin with --enable-x11) and Linux,
and it worked for me. Please check if this is okay (at least it's better
than before).
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0Index: src/fl_font_xft.cxx
===
--- src/fl_font_xft.cxx (revision 8203)
+++ src/fl_font_xft.cxx (working copy)
@@ -358,6 +358,38 @@
// XftFontClose(fl_display, font);
}
+/* returns the string decoded into a series of Unicode characters.
+ n is set to the number of characters upon return.
+ Don't deallocate the returned memory.
+ */
+static const wchar_t *utf8reformat(const char *str, int n)
+{
+ static const wchar_t empty[] = {0};
+ static wchar_t *buffer;
+ static int lbuf = 0;
+ int newn;
+ if (n == 0) return empty;
+ newn = fl_utf8towc(str, n, (wchar_t*)buffer, lbuf);
+ if (newn = lbuf) {
+lbuf = newn + 100;
+if (buffer) free(buffer);
+buffer = (wchar_t*)malloc(lbuf * sizeof(wchar_t));
+}
+ n = fl_utf8towc(str, n, (wchar_t*)buffer, lbuf);
+ return buffer;
+}
+
+static void utf8extents(const char *str, int n, XGlyphInfo *extents)
+{
+ memset(extents, 0, sizeof(XGlyphInfo));
+ const wchar_t *buffer = utf8reformat(str, n);
+#ifdef __CYGWIN__
+XftTextExtents16(fl_display, current_font, (XftChar16 *)buffer, n,
extents);
+#else
+XftTextExtents32(fl_display, current_font, (XftChar32 *)buffer, n,
extents);
+#endif
+}
+
int fl_height() {
if (current_font) return current_font-ascent + current_font-descent;
else return -1;
@@ -371,7 +403,7 @@
double fl_width(const char *str, int n) {
if (!current_font) return -1.0;
XGlyphInfo i;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)str, n, i);
+ utf8extents(str, n, i);
return i.xOff;
}
@@ -397,7 +429,7 @@
return;
}
XGlyphInfo gi;
- XftTextExtentsUtf8(fl_display, current_font, (XftChar8 *)c, n, gi);
+ utf8extents(c, n, gi);
w = gi.width;
h = gi.height;
@@ -585,8 +617,13 @@
color.color.green = ((int)g)*0x101;
color.color.blue = ((int)b)*0x101;
color.color.alpha = 0x;
-
- XftDrawStringUtf8(draw_, color, current_font, x, y, (XftChar8 *)str, n);
+
+ const wchar_t *buffer = utf8reformat(str, n);
+#ifdef __CYGWIN__
+ XftDrawString16(draw_, color, current_font, x, y, (XftChar16 *)buffer, n);
+#else
+ XftDrawString32(draw_, color, current_font, x, y, (XftChar32 *)buffer, n);
+#endif
}
void Fl_Xlib_Graphics_Driver::draw(int angle, const char *str, int n, int x,
int y) {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Makefile and .phony
On 06.01.2011 07:58, Michael Sweet wrote: .PHONY: foo bar is a GNU extension, but fortunately is silently/safely ignored by make programs that do not support it. Thanks to you and all the others that replied. I got some ideas to improve the Makefile. Let's see... Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2506: examples/table-sort.cxx won't compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2506 Version: 1.3-current Fix Version: 1.3-current Greg wrote regarding WIN32 vs. _WIN32: Hmm, I'm thinking example code probably shouldn't assume special FLTK build flags are set, ... This is not a special FLTK /build/ flag, but /must/ be set for all FLTK programs on Windows (except as noted above for Cygwin/X11). You can see why if you run: $ grep WIN32 FL/* | grep '#.*if' Of course, the easiest way to achieve this is to use fltk-config --cxxflags, but Windows IDE users must use the #define in their project settings. Thus, all example programs should IMHO use the same defines to conform to FLTK coding standards. Another related question would be whether they are allowed to #include config.h. The answer is: no, because they should be independent of the build files, so that they can be copied to user code or be compiled independent of the library, as you mentioned above. Link: http://www.fltk.org/str.php?L2506 Version: 1.3-current Fix Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2509: FLUID crashes on MINGW 64 bit
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2509 Version: -current Link: http://www.fltk.org/str.php?L2509 Version: -current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2509: FLUID crashes on MINGW 64 bit
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2509 Version: 1.3-current This has probably been fixed in subversion rev. 8146 (2010-12-31), please see STR #2501. If you have subversion, please use a newer version. If you don't have subversion, you can download the fixed file here: http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/src/filename_absolute.cxx You can also use the next snapshot that will be created in about 8 or 9 hours (Friday, 09:00 UTC). Please verify that this fixes your problem, or post more information. Link: http://www.fltk.org/str.php?L2509 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2510: 'fluid -help' doesn't show anything on windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current I never realized that fluid -c doesn't run serially. Now that you say it, yes it may be under Windows... I wonder how make works when generating the source and header files in the test/ directory. If we made fluid a console app, wouldn't we always get the ugly console window, even if we use it interactively? ... Yes, I just tested it, that's really bad. Option b) appears more appropriate IMHO. Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2510: 'fluid -help' doesn't show anything on windows
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current Well, thinking about fluid -c: fluid doesn't background itself when run from a Cygwin shell and probably not in a MinGW shell (both are usually bash shells). However, it does when run from a Windows CMD shell. Link: http://www.fltk.org/str.php?L2510 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.development] Makefile and .phony
I used .phony in documentation/Makefile to force generation of the doc files manually independent of (not defined) dependencies. I couldn't find another example in our Makefiles and wonder whether this is standard or a GNU make extension. I could not find it on the web. Does anybody know? If it's not standard, how can we achieve the same with standard make? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Makefile and .phony
On 05.01.2011 18:28, s...@sjssoftware.com wrote: I used .phony in documentation/Makefile to force generation of the doc files manually independent of (not defined) dependencies. Albrecht, is this what you're looking for? http://www.gnu.org/software/automake/manual/make/Phony-Targets.html No, but thanks, I knew the gnu make docs... I'm pretty sure this feature is specific to GNU, though I believe some other make's have something called .force which is the same thing IIRC. (Is there a standard make? I think not). Well, maybe not, but I think we try to use only features that are supported by most (if not all) make tools. In any case, using it should be pretty harmless. It will work as intended if the feature is supported; if not, it will do the right thing unless the user has a file called .phony lying around. Hmm, sounds good. However it's not the file .phony, but the real target (in this case html and pdf). And html is also the directory that is created by doxygen. :-( This works only with .phony and if .phony does what it's supposed to. It's different with the current pdf target. I deliberately used another target refman.pdf that will not really be created in the current directory (it's in latex/), and this ought to work unless someone creates it in the current directory. Okay, I'll leave the html target as it is, but I also added refman.pdf to the 'clean' target, just to be sure that 'make clean pdf' works as expected. Unless I read other comments, I'll also leave .phony in the Makefile. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Makefile and .phony
On 05.01.2011 18:45, Duncan Gibson wrote: You can probably get what you want by having a dependency on a file that never exists: ... Thanks, I partially did this already (see other reply: refman.pdf). To be sure you can always do 'make clean dist', and this ought to work as expected. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2506: examples/table-sort.cxx won't compile on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2506 Version: 1.3-current Fix Version: 1.3-current Greg, I saw that this demo uses _WIN32 instead of FLTK's define WIN32. This should probably be corrected as well. To Teun's suggested patch and your comments: __CYGWIN__ is only defined if we are compiling _for_ Cygwin, i.e. with its dll and POSIX layer (configure --enable-cygwin). In this case you can assume to have ls and other Unix tools. WIN32 is defined if we use GDI (with or w/o Cygwin/POSIX), but not if we use Cygwin/X11 (and the latter includes the POSIX layer, of course). Cygwin/X11 is always handled like Unix/X11 in FLTK code. Link: http://www.fltk.org/str.php?L2506 Version: 1.3-current Fix Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current The macros in CMake are identical to those used in configure.in etc.. It's all the same for configuring the CMake build and fltk-config etc. as is done in configure.in and similar .in files. That said, I'm wondering why we have USE_CAIRO in the first place. Reading the comments makes me believe that this is copied from FLTK 2 with the *intent* to add a full-blown Cairo rendering option in the future. Now, with FLTK 1.3's Fl_Device scheme, this will probably be solved differently anyway. But if we want to change it (and I vote +1 for changing), I suggest to use the usual FL_ prefix (i.e. FL_HAVE_CAIRO and FL_USE_CAIRO) and modifiy all source files. That's just a bunch of work, but probably easy to do... Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2505: Xft backend doesn't filter bad UTF-8 characters
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Yes, I think that's right. The OP wrote: ... by doing a UTF-8 to UCS-2/UCS-4 conversion, which has the side effect of filtering the string. That's true, and I tested it with an application that uses ISO-8859-1 for all data (text) internally. The appearance is much more like it is with the Windows version. But there's a difference: on Windows we _must_ convert all strings from UTF-8 to the hosts wchar_t format to do Unicode rendering, on Linux we don't need to do it (basically). So what happens is that we lose speed for something we don't need to do if all text is correct (UTF-8). :-( OTOH, as mentioned above, we _do_ convert all strings on Windows, and this has the same speed loss, so it might be negligible. Maybe? My tests showed some problems with rendering of non-UTF-8 text (similar to misc/iso-8859-1.txt), so I'll need more time to test... Technical remarks to the provided patch: - As seen recently, we must not allocate dynamic arrays like wchar_t wstr[n + 1]; - we must malloc() or new (and free/delete) dynamically sized data for compatibility reasons with old compilers. - As Ian said, the runtime sizeof() comparisons are probably not needed, and we don't need to convert the string if we use it later in the else case as-is. That should be improved, if we agree to apply it. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2504: HAVE_CAIRO macro in installed header
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current I vote for just changing the macro names (and all source files that use them :-( ), and that's enough to close this STR. Everything else must be done anyway when we clean up the Fl_Device hierarchy and separate source files for different platforms and so on... Link: http://www.fltk.org/str.php?L2504 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [fltk.commit] [Library] r8186 - branches/branch-1.3
On 04.01.2011 20:14, Matthias Melcher wrote: On 04.01.2011, at 20:06, fltk-dev@easysw.com wrote: Author: AlbrechtS Date: 2011-01-04 11:06:02 -0800 (Tue, 04 Jan 2011) New Revision: 8186 Log: Fixed a typo and an error. We must not use make html-dist for distribution. This Makefile tag is misleading and should be corrected. Hmm. What is it for then? I'm just writing something about _that_ in another post, I'll send it soon. I do remember that we introduced pdf-dist, which should probably be removed then as well since we are distributing the docs separately? I'll also write something about this in the mentioned post. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] makesrcdist and documentation/Makefile
On 04.01.2011 20:06, fltk-dev@easysw.com wrote: Author: AlbrechtS Date: 2011-01-04 11:06:02 -0800 (Tue, 04 Jan 2011) New Revision: 8186 Log: Fixed a typo and an error. We must not use make html-dist for distribution. This Makefile tag is misleading and should be corrected. To elaborate on this: We used this special tag to run strip_tags on the generated html files to minimize updates (date changes) for svn upload of the web docs. The distributed docs should carry the correct date (see strip_tags). We can probably remove this. We had different Makefile tags because strip_tags would run *too* long for daily use on Cygwin and maybe other older systems. Additionally the html docs should always be generated *after* the pdf docs, because they use the same html/ subdirectory, but use a different doxygen file (Doxyfile with vs. Doxybook w/o frame). If you do it in the wrong order, then the html/ directory may include the non-frame version of the doxygen docs :-( I also believe that we should use make clean html to ensure that the html documentation will be cleaned and generated, because of the only dependency on the html/ directory. That's not yet perfect. Yes, I just tested it, and so it is... Now that you removed documentation/fltk.pdf from svn :-) we can change make pdf to move documentation/latex/refman.pdf to documentation/fltk.pdf again (and remove pdf-dist). This had been done only in pdf-dist), because the generated file would overwrite the subversion file, and this was problematic for commits. The correct way to generate the docs with current svn ought to be: cd documentation make clean pdf-dist make clean html For now: be careful... Shall I try to clean up this mess? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] makesrcdist and documentation/Makefile
On 04.01.2011 20:44, Matthias Melcher wrote: On 04.01.2011, at 20:32, Albrecht Schlosser wrote: The correct way to generate the docs with current svn ought to be: cd documentation make clean pdf-dist make clean html For now: be careful... Shall I try to clean up this mess? Yes, that would be great. You seem to be much more involved than me. Okay, will do. BTW: do you have concrete plans for RC3, or do we first fix all current bugs? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] 1.3.0rc2 installation issue
On 01.01.2011 23:35, Matthias Melcher wrote: On 01.01.2011, at 23:28, Kai-Uwe Behrmann wrote: I get following error with fltk-1.3.0rc2-source.tar.gz : ... Installing documentation files in /opt/local/share/doc/fltk ... Installing fltk.pdf in /opt/local/share/doc/fltk ... /usr/bin/install: Aufruf von stat für „fltk.pdf“ nicht möglich: Datei oder Verzeichnis nicht gefunden Hope that makes sense, Yes. I believe it was fixed in the last hours of 2010. Could you try the current SVN? ... but in the SVN repository, documentation/fltk.pdf exists (currently it is /removed/ in the disribution files. should be in fltk.development Matt, I believe it's time to remove documentation/fltk.pdf from subversion. The new packaging looks okay so far. Do you agree? BTW.: It's also in the snapshots, until we remove it from svn. /should be in fltk.development Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] RFC: Update libpng and libjpeg to currentversions?
On 01.01.2011 01:21, Michael Sweet wrote: Any objections to me updating libpng and libjpeg to the current versions for FLTK 1.3? The current versions are a bit long in the tooth (libpng is currently 1.4.5 vs. 1.2.40 and libjpeg is currently 8b vs. 6b) and are missing some functions my programs normally use... +1 on updating the libs. What about zlib? libpng depends on zlib (1.2.5 or later recommended for performance and security reasons), and our version is 1.2.3. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r8151 - branches/branch-1.3/documentation/src
On 01.01.2011 05:42, fltk-dev@easysw.com wrote: Author: matt Date: 2010-12-31 20:42:56 -0800 (Fri, 31 Dec 2010) New Revision: 8151 Log: A bunch of documentation updates. Not sure if I found everything. The Unicode section needs some love. Modified: branches/branch-1.3/documentation/src/preface.dox ... @@ -63,11 +63,15 @@ ... -\par MacOS -The Apple Macintosh OS 8.6 and later, including OS X. +\par OS X,tt__APPLE__/tt +The Apple desktop operating sytem OS X 10.0 and later. MacOS 8 and 9 support +was dropped after FLTK 1.0.10. This should probably be FLTK 1.1.10 (or 1.1.11?) Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [HIGH] STR #2501: fluid -c crashes on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2501 Version: 1.3-current I can't reproduce this here. Neither with nor w/o X11, both compile and run smoothly (svn r 8145, win 7, Cygwin 1.7.x). I tested Linux as well and can't find a problem. I also took a /short/ look at the code, and it /seems/ that cwd can't be NULL at line #265. Are you sure you didn't mix up your installation somehow? OTOH, this _has_ been changed recently (r8063-r8066)... Link: http://www.fltk.org/str.php?L2501 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2501: fluid -c crashes on cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2501 Version: 1.3-current I saw your latest message only after mine, so here is my Cygwin version for comparison: CYGWIN_NT-6.1-WOW64 mypc 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Link: http://www.fltk.org/str.php?L2501 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [HIGH] STR #2500: fltk.list.in (EPM) is outdated
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2500 Version: 1.3.0 I set the priority to 4 - High, because this probably should be fixed before the final 1.3.0 release. AFAICT fltk.list.in is used by EPM to create the files needed for RPM and/or other packaging systems that may be used by software distributions like Linux. I have no idea how to fix all this. fltk.spec.in should be checked as well, but is maybe not concerned. Some notes (probably incomplete) regarding fltk.list.in: (1) Symlinks to handle common case problems... ... should only be installed if configured with --with-links (1a) The links are probably not complete, new header files have been added in FLTK 1.3. (2) Documentation would be installed in old FLTK 1.1 style (no files). This needs to be adjusted. (3) Examples: unfortunately the test/* files are installed in $docdir/examples. Do we intend to install examples/* as well, and if so, where? Link: http://www.fltk.org/str.php?L2500 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2165: fluid interface drawing problems (Linux + XFT)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2165 Version: 1.4-feature I fixed about_panel.fl (only) by enlarging the boxes and the whole window to accommodate the increased text sizes with XFT fonts. This is not intended to be a complete solution, but only to fix the prominent about_panel display issues (svn r 8144). Link: http://www.fltk.org/str.php?L2165 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2172: Fl_Input: word movement not working (mac/unix/win)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2172 Version: 1.4-feature I believe that this has been fixed for Fl_Input and friends. Greg? Is Fl_Text_Editor still an issue? Link: http://www.fltk.org/str.php?L2172 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [WWW] r586 - trunk/phplib
On 29.12.2010 05:00, fltk-dev@easysw.com wrote: Author: mike Date: 2010-12-28 20:00:52 -0800 (Tue, 28 Dec 2010) New Revision: 586 Log: Fix DOCTYPE ... Modified: trunk/phplib/html.php === --- trunk/phplib/html.php 2010-12-29 03:56:18 UTC (rev 585) +++ trunk/phplib/html.php 2010-12-29 04:00:52 UTC (rev 586) @@ -149,7 +149,7 @@ header(Cache-Control: no-cache); print(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.0 Transitional//EN\ According to http://www.w3.org/QA/2002/04/valid-dtd-list.html this should read ... HTML 4.01 Transitional... Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Missing files in RC1 (currentfltk-1.3.0rc1-source.tar.gz)
On 29.12.2010 16:18, Matthias Melcher wrote: On 29.12.2010, at 13:24, Albrecht Schlosser wrote: I downloaded and compared the newest fltk-1.3.0rc1-source.tar.gz, and there seem to be some missing files. ... RC2 looks okay now, thanks. I checked again and found only these /expected/ results: $ diff -ru fltk-1.3-svn-r8139 fltk-1.3.0rc2|sort Only in fltk-1.3.0rc2: configure Only in fltk-1.3.0rc2: fltk.spec Only in fltk-1.3-svn-r8139/documentation: fltk.pdf Only in fltk-1.3-svn-r8139: makesrcdist Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [WWW] r586 - trunk/phplib
On 30.12.2010 16:23, Michael Sweet wrote: On Dec 30, 2010, at 8:19 AM, Albrecht Schlosser wrote: print(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.0 Transitional//EN\ According tohttp://www.w3.org/QA/2002/04/valid-dtd-list.html this should read ... HTML 4.01 Transitional... Unfortunately, using HTML 4.01 causes many browsers to change their default table rendering which messes up the fltk.org pages. The issue is the use of the outer page table (header, body, footer) with the middle (body) row at 100% height. I've never found an acceptable workaround over the years aside from sticking with HTML 4.0. Thanks for the explanation, that's really bad. I've also sometimes found issues where doing something the non-standard-conforming way worked better with different browsers. :-( Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Clean FLTK installation for CMake on Windows
On 30.12.2010 12:07, Julia Jacobson wrote:
Building FLTK on Windows with Visual C++ worked fine for me.
However, I can only build a FLTK GUI project using CMake if I use absolute
PATHs in my CMakeLists.txt file, which looks like this:
SET(FLTK_DIR C:/Program Files/fltk-1.1.9/)
SET(FLTK_BASE_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_FORMS_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_GL_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_IMAGES_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_INCLUDE_DIR C:/Program Files/fltk-1.1.9/include/)
SET(FLTK_SKIP_FLUID TRUE)
FIND_PACKAGE(FLTK REQUIRED)
if( FLTK_FOUND )
include_directories( ${FLTK_INCLUDE_DIR} )
add_executable( hello main.cpp )
target_link_libraries( hello ${FLTK_LIBRARIES} )
else( FLTK_FOUND )
message(FATAL_ERROR Could not find FLTK)
endif( FLTK_FOUND )
If I don't use absolute PATHs, CMake laments an unsuccessful search for the
FLTK files.
The whole process works fine under linux, but I would like to have a portable
FLTK GUI project.
I think this is probably no only a CMake issue, but rather to the way I
installed FLTK: Except for building it with Visual C++, I did nothing else
like for example adjusting the Windows PATH variable and so on.
How can I install FLTK on Windows in a way that CMake can automatically find
it?
I really don't know how to do it, but maybe I have some hints that
could help.
The main point would be to find out how FINDPACKAGE(FLTK ...) works
on Windows. I have no idea and can't check it now. AFAIK this is
contributed by CMake, so you might find it somewhere.
Once you found out how it works, you could maybe install your
built FLTK libs, dlls, header files so that FINDPACKAGE can find
them...
Note that this (usage of FINDPACKAGE) has changed significantly in FLTK
1.3, but there is a README file how to use FLTK with CMake. But don't
expect too much, this may not help you either. As Ian said, we don't
have CMake experts in our developer team.
If you can't find a way to do it directly (with FIND_PACKAGE), you
could still make a more portable CMake file by using something like
this (just a little guessing, not tested):
if(WIN32)
SET(FLTK_DIR C:/Program Files/fltk-1.1.9/)
SET(FLTK_BASE_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_FORMS_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_GL_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_IMAGES_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_INCLUDE_DIR C:/Program Files/fltk-1.1.9/include/)
SET(FLTK_SKIP_FLUID TRUE)
SET(FLTK_FOUND TRUE)
else
FIND_PACKAGE(FLTK REQUIRED)
endif(WIN32)
...
If nothing helps, you can also add a CMake option to configure the
Windows path you need and use it instead of the hard-coded strings
above.
HTH
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Clean FLTK installation for CMake on Windows
On 30.12.2010 19:15, Julia Jacobson wrote: The main point would be to find out how FINDPACKAGE(FLTK ...) works on Windows. Once you found out how it works, you could maybe install your built FLTK libs, dlls, header files so that FINDPACKAGE can find them... Yes, that was really the point. CMake finds the path of the FLTK installation solely by location the fluid executable and sets the path of the libraries and include files relative to the fluid executable. That's why helping CMake to find the fluid executable solves the problem. Thanks for the feedback, that's good to know. Sorry for the noise and thanks for your help. You're welcome, and there's no reason to apologize. You had a problem, found the solution, and you gave us feedback, so that we have the solution in the news group for the future. Thanks. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] Missing files in RC1 (current fltk-1.3.0rc1-source.tar.gz)
On 28.12.2010 02:14, fltk-dev@easysw.com wrote: Author: matt Date: 2010-12-27 17:14:30 -0800 (Mon, 27 Dec 2010) New Revision: 582 Log: Slightly new scheme: all is compressed in tar.gz, and html and pdf are uploaded separatley +87aa8e940a25e4605d0d8d981f9f1ffd 1.3.0rc1 fltk/1.3.0rc1/fltk-1.3.0rc1-docs-pdf.tar.gz +66f9369b151b354e5377cd0e57bf349e 1.3.0rc1 fltk/1.3.0rc1/fltk-1.3.0rc1-docs-html.tar.gz +dfbdaaadfce2ca48002946ea920a01b0 1.3.0rc1 fltk/1.3.0rc1/fltk-1.3.0rc1-source.tar.gz I downloaded and compared the newest fltk-1.3.0rc1-source.tar.gz, and there seem to be some missing files. Note that the top directory is 'fltk-1.3svn'. Really missing files: documentation/Doxybook documentation/Makefile documentation/README forms.h install-sh ... and two complete directories: examples GL Matt, I wonder how you packed the files. And for the future: +1 for this packing scheme, as discussed previously in fltk.development. Did you change makesrcdist locally, and will this be updated in svn? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Missing files in RC1 (currentfltk-1.3.0rc1-source.tar.gz)
On 29.12.2010 16:18, Matthias Melcher wrote: +1 for this packing scheme, as discussed previously in fltk.development. How it is online now? As above? Or a different one? As it is online now, or maybe also only one documentation file with both HTML and PDF included. I personally don't know if .tar.gz is enough, but if we can make one, we can also make all three usual packings/compressions. I don't know what to do, maybe try with only .tar.gz and wait for complaints? ;-) Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [HIGH] STR #2328: fltk-1.3.0-r7246 Build broken on fedora 12 by fluid.desktop
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 Fix Version: 1.3-current (r7830) Fixed in 1.1.11 as well (r 8119), but fluid.desktop only (no README files). Link: http://www.fltk.org/str.php?L2328 Version: 1.3.0 Fix Version: 1.3-current (r7830) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] Preparing 1.3.0rc1 - do we keep the PDFdocumentation?
On 27.12.2010 16:38, Matthias Melcher wrote:
composing the FLTK 1.3 archive I saw that it doubled in size, because we
include the PDF documentation. Should we keep it that way? It's kind of
bulky, but the docs are right there for the developers... .
;-) First of all, it should be up-to-date.
Shall I update it, an shall we package rc2 ? ;-)
Honestly: I never liked the big PDF file in the distribution and in
subversion, but I think we need it until we find another proper
solution.
My idea: if we could provide a 'parallel' documentation package, as
some Linux and other distros with different source, binary, and
documentation packages, then I vote +99 for this solution.
We would need a way to upload the documentation file(s), and they must
be integrated in the download area. The reason is that they must have
the same version as the sources. If we could manage this, then I
suggest that we package the generated HTML docs as well, maybe
in the same fltk-1.3.x-doc.{zip|tar.gz|tar.bz2) file.
The optimal solution would also generate snapshot files, but I believe
that we would need Mike's assistance for this and maybe also for the
upload mechanism, unless this would already work with the distribution
upload mechanism.
Oh, and we should be able to generate the website docs on the server,
so that we don't need to put the doxygen'erated html files in svn. ;-)
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Preparing 1.3.0rc1 - do we keep thePDFdocumentation?
On 27.12.2010 18:28, Matthias Melcher wrote: Well, I knew that not everything would be 100% for RC1, so if you'd please repack and commit it? I put an updated PDF file in subversion, updated the dependencies, and I also uploaded the current docs to the web site. I'll leave packing rc2 to you, though (never did it, and this is not the right time to try). Do we need to provide three different compression methods, or can we limit this to a single one? I think that by now, every platform supports .zip, even for the hard-core open source addicts. I often see that the zip files have Windows (CR/LF) line endings, whereas the others have Unix (LF) line endings, but this would only matter for the html files. Or is this a feature of the unpacking program... ? Oh, and we should be able to generate the website docs on the server, so that we don't need to put the doxygen'erated html files in svn. ;-) That would be nice. Mike? If it would be easier or even better, we could also generate and pack the documentation files on the developer's local machine, upload the file, and only unpack it to the documentation dir with the help of a server-side command, like it is done with the svn up commands etc. This way we wouldn't need doxygen and all that on the server, and the developer could check the docs before uploading. However, this wouldn't work for snapshots. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] fltk and Fluid under Ubuntu 10.04 lts
On 27.12.2010 01:01, Greg Ercolano wrote: Derek Prowse wrote: I have all installed with Synaptic Package Manager, I didn't do anything fancy, but I can't launch FLUID from Applications/Programming/ menu. I get an 'Error' message box with this disheartening information. I just tried 'apt-get install fluid' (the equiv of using Synaptic) on Ubuntu 8.04 and can replicate. Yes, it seems the folks who made the 'fluid' package did it incorrectly. I don't think any of us on the FLTK team manages that package; someone downstream from us did it. We don't manage the package, but we have the file fluid/fluid.desktop, and we fixed it in FLTK 1.3 (STR #2328, svn r 7830). Anyway, problem seems to be with this file: $ more /usr/share/applications/fluid.desktop [Desktop Entry] Name=FLUID Comment=FLTK GUI Designer TryExec=fluid Exec=cd %D fluid %F-- PROBLEM HERE ... changed to: Exec=fluid %F in svn r8119 (FLTK 1.1.11). This will hopefully propagate to the package managers *if* they create a new FLTK 1.1.11 package, otherwise it should be okay for FLTK 1.3.0. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Remove image dependencies ? [was: Re: [Library] r8091 - in branches/branch-1.3:FLdocumentation/src]
On 26.12.2010 19:12, Greg Ercolano wrote: Opinions on automating the creation of the IMAGEFILES via IMAGEFILES=$(shell find ..) vs. removing the macro completely? +1 for removing. I figure if automated it's no longer a maintenance issue, and retain the dependency that rebuilds docs when a doc image changes. Could be useful if we ever automate doc creation. Only if we also had dependencies for all the source and header files with doxygen docs. Otherwise it's /really/ useless. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2479: Fl_Input: drop emacs editing keys, use 'standard' (Fl_Text_Editor for reference)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2479 Version: 1.3-current Fix Version: 1.3-current (r8067) Thanks for the correction concerning Mac OS X. I just tested on Windows with a FLTK program that has a global shortcut CTRL/ALT/F. This works, but if I set the same key combination on a desktop shortcut, then this application is started, and my FLTK application doesn't get the key combination at all. Didn't test on Linux though. Link: http://www.fltk.org/str.php?L2479 Version: 1.3-current Fix Version: 1.3-current (r8067) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [Library] r8113 - in branches/branch-1.3: . FL ide/Xcode3 ide/Xcode3/FLTK.xcodeproj src test
On 23.12.2010 15:24, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2010-12-23 06:24:29 -0800 (Thu, 23 Dec 2010)
New Revision: 8113
Log:
Adopted use of FL_LIBRARY #define symbol under Mac OS X. This allows to
compile
client applications without including Mac OS system headers, ...
Fine, changes look good, but there's one small thing I don't understand.
Maybe some testing relic ?
You change in src/Fl.cxx:
Modified: branches/branch-1.3/src/Fl.cxx
===
--- branches/branch-1.3/src/Fl.cxx2010-12-23 09:49:57 UTC (rev 8112)
+++ branches/branch-1.3/src/Fl.cxx2010-12-23 14:24:29 UTC (rev 8113)
@@ -667,7 +667,7 @@
*/
void Fl::first_window(Fl_Window* window) {
if (!window || !window-shown()) return;
- fl_find(fl_xid(window));
+ fl_find( Fl_X::i(window)-xid );
}
And you add in src/Fl_cocoa.mm:
Modified: branches/branch-1.3/src/Fl_cocoa.mm
===
--- branches/branch-1.3/src/Fl_cocoa.mm 2010-12-23 09:49:57 UTC (rev
8112)
+++ branches/branch-1.3/src/Fl_cocoa.mm 2010-12-23 14:24:29 UTC (rev
8113)
@@ -3266,6 +3266,11 @@
return CGRectMake(x, y, w 0 ? w - 0.9 : 0, h 0 ? h - 0.9 : 0);
}
+Window fl_xid(const Fl_Window* w)
+{
+ return Fl_X::i(w)-xid;
+}
+
#endif // __APPLE__
AFAICT fl_xid is declared inline on other platforms, thus I suggest
to leave it as is in Fl.cxx, but maybe there is a difference on Mac OS,
or is it only a testing issue that you forgot to revert? I don't have
a Mac here, so I can't test.
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [Library] r8113 - in branches/branch-1.3: . FL ide/Xcode3 ide/Xcode3/FLTK.xcodeprojsrc test
On 23.12.2010 17:24, Manolo Gouy wrote: I had to stop declaring fl_xid inline under OS X because the class Fl_X is not part of the public API, whereas fl_xid() is. This explains why I added fl_xid() to Fl_cocoa.mm. okay, I see The Fl::first_window() function is the single instance in all of FLTK that calls fl_xid(). Oops, I found 53 hits in 17 different files in src/*.c* $ grep fl_xid src/*.c* | wc -l 53 $ grep fl_xid src/*.c* | cut -f1 -d':' | sort -u | wc -l 17 Not to loose in efficiency with the loss of inlining, I have replaced it by its equivalent. This explains the change in Fl.cxx. Okay, but the original looks cleaner ;-) In sum, these changes are quite volontary. I have checked that make builds under Linux and MSWindows, and make+CMake+Xcode builds under Mac OS X all run smoothly. Tested Linux and Windows 'make' builds as well, so I'm okay with it, but let's leave the others as is ;-) Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK 1.3 and Cairo :(
On 23.12.2010 16:37, Slick Dealer wrote: However, if I ./configure --enable-cairo and then make I get a cryptic error message saying - Linking cairo_test... /usr/bin/ld: cannot find -lpixman-1 collect2: ld returned 1 exit status make[1]: *** [cairo_test] Error 1 make: *** [all] Error 1 Can someone please guide me in installing FLTK with cairo enabled? Do I have to install any additional library ? Is there a way to bypass installing the library in the /urr/bin directory (I am testing FLTK in my home directory and would prefer installing any additional libraries in my home directory) You must install a package or something your distro knows that's called pixman-1. I'm not sure why this is needed, but anyway... Should probably be documented somewhere. Cairo also need pkgconfig, IIRC. Note that Cairo support is very limited. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] FLTK on OSX to compile with non-Apple G++ (patchincluded)
On 22.12.2010 08:34, Manolo Gouy wrote: This FL_LIBRARY may be exactly what is needed to solve cleanly this issue. But what exactly is it used for at this point ? I see it set ONLY in src/CMakeLists.txt. Does it mean that not any makefile use it ? It would be useful for this issue if FL_LIBRARY is defined when compiling the library, but not when compiling an application that uses the FLTK public API. Is it possible to use it this way? Please see followup in fltk.development... Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
