> On April 17, 2013, 9:12 a.m., Alin M Elena wrote: > > lib/chat-text-edit.cpp, line 81 > > <http://git.reviewboard.kde.org/r/110061/diff/1/?file=139155#file139155line81> > > > > do you plan to make this two configurable? allow the user to set how > > many lines wants? > > also should not you have two linespacings? > > > > Thomas Pfeiffer wrote: > Please do _not_ make this configurable. Starting with two lines makes > sense to make it clear ot users that this is a multi-line edit box, but we do > not need a user-configurable value because we use an auto-expanding box. I > know that Pidgin was forked over this issue, but I think users will adjust to > auto-expanding boxes over time. > > Martin Klapetek wrote: > I don't think so, the logic is "twice the size of the font + the space > between lines", which seems ok. Also I don't want to see this configurable. > We can't provide configuration options for every single piece of our UIs. > > Róbert Szókovács wrote: > I wanted to give exactly these answers, thanks! > > Alin M Elena wrote: > Thomas and how having it configurable prevents the auto-expanding? > Martin... of course but remember the debate we had about 2 lines vs 1 > line and how people argued for one or another... giving them the chance to > configure how many lines want makes sense... > the two line spaces... one in between the two lines and another one > between the lower line and border... anyhow this is a detail we can change > later if feels bad... > I will say ship it now and keep the discussion open on configuration. > > Thomas Pfeiffer wrote: > Making it configurable of course does not prevent auto-expansion, but I > think that auto-expansion makes configurability of default height unnecessary. > Yes, people debate about a whole lot of things, but most of the time it's > just that they want to keep things like they are personally used to. Neither > a one-line default nor a two-line default are going to cause any real trouble > for anyone, the two-line default just has the slight advantage mentioned > above. > Yes, some people will complain, but if someone quits using KTp over an > extra line in the edit box, that user wasn't really convinced of KTp anyway. > I am for giving the option to turn _features_ which are useful to some users > but annoying to others on and off, but this is not a feature, this is a > little cosmetic detail. And if we make every little cosmetic detail > configurable (because there are always people vocally defending both ways), > we end up with KDE3-style config dialogs. > > Alin M Elena wrote: > Personally I am not for 1 or 2 lines... I have just seen the issue > debated about... > I will add the config option myself once this is committed and we shall > let the user decide. If one person wasted his time to ask for 2 lines and > argue why is good and another for 1 line and iirc no definitive arguments > were given at the time to drop one or another, I think the option is a good > candidate for a config entry... Why shall devs decide on the cosmetic the > user wants? > Arguing against the config I see it unconvincing... as it does not > increase the complexity of the code and gives freedom to the user to choose > -- I hope K input in our name still stands for that. Plus I offered myself to > do the job. > > Martin Klapetek wrote: > "Why shall devs decide on the cosmetic the user wants?" > > Why the user should decide? You know there are gazillions of styles of > everything and each individual likes something different ;) Now if we have > say 20,000 users and each likes something different, which of those users > that "want different cosmetics" we'll choose? We are the developers. We are > educated in this matter. We simply know better (granted, not always). We > should decide because it's our product after all. > > "gives freedom to the user to choose" > > Users do not know what they want for most of times. By making a choice > for them, we're making their life easier. (Btw. here's an awesome TED's talk > about the paradox of choice - http://www.youtube.com/watch?v=VO6XEQIsCoM - > too many choices make people unhappy).
Note this patch matches up with the last comments on bugzilla on https://bugs.kde.org/show_bug.cgi?id=298501 it is not just a random proposal. We should be discussing what patches we are going to make on bugzilla, and use reviewboard comments to discuss the code itself. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110061/#review31196 ----------------------------------------------------------- On April 17, 2013, 9:02 a.m., Róbert Szókovács wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110061/ > ----------------------------------------------------------- > > (Updated April 17, 2013, 9:02 a.m.) > > > Review request for Telepathy. > > > Description > ------- > > This patch makes the input field's minimal size to lines high. > > > Diffs > ----- > > lib/chat-text-edit.cpp 20055c9 > > Diff: http://git.reviewboard.kde.org/r/110061/diff/ > > > Testing > ------- > > > Thanks, > > Róbert Szókovács > >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
