Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken?
Here's my 2 cents for helping to isolate from where it may come: 0. go to system prefs/users and check in the Startup/Open thumbnail that you don't have any booting software starting when you open a session. None. If you have any external usb or firewire controller device unplug it for the test. I was going to say none - but I just remembered that the sound i/o device on that box is Firewire (it's the box I use for a lot of my audio work, so has a reasonably decent sound interface.) 1. svn co into an empty install directory Done. 2. check in debug and release mode, as debug mode does not optimize code, if it's a sdk/compiler bug it may give a different result. Will do - debug modes an idea, will try that also. 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
Carlos Pita wrote: Hi all, I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. Because of its multi-window nature, fluid is not quite amenable to be tiled. Therefore, as there is no way to make it float instead, it becomes virtually unusable. One solution is to mark every window with the Fluid class, just as the main window already is. Usually tiling wms allow to define layout rules based on a window class/instance/name. Regards -Carlos I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). I don't know anything really about WM_CLASS other than I can use it in the compiz rules. From what I can see (using xprop), only the main fluid window has its class set as Fluid. All the other windows have no WM_CLASS? Does it make sense for windows to inherit the WM_CLASS of the main window? I know FLUID provides a field called X Class for Fl_Double_Window properties. I haven't use it though or even know if that is the same was WM_CLASS. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken
On 27.09.2008, at 19:23, imacarthur wrote: Has somebody modified the keyboard handling in Fl_mac.cxx ? It seems to be broken currently. Yes, I did. The implementation is not complete yet and fails below some(?) OS version. The advantage of my keyboard function will be an advanced handling on dead keys and international keyboards in general. The old version did not handle Alt-Key characters. I am very sorry that I do not have the time to take more care of the UTF8 version. Things in the job go crazy once more and we have a nasty deadline coming up :-/ Matthias http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 11:17, alain savelli wrote: I would like to know iof the last version of FLTK support Framebuffer. There is a version of FLTK 1.1 out there that supports framebuffers. There is no official release yet. 1.4 is a pretty good candidate for core developer supported framebuffers. http://robowerk.com/ ___ 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
Please file STRs for both issues, preferably with patches ;-) Thanks. On 29.09.2008, at 18:28, Alvin wrote: Carlos Pita wrote: I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)
On 23.09.2008, at 10:08, Duncan Gibson wrote:
I've just experimented with the new, improved fluid and was able to
add the doxygen comments for these static member variables, and then
to generate the html with some test text (may be changed by the
user).
One comment: on my first attempt I typed in the full doxygen comment
with delimiters (i.e. /** may be changed by the user */ and of
course
fluid enclosed this within extra /** and */. So could you change the
tooltip to add (/** and */ will be added) or strip /** and */ from
the comment text if needed?
Yes, I can see that that is a problem.
Earlier this summer I experimented with adding doxygen comments using
the normal fluid comment feature, and found that the code generation
doesn't always output the comments in the places where doxygen
expects.
This new doxygen comment feature looks much more promising and is a
lot
less awkward to use than New {Class, Function, Declaration} followed
by
New Comment, and then a lot of F2/F3 to move it in front of where it
was needed.
Thanks. The original comment implmentation had no Doxygen in mind. It
was based on the request the add a copyright message at the top and
bottom of the .fl, .H, and .cxx file.
http://robowerk.com/
___
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
On 24.09.2008, at 17:08, Albrecht Schlosser wrote: All fonts have the same problems, e.g. word - looks like: --- schließen - schlie?n Auflösung - Aufl?g größe: 98 - gr? 98 Well, unicode encodes characters in 32bit (currently only the lower 24 bits are used). utf8 is kind of a compression system that converts 24bit numbers into multiple 8bit numbers. To simplify life, characters 127 and below stay the same, wheter encoded in utf8 or not. Characters above 127 however describe different ways of compressing the original 24 bit character. 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. The correct way though would be to convert all source files from ISO to UTF8. http://robowerk.com/ ___ 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. __ Ormund ___ 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
matthiasm wrote: Please file STRs for both issues, preferably with patches ;-) Thanks. On 29.09.2008, at 18:28, Alvin wrote: Carlos Pita wrote: I'm not sure if I must report this as a bug, tell me so if it's the case. Most fluid windows don't play nice with tiling windows managers (wmii, awesome, dwm, xmonad, ratpoison) which depends on the class or instance of a window to be able to put it into a floating layer or layout. I have had a similar problem with FLTK apps and Compiz's animation rules. For example, from what I can tell, all windows in FLTK 1.3.x apps (incl. fluid itself) have a type of Unknown. As a result, FLTK windows do not follow the same animation rules as my other windows (KDE mostly). I have the same animation for all FLTK windows rather than different ones for dialogs, normal windows, etc. From using xprop, I believe the setting has to do with _NET_WM_WINDOW_TYPE(ATOM). http://robowerk.com/ I'm up for it, but I need a little clarification. I've checked the source and this is what I see: * When show(argc, argv) is called (in Fl_arg.cxx) for the first window of the application, a check is made to see if xclass() has been set. If not, argv[0] is used. I have tested this and, sure enough, if I make a symlink called turnip to my program, the WM_CLASS is set to turnip,Turnip. Now, my apps have their main(int,char**) created by fluid. I'm not sure what happens when the show() is called instead of show(int,char**). If someone can tell me, it would be greatly appreciated. * Should the xclass() of other Fl_Windows (and its derivatives) be automatically set when show() is called? That is, of course, if not already set? If so, what should it be set to: (1) The same as the first window? Is that valid? (2) Or a distinct name, something like first window xclass#xid of the Fl_Window being shown. For example, the automatic xclass code would create something like fluid#0xdeadbeaf, Fluid#0xdeadbeaf when the widget properties dialog is shown. -- 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
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. 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. 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. 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. -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FrameBuffer
On 29.09.2008, at 21:35, Ormund Williams wrote: 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. As I said earlier, we would like to have framebuffer support as part of FLTK. The recommended way of going this route would be to create a few patches for the existing FLTK 1.3 (or 2.1, if you should decide to go that path) and submit those to fltk.development. If you patches are good and code conforming, Mike will give you SVN (Subversion) access. You can then branch off your private copy, add framebuffer support, and keep it in sync with whatever is going on in the main brabch. When FB support works well enough, we can merge your code back into the main code and other coders can help you wrap the port up. It doesn't matter really how long this takes - we all are on a small budget time-wise. Its important that your code behaves nicely and plays well with the build systems. There is quite a bunch on knowledgable developers who can help you get started. Matthias http://robowerk.com/ ___ 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
On 29.09.2008, at 21:37, Alvin wrote: * When show(argc, argv) is called (in Fl_arg.cxx) for the first window of the application, a check is made to see if xclass() has been set. If not, argv[0] is used. I have tested this and, sure enough, if I make a symlink called turnip to my program, the WM_CLASS is set to turnip,Turnip. Now, my apps have their main(int,char**) created by fluid. I'm not sure what happens when the show() is called instead of show(int,char**). If someone can tell me, it would be greatly appreciated. Ah, I was wondering about that. The first show() call in an application always should be show(int,char**) for this and other reasons. I beleive it is in the docs somewhere, but I can see how easy it is to get that wrong. * Should the xclass() of other Fl_Windows (and its derivatives) be automatically set when show() is called? Yes, I think that is acceptable. If so, what should it be set to: (1) The same as the first window? Is that valid? Yes, I beleive that this is coded that way anyways, unless xclass() is set differently in a later call. If no class is given or show() is called, the window class will be FLTK (at least in MSWindows). It would probably be better to use the filename instead, but since argv[0] is not accessable here, we would have to go another route (plus argv[0] is not always valid anyways, but IIRC Greg has a collection of functions to get the executable path on all platforms?!) (2) Or a distinct name, something like first window xclass#xid of the Fl_Window being shown. No, I don't think so. From what I understand, the xclass shoudl be the same to signal to the WM that all windows belong to the same app. Which brings me to the first mail: I am very surprised that Fluid is not behaving correctly, and here seems to be the main problem, because Fluid does correctly call Fl::args(...) and main_window-show(argc, argv). http://robowerk.com/ ___ 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
Greg Ercolano wrote: Alvin wrote: matthiasm wrote: Please file STRs for both issues, preferably with patches ;-) Mindless interjection: is this just a matter of modifying fluid to set unique names for the Fl_Window::xclass() of each of its windows? To solve the problem for Fluid, yes. I belive the fix would be to set the X Class field of every dialog in the Fluid source code (.fl files). However, I believe this is symptom of a much wider issue. The issue is, the first window of any FLTK app will have its WM_CLASS set to its argv[0] (unless set by the programmer). However, each subsequent Fl_Window will have no WM_CLASS. -- Alvin ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk.general] :Linking Fluid Error
Dear Ianya i do agree, libraries n all compiled properly, no error but only linker warnings are getting...but still my application codes are not compiling, same linking errors are coming..dats the reason m bit worried.could you suggest any cross compile toolchain with X11 support?? because toolchain what m using in that no X11 related libraries n include files. In the skiff toolchain X11 libraries n include files are there, but after including those in cross compile environment EABI version matching errors are coming.thats true beacuse u know target fluid built with EABI version 4, but X11 built with a EABI version 0. So finaly i have concluded that entire problem with my toolchain only. because of some version problem i coul not able to use skiff toolchain..so can u suggest any other prebuilt toolchain so that i can download n proceed for further process. otherwise i vl have to concentrate on cross compilation of X11 for arm target..RegdsVinayakQuoting quot;MacArthur, Ian (SELEX GALILEO, UK)quot; lt;[EMAIL PROTECTED]gt;:gt; Is this proparly compiled or not??? i hope its not butgt; still m asking you..please reply me.Are the warnings listed (below) the only warnings you get? And there areno outright errors?If so, I'd hazard that the build of the library and the test demoprograms has succeeded.Do you think it has not worked? It seems, from the way you phrased yourquestion, that you believe this has not worked correctly - if so, whatmakes you think it has not worked?Is there some specific problem you are seeing when you try and executethe code on your target board?gt; Linking fluid...gt; /usr/bin/ld: skipping incompatible gt; /home/vinayak/arm-2007q1/arm-none-linux-gnueabi/lib/X11//libXext.sogt; when searching for -lXextgt; /usr/bin/ld: skipping incompatible gt;/home/vinayak/arm-2007q1/arm-none-linux-gnueabi/lib/X11//libX11.sogt; when searching for -lX11gt; === making test ===gt; Compiling unittests.cxx...gt; Lin king unittests...gt; /usr/bin/ld: skipping incompatible/home/vinayak/arm-2007q1/arm-none-linux-These warnings would imply that when the linker is looking for librarieswith the names libXext.* and libX11.*, it is finding some that it cannot link because they are the wrong architecture - I'm guessing it islooking for ARM based libs and is finding some x86 based libs? Youreally need to fix that.Is the linker subsequently finding that quot;correctquot; versions for Xext andX11? I assume it must be as you have not shown any other linker errors.You are sure that you are using the correct (i.e. the ARM compatible)linker? Just checking...!-- IanSELEX Sensors and Airborne Systems LimitedRegistered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3ELA company registered in England amp; Wales. Company no. 02426132This email and any attachments are confidential to the intendedrecipient and may als o be privileged. If you are not the intendedrecipient please delete it from your system and notify the sender.You should not copy it or use it for any purpose nor disclose ordistribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
