Version: (using KDE Devel) Installed from: Compiled sources OS: Linux I am used to write long commit logs on the catalog manager. The next time I open the catalog manager, the commit window is 5 times larger then my screen. it seems it gets the size of the largest string sent, and the string is calculated from the sent message (all in one line).
The attached patch is for kdesdk/kbabel/catalogmanager It tries to make a temporary fix to the symptom that the combo box in the SVN/ CVS commit dialog becomes too wide if there is at least a long old log in the log history and therefore makes the dialog useless (as the buttons are near the right, out of screen). (Bug #115296) The patch is only for SVN for now. It has a few drawback. It cuts the strings at 80 characters and does not care about duplicates. I suppose that it could be committed so, until someone of us takes the time to make a better fix (for example cut at a certain display wide and not at a character number, correct handling of short duplicates that are not duplicate at long form.) (A fix for CVS would be similar but I would like some feedback before porting to CVS.) Have a nice day! Created an attachment (id=13214) combotoowide.diff
---------- Forwarded Message ---------- Subject: Re: [Kbabel] [PATCH] Temporary fix for too wide combo box in SVN/CVS commit (#115296) Date: Sunday 30 October 2005 11:59 From: Nicolas Goutte <nicolasg@snafu.de> To: kbabel@kde.org On Saturday 29 October 2005 23:41, Nicolas Goutte wrote: > The attached patch is for kdesdk/kbabel/catalogmanager I think that I have made my own fedback. :-) I have remembered that there is the class KStringHandler (in kdecore), which has nice functions that I could use. Also for avoid that the "short duplicate" problem, I could use the index of the combobox instead of the text of the entry. (Also I must check if KComboBox should not be used instead of QComboBox, however I do not remember the advantages for a non-editable combo box.) > It tries to make a temporary fix to the symptom that the combo box in the > SVN/ CVS commit dialog becomes too wide if there is at least a long old log > in the log history and therefore makes the dialog useless (as the buttons > are near the right, out of screen). (Bug #115296) > > The patch is only for SVN for now. It has a few drawback. It cuts the > strings at 80 characters and does not care about duplicates. > > I suppose that it could be committed so, until someone of us takes the time > to make a better fix (for example cut at a certain display wide and not at > a character number, correct handling of short duplicates that are not > duplicate at long form.) > > (A fix for CVS would be similar but I would like some feedback before > porting to CVS.) > > Have a nice day! _______________________________________________ kbabel mailing list kbabel@kde.org https://mail.kde.org/mailman/listinfo/kbabel -------------------------------------------------------
The attached patch is for kdesdk/kbabel/catalogmanager This patch is a better version for fixing the too-wide combo box in the SVN commit (again CVS commit is not done et, ut is going to be very similar code). This new patch still limits the number of characters but by using KStringHandlerr::csqueeze now (TODO: try to get GUI info about width of combo box and font info, as QWidget returns such info). The old messages are now kept in two QStringList objects: one for the long messages, the other for the squeezed ones. The "activation" of the QComboBox is now done by numbers, as it is non-editable. As for replacing the combo box by a KComboBox, it is superfluous as KComboBox extensions compared to QComboBox are only for editable combo boxes. Have a nice day! Created an attachment (id=13221) combotoowide2.diff
SVN commit 477660 by goutte: Avoid the old commit log combo box to become too wide (Temporary fix) CCBUG:115296 M +35 -11 libcvs/cvsdialog.cpp M +7 -2 libcvs/cvsdialog.h M +35 -11 libsvn/svndialog.cpp M +6 -1 libsvn/svndialog.h
KBabel is no longer maintained, please use the KDE 4 translator's tool called "Lokalize" instead. For more information, please visit http://userbase.kde.org/Lokalize If this is a bug which is also present in Lokalize, please add a comment so that I can reassign the bug the the Lokalize authors.