question box broken

[westram]

Bugs:

• reuses (old?) title if none gets set
• some activations of question box fail to update:
  
  • after maximizing + restoring question box displays correctly:
    
• question box should not display twice. Doing so indicates, that AW_dialog does not block.

Reproduce above misbehavior:

• reduce number of accepted search results: see patch
• run demo.arb, ARB_EDIT4 with marked species
• edit search setting:
  • search for

    A
    C
    G
    T
    

  • show results (question box already appears here and displays
• store properties and/or save
• restart ARB_EDIT4

[westram]

initial display

[westram]

after maximize + restore

[westram]

patch to provoke question during edit4-startup

[westram]

• question box should not display twice. Doing so indicates, that AW_dialog does not block.

It should be impossible to have two dialogs active (otherwise they are not dialogs, are they?)

Backtrace in the above situation:

#0  AW_device::pop_clip_scale (this=0xbe22a0) at AW_device.cxx:67
#1  0x00000000004ccc95 in ED4_manager::Show (this=0x14da940, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1114
#2  0x00000000004ccc89 in ED4_manager::Show (this=0xe64540, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1112
#3  0x00000000004ccc89 in ED4_manager::Show (this=0xe57400, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1112
#4  0x00000000004ccc89 in ED4_manager::Show (this=0xe16f20, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1112
#5  0x00000000004ccc89 in ED4_manager::Show (this=0xe11de0, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1112
#6  0x00000000004cc49e in ED4_root_group_manager::Show (this=0xe11de0, refresh_all=0, is_cleared=1) at ED4_manager.cxx:993
#7  0x00000000004ccc89 in ED4_manager::Show (this=0xe11cf0, refresh_all=0, is_cleared=1) at ED4_manager.cxx:1112
#8  0x00000000004cc246 in ED4_main_manager::Show (this=0xe11cf0, refresh_all=0, is_cleared=1) at ED4_manager.cxx:944
#9  0x00000000004e87e2 in ED4_root::refresh_window_simple (this=0x8eed40, redraw=false) at ED4_root.cxx:119
#10 0x00000000004e8b6a in ED4_root::refresh_all_windows (this=0x8eed40, redraw=false) at ED4_root.cxx:173
#11 0x00000000004dd183 in ED4_timer () at ED4_no_class.cxx:851
#12 0x00007ffff6eca940 in StrictlyTypedCallback<unsigned int, AW_root*, long, long>::operator() (this=0xb9caf0, p1=0x8eb070, p2=0, p3=0) at /home/ralf/ARB-bilbo/ARB.gtk.fix2/INCLUDE/cbtypes.h:117
#13 0x00007ffff6ec9c8e in Callback_FVV<unsigned int, AW_root*>::operator() (this=0xb9caf0, fixed=0x8eb070) at /home/ralf/ARB-bilbo/ARB.gtk.fix2/INCLUDE/cbtypes.h:172
#14 0x00007ffff6ec9258 in AW_timer_cb_struct::callOrDelayIfDisabled (this=0xb9cae0) at AW_root.cxx:362
#15 0x00007ffff6ec7b38 in AW_timer_callback (aw_timer_cb_struct=0xb9cae0) at AW_root.cxx:376
#16 0x00007ffff744a1ab in ?? () from /lib/libglib-2.0.so.0
#17 0x00007ffff74499d2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#18 0x00007ffff744d858 in ?? () from /lib/libglib-2.0.so.0
#19 0x00007ffff744dd65 in g_main_loop_run () from /lib/libglib-2.0.so.0
#20 0x00007ffff68b852b in gtk_dialog_run () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x00007ffff6eb3d8a in AW_dialog::run (this=0x7fffffffcc30) at AW_dialog.cxx:65
#22 0x00007ffff6ec5c4b in aw_question (unique_id=0x61366b "many_search_results", question=0x7ffff79be846 "More than 4000 results found!", buttons=0x613652 "Allow more,That's enough", sameSize=true, helpfile=0x0) at AW_question.cxx:59
#23 0x00000000004f63b2 in ED4_SearchResults::addSearchPosition (this=0xe58108, pos=0x6f2e090) at ED4_search.cxx:994
#24 0x00000000004f62f2 in reportSearchPosition (start=98790, end=98790, comment=0x0, mismatches=0x7fffffffcd70) at ED4_search.cxx:977
#25 0x00000000004f34c4 in SearchTreeNode::findMatches (this=0x9a5580, off=999, seq=0x6ee54f7 "aaggucccaaagucaugguuaagugggaaacgaugugggaaggcccagacagccaggauguuggcuuagaagcagccaucauuuaaagaaagcguaauagcucacuggucgagucggccugcgcggaagauguaacggggcuaaaccaugcaccgaagcugcggcagcgacgcuuaugcguuguuggguaggggagcguu"..., len=1905, mismatches=0, mismatch_list=0x7fffffffcd70) at ED4_search.cxx:274
#26 0x00000000004f4b1a in SearchTree::findMatches (this=0x9a55d0, seq=0x6e9bcc0 '.' <repeats 200 times>..., len=235892, report=0x4f628b <reportSearchPosition>) at ED4_search.cxx:607
#27 0x00000000004f65dd in ED4_SearchResults::search (this=0xe58108, seq_terminal=0xe58050) at ED4_search.cxx:1054
#28 0x00000000004f6ba9 in ED4_SearchResults::buildColorString (this=0xe58108, seq_terminal=0xe58050, start=64116, end=64199) at ED4_search.cxx:1198
#29 0x0000000000500662 in ED4_sequence_terminal::draw (this=0xe58050) at ED4_text_terminals.cxx:422
#30 0x00000000005013dc in ED4_text_terminal::Show (this=0xe58050, refresh_all=1, is_cleared=1) at ED4_text_terminals.cxx:605
#31 0x00000000004ccc89 in ED4_manager::Show (this=0xe57d40, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#32 0x00000000004ccc89 in ED4_manager::Show (this=0xe57900, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#33 0x00000000004ccc89 in ED4_manager::Show (this=0xe57640, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#34 0x00000000004ccc89 in ED4_manager::Show (this=0xe14f00, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#35 0x00000000004ccc89 in ED4_manager::Show (this=0xe14d00, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#36 0x00000000004ccc89 in ED4_manager::Show (this=0xe16f20, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#37 0x00000000004ccc89 in ED4_manager::Show (this=0xe11de0, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#38 0x00000000004cc49e in ED4_root_group_manager::Show (this=0xe11de0, refresh_all=1, is_cleared=1) at ED4_manager.cxx:993
#39 0x00000000004ccc89 in ED4_manager::Show (this=0xe11cf0, refresh_all=1, is_cleared=1) at ED4_manager.cxx:1112
#40 0x00000000004cc246 in ED4_main_manager::Show (this=0xe11cf0, refresh_all=1, is_cleared=1) at ED4_manager.cxx:944
#41 0x00000000004e87e2 in ED4_root::refresh_window_simple (this=0x8eed40, redraw=true) at ED4_root.cxx:119
#42 0x00000000004e8af1 in ED4_root::special_window_refresh (this=0x8eed40, handle_updates=true) at ED4_root.cxx:160
#43 0x0000000000506723 in ED4_expose_cb (aww=0xbced80) at ED4_window.cxx:387
#44 0x00007ffff6edbcfa in StrictlyTypedCallback<void, AW_window*, long, long>::operator() (this=0xc1c100, p1=0xbced80, p2=0, p3=0) at /home/ralf/ARB-bilbo/ARB.gtk.fix2/INCLUDE/cbtypes.h:117
#45 0x00007ffff6edaecc in Callback_FVV<void, AW_window*>::operator() (this=0xc1c100, fixed=0xbced80) at /home/ralf/ARB-bilbo/ARB.gtk.fix2/INCLUDE/cbtypes.h:172
#46 0x00007ffff6eda709 in WindowCallbackSlot::emit (this=0xc1c0f0) at AW_signal.cxx:72
#47 0x00007ffff6ed652d in AW_signal::Pimpl::emit (this=0xbe2360) at AW_signal.cxx:351
#48 0x00007ffff6ed648b in AW_signal::emit (this=0xbeede0) at AW_signal.cxx:335
#49 0x00007ffff6e96514 in aw_handle_expose_event (event=0x7fffffffdd20, self=0xbeedc0) at AW_area_management.cxx:123
#50 0x00007ffff6939188 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#51 0x00007ffff4bdd5de in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#52 0x00007ffff4bf1598 in ?? () from /usr/lib/libgobject-2.0.so.0
#53 0x00007ffff4bf28b9 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#54 0x00007ffff4bf3033 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#55 0x00007ffff6a500cf in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#56 0x00007ffff6932996 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#57 0x00007ffff658d94a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#58 0x00007ffff658d8f7 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#59 0x00007ffff658a3db in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#60 0x00007ffff658c251 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#61 0x00007ffff68b4591 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#62 0x00007ffff6568db6 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#63 0x00007ffff74499d2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#64 0x00007ffff744d858 in ?? () from /lib/libglib-2.0.so.0
#65 0x00007ffff744dd65 in g_main_loop_run () from /lib/libglib-2.0.so.0
#66 0x00007ffff6932bc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#67 0x00007ffff6ec8569 in AW_root::main_loop (this=0x8eb070) at AW_root.cxx:498
#68 0x00000000004c933f in ARB_main (argc=1, argv=0x7fffffffe2f8) at ED4_main.cxx:579
#69 0x00000000004a489f in main (argc=3, argv=0x7fffffffe2e8) at arb_main.cxx:10

[westram]

Problem arises because events get nested, e.g:

• Timer event gets called while problematic dialog is prompting. New refresh is triggered by timer, another dialog will be opened.
  • timer event can be suppressed by setting AW_root::disable_callbacks=true
  • doesn't fix the problem, but eliminates the second prompt
• Now a configure event gets triggered while still inside expose event
  • configure does a resize ⇒ resets clip_scale_stack of running expose (which is currently blocked by dialog)
  • motif version ​blocks a bunch of events to avoid that case

Possible solutions:

• suppress all events to other windows (i.e. only pass events to running dialog)
  • Cons:
    • only dialog will update (other windows will remain "empty" as in motif version)
• remove all modal dialogs (would also fix #179)
• ???

[westram]

This hack​ fixes most problems. Remaining:

• dialog does not update, i.e. remains empty (resizing dialog-window forces it to update)

[epruesse]

DUMP_EVENTS causes too much spam to be enabled automatically with DEBUG. Really!

The patch results in crash here:

arb_edit4(ED4_window::check_valid_scrollbar_values()+0x80)[0x53e81a]
arb_edit4(ED4_window::update_scrolled_rectangle()+0x216)[0x5146ae]
arb_edit4[0x5157f5]
/home/epruesse/arb/gtk/lib/libWINDOW.so(StrictlyTypedCallback<void, AW_window*, long, long>::operator()(AW_window*, long, long) const+0x30)[0x7f01ca53a074]
/home/epruesse/arb/gtk/lib/libWINDOW.so(Callback_FVV<void, AW_window*>::operator()(AW_window*) const+0x4b)[0x7f01ca539301]
/home/epruesse/arb/gtk/lib/libWINDOW.so(WindowCallbackSlot::emit()+0x27)[0x7f01ca538ceb]
/home/epruesse/arb/gtk/lib/libWINDOW.so(AW_signal::Pimpl::emit()+0xa2)[0x7f01ca535032]
/home/epruesse/arb/gtk/lib/libWINDOW.so(AW_signal::emit()+0x29)[0x7f01ca534f8d]
/home/epruesse/arb/gtk/lib/libWINDOW.so(aw_handle_configure_event+0x235)[0x7f01ca4f7286]

[epruesse]

A modal window will disable input. Even though AW_dialog blocks, it needs to run the event loop so that anything at all gets drawn. Blocking nesting in the event handling leads to all other windows staying gray.

The real issue is IMO that ARB needs to distinguish more cleanly between configure, expose and -input. Neither configure nor expose should cause AW_dialog to be run.

In the case at hand: why is there even a limit to the number of search results?

[westram]

DUMP_EVENTS causes too much spam to be enabled automatically with DEBUG. Really!

sure - just debugging..

[westram]

The real issue is IMO that ARB needs to distinguish more cleanly between configure, expose and -input. Neither configure nor expose should cause AW_dialog to be run.

Ok. I'll put some code against doing that in there.

In the case at hand: why is there even a limit to the number of search results?

Historical .. I'll remove it.

thx 4 comments

[westram]

Blocking nesting in the event handling leads to all other windows staying gray.

I believe event nesting nevertheless is a problem, e.g:

• each window has one event (which gets populated in aw_handle_*_event). Starting a 2nd event while the 1st is still running, will change the events data while inside handler. Works/fails randomly

[westram]

In the case at hand: why is there even a limit to the number of search results?

Historical .. I'll remove it.

done by [12281]

[epruesse]

Replying to westram:

I believe event nesting nevertheless is a problem, e.g:

• each window has one event (which gets populated in aw_handle_*_event). Starting a 2nd event while the 1st is still running, will change the events data while inside handler. Works/fails randomly

The only place we have a nested event loop is for the modal AW_dialog windows. If those were only triggered by input events, then no nesting can happen because input is blocked by the AW_dialog.

The exception are timer events, including updates coming from other components via the . IIRC your patch blocked those, so that should be fine.

Still, a cleaner separation of doing "just drawing" in the expose event, "just resizing" in the configure event and "just changing state" in events would be something to aim for. The entire GTK (or all modern GUI toolkits) concept assumes this. The fact that this is sort of mixed up also causes tons of unnessesary redraws.

The theory is like this: User input changes application state. If the display needs to be updates, the respective window parts are "invalidated". The same goes for configure events. GTK then coalesces all the invalidated regions into a minimal set of rectangles, for each of which an expose event is then triggered.

The drawback is that because expose is deferred until all other events are done, updates such as cursor position in the editor might not show while pressing right arrow. Of course, only if/because the stuff done in the right-arrow handling code takes too long.

The benefit is that, even with a very slow display or system in general, moving is relatively fast because there can be several changes of cursor position before a redraw is triggered. So degradation of performance is less painful IMO.

I believe it would also be easier to debug. Currently, resizes and redraws and resets of clipping stacks etc. are done all over the place (at least it feels that way).

[westram]

Replying to epruesse:

The only place we have a nested event loop is for the modal AW_dialog windows. If those were only triggered by input events, then no nesting can happen because input is blocked by the AW_dialog.

[12289] asserts no dialogs are started from inside events, despite key and button events.

The exception are timer events, including updates coming from other components via the . IIRC your patch blocked those, so that should be fine.

committed with [12290]

Still, a cleaner separation of doing "just drawing" in the expose event, "just resizing" in the configure event and "just changing state" in events would be something to aim for.

ack

[westram]

Milestone powerusability deleted