Open hhzl opened 4 years ago
An (maybe simpler) alternative to implementing a settings button is to construct an example how to use the speadsheet tool to view and edit 'dumb data' or data where the sheet was constructed by code (e.g. binary clock) thus saving screen space.
A third option is to have the configuration and model button on the right hand side with the label 'C' and 'M' thus saving height giving space for more lines.
Refactoring proposal for toolbuilder method categories in order to find the right spot to add a 'preferences' button.
NB: Factor out the construction of the GUI to an SSSheetToolConstructionAction is advisable (with instance variable holding the aSSheetTool probably as SSSheetTool has 1000 LOC.
How was this done? Where is the setting / preference which controls that?
There is no such setting. The screenshot you are referring to was taken in a phase of a project where the menu bar did not yet exist. :-)
A third option is to have the configuration and model button on the right hand side with the label 'C' and 'M' thus saving height giving space for more lines.
We also had some discussions and experiments concerning the position of this button, we also tried out to move them into the right corner (see 9593714), but unfortunately, relevant contents of arbitrary models can be hidden by this, so we decided against it. However, we could move the whole button bar and position it left or right to the cell instead of above this, is this what you meant? Maybe this should even be determined flexibly, depending on the width/height of a cell ...
An (maybe simpler) alternative to implementing a settings button is to construct an example how to use the speadsheet tool to view and edit 'dumb data' or data where the sheet was constructed by code (e.g. binary clock) thus saving screen space.
Are you talking about some pre-toolbuilding selector to turn on/off the buttons? Hm, not sure about this, this should be adjustable using the UI only. But I would not like to overwhelm the UI with too many buttons ...
Just another option would be to move all the buttons into a menu, for instance the yellow button menu of the text field (however, this would not work for universal cells), or by integrating the items into one of the halo menus. However, this would be a greater change because the ToolBuilder framework does not support this ATM afaik.
Tl;dr: I see the disadvantages of the current solution, but I do not know, too, how a perfect solution would like. More ideas are welcome. :-)
Refactoring proposal for toolbuilder method categories in order to find the right spot to add a 'preferences' button.
Thanks for the proposal! This looks like a useful refactoring. Could you open a PR for the change? :-)
NB: Factor out the construction of the GUI to an SSSheetToolConstructionAction is advisable (with instance variable holding the aSSheetTool probably as SSSheetTool has 1000 LOC.
Do you mean kind of a builder object? Actually, I do not see the need for it because except for the toolbuilder-specs-matrixForContents
protocol, the numbers of parameters are usually small. It is a convention to store the toolbuilder logic in the model class and I would not deviate from that convention without a deeper reason than the LOC metric. However, maybe I did not get your idea correctly ...
I'd like to submit a pull request for the refactoring which shows the structure of the Toolbuilder method calls. To do this I need issue #77 (More info in 'Contributing section) solved.
The following change set leads to a first refactoring step in the class SSSheetTool shown in the screen shot below. It adds a message category labeled 'toolbuilder-spec-menu'. It contains 9 methods for button specs and 3 methods for panel specs.
'From Squeak5.3 of 15 April 2020 [latest update: #19435] on 26 October 2020 at 10:55:53 pm'!
!SSSheetTool reorganize!
('accessing' autoEvaluateActivated columnCount contentSheet maxReasonableNumberOfCells menuBarSpacing rowCount steppingActivated steppingActivated: subject subject:)
('toolbuilder-spec-menu' specForAboutButton: specForAutoEvaluationButton: specForDeleteSheetButton: specForDimensionControl: specForDimensionControlOf:selector:with: specForDistributeColumns: specForDistributeRows: specForHelp: specForNewSheetButton: specForOpenSheetButton: specForSaveSheetButton: specForSteppingButton:)
('toolbuilder' buildCell:with:atRow:atColumn: buildCellsPanel buildWith: calculateFrameForItemAtRow:atColumn: labelForAutoEvaluate labelForStepping open specForCell:with:atRow:atColumn: specForDistributionControl: specForFormulaControl: specForLabel:with: specForMainPanel: specForMenuBar: specForSheetManagement: specMatrixForContents:)
('dependents' changed: postInitialize update: windowIsClosing)
('interaction' columnCount: deleteSheetFromImage distributeColumns distributeRows okToChangeRowCount:columnCount: okToClose openAboutWindow openNewSheet openSheet: openSheetFromImage promptDecreaseAndDeleteContent promptDiscardChanges promptOverwriteSheet promptResizeToLargeRange rowCount: rowCount:columnCount: saveSheetToImage toggleAutoEvaluate toggleStepping)
('toolbuilder-constants' defaultCellFraction defaultHeaderScale defaultWindowColor defaultWindowSpace initialExtent menuHeight minimumCellExtent minimumCellSpace minimumExtent minimumSplitterExtent windowTitle)
('stepping' disableSteppingWhile: stepIn: wantsSteps)
('distribution' distributeCellsInDimension:range:splitterSelector: scaleCellsAtSplittersThat:to:)
('testing' hasContentsBeyondRow:column: hasUnacceptedChanges)
('initialize-release' initialize)
('copying' veryDeepInner:)
!
I'd like to submit a pull request for the refactoring which shows the structure of the Toolbuilder method calls. To do this I need issue #77 (More info in 'Contributing section) solved.
I assume you are referring to #78. Please see my comment there. :-)
The second screenshot showing Squeak release versions in the README file shows the spreadsheet with the 'Configuration' and 'Model' buttons hidden.
How was this done? Where is the setting / preference which controls that?