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

List:       kmail-devel
Subject:    Re: [PATCH] attachment column
From:       Don Sanders <sanders () kde ! org>
Date:       2004-02-24 3:07:19
Message-ID: 200402241307.19182.sanders () kde ! org
[Download RAW message or body]

On Monday 23 February 2004 18:26, Carsten Burghardt wrote:
> Till Adam sagte:
> > On Sunday 22 February 2004 23:22, Carsten Burghardt wrote:
> >> What is more intuitive? I don't really know.
> >> I fear that we'll end up with too many icons in our
> >> status-column. If you
> >> have an encrypted message with attachment that you replied to
> >> you'll have 4
> >> icons. Is that still concise?
> >
> > Well, let's optimize for the common case. I'm assuming that the
> > majority of
> > mails do not have attachments and most have only one status. Two
> > at the maximum. For those "normal" mails the KMail way wastes
> > less space because it
> > doesn't need an extra column. For the case of an important,
> > replied, forwarded, signed, encrypted mail with attachments it
> > sucks. But that is not
> > the common case, I think. And having columns for each of those
> > would not make
> > things any prettier for that particular mail, I imagine.
>
> You're probably right. I already created a patch that displays the
> attachment icon along with the status icons and it's ok.

Great I'll look forward to that. I'm not a big fan of new header 
columns either. (But personally I would hesitate to object to the 
original patch because of this preference).

> Concerning the way it's saved in the index: if we want to add more
> states in the future it's probably better to move all boolean
> values that are not switchable to a dedicated map.

This idea of 'not switchable' doesn't make sense to me. If #17513 is 
implemented then the attachments state will be modifiable. Actually I 
guess, it and the encryption/signing states can also be modified by 
moving a message into the drafts and editing it. (Though you could 
consider this as deleting the original and making a new message).

I consider all states to be switchable, and don't see the rational in 
distinguishing between switchable and non-switchable states.

It would be nice to be able to handle an unbounded number of states in 
the index file. But that could be done by having using a single 
modifier bit say PROPERTY_MAP_SET, that relates to property 
map/list/string value.

Personally I think that's the logical way of handling an unbounded 
number of states.

Don.
_______________________________________________
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]