[haiku-development] Re: Contribution suggestion
- From: SoulHunter <hammation@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 31 Aug 2013 17:28:12 +0000
2013/8/31 John Scipione <jscipione@xxxxxxxxx>
> On Sat, Aug 31, 2013 at 11:50 AM, SoulHunter <hammation@xxxxxxxxx> wrote:
> > For example there is the "BS" button, which took me few seconds to figure
> > out it was a "del" equivalent and not a math function wondering why it
> was
> > not labeled as "del" or simply a left arrow (unicode char 2190) like in
> real
> > calculators. Another example is "exp", which caused my confusion with E
> > (10^), because for me it should be "e^x" and "Exp" (10^) or litteraly
> "10^x"
> > (with sup little x if possible), again with "sqrt", for me it should be
> the
> > square root symbol ...
>
> I agree that the BS button is a bit confusing, but, I would think a
> better symbol to use for it would be Unicode 232B ERASE TO THE LEFT
> (⌫).
>
> The exp and sqrt and cbrt buttons are named that way because they call
> equivalently named function in the expression parser, exp(), sqrt(),
> and cbrt() and, well, that was easiest way to implement the feature.
>
> Now, that being said, you could extend the parser to accept e^(), √(),
> and ∛() instead, then you could rename those button labels as such and
> you'd get the feature you want. IIRC e^() already works as exp().
>
> (I hope your email client is set to accept UTF-8 encoded characters)
>
> The parser can be found in src/kits/shared/ExpressionParser.cpp
>
> I'd keep the current function name in the parser in case the user
> thinks to type in exp(), sqrt(), or cbrt() on their own.
>
> > The trivial question here, are my assumptions and suggestions truly
> personal
> > and based on my experience or could I try to tinker with deskcalc to
> > separate the use of the key labels as key codes like it actually does (
> the
> > method is _ParseCalcDesc inside CalcView.cpp) and submit a diff patch
> here ?
> > Or we could discuss about this further ?
>
> We've got complete control in DeskCalc, so, if you wanted to you could
> extend the CalcView::CalcKey struct to have a name that is separate
> from it's label and that might save you from having to do the
> translation in _PressKey(). You could also add a transcendental bool
> to CalcView::CalcKey and use it to add the innertubes () and do the
> selection work without having to compare to the key name for those
> cases also.
>
> The best way to submit a patch IMHO is through a trac enhancement
> ticket, you'll probably want to create a new one for this task.
>
>
Thanks for the feedback.
So we agree that labels could be improved for better usability.
I personally am not in favor of modifying the parser but to use the
functions it offers as they are.
I
am more keen to "translate" the button "operation" to the equivalent
method in the parser.
Finally I think using a key name is a more elegant solution because the
button labels may vary
with the locale and translating the app would be a matter of adding a new
key labels string.
What do you think ?
Other related posts:
