[bt-devel] Gitorious Branch

Greg Hellings greg.hellings at gmail.com
Thu Jan 13 18:06:31 MST 2011


On Mon, Dec 13, 2010 at 2:44 PM, Martin Gruner <mg.pub at gmx.net> wrote:
> Hi Greg,
>
> I like your suggestions and your implementation proposal!
>
> For module specific stuff, I'd recommend to put classes on the <body>
> element, one for the module type ("Bible"), and one for the specific
> module ("Bible_KJV"). That gives you all freedom writing your CSS.

I have made this change and pushed it.  Obviously it doesn't work as
intended if there is whitespace in the module name.  Crosswire does
not allow whitespace in there (I believe) and I don't think Karl has
any in his modules (though I say that without having actually
checked).  I only noticed the problem because I have some personal
modules which are rather poorly named ("A Grammatical Aid to the Greek
New Testament").  One more line of code could easily change the spaces
into underscores or the like if we want to consider the "broken
module" case.

If other people are happy with the changes still, feel free to pull my
branch (I updated it as of 10 minutes ago by merging in master to be
sure of no conflicts).

The extra CSS changes made below I figured ought to be considered more
deeply by multiple people than just me and could make a natural next
step from here.

--Greg

>
> With the CSS, you could go one step further and consolidate redundant
> CSS from the different templates into a basic CSS files which is always
> preloaded. Then the different styles only need to define their
> differences from that. Example:
>
> .sup {
>       vertical-align: super;
> }
> .sub {
>       vertical-align: sub;
> }
> .right {
>       text-align: right;
> }
> .center {
>       text-align: center;
> }
> .bold {
>       font-weight:bold;
> }
>
> This stuff makes sense everywhere and should be consolidated. It is not
> really style-specific.
>
> Right now I don't know if different HTML skeletons are really
> neccessary, but the option of having them is certainly not bad.
>
> My vote: good, can be improved, should be included in BibleTime master.
>
> Regards, mg
>
>
>
>
> Am 13.12.10 16:02, schrieb Greg Hellings:
>> All,
>>
>> I've mentioned this in #bibletime over the weekend, but figured I
>> should state it here, for archival purposes.  I have pushed a branch,
>> named 'externalcss', to
>> http://gitorious.org/~greghellings/bibletime/ghellings.  The purpose
>> of this branch is to move the styling CSS  portions of each of our
>> templates be moved into its own, external, CSS file rather than being
>> embedded in a complete HTML template file.  The hope of this change is
>> multi-faceted in nature.
>>
>> Firstly, this allows a template creator to only mess with the CSS
>> file, if they so desire, and not need to worry about keeping an HTML
>> template file up-to-date.  To create a custom CSS, simply modify or
>> add a CSS file to the share/bibletime/display-templates/ directory of
>> your install and restart BibleTime.  It will then be displayed in your
>> template file list in the configuration dialog.
>>
>> Secondly, this allows a custom HTML structure file to be used if one
>> were so desired.  This can allow the flexibility to add or detract
>> from the files while still maintaining easy inclusion of the current
>> CSS files with no need to modify multiple HTML structure template
>> files.  In the future, if more of them are generated, these could be
>> presented to the user for selection in much the same way that the CSS
>> files currently are, or they could just be used for anything internal
>> that we wish to require different HTML skeletons for.
>>
>> Thirdly, my personal axe-to-grind is the ability to add support for
>> individual module CSS files.  I have currently only added and empty
>> hook in the HTML template file for the attaching of the module's CSS
>> file, there is no attempt to fill that hook with anything other than a
>> blank string.  I intend to write that support and push an additional
>> commit to gitorious with this support.  I know some people oppose this
>> idea, but I am in strong support of it, especially with some of the
>> potential it provides for giving the presenters greater control over
>> their modules while still allowing the user the full range of control
>> and configuration if they so desire.
>>
>> Take a look and check it out.  Let me know what you think, and feel
>> free to pull what you want out of it if you like it.
>>
>> --Greg
>>
>> _______________________________________________
>> bt-devel mailing list
>> bt-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>



More information about the bt-devel mailing list