No premade templates.
I
On Wednesday, May 2, 2012 at 3:14 AM, Daniel Sokolowski wrote:
> Being realistic here we must acknowledge that likely the majority of us are
> great programmers but not great designers – none of the design proposed did
> it for me – they were not bad but they weren’t
Lovely to see fresh talent and energy applied to a long-stalled issue. :)
I think Giovanni's proposal has a strong, simple page structure, and it does a
good job of IA for our varied audience. Putting on my BDesignerFL hat, let's
use that as a starting point.
Let's set aside the issue of restyl
On Monday, April 30, 2012 at 10:16 AM, Brett H wrote:
> Increasing the flexibility for development and integration is more
> important than trying to 2nd guess where we are going to be in 5 years
> time.
Fair enough, but that sort of flexibility is available now. Nothing is
preventing you from
he branch on my fork works pretty well with 1.4:
> https://github.com/h3/django-grappelli/tree/grappelli_2_4
>
> Cheers
>
> On Apr 26, 7:06 pm, Victor Hooi http://gmail.com)>
> wrote:
> > Hi,
> >
> > Is there any news on the Django Admin rewrite front?
&g
fork works pretty well with 1.4:
> https://github.com/h3/django-grappelli/tree/grappelli_2_4
>
> Cheers
>
> On Apr 26, 7:06 pm, Victor Hooi http://gmail.com)>
> wrote:
> > Hi,
> >
> > Is there any news on the Django Admin rewrite front?
> >
&g
As we're already past feature freeze, changing the bundled copy of
jQuery would require that there be a show stopping bug or some truly
exceptional benefit.
Absent both of these, updates like this will have to wait for the 1.5 cycle.
I
On Feb 29, 2012, at 9:42, Ric wrote:
> hi, is it possibile
The next major revision of the admin will definitely use either less or
sass, because it is uncivilized to work without such lovely tools nowadays.
I'm less certain about bootstrap. It has some pros and cons:
Pros:
* widely used (and thus widely understood)
* We won't need to invent our own styl
This is fantastically clear and sensible. +1.
I can't count the hours I've lost either chasing PYTHONPATH issues or
helping nontechnical people work around them so they could deploy their
newly-minted thing.
I
--
You received this message because you are subscribed to the Google Groups
"Djan
So, a while back, I announced that Django is dropping support for IE6 in the
admin. What I _didn't_ specify is what browsers are supported.
I'm currently composing a bit for the 1.4 release notes about admin browser
support, and wanted to explicitly list what we consider to be supported:
YUI's
W00t, poking through the source.
On Saturday, August 20, 2011 at 4:59 PM, Gregor Müllegger wrote:
> So after the exams, vacation and a short illness have I completed a week of
> productive work.
>
> All the parts that were discussed in detail on the mailing list a while back
> are implemented.
Hey Victor,
So far, only small steps -- my time hasn't provided for any thing "major"
yet. :)
My twitter will be a good place, as will this list. Right now, my head is
mainly in helping out with a couple of specific issues (formrendering, admin
sorting). There are some plans underway to provid
On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote:
>
> What is the "significant wart" ?
>
The formconfig tag is a little bit "magical"; there's no other example in
the template langauge of something explicitly affecting state in the same
fashion. Even things like the "with" tag are s
At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about
his work on a revised form rendering API:
http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
I sat down with Gregor, Jannis, Russell, Alex, Ericflo, Andrew God
The technical 500 page does display a lot of information, but debugging a
failure is all about information.
#11834 is helpful (dims django frames) without getting in the way (hiding
things). For now, this is a good example of a helpful change with minimal
negative impact.
I'm sure the 500 page
OK, by the power vested in me, I declare the admin unshackled from the need to
support IE6.
Reception and dancing shall follow.
On Thursday, June 9, 2011 at 2:22 PM, Carl Meyer wrote:
> On 06/09/2011 05:32 AM, Idan Gazit wrote:
> > I'm looking at admin tickets, and I realize tha
I'm looking at admin tickets, and I realize that some defined policy for when
we can safely start to break IE6 would be very helpful.
I'd like to simply declare that going forward, the admin need not work
perfectly in IE6. That leaves our support footprint for the Admin at "modern
browsers" +
Jannis and I are sprinting on this; we'd like to take a 2nd look at potential
behaviors after a long conversation yesterday. The current solution works, but
I think there's still a lot of room for user confusion.
Plan is to look again at existing sorting implementations (on various
apps/platfor
t 8:34 AM, Julien Phalip wrote:
> On Jun 8, 12:25 am, Luke Plant http://cantab.net)>
> wrote:
> > On 07/06/11 11:32, Idan Gazit wrote:
> > > I'd like to propose adding two flags to Trac, "UI" and "UX".
> > So would it be better to have just "U
Greetings, Earthlings.
I'd like to propose adding two flags to Trac, "UI" and "UX".
The impetus for adding these new fields is twofold: I'd like some hooks that I
can use to keep track of tickets related to design issues, but more importantly
this will allow me to say "Designers: here's where
On Tuesday, May 24, 2011 9:48:43 AM UTC+3, Anshuman Aggarwal wrote:
>
> However, as in all deprecation, I would suggest that we start with a
> global setting that allows these links to be hidden on an installation
> by installation basis and the default made to true for now.
>
-1, if only bec
I agree that it's redundant and unnecessary, but absent a particular *need*
to remove it, I'd say leave it until the admin gets an overall refresh.
While having two links may be marginally confusing for new users, _removing_
an existing bit of functionality is akin to a breaking change, IMO. It'
Three cheers for the release team!
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googleg
And lo, the core team spake amongst themselves, crying: "Who shall
take up the mantle of designer among us? Wilson departed many moons
ago for the land of Rdio, and the people cry out for one to provide
succour to those who want a more beautiful Django, and yea, a Django
that listens to thei
Russ/Carl:
Finally got a chance to catch up on the thread, and found Carl penned
a (lovely, much more detailed) version of what I had in mind.
In the end, forms is a repository of unusually common fail because
designers must figure out Python and a lot of how django works in
order to customize fo
What a fantastic proposal. I have some concerns, but I'm not sure if
any of them have to do with my misunderstanding.
1. The {% load %} mechanism can get ugly, fast. What if I am rendering
multiple different forms on the same page? {% load %} {% form %} {%
load %} {% form %} feels mildly unclean t
FWIW, I spoke with Alex the other week about turning piano-man into a
more finished product.
So long as core guarantees that they'll at least take a look at
whatever is made, I'm +1 on rolling our own, and am willing to
champion this project.
I think having something we can easily shape to meet o
I'm looking at http://code.djangoproject.com/ticket/12359, and (with
some guidance from Alex_Gaynor), think that there's really two fixes
here: a short term, backwards-compatible fix which removes the forced
help_text appendage, and a long-term, backwards-incompatible fix which
adds a help_text lay
Hey Wilson, I'm sure I'm not the only one who is delighted that you
have some cycles to spare for Django. :)
As this thread was about practical matters, I'd say the next step is
deciding on a few things that we want to get done. Up at the top, I
suggested setting out a few modest goals for 1.3 as
On Feb 7, 11:58 pm, "j...@jeffcroft.com" wrote:
> You're right, Idan. Sorry if I steered it off-track! I sent Wilson a
> message asking him to check out this thread.
Awesome, thanks!
> I think we first need to make sure we ARE going forward with this
> whole "design czar" idea. Neither Alex no
Just to steer the discussion back to practical matters:
1. This thread isn't about what stuff we want to do in the admin, or
whether grappelli is great. How to improve the admin or any other
aspect of Django which has design issues is a great discussion! It
just isn't *this* discussion.
2. *This*
On Feb 7, 6:06 am, Justin Lilly wrote:
> I, for
> one, am willing to trust their judgement on someone who can lead this
> design-czar selection process, if Wilson doesn't come out and name his
> successor, as it were.
Something that hasn't been explicitly said yet:
I *don't* think that the de
Responses inline.
On Feb 7, 2:26 am, "j...@jeffcroft.com" wrote:
> 1. I wouldn't say "Wilson is out of the picture" without talking to
> him first.
Amen. I was under the impression that he's definitively out of the
picture. If he can be lured back to the community, awesome.
> 2. Is there value
A small addendum:
One way to think about the design czar is someone representing
designers' needs in Django proper. Arguably, we already had somebody
in this role -- Wilson -- and now we have a fantastic template
language and an admin which is still ahead of its time in many ways.
We wouldn't have
Hey folks,
Splitting off from
http://groups.google.com/group/django-developers/browse_thread/thread/ca4f26d616921753,
which has an exhaustive discussion about how django needs to treat
design work.
In the spirit of taking action, I put together this list with Bryan
Veloso. My goal is to spark a
Hey folks,
Won't waste time echoing the sentiments above in many words. Contest
stupid. Ground-up rework in 2.0 (maybe). Refactor & clean up existing
stuff in the meantime. Design czar(s) needed to chaperone this work
into existence.
I don't think that I'm qualified to submit myself for a "djesig
On Aug 18, 12:35 am, Dave Jeffery wrote:
> (Sticking my nose in where it isn't wanted...) The toolbar looks really
> great but it feels a bit over-designed and too heavy for a functional
> interface which will sit atop of existing websites. I'm especially referring
> to the typography, the upperc
On Aug 17, 4:28 pm, Jacob Kaplan-Moss wrote:
> I'd say a similar ethos should be expressed in the debug toolbar branding.
> If you wanted to be extra special, some UI similarity between the
> error pages and the debug toolbar would probably be a good idea.
Fair 'nuff. I'll squash the last remain
Oh, forgot to include the screencast:
http://s3.pixane.com.s3.amazonaws.com/ddt-ui-refresh.mov
-I
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
I've been working on prettyfication of the DDT. Github:
http://github.com/idangazit/django-debug-toolbar/tree/idan-ui-rf. It's
a reasonably complete reskinning of the existing DDT. There are still
a couple of outstanding issues but the redesign is largely finished.
I didn't use the admin color pa
39 matches
Mail list logo
