September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Alistair Grant

On 14 September 2017 at 09:24, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Thank's guys for comments. And thank's Torsten for this initiative. I will > merge your changes soon. RIGHT. A bit late to the party, but I agree that the right version is much easier to read. Thanks, Alistair > 2017-09-14 7:09 GMT+02:00 Max Leske <maxleske(a)gmail.com>: >> >> Right >> >> >> On 13 September 2017 at 18:08:26, Torsten Bergmann (astares(a)gmx.de) wrote: >> >> Hi all, >> >> as you know Denis Kudriashov does a fantastic job in implementing the new >> Calypso system browser. >> The plan is that at some point in time will be a replacement for Nautilus >> in the standard image. >> Even if not yet integrated one can already use it (either by loading from >> catalog or github [1]) >> >> For me the more I use it (and get used to it) the more I like Calypso and >> I guess others enjoy it too already. >> >> But unfortunately there is a single but very prominently visible UI thing >> that I dislike on the current look: >> >> For the "Pharo3Theme" (light theme) the current implementation of Calypso >> has a white toolbar in the >> middle and a white status bar at the bottom. Technically Dennis sets the >> colors of these morphs to >> transparent to have this effect (see LEFT example of the attached >> screenshot) >> >> >> To me this lookes strange and unusual because >> - usually (on Windows, GTK, Java Swing, Linux window managers) such areas >> like a status bar follow the window color >> and are displayed in gray when that is the default window theme color (see >> [2], [3], [4]) >> - these white bars would better fit for the "Glamorous Whitespace" theme >> (as this theme is already more white areas) >> >> Also the current white bars do not make a pleasant contrast to the other >> panes of Calypso: >> - there is not really a visual distinction to the >> package/class/protocol-tag/method panes and filters for the middle part >> (toolbar) >> - there is not really a visual distinction from the code pane for the >> bottom part (statusbar) >> - the divider line in the code pane just stops in a white area without >> borders >> >> To me this looks rather ugly and I would like Pharo to look more >> professional and clean ;) >> >> So I proposed a simple PR [5] today to change this and technically using >> the window color of the theme - the result can be >> seen on the right side of the attached screenshot and discussed with Denis >> on Discord. >> >> Denis on the other hand still likes the white approach on the left more >> while I prefer the right one. >> >> He wrote that he wants other people comment on this issue first to which I >> agree and therefore I write this mail >> to discuss it here on the dev-list and find out about what the majority in >> the community prefers. >> >> So it would be good if others could >> - comment about their personal preference >> - or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) >> in reply to this mail >> - or make another proposal (which is only accepted with screenshot and PR >> ;) >> >> Also please do not mix other UI discussions into this thread. Thanks in >> advance! >> >> Bye >> T. >> >> [1] https://github.com/dionisiydk/Calypso >> [2] >> http://cdn.osxdaily.com/wp-content/uploads/2011/08/show-status-bar-and-disk… >> [3] http://i.stack.imgur.com/pgt5n.png >> [4] http://python.zirael.org/gtk-statusbar1-1.png >> [5] https://github.com/dionisiydk/Calypso/pull/91 > >

Sept. 14, 2017

Re: [Pharo-dev] Sources location and name, PharoLauncher

by Peter UhnÃ¡k

That's not related to Pharo Launcher. Pharo 7 sources (for alpha images) are now shipped with the image, not the VM. Peter On Thu, Sep 14, 2017 at 2:45 PM, stephan <stephan(a)stack.nl> wrote: > After Peter's tweet about the automatic downloading of a vm I decided to > try the improved PharoLauncher myself. I like the automatic downloading of > a vm. When trying it, I noticed that the sources dependency changed to a > very unusable one: each image needs its own specific sources file. > > Stephan > > > > > >

Sept. 14, 2017

Sources location and name, PharoLauncher

by stephan

After Peter's tweet about the automatic downloading of a vm I decided to try the improved PharoLauncher myself. I like the automatic downloading of a vm. When trying it, I noticed that the sources dependency changed to a very unusable one: each image needs its own specific sources file. Stephan

Sept. 14, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #125: SUCCESS

by Pavel Krivanek

the build is red, not success -- Pavel 2017-09-14 11:18 GMT+02:00 <ci-pharo-ci-jenkins2(a)inria.fr>: > There is a new Pharo build available! > > The status of the build #125 was: SUCCESS. > > Could not extract further issue information from commit message: Merge > pull request #278 from guillep/20421-Email-should- > run-in-a-node-and-separate-stage-to-be-sent > > Case 20421: make email run in a unix node > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/125/ >

Sept. 14, 2017

[Pharo 7.0-dev] Build #125: SUCCESS

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

There is a new Pharo build available! The status of the build #125 was: SUCCESS. Could not extract further issue information from commit message: Merge pull request #278 from guillep/20421-Email-should-run-in-a-node-and-separate-stage-to-be-sent Case 20421: make email run in a unix node Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 14, 2017

Re: [Pharo-dev] [Ann][Pillar] Travis -> Bintray for PDFs

by stephan

On 25-08-17 16:42, Stephane Ducasse wrote: > I'm writing a doc of the process so that other people can do it for > their private projects. I know how to copy and rename an existing project, and put that on github. What else do I need to do? Register with bintray, register with travis, generate keys in some way? Stephan

Sept. 14, 2017

Re: [Pharo-dev] Author name in version Iceberg?

by Esteban Lorenzano

> On 14 Sep 2017, at 10:53, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > AFAIK Esteban is planning to support blame in future at least for Tonel (the FileTree replacement), however we are not yet there. this ^ (but we will support it for both: filetree AND tonel, if possible/easy/not hard to maintain) cheers, Esteban > > -- Pavel > > 2017-09-14 10:50 GMT+02:00 stephan <stephan(a)stack.nl <mailto:stephan@stack.nl>>: > On 14-09-17 10:06, Pavel Krivanek wrote: > Iceberg currently uses metadata-less format that does not store method timestamp because of the merging conflicts. You cannot do anything now, sorry. > > No support for blame? > > Stephan > > >

Sept. 14, 2017

Re: [Pharo-dev] Author name in version Iceberg?

by Pavel Krivanek

AFAIK Esteban is planning to support blame in future at least for Tonel (the FileTree replacement), however we are not yet there. -- Pavel 2017-09-14 10:50 GMT+02:00 stephan <stephan(a)stack.nl>: > On 14-09-17 10:06, Pavel Krivanek wrote: > >> Iceberg currently uses metadata-less format that does not store method >> timestamp because of the merging conflicts. You cannot do anything now, >> sorry. >> > > No support for blame? > > Stephan > > >

Sept. 14, 2017

Re: [Pharo-dev] Author name in version Iceberg?

by stephan

On 14-09-17 10:06, Pavel Krivanek wrote: > Iceberg currently uses metadata-less format that does not store method > timestamp because of the merging conflicts. You cannot do anything now, > sorry. No support for blame? Stephan

Sept. 14, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Denis Kudriashov

Hello. I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. Here is the new messages: - pinInMemory - unpinInMemory - isPinnedInMemory - setPinnedInMemory: What was decision about #pinInMemoryDuring: ? Do we need it? 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > +1 for pinInMemory > > It explains what it does. > > On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Norbert, > > > >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> > >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com > >: > >>> > >>> Hi Denis, > >>> > >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < > dionisiydk(a)gmail.com> > >>> wrote: > >>>> Hi Eliot. > >>>> > >>>> I know and I only talk about new messages. I am not trying to rethink > >>>> full meta model of Smalltalk. > >>>> By the way #class is very common message and it is handy to use short > >>>> name. But pinning messages will be used rarely in very specific > >>>> applications. So no much sense to preserve them in short version. > >>> > >>> Agreed. So we have to decide whether to go with pinInMemory or > >>> pinObject, pinObject being suggested by Norbert because it matched > >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel > >>> strongly about pinObject et al? > >>> > >> No I don't. It feels only good to me if there is a requirement not to > >> implement selectors that are likely to be used in user code. I'm ok with > >> pinInMemory although I asked myself where can it be pinned elsewhere if > >> not in memory. So the suffix in memory doesn't add anything but also > moves > >> the selector out of user space. > > > > Well I think Denis' point is that pinInMemory removes ambiguity with pin > for > > other uses and I agree. So I for one am happy to change it to > pinInMemory > > et al. > > > >> > >> Norbert > >> > >>>> > >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >>>>> Hi Denis, > >>>>> > >>>>> > >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com > > > >>>>>> wrote: > >>>>>> > >>>>>> I am really wonder guys. I thought you are not big funs of Object > >>>>>> protocol. > >>>>>> Current pinning messages are a new set of very generic messages in > the > >>>>>> Object. > >>>>> > >>>>> Yes, and that's because this is a fundamental property of all > >>>>> non-immediate objects. Do you object to the #class message? Should > it > >>>>> be #classObject because it might conflict with #class used in an > >>>>> educational or socioeconomic model? All objects other than > immediates > >>>>> can move. Pinning stops that movement. It applies generally. So > the > >>>>> protocol belongs in Object. > >>>>> > >>>>> > >>>>>> > >>>>>> About Norbert idea. > >>>>>> - bePinnedObject is not bad convention. But I would prefer the > memory > >>>>>> suffix because it reflects the low level behaviour. > >>>>>> > >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >>>>>>> yes, me :) > >>>>>>> > >>>>>>> I do not see a reason to change them, tbh. > >>>>>>> for me they are comprensible as they are now and it does not adds > >>>>>>> more information pinInMemory or pinMemory. > >>>>>>> > >>>>>>> Esteban > >>>>>>> > >>>>>>> > >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Anybody else? > >>>>>>>> > >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek > >>>>>>>> <pavel.krivanek(a)gmail.com>: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov > >>>>>>>>> <dionisiydk(a)gmail.com>: > >>>>>>>>>> Hi. > >>>>>>>>>> > >>>>>>>>>> We now have very generic message names: > >>>>>>>>>> - pin > >>>>>>>>>> - unpin > >>>>>>>>>> - setPinned: > >>>>>>>>>> - isPinned > >>>>>>>>>> > >>>>>>>>>> Problem that they collide with possible domain related names. > >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found > >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with > >>>>>>>>>> different names. > >>>>>>>>>> Probably menus also uses pin word but without overrides > >>>>>>>>>> > >>>>>>>>>> What you think about renaming pinning messages? Something like: > >>>>>>>>>> - pinMemory > >>>>>>>>> > >>>>>>>>> I would use pinInMemory > >>>>>>>>> > >>>>>>>>> -- Pavel > >>>>>>>>> > >>>>>>>>>> - unpinMemory > >>>>>>>>>> - isMemoryPinned > >>>>>>>>>> - setPinnedMemory: > >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) > >>>>>>>>>> > >>>>>>>>>> I think it is easy to do now because not much code uses pinning > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> _,,,^..^,,,_ > >>> best, Eliot > >> > > > >

Sept. 14, 2017