March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Random refactoring on UITheme or what?

by Hilaire Fernandes

Hello, Well, if you can't do it, don't. I mean there is no obligation to refactor working stuff if you don't have the resource to go from A to Z. It is ok. Then I *don't* understand something else: why so many new themes? It is ridiculous to see PharoTheme, BlueTheme, OrangeTheme, Pharo3Theme. Some are not even working properly. May be there is a logic, but I don't get it. For the broken Vistary theme, I identified the problem, and I'll let Ben apply the fix as it seems appropriate to him[1]. Thanks Hilaire [1] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme Le 22/03/2014 10:42, Sven Van Caekenberghe a Ã©crit : > The theme stuff is really hard and complex. It is impossible to maintain multiple ones, especially if those are seldom used. Maybe it would have been better to remove all those that are not properly maintained. But that would not have made you happy either I guess. > > It is really simple: with the limited resources that we have, we cannot maintain all of them. > > On 22 Mar 2014, at 09:33, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > >> Hello, >> >> <bitter> >> In Pharo3, the UITheme hierarchy seems to have been hit by random >> refactoring (it really looks like that) because it is broken in so many >> place[1][2][3] and in such obvious way (very visible). >> >> It will be nice the random refactorers take(s) full responsibility to do >> the job from A to Z, and not only from A to H. >> </bitter> >> >> [1] https://pharo.fogbugz.com/f/cases/12554/Broken-Watery-theme >> [2] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme >> [3] https://pharo.fogbugz.com/f/cases/13114/Broken-PharoTheme >> >> Thanks >> >> Hilaire >> >> >> -- >> Dr. Geo http://drgeo.eu > > > -- Dr. Geo http://drgeo.eu

March 22, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by Sven Van Caekenberghe

The theme stuff is really hard and complex. It is impossible to maintain multiple ones, especially if those are seldom used. Maybe it would have been better to remove all those that are not properly maintained. But that would not have made you happy either I guess. It is really simple: with the limited resources that we have, we cannot maintain all of them. On 22 Mar 2014, at 09:33, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hello, > > <bitter> > In Pharo3, the UITheme hierarchy seems to have been hit by random > refactoring (it really looks like that) because it is broken in so many > place[1][2][3] and in such obvious way (very visible). > > It will be nice the random refactorers take(s) full responsibility to do > the job from A to Z, and not only from A to H. > </bitter> > > [1] https://pharo.fogbugz.com/f/cases/12554/Broken-Watery-theme > [2] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme > [3] https://pharo.fogbugz.com/f/cases/13114/Broken-PharoTheme > > Thanks > > Hilaire > > > -- > Dr. Geo http://drgeo.eu

March 22, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by phil＠highoctane.be

Themes are hard to change in 2.0 And the darktheme can only come out of serious refactorings I think. So, I've got hope that we move forward on that and there will indeed be serious breakage along the way. Phil On Sat, Mar 22, 2014 at 9:48 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > <bitter> > > In Pharo3, the UITheme hierarchy seems to have been hit by random > > refactoring (it really looks like that) because it is broken in so many > > place[1][2][3] and in such obvious way (very visible). > > > > It will be nice the random refactorers take(s) full responsibility to do > > the job from A to Z, and not only from A to H. > > </bitter> > > > > [1] https://pharo.fogbugz.com/f/cases/12554/Broken-Watery-theme > > [2] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme > > [3] https://pharo.fogbugz.com/f/cases/13114/Broken-PharoTheme > > > > Thanks > > Thanks hilaire. > > Indeed this is sometimes difficult to do things :) > I think that we should be more cautious about > - making sure that changes fully works. I can tell you that when > we worked three days with igor to clean the frame API > it was a huge work but we when over all the corners and nobody saw > even that we worked. > - deprecate more > > Now you see you are the first one to report this. > > Stef >

March 22, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by Pharo4Stef

> <bitter> > In Pharo3, the UITheme hierarchy seems to have been hit by random > refactoring (it really looks like that) because it is broken in so many > place[1][2][3] and in such obvious way (very visible). > > It will be nice the random refactorers take(s) full responsibility to do > the job from A to Z, and not only from A to H. > </bitter> > > [1] https://pharo.fogbugz.com/f/cases/12554/Broken-Watery-theme > [2] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme > [3] https://pharo.fogbugz.com/f/cases/13114/Broken-PharoTheme > > Thanks Thanks hilaire. Indeed this is sometimes difficult to do things :) I think that we should be more cautious about - making sure that changes fully works. I can tell you that when we worked three days with igor to clean the frame API it was a huge work but we when over all the corners and nobody saw even that we worked. - deprecate more Now you see you are the first one to report this. Stef

March 22, 2014

Random refactoring on UITheme or what?

by Hilaire Fernandes

Hello, <bitter> In Pharo3, the UITheme hierarchy seems to have been hit by random refactoring (it really looks like that) because it is broken in so many place[1][2][3] and in such obvious way (very visible). It will be nice the random refactorers take(s) full responsibility to do the job from A to Z, and not only from A to H. </bitter> [1] https://pharo.fogbugz.com/f/cases/12554/Broken-Watery-theme [2] https://pharo.fogbugz.com/f/cases/13112/Broken-Vistary-theme [3] https://pharo.fogbugz.com/f/cases/13114/Broken-PharoTheme Thanks Hilaire -- Dr. Geo http://drgeo.eu

March 22, 2014

Re: [Pharo-dev] Pharo on Debian 7

by HernÃ¡n Morales Durand

Thanks for the instructions Philippe. Just one note: Should be # dpkg --add-architecture i386 and not # dpkg --add architecture i386 Adding a repository could be done with one command: echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list Hernan 2014-03-20 22:31 GMT, phil(a)highoctane.be <phil(a)highoctane.be>: > On my blog > > http://philippeback.be > > Works with some tweaks. > Le 20 mars 2014 21:49, "jannik laval" <jannik.laval(a)gmail.com> a Ã©crit : > >> Hi, >> >> I tried to load Pharo portable on a Debian. It seems to not work. >> Anyone can confirm that this is not my config that is broken ? >> >> Cheers, >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://car.mines-douai.fr/ >> > -- HernÃ¡n Morales Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

March 22, 2014

Re: [Pharo-dev] Pharo on Debian 7

by phil＠highoctane.be

Jannik, Yes it does. Pure Debian 7. Phil On Fri, Mar 21, 2014 at 9:35 PM, jannik laval <jannik.laval(a)gmail.com>wrote: > Thank you guys, I will try your solutions. > Phil, does your tweak works on a 64bits architecture ? > > Damien, the package you provide is for a i386 architecture. I am > downloading the correct iso. > > Cheers, > Jannik > > > 2014-03-21 18:11 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > >> On Thu, Mar 20, 2014 at 10:16 PM, jannik laval <jannik.laval(a)gmail.com> >> wrote: >> > Ok, any solution ? or deb package ? >> >> >> http://files.pharo.org/vm/pharo/linux/debian_ubuntu/ >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> >> > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://car.mines-douai.fr/ >

March 21, 2014

Re: [Pharo-dev] Voyage cannot be load

by Stephan Eggermont

Stef wrote: >Norbert wrote> >> I know. I would wish we would stop having metacello versions that contain dependencies to symbolic versions. >>A tool like versionner should rewrite every symbolic version to a number version when producing a release. > >Indeed! >Christophe is working on that. >Release should not be symbolic! Snapshots are not patchable. I need both snapshots and patches Stephan

March 21, 2014

Re: [Pharo-dev] Pharo on Debian 7

by jannik laval

