KDE/kdevplatform/plugins/quickopen

[Andreas Pakulat]

On 19.03.09 16:14:26, Aleix Pol wrote:
> On Thu, Mar 19, 2009 at 2:39 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 19.03.09 14:20:52, David Nolden wrote:
> > > Am Donnerstag 19 März 2009 14:00:03 schrieb Andreas Pakulat:
> > > > Can someone with some insight into the expandingtree widget please fix
> > that
> > > > one up so it provides a proper sizeHint? This change is nothing but a
> > > > workaround for a bug in expandingtree, which simply has a far too small
> > > > sizehint.
> > > It is nothing more than a QTreeView. And QTreeViews are not good at
> > providing
> > > size-hints if they have thousands of items in them(At least unfeasably
> > > inefficient). Also we don't want the quickopen widget to be as wide as
> > the
> > > widest entry, since that will be _very_ wide. So we should just pick a
> > > reasonable default.
> >
> > Then maybe it should override sizeHint and provide a meaningful value? As
> > it is this widget doesn't comply with Qt standards (meaning every widget
> > should provide a reasonable sizeHint).
> >
> > Also why is there this huge whitespace area in the quickopen list on the
> > left of the entries? The first column should be a lot smaller in the
> > quickopen list, then we wouldn't even need a reasonable default size for
> > the dialog or the tree.
> >
> > > Actually it did have a very reasonable default size, but maybe that got
> > lost
> > > during the conversion to KDialog(Which I wasn't a fan of, for exactly
> > such
> > > reasons)
> >
> > You'd have the same problem if you'd use the form that we have now, apply
> > it onto a QWidget and put it into a QDialog with a layout. The reason it
> > worked with QDialog is that when you resize it inside designer a resize()
> > call is added to the generated code. So every time someone would resize the
> > dialog in designer and save that we'd have a different size on next start,
> > how good is that?
> >
> > Oh and btw, 800x400 is _not_ a reasonable size, it spans the whole screen
> > on small laptops or monitors. Something like 550x350 seems a lot more
> > reasonable.
> 
> <sarcasm>yeah, too bad i won't be able to use kdevelop on my phone</sarcasm>

I did _not_ talk about phone's.
 
> I tend to think more like david, 700x400 would be better.

Hmm, for me the dialog would be perfectly fine with 600x350, especially if
the treeview/model wouldn't waste so much whitespace. 

> Another way to do that would have been to do something like
> 
> class MyClass : public KDialog
> {
>    public: QSize sizeHint() const { return QSize(700,400); }
> };
> 
> but how would have benefited us?
> 
> And does that method imply that this ::setInitialSize() method is just
> wrong? If it is there it has to be for something...

Both are the exact same thing, however my point was that if the containing
widgets provide proper sizeHint's themselves than we don't need either of
the two and the dialog will have a proper sizehint.

As it seems its technically not possible to make QTreeView provide a
reasonable sizehint by itself. So we'll have to put a hardcoded value
somewhere. Still I think it would be nicer if we can limit that hardcoding
to the innermost widget possible. So in case sizeHints for other widgets in
there (can that change with theme or font? haven't checked) change.

Andreas

-- 
Courage is your greatest present need.