Bug 44662

Summary: Find window too large
Product: [Applications] kfind Reporter: arkmch
Component: generalAssignee: Eric Coquelle <coquelle>
Status: RESOLVED FIXED    
Severity: normal CC: alx5000, dvgevers, havaji, kfl, phoenixreads
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Other   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Kfind window with a very long search term.

Description arkmch 2002-07-03 13:59:24 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kfind
Version:           KDE 3.0.1 
Severity:          normal
Installed from:    Compiled From Sources
Compiler:          Not Specified
OS:                Not Specified
OS/Compiler notes: Not Specified

The size of the find dialog is too large for 800x600 resolution. I can't access any of the buttons on the right hand side of it.

(Submitted via bugs.kde.org)
Comment 1 arkmch 2002-07-12 02:26:31 UTC
I recently upgraded KDE to 3.02 and didn't install the Polish i18n package.=
 I=20
noticed that with US English as my KDE language the size of the dialogue is=
=20
OK. The problem returned after I installed the Polish translation and=20
switched my language to Polish.=20

Actually many other dialogues like those in KDE Control Center or Konquero=
r=20
are too big in the Polish version.=20
Comment 2 LIVINE Christin 2003-05-22 22:30:16 UTC
The kfind windows is always too large.

I use Mandrake 9.1, KDE 3.1, with 1024x768 resolution.

The actual kfind windows is about 1000 pixel large, it should be smaller, 400 
pixels large seems enough (with all translation text,...)

Comment 3 LIVINE Christin 2003-05-26 21:53:15 UTC
Add to comment #2,
I use KDE 3.1 with French UI on Mandrake 9.1.
Comment 4 arkmch 2003-06-07 20:35:14 UTC
I've been able to reproduce this bug using the English version of KDE. All I had
to do was to type a long text into any of the drop-down list boxes.
Comment 5 arkmch 2003-06-07 20:38:43 UTC
Created attachment 1743 [details]
Kfind window with a very long search term.
Comment 6 arkmch 2003-08-24 09:42:36 UTC
Please move it from i18n pl category. This bug can be reproduced using the
English version.
Comment 7 Eric Coquelle 2003-10-29 13:36:07 UTC
*** Bug 62087 has been marked as a duplicate of this bug. ***
Comment 8 Eric Coquelle 2003-10-29 13:39:48 UTC
*** Bug 62954 has been marked as a duplicate of this bug. ***
Comment 9 Sebastian Sauer 2004-02-10 15:37:11 UTC
The problem seems to be that a KComboBox gots always the minsize of the longest item... For those familar with german see http://www.mrunix.de/forums/showthread.php?threadid=30870 for a possible solution...
Comment 10 Michael Schuerig 2004-03-10 00:48:02 UTC
The major culprit for this problem is the "Look in:" directory selection combo box. IMHO, this combo box shouldn't even be there in the kfindpart, i.e. the Find File tool available in Konqueror. In this situation, the user has already chosen where they want to find something, thus Find File should simply use that location instead of offering a second place where to choose a directory. If the users wants to search somewhere else, they can easily use Konqueror to navigate there. In this case, it would be nice if the Find File tool would remain visible until explicitly closed.
Comment 11 Stephan Binner 2004-03-29 11:11:12 UTC
*** Bug 77096 has been marked as a duplicate of this bug. ***
Comment 12 Ben Smith 2004-07-09 03:03:27 UTC
Can anyone duplicate this with kdebase-3.2.3 ?  Does this refer to the kfindpart used in Konqueror or the standalone kfind?
Comment 13 Sebastian Sauer 2004-07-09 14:18:36 UTC
Still reproducable with 3.2.3. Just open kfind and try to size it to the minsize. Those minsize differs and could be very high (like sayed on comment #2) cause it depends on:
1) the longest item in "Look in:" KComboxBox and
2) the longest item in "File type:" and
3) the length of translated items like the "Include subfolders" or the "Case sensitive" row.

