June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Cyril Ferlicot D.

On 09/06/2018 16:43, Hilaire wrote: > Hi Cyril, > > From what I read in an older P7 image > DockingBarMorph>>defaultBorderWidth was not implemented, and inherited, > from AlignmentMorph which defaultBorderWidth returns 0. > It was here but in a different hook. It was in setDefaultParameters as you can see here: https://github.com/pharo-project/pharo/pull/1479/files#diff-f9fc80b09f7cbc9… > Next, why docking bar should have the same width as menu? > It was the previous behavior. What I changed is that now #themeChanged reset the border width to take the one of the current theme when before it was ignored. > The question is do we want docking bar to have border? > I'll probably propose a new method in the theme #dockingBarBorderWidth and we can return 0 by default for it. > I see the Playground tool bar is impacted, although it does not make is > UI less suitable. > > In the meantime I just set DockingBarMorph>>defaultBorderWidth to > returns 0, so I can use the last build at school with students. By doing > so I did not notice glitch.. > > I am not sure docking bar not having border should be considered as a bug.. > > Thanks > > Hilaire > > -- Cyril Ferlicot https://ferlicot.fr

June 9, 2018

Re: [Pharo-dev] Web Frameworks and "Modern" Features

by Paul DeBruicker

Hi I think we're doing OK and that its a "discoverability" problem not a "does not exist or work" problem. E.g. here is Johan's talk about integrating ReactJS & Seaside https://www.youtube.com/watch?v=1eSGO7QSz5c I think part of the problem is that Facebook/Google/Amazon dominate the 'new hotness' discussions and no one has problems at their scale so the solutions that work for them that they advocate that people adopt (so e.g. their hiring pool is better for them) aren't necessarily necessary/appropriate for smaller sites with fewer engineers. For responsive design if he means sites that look good on big or small screens we're OK as its mostly a CSS problem which can be handled out of the box by adopting either Torsten's Twitter Bootstrap library (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) or Cyril's Google Material Design adaptation (https://github.com/DuneSt/MaterialDesignLite) if you're using Seaside. Or just setting a few viewport width breakpoints in your existing css and changing styles appropriately if you don't want to adopt one of those frameworks or are using Teapot or Iliad or whatever. For static-site generators you'd probably want to use Teapot (http://smalltalkhub.com/#!/~zeroflag/Teapot) and just write the generated HTML to a file. For Seaside you could make one using WABuilder but would need to add paths to all of the anchors on your site, which could be done with a RB transformation rule if you had a ton of links. For the multiple competing JS library concern I'm not sure what that means exactly but also how it could be any different in this community vs e.g. Ruby/Rails. Just gotta manage the namespaces in the DOM right I think? If its been a problem for me I've forgotten or haven't noticed. I'd be happy to learn more about the other things he mentions. I know there's this page that describes how Seaside has some inherent security protections (http://seaside.st/about/security) but maybe he's referring to something different? Also testing a Seaside site is pretty straightforward with https://github.com/SeasideSt/Parasol So anyway, I think its out there. Mostly. Except for buzz. There's definitely a very usable/useful set of things that can be done with what we have today. But no question the Rails or JS communities have more because there are more engineers/companies/resources in and behind them. Hope this helps. Paul Sean P. DeNigris wrote > Hernan related running into the following limitations with Pharo web > frameworks. I wonder if these are all still missing or if any are now > availableâ¦ > >> None of them was easily adapted to the emerging web trends for the last >> years like the >> appearance of static site generators, adaptive/responsive design, >> multiple >> competing JS >> libraries, semantic web, mobility, etc. not to mention they lack >> "standard" built-in features >> such as caching, template, security frameworks. > > "adaptive/responsive design" in particular seems like a pretty big > limitation given current expectationsâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Hilaire

Hi Cyril, From what I read in an older P7 image DockingBarMorph>>defaultBorderWidth was not implemented, and inherited, from AlignmentMorph which defaultBorderWidth returns 0. Next, why docking bar should have the same width as menu? The question is do we want docking bar to have border? I see the Playground tool bar is impacted, although it does not make is UI less suitable. In the meantime I just set DockingBarMorph>>defaultBorderWidth to returns 0, so I can use the last build at school with students. By doing so I did not notice glitch.. I am not sure docking bar not having border should be considered as a bug.. Thanks Hilaire Le 09/06/2018 Ã 12:38, Cyril Ferlicot a Ã©critÂ : > > DockingBarMorph>>defaultBorderWidth > Â Â Â Â ^ self theme menuBorderWidth > > > I found the PR I did. > > This code was already here but in another method. > > The difference is that now #themeChanged take the borderWidth into > account. Before it ignored it. So it's probably that before there was > a bug where the docking bar did not matched the theme for the border > and it was corrected. Now, without the bug, you found that the theme > was not as good as you wanted and we need to update the theme. > -- Dr. Geo http://drgeo.eu

