web2py 2.14.4 tomorrow?

[Massimo DiPierro]

speak now if you have any objection.

[Leonel Câmara]

I'm having a weird error with SQLFORM

https://groups.google.com/forum/#!topic/web2py/fbpT9M39nto

I would like to track down what's causing it. Not really an objection, it may be caused by something stupid I'm doing, but in case it isn't it would be nice to have the fix there.

[mcm]

bug in impersonate I do not think can have security impact, but I would wait...

[Leonel Câmara]

Found my problem. Led me to hate SQLFORM and the FORM helper, but I don't see any easy fix for that mess.

[Niphlod]

BTW: there's a serious issue with CAS. 

Before you ask, yes, once again in order to fix something (in this case a possible security leak) we broke backward compatibility because it was not tested.

[Massimo DiPierro]

Can you tell what the issue is and how to reproduce?

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Niphlod]

bug reports are on web2py-users.

someone even fixed it.

https://github.com/web2py/web2py/pull/1268

[Massimo DiPierro]

So we can release 2.14.4 with this fix right?

[Niphlod]

don't know. Did you test CAS is working fine ? On the other end, why should we push for a 2.14.4 ? what are the bugs fixed or the new features ?

BTW: there will soon be a lot of errors with 2.7.10 for CAS and other thingies that use urllib for https resources (CAS could be one of them) that in 2.7.10 by default will check for a proper https certificate.   

[Richard Vézina]

I would like to make sure auth.logout() work from shell...

[Niphlod]

BTW2: can we start discussing a proper versioning ? current doesn't follow pep 440.

I'd like to note that every commit is released as x.x.x-stable-blablabla . "blablabla" doesn't change among commits. "stable" neither. every once in a while we get a "beta" without an "alpha" never actually ever mentioned......  

[Massimo DiPierro]

we are using semantic versioning. This was discussed in the past. I am against changing things that do not break. the blablabla is the timestamp the version changed.

I will check CAS and auth.logout() and then deploy 2.14.4. 

We agreed to deploy often. We had a few bug fixes and there is no reason to wait for new features to deploy bug fixes.

[Richard Vézina]

+1

And start better use Github release 

[Massimo DiPierro]

Please make a proposal of how this is supposed to work.

[Niphlod]

semver was proposed by yours truly. 

It used to change at every commit, and started not to.

Having an identifier (datetime of the commit) that changed at every commit helped at least to pinpoint bugs happening on users using master, but that's not the case anymore.

Also, pull()ing from master and having web2py tagged as the latest stable doesn't really help anyone.

IMHO, "stable" should only be the commit we decide to release (may it be bugged as much as last x.y.z with z < 5 lately).

As soon as a "stable" gets released and tagged, "alpha" or "beta" should kick in.

That being said, it doesn't mean we should stick to the original implementation if we break PEPs. 

Fortunately python is not dead and the community still "forges" ways to make python better, and the incarnation of principles explained in pep 440 isn't bad at all. Also, if we still are all wanting web2py to land on pypi (and from what I recall it was the single most wanted feature together with application's testing), it's a requirement.

[Richard Vézina]

I agree with you for deploy often and as long it follow a standard I ok with versioning and don't think it a emergency to change it even it PEP 440 compliancy may bring some advantages that Simone can explain maybe...

What proposal do you want about Github release? 

https://help.github.com/articles/creating-releases/

I just would like to have Changelog that follow properly version and that we flag (and update) stable releases as sometimes we end with .2, .3, .4 and stock with a final new major release that we consider stable, but that is not clearly identify like that... So for a newbie it get confusing...

See here : https://github.com/web2py/web2py/releases

Last consider stable release :

https://github.com/web2py/web2py/releases?after=R-2.12.2

Last time we have a showing up Changelog is R-2.10.3

For next version I think it should be showing like that :

R-2.14.1 : Pre-release

R-2.14.2 : Pre-release

R-2.14.3 : Pre-release

R-2.14.4 : Latest release

Richard

[Anthony]

