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

List:       kmail-devel
Subject:    Re: tab order in filter dialog - related to #52299
From:       Ingo =?windows-1252?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2004-04-16 18:37:12
Message-ID: 200404162037.21827 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 16 April 2004 09:05, Andreas Gungl wrote:
> On Friday 16 April 2004 01:00, Ingo Klöcker wrote:
> > On Thursday 15 April 2004 22:39, Andreas Gungl wrote:
> > > Have a look at the attached patches. And look at this:
> > > -------------------------------------------------------
> > > // FIXME  QPushButton * mBtnMore = new QPushButton(
> > > i18n("dummy","Dummy"), this );
> > >
> > >   //------------the list of KMSearchRuleWidget's
> > >   mRuleLister = new KMSearchRuleWidgetLister( this, "swl",
> > > headersOnly, absoluteDates );
> > >   mRuleLister->slotClear();
> > >   mRuleLister->setFocusAnchor( this );
> > > -------------------------------------------------------
> > > Comment in the line with FIXME and replace the this in the last
> > > line with mBtnMore and you already have what might be usable for
> > > the rules section. Unfortunatly I didn't find a way to achive the
> > > same behavior without the dummy button. God knows where the tab
> > > stop is. :-(
> >
> > I've tried the patch with the Dummy button. Here tab order is
> > Dummy -> 1st rule widgets -> More -> Clear -> 2nd rule widgets.
> > I've tested this with the Search in Folders dialog.
> > If I add a third set of rule widgets then I get
> > Dummy -> 1st rule widgets -> More -> Fewer -> Clear -> 2nd rule
> > widgets -> 3rd rule widgets.
>
> This is interesting. Using the dummy button I have correct behavior
> i.e. all rules one after another and the More/Fewer/Clear buttons at
> the end. Even selecting More or Fewer prevents the correct tab order
> of the rules. (I haven't explicitly tested changing the rules so that
> the widget stack raises another widget. I will check it tonight.)
>
> I'm wondering why it doesn't work for you. A difference is, that I
> tested using the filter dialog instead of the search dialog. We
> should also check our Qt versions. Perhaps the behavior changed?

I'm still using Qt 3.2.3 (from qt-copy).

> > The easiest solution is probably the following:
> > Since we anyway don't allow more than a fixed number of rule/action
> > widgets we can simply create the maximal number of widgets in the
> > c'tor of KWidgetLister (before the buttons are created) and then
> > just hide widgets which are not used. Sure, we will waste a small
> > amount of memory, but at least we won't have to spend anymore
> > thoughts on trying to outsmart Qt's tab order handling.
>
> If I can't get it to work, this is the last possible solution. The Qt
> documentation lacks details regarding tab order.
> Somewhere I've read that the tab oder is stored in a (ring) list. The
> example is not reflecting this:
> =====
> Note that since the tab order of the second widget is changed, you
> should order a chain like this:
>         setTabOrder( a, b ); // a to b
>         setTabOrder( b, c ); // a to b to c
>         setTabOrder( c, d ); // a to b to c to d
> not like this:
>         setTabOrder( c, d ); // c to d   WRONG
>         setTabOrder( a, b ); // a to b AND c to d
>         setTabOrder( b, c ); // a to b to c, but not c to d
> =====
>
> If you have a chain like a->b->c->d->e and use setTabOrder(a, c), it
> might give you a->c->b->d->e. This is what my experiments have shown.
> But it's not explicitly stated in the documentation, so I'm not sure
> that this is correct in every case.
> It's even likely that it's not defined, why else do you see another
> behavior with the patch than me?

The docu of setTabOrder also says:
"Moves the second widget around the ring of focus widgets so that 
keyboard focus moves from the first widget to the second widget when 
the Tab key is pressed."

This could be interpreted as "Moves the second widget around the ring of 
focus widgets so that keyboard focus moves from the first widget to the 
second widget and from the second widget to the previous successor of 
the first widget when the Tab key is pressed."
Your experiments seem to support this interpretation. And to make sure I 
just checked the source of QWidget::setTabOrder(). The second widget is 
indeed inserted after the first widget (resp. after all children of the 
first widget in case the first widget has a focus proxy).

So the only problem is that we need an anchor (like the dummy button). 
But since a KWidgetLister without any widgets doesn't make much sense 
we can simply create one widget in the c'tor and then use this widget 
as anchor.

My commit to KMSearchRuleWidget (setting focusProxy to the header field 
combo box) should make KMSearchRuleWidget::adjustTabbing obsolete. Most 
likely this method was causing the problems I've noticed with the tab 
order if the visible widget changes (which is not surprising because 
the tab order was only set for the visible widgets). 

Now 
  QWidget * last = mFocusAnchor;
  QPtrListIterator<QWidget> wIt( mWidgetList );
  for ( wIt.toFirst() ; wIt.current() ; ++wIt ) {
    setTabOrder( last, *wIt );
  }
should do what we want. This can even be added to KWidgetLister.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


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