Closed Bug 219589 Opened 21 years ago Closed 19 years ago

Calendar Extension for Thunderbird

Categories

(Calendar :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tim, Assigned: belhaire)

References

()

Details

Attachments

(5 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030906 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030906 Firebird/0.6.1+

I think Calendar should be aviable as an extension to Thunderbird since it makes
to me very good reason to manage my calendar with my e-mails.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
With thunderbird-0.2 on linux ( GTK2 and XFT ) I managed to install and use the
Aug 11th calendar XPI for nightlies. What did you try that didn't work?
Installing the build from august the 4th runs fine. But when starting with
thunderbird.exe --callendar it's broken. I have made a screenshot here:

http://discworld.free-bsd.org/~tim/cal.png
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I began to work on it.
Assignee: mostafah → belhaire
Status: ASSIGNED → NEW
Patch of current CVS hierarchy without the new files.
The new files are in other attachement.
Attached file The newfiles (JS+XUL+PNG) (obsolete) —
The files is a tar archive (newfiles.tar) and includes all the newfiles for the
1st proposed modification to support Thunderbird.
Attached patch Patch with modifications to support Thunderbird (obsolete) — — Splinter Review
Patch of current CVS hierarchy without the new files.
The new files are in following attachment.
Attachment #133174 - Attachment is obsolete: true
The files is a tar archive (newfiles.tar) and includes all the newfiles for the

above modification to support Thunderbird.
Attachment #133175 - Attachment is obsolete: true
Attachment #134966 - Flags: first-review?(mostafah)
Attachment #134967 - Flags: first-review?(mostafah)
Comment on attachment 134967 [details]
tar archive with the newfiles (JS+XUL+PNG)

Checked this patch into cvs.
Note: I had to shorten some filenames. The reason being that Mac doesn't
support long filenames.
Change:
calendarElements.xml -> calElements.xml
calendarExtensionOverlay.js -> calExtOverlay.js
calendarExtensionOverlay.xul -> calExtOverlay.xul
Attachment #134967 - Flags: first-review?(mostafah) → first-review+
Comment on attachment 134966 [details] [diff] [review]
Patch with modifications to support Thunderbird

From the patch:
---------------------
+//I can't what this function is used for launchPreferences() exist in the
file.
 function openPreferences()
---------------------
The answer is that this is a function used by sunbird ( standalone app ) :
http://lxr.mozilla.org/mozilla/source/calendar/sunbird/base/content/menuOverlay
.xul#174
Attached patch Shrunken patch based on previous one (obsolete) — — Splinter Review
I've committed parts of the previous patch into CVS. What remains needs more
attention so I've prepared this new patch for the remainder.

Minor modifications were made to the previous patch before checkin which
follows:
-I changed the line
if( applicationName =="Mozilla" )
to
if( applicationName =="Mozilla" || applicationName=="Firebird" )
for Firebird support.

-I changed the about content from about.html to about.xul so it gets an OK
button
-Some whitespace adjustments were made.
-Changes to lang packs had been made on different lines moving them out of
synch. I readjusted those.
Attachment #134966 - Attachment is obsolete: true
Attachment #135002 - Flags: first-review?(mostafah)
Comment on attachment 134966 [details] [diff] [review]
Patch with modifications to support Thunderbird

patch is obsolete. Removing review request.
Attachment #134966 - Flags: first-review?(mostafah)
Attached patch More shrunken patch — — Splinter Review
Again, parts of the previous patch have been reviewed and checked in.
This patch will deal with the rest.
Attachment #135002 - Attachment is obsolete: true
Attachment #135002 - Flags: first-review?(mostafah) → first-review?
Attachment #135002 - Flags: first-review?
Comment on attachment 135317 [details] [diff] [review]
More shrunken patch

Eric:
- With the new printDialog.js and printDialog.xul, when I try to print in
Mozilla 1.4 it crashes. This is the error:
Trying to position a sizeless window; caller should have called sizeToContent()
or sizeTo(). See bug 75649.

-Was there any specific reason for moving some of the calendar.xul content into
calendarElements.xul? It is an overlay that is not used elsewhere.

-The calendarElements.xul file has duplicated code from calendar.xul. Example:
the calendar-deck element

-In calendarOverlay.xul I have to set the position to "6" for it to show up in
the right place. Would it work for thunderbird if it is set to "6" not "2"?

-Can we just remove the tools menu that is supposed to provide a way to launch
browser/mail/JSconsole from calendar? It doesn't look like the correct way of
doing it.
Mostafa: Responses on prev
> - With the new printDialog.js and printDialog.xul, when I try to print in
> Mozilla 1.4 it crashes. This is the error:
> Trying to position a sizeless window; caller should have called sizeToContent()
> or sizeTo(). See bug 75649.
I don't have this problem with Mozilla 1.5 on windows.

>-Was there any specific reason for moving some of the calendar.xul content into
> calendarElements.xul? It is an overlay that is not used elsewhere.
>-The calendarElements.xul file has duplicated code from calendar.xul. Example:
>the calendar-deck element
I did this when I considered having a calendar.xul per application. But this
solution can not be applied because calendar.xul is a specific name called in
some places with "chrome://calendar/content/". The file calendar.xul, I provided
with the patch is wrong. You can keep the original calendar.xul and not include
calendarElements.xul in CVS (we need to modify jar.nm to accomodate this
modification)

>-In calendarOverlay.xul I have to set the position to "6" for it to show up in
>the right place. Would it work for thunderbird if it is set to "6" not "2"?
Sorry this code is not directly connected with this bug. It just that the
position is not correct here and I tried to correct it. I think that the
original code is not correct anymore as the calendar number (7) as changed a
long time ago. There should not be any problem for thunderbird to have 6. 

>-Can we just remove the tools menu that is supposed to provide a way to launch
>browser/mail/JSconsole from calendar? It doesn't look like the correct way of
> doing it.
Yes you can remove the tools menu (but I find it useful). We need to provide a
way to launch browser/mail because tasksOverlay.xul is no more use. This is
important specially if all other windows than calendar are closed. What do you
propose ? Buttons in the toolbar ? in the statusbar ?
Attached patch patch of current calendar.xul — — Splinter Review
This patch should be applied to current CVS calendar.xul (original).
It does not call the calendarElements.xul overlay which should be removed from
the hierarchy.
mostafa:
content/contents.rdf does not completely reflect the filename changes you made
from calendarExtensionOverlay.xul to calExtOverlay.xul
Ok.
- calElement.xul has been removed from the tree and from jar.mn
- contents.rdf has been fixed
- First line of attachment #135386 [details] [diff] [review] has been checked in.( The next two lines seem
to be related to application support which should be dealt with elsewhere.See below)

