Re: [Evolution-hackers] [Old Version 2.28] Tasks: Prevent Ctrl-X in search box to accidentally delete tasks, For what it's worth: My comprehensive set of patches for ancient 2.28

2013-08-19 Thread Thomas Mittelstaedt 
Am Montag, den 19.08.2013, 11:05 +0200 schrieb Thomas Mittelstaedt:
 Am Montag, den 19.08.2013, 07:51 +0200 schrieb Milan Crha:
  On Fri, 2013-08-16 at 22:50 +0200, Thomas Mittelstaedt wrote:
   I don't know if this works cleanly in the newest versions. But in my
   ancient version, doing a search by entering a term in the search box, 
   selecting a piece of text of that search string and hitting Ctrl-x would
   result in the currently selected task to be deleted. And Ctrl-v would
   not bring it back. I inserted a little crutch in my old version to 
   simply disable the cut command and that worked. See attached diff.
  
  Hi,
  as I replied to one of your previous emails, please use bugzilla for
  issues and patches, the mailing list is not a place where these should
  be added, at least not for evolution-hackers.
 
 All right, Milan. I created an enhancement bug report at
 https://bugzilla.gnome.org/show_bug.cgi?id=706287

And to quote from that report:

For what it's worth: My comprehensive set of patches for ancient 2.28
version. (edit) 
Product:
Evolution 
Component:
Tasks
Version:
2.28.x
Status:
UNCONFIRMED
Priority:
Normal
Severity:
enhancement
Collapse All Comments - Expand All Comments 
[reply] [-] Description Thomas [reporter] 2013-08-19 09:02:07 UTC 
Created an attachment (id=252183) [details]
Set of patches

Just for completeness: I have reached a very nice level of stability and user
satisfaction with this old, ancient version of evolution, which I use on
an ubuntu 10.04 (Lucid Lynx) box.
Over time I applied several patches, fixes of simple safety checks in response
to crashes to this version and I thought, I upload it as an enhancement bug
report, if somebody may be interested.
I use a Software called stacked git (stg) to apply these series of patches.
Naming convention of these patches is issue_number_... . This hints at a
concrete bug report in bugzilla and should be reachable with the following url:
https://bugzilla.gnome.org/show_bug.cgi?id=number.
I also uploaded my build script and the script I use to run the application.


-- 
thomas


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Move IMAPX back to a module library for 3.12

2013-08-19 Thread Matthew Barnes 
The IMAPX classes were moved into Camel's public API to serve as base
classes for evolution-kolab.  But since Christian has parted ways with
us it would appear the evolution-kolab project is no longer active.

I'm planning a good deal of API changes to IMAPX over the next few
months as I work toward completing IMAP NOTIFY support, and I would
prefer these changes not be seen as breaking Camel's public API so I
have sufficient freedom to change what needs changed.

Therefore I plan to move the IMAPX classes back to a runtime-loadable
module library after the 3.10 release.  If the evolution-kolab project
is resurrected at some point in the future then we can renegotiate this.

Any objections?

Matt



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Move IMAPX back to a module library for 3.12

2013-08-19 Thread Srinivasa Ragavan 
On Mon, Aug 19, 2013 at 9:03 PM, Matthew Barnes mbar...@redhat.com wrote:
 The IMAPX classes were moved into Camel's public API to serve as base
 classes for evolution-kolab.  But since Christian has parted ways with
 us it would appear the evolution-kolab project is no longer active.

 I'm planning a good deal of API changes to IMAPX over the next few
 months as I work toward completing IMAP NOTIFY support, and I would
 prefer these changes not be seen as breaking Camel's public API so I
 have sufficient freedom to change what needs changed.

 Therefore I plan to move the IMAPX classes back to a runtime-loadable
 module library after the 3.10 release.  If the evolution-kolab project
 is resurrected at some point in the future then we can renegotiate this.

 Any objections?

I still dont accept it under Camel. Since we are fixing it, Im fine.

-Srini.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers