[haiku-commits] Re: r37894 - haiku/trunk/src/servers/app
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 04 Aug 2010 23:26:09 +0000
> In the Clicked method the decorator just figure out which part of the
> decorator has been clicked. The WindowBehaviour class should then
> transform this into an window action. At the moment the decorator
> also
> returns CLICK_MOVE_TO_BACK and CLICK_SLIDE_TAB in the Clicked method
> which
> should be moved to WindowBehaviour IMHO. The only reason to keep them
> in
> the decorator would be if there are dedicated button for this actions
> in a
> decorator. But in the default decorator this can be calculated in the
> DefaultWindowBehaviour class (CLICK_MOVE_TO_BACK -> right click on
> CLICK_TAB).
>
> So it could use some more refactoring (not on my list at the moment),
> I
> just reorganized the existing code.
Move to back and move to front are actually buttons in the (not yet
written) amiga decorator.
There are other click-areas that could be introduced then, like
differenciating the resize knob from the border, as the border is
sometimes used to move (not resize) windows, or adding the "window
icon" button on the WinDecorator.
For the sake of completeness we could add the 'fold' button of the mac
decorator, but this one was only there on mac to compensate the lack of
a proper deskbar. So we can live without it.
Some X11 WM also have a "show on all workspaces" button... not that
useful either.
Overall, it would mean that most of the time the behavious should be
switched at the same time as the decorator, as clicking the window tab
does different things for each of them (to compensate for the different
set of buttons).The Be and Default decorators lacks a minimize button
so they provide this, while the amiga one should never move to front
when clicking on the tab (as there is a button for that). Writing a
behaviour that can handle all of the decorators can be tricky in this
case.
Other related posts:
