Version: (using KDE KDE 3.2.0) Installed from: SuSE RPMs OS: Linux Using the KDE 3.2 RC1 packages I cannot resize columns in juk anymore, they always jump back to a certain size. It seems as if juk tries to fit them all on the screen by giving the widest most space, i.e. a certain percentage of the page width.
Well, it's not "broken" it just doesn't work like it did before. However I do intend to add an option for setting the column widths manually. (And actually the column widths are based on width of the data they contain and given a percentage of the total width based on that.)
*** Bug 83153 has been marked as a duplicate of this bug. ***
If you really think that this is not a bug, then at least use listView->header()->setResizeEnabled(false); But what this app does, is in my opinion against basic UI style guide: "Give the user the power" and not force him to anything you think is best.
I can tell you not being able to adjust the columns make the display useless, even as a visual aid. In some listings all I get is something like "arti...". It is quite common to expect to be able to manually resize a column width, usually double clicking the column border. Now why would I WANT that... try editing files individually with the columns collapse - useless. Take a look at amarok for a good example of how it can be done.
> If you really think that this is not a bug [...] Actually I didn't intend marking as a duplicate of this to mean that it isn't a bug -- just that they're essentially the same request. I'm changing the status now. > But what this app does, is in my opinion against basic UI style guide: > "Give the user the power" and not force him to anything you think is best. That's actually almost completely bogus. ;-) Most of the things in every user interface have lots of "decisions made for the user" -- that's a big part of what designing interfaces is all about. The only problem here is that there's a case that the user is used to being able to change this particular interface element and that doesn't work in JuK. [next message] > Take a look at amarok for a good example of how it can be done. Actually amaroK uses static column widths which for the "common case" with JuK would be a big step back. With the default set of visible columns on a modern display (1024x768) "weighted columns" (columns whose width is based on the percentage of the on screen data that they contain) makes it possible to see much more information quickly and generally looks nicer. Again, the problem is that this annoys a handful of "power users" and as such there should be a way to turn it off.
A simple solution is to have "fit to page" option, as a button. You can have your "ideal" solution and power users can get it back to the way they expect. Oh to see everything I have to remove the filename column, which takes way too much space (~30%) and shrink the tree display. You have it based on percentages correct? ~70% of the filename is usually directory structures. So at present all columns shrink so I can see the parent directory. How is this "better"? Other things: Track is left justified not right justified - the standard is right justified. During testing I noticed that some columns would take more space (e.g., 26-character album taking up 36 characters when the title is being truncated) If this was accounted for my test would have been fully displayed (less filename). Oh, talking about user interface. Do you know that Save & Delete under "Tagger" is not that intuitive? Took me a few minutes to find it. How about something like like a tagger toolbar which appears when the Tagger is selected? Or dare I suggest buttons as part of the tagger "dialog"?
> A simple solution is to have "fit to page" option, as a button. You can have > your "ideal" solution and power users can get it back to the way they expect. Well, the current way will stay the default. But other than that this is exactly what this bug report asks for... > Oh to see everything I have to remove the filename column, which takes way > too much space (~30%) and shrink the tree display. You have it based on > percentages correct? ~70% of the filename is usually directory structures. So > at present all columns shrink so I can see the parent directory. How is this > "better"? (a) The file name isn't shown by default -- it's not relevant to users in most cases (b) In current CVS it doesn't show the path except in the tooltip -- it just shows the filename (c) Again, this is about the common case -- in the common case it's preferable to not have to scroll left and right to see the information and with the default set of visible columns most of the information should fit on the screen. Using the style that you suggested if you had one track with 200 characters the entire track column would make that fit and show a lot less information since the average track name is probably something like 15 characters.
This is somewhat moot if you are going to implement an option to revert back to standard behavior for columns. For clarification, the filename example, is to point out that the present solution is not *the* ideal solution thus a practical reason to implement the request. Not to mention there is no way to "adjust" and the trouble required to make it usable, as it is now. If you follow the Gnome's "Nautalus" spatial debate, it isn't so much trying something new but *forcing* it on users through obscure configurations. I agree (in both cases) as a *default* but it should never be the *only* way, especially when Konqueror and the common way is to have adjustable columns.
From my point of view the current way of handling column-width does have advantages, if one applies it to an environment where you only have a limited number of columns. Yet, even then juk has to be run maximised, otherwise the columns get to small and thus clearly unuseable. For small resolutions this is even worse. The latter might also be the reason, as to why this kind of column-handling is not the default behaviour for konqueror. It could be argued that what is good for konqueror cannot be bad for other apps. However it is certain, that konqueror's way of handling things does have its reason and these do also apply to juk. Thus juk's way of handling columns should be condsidered as an extra and thus at least be optional and not forced onto the user.
> Thus juk's way of handling columns should be condsidered as an extra and thus > at least be optional and not forced onto the user. Guys this is getting a little redundant since I've planned on making this configurable since before this was filed. I've said several times that I'll make this configurable; this is kind of "beating a dead horse".
Set a date and nobody will bother till then. This issue was filed more than five months ago. Maybe next time you remove a feature and then implement a configuration to bring it back, you should implement the configuration and not simply remove it. This was the same with the clear-button, first removed, then brought back, hopefully. This is more work for you than it could have been.
> Set a date and nobody will bother till then. Sorry -- it doesn't work that way. I have a full time job and a generally busy life and do this in my spare time and this is far from the highest priority issue around. How about this instead -- I'll just ignore further comments. ;-) > Maybe next time you remove a feature and then implement a configuration to > bring it back, you should implement the configuration and not simply remove > it. Uhm, sorry -- if you want to start whining about things please take it somewhere else. Again, this is my hobby; you've asked for something and I've told you that I'll try to get it done. If you expect anything more than that you're going to be sorely disappointed. > This was the same with the clear-button, first removed, then brought back, > hopefully. This is more work for you than it could have been. Well, that's because someone thought of a better way of doing it. And in that case it wasn't ever in a release that I expected to be widely distributed (1.95); unfortunately that release was shipped by almost every distribution despite the fact that I said on the site that it wasn't in suitable shape for such.
I do not know, if this exists in the kde-bug-tracker, but for mozilla there is a keyword <helpwanted> that could be used to get help, if there is not enough time on your side.
WORKAROUND: This works on my system: Resize the column you want by click and draging, making sure to hold the left mouse button. While holding the left mouse button, move your cursor down so that it is over a track (keeping the column the size you want) and right click to bring up the context menu. Now left click on a track. The column won't snap back into place. Near as I can tell, this is due to a bug in KDE that prevents KDE from sending the event that tells juk to resize the column if you've done a right click in the mean time. This bug/feature may be specific to my system (slack 9.1, kde 3.2.3 from the slackware contrib packages). It's not a very good solution (if you mouse over the column title bar KDE picks up and the event and snaps things back, so you won't be able to resize more than one column), but it's better than nothing in the mean time.
ooooh, this is an annoying bug. It made adding the full file name (+path) option completely useless as it pushes everything else into permanently unreadable column sizes. I'm gonna vote and say no more because there's lots of great new features I know I'd appreciate if this bug didn't catch in the throat so painfully. (I'm using KDE3.3)
CVS commit by mpyne: Implement bug 73435 (Add option for manual column widths). Due to a limitation in QListViews, hiding columns doesn't work too well in this mode, which you'll probably encounter while resizing columns next to hidden columns. If I manage to hack around this limitation enough I'll close the bug I guess. I think we need a Config dialog now, right now you can switch between Manual and Automatic Resizing in the view menu. CCMAIL:73435@bugs.kde.org M +4 -0 juk.cpp 1.222 M +2 -1 jukui-rtl.rc 1.3 M +2 -1 jukui.rc 1.54 M +8 -1 playlist.cpp 1.257 --- kdemultimedia/juk/juk.cpp #1.221:1.222 @@ -134,4 +134,8 @@ void JuK::setupActions() new KAction(i18n("&Next Track"), "player_end", KShortcut(), m_player, SLOT(forward()), actions(), "forward"); new KToggleAction(i18n("&Loop Playlist"), 0, KShortcut(), actions(), "loopPlaylist"); + KToggleAction *resizeColumnAction = + new KToggleAction(i18n("&Resize Column Headers Manually"), + KShortcut(), actions(), "resizeColumnsManually"); + resizeColumnAction->setCheckedState(i18n("&Resize Column Headers Automatically")); // the following are not visible by default --- kdemultimedia/juk/playlist.cpp #1.256:1.257 @@ -209,4 +209,7 @@ Playlist::SharedSettings::SharedSettings KConfigGroup config(KGlobal::config(), "PlaylistShared"); + bool resizeColumnsManually = config.readBoolEntry("ResizeColumnsManually", false); + action<KToggleAction>("resizeColumnsManually")->setChecked(resizeColumnsManually); + // save column order m_columnOrder = config.readIntListEntry("ColumnOrder"); @@ -264,4 +267,7 @@ void Playlist::SharedSettings::writeConf config.writeEntry("InlineCompletionMode", m_inlineCompletion); + bool resizeColumnsManually = ActionCollection::action<KToggleAction>("resizeColumnsManually")->isChecked(); + config.writeEntry("ResizeColumnsManually", resizeColumnsManually); + KGlobal::config()->sync(); } @@ -820,5 +826,6 @@ bool Playlist::eventFilter(QObject *watc case QEvent::MouseButtonRelease: { - if(m_widthsDirty) + KToggleAction *manualResize = action<KToggleAction>("resizeColumnsManually"); + if(manualResize && !manualResize->isChecked() && m_widthsDirty) QTimer::singleShot(0, this, SLOT(slotUpdateColumnWidths())); break; --- kdemultimedia/juk/jukui.rc #1.53:1.54 @@ -2,5 +2,5 @@ <!DOCTYPE kpartgui> -<kpartgui name="juk" version="6"> +<kpartgui name="juk" version="7"> <MenuBar> <Menu name="file" noMerge="1"><text>&File</text> @@ -32,4 +32,5 @@ <Action name="showUpcoming"/> <Action name="showColumns"/> + <Action name="resizeColumnsManually"/> <Separator/> --- kdemultimedia/juk/jukui-rtl.rc #1.2:1.3 @@ -1,4 +1,4 @@ <!DOCTYPE kpartgui> -<kpartgui name="juk" version="6"> +<kpartgui name="juk" version="7"> <MenuBar> <Menu name="file" noMerge="1"><text>&File</text> @@ -30,4 +30,5 @@ <Action name="showUpcoming"/> <Action name="showColumns"/> + <Action name="resizeColumnsManually"/> <Separator/>
CVS commit by mpyne: I do believe that this is the best we're going to be able to do with manual column resizing combined with the possibility of showing and hiding columns. With that in mind, I'm closing bug 73435 (Add option for manual column width). CCMAIL:73435-done@bugs.kde.org M +8 -0 playlist.cpp 1.260 --- kdemultimedia/juk/playlist.cpp #1.259:1.260 @@ -999,4 +999,10 @@ void Playlist::hideColumn(int c, bool up setColumnWidth(c, 0); + // Moving the column to the end seems to prevent it from randomly + // popping up. + + header()->moveSection(c, header()->count()); + header()->setResizeEnabled(false, c); + if(c == m_leftColumn) { if(m_playingItem) { @@ -1028,4 +1034,6 @@ void Playlist::showColumn(int c, bool up setColumnWidth(c, 1); + header()->setResizeEnabled(true, c); + header()->moveSection(c, c); // Approximate old position if(c == leftMostVisibleColumn()) {
On Saturday 02 October 2004 12:19, Michael Pyne wrote: > CVS commit by mpyne: > > I do believe that this is the best we're going to be able to do with manual > column resizing combined with the possibility of showing and hiding columns. > > With that in mind, I'm closing bug 73435 (Add option for manual column > width). Scrollbars still don't come on and I think I'd prefer this to also be in the column header context menu. We'll see. That one's getting a bit crowded, but it seems more appropriate.
CVS commit by wheeler: Automatically switch on manual column width mode if the user tries to resize the columns in automatic width mode. Use scrollbars where appropriate in manual width mode. CCMAIL:73435@bugs.kde.org M +47 -4 playlist.cpp 1.261 M +2 -0 playlist.h 1.142 --- kdemultimedia/juk/playlist.cpp #1.260:1.261 @@ -294,4 +294,5 @@ Playlist::Playlist(PlaylistCollection *c m_polished(false), m_applySharedSettings(true), + m_mousePressed(false), m_disableColumnWidthUpdates(true), m_widthsDirty(true), @@ -314,4 +315,5 @@ Playlist::Playlist(PlaylistCollection *c m_polished(false), m_applySharedSettings(true), + m_mousePressed(false), m_disableColumnWidthUpdates(true), m_widthsDirty(true), @@ -335,4 +337,5 @@ Playlist::Playlist(PlaylistCollection *c m_polished(false), m_applySharedSettings(true), + m_mousePressed(false), m_disableColumnWidthUpdates(true), m_widthsDirty(true), @@ -355,4 +358,5 @@ Playlist::Playlist(PlaylistCollection *c m_polished(false), m_applySharedSettings(true), + m_mousePressed(false), m_disableColumnWidthUpdates(true), m_widthsDirty(true), @@ -827,12 +831,22 @@ bool Playlist::eventFilter(QObject *watc case QEvent::MouseButtonPress: { - if(static_cast<QMouseEvent *>(e)->button() == RightButton) + switch(static_cast<QMouseEvent *>(e)->button()) { + case RightButton: m_headerMenu->popup(QCursor::pos()); break; + case LeftButton: + m_mousePressed = true; + break; + default: + break; + } + break; } case QEvent::MouseButtonRelease: { - KToggleAction *manualResize = action<KToggleAction>("resizeColumnsManually"); - if(manualResize && !manualResize->isChecked() && m_widthsDirty) + if(static_cast<QMouseEvent *>(e)->button() == LeftButton) + m_mousePressed = false; + + if(!action<KToggleAction>("resizeColumnsManually")->isChecked() && m_widthsDirty) QTimer::singleShot(0, this, SLOT(slotUpdateColumnWidths())); break; @@ -1130,4 +1144,10 @@ void Playlist::polish() this, SLOT(slotInlineCompletionModeChanged(KGlobalSettings::Completion))); + connect(action("resizeColumnsManually"), SIGNAL(activated()), + this, SLOT(slotColumnResizeModeChanged())); + + if(action<KToggleAction>("resizeColumnsManually")->isChecked()) + setHScrollBarMode(Auto); + else setHScrollBarMode(AlwaysOff); @@ -1410,4 +1430,15 @@ PlaylistItem *Playlist::addFile(const QS //////////////////////////////////////////////////////////////////////////////// +void Playlist::slotColumnResizeModeChanged() +{ + if(action<KToggleAction>("resizeColumnsManually")->isChecked()) + setHScrollBarMode(Auto); + else + setHScrollBarMode(AlwaysOff); + + if(!action<KToggleAction>("resizeColumnsManually")->isChecked()) + slotUpdateColumnWidths(); +} + void Playlist::slotUpdateColumnWidths() { @@ -1809,4 +1840,16 @@ void Playlist::slotColumnSizeChanged(int m_widthsDirty = true; m_columnFixedWidths[column] = newSize; + + if(m_mousePressed && !action<KToggleAction>("resizeColumnsManually")->isChecked()) { + KMessageBox::information(this, + i18n("Manual column widths have been enabled. You can " + "switch back to automatic column sizes in the view " + "menu."), + i18n("Manual Column Widths Enabled"), + "ShowManualColumnWidthInformation"); + + action<KToggleAction>("resizeColumnsManually")->setChecked(true); + slotColumnResizeModeChanged(); + } } --- kdemultimedia/juk/playlist.h #1.141:1.142 @@ -498,4 +498,5 @@ private: private slots: + void slotColumnResizeModeChanged(); void slotUpdateColumnWidths(); @@ -571,4 +572,5 @@ private: bool m_polished; bool m_applySharedSettings; + bool m_mousePressed; QValueList<int> m_weightDirty;
*** Bug 93325 has been marked as a duplicate of this bug. ***
*** Bug 93364 has been marked as a duplicate of this bug. ***
Is it really fixed? In which KDE version? I use KDE 3.2.3 (Debian testing) and there I am unable to resize the columns. What is horrible.
Yes, it is. In KDE 3.4 beta 1, at least.