[Evolution-hackers] Handling Aliases, Silent Mode, Combo Tasks
Greetings I'm not sure if this should fall into the hacking section or general section ... so pardon me if this is the wrong audience. I have bumped into some areas in Evolution that, I think, might either be buggy or could use some improvement. It is possible that I'm doing something wrong. I'd appreciate some corrections, and links in that case. Here they are: 1. Once an account is set up it becomes difficult to implement an alias sending. Evolution doesn't allow its user change the sender's field when composing ... except for accounts created locally. For people involved in open-source projects like Evolution this makes it hard to use evolution to send list related mails. Why? Some users have email aliases tied to their email accounts ... and use the aliases for such projects. Is there no way one could override the sender's field so users can enter their email aliases instead? 2. It would be nice if evolution can start silently ... docked in the panel and runs on the background. This will ensure that the user gets notified when mails arrive. This also frees the task bar. This functionality can be archived in conjunction with another application called Alltray, but alltray has side effects. It introduces shaky graphic performance (Compiz transitions are affected) 3. This is more of a feature request: Wouldn't it be nice if Evolution can handle what I call Layered Tasks ... or Stratified Tasks ... or maybe, Combo Tasks. I've been thinking about this ever since I started using Evolution. I see Combo Tasks (or whatever) as a Task that has other tasks inside it -- like a project with small objectives. As the smaller tasks get satisfied the Main Task counts of progress (in percentage). One can modify the Combo task by adding or removing mini tasks (tasklets). Is there something like this already? This will help group related tasks together ... like in a Project (but it doesn't have to be a HUGE PROJECT). It could be handy for DIY domestics like Build a Kitchen Cabinet ... then you can have sub-tasks like: Design the Cabinet, Discuss it with and, possibly, involve the family, Establish Wood type, Buy parts, Cut the pieces, Assemble it, Varnish and install it, Celebrate. The sub-tasks are full tasks on their own with dates etc and can send notifications/reminders, but they update the Combo Task (container) with progress. It gets more interesting if Sub-tasks can also be Combo tasks. I hope I'm not sounding crazy Thanks for the anticipated response Regards Oku, O ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Handling Aliases, Silent Mode, Combo Tasks
Greetings I'm not sure if this should fall into the hacking section or general section ... so pardon me if this is the wrong audience. I have bumped into some areas in Evolution that, I think, might either be buggy or could use some improvement. It is possible that I'm doing something wrong. I'd appreciate some corrections, and links in that case. Here they are: 1. Once an account is set up it becomes difficult to implement an alias sending. Evolution doesn't allow its user change the sender's field when composing ... except for accounts created locally. For people involved in open-source projects like Evolution this makes it hard to use evolution to send list related mails. Why? Some users have email aliases tied to their email accounts ... and use the aliases for such projects. Is there no way one could override the sender's field so users can enter their email aliases instead? 2. It would be nice if evolution can start silently ... docked in the panel and runs on the background. This will ensure that the user gets notified when mails arrive. This also frees the task bar. This functionality can be archived in conjunction with another application called Alltray, but alltray has side effects. It introduces shaky graphic performance (Compiz transitions are affected) 3. This is more of a feature request: Wouldn't it be nice if Evolution can handle what I call Layered Tasks ... or Stratified Tasks ... or maybe, Combo Tasks. I've been thinking about this ever since I started using Evolution. I see Combo Tasks (or whatever) as a Task that has other tasks inside it -- like a project with small objectives. As the smaller tasks get satisfied the Main Task counts of progress (in percentage). One can modify the Combo task by adding or removing mini tasks (tasklets). Is there something like this already? This will help group related tasks together ... like in a Project (but it doesn't have to be a HUGE PROJECT). It could be handy for DIY domestics like Build a Kitchen Cabinet ... then you can have sub-tasks like: Design the Cabinet, Discuss it with and, possibly, involve the family, Establish Wood type, Buy parts, Cut the pieces, Assemble it, Varnish and install it, Celebrate. The sub-tasks are full tasks on their own with dates etc and can send notifications/reminders, but they update the Combo Task (container) with progress. It gets more interesting if Sub-tasks can also be Combo tasks. I hope I'm not sounding crazy Thanks for the anticipated response Regards Oku, O ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote: As usual this is turning out to be a bigger job than expected, and I'm less confident now that I can get this all done by 2.91.90 but I'm still gonna try. The alternative, since I -really- don't want these XML blobs creeping into GSettings even temporarily, is to depend on GConf for 3.0 and then land this stuff (along with Rodrigo's GSettings branch) early in 3.1. Were it not for the pressure to get everything converted in time for GNOME 3.0, I would already be retargeting this for 3.1. Hi, sounds reasonable, this seems to be quite intrusive change, not only for evo itself, but for everyone using it, so landing in time of .90 might be rather bad. Apart of that we have enough such changes in sources already, counting also gtk3, so I'm 111% for postponing to early 3.1. libedataserverui - All e-passwords functions will simply take an ESource instead of component and key strings. Keyring entries will contain the UID of the corresponding ESource instead of URI components (we'll convert existing keyring entries as part of the migration phase). It would be good to allow also username changing in EPasswords. It's very unusual to allow only password entering when most applications are allowing to change both username and password (I'm not aware of any other with enter password only functionality at the moment). It seems to be related, a bit, thus I'm bringing it here. Also note one thing which might require a bit rewriting. If I recall correctly you would use the ESource's UID for password storing. The thing is that evolution allows setting auth-method, which is used as 'component'. The advantage of this is that the ESource for calendar can share password from mailer (while not knowing the parent source/account at all), because they are using same 'component' and 'key'. So with your change in the passwords there should be a knowledge to which account is this ESource tight (which is not always clear right now?), and this parent account should be used instead of the actual ESource, right? I do not want to complicate things much here, though with the change also user name proposal above it might mean that one wouldn't use different name for calendar and a different name for mailer with this? I think we are not using any such approach here anyway, so I'm only brainstorming here. Bye, Milan P.S.: If you'll be changing API, please change also EIterator API, to not return 'const' pointers from e_iterator_get. We use to forget to change this release by release :) ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Handling Aliases, Silent Mode, Combo Tasks
On Fri, 2010-12-10 at 09:06 +0100, twohot wrote: I'm not sure if this should fall into the hacking section or general section ... Hi, as this is not about developer thing, then I would rather use evolution-list, because you are asking as a user. Nonetheless, see below. 1. Once an account is set up it becomes difficult to implement an alias sending. Evolution doesn't allow its user change the sender's field when composing ... except for accounts created locally. For people involved in open-source projects like Evolution this makes it hard to use evolution to send list related mails. Why? Some users have email aliases tied to their email accounts ... and use the aliases for such projects. Is there no way one could override the sender's field so users can enter their email aliases instead? No way at the moment, there is a bug filled in https://bugzilla.gnome.org for identities or something like that. Evo's way for this is to create an account for each alias and set only sending part there (the receiving will hae None). Then you would be able to choose respective addresses when sending a message. 2. It would be nice if evolution can start silently ... docked in the panel and runs on the background. No way, no need, will never be part of evolution itself. I'm sorry. Also see http://live.gnome.org/Evolution/FAQ 3. I see Combo Tasks (or whatever) as a Task that has other tasks inside it -- like a project with small objectives. Yes, sounds like a feature request. I thought it would be enough to group your tasks based on a category (View-Define view and create a new one there, and assign categories to your tasks), but it might not work as you wish, with a relationship to the parent task. Please search the bugzilla, and if not found there already filled, then feel free to file a feature request there. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Fri, 2010-12-10 at 11:54 +0100, Milan Crha wrote:
It would be good to allow also username changing in EPasswords. It's
very unusual to allow only password entering when most applications are
allowing to change both username and password (I'm not aware of any
other with enter password only functionality at the moment). It seems
to be related, a bit, thus I'm bringing it here.
Also note one thing which might require a bit rewriting. If I recall
correctly you would use the ESource's UID for password storing. The
thing is that evolution allows setting auth-method, which is used as
'component'. The advantage of this is that the ESource for calendar can
share password from mailer (while not knowing the parent source/account
at all), because they are using same 'component' and 'key'. So with your
change in the passwords there should be a knowledge to which account is
this ESource tight (which is not always clear right now?), and this
parent account should be used instead of the actual ESource, right?
User name and authentication method will be stored in a key file group,
which defines the following keys (from my notes):
Schema: org.gnome.Evolution.Source.Authentication
--
[extensions/authentication]
--
domain : 's' (do we still need this?)
method : 's' ('none' means auth not required)
remember-password : 'b'
user: 's'
Both the user name and authentication method can be changed freely.
For a groupware account that shares authentication details across all
data sources, it would make sense to put the authentication group in the
top-level ESource alongside account details, then have child ESources
for mail accounts, calendars, etc. refer to it. The keyring entry for
the groupware account would store the UID of the top-level ESource so
the password too can be easily be shared across all data sources.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Handling Aliases, Silent Mode, Combo Tasks
Yes, sounds like a feature request. I thought it would be enough to group your tasks based on a category (View-Define view and create a new one there, and assign categories to your tasks), but it might not work as you wish, with a relationship to the parent task. Please search the bugzilla, and if not found there already filled, then feel free to file a feature request there. Bye, Milan Thank you very much Oku Onyeibo ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
