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 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. > > An alternative solution may be > the Side Bar List instead of Tabs on the left side (like in LibreOffice, > Gimp, Firefox) I surely agree a Side Bar List is better and that (or something similar) is what I had in mind. In fact I thought that's what you meant as well as the option dialogs for several reports were showing a list of groups instead as a list of tabs on my system already before your change. > * option dialogs with only few tabs: tabs at the top position (like in > Geany, Gedit, Gimp, LibreOffice) As said that would then break consistency again. Wasn't that your initial argument (which I like) ? My ideal solution would be a dynamic side bar list. That is if there's enough horizontal screen space (and the dialog is wide enough) show the list permanently. If the dialog gets narrowed (either due to user action or due to limited screen space), make the list hidden by default (with a button to show it) and when that button is clicked make it hover the actual content. 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... 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.
