gcalctool 5.29 hides switch for display format in its settings window

[Oliver Joos]

Binary package hint: gcalctool

Using Ubuntu 9.10 I tested gcalctool and compiled 5.29.2 from its git sources (the version for 10.04).

I saw many visual changes since 5.28.1. What I really miss are the buttons/switches in the main window to change "Display Format" and "Angle Units". I often use gcalctool to convert hex<->dec by choosing "Decimal", entering a number and then changing to "Hexdecimal". With 5.29.2 much more clicks are necessary.

See my attachment for a proposal which is more compact than 5.28.1 but more handy than 5.29.2. I also colored some blocks of buttons. This would make it easier to distinguish between different types of buttons. This is just a draft - blocks and colors have to be chosen more carefully than I did.

[John Baptist (jepst79)]

I agree. This is a real deal-breaker for me. The only thing that I use the calculator for is to convert between hex/dec/bin and that is now very difficult. As far as I can tell, there is no way to set the default input base to be something other than decimal. As a result, every time I enter a hex number, I have to remember to push the X_16 button afterwards.

Even worse, if I want to convert to hex, I have to go through the Preferences menu. This is much more arduous than just clicking the radio button that use to be there.

I realize that this GUI change represents a more "stateless" calculator, but it also defies how people (at least, I) expect it to work. Perhaps this change was motivated by people getting confused about which mode they were in. I think there are better solutions. For example, you could always display the current output base in subscript next to the result.

On an unrelated note, the hexadecimal digits are now case sensitive. What the?

I hope you can undo this change by the time Lucid is released.

[Peter Clifton (pcjc2)]

Adding a +1 here, gcalctool is severely regressed in is utility for performing programming related tasks, where converting bases is a very routine operation.

[Robert Ancell (robert-ancell)]

John,

This has been improved in gcalctool 5.29.92 (released 8th March).
You can now add the hexadecimal suffix with Ctrl+H
You can now convert between bases by pressing the base buttons, e.g.:
Enter: 1, E, Ctrl+H
Display shows: 1E₁₆
Press Ctrl+B to convert the displayed number to binary
Display shows: 11110₂

There is an open bug to automatically add the hexadecimal suffix when in hexadecimal display mode (will not be implemented for 5.30):
https://bugzilla.gnome.org/show_bug.cgi?id=610759

[Robert Ancell (robert-ancell)]

Also, lower case hexadecimal is fixed.

"For example, you could always display the current output base in subscript next to the result."
I'm not sure what you mean by that - the result is always shown with the base in subscript, could you give an example?

[John Baptist (jepst79)]

Hi Robert,

Thanks for your response. Well, it's not March yet, so I obviously haven't seen version 5.29.92, but even with the mentioned changes, I remain unsure.

For example, even with the addition of the keyboard shortcuts, I need to remember to take an extra step when entering non-decimal numbers. I agree that pressing Ctrl-H is better than having to click on the X_16 button, but it's still an extra step. With the old gcalctool, when the calculator was in hex mode, all input and output defaulted to hex. The bug 610759 that you mention sounds like it might restore this functionality.

Another question is, how are the mentioned keyboard shortcuts discoverable? For a visual tool like the calculator, it seems that buttons would be better. I think the best thing to do, along with the change from bug 610759 that synchronizes input base with output base, is to have buttons on the main window that allow easy switching between bases (and corresponding conversion of the already-displayed result). It could look similar to the mock-up provided by Oliver. This will produce functionality that replaces the old version of gcalctool.

In response to your question, let me clarify. What I mean is that I imagine that these recent changes were introduced because users would change the input base and then forget about it, and be confused later when they got unexpected answers. Maybe I'm wrong, that just seemed to me like the impetus for the change. I'm saying there are better ways to prevent user confusion in that regard than to always default to decimal input, for example, even as the user is inputting numbers, you could display the base in subscript as part of the input value, as well as the output. But of course this depends on the reason for the change in the first place. I was pretty comfortable with the old system.

Thanks again for your responsiveness.

[Robert Ancell (robert-ancell)]

Hi John,

The biggest reason for the change was that is was impossible to mix number bases in one calculation. GCalctool 5.29.x has undergone a number of internal changes to become more stateless (so it is not a matter of being able to easily revert one feature).
The keyboard shortcuts will be mentioned in the help and in the tooltip text for the buttons.
I agree that it is very annoying to have to enter the suffix for each input number. I think the referred bug will solve this and it seems to meet the suggestion you had in the last paragraph of showing the base as the number is input.
I regret that it is unlikely that the automatic base subscript feature will be complete by 5.30 (though I will try and see if I can fit it).

I am very interested in getting your feedback, if you are able please test the latest version in my PPA:
https://launchpad.net/~robert-ancell/+archive/gcalctool

(hmm, looks like I uploaded it to main archive by accident! So you should be able to test it by updating)

[John Baptist (jepst79)]

Hello Robert,

I tried your gcalctool from the PPA and I can confirm that the shortcut keys work. This is definitely a step in the right direction.

If the main problem with improving gcalctool is a lack of time or manpower, I can help you. I will be happy to work on the code myself, if it would be helpful to you.

[Robert Ancell (robert-ancell)]

Hi John. The problem is both lack of manpower and time! There is myself and Robin Sonefors actively developing and we've only had sporadic amounts of time to work on this release. I would say I only achieved half the goals I had planned.

So any help you can provide will be greatly appreciated, let me know if there's anything I can do to help (I am the gcalctool maintainer).

Note that the internal architecture is half way from the total disaster it used to be to being in good shape so any questions/suggestions/improvements are also very welcome.

[Gustaf (g-rantila)]

This seriously gets me fired up! The removing of extremely useful features, which is in line with gnome over all. How in the name of mother earth can hex<->dec conversion be removed from a calculator in "Programming mode"? How did that discussion go?

"Most people using the calculator in programming mode probably use it to just quickly convert hex to dec and vice versa, so let's remove that feature".
Now I'm just really angry. Why does gnome and its tools need to regress and converge to a fun little netbook-based toy?

Please stop removing the few neat parts of gnome that's left, damn it!

[Oliver Joos (oliver-joos)]

As reporter of this bug I made another mockup, more compact than the one of my comment 1:

For me the subscript mode feels strange, but I can live with it to specify the format of my *INPUT*. What's left is a quick way to specify the *OUTPUT* format. Notice that in 5.29.x it is called 'Display Format'.

I propose to add the widget for 'Output Format' directly left of the main display in all except the Basic view. This way there is still enough space for digits and the main window does not need to grow.

[Oliver Joos (oliver-joos)]

I have made a patch for gcalctool 5.29.1 to solve this bug. Additionally it moves the 'Angle units' widget next to the buttons in the scientific_panel. IMHO this is far more effective and it looks nice.

The only issue left: in Basic View the display is a bit too narrow for the new widget. Furthermore the Basic View should stay *basic*. I propose to disable visibility of the format widget and force 'Decimal' while in Basic View. This is not yet part of my patch!

[Oliver Joos (oliver-joos)]

A screenshot of the new widget positions.

[Nigel Babu (nigelbabu)]

Thanks again for the amazing patch. It would be great if you could submit your patch upstream too.

[Oliver Joos (oliver-joos)]

I already contacted Robert Ancell (current maintainer). He does not agree with adding more GUI elements.

I still hope to find some compromise, as I am convinced that for developers a major use-case of gcalctool was to convert dec to hex and vice-versa.

[Robert Ancell (robert-ancell)]

Jeff, I just noticed I called you John in comment #9, sorry!

[Robert Ancell (robert-ancell)]

My review of the attached patch adding a display mode combo box beside the display in advanced mode:
- GNOME is in a hard code freeze and Ubuntu is in a UI freeze so I'm not planning on making any UI changes before Lucid.
- I would very much like to avoid adding GUI elements like this to an already crowded GUI. I think there are better solutions that can be developed to provide functionality like this.
- The requirement for this element was to easily convert between bases, however this functionality has already been fixed as described in comment #4. There doesn't seem to be a good requirement to quickly convert between other display modes.

The UI is certainly not perfect. Lets continue to work on the design in the next cycle. Programming mode is a splatter of buttons and needs to be seriously reconsidered. A thought is to make the programming mode hexadecimal by default.

[Oliver Joos (oliver-joos)]