I propose reverting the examples app (i.e., web2py.com) to the old design. I hope I'm not being offensive, but whatever the merits of stupid.css, I'm afraid the new site does not look professionally designed (hard to put a finger on, but various subtleties regarding spacing/vertical rhythm, layout, some of the hover effects, etc.). The old site could probably use a refresh as well, but I think the new design is a step backwards. If we don't have a designer among us who can pitch in, there are plenty of free and low cost templates (yes, mostly Bootstrap) that we could adopt.

Anthony

[Massimo DiPierro]

I guess my problem is that I do not know how that https://github.com/web2py/web2py/releases?after=R-2.12.2 get created. 

This is the changelog I make https://github.com/web2py/web2py/blob/master/CHANGELOG

[Richard Vézina]

Agree with you Simone about tag doesn't resolve anything... But at least it make thing intelligible when we want to consult change log... In the past on web2py.com we were having the changelog file content, but now it point on Github release and if you are honest there is nothing to understand when you consult Github release... Where I should start, which tag should I clone to test web2py?? Latest maybe... No, it not up to date...

Richard

[Richard Vézina]

Github release API doc : https://developer.github.com/v3/repos/releases/#create-a-release

Richard

[Leonel Câmara]

I propose reverting the examples app (i.e., web2py.com) to the old design. I hope I'm not being offensive, but whatever the merits of stupid.css, I'm afraid the new site does not look professionally designed (hard to put a finger on, but various subtleties regarding spacing/vertical rhythm, layout, some of the hover effects, etc.). The old site could probably use a refresh as well, but I think the new design is a step backwards. If we don't have a designer among us who can pitch in, there are plenty of free and low cost templates (yes, mostly Bootstrap) that we could adopt.

Ahahah I think the same I tried to improve it somewhat. We could use some professional design here. The thing about using stupid.css is that if we work on the examples app we end up being forced to develop stupid.css, I want to work on improving web2py not a CSS framework of which there are plenty of good ones out there for me to use.

[Richard Vézina]

:D

I think Massimo's trying to make us work on stupid.css, he thought we will not noticed...

haha

Just kidding...

Richard

On Wed, Apr 6, 2016 at 4:14 PM, Leonel Câmara <leonel...@gmail.com> wrote:

I propose reverting the examples app (i.e., web2py.com) to the old design. I hope I'm not being offensive, but whatever the merits of stupid.css, I'm afraid the new site does not look professionally designed (hard to put a finger on, but various subtleties regarding spacing/vertical rhythm, layout, some of the hover effects, etc.). The old site could probably use a refresh as well, but I think the new design is a step backwards. If we don't have a designer among us who can pitch in, there are plenty of free and low cost templates (yes, mostly Bootstrap) that we could adopt.

Ahahah I think the same I tried to improve it somewhat. We could use some professional design here. The thing about using stupid.css is that if we work on the examples app we end up being forced to develop stupid.css, I want to work on improving web2py not a CSS framework of which there are plenty of good ones out there for me to use.

[Niphlod]

we're making different topics in one, let's keep them ordered....

+1 on stupid.css not being professional. not sure about the examples app needing to be professional if shipped with web2py but for sure on webpy.com doesn't look as a good "use web2py, you'll get this stylish pages" thing. Already said stupid.css is not the answer on web2py "evading" from css-framework lock-in multiple times. Also, I'm using my own scaffolding since forever and it's filled with niceties that use bootstrap under the hood: I'm not going to leave that wealth of developed plugins by js and css developers any time soon. Not that stupid.css is a bad exercise: I just choose to give web2py the credit of being a python framework as bootstrap a css framework, each one developed by people tremendously skilled in their own "department".

on the versioning scheme, I'm hereby presenting my proposal (as a "formal" wish?!), after reading ALL PEP 440

given that I surely prefer pydal's versioning scheme (again, it'd be hard to battle myself), I'd vouch for

- not meddling with "epoch" nowhere

- not meddling with "local" nowhere

- skipping "0" always in X AND Y AND N and M

- unfortunaly we can't get rid of X = 2 for "historical reasons" ?

- just use 2.Y.N

- major new features get a Y+1

- tagged releases with no new features get a N+1

- both Y+1 and N+1 gets a tag on github

Now, intricacies (given last two years or so may be well ditched):

- the cases where "beta" applied before, that was really a "please test it" gets released as 2.Y.(N+1)rc(M+1)

