[haiku-development] Re: Final Set*UIColor Patch, Version 3e

  • From: looncraz <looncraz@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 22 Nov 2015 12:25:19 -0600

On 11/22/2015 03:07, Stephan Aßmus wrote:

Hi,

Howdy!


It is just not true that you got little feedback on the technical side. The immediate feedback was that it would be much nicer to have a timer mechanism integrated with the BLooper "waiting for the next message" loop. But it didn't seem like you were interested in this feedback as I don't remember any discussion evolving around that.

I received some early on, yes. And I'm sure there is still plenty more to discuss, but the style-comes-first attitude presented detracts from any such discussions.

I did respond to that, but the result would be unusable for my purposes and is well beyond the scope of this patch. app_server needed its own facilities, the client side work is very different. I fully redesigned DelayedMessage twice while trying to figure out why the proper way wasn't working. Then I found a bug in LinkReceiver for handling timeouts and fixed it, then my code worked perfectly and was "overly robust" as a result of thinking the problem was with my code.

I think such a timer mechanism would be the direct solution for many problems. I am about to review your patch, so I may be wrong. But it sounds like you have a solution for a messages delivered after a certain timeout. Which is exactly what BMessageRunner can already be used for. I am sure you had good reasons to not use BMessageRunner, but on the client side, I wonder if DelayedMessage will open up new use-cases. Again, I will have a closer look now...

DelayedMessage goes far beyond what such a system could manage. Its most vital feature is the ability to merge messages by the use of a simple flag (and an optional data mask). Next is its ability to have allocation and copy-free message merging. Next is its freedom to not need to send a message now to send a message later.

BMessageRunner would necessitate that the messages would always be delivered... and won't work in the app_server without using private BMessenger hacks in any event.

Thank you for looking at it!


Thanks for making as many changes as you did. It is perfectly understandable when you are concerned about not having any more time. I regret you had to write your earlier mail, since I feel it will be mixing in bad feelings for the wrong reasons.


Thank you. I love to code, and I have an obvious affinity for the Be API ;-)

I do think some people have taken my email as being more than what it is. As I've said repeatedly, my only concern with this is a systemic issue of prioritization of form over substance. The attitude presented to me lately, by Axel, has been very off-putting. I was careful to not to single anyone out in my original e-mail, but his response is nearly as off-putting as ever, and it seems many many people agree.

Telling someone you are wasting their time because of a few minor style issues is a great way to lose contributors and shows a lack of appreciation for the efforts being expended. It may have taken him 1 hour to review the code, but it took me 150 hours to create it, most of that acquiescing to his every request politely and timely.

Thanks,

--The loon

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 11-2015