Re: [Github-comments] [geany/geany-plugins] Tree browser font (#424)
Is this possible in the Windows (10) installation of Geany? If so, which program do I run, or which configuration file do I edit (and where in that config file)? Also, for me at least, the "Documents" sidebar font and main menu font ... again, on Windows 10 (do I need to file a separate bug?)? -- 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-plugins/issues/424#issuecomment-247911578
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); @b4n yeah, though it would probably be nicer to actually add a new signal for that (ex. `settings-scope-changed`) than using the close signal by proxy. Whichever you guys prefer, I'm rather indifferent. I poked around in Geany and Geany-Plugins and didn't see any problems with either approach. -- 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/pull/1223
[Github-comments] [geany/geany] Add patch for self-compiled grep to fix recursive searching (#1237)
When using --recursive on Windows, grep shows warnings like "recursive directory loop" due to failing inode checks. Since the Mingw runtime doesn't support inodes, the patch will disable inode checking in grep and so grep can work properly on Windows. Patch is taken from http://mingw-users.1079350.n2.nabble.com/Building-GREP-td7582694.html. Closes #1229. The patch file is currently still located at http://download.geany.org/snapshots/grep-2.25-win64_sameinode.patch. I will move the file to the correct location once this PR is going to be merged. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1237 -- Commit Summary -- * Add patch for self-compiled grep to fix recursive searching -- File Changes -- M scripts/gtk-bundle-from-msys2.sh (12) -- Patch Links -- https://github.com/geany/geany/pull/1237.patch https://github.com/geany/geany/pull/1237.diff -- 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/pull/1237
Re: [Github-comments] [geany/geany] Proxy Plugins Filename Pattern Matching (#1236)
@codebrainz pushed 1 commit. 526b9a4 Update proxy plugins documentation -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/geany/geany/pull/1236/files/29d987bb43e338d323d00a61c429e8debf21f053..526b9a455d87625174ed8a89ea2c8de24cdc40a1
Re: [Github-comments] [geany/geany] Proxy suffixes (#1236)
The first two commits should be squished together. -- 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/pull/1236#issuecomment-247850890
[Github-comments] [geany/geany] Proxy suffixes (#1236)
As a result of discussions in #1233 comments. Overview: - Allows proxy plugins to register to pre-match "glob-style" patterns for subplugins. - Allows passing `NULL` to register to probe all potential subplugin files (ie. pattern `*`). You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1236 -- Commit Summary -- * Change proxy plugins to match by filename suffix * Change from suffix to Glob-style pattern matching * Allow proxies to pass `NULL` for the `patterns` parameter -- File Changes -- M src/plugindata.h (4) M src/plugins.c (101) -- Patch Links -- https://github.com/geany/geany/pull/1236.patch https://github.com/geany/geany/pull/1236.diff -- 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/pull/1236
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
:bike: :house: :) -- 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/pull/1233#issuecomment-247847930
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
> It would probably work for "foo.pypy" but if there is no dot at all it would > crash. Sounds like it would be easy to fix. -- 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/pull/1233#issuecomment-247847943
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
fwiw, peasy's probe() expects to get a filename with a dot in it. It would probably work for "foo.pypy" but if there is no dot at all it would crash. -- 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/pull/1233#issuecomment-247847861
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
> Guess it saves every proxy probing every file in the single plugins dir. I wonder if that would be a problem in practice though? Most likely it will be < 50 files and likely no more than a few hundred at the upper limit. -- 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/pull/1233#issuecomment-247847842
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
Guess it saves every proxy probing every file in the single plugins dir. -- 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/pull/1233#issuecomment-247847796
Re: [Github-comments] [geany/geany] Geany 1.28 "Find in files" doesn't work in Windows 7 64bit OS (#1229)
I just noticed my previous tests were wrong: the warnings are not just warnings, actually grep doesn't find matches in sub directories without the patch. With the patch, the warnings are gone and matches will be found properly. So, we probably should apply it. -- 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/1229#issuecomment-247847635
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
Actually what's the point of pre-matching by file extension/suffix at all? Why can't the proxy plugin's `probe()` functions do this alone? We could add a `utils_has_filename_suffix()` if all the want to do is suffix-matching. -- 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/pull/1233#issuecomment-247847617
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
Also proxy plugins matching blindly against extensions, without checking the file contents, are basically broken already, since all the plugins are only allowed in a single directory and the likelihood of extension clashes is great. -- 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/pull/1233#issuecomment-247847197
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
Yeah, it will match `fatso` as well as `fat.so`, but it doesn't change the C API, and only does a minor tweak to the semantics. Also it will only affect an estimated 2 actual proxy plugins known to exist :) But an API version bump is no problem (and accounted for in the comments, but forgotten in the `plugindata.h` file). -- 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/pull/1233#issuecomment-247847050
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
well, as you pointed yourself in the comment, if the plugin doesn't update the suffixes to include the dot, it'll match additional things. -- 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/pull/1233#issuecomment-247846909
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
@b4n not really, but it would be worth an API bump to allow proxy plugins to detect the change if they want. -- 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/pull/1233#issuecomment-247846734
Re: [Github-comments] [geany/geany] Geany 1.28 "Find in files" doesn't work in Windows 7 64bit OS (#1229)
Running the same grep binary from the command line produces the same warnings. After reading http://mingw-users.1079350.n2.nabble.com/Building-GREP-td7582694.html and http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16444 it seems to be a grep issue which is unlikely to be fixed (according to #16444). We could apply http://download.geany.org/snapshots/grep-2.25-win64_sameinode.patch which eliminates the warnings. This patch is from the first link. For testing, I just build grep-2.25 with the mentioned patch, the binary is at http://download.geany.org/snapshots/grep-2.25_sameinode_patch.exe (rename to grep.exe and copy it into bin/ in your Geany installation directory). @ All: do we want to patch our self-compiled grep binary? The warnings are just warnings, i.e. grep still finds the desired results. Still the warnings can be quite annoying. -- 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/1229#issuecomment-247846709
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
@codebrainz yeah. That one would break API, though :) -- 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/pull/1233#issuecomment-247846630
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
@b4n, its ok, I read your hack wrong, its user configs only :) -- 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/1150#issuecomment-247846595
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
(https://github.com/geany/geany/blob/8e27b271181fd302239af64159275fd8433deea2/src/libmain.c#L578) -- 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/1150#issuecomment-247846584
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
@elextr if the user specified `-c`, I don't think it's a good idea to change it because they gave a bad one. -- 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/1150#issuecomment-247846558
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
@b4n, and what about `-c` specified configs? -- 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/1150#issuecomment-247846510
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
Possible "fix": 8e27b271181fd302239af64159275fd8433deea2. But I guess it has many flaws, too. And it's really not trivial to "properly" "fix" this: if you only take root into account, it'll still fail the same when becoming another user than root (lest common, but totally valid). If you try and play with `SUDO_UID`, it'll only work for sudo. If… etc. -- 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/1150#issuecomment-247846289
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
The alternative more flexible approach mentioned in the previous comment would look something like this (untested, except for compiling): https://github.com/codebrainz/geany/commit/267a1651b9e405674bf762e59a4a1039ab9e72ee -- 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/pull/1233#issuecomment-247845612
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
Hum, just reading the documentation of [`g_get_home_dir()`](https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir), it suggests it might have worked like you want in GLib before 2.36. -- 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/1150#issuecomment-247845097
Re: [Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)
> As a result, a fair amount of bash scripts as well as habit, in fact *relies > on the "improperly" configured sudo. Is there? I don't see this myself, and can't really imagine why it would be a problem. The only thing that change is the environment, and the large majority of scripts don't pass much *data* though the environment. And even if they did, all it takes is putting `sudo` at the start of the line instead of the command, `sudo FOO=bar script` instead of `FOO=bar sudo script` -- ok, that means user changing habits, and that's hard. And apparently Debian changed `sudo`'s default without too much issues, or at least I didn't hear about them, so it sounds very possible. > There is a ton of stuff in Linux (and BSD and Windows) where "improper" > eventually became "standard", and tools & apps that consume their services > either have to assume "improper" function, or at least be able not fail in > the face of it. Like I said before, I've never seen a base of code yet, that > consumes lower-level services as a significant portion of it's function, that > doesn't have a significant if not majority share of code devoted to working > around flaws. Nirvana would be stuff that works as expected. _Whether or not > stuff below it works as expected._ > > I could be wrong and it's just an opinion, but it feels like your response is > one of dogmatic ideology, and does nothing to address the world as it is. > That's just my reading. I know that's an attractive stance in the open-source > world. (And to be fair, there is an important place at the table for > hyper-rigid idealistic purity - but it can't be the only voice. We need the > inflexible purists hashing things out with the end users. When those two > don't talk, things get bad.) Well, you're kind of right. I'm reluctant to make a change I don't feel good about in Geany for something I don't think is a Geany problem. If we "fix" Geany, there will be `N-1` applications that suffers from the issue. If `sudo` is "fixed", there will be `0`. If the platform layer we use is "fixed", there will be `N - apps_using_glib` (where `apps_using_glib` is guaranteed to be `>= 1`). I get that you have the problem with Geany because you use Geany, but if GLib "fixes" it, Geany will be "fixed" as long with a long list of other apps. Plus a long list of apps will show a consistent behavior, instead of each using its own version of the hack with its own pros and cons. And yeah, I'm really sad writing apps requires fixing bugs in the platform, so I generally try and fix the platform layer when I can. So… yeah we *could* make a change to get you and few other users happy. I *do* like happy users. But I'm also reluctant to participate to the hack party without trying to improve the situation. > To answer your question, yes I do have dotfiles owned by root. Most people do > if they use dbus or gvfs. I also have a couple of paths put there by > installers, apparently incorrectly. ...But...I've broken things before by > assuming nothing but me should have ownership in my own directory ;-). > Nothing geany-related anyway. Why do you ask? I don't, and I do use apps using DBUS and GVFS. And I ask because actually, if you do have files not owned by your user in your dotfiles, there's a lot more problems than just Geany. If a file is owned by root, your user won't be able to touch it, resulting generally in not being able to save settings, state, history, etc., or worse fail to start because realizing something's fishy is going on. I know several years ago I had that problem with the `nano` editor: it would not be able to write its history file after having been used by `root`, and would complain at each startup -- and using such a basic editor as `root` is a lot more common. I don't know if they did something in `nano` itself or it just got fixed when Debian started to `env_reset` by default though. Anyway, my points is that: 1. every application writing user config/state files suffers from this "bug" unless they have specific handling for it. There however *are* many ways to avoid this without changing applications, addressing the root cause of the problem, and most have been suggested here: * `env_reset` in `sudo` configuration (pick this one!!) * `sudo -H` instead of `sudo` * `su -` instead of `su` * Otherwise making sure to update environment variables like `HOME`, `XDG_CONFIG_HOME`, `XDG_DATA_HOME`, etc. 2. If really `root` user should be sepcial-cased, it should be done lower in the stack, like in the [XDG specification](https://standards.freedesktop.org/basedir-spec/latest/index.html), and then its implementations (like [`g_get_user_config_dir()`](https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-get-user-config-dir) and friends), so it's "fixed" for many people, and not just one application at a time. And it should still be possible to override it if a
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
> meaning that if we strip it implicitly it becomes part of the API so has to > be kept "forever" Then we could make it more flexible (as you eluded to) and just do simple suffix-matching. This would support less-common file names/extensions like `myplugin.tar.gz` or `myplugin.GeanyPy.py` or whatever. It wouldn't be a huge change and can probably be done in a backwards-compatible manner. -- 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/pull/1233#issuecomment-247842046
Re: [Github-comments] [geany/geany] Do not strip dots from proxy plugin extensions (#1233)
> I'm still curious what future use of the dot was being referenced though, I > don't think I understood that possibility, and might have a different opinion > if I did. As said this was a purely theoretical remark, meaning that if we strip it implicitly it becomes part of the API so has to be kept "forever". I have no plan nor ideas why giving the leading not a special meaning would be a good idea. -- 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/pull/1233#issuecomment-247841652
Re: [Github-comments] [geany/geany] Error in "Document/Set Lineend/Set to xx and convert" (#1218)
I just tested it on Windows with a freshly built Geany from master and it works as expected. Then I used the last nightly build and it failed as described. So, it is indeed an issue with the nightly builds. For whatever reasons. @Heihon if you want to test and confirm my assumption, I created test installers from current GIT master: http://download.geany.org/snapshots/geany-1.29nightly20160918_setup.exe http://download.geany.org/snapshots/geany-plugins-1.29nightly20160918_setup.exe These include also updated translation files. Btw, with the cross-compiled nightly builds I get also warnings like ` Error loading theme icon 'geany-build' for stock: Unrecognized image file format`. So I assume this is really some sort of binary incompability, probably between the Geany binaries and GTK/Glib. As said, at some point I'll change the way the nightly builds will be created and then they should get more usable again. -- 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/1218#issuecomment-247840796
Re: [Github-comments] [geany/geany] Error in "Document/Set Lineend/Set to xx and convert" (#1218)
> It would be cool if the nightly builds could produce the full win32 installer > package. Yes, this is the way to go. Technically it should be possible (makensis is available for Linux). It just requires me to do it :). Will do probably but it might take some weeks until I find time for it. -- 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/1218#issuecomment-247840119
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); See #1235 -- 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/pull/1223
[Github-comments] [geany/geany] Emit project-close before destroying project (#1235)
Supersedes #1223 You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/1235 -- Commit Summary -- * Emit project-close before destroying project -- File Changes -- M doc/pluginsignals.c (5) M src/plugindata.h (2) M src/project.c (4) -- Patch Links -- https://github.com/geany/geany/pull/1235.patch https://github.com/geany/geany/pull/1235.diff -- 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/pull/1235
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); Maybe a `@note` about the change in the signal documentation would suffice. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); I don't know why they would depend on that, but I can't be sure they don't, it would be pure speculation. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
b4n commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); Oops, I meant *after*. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); I do, it's the whole point of this PR :) -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
b4n commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); > I wonder if we could just change project-close instead Good point, I indeed can't see why someone would need the signal to be emitted *before* the data is freed. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add utils_get_real_path() and use it (#1224)
codebrainz commented on this pull request. > @@ -42,7 +42,11 @@ TMSourceFile *tm_source_file_new(const char *file_name, > const char *name); void tm_source_file_free(TMSourceFile *source_file); -gchar *tm_get_real_path(const gchar *file_name); +gchar *tm_get_real_path(const gchar *file_name) +#ifndef GEANY_PRIVATE +G_DEPRECATED_FOR(utils_get_real_path) +#endif It seems wrong, which is why I did it like this, but if you'd prefer to have TM also depend on Geany, I can change it to be so. -- 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/pull/1224
Re: [Github-comments] [geany/geany] Add utils_get_real_path() and use it (#1224)
b4n commented on this pull request. > @@ -42,7 +42,11 @@ TMSourceFile *tm_source_file_new(const char *file_name, > const char *name); void tm_source_file_free(TMSourceFile *source_file); -gchar *tm_get_real_path(const gchar *file_name); +gchar *tm_get_real_path(const gchar *file_name) +#ifndef GEANY_PRIVATE +G_DEPRECATED_FOR(utils_get_real_path) +#endif Yeah; now it's under *src/* it might not be so bad -- 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/pull/1224
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); To do that would only require moving [the signal emission](https://github.com/geany/geany/blob/1.28.0/src/project.c#L467) to the top of the same function. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
kugel- commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); Can't imagine someone truly depends on geany_data->app->project being already NULL. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); That would be fine with me. I mostly just didn't want to mess with the existing signal in case some plugins somehow depended on the existing behaviour. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
kugel- commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); I wonder if we could just change project-close instead -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); No, it's not, I just access the global variable `geany_data->app->project`, but it's destroyed and set to `NULL` before the normal `project-close` signal is emitted, so I can't emit the `close` signal on the project 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
kugel- commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); So is this the same problem you solved elsewhere with qdata? Why go a different path here? -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
codebrainz commented on this pull request. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); It would be better, but as you pointed out, I did it like this for consistency with the other signals. My actual use case is to be able to treat the project as a real instance of which there could (in theory) be many, which is why I need to know before it's destroyed. But since none of the other signals give the instance, it'd be weird to just have one that does. -- 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/pull/1223
Re: [Github-comments] [geany/geany] Add utils_get_real_path() and use it (#1224)
codebrainz commented on this pull request. > @@ -42,7 +42,11 @@ TMSourceFile *tm_source_file_new(const char *file_name, > const char *name); void tm_source_file_free(TMSourceFile *source_file); -gchar *tm_get_real_path(const gchar *file_name); +gchar *tm_get_real_path(const gchar *file_name) +#ifndef GEANY_PRIVATE +G_DEPRECATED_FOR(utils_get_real_path) +#endif You mean a reverse dependency of TagManager on Geany? -- 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/pull/1224
Re: [Github-comments] [geany/geany] Add "project-before-close" signal to API (#1223)
b4n commented on this pull request. Mostly LGBI > @@ -47,6 +47,7 @@ typedef enum GCB_PROJECT_OPEN, GCB_PROJECT_SAVE, GCB_PROJECT_CLOSE, + GDB_PROJECT_BEFORE_CLOSE, Yeah, and this enum isn't in the API either. > @@ -156,6 +156,12 @@ static void create_signals(GObjectClass *g_object_class) G_SIGNAL_RUN_FIRST, 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); + geany_object_signals[GDB_PROJECT_BEFORE_CLOSE] = g_signal_new ( + "project-before-close", + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + 0, NULL, NULL, g_cclosure_marshal_VOID__VOID, + G_TYPE_NONE, 0); Wouldn't it be better if the signal received the `GeanyProject` as argument? OK, it'd be inconsistent with the other project signals, so maybe it's a bad idea. Or maybe it's a good idea to break one less thing in the future if we want to allow more than one project to be open? That might not make much sense because the other signals would have to be changed anyway, so meh. -- 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/pull/1223#pullrequestreview-469872
Re: [Github-comments] [geany/geany] Add utils_get_real_path() and use it (#1224)
b4n commented on this pull request. Otherwise, LGTM > @@ -42,7 +42,11 @@ TMSourceFile *tm_source_file_new(const char *file_name, > const char *name); void tm_source_file_free(TMSourceFile *source_file); -gchar *tm_get_real_path(const gchar *file_name); +gchar *tm_get_real_path(const gchar *file_name) +#ifndef GEANY_PRIVATE +G_DEPRECATED_FOR(utils_get_real_path) +#endif Meh, can't we move the implementation at the non-deprecated place and use it in the deprecated one, instead of this? -- 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/pull/1224#pullrequestreview-469697
Re: [Github-comments] [geany/geany] More info about file. (#1196)
Closed #1196. -- 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/1196#event-793248633
Re: [Github-comments] [geany/geany] More info about file. (#1196)
Thank you for response. I just noticed, I can select all content of file, with CTRL+A, and look on "sel" value in statusbar, it's equivalent of my need. -- 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/1196#issuecomment-247830160
