Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken?

2008-09-29 Thread MacArthur, Ian (SELEX GALILEO, UK)
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

Re: [fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread Alvin
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

Re: [fltk.development] fltk-1.3, OSX port keyboard handling broken

2008-09-29 Thread matthiasm
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

Re: [fltk.development] FrameBuffer

2008-09-29 Thread matthiasm
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

Re: [fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread matthiasm
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,

Re: [fltk.development] Fluid supporting Doxygen (SVN 6291)

2008-09-29 Thread matthiasm
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

Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration

2008-09-29 Thread matthiasm
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

Re: [fltk.development] FrameBuffer

2008-09-29 Thread Ormund Williams
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

Re: [fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread Alvin
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

Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration

2008-09-29 Thread imacarthur
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

Re: [fltk.development] FrameBuffer

2008-09-29 Thread matthiasm
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

Re: [fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread matthiasm
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

Re: [fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread Alvin
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

Re: [fltk.development] [fltk.general] :Linking Fluid Error

2008-09-29 Thread Vinayak Pandit
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