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

Re: [Pharo-dev] Dynamical resizing of a Nautilus Plugin

by Thierry Goubier

Le 10/09/2015 20:59, Peter UhnÃ¡k a Ã©crit : > Hi, > > is it possible to dynamically resize (or add/remove) plugin in nautilus? > > It seems that plugins are added during build (AbstractNautilusUI>>addAll:), > however is it possible to do at morphic level? > > Because if I resize the morph of the plugin the parent will have empty > space; so probably I would have to move all the morphs underneath it, > but I am not knowledgeable enough of Morphic. > > Since I can freely resize by hand the code pane area I think it should > be possible, but I am lost. :/ Morphic certainly support that. Can't help you about Nautilus, however :( Thierry > > Thanks, > Peter

Sept. 10, 2015

Dynamical resizing of a Nautilus Plugin

by Peter UhnÃ¡k

Hi, is it possible to dynamically resize (or add/remove) plugin in nautilus? It seems that plugins are added during build (AbstractNautilusUI>>addAll:), however is it possible to do at morphic level? Because if I resize the morph of the plugin the parent will have empty space; so probably I would have to move all the morphs underneath it, but I am not knowledgeable enough of Morphic. Since I can freely resize by hand the code pane area I think it should be possible, but I am lost. :/ Thanks, Peter

Sept. 10, 2015

Re: [Pharo-dev] Disable focusing of FastTable

by stepharo

you should introduce it in FTTableMorph Stef Le 10/9/15 00:06, Yuriy Tymchuk a Ã©crit : > Hi, > > is there a nice way to forbid a fast table to take focus? > > because #takesKeyboardFocus is implemented as: â^ self enabledâ. And #enabled is inherited from Morph and is always true. Do I really have to subclass the FTTableMorph just to get rid of focusing? > > Uko >

Sept. 10, 2015

Re: [Pharo-dev] FastTable non-selectable, clickable

by stepharo

yuriy Alain is probably busy but send him a mail. Le 10/9/15 12:10, Yuriy Tymchuk a Ã©crit : > Thanks, Iâll take a look on that. What would be interesting is to add a stripe like line numbers but with critic indicators. Do you know how this should work? > > Uko > >> On 10 Sep 2015, at 12:01, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 10-09-15 11:41, Yuriy Tymchuk wrote: >>> Ideally I want it to be embedded into rubric representation. But I donât know where to start with that. >> Add an instance variable qualitySummary to NautilusAnnotationDisplayer. >> >> add qualitySummary := self qualitySummaryMorph to noteNewOwner: aMorph >> >> in qualitySummaryMorph, return a morph that draws the summary and reacts to click by opening the QA panel. >> >> Stephan >> >> > >

Sept. 10, 2015

Re: [Pharo-dev] FastTable non-selectable, clickable

by stepharo

Stefan We know that the qualityAssistant could be better but for now we should use it and pay attention that yuriy should publish about his research and stay active around :). Stef Le 10/9/15 12:01, Stephan Eggermont a Ã©crit : > On 10-09-15 11:41, Yuriy Tymchuk wrote: >> Ideally I want it to be embedded into rubric representation. But I >> donât know where to start with that. > > Add an instance variable qualitySummary to NautilusAnnotationDisplayer. > > add qualitySummary := self qualitySummaryMorph to noteNewOwner: aMorph > > in qualitySummaryMorph, return a morph that draws the summary and > reacts to click by opening the QA panel. > > Stephan > > >

Sept. 10, 2015

Re: [Pharo-dev] Pharo on iPad Pro

by stepharo

Le 10/9/15 15:31, Stephan Eggermont a Ã©crit : > On 10-09-15 14:57, Aliaksei Syrel wrote: >> Are you Apple's advertisment agent? :D > > No that is a direct quote. I'm just happy that > Apple very slowly seems to move in the right direction. > It will probably need a lot of pressure from EU to keep > going in that direction. That makes them rather similar to Facebook, > Microsoft and Google, and earlier IBM. +1 I want a brick app in such device :) > > Stephan > > > >

Sept. 10, 2015

Re: [Pharo-dev] FogBugz (Case [Issue]16520) CI and Bugtracker - Help topic for how to contribute to Pharo basecode

by stepharo

+ 1 This is important! Stef Le 10/9/15 16:30, Alexandre Bergel a Ã©crit : > Thanks Marcus! > Apparently my two fixes are now in. This is cool! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Sep 10, 2015, at 11:23 AM, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> I did some workaround for now >> >> => disabled some not that useful checks >> => put the timout higher >> >> a normal run is now at around 30 min. >> >> >>> On 09 Sep 2015, at 22:05, Marcus Denker <marcus.denker(a)inria.fr >>> <mailto:marcus.denker@inria.fr>> wrote: >>> >>> It needs to be fixed but I *really* did not find any time yet. >>> >>>> On 09 Sep 2015, at 22:00, Peter UhnÃ¡k <i.uhnak(a)gmail.com >>>> <mailto:i.uhnak@gmail.com>> wrote: >>>> >>>> Maybe change the error message until it is resolved to something >>>> like "Timeout blablabla... this is CI issue, please tell the monkey >>>> to try again". >>>> So people know it's not their error and it will also tell them what >>>> to do, so they (me last week, Alex this week, someone else next >>>> week) don't need to ask again and again. >>>> >>>> Peter >>>> >>>> >>>> On Wed, Sep 9, 2015 at 9:57 PM, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> yes in that case why not fixing that because this is really >>>> really annoying to always get a fix rejected with a bad feedback. >>>> >>>> Stef >>>> >>>> >>>> Le 9/9/15 21:52, Marcus Denker a Ã©crit : >>>> >>>> On 09 Sep 2015, at 20:27, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> Not much mark it as fix to include. >>>> >>>> The last where this was done added an undeclared. Quality >>>> goes down very fast when we add changes without running the >>>> tests. >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>> >> >

