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.

Sign up for GitHub

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

Jump to bottom

no re-rendering of a visited document when tab-browsing #27

Open
ralf3u opened this issue Dec 1, 2021 · 2 comments
Open

no re-rendering of a visited document when tab-browsing #27

ralf3u opened this issue Dec 1, 2021 · 2 comments
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@ralf3u
Copy link

ralf3u commented Dec 1, 2021 •
edited
Loading

Actual behavior
When tab-browsing with shortcuts or with the mouse, for example on a html-document, which already has been visited in the Geany session, and with an image on top of the webpage, then I can see a re-rendering in the preview (see the code down below), although there was no change. I can see the webpage re-rendering, because for a part second the text is there where the picture is located.

Expectation
When tab-browsing with shortcuts or with the mouse from one document to another document, the preview should do some kind of hide the preview or keep the preview in memory. So, when the user is tab-browsing back in the editor to the document, the preview should appear right away, so without re-rendering.

Sidebar
The issue appears also when tab-browsing in the sidebar.

Remark
I think this would be a cool a feature. The content of the preview would appear then in light speed.

Test
This is the test-document (a picture named 1.jpg need to be added in the same level of the html-document):

<!DOCTYPE html>
<head>
<title>test</title>
</head>
<body>
<br><br><br><br><br>
<img src="1.jpg" style="width:300px">
<br><br><br><br><br>
<div>1agsjdghjhsgjhgaskdgkagdaksdgaksdgh</div>
<div>agsjdghjhsgjhgaskdgkag2daksdgaksdgh</div>
<div>agsjdghjhsgjhgaskdgkagd4aksdgaksdgh</div>
<div>agsjdghjhsgjhgaskdgkagda5ksdgaksdgh</div>
<div>agsjdghjhsgjhgaskdgkagdaksd6gaksdgh</div>
<div>agsjdghjhsgjhgaskdgka3gdaksdgaksdgh</div>
<body>
<html>

The settings in preview.conf are:
snippet_html=false
extra_css=extra-media.css
@xiota
Copy link
Owner

xiota commented Dec 2, 2021 •
edited
Loading

The update is b/c the document could have changed while the preview was hidden. Rather than do a lot of bookkeeping to track changes, it's easier to just update. There are also lots of times when the preview needs to be updated that are hard to detect, and it's worse to not update when needed than to update when not needed.

The preview uses the same webview for everything. So cannot keep the render in memory. Even if it could cache, the renders would frequently be out of date when documents are edited.

This is probably a wontfix unless I just happen across a more efficient way to handle it while reorganizing code.

@ralf3u
Copy link
Author

ralf3u commented Dec 2, 2021 •
edited
Loading

The update is b/c the document could have changed while the preview was hidden.

Yes, but then a bar automatically appears on top of the editor, when the tab is again in focus. So, there is no need to check if the document was changed while the preview was hidden. This is the test:

  • open Geany and open a document, let's say an html-document
  • open an other document, a txt-document (result: the txt-document in Geany is now in focus)
  • open the same html-document in an other editor, like FeatherPad, change the code and save the document
  • in Geany: tab-browse back to the html-document (result: a bar appears on top of the editor)

Rather than do a lot of bookkeeping to track changes, it's easier to just update.

The test shows that a bookkeeping to track changes is not necessary.

There are also lots of times when the preview needs to be updated that are hard to detect, ...

I don't know what that means. Is there an example?

@ralf3u ralf3u mentioned this issue Dec 2, 2021
Closed
@xiota xiota added wontfix This will not be worked on enhancement New feature or request labels Feb 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xiota @ralf3u