# Need help designing UI

**URL:** <https://www.ruby-forum.com/t/need-help-designing-ui/60809>\
**Category:** Ruby\
**Created:** [May 17, 2006, 6:09pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809 "2006-05-17T18:09:41Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 6:09pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/1 "2006-05-17T18:09:41Z")

</div>

Hi,

I’m working on a user interface and I’m hoping I can get some  
feedback/advice. I have 3 main classes: Viewer, Toolbar and  
ToolbarButton. Given that an instance of Viewer has an instance of  
Toolbar and that Toolbar has a collection of ToolbarButtons, I’m trying  
to decide how I want to implement the workflow for the “Close” process.  
The creation of all these instances is all rather “pretty” at the moment  
but no instances really “knows” or cares about the other. (parts is  
parts!)

So, consider when the user clicks a “close window” ToolbarButton.  
Somehow the Viewer must be informed that its time to close the window.

For some reason, I’m trying to avoid keeping a reference to the Viewer  
in the button (like with a call back). I’m hoping for a somewhat more  
interesting design. I’ve tried a variety of things over the years but  
I’m curious what others have tried, got working and generally like.

Any comments would be greatly appreciated.

Scott

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 6:31pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/2 "2006-05-17T18:31:54Z")

</div>

Over the years I’m sure there has been invented countless ways of  
doing what you are asking, but I am personally most experienced with  
the GUI system on BeOS, which I think is a very nice design.

Essentially all communication between various parts of the system  
(from the OS to applications and back, from applications to their  
windows and back, from windows to the GUI components and back) is done  
via messages. A looper class is used to loop over messages coming in  
and then the handling of these messages are delegated to a handler  
class. On BeOS frequently the looper and handler are the same class.

Messages are handled first by their direct recipient (for example a  
mouse down would be handled first by the component being clicked on.)  
If the message cannot be handled by that recipient, it is passed up  
the inheritance hierarchy until it is handled. Usually messages that  
are used within an application itself are targeted directly to the  
window, and then the window can delegate to the appropriate component.

So for you example, the “Close Window” toolbar button would have a  
message with an associated CLOSE command constant, with the target of  
the message being the window. When the button is clicked, the CLOSE  
message will be sent to the window and the handling of that message  
will close the window (of course.) The nice thing about this is that  
the CLOSE message could be used from other places without having to  
change how it is handled within the window.

Ryan

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 7:25pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/3 "2006-05-17T19:25:44Z")

</div>

Ryan L. wrote:

> Essentially all communication between various parts of the system  
> (from the OS to applications and back, from applications to their  
> windows and back, from windows to the GUI components and back) is done  
> via messages. A looper class is used to loop over messages coming in  
> and then the handling of these messages are delegated to a handler  
> class. On BeOS frequently the looper and handler are the same class.
> 
> Messages are handled first by their direct recipient (for example a  
> mouse down would be handled first by the component being clicked on.)  
> If the message cannot be handled by that recipient, it is passed up  
> the inheritance hierarchy until it is handled. Usually messages that  
> are used within an application itself are targeted directly to the  
> window, and then the window can delegate to the appropriate component.
> 
> So for you example, the “Close Window” toolbar button would have a  
> message with an associated CLOSE command constant, with the target of  
> the message being the window. When the button is clicked, the CLOSE  
> message will be sent to the window and the handling of that message  
> will close the window (of course.) The nice thing about this is that  
> the CLOSE message could be used from other places without having to  
> change how it is handled within the window.
> 
> Ryan

I think there are two essential design patterns here, one is message  
dispatcher, and the other is chain of responsibility .

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 7:26pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/4 "2006-05-17T19:26:38Z")

</div>

Ryan L. wrote:

> So for you example, the “Close Window” toolbar button would have a  
> message with an associated CLOSE command constant, with the target of  
> the message being the window. When the button is clicked, the CLOSE  
> message will be sent to the window and the handling of that message  
> will close the window (of course.) The nice thing about this is that  
> the CLOSE message could be used from other places without having to  
> change how it is handled within the window.

Thanks for replying Ryan. This got me thinking about some design goals.  
Your description sounds like MS Windows, in any case, it implies some  
sort of Windowing management. What I’m building is pretty high level and  
the overall impetous of the project is not the UI - more of a library  
kind of thing. The UI is sweetness? So to keep things simple, I’m  
thinking I need to concentrate on two things.

