Hi,
well I don't know if there are ebuilds for Gentoo, actually, for what I know, there are rpm packages released by some distro vendors. I released only the tar.bz2 format for space saving and because I use slackware ;-)
First of all, Robert wants to encourage your work. So please take his criticisms as constructive, and not merely some random rant.
I while ago he wrote a blog about usability, and used kcalc as a demonstration. You can find it here: http://www.pycs.net/lateral/stories/33.html. With kalcoolus you seem to be duplicating the mistakes of kcalc, and he mentioned it in yesterday's blog here: http://www.pycs.net/lateral/weblog/2005/03/08.html#P283.
In a nutshell, his main concern is that the command line interface (CLI) to bc was sufficient, and that the GUI frontend of kalcoolus has considerably reduced usability. You need to read his first blog to understand why. He is not arguing that kalcoolus should never have been done, but rather that the approach it is taking is the wrong one.
I accept criticism. Yes perhaps my approach is wrong, but consider that the kcalc interface is very familiar, for historic reasons, to most users. I would simply create a graphic tool that uses bc as an engine and that looks familiar to kde users. When I rewrote KFilereplace, some user told me that a command line utility like find is enough... yes, it is, but I found that much users like KFilereplace... I think kalcoolus will be usefull though it "wrong" design.
The problem is people think that the GUI and command line cannot ever meet. This is the wrong approach. Look at traditional CAD software, they all have a command line in the GUI. Kalcoolus (and kcalc) can do the same. That's all Roberto is asking.
Ok, but in a certain way kalcoolus has a command line; I added a tab page in wich user can add it own functions code. I'm not saying that GUI and command line are orthogonal, I'm saying that looking to physical calculator is not bad. Using a GUI implies to put constraints to user actions, these constraints are not negatives, they build a familiar work environment and prevent user to make mystakes. And if something is not so familiar, people can consult manuals. With a single button kalcoolus save all your preferences and user defined items in a database and reload them from one session to another. Kalcoolus now has syntax highlighting, well I implemented this feature in 20 minutes! But if people need more flexibility, then they open a terminal and use bc interactively. Perhaps the word frontend is not totally correct, actually kalcoolus uses bc as engine, and try to extend its capabilities when needed(I'm planning other features that bc does not have). I think this is not a wrong approach; old approach yes, but not wrong.
I also agree that there should be a better way to input. I just compiled and ran kalcoolus on my laptop and its very hard to use with the touchpad and the thin buttons. It would be nice to be able to type in functions.
Such a feature would also be useful for people who are copying some expression from some other source. Most (probably all) other calculators force you to retype it-- scratch that, re-click it. Your application _is_ a little better than most because it lets you see the full expression whereas other applications mimic the single 10 digit display for both answer and input.
Anyway, a text input field would be cool because then if the user messed up, there could be an "up/down" history like on the terminal that would allow him/her to edit the mistake.
I don't see how it will be hard to implement since with the current mouse input its still possible to have invalid input: try using the custom function with multiple parameters, its pretty hard to use. With a text input, I could have typed "a + test(1, 3, 4)" and gotten my answer in about 3 seconds. Mouse input took me 45 seconds, and never figured out how to set the second/third parameters.
But other than that, this application seems very good. I voted "good" for it.
Hi Roberto,
you pointed out problems, that I'm trying to solve. I know that moving through the line of the editors is a bit tricky, so I'm thinking to replace input/output editors with a sort of mini electronic sheet of two colums and N rows. This way should simplify both implementation and usability. User will see each line clearly separated and keyboard editing should be more simple. For now I added two DCOP methods to permit user to send data to kalcoolus/ and receive data from it, it could be usefull for example, if you want to copy data to/from a text file opened with kate.
However stay tuned and thank for the hints :-) if you find bugs please let me know.
Ratings & Comments
12 Comments
A SlackWare 10.2 TGZ Package is ready to download!!! http://www.slacky.it/ http://www.slacky.it/index.php?option=com_remository&Itemid=1&func=fileinfo&filecatid=750&parent=category
Are there any Gentoo ebuilds for Kalcoolus?
Hi, well I don't know if there are ebuilds for Gentoo, actually, for what I know, there are rpm packages released by some distro vendors. I released only the tar.bz2 format for space saving and because I use slackware ;-)
He means that the program is currently in an early state of developement and if the author (Emiliano) wants he can still change his basic approach.
It's worth a reading: http://www.pycs.net/lateral/weblog/2005/03/08.html Kalcoolus está todavía en una fase muy temprana de desarrollo, así que si Emiliano lo desea, podría cambiar su enfoque.
I'm sorry, I don't understand spanish :-(, could you repeat in english or italian? :-)
First of all, Robert wants to encourage your work. So please take his criticisms as constructive, and not merely some random rant. I while ago he wrote a blog about usability, and used kcalc as a demonstration. You can find it here: http://www.pycs.net/lateral/stories/33.html. With kalcoolus you seem to be duplicating the mistakes of kcalc, and he mentioned it in yesterday's blog here: http://www.pycs.net/lateral/weblog/2005/03/08.html#P283. In a nutshell, his main concern is that the command line interface (CLI) to bc was sufficient, and that the GUI frontend of kalcoolus has considerably reduced usability. You need to read his first blog to understand why. He is not arguing that kalcoolus should never have been done, but rather that the approach it is taking is the wrong one.
I accept criticism. Yes perhaps my approach is wrong, but consider that the kcalc interface is very familiar, for historic reasons, to most users. I would simply create a graphic tool that uses bc as an engine and that looks familiar to kde users. When I rewrote KFilereplace, some user told me that a command line utility like find is enough... yes, it is, but I found that much users like KFilereplace... I think kalcoolus will be usefull though it "wrong" design.
The problem is people think that the GUI and command line cannot ever meet. This is the wrong approach. Look at traditional CAD software, they all have a command line in the GUI. Kalcoolus (and kcalc) can do the same. That's all Roberto is asking.
Ok, but in a certain way kalcoolus has a command line; I added a tab page in wich user can add it own functions code. I'm not saying that GUI and command line are orthogonal, I'm saying that looking to physical calculator is not bad. Using a GUI implies to put constraints to user actions, these constraints are not negatives, they build a familiar work environment and prevent user to make mystakes. And if something is not so familiar, people can consult manuals. With a single button kalcoolus save all your preferences and user defined items in a database and reload them from one session to another. Kalcoolus now has syntax highlighting, well I implemented this feature in 20 minutes! But if people need more flexibility, then they open a terminal and use bc interactively. Perhaps the word frontend is not totally correct, actually kalcoolus uses bc as engine, and try to extend its capabilities when needed(I'm planning other features that bc does not have). I think this is not a wrong approach; old approach yes, but not wrong.
I also agree that there should be a better way to input. I just compiled and ran kalcoolus on my laptop and its very hard to use with the touchpad and the thin buttons. It would be nice to be able to type in functions. Such a feature would also be useful for people who are copying some expression from some other source. Most (probably all) other calculators force you to retype it-- scratch that, re-click it. Your application _is_ a little better than most because it lets you see the full expression whereas other applications mimic the single 10 digit display for both answer and input. Anyway, a text input field would be cool because then if the user messed up, there could be an "up/down" history like on the terminal that would allow him/her to edit the mistake. I don't see how it will be hard to implement since with the current mouse input its still possible to have invalid input: try using the custom function with multiple parameters, its pretty hard to use. With a text input, I could have typed "a + test(1, 3, 4)" and gotten my answer in about 3 seconds. Mouse input took me 45 seconds, and never figured out how to set the second/third parameters. But other than that, this application seems very good. I voted "good" for it.
Hi Roberto, you pointed out problems, that I'm trying to solve. I know that moving through the line of the editors is a bit tricky, so I'm thinking to replace input/output editors with a sort of mini electronic sheet of two colums and N rows. This way should simplify both implementation and usability. User will see each line clearly separated and keyboard editing should be more simple. For now I added two DCOP methods to permit user to send data to kalcoolus/ and receive data from it, it could be usefull for example, if you want to copy data to/from a text file opened with kate. However stay tuned and thank for the hints :-) if you find bugs please let me know.