Fork me on GitHub

One thing I've noticed is people nav-ing into values accidentally. I'm thinking of changing it from a double click to a right click. How do folks feel about that? If so, should the value be selected before right click is enabled?


I think that would be much worse - right click is universally understood to be "bring up a context menu" and I would be very surprised to have it cause some change in the application state

ā˜ļø 3
šŸ‘ 3

maybe something like Ctrl/cmd - click?


TBH, I'm not sure I even realized that double-click worked like that...!

āž• 1

Ctrl/cmd - click is already mapped to multi-select


I could just remove it entirely šŸ˜‚


yeah, click + enter seems intuitive enough


I think I was trying to mimic finder and other file system browsers with the double click behavior, but the timing feels off


I think the difference is that file explorer UI has a "button" metaphor whereas Portal behaves much more like "selectable text"


I was just trying to copy a chunk of text in a pr-str viewer by double-clicking in the middle of a word and dragging (unconsciously) and this triggered the nav action

šŸ‘ 1

The accidental navigation with double click has happened to me once in a while but I just nav-back. It's not usually an issue because I avoid using mouse as much as possible.


> Ctrl/cmd - click is already mapped to multi-select related: is it possible to have a command do multi selection? I'd love to be able to multiselect stuff without using the mouse šŸ˜„


I quite like the double click to navigate, I do use mouse a lot, and I think double click to go in is intuitive, I prefer if you keep it šŸ™‚

āž• 2
Ben Sless04:05:58

Shift click?


I use the keyboard so I don't care much about mouse stuff šŸ™‚


Is it just me who finds the "inspector" viewer's collection indicators to be confusing? The [1] syntax evokes some sort of indexing system / IPython evaluation order indicators instead of conveying the number of items in the collection. Either that, or they're mistaken for the actual value - eg. #{5} looks like an actual set containing a single number 5 instead of a 5-element set.


Yeah, I often get that in my head. I think [] : 5 and #{} : 5 would be a better way to display that (or something similar) @U1G869VNV?


I was thinking subscripts, like [ ]ā‚…

Cora (she/her)20:05:18

it might be instructive to see what chrome and firefox and safari do for this in devtools

šŸ’” 2
Cora (she/her)20:05:42

I'm sure they've worked on that quite a bit and there might be some usability bits to learn from


Agree, it's the thing that confused me the first time I saw portal. @U02N27RK69K nice suggestion, I think the Chrome dev tools try to show you a map/array inline if possible, or with an overflow if not.


The number of entries is definitely useful as a sanity check -- if I eval something and get #{0} when I'm expecting maybe #{54} that's immediately useful. Similarly for #{10} vs #{275}. So I wouldn't want to lose the cardinality, regardless of how else it is displayed.


Chrome devtools doesn't indicate cardinality, except by chance when the length prop of an object gets shown in the inline key-value display. Neither does Cider Inspector or Proto REPL, of those which I've tried before. It's definitely a handy sanity check, but it gets tricky when dealing with lazy or infinite seqs - our codebase has quite a few of those, which Portal just does not handle at the moment


Cider inspector has the concept of a 'page size' so it only realises the first N=32 elements of a seq and displays uncertainty page 1 of ? until you reach the last page. I guess this could be implemented in Portal by a Show More button, using bounded-count and keeping track of the number of realized elements so it could display something like (50++)


For what it's worth, I managed to get a dev setup going and implemented the subscript idea to see how it would look šŸ™‚

ā¤ļø 1

or alternatively:

ā¤ļø 1

I love the second one!


For some reason it's much more obvious to me that there's stuff inside the data structure, and that it's a clickable thing.


Yeah, I like that. Even just the ... helps.


@UCPS050BV I'm down to try this change, just make sure to use the unicode ā€¦ :thumbsup:


I tried it but it was a little too cramped in a monospace font for my liking


(let me know if you want a PR, I don't need the credit)


ultimately I think the collapsed preview should be a truncated one-liner of the collection contents - now I find myself stepping through the keys one by one and cycling the viewer to pprint to achieve this

ā¤ļø 1

here's cider-inspector's rendering of the same data for reference - in this case I would prefer the cardinality indicator to be outside the brackets to avoid confusion with its contents ie. ( 0 1 2 3 4 ... )ā‚ā‚€ [ 1 2 3 [ 4 5 6 ] ]ā‚„


Yes, exactly, @UCPS050BV - if there's space to show a bit of data, that's a huge usability improvement: ā€¢ sometimes results fit in the line, no truncation necessary ā€¢ even when they not fit, seeing a couple of results helps to identify the value, in the context of the domain


Also, my keyboard navigation gets broken after every nav action, I have to select-root via the command palette or click on something with the mouse to get it working


I believe you could just hit enter instead of ctrl+j and selecting from the popup? That might keep focus better?


yes that's what I mean - after selecting a collection and pressing enter to nav inside it, the selection loses focus and I have to click somewhere to get the selection back.


Good catch. I think this was a recent regression but should be fixed by change

ā­ 1