- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Igor Stasenko

On 5 September 2010 12:23, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > >> screenshots PLEASE! > > http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png > No round corners! kewl! :)) > Doru, > > I made the #baseSelectionColor almost black (I didn't like the blue, de gustibus non est disputandum ;-) by overwriting it: > > baseSelectionColor > Â Â Â Â ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker > > I could subclass as well I guess, or you could make it into a variable with a setter, what do you think ? > > Anyway, very well done, it feels very fast, which was a goal I presume. > > Sven > > PS: the name is a nice pun too! > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Sven Van Caekenberghe

On 05 Sep 2010, at 12:02, Tudor Girba wrote: > In my mind, the theme should be the entry point that attaches a name to a consistent design. We already have ThemeSettings which already introduce a lot of complexity and which leads to a mess. I would actually prefer to have only a hierarchy of Themes without any, or in exceptional cases very limited, parametrization options. > > Perhaps the selection color could be made a parameter, but at the moment I would still prefer subclassing. OK, I understand, UIThemes are already complex enough. I'll subclass, the hooks are there (you made some extra elements explicit, so that is good). Sven

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Tudor Girba

Hi, On 5 Sep 2010, at 11:23, Sven Van Caekenberghe wrote: > > On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > >> screenshots PLEASE! > > http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png > > Doru, > > I made the #baseSelectionColor almost black (I didn't like the blue, > de gustibus non est disputandum ;-) by overwriting it: > > baseSelectionColor > ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker :) No comment. > I could subclass as well I guess, or you could make it into a > variable with a setter, what do you think ? In my mind, the theme should be the entry point that attaches a name to a consistent design. We already have ThemeSettings which already introduce a lot of complexity and which leads to a mess. I would actually prefer to have only a hierarchy of Themes without any, or in exceptional cases very limited, parametrization options. Perhaps the selection color could be made a parameter, but at the moment I would still prefer subclassing. > Anyway, very well done, it feels very fast, which was a goal I > presume. Thanks. Speed was a goal indeed. Cheers, Doru > Sven > > PS: the name is a nice pun too! :) -- www.tudorgirba.com "Reasonable is what we are accustomed with."

Sept. 5, 2010

Re: [Pharo-project] glamorous theme :)

by Tudor Girba

Indeed, I struggled with this, too, and I have no idea why it happens. It should overlap with the normal border. It looks like some kind of Morphic voodoo :) Doru On 5 Sep 2010, at 09:37, Sven Van Caekenberghe wrote: > > On 05 Sep 2010, at 09:08, Tudor Girba wrote: > >> Hi Sven, >> >> I am not sure I understand what you are referring to. Could you be >> more explicit? > > Sorry: if you switch to the Pro theme (UIThemePro from the Polymorph- > Themes-Pro package, PharoInbox) and do "UITheme > exampleBasicControls." you get the following window: > > <Screen shot 2010-09-05 at 09.28.50.png> > > The Default Button has an ugly blue border (well the blue border has > the wrong shape). Every dialog has this ugly button that's why it is > a pity because the Theme is otherwise quite nice. > > I really got lost trying to fix this (I lack knowledge of all this > drawing code). But you probably encountered similar problems. > >> The reason I chose square shapes is that as long as we do not have >> proper and fast antialiasing, it requires images (like in the >> watery2 theme) which are time consuming to produce, or it just does >> not look nice. > > Having a fast theme is also a definitive plus, sure. > >> Cheers, >> Doru >> >> On 5 Sep 2010, at 08:23, Sven Van Caekenberghe wrote: >> >>> Hi Doru, >>> >>> Nice indeed, clean & professional, x-platform. I see that you >>> managed to get 'button with focus' (blue border) drawn correctly, >>> even though you subclass 'Watery2' which has round buttons, which >>> was a problem with the Pro theme. I tried to solve it, but I got >>> lost. Maybe you can see what is wrong there ? (see my mail aug 30). >>> >>> Regards, >>> >>> Sven >>> >>> On 04 Sep 2010, at 23:18, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> Over the past week I worked on a new theme for Pharo called the >>>> Glamorous Theme :). The theme is developed in the context of the >>>> Glamour project, and its goal is to create a look that: >>>> - does not look like a specific operating system. In particular, >>>> the icons should be operating system agnostic, because, for >>>> example, people in Windows are confused by the red, yellow, green >>>> buttons of apple. >>>> - uses a limited amount of colors and effects. >>>> >>>> It is still work in progress, but you can get the current version >>>> by executing: >>>> >>>> Gofer new >>>> squeaksource: 'Glamour'; >>>> package: 'Glamour-Morphic-Theme'; >>>> load. >>>> GLMUITheme defaultSettings: nil. >>>> GLMUITheme beCurrent. >>>> GLMUITheme setPreferredWorldBackground. >>>> >>>> Cheers, >>>> Doru > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by Sven Van Caekenberghe

On 05 Sep 2010, at 09:54, StÃ©phane Ducasse wrote: > screenshots PLEASE! http://homepage.mac.com/svc/Screenshots/Screenshot-20100905T111347.png Doru, I made the #baseSelectionColor almost black (I didn't like the blue, de gustibus non est disputandum ;-) by overwriting it: baseSelectionColor ^ "Color r: 0.38 g: 0.64 b: 0.88" Color darkGray muchDarker I could subclass as well I guess, or you could make it into a variable with a setter, what do you think ? Anyway, very well done, it feels very fast, which was a goal I presume. Sven PS: the name is a nice pun too!

Sept. 5, 2010

Re: [Pharo-project] systemNavigation cleaning

by Lukas Renggli

I've split the refactoring model into various packages as outlined in the previous mail. The dependencies between the tests are slightly problematic, but will eventually be fixed as depicted in red in the attached dependency graph. It shouldn't matter for loading, so there is no hurry. Thank you for updating the configuration Mariano. Note that OB-Refactory depends on all the non-test packages. Lukas On 4 September 2010 14:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: > >>>> I agree that SystemNavigation is ugly, but *a lot* of existing code >>>> depends on it. >>> >>> Well if I start forking all the classes that we should fix because there are used it will be endless. >>> I was thinking to start also to look at senders and use deprecate. >>> >>> do you have a lot of external tools that use it? >> >> Yes, all tools use it: >> >> Â Monticello, Paragraph Editor (new and old), OmniBrowser, >> eCompletion, Refactoring Engine. >> >> Now I removed its use from the BrowserEnvironment in the refactoring >> engine itself. There are still a couple of references though, where >> people used the wrong abstraction layer when implementing stuff >> (platform code instead of the abstraction of the refactoring engine). >> >>> So what do you suggest? >>> Separating BrowserEnvironment and its superclass from RB and starting to >>> Â Â Â Â - check its api >>> Â Â Â Â - improve it >>> Â Â Â Â - migrate caller of systemNavigation -> BrowserEnvironment (rename browserEnvironment) >> >> Yeah, maybe one step would be to split the refactoring engine into >> smaller and independent packages: >> >> Â AST-Core (that already is separate) >> Â Refactoring-Environment (this is currently part of > > yes this would be good so that we can start do the idea with the integration related to systemDictionary been a potential leave of the composition > tree we talked last time you visit us. > >> Refactoring-Core, but would work independently) >> Â Refactoring-Changes (this is currently part of Refactoring-Core, >> but would work independently) > > yes I'm curious to see if/how we could use changes to represent changeset. > > >> Â Refactoring-Refactorings (this is currently part of >> Refactoring-Core and depends on all of the above) >> Â Refactoring-Lint (this is currently part of Refactoring-Core and >> depends on all of the above) >> >> Like this Pharo could integrate Refactoring-Environment and >> Refactoring-Changes independently. > > :) > >> I'll see if I can repackage the refactoring browser a bit, might take >> a while though because the tests are not that nicely separated. > > I imagine. > Now incremental changes is the only way for us :) >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 5, 2010

[Pharo-project] Issue 2909

by Pavel Krivanek

Hi, please integrate this issue: http://code.google.com/p/pharo/issues/detail?id=2909 The original version by Stef included two tests of the same selector: self deny: (sels includes: #submorphs). self deny: (sels includes: #submorphs). Was it a purpuse? -- Pavel

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by laurent laffont

I like it. Screenshot: http://picasaweb.google.com/lh/photo/C8Psie5Q-msL2ZDAiIf3BQ?feat=directlink Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Sun, Sep 5, 2010 at 9:54 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > screenshots PLEASE! > On Sep 4, 2010, at 11:18 PM, Tudor Girba wrote: > > > Hi, > > > > Over the past week I worked on a new theme for Pharo called the Glamorous > Theme :). The theme is developed in the context of the Glamour project, and > its goal is to create a look that: > > - does not look like a specific operating system. In particular, the > icons should be operating system agnostic, because, for example, people in > Windows are confused by the red, yellow, green buttons of apple. > > - uses a limited amount of colors and effects. > > > > It is still work in progress, but you can get the current version by > executing: > > > > Gofer new > > squeaksource: 'Glamour'; > > package: 'Glamour-Morphic-Theme'; > > load. > > GLMUITheme defaultSettings: nil. > > GLMUITheme beCurrent. > > GLMUITheme setPreferredWorldBackground. > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 5, 2010

Re: [Pharo-project] [Moose-dev] glamorous theme :)

by StÃ©phane Ducasse

screenshots PLEASE! On Sep 4, 2010, at 11:18 PM, Tudor Girba wrote: > Hi, > > Over the past week I worked on a new theme for Pharo called the Glamorous Theme :). The theme is developed in the context of the Glamour project, and its goal is to create a look that: > - does not look like a specific operating system. In particular, the icons should be operating system agnostic, because, for example, people in Windows are confused by the red, yellow, green buttons of apple. > - uses a limited amount of colors and effects. > > It is still work in progress, but you can get the current version by executing: > > Gofer new > squeaksource: 'Glamour'; > package: 'Glamour-Morphic-Theme'; > load. > GLMUITheme defaultSettings: nil. > GLMUITheme beCurrent. > GLMUITheme setPreferredWorldBackground. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Sept. 5, 2010

[Pharo-project] About using RB changes in Gaucho and Pharo

by Fernando olivero

When i started working on the new Gaucho, i tried to use/understand the current change model without success. So i chose to use the RB engine ( thanks lukas for nicely maintaining it!) In the soon to be released Gaucho1.1 i'm using RB changes to record every change made to the system, changes that take part during a Gaucho development session. So i will be able to provide an insight to the feasability of using RB changes to record and persist sessions, and easily provide undo's . Maybe this work could be plugged into a new Pharo changes system! Fernando pd: BTW, i enhanced the RB changes with AddPackageRefactoring and others related to the UI, ( in this way i'm also recording every UI event ). After the ESUG i will try to integrate the relevant ones to RB. > >> Refactoring-Core, but would work independently) >> Refactoring-Changes (this is currently part of Refactoring-Core, >> but would work independently) > > yes I'm curious to see if/how we could use changes to represent changeset. >

Sept. 5, 2010