Promoting #buildWindowWith:specs: et al.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Promoting #buildWindowWith:specs: et al.

timrowledge
Does anyone have a problem with StringHolder>buildWindowWith* being promoted to Model and the now redundant Font[Chooser|Importer]Tool versions getting removed? It seems to me a reasonably general pair of methods with applicability to other Model related classes, like for example, the new file chooser & saver dialogues I’m preparing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CM: Circulate Memory



Reply | Threaded
Open this post in threaded view
|

Re: Promoting #buildWindowWith:specs: et al.

marcel.taeumel
Hi Tim,

yes, seems reasonable. Please do not forget to add #windowTitle to Model, which I would prefer over #labelString. :) #labelString should be deprecated.


Best,
Marcel

Am 28.10.2017 05:48:47 schrieb tim Rowledge <[hidden email]>:

Does anyone have a problem with StringHolder>buildWindowWith* being promoted to Model and the now redundant Font[Chooser|Importer]Tool versions getting removed? It seems to me a reasonably general pair of methods with applicability to other Model related classes, like for example, the new file chooser & saver dialogues I’m preparing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CM: Circulate Memory





Reply | Threaded
Open this post in threaded view
|

Re: Promoting #buildWindowWith:specs: et al.

Tobias Pape
In reply to this post by timrowledge

> On 28.10.2017, at 05:48, tim Rowledge <[hidden email]> wrote:
>
> Does anyone have a problem with StringHolder>buildWindowWith* being promoted to Model and the now redundant Font[Chooser|Importer]Tool versions getting removed? It seems to me a reasonably general pair of methods with applicability to other Model related classes, like for example, the new file chooser & saver dialogues I’m preparing.

Certainly.
I was just reluctant the last time, when I created the FontImporterTool, to do that.

Best regards
        -Tobias


>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: CM: Circulate Memory
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Promoting #buildWindowWith:specs: et al.

timrowledge
In reply to this post by marcel.taeumel

> On 28-10-2017, at 12:55 AM, Marcel Taeumel <[hidden email]> wrote:
>
> Hi Tim,
>
> yes, seems reasonable. Please do not forget to add #windowTitle to Model, which I would prefer over #labelString. :) #labelString should be deprecated.

Hmm, well I agree that is a better name, but there is going to be some fallout. Take a look at SystemWindow>update: and use of #relabel. And then the senders of #relabel, and the implementors of labelString. That’s quite a few bits of code needing touching, so do please feel free to touch them while I keep working on these new dialogs.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PBF: Pay Bus Fare



Reply | Threaded
Open this post in threaded view
|

Re: Promoting #buildWindowWith:specs: et al.

timrowledge

> On 28-10-2017, at 1:17 PM, tim Rowledge <[hidden email]> wrote:
>
>
>> On 28-10-2017, at 12:55 AM, Marcel Taeumel <[hidden email]> wrote:
>>  Please do not forget to add #windowTitle to Model, which I would prefer over #labelString. :) #labelString should be deprecated.
>
> Hmm, well I agree that is a better name, but there is going to be some fallout. Take a look at SystemWindow>update: and use of #relabel. And then the senders of #relabel, and the implementors of labelString. That’s quite a few bits of code needing touching, so do please feel free to touch them while I keep working on these new dialogs.

Urk. Well it turns out there is a *load* more fallout than I’d expected. The usage of label is so widespread for window titles as well as buttons, menus, debugger logs and so on, that it makes for very long list of code to examine and I’m currently guessing at over a hundred methods to change, all to swap a simple term.

Those windows built via ToolBuilder can be told to use any message you like, so there’s no problem there BUT even in ToolBuilder the concept is labelled as… err… label. I also noticed a number of places where ‘changed: #labelString’ is sent and yet no plausible implementations of any use of that to actually do something. My guess is a change in the past that moved to #relabel and didn’t completely update everywhere required. It certainly pre-dates 2.8 and I really can’t be bothered to search back any further. The point is that there’s a number of places that appear to expect to update the title bar and don’t. Sigh.

Given all that I’m going to revert the deprecation - so we’ll have a deprecated deprecation to deprecate later - of labelString and a couple of related method changes. It’s far more turmoil than is warranted for a simple nomenclature swap in my view.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Cloister: a pretentious clam