After calling
```
ui_progress_bar_start("foo");
...
ui_progress_bar_stop();
```
which should theoretically completely stop the progress bar, I get elevated CPU usage of the whole Geany process ~1% CPU on idle (and around 4% on macOS) compared to 0% after Geany launch before the status bar progress bar is used (e.g. by compiling). GTK seems to keep the widget connected to "tick callback" which causes the higher CPU (in fact, there's no gtk_progress_bar_stop() so it can't do it).
The workaround to fix this problem is to call
```
gtk_progress_bar_set_fraction()
```
which switches the progress bar to the mode where it shows the user-provided progress and this removes the "tick callback".
Am I crazy or can others reproduce this too? It was quite a bug hunt - first I suspected the LSP plugin (clangd indexes files on start which creates the progress bar which made it confusing), then jsonrpc-glib, then the blinking caret or Scintilla notifications, then Geany, and finally I got to GTK (3.24.38 to be precise).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3902
-- Commit Summary --
* Fix elevated CPU usage after ui_progress_bar_start/stop() is used
-- File Changes --
M src/printing.c (2)
M src/ui_utils.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/3902.patchhttps://github.com/geany/geany/pull/3902.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3902
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3902(a)github.com>
This is one more attempt on unifying `TMTag`s and externally provided symbols for the symbol tree before giving up and making the plugins create the symbol tree by themselves (which leads to quite a significant code duplication). This time (unlike the previous attempts) I'm quite happy with the result though. I called the new structure `GeanySymbol` - could be renamed to something else if someone has better idea.
The idea is to make `GeanySymbol` operate in two modes:
- either it is backed by a `TMTag` and created using `GeanySymbol *geany_symbol_new_from_tag(TMTag *tag)`
- or it is created by some external source such as the LSP plugin using
```C
GeanySymbol *geany_symbol_new(gchar *name, gchar *detail, gchar *scope, gchar *file,
TMParserType lang, glong kind, gulong line, gulong pos, guint icon)
```
The corresponding structure looks this way:
```C
typedef struct GeanySymbol
{
gchar *name;
gchar *detail;
gchar *scope;
gchar *file;
TMParserType lang;
gulong line;
gulong pos;
glong kind;
guint icon;
TMTag *tag;
gint refcount; /* the reference count of the symbol */
} GeanySymbol;
```
where either `tag != NULL` when using `geany_symbol_new_from_tag()`, or `tag == NULL` for `geany_symbol_new()`.
The important part is that the members of `GeanySymbol` cannot be accessed directly from other files but only using getters that either use the `tag` or the member of `GeanySymbol` such as
```C
const gchar *geany_symbol_get_name(const GeanySymbol *sym)
{
if (sym->tag)
return sym->tag->name;
return sym->name;
}
```
By this interface, all callers like the symbol tree implementation are completely shielded from the details of where the symbol comes from. The bulk of the diffs inside `symbols.c` is pretty much just using this interface instead of using `TMTag` directly and renaming `tag` to `symbol`. `get_symbol_name()` and `get_symbol_tooltip()` were moved to `GeanySymbol` implementation, and also (previously inlined) `geany_symbol_get_name_with_scope()` was moved there too.
The additional `PluginExtension` interface for using these symbols would be more or less identical to what I proposed in https://github.com/geany/geany/pull/3850, i.e.
```C
gboolean (*doc_symbols_provided)(GeanyDocument *doc);
GPtrArray *(*doc_symbols_get)(GeanyDocument *doc);
```
and
- either additional `void (*doc_symbols_request)(GeanyDocument *doc, GCallback on_done);` in this interface making Geany request the extension for symbols (asynchronously)
- or some `symbol_tree_reload()` function the plugin could call which would make Geany re-request symbols using `doc_symbols_get()` after the plugin gets them e.g. from the LSP server
@b4n How does something like this sound? The implementation here is incomplete (only tested with the `TMTag` "backend" of `GeanySymbol`) but I don't want to continue in case you have some reservations regarding this approach.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3910
-- Commit Summary --
* Possible extension interface for symbol tree
-- File Changes --
M meson.build (3)
M src/Makefile.am (1)
M src/sidebar.c (7)
M src/sidebar.h (2)
A src/symbol.c (341)
A src/symbol.h (67)
M src/symbols.c (426)
M src/symbols.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/3910.patchhttps://github.com/geany/geany/pull/3910.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3910
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3910(a)github.com>
After losing focus, the key release of Ctrl+tab isn't delivered to the handler and the MRU window is shown "forever" (or until it's removed by repeated ctrl+tab).
There are 2 situations when focus loss may happen:
1. In the 600ms interval when the MRU popup isn't shown yet but tabs are already being switched. This is handled by checking whether the main window has focus in on_switch_timeout() and the MRU window isn't shown when the focus is lost.
2. After the MRU popup is shown. This is handled by connecting to "focus-out-event" of the main window and stopping the switch in its handler.
Fixes #3330.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3907
-- Commit Summary --
* Fix stuck MRU dialog when Geany loses focus
-- File Changes --
M src/notebook.c (47)
-- Patch Links --
https://github.com/geany/geany/pull/3907.patchhttps://github.com/geany/geany/pull/3907.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3907
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3907(a)github.com>
My proposial is to add possibility that the user could exclude specific folders and files from showing inside of the explorer of the project and workspace.
Currently seem that the above either doesn't exist or is not documented.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3876
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3876(a)github.com>
This is just a quick test of multiple carets for Geany. IMO we don't need a full support of everything working on multiple carets, users typically just need to insert/delete things at multiple places simultaneously for which this is sufficient.
Ideally, this should be mapped to alt+click as this is what vscode does and also we use alt+shift for the block caret. I only did run into a problem on macOS where (currently in a virtual machine) I get `GDK_MODIFIER_RESERVED_25_MASK` instead of `GDK_MOD1_MASK` but I'm always confused with GDK events so I'm maybe doing something wrong.
(Comparing to the LSP plugin, the ratio of the number of thumbs up for this feature to the amount of time spent on implementing it is quite favorable ;-)
Fixes #1141
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3899
-- Commit Summary --
* Preliminary support of multiple cursors
-- File Changes --
M src/editor.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/3899.patchhttps://github.com/geany/geany/pull/3899.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3899
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3899(a)github.com>
Closed #3369 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3369#event-13204668841
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issue/3369/issue_event/13204668841(a)github.com>
This could be X windows or XFCE related, sorry I have no idea.
geany -V; geany 1.36 (built on 2020-03-22 with GTK 3.24.14, GLib 2.64.1)
OS is Mint 20.3 Una XFCE edition
To reproduce;
- open geany
- type "a" in untitled
- ctrl-n
- press and hold ctrl-tab to switch tabs, release tab key but keep ctrl key held down till popup shows
- click any menu
- release ctrl
- Now popup is stuck as always on top until geany is closed
See attached screen capture for example (you may need to download it first to view)
https://user-images.githubusercontent.com/72730470/200763465-e06bbdc2-bba1-…
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3330
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3330(a)github.com>
Steps to reproduce:
1. Open document `foo.bar` in Geany.
2. Open the same document in e.g. `vi` and modify it.
3. Click inside the Scintilla widget inside Geany containing `foo.bar`
4. This single click selects several lines of code.
The selection below is a result of a single click:
<img width="1005" alt="Screenshot 2024-06-13 at 16 02 18" src="https://github.com/geany/geany/assets/713965/89e45dd2-c49b-4ba8-945e-b62d50…">
What I think happens is that when the widget with the warning appears at the top of the window, Scintilla scrolls the text by the amount of the height of the widget and all this happens within the click handler. As the scroll happens while the click is in progress, selection is made between the start Scintilla position of the click and the end position after the scroll.
Maybe postponing the display with the warning to idle would help here.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3906
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3906(a)github.com>