There's a new Bootswatch based on the popular Flat look that's been all the rage lately:
http://bootswatch.com/flatly/
(Original inspiration http://designmodo.github.io/Flat-UI/ )
Thought I'd mention it as some people have expressed interest in the Flat UI, but it's use of SASS made it a bit tricker to integrate into Moodle (on reading further it seems the pro version of Flat UI that you have to pay for added a LESS version).
Dear David,
It appears that the 'less' files are there - applied to the 'Clean' theme in around five mins (inverted navbar shown and small size to get the screen shot under the 100K forum upload limit)....
Cheers,
Gareth
Looks quite nice. I particularly like the font and having the wide range of font widths opens up some interesting possibilities..
http://www.latofonts.com/lato-free-fonts/
http://www.google.com/fonts/specimen/Lato
Like Bootstrap 3 the Moodle theme needs a little bit of tweaking to make the turn editing on button fit where it currently is because the buttons are bigger.
Someone should really start a project to port all the Bootswatches to Moodle Themes so that the little things like that can be worked on collectively and sorted once and for all.
http://www.latofonts.com/lato-free-fonts/
http://www.google.com/fonts/specimen/Lato
Like Bootstrap 3 the Moodle theme needs a little bit of tweaking to make the turn editing on button fit where it currently is because the buttons are bigger.
Someone should really start a project to port all the Bootswatches to Moodle Themes so that the little things like that can be worked on collectively and sorted once and for all.
Dear David,
Indeed, I did work on a fix for the editing button - MDL-40087 - but clearly it now requires the capability to force its container to enlarge using padding (I think).
Cheers,
Gareth
The root of the issue is that it's not actually "in" the "container", it's floated over the top to look like it is because a hacky CSS solution was, at the time, more acceptable than a hacky renderer solution, or a proper renderer solution.
To continue the CSS hackery you could just make the button thinner (or use a smaller preset button size) or make the navbar bigger.
There's probably lots of interesting options for what you can do with that button, but currently the bit of code that puts the button there also does a random handful of unrelated things that all get dumped in the same place depending on what screen you're on (I think each page basically gets to decide what to put there, but I might be wrong). If that was teased apart your options would expand greatly but I'm not sure that's possible.
I'd probably lean towards a slightly hacky renderer solution that inserts the button renderer into the output of the navbar renderer.
To continue the CSS hackery you could just make the button thinner (or use a smaller preset button size) or make the navbar bigger.
There's probably lots of interesting options for what you can do with that button, but currently the bit of code that puts the button there also does a random handful of unrelated things that all get dumped in the same place depending on what screen you're on (I think each page basically gets to decide what to put there, but I might be wrong). If that was teased apart your options would expand greatly but I'm not sure that's possible.
I'd probably lean towards a slightly hacky renderer solution that inserts the button renderer into the output of the navbar renderer.
Dear David,
Fair enough
RE: Someone should really start a project to port all the Bootswatches to Moodle Themes so that the little things like that can be worked on collectively and sorted once and for all. - Are you saying that you would like a version of Mutant Banjo in core?
Cheers,
Gareth
I was thinking more of a bit of automation to generate multiple themes each with a unique look created from bootswatches rather than a single theme with multiple looks but the most general thing would be to fork the Bootswatch repository and then add any Moodle specific tweaks to the bootswach.less file for each different swatch.
People could then use these slightly modified swatches for various purposes. And people could use the inspiration to get ideas on how to customise their own themes.
People could then use these slightly modified swatches for various purposes. And people could use the inspiration to get ideas on how to customise their own themes.
Dear David,
Ok, a different way to go about it
Cheers,
Gareth
Dear David,
I experimented with a custom renderer for the next version of Shoelace and came up with a hybrid Flatly-Shoelace as can be seen below...
Cheers,
Gareth
Did you try it with btn-small? Because of the prominence of position I think you can get away with the smaller button size. Which would save you having to change the breadcrumb too much (though that's another option too).
Dear David,
To be honest, no, but this was really a means of seeing if custom renderer code could be written to embed the button within the navbar and use 'overflow: hidden' with the float to change the size of the button and have the navbar adjust.
Cheers,
Gareth
I use this in some themes...works OK
/**
* Returns HTML to display a "Turn editing on/off" button in a form.
*
* @param moodle_url $url The URL + params to send through when clicking the button
* @return string HTML the button
*/
public function edit_button(moodle_url $url) {
$url->param('sesskey', sesskey());
if ($this->page->user_is_editing()) {
$url->param('edit', 'off');
$text = '<a href="'.$url.'" class="btn btn-danger" title="'.get_string('turneditingoff').'"><i class="icon-off icon-white"></i></a>';
} else {
$url->param('edit', 'on');
$text = '<a href="'.$url.'" class="btn btn-success" title="'.get_string('turneditingon').'"><i class="icon-edit icon-white"></i></a>';
}
return ($text);
}
Add it to 'theme_bootstrapbase_core_renderer' Mary?
Yes if it is not already used for something else.
The method 'edit_button' has not been overridden, so could be as long as the classes are Bootstrap ones, which I would have thought you would not have made that mistake.
But the code could be written more optimally:
public function edit_button(moodle_url $url) {
$url->param('sesskey', sesskey());
if ($this->page->user_is_editing()) {
$url->param('edit', 'off');
$btn = 'btn-danger';
$title = get_string('turneditingoff');
$icon = 'icon-off';
} else {
$url->param('edit', 'on');
$btn = 'btn-success';
$title = get_string('turneditingon');
$icon = 'icon-edit';
}
return '<a href="'.$url.'" class="btn '.$btn.'" title="'.$title.'"><i class="'.$icon.' icon-white"></i></a>';
}
Oh whatever
Ah...but wait a minute, should you not be using html_writer???
in the return item that is?
True:
return html_writer::tag('a', html_writer::tag('i', '', array('class' => $icon.' icon-white')), array('href' => $url, 'class' => 'btn '.$btn, title => $title));
I thought (hoped?) there was a move away from using html_writer where it mostly served to complicate and confuse the intent of the renderer. Because Gareth's version is a bit more "programmery" there's more need for html_writer but I preferred Mary's original despite/because of the duplication which makes the intent and HTML clear:
if ($this->page->user_is_editing()) {
$url->param('edit', 'off');
$text = '<a href="'.$url.'" class="btn btn-danger" title="'.get_string('turneditingoff').'"><i class="icon-off icon-white"></i></a>';
} else {
$url->param('edit', 'on');
$text = '<a href="'.$url.'" class="btn btn-success" title="'.get_string('turneditingon').'"><i class="icon-edit icon-white"></i></a>';
}
My own actual personal preference would be a function/renderer that just did buttons e.g. something like:
return button_link_with_icon($url, "success", get_string("turneditingon", "edit");
but that's even more programmery, so simple straightforward presentational PHP seems like the next best thing, though Mary's version could be improved just by seperating the logic of deciding which button to use and the presentation of that button into separate functions so that people could tweak the HTML without worrying about the surrounding code.
Dear David,
I do admit that the 'html_writer' looks very complicated in implementation - please look at the new renderer methods in Shoelace -> https://github.com/gjb2048/moodle-theme_shoelace/blob/MOODLE_25/renderers/core_renderer.php.
But I thought that the current policy was to move to 'html_writer' as a matter of policy, but has that policy been replaced by another policy and was there a policy in place that mandated the policy change procedure? ;)
The main think here is if it works and it's understandable then don't change it unless there is a benefit that outweighs the risk of change.
Cheers,
Gareth
You ARE supposed to use html_writer in renderers. I quite like the way that turned out now you have mastered the Art of HTML Writer!
I don't know what the official stance is/was (can you point me to it if you know where it is?), but I've long thought the combination of writing low-level HTML and using html_writer to be a very bad idea indeed.
It seems strange for the FRONTEND team to be investigating/suggesting the use of template engines in renderers, presumably so that they are easier to write for people who know HTML, while also having a policy that recommends using such an obtuse, verbose and unfriendly API for simple HTML. It's as if we're officially pretending that Moodle is written in Java rather than PHP. After all, PHP itself is one of the "template engines" the front end team is considering since it's had this ability to blend code and HTML built into the language from day one.
Note I'm aware that html_writer is useful in situations where you're passing variables about and changing them before rendering something at the end, similar to your example. I wrote something very similar myself, except that it produce more idiomatic HTML5, and I believe this is the task that html_writer was originally created for. But for writing out what would otherwise be a mostly static bit of HTML it's just silly how much extra typing is involved and how unreadable the result is.
It seems strange for the FRONTEND team to be investigating/suggesting the use of template engines in renderers, presumably so that they are easier to write for people who know HTML, while also having a policy that recommends using such an obtuse, verbose and unfriendly API for simple HTML. It's as if we're officially pretending that Moodle is written in Java rather than PHP. After all, PHP itself is one of the "template engines" the front end team is considering since it's had this ability to blend code and HTML built into the language from day one.
Note I'm aware that html_writer is useful in situations where you're passing variables about and changing them before rendering something at the end, similar to your example. I wrote something very similar myself, except that it produce more idiomatic HTML5, and I believe this is the task that html_writer was originally created for. But for writing out what would otherwise be a mostly static bit of HTML it's just silly how much extra typing is involved and how unreadable the result is.
I totally agree.
Ok, technically, Java has had templating from day one because it has 'interfaces' and J2EE has templating in Java Server Pages ;)
Does anybody have a link to the 'Policy'?