It should now be more feasible to remove some hard coded gradients in widgets like windows, buttons and menus. Many of them rely on one user selected color and to hard code the other to white for example. It should now be much easier to edit a gradient with more than 2 colors
Karl
On Thu, Oct 29, 2015 at 1:10 PM, commits@source.squeak.org wrote:
Karl Ramberg uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-kfr.1022.mcz
==================== Summary ====================
Name: Morphic-kfr.1022 Author: kfr Time: 29 October 2015, 12:52:07.646 pm UUID: 64c8e8d1-462d-48e5-af29-706bd470f767 Ancestors: Morphic-kfr.1021
More look enhancements
=============== Diff against Morphic-kfr.1021 ===============
Item was changed: RectangleMorph subclass: #GradientEditor
instanceVariableNames: 'gradientDisplay rampMorphs selectedSketch
row text target selector morph'
instanceVariableNames: 'gradientDisplay rampMorphs selectedSketch
gradientMorph row text target selector morph' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Widgets'!
Item was changed: ----- Method: GradientEditor>>addButtonRow (in category 'initialization') ----- addButtonRow | button button2 buttonRow button3 | buttonRow := RectangleMorph new borderWidth: 0; color: Color transparent; layoutPolicy: TableLayout new;
hResizing: #spaceFil;
vResizing: #spaceFill;
hResizing: #shrinkWrap;
vResizing: #shrinkWrap; cellPositioning: #center; listCentering: #topLeft; listDirection: #LeftToRight; reverseTableCells: true;
cellInset: 4.
cellInset: 20 @ 20. button := PluggableButtonMorph on: self getState: nil action: #addHandle label: #addColorButtonLabel.
button hResizing: #spaceFill;
vResizing: #spaceFill. buttonRow addMorph: button. button2 := PluggableButtonMorph on: self getState: nil action: #deleteHandle label: #removeColorButtonLabel.
button2 hResizing: #spaceFill;
vResizing: #spaceFill. buttonRow addMorph: button2. button3 := PluggableButtonMorph on: self getState: nil action: #delete label: #closeButtonLabel.
button3 hResizing: #spaceFill;
vResizing: #spaceFill. buttonRow addMorph: button3. self addMorph: buttonRow!
Item was changed:
----- Method: GradientEditor>>initialize (in category 'initialization')
initialize
super initialize. self myLayout. self extent: 600 @ 150. row := RectangleMorph new extent: self width @ 100; color: Color
transparent; borderColor: #inset.
row addMorph: (gradientDisplay := GradientDisplayMorph new
position: 20 @ 20; extent: self width - 40 @ 40). gradientDisplay fillStyle direction: gradientDisplay width @ 0.
self addMorph: row. self addButtonRow.
"text := PluggableTextMorph
text := PluggableTextMorph on: self text: #colorRamp accept: nil readSelection: nil menu: nil. text color: Color white; width: self width; height: 50.
self addMorph: text."
self addMorph: text. !
Item was changed:
----- Method: GradientEditor>>myLayout (in category 'initialization')
myLayout self color: (Color white darker) ; cornerStyle: #rounded ; borderWidth: 0; layoutPolicy: TableLayout new; hResizing: #shrinkWrap; vResizing: #shrinkWrap; cellPositioning: #center; listCentering: #topLeft; layoutInset: 4; listDirection: #topToBottom; reverseTableCells: true; wrapCentering: #topLeft;
cellInset: 4!
cellInset: 19 @ 10!
Item was changed: ----- Method: GradientEditor>>updateColorRamp (in category 'change reporting') ----- updateColorRamp | newAssociation newKey newColor sketch colorRamp |
self updateRampMorphs. colorRamp := OrderedCollection new. rampMorphs do: [:i | newKey := ((i position x - gradientDisplay left /
gradientDisplay width) asFloat roundUpTo: 0.01) min: 1.0 max: 0.0. sketch := i findA: SketchMorph. newColor := sketch rotatedForm colorAt: sketch rotatedForm center. newAssociation := newKey -> newColor. colorRamp addLast: newAssociation]. colorRamp := colorRamp sorted. gradientDisplay colorRamp: colorRamp. gradientDisplay fillStyle direction: gradientDisplay extent x @ 0. self changed. target ifNotNil:[ target perform: selector with: colorRamp with: morph].
"text setText: self colorRamp"!
text setText: self colorRamp!
Hi Karl,
if we remove gradient specifications from code, how will we version them with Monticello?
Is there a way to get the code snippet that produces the result, which the user has fine-tuned in this gradient editor?
Best, Marcel
-- View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-1022-mcz-tp4858453p4858595.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Is there a way to get the code snippet that produces the result, which the user has fine-tuned in this gradient editor?
I didn't see the new editor yet, but +1 about the idea. Like the NewColorPicker shows the code snippet for instantiating the selected color.
I love things like this which bring the code to the surface in a useful way and invite users to use and regard code as just another widget of the UI.
On Fri, Oct 30, 2015 at 8:42 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
Hi Karl,
if we remove gradient specifications from code, how will we version them with Monticello?
They must be stored in preferences.
Is there a way to get the code snippet that produces the result, which the user has fine-tuned in this gradient editor?
It is kind of possible but needs more work. I reuse stuff from NewColorPicker which have the color as text printed back to the UI. You can also change the color in the text to change it. It's a little more complicated with the gradient since it must be possible to change a color in a array.
Also the GradientEditor is not accessing all the aspects of the GradientFillStyle at the moment, just the colorRamp. The origin, direction, normal and radial is not accessible from the UI at the moment .
Best, Marcel
-- View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-1022-mcz-tp4858453p4858595.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Nice. :)
We might want to think about Monticello and Code from time to time. At the moment, there is no feasible way to version real objects (morphs etc.) with it. [Which is not a limitation of MCZ files storing binary versions of MCMethodAddtions already in the snapshot.bin]
Those really cool features do all make sense. However, a team may only pick them up if it can share and version the results.
Best, Marcel
-- View this message in context: http://forum.world.st/The-Trunk-Morphic-kfr-1022-mcz-tp4858453p4858794.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Sat, Oct 31, 2015 at 09:00:42AM -0700, marcel.taeumel wrote:
Nice. :)
We might want to think about Monticello and Code from time to time. At the moment, there is no feasible way to version real objects (morphs etc.) with it. [Which is not a limitation of MCZ files storing binary versions of MCMethodAddtions already in the snapshot.bin]
Edgar De Cleene has provided a working implementation that is worth review. The changes would need to be merged into trunk, but that should not be hard to do.
The MCZ with Edgar's changes is Monticello-edc.534.mcz in the repository http://www.squeaksource.com/Ladrillos.
Edgar also provided a video that shows how use this to load an MCZ with resources for a morphic puzzle, similar to the way this might otherwise be done with a SAR archive.
https://www.youtube.com/watch?v=EZucdZZCdYY&feature=youtu.be
The original discussion of this was in the 'Updating SAR builder tool' thread on squeak-dev last August.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2015-August/185739.ht...
I tried this myself in a 5.0 image and it worked well. Unfortunately I didn't find the time to follow up by extracting the changes and putting them into the inbox, which I guess would be the best way to proceed if we have an interest in this approach.
Dave
squeak-dev@lists.squeakfoundation.org