Age | Commit message (Collapse) | Author |
|
|
|
Rewrote FltkViewport::draw() into a much cleaner style, fixing 3 problems.
Bug fixes:
1. The mouse button FL_RELEASE event over the scrollbars area
triggered an unnecessary redraw.
2. The mouse button FL_RELEASE event, after scrolling,
triggered an unnecessary redraw.
3. The FL_RELEASE event, after {horiz|vert}scrolling
was passed upwards although already handled.
|
|
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.
|
|
to a quick glance, that looked like division could be involved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Had been removed in d604d0b0c3f8.
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2012-November/009537.html
|
|
I played around with different speed algorithms, without anything seeming
_obviously_ best, so here's something to start with, anyway...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Added setDragScroll(bool) to the viewport to enable/disable it
* Made middle-click paste URL upon FL_RELEASE
|
|
|
|
* Allows using these keys for next/prev tab when hscrollbar is visible
|
|
|
|
* It also has a fix for scrollbars resize, and an optimization to avoid
scrollbar adjustment overhead.
|
|
There's probably useful untangling of the scrollbar code that
one could do because they're probably supposed to resize to
zero thickness when we can't see them, but...
And as for the modifier check, it was originally added in
http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dw2/dw/fltkviewport.cc?cvsroot=dillo#rev1.21
which just says "Fixed an include for OpenBSD compatibility." --
so I have no idea whether it's there for a reason. If a reason
reveals itself, I can add a comment.
|
|
|
|
The Bug Meter needs some work due to differences with FLTK2
|
|
|
|
|
|
Plain Dillo has this bug as well, which I know I've tripped upon on
occasion but had never noticed quite what I'd done to trigger the
misbehaviour.
|
|
It turns out that Fl_Group::handle() is where some of the magic
lives that makes pushed() and FL_DRAG all work properly so that
you can drag the scrollbar without keeping the cursor within
its confines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Let fltk decide which widget should get the focus when the window
regains focus.
Unfocus any form widgets when the view area is clicked with the left
mouse button.
Reported by: Roger
http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-May/007486.html
|
|
"using namespace" in headers also affects all files that include the
header which is unwanted and unexpected in most cases.
|
|
|
|
|
|
|
|
|
|
|
|
|