Version: 1.2.4 (using KDE KDE 3.4.1) Installed from: SuSE RPMs Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) OS: Linux If I change the width of a column in the playlist editor, the column right of the column I am changing is changing it's width as well. Let say I change the width of column no. 2, then column no. 3 changes that way that the total width of column no.2 plus column no. 3 is constant. It would be better not to change the width of the other column like in a spread sheet application. Regards, Jochen
We implemented this specifically for aesthetic reasons. We wouldn't change it back unless there was an excellent reason.
Before you go on reading: Please don't missundestand me, I really do like amarok and from my point of view it can't honored enough what you do! Know to the response of your answer: I am really surprised! You basically say that any spreadsheet application in the world isn't aesthetic. As it is now I consider the "feature" changing the width of a column as unusable and totally anoying. I would like to know the excellent reason why it was done this way....? Do we really talk about the same feature? You change the width of one column and the column next to it has the width zero at the end, so you have to change this one again, but uuups now the column next to it has the length zero and so on. I really can't see what here the aesthetic reason is! Do you think this way it is userfriendly? [] yes [] no In terms of usuabilty I just would expect that is works like any other application in the world which has somewhere columns where you can change the width. If you're interested to discuss it further I am happy to do so and try to convince you. If you don't mark this request as "resolved" and I will keep quiet.
Jochen - sorry I was a little abrupt with my reply! The problem which we faced is that KListView works in a strange way with columns. Removing columns in the playlist would create an unused 'empty space', which the user would have to manually resize the columns to fit the window width. Additionally, resizing the window would put the column widths out of skew. I don't know if you have noticed, but manually resizing column widths to fit the window is a fiddly task - and we wanted the user to have an automatic configuration of the column widths. Whilst I understand your concern about not being able to have a horizontal scroll bar to fit more columns into the window, it seems that the majority of users benefit greatly in convenience and provides a more polished interface.
Sorry, but the way column resizing works right now is brain dead. I'd have a hard time believing I'm the only who finds it frustrating and inconvenient that resizing one column means resizing them all. That's unacceptable in a UI! Say for example I have 5 columns and want to increase the width of column 2. As I drag it to the right, columns 3, 4, and 5 all get compressed! In what world is this acceptable? The way it should work is that when I drag the right-hand border of column 2 to the right, columns 3, 4, and 5 are "pushed" to the right. If the total column width begins to exceed window width, then a horizontal scrollbar appears. Maybe this should be marked 'upstream' and KListView should be fixed. Because if this behaviour is the same for all KDE apps, you'd have a hard time convincing me to switch to KDE. I don't understand how removing columns would create a problem. The program could just move all the columns to the right over to the right-most border of the column to the left of the removed column. Resizing the window shouldn't be a problem either. Leave the column widths the same - if you make the window smaller, a horizontal scrollbar appears, and if you make the window larger, you're left with empty space on the right-hand side of the screen. DO NOT resize the columns for the user. That's how I would expect any application to behave. I don't know how you can say the current behaviour is convenient for anyone and provides a "polished" interface.
"We implemented this specifically for aesthetic reasons." So no, its not a KListView feature.
I often ask myself why this "stupid" and absolutely unusual behaviour was implemented. It is just impossible to show 10 columns on 1024x768 with visible context browser. But hey, it's amarok and does things it's own way (even if it's different from the rest of the world). And on this account i love amarok. So i've accepted it and just don't fall back on information i get in other music players. >> "We implemented this specifically for aesthetic reasons." I'll always fall back on this quotation when i resize the the first column to 80% (and then back again..) and three-quarter of the other colums are f**** up. (1.4-SVN) So wouldn't it be more aesthetic to show a nice vertical scrollbar? Please don't understand this as an attack, it's just my opinion. :-) So centralised this feature has both advantages and disadvantages. regards and keep it up! Tobias
Yes, a horizontal scroller would indeed be better if you have 10 (!) columns. But the current behavior works better for most (since scrolling is annoying). I would recommend hiding and showing columns rather then dealing with 1px column widths.
I don't see how the current behaviour works at all. Scrolling is more annoying than resizing every column when you want to change the width of one? Could someone please provide me an example where the current behaviour is best? Because I find the current behaviour tremendously annoying and I seriously do not understand how it's useful.
The current behaviour is useful when columns resize because of the window being resized. When individual column widths are changed by the user, it's perhaps not optimal. On 24 Jan 2006 00:34:34 -0000, Duke <duke@spacebox.net> wrote: [bugs.kde.org quoted mail]
Reopening to close properly.
Just some advice to some of the people that commented on this bug: the way you report something makes a big difference, especially when it's about free software. If you think something is not working properly, and you're not coming with a patch, at least respect the developers, as they're the persons that will spend their valuable time fixing that. Irony, or saying that something is stupid or brain dead doesn't help your request at all. That's exactly the opposite. Remember that people use programs differently, many love that behaviour, even with the problems, as you don't get the horrible horizontal scrollbar, and don't have wasted space. On this case, just saying something like "it's impossible to have all the collumns I want" would be pretty enough to show how important it is. Anyway, as I was quite happy yesterday, I added an option, so that people who like having many collumns could turn it off. It's called "Smart Column Resizing", and is on the context meny of the playlist columns' titles. For 1.4 only. Have fun. When this option is ON (and it's on by default), changing one column will, of course, affect the others. If you don't like, turn it off.
Alexandre, you're right. So excuse my unsound diction and thanks a lot for this option.