<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sounds great to me.<br>
<br>
Thanks,<br>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
<br>
On 5/25/2020 8:26 AM, Casey Ransberger via Cuis-dev wrote:
<blockquote
cite="mid:DDB00124-CFBA-45BF-A0A7-9665286BB29D@icloud.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Yeah. Themes and the taskbar should only intersect where the
taskbar decides how it should look. Whether or not it’s shown
should belong to the taskbar itself (probably class-side, since
there’s only one taskbar,) and be exposed in Preferences.
<div class=""><br class="">
</div>
<div class="">I’m ambivalent about whether or not an instance of
the taskbar exists while it isn’t being shown. It shouldn’t be
eating up a bunch of processing if we can’t see it, and it
shouldn’t take up a lot of space in the image in any event. May
as well leave it allocated if it isn’t being a bother, but
better to measure things and figure out what’s best if that’s a
concern people have.<br class="">
<div><br class="">
</div>
<div>This was what I was looking into when I encountered the
pattern of duplicated code in senders of #useUniformColors.
I’d rather get rid of all of these divergent paths before I
even worry about where the “show taskbar” bit lives.</div>
<div><br class="">
</div>
<div>—Casey</div>
<div><br class="">
</div>
<div>P.S.</div>
<div><br class="">
</div>
<div>Also, the theme system isn’t done until existing windows
and widgets update themselves when you change themes. Much to
do, there is, to say it like Yoda would.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On May 25, 2020, at 3:47 AM, Luciano
Notarfrancesco <<a moz-do-not-send="true"
href="mailto:luchiano@gmail.com" class="">luchiano@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div dir="auto" class="">Sounds very good to me. And
while you’re at it, perhaps we can remove useTaskbar
as you suggested before, as long as we avoid randomly
showing the taskbar again. Juan already removed the
call to restoreDefaultDesktop, and we should also
avoid adding the taskbar again in Theme
class>>currentTheme:</div>
</div>
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 25 May 2020
at 5:33 PM, Casey Ransberger via Cuis-dev <<a
moz-do-not-send="true"
href="mailto:cuis-dev@lists.cuis.st" class="">cuis-dev@lists.cuis.st</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin: 0px 0px
0px 0.8ex; border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">I’m
poking around in the vicinity of Theme, thinking
about adding a class to Theme-Core. When I
initially wrote Theme, I did a lot of gymnastics
to keep it down to a single class, wanting to
avoid unnecessarily adding a bunch of classes to
the system. Also wanted to impress Juan, who I
expected would be hesitant to add a bunch of
complicated machinery to Cuis.
<div class=""><br class="">
</div>
<div class="">Looking back on the code something
like a decade later, I think I was a little
gung-ho with the one-class thing. Adding a
single class UniformColorTheme (or maybe we can
think of a better name like BoringColorTheme)
seems to obviate #useUniformColors completely,
and thus eliminate 13 send sites (which, I might
add, all have a code duplication smell.) Each of
these send sites involves branch logic that
would go away, 3 or 4 lines of code each. I
haven’t investigated this last one yet, but
#defaultWindowColor might also go away, yielding
a bit more in the way of complexity savings.</div>
<div class=""><br class="">
</div>
<div class=""><font style="" class=""><span
class="">Here’s a typical send site of
Theme>>useUniformColors.</span></font>
<div style="" class=""><br class="">
</div>
<div style="" class="">
<div class="">Theme>>versionsBrowser</div>
<div class=""><span style="white-space:
pre-wrap;" class=""> </span>^ self
useUniformColors</div>
<div class=""><span style="white-space:
pre-wrap;" class=""> </span>ifTrue: [
self defaultWindowColor ]</div>
<div class=""><span style="white-space:
pre-wrap;" class=""> </span>ifFalse: [
`(Color r: 0.869 g: 0.753 b: 1.0) duller` ]</div>
</div>
<div style="" class=""><br class="">
</div>
<div style="" class="">I’m not sure if I wrote
the above code or not.</div>
</div>
<div class=""><br class="">
</div>
<div class="">It’s always ^self <span style=""
class="">useUniformColors ifTrue:[] ifFalse[].
All 13 sites.</span></div>
<div class=""><br class="">
</div>
<div class="">Between one and two methods would go
away along with an additional 39+ lines of code.
In exchange, we get a new class (my vote is for
BoringTheme) with as many as 13 one-line
methods. A cross-cutting concern goes away. We
lose 5 LoC to a class definition, if we want to
even count that, still a 21+ line win. I haven’t
looked at the extra themes, but I’ll update them
if I make the change, and I expect code savings
there as well. More importantly, it will be more
logical, more object oriented, less tricky.
Right now to implement a theme, you need to know
about this odd convention in these 13 methods,
and it shouldn’t be that way. <span style=""
class="">I went with methods instead of
sticking instances of Color in ivars so we
could experiment with functional expressions
that yield arbitrary UI objects (originally
there was going to be a lot more to this than
colors, but life has a way of interrupting
grand schemes.) Here though we’re throwing in
logic to pick between two colors, which smells
like the opposite idea.</span></div>
<div class=""><br class="">
</div>
<div class="">Okay that’s the gist of it. Only
performance impact should be negligible but
positive (sends and branch logic that don’t need
to happen anymore.) Theme-Core isn’t at all a
crowded category so scrolling and cognitive load
shouldn’t be an issue with adding a class here.
I can probably absorb what I think used to be
called GrayTheme out of the extra themes package
into OfficeDull Win95KnockOff or whatever we
decide to call it, so any methods there go away
from the extra themes package.</div>
<div class=""><br class="">
</div>
<div class="">Is everyone okay with me doing this?</div>
</div>
<div style="word-wrap: break-word;" class="">
<div class=""><br class="">
</div>
<div class="">—Casey</div>
</div>
-- <br class="">
Cuis-dev mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:Cuis-dev@lists.cuis.st"
target="_blank" class="">Cuis-dev@lists.cuis.st</a><br
class="">
<a moz-do-not-send="true"
href="https://lists.cuis.st/mailman/listinfo/cuis-dev"
rel="noreferrer" target="_blank" class="">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br
class="">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>