Re: [Evolution-hackers] External editor plugin
On Wed, 2008-09-17 at 08:20 -0400, Reid.Thompson wrote: On Wed, 2008-09-17 at 11:22 +0530, Sankar wrote: Will such a workflow be not best done by having vi/emacs style key-bindings for the composer body area , rather than opening a external program ? Is this being implemented/considered? If so, where is it hosted? The problem with emacs-style key bindings is that, for those of use who've been using Emacs almost as long as we've been using computers, they are never complete enough. Bind-alikes are OK for some small text editing areas, but for something like email you really miss all the extra keybindings that a real Emacs gives. Don't get me wrong: some compatibility is better than none. Invoking an external editor is also useful and something I'd be interested in trying out (I used Emacs VM mode for mail for years and years before I had to connect to an Exchange server, just so I could have full Emacs editing for my mail). However, the most ideal situation that I can imagine would be to figure out how to make Emacs embeddable. Then it can become a universal editor plugin, for Evo, FireFox text boxes, Eclipse, etc. etc. Start up Emacs in the background and have applications that need an editable box contact it to create new child windows containing real Emacs buffers. I would actually cry if I could get that. :-) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
I think this idea is extremely valuable and merits robust discussion to discover ways to encourage application developers to incorporate this way of approaching data storage. Thank you, I'm not always as coherent as I'd like when I describe my ideas and knowing it made sense to you gives me confidence in presenting it as a discussion at UDS in December. I wonder how would you differentiate between data and configuration if you were to write a specification for this? There is a logic between the two can be broken down into the following definitions: Configuration - Data which changes the state and logic of a computation, key selection of the flow of an application or execution which are not involved in the input or output data directly. User Data - Data which is directly the input or output results for any computation or use. Consider for example Pidgin, which stores its account data within a .purple directory. The same tree also contains logs for each of the discussions, icons, application preferences and miscellaneous other files. Examples: - Pidgin * Configuration - Settings for which services to connect to, what skins to use and what plugins to use. * Data - Text entered at the keyboard, text received over the service, files received or sent over the service, chat logs. - Gnome Background Settings * Configuration - which background is selected, which backgrounds are available, how a background is to be presented. * Data - Background image files - Evolution Email Application * Configuration - which services to connect to, which plugins to use, syncing rates, display preferences. * Data - Email messages recieved, contact data, calendar event, note text, text typed in, files sent as attachments. What I'm asking is, at which point do you think the line between application data and user data needs to be drawn, or do you think that a best practice approach might incorporate the idea that if your application stores information that is useful to another application, it should be stored in a non-configuration location? There is a further separation at the configuration level which must be accounted for. Sercive configuration often involves standard protocols which multiple different apps for different reasons could use the same configurations for. This isn't to be confused with user data though. A directory for ~/.services/email/accounts.xml would be a way of standardising the service/protocol level configuration. User data though needs to be stored in ways which users have control over directly. The cheese project recognised that keeping photos out of the home directory browsing space was a bug and that hiding user data is not a desirable quality when you want flexibility and user control. The fact that other applications could use this data is a useful side effect too. For instance using XSD directories cheese has allowed F-Spot to be made to import photos from the XDS directory, grabbing cheese photos and then allowing the user to export them to flikr or what ever the user wants. This provides a level of context to a users data and power to the user. The XSD directories idea is a very powerful one which should be considered for more user data than it is currently. Another aspect is making sure that each elemental datum has a standard format which we can use to allow the user control of. For instance an image can be saved as a png file, An email message can be saved as an eml/message file and a bookmark can be saved as a link file. but not all of the available formats have been agreed upon, standardised or even meet all of the feature requirements of the applications involved. For instance vcards are nice, but I can't see EDS using them as a data store since it's not a very normalised format. I should also make a note that just because the data is stored in files in some of these examples doesn't mean you are forced to forgo the use of an index. The mechanism of recording your email messages in a sqlight db file which may or may not be specific to the application is not in question. Let me know if I've managed to explain my ideas on how we can differentiate user data from configuration data. I'd be interested in cases which break my logic. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi, I think it would be important to distinguish between a local cache of a remote IMAP or CalDAV folder (i.e. Configuration) vs. local mail folders, calendars, contact lists, etc. (Data). I agree, I regretted not making a note about cache data. Caches are temporary stores, if it makes sense to export them to a more permanent states then that would be where they'd translate into user data. As an example, pidgin's user lists and profile images are cache, unless the contact is tied to a standard address book system where the profile image could be stored in the right place it's not permanent and is more of a state of the application. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Fwd: Evolution: Taking forward...]
Hi, So here is the plan : * Drop Evolution copyright assignments and make it really easy to contribute to Evolution * Move Evolution licensing to LGPL v2 and LGPL v3 to let us re-use the code more easily around the platform. This also moves us closer to Thunderbird's MPL/LGPL model. We think this is good for Evolution and (of course) we continue to invest in Evolution. We are also working to ensure we have the rights to re-license all of the code. We will do the licensing/header changes as we audit the code ownership situation. It would be really helpful if you can post a public/explicit mail with permissions to do it, or code pointers - if you think you wrote a piece of Evolution code object. I hereby approve the license change for the alleged 3 lines of code I have :) Thanks, James ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Shouldn't the Telepathy framework be considered for storing account settings? Remco ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-sharp-0.17.5 vs mono-2.0
Hello, Trying to build evo# on mono-2.0 we get this error: /usr/bin/gacutil /i evolution-sharp.dll /f /package evolution-sharp /root /var/tmp/evolution-sharp-0.17.5-build/usr/lib Failure adding assembly evolution-sharp.dll to the cache: Strong name cannot be verified for delay-signed assembly There's a check-in, r191, which purports to fix this but it also breaks backward compatibility. What's the right way to fix this? We need something for openSUSE 11.0. Thanks, Andrew Jorgensen (Mono / openSUSE Package Maintainer) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Nice thoughts, really nice thoughts! But I have to defend cheese! You're right, storing the pictures in a hidden directory is not that good! The maintainer of cheese, daniel siegel implemented it this way, because he thought storing all these random-crazy-looking-pictures taken with cheese in the photo directory makes more than a mess! Anyway, we have changed that already in the latest version (which will be released with gnome 2.24 on Sept. 24)! Now the pictures and videos are stored either in a user-defined path (at the moment its only a gconf option, but it could be part of a preferences dialog too in future...) or in the standard xdg folder [1], for example /home/foo/Videos/Webcam (if the gconf option is not set)! So, try out the new cheese and tell us if you like it ;) Best Regards, Felix Kaser [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html Martin Owens schrieb: Dear Ubuntu and Evolution Developers, I'm sending this email to the gnome evolution hackers list to see what their thoughts are. I have noticed a really odd disconnect in gnu/linux with user data which has me a little worried. Some user data is hidden from users in configuration directories. Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. For consideration I present Cheese, a very nice tool for using web-cams to take photos with weird disfiguring effects. The problem as I see it is that Cheese stores each of the photos in it's ~/.cheese directory which makes them hidden from the user. Instead I propose that Cheese use a standard directory (possibly configurable) such as ~/Photographs/Cheese or ~/Documents/Cheese which is accessible to user browsing. Cheese is an excellent example of making user data more accessible to casual file browsing which is not just limited to jpeg images but could just as easily apply to the way Evolution stores emails, addresses, contacts and so on. In these instances the data is always bound up in evolution specific formats inaccessible to casual browsing as well as casual integration (without delving into the EDS API) I'd like data to be available to send in an email, or browse in nautilus (or on a command line) I'd like to be able to open the same jpeg in image viewer and gimp, not just in what ever created or generated them. I'd like to be able to open addresses and copy an event file to my thumb drive. Wouldn't it be good to backup all your files without configs and be sure your not missing emails or bookmarks? In fact the methods we use to store data seems to be along the same lines that certain Windows and Mac programs use to obfuscate and hide data in order to lock users into their products. Do we really need to do this on our gnu/linux systems? Should we instead intend user data to be converted with plugins and export features in every application because of their hidden default outputs? This issue may be interesting to the FDO (freedesktop.org) crowd. It is a very heavy topic that will probably get me a little flaming because it goes against what is currently best practice. Best Regards, Martin Owens ___ Cheese-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/cheese-list ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution: Taking forward...
Permission granted to relicence my code (committed as [EMAIL PROTECTED] or [EMAIL PROTECTED]). Thanks, Philip On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote: Hello guys, We have had a set of problems that we are carrying around for some time like : * Copyright assignments, which is not the best way looking for the future of Evolution. It sucks and sort of limits contributions to Evolution and we wanted to drop it. * The current licensing incompatibility issues of Evolution with Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the new mapi based connector being developed for Exchange 2007. So here is the plan : * Drop Evolution copyright assignments and make it really easy to contribute to Evolution * Move Evolution licensing to LGPL v2 and LGPL v3 to let us re-use the code more easily around the platform. This also moves us closer to Thunderbird's MPL/LGPL model. We think this is good for Evolution and (of course) we continue to invest in Evolution. We are also working to ensure we have the rights to re-license all of the code. We will do the licensing/header changes as we audit the code ownership situation. It would be really helpful if you can post a public/explicit mail with permissions to do it, or code pointers - if you think you wrote a piece of Evolution code object. We are really excited about this and we feel this would really help Evolution a lot. We need your support now for making this change and to take Evolution to great heights. Thanks for your contributions and support. -Srini. ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Since we do really want to remove the fork and pick up packages from upstream, I can change the apis in evolution related packages if a new set of apis with some suffix is provided from libical upstream. Many of you have probably already read this on the libical mailing list, but just in case: I have applied Chenthill's memory management patches (only to the 'libical' directory and to the examples -- still have to do the 'libicalcap' and 'libicalss' directories) using function names ending in _r. For example, icalcomponent_as_ical_string() is now simply a wrapper around icalcomponent_as_ical_string_r() which places the new string buffer on the ring before returning it to the caller. The functions whose names end in _r have had Chenthill's memory management patches applied to them. Do we still need to add the HANDLE_LIBICAL_MEMORY hack to make the old function names act like the new ones? Chenthill's most recent message (quoted above) seems to imply that the Evolution team is willing to move to the new function names. Let me know. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
On 13/09/08 11:48, Martin Owens wrote: Technically configuration directories denoted by being hidden (suffexed with a '.') are there to hold collections of configuration files for the applications which they serve. But there are plenty of programs using these directories to store the data results as well as configuration. I think this idea is extremely valuable and merits robust discussion to discover ways to encourage application developers to incorporate this way of approaching data storage. I wonder how would you differentiate between data and configuration if you were to write a specification for this? Consider for example Pidgin, which stores its account data within a .purple directory. The same tree also contains logs for each of the discussions, icons, application preferences and miscellaneous other files. The account information is stored in an XML file which mixes Pidgin-specific data with user IRC account data. What I'm asking is, at which point do you think the line between application data and user data needs to be drawn, or do you think that a best practice approach might incorporate the idea that if your application stores information that is useful to another application, it should be stored in a non-configuration location? -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
