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 duplication means that subtle bugs can occur... now that we have got the awesome new CCSR theme added, the next step is to fix the OPAC dir structure to accommodate multiple themes easily and safely :) i have a proposed redesign, which i think is the best balance of removing all duplication, and making the least number of changes to the existing structure in the new design there are 2 new top-level dirs, 'themes' and 'langs'. note: these are the *only* newly created dirs - the rest of the redesign is simply moving existing dirs from one location to another location each theme's dir (eg: prog or ccsr) only needs a 'css' dir, all other theme's existing subdirs can be moved to the shared top-level 'lib' and 'images' dirs again, with the language subdirs… each 'langs' subdir (eg: en or fr-FR) only needs an 'includes', 'modules', and 'xslt' dir (as these are the only dirs that have any actual language translation/substiution applied to them) all other existing language's subdirs can be moved to the shared top-level 'lib' and 'images' dirs, too below is an example of a redesigned OPAC dir structure, for 2 themes, with 2 languages (en and fr-FR) the directory/file count has been reduced from from 124 directories, 2542 files… to 60 directories, 1857 files any thoughts or improvements...? opac-tmpl └── themes (new) ├── ccsr │ └── css └── prog └── css ├── langs (new) │ ├── en │ │ ├── includes │ │ │ └── search │ │ ├── modules │ │ │ ├── errors │ │ │ ├── sco │ │ │ ├── search │ │ │ ├── svc │ │ │ └── text │ │ └── xslt │ └── fr-FR │ ├── includes │ │ └── search │ ├── modules │ │ ├── errors │ │ ├── sco │ │ ├── search │ │ ├── svc │ │ └── text │ └── xslt ├── images (existing, shared for all themes and langs) │ ├── datatables │ └── itemtypeimg │ ├── bridge │ ├── carredart │ ├── colors │ ├── crystal-clear │ ├── liblime-kids │ ├── npl │ ├── Seshat │ └── vokal ├── lib (existing, shared for all themes and langs) │ ├── famfamfam │ │ ├── mini │ │ └── silk │ ├── greybox │ │ └── GreyBox_v5_5 │ │ ├── adobe_images │ │ ├── compression_lib │ │ ├── greybox_source │ │ │ ├── base │ │ │ ├── gallery │ │ │ ├── set │ │ │ └── window │ │ └── static_files │ ├── jquery │ │ ├── images │ │ └── plugins │ │ └── themes │ │ └── classic │ └── yui │ ├── container │ ├── menu │ └── utilities
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 to the existing structure
if you are git curious, heres a commit with the layout changes i described.. https://github.com/KohaAloha/Koha-Dev/commits/opac-shuf2 https://github.com/KohaAloha/Koha-Dev/commit/4994789007fa79f283f5a6c206b0b55... please note that i haven't started making any actual code or path changes yet at this stage, its just an example - for discussion :)
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
all this duplication means that subtle bugs can occur... now that we have got the awesome new CCSR theme added, the next step is to fix the OPAC dir structure to accommodate multiple themes easily and safely :)
Agreed, but I have some reservations about your proposal (described below). each theme's dir (eg: prog or ccsr) only needs a 'css' dir,
all other theme's existing subdirs can be moved to the shared top-level 'lib' and 'images' dirs
If this is prescriptive (i.e. "nothing but CSS can go in a theme"), I think this would be a problem. The entire point of themes is that you can do more than just change opac.css and colors.css. If that's all themes did, we wouldn't need them because we have system preferences to change opac.css and colors.css.
again, with the language subdirs…
each 'langs' subdir (eg: en or fr-FR) only needs an 'includes', 'modules', and 'xslt' dir (as these are the only dirs that have any actual language translation/substiution applied to them)
all other existing language's subdirs can be moved to the shared top-level 'lib' and 'images' dirs, too
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. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
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
all this duplication means that subtle bugs can occur... now that we have got the awesome new CCSR theme added, the next step is to fix the OPAC dir structure to accommodate multiple themes easily and safely :)
Agreed, but I have some reservations about your proposal (described below).
each theme's dir (eg: prog or ccsr) only needs a 'css' dir, all other theme's existing subdirs can be moved to the shared top-level 'lib' and 'images' dirs
If this is prescriptive (i.e. "nothing but CSS can go in a theme"), I think this would be a problem. The entire point of themes is that you can do more than just change opac.css and colors.css. If that's all themes did, we wouldn't need them because we have system preferences to change opac.css and colors.css.
yes, a great question! what exactly is a 'theme' going to be in Koha…? i think, a theme can only have custom css, and image files, and that is all a theme must *not* have custom template, xslt, and include files (history has shown, to allow this would be impossible to maintain safely) i hope most agree on this point? :) also, i have realized i have missed some important bits of the redesign... 1/ each theme also needs its own 'images' subdir 2/ a top-level 'css' dir should be added, that contains 'css' content that is shared between all themes so, the basic idea is that we have shared top-level 'images' and 'css' dirs. that contains content that is *common* between all themes and some theme specific 'css' and 'images' subdirs, that contains only *unique* content, to that theme remember 90%+ of this css/images content is common between all themes i think,the most urgent 'bug' to fix before all this, is that each theme has its own 'includes' dir we need to fix this before the redesign can start so, as a first step, we symlink CCSR's 'includes' dir to PROG's 'includes' dir (as we currently do with CCSR's 'modules' dir) and test/fix any breakage that may occur …after that change is stable, we can then start the redesign proper fyi: heres an example of the additional css and images dirs… opac-tmpl └── themes ├── ccsr │ └── css │ └── images └── prog │ └── css │ └── images ├── css ├── images
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.
awesome, sounds great
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 that allows for differing templates between themes and replace it with CSS-only themes and customized images the reason why i think we sound do this is to reduce the maintenance problems that we have had historically
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 releases? Katrin Am 06.05.2013 02:57, schrieb Mason James:
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 that allows for differing templates between themes and replace it with CSS-only themes and customized images
the reason why i think we sound do this is to reduce the maintenance problems that we have had historically _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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 functionality and still decide to only officially support one theme in releases?
I'm just going to say this.. we have already make this mistake a few times now with Koha and themes afaik, Koha has had at least 3 previous themes, using the current directory structure ensuring that those previous theme files were maintained and correct proved to be an impossible task, and all of those themes were eventually removed i am certain if we don't fix this problem, for this cycle of themes - the same fate will occur again...
Katrin
Am 06.05.2013 02:57, schrieb Mason James:
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 that allows for differing templates between themes and replace it with CSS-only themes and customized images
the reason why i think we sound do this is to reduce the maintenance problems that we have had historically _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
cheers, Mason -- KohaAloha, NZ
On 6 May 2013 20:08, Mason James <mtj@kohaaloha.com> 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 some Koha projects.
Couldn't we keep the functionality and still decide to only officially support one theme in releases?
I'm just going to say this.. we have already make this mistake a few times now with Koha and themes
afaik, Koha has had at least 3 previous themes, using the current directory structure
ensuring that those previous theme files were maintained and correct proved to be an impossible task, and all of those themes were eventually removed
i am certain if we don't fix this problem, for this cycle of themes - the same fate will occur again...
I disagree, the problem has not ever been, nor is it, a technical one. Just because we can support themes that include differing xslt, includes has never meant we had to. I agree that having only one officially supported template is a good thing, however I don't agree with making it impossible to let people do it. 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. Chris
Hi, On Mon, May 6, 2013 at 1:13 AM, Chris Cormack <chris@bigballofwax.co.nz> 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.
+1 An additional consideration: suppose we settle on a single supported theme for 3.14 (and barring a complete a complete inability for us to reach a consensus, that is a goal I want to pursue for the release), eventually we'll get tired of it. Maintaining support for having multiple themes (and not restricting them to CSS-only) also maintains an avenue for future innovation. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
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 some Koha projects.
Couldn't we keep the functionality and still decide to only officially support one theme in releases?
I'm just going to say this.. we have already make this mistake a few times now with Koha and themes
afaik, Koha has had at least 3 previous themes, using the current directory structure
ensuring that those previous theme files were maintained and correct proved to be an impossible task, and all of those themes were eventually removed
i am certain if we don't fix this problem, for this cycle of themes - the same fate will occur again...
I think what Katrin is saying -- and I'd like to concur with -- is that we should keep the function, not keep maintaining different themes. There would only be one maintained theme in Koha out of the box and libraries that use their own custom theme will have to maintain it themselves. The whole theme thing is kind of irrelevant if we reduce it to CSS, we can have that in the appropriate sysprefs. My library actually just has decided to create a custom theme for the university's corporate identity, so I am biased, but I assume a lot of libraries will run into problems if that functionality will disappear. -- Mirko
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 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 releases?
I'm just going to say this.. we have already make this mistake a few times now with Koha and themes
afaik, Koha has had at least 3 previous themes, using the current directory structure
ensuring that those previous theme files were maintained and correct proved to be an impossible task, and all of those themes were eventually removed
i am certain if we don't fix this problem, for this cycle of themes - the same fate will occur again...
I think what Katrin is saying -- and I'd like to concur with -- is that we should keep the function, not keep maintaining different themes. There would only be one maintained theme in Koha out of the box and libraries that use their own custom theme will have to maintain it themselves.
The whole theme thing is kind of irrelevant if we reduce it to CSS, we can have that in the appropriate sysprefs.
My library actually just has decided to create a custom theme for the university's corporate identity, so I am biased, but I assume a lot of libraries will run into problems if that functionality will disappear.
-- Mirko
yeah, i was just talking to Chris on IRC, and i now agree with you both :P
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. In order to accomplish this, the following steps would need to occur: 1. Identify the variables demanded by each page 2. Consolidate variables that are shared into centralized includes/objects 3. Fill in any missing variables or generalize where appropriate 4. Document The Koha community could make it a policy to only officially support one theme with the main release, but any other institution, entity or individual could maintain and distribute their own theme customized for particular needs. They would only need to follow the change log in the API documentation to do so, and would only need to do the maintenance work at most once every 6 months. Cheers, -Ian On Mon, May 6, 2013 at 4:29 AM, Mason James <mtj@kohaaloha.com> wrote:
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 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 releases?
I'm just going to say this.. we have already make this mistake a few times now with Koha and themes
afaik, Koha has had at least 3 previous themes, using the current directory structure
ensuring that those previous theme files were maintained and correct proved to be an impossible task, and all of those themes were eventually removed
i am certain if we don't fix this problem, for this cycle of themes - the same fate will occur again...
I think what Katrin is saying -- and I'd like to concur with -- is that we should keep the function, not keep maintaining different themes. There would only be one maintained theme in Koha out of the box and libraries that use their own custom theme will have to maintain it themselves.
The whole theme thing is kind of irrelevant if we reduce it to CSS, we can have that in the appropriate sysprefs.
My library actually just has decided to create a custom theme for the university's corporate identity, so I am biased, but I assume a lot of libraries will run into problems if that functionality will disappear.
-- Mirko
yeah, i was just talking to Chris on IRC, and i now agree with you both :P
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Mon, May 6, 2013 at 4:26 AM, Ian Walls <koha.sekjal@gmail.com> 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 this API would need to be well publicized between major releases.
In order to accomplish this, the following steps would need to occur:
Identify the variables demanded by each page Consolidate variables that are shared into centralized includes/objects Fill in any missing variables or generalize where appropriate Document
I am in favor of this idea, particularly if we emphasize consolidation, which I'm reading as increasing the consistency of the template variables that we expose. Who might be interested in working on this project? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
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 biblioitem fields at the first level, and an "items" field that is an array of the items. Any pages with a plurality of records or patrons would just have a plural name instead ( "Borrowers" ), and be an array of the same data the singular would have. My instinct is telling my that DBIx::Class would make this easy, as it can do lazy fetches of data so we aren't loading up data that never gets used. Please correct me if I'm wrong. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Mon, May 6, 2013 at 11:18 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Mon, May 6, 2013 at 4:26 AM, Ian Walls <koha.sekjal@gmail.com> 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 this API would need to be well publicized between major releases.
In order to accomplish this, the following steps would need to occur:
Identify the variables demanded by each page Consolidate variables that are shared into centralized includes/objects Fill in any missing variables or generalize where appropriate Document
I am in favor of this idea, particularly if we emphasize consolidation, which I'm reading as increasing the consistency of the template variables that we expose.
Who might be interested in working on this project?
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.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 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 reassemble into his constituent part. And there's a lot of code that manipulates data for presentation reasons before passing it to the template that can do the same presentation task as well, if not better (and usually more efficiently). I'd treat any code that retrieves data and then loops through it as suspect. Safer to get the result set and pass it to the template to display. Which brings the code closer to the approach that an ORM would require. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
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 ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Tue, May 7, 2013 at 11:03 AM, Colin Campbell < colin.campbell@ptfs-europe.com> wrote:
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 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 reassemble into his constituent part. And there's a lot of code that manipulates data for presentation reasons before passing it to the template that can do the same presentation task as well, if not better (and usually more efficiently). I'd treat any code that retrieves data and then loops through it as suspect. Safer to get the result set and pass it to the template to display. Which brings the code closer to the approach that an ORM would require.
Colin
-- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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 reassemble into his constituent part.
I tend to agree with this. I guess that H::T::P was not as capable of digging into data structures, but for new code, there's no reason to not pass a borrower, or an array of biblio hashes, or whatever. T::T lets you do virtually everything you can do in Perl to the structures. This also leads nicely into having T::T libraries for common display operations that are needed on many pages. This said, I'd encourage people to keep in mind having only display-related logic in the templates, and all other logic in the appropriate .pl/.pm. It can sometimes be tempting to put things in the easy place, rather than the right one. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On 2013-05-7, at 3:18 AM, Galen Charlton wrote:
Hi,
On Mon, May 6, 2013 at 4:26 AM, Ian Walls <koha.sekjal@gmail.com> 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 this API would need to be well publicized between major releases.
In order to accomplish this, the following steps would need to occur:
Identify the variables demanded by each page Consolidate variables that are shared into centralized includes/objects Fill in any missing variables or generalize where appropriate Document
I am in favor of this idea, particularly if we emphasize consolidation, which I'm reading as increasing the consistency of the template variables that we expose.
Who might be interested in working on this project?
Regards,
Galen
hi Folks, i really like this idea, and I'm keen to help out on these tasks.
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 heard, I've been working on a new OPAC theme based on Bootstrap. Some screenshots of my current progress are here: http://zivotdesign.com/zp/Koha/bootstrap-opac-redesign/ These are *very* early in the process, based primarily on CCSR for the general look and feel. My goal here is to end up with a theme that feels more modern, is fully-responsive, and which is maintains all the functionality of the current prog theme. Here are the steps I have envisioned for this theme once it is finished: 1. Replace CCSR with this new theme. I suggest this because I suspect there are fewer libraries out there with extensive CCSR customizations. Replacing CCSR with a new theme that offers a similar look and feel will be less surprising. 2. Announce the sunsetting of the prog theme. Give libraries plenty of time to prepare to switch to CCSR for their customizations. 3. Drop prog and make CCSR default, perhaps renaming it "default" for clarity? Or give it another Koha-specific name? For what it's worth, I also vote that we do *not* remove the ability to create new custom themes. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hi, On Mon, May 6, 2013 at 5:30 AM, Owen Leonard <oleonard@myacpl.org> 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 are here:
+1 to continuing with the new theme. This might be a bit early, but can you comment on how the proposed theme would interact with Debian's Booststrap packages?
1. Replace CCSR with this new theme. I suggest this because I suspect there are fewer libraries out there with extensive CCSR customizations. Replacing CCSR with a new theme that offers a similar look and feel will be less surprising.
2. Announce the sunsetting of the prog theme. Give libraries plenty of time to prepare to switch to CCSR for their customizations.
3. Drop prog and make CCSR default, perhaps renaming it "default" for clarity? Or give it another Koha-specific name?
+1 to using a name like 'default'. To sum up, assuming folks are on board with the Bootstrap-based theme, I suggest: 3.14 -- new theme is introduced as 'default', replacing CSSR. 'prog' is officially deprecated 3.16 -- 'prog' is removed Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
+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 <oleonard@myacpl.org> 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 are here:
+1 to continuing with the new theme.
This might be a bit early, but can you comment on how the proposed theme would interact with Debian's Booststrap packages?
1. Replace CCSR with this new theme. I suggest this because I suspect there are fewer libraries out there with extensive CCSR customizations. Replacing CCSR with a new theme that offers a similar look and feel will be less surprising.
2. Announce the sunsetting of the prog theme. Give libraries plenty of time to prepare to switch to CCSR for their customizations.
3. Drop prog and make CCSR default, perhaps renaming it "default" for clarity? Or give it another Koha-specific name?
+1 to using a name like 'default'. To sum up, assuming folks are on board with the Bootstrap-based theme, I suggest:
3.14 -- new theme is introduced as 'default', replacing CSSR. 'prog' is officially deprecated 3.16 -- 'prog' is removed
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Fridolyn SOMERS Biblibre - Pôle support fridolyn.somers@biblibre.com
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 <mtj@kohaaloha.com> wrote:
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 duplication means that subtle bugs can occur... now that we have got the awesome new CCSR theme added, the next step is to fix the OPAC dir structure to accommodate multiple themes easily and safely :)
i have a proposed redesign, which i think is the best balance of removing all duplication, and making the least number of changes to the existing structure
in the new design there are 2 new top-level dirs, 'themes' and 'langs'.
note: these are the *only* newly created dirs - the rest of the redesign is simply moving existing dirs from one location to another location
each theme's dir (eg: prog or ccsr) only needs a 'css' dir, all other theme's existing subdirs can be moved to the shared top-level 'lib' and 'images' dirs
again, with the language subdirs…
each 'langs' subdir (eg: en or fr-FR) only needs an 'includes', 'modules', and 'xslt' dir (as these are the only dirs that have any actual language translation/substiution applied to them)
all other existing language's subdirs can be moved to the shared top-level 'lib' and 'images' dirs, too
below is an example of a redesigned OPAC dir structure, for 2 themes, with 2 languages (en and fr-FR) the directory/file count has been reduced from from 124 directories, 2542 files… to 60 directories, 1857 files
any thoughts or improvements...?
opac-tmpl └── themes (new) ├── ccsr │ └── css └── prog └── css
├── langs (new) │ ├── en │ │ ├── includes │ │ │ └── search │ │ ├── modules │ │ │ ├── errors │ │ │ ├── sco │ │ │ ├── search │ │ │ ├── svc │ │ │ └── text │ │ └── xslt │ └── fr-FR │ ├── includes │ │ └── search │ ├── modules │ │ ├── errors │ │ ├── sco │ │ ├── search │ │ ├── svc │ │ └── text │ └── xslt
├── images (existing, shared for all themes and langs) │ ├── datatables │ └── itemtypeimg │ ├── bridge │ ├── carredart │ ├── colors │ ├── crystal-clear │ ├── liblime-kids │ ├── npl │ ├── Seshat │ └── vokal
├── lib (existing, shared for all themes and langs) │ ├── famfamfam │ │ ├── mini │ │ └── silk │ ├── greybox │ │ └── GreyBox_v5_5 │ │ ├── adobe_images │ │ ├── compression_lib │ │ ├── greybox_source │ │ │ ├── base │ │ │ ├── gallery │ │ │ ├── set │ │ │ └── window │ │ └── static_files │ ├── jquery │ │ ├── images │ │ └── plugins │ │ └── themes │ │ └── classic │ └── yui │ ├── container │ ├── menu │ └── utilities
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
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, but a name-change will be tricky... 'koha-tmpl' is hardcoded in the apache config files, so a dir rename will break apache when people upgrade :/ ...as are the dir names 'opac-tmpl' and 'intranet-tmpl' so, it will be tricky to rename any of these dirs without breaking existing Koha installs
On Sun, May 5, 2013 at 4:44 AM, Mason James <mtj@kohaaloha.com> wrote: hi All
Owen and I were talking recently about a plan to improve the current OPAC directory structure…
participants (13)
-
Chris Cormack -
Colin Campbell -
Fridolyn SOMERS -
Galen Charlton -
Ian Walls -
Jared Camins-Esakov -
Katrin Fischer -
Kyle Hall -
Mason James -
Mirko -
Owen Leonard -
Robin Sheat -
Tomas Cohen Arazi