Re: Proposal: Adding UI and UX fields to Trac
UI: "The sorting icon is ugly." UX: "Sorting is confusing." That being said, I agree that most people won't be able to make the distinction. I'd say that we should just add a single boolean flag. I don't want to call it "Design" so as not to confuse people with DDN tickets. "UI/UX"? "DesignHelp"? I'd be happy with any of these. Again, my practical goal is to having something I can use to filter trac, and a visible signal to non-code contributors that we desire their involvement. -I On Wednesday, June 8, 2011 at 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 "UI/UX"? > > I totally agree that Trac needs something specific for this, as it's a > shame we have to remove admin-related tickets from the contrib.admin > component. > > I also agree with Luke that having two different fields could be > confusing. UX encompasses UI so both are not completely orthogonal > from each other. How about a single "User experience" flag? Or maybe > something more explicitly targeted to the end goal, like a "Needs > designer's talents" flag? > > Julien > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Adding UI and UX fields to Trac
On Wed, Jun 8, 2011 at 9:36 AM, Idan Gazit wrote: > UI: "The sorting icon is ugly." > UX: "Sorting is confusing." > > That being said, I agree that most people won't be able to make the > distinction. > > I'd say that we should just add a single boolean flag. I don't want to call > it "Design" so as not to confuse people with DDN tickets. "UI/UX"? > "DesignHelp"? I'd be happy with any of these. > > Again, my practical goal is to having something I can use to filter trac, > and a visible signal to non-code contributors that we desire their > involvement. > > -I > > On Wednesday, June 8, 2011 at 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 "UI/UX"? > > > > I totally agree that Trac needs something specific for this, as it's a > > shame we have to remove admin-related tickets from the contrib.admin > > component. > > > > I also agree with Luke that having two different fields could be > > confusing. UX encompasses UI so both are not completely orthogonal > > from each other. How about a single "User experience" flag? Or maybe > > something more explicitly targeted to the end goal, like a "Needs > > designer's talents" flag? > > > > Julien > > > > -- > > 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(mailto: > django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com (mailto: > django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > 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...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > How about "UI related" I think for most people (myself included) UI will clearly indicate all of this stuff. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Timezone-aware storage of DateTime
On Jun 7, 4:30 pm, Luke Plant wrote: > There seems to be the assumption in other messages in this thread that > Django 'owns' the database. That is not the philosophy Django takes - it In the case of SQLite, it just plain sucks, because the DB is too stupid to support a true timestamp data type. On the other hand, this should have been foreseen when designing the Python SQLite API. I've not read anything about SQLite supporting true timestamps any time soon, so IMHO, something has to take ownership of this problem. Normally I would use Postgres for my Django apps, but I'm developing one in particular that will run on embedded Linux boxes, and they don't have the resource to run Postgres. > globally changing the format of how datetimes are stored in SQLite is > just not an option (at least not until Django 2.0), unless we can > guarantee backwards compatibility with existing data and other apps use > of the data. Backwards compatibility is always going to be a thorny issue for things that were not designed properly in the first place... As I suspected would be the case, I will probably roll my own custom field that handles this correctly, and maybe in a few years time somebody else will raise this issue... again. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Odp: Re: Allow disabling choices in a
Indeed it is useful, I was using a custom made app to do so. Thank you -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/M3Y5dFA1Q05ZdFVK. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django Error Display Page
Hi, 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. What do you think? -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Class based view version of FormPreview
I used the FormPreview class in contrib.formtools for the first time
on Monday and having worked with class based views, wished it used
FormMixin.
I refactored the FormPreview class to inherit from FormView so Django
provides a more consistent API like its sister tool FormWizard which
recently got an update.
It is 100% backwards compatible though at the expense of clarity. The
old FormPreview class based view used get_context whereas newer CBVs
use get_context_data. I discussed this and other issues in the ticket.
Overall, the mechanisms aren't any different but the code has been
moved around to act more like the other CBVs.
I created a ticket in Trac (https://code.djangoproject.com/ticket/
16174) and you can view the diff on my Github branch of the Django
mirror (https://github.com/ryankask/django/commit/
d92e4f03e81a0648bb7755fe6e43e1309b91f08a).
If this patch isn't acceptable, there a test in contrib.formtools that
should be fixed ("test_form_submit_bad_hash"). The last assertion in
the test will always be true because the request it tests 404s. I
commented on that in the ticket too.
If it is okay, I'd like to test it in the browser a little more and
write better documentation.
Best,
Ryan Kaskel
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
More Class Based Views
Well.. I wasn't sure when to send this email, mostly cause I haven't had time to properly document everything, but Russ' talk Wither Django[0] seems to have done it. One of the points he mentions in what he'd like in 1.4 is "More Class Based Views". I've started working sporadically in an external app[1] before 1.3 was released. I've implemented CBV for formsets, modelformsets and inline formsets[2], and with some more work in them I think they could be the base of something that could get into core. I've based my work in both the actual generic CBV and how the admin treats inlines. Should open a ticket for this? I would appreciate help with documentation; English and documentation are not my forte. Apart from this we could get some other Mixins and CBV into core. Ideas? Another thing I think is reaaally important is better CBV documentation. Most people I've talked about CBV agrees that the documentation is not enough and that one has to dig into the code to figure out how everything works and what to override. Russ has just said it's very improvable. Django CBVs have been called code ravioli, and it doesn't help that the documentation isn't that good. Some ideas might be making a parallel tutorial using CBV, or add a step where you can rewrite everything as CBV. Another thing I'd like to see are examples where we override each CBV and different parts of each, with real life examples. I can help here. Which do you think would be the best approach? I'll be online tomorrow at #django-sprint since 8am GMT-3 more or less. I hope more people is interested in this so that we can work together. Regards, Iván [0] http://www.djangocon.eu/talks/26/ [1] https://github.com/rasca/django-enhanced-cbv [2] https://github.com/rasca/django-enhanced-cbv/blob/master/enhanced_cbv/views/edit.py -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Error Display Page
This ticket might be a part of what you're looking for: https://code.djangoproject.com/ticket/11834 It proposes to dim the django parts of the stacktrace, so the code which most likely caused the error stands out better, which is certainly something I'd love to see. There's some similar ideas discussed here: https://groups.google.com/group/django-developers/browse_frm/thread/bd43e2e040a17784/?hl=de&pli=1 On 8 June 2011 03:50, Mateusz Harasymczuk wrote: > Hi, > 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. > What do you think? > -- > Matt Harasymczuk > http://www.matt.harasymczuk.pl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Odp: Re: Django Error Display Page
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. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Adding UI and UX fields to Trac
A single flag for "UI/UX" would be my first choice, with just "UI" being second. Differentiating the two isn't going to produce a lot of useful information at this juncture. Certainly fine with me to go ahead and add something for it, though. - Gabriel -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/cW5yQUdPdlFBaFFK. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Data loss bug on trunk
Hi all, Karen recently discovered a data loss bug that was on trunk from 20th April to 4th June. I realised it might affect other people who are running trunk, so I thought I should give a heads up here. The bug was this: If a user was editing records in the admin using the list_editable feature of the change list, and had moved off the first page or had added a filter, when the data was saved, the wrong database rows would be updated. It appears that due to the admin audit log it should be possible to locate any records that have been corrupted in this way. The ticket has more details: https://code.djangoproject.com/ticket/16154 A milder form of the bug is still actually present, and has been for some time, but affects far fewer situations in the normal case - see ticket #11313. The bug was caused by me mistakenly thinking that a relative URL of "." (a single dot) meant the same as a relative URL of "" (the empty string). My sincere apologies if this has affected anyone. Regards, Luke P.S. I realise that my email signature for today is especially inappropriate - I'm pretty sure my ignorance this time did not make me more attractive to anyone... -- "Where a person wishes to attract, they should always be ignorant." (Jane Austen) Luke Plant || http://lukeplant.me.uk/ -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Test optimizations (2-5x as fast)
On 6/6/2011 10:19 PM, Ramiro Morales wrote:
On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote:
When I try this on a PostgreSQL database, I have problems relating to
violated uniqueness constraints, sometimes from tests themselves, sometimes
from setUpClass, sometimes from tearDownClass. In the latter two cases,
it's the sites table involved. Is this something others have dealt with, or
am I on my own? :)
I tried adding a PostgreSQL "disable constraints" statement here:
https://github.com/jbalogh/test-utils/blob/master/test_utils/__init__.py#L109
cursor.execute('SET CONSTRAINT ALL DEFERRED')
It didn't help.
This might be related to ticket [1]#11665, a knownissue in the TestCase
handling of constraints with pg. Suggestion athere si to use
SET CONSTRAINTS ALL IMMEDIATE
before the rollback.
HTH
Thanks for the idea, but it did not help, which makes sense to me. The
ticket in question is complaining that TestCase doesn't throw enough
constraint violation exceptions, and suggests setting SET CONSTRAINT ALL
DEFERRED as a way to force problems to the surface. I'm trying to do
the opposite...
--Ned.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Sorting UX question
In the new admin sorting UI, which now supports sorting on multiple fields, the behaviour can be described by the following two rules: 1. If you click on a header, it is made the primary sort field (with others moved down the list as necessary). 2. If you click on a header that was already part of the sorting, the sort order for that field is reversed. Item 1. is behaviour we agreed on, and item 2. is too, kind of, but the latter is the one I'm interested in tweaking. Currently, this means that if, for example, you do: 1) Click 'first name' header 2) Click 'last name' header 3) Click 'first name' header you build up the following sort: 1) Sort by first name ascending 2) Sort by last name ascending, then first name ascending 3) Sort by first name *descending*, then last name ascending It is this last step that might need improving. Is it confusing that you end up with first name *descending*? We could change the 2nd rule to: 2. If you click on a header that was already the primary sort field, the sort order for that field is reversed. I think this might be more intuitive. Comments? Luke -- "Where a person wishes to attract, they should always be ignorant." (Jane Austen) Luke Plant || http://lukeplant.me.uk/ -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sorting UX question
On Jun 9, 9:45 am, Luke Plant wrote: > In the new admin sorting UI, which now supports sorting on multiple > fields, the behaviour can be described by the following two rules: > > 1. If you click on a header, it is made the primary sort field > (with others moved down the list as necessary). > > 2. If you click on a header that was already part of the sorting, > the sort order for that field is reversed. > We could change the 2nd rule to: > > 2. If you click on a header that was already the primary sort field, > the sort order for that field is reversed. The difficulty in the interface design here is that there are three different possible behaviours, all operated by the same user action (i.e. clicking on a header): selecting a field for sorting, ordering the sorting fields, and toggling sorting for a given field. I actually think that the current interface already does a pretty good job dealing with this. Having two different behaviours for the same action, as suggested by your new #2 rule, would actually make it less intuitive and potentially confusing, I think. Whatever the behaviour, good or bad, it's always better if the user can predict it (and quickly fix it if necessary). Perhaps the interface could be improved by dissociating the clicking on the header and the clicking on the arrow icons. Clicking on the header would do exactly the same as currently, i.e. select the field for sorting, make it the primary sorting field, and toggle it. Then, clicking specifically on the arrow icon would simply toggle the sorting for that field, without making it the primary sorting field (unless it already is) and without changing the order of sorting fields. Separately highlighting the arrow icons and the header in visually different ways on mouse hover (e.g. change the header's background when hovered, display an arrow icon with a different colour when hovered) would indicate that both are associated with two different behaviours. Adding tooltip texts would also help (e.g. for the arrow icon: "Toggle the sorting for this field without affecting the order of sorting fields"). I think this would resolve the main issue for me with this interface, which is that it's frustrating having to change the order of sorting fields when all you want is toggle a given sorting field. This is already possible to do via clicking "toggle" in the popup, but I think that clicking directly on the arrow would feel better and be more intuitive. It is a complex interface problem. Generally in this case it's OK if the user doesn't get exactly what she wants in the first go, but at least the interface should be forgiving and recovery should be quick. My two cents ;-) Julien -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Re: Django Error Display Page
Hi Mateusz, I think, adding a link at top, getting you to the end of traceback would be suitable and would work 96% of times. e.g, top line with exception type and URL could be a link moving you to the end of traceback, where the exception happened. What do you think? Smart (colored) traceback could change that to moving to the last piece of code which is not django code, but to be really usable, one would have to customize it (i.e, to add info what 3rd-party packages you use), which I feel is wrong. Tabs would also have this problem, and also that without django lines traceback would be much less readable. On Wed, Jun 8, 2011 at 11:44 PM, Mateusz Harasymczuk wrote: > 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. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
