Been there, used it - such hard work. Have to write code in low level languages. UI looks almost but not quite. Would never touch it again.
one 'd prefer UI that “almost but not quite”, but delivers vs DxO deficiencies…
Another “Aha !” … This may explain DxO’s reluctance (or inability ?) to enable user-defined hot-keys - and/or - to provide additional hot-keys in response to ease-of-use requests (like this one).
That said, there are other design flaws in the gui. A pipette as a tool to change the color temperature should not be directly selectable but only via the color temperature function. And can only exist within that function. There are more examples like this.
George
Yes. See my suggestion above about how to get rid of the top toolbar in DPL (message #50).
I believe the problem is not only the design of the gui but also the way of programming. If the foundation had been object oriented programming this interface would never have existed.
A long time ago I once played with AutoCad. At that time that was also based on procedures and functions. I then bought TurboCad and that was OOP. What a difference and how easy to work with. AutoCad is also OOP now I believe.
George
As has been said many times PL really is in need of a full reprogram!
2 Likes
Object Oriented Programming is not a guarantee for good design “per se”. You can create terrible applications using OOP. OOP is supposed to be a way to abandon procedural programming more easily. It’s another way of thinking which has to be learned.
1 Like
No, it’s no quarantee for a good design. But it helps you think in a structural way.
George
1 Like
Don’t I know it! As a software design consultant it has been frightening to see how some developers can and do get it wrong.
Hmmm. I’m not sure if I totally agree with that. every function or procedure in a class is nothing more than procedural code. The difference is that code has been bundled together with the data it manages and helps avoid, what I think you are calling procedural code, where code somewhere calls data somewhere else, not necessarily correctly.
On one project, I discovered that the programming team had written seven blocks of code to do the same thing (calculate sales tax) but each code block did it differently 
I blame Microsoft ! 
… If only they’d adopted one specific app.dev paradigm and continually evolved it to handle new requirements - rather than chopping and changing, leaving devs dangling on abandoned paths … with no clear solution for anything.
1 Like
Yes let´s open our minds!
The only reason there has to be a global and local side in this application is because there still are so many limitations. When all tools can be used without limitations regardless if they would be used on the “background/base image” or “locally” there isn´t even any need for concepts like “Local” or “Global”.
I guess the reason Photolab looks as it does is because Lightroom once invented these concepts and user interface designs. DXO follows in Adobes foot steps as good as they can and Local Adjustments are just another way to say Adjustment Brush or whatever they might call it these days.
Please observe some finesse: If we have two sets of tools like in DPL7, each tool and its boxes and sliders can be made to work in global or local context - one context per toolset. If this is achieved (by fixing whatever feels broken), there is no need for a “master switch” that limits the tool scope to GA or LA.
This means that we have at least to ways of implementing GA and LA
- One set of tools and a GA-LA-switch (a UI element that the user operates)
- Two sets of tools with clearly defined (mutually exclusive) global or local scopes
Of course, we need masks for LA and we can use layers (or understand masks as such)…but the main thing is that the respective scopes can clearly (and easily) be held apart.
… Yes - - and, my view is that PL should have 2 completely separate “states” - being; LA mode -OR- Global mode … Not because it’s not possible for it to be “mode-less” (as PLv7 now is), but because;
-
Until this was changed in PLv7 - PL has operated with 2 completely separate modes, (switched via the BIG “Local Adjustments” button) - Therefore;
a) This is the way PL users are used to working (either in LA mode -OR- GA mode)
b) This the way many PL users assume PL is still working !!
c) Consequently, as per the title of this thread, the way that PLv7 is now working is confusing to many (most?) users. -
There is no practical benefit in it being possible to be in both modes at the same time … mainly because one needs to have the relevant mode-specific palettes/tool-panels available to work with … and they’re not, once one switches away from the LA-tab to a Global palette — And, therefore, there’s absolutely no point being in more than one mode at once … and it’s nothing other than confusing on finding LA-widgets active on the screen when none of their LA-sliders are reachable.
3 Likes
Splitting hairs here: We are never in both modes at the same time because we can’t push two sliders together at any time.
That being said,
I prefer to be able to use any slider, be it for GA or LA, without having to worry what the scope will be. This should be easily attainable (from a pov of logic rather than programming effort) if the current overlap of scopes can be removed by DxO.
Having to explicitely flip a switch is just an empty action…but it could save the dock from a plethora of duplicate tools. It coul also lead to other irritations, e.g. if one forgets to switch modes before pushing sliders.
I respectfully disagree, you still need to select a LA mask to act upon or deselect all masks to act globally.
I still prefer the PL6 LA button which means you know which mode you are in and you don’t have to go and deselect LA masks to exit LA mode!
1 Like
And that’s precisely my point … In which case, there’s no point in PLv7 being “modeless”.
The simplest way around this would be for the LA-Tab (this control: 
) to act to switch LA-mode ON/OFF … which is what most users assume it’s doing now anyway.
1 Like
…but do we need/want a mode switch for explicit mode switching…or could we do with implicit mode switching based on whether we move a GA or LA slider?
If we’ll get an explicit mode switch, I’d strongly propose to get rid of the second set of tools for LA and simply filter the view accordingly…but get a keyboard shortcut to switch modes.
Let’s see if we can clearly show the differences between possible implementations from a user point of view. It’s about how we operate the thing, not its innards and programming, which are completely and exclusively DxO’s responsibility. I put this in attn. of @StevenL who might be interested in this user perspective (I hope he is).
Explicit Mode Switching (new paradigm)
- The BRUSH view filter button shall act as THE mode switch and as a filter that shows LA tools with their respective functionality only.
- There shall be only ONE set of tools, the scope of which depend on how the BRUSH switch is set.
- The user shall enter and leave LA mode by clicking on the BRUSH switch.
- The BRUSH switch shall have a different colour when active in order to highlight the mode and scope of the tools and to reduce the risk of users getting confused in which mode the tools are used.
Implicit Mode Switching (current paradigm)
- The BRUSH view filter button shall act as a filter that shows LA tools with their respective functionality only.
- There shall be TWO set of tools, the scope of which depend on which set is used.
- The user shall enter and leave LA mode by using the respective tool(s).
- The tools shall have a different colour badge (or separate palette) in order to highlight the mode and scope of the tools and to reduce the risk of users getting confused in which mode the tools are used.
Added Value
- If we/DxO start from implicit switching, but make the BRUSH button filter to show either GA or LA tools, we’re pretty much in explicit mode switching…and we/DxO could therefore get/provide a choice in DPL’s settings for the user to decide to use either of the two modes. At a later stage, the second set of tools could be removed in order to reduce development and maintenance effort…without having to remove the mode switch selection setting.
Anyways, the current mode mess needs to be fixed soon.
3 Likes
Am I correct to understand you mean (in Window’s “Controls” terms) the LA-Tab ?
- That is, this thing … … It’s a “Tab” (which functions to display a specific list of tools/sliders … in this case, specific to LA-mode)
Right ? … Just to get our terminology straight, to avoid confusion.
No argument on this at all … I don’t believe anyone is defending the status quo - Are they (?)