@Robert: Now I finally understand how to use the new base buttons to convert hex->dec and dec->hex without changing the result format. Apart from being blind because of my nice patch, I think conversions could be more obvious.

What puzzled me most is that the base buttons react very differently while typing input and after a result is displayed. What about a visual difference, e.g. white background while typing / grey background if an immutable result is displayed?

The base buttons are really intelligent. Press:
[1] [2] [x₂] [x₂] -->12₂₂ [=] -->24
[1] [0] [x₂] [x₂] -->10₂ [=] -->10₂ [=] -->2

Finally correct. But I just don't like calculators that are smarter than me! IMHO if there are less buttons that react more complex, then usability gets worse. Please consider this when redesigning the Programming View.

[Oliver Joos (oliver-joos)]

...i meant "less buttons but reacting more complex".

[Robert Ancell (robert-ancell)]

Instructions for installing the Karmic gcalctool in Lucid:
http://bobthegnome.blogspot.com/2010/04/gcalctool-528-in-ubuntu-1004-lts.html

[Kevin Wang (tsubasa-xw)]

v5.30 still like v5.29, that's too bad~~~ why make it so complex?

[Robert Ancell (robert-ancell)]

Kevin, 5.29 is the unstable release - 5.30 is the stable. So they are the same.

[Mike (mvniekerk)]

Yeah, 5.30 sans Hex/Dec/Bin radio-buttons ships with Lucid. This makes embedded programming a major irritation.

[Robert Ancell (robert-ancell)]

We have taken the decision to downgrade to gcalctool 5.28 for Lucid. I fully support this decision as the best option for the LTS. Please try the 5.31 releases of gcalctool so we can make it the best calculator for Ubuntu 10.10 Maverick Meerkat (I will be blogging details and providing a PPA). Thanks for all the feedback.

[Oliver Joos (oliver-joos)]

Thank you Robert, for making it possible to downgrade gcalctool for Lucid!

I am convinced that for gcalctool 5.31 a good compromise can be found between your valuable work for gcalctool and the needs of developers like me or Mike (e.g. quick and intuitive number conversions).

[Robert Ancell (robert-ancell)]

Here is the mockup I'm working on for 5.31...

The things to note:
- It will support a default base option (requires some changes to the parser)
- The currently displayed number will be automatically shown in the other bases below the display.
- The binary value displayed will be editable.

Feedback encouraged!

[Oliver Joos (oliver-joos)]

I like the colored buttons and an editable binary value.

I'd add some digit separators, like:
12'5715₈ 43'981₁₀
010'1011 1100'1101₂

And perhaps three button colors would be enough. For me only transitions from one color to another count and I see them like digit separators - only for buttons blocks. An absolute mapping from color to function is hard to remember. And last but not least: less is more ;-)

[Robert Ancell (robert-ancell)]

Closing as we are using 5.28 now.

[Oliver Joos (oliver-joos)]

Fix Released?

I'd say for 5.28 it's "Invalid", for 5.29/5.30 it's "Won't fix" and for 5.31 it's "Triaged". And since 5.31 is our focus now we could set it to "Triaged" and change its title to "gcalctool 5.29 and later hides ...".

Otherwise a new bug would have to be opened for 5.31 and all the findings of this bug report have to be referenced.

[Robert Ancell (robert-ancell)]

Well, set it to what you like...
From Ubuntu's perspective this bug doesn't exist as 5.30 is not in Ubuntu. (the bugs here only relate to released versions of packages).

If you want to track this open it upstream:
https://bugzilla.gnome.org/browse.cgi?product=gcalctool

(this will be fixed in 5.31 once I've reworked the lexer/parser/display to handle a default base correctly).

[Oliver Joos (oliver-joos)]

Good point. I cannot set "Triaged" and chose "In Progress" instead as this will also prevent duplicates from people who try out 5.3x. Simple search of Launchpad just won't find this bug if it's Fix Released.

I agree to open a new bug upstream for any issues about the base buttons.

I am looking forward to try out 5.31.

[Robert Ancell (robert-ancell)]

Oliver, do you consider this fixed in 5.32?

[Oliver Joos (oliver-joos)]

Definitely! Very good solution in 5.32, thanks for your work!