More consistent menu structure

Ideas for improvements and requests for new features in XnView Classic

Moderators: XnTriq, xnview

User avatar
xnview
Author of XnView
Posts: 33205
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Post by xnview » Mon Jun 18, 2007 7:00 am

Icfu wrote:The only important thing is if you wanna be respected by your users/customers and if you respect them. With the approach "MY program, My code, MY decision" you should better not release a program but develop it for your kids only.
Yes, right, but it's "My program, My code but i'm NOT the user and it's not only My decision for new features", i try to add all requested features but the list is long, very long and my time is limited...

So i have made a poll, let's see what others users think!
http://newsgroup.xnview.com/viewtopic.php?p=49942
Pierre.

User avatar
helmut
Posts: 8213
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Post by helmut » Tue Jun 19, 2007 8:50 pm

Flexible menus would allow for changing the menu structure of XnView to anything the user likes. They can offer possibilities, but there are various issues which should be taken into account. Below I have summarized and written up some pros and cons of flexible menus and try to explain the importance of the initial menu structure.

Flexible menu structure
With a flexible menu structure any user could change the menu structure to his/her needs. Menu items could be moved, renamed and/or even hidden. This way the user could strip down XnView to the functionality he/she needs and make the menu structure work and fit best for him/her. There might be even various pre-defined versions of the flexible menu structure for XnView with simple, medium, and complex functionality. A light version of XnView could be created and provided easily for download. Users of other graphic viewers could make XnView look-alike what they are used to, see discussion IrfanViewmode.

So a flexible menu structure can solve various issues. But there are some possible issues/disadvantages:

- Effort
Currently, on the programmer's side (Pierre), the effort for such flexible menu is not that clear. There might be the chance of combining the introduction of the really important text based language files with flexible menus. Defining the text string used for a menu and defining the structure of the menu may be done with the same implemention, maybe not.

- Benefit not so clear
Flexible menus are not a brand-new idea, Word '97 has them, already. I have no figures at hand (and possibly even Micro$oft hasn't), but my guess is that most users do not use flexible menus. Some users might not know, other users do know them but do not touch the structure for various reasons: They are happy with the default structure, some are not happy but don't know how to really improve the structure, and some are afraid that other users (neighbour, technical support, ...) won't understand their program or the other way round. So the benefit of the flexible menus for users, especially novice and average users is uncertain and questionable.

- Impact on user interface
Something that is not used might do no harm to users, but only if it's well enough hidden. (I guess there are many users-like me who happened to move the toolbar of Word to another position without actually wanting it to move). A good mixture of opacity and availability must be found.

- Challenge for Technical support
Once users have changed their menu structure, it might become harder for the technical support to understand what they mean.

Initial menu structure
With a flexible menu-structure, every user could change the menu structure and create a good customized structure he/she likes best, regardless whether the initial structure is good, so-so, or even bad. Still, the initial menu structure is important:
The initial structure is what every user sees first and it gives a first impression of a program. Before changing a program's structure the user will have to understand the program and see what it is like and how it works and he/she must know that and how he/she can change the menu structure. With a not-so-good initial structure, all users will have to fiddle around and find a better/good personal structure. Power users might have less problems with customizing, given that they find the appropriate options and last not lest they are patient enough to do so.

Summary
I think that flexible menus are a good idea. They might even solve the issue of providing a light version of XnView easily. But some issues like the effort in programming for example must be clarified and taken into account, especially with the current situation of many other open issues, some of them quite important.

Regardless of the usage of hard-coded or flexible menus, the initial menu structure is very important and should be discussed and improved to have maximum quality (which means ease of use, fast access, and intuitivity).

I suggest to rename this topic to something like "Flexible menus" and start a new topic to discuss Wolfang's initial issue and question, the hard-coded menu structure, which one day might become the default menu structure for flexible menus.

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Better---

Post by Clo » Thu Jun 21, 2007 4:52 pm

—> helmut

• Hi !

• Such a speach sounds indeed much better, thank you.

• Here, I'll try to add more explanations, despite the most important points have been developed already here.
Flexible menu structure
With a flexible menu structure any user could change the menu structure to his/her needs. Menu items could be moved, renamed and/or even hidden. …
• This is the main advantage for the users. For Total Commander, advanced users provide alternative menus for those who don't know how to change a menu, although this is documented in the Help files for ages, and is not very complicated…
- Any level of change¦improvement can be done, from simply add a pop-up - that I do for the displayed items- up to totally different menus NC-like made by Petermad and very appreciated…
…- Effort
Currently, on the programmer's side (Pierre), the effort for such flexible menu is not that clear. There might be the chance of combining the introduction of the really important text based language files with flexible menus. Defining the text string used for a menu and defining the structure of the menu may be done with the same implemention, maybe not. …
• This is the main bone of contention, and it seems that the workaround we proposed making templates
has not been understood really… :|

¤ In brief :
- Pierre must have a kind of list of all existing internal commands. These commands are already partially available as names for the users about the addition of buttons in the tool-bars for the three display modes.
- Let's notice that this whole command-list might be available for the user (*.INC text-file),
and managed from an appropriate dialogue-box like I proposed HERE.
- It could be already useful for the buttons, then enhanced for the menus, or even for the short cuts too.
- One must keep in mind that all that is around the internal commands is the same three-spoke wheel :
Menus, buttons and keyboard short cuts. This way to consider the problem helps a lot…

• To build menus text-files, in both cases Pierre must define each command for each menu-item, anyway. Then, with a hard-coded structure, build a whole text-file “by hand” from the sources *.c files, in which each entry must be marked off with its command-name, since Pierre states that he changes the numbers continually
(don't ask me why…This is unusual in other programmes).
- With structured menus, same mess, plus the need to write the structure also by hand from the source-files,
according to the commands list.
- However, there is another cleverer way we used to build the final MNU structured file
that has to be released with the programme.
- Like I showed above as a simple example with an image, the final structured MNU file is very close of the menu which exists in the resources, say in the programme for the embedded English language, and in each language DLL…
- It's pretty easy to extract the whole menus scripts and to convert them into a final MNU file !
We done. No programming tool needed.
- We could do that again using the internal commands as names, hence Pierre could save a lot of hours…
- Menus written in that way are easy to translate into any language from a single original English template. It's easy to spot a menu, a main pop-up, a sub-menu pop-up and the menu-items belonging to every section…
…I think that flexible menus are a good idea. They might even solve the issue of providing a light version of XnView easily. But some issues like the effort in programming for example must be clarified and taken into account…
• That is obvious. I tried to explain above how the effort can be reduced, it's worth a try, IMHO.
…I suggest to rename this topic to something like "Flexible menus" and start a new topic to discuss Wolfang's initial issue and question, the hard-coded menu structure, which one day might become the default menu structure for flexible menus.
• Like you feel, nothing against.

:mrgreen: G.
Claude
Clo
Last edited by Clo on Fri Jun 22, 2007 1:48 am, edited 3 times in total.
Old user ON SELECTIVE STRIKE till further notice

User avatar
helmut
Posts: 8213
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Re: Better---

Post by helmut » Thu Jun 21, 2007 9:48 pm

Clo wrote:• Such a speach sounds indeed much better, thank you.
Thanks, sometimes it makes a difference if you think about things thoroughly. The more I think about those flexible menus, the more I think that it might be a good way to reduce the complexity of XnView. Providing 2-3 versions with different initial functionality has some charm. But this will need further discussions in the appropriate topics.

I'm pretty sure that Pierre would find a way to implement this, so I do not worry and care too much about implementation. My main concern is still that there are so many other things to do, some of them discussed and suggested many months ago: E.g. Improved Rotation, Pan&Zoom, Automatic White Balance, improved categories and ratings, Webtemplates with preview, unified file handling in batch dialogs, and many more. I hope that Pierre finds enough time to implement most of them in not too far future.

User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Post by JohnFredC » Tue Jun 26, 2007 6:06 pm

As Clo hints at, the biggest issue for the development of a user-defined menu system in XnView is the exposure of all internal XnView commands in the form of: function call, parameter(1), parameter(2), ..., parameter(n).

That this is a non-trivial matter is evidenced by the incomplete list of commands currently available for the XnView toolbar icons. If it was straight-forward for Pierre to do, wouldn't we already have ALL commands in the toolbar button definition list?

In retrospect, for my own applications, if I had started the design with such an architecture in mind (that is: exposed, standardized function calls), it would have made changing the control surfaces (menus, buttons, shortcuts, etc) so much easier. However, since in many cases I didn't, in my own apps the only approach that is not a radical re-architecting of the internal call structures themselves is an enormous If..Then..Else or Case..End Case structure with a large number of variant parameters and type-casting et al.

Not for the faint of heart.

Though I have been thinking about a record structure/lookup table approach that could be retrofitted with some effort.
John

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Three groups…

Post by Clo » Mon Jul 02, 2007 4:55 am

—> JohnFredC

:) Hello John !

• Sorry for the delay, but I had some health problems during this last fortnight…
…Though I have been thinking about a record structure/lookup table approach that could be retrofitted with some effort.
- It should be nice to see that you cogitated about that… :wink:
- All ideas are welcome.
- Like I said above, I drew a mock-up as a start to manage the internal commands.
- It's indeed a bit more complicated than in TC, since here we need three groups
(overlapping ones others, though) because the three display modes.
- I mean of course that some commands are not usable in some modes…
- Thank you for the thoughts you express here, it's still useful.

:mrgreen: KR
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice

Post Reply