- nightly gets eventually tagged different as 2.Y.rc(N+1).dev(M+1) (but given the current rate of nighlies I'd avoid alltogether)

If I'm correct in reading pep 440, I'd expect, e.g. for following releases

2.14.4

2.14.5

2.14.6

2.14.7rc1 (please test it)

2.14.7rc2 (please test it, round #2)

2.14.7

2.14.8

2.14.9rc1.dev1 (nightly)

2.14.9rc1.dev2 (nightly, round #2)

2.14.9rc1 (please test it)

2.14.9

2.14.10

2.15.1

this can be verified by the following script

from pkg_resources import parse_version, SetuptoolsVersion
versions = """
2.14.4
2.14.5
2.14.6
2.14.7rc1
2.14.7rc2
2.14.7
2.14.8
2.14.9rc1.dev1
2.14.9rc1.dev2
2.14.9rc1
2.14.9
2.14.10
2.15.1
"""
list_vers = [a for a in versions.split('\n') if a]
parsed_vers = [parse_version(a) for a in list_vers]
# verify that we're using correct scheme
assert all(isinstance(a, SetuptoolsVersion) for a in parsed_vers)
# verify that the order doesn't change
parsed_vers.sort()
# print together
for i, (orig, parsed) in enumerate(zip(list_vers, parsed_vers)):
    print "step %s, orig: %s, parsed %s" % (i, orig, parsed)

The aforementioned script SHOULD anyway be used to validate any new versioning scheme comes up.

[Massimo DiPierro]

OK on versioning. 

I am committed to supporting stupid.css. I know it has problems on IE (I do not have IE and cannot test on IE) but to my eyes with Chrome, the examples app looks much more professional than it did before and the code base is much smaller. 

I do not want to revert for now but I will fix specific problems if you report them. In particular if you have screenshots.

[Niphlod]

Press "draft a new release" button (top right corner) and be amazed ^__^

I'm +1 with Richard on a better CHANGELOG (i.e. we're on 2.14.3 on the verge of 2.14.4 but changelog reports 2.14.1, so anyone can - and do - ask what changed since 2.14.1). web2py.com's CHANGELOG links to https://github.com/web2py/web2py/releases , which is ..... misleading.

Not sure I'm on board with "sponsoring" github releases as they were because they trick the user to press "download zip" which doesn't include pydal's submodule. The real deal would be to avoid releasing alltogether on web2py.com and use github hosting with releases accompanied by binaries.

A process that once a stable release is ready:

- checks for correct API docs build on readthedocs

- checks for travis and appveyor tests passing

- checks that pydal's tracked version is a tagged pydal release

- fills the CHANGELOG file

- changes the VERSION file according to pep 440

- tags accordingly the commit on github

- prepare release on github copy-pasting the CHANGELOG section

- uploads src, win and osx binaries for that version

would probably avoid many of the latest "whoopsies" accomodating a more "formal" approach likable by users and enterprises.

[Massimo DiPierro]

before make a new release I run make src so I would like anything to be done to be done in there

[Dave S]

On Wednesday, April 6, 2016 at 2:16:52 PM UTC-7, Massimo Di Pierro wrote:

OK on versioning. 

I am committed to supporting stupid.css. I know it has problems on IE (I do not have IE and cannot test on IE) but to my eyes with Chrome, the examples app looks much more professional than it did before and the code base is much smaller. 

<URL:https://www.browserling.com/> allows you to test on IE.  (There's a "client farm" behind the web interface).

Free plan is Windows Vista, IE9 only, 3 minutes per session.

The single user plan is $19 month for "all browsers" multiple OS plantforms.  $29/month for mutlitple users.

 

I do not want to revert for now but I will fix specific problems if you report them. In particular if you have screenshots.

I think it looks good on FF 45.0.1 on an older Fedora.  Has a clean, modern look, but is very spare; could perhaps use a few softer edges.

I am not a designer, though, even if I sometimes read a type design blog or browse the Hammer Museum (in person).  

/dps

 

On Wed, Apr 6, 2016 at 3:56 PM, Niphlod <nip...@gmail.com> wrote:

we're making different topics in one, let's keep them ordered....

+1 on stupid.css not being professional. not sure about the examples app needing to be professional if shipped with web2py but for sure on webpy.com doesn't look as a good "use web2py, you'll get this stylish pages" thing. Already said stupid.css is not the answer on web2py "evading" from css-framework lock-in multiple times. Also, I'm using my own scaffolding since forever and it's filled with niceties that use bootstrap under the hood: I'm not going to leave that wealth of developed plugins by js and css developers any time soon. Not that stupid.css is a bad exercise: I just choose to give web2py the credit of being a python framework as bootstrap a css framework, each one developed by people tremendously skilled in their own "department".

[edit -- trim version discussion I'm not addressing]

 

[Dave S]

On Wednesday, April 6, 2016 at 2:54:36 PM UTC-7, Dave S wrote:

On Wednesday, April 6, 2016 at 2:16:52 PM UTC-7, Massimo Di Pierro wrote: 

 

I do not want to revert for now but I will fix specific problems if you report them. In particular if you have screenshots.

I think it looks good on FF 45.0.1 on an older Fedora.  Has a clean, modern look, but is very spare; could perhaps use a few softer edges.

I am not a designer, though, even if I sometimes read a type design blog or browse the Hammer Museum (in person).  

Is the updated site missing a favicon?

/dps

 

[Richard Vézina]

On Wed, Apr 6, 2016 at 5:41 PM, Massimo DiPierro <massimo....@gmail.com> wrote:

before make a new release I run make src so I would like anything to be done to be done in there

In web2py root folder?

[Massimo DiPierro]

Now perhaps you understand why I hate it too. 1) it is not easy to create widgets or accommodate different css. 2) if there are errors it does not know how to refresh custom widgets. 

On Tue, Apr 5, 2016 at 6:38 PM, Leonel Câmara <leonel...@gmail.com> wrote:

Found my problem. Led me to hate SQLFORM and the FORM helper, but I don't see any easy fix for that mess.

--

[Richard]

We make it to 46% coverage congratulations!!

:)