Sept. 10, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by stepharo

Pragma should not depend on SystemNavigation. The inverse Le 10/9/15 19:44, Ben Coman a Ã©crit : > On Fri, Sep 11, 2015 at 12:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> The bootstrap-dependency graph and report [1] mark dependency >>> System-Announcements --> PragmaCollector for pruning. This is due to... >>> >>> SystemAnnouncer>>restoreAllNotifications >>> | collector | >>> self reset. >>> collector := PragmaCollector filter: [ :pragma | >>> pragma keyword = #systemEventRegistration ]. >>> collector reset. >>> collector do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector ] >>> >>> Browsing around I came to understand that PragmaCollector is useful as >>> a pragma cache, but here the collector is thrown away, so that >>> facility is not needed. A key part is "collector reset" which does... >>> self class allSystemPragmas >>> do: [:pragma | self addPragma: pragma] >>> >>> where the #addPragma: evaluates the initialize'd #filter: block. Now >>> it seems that #allSystemPragmas might fit nicely on Pragma rather than >>> PragmaCollector >>> such that the following should be equivalent... >>> >>> SystemAnnouncer>>restoreAllNotifications >>> | systemPragmas | >>> self reset. >>> systemPragmas := Pragma allSystemPragmas collect: [ :pragma | >>> pragma keyword = #systemEventRegistration ]. >>> systemPragmas do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector >>> >> Cool. I like that better. >> >>> However #allSystemPragmas depends on SystemNavigation, so is it be >>> okay for Pragma to depend on SystemNavigation? >> Spontaneously Iâd say that SystemNavigation should depend on Pragma or PragmaCollector for looking up pragmas, not the other way around. > So you mean something like... > > SystemAnnouncer>>restoreAllNotifications > self reset. > SystemNavigation allPragmasNamed: #systemEventRegistration do: > [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ]. > > where... > > SystemNavigation>>allPragmasNamed: symbol do: aBlock > | systemPragmas | > systemPragmas := > self allSystemPragmas collect: [ :pragma | pragma keyword > = symbol ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector > > SystemNavigation>>allSystemPragmas > ^ (Array > streamContents: [:stream | > self allBehaviorsDo: [:behavior | > Pragma > withPragmasIn: behavior > do: [:pragma | stream nextPut: pragma]]]) > > cheers -ben > > >>> Actually, class side of Pragma has several #named:in: like methods, so >>> something like the following would be neat... >>> SystemAnnouncer>>restoreAllNotifications >>> self reset. >>> Pragma allNamed: #systemEventRegistration do: [ :pragma | >>> pragma methodClass theNonMetaClass perform: pragma selector ]. >

Sept. 10, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by stepharo

Hi ben I agree with you. I had the impression that many pragmaCollector methods would make sense in Pragma class level. Please continue your analysis. We should drastically clean SystemNavigation. - It should work on environment - remove all the browse behavior. Stef Le 10/9/15 17:22, Ben Coman a Ã©crit : > The bootstrap-dependency graph and report [1] mark dependency > System-Announcements --> PragmaCollector for pruning. This is due to... > > SystemAnnouncer>>restoreAllNotifications > | collector | > self reset. > collector := PragmaCollector filter: [ :pragma | > pragma keyword = #systemEventRegistration ]. > collector reset. > collector do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ] > > Browsing around I came to understand that PragmaCollector is useful as > a pragma cache, but here the collector is thrown away, so that > facility is not needed. A key part is "collector reset" which does... > self class allSystemPragmas > do: [:pragma | self addPragma: pragma] > > where the #addPragma: evaluates the initialize'd #filter: block. Now > it seems that #allSystemPragmas might fit nicely on Pragma rather than > PragmaCollector > such that the following should be equivalent... > > SystemAnnouncer>>restoreAllNotifications > | systemPragmas | > self reset. > systemPragmas := Pragma allSystemPragmas collect: [ :pragma | > pragma keyword = #systemEventRegistration ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector > > However #allSystemPragmas depends on SystemNavigation, so is it be > okay for Pragma to depend on SystemNavigation? > > Actually, class side of Pragma has several #named:in: like methods, so > something like the following would be neat... > SystemAnnouncer>>restoreAllNotifications > self reset. > Pragma allNamed: #systemEventRegistration do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ]. > > cheers -ben > > [1] https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > >

Sept. 10, 2015

improvements of RB are cool!!!!

by stepharo

today I spend a couple of hours refactoring some hiearchies and I had many push them and others... and this was a really experience: - do you want to remove the methods in the other subclasses? oh yes please. We should continue to improve pharo because it is becoming better and better. Stef

Sept. 10, 2015