Menubar is customizable in CorelDraw for example.
As well in Corel Photo-Paint, MS Word, Excel, PowerPoint, Outlook, Access etc. the entire LibreOffice, the entire Apache Office, some from Adobe's programs (eg. Photoshop)...
However,
you spoke about the need of menu customisation because you wanted to have the menu on the same line with other "things" (buttons etc.).
IMHO, as I said, your need can be easier covered by putting the menu in a toolbar. Having a full menu customization engine can be harder to write than a toolbar one because one should be allowed to add/delete/move items in a tree. Also, usually the GUI frameworks come with a ready-made end-user toolbar editor which the programmer can just use whereas an end-user menu editor should be written from scratch.
Customization is done by the users that know how to do it, that's why it can NOT "confuse users". "Reset" button can be in help for confused users too.
Almost everyone thinks that he know how to do it. But reality is different. That's why we seldom see 1.) changed menu layouts in programs which support it and 2.) such requests in the programs which doesn't support it.
Also, btw, from the entire market segment at which XnViewMP targets which do you think that's the percentage of the users who need a menu customization engine
before a solid on-disk AND in database management subsystem for the photos?
It all boils down to priorities. I'm not apriori against of menu customization (also I like very much the visual way in which Corel Draw/Photo-Paint handles it) but looking at the Photo Managers market today, the programs which compete here (Lightroom, ACDSee Pro, AfterShot Pro, PhotoSupreme / IDImager, FastStone Viewer, digiKam, RawTherapee, UFRaw, darkTable, Zoner Photo Studio, Picasa, iMatch, IrfanView... ...did I missed anything?)
everyone (and his mother) is targeted to provide a better user experience in photo management (first - because viewing has reached more or less at the level of the commodity),
editing (second - because there are Photoshop and Lightroom and is quite difficult to penetrate)
and viewing.
I am quite reserved that a community will adopt a Photo Manager because it has a customizable menu when it has problems with on-disk primitives (copy/move etc.) and on-db ones (rating/coloring, keywording, searching/filtering etc.). As I said, it all boils down to priorities.
You are right - menu can be added as toolbar button too, similar to the "Firefox button", or "Office button" in MS-office.
Yes, but this is not what I meant. I meant to put the menu in a (draggable) toolbar. Like this:
- Menu-as-toolbar.jpg (13.26 KiB) Viewed 1214 times
....there are much more important things to do...
interface is not unimportant, is it?
I didn't say that is unimportant I said that "there are much more important things to do". (see above).
Also,
we should look at the efficiency of the implementation. If the outcome covers the needs of an extensive area of our user base in a discoverable way by a rather small amount of coding effort, then go for it. Otherwise go there where we can get the most bang for the buck without paying too much technical debt (IOW sacrificing internal architecture, introducing bugs etc.)
...The standard way is to use a splitter with maximize/minimize buttons on it (sometimes called Netscape Splitter).....
I use this splitter button often in standard version (in the middle of the height of the splitter bar- yes ?? ), but I dont see it in xnViewMP. Now i can show/hide tree-pane only by the menu or toolbar button. I think double-click on tabs or empty tab area can simplify the show/hide action. Even single click on "folder" tab is not in use for now.
Double-clicking on tabs, yes (somewhat). But double-clicking should hide only that tab. IMHO we complicate things.
It is much easier and safer to go to classical way by having a Netscape splitter. The solution for Qt is here:
http://stackoverflow.com/questions/8831 ... tons-on-it
....You are not a programmer, isn't it?
I'm not a programer, but there are a lot of programs - customizable, stable and useful, you know this.
"Customizable, stable and useful" - pick two.
...sorry I couldn't resist.
It is very very hard (read: hard like hell) to have a good QA when your program is very customizable. The QA complexity grows exponentially with each option added. Believe me, I was there (and I dare to say that still I am). However, I don't say that XnViewMP shouldn't be customizable. On contrary. But we must be very careful what to implement in order to not destabilize the beast.
Customization is important, xnView is customizable, that's one of the reasons we like it so much.
I'm trying to add some ideas to make it even better in MP version.
I applaud your intentions.
Be my guest.
P.S.
m.Th., I see this in your signature:
- Dark Themed XnViewMP 0.61 64bit & XnView 2.00 x64 on Win7 x64 -
Is this another "Dark theme" for xnViewMP and where to find it ?
In the menu go to View | Theme | Dark Theme and then choose 'Apply' and 'Ok'.
Question: What would happen if I had my own home-made menu layout?
