Autocomplete in event/task dialog (e.g. title, location, url, ...)

NEW
Unassigned

Status

Calendar
Dialogs
--
enhancement
16 years ago
3 years ago

People

(Reporter: Henrik Gemal, Unassigned)

Tracking

unspecified
Dependency tree / graph
Bug Flags:
wanted-calendar1.0 +

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

16 years ago
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

Updated

16 years ago
Severity: normal → enhancement

Comment 1

15 years ago
New contact from mikep@oeone.com to mostafah@oeone.com
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.
Assignee: mikep → mostafah

Updated

13 years ago
QA Contact: colint → sunbird

Comment 2

13 years ago
Created attachment 213466 [details]
This component implements nsIAutoCompleteSearch for events

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 ?

Comment 3

13 years ago
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.

Comment 4

13 years ago
(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

Comment 5

13 years ago
(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.

Updated

13 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 6

13 years ago
Created attachment 213705 [details] [diff] [review]
This component implements nsIAutoCompleteSearch for items

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.
Attachment #213466 - Attachment is obsolete: true

Comment 7

13 years ago
Created attachment 213818 [details] [diff] [review]
This component implements nsIAutoCompleteSearch for items

Show todo list for completion
Attachment #213705 - Attachment is obsolete: true

Updated

13 years ago
Depends on: 329034

Comment 8

13 years ago
Created attachment 214782 [details] [diff] [review]
This component implements nsIAutoCompleteSearch for items

- 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.
Assignee: mostafah → paul.rouget
Attachment #213818 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Whiteboard: [incomplete patch in hand]
Target Milestone: --- → Sunbird 0.5
Target Milestone: Sunbird 0.5 → ---
Not going to make the 0.5 train.
Component: Sunbird Only → General
QA Contact: sunbird → general
Summary: autocomplete in event → Autocomplete in event dialog
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).
Assignee: paul.rouget → nobody
Status: ASSIGNED → NEW
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.
Flags: wanted-calendar0.9+
Keywords: helpwanted

Comment 12

10 years ago
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.

Assignee: nobody → paul.rouget

Comment 14

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

Comment 15

10 years ago
Created attachment 326372 [details] [diff] [review]
patch v2

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 ) ?
Attachment #214782 - Attachment is obsolete: true
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.
Attachment #326372 - Flags: review?(philipp)

Comment 17

10 years ago
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.
Attachment #326372 - Flags: review?(philipp) → review?(daniel.boelzle)
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.

Updated

10 years ago
Flags: blocking-calendar0.9?
Status: NEW → ASSIGNED
Keywords: helpwanted
Whiteboard: [incomplete patch in hand]
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.
Attachment #326372 - Flags: review?(daniel.boelzle) → review?(philipp)
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#

Comment 23

10 years ago
Created attachment 327799 [details] [diff] [review]
patch v2.1

Oops... XUL part of the patch was missing.
Attachment #326372 - Attachment is obsolete: true
Attachment #327799 - Flags: review?(philipp)
Attachment #326372 - Flags: review?(philipp)
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?

Comment 27

10 years ago
(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?

Comment 29

10 years ago
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.

Comment 31

10 years ago
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 ?

Updated

10 years ago
Flags: blocking-calendar0.9? → blocking-calendar0.9-
Depends on: 360648
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.
Attachment #327799 - Flags: review?(philipp) → review-

Updated

10 years ago
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar0.9-
Component: General → Dialogs
QA Contact: general → dialogs
Summary: Autocomplete in event dialog → Autocomplete in event/task dialog (e.g. title, location, url, ...)
Duplicate of this bug: 536930

Comment 34

8 years ago
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
Duplicate of this bug: 674154
Duplicate of this bug: 148419

Comment 37

7 years ago
Not working on this anymore.
Assignee: paul → nobody

Comment 38

7 years ago
Hopefully somebody else takes over...
Status: ASSIGNED → NEW

Comment 39

6 years ago
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.
Duplicate of this bug: 1040871

Comment 43

4 years ago
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?

Comment 44

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

Comment 45

3 years ago
(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?
You need to log in before you can comment on or make changes to this bug.