On Nov 15, 2008, at 8:44 AM, Paul Lesniewski wrote: > On Sat, Nov 15, 2008 at 5:30 AM, Scott Haneda <talklists@xxxxxxxxxx> > wrote: >> On Nov 15, 2008, at 1:55 AM, Paul Lesniewski wrote: >>> On Fri, Nov 14, 2008 at 10:36 PM, Scott Haneda >>> <talklists@xxxxxxxxxx> wrote: >>>> On Nov 14, 2008, at 7:21 PM, Paul Lesniewski wrote: >>>> >>>>> You are welcome to play with the default (or default advanced) >>>>> skin in >>>>> 1.5.2 and change it to suit your needs (and share with the >>>>> community >>>>> please). Once 1.5.2 becomes more stable, the hope is that it >>>>> catches >>>>> on and [...] >>> You should start by looking at the code IMO, not making assumptions >>> based on the interface. The skin/template documentation isn't yet >>> written, but I'd start by reading the configuration file in the >>> templates/default directory. Then start fiddling with the layout >>> code >>> therein. >> >> There will be places in which I do that, and I did first look for >> docs. But in reality, for the question above, to look through the >> code, get familiar, and determine the answer to my question, is going >> to take a good deal of time. >> >> In cases like this, is it really a bad idea to ask the mailing list, >> and hope to get someone who implemented it to reply in a few >> sentences? > > Sure, it's fine, but you should at least look at the code first - > particularly the templates directory, since I already pointed you > there. FYI, that's ultimately the ONLY place a skin developer should > need to go to make a skin, since skins will be distributed as tarballs > that are unpackaged in that directory and then added using the > configuration tool, exactly like plugins are. You may have to also > look at the core, etc., to help massage the core to be more friendly > to skins, and we REALLY appreciate any help you offer in that area. Thanks, I agree. I just wanted to make sure that I can in fact ask questions here on the list. I know that I will have to dig into the code, that is just part of how this is going to have to work given the current state that this development version is in, and how the new templating system is going to work. Seems there is a little flux with all the files and methods, however, a good starting point is in place. There are going to be board conceptual things that I need pointers on, I just wanted to be sure could get broad conceptual answers back on the list. Like any other project I have worked on, be it CSS or real code work, getting a "get me up to speed" type of answer always helps *me* see the basic flow. Once I get the basic flow, I can then drill into the code and find specifics. I have always wondered about the state of themes and such in SM, and now I understand why it is the way it is. This is a much needed improvement. I am happy to help. Of course, this it outside my normal working job, and done in my spare time, but I am excited about the possibility, and have already started working on getting to know the code. I will post a clean thread with the direction I am taking this in for how I think it should look, just for the sake of community feedback. Even though this comment is a bit out of context of this thread, I am looking to take it in a semi-gmail looking way. I want clean, good looking, but never at the sacrifice of performance. >> I mean, I can take up a few minutes of someone's time, and move on to >> getting something more productive done, or I can wade through the >> code >> and get an answer in a few hours. >> >> If that is your suggestion, I will respect that, but in this case, I >> think it is a good time slow down with little gain to me to >> accomplish >> my goal, to built a nice skin/theme. > > I think it's better to take the time to understand the architecture > and intended design, especially if the goal is to help finish off the > template implementation in SM. Agree, and understood. >>>> So three different ways to deal with this, then in the distro I >>>> see / >>>> themes, /templates, /css >>> >>> I don't know to what extent if any the /css and /themes directories >>> are used any more, but I think the idea was to move away from >>> them, so >>> that most of the important stuff is in each skin (template) >>> directory. >> >> Ok, thanks, I will reply to this in your other email as well, since >> it >> is related. > > Oh, and FYI, the themes directory, beside being a hold-over from 1.4.x > is, for the time being, intended as a way to still allow skins to have > different color themes. Usually a skin has just one color theme, and > it might be the case that they in fact do in SM (I forget), but the > decision is not yet clear that a skin couldn't use the dynamic colors > from those files to allow users to change the color theme of their > skin/layout. We need to ultimately make that decision and either do > away with themes completely or make sure skins actually use the > colors. Yes, I am going to have to think about how I approach this. In large part, the system that SM is moving toward, is a lot like the php based forums. So you have some css files, but of course, there just had to be some php to do the work. I see no way around this. For example, you could not offer this, and just offer to allow people to adjust a css file, but then you have a rather rigid layout dictated by the output of SM. A good example would be that every email you read has minimal headers at the top of the email, and then the body copy. If for some reason, someone wanted to move that around, it could be done in CSS, but only with absolute positioning, which in my humble opinion, it is a bad way to do things. The way it is offered now, allows me to do what I need with CSS, and also, using a minimal amount of php, I can run repeat loops, and move other things around as needed. I like this, it is familiar to all other template driven projects, and makes sense. I think for the allowing the change of the color parts, there are a few approaches. The current way, would allow over rides based on a selection in your preferences. You could parse out the css colors, and change them, or swap in a new CSS file etc. Personally, I lean on letting the user simply adjust the CSS file code by hand, but that could be a barrier to some, and need more thought. Maybe the easiest way, is to take the approach of CSS based font size changing, where they simply allow a preference and you toggle a cookie value, and conditionally swap in directives based on the cookie value. Either way, I will strive to make it as flexible and simple on the user. Mainly, I wanted to put this out there, since another poster touched on this topic, and is from my interpretation, leaning on generating core code that is structured, and all edits happen in pure CSS. Wile that is possible, I think that is not as flexible a system as what would be best for moving forward. >>>> If you can point me to any docs on this, and how to understand the >>>> flow, that would be appreciated. Mainly, looking to see how to >>>> activate my own set of files in the list. >>> >>> One important thing to note is (see the default_advanced skin) that >>> skins can inherit from one another. That way, you can create a skin >>> where you only add a few files at a time, and any pages that are not >>> found in your skin are taken from whatever skin you inherit from. >> >> Ok, thanks for that info. I will be providing a complete and final >> solution though. > > That's much appreciated, but it is very much acceptable (and usually > expected) for a "complete" solution to inherit from at least the > default skin. You will probably have little reason to override files > such as non_breaking_space.tpl (or whatever it's called). Take a look > at the advanced template and see that it contains far fewer files than > the default one, yet I think it might be reasonably complete (well > maybe not totally). Ahh, ok, I see what you mean now. I will keep this in mind when I start getting into something that actually is worth showing back to you/everyone. >> I am not sure how well it plug-ins will degrade into >> the system, but I can toss in a few calendars and the like and see >> what happens. > > Plugins provide their own template files for any output they add to > the interface. They have their own template directories. If you > decide you'd like to provide your own template file for a plugin, you > can do so by putting it in a "plugins" directory in your skin pack - > copy the initial file from the plugin and change it within your skin > pack and yours will override what the plugin provides. The working > example I think might be the preview_pane plugin, which should have > template files in the default_advanced skin (although I'm not looking > at the code right now). Wow, ok, that is very cool. When looking at NutsMail, I see they were doing this in result, but they do so by modifying the core code. I am not going down that road at all costs. With SM still in development branch, anything that gets in my way in that regard, is something, that so long as I provide a compelling case as to a better way, we can work to make that change, and help future theme developers. Ok, enough chatter, time to start poking at this :) -- 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
