configurable css_override_url

[jvanasco]

I patched this locally, but can do a PR if others find it useful (I think it is)...

I added a .ini setting of css_override_url. If set, that is injected into the Exception and Toolbar templates after the core css is loaded.

The use case is allowing developers to do a few simple things with css such as making the toolbar fit more information on the screen by:

• Make the font-size smaller
• Decrease the padding on the tabs
• Decrease the height of the toolbar nav/branding

[stevepiercy]

Got a screenshot?

In which file would you add the CSS?

[jvanasco]

Images below are with and without custom overrides. Obviously done for an extreme of "Power User" needs, and not general use (which the defaults are fine for).

I render (if present) a "css_override_url" in console.dbtmako, exception.dbtmako and toolbar.dbtmako.

I populate the var in tbtools.py and views.py.

Submitting a patch would happen after another PR i have is accepted, because it touches on an existing bug I fixed elsewhere (registry.settings vs registry.parent_registry.settings).

On a similar note, I think it's worth creating a "default_render_args(request)" function that creates a standardized dict, instead of individually defining static_path and root_path.

The override css I used, btw, is fairly agressive:

.navbar {
    min-height: 25px;
    max-height: 25px;
    overflow: hidden;
}
.navbar .container-fluid {
    margin-top: -12px;
}

#content {
    margin-top: -40px;
}
.sidebar {
    margin-top: -40px;
}
body {
    font-size: 11px;
}

.nav.nav-tabs a {
    padding: 5px;
}

.table>thead>tr>th, .table>tbody>tr>th, .table>tfoot>tr>th, .table>thead>tr>td, .table>tbody>tr>td, .table>tfoot>tr>td {
    padding: 4px;
}

[stevepiercy]

How about this idea? Add a new line after this:
https://github.com/Pylons/pyramid_debugtoolbar/blob/master/pyramid_debugtoolbar/templates/toolbar.dbtmako#L13

    <link rel="stylesheet" type="text/css" href="${static_path}css/override.css">

And add a new empty file override.css in here https://github.com/Pylons/pyramid_debugtoolbar/tree/master/pyramid_debugtoolbar/static/css

Then users can dump whatever custom CSS they want in there locally, and optionally add that file to .gitignore after the initial checkout.

I would like to give users the option to have customizations like this while preserving the core styles. I'd write documentation to accompany this change. What do you think @jvanasco ?

[blaflamme]

This is actually the kind of override I was afraid someone would want to do. All those padding overrides makes the whole UI almost unreadable while you're keeping other padding between columns where they could be narrowed a bit. By doing this you break the whole UI cohesion for a less valuable goal of fitting more info within the same space. There are UI reasons while there are padding and you can't just remove here and there and not affect the whole thing. I'm not saying the defaults are awesome, mostly just plain bootstrap and they certainly need more customization, but everything should be fine tuned to keep consistency across the UI.

As an example you narrow the top bar and keep the logo as is and only get a part that doesn't fit at all... ouch :(

Now that people start to add more and more panels, the tabbed interface is not a great choice, tabs on multiple lines break the UI purpose of this component. This should be re-thinked and panels could probably be shipped with their own css addons. That way you could override or extend the current css but ideally following a well defined guideline to keep things coherent and similar.

[mmerickel]

Sorry @stevepiercy, modifying the project in a fork defeats the idea here. My solution to this is to propose a hook that will allow some arbitrary configuration of the debugtoolbar app by providing access to the configurator. This would be analagous to pyramid.includes except probably debugtoolbar.includes. From there it'd be simple to modify the static assets using traditional overriding.

@jvanasco is this enough information to give you an idea what I'm talking about? The only downside I see atm is that it doesn't allow you to re-use the old css, it'd be a complete override of the entire file.

[blaflamme]

@mmerickel ideally we should keep the base css and have a way to add css files to be included at render time. That way people could extend or add css for their own panels using an include-like approach.

[mmerickel]

@blaflamme that's a much larger change than my simple do-whatever-you-want hook that already exists in pyramid because then we have to update our templates to support all of this. If you're interested in doing the work then I'm happy to keep talking about it.

[blaflamme]

@mmerickel ideally we should merge both of our ideas :)

We can provide a hook to add adhoc files and make them available trough a response and loop them at the right location in the master template or we can provide a hook to mount a debug toolbar static view for the panel and provide an add_css and add_js to also be included or looped in the master template?

[jvanasco]

In my existing dirty-hack solution, I add the override css right after the static one. This allows the defaults to be pulled in, and a developer can just override whatever params as needed within their project. Just edit the .ini to specify the url, and the url can be local or elsewhere. No fork needed.

I get what @mmerickel is talking about from the Pyramid point of view, not sure how apply that in this use case.

I totally understand @blaflamme's UX concerns. This isn't a default though, it's for an advanced need. The default UX provided from Bootstrap is very generous with spacing and whitespace. The navbar on the top was great when I first started using pyramid, but I only ever click it now to toggle profiling. It's a lot of space that could be used for reporting and stats, so developers don't have to scroll.

[mmerickel]

debugtoolbar.includes = myapp.lib.debugtoolbar

def includeme(config):
    config.override_asset(to_override='pyramid_debugtoolbar:static/css/toolbar.css', override_with='myapp.lib.debugtoolbar:static/toolbar.css')

I realize this is a little verbose but I'm hesitant to add first-class support for completely re-styling the toolbar. The mechanism I'm proposing works great for someone (like @jvanasco) who may want to put a completely custom toolbar UI on pypi, activated simply by debugtoolbar.includes = my_custom_toolbar_ui and doing pip install my_custom_toolbar_ui.

[mmerickel]

We can always add some sugar into this by adding some config directives. My point is that you shouldn't be specifying custom things like this in your ini file to the degree of css_override_url. That's too specific, and means we're adding too many ini settings. This belongs in code in an addon, even if we end up adding config.override_toolbar_css('myapp:static/toolbar_override.css').

[blaflamme]

I still prefer a way to add css and js addons via panel includes. That way you can add all the missing parts and because the files are loaded after you can then customize the UI. That also means that if your panel include only load css files, it can be used only to override the UI, but always based on the initial css.

[mmerickel]

@blaflamme I think you're solving a separate issue too directly. Not all of his customizations are in the panels.

[mmerickel]

@blaflamme to address that specifically, panels already can ship with their own static assets. We should probably support some sort of API in the panels for adding css/js includes that are separate from the actual contents. I just think it's not as pressing of an issue right now.

[blaflamme]

@mmerickel yeah you're right. But still I would prefer an add_css to an override_css, but we can provide both.

config.add_toolbar_css('myapp:static/my_toolbar.css')

[mmerickel]

I was going for "least-work-possible" but I realize it's definitely not ideal. Maybe just a good start! We should definitely add the extra directives I think.

[blaflamme]

I think the same

[mmerickel]

I added debugtoolbar.includes in 9e4dc75 and 4f31224.

[mmerickel]

This can be done right now by overriding the css asset doing something like:

# myapp/debugtoolbar.py
def includeme(config):
    config.override_asset(to_override='pyramid_debugtoolbar:static/toolbar.css', override_with='myapp:static/toolbar.css')

And then debugtoolbar.includes = myapp.debugtoolbar.