On 24-okt-2006, at 14:33, Ryan Rittenhouse wrote:
I got a seperate pane this way but it had the RC start page with
"SERVICE CURRENTLY NOT AVAILABLE!".
Oops, sorry.
I forgot to add skins/default/templates/previewmessage.html to the
patch:
<roundcube:object name="messageHeaders" class="headers-table"
cellspacing="0" cellpadding="2" addicon="/images/icons/plus.gif"
summary="Message headers" />
<roundcube:object name="messageAttachments" id="attachment-list" />
<roundcube:object name="blockedObjects" id="remote-objects-message" />
<pre><roundcube:object name="messageBody" id="messagebody" showImages="true" /></pre>
I think RoundCube could more gracefully tell the user that it's just
a simple missing template file.
Robin
I've stuff the template file in and the only way I can get the preview pane to show up is to comment out the requirement for this.env.enable_preview in the if statement. It doesnt appear to be getting set right. It does, however follow the user preference (this.env.preview) just fine. At any rate, minor bug. Looks great! Nice Job! :)
-Ryan
Robin Elfrink wrote:
On 24-okt-2006, at 14:33, Ryan Rittenhouse wrote:
I got a seperate pane this way but it had the RC start page with "SERVICE CURRENTLY NOT AVAILABLE!".
Oops, sorry.
I forgot to add skins/default/templates/previewmessage.html to the patch:
<roundcube:object name="messageHeaders" class="headers-table" cellspacing="0" cellpadding="2" addicon="/images/icons/plus.gif" summary="Message headers" /> <roundcube:object name="messageAttachments" id="attachment-list" /> <roundcube:object name="blockedObjects" id="remote-objects-message" />
<pre><roundcube:object name="messageBody" id="messagebody" showImages="true" /></pre>
I think RoundCube could more gracefully tell the user that it's just a simple missing template file.
Robin
Ryan Rittenhouse wrote:
I've stuff the template file in and the only way I can get the preview pane to show up is to comment out the requirement for this.env.enable_preview in the if statement. It doesnt appear to be getting set right. It does, however follow the user preference (this.env.preview) just fine. At any rate, minor bug. Looks great! Nice Job! :)
-Ryan
Just wanted to confirm this. I experienced the exact same thing on a fresh checkout from SVN. I could not get the preview pane to appear until I edited the app.js as mentioned above. After doing that it does however work well, very nice work. I hope this will be integrated into roundcube soon so we dont need to fiddle around with patches.
-- R
same thing here - i cant get the preview to work unless i edit the app.js in the mentioned way ;/
Otherwise this works nicely - only the preview pane doesnt get cleared once i click some other folder, just clicking on some message will update the preview
Nice work so far! I still do not like the fact that the core script (app.js) decides about the size of the preview pane. I'd like to strictly separate the visual appearance from the core functionality. In your patch the user can decide whether he/she wants to see the preview pane or not. This makes it even more complicated to separate functionality and skins.
I worked on the preview pane as well and here's my suggestion to implement it. The preview pane is defined by the skin template and not configurable. If you want to make the pane resizable, it should be implemented in the skin template (I didn't have the time to do that yet). There's no user configuration available in my patch which means that the admin decides which skin is used and all users are faced with the preview pane or not. There are two solutions to get around this: Either the user can choose from several skins (a nice feature anyway) or (that's something I always had in my mind) the template parser can handle conditional tags like <roundcube:if condition="$config.preview_pane"> .. roundcube:else .. roundcube:endif
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
Thanks. Thomas
..and of course I forgot to add the new template to the diff file. Please also save the attached file in /skins/default/templates/messagepreview.html
Regards, Thomas
2006/11/9, Thomas Bruederli roundcube@gmail.com:
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
Thomas Bruederli wrote:
Nice work so far!
Thank you!
I still do not like the fact that the core script (app.js) decides about the size of the preview pane. I'd like to strictly separate the
I agree. But I couldn't get that to work in the timeframe that I needed the preview pane in.
visual appearance from the core functionality. In your patch the user can decide whether he/she wants to see the preview pane or not. This makes it even more complicated to separate functionality and skins.
Complicated maybe, but that's what I need. When I started using RoundCube for our webmail, some of my users requested a preview pane. When I got that, some requested that I immediately remove it. It's hard to please everyone.
(Actually, being a commercially challenged technical person I'd love to tell half of them to piss off, but that would probably have severe consequences for my job).
[...]
Either the user can choose from several skins (a nice feature anyway)
That would be nice indeed.
or (that's something I always had in my mind) the template parser can handle conditional tags like <roundcube:if condition="$config.preview_pane"> .. roundcube:else .. roundcube:endif
That's something I've been thinking about, as well. Is it hard to do? If you have some pointers for me I can spend some time on this.
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
Well, it works. What else can I say. I think I like the fact that the preview pane is _always_ there, regardless if there's an email being displayed. Makes it easier for the layout stuff. I don't even remember why I chose to do it differently.
Robin
Robin Elfrink wrote:
Thomas Bruederli wrote:
Nice work so far!
Thank you!
I still do not like the fact that the core script (app.js) decides about the size of the preview pane. I'd like to strictly separate the
I agree. But I couldn't get that to work in the timeframe that I needed the preview pane in.
visual appearance from the core functionality. In your patch the user can decide whether he/she wants to see the preview pane or not. This makes it even more complicated to separate functionality and skins.
Complicated maybe, but that's what I need. When I started using RoundCube for our webmail, some of my users requested a preview pane. When I got that, some requested that I immediately remove it. It's hard to please everyone.
(Actually, being a commercially challenged technical person I'd love to tell half of them to piss off, but that would probably have severe consequences for my job).
[...]
Either the user can choose from several skins (a nice feature anyway)
That would be nice indeed.
or (that's something I always had in my mind) the template parser can handle conditional tags like <roundcube:if condition="$config.preview_pane"> .. roundcube:else .. roundcube:endif
That's something I've been thinking about, as well. Is it hard to do? If you have some pointers for me I can spend some time on this.
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
Well, it works. What else can I say. I think I like the fact that the preview pane is _always_ there, regardless if there's an email being displayed. Makes it easier for the layout stuff. I don't even remember why I chose to do it differently.
Robin
I mean not to sound like an ass, so if I do, I apologize. If you want to include the conditional functionality (<roundcube:if /> <roundcube:else >) then I might suggest looking at what SMARTY has already put in place. They're dedicated to the template system, and it works well. I'm not saying convert to SMARTY, but it is an option if you so choose. But if you wanted to add the functionality, SMARTY already has it in place and it works very well. So look at how it's done elsewhere, and bring it over ;)
Just my $0.02
~Brett
I just applied this to our test branch here and I must say I realy like this good job guys.
Brett Patterson wrote:
Robin Elfrink wrote:
Thomas Bruederli wrote:
Nice work so far!
Thank you!
I still do not like the fact that the core script (app.js) decides about the size of the preview pane. I'd like to strictly separate the
I agree. But I couldn't get that to work in the timeframe that I needed the preview pane in.
visual appearance from the core functionality. In your patch the user can decide whether he/she wants to see the preview pane or not. This makes it even more complicated to separate functionality and skins.
Complicated maybe, but that's what I need. When I started using RoundCube for our webmail, some of my users requested a preview pane. When I got that, some requested that I immediately remove it. It's hard to please everyone.
(Actually, being a commercially challenged technical person I'd love to tell half of them to piss off, but that would probably have severe consequences for my job).
[...]
Either the user can choose from several skins (a nice feature anyway)
That would be nice indeed.
or (that's something I always had in my mind) the template parser can handle conditional tags like <roundcube:if condition="$config.preview_pane"> .. roundcube:else .. roundcube:endif
That's something I've been thinking about, as well. Is it hard to do? If you have some pointers for me I can spend some time on this.
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
Well, it works. What else can I say. I think I like the fact that the preview pane is _always_ there, regardless if there's an email being displayed. Makes it easier for the layout stuff. I don't even remember why I chose to do it differently.
Robin
I mean not to sound like an ass, so if I do, I apologize. If you want to include the conditional functionality (<roundcube:if /> <roundcube:else >) then I might suggest looking at what SMARTY has already put in place. They're dedicated to the template system, and it works well. I'm not saying convert to SMARTY, but it is an option if you so choose. But if you wanted to add the functionality, SMARTY already has it in place and it works very well. So look at how it's done elsewhere, and bring it over ;)
Just my $0.02
~Brett
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete this material from any computer.
In accordance with industry regulations, all messages are retained and are subject to monitoring.
This message has been scanned for viruses and dangerous content and is believed to be clean.
Securities offered through Cantella & Co., Inc., Member NASD/SIPC. Home Office: 2 Oliver Street, 11th Floor, Boston, MA 02109 Telephone: (617)521-8630
I just tried out this patch on SVN 364 - and I think it looks great. One minor annoyance is that it previews the contents of the previously selected email when you change folders, select multiple emails etc.
I don't know how hard it would be to update the preview pane when an email is no longer 'in focus', but I think it would be a good idea if possible.
Great work so far though - I really like roundcube :)
Nathan.
On Fri, 10 Nov 2006 16:44:11 -0500, Chris Richardson techlist@cantella.com wrote:
I just applied this to our test branch here and I must say I realy like this good job guys.
Brett Patterson wrote:
Robin Elfrink wrote:
I mean not to sound like an ass, so if I do, I apologize. If you want to include the conditional functionality (<roundcube:if /> <roundcube:else >) then I might suggest looking at what SMARTY has already put in place. They're dedicated to the template system, and it works well. I'm not saying convert to SMARTY, but it is an option if you so choose. But if you wanted to add the functionality, SMARTY already has it in place and it works very well. So look at how it's done elsewhere, and bring it over ;)
Just my $0.02
~Brett
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete this material from any computer.
In accordance with industry regulations, all messages are retained and are subject to monitoring.
This message has been scanned for viruses and dangerous content and is believed to be clean.
Securities offered through Cantella & Co., Inc., Member NASD/SIPC. Home Office: 2 Oliver Street, 11th Floor, Boston, MA 02109 Telephone: (617)521-8630
Thomas Bruederli wrote:
..and of course I forgot to add the new template to the diff file. Please also save the attached file in /skins/default/templates/messagepreview.html
Regards, Thomas
2006/11/9, Thomas Bruederli roundcube@gmail.com:
Please try out the attached patch on the latest rev. 364 and write your oppinions about the one or the other approach.
I am trying it on on svn367 and it looks great. Couple differences I
noticed that in the pane from Robin when images are sent in an email the
preview pane doesn't display them or give you the option to display
them, the other is that you can enable or disable the preview pane.
Obviously the image thing is a problem and I would much rather use the
skin approach based on that criteria alone. However it would be nice if
the preview pane was more user configurable. For instance
enabling/disabling it from the main window and being able to resize it,
I think would make it more user friendly. Just want to say I am new to
roundcube and I really like it. Appreciate all the work. Thanks
Geoff
Has anyone noticed this while composing?
See the end of the first script tag split by the second. I can't quite figure out the cause however.
Matt
<script type="text/javascript"> <!-- var cc_field = document.form._cc; if (cc_field && cc_field.value!='') rcmail_toggle_display('compose-cc'); //--> </scrip<script type="text/javascript"> <!-- if (window.call_init) call_init('rcmail'); var googie = new GoogieSpell('skins/default/images/googiespell/','./?_task=mail&_action=spell&lang='); googie.lang_chck_spell = "Check spelling"; googie.lang_rsm_edt = "Resume editing"; googie.lang_close = "Close"; googie.lang_revert = "Revert to"; googie.lang_no_error_found = "No spelling errors found"; googie.setCurrentLanguage('en'); googie.decorateTextarea('compose-body'); rcmail.set_env('spellcheck', googie); //--> </script>
t>
I think it is corrected in SVN 357
Matt wrote:
Has anyone noticed this while composing?
See the end of the first script tag split by the second. I can't quite figure out the cause however.
Matt
<script type="text/javascript"> <!-- var cc_field = document.form._cc; if (cc_field && cc_field.value!='') rcmail_toggle_display('compose-cc'); //--> </scrip<script type="text/javascript"> <!-- if (window.call_init) call_init('rcmail'); var googie = new GoogieSpell('skins/default/images/googiespell/','./?_task=mail&_action=spell&lang='); googie.lang_chck_spell = "Check spelling"; googie.lang_rsm_edt = "Resume editing"; googie.lang_close = "Close"; googie.lang_revert = "Revert to"; googie.lang_no_error_found = "No spelling errors found"; googie.setCurrentLanguage('en'); googie.decorateTextarea('compose-body'); rcmail.set_env('spellcheck', googie); //--> </script>
t>
-
andy -
Brett Patterson -
Chris Richardson -
Geoff Hasz -
Matt -
Nathan Coad -
Oleg Albegov -
Robin Elfrink -
Roger 'Rocky' Vetterberg -
Ryan Rittenhouse -
Thomas Bruederli