Messages

Looking for an 'execute' icon for the center column.

The lightning icon looks like it has something to do about flash and/or I'll fry my camera with high voltage :-p ... wolf's version is more neutral, though not 100% intuitive. Aren't there any internationally acknowledged symbols for "start" or "on" like the power on symbol on just about any hifi equipment? http://www.clker.com/cliparts/d/9/0/3/1245640607507785093Soeb_Power_symbol.svg.hi.png

It's very hard in this phase because people are evaluating fragments in isolation, and drops that do not necessarily use the proposals as intended, have not yet implemented them or might not implement them.

Lots of it might be a moving target, but at the same time I guess some input from people using the current trunk might still be valuable - or you might be faced with more disappointment when it's a "do or die" proposal. And my only issue with the current junkie menu implementation is really only the green color for the setting tiles, otherwise I consider it near perfect (though I wouldn't be surprised if you've got some other ideas :-)).

The "normal" menu system is rather more complex and it's great you're trying to figure out a consistent approach for all the different ideas implemented in ml, hopefully without loosing the "toolbox" spirit - after all, it is assembled of various different ideas of different people, and it will continue to be a non-monolithic "bottom-up" product.

I'm glad people are seeing progress, but there's so much more that can be done. I know it can be much better and if we get there we'll be hearing more like scrax's "I found out thing that were not so clear to me even if I'm along time user". (thx scrax.)

At the same time, I hope you don't hear too many "But it's gotten dumbed down!" exclaims, but I'm positive it's on the right track at the moment - thanks for all your work!

I'm agreeing with you. The only question, which is debatable, is whether items that access ON things should show ON so that you know they are there.

I don't understand what items you're talking about exactly - could you give some examples? The items I don't think should be colored bright green (since they are settings and not on/off-switchable) are submenu items in "My Menu" plus mainmenu items like iso, aperture, picstyle, ... and imho in most cases it doesn't matters at all what "default" the ml devs happen to choose, so that's not a good basis for coloring the item. My suggestion is still to give these another color like medium green, that makes four background colors (1x grey + 2x green + 1x tba - how about black bg?) and should be under the confusion threshold.

But I'd also like other's opinions on that, it's great the ui is progressing at great speed but probably it's a good idea to isolate some "debatable" points in a list and then wait for ml users that don't visit the thread on a hourly basis.

The system of colors is a language (or should be). It should apply to both so that what you learn from one applies to the other. This is my goal anyway.

Sure, I was just notifying you that I my comments only concerned the junkie menu and I didn't have a look at the recent icons at all.

In your example, 'EV increment' communicates bogus state through its ON/OFF green LED, and your confusion is a breakdown. But I don't think having no LED would create confusion. No LED and normal enabled tile color is what I recommend.

I recon you're very in depth with design, but if you arrive passing various theoretical stages at a proposal that creates confusion with simple /me, I dare to skip the whole process where you basically lost me (sorry) and still comment that bright green in junkie menu for non-on/off-switchable items is not helpful. I don't want to start with GNOME3 loosing their users again, but if is like real world shooting problems ("can I switch this on or off, or is it a setting?") interfere with design it's nearly like you're only talking to yourself here :-o

Edit: not to be misunderstood, now that we're beyond full screen submenus :-> I think most recent changes are great and will widen the ml userbase, but imho feedback from user experience now and further down the road has to be evaluated unbiased by a design philosophy but by the result for the final stage: shooting pictures and videos and not necessarily winning the "design of the year" award, though the latter would be a nice extra.

I promote seeing green has representing non-default state.

I'm just talking about background colors in junkie mode here, not about icons. The default/non default state difference isn't my perception when úsing it. As a plain and simple ml user my I see that grey represents "disabled, but can be enabled", dark green "enabled but not active" (probably because lv only) and bright green "enabled and active".

* Tile type like "Save Config now" cannot be enabled, just triggered an imho doesn't qualify as either of these three former types - so another color (medium green or something completely else) makes sense to me.

* For tile types from submenus like "ev increment" that just trigger a setting menu it doesn't matter what the "default state" is (1ev? 2ev? who cares), it just should be clear that this neither enabled (green) nor disabled (grey) but simply a configurable tile - so the current bright green color is very confusing to me - another color would clear that up. This is for example also the case for items from the mainmenus like expo menu iso, aperture, picstyle, ...

Optimization suggestion for junkie mode: If putting submenu items in "My Menu" they appear with bright green brackground, though they cannot be enabled or disabled but only triggered (like "Save Config now") or modified (like bracketing frames/step/type) -> imho these two tile types should have another background color altogether, maybe something between the dark and bright green.

In the case of explaining what must be turned on for a feature to work, I don't see why you characterize it as a 'warning'. There is no pending harm or trouble, just information explaining dependent relationships between features.

I agree with that, green is ok for purely informational messages that the user can ignore since it won't do any harm or it'll obvious sooner or later (like things only working in lv).

Yellow should be reserved for information/warnings that could harm your next shot (like i.e. my recent confusion about bracketing only going to max. 30s shutter in non-m mode, the understated ml warning message is "This feature works best in Manual (M) mode") and red when something is about to critically wrong during shooting/video.

... that's how Canon firmware works.

Yes, I understand that now - I just assumed that *ML* bracketing automatically works around that problem just as it is able to do bulb timing. But if I was the only one with this knowledge gap and everybody else has worked it out I'm fine :-)

Can we have an option to use Q for increase and avoid pickboxes, sort of legacy mode?

I can understand this with a Rebel-style camera, but with a back wheel like on 60d I happen to really like the changed navigation set -> wheel -> set, just two bugs:

* play *decreases* the values like with bracketing frames, the more intuitive way would to *increase* them

* for some menus there is a dropdown (like bracketing frames), for other with more there isn't (like bracketing increment). It would be really nice to have the dropdown for all options even if there are too many to fit on the screen, but in these cases the dropdown values should scoll up/down so it is immediately visible what the next & previous options are.

In Av mode it won't go past 30 seconds, try M.

Ok, thanks - though I think this information deserves a big red warning in the help menu since the changed aperture is hard to spot when shooting.

Sounds like a bug, was in M mode? if so, how to reproduce?

It was Av mode with 0+-+- bracketing, 1ev steps, 7 frames, shot with f8 - the +1 frame was 30sec @f8, and then the +2 & +3 frames were also 30sec but with 1 and 2 stop larger apertures resulting in a sharpness loss & changed dof.

I only discovered this yesterday when doing night-time shots - when doing a bracket 0+-+- or 0++ when the slower frames are more than 30s, the camera automatically opens up the aperture to still reach 30s which the bad effect on sharpness and ability to merge frames because of different dof.

Ml can do bulb timing, so it'd be great if the slower brackets could still be shot with a smaller aperture, but more than 30s shutter speed? That would also be a distinct advantage over Canon bracketing.

Mask underlying menu completely.

What I like about the current opaque approach that most of the background is kept, so only information is added/subtracted and when the submenu disappears I know right where to read on. This basically is a modified reasoning like with full screen submenus, but the new "hide background" is a bit more agreeable since the menu bar is kept in place.

If I'm the only one with this perception please do implement it, but personally the "clean" argument is not sufficient for me, "clean" to what effect exactly? Is the opaque background just in the way of a specific idea about how design should be, or how does the opaque background hinder ml's usability - because this time there are no added benefits like more space. If the idea that the background is confusing, it's exactly the reverse of what I perceive.

Polish/simplify: Consider hiding Movie and Audio tabs when not in Movie mode - both regular and junkie modes.

Generally I'm in favor (<- please not this :-)) of your idea but see three problems:

* I recently discovered that "Audio Remote Shot" in is depending on the Audio stuff (Wind Filter, Mic Power...), and it's helpful to see the audio meters to have an idea of the trigger level vs. the background level, i.e. the danger of accidental release.

* The Movie menu has "Creative Effects" in it that is helpful for lv mode & manual focusing (focus peaking is easier with desaturate to b/w), actually that's the only item I have left in this menu

* People might want to leisurely change movie settings before going to movie mode because once in movie mode (at least on my 60d) the mirror flips instantly up, drawing battery power. Sure you can turn off lv again, but it's a hassle.

I hope these concerns can be worked out, esp. since I'm never doing a/v and even disabled these features in the binary.

Polish/simplify: Only one menu customization mode. When in the mode, pressing SET rotates through displaying no icon (normal), <star> (MyMenu), and "X" (hidden). This essentially gives you three levels of importance.

I nearly wrote the same thing as a feature request, but didn't for a reason - so I have to be Mr. Killjoy again: Currently I have some (sub)menu items in "My Menu", but hid them in the original location to avoid duplication. I rather like this possibility, so if at all I'd suggest *four* modes: none/star/hidden/both(star+hidden), the latter with a new icon or both icons next to each other. I know this is not exactly intuitive to newbies (here we go...) but personally I'd rather keep the current trunk system than loose this functionality.

[ML Junkie]

ML Junkie

This is absolutely terrific, thanks! And I have to mention junkie is very fast and mode looks great with traditional submenus :->

For example for Marsu42 he can close Junkie menu with ExpoLock selected and during shooting pressing Trash and then play will toggle it each time.

Yup, at least that's a 2-click solution - though as in the feature request quick access keys for different features and a confirmation would enable keeping the eye to the vf, the junkie mode is a (very welcomed) shortcut when looking at the display.

Interesting - but it is something rather different from the current focus stacking for extended dof and sharpness, it's more like "multishot af". The current code is very targeted at stack/rack focus, I don't think your idea is trivial to add to this.

Adding a new menu/submenu "multishot af" for your idea might be more appropriate, with items set points/reset/play - but reordering a list afaik isn't included in the current ui. But simply coding a record/play list of af positions should be doable.

The question is how many people would use this and thus how high the priority should be. Maybe you could further elaborate potential usage scenarios for other users to generate interest for this idea.

It will be useful, in some situations, to have more than two focus points in focus stacking. A user-defined numbers of focus points would be perfect, along with a user-defined sequence to follow (for example: 1-2-3-2-1 or 1-4-2-3-1-2 and so on)

I'm curious: what situations are you talking about?

I appreciate your candor and I agree - that language is a turn-off. I don't know how else to say it besides how I did earlier in the thread.

:-) and thanks in return for saying that - I would expect you to be rather sincere for improving ml or you wouldn't put as much work in it. I do hope we'll find a mutual acceptable approach w/o too much code complexity, though it's inevitable some decisions have to be taken - but afaik this is no time-critical matter and no need to rush, more people might want to try the latest trunk ui and suggest improvements that might very well meet yours.

I do wish that people would consider that they might not object to something in practice as much as they think they will. This can only be determined if they try. Why should they? Because the the benefits I'm trying to promote. The current approach closes doors, and I think unnecessarily.

