Re: Evolution Plugins (Was Re: Rise of the Plugins)



On Mon, 2007-11-19 at 03:33 -0700, Sankar P wrote:
> On Mon, 2007-11-19 at 11:06 +0100, Alexander Larsson wrote:
> 
> > 
> > Hmm, didn't know about that! Its much nicer, but a bit busy by default
> > with showing so many columns. What if it only showed prefered email
> > address and prefered phone nr by default?
> > 
> > Also, preview is still on bottom so as soon as you enable that its much
> > harder to browse in the list. Even when there is lots of unused space
> > availible to the right, since I just removed a bunch of the columns in
> > the listview...
> 
> Yes. It shows a lot of not-so-often-used columns. I have a custom-view
> which I have saved long-back and been using for years which has some of
> these columns removed and re-sized properly. (Same for mailer as well)
> 
> Similarly, the New Contact dialog also shows a lot of options, one may
> not fill most of the times.

So, maybe we should at least go over the default settings and see if
they can be made better?

> Patches are welcomed *hint* :) 

Heh. Unfortunately I don't have any time to spend on this... I just have
time to complain. :)

> > Why not go whole-hog and do per-component toplevel window designs. :)
> > Thats more or less what you get if you make everything about the window
> > per-component specific, but in a much more complicated way.
> 
> It is just that I do not want to lose the functionality of everything
> under a shell which is been preferred/used by the large chunk of
> corporate users (migrated from Outlook, Novell GroupWise client, etc.)
> Accepting appointments from mail-view, Mail-To-Task are all heavily used
> in corporate setups.

I can totally understand this. And as corporate clients is a very
important customer for novell (and redhat too for that matter) its seems
sensible. I just get the feeling that it also limits the ability for
evolution to experiment with better solutions at times...

> Furthermore, as I explained in some other mail, mails, calendars and
> address-books are related applications to me. And hence I want to have
> them under a single shell launched by a single-click.

Sure, they are related, and they need to be efficiently accessible from
the same place. This means both having UI for single click access
between the applications and things like preloading and/or sharing
address space. However, I don't see how this requires the components to
be sharing the same shell, in the same window, or in windows that have
the same kind of shell.

> As Srini said in another mail, we should have an amicable solution for
> this by 2.22, once we complete the MAPI work we are currently doing.

Sounds very good! Keep up the good work!




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