[Evolution-hackers] Approval of licensing change
Hi all, Kjartan Maaras pinged me on #i18n about licensing change and mentioned how I was one of the missing guys. Unfortunately, I have not received an email about it, so here it goes: I give approval for a license change to both LGPLv2 and LGPLv3 for all my contributions to Evolution and related software packages (including, but not limited to evolution-data-server, evolution-exchange). Since SMTP headers can easily be forged, if in any doubt, email me with a secret token and I'll reply back. Cheers, Danilo PS. It's possible that I've used different email addresses in the past. The list includes [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] All of them still go to me, so feel free to use them as well. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Dear Felix, Ahhh wait! It's nice you separated data and configuration, but to be honest: I really don't want my home directory to be flooded with data I don't even want do see outside the application! Calm down dear, it's only a discussion. I don't want to have a folder background images in my home where the background images are, I don't want to have a evolution emails folder where I can get to my emails without opening Evolution itself! I don't think I'm alone with this thought...think of all the non-power-user, for them it would be a tsunami of data they cannot handle... I don't think it would be that much of a 'tsunarmi' not only would defaults be selected in a way which would make them structured and shared; but they would be configurable (even to the point of hiding) and wouldn't exist until you needed them anyway. The idea is nice, but not for every program! Why should I want to access the emails directly? Why wouldn't you want to? 1) Backup your emails without special software, 2) Be tied to a specific program for the rest of your life with special syncing software. 3) Unable to index emails without special indexing software. 4) Be able to search for emails without a searcher that integrates with said indexing software 5) Be able to input and export to and from other services and devices without special software. In fact one of the themes of the above is that for every innovation you need to have special software which interacts with the application APIs or hidden proprietary formatted configuration files in order to do anything interesting. It's a lot of wasted work which only comes about because developers think it's nice to want to hide their user's data. I can use Evolution for that, its nicer and a lot more user friendly then the file explorer is! I think this is a big step in the wrong direction, you would like to use the email application just to make the connection and download the mails! That reminds me of the old telnet email clients - my uncle still uses one of them, because he's familiar with that - but we have really powerful applications now, we should use them! So be it, no one said these folders couldn't be hidden in a teletubby distro for those who are weak of heart. As far as a step in the wrong direction I think not: the underlying technical principles set forth in my previous emails would be valuable, if employed in an integrated manner. they would allow people to move from/to gnome/kde/xfce without having to sync data, it would allow programmers far more stability and confidence in how to access various types of data, creating a platform for more interesting ideas to be tried out. Oh and most people end up creating a backgrounds folder anyway. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] External editor plugin
Em Qua, 2008-09-17 às 11:22 +0530, Sankar escreveu: I have not seen how this is done in claws-mail. Is it external editor embedded into the composer body area ? No, the composer body area gets blocked while the external editor is being run and, when it's done, the edited text gets to the composer body area. Greetings. -- marcot Página: http://marcotmarcot.iaaeee.org/ Blog: http://marcotmarcot.blogspot.com/ Correio: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi Felix, Now I think your idea is not bad at all, because we have a quite nice folder structure already (Documents, Pictures, Videos and so on). But they must be used! Correct me if I'm wrong, but FSpot makes its own directory (/home/foo/Photos) for the pictures you want to copy to picture location (you can select this option when importing pictures to fspot). Yes that is the case, the way these directories are configured is that there is a config file which lists each one. this allows for folders in different languages to be used correctly by programs without having to have that foreign language support built in (without breaking horribly). Getting folders used is a matter of project preference, although support for the ideas from other developers would help push standards too. I still see some issues (like a unified way to save emails, not that if I first use Thunderbird my emails are stored like foo.mail and with Evolution they are stored like 080916_foo.evomail or similar) but issues are here to resolve and as you pointed out already: this is a discussion, so lets discuss :) The file names them selves might not be such a problem so long as the structure is well defined. Making sure the folder structures in evolution correspond to the folders in the file system would be a first step. This may either be done through convention or by configuration (such as a more detailed XDS) The file formats and the mime-type would be the most important aspects after structure. E.g ~/Email/Personal Account/Inbox Martin, are you familiar with Cosimo Cecchi's Summer of Code project? (http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A) It's a very interesting project, it actually seems more radical than my ideas but certainly is along the same lines. Having an index based file chooser is a very useful feature. Probably a integration of his media manager into nautilus would solve some of your problems? Although the main aspects of being able to run your files through any application outside of gnome is still very attractive. ergo: ssh from your laptop to your computer, your looking for a contact in your evolution account. You have the command line. P.S. I've taken cheese mailing list off the reply, don't want to flood their list. 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, first, let me tell you I perfectly agree with you that user data should be easily accessible to users. It's their data after all. Now I want to shade this a bit for what is usually called PIM data. imho, users (I mean normal non-geeky users) often only know about one way of getting to their data and can only handle few at a time. This is really important wrt to what you said about mails. Somebody replied to this thread qualifying what would be the direct (brutal) application of your proposal as a tsunami of data and I can only agree with that. This would be a poor user experience really :) About standards, evolution actually uses standards to store data, mbox for mails, ics/vcard for addressbook, events memos. It can also export all of these data from their hidden store to another standard format. Even nicer, it has a backup plugin that saves all this and configured accounts to a tarball that you can save anywhere you want. Personnaly I've had harder times getting my data out of thunderbird last time I tried (which was probably ~1.0). Now obviously all programs probably won't be able to deal with evolution's backup tarball (but most probably can with individual exports) but that's probably because nobody even thought about getting started on standardizing this kind of stuff before. -- Gilles Dartiguelongue [EMAIL PROTECTED] signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Configuration masquerading Data
Hi Gilles, first, let me tell you I perfectly agree with you that user data should be easily accessible to users. It's their data after all. It's not just abut accessibility in your currently working computer at this point in time. It's also about visibility, compatibility with alternative and future programs, the ability to use these files in interesting way. Do we have a program that can give you real time reports on your emails? do we have innovation in data processing? I beleive hiding the data has lead everyone down the garden path, restricting compatibility, reducing the drive for standardisation and ensuring programmers have lots of work to do in the import and export plug-ins market. Now I want to shade this a bit for what is usually called PIM data. imho, users (I mean normal non-geeky users) often only know about one way of getting to their data and can only handle few at a time. Dealing directly with how the user interfaces is an important question, but I believe we must enable as many routes to use our data effectively with the way we structure our output. For instance I don't believe someone will check their emails in nautilus. But could they do a search or open those self same emails in kmail without syncing and api bridging crutches? Could they access their email in a command line tool? is there a way to send a message in a business account on evolution as an attachment in your gmail account? This is really important wrt to what you said about mails. Somebody replied to this thread qualifying what would be the direct (brutal) application of your proposal as a tsunami of data and I can only agree with that. This would be a poor user experience really :) Well only if the emails were all pushed into their face, say if we store them all in ~/, I'm not advocating bad design. Picking out the ideal structure for where emails go which is out of the way but still available is important. The suggestions I've given already make it clear that the system is just as important as the principle to make sure we don't introduce new problems. About standards, evolution actually uses standards to store data, mbox for mails, ics/vcard for addressbook, events memos. this is good, if EDS is already using these files then it's not much of a change to make it configurable and/or based on XDS directories (which distro's could then configure) giving users, distributors and other programmers ways to find and control data output in what ever way they feel their target users would like. It can also export all of these data from their hidden store to another standard format. Even nicer, it has a backup plugin that saves all this and configured accounts to a tarball that you can save anywhere you want. Personnaly I've had harder times getting my data out of thunderbird last time I tried (which was probably ~1.0). Lots of exports are band-aids, some exports are genuinely useful such as svg to pdf, going from editable design stage to print ready production. others are for compatibility or for backing things up. Exporting an email to a processed thread file would make sense I think. Exporting it to an email backup file seems like it's trying to get around the limitations of the user data storage, because if normal backup solutions can't back your emails up without making special exceptions to decided what is data and what is configuration for every app it's not doing something right. Now obviously all programs probably won't be able to deal with evolution's backup tarball (but most probably can with individual exports) but that's probably because nobody even thought about getting started on standardizing this kind of stuff before. If you made a backup using a standard file backup utility when using the proposed ideas; you would be able to recover the emails in the right directories ready for use, even if during the time you had moved applications or even platforms. In fact there would be no thought needed from the user, it would be a simple matter of getting the files in the right places. As for opensync, could you imagine if they could eliminate all those custom end point plugins for each and every application? Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
