In its TI-89 compatibility mode, it makes an excellent everyday-use calculator with bonus super-advanced capabilities (symbolic integration, for example), but the user interface is not very nice. With a little work on a KDE frontend it could be awesome. Students would love it.

No, I'm half serious, when I need a calculator I just use the interactive python interpreter. (I guess I should rename it kython ;)
(anyone who has learned to program in any language should find it very easy to use AS A CALCULATOR).

As far as usability goes, I think this (UseCalc) is great. Good job Robert. People have distorted ideas about what usability is, and just because it looks like a calculator, doesn't mean it is usable.

I guess that my point was why do I even need a calculator program? (I'm trying to take what you are saying a step further). There is already something installed on my computer that does it just fine.

OT RANT WARNING....

To me a kalculator is just bloat (in fact 80-90% of kde/gnome are bloat to me). Don't take this the wrong way, I love kde and have been using it on the desktop since 1.x days. But I'd much rather lose all of the bloat. To me more important is to have integration between best of breed apps.

I mostly use audacity, firefox, cinelerra, dvdstyler, gimp, inkscape, eclipse, kde (mostly for k3b and konqueror file browsing (fish://, etc), want to try digikam at some point), emacs. (I'm still looking for the best of breed multimedia app, using xine for dvds and mplayer for things that xine chokes on, but xmms, and noatun just don't feel good). It would be nice if these apps played together nicely (sound, printing, drag and drop, etc). (And that I don't have to install all of the other apps for kde when I mostly just want k3b and konqueror).

I blame it on Alex. After I saw this I had to write my version in Ruby using Korundum. And thanks to Aaron I can even show it: http://www.bddf.ca/~zrusin/kalc.tar.bz2 . It uses KComboBox with a history instead of a lineedit. I simply preferred it that way. Also uses text browser instead of a listview to display the results. I thought it seperates it nicely. The main gui is done in designer so people who don't know ruby can play with it. You can also define your own variables in it which is kinda neat.

There are so many ways to improve kcalc. There is no history. You can't easily review and correct what you have typed. There.. mmmm... I really can't complain much more about it, because there are just no features to complain about.

I'm not sure if an improved calculator (but remember, we're talking about the default, basic, standard KDE calculator here) should duplicate the physical keys of the keyboard, but somehow it should *look like* a calculator and not like the prompt of bc. Otherwise the target audience will never touch kcalc and use their plain old solar calculator (or your HP48G, whatever) instead.

Maybe the number buttons could be replaced by a "Casio"-Logo in the top right corner, so it will still look somewhat familiar.

At the moment there is really no reason not to use a physical calculator, since kcalc is just a clone of it.

I wonder why you are asking this question, since your calculator makes much better use of the capabilities of a computer. The only problem I see with it is that it won't work for people with a weak mathematical background. The goal should be to provide a better calculator for those who use nothing more than basic calculators now.

Of course I wouldn't mind any advanced features, but the highest priority must be to make it instantly usable for every kde user.

> At the moment there is really no reason not to use a physical calculator, since kcalc is just a clone of it.

So how do you copy & paste between an application on your computer and a physical calculator?

(From the article):

> The supported operators are the usual, plus parenthesis, and ** which is power. If you want a square root, just use **0.5. If you want, I can add something more obvious.

This is a regression from KCalc. If somebody wants a square root in KCalc, they see the square root button and hit it. If somebody wants power in KCalc, they see the button and hit it. Learning new syntax for such a simple application that *already works* is insane. It would work well if normal keyboards had square root and power keys on them, but they don't, so your whole principle of "the keypad already does what we want" is false.

I know that´s not good. I also know, and said, that this is just a prototype application. In fact, in another post, I mentioned that some buttons could come handy. The square root one is a good such example.

And yes, there *must* be something that´s easier using kcalc.

Sure, only 1% of the users give a damn, but it´s easier to do square roots.

And you are obviously being argumentative, but the keyboard does have a "1" button. That it doesn´t have a sqrt button doesn´t invalidate the argument I made about number keys, it invalidates the argument I *didn´t* make, about square roots.

Actually, it's you that appears to be argumentative. Simply disagreeing with one of your fundamental premises doesn't make me argumentative.

> but the keyboard does have a "1" button. That it doesn´t have a sqrt button doesn´t invalidate the argument I made about number keys

Yes it does, unless you split the interface between the mouse and keyboard. If, as you now suggest, add a graphical sqrt button, it means people making use of it are constantly switching between the keyboard and mouse. It's a basic ergonomics mistake. If you expect people to use the mouse for that task, don't force them to switch back to the keyboard for related tasks unnecessarily. If half the interface is the keyboard and half is the mouse, the application == calculator metaphor is completely broken.

Of course *I* was being argumentative. That{ s the whole point of the article.

But anyway, regarding your comment, I call bullshit. Every application has the interface split between keyboard and mouse: the common tasks are easier to access with the keyboard, the harder ones have both a harder keyboard shortcut, and a mouse access.

Consider a word processor. The text input is done via the keyboard, and there isn´t any way to perform it via the mouse. But switching to bold can be done via the keyboard (not too obvious), and a easily seen mouse interface.

The obvious analogous situation is that number and basic operation in a calculator should tend to be keyboard-based, while not-often used functionality should be mouse-accessible.

So, what you say about usability seems pretty much something you just made up right now. And yes, the point that the application == calculator metaphore is broken is absolutely right. That´s why my interface proposal dumps it.

I know a lot of people almost running away of mine because they are completely lost with the RPN mode. But OTOH people using HP's will be in science/enginering fields and have no trouble using algebraic expressions as input.

That said, I also do not prefer a different Calc. Maybe a dumber one, as you do not want to do anything really serious with it, just a few sums when you are in the computer, not your 50 items math homework. The only trouble about dumbing it down is what features should be left to keep people happy. I rarely do DEC-HEX conversions, I guess other people want to keep almost every else feature available.

I prefer the way HP calc series (such as my HP-48G) do work, using inverse polish notation. Specially liked the possibilities that the calc offers to this way of operating, making possible to operate things on the stack...

I fully agree with you that Kcalc needs a replacement or overhaul. Especially the "paper log" is something I often miss.
But about the buttons: I actually use the number buttons from time to time. This is during phone calls, when I have one free hand only, so I don't like shifting back from the mouse to the keyboard. Suggestion: Groups of keys should be enabled separately.
Another suggestion: It should be possible to go back on the paper say 10 rows, update a number there and have everything below recalculated accordingly.
Final nagging: My old TI59 has a display mode "engineering", where the exponent is normalized to multiples of 3. This would be cool; even more so by replacing the exponent with the SI-Unit prefixes (3=k, 6=M, 9=G, ...)

We did a business calculator in Kommander. It does a paper tape type log and allows you to enter basic math formulas which are entered into the log along side the total values and it provides a summary value at the bottom. It's okay as it is but we wanted to add the ability to output printed results too. Anyway because it's Kommander it's small, fast, easy to enhance and only requires that you have kdewebdev 3.3 installed. Enjoy.

BTW as a security measure it will complain if you try to run it from a non local source.

This is just another example of a big difference between different types of people when it comes to doing calculations. Some people have to write things out, think slower, and prefer using graphing calculators where they have to type a whole problem in some horrible mess of parentheses, not thinking linearly through the problem as to the order of calcuations as they type, but of the order they have to type to get the calculator to do the right thing.

Then there's people who think faster, can keep track of some things in their head, and prefer scientific calcuators with memories (yes plural, mine has 7 instead of one), and can fly through complicated calculations (in a much more linear and logical fashion I might add) much faster than others.

And it's not to say there's anything wrong with you whether you fall into one group or the other, you can't change who you are. Some people will just prefer the style of interface you have shown, and for some KCalc just is more usable. Not that there isn't room for improvement.

I am sure you can calculate 20% of 75 plus 15% of 64 faster using your calculator, right?

I mean, .2*75+.15*64(enter) is so much slower than .2*75(push into mem).15*64+(pop from mem)= :-)

For each approach used to interface the calculator, there is some set of problems that are slower. My own guess (and nothing more than that) is that this approach is faster for a significant set of problems.

.. And this is where an rpn interface would shine.
.2 [enter] 75 [*] .15 [enter] 64 [*] [+]
You get to see intermediate results, and get to enter in the order written, evaluating as you go. The only practical problem with the RPN approach is stack height, but that's not a problem with a calculator based on a computer, with kaboodles of memory.

PGCalc2 lets you enter number and operators directly from the numpad, and use the mouse for things like SIN.

The example you gave should take the exact same keystrokes actually, so no advantage either way there. With other problems, *nothing* will be faster with a usecalc/graphing calculator interface if you know what you are doing.