GNOME.org
 

Re: [Evolution] Evo 2.24.3 bug list, by personal priority.

I want to thank you all for your great responses and feedback - even
where you firmly told me that you disagreed with me, I do appreciate it.
I'll keep the responses brief, and group them into one message to keep
it simpler.


I did try to limit mine to my top 5-6 "really can't use this utility
properly" bugs, and also to limit them to things which are really
obviously bugs, and not just "I wish Evo would work differently",
where other people may disagree.  In my experience the more you add to
your wishlist the less people feel inclined to read it all and work on
it.


My apologies, I will try to keep it briefer if I do it again.


* Bug 558363 - Evolution: Appointments reminder window lost on
  logout + login (reminder data loss) (Evolution)
  http://bugzilla.gnome.org/show_bug.cgi?id=558363
* Bug 558493 - Evolution: Reminders for Appointments due when the
computer is turned off are lost / never shown. (Evolution) [not sure
if this still happens in 2.24, need to check]
  http://bugzilla.gnome.org/show_bug.cgi?id=558493


I find these funny, because Evo used to work exactly like this.


Oh no! Sorry, I didn't know that.


And, people complained because after a long absence, when they started
Evo they would get hundreds of popup windows announcing reminders for
meetings that were long past... it entailed a lot of hunting and
clicking to locate and get rid of them all and really, what was the
point?  Those appointments were gone; it's not like you can get them
back.


Okay, I'm probably using my calendar a bit differently. I tend to
calendar things for myself that I'm planning to do (e.g. work on project
A on Tuesday, do company taxes on Wednesday, etc). Suppose I get the
project A work done, but some bit of hardware dies and needs replacing
on Wednesday, so I don't get the taxes done. In that case, I want the
taxes reminder to still appear on Thursday, because I'll reschedule it
for later.

Also, I'll set far-away reminders for events I need to prepare something
for - for example, a family member's birthday, where I know that person
is very hard to buy present for, so I'll give myself a week and half's
notice on the reminder, and I want the reminder to persist until I
dismiss it, because it's doing something useful by constantly reminding
me that I need to get a present for that person.

Of course some events do have a fixed date and very short reminders, but
they're quick and easy to dismiss.


So, bugs were filed and Evo was changed so that it no longer did
this.  People were happy.  But I guess not everyone :-).

I agree that a better fix to the original problem would have been to
have a single window with a list of reminders so that it was easy to
select and dismiss them in a group, rather than having individual
popup windows for every reminder.


And that is the solution that we will have for Evo 2.26 (I think) where
some reminders can be dismissed (or you can go dismiss all). Here's a
screenshot:
http://bugzilla.gnome.org/attachment.cgi?id=121962&action=view
(I.e. now has "dismiss" vs "dismiss all" buttons). The resolved bug for
that is here: http://bugzilla.gnome.org/show_bug.cgi?id=558354

That allows getting rid of everything very quickly (just click "dismiss
all" and you're done), or selectively keep some and not others
(highlight those you don't want, click "dismiss") ... so given that
we'll soon have this, with a single window with granularity on what
reminders can be dismissed, I personally would like to see reminders
persist and only go away when they are explicitly dismissed by the user.


a dismissive attitude towards RFCs will not get you very
far with FOSS software.  Microsoft refugees may find this
shocking ;-), but standards trump personal preferences and "the user",
_every time_. There is simply no contest at all.  Standards are what
make the entire ecosystem of FOSS possible--even the small and "silly"
ones--and as such they create an extremely high barrier.  It's no
longer in the realm of personal preference.


I'm a little bit wary here, as I don't want to get into an extended
debate, and I think we largely agree anyway.

In general, I am extremely pro-RFCs. I am 100% pro RFCs where they are
invisible to the user (e.g. SMTP RFCs, HTTP headers, etc). RFCs about
infrastructure rock.

I am also pro de-facto standards for public Internet communications,
such as on mailing lists, such as having the "-- " separator to assist
with removing long signatures. But for private internal corporate
communications, it looks out of place, and it's trying to solve a
problem that nobody wants solved (total number of times that a boss /
colleague / customer has ever said "gee, I wish people would use DASH
DASH SPACE before their signatures" or anything like it, in 15 years:
Zero).

Furthermore, to quote the RFC itself, from
http://www.ietf.org/rfc/rfc3676.txt , section 4.3:

 There is a long-standing convention in Usenet news which also 
  commonly appears in Internet mail of using "-- " as the separator
  line between the body and the signature of a message.


... in other words, the RFC itself says that if the separator exists you
should honour it, and it's saying that it's a convention for usenet and
Internet mail, but at no point does it say that it applies to all
private internal communications and that you must use it for all
signatures in private internal communications. Forcibly inserting DASH
DASH SPACE into private internal emails is not something that the RFC
attempts to enforce (as far as I can tell), yet that is the very
behaviour that Evolution is forcing, which is not something which is
covered by the RFC in question.

Disclosure: I am assuming here that "Internet mail" refers mostly to
"public mailing lists", because that is the only context for mail on the
Internet in which I have observed "-- " as "commonly appearing".


I'm just warning you that trying to argue that some aspect of
Evolution, or any FOSS package, should be changed to violate an RFC 


No, I want the RFC to enforced, but in the contexts in which the RFC
itself says it applies (mailing lists and usenet), and not in the
contexts in which it does not apply (private internal communications).
That may even mean that I am more pro-RFC that yourself - we all want
the RFC applied, but I just want it applied correctly ;-) Joking aside
though, I think we largely agree, and there's a comprise solution
attached in one of the patches (see below), which will allow users to
change this by using an external app (gconf) and digging through
multiple layers to change a setting, but the default behaviour remains
as-is. Seems the best solution, as people who are really bothered can
change it, and for everyone else it stays as-is.


I assume that Nick is right about a bug introduced in 2.24.3, and hope
it gets fixed, but I hope it is fixed to correct the feature, not
remove it.


Looks like that has been/will be fixed - to quote from
http://bugzilla.gnome.org/show_bug.cgi?id=551470#c4 :

Not speaking of the issue of making "-  \n" from "-- \n" in some
cases, which I fixed in some other bug, which is waiting its review or
is in some other state


Responding to Patrick O'Callaghan:

It wasn't me, at least not in any systematic way. I do recall posting
a short list of "favourites" not long ago.


Sorry, I think I got my wires crossed between yourself and Paul Smith.


I see most of the list is related to calendaring, tasks etc. I only
use Evo as a mailer, so I won't comment on these.


Yeah, I tend to use Evo as a complete Personal Info Manager (memos,
calendaring, tasks, contacts, email), and tend to find more bugs in the
non-email parts (presumably because they're not as frequently used as
the email parts).


* Bug 558037 - Evolution: Accept semicolons, as well as commas, as
email-address separators in the "TO" address field. (Evolution)
  http://bugzilla.gnome.org/show_bug.cgi?id=558037


It doesn't help your argument to say you have no idea what an RFC has
to do with it, under the general principle of "be strict in what you
send, be flexible in what you accept". Not a point of honour however.


I probably haven't expressed this very well. I think that on the wire
Evolution should be completely RFC compliant, but as a User Interface,
for entering email addresses, it would be nicer for end-users for the TO
field to accept semicolons (and then convert them to commas either when
the user clicks send or save, or even as they type). The main reason for
accepting this is that users of Gmail and Outlook will be used to this
user interface, so it's one less different thing for getting the hang of
Evolution. I'm honestly not anti-RFC (even though I can see it might
seem that way), rather I'm pro-usability.


* Bug 200683 - Evolution: Spell check does not spell check an

email's

subject line (Evolution)
  http://bugzilla.gnome.org/show_bug.cgi?id=200683


Never even noticed this (I almost never use spell-check anyway). How
would this work with replies? You probably don't want the Subject of a
reply to be changed, at least not automatically.


I guess it could ignore the subject line of a reply? Or make the
correction suggestions, but the user can ignore them?

Also a quick update from bugzilla on a few of the previously-listed
bugs:

An number of the bugs that were listed are either already resolved in
the "kill-bonobo" branch, or are targeted at that branch, which Matthew
Barnes is working on. This sounds great, and I genuinely look forward to
this branch succeeding and landing on the trunk. Examples include:
* [Bug 556078] Evolution: Make Tasks / Memos / Calendar items remember
window size
* [Bug 558322] [KB-Fixed] Pressing "F2" on a highlighted Task List /
Memo List / Address Book / Calendar should bring up the properties
dialog box.
* ... plus a number of other bugs, which are not listed here.

I also want to thank Milan Crha, who has posted a number of patches for
bugs that were listed in the past 12 hours, including the following:
* Evolution: Clicking in a contact's "anniversary" or "birthday" field,
without changing anything, sets the date to today
  http://bugzilla.gnome.org/show_bug.cgi?id=559027
* Evolution: Make the "Attendee" column wider by default when adding or
editing a meeting.
  http://bugzilla.gnome.org/show_bug.cgi?id=561465
* Evolution: do not insert "--" (dash dash) at the start of signatures
  http://bugzilla.gnome.org/show_bug.cgi?id=551470
  [Note: this adds a hidden option, which you explicitly have to seek
out through gconf, in case you don't like the signature behaviour; I
think this is probably a good compromise solution - default to the
current behaviour, but allow it to be turned off with some effort by
users who really dislike it]
* Evolution: Set timezone for Imported calendar items if none is
specified.
  http://bugzilla.gnome.org/show_bug.cgi?id=558366

If some of the developers could maybe give a quick look over the above
patches, and give their comments on them, that would be most
appreciated.

-- All the best,
Nick.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]