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 i

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

2008-09-29 Thread MacArthur, Ian (SELEX GALILEO, UK)
> Is this proparly compiled or not??? i hope its not but > still m asking you..please reply me. Are the warnings listed (below) the only warnings you get? And there are no outright errors? If so, I'd hazard that the build of the library and the test demo programs has succeeded. Do you think it

[fltk.development] FrameBuffer

2008-09-29 Thread alain savelli
Hello, I would like to know iof the last version of FLTK support Framebuffer. thanks i'm waiting for your reply. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev

[fltk.development] WM_CLASS property for fluid windows

2008-09-29 Thread Carlos Pita
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. Bec

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

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 handli

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 framebuf

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,

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 a

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

2008-09-29 Thread imacarthur
On 29 Sep 2008, at 18:18, matthiasm wrote: > > 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 advantag

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).

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 g

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 wi

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

2008-09-29 Thread Greg Ercolano
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? ___ f

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. Ther

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 Dire

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

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,

Re: [fltk.development] FrameBuffer

2008-09-29 Thread Ormund Williams
On Mon, 2008-09-29 at 23:55 +0200, matthiasm wrote: > 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 submi

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 t