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@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

Hi Hilaire, There are many themes that needs to be removed (Pharo -is the old one-, Orange, Blue). Then others we need to decide what we do with them. For example, I have the feeling that vistary theme is so bad that no one uses it, but I can be wrong (and maybe is not so bad and is just me who hates the vista look). But watery is very well done and deserves to survive, I think. But well.. some problems are inherent to the “theme” mechanism (the thing that makes buttons not appear on hover for example… it happens almost whenever you change a theme). So… I suppose we need to do both: clean removing the old ones and fix the ones we decide to keep :) Esteban On 22 Mar 2014, at 11:50, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:

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@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

Speaking of that, one will notice that the class comment of UITheme has the examples list: Common superclass for User Interface themes. Provides methods for creating new morphs in a standard way, various "services" like a file dialog, message dialogs etc. and also methods for customising aspects of the appearance of various morphs. Though conceptually abstract, no code is "missing". Subclasses, therefore, should override the aspects they wish to change. UITheme exampleBasicControls UITheme exampleBuilder UITheme exampleColorControls UITheme exampleDialogs UITheme exampleGroups UITheme exampleOtherControls UITheme exampleWindowWithToolbars But in 3.0 it is not in there, it moved to Widgets in 'Morphic-Examples-Widgets' with: ExampleBuilderMorph WidgetExamples Maybe worth a change in the class comment. Phil On Sat, Mar 22, 2014 at 10:42 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:

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@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

Personnally, I find a huge progress in usability of 3.0 tools versus 2.0 which was really awfull. If it must be at the price of broken themes (we can hope temporarily), I buy it. 2014-03-22 15:14 GMT+01:00 Pharo4Stef <pharo4Stef@free.fr>:

...

Speaking of that, one will notice that the class comment of UITheme has the examples list:

Common superclass for User Interface themes. Provides methods for creating new morphs in a standard way, various "services" like a file dialog, message dialogs etc. and also methods for customising aspects of the appearance of various morphs. Though conceptually abstract, no code is "missing". Subclasses, therefore, should override the aspects they wish to change.

UITheme exampleBasicControls UITheme exampleBuilder UITheme exampleColorControls UITheme exampleDialogs UITheme exampleGroups UITheme exampleOtherControls UITheme exampleWindowWithToolbars

But in 3.0 it is not in there, it moved to Widgets in 'Morphic-Examples-Widgets'

indeed!

...

with:

ExampleBuilderMorph WidgetExamples

Maybe worth a change in the class comment.

Yes! I think that many changes missed a deprecation or information to help people migrating.

Pharo3Theme is a renamed glamourTheme under Watery with some leftovers. Maybe a PharoTheme just under UITheme would be cleaner. Phil Le 22 mars 2014 16:49, "Hilaire Fernandes" <hilaire.fernandes@gmail.com> a écrit :

I don't think so. These are orthogonal.

I will propose a simple hierarchy for the theme:

UITheme +-UIPharoTheme +-UIVistaryTheme +-UIWateryTheme

I will propose to delete all the other themes as they should belong to other package.

Hilaire

Le 22/03/2014 15:27, Nicolas Cellier a écrit :

...

Personnally, I find a huge progress in usability of 3.0 tools versus 2.0 which was really awfull. If it must be at the price of broken themes (we can hope temporarily), I buy it.

-- Dr. Geo http://drgeo.eu

Hilaire Fernandes wrote:

Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice. Fixing that as well.

Hilaire

Thanks Hilaire.

Le 22/03/2014 17:10, phil@highoctane.be a écrit :

...

Pharo3Theme is a renamed glamourTheme under Watery with some leftovers.

Maybe a PharoTheme just under UITheme would be cleaner.

I already double checked with Doru that it does not disturb moose (no problem), so I will integrate it now. On 22 Mar 2014, at 20:33, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:

Slice in the Inbox.

https://pharo.fogbugz.com/f/cases/13118/Clean-up-the-mess-in-UITheme-hierarc...

Thanks

Hilaire

Le 22/03/2014 18:11, Ben Coman a écrit :

...

Hilaire Fernandes wrote:

...

Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice

Slice in the Inbox. https://pharo.fogbugz.com/f/cases/13118/Clean-up-the-mess-in-UITheme-hierarc... Thanks Hilaire Le 22/03/2014 18:11, Ben Coman a écrit :

Hilaire Fernandes wrote:

...

Sure. Oh, by the way I realize the Polymoprh examples where scalped in Pharo3 because of the protocol change of ListModel. This is really *not* nice. Fixing that as well.

Hilaire

Thanks Hilaire.

...

Le 22/03/2014 17:10, phil@highoctane.be a écrit :

...

Pharo3Theme is a renamed glamourTheme under Watery with some leftovers.

Maybe a PharoTheme just under UITheme would be cleaner.

-- Dr. Geo http://drgeo.eu

Ben, My personal opinion on that: - Pharo3Theme subclassing UIWatery was not necessary as these two themes have mostly nothing in common - Indeed if you want to only change a base color of watery theme, you have to subclass from it. - For DrGeo on tablet I needed a dedicated theme to remove the windows decoration, for positionning dialog centered on the top, etc., and with the look of watery; so I subclassed from watery. Thanks for the integration work Hilaire Le 26/03/2014 18:08, Ben Coman a écrit :

Just curious to learn... I saw mentioned somewhere that it was bad to subclass themes. What is inherently wrong with that? For example Pharo3Theme was inheriting from UIWateryTheme ? If I wanted my own theme, the same as UIThemeWatery but a different baseColor, should I do... UITheme subclass: MyTheme and copy all methods from UIThemeWatery then modify MyTheme class >> baseColor

or do... UIThemeWatery subclass: MyTheme and add MyTheme class >> baseColor

cheers -ben

-- Dr. Geo http://drgeo.eu