So, we've some design flaws here cause everything works nice as long as the default english language is used but it gets ugly (user unfriendly) if another language (with longer strings) is used.
First both points are cause of the in comment #9 described problem that the minsize of a KComboBox/QComboBox (and therefore the minsize of the whole kfind-dialog) gots determinated by it's longest item. You arn't able to note that problem as long as you don't have such long items in one of the both combobox's.
The third point is cause the dialog contains areas where e.g. 2 or 3 checkbox's are on one row. If the translated caption is very long, they took a lot of space. This could be fixed IMHO by a one-liner (something like setAlignment(Qt::WordBreak) ?!) to autowrap those checkbox's to the next line if they just got to long.
Comment 14 Nick Shaforostoff 2004-07-11 09:20:26 UTC
still in kde 33 beta
Comment 15 Stephan Binner 2004-12-10 21:41:15 UTC
*** Bug 94850 has been marked as a duplicate of this bug. ***
Comment 16 Bojan 2004-12-11 03:18:47 UTC
Any chance of making it like in windows2000?
http://www.geocities.com/havaji/find/
Comment 17 Martin Koller 2004-12-28 20:00:54 UTC
I commited a partial fix for this bug:
The "Named:", "Look in:" and "File Type:" ComboBoxes can now shrink below their widest entries, and the 3 combo boxes on the first tab "Include subfolders", "case sensitive search" and "Use file index" are now arranged vertically to allow more room for translations.
But there are still issues on the other tabs where you have several widgets with translatable text side by side, so probably this fix alone is not enough.

It would be nice if someone with polish translation can check if it is still a problem.
Comment 18 Stéphane Gourichon 2005-12-29 14:57:24 UTC
Still too large on KDE3.4.3 (Ubuntu 5.10 Breezy Badger, french but nothing specific actually specific to french, 1280x1024).
Default window size is 924x492, nothing to regret here. 
It can't be resized below 856x294 which is still too big. The layout does not justify such a width. Even if for most usages the user will prefer to enlarge it, it should be possible to make it smaller.
Comment 19 Philippe ROUBACH 2006-01-25 09:50:16 UTC
My config
MDV 2006
screen 15", 800*600
French
KDE 3.4.2

since i practice Linux(Mdk 7.x) to today

many kinds of windows in many kde applications do not adjust their size to the size of the screen.

- a good solution is to insert a property of dynamic adjustement in the object "window" or in the object "contents of window" like a dynamic PAO

- an intermediate and faster solution is only dynamic adjustement in the object "windows"
so the windows adjust to the size of screen with horizontal and vertical scroll bar like internet browsers

I think good page setting is high priority to convince people to switch to linux.
People are very susceptible to coating. People judges the quality via appearence.

linux via kde appears a non finished product and people at once
have hesitation
Comment 20 David Faure 2006-05-16 20:15:38 UTC
SVN commit 541602 by dfaure:

Fix 16th most hated bug: "kfind window too large", using code similar to minicli's.
BUG: 44662


 M  +14 -0     kftabdlg.cpp  
 M  +2 -0      kftabdlg.h  


--- branches/KDE/3.5/kdebase/kfind/kftabdlg.cpp #541601:541602
@@ -855,4 +855,18 @@
   conf->writePathEntry(entry, sl);
 }
 
+QSize KfindTabWidget::sizeHint() const
+{
+  // #44662: avoid a huge default size when the comboboxes have very large items
+  // Like in minicli, we changed the combobox size policy so that they can resize down,
+  // and then we simply provide a reasonable size hint for the whole window, depending
+  // on the screen width.
+  QSize sz = QTabWidget::sizeHint();
+  KfindTabWidget* me = const_cast<KfindTabWidget*>( this );
+  const int screenWidth = qApp->desktop()->screenGeometry(me).width();
+  if ( sz.width() > screenWidth / 2 )
+    sz.setWidth( screenWidth / 2 );
+  return sz;
+}
+
 #include "kftabdlg.moc"
--- branches/KDE/3.5/kdebase/kfind/kftabdlg.h #541601:541602
@@ -49,6 +49,8 @@
 
   void setURL( const KURL & url );
 
+  virtual QSize sizeHint() const;
+
 public slots:
   void setFocus();
 
Comment 21 Stefan Borggraefe 2006-06-29 13:35:42 UTC
*** Bug 83199 has been marked as a duplicate of this bug. ***