| Age | Commit message (Collapse) | Author |
|---|
|
Now there's a single fl_scroll() call for each scroll operation,
instead of calling fl_scroll() and then draw().
The patch also fixes support for FL_DAMAGE_EXPOSE in FltkViewport::draw().
Test data:
FL_DAMAGE_CHILD = 0x01, 1
FL_DAMAGE_EXPOSE = 0x02, 2
FL_DAMAGE_SCROLL = 0x04, 4
FL_DAMAGE_OVERLAY = 0x08, 8
FL_DAMAGE_USER1 = 0x10, 16
FL_DAMAGE_USER2 = 0x20, 32
FL_DAMAGE_ALL = 0x80 128
-----------------------------------------------------------------------------.
| scroll: keys | focus click | Alt-Tab | unfocus|
| or mousewheel | viewport | statusbar | unfocus | focus | click |
-----------------------------------------------------------------------------|
d4235 | 5,5 | 16 | | 128 |128,128,128| |
d4529 | 5,5 | 16 | | 128 |128,128,128| |
dpatch | 5 | 16 | | 128 |128,128,128| |
-----------------------------------------------------------------------------'
</pre>
The first column means dillo version (hg rev). The second one
the FLTK damage bits received by FltkViewport::draw() per scroll
operation (also viewable at dillo's stdout).
The other columns show excessive calls, but that's another bug
that is not as relevant as scrolling now, so feel free to ignore
them by now.
|
|
http://lists.dillo.org/pipermail/dillo-dev/2014-November/010303.html
for: "If an input has focus and you click on the page to give it focus instead,
and then the cursor leaves the page and returns to it, the input is given
focus instead."
|
|
http://lists.dillo.org/pipermail/dillo-dev/2014-November/010299.html
and, from commit text for changeset eb902ac9fc66
"Starting with fltk-1.3.3, we can't use fl_oldfocus, this patch
fixes this problem.
IOW. this patch is necessary to link with fltk-1.3.3."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I see that firefox includes Location as well, but that would likely be
tricky in our case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(I had made it use that less-clear int[][2] interface because fltk2 let you add
all of the vertices in one call.)
It feels good to change that nasty-looking pointArray in Polygon::draw().
|
|
|
|
|
|
no change in behaviour intended
|
|
|
|
This is a complex problem where it is not clear whether the bug lies
in dillo, fltk, or in their interaction.
Tooltip handling is fuzzy in FLTK, and there are glitches in it; trying
to "fix" it inside dillo produces partial solutions. OTOH, although
implementing custom tooltip handling adds complexity, it provides a solution
that so far works in all the testcases.
|
|
In fltk-1.3, it doesn't draw inside labels for Fl_Inputs, and it
wasn't very nice anyway. Here I move them to the left.
Johannes took a look at this change:
"The only issue I could think of is that the additional
draw_outside_label() would cause excessive redraws for
some reason. But I didn't see anything like that during short
testing here."
|
|
|
|
|
|
|
|
The drawBorder{Top,Bottom,Left,Right} functions are similar. They
use a trapezium as draw polygon, or drawTypedLine() for dots and dashes.
Although the concept is simple, achieving pixel accuracy is laborious [1].
[1] http://www.dillo.org/css_compat/tests/border-style.html
|
|
* Variable length arrays are not allowed in C++. They are supported in
C99 and gcc seems to accept them in C++ mode.
Replace the few places where variable length arrays are used.
* The widget member in ComplexButtonResource was colliding with the
widget member of FltkResource, so rename it to childWidget.
|
|
With these functions there's no need to alter the locale.
|
|
|
|
For some reason utf8decode() didn't work for me, so I used mbrtowc() funcs.
|
|
(some uppercasing is done but not utf8)
|
|
|
|
To avoid artifacts we need clip with a rectangle that is line_width()
larger than our expose area.
Noticed by: corvid <corvid@lavabit.com>
|
|
|
|
"using namespace" in headers also affects all files that include the
header which is unwanted and unexpected in most cases.
|
|
|
|
For me, at least, ARROW and DEFAULT are slightly different.
|
|
Make currently exposed area available in FltkViewBase and use it to
clip rectangles to the required size before drawing them.
We can use the same mechanism to limit drawImage() calls instead of
doing it in dw/image.cc as currently done.
|
|
* allow negative width / height
* clip rectangle to size of the view. This avoids issues with 16 bit X11
coordinates overflowing and seems to improve performance.
|
|
We always need to set a clipping rectangle when drawing to
avoid that text "leaks" out as in the following
test case (by corvid):
<input type="image" name="name1" src="whatever"
WIDTH="80" HEIGHT="14"
alt="name1name1name1name1">
<input type="image" name="name2" src="whatever"
width="9" height="14"
alt="name2name2name2name2">
|
|
|
|
|
|
|
|
|
|
|
