<div><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 11, 2025 at 18:10 Mariano Montone <<a href="mailto:marianomontone@gmail.com">marianomontone@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">Hi Luciano,<br>
<br>
El 11/3/25 a las 07:25, Luciano Notarfrancesco escribió:<br>
> perhaps ApplicationMorph could be called ApplicationWindow?<br>
That's an option. But I liked Morph instead of Windows because the tools <br>
(Browser, Inspector) are not "windows" anymore :) But preserving the <br>
"Window" in the class name also makes sense.</blockquote><div dir="auto"><br></div><div dir="auto">Yes, I see your point too, makes sense.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">> Also, why not make it subclass of PluggableMorph as other morphs with <br>
> model? And do we really need this class, or we could just make them <br>
> subclass of PluggableMorph?<br>
I'll try it. The reason of to make it subclass of LayoutMorph and not <br>
PluggableMorph is because SystemWindow interface are all built on a <br>
layoutMorph (instance variable and class). And so I subclassed from <br>
LayoutMorph and added some extra methods in ApplicationMorph. But I'll <br>
consider doing it as you suggest .</blockquote><div dir="auto"><br></div><div dir="auto">Oh, I missed that, sorry… maybe just ignore my suggestion.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>> Also, the WindowManager class seems unnecessary to me, I think all <br>
> that it does could be implemented on the class side of the decorated <br>
> windows (open:, open:label:), or on the instance side of the <br>
> application windows (open, openWithLabel:), and the class of system <br>
> window to use can be set in a class variable.<br>
<br>
Ok. That's another option. Note that although it is a very simple at the <br>
moment, my thought is that the WindowManager not only handles the type <br>
of WindowDecoration to open, but also position (let's say you want a <br>
tiling window manager), size, etc. And so I thought it would be nice to <br>
have a WindowManager to delegate everything window managing related.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">Hm, yes, in fact I did what you are saying in my tiling window manager, and it also receives messages when windows are closed and handles global keyboard shortcuts (open a browser, open a workspace, etc). That was before pluggable windows, and now with this new idea it feels I might make my window manager package cleaner if it just implementing a new type of system window like DynamicTilingWindow that knows about tiling and other window modes, etc (because it has controls for tiling, it is not really independent of the window manager). But it might be better to decouple the window from the window manager as you say, I’m not sure..</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto"><br>
Let me try another version. I'll upload image when I have it.<br>
<br>
             Mariano<br>
<br>
</blockquote></div></div>