[haiku-bugs] Re: [Haiku] #7445: app_server DecorManager + DecorInfo patch
- From: "looncraz" <trac@xxxxxxxxxxxx>
- Date: Wed, 18 May 2011 18:28:06 -0000
#7445: app_server DecorManager + DecorInfo patch
----------------------------------+-------------------------------------
Reporter: looncraz | Owner: axeld
Type: enhancement | Status: new
Priority: normal | Milestone: Unscheduled
Component: Servers/app_server | Version: R1/Development
Resolution: | Keywords: DecorManager, decorator
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
----------------------------------+-------------------------------------
Comment (by looncraz):
Replying to [comment:12 stippi]:
> Could you please point out where there have been list lookups replaced
that are performance relevant to make the "UI noticeably snappier"? That
statement looks really dubious to me. I understand the desire to get
patches in, it contains hard work, but nobody needs to resort to such
claims (but I'll apologize when you can indeed point out the performance
improvements in the code). The real reason that I have not applied this
patch yet is not that I need more incentive to do so, but because there
are still a whole lot of coding style violations. Before applying the
patch, I intend to fix them, and it's just a daunting work, I have no time
and I just don't understand why I have to do it and not looncraz. I also
pointed out that the preview solution is pretty hacky, but I understand
that the motivation is low to code a proper solution (which would be to
let Decorators render into a bitmap and show the user a preview of all
decorators side by side before he even selects any other).
IIRC, the (sole?) location would be in DecorManager.cpp while looking up
which decorator to apply to a window. This is entirely from memory and I
code 6/7 days a week on a half dozen or so projects so sometimes things
get fuzzy ;-) Correct me if I'm wrong, I'm not making any claims to
performance increases or stability improvements, just that I *shouldn't*
be causing new issues. Also that a performance increase should be noticed
at boot.
While I'd like to see the patch applied, I'm in no serious rush. I can
always add this patch in manually to get what I need for development. I'm
an absolute perfectionist so I would like to resolve any issues myself so
that future submissions are more easily acceptable.
Further, since the last comments made by you I did a drastic round of code
clean-up. Pe makes the code look perfect in regards to tabbing and
spacing, but on here it does look weird. No idea how to address that,
sorry. My natural tabbing style only has one conflict with the coding
guidelines ( I align in-function - well, everything... ). I removed all I
found in a single round of code cleanup, I'll do another run today (
since, I have the time ).
I have no issue in providing what you call a proper preview solution, but
I prefer a true
live preview. This idea is precisely the method Be used in Dano, because,
when carried to the UI, there are many options ( such as changing just the
Appearance window's decorator when selecting a decorator from the list ).
A bitmap rendering remains static, and is generally unable to demonstrate
any features.
However, the ideas should be combined, IMHO. I still need to find out how
to do the rendering server-side. My original patch had a static preview,
and I got much static from that. One problem is the more you do server-
side the more likely you open you are to system crashes, which is
something I'd like see avoided. (granted a better debugger could go a
long way, I think about the inexperienced user ).
In th eend, the UI development will determine the feature requirements. I
believe a static preview attachment of a set size as a resource would be
ideal so we can merely put GetPreviewBitmap(...) back into
DecorInfoUtility and we have the best of both ideas while permitting
additional creative license to decorator designers.
In any event, this preview functionality shouldn't be a hold-up, IMHO,
nothing is set in stone until a full UI is developed and released to the
public - and then it still is not in stone. I made the changes behind the
scenes in regard to BWindow and Window so that no compatibility issues
would arise.
--The loon
--
Ticket URL: <http://dev.haiku-os.org/ticket/7445#comment:15>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