Richard

[Richard Vézina]

Search results :

http://www.barrykooij.com/create-github-releases-via-command-line/

Small project to interract with Release API :

https://github.com/aktau/github-release

Richard

[Anthony]

I am committed to supporting stupid.css.

Does that mean you are committed to using it for web2py.com?

 

I know it has problems on IE (I do not have IE and cannot test on IE) but to my eyes with Chrome, the examples app looks much more professional than it did before and the code base is much smaller.

Looking back at the old site, indeed some elements are improved, but some are worse. Overall, both designs could use a lot of improvement.

 

I do not want to revert for now but I will fix specific problems if you report them. In particular if you have screenshots.

My sense is that this is difficult to get right for non-designers, and we would probably be better off adapting a nice professionally designed template. But if that's off the table, here's my list of issues with the current design:

• We need a logo in the header.
  
• Pure white on pure black or vice versa is too much contrast (on most websites where the background or text appears black, it is not really pure black). Change the header and footer backgrounds to a very dark gray (i.e., just short of pure black). Likewise, make a similar change to the black text color.
  
• I don't particularly like the new green color for links, but that's a personal preference. However, it definitely does not work on the dark background of the header (i.e., when hovering over the navigation links). Instead, consider changing those links to a gray color that turns white on hover.
  
• The underline animation on all the links is distracting and should be removed.
  
• The drop shadow on the buttons on hover is distracting. Instead consider darkening the button itself upon hover.
  
• The font sizes all look a little too big (headings and body text).
  
• There is too much line spacing within paragraphs and not enough spacing between paragraphs.
  
• The lists on the about, docs, support, and contributors pages have too much spacing between items, too little spacing between headings/sections, and should use bullets.
  
• The bright red buttons on the home page do not look good in contrast to the green headings/links (the old buttons looked a little better, as they were a more muted color).
  
• There should be some space between the technology award image and the download button on the home page. Better yet, maybe it's time to move that four year old award to a less prominent place.
  
• On the download page, too much space between the rows of buttons, not enough space between the heading and first row. Also, the new bright primary colors are not attractive (the more muted colors of the old site were not perfect but much better). It's also not clear why particular buttons are particular colors (maybe just make them all the same color -- and please not bright red).
  
