Re: New module proposal: tracker
Not contributing to the core discussion. On Wed, Aug 19, 2009 at 3:26 PM, Alan Coxa...@lxorguk.ukuu.org.uk wrote: I think there lies a misassumption. The actual indexing has a fairly high cost. The cost of extracting metadata while indexing ought to be relatively low in comparison. That argues that allowing stuff to plug into the indexing based on file type is useful. It's not really function creep either given the only interface the indexer needs is - who is associated with this file type (which exists) - give me your metadata for this file content One short coming in this approach will be, It will cause a problem where multiple applications can be associated with a file-type, over a period of time. For instance, for .mbox files, the applications could vary like: Evolution, Mutt, Pine, Claws, Thunderbird, etc. And it is common among some people to switch between applications; not for email but other applications like PDF-viewer, etc. once in few months. All these different applications may have different interpretations for what is a valid meta-data. For instance, Evolution will consider any thing within ** will be metadata whereas mutt might consider subject is the metadata etc. So every time the user switches applications, the earlier collected meta-data might need some brushup. In my personal biased opinion, the need for meta-data and desktop search is over-rated. Internet is extra-ordinarily mammoth and is impossible to reach without a search engine as you won't even know how many sites exist. For desktop the scale of the things is less, individual application-provided-search is enough and will satisfy the needs of most of the users. ctags, mairix etc. can provide specialized and more effective searching. -- Sankar P http://psankar.blogspot.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Unifying name for Plugins/Extensions/etc.
On Wed, 2007-12-19 at 17:33 -0600, Shaun McCance wrote: (The fact that Plugins is very hard to translate was brought up by a number of people. Extensions apparently does not have this problem (comment #8 on the blog): I vote for Extensions. In Italian you can't really translate plugin, thus one has got to let it untraslated. Every time I use the word plugin I have to spend 5 min explaining it. So, besides being very culturally insensitive, it's time consuming as well.) Since plugin and extension are effectively synonomous, what's to stop the Italian translators for using their extension word for plugin? I will vote for continuing the usage of Plugins over any new jargon. Evolution, gedit, rhythmbox, gvim, anjuta all use the word Plugins. IIRC, Eclipse, Mono-develop, compiz-fusion as well. From my past experience, Using a new jargon may not be so well-received by users. We changed VFolders in Evolution to Search Folders. Still there are a lots of people using both the terms interchangeably. And all the code refers as vfolders, so developers end-up using VFolders more frequently than Search-folders. If translation is tough in Italian for the word Plugins, as Shaun said, why can't we use the Italian word for extension in that place ? Changing the term Plugin means, All the dependent user-docs, wiki pages, developer-docs, FAQ pages, screenshots should also be updated. Some distros ship plugins as seperate RPMs/packages. So these rpm/package names should also be changed. IMHO it is too much of an effort with lesser benefits. -- Sankar P Evolution Plugins (Extensions ?) Maintainer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evolution Plugins (Was Re: Rise of the Plugins)
On Thu, 2007-11-15 at 07:22 +, Philip Withnall wrote: We currently have the other extreme: several different applications each have their own take on the address book (and then each have their own different ways of integrating/syncing it with e-d-s). Why not just have one desktop-wide address book (I'm thinking Soylent here), and have the mail application use that instead? This would give us the opportunity to swap out the address book application in favour of other things if necessary, such as an application which would use some web service as an address book. I am not much aware of what Soylent is. So I cannot comment about using that atm. However, evolution-data-server is the system-wide address-book that will answer your needs. IIRC, eds exposes a dbus interface which can be consumed by any of the desktop applications, say Contacts, Gnome-calendar, OpenOffice, etc. Evolution-Addressbook (not eds) is just another client for the evolution-data-server addressbook. Probably Ross Burton can explain in more detail. IMHO a better approach will be to make the user choose what components he want to see in his Switcher. Say if someone wants to use only Mailer and Address-book, do not bother showing the Calendar component in the switcher. But that's effectively like turning the components into plugins, and then disabling some of them; it comes back to the problem that core functionality shouldn't be in plugins, and you might as well split off such plugins into separate applications. Atleast for me, It will be far more useful than launching two or three applications everyday morning (Mail/Calendar/Tasks) Isn't that what your startup programs list is for? :-P Yeah. I should have made it a little elaborate. Everytime I (or any corporate user) launches evolution, what I want to do with that is: - Send/receive mails - Accept/Decline/Schedule appointments - Mark the tasks that I have completed, so my boss knows if it is worth paying me for. In addition to these basic activities sometimes I may be publishing my calendar etc. All these activities adhere to the Communication aspect of an office worker. And I do this atleast 4-5 times a day. Rest of the times I spend on gnome-planner, OO, vi etc. So opening three applications for this communication aspect, each time, may not be an appealing option. I do not say that it is bad/evil to split applications but IMHO it may be a better idea to have Gnome applications aligned/coupled on the lines user behaviors, bringing similar applications in a shell, but very-loosely tied. In the same way how OO has a Spreadsheet, Doc-writer, Presentation-tool. Just my 0.001 Paisa(1). though :) Regards, Philip -- Sankar P (1) - http://en.wikipedia.org/wiki/Paisa ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evolution Plugins (Was Re: Rise of the Plugins)
On Thu, 2007-11-15 at 21:20 +1100, Jeff Waugh wrote: quote who=Alexander Larsson This is kinda a backward question. The reason you want to split it out is of course not because you want to use the mailer without the addressbook, it is because you want to use the address book without the mailer. ... and you can provide a deliciously optimised user experience for both use cases. It's worth looking at the user experience of the OS X communications tools, and possibly even the Windows Vista ones (although they're definitely uglier) to see why this is such a good way to go. It would be *FANTASTIC* to see Evolution become a suite of wonderful, focused applications instead of the Outlook clone it is today (and, sure, designed to be). The components of Evolution are loosely ties to the Evolution shell, so that you can use any component without other components loaded at all. To answer Alexander, if you have at least one account configured, you can directly launch Evolution Addressbook without ever having anything to do with Mail component. If you launch Evolution Addressbook from your gnome main menu, it should not ask your IMAP password. If it does, it is a bug, please file that. The reason for bringing up the account setup wizard when no account is configured is because it was expected that configuring an account will be the first thing a user will want to do. I accept that the bringing-up of account-setup wizard at startup, when no account is configured, needs to go away, with a Forget It. I want to use Evolution button, in the wizard-beginning. It is a needless restriction. I must admit, I've been trying to usher anyone involved in Evolution in this direction for years, so I'm very firmly on one side of the fence here. ;-) - Jeff -- Sankar P Harver's Law: A drunken man's words are a sober man's thoughts ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Evolution Plugins (Was Re: Rise of the Plugins)
Hi All, Some of the issues that were discussed (here and in #496839) and my personal take on them will be: 1) Plugin list being un-manageable I am thinking of adding a smart-search-box which will query based on plugin-names and pre-defined-tags associated with each plugin. This will make it easy to find out the plugin that you are looking for. Do you have any suggestion for how you want the Evolution Plugin-manager to look like ? Can you send any mockups that you have in mind ? 2) Some plugins should not be shown This may not be possible as people may not want a functionality implemented by a plugin. Disabling this plugin helps them to save screen-real-estate (menu-items etc) and reduces memory foot-print. If any of the core feature is implemented as a plugin, I accept that it should not be shown in the plugin-manager and will happily remove it from the plugin-manager list. (It should have been core-code than a plugin in the first place though) HTTP Calendars and IMAP Featuers are not core features since it may not be needed by everyone. Say a corporate Evolution-GroupWise user. 3) Splitting Evolution into individual applications I have seen this asked by people a few times. But I wonder what good a mail-client or Calendar-client will be without an addressbook. Evolution shell will not load a component (Tasks or Notes) unless you click open the component (except for addressbook) explicitly. But some people have a mis-conception that all components are always loaded (and hence consumes memory etc.) IMHO a better approach will be to make the user choose what components he want to see in his Switcher. Say if someone wants to use only Mailer and Address-book, do not bother showing the Calendar component in the switcher. Atleast for me, It will be far more useful than launching two or three applications everyday morning (Mail/Calendar/Tasks) 4) Evolution Preferences Dialog is Horrendous Yes. This is a terrible thing to have especially when you are working in low resolution. The reason why this was so mammoth was because even the plugin configurations were added to the General preferences. From 2.12 onwards, we have Configure support for plugins and hence people can configure plugins within the plugin-manager window itself. attachment-reminder plugin's configure UI has been already moved from General preferences to Plugin-Manager-Configure already. Work is on for Automatic-Contacts and other plugins already. One another option will be to show the preferences of the current component alone. Like if you launch preferences from Mailer component then only Mailer preferences should be shown. -- Sankar Gnome-Evolution Plugins Maintainer Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
