GNOME Bugzilla – Bug 743499
Awkward relationship between input area and results list
Last modified: 2016-10-20 07:52:06 UTC
Created attachment 295391 [details] mockup When you type an equation and press enter, the equation jumps over to the other side of the window. This makes it quite hard to follow what is happening, and feels awkward. As a way to fix this, we could: * Use the same text size for the results and input areas. * Left-justify equations, both in the results and input areas. * Right-justify results. * Insert new results at the bottom of the list and scroll up. See the attached mockup for how this could look.
Adding to the 3.16 target, since this is the most obvious issue with the results history feature which will be appearing in the next release.
Has any progress been made here? If not, this is probably not a 3.16 "GNOME Target" as we are under UI Freeze for 3.16 now.
Allan, Thanks for the feedback. (In reply to Allan Day from comment #0) > When you type an equation and press enter, the equation jumps over to the > other side of the window. This makes it quite hard to follow what is > happening, and feels awkward. > > As a way to fix this, we could: > > * Use the same text size for the results and input areas. If we increase the size of text in history area, it will look great for small equations, but will look clumsy for larger equation. Especially in basic mode, where the total window width is really small, by increasing the text size, we will end up with most equations unable to fit into the allocated space. . On the other hand, in my opinion it's not a good idea to reduce the input area text size either. It'll become harder to use the Calculator with really tiny text. > * Left-justify equations, both in the results and input areas. > * Right-justify results. Do you mean, we show both equation and live results of the entered equation simultaneously? e.g. +--------------------------+ | ... | ... | | <equationt> | <ans> | <--- History part +--------------------------+ | <equationt> | <ans> | <--- Input area +--------------------------+ This is not possible because there is no way to safely kill a spawned calculation thread, which means if there is a long calculation, the answer section will freeze till the calculation is over. If you mean to say, show input as left justified while the user is entering the equation, and right justify the answer when user presses enter (or clicks "="), doesn't it create same issue as equations jumping to the other side of the window? > * Insert new results at the bottom of the list and scroll up. Isn't this already working? The equation is always inserted at the bottom, and the list is scrolled up. (that is working as expected on my machine). > See the attached mockup for how this could look. Alternative to the left vs right justification of the input area, can we make the equations of history view right justified? e.g. +--------------------------+ |1+1 = 2 |(What is currently implemented) +------------vs.-----------+ | 1+1 = 2 |(What I'm suggesting now) +--------------------------+ This will reduce the displacement of an equation by as much as 3/4th of the window size when user presses enter.
(Allan is out this week) I think he really wants the input line to be always left aligned, both for entering the equation, and when it gets replaced with the answer. And yes, that means that the answer will 'jump' from the left to the right (in the history).
but probably time to move this off the target list as well.
(In reply to PioneerAxon from comment #3) Sorry the slow reply - I only just noticed your comment. ... > > * Use the same text size for the results and input areas. > > If we increase the size of text in history area, it will look great for > small equations, but will look clumsy for larger equation. Especially in > basic mode, where the total window width is really small, by increasing the > text size, we will end up with most equations unable to fit into the > allocated space. > . > On the other hand, in my opinion it's not a good idea to reduce the input > area text size either. It'll become harder to use the Calculator with really > tiny text. The basic issue is that different font sizes don't look good - they make the whole UI feel inconsistent, inelegant, and harder to read. And I think that the constraints are roughly the same for the input area and the results list - small text is more difficult to read for both, and space constraints will become apparent in either. Perhaps a happy medium can be found between the two existing font sizes. We could also look into problems with running out of space in the results list. Making the window resizable is one possibility. Another would be to wrap the equations in the results list. > > * Left-justify equations, both in the results and input areas. > > * Right-justify results. > > Do you mean, we show both equation and live results of the entered equation > simultaneously? > > e.g. > +--------------------------+ > | ... | ... | > | <equationt> | <ans> | <--- History part > +--------------------------+ > | <equationt> | <ans> | <--- Input area > +--------------------------+ > This is not possible because there is no way to safely kill a spawned > calculation thread, which means if there is a long calculation, the answer > section will freeze till the calculation is over. > > If you mean to say, show input as left justified while the user is entering > the equation, and right justify the answer when user presses enter (or > clicks "="), doesn't it create same issue as equations jumping to the other > side of the window? My primary suggestion here would be to not show results in the input area, since they are now shown in the results list above. However, if you want to continue showing the result in the input area, you could possibly show them on the left. > > * Insert new results at the bottom of the list and scroll up. > > Isn't this already working? The equation is always inserted at the bottom, > and the list is scrolled up. (that is working as expected on my machine). It is true that the results scroll up. However, when you first enter an equation, the result appears at the top of the list. Ideally results would always appear directly above the input area. > Alternative to the left vs right justification of the input area, can we > make the equations of history view right justified? > e.g. > +--------------------------+ > |1+1 = 2 |(What is currently implemented) > +------------vs.-----------+ > | 1+1 = 2 |(What I'm suggesting now) > +--------------------------+ > > This will reduce the displacement of an equation by as much as 3/4th of the > window size when user presses enter. The equation would still appear to move across though. I don't think that merely reducing the movement is enough here - the whole point is to make it appear like the equation is simply shifting up from the input area to the results list.
(In reply to Allan Day from comment #6) > My primary suggestion here would be to not show results in the input area, > since they are now shown in the results list above. However, if you want to > continue showing the result in the input area, you could possibly show them > on the left. This implies a slight behavioral change: the result of the previous equation would no longer automatically become the first value in the next equation. Is that what you want? I was thinking we'd need to add an ans (for "answer") button in that case, to insert the result of the previous equation, but actually you can just click on the result in history.
Created attachment 329349 [details] [review] Added CSS classes to history entries and changed a few things. Hi everyone. I made a small patch that gives history-entries and its children labels a CSS class, and made sure that the background is now a bit darker(amongst others). Maybe this is something we can start from?
Review of attachment 329349 [details] [review]: Thanks for the proposed patch. This is indeed a good start, with a minor adjustment: * with history-entry border set to 1px we get double-borders both on the sides (parent border+entry border) and between entries (bottom border of top entry and top border of bottom entry), I think simply using bottom-border (with a :last-row exception) would be better.
@ Niels De Graef : Could you please check and update the patch (based on the review)? Due to the recent changes, it does not apply anymore.
Created attachment 337393 [details] [review] Proposed patch (applicable to master) Done!
(In reply to Niels De Graef from comment #11) > Created attachment 337393 [details] [review] [review] > Proposed patch (applicable to master) > > Done! Strange, this still doesn't apply to me on current master. A recent commit has fixed reusing results from history (https://git.gnome.org/browse/gnome-calculator/commit/data/history-entry.ui?id=c0888820198f7a072c0e72ea42ca89e08efa5c64), and it looks like the version you have based your patch on, does not include this commit.
Created attachment 337502 [details] [review] Proposed patch - applicable to master (7432b72) Whoops, my bad! This time it should work.
Review of attachment 337502 [details] [review]: It's a good start indeed, at least we have some styling and more stylability by the separately added '=' sign, pushing this to master, but let's not stop here :)
I have made a couple of fixes, alignments, padding, font size adjustments, so that we are closer to the mockups. The remaining item is to insert history entries at the bottom and scroll up.
@everyone: I have fixed this on master, and I can say I am pretty happy with the result. It is completely what Allan has suggested, and I feel it is natural. It would be great if you could test it and provide some feedback. As I consider this fixed (everything from the description and the discussions has been implemented), I am marking this as fixed in head, if you have any suggestions for improvements, feel free to comment (and optionally reopen). This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.