• The "Read More" button on the download page should have rounded corners, like all the other buttons on the site.
  

Anthony

[Richard Vézina]

Anthony pin point many of my own observation I agree to most part if not all...

I don't think that we should use some other template as most of the observations can be fixed to me...

I have a background in Pre-press infography... I can give a try...

Is the web2py.com app can be changed over github somewhere?

Richard

--

[Anthony]

I don't think that we should use some other template as most of the observations can be fixed to me...

I have a background in Pre-press infography... I can give a try...

Great.

 

Is the web2py.com app can be changed over github somewhere?

web2py.com is the "examples" app in the /applications folder.

Anthony

[Dave S]

On Thursday, April 7, 2016 at 9:23:29 AM UTC-7, Anthony wrote:

• [...] 

• On the download page, too much space between the rows of buttons, not enough space between the heading and first row. Also, the new bright primary colors are not attractive (the more muted colors of the old site were not perfect but much better). It's also not clear why particular buttons are particular colors (maybe just make them all the same color -- and please not bright red).
  

Part of that is distinguishing the columns.  And the old version did it, too.  But I keep looking for the button that says "For Linux".  (It looks like web2py doesn't support Linux; "aliasing" the "Source Code" button would be fine, I think.)

• The "Read More" button on the download page should have rounded corners, like all the other buttons on the site.
  

Under "Instructions", the command line examples look like buttons.

/dps

[Richard Vézina]

haha... Dumb me!

Richard

Anthony

--

[Anthony]

• On the download page, too much space between the rows of buttons, not enough space between the heading and first row. Also, the new bright primary colors are not attractive (the more muted colors of the old site were not perfect but much better). It's also not clear why particular buttons are particular colors (maybe just make them all the same color -- and please not bright red).
  

Part of that is distinguishing the columns.

Yes, but the columns already distinguish the columns. And why are "normal users" and "developers" both red but "testers" yellow? And then we have change log and bug report in green.

Anthony

[Massimo DiPierro]

On Thu, Apr 7, 2016 at 11:23 AM, Anthony <abas...@gmail.com> wrote:

I am committed to supporting stupid.css.

Does that mean you are committed to using it for web2py.com?

open for discussion. If nobody steps up to re-design it and I have to do it, than I will do it the stupid way.

 

 

I know it has problems on IE (I do not have IE and cannot test on IE) but to my eyes with Chrome, the examples app looks much more professional than it did before and the code base is much smaller.

Looking back at the old site, indeed some elements are improved, but some are worse. Overall, both designs could use a lot of improvement.

+1

 

 

I do not want to revert for now but I will fix specific problems if you report them. In particular if you have screenshots.

My sense is that this is difficult to get right for non-designers, and we would probably be better off adapting a nice professionally designed template. But if that's off the table, here's my list of issues with the current design:

• We need a logo in the header.
  

I can put it back

• Pure white on pure black or vice versa is too much contrast (on most websites where the background or text appears black, it is not really pure black). Change the header and footer backgrounds to a very dark gray (i.e., just short of pure black). Likewise, make a similar change to the black text color.
  

I can. I like it better black but I will try. 

• I don't particularly like the new green color for links, but that's a personal preference. However, it definitely does not work on the dark background of the header (i.e., when hovering over the navigation links). Instead, consider changing those links to a gray color that turns white on hover.
  

Give me a color scheme. No preference.

• The underline animation on all the links is distracting and should be removed.
  

That's the thing I like the most. :-( 

• The drop shadow on the buttons on hover is distracting. Instead consider darkening the button itself upon hover.
  

How about a wave effect like materialize? 

• The font sizes all look a little too big (headings and body text).
  
• There is too much line spacing within paragraphs and not enough spacing between paragraphs.
  
• The lists on the about, docs, support, and contributors pages have too much spacing between items, too little spacing between headings/sections, and should use bullets.
  
• The bright red buttons on the home page do not look good in contrast to the green headings/links (the old buttons looked a little better, as they were a more muted color).
  
• There should be some space between the technology award image and the download button on the home page. Better yet, maybe it's time to move that four year old award to a less prominent place.
  
• On the download page, too much space between the rows of buttons, not enough space between the heading and first row. Also, the new bright primary colors are not attractive (the more muted colors of the old site were not perfect but much better). It's also not clear why particular buttons are particular colors (maybe just make them all the same color -- and please not bright red).
  
• The "Read More" button on the download page should have rounded corners, like all the other buttons on the site.

I am ok with changing all of them. If you want me to do them, I will do them as a stupid theme.

 

• 
  

Anthony

[Massimo DiPierro]

For the record. I did not change the button colors. They were always those colors.

--

[Richard Vézina]

about button I think it is mostly the placement and color is too bright (as Anthony says muted color...)

About underline animation, I think it a matter of not using them all over the place...

Should I let you go first Massimo?

[Massimo DiPierro]

I can make some improvements during the week-end.

[Richard Vézina]

Ok I am on it right now will send PR later today with some improvement over stupid.css and welcome.css

[Massimo DiPierro]

Please do not change stupid.css. Just make another css with the overrides we discussed.

[Carlos Cesar Caballero Díaz]

El 07/04/16 a las 15:10, Massimo DiPierro escribió:

On Thu, Apr 7, 2016 at 11:23 AM, Anthony <abas...@gmail.com> wrote:

I am committed to supporting stupid.css.

Does that mean you are committed to using it for web2py.com?

open for discussion. If nobody steps up to re-design it and I have to do it, than I will do it the stupid way.

I asked in the past about that and no one said a word. Right now I have no designer available for doing so, but if we can find some starting template (or design guide), I can work on that.

But please, not using stupid (at least not from now), is good to make a small css framework, but a css framework needs a professional designer working on that.

[Richard Vézina]

Stupid.css change so far :

td, th {padding:5px; vertical-align:top; text-align:left; border:0}

For :

td, th {padding:0; vertical-align:top; text-align:left; border:0}

Which I think do much more sens... Depending how you realize (if you do it) BT condense vs normal... But to me table should never be responsible for adding spacing between element, better the elements itself doing it...

I can avoid making change to stupid.css

Richard

--

[Massimo DiPierro]

OK. I can live with that.

[Richard Vézina]

@Carlos

I don't think stupid.css is the reason about all that... To me most of what make web2py.com not professional turn around wrong blank space proportion between elements (padding, margin) and too brigth color... Other then that it look like the old site... Maybe the overall placement start to date a bit... But let try small step theory for not further delay next release... 

Feel free to make any proposal for a new design... 

I like ala docker : https://www.docker.com/ (I take this one there is plenty of product using such template now)...

Richard

[Massimo DiPierro]

On second thought. Bootstrap adds padding: 8 to table cells too. I will keep that in stupid.css.

[Anthony]

On Thu, Apr 7, 2016 at 11:23 AM, Anthony <abas...@gmail.com> wrote:

I am committed to supporting stupid.css.

Does that mean you are committed to using it for web2py.com?

open for discussion. If nobody steps up to re-design it and I have to do it, than I will do it the stupid way.

:-)

 

