[haiku-development] Re: Deskbar feature patch
- From: John Scipione <jscipione@xxxxxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Wed, 29 Jan 2014 17:03:12 -0500
On Wed, Jan 29, 2014 at 4:49 PM, looncraz <looncraz@xxxxxxxxxxx> wrote:
> Also, as predicted and expected, getting any live-resizing in Deskbar is a
> major pain. Easiest way would be to just rebuild the entire interface after
> changing sMinimumWindowWidth (which, for some odd reason, is exported from
> StatusView.cpp...).
I've really tried to make Deskbar not rebuild the entire interface
after each action in most cases for performance reasons, it's just too
slow. Instead I try as hard as possible to inform each view what it
needs to do to move to the right place... there's a couple of
instances where I'm still rebuilding objects though. I've got a branch
where I've fixed this, I'd like to finish this up at some point.
> The Deskbar violates every convention I hold for view management... I don't
> permit grandparents to mess with the kids... that's the parents' job only.
> I don't let the kids tell the parents what to do, either...
>
> The relationship with TDragRegion, TReplicantTray, and TBarView in this
> regard is perplexing and frustrating. So many hands in the pot, so to
> speak. Each one of them has some say that conflicts with the others... no
> wonder the dragger hasn't been properly repaired for over a decade! (It's
> suppose to have a border, and be about twice as wide as it is).
Agreed these classes have an unnecessarily complex relationship with
each other. At one point I tried to clean this up by creating three
BGroupLayouts, one for vertical expando mode, one for vertical
mini-mode, and one for horizontal mode, since the layout of the pieces
is different in each of these modes, and then call SetLayout on the
window to choose the one you want for the mode you're in as you drag
the window around. I never quite got it to work though, it would
crash, but, I think that's ultimately the way to go if you are up for
the necessary layout-fu.
> Oh well, for now I am just sending commands with 'hey' to work out the
> resizing issues. We could just calculate the width of the Deskbar for the
> screen ratio... keep it in the same proportions. We would just need to
> respond to screen resolution changes and on startup - which is dead simple
> considering the menu is already essentially rebuilt on each of these events
> anyway (so odd moving and reshaping will seem natural).
That's a decent idea. BWindow has a ScreenChanged() method you can
hook into to recalculate the width and redraw when the resolution
changes.
Other related posts:
