Bug 61862 - Font size changing with mouse wheel is counter-intuitive.
Summary: Font size changing with mouse wheel is counter-intuitive.
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-30 17:29 UTC by Gilles Schintgen
Modified: 2003-11-25 12:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
proposed quick-fix (606 bytes, patch)
2003-09-24 20:07 UTC, Leo Savernik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gilles Schintgen 2003-07-30 17:29:12 UTC
Version:            (using KDE KDE 3.1.2)
Installed from:    Compiled From Sources
OS:          Linux

I think the current default mouse bindings for changing the font size are somewhat strange. I think it should be normal to assume that [SHIFT]+WHEEL_UP increases font size while WHEEL_DOWN decreases it. However, the default is exactly the contrary: WHEEL_UP decreases the font size while WHEEL_DOWN increases it.
Is there a specific reason for this behavior?
BTW, all my linux-using friends are also wondering about this strange default setting.
Comment 1 Thiago Macieira 2003-07-30 17:42:09 UTC
That was zooming in and zooming out. 
 
Let me think.. no, that doesn't make sense for me either. Wheel Up should zoom in... 
Comment 2 Jorge Adriano 2003-09-24 19:17:22 UTC
I agree, just started a thread on this same subject in the kde-usability mailing list and everyone 
there seems to agree too - WHEEL UP should INCREASE the font size/zoom in.  
Furthermore that is other browsers (Opera) have been been reported to work like that, and I 
even some  other KDE apps, like kghostview.  
 
So we got two problems here: 
- The shift+wheel behaviour should be consistent among kde apps.   
Right now Kghostview and Khtml are not consistent. 
The chosen behaviour should probably be listed in the KDE HIG. 
 
- Seems like there is general agreement, Shift+Wheel Up should incerase font/zoom in. 
So khtml should be the on to change. 
Comment 3 Leo Savernik 2003-09-24 20:07:01 UTC
Created attachment 2569 [details]
proposed quick-fix

The attached patch reverses the behaviour for khtml.

However, this is the easy part. The difficult part is how to treat those who
are already used to the non-intuitive behaviour.
Comment 4 Dirk Mueller 2003-11-02 18:18:05 UTC
Subject: kdelibs/khtml

CVS commit by mueller: 

reverse the way of how the font zooming shortcut works.
CCMAIL: 61862-done@bugs.kde.org


  M +22 -0     ChangeLog   1.76
  M +1 -1      khtmlview.cpp   1.582


--- kdelibs/khtml/ChangeLog  #1.75:1.76
@@ -1,2 +1,24 @@
+2003-11-02  Dirk Mueller  <mueller@kde.org>
+
+        * khtmlview.cpp (viewportWheelEvent): toggle Font zooming orientation (#61862).
+
+        * rendering/render_box.cpp (paintBackgroundExtended): implement. needed
+        for inline elements background drawing somewhen. 
+
+        * rendering/render_object.cpp (nodeAtPoint): merge from Safari. Still
+        does not work, but at least its the same now. 
+        (lineHeight): handle replaced elements here. They don't necessarily
+        inherit RenderReplaced anymore. 
+        (baselinePosition): handle replaced elements.
+
+        * rendering/render_replaced.cpp: remove baselinePosition/lineHeight. its in
+        RenderObject now.
+
+        * rendering/render_block.cpp (isSelfCollapsingBlock): collapse away trailing whitespace
+        at the end of the block.
+        (setStyle): set "isReplaced" for display: inline-block.
+        (addChildToFlow): Make sure we don't append things after :after generated content.
+        (calcInlineMinMaxWidth): respect text-indent (taken from WebCore 106).
+
 2003-11-02  Stephan Kulow  <coolo@kde.org>
 

--- kdelibs/khtml/khtmlview.cpp  #1.581:1.582
@@ -1893,5 +1893,5 @@ void KHTMLView::viewportWheelEvent(QWhee
     if ( ( e->state() & ShiftButton ) == ShiftButton )
     {
-        emit zoomView( e->delta() );
+        emit zoomView( - e->delta() );
         e->accept();
     }


Comment 5 Christian Spitzlay 2003-11-11 02:22:02 UTC
Jorge Adriano wrote: 
> Right now Kghostview and Khtml are not consistent. 

This had been true for KDE 3.1.x but kghostview's behaviour 
has been adapted to khtml's a while ago in HEAD. 
So in fact by granting this wish wrt. khtml you just *made* them 
inconsistent again.  Argh! :-|

I don't really like this change and the argument that it's 
more intuitive that scrolling UP means INCREASING the size
doesn't convince me.  I think that connection is a little bit far-fetched.
Being used to a certain behaviour is much more important IMHO. 
Besides I find it much more comfortable to scroll down than up, 
and most of the time I want to increase font size, not decrease it. 
So now, with the recent change, I have to scroll "the wrong way" 
most of the time :-(

Well, if it stays like that, 
could someone with a CVS account please apply the 
following patch for consistency sake:

Index: kgvpageview.cpp
===================================================================
RCS file: /home/kde/kdegraphics/kghostview/kgvpageview.cpp,v
retrieving revision 1.16
retrieving revision 1.15
diff -u -3 -p -r1.16 -r1.15
--- kgvpageview.cpp     4 May 2003 20:39:19 -0000       1.16
+++ kgvpageview.cpp     7 Mar 2003 22:09:24 -0000       1.15
@@ -94,7 +94,7 @@ void KGVPageView::wheelEvent( QWheelEven
     int delta = e->delta();
     e->accept();
     if ((e->state() & ShiftButton) == ShiftButton) {
-        if ( e->delta() > 0 )
+        if ( e->delta() < 0 )
                        emit zoomOut();
                else
                        emit zoomIn();


and thus revert the change to kghostview?

Comment 6 Waldo Bastian 2003-11-25 12:13:42 UTC
kghostview patch has now been applied/reverted.