• Pure white on pure black or vice versa is too much contrast (on most websites where the background or text appears black, it is not really pure black). Change the header and footer backgrounds to a very dark gray (i.e., just short of pure black). Likewise, make a similar change to the black text color.
  

I can. I like it better black but I will try.

I think the internet disagrees with you. Check any site that has "black" text -- it is almost never pure black (e.g., here on Google Groups, the text is rgb(34, 34, 34)). Same goes for "black" backgrounds. It's OK if it looks black, but it should not be rgb(0, 0, 0).

 

• I don't particularly like the new green color for links, but that's a personal preference. However, it definitely does not work on the dark background of the header (i.e., when hovering over the navigation links). Instead, consider changing those links to a gray color that turns white on hover.
  

Give me a color scheme. No preference.

Part of my point was that we are not designers -- we don't do color schemes. Anyway, here's a generated color scheme with a primary color very similar to the green/teal we currently have on the site: http://www.materialpalette.com/teal/orange.

 

• The drop shadow on the buttons on hover is distracting. Instead consider darkening the button itself upon hover.
  

How about a wave effect like materialize? 

Material uses the ripple effect for clicks, not hovers. For hovering, typically it is just a darkening or lightening of the color. If the buttons are raised, they have a slight shadow all the time, and Materialize does enhance the shadow on hover in that case -- but note that it is directional, not the same all around (and I don't think it looks quite right with flat buttons -- i.e., when there is no shadow at all except on hover). Ripple on click would be nice, but only if done well (I've seen some bad ripple implementations).

