| Age | Commit message (Collapse) | Author |
|---|
|
Declare Fl_Scroll::bbox() and Fl_Scroll::recalc_scrollbars() 'const'.
These methods don't change the Fl_Scroll widget.
Use Fl_Scroll::recalc_scrollbars() in Fl_Scroll::bbox() to simplify
the code and to avoid code duplication.
bbox() can now be called at any time and returns the correct values,
no matter if draw() has been called before.
|
|
This corresponds to changes of PR#277 (Author: Samuel Mannehed)
|
|
There's not much we can do if we find unknown data in the main
parser loop. The best we can do is terminating.
If we find a GIF trailer (0x3b) this means logical end of file.
If we get there in the main loop the GIF file is empty (no image).
This behavior is consistent with many other image viewers including
browsers (Firefox and Chrome).
|
|
Document clearly that reading from memory w/o the length argument
(old constructor) is discouraged (deprecated).
|
|
... and separate constructors for memory reader with and w/o length
argument for better documentation.
|
|
Thanks to @wcout for finding this.
|
|
This could happen if a read error or end of file was encountered.
|
|
- use new features of Fl_Image_Reader (read error and EOF checks)
- add length argument to constructor reading from memory
|
|
- add error and EOF checks
- fix transparent pixel index outside ColorMap (#271)
- fix Fl_GIF_Image decoder bug (#274)
- add Fl_Image_Reader::skip(unsigned int)
- use new skip() method in GIF reader
|
|
Fix: Fl_Image_Reader::seek() would not clear the error flag when
reading from memory.
|
|
This is part 1 and a prerequisite for the fix of issue #271.
It enables the user of this internal class (Fl_{BMP|GIF}_Image)
to test for read errors and EOF (end of file) while reading.
The method used to read data from memory got an optional third
argument 'const long datasize = -1)' to limit the size of the
memory block of data provided to the image reader. Default is -1
which means "unlimited" (backwards compatibility).
Using only two arguments (w/o size limit) is deprecated and should
only be done if the data size is not available.
|
|
|
|
|
|
|
|
src/Fl_Native_File_Chooser_WIN32.cxx:331:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
331 | while ( s=strchr(s,'\\') ) *s = '/';
| ~^~~~~~~~~~~~~~~
src/Fl_Native_File_Chooser_WIN32.cxx:336:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
336 | while ( s=strchr(s,'/') ) *s = '\\';
| ~^~~~~~~~~~~~~~
|
|
add Notes: section to fl_filename_match documentation
explaining case-sensitivity [or not] and use of \x
see also https://www.fltk.org/str.php?L3186
|
|
This fixes a regression introduced in FLTK 1.4 in commit
3bc5be71a39bf2ed9d9937a4f60df61dd6d3a2b4 ("Rewrite Fl_Tooltip.cxx
for the driver model").
|
|
I compiled with `-Wextra-semi -Werror=extra-semi` on Linux and Windows
(cross-compiled on Linux) and removed all "extra semicolon" warnings
I could find. I didn't check on macOS (yet).
Note: Linux configured with and w/o Pango but not w/o Xft. Compilation
with other options (e.g. Cairo) might still emit such warnings.
|
|
|
|
|
|
initWithFocusedViewRect:] in macOS 10.14
|
|
With macOS 11.x, the pasteboard image can be found with floating point pixel values.
This changes makes FLTK process adequately such image data.
|
|
|
|
|
|
Add CMake test for PTHREAD_MUTEX_RECURSIVE
Add autoconf/configure compile test for PTHREAD_MUTEX_RECURSIVE
Replace "#ifdef PTHREAD_MUTEX_RECURSIVE"
with "#ifdef HAVE_PTHREAD_MUTEX_RECURSIVE"
and define HAVE_PTHREAD_MUTEX_RECURSIVE in config.h
|
|
- add missing dependencies to build the shared libfltk_cairo(.dylib)
- remove incorrect dependency on cairo from libfltk
- add cairo_test-shared demo (linked with shared libs)
|
|
- configh.in: add and improve comments, reorder statements
- configh.cmake.in: add comments, fix whitespace
- src/drivers/GDI/Fl_GDI_Graphics_Driver_line_style.cxx:
fix trailing whitespace
|
|
The old version would reschedule an existing timer if a matching timer
existed already which was unique to macOS.
The new behavior is consistent on all platforms and allows to create
multiple timer entries with the same callback and userdata.
|
|
Calling Fl::repeat_timeout() instead of Fl::add_timeout() to create
a timer would crash on macOS but fall back to Fl::add_timeout() on
Windows and Unix/Linux. Although this is documented as "undefined
behavior" a crash should always be avoided and the fallback is now
consistent on all major platforms.
In the future this may be documented as the standard behavior.
|
|
Sorry for the noise, this was a "merge error".
Also, fix a typo.
|
|
Thanks to @wcout for pointing out that "<svg\t" is a valid notation.
The overall length check (>= 5) is left in place intentionally.
|
|
|
|
|
|
Issue #210: "Fl::event_x() & event_y() doesn't take into account
embedded window's coords with Mouse wheel events"
In fact the calculation of Fl::event_x() and Fl::event_y() used the
wrong window coordinates if the event was sent to a subwindow.
|
|
|
|
This is a hypothetical fix, since the condition `count == 0` may not
be true although `doit` has been allocated. In practice this should
not be possible since the same loop is executed twice in lines 463++
and 471++. But anyway, here it is...
|
|
Signed-off-by: Albrecht Schlosser <albrechts.fltk@online.de>
|
|
Some of the previous constness changes turned out to be incomplete,
others had to be reverted because some other driver methods could
not be made 'const' - particularly those calling open_display() to
get the requested information.
|
|
As requested by issue #181:
"Fl_Screen_Driver.H non-const functions should be const"
Not all methods could be made 'const' because some screen related
methods call init() internally.
|
|
|
|
src/Fl_Native_File_Chooser_WIN32.cxx:190:10:
warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound
depends on the length of the source argument [-Wstringop-overflow=]
190 | strncpy(wp2, string, n);
| ~~~~~~~^~~~~~~~~~~~~~~~
Although there was no real problem with the code (the allocated buffer
was large enough), the code was questionable and there was redundant
code that could be simplified.
|
|
|
|
|
|
This fixes this issue mentioned in fltk.general :
https://www.fltk.org/newsgroups.php?s40623+gfltk.general+v40638+T
|
|
|
|
Use correct conversions to Windows "wide character" encoding and
use the appropriate wide character functions.
|
|
Pre-clip coordinates to 16-bit range before using X11 clipping
functions because X11 supports only 16-bit int's.
|
|
|
|
This is a convenience method that does range checking (index n),
removes the child given by index n from the group and deletes it.
|
|
- disable warning C4244 (conversion / data loss)
- restore #pragma warning after nanosvg includes
|