I think one way to keep everyone happy is to implement a more beginner-friendly ui  - and I very much appreciate beginner's input, it's of course true that long-term ml usage creates some bias though I hope I can reflect it. But at the same time more direct access to critical features has to be added, "My Menu" is a first approach and more key shortcuts outside lv (I hope that's possible) to prevent clicking through menus if under stress while shooting.

I'm not following your point here. I don't disagree with the desire for one-handed operation. Again my confusion is how right-hand use of submenus is being to highly prioritzed when people also argue that submenus are "set and forget".

That's a misunderstanding - imho people (including me) think that *some* submenus are set & forget, but others certainly aren't like bracketing which I change all the time. This is is a bit eased because I could put the vital submenu items in "My Menu", but during the colder season (in Berlin about half of the year ) I usually wear gloves - a complete thick glove on the left, and one with fingers cut off on the right. That's why I like right-hand navigation so much, in other situations it's nice, but not essential.

With respect to 60D, I truly don't understand your point regarding one-handed operation, because all the buttons in my proposal are on the right side on that camera. I do want to understand.

Doh, sorry, you're correct and I was confused by your 600d mockup - on 60d/6d there's really no problem with your proposal for me personally. I can understand others with the Rebels though, but now no argument against 3rd level submenus from me :->

canon info screens let you change it too.

I know, same on 60d - but it's not very accessible and "Rebel"-Style", changing the custom wb is a pita.

shortcut keys work for wb on 6D. 

... I don't really like the current shortcut keys implementation (if I get them to work at all). I'm talking about non-lv shooting mode here. Have you ever used a 5d3? That's the speed it should be on all cameras, but with ml support instead of Canon. That's why I like scrax' idea (see above) - I'd imagine it like this:

Press LV (or probably DOF), and to change three functions you can pre-select in the ml menu (like "My Menu" select/hide) by using either left/right, up/down or the back wheel. To have a feedback about what you're changing the value(s) should be printed on the screen, or for binary values there should be the option for an on/off beep to be able to keep the eye to the viewfinder. If you're finished press SET, or LV (or DOF) again to trigger the function originally assigned to that key.

I know that is possible to use makefile.user to define features, maybe there is a way to undef them too from there, but I don't know it.
Since we define a function with -DFUNCTION maybe -UFUNCTION undef it?

Yes and no - there is a gcc -U function, but it fails if the macro is #define'd in the source code. So the only solutions are either to #include a user_features.h from features.h (my suggestion, by far the easiest) or wrap all #define statements in features.h/all_features.h into another macro, for example:

#ifndef SKIP_FEATURE_SNAP_SIM
#define FEATURE_SNAP_SIM
#endif

This is obvious and most probably left out because of time constraints - but it woudl be nice if there would be an option to re-order the items in the ml "My Menu" just like in the Canon one.

Otherwise great work, I'm very happy with this feature - now all we need is quick button access to features like scrax is developing, and it'll be a major usability improvement!

The big problem is that you can't get focal length updates outside LiveView.

Doh, I didn't realize that, it really just shows the lens description so extracting the focal length (range) would be a hassle.

In this case I'd suggest to go for plan b: in the handheld mlu menu split the the static 1/2...1/125 option into two configurable settings with upper and lower shutter limits, plain and simple.

With the current code I press iso then play and can toggle without removing the eye from eyefinder ALO, with < then PLAY I toggle metering mode, once learned all those shortcut can be used without watching the menu. That's not as simple as a button switch but gives a lot more flexibility.

My idea is to put a selectable list of ml item in DriveDialog and use up/down arrrow to select what to toggle and LV button to activate it. So you can have set Expo lock before shooting and < then LV will toggle ExpoLock without leaving the eye from viewfinder

Sounds absolutely terrific and flexible, I really hope you can add this!

The only addition I'd like to suggest an on/off feedback for things that aren't visible in the viewfinder or top lcd - for example for expo lock you only recognize if it's on or off after changing something. My suggestions:

* beep for on (when having the eye to the viewfinder)
* big message on the display ("Expo Lock ON" or "WB set to xxxx").

This of course on a rebel like camera layout, for the pro wheeled camera I need suggestion eventually.

With the 60d and 6d this should also be ok, that leaves the 5dc/5d2/5d3 - in these cases the joystick should replace the directional keys.

As for the back wheel: This would be great if used for non-binary options like white balance, if you manage to add lv+back wheel for changing this you'd fix a major problem with the 6d in comparison to the 5d3 - on 5d3 you can access wb through buttons, on the 6d you have to use the menu.

What is the whole thing? I have no c-mode on 600d so don't know how canon works

Ups, sorry - the Canon C mode(s) save just about everything selectable from the Canon menu, from lcd brightness for custom functions. This is often overkill, but the safest way to adopt to different shooting situations quickly requiring different settings like mlu/htp/af modes/... except the setting list in your link.

So I'd either vote for full-fledged custom modes, saving everything just like Canon does, or I'd have some items I'd like to add to the list of settings saved/restored...

You can #undef every single feature, look in features.h and all_features.h.

Doh, I had no idea there already is such a fine-grained structure since I never had a look at all_features.h - great work, thanks!

One other request though - would it be possible to #include some (empty) user_features.h after the platform features.h so I don't have to modify the features.h, causing potential merge collision when updating? No problem if I'm the only one potentially using it :-) but I recently had such a merge collision with features.h