[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KIconDialog++
From:       Sébastien_Laoût <slaout () linux62 ! org>
Date:       2006-05-31 20:22:44
Message-ID: 200605312222.45345.slaout () linux62 ! org
[Download RAW message or body]

Le Mardi 30 Mai 2006 02:28, Luke Sandell a écrit :
> Hello all. You may remember some months ago when I posted about a new icon
> dialog I was working on. I finally got around to finishing the code and
> posting it. It is at
> http://www.kde-look.org/content/show.php?content=35528. The source code is
> there and buildable. If people like it I can work on integrating it into
> KDE 3.5.x and eventually 4.

I've integrated it into BasKet Note Pads, as your dialog is an huge 
improvement and that application need that type of dialog a lot.

It also gave me the occasion to test the dialog.
Wahoo: impressive!
It should replace KIconDialog for KDE 4.

Some comments:

- My KDE is configured in "Single-click" mode.
  When I click an icon in your dialog, the icon is directly returned.
  In the old version, the icon was selected and I had to double-click it to
  return it.
  This double-click behaviour is the one also used in File/Open dialog.
  Idem with the dialog to select a directory...
  I think we should have consistency with both dialogs.
  Someone to comment on that usability point?

- Even if it's a detail, can you center vertically the progressbar.
  The filter textbox is vertically centered with the Browse pushbutton but
  the progressbar is bottom-aligned with the pushbutton.

- When right-clicking the icon view, the selection is canceled: no more icon
  is selected, so how to know what icon will be choosen when clicking Ok?!
  This is a Qt or KDE bug (or intentional behaviour, don't know).
  I solved a similar problem with the class I've attached to this email.
  Use it instead of KIconView.

- There are two related problems with filtering:
  The first one is when adding a filter term and then switching to another
  category, the filterbar is not reseted but the icon view show every icons.

  Two solutions:
  - When changing category, reset the filterbar to show all icons of that
    category.
  - When changing category, keep the filter term and show only the icons that
    match that term.

  It will depend on use cases.
  If someone don't find a term, he can go to another category to see if the
  icon she search is in that category, in this case the filter should rest.
  But if she does not know in wich category an icon is, it's better to presume
  he first go to the "All" category before filtering, so don't keep filter
  between categories.
  But (yes, another :-) ), someone can search an icon, see no result and think
  "oh yes I forgotten to first go to the category Foo". In this case, keep
  filter :-)
  What do you all think is better?
  In other applications like KMail, filter is per-folder, so to keep
  consistency, filter should be per-category.

- The second bug is when using KIconButton: filter, click an icon, then
  re-click the KIconButton. The filter is still there!
  You should reset the filter when showing the window again.
  And the same bug is there too: all icons are shown whether they match the
  filter or not.

- When using KIconButton, the dialog is not modal! we still can use the
  calling parent window when the icon dialog is displayed, and the window has
  its own entry in Alt+Tab.
  Hum... In fact I have several KIconButton in my app, and with another
  KIconButton, this time the dialog is modal, but not entirely :-/
  I still can click buttons and other things of the parent window, but I can't
  type anything on the keyboard to the parent window since the KIconDialog is
  the focused window (no distinct Alt+Tab entry, no way to focus the parent
  window, while the mouse events are still passed to the parent window).
  Very strange.
  Ah... More information: the first time KIconButton show a KIconDialog, only
  the mouse events are passed to the parent window and when clicking a second
  time on the KIconButton it seams to re-use the previous window and this time
  the window have its own Alt+Tab entry (but not taskbar entry) and is
  focusable.

- Is dropping of file images working (to simulate a Browse click and file
  choose)? Does not seam to work here.
  Tough when drag-hovering the icon view, it tell it accepts drops.
  But when drag-hovering an icon in that icon view, it tells it do not accept
  drops. Clearly a bug: we want to drop an icon to the view (or possibly even
  to the window itself!), not to "an empty space of the icon view").
  Would be cool to be able to drop an image file anywhere in the window.

- Not a usability remark, but when editing kicondialogui.ui, kicondialogui.cpp
  is regenerated and that file includes "kicondialogui.moc" both on top and on
  bottom! This lead in a compile error.
  I edited kicondialogui.ui with KWrite and removed « <includes><include
  location="local" impldecl="in implementation">kicondialogui.moc</include>
  </includes> ».
  Not sure it's the right and proper way to do?!

Arf, sorry for the very long mail ;-)
I written the bugs and issues as I tested the dialog.
You've done a very good job and the bugs are very small (but they all adds up 
and are annoying) so they will be quickly solved.
If you want to release a 0.4 version, I'm proposing myself to be a 
beta-tester, as I really want to use your work in my application, but by now 
I'm afraid I will not do it (as I wanted to do at the begin of this email).

["SingleSelectionKIconView.txt" (text/plain)]

I leave you include the include files that need to be included :-)
This class also prevent dragging items, but you certainly don't want that.



> > > > > > > > > > > > > > > > > THE INCLUSION FILE :::::::::::::::::


/** The class KIconView allow to drag items. We don't want to, so we disable it.
  * This class also unselect the selected item when the user right click an empty \
                space. We don't want to, so we reselect it if that happens.
  * @author Sébastien Laoût
  */
class SingleSelectionKIconView : public KIconView
{
  Q_OBJECT
  public:
	SingleSelectionKIconView(QWidget *parent = 0, const char *name = 0, WFlags f = 0);
	QDragObject* dragObject();
	QIconViewItem* selectedItem() { return m_lastSelected; }
  private slots:
	void slotSelectionChanged(QIconViewItem *item);
	void slotSelectionChanged();
  private:
	QIconViewItem *m_lastSelected;
};





> > > > > > > > > > > > > > > > > THE CODE FILE :::::::::::::::::



/** class SingleSelectionKIconView: */

SingleSelectionKIconView::SingleSelectionKIconView(QWidget *parent, const char *name, \
WFlags f)  : KIconView(parent, name, f), m_lastSelected(0)
{
	connect( this, SIGNAL(selectionChanged(QIconViewItem*)), this, \
SLOT(slotSelectionChanged(QIconViewItem*)) );  connect( this, \
SIGNAL(selectionChanged()),               this, SLOT(slotSelectionChanged())          \
); }

QDragObject* SingleSelectionKIconView::dragObject()
{
	return 0;
}

void SingleSelectionKIconView::slotSelectionChanged(QIconViewItem *item)
{
	if (item)
		m_lastSelected = item;
}

void SingleSelectionKIconView::slotSelectionChanged()
{
	if (m_lastSelected && !m_lastSelected->isSelected())
		m_lastSelected->setSelected(true);
}



_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]