| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Conflicting demands arise in the implementation of class Fl_Xlib_Graphics_Driver
for drawing images with the XRender library :
1) Issue #163 leads to use a bilinear filter to draw-and-scale images.
2) This tends to blur the edges of drawn areas which is bad for tiled images
(that is because the edges get alpha values, even for an opaque source image).
This commit resolves the conflict adding a means to detect whether the library
is busy drawing a tiled image. If so, the bilinear filter is not applied, drawn areas
don't have blurred edges, resulting in a nice tiling.
With this commit, these test apps perform correctly:
- tiled_image is correct at all scaling factor values also when modified
to use a depth-3 or a depth-4 Fl_RGB_Image as tile;
- unittests - Drawing Images is correct at all scaling factor values;
- pixmap_browser scales correctly up and down JPEG and PNG images.
|
|
Modifying test/tiled_image to make it use a depth-3 image for
tiling (rather than an Fl_Pixmap) shows the filter does require
to use PictOpOver as the render op in the XRenderComposite call.
|
|
|
|
|
|
Support different margin sizes on all four edges. Default margin
and gap size is now 0 (compatible with Fl_Pack).
Doxygen: move the description from the constructor to the class
declaration which constitutes a "description".
Make some methods virtual and/or 'const'.
Clarify demo programs, make them even more "FLTK style".
|
|
|
|
Fl_Wayland_Graphics_Driver::buffer_commit().
|
|
|
|
|
|
|
|
|
|
sequences.
|
|
Don't add the widget to the array if size == 0 (unset) but it has
not been in the array (or it's called twice).
|
|
This work is based on the repository and latest commit:
https://github.com/osen/FL_Flex.git
commit 36e4ed75a00daac825b87e81295818b4650991f5
Author: Karsten Pedersen <...>
Date: Fri Apr 23 12:06:16 2021 +0000
Added Fltk (LGPL) license.
This widget is similar to Fl_Pack and supports either one row or one
column of widgets but has some more features. Test and demo programs
are included:
test/flex_login.cxx: simple "login window" demo program
test/flex_demo.cxx: slightly more complex demo program
The original demo programs can still be compiled and built with
the new widget provided you '#include <FL/Fl_Flex.H>'.
Backwards compatible methods are included (except debug()).
The original widget has been modified to match FLTK standards and
enhanced in several ways, including:
- support box frames
- add HORIZONTAL and VERTICAL enum values (as in Fl_Pack)
- add horizontal() method (as in Fl_Pack)
- use type() rather than internal 'direction' variable
- add standard widget constructor (x, y, w, h, label)
- add margin and gap accessors rather than hard coding constants
- improve test and demo programs
- add documentation
- replace <vector> with array as required by FLTK CMP
- rename camelCase method names, keeping old names for compatibility:
- change 'setSize(Fl_Widget*, int)' to 'set_size(Fl_Widget*, int)'
- change 'bool isSetSize(Fl_Widget*)' to 'int set_size(Fl_Widget*)'
- remove debug() method
- add a way to "unset" fixed size: set_size(Fl_Widget *, 0)
- add layout() method to force recalculation of children
- unify resizeRow() and resizeCol() methods to avoid code duplication
- improve widget size calculation.
|
|
|
|
This looks a little better and more like FLTK 1.3
|
|
|
|
|
|
and v1.4
|
|
|
|
|
|
|
|
under USE_XFT=1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Please note that the parameter 'percent' of XBell(3).
Given the value of 100, the system defined setting
(normally specified via xset) is ignored and the
percent of 100 is used instead. When calling the
bell from fltk with FL_BEEP_DEFAULT I would expect
to get the default (system specified) percent setting.
|
|
|
|
This is only one part of issue 461 which describes two build errors
on "Raspberry Pi4 bullseye". It turned out that the build didn't
find Xft.
|
|
That's because this member is used only in Fl_Quartz_Font_Descriptor.
|
|
scaling applies.
The implemented approach is to create and use the pango_layout_ object only relatively
to an unscaled cairo context. With this, the pixel width of a drawn string equals
the sum of the widths of its characters.
|
|
|
|
|
|
|
|
Fl_Wayland_Gl_Window_Driver::gl_start().
|
|
|
|
|
|
This improves reading large selections and fixes one more bug.
- Fix reading selection data size of clients that don't send the size.
These clients don't respect the ICCCM. Using a default size instead.
- Improve memory allocation by pre-allocating at least 4 MB and
extending by 4 MB to reduce the number of realloc() operations.
This may waste up to 4 MB buffer space but this is only an issue
if clients don't send an appropriate size (see above).
- Limit the initial allocation to 200 MB in case clients send higher
values. This is very unlikely and might be a bug in these clients.
Default extension as above would apply anyway.
- Add more comments and optional debug statements (commented out).
Note: reading selections (clipboard) from other clients using the
INCR protocol is implemented but the opposite (providing large
selections (clipboard) by using the INCR protocol is not.
|
|
- Fix reading the size (aka "lower bound") of selection data.
- Use Fl::fatal() to terminate the process if memory for the selection
(aka clipboard) data can't be allocated. This should rarely
happen but if it does this is at least a "clean" exit and does
not overwrite arbitrary data waiting for later errors that are
hard to debug (as the old code would have done).
Todo: find a better solution because this can be caused by
another faulty process (the "selection owner"). It would be good
if we could ignore the transfer rather than killing the process.
- Continue processing the INCR protocol if another "unexpected" event
is received. Such events can definitely happen but the current code
can't deal with this because other events might cause recursions.
Hence such events are currently ignored.
Example: pressing and holding ctrl/v would trigger another clipboard
transfer while we're still processing one.
Todo: maybe process "other" events correctly while processing the INCR
protocol. The current processing is done inside a function and would
need to call fl_handle() with potential recursions, hence this would
likely need major refactoring.
|
