Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI Suggestions #264

Closed
habemus-papadum opened this issue Oct 12, 2016 · 17 comments
Closed

UI Suggestions #264

habemus-papadum opened this issue Oct 12, 2016 · 17 comments

Comments

@habemus-papadum
Copy link

Hello --

Here is a list of suggested UI tweaks (obviously, with no expectations they will be addressed but hopefully the list will be useful, and perhaps one day I'll figure out enough to fix them myself):

Many of them may require modifications to ink or possibly upstream in Atom, but pragmatically it seemed sensible to present the list here.

  • Newly opened files should not be added to the Julia Console tab group. Currently, it looks like Atom places new file editors into the last active tab group, however it rarely makes sense to add files to the tab group that is hosting the Julia Console. For instance, when clicking a line number in a stack trace in the Julia Console, the newly opened file opens in a inconvenient location. Possible resolution: The upstream api in Atom for tab groups (i believe implemented by Mike) should have pluggable support for ranking existing tab groups for receiving a new editor. The default algorithm should prefer aspect ratios close to letter paper, in addition to considering most recently active tab. Links created to source files in Ink should allow the user to right click and explicitly select the tab group they want to open the new file (This behavior should be present in the Atom file tree explorer as well)
  • (Re) Support navigating to definition. This is a feature I miss dearly from Atom/LT. The flow use to be something like: in an editor, right click on a symbol, select "show methods", the pop presented would have links to various definitions --> this made it extremely easy to explore the inner workings of Julia code in julia/base or someone else's package. Currently, I use methods(f) in the console to closely achieve a similar flow, but due to the item above, it is less than perfect (and the old flow was really nice). This definitely requires adding support for navigating back so that one can quickly return the prior context.
  • Console Completions stutter with large fonts: Due to my old eyes being incompatible with apple monitors, I use menlo-18 as my normal Atom font. When the completion box pops up in the Console and when Console is at the bottom of the workspace, the completion popup stutters quickly about 15 times, I believe as completions are coming in. This problem seems to go away which smaller font size. If you cannot recreate using cmd-+, let me know and I will try for a screen capture.
  • Inline Annotation Popups inconvenient with large fonts: Currently when inline editor annotations are expanded, they are nearly unusable when using large fonts as there is no way to scroll the content. This is inconvenient as error messages in the inline results have line numbers that I cannot access. My current work around is to right click, choose 'copy', and then paste the content into a scratch editor. In addition to adding a scroll bar, it might be useful to either add support for resizing the inline content by dragging on the bottom right corner, or even better, double clicking the annotation would float the fully expanded content over the workspace until the user either presses "esc" or clicks elsewhere (or clicks on a link to a source file). This behavior mimics "Popovers" in IOS. Finding a fully keyboard driven flow would be ideal.

Again no expectations, and feel free to ask for clarifications. Cheer, nehal

@pfitzseb
Copy link
Member

Thanks for writing this up, those are all very valid points.

  • This has annoyed me as well, and I kinda like your proposed solution even though it might be a bit too unpredictable.
  • We now have a UI element that can somewhat do that on master: When the cursor is over a method, you can call Goto Symbol, which will bring up a method selector that enables you to quickly jump to the definition.
  • This sounds like Much blinking near the end of file atom/autocomplete-plus#680 (and probably is an issue with Atom overlays).
  • I don't think anyone is really happy with the state of inline results right now, but you should definitely have scroll bars in them if you hover your mouse over them. Making them resizeable sounds reasonable, just like auto-expanding them to the right when clicking them. The latter depends on some upstream fixes to Atom though, I think. Regarding "keyboard driven workflow": I have a proof-of-concept for dealing with results here.

@habemus-papadum
Copy link
Author

re: atom/autocomplete-plus#680 -- thanks for the pointer, that is exactly what I was trying to describe. And the styling provided in one the the comments has provided a very nice work around for now!

@habemus-papadum
Copy link
Author

@pfitzseb

but you should definitely have scroll bars in them if you hover your mouse over them

Do you mean this behavior already exists or that it should be implemented one day (I currently cannot find any way to get scroll bars -- my info is Atom 1.10.2, ink 0.5.3, julia-client 0.5.6, osx)

@pfitzseb
Copy link
Member

Inline results should look as follows on mouse over (pointer isn't in the screencapture for whatever reason):
error

@habemus-papadum
Copy link
Author

@pfitzseb I can't seem to get the same behavior. I just see truncated text but no scrollbar regardless of where or how long I hover. I'm on a mac, what platform was your sceenshot taken from.
I even tried placing

.ink.inline {
  //max-width: none;
  overflow: scroll;
  pointer-events: all;
}

in my global atom style file, but still no luck. For now max-width is a work around.

@pfitzseb
Copy link
Member

Very strange. I'm on Windows, but I do think this works on mac, because otherwise @MikeInnes would've noticed. We do have

.ink.inline:hover {
  overflow: auto;
}

in our styling -- can you check if that's applied correctly in the atom dev tools (View -> Developer -> Toggle Dev Tools)?

@habemus-papadum
Copy link
Author

habemus-papadum commented Oct 12, 2016

@pfitzseb It turns out, it is a mac thing related to OSX suppressing scrollbars if you have a track pad and a mouse. http://heresthethingblog.com/2015/03/10/mac-tip-macs-scroll-bars/

Once I changed my settings to something different, everything makes sense, so I am all set with this one!

@pfitzseb
Copy link
Member

Ah, that makes sense. Glad you figured it out!

@TsurHerman
Copy link

+1 for the goto definition enhancement

@pfitzseb
Copy link
Member

Try C-j C-g when the cursor is over a method, that should bring up a selector with which you can navigate to the definitions.

@TsurHerman
Copy link

TsurHerman commented Nov 14, 2016

oh I just love it when my life gets better in a small but meaningful way.
Thanks!

So why not change the right click menu to reveal this wonderful option.
it is currently populated with useless things.

@pfitzseb
Copy link
Member

No reason at all. :)

@TsurHerman
Copy link

Great .. though this I also discovered about toggle-documentation option, neat!
now I need to find a way to disable the rest of Atom useless right click context menu.

what about alt-x for debugging.. it doesn't seem to be working , it works from the command line though
but I am unable to remove a break-point once I declare it

@pfitzseb
Copy link
Member

Right, breakpoints will be removable once Gallium is tagged (or you can switch to Gallium master). Alt-X will work once #275 is merged.

@TsurHerman
Copy link

no further qeustions your honor

@pfitzseb
Copy link
Member

pfitzseb commented Apr 17, 2017

Some progress on this: https://github.com/JunoLab/atom-ink/tree/sp/newrsults.

  • double click will expand the result to fill the whole width of the editor:
    dblclick
  • inline results are automatically resized so they fill all remaining space in the editor.

@pfitzseb
Copy link
Member

Pretty much all of your suggestions have been implemented now! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants