### percieved working * open the file plugin in the sidebar * single click a file - it opens in an editor tab (say preview mode tab) in the read only mode (with some indication - say, the name in the tab bar in italics) * single click another file - it opens in the existing preview mode tab, and similar manner * repeat with as many files as you want * double click on any preview mode tab to convert it to normal tab
### what does it address * currently rapidly previewing files in a directory/project to get a refresher/overview * causes too many persistent editor tabs to stay * which: * hog the system * get mingled with the files you are actually working on * require manual closing and additional precaution to avoid closing the intentional editor tabs
inspiration took as it is from: vscodium
read only mode (with some indication - say, the name in the tab bar in italics)
Already uses colour, try `Document->Read Only`
"Somebody" could add the functionality to the filebrowser plugin to open or focus its "Preview" tab and show the file in it when selected.
"Somebody" could add the functionality to the filebrowser plugin to open or focus its "Preview" tab and show the file in it when selected.
any idea on how much effort would that be?
What kind of answer do you expect? An amount of hours? Relative to another feature? It highly depends on how it will be implemented and also how experienced the person implementing it is.
I saw this feature in VSCode at colleagues and it made me cry mentally. At least if not implemented properly or not used properly, it can create a very bad user experience. So, if implemented at all, it should be in the FileBrowser plugin and it should be configurable with a default to off.
What kind of answer do you expect? An amount of hours? Relative to another feature?
effort might not have been a correct word - sorry - i meant to ask for difficulty
so, some measure of difficulty - in implementation and the nature of it - ofcourse, it's all relative, but still, some idea on if it will be more mechanical - or like would involve more diving into (relatively) large number of corners and stuff...
I saw this feature in VSCode at colleagues and it made me cry mentally.
Awwww, there there ;-)
At least if not implemented properly or not used properly, it can create a very bad user experience.
In vscode its not really opened in read only, the cursor can be moved to the tab and changes made. It was ages before I even noticed the preview, as I always only opened things I wanted to change, and the change exited preview mode. And single click and then enter focuses the tab and exits preview mode, or double click focuses the tab and opens non-preview same as filebrowser.
It might be a useful function for finding something in a codebase that the user doesn't know, but "find in files" or "go to declaration/definition" tend to be better navigation tools than the mk1 eyeball.
@yashpalgoyal1304
so, some measure of difficulty - in implementation and the nature of it - ofcourse, it's all relative, but still, some idea on if it will be more mechanical - or like would involve more diving into (relatively) large number of corners and stuff...
Given it changes the behaviour of tabs (change the document in an existing tab isn't available now AFAIK) I would guess its gonna need significant work in Geany itself, not just the plugin, but who knows, "somebody" would have to investigate and only "somebody" who wants the feature is likely to do that (probably leaves out @eht16 ;-). Simulating it by closing a tab and opening a new tab might be possible from the plugin itself, but also may generate visual artefacts, "somebody" would have to test it.
Closed #3327 as completed.
Closed #3327 as not planned.
github-comments@lists.geany.org