Op donderdag 2 augustus 2018 22:21:57 CEST schreef Di Mang: > 2018-08-01 13:58 GMT+02:00 Adrien Monteleone <adrien.montele...@lusfiber.net > > > On Aug 1, 2018, at 4:57 AM, Geert Janssens <geert.gnuc...@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 _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.