It would be really really cool if there where autocomplete in the New Event dialog. Phoenix has the same autocomplete as IE which is the best. You normally defined the same stuff when making new event. Like Meeting or birthday, so it could save a lot of time if I could autocomplete the text stuff

New contact from mikep@oeone.com to mostafah@oeone.com Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.

If you put this component in the component directory of Sunbird and replace: <textbox id="item-title" oninput="updateAccept();" flex="1"/> by: <textbox id="item-title" oninput="updateAccept();" flex="1" type="autocomplete" autocompletesearch="CalendarEventsTitle"/> in calendar.xul the title of the event was autocompleted by all the title of the events of the selected calendar. What do you think of the approach ?

First impressions: -Wow, sweet! -I'm not very familiar with auto-complete functionality, but this certainly looks interesting. My biggest question is, when does startSearch run? getItems() is kinda fast, but if startSearch is going to run after every letter is typed, that could get ugly quickly. For non-trivial sized calendars, getItems is expected to be on the order of 1-2seconds. For large calendars, I can imagine getting up to 5-10seconds. (Note that we're currently much slower, ie 30-45s for medium-large cals, but this can be improved.) If this is going to be an issue, you might be better off doing the query at startup and caching the results. Then add onAddItem/onModifyItem listeners, to adjust the cached results as necessary. On the other hand, I may have simply misunderstood the mechanics of auto-complete. -We currently build the calendar.xpi for Seamonkey from the same codebase. As I understand nsIAutoCompleteSearch, it's toolkit only. How will this interact with Seamonkey? -Given that we're getting all of the items, are there other fields that it might make sense to auto-complete (and make this componenent a bit more general)? Location immediately jumps to mind. URL might also be reasonable. Some minor/less important thoughts: -Do we want the search to be based off of the item-type (event/task) too? -Why restrict to the currently selected calendar? I don't usually adjust the calendar that my event is going into until last, or it might be the case that I want copies of the same/similar event in 2 different calendars. -For js-components, calendar has an auto-component loader. Simply filling in the proper data in http://lxr.mozilla.org/mozilla/source/calendar/base/src/calItemModule.js#79 ought to save you the trouble of factories. I'd be curious what some of the people more familiar with this functionality think. I believe mvl did some work along these lines too.

(In reply to comment #3) > -We currently build the calendar.xpi for Seamonkey from the same codebase. As > I understand nsIAutoCompleteSearch, it's toolkit only. How will this interact > with Seamonkey? Seamonkey wants to migrate to Toolkit in time. I would say that this will be one more incentive for them. Until they migrate we could put that stuff into an #ifdef MOZ_XUL_APP

(In reply to comment #3) > First impressions: > -Wow, sweet! > > -I'm not very familiar with auto-complete functionality, but this certainly > looks interesting. My biggest question is, when does startSearch run? StartSearch was called on each input event. > getItems() is kinda fast, but if startSearch is going to run after every letter > is typed, that could get ugly quickly. For non-trivial sized calendars, > getItems is expected to be on the order of 1-2seconds. For large calendars, I > can imagine getting up to 5-10seconds. (Note that we're currently much slower, > ie 30-45s for medium-large cals, but this can be improved.) > > If this is going to be an issue, you might be better off doing the query at > startup and caching the results. Then add onAddItem/onModifyItem listeners, to > adjust the cached results as necessary. On the other hand, I may have simply > misunderstood the mechanics of auto-complete. Yes, for that I have to implement stopSearch, but I don't know how to break getItems() process yet. Is it a good idea to manage an events cache just for an autocomplete process ? Why not just make autocomplete working for local calendar ? > -We currently build the calendar.xpi for Seamonkey from the same codebase. As > I understand nsIAutoCompleteSearch, it's toolkit only. Yes For an autocomplete process on seaMonkey, a nsIAutoCompleteSession must be implemented. > How will this interact with Seamonkey? I'm sure this can't work, but I don't know if there is any side effect. > -Given that we're getting all of the items, are there other fields that it > might make sense to auto-complete (and make this componenent a bit more > general)? Location immediately jumps to mind. URL might also be reasonable. Location and URL, yes... it's a good idea. > Some minor/less important thoughts: > -Do we want the search to be based off of the item-type (event/task) too? I don't know, tell me :) > -Why restrict to the currently selected calendar? I don't usually adjust the > calendar that my event is going into until last, or it might be the case that I > want copies of the same/similar event in 2 different calendars. You're right. > -For js-components, calendar has an auto-component loader. Simply filling in > the proper data in > http://lxr.mozilla.org/mozilla/source/calendar/base/src/calItemModule.js#79 > ought to save you the trouble of factories. Yeah :) Thanks ! > I'd be curious what some of the people more familiar with this functionality > think. I believe mvl did some work along these lines too. Yes... I'm interested by an opinion about using a nsIautoCompleteSearch.

What's new: - use auto-component loader - use all calendar - put the calendar name as comment (on the right of the popup). Using showcommentcolumn textbox attribute - autocomplete on title, URL and location. If there is another property, just put its name on the autocompletesearchparam textbox attribute for an autocompletion. It needs a cancelable getItems for large or distant calendar. dmose file a bug about this: 329034. Not use task list yet. No XPFE support yet.

Show todo list for completion

- task list support - correct use of onOperationComplete Everything should be ok. I've tried autoComplete with a big and distant calendar: webcal://www.agendadulibre.org/ical.php?region=all ... and autocompletion seems to work fine. but we should wait for a nsICancelable from getItems function: https://bugzilla.mozilla.org/show_bug.cgi?id=329034 in order to cancel getItems lauched by deprecated startSearch request.

Not going to make the 0.5 train.

No progress for over a year. -> Re-assigning to nobody. Feel free to re-assign this bug to yourself if you work on it (again).

Moving this up the radar. This is a major usability win and it would be great if someone could push this forward based on the old (and probably bitrotted) patch, which should still be a good foundation.

Wow, an old patch from me. I'll update the code asap.

(In reply to comment #12) > Wow, an old patch from me. I'll update the code asap. Paul, any update here? We would really like to take this for 0.9.

I have an early patch in my hands. I will post it Sunday. Sorry for the delay.

An early patch, only tested with Lightning 0.9pre and TB 2. Some questions (for performance issues): - what calendars should we query ? - Should we skip calendars requiring network and calendars without cache supported ? - Should we query items from a defined (preference ?) date range (6 month before today and 6 month after ) ?

Comment on attachment 326372 [details] [diff] [review] patch v2 It's probably best, if you discuss those things with your patch reviewer. Philipp, please see comment 15 before doing the review.

Please consider providing a pref to disable this feature for those of us who will never use it and have slow CPUs.

Comment on attachment 326372 [details] [diff] [review] patch v2 I'm quite swamped with exam preparation, moving review to daniel.

Just some general questions I have though: Does any caching take place automatically (i.e in toolkit?). I imagine that even if we only allow this on cached calendars or local calendars, this will really make the event dialog unusable on a large calendar. Have you tried this with something like the Musicians Birthday calendar? How does this look like in the UI? Is it like the usual autocomplete search boxes that dropdown below the textbox? If so, can I remove certain things from the list with the delete button so that they are removed permanently? For example, if I've entered the location "Sex club" into a certain private calendar that I don't want anyone looking over my shoulder to see, but when I start entering "Summer Camp", then due to the calendar still being in my list I'd have that option? Also, we might want to think about a general event search api that providers can implement. For example, google allows server side querying of certain things, so even an uncached calendar could return just results containing the searched string. Also, the storage provider could be modified to only SELECT certain fields that contain the searched string. This would improve performance greatly. Something to be done in a different bug though. Paul, would you be interested in doing so? If we have this search api, then we probably don't have to limit the search to a specific date range. We could limit querying to calendars that are either local, cached, or are remote and support the event search api.

In my opinion the autocomplete should only show entries I have entered before while creating/editing events, e.g. previously entered titles for the title field or previous entered locations for the location field. It should not show entries from all kinds of calendars I might be subscribed to. Or at least this should be an option that can be turned on.

Comment on attachment 326372 [details] [diff] [review] patch v2 Moving review back to myself, since daniel is on vacation. Sorry for the delay, I'll be able to get to this after the 2nd I hope.

I also think ssitter's opinion might be worth considering. Of course it might be a good thing to allow auto-completion from all locations in my calendars, but as said this might be too much. It might be a good idea to bring this discussion into the newsgroups, I'm opening a thread there, see http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/5fdbdc14ccf3da87#

Oops... XUL part of the patch was missing.

Comment on attachment 327799 [details] [diff] [review] patch v2.1 >Index: calendar/base/src/calItemAutoComplete.js >+const Cc = Components.classes; >+const Ci = Components.interfaces; >+const Cr = Components.results; At some point we decided not to use Cc, Ci, Cr. please expand. I could imagine that you want to shorten line lengths, in that case, please use const nsIAutoCompleteResult = Components.interfaces.nsIAutoCompleteResult; >+ >+function calItemAutoComplete() { >+ this._pendingOperations = []; >+ this._searchParam = null; >+ this._caller = null; >+ this._result = null; >+} I'd prefer prefixing with m, i.e this.mPendingOperations. Also, please add these variables in the prototype, i.e mPendingOperations: null, mCaller: null, ... >+ >+calItemAutoComplete.prototype = { >+ QueryInterface: function(iid) { Make sure all functions are non anonymous and prefix arguments with a, we often use shortcuts like: QueryInterface: function cIAC_QueryInterface(aIID) Also, we have a doQueryInterface function in calUtils.js which makes QueryInterface look a bit cleaner. >+ _fireResult: function() { >+ if (this._result.matchCount == 0) >+ this._result.setSearchResult(Ci.nsIAutoCompleteResult.RESULT_NOMATCH); >+ else >+ this._result.setSearchResult(Ci.nsIAutoCompleteResult.RESULT_SUCCESS); >+ this._caller.onSearchResult(this, this._result); See style guide, use {} also for one-line ifs. Also please expand tabs to 4 spaces and remove redundant spaces at the end of lines. >+ var calManager = Cc["@mozilla.org/calendar/manager;1"].getService(Ci.calICalendarManager); use getCalendarManager() >+ var op = cal.getItems(Ci.calICalendar.ITEM_FILTER_ALL_ITEMS, 0, null, null, this); >+function SimpleResult() { I'd prefer a name more related to calendar, i.e calSimpleResult ? Same comments about prefixes, QI, prototype vars, anonymous functions, style for this file of course. >+ appendMatch: function(aValue, aComment) { >+ //FIXME: crappy is aValue a unique string? You could use an object, i.e if (!(aValue in this.mResultsMap)) { this.mResultsMap[aValue] = aComment; } So much for code review, some questions regarding implementation are still open therefore no r+ yet.

Comment on attachment 327799 [details] [diff] [review] patch v2.1 >+ var calManager = Cc["@mozilla.org/calendar/manager;1"].getService(Ci.calICalendarManager); >+ var calendars = calManager.getCalendars({}); Nice comment on the NG about disabled calendars: we want to exclude them here. you might want to consider using the composite calendar here which already filters out disabled calendars.

From reading the NG posts, I have the feeling the majority tends to only want previously entered values to be added. Paul, do you agree? Is this something you would implement? Maybe the advanced mode to take all entries into account is something the user could turn on via advanced preference?

(In reply to comment #26) > From reading the NG posts, I have the feeling the majority tends to only want > previously entered values to be added. Paul, do you agree? Is this something > you would implement? Maybe the advanced mode to take all entries into account > is something the user could turn on via advanced preference? > Ok, it makes sense and it sounds feasible. Where the history would be stored ?

Not sure, how does firefox do it with saved form data? Possibly a new sqlite database that contains some needed indexes would be good. Daniel, what do you think?

Firefox stores such data in a sqlite file (formhistory.sqlite). I think I will use the same mechanism (and the same filename ?).

A sqlite db sounds reasonable to me, but I worry about when that data is cleaned up.

What about delegating such mechanism to the toolkit form-history component ? Components: "@mozilla.org/satchel/form-history;1" through nsIFormHistory2 for feeding the db. I've tried, but, first, this component is not built by default in Thunderbird, and then, XPFE autocomplete mechanism doesn't work well with such component. Some patch in the XPFE autocomplete XBL seem to be needed (for instance about getStyleAt call). Bug 360648 may have to be fixed first. I think it's the proper (but longer) way to fix this bug. Should I work on a "short term" patch ? Any thoughts ?

Comment on attachment 327799 [details] [diff] [review] patch v2.1 I agree we should use generalized interfaces as far as possible. I'll be happy to review a short-term patch if you like, I'm quite indifferent. If you feel like investing work into a short-term patch, go ahead. Otherwise its probably fine if this bug stays open for a bit longer r- for now to get this out of my queue and since we've come to the conclusion that we shouldn't query all items.

Bumping this request, for the following reason: Recently and I think more in the near future, the new Provider for Exchange will gain popularity and allow Thunderbird to be used in big corporations like mine, where MS rule (office, outlook). I'm currently using it to replace Outlook fully. But I stumble upon an unexpected lack of feature: there is no history in "location", while there is one in Outlook! This seems stupid, but it is very useful, as all my meetings happen in 3 different virtual locations only :) And without it, you have to copy&paste it from somewhere... Not really nice! Thanks

Not working on this anymore.

Hopefully somebody else takes over...

Hello community Are there any plans in a near future for this bug? This would be so useful... Thanks

Sad to see nothing new on that side. I think maybe the bug is too big? Why not starting to autocomplete locations only (most usefull in my opinion), and then see if the rest is really needed?

I think the problem is that the perfect way to solve this requires so much dependent work. Ideally, if Lightning could hook into gloda, then we have an index of all locations on all events thats quickly accessible. Then implementing this would be a breeze. Anything else means we need to reinvent gloda in a less complete form. Some sort of caching for locations thats quickly accessible, possibly on top of the calendar cache, on top of the storage calendar.

I maybe wrong in my thinking, but isn't autocomplete a standard practice when programming forms? Isn't that a part of a good IDE?

Bug don't exist now. Can somebody close it?

(In reply to bug from comment #44) > Bug don't exist now. Can somebody close it? Unfortunately, your comment is not helpful. This issue is a feature request, not a bug-report. And, as far as I can see, right now (Thunderbird 31.7.0 + Lightning 3.3.3), the feature is not yet implemented. Neither the task name, nor the location are auto-completed, so this is still pretty much relevant. Or what was your point?