 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
10 messages in net.sourceforge.lists.courier-sqwebmailRe: [sqwebmail] [PATCH] Simpler chang...| From | Sent On | Attachments |
|---|---|---|
| Marcin Semeniuk | May 23, 2006 1:02 am |  .patch |
| Brian Candler | May 24, 2006 12:44 am | |
| Mark Constable | May 24, 2006 3:14 am | |
| Pawel Tecza | May 24, 2006 7:29 am | |
| Brian Candler | May 24, 2006 8:21 am | |
| Pawel Tecza | May 29, 2006 3:48 am | |
| Sam Varshavchik | May 29, 2006 6:19 am | |
| Brian Candler | May 29, 2006 1:42 pm | |
| Pawel Tecza | May 29, 2006 11:15 pm | |
| Marcin Semeniuk | Jun 13, 2006 1:28 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [sqwebmail] [PATCH] Simpler changing of textarea for singature editing | Actions... |
|---|---|---|
| From: | Brian Candler (B.Ca...@pobox.com) | |
| Date: | May 24, 2006 8:21:59 am | |
| List: | net.sourceforge.lists.courier-sqwebmail | |
On Wed, May 24, 2006 at 04:29:51PM +0200, Pawel Tecza wrote:
It's a very good idea. I like it :) I also propose to add a new environment variable (for example SQWEBMAIL_CSSFILE), for dynamic setting of CSS file.
I think better would be to insert a cascaded stylesheet: e.g.
<link rel="stylesheet" type="text/css" href="[#SQWEBMAILCSS#]" /> <link rel="stylesheet" type="text/css" href="[#SQWEBMAILCSSUSER#]" />
(where SQWEBMAILCSSUSER could be set from an environment variable, with a sensible default)
In this case, the user's CSS file need only list those items which they want to override; and if the base CSS file is updated later, then the new items in the base file will still take effect.
In my opinion it can be a good complement for the SQWEBMAIL_TEMPLATEDIR variable. Now if I want to have the same templates, but with the different styles (for example with default, bigger and the biggest fonts), I have to multiply templates.
I worked around this using mod_rewrite in Apache; you can rewrite /images/sqwebmail.css to fetch an arbitary file based on a database lookup. But your environment feature makes this easier to implement in simple virtual hosting setups.
The main issue would be with the rounded corner boxes, but personally I wouldn't mind if they were lost.
I propose to create the template variables for setting a look of box corners, for example BOX_BEGIN and BOX_END. If you don't like the rounded corner boxes, you could set
[#$BOX_BEGIN=<table class="box"><tr><td>#] [#$BOX_END=</td></tr></table>#]
Well, if sqwebmail can finally divorce templates from language strings, then you could just have one template set with corner boxes, and one template set without. I want to get to the point where users can perform all the customisation they need without touching the HTML templates at all. This is so that new versions of sqwebmail (necessarily containing new HTML templates if there are new features) can be installed, without breaking the look of the users' sites or their customisations.
As for corner boxes: what I really meant was, if the user has changed the colour of their index from blue to green (say), then they will also want to change the colour of the box corners to green as well.
I've worked around this using more mod_rewrite tricks to allow each customer to have their own .png's which override the standard sqwebmail ones, but that's a nasty trick.
I agree with you, in that installing a different set of HTML templates without corners avoids this problem. However, every time you upgrade to a new version of sqwebmail, you'd have to make the corresponding set of changes to the new version's templates.
If sqwebmail were to ship with two sets of HTML templates - one with corners, one without - then this wouldn't be a problem. Taking language strings out of the HTML then avoids the N x M explosion of templates.
Regards,
Brian.