"About ..." item of the application menu. This issue appeared with OS X 10.7.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@9152 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
window failed under OS X 10.7. It's replaced by a simpler, OS version-independent procedure.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@9144 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
A new event FL_SCREEN_CONFIGURATION_CHANGED is introduced.
Fl::add_handler() allows to register a callback for this event.
The unix/X11 implementation is still missing.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@9087 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This introduces 3 new functions
static void Fl::screen_work_area(X,Y,W,H)
static void Fl::screen_work_area(X,Y,W,H,mx,my)
static void Fl::screen_work_area(X,Y,W,H,screen_no)
that compute screen work areas and are used by FLTK to position menu windows.
The Fl::x(),y(),w(),h() functions are made consistent across platforms: they return
the origin/size of the work area of the main screen (as far as possible, see below).
On the Mac OS platform, all screen functions reflect changes in screen number and
positions without requiring the application to restart.
On the X11 platform, I did not find an API to compute the main screen work area
in all conditions. What's used does compute the correct work area when there's
a single screen, but not when there are several, because it returns an area that
encompasses all screens. The implemented workaround is that Fl::x(),y(),w(),h()
and Fl::screen_work_area(X,Y,W,H,0) return the exact work area when there's
a single screen, and return the full screen area when there are several.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@9084 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
when the window is iconized for all platforms.
Also, factorized some duplicated code in src/Fl_x.cxx.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8759 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
that sets the window name when it is iconized (or minimized).
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8664 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
if (winclass != kHelpWindowClass)
is now replaced in Fl_cocoa.mm by its exact equivalent:
if ( w->border() || (!w->modal() && !w->tooltip_window()) )
so that tooltip windows are handled as in carbon.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8601 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
badly formed UTF8 strings.
This probably is not the best solution, but it
does work.
Note that the problem actually seems to be in
setting the window title, and indeed if you try to
label ANY window with a badly formed UTF8 string
(not just a tooltip) you get the same exception
thrown.
NOTE: I'm not even sure why we try to set the
window title in tooltips, as it is never used
and the tooltip label itlsef still works fine.
Anyway, we can do something better, but this will
work for now.
Aside: If you close an app on OSX whilst a tooltip
is visible, the app will not exit, as there is still
a window open (the tooltip) but no way to cancel
the tooltip.
Don't know if this is OSX specific or not though
but it is certainly a bug.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8598 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Added Fl_Window::decorated_w() and Fl_Window::decorated_h() that return the size
of a window with its title bar and frame.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@8593 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
