[GNC] survey: unifying the appearance in different options dialogs

[Geert Janssens]

Op donderdag 2 augustus 2018 22:21:57 CEST schreef Di Mang:
> 2018-08-01 13:58 GMT+02:00 Adrien Monteleone <adrien.monteleone at lusfiber.net
> > > On Aug 1, 2018, at 4:57 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > 
> > wrote:
> > > Op dinsdag 31 juli 2018 00:51:54 CEST schreef Di Mang:
> > >> Hello Geert and Adrien,
> > >> 
> > >> I agree it is a good idea to revise the report options and possibly
> > >> summarize to reduce the number of tabs.
> > >> There are currently
> > >> some reports that have tabs with only a few settings.
> > >> 
> > >> 
> > >> But in my opinion it would not be a good solution to move away
> > 
> > completely
> > 
> > >> from tabs for *all* option dialogs.
> > >> For option dialogs with only a few reports it will take up too much
> > 
> > space
> > 
> > >> on the window.
> > > 
> > > This doesn't make sense to me. If we move to "tabs" on the left for at
> > 
> > least
> > 
> > > one option window, we need to dimension the window anyway that it will
> > 
> > fit on
> > 
> > > the smallest screen we wish to support. How would this minimal dimension
> > 
> > be
> > 
> > > affected by the number of "tabs" in that area ? (I'm quoting "tabs"
> > 
> > because
> > 
> > > it's not the exact term for the exact widget I had in mind, more on that
> > > below).
> > > 
> > > Having a consistent way to represent options throughout the application
> > 
> > is
> > 
> > > more important to me.
> > 
> > I agree. Options shouldn’t switch to one or the other based on their
> > quantity. All of these dialogs should be consistent. And if it can work
> > once...
> > 
> > >> I think we
> > >> have to
> > >> distinguish between different
> > >> option
> > >> dialogs / windows:
> > >> 
> > >> *
> > 
> > main window:
> > an exception, because of dynamic tabs (with a scroll bar if
> > 
> > >> necessary)
> > > 
> > > Indeed, although a scroll bar for tabs is a bit awkward.
> > > 
> > >> *
> > >> windows with main preferences: currently with
> > 
> > tabs on the left side (like
> > 
> > >> in Geany)
> > > 
> > > I suppose you mean “many" preferences.
> > 
> > Perhaps the
> > ‘main’ app preferences, which does use the sidebar list. The Gnome desktop
> > does the same.
> 
> Yes,
> 
> I meant here the "main" app preferences: like "Edit" > "Preferences" in
> GnuCash.
> 
> For more clarity find examples of different dialogs in the appendix.
> 
On that image:
* I now understand with "scroll bars" you mean a way to scroll left or right 
if there are more tabs than fit the window. I took it for a complete scroll 
bar, where you just mean a left and right arrow. So we agree here.

* The lower right image is an assistant as stated earlier, and should not be 
compared with dialogs or windows with tabs/lists. We don't control the visual 
behavior of these. It comes from gtk.

* The two dialogs (one with many and one with few tabs). I still don't see a 
reason to make an exception based on the number of tabs. For me all options 
dialogs should still behave the same and so use the same ui components.


> > > Here's a video of another application implementing this behavior (though
> > 
> > from
> > 
> > > the KDE world):
> > > https://www.youtube.com/watch?v=H24jdjE5Q6E
> > > 
> > > Clearly this is for gnucash 4.x at best...

> > Interesting. I don’t suppose Gtk+4 has this in the works?

Adrien, I have no idea if Gtk is heading in a similar direction or not.

Regards,

Geert