Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
imacarthur wrote: On 29 Sep 2008, at 19:14, matthiasm wrote: I won't go into detail, but it is enough to know that there are illegal sequences, for example, ös in ISO genrates a byte sequence that would be illegal in utf8. Maybe MSWindwos and OS X recognize illegal sequences and assume ISO encoding. There is an attempt, of sorts, in the fltk code to catch some of these illegal sequences and assume they are from ISO-8859-1 or CP1252 (see the relevant macros in fl_utf.c) which is enabled by default. Without looking at the code again, that's what I remembered from testing your utf-8 patch, and that's why I thought it should work somehow, at least if the input string is ISO/CP 1252. I suspect this doesn't work all that well, particularly on linux/XFT, where I suspect that this workaround is partly inhibited by my decision to render the text strings using XftDrawStringUtf8() directly. Ah, meanwhile I checked that I use xft on linux. I'll try again without, just to see what happens. However, I have not looked at this in any real detail, and I don't have the time just now... If, for example, the text renders OK in fltk/linux/non-XFT, then my theory may have some merit. But, if it is equally broken in builds either with or without XFT enabled, then Something Else is going on, and I really have no idea right now what! The correct way though would be to convert all source files from ISO to UTF8. Oh yes. Yes, I'll have to do that when I decide to go productive with FLTK 1.3. Albrecht's concern, I think, was that his server's wouldn't understand utf-8 (presumably for paths or filenames) so there can be issues there also. I think this works OK for me since all may filenames and paths are ASCII, and ASCII==utf8 for the range of characters my language uses, but I can see that if your paths or filenames include character values outside the base 127 ASCII values, then the utf8 mapping might be, erm, less convenient. My problem is not a file server. My main app is a client that communicates with a server, and the user does all data entry with this client app. Thus, all text data (from widgets derived from Fl_Input, Fl_Text_Editor, and some more) would have to be converted. But I was aware of that anyway, I only wanted to make some tests without string conversion, and it worked on Windows, but failed on Linux. That seemed strange, but since there are different fonts, I'll have to test more. Yesterday I tested with test/utf8, and I could display utf-8 chars in different fonts, even this RTL (?) text on the left side, #5 and #6. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
MacArthur, Ian (SELEX GALILEO, UK) wrote: Anyway, what I was going to suggest is that Fl::get_system_colors() could maybe be extended to cover setting the xclass, to cover those cases where show() is called wrongly at initialisation. Would that help at all? Or something like Fl::set_window_class(MyWindowClassName) before calling show for the first time ? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
I suspect this doesn't work all that well, particularly on linux/XFT, where I suspect that this workaround is partly inhibited by my decision to render the text strings using XftDrawStringUtf8() directly. Ah, meanwhile I checked that I use xft on linux. I'll try again without, just to see what happens. If you were able to try a parallel build, one with XFT, and one without, then I'd very much welcome the feedback (although if you do find a problem I'll likely not be in a position to fix it all that soon!) aware of that anyway, I only wanted to make some tests without string conversion, and it worked on Windows, but failed on Linux. That seemed strange, but since there are different fonts, I'll have to test more. Fonts, and the set of glyphs they actually contain, is a bit of a pain. Some things appear *not* to work on Linux because the fonts tend to contain sets of glyphs targeted for specific languages, or language groups. This happens on Windows and OSX too, of course, but it is less obvious there because: - M$ provide a few pan-Unicode fonts that contain a much larger set of glyphs, making it less likely you'll hit a gap. - OSX ATSU incorporates a mechanism (off by default, but enabled in my fltk-utf8 port, despite being quite slow!) that tries to automatically substitute glyphs from a set of fallback fonts, if the current font does not provide the glyph you requested. Now, that last trick (auto font substitution) we sort of can do with XFT, or at least we could write some code that emulated that behaviour by creating a font set (at runtime) that covered the glyphs in the text to be rendered. I did a few experiments on this at the time, but left it out because I wasn't happy with what I'd done. I plan on going back to this. Eventually... Yesterday I tested with test/utf8, and I could display utf-8 chars in different fonts, even this RTL (?) text on the left side, #5 and #6. RTL - right-to-left, used for languages (Hebrew, Arabic, etc) that are rendered in the other direction. Other TLA's you'll often see looking at fonts are: LGC - Latin Greek Cyrillic, used to denote a font that contains glyphs intended to cover the majority of languages that use L, G or C characters. CJK - Chinese Japanese Korean, ditto, for C, J or K languages. -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fltk-1.3 configure error with mingw
Last night I was trying out Fabien's Cairo patch on my laptop under Vista (with Msys/mingw) and had a problem with the generated makeinclude file. I assumed this was finger trouble on my part and tweaked the makeinclude to work, but it happened again on this XP box, so I actually had a look. Turns out that the problem is in the makeinclude file, in the line defining CXXFLAGS. This line has two occurrences of -mno-cygwin but the second one, right at the end of the line, is preceded by a non-printable character, an SOH, or value 01. I *assume* (I have not checked) that this is actually being appended to the end of the include path for pixman, which is the last entry before the error. I didn't see the little hiccup on OSX or Linux, so may be specific to the mingw case? Not sure. Anyway, a little judicious editing and it all builds and runs nicely. -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fltk-1.3 --enable-cairo mode on winXP
Fabien (et al) Is it intended that the --enable-cairo option means the generated code always depends on Cairo? I had expected it would work like OpenGL does - if you use it, you need to link it in, but if you aren't using it, you don't. But, what I find is that if I build fltk-1.3 with --enable-cairo set at configure, then I have to link *everything* against Cairo, whether it is using Cairo or not. This seems like a bug to me, probably. Cheers, -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
MacArthur, Ian (SELEX GALILEO, UK) wrote: Anyway, what I was going to suggest is that Fl::get_system_colors() could maybe be extended to cover setting the xclass, to cover those cases where show() is called wrongly at initialisation. Would that help at all? Or something like Fl::set_window_class(MyWindowClassName) before calling show for the first time ? Albrecht Or something as Fl_Window::set_class(myClassName) would be IMHO even better in that case. We should be careful from now not to multiplicate (pseudo) global functions in Fl when there is not a good reason to do it. This class is really too populated ... In my cairo addon, I created a state class to limit the number of attributes and methods addons, also, I named the functions as Bill suggested first, but now I wonder if I should not move my static functions to Fl_Window too as the cairo addon granularity is the Window anyway. Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Or something as Fl_Window::set_class(myClassName) would be IMHO even better in that case. Yes. I wonder though - if the app has several windows, would we expect to set the window-class individually per window, or would it be a static such that setting it once sets it for all windows? (I'm starting to get confused about overloading the words window and class now - we set the window class using a member function of the Fl_Window class...) -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 --enable-cairo mode on winXP
Fabien (et al) Is it intended that the --enable-cairo option means the generated code always depends on Cairo? I had expected it would work like OpenGL does - if you use it, you need to link it in, but if you aren't using it, you don't. But, what I find is that if I build fltk-1.3 with --enable-cairo set at configure, then I have to link *everything* against Cairo, whether it is using Cairo or not. This seems like a bug to me, probably. Cheers, --=20 Ian Well, the problem is that I needed to add cairo functions calls in fltk internals and thus, the lib you link against in that case would need cairo at least each time you link with fltk which must be quite often :) There is a way to avoid that like adding a new cairo option in configure allowing or not fltk code instrumentation , even in that last case, we would need an fltkcairo lib module to make sure fltk lib is independent from cairo. Could be done if fltk internal cairo calls related functionality are disabled, any thoughts ? Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Or something as Fl_Window::set_class(myClassName) would be=20 IMHO even better in that case. Yes. I wonder though - if the app has several windows, would we expect to set the window-class individually per window, or would it be a static such that setting it once sets it for all windows? (I'm starting to get confused about overloading the words window and class now - we set the window class using a member function of the Fl_Window class...) --=20 Ian IMHO, as the window is already created but not showed from what I read of the current need, it could be a non static function. If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Yesterday I tested with test/utf8, and I could display utf-8 chars in=20 different fonts, even this RTL (?) text on the left side, #5 and #6. RTL - right-to-left, used for languages (Hebrew, Arabic, etc) that are rendered in the other direction. Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and behavior like this fl_rtl_draw() API. So I started to code back what was missing in our current 1.3 getting inspired from the original 1.1.9 code, but the result is that the label texts are all systematically, incorrectly shifted right making the label getting outside his related widget box when it should be inside like for standard buttons. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Fabien, sorry, I didn't read _exactly_ what you wrote. Adding a static Fl_Window member instead of Fl member, as I proposed, would of course do it. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Albrecht Since xclass is automatically set by Fl_Window::show(int,char**), why not store the string as a static member in Fl_Window as well (e.g. Fl_Window::default_xclass). Basically, when show(int,char**) is called it checks xclass(). Regardless if show(int,char**) creates a WM_CLASS from agv[0] or uses the string supplied by the user, e.g. o-xclass(foobar);, the value is saved in the static memember Fl_Window::default_xclass. I would guess that for 99.999% of the FLTK applications, default_xclass would be set from argv[0] by show(int,char**). Then, when Fl_Window::show() is called, if xclass is not set, the value from default_xclass would be used. This would ensure that every Fl_Window created by the application will have its WM_CLASS set. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] WM_CLASS property for fluid windows
Fabien Costantini wrote: Albrecht Schlosser wrote: Fabien Costantini wrote: If it is made clear that it could be intersting to get a default configurable class name for all windows created after a setting, then we could also add an Fl_Window static member... That's what I thought of and why I proposed this. If the current default would be to derive the class name from argv[0], then it would be useful to set a global default, but otherwise you're right and it should be a window property - with a useful default value... Albrecht Since xclass is automatically set by Fl_Window::show(int,char**), why not store the string as a static member in Fl_Window as well (e.g. Fl_Window::default_xclass). Basically, when show(int,char**) is called it checks xclass() ../.. Alvin IMHO, the advantage of using only static get/set methods is that we don't add a potentially unused attribute to the Fl_Window base class. This is also the drawback, and it should be analysed whether we should add both static method and window property methods. In all cases, it seems to be a good idea to have the static get/set methods. Fabien My suggestion was only to minimumally extend the current functionality. As of right now, the WM_CLASS is only set for the first Fl_Window created by the app (assuming Fl_Window::show(int,char**) is called. This handles the cases were xclass is set by the developer or, if not set, determined by argv[0]. However, all other Fl_Window's that are created do not have WM_CLASS set. My suggest is only to retain the string that was used. Then every other Fl_Window could use that same string (if xclass() has not been set otherwise). -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and behavior like this fl_rtl_draw() API. Yes, probably my fault - I gave up on QD when I did my utf8 port and switched to Quartz only. It was too hard to make it handle the Unicode properly, while Quartz was much easier, and I needed it working quickly... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version. The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Ian wrote: Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I=20 noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and=20 behavior like this fl_rtl_draw() API. Yes, probably my fault - I gave up on QD when I did my utf8 port and switched to Quartz only. It was too hard to make it handle the Unicode properly, while Quartz was much easier, and I needed it working quickly... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version.=20 The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. It's a good thing, but as we still support it in 1.3, it should work as before, even if not supporting utf8. I'll see what I can do to fix it. BTW I would really like to start helping in the utf8 add-on, the only thing is that I'd also like to see someone that is involved in the current modifications to please update the READ.fltk118-utf file to explain in it: - What is really done in the utf8 modification today (i.e: we don't fully support it, like the glyphs variable width placement in the text and so on, what is the Oksid ...) - What are the new inputs/output strings types expected in the process (we have to deal in fl_font_mac.cxx with UTF8,UTF16, char, UniChar,...) The UTF8 format is, from what I see, not complicated at all (at least it's encoding method), but I currently have difficulties to understand what is still to be fixed/enhanced in 1.3 For now I understand there must be 2 different functionalities: output an utf8 coded string in a text-related widget (like in the utf8 demo), input special characters to be encoded internally as utf8 (keyboard input modifications ?). It would greatly help to document the current 1.3 modifications and what is expected, so that any developer in the team could give a hand. Thanks, Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
MacArthur, Ian (SELEX GALILEO, UK) wrote: I suspect this doesn't work all that well, particularly on linux/XFT, where I suspect that this workaround is partly inhibited by my decision to render the text strings using XftDrawStringUtf8() directly. Ah, meanwhile I checked that I use xft on linux. I'll try again without, just to see what happens. If you were able to try a parallel build, one with XFT, and one without, then I'd very much welcome the feedback (although if you do find a problem I'll likely not be in a position to fix it all that soon!) Okay, I tested it on Linux with and without XFT, and I tested it on the Linux pc with local X display and with remote X display on my windows pc. There's no difference visible :-( All the Linux versions (with different fonts) I tested don't display ISO-8859-1 characters correctly (well, they don't convert them to utf-8 and display this correctly would be more precise, right?). The Windows version, however, does. I'll append two small png images: utf8-linux.png (gray) and utf8-windows.png (XP-default color, is it beige in english?). The two strings should display abcäöüßÄÖÜëxyz... - the first is ISO encoded, the second is utf-8. Albrecht inline: utf8-linux.pnginline: utf8-windows.png___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Albrecht Schlosser wrote: MacArthur, Ian (SELEX GALILEO, UK) wrote: I suspect this doesn't work all that well, particularly on linux/XFT, where I suspect that this workaround is partly inhibited by my decision to render the text strings using XftDrawStringUtf8() directly. Ah, meanwhile I checked that I use xft on linux. I'll try again without, just to see what happens. If you were able to try a parallel build, one with XFT, and one without, then I'd very much welcome the feedback (although if you do find a problem I'll likely not be in a position to fix it all that soon!) Okay, I tested it on Linux with and without XFT, and I tested it on the Linux pc with local X display and with remote X display on my windows pc. There's no difference visible :-( All the Linux versions (with different fonts) I tested don't display ISO-8859-1 characters correctly (well, they don't convert them to utf-8 and display this correctly would be more precise, right?). The Windows version, however, does. I'll append two small png images: utf8-linux.png (gray) and utf8-windows.png (XP-default color, is it beige in english?). The two strings should display abcäöüßÄÖÜëxyz... - the first is ISO encoded, the second is utf-8. Update: I just found out that I didn't really use Xft in my tests, because I didn't have the header files installed :-( (USE_XFT was always defined as 0, although I configured with --enable-xft). After installing the (debian) package libxft-dev, USE_XFT is defined as 1, and there are some xft-related warnings when compiling. Now there is a difference: the ISO string is now truncated at the first non-utf-8 character, i.e. it displays iso-8859-1: abc only, but the utf-8 string is still okay. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk-1.3 configure error with mingw
On 30 Sep 2008, at 14:32, Fabien Costantini wrote: Thanks Ian I'll check that ASAP, AFAIK, It worked well on osx, linux and win32 but i didn't check for mingw. Fabien, thanks for checking in the change for this - unfortunately, this time when I configure, I still get an SOH but this time it is after libpng12 rather than after libpixman-1... maybe it was always there as well and I never noticed... Sorry... -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On Mon, 2008-09-29 at 02:17 -0700, alain savelli wrote: Hello, I would like to know iof the last version of FLTK support Framebuffer. About a year and a half ago Nikita Egorov took the first steps in porting FLTK to DirectFB, I would like to continue that effort and see if it will get accepted into the FLTK. My main interest is building user interfaces for machines, FLTK provides a rich set of widgets and looks like it will crosscompile without too much trouble. I don't know how long it will take me, don't have a lot of experience with graphic software, but if others are interested it might help move it along. Hi, Ormund. Do you want to create a port for clean framebuffer or via using DirectFB's functions ? In fact, the most FLTK's features (except GL) are working properly with DirectFB. As I wished to put only minimal changes into the sources of FLTK so I've simply rewritten most of X11's functions used in FLTK :). You can take the version 1.1.9 from http://git.directfb.org. Read readme.dfb. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Fabien Costantini wrote: ... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version.=20 The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. It's a good thing, but as we still support it in 1.3, it should work as before, even if not supporting utf8. I'll see what I can do to fix it. Actually, I vote to drop QuickDraw support entirely. That interface (QuickDraw) is slower and buggier than Quartz, and is deprecated in 10.5. -- __ Michael Sweet, Easy Software Products mike at easysw dot com ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