Thank you guys, I will try your solutions. Phil, does your tweak works on a 64bits architecture ? Damien, the package you provide is for a i386 architecture. I am downloading the correct iso. Cheers, Jannik 2014-03-21 18:11 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Thu, Mar 20, 2014 at 10:16 PM, jannik laval <jannik.laval(a)gmail.com> > wrote: > > Ok, any solution ? or deb package ? > > > http://files.pharo.org/vm/pharo/linux/debian_ubuntu/ > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

March 21, 2014

Re: [Pharo-dev] Nautilus: plugins, PackageTreePackageSelection, PackageTreeTagSelectop, promote, tags, ...

by Pharo4Stef

thanks phil We should do another pass on nautilus. On 21 Mar 2014, at 19:58, phil(a)highoctane.be wrote: > Furthering the investigation: > > With groups, plugins are not working at all as package doesn't exist in DynamicClassGroup etc. > > I fixed the plugin I was interested in but this makes for strange code as: > > >>packageSelected: anAnnouncement > > | package name | > > (anAnnouncement respondsTo: #package) ifTrue: [ > ... > > This is because the announcement comes for a package which is not one. > > even if one has registered it with: > > registerTo: aModel > > aModel announcer > on: NautilusPackageSelected send: #packageSelected: to: self > > Maybe should we have other announcements for these specific items like DynamicClassGroup (e.g. DynamicClassGroupSelected announcement) > > I have made a little plugin to help me explore the selected classes in the left most list. > > Also adding > > RPackage>>package > ^self > > helps with package selected code as without it it is hard to write: > > package node item package > > for both PackageTreeTagSelection and PackageTreePackageSelection > > > This makes the TasksPlugin code like; > > packageSelected: anAnnouncement > > | package | > (anAnnouncement respondsTo: #package) ifTrue: [ > package := anAnnouncement package. > > package > ifNil: [ tasks removeAll ] > ifNotNil: [ > (package node item respondsTo: #package) ifTrue: [ > tasks := (self systemNavigation allCallsOn: 'flag:' asSymbol) select: [ :m | package node item package includesMethod: m selector ofClass: m methodClass ] > ]. > ]. > > > ] ifFalse: [ > tasks removeAll. > ]. > > self changed: #tasks. > > Maybe can we get this leaner with the proposed changes to the announcements. > > Phil > > > > > > On Fri, Mar 21, 2014 at 7:12 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I have been looking at Nautilus plugins as I wanted to be able to export some classes to other formats (e.g. CSV, XML for use with other tools). > > Then, I started playing around with the URLPlugin with its buildString method, which proves helpful to find out about what is selected in the 'list2'. > > So, that's where I started drilling down the rabbit hole... > > So, I see that we have packages and package tags. And actions like promote as true package and demote (which kind of doesn't work and crashes, but I should test further). > > One thing is that this setup breaks the PackageTasks plugin is broken at this point. > > We have: > >>packageSelected: anAnnouncement > package := anAnnouncement package. > ... > tasks := (self systemNavigation allCallsOn: 'flag:' asSymbol) select: [ :m | package includesMethod: m selector ofClass: m methodClass ] ] > > But with the packages and tags, it doesn't work. > > In fact, package is misleading as the announcement contains a PackageTreePackageSelection or a PackageTreeTagSelection. > > Question: how is one filtering on either the package or a given tag? Is this possible? > I saw the >>node and node>>item things. > > I was trying to build the full path (Like "Nautilus-Plugin" from what is selected in the model). > Question; Is there any method for doing that at this point? (e.g. fullTag?) > > Then I tried this: > > Object subclass: #XXXX > instanceVariableNames: '' > classVariableNames: '' > category: 'Nautilus-Nautilus' > > This gets XXXX mixed with the classes in Nautilus under the Nautilus package in the Nautilus tag. > > So, a tag class is mixed with the root package. Not nice. > > What's the underlying model? Is there a doc somewhere? > > Going back to the digging... > > TIA > Phil > > <ExplorePackageSelectedPlugin.st>

March 21, 2014