+1 to have one official theme to reduce maintainance work.
Le 06/05/2013 17:27, Galen Charlton a écrit :
Hi,
On Mon, May 6, 2013 at 5:30 AM, Owen Leonard wrote:
If I get my way and we replace the prog theme with a new default
theme, then YUI is going away altogether. For anyone who hasn't hea
On 2013-05-7, at 3:18 AM, Galen Charlton wrote:
> Hi,
>
> On Mon, May 6, 2013 at 4:26 AM, Ian Walls wrote:
>> I'd like to interject here again the idea of creating a stable API for
>> template variables, so that if people feel the need to template out there
>> out theme, they can do so without
Colin Campbell schreef op di 07-05-2013 om 16:03 [+0100]:
> A lot of the code creates variables for every element. When you have
> to
> invent that many variables the code soon gets inconsistent and buggy.
> If
> we are passing a borrower pass a borrower as a hashref dont
> disassemble
> and reasse
I've read and re-read your reply, and I'm still not able to comprehend it ;
)
Do you think you could break this down more clearly, I guess I'm a bit slow
today.
http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
On Tue, May 07, 2013 at 10:21:30AM -0400, Kyle Hall wrote:
> I think we need very
> standard variable names. For example, any and all pages about a single
> patron should have a standard patron variable ( let's say "Borrower" ). The
> same thing should go for records.
A lot of the code creates var
I'd be willing to donate some time to this project. I think we need very
standard variable names. For example, any and all pages about a single
patron should have a standard patron variable ( let's say "Borrower" ). The
same thing should go for records. Each record should have the biblio and
biblio
Hi,
On Mon, May 6, 2013 at 5:30 AM, Owen Leonard wrote:
> If I get my way and we replace the prog theme with a new default
> theme, then YUI is going away altogether. For anyone who hasn't heard,
> I've been working on a new OPAC theme based on Bootstrap. Some
> screenshots of my current progress
Hi,
On Mon, May 6, 2013 at 4:26 AM, Ian Walls wrote:
> I'd like to interject here again the idea of creating a stable API for
> template variables, so that if people feel the need to template out there
> out theme, they can do so without having to re-engineer it mid-release. Any
> changes to thi
Hi,
On Mon, May 6, 2013 at 1:13 AM, Chris Cormack wrote:
> So +1 for only one supported theme, -1 for trying to achieve that by
> technical means, just make a policy and stick to it .. problem solved.
> Then those of us who use the themes locally can not have a feature
> ripped out from under us.
> While we are reorganizing things, it might be nice to reorganize the YUI
> files so that we organize them the same way that the official YUI package is
> organized.
If I get my way and we replace the prog theme with a new default
theme, then YUI is going away altogether. For anyone who hasn't he
I'd like to interject here again the idea of creating a stable API for
template variables, so that if people feel the need to template out there
out theme, they can do so without having to re-engineer it mid-release.
Any changes to this API would need to be well publicized between major
releases.
On 2013-05-6, at 8:21 PM, Mirko wrote:
> Mason James schrieb am 06.05.2013
>
>>
>> On 2013-05-6, at 5:42 PM, Katrin Fischer wrote:
>>
>>> Hi,
>>>
>>> I agree that maintaining 2 themes is a bit harder to do in
>>> Koha development,
>>
>>> but I am not sure this necessarily means we have to re
Mason James schrieb am 06.05.2013
>
> On 2013-05-6, at 5:42 PM, Katrin Fischer wrote:
>
>> Hi,
>>
>> I agree that maintaining 2 themes is a bit harder to do in
>> Koha development,
>
>> but I am not sure this necessarily means we have to remove
>> functionality that could be quite useful for
On 6 May 2013 20:08, Mason James wrote:
>
> On 2013-05-6, at 5:42 PM, Katrin Fischer wrote:
>
>> Hi,
>>
>> I agree that maintaining 2 themes is a bit harder to do in Koha
>> development,
>
>> but I am not sure this necessarily means we have to remove
>> functionality that could be quite useful for
On 2013-05-6, at 5:42 PM, Katrin Fischer wrote:
> Hi,
>
> I agree that maintaining 2 themes is a bit harder to do in Koha
> development,
> but I am not sure this necessarily means we have to remove
> functionality that could be quite useful for some Koha projects.
>
> Couldn't we keep the func
Hi,
I agree that maintaining 2 themes is a bit harder to do in Koha
development, but I am not sure this necessarily means we have to remove
functionality that could be quite useful for some Koha projects.
Couldn't we keep the functionality and still decide to only officially
support one theme in
On 2013-05-6, at 11:52 AM, Mason James wrote:
>>
>> Mason,
>>
>> Owen and I were talking recently about a plan to improve the current OPAC
>> directory structure…
as Jared mentioned to me, a simple way of describing what i am suggesting is...
we eliminate the existing themes functionality
On 2013-05-6, at 3:13 AM, Tomas Cohen Arazi wrote:
> I'd also go for a templates/ dir also :-D
>
> http://wiki.koha-community.org/wiki/Source_tree_reorganizatiton_RFC
>
> Regards
> To+
heya, yep - we have that dir already
its just called 'koha-tmpl' not 'templates'
i really love your idea, b
>
> Mason,
>
> Owen and I were talking recently about a plan to improve the current OPAC
> directory structure...
>
> the big problem is there is currently much duplication of unnecessary
> dirs/files.
> each theme has many duplicated files - and each language for each theme has
> many duplic
I'd also go for a templates/ dir also :-D
http://wiki.koha-community.org/wiki/Source_tree_reorganizatiton_RFC
Regards
To+
On Sun, May 5, 2013 at 4:44 AM, Mason James wrote:
> hi All
>
> Owen and I were talking recently about a plan to improve the current OPAC
> directory structure...
>
> the
Mason,
Owen and I were talking recently about a plan to improve the current OPAC
> directory structure...
>
> the big problem is there is currently much duplication of unnecessary
> dirs/files.
> each theme has many duplicated files - and each language for each theme
> has many duplicated files
>
On 2013-05-5, at 7:44 PM, Mason James wrote:
> hi All
>
> Owen and I were talking recently about a plan to improve the current OPAC
> directory structure...
>
> i have a proposed redesign, which i think is the best balance of removing all
> duplication, and making the least number of changes
hi All
Owen and I were talking recently about a plan to improve the current OPAC
directory structure...
the big problem is there is currently much duplication of unnecessary
dirs/files.
each theme has many duplicated files - and each language for each theme has
many duplicated files
all this
23 matches
Mail list logo
