KVIrc
KVIrc copied to clipboard
kvirc
Fixed width option for UserList
Reported by Stanzilla on 14 Aug 2011 18:35:08 UTC A nice addition to the KVIrc options for themes would be the possibility to set a fixed width for the userlist so it can have the same one in every channel. I remember having a min/max width setting in version 3.x, even something like that would be cool.
Migrated from: https://svn.kvirc.de/kvirc/ticket/1197
+1 for configurable widths all around
But not a themes setting but rather a global setting akin to "Set windows props as default" popup function.
Implementing this feature request would probably solve https://github.com/kvirc/KVIrc/issues/900
fixed by https://github.com/kvirc/KVIrc/pull/2028
What I find interesting is @Stanzilla trolling, This request was made by him, yet, when someone voted to not implement #2028 he reacted with thumbs up (suggesting it shouldn't be implemented)
@Stanzilla please make up your mind.
So anyway, this already has been implemented so closing as FIXED.
@un1versal fixed width != minimum width. And that is no trolling, I just said that your suggestion of adding a minimum width is not a fix and actually doesn't help anyone.
I realize its not the same, but you can use it to that effect more or less.
as such Ill consider this closed since you also said that would be cool on request.
You wont get a maximum, so for a 2011 issue take and and smile.
I disagree. With a fixed width, the client would set the width of the pane when applying the theme. That is something entirely different from what has been done.
I remember having a min/max width setting in version 3.x, even something like that would be cool.
You get minimum dont use it if you dont like it,
I disagree. With a fixed width, the client would set the width of the pane when applying the theme. That is something entirely different from what has been done.
Its is not... it can be and is also set by theme. The difference being you dont get a maximum value to lock on a set min/max. usless to me imo, you never know the difference in this case.
That answer does not qualify to close the issue. Since the feature request is not done, it should stay open.
well no one else cared since 2011 so Im not going to do anymore about this and disagree with max values here.
You are welcome to have at it for your own local copy.
Can't you just leave the things alone that you have no clue about? You are not a developer, you are graphics guy, this is a code issue.
...quite a slap in the face after the months of work I put into this project. but there we have it.
I also am fully capable of understanding this feature fully since I implemented minimum width and and fully capable of implementing maximum width also, Only I disagree with it and will not implement it.
locked.
at that rate, we could probably mark 99 % of the issues here as wontfix, since they ehm... wont be fixed anyway i suppose.
We have enough labels here, I meant its not worth implementing the maximum width.
The minimum width solved an issue in #900 the maximum width is just a one person thing doesnt solve anything and has no benefits that justify its implementation...
I could do it, but for those reasons I do not think its worth the time and effort.
Hence I closed it...
Its obvious People who make feature req, want them implemented, but we cant very well implement everything either especially is law of diminishing returns applies.