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

Re: [Pharo-dev] GTSpotter > code view > class comment

by Andrei Chis

Hi Ben, Could you also create 'would be nice issues' for these requests. Otherwise they will get lost on the mailinglist. On Wed, May 6, 2015 at 2:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > Just a passing thought and request. When the code view is open in Spotter > and a class is selected, could the class comment be shown as well its > definition. > > Maybe also show the class-side definition(?). > > Maybe also show the hierarchy tree as a bread-crumb .e.g. A > B > C (???) > I do not get this one :) Cheers, Andrei > > cheers -ben >

May 6, 2015

Re: [Pharo-dev] Rendering morph list items in NewList

by Yuriy Tymchuk

Should I use another morph? Uko > On 05 May 2015, at 21:03, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Alain Plantec <alain.plantec(a)yahoo.com> > Subject: Re : [Pharo-dev] Rendering morph list items in NewList > Date: 5 May 2015 21:03:45 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello > I ve the impression that it is due to the redrawing of invalid rectangles. Maybe because of a lack of efficienty of the morph list > Alain > De:"Yuriy Tymchuk" <yuriy.tymchuk(a)me.com> > Date:mar j mai PM Ã 14:13 > Objet:[Pharo-dev] Rendering morph list items in NewList > > Hi, > > when I use strings for list items of NewList - everything is fine, but if I use morphs - I get a strange artifacts if another window showers over them. Here is an example video: https://dl.dropboxusercontent.com/u/83145561/morphItems.mov <https://dl.dropboxusercontent.com/u/83145561/morphItems.mov> > > Maybe some morph gurus have an idea whatâs wrong? For now Iâve discovered that all items render themselves with #listRenderOn:atRow:bounds:color:backgroundColor:from: > > Cheers! > Uko > >

May 6, 2015

GTSpotter > code view > class comment

by Ben Coman

Just a passing thought and request. When the code view is open in Spotter and a class is selected, could the class comment be shown as well its definition. Maybe also show the class-side definition(?). Maybe also show the hierarchy tree as a bread-crumb .e.g. A > B > C (???) cheers -ben

May 6, 2015

Re: [Pharo-dev] Rendering morph list items in NewList

by Yuriy Tymchuk

I use just NewList because I need a plain morph. For items I use a method like: listItemFor: anObject | listItem | listItem := Morph new âsetup morph" yourself. âadd submorphs" ^ listItem Uko > On 05 May 2015, at 20:58, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-05-05 14:13 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Hi, > > when I use strings for list items of NewList - everything is fine, but if I use morphs - I get a strange artifacts if another window showers over them. Here is an example video: https://dl.dropboxusercontent.com/u/83145561/morphItems.mov <https://dl.dropboxusercontent.com/u/83145561/morphItems.mov> > > Maybe some morph gurus have an idea whatâs wrong? For now Iâve discovered that all items render themselves with #listRenderOn:atRow:bounds:color:backgroundColor:from: > > I can not reproduce this, how do you draw the items? Did you use NewListModel or do you use just NewList ? > > > Cheers! > Uko >

May 6, 2015

Re: [Pharo-dev] Package comments

by Christophe Demarey

Le 6 mai 2015 Ã 13:21, Kasper Osterbye a Ã©crit : > demarey wrote >> If you want to allow package comments in Nautilus, I would display the >> content of the description method of the package manifest if available. > > It would be great to leverage on something already taking place. > Are you talking about class PackageManifest? > I can see that RPackage has a method which will give me a PackageManifest > (or create a new one). I have not been able to spot "the description method > of the package manifest" (as mentioned by Marcus). Mostly those Manifest > classes seems to be used for other purposes than documentation. Manifest classes were introduced to manage code critics false positives. > I'll try out a few things to see how it can work, my reading of the > "TheManifestBuilder>>createManifestNamed:" shows that manifests would be > very suited for this documentation purpose, as it actually create a > ManifestClass in the package. I believe this class is stored in Monticello > like any other class. right > For the time being I found no instances of PackageManifest, so it is a bit > unclear to me how these Manifest classes store any data? Indeed. There are PackageManifest classes only for projects managing code critics false positives. I created the PackageManifest class to start the decoupling between the manifest and critics, but there is not yet a lot of other tools / project using it (but it will come). Data is stored in raw strings in methods (instance side) of the Manifest. ex: ManifestKernel>>#description ^ 'I am the description of the Pharo Kernel package.'

