> 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
> 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
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
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
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
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
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
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,
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
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
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).
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
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
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
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
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
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
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,
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
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
20 matches
Mail list logo