Bootstapbase didn't replace Base in 2.5. You can go check yourself, Base is still there in all its glory, underlying the default theme Standard and every other included theme in Moodle, with the sole exception of Clean. So perhaps it's not going quite as fast as you think it is?
And I'm not sure that you and I have the same definition of "deprecate". What do you think is going to happen when this deprecation occurs? The whole point of deprecation is to give advanced warning of changes while maintaining backwards compatibility. How can delaying the warning help anyone?
David Scotson
Posts made by David Scotson
Gareth, I'm not sure that's a great analogy. I'm talking about deprecating something, no explosives are required. It's more like putting a sign on a door saying "There's a newer, better, more accessible toilet down the hall that we'd prefer if you used" (and having sent a memo round a year or so previously to let people know this was going to happen).
http://en.wikipedia.org/wiki/Deprecation
The "demolition" happens some time after the deprecation, once enough people have started using the new facilities that it no longer seems worth re-filling the soap in the old ones and even then Moodle's open source so it would be more like locking a door that everyone has the key to open if they really want.
http://en.wikipedia.org/wiki/Deprecation
The "demolition" happens some time after the deprecation, once enough people have started using the new facilities that it no longer seems worth re-filling the soap in the old ones and even then Moodle's open source so it would be more like locking a door that everyone has the key to open if they really want.
Richard, I get the general picture that "change is bad", but exactly what changes are the big sticking points here?
Which bits of base/standard/canvas do you really not want to lose? If those bits could be moved into a future default theme, and/or a future base theme then would that help? If base/standard/canvas continued to exist in core Moodle beyond 2.7 but bits within theme (e.g. the forms) were re-written in much the same way course lists were rewritten in 2.5 would that be a problem for you?
I'm trying to suggest concrete, actionable changes to improve Moodle for everyone and I'd happily modify them to help you out in any way I can but you're not giving me much to work with here. For some people that use Standard an upgrade to Clean as default in 2.6 would be nothing but positive. Please outline the difficulties others would face so that we have time to fix them.
Which bits of base/standard/canvas do you really not want to lose? If those bits could be moved into a future default theme, and/or a future base theme then would that help? If base/standard/canvas continued to exist in core Moodle beyond 2.7 but bits within theme (e.g. the forms) were re-written in much the same way course lists were rewritten in 2.5 would that be a problem for you?
I'm trying to suggest concrete, actionable changes to improve Moodle for everyone and I'd happily modify them to help you out in any way I can but you're not giving me much to work with here. For some people that use Standard an upgrade to Clean as default in 2.6 would be nothing but positive. Please outline the difficulties others would face so that we have time to fix them.
I'm a bit concerned about how the outlined plan translates into concrete actions for the 2.6 dev cycle.
Some things I'd suggest could be done in that 4 month window and could be done in simple stages that continually improve Moodle without many big-bang changes in case we run out of time:
- Copy current renderers into Base theme
- Rewrite all current renderers with Bootstrap compatible code
- As part of above, break current renderers into modular logic and display parts...
- ...and tweak renderers API to better suit modern frameworks (might need simple API translation layer in Base renderers)
- Shift a few more bits of code into using renderers that exist
- Shift a few more bits of code into renderers (grids, a-z pickers, forms, ...)
- Declare Moodle "mobile first", in 2.6 timeframe this mostly involves fixing silly bugs that haven't been found/fixed due to lack of mobile usage e.g. PDF display on iOS, and testing everything on phones
- Declare Base/Standard theme deprecated after the next release (2.6)
- Delete all lines of CSS that support IE7 or previous (and various other simple CSS cleanups e.g. redundant gekco/webkit usages)
- Have a separate Bootstrap theme that apes the look of Bootstrap more completely just to prove it's possible before going off and making Moodle specific tweaks to the default theme Clean (which shares the Bootstrap toolkit underneath).
- Upgrade to Bootstrap v3
- Integrate a good 3rd party CSS compressor
There's plenty more to do and they're mostly kind of boring clean up tasks of old code or simply fixing bugs. I'm a bit worried these things will get overlooked in favour of more glamorous tasks that involve green field development, snazzy new tech and inventing exciting new ways to do things from scratch.
Writing a pureio theme would be very easy, you'd copy all the core Bootstrap renderers into the theme and then do a search and replace on some class names. (If the renderers were well written, you'd only need to do this to one single renderer file). How would you do it in a "sitting on the fence" approach?