May 6, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

demarey wrote > If you want to allow package comments in Nautilus, I would display the > content of the description method of the package manifest if available. It would be great to leverage on something already taking place. Are you talking about class PackageManifest? I can see that RPackage has a method which will give me a PackageManifest (or create a new one). I have not been able to spot "the description method of the package manifest" (as mentioned by Marcus). Mostly those Manifest classes seems to be used for other purposes than documentation. I'll try out a few things to see how it can work, my reading of the "TheManifestBuilder>>createManifestNamed:" shows that manifests would be very suited for this documentation purpose, as it actually create a ManifestClass in the package. I believe this class is stored in Monticello like any other class. For the time being I found no instances of PackageManifest, so it is a bit unclear to me how these Manifest classes store any data? -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4824772.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 6, 2015

Re: [Pharo-dev] Package comments

by Marcus Denker

> On 06 May 2015, at 10:53, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 5 mai 2015 Ã 17:14, Kasper Osterbye a Ã©crit : > >> Marcus Denker-4 wrote >>> Right now we do not have yet Package comments. >>> >>> But we should! >>> >>> MBInfo seems to be a private class of Versionnerâ¦ >>> >>> For package comments we first need to evaluate the design spaceâ¦ >>> e.g. where to store it in the image, how to store it in Monticelloâ¦ >> >> OK - Makes sense. >> >> From my perspective, the key to getting this of the ground is to make sure >> such comments can be written and read in Nautilus. The package objects used >> in Nautilus are from "RPackage". >> Thus, the problem, in my view reduces to: >> a) How to make room in RPackage for a comment field (add one more IV) >> b) How to integrate the storage of this field in connection with Monticello >> as Marcus writes. > > I don't think is the good way to do that. > We are working on adding meta-data to packages. These meta-data includes a package description (or comment) but also a lot of other data. > You will not be able to store everything in rpackage inst. var. And of course, there is also the problem that Monticello is not able to store meta-data (e.g. STON files). > For now, the best option is to use a PackageManifest. > > If you want to allow package comments in Nautilus, I would display the content of the description method of the package manifest if available. > Yesâ¦ this could be the easiest for now. Then as a second step, we add support to store resources in Monticello. Marcus

May 6, 2015

Re: [Pharo-dev] Package comments

by Christophe Demarey

Le 5 mai 2015 Ã 17:14, Kasper Osterbye a Ã©crit : > Marcus Denker-4 wrote >> Right now we do not have yet Package comments. >> >> But we should! >> >> MBInfo seems to be a private class of Versionnerâ¦ >> >> For package comments we first need to evaluate the design spaceâ¦ >> e.g. where to store it in the image, how to store it in Monticelloâ¦ > > OK - Makes sense. > > From my perspective, the key to getting this of the ground is to make sure > such comments can be written and read in Nautilus. The package objects used > in Nautilus are from "RPackage". > Thus, the problem, in my view reduces to: > a) How to make room in RPackage for a comment field (add one more IV) > b) How to integrate the storage of this field in connection with Monticello > as Marcus writes. I don't think is the good way to do that. We are working on adding meta-data to packages. These meta-data includes a package description (or comment) but also a lot of other data. You will not be able to store everything in rpackage inst. var. And of course, there is also the problem that Monticello is not able to store meta-data (e.g. STON files). For now, the best option is to use a PackageManifest. If you want to allow package comments in Nautilus, I would display the content of the description method of the package manifest if available. Christophe.

May 6, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

Sergio Fedi wrote > If you need help, or just a buddy to tag along I can work with you.â That would likely be very nice Sergio. I have opened a case in FogBugz (https://pharo.fogbugz.com/f/cases/15495/Package-comments) for this. I believe the result of this work will end up as some kind of slice. I will set up a project on smalltalk hub where this can be done. Right now is time for the next meeting - sighs. -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4824741.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 6, 2015

[pharo-project/pharo-core]

by GitHub

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

May 6, 2015