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 people begin to develop skins for it. But as I mentioned >>>> earlier in this thread, finding free time to complete some of the >>>> big >>>> development tasks needed for 1.5.2 has become difficult for many >>>> of us >>>> on the team. >>> >>> >>> Where do I find out more about this structure, there seems to be >>> General Display Options >>> Skin: >>> Theme: >>> Icon Theme: >> >> 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. > 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. >>> 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. The main SM css directory I think is used as a fall-back for some of the basic styles in the interface. It is not clear (or I don't remember if a decision was made) if those should be wholly moved into the default skin's css directory instead, but either way, they should be of course override-able in your skin. >>> I opened /templates and duplicated default to defaults_scott and it >>> is >>> not showing up in the Display panel. >> >> Run the configuration utility and add the skin or edit the main SM >> config file and add it there. > > Ok, will try that. > >>> 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). > 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). ------------------------------------------------------------------------- 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
