> + gboolean val = *(gboolean *)optentry->arg_data;
> + gboolean reverse = (optentry->flags & G_OPTION_FLAG_REVERSE);
> + if ((val && !reverse) || (!val && reverse)) /* logical XOR */
> + s = g_strdup_printf("--%s", optentry->long_name);
> + }
> + break;
> +
> + case G_OPTION_ARG_INT:
> + if (*(gint *)optentry->arg_data)
> + s = g_strdup_printf("--%s=%d", optentry->long_name, *(gint *)optentry->arg_data);
> + break;
> +
> + case G_OPTION_ARG_STRING:
> + case G_OPTION_ARG_FILENAME:
> + if (*(gchar **)optentry->arg_data)
> + s = g_strdup_printf("--%s=%s", optentry->long_name, *(gchar **)optentry->arg_data);
Actually, we have no STRING, so I'll discard it (the original SM option reproducer by Eugene supported even string and filename arrays, but I removed them at some point as unneeded).
As of the FILENAME, GLib says "returned in the GLib filename encoding", which is native for POSIX and UTF-8 under Windows. So a conversion is probably needed under Windows (that didn't matter for SM, which is *nix only). I'll test it to be sure.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/637/files#r38775687
> @b4n @elextr @codebrainz sorry to annoy you but I really really want this for 1.26 so give it a look pretty please
I'm busy this WE, but I should be on it starting next Monday. Feel free to ping me continuously if I don't ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/629#issuecomment-137754782
Who opened a large json file of 42 megabytes, it opened very quickly.
Thank you very much!
I do not know what you've done, but it was working really fast!
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/577#issuecomment-137666946
While I concur that this should be handled through the theme, for sake of consistency alone, I think it is simple to change the active tab since this is also just a gtk widget or? I remember that I have done so myself in my ruby-gnome apps, being able to change in particular the colours. Perhaps it is not worth to invest time into it, but I think in principle this should be fairly simple to do - one could have an "advanced options widget" for these kind of preferences in the long run.
PS: The old bluefish 1.x editor does some slight intensification of the currently selected tab; it appears a bit as if it would have a shadow. Perhaps bolding the text and colouring the background e. g. with a colour, could be done in such an advanced user preferences setting, while also notifying the user that the theme should do so.
PSS: It would be nice if a screenshot could be added to show how this is done via a theme properly, in the screenshot gallery. Thanks! \o/
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/635#issuecomment-137629763
> @@ -52,6 +52,17 @@ CommandLineOptions;
> extern CommandLineOptions cl_options;
>
>
> +/* Information about command line entries that can not be stored in GOptionEntry. */
> +typedef struct
> +{
> + gboolean persistent; /* The option should be passed to "New Window" */
> +}
> +GeanyOptionEntryAux;
> +
> +extern GOptionEntry optentries[];
> +extern GeanyOptionEntryAux optentries_aux[];
We could add a function in libmain.c which could be called at argv parsing time and save a GPtrArray containing the `argv` to be forwarded into the already global `GeanyApp` structure. It would have the advantage of keeping all of the `argv`/GOption parsing code in the same file/place too.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/637/files#r38709998
> I like the fact that it uses the `spawn_*()` API now, instead of `g_find_program_in_path()` + `utils_spawn_*()` (change 1), and agree with the changes from @b4n's PR that it incorporates getting the installed/resource binary path (change 2, without using his commit+attribution), but the stuff with the options lookup table, and new globals, functions, and data types (change 3..N) seems like a lot of complexity (though it may indeed be warranted), and the part that guards out the `is_osx_bundle()` seems unrelated (change N+1).
Agreed.
Anyway, I don't have a strong opinion on this whole new window discussion, any solution that give a reasonably consistent user experience is fine with me. This particular PR seem to properly restore all meaningful arguments so the new instance behaves as closely as the original one as possible, so that's nice.
Also, the result seem to make sense -- though I have yet to test it.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/637#issuecomment-137446323
> @@ -52,6 +52,17 @@ CommandLineOptions;
> extern CommandLineOptions cl_options;
>
>
> +/* Information about command line entries that can not be stored in GOptionEntry. */
> +typedef struct
> +{
> + gboolean persistent; /* The option should be passed to "New Window" */
> +}
> +GeanyOptionEntryAux;
> +
> +extern GOptionEntry optentries[];
> +extern GeanyOptionEntryAux optentries_aux[];
I'm not very fond of exposing those outside of main, maybe it'd be nice to find a clean way to encapsulate access to those… any idea?
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/637/files#r38644632