jokkedk/webgrind

Select cachegrind file from above - there is nothing "above"

OnkelTem opened this issue · 4 comments

OnkelTem commented

Just launched the project for the first time, see the page saying

                     Select a cachegrind file above
(looking in /data/xdebug/ for files matching /^cachegrind.out..+$/)

but there are no files "above" or below or on sides. Just don't get from where to start?

chipitsine commented

check open_base_dir setting, is your webgrind installation allowed to open files from "/data/xdebug" ?

alpha0010 commented

The "above" refers to a dropdown box at the top of the screen (just after the word "of"). If this box is empty, it means webgrind cannot find any cachegrind files.

  • 👍1
  • 😄1
OnkelTem commented

@alpha0010
Thanks I've finally located it!

xparq commented

Yups, just FTR: that same thing caused some headache here, too, for the first time...
I even started debugging Webgrind first, checking that getFiles actually still gets it OK, so WTF?!... ;)

...Until finally realizing that albeit the UI shows absolutely no indication that it has found anything, AND the displayed default Auto (newest) is just the option I'd like (so there's no reason to click that list, to discover the file actually hiding there!).

BUT, that alone may still not have been enough to baffle me, without yet another trick on the UI to defeat the user: the "update" button...

Update what? The list? The preprocessing data? The screen? I just didn't want to "update" anything, until I knew what it would do.

So, why not "Show"? Because that's what it does. And vice versa: nothing is actually shown, until one clicks that button.

(Moreover: it doesn't even seem to actually "update" anything (but the screen...) when repeatedly clicked, it just reads the last cached (preprocessed) data. The fact that it also happens to do some lengthy preprocessing the first time is just an unavoidable internal impl. detail of the "Show" action, so the label should reflect the user intent, not that implicit internal, uninteresting "updating of data" calculation, which is actually irrelevant for the UX. Some "please wait, updating whatever" message, while actually preprocessing (after clicking "Show") would be enough -- exactly as it's been done already. In fact, that's a quite nice part of the UI, actually.)

Thanks for the patience. Oh, and BTW: Webgrind is awesome, thank's a lot for the great work!!!

UPDATE:
OK, I now realize the rationale for the "update" label: indeed, there's a use case when the data is updated in the background (e.g. by an app page reload or test run), and the user is monitoring the change on the same Webgrind page, refreshing it with "update". So, indeed, that's a screen update then.

Nevertheless, people seem to get confused when facing it the first time.

So, if the page is rendered empty for the first time, when there's nothing to update actually (but the empty page), it could/should still set the button label to something like "Show".

  • ❤️1