Re: [Evolution-hackers] Evolution Ideas for Future

[Rodney Dawes <dobey ximian com>]

On Tue, 2003-07-15 at 23:09, Not Zed wrote:

> Looks quite like a souped-up summary in a separate window.

Yeah. It would at least make tasks more useful to have them in a
separate window, or something. I don't use the evo tasks right now
because it needs the whole thing open to view them, and I haven't
bother playing with one of the scripts to put them in a text file
on my desktop, and scale the icon up. Besides, I do some funky stuff
with the libs on my system, and Nautilus likes to crash when I try
various icon themes. :)

> I'm not so keen on this one.  Mainly because its already a bit of a task
> fitting enough useful information in the list for it to be usable.  And
> then you also have the user-interface ambiguity of which pane is
> currently active etc.  e.g. see the way unfocussed message-lists still
> display the selected message which matches the one displayed below.

Right. I didn't say I was either. It's definately a usability/a11y
nightmare. I was just pointing the possibilities. Perhaps someone else
could make a custom patch for their Evolution install. If they did, I'd
rather see it done mostly right. :)

> Yeah, evo plugins? ...  They also come up with some odd stuff like an
> online buggon 'only if they use your client'.  Which seems pretty bunk -
> what do they mean, you have the IM implemented directly as part of the
> app, ignoring all other IM protocols and directories?

Plug-ins indeed. If we had a nice sane plug-in system, it would be easy
to write a plug-in that did the necessary CORBA stuff to get data from
my IM client. I'm not sure how it would work with some of the other
clients though. I imagine one would have to write some kind of funky
plug-in-to-plug-in communication method for gaim or something.

> And yeah, what about video/phone conferencing?

We don't need a plug-in system so much for this. The only *really*
useful thing it would get us, is the ability to determine whether or
not someone is already in the middle of a call. And if you are doing
a conference with multiple people that are connected to a conferencing
server, then that's mostly moot anyway, but it would provide a hint as
to whether or not they are connected to the conference yet. I bet the
pointy-haired types would love this feature. :P

> Well ...
>  - often you don't care if they're there or not, otherwise you'd phone
> them up/im them, and getting a mail to say they wont reply for a few
> hours might just be more noise than signal.
>  - it could divulge otherwise personal information you didn't want to
> (i.e. am i at home/in my office)
>  - if you do the IM thing, then it just duplicates the same
> functionality it could provide (and you may indeed be mailing them
> because they're away from their IM client ...).

True. Though, it does make more sense in the IM case. The IM client
could find out that you are in a meeting or something and set yourself
away and auto-reply with "In a Meeting. E-Mail me or call back later."
or something similar.

> If we did some plugin system it would be easy to do, if only we had one.

Agreed that it would probably be much better to have it be a plug-in,
but it should still be quite simple to do it with a single client and
allow people to modify the command lines for the backends via gconf or
an xml file. Considering that we'd probably want to just use the same
code that is already in the filters stuff for this, XML files may
make more sense, then we can just tell the filter backend to use a
separate filters.xml for each action (ham/spam/report/whitelist/etc...).
I don't know how abstract the code is in the mailer though, but it's
worth looking at for 2.0, especially since we are refactoring a lot of
code, and this would make many many many people happy.

> What happens when you mouse-over a multiple address field and one which
> doesn't fit on screen?

Chris already pointed out that we couldn't (shouldn't?) do this in the
mail list, since it already has tooltips for showing the full address.
But then again, now that I think about it, the full name and address
would be in the popup for the vcard anyway. And for the other columns,
we could just do what we do already. And then, if the address isn't in
any of the autocompletion folders, and no vcard is attached to the mail,
we could just show "Full Name <user host com>" or something, perhaps
more similar to the format we would use the the vcard tooltips.

> Naah you could just use the existing label system.  And use filters to
> do the marking.  Whats the external app needed for?

Because filtering, labelling, and marking is one thing. It would be
oh-so-very-nice to not have to have evo running to have it check mail
every N minutes or whenever, and the external app would be to pop up
the notification icon without needing the full evo gui open. Or perhaps
one might be on another desktop at the other end of their ad infinum
amount of virtual desktops, and want to know when new important mail
comes in, without needing to look in the gui itself.

> This is always a two edged sword, if you put too much into the context
> menu, it becomes less usable.

My sentiments exactly. And we already have too much. :)

> > Bonus) P2P Document Sharing
> > 
> > 	This is probably done better with some combination/integration
> > 	method with Rendezvous, MultiSync, and possible one of the open
> > 	p2p protocols.
> 
> Versioning and so forth would be neat.  But this sounds like a much
> bigger problem than should be pushed into a mailer (i presume it uses
> email as the transport protocol).

Indeed. At least, it could be a much bigger problem. It's probably not
worth even remotely looking at until we get the mono runtime embedded anyway,
so that we can just have a C# plug-in to do rendevous-ish things. And that is
a long time off, from what I can see.

-- dobey