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

Re: [Pharo-dev] Let's talk about Themes
by Stephan Eggermont Nov. 10, 2014

Nov. 10, 2014

Kilon wrote: >Thanks Stephan for your honest answer :) Sorry about the negative attitude. Making sure that the window color in the preferences correctly reflects the one in the theme would already be a great improvement. You are correct that editing the theme in the settings would quickly become a mess. It would be a good idea to develop a theme editor that can directly show the effects of all its settings. That is difficult, as you need to make sure that you can always see the effect of changes. For small changes (space between text lines) you might need something like a looking glass. You also need some way of finding out what settings might be related to what you are trying to do. If the line height is a calculation of text size and interline distance, you want to be able to find that out. Stephan

2 1

Re: [Pharo-dev] Let's talk about Themes
by Stephan Eggermont Nov. 10, 2014

Nov. 10, 2014

Kilon wrote: >Actually my point was the creation of themes, thats what a theme manager does. No its not easy, its not easy to have to go to the System Browser find Dark Theme class, try to guess which method is responsible >for the background color and then go the usual Pharo rabbit hole of senders and implementors so that I dont brake anything. It kills my inner child. Slowly. Painfully. Well, then please don't. There is no current value in adding more themes. Adding themes on the current code will just add to the mess that needs to be cleaned up. It leads to more fragmentation. >About moving away from static values and replace them with references I agree 100% with you >but you also mention the very important that its something we have to agree on and I don't want > to go through the pain of asking permission each time I want to do something like that. No need to ask for permission. Just take small steps and post mails on your decisions. defaultSpec implementations are good candidates, just like defaultBounds, defaultBorderColor, defaultBorderWidth, defaultColor and defaultExtent >Because writing code to create a theme , makes no sense to me whatsoever. Avoiding duplication tends to be extremely difficult otherwise. Stephan

2 1

Re: [Pharo-dev] Let's talk about Themes
by Stephan Eggermont Nov. 10, 2014

Nov. 10, 2014

The point is not the creation of a theme. That is easy. And editing is too. The problem is that you need to check the whole system and get rid of all the constants and replace them by references to symbolic values in the application theme. There is the value. For example CheckBoxExample>>defaultSpec ^ { #ContainerModel. #add:. { self topSpec. #layout:. #(#SpecLayoutFrame bottomFraction: 0 bottomOffset: 20) }. #add:. {{#model . #container } . #layout: . #(#SpecLayoutFrame topOffset: 22) } } the values 20 and 22 need to be replaced. They are dependent on at least the font size. There are lots of these, e.g. CredentialEditor class >>defaultSpec <sepc: #default> ^ SpecLayout composed newColumn: [ :col | col newRow: [ :r | r add: #usernameLabel width: 80; add: #username ] height: self inputTextHeight; newRow: [ :r | r add: #passwordLabel width: 80; add: #password ] height: self inputTextHeight + 4; newRow: [ :r | r add: #showPasswordWidget width: 120; newColumn: [ :c | ] ] height: self inputTextHeight + 4; newRow: [ :r | ] ]; yourself That <sepc: #default> looks like a typo btw. These values are often composites, something like textSize+2*textLineVerticalSeparation. Coming up with good symbolic names is not trivial either. Stephan

2 1

What changed in compiler/RB that causes Seaside tests failures?
by Stephan Eggermont Nov. 10, 2014

Nov. 10, 2014

The slime tests that run in Pharo 3 fail in 4. And there are significant differences between running the tests in-image and in ci. https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/ Stephan

3 2

Let's talk about Themes
by kilon alios Nov. 10, 2014

Nov. 10, 2014

So I had a brief discussion with a newcomer to Pharo at IRC #pharo. He basically wanted to change the background color of a window. Naturally I assumed that is easy enough to do , so I though that window color in Preferences -> Appearance -> Morphic would do that trick but alas it did not. I am using PharoDark Theme and I found out that windowColor is not used and instead backgroundColor does the trick. Then it hit me, it would be really nice if a theme manager existed to make it easy for people to modify a theme at a basic level. "Damn it where is my Theme manager ? " which of course leads to the answer "Why you dont make one yourself?". So I decided to make one myself. I am not a fan of the idea to do this inside System Preferences because they are already too convoluted . So I am considering doing this as a separate tool as part of my Ephestos project. It is one the goals of my project to offer easy to create custom GUIs and of course a Theme manager is a first basic step. Now a first plan I had is to just create a single theme, that subclasses Dark Theme that I call Morpheas Theme and use that theme as a basis for every subtheme. So a theme will no longer be a class but rather a dictionary entry to an instance variable inside Morpheas Theme. The manager will basically allow to modify this dictionary with each sub theme having each own entry to this dictionary. I will try avoid messing with the code of other projects inside Pharo, ideally totally, it seems already the Dark Theme class can accomplish all I need. This approach ensures that structure of the theme remains the same only the data changes , keeping it clean and simple, with no need for the user to dive inside the code as it happens currently. So I am posting here since you guys are more experienced on this for your own opinion and though since I will do this at my own pace, slowly and step by step. I would like to avoid the pitfalls of unexperienced Pharo coder like me and of course make it easy also for other people to contribute.

1 0

[Update] #40363
by Marcus Denker Nov. 10, 2014

Nov. 10, 2014

14429 DebuggerTests package should be Debugger-Tests https://pharo.fogbugz.com/f/cases/14429 14431 FontInfrastructureTests package should be FontInfrastructure-Tests https://pharo.fogbugz.com/f/cases/14431 14430 EmbeddedFreeTypeTests package should be EmbeddedFreeType-Tests https://pharo.fogbugz.com/f/cases/14430

1 0

[Update] #40362
by Marcus Denker Nov. 10, 2014

Nov. 10, 2014

14425 FileList should not be used as Widget for opening Folders https://pharo.fogbugz.com/f/cases/14425 14436 NautilusTests package should be Nautilus-Tests https://pharo.fogbugz.com/f/cases/14436 14435 NECompletionTests package should be NECompletion-Tests https://pharo.fogbugz.com/f/cases/14435

1 0

14445 META case: Pharo4 should have green tests
by Marcus Denker Nov. 10, 2014

Nov. 10, 2014

We have just 4 failing left to fix... ReleaseTest.testMethodsWithUnboundGlobals ReleaseTest.testUndeclared ObsoleteTest.testFixObsoleteSharedPools AJx64AssemblerTests.testStringOps64Mnemonics 14445 META case: Pharo4 should have green tests https://pharo.fogbugz.com/f/search/?sSearchFor=outline%3A14445

1 0

[Update] #40361
by Marcus Denker Nov. 10, 2014

Nov. 10, 2014

14417 remove #theme from GraphicsFontSettings class https://pharo.fogbugz.com/f/cases/14417 14260 Add gt inspector views to Ordered[Identity]Dictionary https://pharo.fogbugz.com/f/cases/14260 14441 SmartSuggestionsTests package should be SmartSuggestions-Tests https://pharo.fogbugz.com/f/cases/14441 14440 SlotTests package should be Slot-Tests https://pharo.fogbugz.com/f/cases/14440

1 0

StandardFileStream>>open:forWrite: serious isse...
by phil＠highoctane.be Nov. 10, 2014

Nov. 10, 2014

Code (Transcript calls of mine) open: fileName forWrite: writeMode "Open the file with the given name. If writeMode is true, allow writing, otherwise open the file in read-only mode." | f | f := fileName asVmPathName. Transcript log: 'File:', f. fileID := StandardFileStream retryWithGC:[self primOpen: f writable: writeMode] until:[:id| id notNil] forFileNamed: fileName. fileID ifNil: [ ' > Cannot get fileID' logCr. ^ nil]. "allows sender to detect failure" (' > Got fileID: ', fileID printString) logCr. name := fileName. self register. rwmode := writeMode. buffer1 := String new: 1. self enableReadBuffering I have a ton of files to open. And some were slow to return a problem. After digging, I got to the method above. Now at one moment, I get nil fileIDs. What is that retryWithGC: until: thing??? retryWithGC: execBlock until: testBlock forFileNamed: fullName "Re-implemented to only force GC if a file with the given name exists" | blockValue foundIt | blockValue := execBlock value. (testBlock value: blockValue) ifTrue:[^blockValue]. "See if we have a file with the given name" foundIt := self registry keys "hold on strongly for now" anySatisfy:[:file| file name sameAs: fullName]. foundIt ifFalse:[^blockValue]. Smalltalk garbageCollectMost. blockValue := execBlock value. (testBlock value: blockValue) ifTrue:[^blockValue]. Smalltalk garbageCollect. ^execBlock value. Huhhhhh, yeah, some lookup going on in a registry... and GCs? For file opens? I am doing these opens in a webapp, what I want is to know if the file is there or not and fail fast, not have all of this thing (debugging kind of nightmarish...) I have tested with 100 files and of course it all works since I get the IDs back from the registry. But at one point, it all fails. Registry full? What to do here? TIA Phil

4 8