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
course).
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
ability.
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.
Huh?
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
vfolders!)
* 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
guess.
- 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.
Great!
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
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?
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:
A
B
| E
| F
| | G
| H
C
| D
| P
| | J
| | K
What if you don't have message A?
Then you would simply display everything except message A, ie:
B
| E
| F
| | G
| H
C
| 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
above.
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
it.)
* 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.
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.
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
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.
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
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.
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
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'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.
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.
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.
Cheers,
Mark.
--
_/~~~~~~~~\___/~~~~~~\____________________________________________________
____/~~\_____/~~\__/~~\__________________________Mark_Phillips____________
____/~~\_____/~~\________________________________mark ist flinders edu au_
____/~~\HE___/~~\__/~~\APTAIN_____________________________________________
____/~~\______/~~~~~~\____________________________________________________
__________________________________________________________________________
"They told me I was gullible ... and I believed them!"
