[patch] minicli sizing
m.koller at surfeu.at
Mon Nov 1 14:09:51 GMT 2004
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.
> 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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel