Difference between revisions of "UnsinkableDialogs"

From Inkscape Wiki
Jump to navigation Jump to search
(Categorization)
 
(9 intermediate revisions by 2 users not shown)
Line 6: Line 6:


:Also, when new windows are created too fast (press and hold ctrl-n for a couple seconds), this often results in "jitter" where windows fight for focus and frantically redisplay. I'll see if some new checks can heal this.
:Also, when new windows are created too fast (press and hold ctrl-n for a couple seconds), this often results in "jitter" where windows fight for focus and frantically redisplay. I'll see if some new checks can heal this.
:'''UPDATE:''' Here's what I found so far. If I add a gtk_window_present(w) at the end of sp_transientize_callback (i.e. bring  on top the document window that initiated the transientize), the dialog stays reliably on top, but it gives frantic races when there are too many document windows created too fast. If I remove this call, there are no races, but the dialog not always shows up on top of the document window; usually when you switch to a new document, it buries the dialogs (even though they are re-transientized!) and only if you click on the window bar of the document one more time, the dialogs emerge.
: So both options have their problems. I continue to thinks about it. Please test and share your insights!
:'''UPDATE 2:''' I did it! Not the most straightforward way, but it works. Now each retransientizing sets a semaphore that prevents another retransientizing for 20 msec after this one has finished (using timeout). This way, there are no more races (you can press and hold ctrl-n, or load *svg from an entire dir), but each transientizing brings dialogs nicely to top so they are truly unsinkable. Only two dialogs are made unsinkable so far, the toolbox and ctrl-shift-f. Please test the latest CVS and report your experience.


* The first (and only the first) desktop created by the program sends out the signal before a window for it is created, and the transientizing therefore fails. I added an ugly hack, inkscape_reactivate_desktop in inscape.c, which is called by sp_create_window in interface.c when it's done creating the window. This works but perhaps there's a better way. Ideas welcome.
* The first (and only the first) desktop created by the program sends out the signal before a window for it is created, and the transientizing therefore fails. I added an ugly hack, inkscape_reactivate_desktop in inscape.c, which is called by sp_create_window in interface.c when it's done creating the window. This works but perhaps there's a better way. Ideas welcome.
--------
::I just got a chance to try this out and I generally like it.  One thing I do not like is that the document window is auto-raising itself when it gets the focus.  To me this is is counter-intuitive, as every other gnome application I use follows the window manager settings of not auto-raising windows when they get the focus.  I think associating transients with the focused window is the right thing to do, but I dont think its a good idea to auto-raise the windows.  Make sense?  Let me know if I'm off-base here.  -tvon
:::Please comment out gtk_window_present(w) inside sp_transientize_callback() in src/dialogs/dialog-events.c and see if this solves your problem. Please also check if the dialogs still stay on top after this change. As described above, I tried it without the gtk_window_present, but on my KDE it resulted in dialogs not emerging on top when I switch document windows, even though the dialogs are now re-transientized to the new document. For example, try switching between two maximized document windows and compare the behavior of dialogs with and without gtk_window_present(w). --bb
::::That seems to do it.  The document windows no longer auto-raise, but the toolbox is always-on-top.  Thanks much Bulia.  --tvon
[[Category:Wiki Attic]]

Latest revision as of 17:58, 20 June 2006

I just committed an update that makes the toolbar and the object-properties dialog (ctrl-shift-f) unsinkable. This means they re-transientize themselves whenever a new desktop window becomes active. That is, no matter how you switch between document windows, these dialogs remain on top. If you minimize the last (or the only) document window, however, the dialogs minimize too.

Implementation is very simple: the dialogs respond to the activate_desktop signal by attaching themselves to the window of the desktop that sent that signal. There are two problems where I may use someone's help, before I make all other dialogs similarly unsinkable:

  • It's not 100% reliable. Sometimes dialogs fail to re-tranzientize. Looks like this happens when the signal is not sent for some unknown reason. Please test and report your observations or ideas.
Also, when new windows are created too fast (press and hold ctrl-n for a couple seconds), this often results in "jitter" where windows fight for focus and frantically redisplay. I'll see if some new checks can heal this.
UPDATE: Here's what I found so far. If I add a gtk_window_present(w) at the end of sp_transientize_callback (i.e. bring on top the document window that initiated the transientize), the dialog stays reliably on top, but it gives frantic races when there are too many document windows created too fast. If I remove this call, there are no races, but the dialog not always shows up on top of the document window; usually when you switch to a new document, it buries the dialogs (even though they are re-transientized!) and only if you click on the window bar of the document one more time, the dialogs emerge.
So both options have their problems. I continue to thinks about it. Please test and share your insights!
UPDATE 2: I did it! Not the most straightforward way, but it works. Now each retransientizing sets a semaphore that prevents another retransientizing for 20 msec after this one has finished (using timeout). This way, there are no more races (you can press and hold ctrl-n, or load *svg from an entire dir), but each transientizing brings dialogs nicely to top so they are truly unsinkable. Only two dialogs are made unsinkable so far, the toolbox and ctrl-shift-f. Please test the latest CVS and report your experience.
  • The first (and only the first) desktop created by the program sends out the signal before a window for it is created, and the transientizing therefore fails. I added an ugly hack, inkscape_reactivate_desktop in inscape.c, which is called by sp_create_window in interface.c when it's done creating the window. This works but perhaps there's a better way. Ideas welcome.

I just got a chance to try this out and I generally like it. One thing I do not like is that the document window is auto-raising itself when it gets the focus. To me this is is counter-intuitive, as every other gnome application I use follows the window manager settings of not auto-raising windows when they get the focus. I think associating transients with the focused window is the right thing to do, but I dont think its a good idea to auto-raise the windows. Make sense? Let me know if I'm off-base here. -tvon
Please comment out gtk_window_present(w) inside sp_transientize_callback() in src/dialogs/dialog-events.c and see if this solves your problem. Please also check if the dialogs still stay on top after this change. As described above, I tried it without the gtk_window_present, but on my KDE it resulted in dialogs not emerging on top when I switch document windows, even though the dialogs are now re-transientized to the new document. For example, try switching between two maximized document windows and compare the behavior of dialogs with and without gtk_window_present(w). --bb


That seems to do it. The document windows no longer auto-raise, but the toolbox is always-on-top. Thanks much Bulia. --tvon