I always found this surprising. Now, maybe I have an explanation. Please look at this thread :
In message #3, I give some information about the window hierarchy implemented by DPL. I think that those of you who are developers might be surprised, especially when comparing with Lightroom. I have the feeling that the DPL main window is actually a big dialog box.
I discovered these details by chance when trying to answer a question from user @Joaquin.
Well, it seems that I have an answer about the unusual behavior of the DPL UI (see my messages above). Quoting my last message in the thread related to the Alt+ underlined char. feature mentioned above :
After investigating a little more, it appears that the DPL UI is designed using XAML (that is, using the WPF technology). I won’t go into technical details that would be annoying for non developers but it’s somehow like if the UI was described in a markup language like HTML and then compiled. This design approach is very different from the “classical UI” development approach. It has its advantages and also its drawbacks.
Anyway, with such an UI, we cannot expect a behavior [exactly] similar to a “standard” UI.
I won’t argue against XAML but one of the drawbacks of this technology is that the UI is less “dynamically programmable” than in classical programming. This is equivalent to (but more sophisticated than) dynamically adapting an HTML page to the user actions. Which is obviously less flexible than the standard way of designing an UI.
So, when we request changes in the UI, I think that we should keep in mind that it’s not just a matter of modifying a dialog box resource and adapting a few lines of code.
Aha - So, that may explain why there’s so much reluctance (on DxO’s part) to address what often seems to me to be “quick & simple” UI fixes and improvements. Not that this should let them “off the hook”, but !
May also be no one there that can program in it now!
You can write very modern reactive UIs in WPF, I don’t think that is any stopping point.
Yes, certainly. But WPF/XAML and WinForms (the legacy way of designing UIs) are very different and it’s not really possible to mimic in WPF what can be done in WinForms and reversely.
It’s easy to find WPF versus WinForms comparisons and I do think that WPF is certainly a more modern approach. The question is “when should it be used ?”. WPF has support for data binding, portability, advanced graphical features, etc. But it has a steeper learning curve and takes more development time. It’s also difficult (or impossible) to dynamically modify at runtime what has been specified separately in XAML. Also, you can’t benefit from Windows native features like the Alt+underlined char. feature in menus and dialog boxes. I think that’s why many developers are reluctant to adopt WPF : it modifies “standard” behaviors to which users are accustomed. By the way, the following question regularly appears on the Web : “Is WPF dead ?”. It’s not but never was as successful as expected by Microsoft.
Another example is this one. Input focus issues in DPL have been regularly reported. Now I understand why.
WPF is more “universal” and less OS/platform dependent. It is supposed to facilitate portability. However, we already know that it was apparently impossible to obtain an identical UI in the Windows and Mac versions. And the differences are sometimes not minor. So far for the portability.
Well, it’s DxO’s choice and they won’t ever go back to WinForms anyway. But I’m wondering why they decided to use this technology, especially because they have limited development resources. It’s more complex and requires more development time and I don’t see where the advantages WPF brings are significantly useful in DPL.
Actually, it seems that we have here a situation similar to the one in Lightroom. A good part of Lightroom is written in LUA. It’s easier to code than C# or C++. OK. But when we are wondering why some very old bugs in LR have never been fixed, the answer is obvious : they just can’t. When a language is lacking the features allowing to easily spot a bug (which is the case in LUA : there’s no exception handling in this language), the developers will quickly give up.
Now I see, like John-M, that “quick and simple” fixes may imply much more efforts than expected just because of questionable initial design decisions.
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.