Chris Muller uploaded a new version of SMLoader to project The Trunk:
http://source.squeak.org/trunk/SMLoader-cmm.85.mcz ==================== Summary ==================== Name: SMLoader-cmm.85 Author: cmm Time: 15 September 2015, 2:58:07.033 pm UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b Ancestors: SMLoader-dtl.84 Revert dtl.84, because it broke the Catalog filters. =============== Diff against SMLoader-dtl.84 =============== Item was changed: ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') ----- packageListCalculated "Return a list of the SMPackages that should be visible by applying all the filters. Also filter based on the currently selected category - if any." ^ self packages select: [:p | + filters allSatisfy: [:currFilter | - filters anySatisfy: [:currFilter | currFilter isSymbol ifTrue: [(self perform: currFilter) value: p] ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]! |
After review and some thought, it has become clear to me that Dave's
change is incorrect. Please take a look at the SqueakMap filters and consider them from the context of the use-cases -- what users need to do with SqueakMap, and NOT from the context of a database that needs to produce generalized "query results" <---- because it doesn't. "Published" are the ones which have software to install, while "Auto-installable" shows only packages that are installable from the "Install" menu selection within the image. These two filters are useful together in a restricting fashion, not an inflating one, so that newbies can see what's ready to go. It was then that I also realized that Hannes' combination was not a use-case either. The use-cases we have are: 1) user wants to install software or, 2) user wants to see what they have already installed. Seeing a cumulative list of both installed and uninstalled satisfies neither use-case. Nevertheless you may once again "Clear all filters" (which was broken by Dave's commit) if you want to see everything. I still say SqueakMap catalog can and needs improvement, but we need to really consider our changes because its clear that Göran put a lot of thought into the usage of SqueakMap and its role in the community; so I think we can afford to be a bit more skeptical before thinking something like that was a bug in the first place and for nine years running.. On Tue, Sep 15, 2015 at 2:58 PM, <[hidden email]> wrote: > Chris Muller uploaded a new version of SMLoader to project The Trunk: > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz > > ==================== Summary ==================== > > Name: SMLoader-cmm.85 > Author: cmm > Time: 15 September 2015, 2:58:07.033 pm > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b > Ancestors: SMLoader-dtl.84 > > Revert dtl.84, because it broke the Catalog filters. > > =============== Diff against SMLoader-dtl.84 =============== > > Item was changed: > ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists') ----- > packageListCalculated > "Return a list of the SMPackages that should be visible > by applying all the filters. Also filter based on the currently > selected category - if any." > ^ self packages select: [:p | > + filters allSatisfy: [:currFilter | > - filters anySatisfy: [:currFilter | > currFilter isSymbol > ifTrue: [(self perform: currFilter) value: p] > ifFalse: [self package: p filteredByCategory: (map object: currFilter)]]]! > > |
Maybe it would be nice if the filters where off when opening the SqueakMap browser. With filters on it seems to be empty and not functioning. There is always warnings about package not being compatible when you try to load them anyway. Karl On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller <[hidden email]> wrote: After review and some thought, it has become clear to me that Dave's |
> Maybe it would be nice if the filters where off when opening the SqueakMap
> browser. With filters on it seems to be empty and not functioning. No. Just a gentle reminder, the best way to talk about SqueakMap and figure out how to improve it is to orient ourselves with the requirements: http://wiki.squeak.org/squeak/6183 Presenting everything in the list would violate requirement #4. Publishers who simply follow these publishing guidelines [1] are able to meet these requirements, and so what users see in the list is what WORKS. If we show "everything" then we're hiding what works, and SM becomes useless again. Why do you say its an empty list? I just checked Squeak 5.0 and there are at least 20 packages showing up in there..? IF nothing were to show up in the list when "Safely-available" filter (and nothing else) is checked, then that's on us as a community. It simply means that we didn't care enough to take the 5 minutes necessary to recertify our packages for the latest Squeak. It is what it is, but let's not fake out the "truth". Thankfully, we DON'T have a blank list in 5.0. Thanks to those in the community who have gotten on board with the publishing guidelines we have packages on SM that actually WORK (if they were done right) and have single one of those requirements met. Users are able to consume those packages with one click instead of being forced to come begging to the list for "how to load it".. We will get there! [1] -- SqueakMap Publishing Guidelines http://wiki.squeak.org/squeak/6182 [2] -- How to designate existing SqueakMap packages for a new version of Squeak http://wiki.squeak.org/squeak/6180 > There is always warnings about package not being compatible when you try to > load them anyway. > > Karl > > On Tue, Sep 15, 2015 at 10:04 PM, Chris Muller <[hidden email]> wrote: >> >> After review and some thought, it has become clear to me that Dave's >> change is incorrect. Please take a look at the SqueakMap filters and >> consider them from the context of the use-cases -- what users need to >> do with SqueakMap, and NOT from the context of a database that needs >> to produce generalized "query results" <---- because it doesn't. >> >> "Published" are the ones which have software to install, while >> "Auto-installable" shows only packages that are installable from the >> "Install" menu selection within the image. These two filters are >> useful together in a restricting fashion, not an inflating one, so >> that newbies can see what's ready to go. >> >> It was then that I also realized that Hannes' combination was not a >> use-case either. The use-cases we have are: 1) user wants to install >> software or, 2) user wants to see what they have already installed. >> Seeing a cumulative list of both installed and uninstalled satisfies >> neither use-case. >> >> Nevertheless you may once again "Clear all filters" (which was broken >> by Dave's commit) if you want to see everything. >> >> I still say SqueakMap catalog can and needs improvement, but we need >> to really consider our changes because its clear that Göran put a lot >> of thought into the usage of SqueakMap and its role in the community; >> so I think we can afford to be a bit more skeptical before thinking >> something like that was a bug in the first place and for nine years >> running.. >> >> >> On Tue, Sep 15, 2015 at 2:58 PM, <[hidden email]> wrote: >> > Chris Muller uploaded a new version of SMLoader to project The Trunk: >> > http://source.squeak.org/trunk/SMLoader-cmm.85.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: SMLoader-cmm.85 >> > Author: cmm >> > Time: 15 September 2015, 2:58:07.033 pm >> > UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b >> > Ancestors: SMLoader-dtl.84 >> > >> > Revert dtl.84, because it broke the Catalog filters. >> > >> > =============== Diff against SMLoader-dtl.84 =============== >> > >> > Item was changed: >> > ----- Method: SMLoaderPlus>>packageListCalculated (in category >> > 'lists') ----- >> > packageListCalculated >> > "Return a list of the SMPackages that should be visible >> > by applying all the filters. Also filter based on the currently >> > selected category - if any." >> > ^ self packages select: [:p | >> > + filters allSatisfy: [:currFilter | >> > - filters anySatisfy: [:currFilter | >> > currFilter isSymbol >> > ifTrue: [(self perform: currFilter) >> > value: p] >> > ifFalse: [self package: p >> > filteredByCategory: (map object: currFilter)]]]! >> > >> > >> > |
Ok Karl On Wed, Sep 16, 2015 at 6:39 PM, Chris Muller <[hidden email]> wrote: > Maybe it would be nice if the filters where off when opening the SqueakMap |
Free forum by Nabble | Edit this page |