[patch] minicli sizing

[Martin Koller]

On Monday 01 November 2004 13:56, Dawit A. wrote:

> Nope. This has been hashed over a million times before. Please search
> the mailing lists for those discussions.

Hm ..., did not find anything.

> With your change, the size of the 
> combobox will grow infinitely with the size of the URL which is worse.

Can you tell me details, please? When will it grow (by doing what) ?
I can't see why it should.

> BTW, 
> why could you not edit a long URL with the current fixed size ?

It's not the question of "if", it's the question of "how userfriendly" it was.

Also, it seems to me that the "fixed size" approach is not done "by design", 
but instead to work around a different problem (which you described above).
I was trying to solve this in a clean way (probably I failed, but then please 
give me a test case where it does not work and I'll try to improve it).


P.S.: my use case:
I have always the problem that I receive emails with long URLs from broken 
mailers which break the URL in several lines. So I copy/paste this into 
minicli and try to find the blanks and then remove them.
On being able to resize minicli, I have a much better overview and don't have 
to scroll inside the combo.
Also, a non-resizeable dialog always reminds me on the borked MS 
implementations when one could not resize e.g. a fileselector dialog (where 
it also was possible to select a file, but not in a friendly way).

-- 
Best regards/Schöne Grüße

Martin    ()  ascii ribbon campaign - against html mail 
          /\                        - against microsoft attachments

       Some operating systems are called 'user friendly',
             Linux however is 'expert friendly'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041101/16b0e31c/attachment.sig>