Version: SVN (using KDE 4.3.0) OS: Linux Installed from: SuSE RPMs This is basically a regression from kdevelop3 in my point of view. The attached screenshot shows kdevelop4 and 3 together, with the same documents open. kdevelop4 is able to show 2.5 tabs simultaneously, while kdevelop3 shows 4.5 tabs in the same area. The problems I see: 1. The Line / Column display (biggest offender). It's also much larger than it should be (the area to the left of it is empty). If this was supposed to be in status bar, it's not (there's no status bar, even if it's enabled). 2. Tab texts have unnecessarily large paddings. (Qt4 is known to have larger paddings than Qt3 by default, so this may be that). 3. The "close" icon also acts as a "modified" icon (quite usefully) in kdevelop3, but no such thing in kdevelop4.
Created attachment 36175 [details] screenshot showing the regression
(In reply to comment #0) > This is basically a regression from kdevelop3 in my point of view. That doesn't count anything, we're creating a new app here, so there cannot be any regressions. > The attached screenshot shows kdevelop4 and 3 together, with the same documents > open. kdevelop4 is able to show 2.5 tabs simultaneously, while kdevelop3 shows > 4.5 tabs in the same area. Too bad, but yeah, tabs are the worst UI for displaying file. They simply don't scale, just disable them ;) > 1. The Line / Column display (biggest offender). It's also much larger than it > should be (the area to the left of it is empty). I can't see our code adding any additional space, so this could be a style issue (I also have a bit of extra space here, but not as much as you see). > If this was supposed to be in > status bar, it's not (there's no status bar, even if it's enabled). No, because the statusbar is a very small area in the bottom-right area where the progress bar is shown. There's no separate statusbar line, which allows us to show more editor content. > 2. Tab texts have unnecessarily large paddings. (Qt4 is known to have larger > paddings than Qt3 by default, so this may be that). We don't do anything to those texts, so thats definetly Qt, also I can't say I have a lot of padding here, so again probably a style issue. > 3. The "close" icon also acts as a "modified" icon (quite usefully) in > kdevelop3, but no such thing in kdevelop4. Thats actually wrong, we do have a modified icon (on the left), the reason this is differently in kdevelop3 is because the close-icon on tabs was actually a hack around the missing functionality in Qt3. So, to conclude, I can't see any bug in kdevelop, hence closing this.
(In reply to comment #2) > Too bad, but yeah, tabs are the worst UI for displaying file. They simply don't > scale, just disable them ;) Well, do you have a usable alternative? If you're refering to the Documents tool view, then no, it's not good enough. The documents are ordered by type and alphabetically, instead of an order in which they were opened. Also, constant switching between Documents and Projects views just to open a new file is not fun. Moving one of them to the other side is not really an option due to limited horizontal resolution. The Projects tool view is also no good, it contains too many entries with no indication of which ones are open and which ones are not. Also, it doesn't display out-of-project files. Plus, it requires a double-click (why does it not honor KDE settings anyway?). As for scaling, it's not like I need to have 20 tabs opened simultaneously (well, I do that in browsers, but this is no browser). 4 active documents (tabs) is usually enough for me, and kdevelop3 handled that just well. There is also a possibility of adding an option to make the tabbar take the whole horizontal area (going above the tool views). Opera does this (see its panels), and does it very well. Tabs have been an integral part of every IDE I've seen, so crippling that feature is simply counter-productive. > > 1. The Line / Column display (biggest offender). It's also much larger than it > > should be (the area to the left of it is empty). > > I can't see our code adding any additional space, so this could be a style > issue (I also have a bit of extra space here, but not as much as you see). > > > If this was supposed to be in > > status bar, it's not (there's no status bar, even if it's enabled). > > No, because the statusbar is a very small area in the bottom-right area where > the progress bar is shown. There's no separate statusbar line, which allows us > to show more editor content. Well, then consider this a wishlist for hiding the Line / Column display, or moving it to the status bar (bottom right corner?). It certainly will do less usability damage there than in the tab bar. > > 2. Tab texts have unnecessarily large paddings. (Qt4 is known to have larger > > paddings than Qt3 by default, so this may be that). > > We don't do anything to those texts, so thats definetly Qt, also I can't say I > have a lot of padding here, so again probably a style issue. Yes, now that you mention it, it seems to be a styling problem. Setting the stylesheet with small padding helps, but disables the styling, so no immediate workaround there (aside from changing to oxygen, which I really don't like)... > > 3. The "close" icon also acts as a "modified" icon (quite usefully) in > > kdevelop3, but no such thing in kdevelop4. > > Thats actually wrong, we do have a modified icon (on the left), the reason this > is differently in kdevelop3 is because the close-icon on tabs was actually a > hack around the missing functionality in Qt3. What I meant is that in kdevelop3 there is only one icon, which acts as both "close" and "modified", depending on situation. In kdevelop4 there are two icons (modified to the left, close to the right), which makes the tab larger horizontally. The reasons for implementing it that way in kdevelop3 may have been because of the missing functionality, but the result (from user standpoint) was more compact tabs, which is a good thing. > So, to conclude, I can't see any bug in kdevelop, hence closing this. It was never filed as bug, but as a wishlist. So, I'll reopen it if you don't mind.
I also haven't seen a usable alternative to tabs yet. I think it's a valid wish to make them more compact. There's many possible ways of doing that: - Move the line/col info into the place where we show the progress-bar - Hide the 'close' button - Multiline-tabbar if required..
> - Hide the 'close' button AFAIK, Kile had the close button hidden by default (in an older release maybe before 2.1beta, just noticed the change), and showed it when hovering the tab. They also added a short delay where the button is "grayed out", so you don't accidentally close it. However, that behavior changed, current build don't do that anymore (sadly). I think that would be a nice alternative, as the close button did not take any space and the tab text was shortened when the button was visible,,
(In reply to comment #3) > (In reply to comment #2) > > Too bad, but yeah, tabs are the worst UI for displaying file. They simply don't > > scale, just disable them ;) > > Well, do you have a usable alternative? One would be the documentswitcher (try Ctrl+Tab). Its not open all the time, but then again with tabs you also only have a minor amount of files visible at the same time. > If you're refering to the Documents tool view, then no, it's not good enough. > The documents are ordered by type and alphabetically, instead of an order in > which they were opened. Also, constant switching between Documents and Projects > views just to open a new file is not fun. You do know about quickopen, do you? The only things I find myself using the projects view for are selecting an item to add to the buildset, or doing VCS actions. > Moving one of them to the other side > is not really an option due to limited horizontal resolution. You can also move either to the bottom. > The Projects tool view is also no good, it contains too many entries with no > indication of which ones are open Why should it, thats not its purpose. > and which ones are not. Also, it doesn't > display out-of-project files. Thats on purpose, if you want out-of-project files, use the filesystem view. > Plus, it requires a double-click (why does it not > honor KDE settings anyway?). Because there's no usable alternative. Single-clicking in the projects treeview as it is currently has major usability problems. > As for scaling, it's not like I need to have 20 tabs opened simultaneously > (well, I do that in browsers, but this is no browser). 4 active documents > (tabs) is usually enough for me, and kdevelop3 handled that just well. Lucky you ;) > There is also a possibility of adding an option to make the tabbar take the > whole horizontal area (going above the tool views). Opera does this (see its > panels), and does it very well. That doesn't make the slightest sense to me - ui-wise. The tabbar is specific for the editor area, it doesn't have anything to do with the toolviews. > Tabs have been an integral part of every IDE I've seen, so crippling that > feature is simply counter-productive. Well, we're not crippling it on purpose, in fact the problem is mostly that nobody works on the relevant code. > > > 1. The Line / Column display (biggest offender). It's also much larger than it > > > should be (the area to the left of it is empty). > > > > I can't see our code adding any additional space, so this could be a style > > issue (I also have a bit of extra space here, but not as much as you see). > > > > > If this was supposed to be in > > > status bar, it's not (there's no status bar, even if it's enabled). > > > > No, because the statusbar is a very small area in the bottom-right area where > > the progress bar is shown. There's no separate statusbar line, which allows us > > to show more editor content. > > Well, then consider this a wishlist for hiding the Line / Column display, IMHO line/col info is a major information for text editor and I don't like to have an option for disabling it. > or > moving it to the status bar (bottom right corner?). It certainly will do less > usability damage there than in the tab bar. That one doesn't work with split-views and it means disconnecting the information from the actual editor area. So in fact this does have usability issues. > > > 3. The "close" icon also acts as a "modified" icon (quite usefully) in > > > kdevelop3, but no such thing in kdevelop4. > > > > Thats actually wrong, we do have a modified icon (on the left), the reason this > > is differently in kdevelop3 is because the close-icon on tabs was actually a > > hack around the missing functionality in Qt3. > > What I meant is that in kdevelop3 there is only one icon, which acts as both > "close" and "modified", depending on situation. Yeah and thats actually quite bad usability. > In kdevelop4 there are two icons (modified to the left, close to the right), > which makes the tab larger horizontally. Thats the case for any KDE4 app, so we're just consistent here. > The reasons for implementing it that way in kdevelop3 may have been because of > the missing functionality, but the result (from user standpoint) was more > compact tabs, which is a good thing. We're not going to add hacks to create custom tabs. so this is a wontfix.
(In reply to comment #4) > I think it's a valid wish to make them more compact. There's many possible > ways of doing that: > - Move the line/col info into the place where we show the progress-bar Not an option as I said in my answer to Alexander, it disconnects the information from the editor and doesn't work with split-view. > - Hide the 'close' button Not an option IMHO. The close button is an important way of closing tabs. And I don't like adding 20 options with all the needed amount of code to be able to fully customize how the tabbar looks. > - Multiline-tabbar if required.. Definetly not an option, apart from this needing complete custom implementation on our side, multiline tabbars take away vertical space again. I'd rather see the status-line-in-the-editor re-appear (as non-default option) than this.
(In reply to comment #6) > (In reply to comment #3) > > (In reply to comment #2) > > > Too bad, but yeah, tabs are the worst UI for displaying file. They simply don't > > > scale, just disable them ;) > > > > Well, do you have a usable alternative? > > One would be the documentswitcher (try Ctrl+Tab). Its not open all the time, > but then again with tabs you also only have a minor amount of files visible at > the same time. Well, it's something, but still doesn't beat the single click required to activate, say, the fourth tab. > > If you're refering to the Documents tool view, then no, it's not good enough. > > The documents are ordered by type and alphabetically, instead of an order in > > which they were opened. Also, constant switching between Documents and Projects > > views just to open a new file is not fun. > > You do know about quickopen, do you? The only things I find myself using the > projects view for are selecting an item to add to the buildset, or doing VCS > actions. I do know about quickopen. Still, it requires too many clicks / keyboard events. Plus, the auto-expanding thing when you click a file is distracting. > > Moving one of them to the other side > > is not really an option due to limited horizontal resolution. > > You can also move either to the bottom. The bottom area is in the lower side of my virtual resolution (beneath the initial physical resolution) to make room for the editor (the left pane and the editor take up my physical resolution), so that would ruin the good setup. > > The Projects tool view is also no good, it contains too many entries with no > > indication of which ones are open > > Why should it, thats not its purpose. I know, I was just saying it's not good for document switching in case you were advocating that. If you weren't, please forget I wrote that. > > and which ones are not. Also, it doesn't > > display out-of-project files. > > Thats on purpose, if you want out-of-project files, use the filesystem view. Same here. > > Plus, it requires a double-click (why does it not > > honor KDE settings anyway?). > > Because there's no usable alternative. Single-clicking in the projects treeview > as it is currently has major usability problems. Not sure about which usability problems you're refering to. Single-clicking worked like charm in kdevelop3, and I don't see how this is different. Anyway, I think the user should be able to make the choice. > > As for scaling, it's not like I need to have 20 tabs opened simultaneously > > (well, I do that in browsers, but this is no browser). 4 active documents > > (tabs) is usually enough for me, and kdevelop3 handled that just well. > > Lucky you ;) > > > There is also a possibility of adding an option to make the tabbar take the > > whole horizontal area (going above the tool views). Opera does this (see its > > panels), and does it very well. > > That doesn't make the slightest sense to me - ui-wise. The tabbar is specific > for the editor area, it doesn't have anything to do with the toolviews. Well, it may not make sense the first time you see it. But it did make sense for me in Opera, and I'm thankful they didn't do it any other way. What's important is that in the end, it doesn't matter if it looks "correct" or not. What matters is the general usability of a feature. If implementing it adds some space for a couple of tabs, and the user is able to do more with that setup, then it's definitely a plus. Also, it can always be an optional thing, so that people who need more tab space could enable it, while people who like the more "correct" look keep it disabled. > > Tabs have been an integral part of every IDE I've seen, so crippling that > > feature is simply counter-productive. > > Well, we're not crippling it on purpose, in fact the problem is mostly that > nobody works on the relevant code. Well, that's a completely different matter. :) > > > > 1. The Line / Column display (biggest offender). It's also much larger than it > > > > should be (the area to the left of it is empty). > > > > > > I can't see our code adding any additional space, so this could be a style > > > issue (I also have a bit of extra space here, but not as much as you see). > > > > > > > If this was supposed to be in > > > > status bar, it's not (there's no status bar, even if it's enabled). > > > > > > No, because the statusbar is a very small area in the bottom-right area where > > > the progress bar is shown. There's no separate statusbar line, which allows us > > > to show more editor content. > > > > Well, then consider this a wishlist for hiding the Line / Column display, > > IMHO line/col info is a major information for text editor and I don't like to > have an option for disabling it. What's wrong with an _option_? It's not like you're required to change that option from the default or something. Options are created for a reason - because we all have different habits, working patterns and preferences, otherwise we would all be in OS X land. "The way the creator intended" and "You don't need this" phrases come to mind. :) I may use the row / col information maybe once a week, while I definitely use tabs more often than that. :) > > or > > moving it to the status bar (bottom right corner?). It certainly will do less > > usability damage there than in the tab bar. > > That one doesn't work with split-views and it means disconnecting the > information from the actual editor area. So in fact this does have usability > issues. I didn't think about the split views. Still, even a separate row for col/row info would be better than the current layout IMHO. The vertical resolution required for that is less than tab height, while the horizontal is, well, a lot. You could also fit some other interesting features in there (like the working set stuff, for example). The vertical space may be a luxury on those new widescreen displays, but on 4/3 and 5/4 screens horizontal is usually more important (I'd rather spend 20 pixels vertically than 100 pixels horizontally). > > > > 3. The "close" icon also acts as a "modified" icon (quite usefully) in > > > > kdevelop3, but no such thing in kdevelop4. > > > > > > Thats actually wrong, we do have a modified icon (on the left), the reason this > > > is differently in kdevelop3 is because the close-icon on tabs was actually a > > > hack around the missing functionality in Qt3. > > > > What I meant is that in kdevelop3 there is only one icon, which acts as both > > "close" and "modified", depending on situation. > > Yeah and thats actually quite bad usability. Depends on individual preference, IMHO. > > In kdevelop4 there are two icons (modified to the left, close to the right), > > which makes the tab larger horizontally. > > Thats the case for any KDE4 app, so we're just consistent here. Haven't really used any other applications like that, can't say. Which ones are those anyway? (I don't use KDE much at all, I'm a Window Maker user). > > The reasons for implementing it that way in kdevelop3 may have been because of > > the missing functionality, but the result (from user standpoint) was more > > compact tabs, which is a good thing. > > We're not going to add hacks to create custom tabs. so this is a wontfix.
(In reply to comment #8) > (In reply to comment #6) > > Because there's no usable alternative. Single-clicking in the projects treeview > > as it is currently has major usability problems. > > Not sure about which usability problems you're refering to. Not being able to select items without triggering an expand/collapse or opening a file. Many workarounds for that require additional space, which the treeview doesn't have. That said, we do think we may have found a way to make it work, now somebody just needs to sit down and implement it. > > That doesn't make the slightest sense to me - ui-wise. The tabbar is specific > > for the editor area, it doesn't have anything to do with the toolviews. > > Well, it may not make sense the first time you see it. But it did make sense > for me in Opera, and I'm thankful they didn't do it any other way. > > What's important is that in the end, it doesn't matter if it looks "correct" or > not. What matters is the general usability of a feature. If implementing it > adds some space for a couple of tabs, and the user is able to do more with that > setup, then it's definitely a plus. > Also, it can always be an optional thing, so that people who need more tab > space could enable it, while people who like the more "correct" look keep it > disabled. Optional feature means extra code that has to be written and maintained. Looking at our track record we need to make sure to not introduce too many options, such that we can't maintain the code anymore. Additionally this doesn't work at all with split views, so again even more code to either disable split-views or disable this certain feature when split-views are activated. > > > > > 3. The "close" icon also acts as a "modified" icon (quite usefully) in > > > > > kdevelop3, but no such thing in kdevelop4. > > > > > > > > Thats actually wrong, we do have a modified icon (on the left), the reason this > > > > is differently in kdevelop3 is because the close-icon on tabs was actually a > > > > hack around the missing functionality in Qt3. > > > > > > What I meant is that in kdevelop3 there is only one icon, which acts as both > > > "close" and "modified", depending on situation. > > > > Yeah and thats actually quite bad usability. > > Depends on individual preference, IMHO. No, luckily this doesn't AFAIK. You're _hiding_ a given feature and only activating it via a hidden shortcut (moving the mouse over a purely information icon). > > > In kdevelop4 there are two icons (modified to the left, close to the right), > > > which makes the tab larger horizontally. > > > > Thats the case for any KDE4 app, so we're just consistent here. > > Haven't really used any other applications like that, can't say. Which ones are > those anyway? (I don't use KDE much at all, I'm a Window Maker user). konqueror has them, I don't seem to use another app that has close buttons on the tabs either.
About split views: You can show the active editor's col/row info only (in the status bar or wherever). I just checked Visual Studio and that's what it does too. So, row/col info in the status bar _is_ compatible with split views, after all. Also, completely hiding that info is also not a big deal (at least for me, if it's optional). I mean, when I actually need to know which line I'm on (rarely), Ctrl-G shows that information. And I don't seem to recall needing a column information, _ever_.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > Because there's no usable alternative. Single-clicking in the projects treeview > > > as it is currently has major usability problems. > > > > Not sure about which usability problems you're refering to. > > Not being able to select items without triggering an expand/collapse or opening > a file. Many workarounds for that require additional space, which the treeview > doesn't have. That said, we do think we may have found a way to make it work, > now somebody just needs to sit down and implement it. > > > > That doesn't make the slightest sense to me - ui-wise. The tabbar is specific > > > for the editor area, it doesn't have anything to do with the toolviews. > > > > Well, it may not make sense the first time you see it. But it did make sense > > for me in Opera, and I'm thankful they didn't do it any other way. > > > > What's important is that in the end, it doesn't matter if it looks "correct" or > > not. What matters is the general usability of a feature. If implementing it > > adds some space for a couple of tabs, and the user is able to do more with that > > setup, then it's definitely a plus. > > Also, it can always be an optional thing, so that people who need more tab > > space could enable it, while people who like the more "correct" look keep it > > disabled. > > Optional feature means extra code that has to be written and maintained. > Looking at our track record we need to make sure to not introduce too many > options, such that we can't maintain the code anymore. > > > > > What I meant is that in kdevelop3 there is only one icon, which acts as both > > > > "close" and "modified", depending on situation. > > > > > > Yeah and thats actually quite bad usability. > > > > Depends on individual preference, IMHO. > > No, luckily this doesn't AFAIK. You're _hiding_ a given feature and only > activating it via a hidden shortcut (moving the mouse over a purely information > icon). A constantly displayed close icon (so it's not purely information), which changes to "modified" only when the document is modified - I don't think it's _that_ confusing (95% of IDE users are power users, after all). I mean, the user already knows it's there, and it still does what it's supposed to (closes the document). The only thing that changes is that it conveys some additional information. Note that the "modified" icon could still look like a close icon, just a bit different to indicate that the document has been modified. > > > > In kdevelop4 there are two icons (modified to the left, close to the right), > > > > which makes the tab larger horizontally. > > > > > > Thats the case for any KDE4 app, so we're just consistent here. > > > > Haven't really used any other applications like that, can't say. Which ones are > > those anyway? (I don't use KDE much at all, I'm a Window Maker user). > > konqueror has them, I don't seem to use another app that has close buttons on > the tabs either. Not sure about your Konqueror, but mine certainly does _not_ display the close icons on tabs. It has a single close icon for the whole tab bar (to the right). While I may have changed that from the default (I don't remember exactly), at least it gives an option to do so. So, no "any KDE4 app" here. Anyway, I don't like hiding the close button, I'd rather have some other solution, but it's up to kdevelop developers to decide, of course. So far, the possible solutions for improving the tab bar are: 1. Allow hiding the col / row area. 2. Allow moving the col / row area to the status bar, and displaying information for active document only, in case of split views. 3. Manually set the minimal padding for tabs (useful for non-oxygen styles). 4. Make the close button change to "modified" button (the same close button, but with some effect maybe?). 5. Hide the tab-specific close buttons, maybe add a single close button for the whole tab bar. (See Konqueror with "Show close button on tabs" disabled). 6. Make the tab bar stretch the whole window width, above the left/right panels (see Opera). (This adds space for about 2 more tabs, for people who care more about functionality than the looks after the first 5 minutes). 7. Fix the maximum constant width for the tabs, ellipsizing the text. This helps with very long filenames. The full filenames can be displayed as tooltips. 8. Make the tabs shrink in width (up to some minimum size, maybe) if they don't fit. (See Konqueror, Opera, Firefox). Again, the tooltips will help here. 9. Multi-line tab bar. I think Firefox had an option for that, but I can't find it now. Opera offers 3 ways here: "No wrapping (aka shrink)", "Wrap to multiple lines", "Show extenders". So, should we do a web poll or something? :)
(In reply to comment #10) > About split views: > You can show the active editor's col/row info only (in the status bar or > wherever). I think I already said that we've explicitly moved it into the editor area to be able to show the information together with the view. Its useful to be able to see where the cursor is in the other view while working in this view. > I just checked Visual Studio and that's what it does too. That doesn't mean we need to do the same thing if there's a better alternative.
(In reply to comment #12) > (In reply to comment #10) > > About split views: > > You can show the active editor's col/row info only (in the status bar or > > wherever). > > I think I already said that we've explicitly moved it into the editor area to > be able to show the information together with the view. Its useful to be able > to see where the cursor is in the other view while working in this view. Yes, that means crippling another feature because of the split views (which is used a lot less than the tabs feature). There should be an option for those of us who don't really care about split views, or could live with a common col/row info in a status bar, or a col/row info in the tab bar only when using split views. > > I just checked Visual Studio and that's what it does too. > > That doesn't mean we need to do the same thing if there's a better alternative. One man's better alternative is another man's misfeature.
(In reply to comment #11) > A constantly displayed close icon (so it's not purely information), which > changes to "modified" only when the document is modified - I don't think it's > _that_ confusing You're misremembering how this works in kdevelop3. There was the icon on the tab all the time and only when you hovered it you got a close icon. Thats why its a hidden features and hidden features are bad usability. > (95% of IDE users are power users, after all). My experience shows that they're not. In fact those people that really have problems with KDevelop after the first start and for whom we try to improve the usability are people that haven't ever seen an IDE. > Not sure about your Konqueror, but mine certainly does _not_ display the close > icons on tabs. It has a single close icon for the whole tab bar (to the right). > While I may have changed that from the default (I don't remember exactly), at > least it gives an option to do so. So, no "any KDE4 app" here. I was a bit imprecise there I guess, I mean that all KDE4 apps that have a close icon on their tabs will have it on the right additionally to the normal icon on the left. > So far, the possible solutions for improving the tab bar are: > 1. Allow hiding the col / row area. > 2. Allow moving the col / row area to the status bar, and displaying > information for active document only, in case of split views. Can you please separate one of those into a separate wish. > 4. Make the close button change to "modified" button (the same close button, > but with some effect maybe?). This doesn't make any sense to me. > 5. Hide the tab-specific close buttons, maybe add a single close button for the > whole tab bar. (See Konqueror with "Show close button on tabs" disabled). Another wish please. > 6. Make the tab bar stretch the whole window width, above the left/right panels > (see Opera). (This adds space for about 2 more tabs, for people who care more > about functionality than the looks after the first 5 minutes). Not an option even as an optional feature IMHO. I don't want to cripple kdevelops looks or how it feels when being used for such a minor thing. > 7. Fix the maximum constant width for the tabs, ellipsizing the text. This > helps with very long filenames. The full filenames can be displayed as > tooltips. Another wish. > 8. Make the tabs shrink in width (up to some minimum size, maybe) if they don't > fit. (See Konqueror, Opera, Firefox). Again, the tooltips will help here. Not sure what you mean with "shrink". If the widget/style decides that n pixel are needed for a tab, then kdevelop shouldn't change that. > 9. Multi-line tab bar. I think Firefox had an option for that, but I can't find > it now. Opera offers 3 ways here: "No wrapping (aka shrink)", "Wrap to multiple > lines", "Show extenders". Needs far too much code as optional feature IMHO. > So, should we do a web poll or something? :) Thats completely useless as in the end of the day the only thing that matters is if you can find a developer to implement it.
PS: I'm out at this point, bugzilla is just unusable to discuss this. If you want to go on please join our development mailinglist.
I just came across this bug while searching for another one on Google. This bug report is quite convoluted and doesn't really address single issues. I agree with Andreas that we should rather drive this discussion on a mailing list if needed. Closing this one.