A command constant. Definitely warming to this idea. The constant as in  
your description is merely a token to pass around.

Some form of context. A toolbarbutton is on a toolbar is on a viewer. In  
a generic way, when the viewer gets created, it would register a context  
which could be a simple random number. All sub-parts get the context?  
When the toolbarbutton fires it broadcasts a command constant and the  
context? Thinking out loud. Does avoid the references but now I gotta  
pass around a random number. In Ruby - that’s a reference too. hmmmmm.

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 7:29pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/5 "2006-05-17T19:29:17Z")

</div>

uncutstone wu wrote:

> I think there are two essential design patterns here, one is message  
> dispatcher, and the other is chain of responsibility .

Thanks, will google that!

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 17, 2006, 8:29pm UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/6 "2006-05-17T20:29:30Z")

</div>

On 5/17/06, Scott L Holmes [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Some form of context. A toolbarbutton is on a toolbar is on a viewer. In  
> a generic way, when the viewer gets created, it would register a context  
> which could be a simple random number. All sub-parts get the context?  
> When the toolbarbutton fires it broadcasts a command constant and the  
> context? Thinking out loud. Does avoid the references but now I gotta  
> pass around a random number. In Ruby - that’s a reference too. hmmmmm.

For the command constant you should use Ruby symbols:

:this\_is\_a\_symbol  
:another\_one

In other words anything starting with a colon. These are unique per  
invocation of Ruby, and :this will always equals :this through-out the  
program. So in your case using something like :cmd\_close or :CMD\_CLOSE  
would be the best choice.

Ryan

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 18, 2006, 8:01am UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/7 "2006-05-18T08:01:26Z")

</div>

Scott L Holmes wrote:

> Hi,
> 
> I’m working on a user interface and I’m hoping I can get some  
> feedback/advice. I have 3 main classes: Viewer, Toolbar and  
> ToolbarButton. Given that an instance of Viewer has an instance of  
> Toolbar and that Toolbar has a collection of ToolbarButtons, I’m trying  
> to decide how I want to implement the workflow for the “Close” process.  
> The creation of all these instances is all rather “pretty” at the moment  
> but no instances really “knows” or cares about the other. (parts is  
> parts!)
> 
> So, consider when the user clicks a “close window” ToolbarButton.  
> Somehow the Viewer must be informed that its time to close the window.
> 
> For some reason, I’m trying to avoid keeping a reference to the Viewer  
> in the button (like with a call back). I’m hoping for a somewhat more  
> interesting design. I’ve tried a variety of things over the years but  
> I’m curious what others have tried, got working and generally like.
> 
> Any comments would be greatly appreciated.
> 
> Scott

Investigate a listener/dispatcher pattern, as used by the Java Swing  
Framework.  
Basically, have a control class (MainProgram) register itself as a  
‘click listener’ on the close button (this is done with interfaces in  
Java - obviously not necessary for ruby code). That way, the control  
flow of the program is abstracted outside of your specific UI  
components.

If every toolbar has a close button, then it may be better to have the  
toolbar register itself as a click listener on the close button, and  
then reposting this as a close event.

- Xavier

---

<div class="post-metadata">

**Author:** ![daborg69](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/d9b06d/32.png) [@daborg69](https://www.ruby-forum.com/u/daborg69)\
**Post date:** [May 18, 2006, 6:17am UTC](https://www.ruby-forum.com/t/need-help-designing-ui/60809/8 "2006-05-18T06:17:24Z")

</div>

Hi,

On 5/17/06, Scott L Holmes [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> So, consider when the user clicks a “close window” ToolbarButton.  
> Somehow the Viewer must be informed that its time to close the window.
> 
> For some reason, I’m trying to avoid keeping a reference to the Viewer  
> in the button (like with a call back). I’m hoping for a somewhat more  
> interesting design. I’ve tried a variety of things over the years but  
> I’m curious what others have tried, got working and generally like.
> 
> Any comments would be greatly appreciated.

In a DOM-like system: on clicking the button, it would bubble up a  
CloseWindow-event, which the Viewer would then catch and close the  
window.

Pseudo-code:

class Object  
def send\_up(\*args)  
process\_up\_event(\*args)  
@parent.send\_up(\*args) if @parent  
end  
end

close\_button.on\_click{ close\_button.send\_up(:close\_window) }  
viewer.on\_close\_window{ exit }

viewer \<\< toolbar  
toolbar \<\< close\_button

Ilmari