[haiku-commits] Re: r41215 - haiku/trunk/src/add-ons/input_server/devices/keyboard
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 12 Apr 2011 22:58:19 +0200
"Jonas Sundström" <jonas@xxxxxxxxxxx> wrote:
> Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> > jonas@xxxxxxxxxxx wrote:
> > > Log:
> > > Add a Quit button to the Team Monitor.
> > While it doesn't hurt, isn't that the wrong tool for that job?
> > Why not simply use the Deskbar, or even the Switcher?
> I've found myself in the Team Monitor on a couple of occassions and
> missing a quit option. Sometimes one might want to try quitting
> something before killing it, so why not have both options.
Sure, I just think the Team Monitor shouldn't really be something a
normal end user should ever need or want to use.
There is a reason that it has a "Force Reboot" button, and that it
floats over all windows - it's a tool meant as a last resort solution.
"Quit" seems almost too nice to end up in there.
> We're probably underusing the Team Monitor since we're so used to
> having ProcessController so prominently in Deskbar.
>
> I would like to break out the Team Monitor to a stand-alone app and
> merge it with ProcessController. A fullsize version of it. Which the
> keyboard input_server add-on would launch on Ctrl-Alt-Delete.
> Perhaps also the ActivityMonitor.
Nope, please not! That would repurpose the Team Monitor to be something
else. Furthermore, it couldn't fulfill its former purpose anymore this
way - if the system is going havoc, it might not be able to launch
another app; the Team Monitor is already loaded at that point, and will
still work just fine.
While I have nothing against a fullsize version of ProcessController,
Team Monitor should not be part of that vision.
> > > +TeamListItem::IsApplication()
> > > +{
> > > + if (fAppSignature.Length() > 0)
> > > + return true;
> > > + else
> > > + return false;
> > > +}
> > 1) in these cases, the "else" is superfluous,
> > and should be removed to make it clearer.
> I would argue that if() return / else return is more beautiful,
> or balanced, from an algorithmic point of view. Perhaps it's
> a matter of taste.
Not really: the indentation, and the "else" are hiding the actual
program flow, and that makes it harder to see what the function
returns. Of course, there are examples of this obfuscation that are
harder to follow than the example you did :-)
Bye,
Axel.
Other related posts:
