Re: [Evolution] Feature requests

Dear Jeff,

Thanks for your recent reply.  I agree with most of what you said!

I completely agree with you about the danger of "bloating" before the
software is stable.  I agree that your highest priority at the moment
is to make sure existing features are stable.  It is much more
important that release 1.0 is stable, that that it have many more
features added.

When you say that many of my feature suggestions should wait till
after 1.0 I agree entirely!  A few of them could go in before 1.0 but
for the rest, most definately wait till later.  Perhaps I should have
prefaced my suggestions with the comment that many of them had the
longer term view in mind.  I suppose I thought that if I mention these
ideas now, it gives you guys longer to think about possible future

Yes I do agree that it's not worth adding options that hardly anyone
will use.  Well actually, let me qualify this statement.  The way I
would like to look at it is that one should consider the following
factors when considering whether it's worth adding a certain feature:

1. How many people would use it?

2. How powerful an option is it?  Ie, would it add significant value
to the software for those people who did use the option?  (Even if the
number of people using it is on the small side.)

3. How much work would it be to code it?

4. How would adding this option affect ease of use for users?  Ie, how
much (possibly unnecessary) complexity would it add?

Factor 4 is largely a question of proper design.  Well designed
software should present a simple interface for the beginner user, yet
allow sufficient complexity for the seasoned and able user.  Design
which achieves this goal is often difficult to do, but usually
possible and most definately worthwhile.

Factor 2 is one which is often missed by products designed for the
mass-market.  There is a tendency to cater for the "lowest common
denominator".  About 15 years ago I bought an average priced digital
watch.  It was a very good one which served me well for quite a few
years.  It had one feature I loved --- a setting which adjusted the
monthly time gain or loss.  Using this I could set my watch so that
after a month it was out by only a second or two.  Sadly the day came
when I had to replace my watch, but I could not find one with the same
feature.  The watch I currently own gains about 40 seconds after a
month.  I can only conclude that the majority of people didn't use the
functionality of that setting and so the mass-market manufacturers
ditched it.  But it was a very nice option.  It meant that I could be
confident my watch was accurate and I only had to reset my watch once
a year or so.  These days I have to reset it much more frequently.
More to the point, I am constantly having to think when I last reset
it and estimate how fast my watch currently is --- a real pain.

My point is that "good" software is not always the same thing as
"mass-market" software.  I know in a sense you are targeting Evolution
at the mass-market, but I believe it is possible to do this without
sacrificing ideals of making it "good".

When I think about how this idea applies to Evolution, I think of the
filtering rule syntax.  The mass-market would be happy with a simple
list like structure, with the choice of either "anding" everything
together, or "oring" it together.  Having the ability to mix anding
and oring would add considerable power to the software, making it a
really "good" bit of software.  Perhaps only a minority of people
(20-30% maybe) would actually use this added power, but those who did
would be extremely glad of it.  I realize that this project would have
to be of lower priority than some others, and a longer term goal.
What I am suggesting however is that you do include it in your plans,
so that evolution is designed for this functionality to "slot in" when
it eventually is developed.

Well that's about all I wanted to say.  I think we are basically in
agreement.  Thanks for listening and keep up the great work!  I really
am appreciative of the work ximian programmers are doing!



Jeffrey Stedfast [fejj ximian com] wrote:
It's not that I don't believe in config options, I do. I just think
people get too carried away with config options which ends up bloating
the piece of software out of existance. I'm all for trying to make
Evolution useful for as wide an audience as possible, but I also think
that it's not worth my time to add options that only 2% of the user base
is even going to know how to use nevermind actually use it :-)
Wouldn't you agree?

I think that once Evolution reaches 1.0 and is considered "stable", that
would be the time to start bloating it with mostly-useless features.
Bloating it with features before it's even stable is in my very humble
but correct opinion a terrible waste of resources and not a very good
idea as we have deadlines to meet and the more features we code the less
time we have to actually fix stability problems :-)

I think that this is the biggest problem with a lot of free software
projects (other than perhaps being underdesigned). They implement every
possible feature imaginable before the application can even stand on
it's own. It's just asking for trouble.

Please, don't get me wrong - features are good, but only after the base
features work well. I think that you did have some very good ideas (I
even think some of them should definetely be there before 1.0). I just
think that the time for most of your features should come after 1.0 or
at least not be added until everything else is working correctly ;-)


On 29 Jan 2001 18:01:05 +1030, Mark Phillips wrote:
Dear Jeff,

Thanks for your reply.  I presume you are one of the guys who actually
does the coding for evolution.  So thanks --- it's looking good so far.

I realize I can't make any demands about what goes into evolution and
what does not.  If I really want something I should code it myself.
As you said, you accept patches. :-) Unfortunately due to time
committments, I cannot code.  I can only make suggestions.  If you
find any of my ideas useful then it would be great if they could be
implemented.  But of course, if I fail to persuade the programmers of
the merits of my ideas then I quite understand they won't happen.
Basically I am trying to help in the limited way I can at the moment
--- and that is to suggest things which I think would make evolution a
better piece of software.

You don't like configurable options it would seem, or at least not
many of them.  It sounds like we have a different philosophy on the
matter.  Yes I can understand configurable options mean more work, but
there is plenty of software out there, particularly in the unix world,
that allows a lot of configuration.  I believe the work involved in
making something configurable is worth it.  Not everyone thinks the
same.  Not everyone uses the software for the same purposes.  Not
everyone uses the software in the same way.  Configurable options give
the freedom and the flexibility to satisfy everyone.  However I do
accept that it is possible to go too far with configuration ability.
Some thought does need to go into how useful a particular
configuration option is and whether it is worth the effort.  It sounds
however like you and I may have a different perception of how much
flexibility is good.  Oh well.  All I can do is argue my case, and
leave it to the programmers to make the decisions.

Jeffrey Stedfast [fejj ximian com] wrote:

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

The value in size information is that you could quickly gauge how much
disk space a particular folder was using up.  If you need to prune
your messages to save on space, this is useful information to have.

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.

I don't know the specifics of your code, so it's hard for me to
comment on the practicality of displaying thread information.  However
one solution would be to store this kind of info in the folder
directory.  That is, count the threads once and store this
information.  When things change, update this information.  That way
you would not need to recalculate the number of threads every time you
wished to display it.

The danger with this is that with bugs, the stored information could
get out of alignment with the actual situation.  It would be helpful
therefore to have some form of "resyncing" ability.

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.

Perhaps.  But if the messages still actually exist in the folder, and
are recoverable, it may still be useful to have this information.

    - 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

It depends on the type of user.  Perhaps the average windows user
wouldn't, but for many Linux users, who are used to customization
ability, they would customize much more.  I know I do with other
software.  One of the things I like about mutt is its customization

I accept that configuration options are more work, but I also suspect
you are painting a slightly bleaker picture than reality.  In mutt,
configuration options are part of the design framework.  A lot of
thought has gone into the different types of configuration required
and how to organize this.  I suspect a well designed configuration
framework would make programming the different options more bearable.
But then, I only speak as someone who isn't doing the work.  You are
the ones writing the code, so if you disagree with me, you win. :-)

I suppose what I am suggesting, is that if the people making the
design decisions at ximian agreed that allowing a reasonable degree of
configurability was a good thing, then you could come up with a
unified approach to configuration.

The option of choosing which information to display wouldn't really be
that hard to do: a configuration window for selecting items to display
and a display routine which works out which information to display
based on the variables which have been set.  I can understand that
doing lots of configuration options in an ad-hoc manner could be a lot
of work, but a unified approach to configuration would reduce the work
load.  I suppose in the end though it comes down to how much you value
the ability to configure.

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

Well that would be a good start.

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


Okay let me try to explain.  Sometimes I go into a folder, look for
interesting messages and then leave.  Because I've only "read" some of
them, most of them are still listed as unread, even though I've
scanned through the subjects briefly and decided they're not that
interesting.  Now I could just mark them all as unread, but I don't
want to do that, because I may still want to go back and look more
closely at the unread messages.

But suppose I go out of the folder and some new mail comes in.  I
haven't read this new mail.  I haven't even looked at the subject
lines.  So I want to look at this new stuff to see if I notice
anything interesting.  But in threaded view I can't easily, because
the "new new" messages are mixed up with the "old new" messages.  Of
course I could just unthread the display and see them that way, but
that would take time, and besides, often I want the threaded display.

Making the "new un-read"-"old un-read" distinction is a nice solution
to this dilemma.  I did not think of this, a number of other email
clients do exactly this: elm, pine and mutt for a start.

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

I think it's a good idea, but if the programmers don't agree... I'll
just have to accept it.  (And either put up with it, or find another
email client --- which would be a real pity because I love your

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

This is a partial solution, but still somewhat lacking.  I would like
to be able to step through the messages while using the "full message
view" option.  That is, while looking at the full message, I would
like to be able to press "n" say, and have the next message whipped
up.  Your solution would require me to open and close a new window
each time.

Perhaps an alternative solution to my problem would have an option
where the message display is a separate window.  It would behave
exactly like the current message frame, but in its own window.  Though
I still think that my original suggestion is better.

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

It's nice to know that, for example: "Oh look, I've got 118 new
messages to be incorporated".  At the moment I have to do a bit of
quick arithmetic early on in the incorporation stage to guess how many
new messages are coming in --- and even then, it is only a rough

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

Yay, we have agreement! :-)

    - 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, I use Evolution in this very manner. Folder tree on, shortcut
bar off.

Thanks, I missed this option!

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

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?

I understand what you are saying, but it is not necessary to have the
parent to display the messages in a threaded fashion.  You simply
display the relationships between existing messages.  That's the way
mutt works and its way of doing threading is one of the things I
really like about it.

For example, say you have the following structure:

  |  E
  |  F
  |  |  G
  |  H
  |  D
  |  P
  |  |  J
  |  |  K

What if you don't have message A?

Then you would simply display everything except message A, ie:

  |  E
  |  F
  |  |  G
  |  H
  |  D
  |  P
  |  |  J
  |  |  K

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

It sounds like you don't like console based mail clients.  In my view
they have advantages and disadvantages.  The disadvantages are one of
the reasons I am hoping to move to evolution on a more permanent
basis.  However just because GUI mail clients have some advantages
over console based ones, doesn't mean there latter don't have some
good ideas that you could pinch.  I happen to think mutt does
threading very well and evolution could learn from this.

Yes I know evolution doesn't have to use +'s and -'s etc, but that is
missing the point.  The point is that with the subject line printed
for every message, the whole thing looks cluttered and is hard to
read.  It is hard to see where one thread starts and another finishes.
It is hard to see where a thread changes subject line part way
through.  When your eye tries to find a subject line to read, there is
not one clear choice --- the result of this being that trying to scan
through different threads quickly takes longer.  I have used mutt
threads for a while and I have used evolution threads for a while and
I know that the former are much easier to read.

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

Well date would be another good one, but others may have merit at
times too.  But even if you limited it to From, To, Cc, Subject and
Date, somebody may only want to use a couple of these, eg From and
Subject --- thus using screen estate more efficiently.  Different
people have different needs.  And once you make it configurable, you
may as well allow a reasonable variety of choice.

Again, it depends on whether you want to make configurability part of
your design choices.  If as a team you choose to do configuration,
then to add this bit of configuration wouldn't be that much work.  The
configuration panel you would need would be of much the same format as
the configuration panel needed earlier in this email --- ie for the
mail folder information stuff.  The kind of configuration is very
similar.  If you had a standardized way of dealing with this kind of
configuration issue then it wouldn't be so much work.  (Still some
extra work of course, but not as painful --- and in my view, worth

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

I would code if I had the time but at the moment I don't.  I do feel
however that I would not be the only one who would find a comment
field useful, and surely this is one suggestion which wouldn't be too
much work?  I am only suggesting these things because I think they
would make evolution a better piece of software.


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

I admit this is a bit more of a challenge than some of my other
suggestions.  I still think it would be worth looking at as a longer
term goal however.

    - 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

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!


* Option to edit message using an alternate editor: 

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

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.

That's fine.  I'm glad to hear there are plans in the works.

* Save draft option improvements: 

    - The save draft menu item should not automatically kill the compose
    - 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.

Perhaps the best place to delete the old message is at precisely the
time you save the new one?  You would need a mechanism which allows
the composer to know that this old draft exists.

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

    - 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'm not sure what you mean by `glade` it (I'm not familiar with glade).

Have you ever used a compiler environment which understands your
syntax and so colourizes and indents accordingly?  I envisage
something similar, except perhaps with a few extra ideas thrown in.
It would be a "text editor", except that it would automatically format
things as you typed.  It would also colourize (or buttonize) certain
key words if they were typed in the correct place.  For example, if
you typed "To:" in the appropriate location, it would perhaps write it
in a different font, maybe underline it, and make it clickable --- ie
turn it into a button as well as being text.

Yes I realize that this would be a fair amount of work.  I am
suggesting it as a longer term goal, not a short term one.

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

Console land isn't all bad.  Buttons, pull down menus etc all have
their place, but there are also times when they have limitations.
Text is very flexible --- it is two dimensional rather than one, and
you can type anything.  This also has it's drawbacks.  I am looking at
taking the best from both worlds.  With my suggestion, if you wanted
to add an extra header, you just type it.  If two dimensional
formatting is required, it just does it.

There probably also are ways of improving the functionality using
normal buttons etc, but in the longer term I suspect my way would be
better.  One advantage is that you would be able to use a similar
approach elsewhere in evolution, such as with the filtering rules.


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

Has key customization been done now --- I didn't realize.  I know you
can do some form of composer editor customization already, but I
didn't know there was general key customization yet.

Well, I hope you've found my suggestions food for thought and that at
least some of them you've found to be worthwhile.



____/~~\_____/~~\________________________________mark ist flinders edu au_
        "They told me I was gullible ... and I believed them!" 

____/~~\_____/~~\________________________________mark ist flinders edu au_
        "They told me I was gullible ... and I believed them!" 

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