You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
#2949 means you can avoid this if you don't want it smile
Haha... yes...
IIRC all Geany popups are marked modal, so they should take focus, but it is up to the window manager/wayland compositor to grant that. Seems to work here with Cinnamon.
It's probably focus stealing prevention... But I prefer no popups in the first place.
Ok, but project load does cause a signal that plugins might use, do the project plugins do rescans or other stuff when that happens.
Since the project is already open, I'd expect that plugins would have done what they needed the first time the project was opened. I used grep to look for plugins that handle the project-close and project-open signals.
geanylua and geanypy – pass the signals on to scripts.
projectorganizer – close/open/update project, update sidebar. I don't see anything that looks like updating indices in response to open/close signals, but those could be hiding in function calls I didn't follow (I only looked at only 2-3 levels across two files). I've been using this plugin and PR together with no ill effects.
scope – Functions that call functions that call functions that look like they eventually update the menu. Since it's the same project, I would guess the menu state would end up in the same place.
geanyctags – Changes widget sensitivity. Would not be affected by this PR because it's clearly supposed to end up in the same state.
treebrowser – Updates the path. There are also buttons and context menu items that can be used to update the path to achieve similar effect.
When a project is opened from the menu, no warning is generated.
Oh, Ok, well no need to add one then, coulda sworn it did, but maybe its been removed, maybe github search knows ... ahh, it used to for a "recent project" open, but that was removed in f40569d.
My main concern was opening from the file manager, since that's how I've been opening projects. Maybe already-open projects can continue to be re-opened from the menu because "Unlikely to be done accidentally." ?
Or the behavior of this PR could be put behind an option, like files.reload_project_open_same ?
... only getting confused for smarties with multiple paths to the same file, but in that case its no different to the current situation, so no need for real_path.
I missed the symlink issue. I've changed it to use the real path.
Do you get an absolute path from the socket buffer then?
I think so because the filenames are able to match, preventing the project from opening.
BTW I am not saying this PR is a bad idea, just want to be sure the implementation has no negative side effects.
My interpretation is that your intention is to improve the PR... Or if it's really misguided, help me figure it out...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.