Remaining issues:
- We should fix the crash problem with the new printdialog on 1.4 because some
consider 1.4 as the latest stable release. Eric: Does that change actually
effect thunderbird support? If not we can open a seperate bug for it.
- We'll deal with application support seperately. A good solution needs more
thought,investigation and testing. I had problems with the suggested
implementation and since it effects other applications it might confuse their
developers with issues rising from the way we launch them.
> - The next two lines seem to be related to application support which should be
> dealt with elsewhere.See below
globalOverlay.js is necessary to allow to use the quit command in the calendar
window (with Firebird only if I remember well)
applicationUtil.js includes the function launchBrowser( UrlToGoTo ) which should
when you click on the visit URL button in event dialog. You can may be suppress
its call in calendar.xul but not suppress the file itself.

Remaining issues:
>- We should fix the crash problem with the new printdialog on 1.4 because some
>consider 1.4 as the latest stable release. Eric: Does that change actually
>effect thunderbird support? If not we can open a seperate bug for it.
The changes are necessary to provide the print support in Thunderbird.
>- We'll deal with application support seperately. A good solution needs more
>thought,investigation and testing. I had problems with the suggested
>implementation and since it effects other applications it might confuse their
>developers with issues rising from the way we launch them.
I don't see your point but I agree to report those modifications after more
testings.
>- We should fix the crash problem with the new printdialog on 1.4 because some
>consider 1.4 as the latest stable release. Eric: Does that change actually
>effect thunderbird support? If not we can open a seperate bug for it.
No crash problem in Mozilla 1.4.1 on windows here.
Then:
- attachment #135386 [details] [diff] [review] completely checked in.
- printdialog changes checked in.
- If working on application support, consider the possibility of using
tasksOverlay.js. It's included everywhere and provides toNavigator() and
toJavascriptConsole().
I've confirmed the following change for bug 206803.
http://bugzilla.mozilla.org/attachment.cgi?id=136955&action=view

I don't see any reason for this happening but please let me know if this change
affects thunderbird support in anyway.
Mostafa http://bugzilla.mozilla.org/show_bug.cgi?id=219589#c21 :
calendarOverlay.xul should not be use when running in thunderbird. So it should
not be any problem with this modification.
Current CVS does not run on Thunderbird (at least 0.4) : some menu entries has
been suppressed from the patch I submitted here, but some related stuff remains
in calendar.js (reference to 'tasksMenuNavigator'). The following patch suppress
this reference. 
This patch also includes :
- a reverse back to the function displayCalendarVersion() to open the about dialog.
- a reverse back to the original id for the Tools Menu ("tasksMenu" instead of
"toolsMenu"). The Tools name is more logical, but tasksMenu is the name used in
Mozilla Application Suite and I am trying to work to the Application Support and
I am working on a way to restore the previous calendar look with
tasksOverlay.xul support. This original name is needed for overlays.
See previous comment for details
Attachment #137260 - Flags: first-review?(mostafah)
Comment on attachment 137260 [details] [diff] [review]
patch of calendar.js and menuOverlay.js

