Set correct sidebar/message window positions before showing the… #576
Conversation
|
@b4n Any opinion on this one? The reason I'm asking is that as I was playing with the big files and testing Geany performance now, I triggered this quite frequently and actually in a non-cosmetic way. It seems that when opening Geany takes longer because e.g. a bigger file has to be parsed, the redraw to the correct size gets somehow skipped and Geany gets into a strange state where it's drawn with the sizes from Glade and is kind of frozen (clicking inside editor doesn't work, menus don't react etc.). It only helps if I click to another editor tab after which Geany gets redrawn and starts working normally. This strange behavior doesn't happen if the correct sizes are applied before the initial show(). |
|
We should also show the main window before loading any files. It's better to have Geany show and then freeze/lockup than to have nothing happen when the user clicks the Geany icon. I experienced this a few times while testing that really slow Java file, I thought Geany was crashing on startup or something, but it was just that the really slow file was in session history. About 5 minutes passed before any sign of Geany running appeared. |
|
@codebrainz S/B a separate issue, but yeah showing Geany with "Loading Session Files..." would be better. @techee looks sensible to me. |
|
@codebrainz Good point, I tried this with the above patch and it seems to work - hope it doesn't have any side-effects. It's a bit unusual to see the empty window but I think I just have to get used to it. |
|
Can the status bar say "Loading Session Files..."? |
techee
force-pushed
the
start_flicker
branch
from
95f1b12
to
00d9bba
Compare
|
@elextr Done. The only problem was what to use to clear the "Loading session files..." message once they are loaded - I used the "This is Geany 1.26" message (which means that the message isn't displayed in the status window at the very beginning of the log). I also modified the patch slightly so the geany-startup-complete is emitted after all the session files get loaded in case some plugins depend on this behavior. |
Seems like a good thing to show when Geany is ready to use. |
…winodw Otherwise the window is first drawn with some default values and then redrawn with the saved ones which doesn't look nice.
techee
force-pushed
the
start_flicker
branch
from
00d9bba
to
21c5cfd
Compare
techee
changed the title
| gtk_paned_set_position(GTK_PANED(ui_lookup_widget(main_widgets.window, "hpaned1")), hpan_position); | ||
| gtk_paned_set_position(GTK_PANED(ui_lookup_widget(main_widgets.window, "vpaned1")), vpan_position); | ||
| } | ||
|
|
There was a problem hiding this comment.
I believe the only reason why it was here was that hpan_position and vpan_position were read in this file and accessible only here.
… main winodw
At the moment there's a slightly ugly redraw of the sidebar and message window when starting Geany because configuration_apply_settings(), which sets their correct positions, is called after gtk_widget_show() on the main window. When moving it before, this issue disappears.
I'm definitely not a GTK expert and the comment above configuration_apply_settings() says it should be called after the window is realized but is this really the case? It seems to work fine even with this change and even if this isn't the correct approach, I guess there must be some way to set the initial positions before showing the window (other editors start with the correct sizes when launched).
This patch isn't meant to be applied as it is (if the comment above configuration_apply_settings() is wrong, it should be removed at least), it's mainly meant for quick testing and further discussion.