Bug 76360 - Navigation panel insists on zero width
Summary: Navigation panel insists on zero width
Status: RESOLVED LATER
Alias: None
Product: konqueror
Classification: Applications
Component: sidebar (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Joseph Wenninger
URL:
Keywords:
: 72884 76636 80052 81248 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-28 18:25 UTC by Malte S. Stretz
Modified: 2005-01-19 17:13 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed work-around until Qt 4.x (3.68 KB, patch)
2004-06-09 23:14 UTC, Stephan Binner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Malte S. Stretz 2004-02-28 18:25:16 UTC
Version:           3.2.0 (using KDE 3.2 BRANCH >= 20040204, Gentoo)
Compiler:          gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)
OS:          Linux (i686) release 2.4.20-gentoo-r8

Some days ago I resized the Navigation Panel/Sidebar in Konqi to a zero width so that only the tabs are visible. Now when I try to resize it back to a reasonable width, I can see the resized Sidebar while I'm dragging but as soon as I release the mouse button it snaps back to zero width.
Comment 1 Daniel Bausch 2004-03-02 23:44:24 UTC
I had the same problem and can narrow it down, that it only occours in tabed mode. It also is not specific to a zero width nav-panel, it can also happen that a visible panel can not be resized. It snaps back to it's original width, when the mouse button is released. While being resized it flips beween its new and the old size continuously. Also when mouse is not moved while dragging.
Comment 2 David Vogt 2004-03-16 14:10:48 UTC
Same problem here. Didn't have it with 3.2.0 although, but now with 3.2.1 it is here. I can confirm that this problem only occurs if the tab bar is visible.
Comment 3 Malte S. Stretz 2004-03-16 17:51:47 UTC
You can trick the bug by moving your mouse *really* fast to one direction -- sometimes the (random) size you get with that stays. And is as hard to shrink as it was to extend it. I guess "really fast" means as much as "faster then some kind of redraw event" :)
Comment 4 Rob Ross 2004-03-24 00:28:33 UTC
I get this too (on 3.2.1). If I uncheck the "Hide the tab bar when only one tab is open" option in Web Behaviours and restart Konqueror I can resize the navigation panel, but if I open a new tab (or change the option back again) I can no longer resize the panel, although it stays wherever I left it before changing the option, so it's still usable I guess.

Hope this helps.
Comment 5 Kaorukun 2004-04-10 23:53:42 UTC
I found this bug while submitting mine, so I just post a comment instead of duplicate.
"Hide the tab bar when only one tab is open" option breaks the splitter window in file manager mode (after Konqueror is restarted), in my case, window splitter between folder tree subwindow and folder contents subwindow stays in an "anchored" position, and refuses to be moved left or right, or snaps to left or right side. Unsetting the option and restarting brings it back to normal, but then you cannot use the said option, so it's broken in current versions. Seen with 3.2.0 and 3.2.1.
Comment 6 Stephan Binner 2004-05-01 10:24:06 UTC
*** Bug 76636 has been marked as a duplicate of this bug. ***
Comment 7 Vasilis 2004-05-09 02:03:38 UTC
Do you see this problem when you run konqi as root?
I do not and I am wandering why...
Comment 8 Michael Nottebrock 2004-05-12 15:58:13 UTC
I just stumbled over this bug as well. FWIW, I don't think there's a direct relation to the "Hide the tab bar when only one tab is open" option. I've never had it activated, yet I stumbled over the bug and after some playing around, the window splitter in filemanager mode now remains snapped to the left border of the window hard. I cannot even snap it to the right anymore, it refuses to be dragged anywhere. Needless to say this is VERY annoying.
Comment 9 Michael Nottebrock 2004-05-12 16:05:43 UTC
Oh, and this is on 3.2.2
Comment 10 Michael Nottebrock 2004-05-12 16:12:04 UTC
And another fresh observation: Madly switching between bookmarks/root/home... views got the splitter back open and consecutively _activating_ "Hide the tab bar when only one tab is open" makes it behaving normally (instead of trying to snap back to whatever position it is in when you start dragging). This is quite exquisitely broken indeed.
Comment 11 Stephan Binner 2004-05-12 16:15:00 UTC
I think the whole combination of FollowSizeHint resize mode together with a sizeHint which is modified within resizeEvent() is unfortunate. This is easy supposed to fail with any widget besides which triggers a updateGeometry() - as the close tab widget button (rightCornerWidget) of QTabWidget does.
Comment 12 Stephan Binner 2004-05-12 21:27:05 UTC
*** Bug 72884 has been marked as a duplicate of this bug. ***
Comment 13 Stephan Binner 2004-05-12 21:31:00 UTC
*** Bug 81248 has been marked as a duplicate of this bug. ***
Comment 14 Eduardo Robles Elvira 2004-05-25 14:57:14 UTC
Still happening in KDE 3.2.2. BTW, this is a Regression because the problem didn't occur in elder KDE versions.
Comment 15 Waldo Bastian 2004-05-26 16:25:51 UTC
#11: Problem is that QSplitter doesn't have any hooks to detect user initiated resizing.
Comment 16 Waldo Bastian 2004-05-26 16:39:30 UTC
QSplitter makes it rather difficult to detect when the user moves the splitter 
as opposed to size changes due to layout management.