Checked in the patch with one exception:

I didn't switch "toolsMenu" to "tasksMenu" because if you include
tasksOverlay.xul you will get other applications added to the "tools" menu
along with "import","export",etc. It's better to keep toolsMenu as it is and
add a seperate tasksMenu if we need it.
Attachment #137260 - Flags: first-review?(mostafah) → first-review+
Mostafa : I don't agree with you concerning :
> I didn't switch "toolsMenu" to "tasksMenu" 
"tasksMenu" which has been used until
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=menuOverlay.xul&branch=&root=/cvsroot&subdir=mozilla/calendar/resources/content&command=DIFF_FRAMESET&rev1=1.50&rev2=1.51
> because if you include tasksOverlay.xul you will get other applications added to 
>the "tools" menu along with "import","export",etc. It's better to keep
toolsMenu >as it is and add a seperate tasksMenu if we need it.
The other applications are added in the windowMenu in Mozilla Application Suite
(it could be in toolsMenu in Firebird). You can have a look to
http://pagesperso.laposte.net/ericb/ is you want to test the modifications.
You are absolutely right Eric, applications go under windowMenu. I got confused
there.
So let's start with why I changed tasksMenu to toolsMenu:
The tasksMenu.label was set to "tasks" in menuOverlay.dtd. This I thought would
cause confusion because many people refer to "TODO" events as tasks and btw,
tasksMenu.label was "Tools" in the first place so people were used to finding
import/export under "Tools".
To fix this I had two solutions:
-Either to rename all tasksMenu.label entries in all dtd files ( which some had
already been translated ) from "tasks" to "tools".
-To use toolsMenu instead of tasksMenu to get that name change with a simple
change.( Note that toolsMenu was not being used in CVS code and I thought this
would be safe)
I chose the second way which I admit was a mistake.

Now if you agree with the problem I mentioned, is it ok if we change the label
for tasksMenu to "Tools", the label for toolsMenu to something else ( e.g.
"OtherApps" or whatever appropriate ) and use tasksMenu instead of toolsMenu again?

In other words, I suggest the following layout for the menus:
File Edit View Go Tools <OtherApps> Help

Tools comes from tasksMenu and OtherApps comes from toolsMenu.

Let me know if you agree so I will come up with a patch.
Mostafa: I agree with the problem you mentioned. But I don't really understand
some parts of your comment :
In the patch I provided, I keep the label for taskMenu as "Tools" through
"&toolsMenu.label;" and there is no other toolsMenu defined. I only changed the
menu id. The menu you call toolsMenu is in fact call windowMenu in Mozilla
Application Suite (which is confusing).

In other words, I agree with the layout you suggest:
File Edit View Go Tools <OtherApps> Help

BUT, Tools comes from tasksMenu and OtherApps comes from *windowMenu*.

My patch should prepare to provide us exactly this (it was in fact its goal).
Currently, the windowMenu is provided by the separated small addon I posted on
my WEB site, because it is only compatible with the suite and it is not with
Thunderbird. If you think that all this is correct, I will try to provide an
equivalent addon for Thunderbird.
>In the patch I provided, I keep the label for taskMenu as "Tools" through
>"&toolsMenu.label;"

I overlooked this too.Sorry.
Changed "toolsMenu" to "tasksMenu" for menuOverlay.xul in cvs.

Also the addon is great for now. If you provide one for thunderbird it would be
even better. I still have hope that all this would be resolved in bug 222049.
Eric: Can you also verify that the patch for bug 227675 works for thunderbird?
Mostafa: the patch for bug 227675 works works perfectly for thunderbird.
I am not sure where it belongs, but I will post it here: even with the latest
Calendar extension (2004040813) for Tbird, it is not possible to start Tbird
while a Calendar window is open. Steps to reproduce:
1. Shutdown Tbird (if running)
2. Execute "thunderbird.exe -calendar"
3. Try to run Thunderbird. It won't start.

The reason is that Tbird (unlike the mail client in Mozilla Suite) does not
support multiple instances of itself. While I like that (I see no reason for me
to have more than one main mail windows and it is very confusing to the average
user), I think that the above problem is important. If a Windows user uses
Calendar every day, he may want to have it started with OS startup (by placing a
"thunderbird.exe -calendar" shortcut on Programs->Startup menu). No chance to
start Tbird then :-(
Depends on: 244869
No longer depends on: 244869
Depends on: 245208
> If a Windows user uses
> Calendar every day, he may want to have it started with OS startup (by placing a
> "thunderbird.exe -calendar" shortcut on Programs->Startup menu). No chance to
> start Tbird then :-(

This is addressed in bug 246115
New problem with thunderbird 0.7: 

Error: Components.classes['@mozilla.org/profile/manager;1'] has no properties
Source file: chrome://calendar/content/calendarManager.js    Line: 716

It seems the profile manager is not present in tb 0.7 or has it just been renamed?
(In reply to comment #34)
> New problem with thunderbird 0.7: 
> 
> Error: Components.classes['@mozilla.org/profile/manager;1'] has no properties
> Source file: chrome://calendar/content/calendarManager.js    Line: 716
> 
Fix:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcalendar%2Fresources&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-06-18+08%3A50&maxdate=2004-06-18+09%3A00&cvsroot=%2Fcvsroot

Build 2004-06-18 supports TB 0.7 again.
Calendar20040618 on Thunderbird 0.7 on W2k crashes for me on alarms, either
during session or trying to start a new session with an alarm pending.  
TB138013Y (Unfortunately talkback or fast find doesn't seem to be working for
recent thunderbird crashes.)
(In reply to comment #36)
> Calendar20040618 on Thunderbird 0.7 on W2k crashes for me on alarms, either
> during session or trying to start a new session with an alarm pending.  
> TB138013Y (Unfortunately talkback or fast find doesn't seem to be working for
> recent thunderbird crashes.)

Fixed:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcalendar%2Flibxpical&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-06-18+14%3A50&maxdate=2004-06-18+14%3A55&cvsroot=%2Fcvsroot
User-Agent: Mozilla Thunderbird version 0.7.2 20040707
Build Identifier: Mozilla Thunderbird version 0.7.2 20040707
System Specs:  Windows 98SE, PIII 800Mhz Processor, 384 MB SDRAM 20 GB HD

I installed the Calendar 20040622 extension on Thunderbird 0.7.2.  I cannot
Print the Calendar.  I Searched, and this was the only Bug I came up with. 

Reproducible: Always

Steps to Reproduce:
1.  Added two entries to Calendar
2.  Tried to print, but the "Print" tab is inactive
3.
Some file should have been renamed and moved in Thunderbird. I added a ref to
the file printUtils to restore the missing print settings definition leading to
the errors described in http://bugzilla.mozilla.org/show_bug.cgi?id=219589#c38.

I did not test the patch in Sunbird and Firebird and Mozilla Suite, only
Thunderbird 0.7.1 (in WindowsXP).
Attachment #154557 - Flags: first-review?(mostafah)
Attachment #154557 - Attachment description: add a ref to printUtils.js of Thunderbird hierarchy → add a ref to printUtils.js of Thunderbird hierarchy ( checked in )
Attachment #154557 - Flags: first-review?(mostafah) → first-review+
Latest xpi
http://pagesperso.laposte.net/ericb/calendar-TB-MozillaSuite-031107.xpi didn't
work for me on Thunderbird 0.7.2 (20040707) zip build. After installation and TB
restarting, I get the following message:
"The procedure entry point ??1nsCString@@UAE@xz could not be located in the
dynamic link library xpcom.dll" 
There is a blank zone under the status bar and, of course, Calendar option is
absent.
(In reply to comment #40)
I have version 0.8+.  The install on Thunderbird 0.7.3 works ok (for birthdays
and stuff, I'm not a heavy calendar user).  When I installed it on Firefox
0.9.3, the calendar appears and is working, but the extension manager still has
"This item will be installed after you restart Firefox".  5 other extensions
have the same problem.

What I want is a SHARED calendar.  When installing, it should check for an
existing calendar install from another 'zilla component and merge pointers.  I
would expect to have the same exact calendar data show up if I click it from
Firefox, Thunderbird, Mozilla suite, etc.  Instead, I have to program duplicate
data into each one.  It would also be cool if I could put a calendar on a
website and have it not writeable from anyone but me, but I could post events
and stuff for my RollingThunderChapter1PA.com website.

rob
(In reply to comment #41)
I agree, Calendar data must be shared!
I can't find a reason for this bug, and its dependency (bug 245208) to remain
open.  The calendar Roadmap lists 'Complete Integration with Thunderbird' as
completed (strike-through text), and I have installed Calendar in TB with no
problem.  Uninstall also was successful.  In response to the 'shared calendar'
requests (comment 41 and comment 42), that is covered in bug 256181.
QA Contact: gurganbl → general
This bug has been fixed for a long time.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: