- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] spotter usage - a rough analysis of categories

by Tudor Girba

Hi, > On Jun 10, 2016, at 10:55 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > On Fri, Jun 10, 2016 at 4:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito(a)gmail.com> wrote: >>> >>> I use spotter a lot as well. >> >> Me too ! >> >>> It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace. >> >> Indeed, same here. >> >>> The things I look most by name are tools (Menu entries), classes and packages. >>> >>> History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else. >>> >>> Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: >>> - open spotter >>> - type "Process" >>> >>> you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category. >>> >>> Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session? >> >> Some simple learning would be super cool. >> >>> Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them. >> >> Yes, that is indeed something that I miss as well: browsing them all. > > I often worry one day someone will remove the Senders <meta-n> and > Implementors <meta-m> windows since Spotter *mostly* supersedes them, > but actually they fill different needs. Spotter is transient. It > opens quickly from anywhere, helps you go to what you want and then it > hides itself away. But often I have several different Senders / > Implementers windows open for hours at a time, and its nice to flip > back and forth between implementations and make edits there. For > example, I want to add a halt in every implementer. > > In the past I asked editing capability in the Spotter code window, > but with Spotters transitive nature maybe is not the best place to > make edits. Exactly :). In the current form, Spotter serves the role of opening a conversation with objects (or code). It is not yet enough for sustaining that conversation. So, we still need a solution for working with a subset of elements for longer periods of time. Cheers, Doru > cheers -ben > >> >> Sven >> >>> Guille >>> >>> -------- Original Message -------- >>>> and just another thing :) >>>> >>>> I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damienâ¦ I do not remember the name, but it has a name) that thing that you type âabcâ and it will find >>>> - abc >>>> - absoluteBinaryCapability >>>> - AbstractBlooperContext >>>> - etc >>>> >>>> I think it is a super functionality (and it was fast), that should be included by default. >>>> >>>> Esteban >>>> >>>>> On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :) >>>>> >>>>> Esteban >>>>> >>>>>> On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> I need to enable data collect ;) >>>>>> >>>>>> in my case, Iâm a happy Spotter userâ¦ I even have a plugin I made for my own that fits my way of work with repositoriesâ¦ anyway, I wanted to point: >>>>>> >>>>>> - I use a lot Classes/Methods/Packages... and catalog >>>>>> - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) >>>>>> - some categories seems confusing >>>>>> - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground >>>>>> - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1â¦ etc) >>>>>> >>>>>> I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :) >>>>>> >>>>>> cheers! >>>>>> Esteban >>>>>> >>>>>>> On 10 Jun 2016, at 08:42, Max Leske <maxleske(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Doru, >>>>>>> >>>>>>> I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process). >>>>>>> >>>>>>> Cheers, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On 10 Jun 2016, at 00:56, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members. >>>>>>>> >>>>>>>> Of these 34 used the dive-in feature. That is, these users used at least one contextual search. >>>>>>>> >>>>>>>> We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it: >>>>>>>> >>>>>>>> <spotter-categories-distribution.png> >>>>>>>> >>>>>>>> 'Classes'->40 >>>>>>>> 'Implementors'->38 >>>>>>>> 'History'->34 >>>>>>>> 'Menu'->24 >>>>>>>> 'Packages'->23 >>>>>>>> 'Messages'->19 >>>>>>>> 'Catalog Projects'->12 >>>>>>>> 'Instance methods'->10 >>>>>>>> 'Senders'->9 >>>>>>>> 'Pragmas'->6 >>>>>>>> 'References'->5 >>>>>>>> 'Playground named pages'->5 >>>>>>>> 'Playground cached pages'->4 >>>>>>>> 'Help topics'->4 >>>>>>>> 'Examples'->3 >>>>>>>> 'Super instance methods'->3 >>>>>>>> 'Selectors'->3 >>>>>>>> 'ws.stfx.eu'->2 >>>>>>>> 'GitHub Baselines'->2 >>>>>>>> 'Dirty Monticello packages'->2 >>>>>>>> 'Class methods'->2 >>>>>>>> 'Global variables'->1 >>>>>>>> 'All subclasses'->1 >>>>>>>> 'Example Subjects'->1 >>>>>>>> 'Files'->1 >>>>>>>> 'Monticello Repositories'->1 >>>>>>>> 'Metacello Configurations'->1 >>>>>>>> 'Class instance variables'->1 >>>>>>>> 'Items'->1 >>>>>>>> 'Tags'->1 >>>>>>>> 'Help contents'->1 >>>>>>>> 'Monticello Package'->1 >>>>>>>> 'Instance variables'->1 >>>>>>>> 'Productions'->1 >>>>>>>> 'Methods'->1 >>>>>>>> >>>>>>>> Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods). >>>>>>>> >>>>>>>> As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages. >>>>>>>> >>>>>>>> We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE. >>>>>>>> >>>>>>>> This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.feenk.com >>>>>>>> >>>>>>>> "Value is always contextual." -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

June 10, 2016

changes in latest Athens configuration

by Nicolai Hess

ConfigurationOfAthens project version:'3.9.6' see case 18445 <https://pharo.fogbugz.com/f/cases/18445/ConfigurationOfAthens-is-not-in-syn…> ConfigurationOfAthens is not in sync with current Pharo packages Why do we merge compositing modes with "paint options"? I would consider a compositing mode as a "mode" for current drawing operations and the antialiasing setting is only a "hint" for the backend, it may be completly ignored. Or am I confused with the font rendering antialiasing hint? Can we paint by set compositing mode do paint set different compositing set antialiasing mode do paint set different antialiasing mode do paint does it work that way (and would it make sense)? nicolai

June 10, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60077 Home: https://github.com/pharo-project/pharo-core

June 10, 2016

[pharo-project/pharo-core] fd504e: 60077

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fd504e953b3a85b91c4239eb32dffba12765614e https://github.com/pharo-project/pharo-core/commit/fd504e953b3a85b91c4239eb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/README.md R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/accessing/project.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/development support/DevelopmentSupport.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/development support/validate.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/loading/load.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/loading/loadBleedingEdge.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/loading/loadDevelopment.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/metacello tool support/isMetacelloConfig.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/private/baseConfigurationClassIfAbsent_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/private/ensureMetacello.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/class/private/ensureMetacelloBaseConfiguration.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/definition.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/accessing/customProjectAttributes.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/accessing/project.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/baselines/baseline10_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/baselines/baseline112_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/development_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/stable_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version100_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version110_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version111_.st R ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version112_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/README.md R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/accessing/project.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/loading/load.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/loading/loadDefault.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/loading/loadDevelopment.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/metacello tool support/isMetacelloConfig.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/class/private/ensureMetacello.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/definition.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/accessing/project.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline01_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline02_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline10_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline20_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline21_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline22_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline23_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/development_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version10_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version110_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version111_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version112_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version113_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version114_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version115_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1161_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1162_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1163_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1164_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1165_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1166_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version116_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version117_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1181_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1182_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1183_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1184_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1185_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1186_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1187_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version118_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version11_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1210_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1211_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1212_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1213_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1214Moose51_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1214_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1215_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1216_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1217_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version121_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version122_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version123_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version124_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version125_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version126_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version127_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version128_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version129_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version12_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version131_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version132_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version133_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version134_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version135_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version136_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version137_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version13_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version141_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version142_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version143_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version14_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version15_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version16_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version17_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version18_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version19_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version20_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version210_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version211_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version212_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version213_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version214_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version215_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version216_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version217_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version218_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2191_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2192_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2193_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2194_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version219_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version21_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2201_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2202_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version220_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version22_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version23_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version241_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version242_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version24_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version25_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version26_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version27_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version281_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version28_.st R ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version29_.st M OpalCompiler-Core.package/OpalEncoderForV3.class/README.md R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60076.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60077.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60076.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60077.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60077 18466 Make Rubric packages internal https://pharo.fogbugz.com/f/cases/18466 18465 EncoderForV3 does not have its specification in its comment https://pharo.fogbugz.com/f/cases/18465 18467 Make CodeImporter interal https://pharo.fogbugz.com/f/cases/18467 http://files.pharo.org/image/60/60077.zip

June 10, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60076 Home: https://github.com/pharo-project/pharo-core

June 10, 2016

[pharo-project/pharo-core] 10f999: 60076

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 10f9990590fb81e9e10e10e802088886a9c822bf https://github.com/pharo-project/pharo-core/commit/10f9990590fb81e9e10e10e8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version2202_.st M Rubric.package/RubTextSegmentMorph.class/instance/drawing/displayIconAt_onAthensCanvas_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60075.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60076.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60075.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60076.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60076 18464 Update ConfigurationOfRubric to 2.20.2 https://pharo.fogbugz.com/f/cases/18464 http://files.pharo.org/image/60/60076.zip

June 10, 2016

Re: [Pharo-dev] spotter usage - a rough analysis of categories

by Ben Coman

On Fri, Jun 10, 2016 at 4:11 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> I use spotter a lot as well. > > Me too ! > >> It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace. > > Indeed, same here. > >> The things I look most by name are tools (Menu entries), classes and packages. >> >> History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else. >> >> Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: >> - open spotter >> - type "Process" >> >> you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category. >> >> Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session? > > Some simple learning would be super cool. > >> Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them. > > Yes, that is indeed something that I miss as well: browsing them all. I often worry one day someone will remove the Senders <meta-n> and Implementors <meta-m> windows since Spotter *mostly* supersedes them, but actually they fill different needs. Spotter is transient. It opens quickly from anywhere, helps you go to what you want and then it hides itself away. But often I have several different Senders / Implementers windows open for hours at a time, and its nice to flip back and forth between implementations and make edits there. For example, I want to add a halt in every implementer. In the past I asked editing capability in the Spotter code window, but with Spotters transitive nature maybe is not the best place to make edits. cheers -ben > > Sven > >> Guille >> >> -------- Original Message -------- >>> and just another thing :) >>> >>> I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damienâ¦ I do not remember the name, but it has a name) that thing that you type âabcâ and it will find >>> - abc >>> - absoluteBinaryCapability >>> - AbstractBlooperContext >>> - etc >>> >>> I think it is a super functionality (and it was fast), that should be included by default. >>> >>> Esteban >>> >>>> On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :) >>>> >>>> Esteban >>>> >>>>> On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> I need to enable data collect ;) >>>>> >>>>> in my case, Iâm a happy Spotter userâ¦ I even have a plugin I made for my own that fits my way of work with repositoriesâ¦ anyway, I wanted to point: >>>>> >>>>> - I use a lot Classes/Methods/Packages... and catalog >>>>> - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) >>>>> - some categories seems confusing >>>>> - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground >>>>> - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1â¦ etc) >>>>> >>>>> I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :) >>>>> >>>>> cheers! >>>>> Esteban >>>>> >>>>>> On 10 Jun 2016, at 08:42, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> >>>>>> Hi Doru, >>>>>> >>>>>> I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process). >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> >>>>>>> On 10 Jun 2016, at 00:56, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members. >>>>>>> >>>>>>> Of these 34 used the dive-in feature. That is, these users used at least one contextual search. >>>>>>> >>>>>>> We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it: >>>>>>> >>>>>>> <spotter-categories-distribution.png> >>>>>>> >>>>>>> 'Classes'->40 >>>>>>> 'Implementors'->38 >>>>>>> 'History'->34 >>>>>>> 'Menu'->24 >>>>>>> 'Packages'->23 >>>>>>> 'Messages'->19 >>>>>>> 'Catalog Projects'->12 >>>>>>> 'Instance methods'->10 >>>>>>> 'Senders'->9 >>>>>>> 'Pragmas'->6 >>>>>>> 'References'->5 >>>>>>> 'Playground named pages'->5 >>>>>>> 'Playground cached pages'->4 >>>>>>> 'Help topics'->4 >>>>>>> 'Examples'->3 >>>>>>> 'Super instance methods'->3 >>>>>>> 'Selectors'->3 >>>>>>> 'ws.stfx.eu'->2 >>>>>>> 'GitHub Baselines'->2 >>>>>>> 'Dirty Monticello packages'->2 >>>>>>> 'Class methods'->2 >>>>>>> 'Global variables'->1 >>>>>>> 'All subclasses'->1 >>>>>>> 'Example Subjects'->1 >>>>>>> 'Files'->1 >>>>>>> 'Monticello Repositories'->1 >>>>>>> 'Metacello Configurations'->1 >>>>>>> 'Class instance variables'->1 >>>>>>> 'Items'->1 >>>>>>> 'Tags'->1 >>>>>>> 'Help contents'->1 >>>>>>> 'Monticello Package'->1 >>>>>>> 'Instance variables'->1 >>>>>>> 'Productions'->1 >>>>>>> 'Methods'->1 >>>>>>> >>>>>>> Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods). >>>>>>> >>>>>>> As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages. >>>>>>> >>>>>>> We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE. >>>>>>> >>>>>>> This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "Value is always contextual." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > >

June 10, 2016

Re: [Pharo-dev] CodeImporter and Rubric will not be external projects managed by configurations

by Nicolai Hess

I don't much about code importer, but +1 for rubric 2016-06-10 10:50 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Yes, good idea, external projects only make sense if they really can exist > outside Pharo and if they are actively maintained as such. > > > On 10 Jun 2016, at 10:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > Hi, > > > > to make our and your lifes easier we want to stop to manage CodeImporter > and Rubric as external projects. For CodeImporter it makes no sense to have > it as external project and moreover why to have special configuration for > only one package. The Rubric has a lot of small updates, not defined > maintainer and manage it externally is a pain for everyone. > > > > Let us know if you have something against it. > > > > Cheers, > > -- Pavel > > >

June 10, 2016

Re: [Pharo-dev] CodeImporter and Rubric will not be external projects managed by configurations

by Sven Van Caekenberghe

Yes, good idea, external projects only make sense if they really can exist outside Pharo and if they are actively maintained as such. > On 10 Jun 2016, at 10:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > to make our and your lifes easier we want to stop to manage CodeImporter and Rubric as external projects. For CodeImporter it makes no sense to have it as external project and moreover why to have special configuration for only one package. The Rubric has a lot of small updates, not defined maintainer and manage it externally is a pain for everyone. > > Let us know if you have something against it. > > Cheers, > -- Pavel

June 10, 2016

CodeImporter and Rubric will not be external projects managed by configurations

by Pavel Krivanek

Hi, to make our and your lifes easier we want to stop to manage CodeImporter and Rubric as external projects. For CodeImporter it makes no sense to have it as external project and moreover why to have special configuration for only one package. The Rubric has a lot of small updates, not defined maintainer and manage it externally is a pain for everyone. Let us know if you have something against it. Cheers, -- Pavel

June 10, 2016