[Evolution] Feature requests

[Mark Phillips <mark infoeng flinders edu au>]

I hope I don't appear greedy, but I've had a lot of ideas about how
Evolution could be improved.  So I thought I'd compile a list, using
categories previously used by Duncan Mak.  Keep up the good work!


Mail

General:

* Folder information: there is lots of useful information about a folder
which could be displayed. 

    - In addition to the number of unread messages, one could also
    display total number of messages, total number of threads, number of
    messages waiting to be expunged, total size of messages in KBytes
    and probably much more.
    - This information should be displayed on the folder information bar
    at the top.  However, one should be able to customize this display
    so that only information you want displayed, is displayed.
    - This information should also be able to be displayed in the
    folders panel.  Currently only the number of unread messages is
    displayed.  Extra information like the total number of messages
    should also be displayed.  Again, precisely what is and isn't
    displayed should be configurable.

* Distinguish "new un-read" from "old un-read": 

    - Currently messages are classified simply as read or un-read (and
    unhighlighted or highlighted accordingly).  It is useful (and a
    number of other mailers do this) to make a further distinction:
    between messages which remain un-read, but whose folder has been
    opened, and messages newly arrived whose folder hasn't even been
    opened since arrival.
    - These two types of un-read messages should be distinguished and
    highlighted differently.  So too should a folder be highlighted
    differently if it contains "new un-read" messages.

* Toggling message-list/message-view display: 

    - Currently there is a split screen message-list/message-view
    display, the relative sizes of which, may be adjusted with a mouse.
    It would be convenient if there were options to change to full
    screen message-list and full screen message-view.  With suitable
    key-bindings as well, one could quickly change from one view to the
    other (similar to what is available under mutt).  Having full screen
    options means one can have more space for reading either the list,
    or the message itself, depending on what one is focusing on at that
    time.  The other advantage of the full screen message-list, is that,
    because messages aren't actually being viewed, one may work with the
    message list without causing messages to be marked as "read" when
    they really haven't been.

* Get mail information: 

    - When the "Get Mail" button is pressed, a window comes up with a
    "running commentary" displayed telling one how the mail
    incorporation process is going.  At the moment it displays the
    message number being incorporated and the percentage of emails so
    far incorporated.  My suggestion is that in addition, the total
    number of messages destined for incorporation also be displayed.
    - This "running commentary" window requires an OK button to be
    pressed after it is finished.  There should be a configurable option
    making this window automatically go away on completion without
    having to press OK.

* Screen estate savings: 

    - At the moment it is difficult to make full use of the full height
    of the screen.  A number of things could be done to improve this.
    - Having a pop-up search window as an alternative to a permanent
    fixture has already been suggested.
    - It is already possible to move the icon bar from the top to the
    side - making it vertical.  Unfortunately the vertical display isn't
    very asthetic with the text jutting out next to it and the icons all
    jumbled.  The text should appear below the icons and the whole thing
    made neater.
    - There is a bar at the top, currently with nothing but the Folder
    name in it.  Perhaps there is a better place for it?
    - On the horizontal screen estate front --- the evolution shortcuts
    is normally unnecessary if you have the Folders window permanently
    enabled as I do.  There should be the option to hide the shortcuts
    window.

Message List:

* Thread display: 

    - Evolution currently seems to often use a "dummy" message at the
    start of a thread.  I find these dummy messages very annoying and
    unnecessary.  Why are they used?  If some people like them (for
    whatever reason), perhaps their use could be made a configurable
    option.
    - Instead of the subject line of a particular thread being displayed
    for every message in that thread, why not simply display it once at
    the top of the thread and leave the other subject lines black,
    except for the arrows indicating the relationships between messages
    within that thread.  There would be a few exceptions to this rule
    --- if the subject line changes mid thread, the new subject line
    would be displayed; if a top portion of a thread is not in the
    current field of view of the window, then the top most message of
    the thread which is displayed, should display the full subject line.
    What I am suggesting is thread display similar to that found in
    mutt.  Thread display is one thing I think Mutt does very well.  The
    advantage in not always printing the subject line within a thread is
    that the window doesn't look unnecessarily cluttered, and different
    threads (and the relationships within) are more easily seen.
    - If some people like thread display in which every message includes
    the subject line, then perhaps it could be a configurable option.


Message View:

* Header information: 

    - It seems that now we have the choice of either having very
    abbreviated header information, or displaying all of it.  I'm glad
    we now have the option of seeing everything!  A further improvement
    would be to allow the abbreviated header format to be configurable.
    That is, instead of only displaying From, To, Cc, and Subject, other
    fields could optionally be added to this display.

Mail Filtering:

* More advanced filter rule combination:  See VFolders

* More advanced filter rule editing: 

    - At the moment you can only insert and delete rules at the end of
    the list.  This should be able to occur anywhere.
    - You should be able to rearrange the rules.
    - There should be a "comment" field so you can, for example, specify
    who a certain email address that you're filtering on, belongs to.

VFolder:

* More advanced vfolder filter rule combination: 

    - It would be helpful to be able to combinations of "and" and "or"
    filtering, ie to have more advanced filtering constructs.  Let me
    give one real example of where I would use it.  I want to create a
    virtual folder for my friend Bill, so I search for emails with
    "sender contains bill whatever".  However, I also want this virtual
    folder to contain messages I write to Bill, so I "or" this condition
    with "recipients contains bill whatever".  However, this means the
    folder also contains messages to Bill from other people (where I am
    a recipient as well).  So what I would like to be able to do is: 
        (sender contains bill whatever) or ((recipients contains
        bill whatever) and (sender contains me whatever)) 
    - It shouldn't be too hard to construct a visual user interface that
    allows for such constructions.  I would envisage the layout being
    something like this: 
            condition A     or
               (    condition B     and
                    condition C     and
                not condition D        )    or
        not condition E    or
        not    (    condition F    and
                not    (    condition G     or
                            condition H        ))
    This would be a bit of extra work to code, but it should be doable
    and it would certainly improve functionality and flexibility quite a
    bit.
    - Perhaps it would be best to keep the current list base filter rule
    configuring and have this as a special advanced option.
    - In the "Composer" section below I suggest the use of a "pseudo
    text editor" for entering email fields.  I say "pseudo" because I
    envisage it as a cross between a text editor and a
    button/field/pull-down editing scenario.  The big advantage of text
    editing is that there is lots of flexibility and power.  The
    disadvantage is that it is often not that neat, doesn't tell you
    what your options are and in general doesn't allow for a lot of
    program interaction to help you get things correct.  But it should
    be possible to devise a "text" editor that incorporates many of the
    button/field/pull-down features, as well as doing a lot of automatic
    formatting to neaten things up.  Basically the editor would also
    have to be an interpreter, adhering to a certain syntax which it
    would have to understand to some extent.  It would recognise certain
    key words as "buttonable" and certain text elements as "pull down
    fields" which it would highlight differently and allow you to pull
    them down using the right mouse button.  Hopefully you get the
    picture.  This kind of editor would not only be useful for
    specifying email fields, it would also be the right kind of thing
    for constructing filtering conditions.  I realize that making this
    kind of editor would be quite a bit of work, but it would be a
    fantastic way of doing things.  Hopefully you could add this as a
    long term project.

Composer:

* Option to edit message using an alternate editor: 

    - There are times when I would like to use emacs to compose my
    message.

* Option to use "plain text" editing: 

    - The current html editor is very nice in some ways, but there are
    times when one wishes to do a simple ascii text reply and the
    different fonts and things are just a nuciance.  The included text
    of the message being replied to is in a different font, which can be
    a pain.  Ascii art doesn't work because of the proportional font.
    Diagrams and tables etc can be difficult, again because of the
    proportional font.  There should be an option for plain text editing
    using a fixed-width font.

* Paragraph formatting: 

    - It seems that currently paragraph formatting is done when the
    message is sent.  This can be a pain because it means composing is
    not WISIWYG.  It would be nice if you could configure a right
    margin, so that words would automatically wrap, using a "hard
    return" upon reaching that margin.  Of course, you should be able to
    delete a "hard return" so that you can send emails with long lines.
    - The other important option is to have a command to reformat a
    paragraph.  Ie, the Meta-q command of emacs.  I find this
    tremendously useful in composing emails.  It means I can easily
    reformat paragraphs that I write.  But moreover, it also allows me
    to reformat ">"-quoted (etc) text properly as well.  This is very
    useful because sometimes you are replying to a messy email and
    reformatting their paragraphs makes things more tidy.  Sometimes
    also you just want to quote a small section of their reply, and
    reformatting allows you to neaten the bit you select. 

* Slow I/O with long lines: 

    - When typing in a line, as it gets longer, I/O response gets slower
    and slower.  This needs speeding up if possible.

* Save draft option improvements: 

    - The save draft menu item should not automatically kill the compose
    message.
    - The save draft should not create a new draft message every time
    --- a single draft message should be worked with until the final
    version is finished and sent.

* The email fields section of the composer should be in a more editable
form: 

    - Why not have the fields specified using a pseudo text editor?
    This would allow new fields to be easily specified --- you just type
    the new fields in.  It would also allow easier viewing of large
    fields, eg if you had a list of 20 people in the Cc field, it could
    format the addresses in a column.
    - I say "pseudo" because you would want a means of adding in the
    advantages of the current setup.  Instead of having To: as a button,
    you would have it as text, but the editor would recognise the field
    and highlight it or underline it or something, meaning you could
    click on it.  You could use another form of highlighting which means
    if you select this with the right mouse button it pops up a list of
    possible options.

Keybindings:

* Key-binding "themes": 

    - It has already been proposed that key-bindings be customizable,
    which is a very sensible suggestion.  However I would go one step
    further and propose that key bindings be saveable and loadable.
    That way, if someone works out a good set of bindings, it is easy
    for them to share this with others.  Probably a few of these will
    become popular and so a few "themes" could be distributed with
    Evolution.  That way, users would have the choice of a few good, but
    different, ways of doing things.
    - Perhaps the "theme" idea could be extended beyond just
    key-bindings?  I'm not sure.  Indeed, perhaps "theme" is not the
    right word, but you get the idea.
    - There is a question of what format should be used for key-binding,
    not to mention other forms of configuration.  There are some big
    advantages with having ascii text configuration files: 
        - they can be manually viewed and edited with a simple text
        editor
        - you can often understand them by just viewing them, especially
        when combined with well placed comments.
        - they can be easily shared
        - it is easy to mix and match, ie if someone else has a
        configuration file, you can easily pinch a little bit of it that
        you like, and put it in yours --- graphical configuration
        interfaces don't easily allow this. 
    The best strategy is to store the configuration file as easy to
    understand text, complete with comments, but to have a graphical
    "configurator" that allows people to configure things interactively
    if they prefer.

-- 
_/~~~~~~~~\___/~~~~~~\____________________________________________________
____/~~\_____/~~\__/~~\__________________________Mark_Phillips____________
____/~~\_____/~~\________________________________mark ist flinders edu au_
____/~~\HE___/~~\__/~~\APTAIN_____________________________________________
____/~~\______/~~~~~~\____________________________________________________
__________________________________________________________________________
        "They told me I was gullible ... and I believed them!"