It should be noted that WPF has transitioned to a community-run project and has been rather recently handed off to IDC (Microsoft’s India Developer Center). So, not dead but say, semiretired.
I have not been accurate enough : XAML is portable, WPF is Windows only.
I was involved as consultant/architect on a major Windows app, back in the days of WindowsXP. I believe they used WinForms, as it was in the early days of the .NET framework.
Fortunately, my main responsibility was to design and implement the object model using OOAD techniques, which meant that all the calculation and logic was coded in separate classes that were totally non-visual. Then the UX team would create forms and the visual components to display or allow interaction with the business logic that I had created.
WinForms was not always easy but WPF was a complete nightmare to make changes to as so much had to be changed on form code rather than visually.
Whereas, using Xcode for Mac development is a whole different game because dynamic UI layouts can be defined visually and are easily changed.
Nonetheless, one thing that can be created in common to both platforms is the “business model”, with the proviso that it is written in something as basic as C++, which then precludes using certain development frameworks that are exclusive to one platform or another.
There are a couple of development tools that claim to be “write once, deploy everywhere” but, having seen the results, they are like using a UX that is neither one nor the other and feels “sort of”, “almost”, “not quite” like the platform that it is being run on. Things like the OK/Cancel buttons being in the wrong order on one platform, which is more annoying than you can dream. Not forgetting keyboard modifier keys that are different and Mac doesn’t use “underlines” for keys but does provide “alternate” actions for the same key, dependent on the modifier key used.
All in all, developing a single code base for multiple platforms is something that you don’t want to be doing and, fortunately, DxO realise this. unfortunately, this can mean divergence between platforms and having to write code which satisfies the lowest common denominator, rather than being able to take advantage of those features on the more sophisticated platform.
I, for one, can appreciate the hard work that DxO has to do but… this LA/Global UX isn’t even comprehensible on either platform.
I get a feeling that it may be necessary to wait for the rest of the LA functionality to be completed, possibly in PL8, but the problem being that folks are being turned off the PL7 version and either jumping ship or, at least staying with PL6 or earlier.
But, XAML is not portable to Mac without third party tools that have to be licensed and, as I have said before, working in XAML is so much harder than Apple’s native development environment. Cross platform here means desktop or mobile within the Windows ecosystem.
Qt ( Qt Products | Design, Develop, & Deploy Cross-platform Apps ) → FastRawViewer for example uses it for both Windows and OSX
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!
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.
No, it’s no quarantee for a good design. But it helps you think in a structural way.
George
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.
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
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.
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!
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.