June 9, 2018

Web Frameworks and "Modern" Features

by Sean P. DeNigris

Hernan related running into the following limitations with Pharo web frameworks. I wonder if these are all still missing or if any are now availableâ¦ > None of them was easily adapted to the emerging web trends for the last > years like the > appearance of static site generators, adaptive/responsive design, multiple > competing JS > libraries, semantic web, mobility, etc. not to mention they lack > "standard" built-in features > such as caching, template, security frameworks. "adaptive/responsive design" in particular seems like a pretty big limitation given current expectationsâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

Re: [Pharo-dev] ApplicationSecurity Questions

by Sean P. DeNigris

hernanmd wrote > I really loveâ¦ However there a lot of things missing This hints at an issue I've been thinking about a lot lately. It would seem to be a huge boon if frameworks were designed to be more pluggable. The driver of my thoughts were the incompatibility of OSProcess and OSSubprocess, which can't even be loaded at the same time no less plugged in and out! Imagine if we could use Formulas in Seaside, and plug whatever web server into Iliad. It's a shame that each one seems to lock one into an ecosystem - the good with the bad, especially when this kind of stovepiping was one of the very things Smalltalk aimed to avoid! I wonder if there has been any research/experimentation/thinking in this directionâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

Re: [Pharo-dev] Empirical Analysis of Programming Language Adoption

by Sean P. DeNigris

EstebanLM wrote >> A typical discovery / new user will do "senders of" first, and then >> discover the result is far too large. > calypso has the possibility of scoping after look for senders. > â¦often I want to scope several packages Ah! Now I understand the purpose of that feature better, but indeed multi-package selection is a must. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

Re: [Pharo-dev] ApplicationSecurity Questions

by Sean P. DeNigris

hernanmd wrote > (some reasons below). Thanks! Very informative :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 9, 2018

[Pharo 7.0-dev] Build #1030: 22101-OSWindow-keyboard-events-needs-to-be-able-to-be-processed-as-keymap

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1030 was: FAILURE. The Pull Request #1511 was integrated: "22101-OSWindow-keyboard-events-needs-to-be-able-to-be-processed-as-keymap" Pull request url: https://github.com/pharo-project/pharo/pull/1511 Issue Url: https://pharo.fogbugz.com/f/cases/22101 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Cyril Ferlicot

On sam. 9 juin 2018 at 09:48, Hilaire <hilaire(a)drgeo.eu> wrote: > Why ? > > DockingBarMorph>>defaultBorderWidth > ^ self theme menuBorderWidth > I found the PR I did. This code was already here but in another method. The difference is that now #themeChanged take the borderWidth into account. Before it ignored it. So it's probably that before there was a bug where the docking bar did not matched the theme for the border and it was corrected. Now, without the bug, you found that the theme was not as good as you wanted and we need to update the theme. > > Le 09/06/2018 Ã 09:27, Hilaire a Ã©crit : > > I am not there yet, hope to have time. Now I just browse changes from > > github, can see several changed related to use of theme borderwidth > > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr

June 9, 2018

Re: [Pharo-dev] Annoying frame around ToolDockingBarMorph

by Cyril Ferlicot

On sam. 9 juin 2018 at 09:48, Hilaire <hilaire(a)drgeo.eu> wrote: > Why ? > > DockingBarMorph>>defaultBorderWidth > ^ self theme menuBorderWidth > > > Le 09/06/2018 Ã 09:27, Hilaire a Ã©crit : > > I am not there yet, hope to have time. Now I just browse changes from > > github, can see several changed related to use of theme borderwidth > Hi, This is on my todo list to check this problem. I just did not get time yet. If we revert the changes it's the menu bar that will break. I think the previous code already used the #menuBorderWidth from theme but maybe badly and it was broken? I'll check how to correct this. Maybe I'll add to the theme #dockingBarBorderWidth. But I'll probably not have the time this week end. > -- > Dr. Geo > http://drgeo.eu > > > > -- Cyril Ferlicot https://ferlicot.fr

June 9, 2018