Re: Responsive admin

[Collin Anderson]

I think for the admin fonts, we put those in a separate css file:
fonts.css, so you could easily disable them by replacing that file with a
blank file. We could probably do the same thing with a responsive.css file.

(Though if we do give the option to switch, do we now need to support and
test every change for both cases? or maybe from now on we only touch
responsive.css?)

Collin

On Mon, Jan 9, 2017 at 8:26 AM, Marc Tamlyn  wrote:

> I'd suggest including this with a mechanism (on the admin site?) to
> disable it for a while if that causes problems for existing custom setups?
>
> Marc
>
> On 9 January 2017 at 11:59, Adam Johnson  wrote:
>
>> - perhaps supplying an empty CSS file with the same name overrides the
>>> file provided by the admin? (I’m not sure)
>>
>>
>> It does, as long as the app it's in is before django.contrib.admin in
>> INSTALLED_APPS, django-grappelli
>>  uses this mechanism
>> to extend/replace the admin's javascript and styles.
>>
>> I'm totally +1 for the responsive CSS too, thanks for your work on
>> django-flat-theme!
>>
>> On 9 January 2017 at 11:50, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> Hello Elky,
>>>
>>> I’d love to see this responsive design merged in Django. I’m using the
>>> admin from my phone quite often and the lack of a responsive design makes
>>> that painful.
>>>
>>> The admin gets very few CSS changes. I don’t think we should refrain
>>> from adding a useful responsive design out of fear that it will be hard to
>>> maintain.
>>>
>>> An opt-out mechanisms for third-party apps that don’t want the
>>> responsive styles will a nice touch (but not absolutely necessary in my
>>> opinion). I don’t think a setting is appropriate. I’d rather use the
>>> template or static file overriding mechanisms, for example:
>>> - perhaps supplying an empty CSS file with the same name overrides the
>>> file provided by the admin? (I’m not sure)
>>> - alternatively responsive styles could apply only within
>>> body.responsive; the admin’s template would have a >> class=“responsive”>; third party apps could override that template and
>>> remove the class
>>>
>>> Thanks for you work on the admin’s style,
>>>
>>> --
>>> Aymeric.
>>>
>>> On 9 Jan 2017, at 11:59, elky  wrote:
>>>
>>> Hi guys,
>>>
>>> Few months ago I released *django-flat-responsive*
>>>  app - a simple
>>> extension for admin that makes interface mobile and tablet friendly. I
>>> tested it on few complex projects using major mobile browsers and it works
>>> good. Now I'm going to make pull request to Django repo but before I want
>>> to ask community -- is it necessary to have responsive admin?
>>>
>>> My thoughts:
>>>
>>> Pros:
>>> - It's modern
>>> - Few times I really needed to make some edits inside admin through my
>>> mobile (it was painful), so I think some people want admin to be responsive
>>>
>>> Cons:
>>> - New admin features should be always tested on mobile devices (or on
>>> different screen sizes at least). It also uses CSS3 flexbox so developers
>>> shoul learn how it works
>>> - 3rd party apps should care about responsive layout. It's not so easy
>>> for some apps like Django Admin Tools or some CMS based on admin
>>>
>>> As fas as django-flat-responsive just adds one CSS file to static
>>> folder, what if to have an option in *settings.py* that enables
>>> responsive admin?
>>>
>>> I would glad to hear your thoughts
>>>
>>> Thank you
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/dd915c1d-d8a8-4f91-a223-268e17044cd1%4
>>> 0googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/5A95FC83-B1DD-408C-94B7-9A4E81A6F1D3%4

Re: Methodology for increasing the number of PBKDF2 iterations

[Tobias McNulty]

IMO this doesn't change the argument that it would be best to default to
the higher number of iterations (i.e., 100k or higher, given some time as
passed since 2013), while noting in the documentation that individual
projects have the ability to reduce it if need be (though perhaps
recommending that they try first to find a faster Python). Other thoughts?

On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen 
wrote:

> The Python3.5 on my system was installed by the official Python installer,
> and is almost 3X slower than the Apple-built 2.7 install. I use pip all day
> long.
>
> True, my MacBook is not a server, but it still serves to demonstrate the
> point that it is not a reasonable assumption that all 3.5 installs use
> OpenSSL libraries.
>
> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>
>> About "we cannot just assume that all Python 3 installs have a "fast"
>> PBKDF2 implementation" -- I'd expect very few if any Django users to be
>> compiling their own Python and doing so without OpenSSL. I'm guessing that
>> any operating system Python will have the OpenSSL bindings. Or is that a
>> bad assumption?
>>
>> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen wrote:
>>>
>>> I think this is a pretty solid guess. Bear in mind this was a direct
>>> install from Python.org.
>>>
>>> The important thing here is, this demonstrates that we cannot just
>>> assume that all Python 3 installs have a "fast" PBKDF2 implementation =/
>>>
>>> On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty wrote:
>>>
 ...

>>> Martin, is it possible your version of Python 3 is not linked against
 OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
 a chance to try your benchmark yet, but in a quick test I don't see any
 difference between Python 3.5.2 and Python 2.7.12 on a Mac.

 Tobias

>>>
>>>
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/9261dcdc-f3b2-458c-a6e1-
> bde49642c56b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKRz1%2BBQXs%2BpQTSf%2BNds%3DjLx4QoPtfT1%3DywL0Gy%2Bzsk72w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

settings.DEFAULT_CONTENT_TYPE incompatibility with admin

[Tim Graham]

According to ticket #23908 [0], 

By using the setting:


DEFAULT_CONTENT_TYPE = "application/xhtml+xml"


The admin site no longer renders correctly.


Do you think we should try to fix this by having all the admin responses 
specify content_type="text/html"? That requires a lot of changes [1] -- I'm 
not sure if discouraging the use of that setting might be acceptable 
instead. I imagine any third-party app that provides templates has this 
same problem.


[0] https://code.djangoproject.com/ticket/23908

[1] https://github.com/django/django/pull/7807

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7dd3a2df-5cfb-4eec-b949-7147cb5bdf24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: untranslated placeholders

[benzkji]

...in the meantime. I've created a proof of concept repo 
(https://github.com/benzkji/djangocms-untranslated-placeholders), that uses 
the code from my pull request. some things I learned/discovered:

   - it works already quite well
   - untranslated plugins are still added with a language_code. this would 
   not be a problem, but...
   - when it comes to publishing, a page with untranslated plugins can only 
   be published in the language the plugin was initially added (state/dirty 
   problem).

I don't see any other issues for now, but would be glad if some of you core 
devs could have a look at it - I remember a short discussion with ojii a 
few years ago, where he said it would be easy and a 10min job ;-)

thanks for your time
ben


On Friday, 25 November 2016 08:21:37 UTC+1, benzkji wrote:
>
> Hi there
>
> I started working on "untranslated placeholder". 
> https://github.com/divio/django-cms/pull/5675
>
> Quoting myself: This is a proposal, how a "untranslated" setting could be 
> added to the placeholder config. untranslated placeholders would just 
> ignore the language field on plugins, and always show all plugins. Typical 
> use cases: Header images, and other "non language specific content". I'm 
> aware that almost the same can be achieved with language_fallbacks, but IMO 
> it's worth it, as it makes the UI more clean for those use cases. Differences 
> to language fallbacks: Fallbacks need to be defined, untranslated just is 
> untranslated. Also, fallback plugins are not shown in edit mode (so one 
> could add a plugin, and no more fallback would be needed), wereas 
> untranslated plugins are visible in any language, also in edit mode.
>
> I can see Paulos point on complexity, as every feature you add will add 
> complexity. Concerning the performance hit though, I'm not yet sure which 
> way this would go. Sure, if you only have translated placeholders, and no 
> fallbacks, this will be +1 query on every page hit for getting untranslated 
> plugins. But. If you have at least one fallback placeholder, things will go 
> the other way quickly - depending how many fallbacks there are, there will 
> be more querys. amount_of_fallbacks * amout_of_fallback_placeholders, in 
> the worst case, as far as I can see. Compared to only one more query, when 
> using untranslated mode.
>
> The argument that it can be done with fallbacks is valid. But I had to 
> explain to customers "you need to change to the main language, to edit the 
> header image" when using fallbacks for header images (fallbacks are not 
> considered in edit mode, as one would expect), so this could be much more 
> cleaner, from an end user view.
>
> As written in the PR, I'm not really aware what more would be needed to 
> change to make this fully functional...
>
>
> Cheers
> Ben
>

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/84b97ddb-bc03-40af-80ba-38f8df320c77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature request] Template language type annotations (#27703)

[Martin Owens]

On Monday, January 9, 2017 at 2:43:00 PM UTC-5, Дмитрий Симонов wrote:
>
> Ok. Here is my example with multiline annotations.
>
> https://github.com/a1fred/django-template-type-annotations
>
> What do you think?
>

It should probably avoid parsing of the main body, I don't believe that to 
be canonical with the rest of django's tags.

It might be better to parse each pair of variables from the {% var %} tag 
itself. Just allow that tag to take more than one pair and you should have 
all the support for single and multiple declarations.

The other issue I have is that the tag doesn't effect the output the 
template produces, so it's placement in templates will complicate the 
formatting for non-coding contributors. This might be worth it, but I can 
see the benefit of keeping these check lists outside of the template file 
itself too. Having a test suite pick up these issues is my preferred 
pattern, but anyway you develop it you'll have a very small amount of use 
from most projects.

Best Regards, Martin Owens
Inkscape Website Admin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a06029e0-ceb4-4b7c-bd63-6acbaa406fd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing aliased imports ("from") in generated migration files to prevent conflicts

[Alexey Kotlyarov]

Django doesn't depend on flake8, so it can't be used during migration 
generation. Otherwise, I think aliasing the conflicting modules (6) is 
indeed a better way.

The problem came about on #django IRC channel because someone named an app 
"settings", presumably to store some configuration.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a15fe07e-2367-4a8a-9fc3-3a06cf84615f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.