• Gtk.Message_Dialog

    From AdaMagica@21:1/5 to All on Wed Sep 8 06:52:13 2021
    I need a two page message for a help button, so I have the callback

    procedure Help (Self: access Gtk.Button.Gtk_Button_Record'Class) is
    begin
    Show ("Page 1");
    Show ("Page 2");
    end Help;

    where

    procedure Show (Message: Glib.UTF8_String) is
    Dialog : Gtk.Message_Dialog.Gtk_Message_Dialog;
    Response: Gtk.Dialog.Gtk_Response_Type;
    begin
    Gtk.Message_Dialog.Gtk_New (Dialog,
    Parent => Parent,
    Flags => Modal,
    The_Type => Message_Info,
    Buttons => Buttons_Close,
    Message => Message);
    Response := Gtk.Message_Dialog.Run (Dialog);
    Gtk.Message_Dialog.Close (Dialog);
    end Show;

    The problem is: When the first dialog's Close button is pressed, the next page appears, but the first is not closed. When the second page's Close is pressed, the window disappers, but the first dialog window is still there. Only pressing the red cross on
    the window's right upper edge closes the dialog.

    What's wrong with my code?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to AdaMagica on Wed Sep 8 17:02:51 2021
    On 2021-09-08 15:52, AdaMagica wrote:
    I need a two page message for a help button, so I have the callback

    procedure Help (Self: access Gtk.Button.Gtk_Button_Record'Class) is
    begin
    Show ("Page 1");
    Show ("Page 2");
    end Help;

    where

    procedure Show (Message: Glib.UTF8_String) is
    Dialog : Gtk.Message_Dialog.Gtk_Message_Dialog;
    Response: Gtk.Dialog.Gtk_Response_Type;
    begin
    Gtk.Message_Dialog.Gtk_New (Dialog,
    Parent => Parent,
    Flags => Modal,
    The_Type => Message_Info,
    Buttons => Buttons_Close,
    Message => Message);
    Response := Gtk.Message_Dialog.Run (Dialog);
    Gtk.Message_Dialog.Close (Dialog);
    end Show;

    The problem is: When the first dialog's Close button is pressed, the next page appears, but the first is not closed. When the second page's Close is pressed, the window disappers, but the first dialog window is still there. Only pressing the red cross
    on the window's right upper edge closes the dialog.

    What's wrong with my code?

    You must call Destroy on the dialog to kill its window.

    P.S. Note, that when the object reference is "floating" you have to sink
    it first before calling Destroy. However, in your case after Run all
    references must be OK.

    P.P.S. Modal dialogs is the root of all evil...

    --
    Regards,
    Dmitry A. Kazakov
    http://www.dmitry-kazakov.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From AdaMagica@21:1/5 to Dmitry A. Kazakov on Wed Sep 8 10:09:54 2021
    Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:
    You must call Destroy on the dialog to kill its window.
    Thanks, Dmitry, that worked.
    P.P.S. Modal dialogs is the root of all evil...
    Whar else would you recommend?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to AdaMagica on Wed Sep 8 21:01:32 2021
    On 2021-09-08 19:09, AdaMagica wrote:
    Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:
    You must call Destroy on the dialog to kill its window.
    Thanks, Dmitry, that worked.
    P.P.S. Modal dialogs is the root of all evil...
    Whar else would you recommend?

    Just common sense of ergonomic UI, because I am no expert in this.

    I do not like dialogs because they cover other UI elements and require switching user attention.

    If I need some input field I usually reserve a place on the screen with confirmation and cancel buttons. I try to implement
    checking-while-typing when possible and not too annoying.

    A confirmation/commit button is IMO preferable, however modern UIs tend
    to commit changes as soon as the UI element loses the focus.

    For settings I use tabbed views. They tend to grow out of any measure.
    Not a perfect solution, but IMO much better than dialogs and in any case
    better than tree views when you need to expand and collapse nodes
    looking for a setting parameter.

    Modal dialogs are OK for emergencies when continuation is absolutely
    impossible without user intervention.

    One of few advantages of GTK is that widgets and containers
    automatically expand and shrink. One should use this feature and avoid
    fixed sizes. The minimum widget size, e.g. of a label or edit field can
    be set.

    --
    Regards,
    Dmitry A. Kazakov
    http://www.dmitry-kazakov.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mark Wilson@21:1/5 to Dmitry A. Kazakov on Fri Sep 10 11:54:55 2021
    On Wednesday, September 8, 2021 at 8:01:35 PM UTC+1, Dmitry A. Kazakov wrote:
    On 2021-09-08 19:09, AdaMagica wrote:
    Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:

    I do not like dialogs because they cover other UI elements and require switching user attention.


    Spot on in my view.

    Modality, which a vast majority of dialogs are, are anathema to a good user experience.

    Apple used to know this, once, but they've relented in the face of ever increasing costs of actually giving a shit. Windows, and Linux, well, ...

    You'd think that the open source software community would take one (or three) steps back, look at the literature, look at the evidence, and change their ways.

    They won't. Not enough $$ in it, sadly.

    Rant over.

    Cheers,
    M

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)