This would be much easier if QSplitter::moveSplitter() was to emit a signal.

Cheers,
Waldo
Comment 17 András Manţia 2004-05-26 16:51:49 UTC
Subclass QSplitter, override the moveSplitter() and emit the signal 
there? Not so clean, but might help to get rid of this ugly bug.

Comment 18 qt-bugs 2004-05-27 17:24:33 UTC
On Wednesday, 26. May 2004 16:42 Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> QSplitter makes it rather difficult to detect when the user moves the
> splitter as opposed to size changes due to layout management.
>
> This would be much easier if QSplitter::moveSplitter() was to emit a
> signal.
>
> Cheers, Waldo

Hi Waldo

Sounds like a good idea to me. We'll consider this for 4.0. Thanks for
the suggestion.


best regards

Anders Bakken
--
Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway

Comment 19 Stephan Binner 2004-06-02 22:17:54 UTC
*** Bug 80052 has been marked as a duplicate of this bug. ***
Comment 20 Stephan Binner 2004-06-09 23:14:15 UTC
Created attachment 6290 [details]
Proposed work-around until Qt 4.x

Andras, moveSplitter() is not virtual. But setRubberband() is so why not make
this splitter resize non-opaque? It doesn't look opaque and flickers perhaps a
bit too much when releasing the splitter but it makes resizing possible.
Comment 21 Stephan Binner 2004-06-10 12:35:06 UTC
Committed until someone offers a better solution.
Comment 22 András Manţia 2004-06-10 13:47:14 UTC
On Thursday 10 June 2004 00:14, Stephan Binner wrote:
> Andras, moveSplitter() is not virtual. 

Too bad. :-( 

> But setRubberband() is so why 
> not make this splitter resize non-opaque? It doesn't look opaque and
> flickers perhaps a bit too much when releasing the splitter but it
> makes resizing possible.

Yes, it does some extra resizes (cannot those events be blocked?), but 
it works, so it's much better than not being able to resize the sidebar 
at all.

Andras
Comment 23 James Richard Tyrer 2004-06-29 05:48:24 UTC
This now appears to work in BETA 1 so it is resolved unless there will be a KDE-3.2.4 release.

--
JRT
Comment 24 CTWaley 2004-12-21 23:50:42 UTC
FYI - I, too, have this problem in KDE 3.2.3..........I was able to work around this issue by following Rob Ross's suggestion by unchecking the "Hide tab bar when only one tab is open" option and then clicked the Apply button at the bottom of the dialog box........And I didn't have to restart Konq for it to take effect........ :-)

Glad to hear it will be resolved in future versions....
Comment 25 Stephan Binner 2004-12-23 11:36:35 UTC
What future version? It's fixed in KDE 3.3 to my best knowledge, you just have to upgrade.
Comment 26 qt-bugs 2005-01-19 17:13:14 UTC
On Wednesday, 26. May 2004 15:42 Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> QSplitter makes it rather difficult to detect when the user moves the
> splitter
> as opposed to size changes due to layout management.
>
> This would be much easier if QSplitter::moveSplitter() was to emit a
> signal.

Hi Waldo,

We've added a splitterMoved() signal to QSplitter in Qt 4. If you want
to try it out and give some feedback, you are more than welcome to do
so :)

Hope this helps,

--
Trenton Schulz
Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway