GNOME.org
 

Re: [Evolution] Feature requests

On 29 Jan 2001 12:15:15 +1030, Mark Phillips wrote:

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.


total # of messages is the only thing more we could show as we don't
have a way to get the other information you suggest. Well, total size
might be doable with a for-loop on the message summaries and just keep
adding the size fields. However this seems rather silly. Total threads
would not be doable at all I don't think until they have actually been
threaded and then we'd have to go through the tree and count them. Ugh.
The number of messages marked as deleted could probably be done
similarly as the unread-message-count but again, this just seems like a
waste of effort as we plan on hiding deleted messages anyway.


    - 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.


Oh the pain, the pain that comes in the form of yet more config options.
You have no idea how painful it is to do more and more config options.
It has a tendency to make code awefully painful. Not to mention the
end-users get so confused as to what all these config options even are!
I am willing to bet that the average user is lucky if he sets more than
3 to 5 config options (other than his identities and mail sources of
course).


    - 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.


The total message counts might be useful, they are the only thing that
I'd even consider.



* 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.


Huh?


    - 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.


We will accept patches as always... ;-)



* 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.


Suggestion: drag the view pane all the way to the bottom so that you see
only the list, and then double click or use the keyboard shortcut to
open a message-view window.



* 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.


You've lost me, what's the difference?


    - 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.


Okay, this is a reasonable reuest and I think I agree.



* 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.


There already is an anvanced search bar that you can spawn from the
Search menu, tho I am aware that this doesn't completely solve your
problem here.


    - 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.


Already fixed.


    - 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.


There is, I use Evolution in this very manner. Folder tree on, shortcut
bar off.



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.


Ugh with the configurable options again! These dummy messages are needed
as parent nodes of a thread in which you don't have the parent message
of the thread. For example, you may have messages B, C, and D that are
all replies (and/or sub-replies) of message A of which you don't have a
copy. How then should these messages be threaded?

For example, say you have the following structure:

A
  B
  |  E
  |  F
  |  |  G
  |  H
  C
  |  D
  |  P
  |  |  J
  |  |  K

What if you don't have message A?


    - 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.


Why not have the subject for each message? This is not mutt, this is not
a console mail client. This is a GUI mail client that displays the
thread relationship via dashed lines and +'s and -'s etc etc.


    - 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.


Oh please, what more do you REALLY need? If you want to see all the
header info why not just use the View->Source menu? I can see Date as
another field that'd be useful but as for the others, no. This also
seems to me that it'd be quite a frustation to create the configure
options for this. Also note my config option nightmare explanation
above.



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.


We will accept patches.



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)) 


This is extremely difficult to do in a GUI editor, however as I've said
before we are willing to accept patches if you feel up to the challenge.


    - 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.


Feel free to show us how easy it'd be to code by sending us a patch :-)


    - 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.


I'm awaiting your patches!



Composer:

* Option to edit message using an alternate editor: 

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


Feel free to bonobize emacs or bonobize the zvt widget :-)
This is actually planned but we haven't had the time and I suspect it'll
be a few more months.



* 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.


I have yet to figure out the best way to stop 'editing drafts' from
creating a new draft, I could delete the message when you go to edit the
draft as it is being placed into the composer, but what if the mailer
crashes? then you've lost the mail. I agree that this is an anooying
thing but don't know the best way to solve it.



* 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 don't know what you mean by a pseudo text editor, you're explanation
above didn't really give me a good enough idea of what you're talking
about, could you `glade` it for me to look at?


    - 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.


Sounds to me like you have lived in console land a bit too long. Why is
a button a bad idea? Why would a label with pre-light be any better? Not
to mention it's harder to code.



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.


erm, you edit and save them in a text editor, so that solves your
problem already. We distribute emacs and Windows something-er-other key
bindings by default already.


    - 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.



Jeff
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]