Anthony

[Dave S]

For some reason, FF is drawing the local copy of the buttons under the award with the left several pixels on the line above the button, which makes that column look something like a gas pump.  Doesn't happen with the real web2py.com,

/dps

 

[Dave S]

Example attached

On Wednesday, April 6, 2016 at 2:54:36 PM UTC-7, Dave S wrote:

[Massimo DiPierro]

Will fix. You are right about black. Took my palette for here http://clrs.cc so should have used #111111 whish "looks black".

--

[Anthony]

On Thursday, April 7, 2016 at 10:35:35 PM UTC-4, Massimo Di Pierro wrote:

Will fix. You are right about black. Took my palette for here http://clrs.cc so should have used #111111 whish "looks black".

The palette I linked had #212121, which I think looks pretty good (even the #343434 here on Google Groups still looks "black" to me, but not as stark). #111111 might still be a little too dark.

Anthony

[Massimo DiPierro]

I am not a designer either but as a physicist I do not understand why the shadows should not be symmetrical. The shadow comes from raising the button and the light comes from outside the screen, not form one side.

Anthony

--

[Anthony]

On Friday, April 8, 2016 at 1:36:13 AM UTC-4, Massimo Di Pierro wrote:

I am not a designer either but as a physicist I do not understand why the shadows should not be symmetrical. The shadow comes from raising the button and the light comes from outside the screen, not form one side.

I'm not sure how much it really matters, but I assume the idea is that it feels more natural for the primary light source to be coming from above rather than directly in front of the screen (or equally from all directions). If you look around, I suspect most physical objects you see do not tend to have symmetric shadows. Anyway, I was just observing how Materialize (and several other similar libraries, including Google's Polymer and MDL) seem to be handling drop shadows.

Anthony

[Leonel Câmara]

Yep the theory is that in the real world light comes from the top, where the sun is. In my opinion, nowadays, it also makes sense to consider light coming from outside the screen (perpendicular to the screen) as people use more tablets/phones and so the position of the screen is not necessarily to be standing vertically anymore. 

[Richard Vézina]

I will, not touch stupid.css

As I said, I think it may be useful for normal, not condensed table display... Bootstrap I think will just remove the padding when you use table-condensed...

Exactly look here : http://www.w3schools.com/bootstrap/tryit.asp?filename=trybs_table_condensed&stacked=h

Remove and add the class you will see that padding 8px is removed when table-condensed is on...

Richard

[Massimo DiPierro]

it does not remove it. It decreases 8px to 5px padding.

[Richard Vézina]

padding 0 look good for the download page though... I didn't have time to work on it last night... I will send what I did so far...

Richard

[Massimo DiPierro]

thanks!

other that this I think we are ready to release 2.14.4.

[Richard Vézina]

Didn't fix the issue with impersonate found by Michele...

I am really clue less at where CODE() that generate this :

> python2.7 web2py.py -h

It ends up with a pre tag with style attached to the element so can't modify it as it the latest css rule that rules the display...

I try to past style attribute to CODE(), I search all over web2py... The style of the pre element is surely not litteraly expose in the code I guess it's extracted from css style some how... All that to say that the padding of the pre element should be incrise to 8px at least...

Richard

[Massimo DiPierro]

CODE has a hardcoded style. This is bad. All we can do allow customization of the CODE style attribute.

[Anthony]

On Friday, April 8, 2016 at 8:43:44 AM UTC-4, Leonel Câmara wrote:

Yep the theory is that in the real world light comes from the top, where the sun is. In my opinion, nowadays, it also makes sense to consider light coming from outside the screen (perpendicular to the screen) as people use more tablets/phones and so the position of the screen is not necessarily to be standing vertically anymore.

Even without the screen standing vertically, unless the light is emanating from your face or coming equally from all directions, you would still expect to see asymmetric shadows.

Anyway, aside from light direction, I think the bigger distinction between the Materialize hover effect and the one used on web2py.com is that the former mimics a real physical reality whereas the latter does not. In Materialize, the button always has a drop shadow, suggesting it hovers above the background. When you hover over the button, the button color gets lighter and the drop shadow extends a little further, suggesting the addition of a new light source (i.e., something that could happen in the real world). On web2py.com, there is no drop shadow, suggesting that either the button is at the same level as the background or the lighting is so diffuse and uniform that no shadows are cast. However, upon hover, a drop shadow suddenly appears, suggesting that either the button has been raised up from the background (in which case, it should get larger), or a new light source has been added (in which case, the button color should get lighter). But the button remains the same size and color, so the sudden appearance of a drop shadow does not mimic reality and therefore appears odd and distracting.

Anthony

 

[Richard Vézina]

Man... Try with styles='string of style', list of style, dict of style...

Can't find the hardcoded style in html CODE class... Where it is?

Anyway I will send a PR of where I get so far...

Richard

[Richard Vézina]

I am so dumb... It was just in my face in examples.css haha! :

pre {background-color: black!important;border-radius:5px; color:white; padding:10px}

It tooks that I lost all my change because of a wrong stash command for finding it...

Let me redo my change it should take an hour...

Richard

[Richard Vézina]

Here : https://github.com/web2py/web2py/pull/1276

Finally it really hardcode as only the color of PRE element can be changed as it is hardcoded as transparent...

I was lucky there were an instance of gedit which was open with the changes I made so I recover them...

It just small improvements but I think it already make the display more professional

Richard

[Richard Vézina]

Hope there is no glitch between navs... It was looking good with chromium...

[Paolo Valleri]

Regarding tests, I remember we have already discussed about running pydal tests on web2py but since web2py is shipped with few dated contrib drivers es: pg8000, pymysql, pypyodbc, is there any guarantee that they are still working with latest pydal?

 Paolo

[Richard Vézina]

Hello Paolo,

Maybe a polls to know if they are used could provide idea if they really are used... I try pg8000 once and it was buggy... I know that the point is to have fully python drivers but it is not working properly...

Richard

[Massimo DiPierro]

I agree. Shall we remove it?

[Richard Vézina]

Just leave working stuff... There is no problem to add them back if they start to work properly latter... ?

[Leonel Câmara]

I think we shouldn't be maintaining our own pg8000 driver, however, I think it's a good idea for pyDAL to support it, and if pyDAL supports it then it has to work around its bugs and limitations which it doesn't right now.  When I started using postgresql consistently, I quickly stopped using pg8000 because of how many problems I bumped into that simply disappeared when I used psycopg2.  

  

Basically, we need an adapter just for pg8000 and if, for now, no one is willing to maintain it, oh well. 

[Massimo DiPierro]

I had issues too with it. Like crashes when exporting a large database.

On Apr 8, 2016, at 5:19 PM, Leonel Câmara <leonel...@gmail.com> wrote:

I think we shouldn't be maintaining our own pg8000 driver, however, I think it's a good idea for pyDAL to support it, and if pyDAL supports it then it has to work around its bugs and limitations which it doesn't right now. I quickly stopped using pg8000 when I started using postgresql consistently because of how many problems I bumped into that simply disappeared when I used psycopg2.  

  

Basically, we need an adapter just for pg8000 and if, for now, no one is willing to maintain it, oh well. 

[Niphlod]

as a sidenote, not that I'm the first one knowing it .... ubuntu 16.04, which is the newer LTS has no python 2.x installed, and by default it ships with python 3.

It'll be a good time to start talking PROPERLY about py3 code.

[Richard Vézina]

:)

I already mention that, but install script for ubuntu worked well with beta2... I didn't test with the official release though...

Are we making a new version soon?

[Massimo DiPierro]

Oh boy!

[Leonel Câmara]

Not exactly, ubuntu still respects pep 394

https://www.python.org/dev/peps/pep-0394/

Still, we need to be compatible with python 3 soon anyway as python 3 is starting to get a lot of goodies that python 2 doesn't have. A good first step would be to drop python 2.6 as it's much easier to make 2.7 code compatible with py3.

[Niphlod]

BTW: I expected it, but just to confirm, the script doesn't work.