Bug 76360

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.

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.

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" :)

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.

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.

*** Bug 76636 has been marked as a duplicate of this bug. ***

Do you see this problem when you run konqi as root?
I do not and I am wandering why...

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.

Oh, and this is on 3.2.2

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.

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.

*** Bug 72884 has been marked as a duplicate of this bug. ***

*** Bug 81248 has been marked as a duplicate of this bug. ***

Still happening in KDE 3.2.2. BTW, this is a Regression because the problem didn't occur in elder KDE versions.

#11: Problem is that QSplitter doesn't have any hooks to detect user initiated resizing.

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

Subclass QSplitter, override the moveSplitter() and emit the signal 
there? Not so clean, but might help to get rid of this ugly bug.

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

*** Bug 80052 has been marked as a duplicate of this bug. ***

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.

Committed until someone offers a better solution.

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

This now appears to work in BETA 1 so it is resolved unless there will be a KDE-3.2.4 release.

--
JRT

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....

What future version? It's fixed in KDE 3.3 to my best knowledge, you just have to upgrade.

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