Printing Mails

[kaystrobach]

@nelius,
see above, i replaced the code with the patch, i needed to find a working diff for windows at first - as my current ide is completly setup to follow other coding giudelines and replaced prefixed spaces with tabs

PS1: I stripped of the comments. As i seems to be standard to not write comments in JS files in tine20
PS2: I was not allowed to add a patch file as attachment

Best regards
Kay

[Peterchen]

I Have seen the Patch in the Task.
Will look an build it on Monday in my Trunk Version or have you did it in the trunk direct?

[kaystrobach]

no it's not in the trunk, as nelius asked me to not commit things in tine20 trunk directly, but send patches ...
i attached the same file to the tracker
http://www.tine20.org/bugtracker/view.php?id=1278

[nelius]

@kay

seems we had a litte tiff... sorry. You can directly commit to trunk, no problem. Creating patches/svndiffs before committing was just a tip for self controlling.

so just go ahead and commit to trunk to get the fame for your contribution!

PS I: you don't need to strip comments! usefull comments about the current state are always a PLUS!
PS II: added diff and patch to allowed files in the forums

[kaystrobach]

@nelius

seems we had a litte tiff... sorry. You can directly commit to trunk, no problem. Creating patches/svndiffs before committing was just a tip for self controlling.

Ahhh ok - a classic missunderstanding - But it would be also ok, if there is only one person who commits to trunk and merges all the changes- that's why i used that way - no problem, i understand that, it's the same with the linux kernel.

My Workflow is as follows:
> checkout > create working copy > work on the copy > recheckout > check for other people changes > (merge checkout and working copy) > commit

Additionally i've seen, that Phil was added as maintainer for the printing problem, so it's ok to give him a hint. And let him do the rest. I hope using this.detailpanel is generic enough to get it working with other applications of tine20 too. (should work with additional css- as i would say after a short look in the code). I'm happy to see the changes in trunk.

so just go ahead and commit to trunk to get the fame for your contribution!

Oh, it's not the fame why i'm working on opensource products - it's the spirit, i learned from a nice community project called TYPO3 - Inspiring People to share

PS1: OK
PS2: Thanks

[ph_il]

hi kay,

i just made you developer in the bugtracker and assigned the printing task to you ... when you committed the changes to the trunk, you can resolve the task and set the target version and 'fixed in' version to beta 1 of mialena.

edit: bin gerade in elternzeit und komme nur wenig zum programmieren ...

[Balazs]

Hi

I am not satisfied with the printing options I can see at the moment.

To my mind the user need two options:

1. Print an email: This should directly open the system-printing-dialogue, ideally including a preview.
2. Print to .pdf / export as .pdf: This option should directly open the .pdf

I do not understand the option "print preview". Could you please explain the use-case for that? And why does it open in a new tab/window?

I will be on vacation for one week, but will continue to discuss here as soon as I am back.

Cheers,
Björn

[ph_il]

2. Print to .pdf / export as .pdf: This option should directly open the .pdf

perhaps we should open an extra task for that, because this is much more complex ...

I do not understand the option "print preview". Could you please explain the use-case for that? And why does it open in a new tab/window?

i think we can remove the preview button, too.

and one more suggestion: we should add the print button to the context menu as well.

[kaystrobach]

2. Print to .pdf / export as .pdf: This option should directly open the .pdf

perhaps we should open an extra task for that, because this is much more complex ...

agree

I do not understand the option "print preview". Could you please explain the use-case for that? And why does it open in a new tab/window?

i think we can remove the preview button, too.

Ok, it was just an idea. My users asked for a preview option - don't know why - i think they used it to copy the text with select all (?!), but they were satisfied with the way i implemented that. Perhaps the print dialogue should open automatically in the preview.

It's not added to the context menu, because the mail is printed directly from the preview panel at the bottom and not from the selection at the grid.
Otherwise the print panel must grab the data from the server before the printing dialogue appears. This will be scary to the user as the request takes a while - especially on slow connections

and one more suggestion: we should add the print button to the context menu as well.

Ok, what about multiselection - sounds great, but i see the timing problem - as described above.

Hope that helps to understand my way of implementing it.

[ph_il]

ah, i see. then forget about the ctx menu at the moment.

perhaps we can just group the buttons vertically (like the read/unread and mark buttons)?