Colorized technical_500_response: django code is green, user code is red.

[Yuri Baburov]

Pretty debatable feature. Helps to grasp easily what parts of the frame belongs to django, and what to user.

[Yuri Baburov]

How does it looks after applying patch

[Yuri Baburov]

Different stack

[Russell Keith-Magee]

Reasonable suggestion, but probably calls for different colour choices. To me, Red/Green implies stop/go or broken/good, which isn't the intention. There's nothing wrong with the existing stack trace colors, IMHO - we just need to pick a way to make a distinction between user and internal code. Collapsing the 'django' portions of the stack is another option.

[Yuri Baburov]

Green-yellow

[Yuri Baburov]

My friend designed suggested the green-yellow color scheme fix, i've updated patch and added new screenshot.
How about this version? I like it even more.

[Russell Keith-Magee]

#13148 made some additional suggestions regarding the debug page, raising the UX issues for the debug page again.

I'm going to move this to the UX component so we can get some designer mojo on it.

[Yuri Baburov]

Patch allowing to customize debug colors.

[Yuri Baburov]

Patch allowing to customize debug colors.

[Yuri Baburov]

Russell, great idea.
I added also a better patch, that allows changeable and controllable colors.
It's not in RFC state (docs & constants are inlined), but overall it's very good prove of the concept, and you can play with it.

But if we considering real improvements of the debug pages,
I'd also add a way to do werkzeug-style of post-mortem inplace-debugging, also reducing default output,
and a better output for template frames.

[Thomas Güttler]

Thread on django-dev ​http://groups.google.de/group/django-developers/browse_frm/thread/bd43e2e040a17784/

[Chris Beaven]

From the group discussion:

The agreement between core devs and me (or at least how i get it) was
that we decided that this patch needs to be a part of larger "debug
page usability improvement suite".

I'd be happy to just see just this in for now. We can iteratively improve the debug page, and getting colorization in would be a great start.

[Alex Gaynor]

As someone who hits Django bugs often enough (if you aren't pushing the framework to the limit you're doing something wrong :D) I'd really want a way to disable this.

[Chris Beaven]

I'm confused. Why would you need to disable this because you hit a Django bug? It still helps with readability of the traceback.

If you really wanted to though, you can disable it by setting TRACEBACK_COLOR_SCHEME = {'': ('#bbe',)} (althought it would be nicer if you could just set it to None for no colouring).

[Chris Beaven]

(or perhaps you don't even need that '' option taking a second look)

In any case, we can't use a dictionary here for the color scheme because the order isn't guaranteed so marking as needs improvement.

[Jannis Leidel]

Sounds like a great thing for our design BDFL to decide.

[Idan Gazit]

Nifty.

I like the idea of making it easier to see in what parts of a traceback are in "my code" (versus code in Django itself).

This solution seems over-engineered to me for that purpose. Looking at the patch, I have configurable control over how packages are colored; I'm skeptical that most users require this kind of detail, let alone configurability.

Second, multiple colors starts to introduce design considerations that aren't being addressed. When I'm looking through a traceback, I'm afforded no indication of what these colors mean, nor am I provided a legend indicating which colors map to what parts of my source. I'm not wild about adding a legend to tracebacks; there's already quite a bit of information for users to process there without adding more.

Keeping in line with the original goal of the ticket, I'd propose that the solution simply help users distinguish between their code and Django code in tracebacks. With the exception of outliers like Alex, most users are hunting bugs in their code, not Django. With this simpler distinction, we can do away with colors, and rely on a simpler mechanic which is self-explanatory, like slightly dimming the Django frames. The goal isn't to make them light to the point of invisibility, rather to make them just different enough that the eye has an easy time skipping over the Django frames. Hopefully, this solution also obviates the need for Yet Another Setting.

[Paul McLanahan]

@idangazit +1. Dimming sounds perfect, plus it'll work even for the colorblind.

[Thomas Güttler]

patch which applies to 1.3.x SVN

[Thomas Güttler]

I don't think yet another settings variable is a good solution. I think this should be a small patch to highlight django code vs. other code. I think this
patch does not need tests or documentation. It needs to be committed, since it is very useful.

[Jannis Leidel]

Well, it certainly needs a proper patch though now that we have a good proposal from idangazit. Documenting the change is also imperative to explain the reasoning behind it.

[Matt Harasymczuk]

I have been thinking about this for quite a long time.

Can you make an error display page less verbose?
I mean not to exclude those useful information, but to initially fold (hide) them.

Fold those items:

• Python path at the top yellow background.
• (Hide or fold) django traceback entries

When I have a problem I have to scroll down (passing django calls) few pages until I am able to find which MY action caused an error.
I know looking at django callback may be useful, but in my case, hardly ever, and probably for newcommers also.

I am imagining this like that:

At the top of the error page, there are tabs.
Summary, Traceback, Request, Settings, and copy-paste view (feedback view).

Summary tab, contains this yellow background information with PYTHON_PATH initially folded, and traceback filtered out to include only information from project not calls from django itself.

Traceback, request and settings tabs as it is right now, but separated for easy of view.

copy-paste (feedback) - a standardize view for easy of copy-and-paste to the Internet message boards, groups and so on...

It would need a template refactor and some more js involved, should not be a hard thing to do.
I read that there is a plan to redesign an error page, but since then, those modifications should do the job.

Colored output of the trackeback does not solve my problem of scrolling few screens in order to find whats happening, or use cmd-F key to quick jump.
I think this is not a good way to do this.

What's I am thinking is a tabs at the top which manipulates with visibility of certain divs of error page.
A quick temporary fix, before complete redesign of error page.

Discussion at: ​https://groups.google.com/forum/#!topic/django-developers/aQtKMRxdTHM

[Aleksandra Sendecka <asendecka@…>]

buriy's first patch changed into grey-scale

[Aleksandra Sendecka <asendecka@…>]

and the debug page with a patch

[Idan Gazit]

In [16343]:

Fixed #11834 -- Improved technical 500 stacktrace display.

Thanks to buriy and Aleksandra for the implementation!