Loading ...
Sorry, an error occurred while loading the content.
 

GUI Patterns

Expand Messages
  • Shlomi Fish
    Those who use a lot of GUI Programs know that there are some common patterns in them. Many of which are not abstracted into an API by GUI libraries such as
    Message 1 of 8 , Jun 2, 2002
      Those who use a lot of GUI Programs know that there are some common
      patterns in them. Many of which are not abstracted into an API by GUI
      libraries such as Gtk+, Qt, the Win32 API, MFC, wxWindows, etc. Nor should
      they, as these libraries should be flexible enough to allow you to design
      any GUI you'd like out of the most basic widgets. But, wouldn't it be cool
      if you had an API above them that would abstract such patters?

      Examples, off the top of my head:

      1. Disabled/enabled controls in a dialog. In everywhere I saw, if checkbox
      X disables or enables some of the controls below it, then the disabling
      logic has to be hard-coded into the program.

      2. A selection of items out of a list. Usually implemented as two
      list-boxes with a left arrow, right arrow (and up arrow and down arrow if
      appropriate). But there isn't such a predefined control.

      3. A scroll-bar that is synchornized with an edit-box displaying the exact
      numeric value.

      And naturally there are more.

      Do you know of any libraries offering such pre-defined meta-widgets? Any
      for Linux?

      Regards,

      Shlomi Fish



      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      "Let's suppose you have a table with 2^n cups..."
      "Wait a second - is n a natural number?"
    • Oleg Goldshmidt
      ... I am not a GUI programmer, but don t the things that you describe (parts of dialogues and options enabled/disabled etc) go deeper than GUI? E.g. don t they
      Message 2 of 8 , Jun 3, 2002
        Shlomi Fish <shlomif@...> writes:

        > Do you know of any libraries offering such pre-defined meta-widgets?
        > Any for Linux?

        I am not a GUI programmer, but don't the things that you describe
        (parts of dialogues and options enabled/disabled etc) go deeper than
        GUI? E.g. don't they imply an underlying state machine that governs
        what should be disabled/enabled in each state?

        Or am I misreading the question?

        --
        Oleg Goldshmidt | ogoldshmidt@...
        "A sense of the fundamental decencies is parceled out unequally at birth."
      • Nadav Har'El
        ... When the library is OO-like, even if the language itself is not OO, you can create such mega-widgets, which will look and behave like one widget but will
        Message 3 of 8 , Jun 3, 2002
          On Mon, Jun 03, 2002, Shlomi Fish wrote about "[hackers-il] GUI Patterns":
          > 1. Disabled/enabled controls in a dialog. In everywhere I saw, if checkbox
          > X disables or enables some of the controls below it, then the disabling
          > logic has to be hard-coded into the program.
          >
          > 2. A selection of items out of a list. Usually implemented as two
          > list-boxes with a left arrow, right arrow (and up arrow and down arrow if
          > appropriate). But there isn't such a predefined control.
          >
          > 3. A scroll-bar that is synchornized with an edit-box displaying the exact
          > numeric value.
          >
          > And naturally there are more.
          >
          > Do you know of any libraries offering such pre-defined meta-widgets? Any
          > for Linux?

          When the library is OO-like, even if the language itself is not OO, you
          can create such mega-widgets, which will look and behave like one widget
          but will ultimately be composed from several seperate built-in widgets.

          You can do that in Motif using the Xt framework (but keep a psychologist
          on retainer, you're going to need one if you program in Xt/Motif...), and
          it is even more natural in Tk and [incr Tcl] (the OO version of TCL, those
          who know TCL will appreciate the pun on C++'s name); The most well known
          Tk mega-widget set is the [incr Widgets], see
          http://incrtcl.sourceforge.net/iwidgets/

          A short quote from that site:
          "[incr Widgets] offers a strong object-oriented foundation which addresses
          the need for a flexible and extensible mega-widget set. Its usage replaces
          common widget combinations with higher level abstractions, simplifying
          code, reducing errors, increasing readability, adding productivity, and
          promoting a singular look-and-feel."

          I assume similar things are doable in Qt and maybe even Gtk, but I never
          looked into it (I have to admit that though I have a lot of experience in
          GUI programming, I'm a little behind-the-times because it's been a few
          years since I wrote a GUI).

          --
          Nadav Har'El | Monday, Jun 3 2002, 23 Sivan 5762
          nyh@... |-----------------------------------------
          Phone: +972-53-245868, ICQ 13349191 |Someone offered you a cute little quote
          http://nadav.harel.org.il |for your signature? JUST SAY NO!
        • Nadav Har'El
          ... Not really. Modern GUI design is based not on a state machine (also called modal design, because the UI is based on entering various modes, e.g., see Vi)
          Message 4 of 8 , Jun 3, 2002
            On Mon, Jun 03, 2002, Oleg Goldshmidt wrote about "Re: [hackers-il] GUI Patterns":
            > Shlomi Fish <shlomif@...> writes:
            >
            > > Do you know of any libraries offering such pre-defined meta-widgets?
            > > Any for Linux?
            >
            > I am not a GUI programmer, but don't the things that you describe
            > (parts of dialogues and options enabled/disabled etc) go deeper than
            > GUI? E.g. don't they imply an underlying state machine that governs
            > what should be disabled/enabled in each state?

            Not really. Modern GUI design is based not on a state machine (also called
            "modal" design, because the UI is based on entering various modes, e.g.,
            see Vi) but rather on callbacks. The UI is presented on the screen, and
            when something happens (e.g., a user clicks on some button) an appropriate
            callback function is called and does some predetermined task (which might
            depend also on what goes on in the rest of the application). If the button
            is "disabled" (e.g., grayed out), a user will not be able to click on it
            and the callback will never be called - the application doesn't need to
            to remember such a thing in some special hidden "state" variable. The
            application does need to implement callbacks correctly: for example, before
            a file is loaded into an editor, the "save" and "close" buttons may
            be grayed out (or absent altogether); When a file is loaded, e.g. as
            a callback from the "Load" button, this callback will ungray the "save"
            and "close" buttons. The "close" callback will gray out these buttons
            again. I think what Shlomi was after was some framework under which you
            can keep all these decisions in one place (object, in OO speak) instead
            of spreading it around in the various callbacks for different objects (in
            this example, for load and close).

            By the way, if anyone is curious why modern GUIs are callback-based rather
            than modal - well, while keeping complicated hidden "state" variables and
            logic by the computer is possible, keeping it in the human brain is much
            harder. A human (especially those of the genus Homo Sapiens Newbicus)
            tends to forget what state the program is in, and which kinds of operations
            are valid in this state. A callback-based GUI solves this problem, because
            all operations are run by clicking (or some other method of interaction)
            on some visible on-screen control, each of which in turn runs its callback
            to do the desired work.
            For the finest example (in my opinion) of an (almost) mode-less GUI, see
            the Palm Pilot. There you (ideally) don't even have the mode of "which
            application I'm in" - at any point you can switch between applications,
            turn of the machine, and so on, and then go back to the application which
            is (ideally, but not always in practice) exactly like you left it.

            --
            Nadav Har'El | Monday, Jun 3 2002, 23 Sivan 5762
            nyh@... |-----------------------------------------
            Phone: +972-53-245868, ICQ 13349191 |"Outlook not so good." Wow! That magic 8-
            http://nadav.harel.org.il |ball knows everything! So, what about IE?
          • Oleg Goldshmidt
            ... That s what I meant: while the action performed when a button is pressed is implemented via a callback, the GUI must have a way to determine whether or not
            Message 5 of 8 , Jun 3, 2002
              "Nadav Har'El" <nyh@...> writes:

              > for example, before a file is loaded into an editor, the "save" and
              > "close" buttons may be grayed out (or absent altogether); When a
              > file is loaded, e.g. as a callback from the "Load" button, this
              > callback will ungray the "save" and "close" buttons. The "close"
              > callback will gray out these buttons again.

              That's what I meant: while the action performed when a button is
              pressed is implemented via a callback, the GUI must have a way to
              determine whether or not "save" and "close" should be disabled, and
              that depends on state... What am I missing?

              --
              Oleg Goldshmidt | ogoldshmidt@...
              "A sense of the fundamental decencies is parceled out unequally at birth."
            • Nadav Har'El
              ... There s generally no added state : whenever the close callback is called, it will (in addition to other stuff) disable the save and close buttons.
              Message 6 of 8 , Jun 3, 2002
                On Mon, Jun 03, 2002, Oleg Goldshmidt wrote about "Re: [hackers-il] GUI Patterns":
                > "Nadav Har'El" <nyh@...> writes:
                >
                > > for example, before a file is loaded into an editor, the "save" and
                > > "close" buttons may be grayed out (or absent altogether); When a
                > > file is loaded, e.g. as a callback from the "Load" button, this
                > > callback will ungray the "save" and "close" buttons. The "close"
                > > callback will gray out these buttons again.
                >
                > That's what I meant: while the action performed when a button is
                > pressed is implemented via a callback, the GUI must have a way to
                > determine whether or not "save" and "close" should be disabled, and
                > that depends on state... What am I missing?

                There's generally no added "state": whenever the "close" callback is
                called, it will (in addition to other stuff) disable the "save" and
                "close" buttons. If that operation would not make sense (because no
                file is loaded) the user would not have been able to cause this callback
                to run in the first place, because sometime earlier the "close" button
                would have been disabled (e.g., by an earlier "close" operation).

                This means that all state is visible to the user. Many times this is not
                possible to do completely, so the program still keeps some hidden state.
                But the less there is such hidden state, the more user-friendly (and
                un-Unix-ish) the GUI is considered.

                --
                Nadav Har'El | Monday, Jun 3 2002, 23 Sivan 5762
                nyh@... |-----------------------------------------
                Phone: +972-53-245868, ICQ 13349191 |The space between my ears was
                http://nadav.harel.org.il |intentionally left blank.
              • Shlomi Fish
                ... From my impression these meta-widgets are not exactly what I was looking for. I was looking for a widget that will abstract some of the functionality and
                Message 7 of 8 , Jun 18, 2002
                  On Mon, 3 Jun 2002, Nadav Har'El wrote:

                  > On Mon, Jun 03, 2002, Shlomi Fish wrote about "[hackers-il] GUI Patterns":
                  > > 1. Disabled/enabled controls in a dialog. In everywhere I saw, if checkbox
                  > > X disables or enables some of the controls below it, then the disabling
                  > > logic has to be hard-coded into the program.
                  > >
                  > > 2. A selection of items out of a list. Usually implemented as two
                  > > list-boxes with a left arrow, right arrow (and up arrow and down arrow if
                  > > appropriate). But there isn't such a predefined control.
                  > >
                  > > 3. A scroll-bar that is synchornized with an edit-box displaying the exact
                  > > numeric value.
                  > >
                  > > And naturally there are more.
                  > >
                  > > Do you know of any libraries offering such pre-defined meta-widgets? Any
                  > > for Linux?
                  >
                  > When the library is OO-like, even if the language itself is not OO, you
                  > can create such mega-widgets, which will look and behave like one widget
                  > but will ultimately be composed from several seperate built-in widgets.
                  >
                  > You can do that in Motif using the Xt framework (but keep a psychologist
                  > on retainer, you're going to need one if you program in Xt/Motif...), and
                  > it is even more natural in Tk and [incr Tcl] (the OO version of TCL, those
                  > who know TCL will appreciate the pun on C++'s name); The most well known
                  > Tk mega-widget set is the [incr Widgets], see
                  > http://incrtcl.sourceforge.net/iwidgets/
                  >
                  > A short quote from that site:
                  > "[incr Widgets] offers a strong object-oriented foundation which addresses
                  > the need for a flexible and extensible mega-widget set. Its usage replaces
                  > common widget combinations with higher level abstractions, simplifying
                  > code, reducing errors, increasing readability, adding productivity, and
                  > promoting a singular look-and-feel."
                  >

                  From my impression these meta-widgets are not exactly what I was looking
                  for. I was looking for a widget that will abstract some of the
                  functionality and behaviour of the GUI, while these widgets address mostly
                  look and feel and a bit more.

                  Regards,

                  Shlomi Fish


                  > I assume similar things are doable in Qt and maybe even Gtk, but I never
                  > looked into it (I have to admit that though I have a lot of experience in
                  > GUI programming, I'm a little behind-the-times because it's been a few
                  > years since I wrote a GUI).
                  >
                  > --
                  > Nadav Har'El | Monday, Jun 3 2002, 23 Sivan 5762
                  > nyh@... |-----------------------------------------
                  > Phone: +972-53-245868, ICQ 13349191 |Someone offered you a cute little quote
                  > http://nadav.harel.org.il |for your signature? JUST SAY NO!
                  >
                  >
                  > To unsubscribe from this group, send an email to:
                  > hackers-il-unsubscribe@egroups.com
                  >
                  >
                  >
                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                  >
                  >



                  ----------------------------------------------------------------------
                  Shlomi Fish shlomif@...
                  Home Page: http://t2.technion.ac.il/~shlomif/
                  Home E-mail: shlomif@...

                  "Let's suppose you have a table with 2^n cups..."
                  "Wait a second - is n a natural number?"
                • guy keren
                  ... if you look at glade, you ll see that there are some such widgets in both gtk and gnome. it begins with simple ones (gtk_clist), goes to the file-selection
                  Message 8 of 8 , Jun 18, 2002
                    On Tue, 18 Jun 2002, Shlomi Fish wrote:

                    > From my impression these meta-widgets are not exactly what I was looking
                    > for. I was looking for a widget that will abstract some of the
                    > functionality and behaviour of the GUI, while these widgets address mostly
                    > look and feel and a bit more.

                    if you look at glade, you'll see that there are some such widgets in both
                    gtk and gnome. it begins with simple ones (gtk_clist), goes to the
                    file-selection dialog (which also supports navigating the file system,
                    creating and deleting directories, renaming files....), and goes to
                    calendar widget, and up to a 'gnome application' widget, which sets up the
                    menu bar, toolbar, status line and application area.

                    it is true that much more can be done, provided one has enough experience
                    with GUI programming, that they can make the interfaces of such composite
                    classes - general enough, to not limit their users to the point where
                    they'll dump the class and roll their own.

                    --
                    guy

                    "For world domination - press 1,
                    or dial 0, and please hold, for the creator." -- nob o. dy
                  Your message has been successfully submitted and would be delivered to recipients shortly.