NOV
16
2007

KDE4 "active" colors, and resizing a dialog

I need help on some things which ought to be trivial. I'm working on the KStars Observing List tool, depicted here:


Ain't it pretty? The first trouble arises if the TableView listing the objects loses input focus. Then it looks like this:

So it's just about impossible to see what objects are selected, and the only way to restore the active colors without altering the selection or column ordering, is to click on the vertical scrollbar (if there is one!). If these "disabled" colors appeared when the dialog lost focus, that would maybe be acceptable. However, as it is now, if any other widget in the dialog gets focus, I get these "disabled" colors in the TableView. This is obviously a usability nightmare; how do I make the "active" colors persist as long as the dialog has focus (or heck, keep the active colors no matter what...that would be better than the current situation)? Any advice would be most appreciated.

The second thing I need help with is resizing the dialog. The button in the upper right is supposed to present a more compact version of the tool, in case the user would like to keep it open without it taking up too much of the screen. This button hides all columns except the first, and shrinks the Action buttons so they only contain one letter each. This all works, but it simply refuses to resize the dialog itself to match the contents:


What I want to happen is the following (which I achieved by manually resizing the Dialog):


Does anyone know how to make it do this resizing automatically? I've tried resize(), adjustSize(), everything I could think of.

Thanks!

Comments

I noticed that grey selection thing as well, but when i updated a few days ago, it was fixed. So I think you just need to update your kdelibs.

Also you should set tableview->horizontalHeader()->stretchLastSection(true);

When you change to the simple view, you could set the size of the widget to the sizehint of the first column, to do the autoresize thing.


By John Tapsell at Fri, 11/16/2007 - 08:05

By adding:

ui->TableView->horizontalHeader()->setResizeMode( QHeaderView::ResizeToContents );

to the ctor, and:

resize( ui->TableView->columnWidth(0) + left + right, height() );

to my slotToggleSize() slot, I am able to get the window to shrink, but only by about 20 or 30 pixels! I couldn't understand why, but then I noticed that it shrinks to a width that is just wide enough to accommodate the row of five "action buttons" at their full size! It's as if the layout is not yet aware of the shrinking of these buttons at the time it's resizing the window, so it doesn't allow the window to get any smaller. I tried adding adjustSize() to each of the buttons, and I tried delaying the resize by calling processEvents() first, nothing seems to work.

This is pretty frustrating, I would think that adjusting a widget's size to fit a new layout would be pretty trivial!

Any other advice?

--
KStars: A desktop planetarium for KDE


By Jason Harris at Fri, 11/16/2007 - 14:46

Hiding the text of the buttons is silly, who on earth (aside kstars developers) would be able to guess their meaning??? You should rather make the resize the listview to take up the full width (there is a property to do that iirc).


By sredna at Fri, 11/16/2007 - 18:44

> Hiding the text of the buttons is silly, who on earth (aside kstars developers) would be able to guess their meaning???

(a) Tooltips

(b) It's not the default state of the window, it's a discoverable miniaturization that interested users who have already become familiar with the action buttons may use, if they want to.

(c) I may add icons to these buttons, and only show the icons in the small state, and show icons+text in the default state.

--
KStars: A desktop planetarium for KDE


By Jason Harris at Fri, 11/16/2007 - 21:32

> I noticed that grey selection thing as well, but when i updated a few days ago

Still happening here with a fresh kdelibs...

--
KStars: A desktop planetarium for KDE


By Jason Harris at Fri, 11/16/2007 - 14:47

Hi!

The disabled-looking color is actually a "feature" of kdelibs. Lots of developers are unhappy about it. See http://bugs.kde.org/show_bug.cgi?id=152128, which is the bug I filed about that. Please leave your comments there and vote for it.


By tmcguire at Fri, 11/16/2007 - 13:26

Yes this *is* a feature. Just the current colorscheme is very much broken... ;)


By sredna at Fri, 11/16/2007 - 18:39