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

List:       kmail-devel
Subject:    Re: Fwd: KMail
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       2000-03-12 23:55:36
[Download RAW message or body]

On Mon, 13 Mar 2000, Reginald Stadlbauer wrote:

> > On Sun, 12 Mar 2000, Don Sanders wrote:
> >On Sun, 05 Mar 2000, Don Sanders wrote:
> >> From: Reginald Stadlbauer <reggie@troll.no>
> >>
> >> > Also it seems that you react on currentChanged() in the header
> >> > listview to display a message. IMO if currentChanged() is called but
> >> > the new current item is not selected, the message of the new current
> >> > item should _not_ be shown, but rather stay with the old shown message
> >> > or show no message. Well, I'm not really sure about that but it seems
> >> > wrong to me to show a message which is not selected.
> >>
> >> Good point, I hadn't thought of that. I think Andreas Gungl pointed that
> >> out too.
> >
> >Ok how do I do this? I figured if I used Extended selection mode and
> >connected the selectionChanged signal this would be easy, but the
> >selectionChanged signal is never emitted when in Extended mode. Next I
> > tried connecting the currentChanged signal (staying with Multi selection)
> > and using something like:
> >
> >// Connected to currentChanged signal
> >void KMHeaders::highlightMessage(QListViewItem* lvi)
> >{
> >  if (!lvi)
> >    return;
> >
> >  if (lvi->isSelected()) // (Really I need to know if the selection has
> >                                 // changed, so this isn't quite right)
> >    // Update the message shown in the reader window
> >}
> >
> >But lvi->isSelected is always false. (I mean when clicking on an item or
> > when pressing the space bar after using ctrl-arrows to change the current
> > item) I guess items are selected after the currentChanged signal is
> > emitted.
> >
> >Does that make sense? Using extended seleciton I don't see an easy way to
> >only update the message shown in the readerwindow when the selection is
> >changed.
> >
> >(Note I did getting this working to my satisfacation by using my custom
> >selection behaviour implemented in kmheaders.cpp and checked this in to
> > cvs).
>
> Well, I don't know what you did. Attached (lv.tgz) is the listviews example
> which does in the message view what I'd expect from a mail-client and what
> you wanted. It displays the message of the current item, if this is
> selected.
>
> Note: I'm really not sure about how the Extended Selection mode works in
> the Qt version you use. In the most recent one I have here it works fine. I
> think if you use 2.1 Beta2 it works not correctly, as I changed the
> Extended selection mode after that, I think. But I'm not sure, maybe I
> changed it before Beta2. Anyway, qlv.tgz contains the most recent
> qlistview.cpp and qlistview.h. If you use them, it should work fine.
>
> BTW: I don't cc to kmail@ as I want to send the big attachments there.

I think I'm using 2.1 Beta2. The qlistview.cpp you sent me is signficantly 
different from the one I have installed.

I've had a quick look at the listview.cpp you sent me I guess I'll try 
something in like that in the message view code kmheaders.cpp in a few days 
or so. It could simpify the code quite a bit.

I'm still going to use some customized navigation/selection code for the 
folder view (kmfoldertree.cpp) as I want Extended like behaviour except only 
one item can be selected at a time, (so I will need some extra code to 
enforce this condition I think).

I should point out that at the moment the html widget is messed up and once 
it gets the focus you can't tab/shift-tab out if it :-( This is a new bug it 
was working a few days ago, maybe it is already fixed in cvs.

I'm not too keen on having custom navigation/selection behaviour like you 
suggested when the html view has focus. Really this has exactly the same 
problems as implementing custom navigation/selection behaviour for the 
qlistview based views. (Think about it). It means there will be problems if 
the html widget ever gets good keyboard support (for navigation/selecting 
links and text) then my custom behaviour will probably conflict with the html 
widget keyboard handling.

Instead I'm thinking about having a fourth invisible widget, called "no 
widget", and when "no widget" is active then the following keyboard 
accelerators will be supported:

Cursor Right, "N" next message
Cursor Left, "P" previous message
"+", next unread message
"-", previous unread message
CNTRL-Up, change current folder to the previous folder (but do not select it!)
CNTRL-Down, change current folder to the next folder (but do not select it!)
Space select the current folder (deselects previous folder).
Up,Down,Next,Prev, scroll html widget (message view) appropriately
"r", reply
"a", reply to all
"f", forward
etc..

You can use tab/shift-tab to iterate through the views (folders, headers, 
messages, "no widget") changing focus.

BFN,
Don.

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