On Nov 15, 2008, at 8:49 AM, Paul Lesniewski wrote: > On Sat, Nov 15, 2008 at 5:35 AM, Scott Haneda <talklists@xxxxxxxxxx> > wrote: >> On Nov 15, 2008, at 2:02 AM, Paul Lesniewski wrote: >>> On Fri, Nov 14, 2008 at 11:12 PM, Scott Haneda >>> <talklists@xxxxxxxxxx> wrote: >>>> On Nov 14, 2008, at 7:21 PM, Paul Lesniewski wrote: >>>> >>>>> Also, if you can please report the style name for the table issue >>>>> you >>>>> identified (and even the fix if you find it), I will put the fix >>>>> into >>>>> the default skins. >>>> >>>> >>>> <td class="col_date" >>> >>> Why col_date? The whole table is what isn't stretched out, right? >> >> I thought you wanted me to report the name of the css class I could >> not find referenced in any css files. I am no longer trying to >> resolve the issue of a table not fitting into the correct width, >> which >> is easily solved by setting the second inner table to 100% the same >> as >> the outer table. > > You didn't specify that you found a fix for the problem you first > reported. If you can indicate where you made this change, I'd like to > commit it to SVN. Please do tell. I think it is premature now that you have explained a few things to me. Rather than me supplying patches willy nilly here and there, I want to get a better grasp of what is going on with the code and the theme systems. I can provide much better patches, and patches that do more and take less of your time in code review, if I take the time to learn a more complete idea of the entire system. >> Ay any rate, eventually, if this is to remain as a table, I would >> need >> access to every td in every table. I think I can manage this with >> the >> new template based theme system, it looks a lot like phpBB, which I >> have hacked around in a good deal. > > I think ultimately the idea was to leave the simple table layout and > allow skin developers to go table-less if they felt like it. But I'd > be interested to hear if you have another proposal for the basic > default template. To table or not to table. I have been thinking about this in the background a bit. The table layout provides a logical way of viewing web based email. It fails on a few fronts, mainly in that the refresh parameter must be set for the left frame. I think still having that is a good idea, but rather then meta refresh, using a little javascript in that area may give a better user experience. It may not be worth it for the fact it can fail if you do not want to use JS. Certainly, there are many actions users perform in SM, that can be more intelligent about that refresh. Any action in the main window (child) certainly can send a refresh off to the left frame (child) giving it a much higher chance of being up to date. Then, you can simply not enable an auto-refresh, which saves some performance cycles to the server, as well as that blink of page redraw on the screen. The clock is another one, in that it is only as up to date as a refresh, and adding in the seconds parameter, is rather pointless, as it will always be out of date. There are plenty of preferences that set the time zone and offset, so that can easily be a real time clock. The main consideration for me with the left/right table issue, is design driven. If you want to make a truly well designed theme, the left and right frames should, in my opinion, be able to blend into each other. This could be tricky since the width of the left frame is variable. I do think, with some thought, a background image could be put into place, that seamlessly blends the two together, and no matter the left frame width, the users experience would be that the page is one cohesive unit. I will tackle this when I get there, but I just wanted to put it out there, as it is the first area I will look at once I get up to speed on the system. >> Ok, I can do that as well, that is a simple find and replace as long >> as I am careful. I think the new template/theme/skin system will >> make >> it a non issue anyway, as I should be able to rename anything I >> desire >> to whatever I desire, as soon as /css and the other little bits are >> compartmentalized into the template system. > > Well, but it makes A LOT of sense to keep a consistent list of > commonly used base styles. Forcing every skin developer to create a > whole slew of styles of their own is overkill and won't be very > inviting to more casual skin developers. Right, good point. And further, each css class, id etc, needs to be documented along with the name. A simple short one or two sentence description of what it controls, where it can be found and where it is in use, will go a long way. There is no way my brain can remember this as I go, so as I always do, I will be taking notes as I go for my own purposes. If these end up becoming useful, you can add them to the docs when I feel they are complete. Perhaps they could become part of a theme development guide that should one day exist. Thanks again. -- Scott ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
