Yes, I’m “pushing ahead” too … but I am encountering a number of obstacles … esp. in the case of PLv6 features that didn’t make it into PLv7 — That is, dreaded regression !!!
Intrigued - of what do you talk?
Or are you referring to things like the incomplete DAM from PL5?
Crucial functionality (now missing in PLv7) such as this …
For more discussion on functional deficiencies of the new LA UI, see here …
Let’s have a look at Lightroom, just to try to determine what makes the difference between confusion and clarity + consistency :
-
In Lightroom, we don’t have any top toolbar.
-
In the Develop module right pane we have a very simple toolbar with only 5 icons : Edit, Crop, Healing, Red Eyes, Masking (that is, local adjustments). In DPL, the first 4 icons are replaced with icons allowing to access a view of the global settings that is different from the view that we have when the LA button is deactivated. IMHO, this view is useless for several reasons :
- all setting sections are expanded by default
- no solo mode
- sections cannot be easily distinguished from each other because for each section, title and contents have the same background color. In LR, the palette title bar is immediately visible : title text is right justified, font size is bigger, background color is different from the one of the palette contents.
-
Whatever the icon has been clicked in the right pane top toolbar, we always have access to all global settings palettes. Since there’s a solo mode (key point), this doesn’t necessarily occupies much room. Palettes are grouping settings by theme. They are not expanded by default and Solo mode provides for less cluttering.
-
When one of the 5 icons is activated, the corresponding settings are displayed immediately under the toolbar. The corresponding options are displayed at the bottom of the viewer window. In Masking mode, the settings are organized in sub sections and solo mode is also available there.
-
In LR, the View options are located in the left pane because they apply to both Library and Develop mode. However, they don’t need to be in the same toolbar as the other tools. Assuming they have been removed from the top toolbar in DPL, one can then see that the remaining tool icons could also been cleaned up : we don’t necessarily need to have the WB, Horizon and Perspective tools there (why should it be assumed that we are using these tools more often than others ?). If they were also removed from the top toolbar, it would be possible to do the same as in LR : moving the remaining icons to the simple toolbar at the top of the right pane where they could replace the useless “theme icons”. No more top toolbar. By the way, personally, I don’t see any use for the Favorites feature either.
-
The Mask Management window is handled the same way in LR and DPL.
So far for the key points.
So, basically the models are not fundamentally different. But the LR model is much lighter, clearer and simpler. At every moment the user knows what it is doing by simply looking at the UI. I think that things could be, as a first step, quickly enhanced in DPL if DxO Labs could eventually accept, after all these years, the idea that Solo mode at all levels is more important than they think and that putting some attention to a few graphical details could make the whole UI more readable.
My two cents…
1 Like
The dropper on the toolbar is direct related to the white balance. Why is it there on the toolbar??
Different perspective functions are in the toolbar and taken a lot of space. For what use? I only use it once on an image. It was said in the past they would be collected in a drop down box. Not yet.
An info that I use often is the zoom info. On a small screen,laptop, this is one of the first elements to disappear and collected in a drop down box.
George
1 Like
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.
2 Likes
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.
1 Like
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