One thing that drives me crazy is how when I have files associated with Geany, if I double click on them to open them, it will open the file in another Geany instance on *another* desktop instead of on the *current* desktop. This was one thing I took for granted when I was using gedit.
I have searched and found someone that suggested somehow using a unix socket file that is named based on the current desktop number, but I have not been successful in doing so. In fact, their solution seemed to lead to some loop that would keep spawning new Geany processes, bringing the OS to a near halt.
Can something like this be *baked in* to Geany so that no special setup or configuration is necessary? If there is a good reason not to, is there an official solution to this somewhere (that works)?
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1025
Teach your association to run `geany -i` to run a new instance, just beware they all share config and session, so last closed wins.
Geany doesn't know about desktops, thats something thats specific to your DE, but it should have a way of making associated programs run in specific desktops.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1025#issuecomment-217036175
That will open a new instance for *every* file though. I still want to group together all files in a single instance opened in a particular desktop.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1025#issuecomment-217038146
You can have separate instances and group files in them by giving each its own config, so `geany -c a_config_for_this_group a_file` and all files opened specifying the same config will open in the same instance.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1025#issuecomment-217042901
On 2016-05-04 04:29 PM, Brian White wrote:
That will open a new instance for *every* file though. I still want to group together all files in a single instance opened in a particular desktop.
Some window managers support more window placement options. In KDE you right-click the titlebar and go to "More Actions->Special Window Settings" and it will let you match windows and control how and where they're placed. I'm assuming other window managers have similar features, except maybe GNOME's WM since it offloads window management into each individual application now and isn't exactly known for allowing users to configure anything.
Cheers, Matthew Brush
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1025#issuecomment-217048888
Maybe the --socket-file option can help, as documenten on [geany.org](https://www.geany.org/manual/current/#command-line-options)
this solution will help https://unix.stackexchange.com/questions/246827/geany-open-a-new-instance-pe...
Although the above solution url works, **but it will be really great if this solution is "inbuilt" into geany itself as a setting option**
@zaxebo1 feel free to __make a pull request that provides this__.
Note that current versions of Geany create the socket file name in /tmp as a tempfile of the form `geany_socket.XXXXXX`. The file of the form `geany_socket_host_display` (with host and display having characters that filenames might not like removed) is created in the Geany config directory and is a link to the /tmp dir. You could make an option to include the desktop name in that linkname.
@zaxebo1, thanks for the link! I've modified it to this: ```bash #!/bin/sh
socket=`xprop -root _NET_CURRENT_DESKTOP` socket=${socket##* }
if [ "$socket" ] then if [ "$DISPLAY" ] then socket="${DISPLAY%.*}-$socket" socket=${socket#*:} else socket="NODISPLAY-$socket" fi exec /usr/bin/geany --socket-file "/tmp/geany_socket_$socket" "$@" else exec /usr/bin/geany "$@" fi ```
Then I've saved it as `~/.local/bin/geany`, made it executable and added `~/.local/bin` to PATH.
SInce in Ubuntu `geany.desktop` uses simply `geany` instead of full path, all file types associations now use this new script as well as direct execution from menu. Works wonderfully, finally proper replacement for slow gedit.
IMHO, this should be the default behavior.
Closing since the original issue can be solved using the provided workaround. Pull requests are welcome to improve this aspect of Geany.
Closed #1025.
Well, workaround is not a fix. I would rather like to see a checkbox in app setting for choosing desired behavior.
@nazar-pc the script only works for Geany running on X, but even then nobody has contributed the code to perform the actions of the script in code. But Geany also runs on Wayland and Windows and OS-X, so any X only solution must be appropriately disabled in those cases.
Pull requests are welcome.
I've been using the excellent script by @nazar-pc for two years, but my upgrade has stopped it working. Now it's back to throwing everything in as tabs in the first-opened version of geany, whichever desktop that's on.
I'm now on Fedora 31 Gnome 3.34.5 geany 1.36
Thanks if you can help!
I gather nobody is likely to look at this comment in a closed report so I've opened a new report, see above.
@ElizBaldwin check what .desktop file looks like, maybe they have stopped just using `geany` and switched to full path.
@nazar-pc thanks but I gave your script a different name and invoke it directly via that name, calling it geany never worked for me anyway. So it's definitely your script that's no longer working.
@ElizBaldwin your fedora 31 isn't running wayland and not X11 is it?
Reopened #1025.
@elextr I believe it uses Wayland by default unless you're using the NVidia blob driver. I believe it's selectable from the login manager though.
@elextr I'm on Xorg. Yes, Wayland is default, but I found it v unstable when it was first default and moved back to Xorg, and I've just left the setting there. Might the fix work in Wayland? I'll try that when I next reboot.
@ElizBaldwin Actually the opposite, if using wayland then the X11 xprops is probably wrong (IIUC I'm no wayland expert) and it almost certainly won't work.
Thanks.
I should maybe apologise, though - the fix is working for me today. But it definitely wasn't yesterday, I spent some time with it. How odd.
Closed #1025.
Maybe Geany developers can change their mind about this behavior and finally implement it natively? People are using hacky workarounds for years now just to achieve basic functionality other editors have, there is clearly a demand for this.
@nazar-pc pull requests are welcome, which desktop technology will you be doing it for?
X11 which is dying? Wayland (nobody has posted a solution yet)? Windows? OSX? And on X11/Wayland will that be for KDE, Gnome, Lxqt, i3, sway etc?
You will need to do it for each native technology separately because the GTK library does not support multiple desktops AFAICT (happy to be corrected).
Finally to repeat something I have said until I'm blue in the face, all "Geany devs" are volunteers who work on whatever they are interested in, not corporate employees who can be assigned tasks. So if you want something either you need to do it yourself, or if you are don't know how then to interest somebody who does.
I'm using X11, but the issue is clearly not specific to it, and thankfully workaround exists. I certainly understand how Open Source works and appreciate all the work developers of Geany have done, but I'm wondering why this feature request is closed with "workaround exists" label instead of being left open for someone to pick up. At least limited platform support would already be useful I think.
Reopened #1025.
but I'm wondering why this feature request is closed with "workaround exists" label instead of being left open for someone to pick up
Nothing nefarious, just to trying to cleanup old bugs. I assumed if someone wanted to pick this up, they'd reference it in their PR.
My interpretation is that the issue had been closed originally because there was a workaround, was re-opened when the workaround seemed to have failed, but was re-closed when that now seems to be a mistake. Anyhow I don't think somebody providing solutions to desktops is really going to be dependent on this issue, just somebody has gotta do it.
Sorry for the grumpy, just that many projects these days are corporate supported (which is a good thing) and many posters seem to expect the same level of support and response from volunteer projects. Volunteer projects can sometimes be as responsive as a herd of cats, and with as much hissing and growling :)
github-comments@lists.geany.org