why not just create an account for each location and which which account(s) are enabled?
Jeff On Fri, 2003-07-18 at 15:42, Tom wrote: > Would it be possible to have multiple locations (user-defined), with a > different pop3/smtp setting for each location? For example, I travel > quite a bit to various customer locations. Each customer site has their > own requirements for pop3/smtp, requiring me to change my account > settings each time I go to a new place. > > If I could simply select my location from a list and have Evolution use > the pop3/smtp settings for that location it would sure make things > easier for me. > > > On Thu, 2003-07-10 at 17:44, Ettore Perazzoli wrote: > > > > > > Hello! > > > > Here at Ximian we have been brainstorming a bit about what happens > > next in the Evolution world. One of the ideas that has come up is a > > substantial overhaul of Evolution's UI. > > > > Since images speak better than words, here are the mockups for some > > designs that Anna has developed: (this is just to give a very rough > > idea of what it would be like; the icons and labels are not final, the > > widgets are not the real ones etc.) > > > > http://primates.ximian.com/~anna/evo2/evo2_contacts.png > > http://primates.ximian.com/~anna/evo2/evo2_calendar.png > > http://primates.ximian.com/~anna/evo2/evo2_mail.png > > http://primates.ximian.com/~anna/evo2/evo2_tasks.png > > http://primates.ximian.com/~anna/evo2/evo2_navbar_shrunk.png > > > > The most important changes are: > > > > * You no longer see all the types of folders at once. You > > switch between calendar, mail, tasks and contacts by > > clicking on the buttons at the bottom. > > > > * The calendar allows you to see multiple calendar at once. > > Also you can subscribe to web calendars and see them in the > > pane on the left as well. > > > > There are a few reasons for us to go with this design: > > > > * It kills the all-in-one tree view, which currently makes it > > difficult to reach for your calendar or contacts folders, > > since they are hiding between all the various mail folders. > > You no longer need to hunt for you calendar folder scrolling > > through the tree to see what your schedule is like, you just > > click on an easily accessible button marked "Calendar". > > Much better navigation. (Please note that, although it's > > not obvious from the mockup, we would still have a mail > > folder tree, the same way we have it now. Calendar, Tasks > > and Contacts, however, would be just flat lists.) > > > > * Killing the tree view also simplifies the architecture a > > lot. Right now there is a lot of machinery in place to > > handle the tree, making sure that components don't step on > > each other's toes. In particular, the handling of local > > folders is a maintenance nightmare, and also makes it very > > hard to provide the hooks that hackers need eg. to access > > Evolution's folders and do cool desktop integration hacks. > > > > * The shell's APIs would be drastically reduced to just > > a couple calls and it would become a lot simpler to > > implement new components. > > > > * This design simplification would also allow components to be > > launched independently from each other. We could > > potentially even launch the shell without certain components > > (e.g. launch only the mailer) if the user wants it that way. > > If we wanted to have separated apps a la OS X we could > > trivially do that too. > > > > * As I mentioned, it allows side-by-side calendar viewing, > > which increases the usability of the calendar manyfold. > > > > On the other hand, if we go this way we are probably also going to > > drop the following features: > > > > * The summary. While the summary is neat, there is a general > > feeling (at least amongst the developers) that the mail and > > calendar summaries are not tremendously useful, and that > > weather and RDF and weather information is better suited for > > a specialized application. Also we are trying to reduce the > > amount of code we have to maintain, and this seems like a > > good candidate for trimming. > > > > * The shortcut bar. It's been shown that only a relatively > > small part of the Evolution user community actually uses it, > > and we feel that it unnecessarily complicates the UI. The > > new design is much simpler to navigate anyways, and the > > shortcut bar would add clutter and complexity, both in code > > and UI. Also, it wouldn't be easy to implement in this > > model without keeping some of the shell's complexity that > > we would like to get rid of. > > > > Opinions? > > > > -- Ettore > > _______________________________________________ > > evolution maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution > > > > > > > > _______________________________________________ > evolution maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
