Desperate call for Solo Mode

I don’t think so. There are 2 buttons at the top right of the right tab in Customize mode :

The Favorites Corrections button (star) button displays all the palettes that you have marked as favorites by clicking the star in the palette’s title bar. If you didn’t specify any favorite and click on that button, the right tab becomes empty.

The Active Corrections button displays only the palettes in which a setting value is different from the default. If you didn’t change any setting and click on that button, the right tab becomes empty.

Although these features are interesting, they have absolutely nothing to do with the Solo Mode found in other similar programs. The Solo Mode allows to automatically close all other palettes in the tab when you open one. IMHO this should be the third button displayed along with the 2 buttons described above. This would make the display less cluttered and distracting.and would allow to focus on the current palette and on the image currently processed. Ideally, a keyboard shortcut should assigned to each of these 3 buttons.

Another remark about the design of the palettes in the right tab :

When all palettes are opened, it’s rather difficult to distinguish between them. The title bar of an inactive palette can barely be distinguished from its contents. In that case, the enable/disable button at the left of the palette title bar is almost invisible and the title bar background is exactly of the same color as the palette’s background. Big mistake. So, there’s no visible transition between inactive palettes which also adds to the clutter and generates confusion. Another justification for the solo mode.

I’m repeating this since years : DxO need a software engineer specializing in UI development. That’s so obvious.

My hack to enable some sort of a Solo Mode on Mac:

  • collapse all palettes
  • command+click on a palette’s name. This opens it while closing the previous one.



Thanks Ian. Unfortunately, this doesn’t seem to work in the Windows version.

That’s weird.
This is my starting environment (Windows).
Some pallets are closed !


1 Like

Seing your image, it seems undocked palettes are allowed to be closed.

1 Like

Undocked or not, my pallets remain in the same state at the opening.

I think you’re confusing the issue a bit with your mention of favorite and active corrections. If you don’t activate either, the Smart Workspace buttons work very similarly to Solo mode. The main problem, unfortunately, is that collapsing any of the sub palettes is not maintained between editing sessions, a separate issue I’ve been mentioning for years. In any case, I prefer less clutter than the standard palettes create and primarily use the smart workspace buttons instead.


Hi Mark,

Sorry but unless I’m missing something obvious, I don’t see what the Smart Workspace buttons have to do with Solo Mode. And no, even if the Favorites Corrections and Active corrections are disabled (the Smart Workspace buttons), there’s nothing available that looks like Solo Mode. I don’t think that I have added confusion to the topic. I have just shown the inconsistency of the UI design.

Once you have opened several palettes, they will all stay opened and there’s no way to automatically close everything except the one you have just opened by clicking on its title bar. And, as you mentioned, you cannot rely on DPL saving the current state of the workspace including the open/closed state of each palette and retrieve it upon relaunch. It cannot even remember the current mode (Library or Customize) it was in when quitting.

I’m not saying that the Favorites Corrections and Active corrections filter buttons are useless but this has from far nothing to do with Solo Mode. I don’t know if you have ever used Lightroom. If not, please have a look at this video and tell me what in DPL can be considered as similar to this behavior.

I don’t think that’s an assumption you can make unless you’re privy to DxO’s code base. It seems simple and should be simple, but we cannot know if it is simple.

Evidence: I work in IT, have written and maintained software for many years, and have numerous times been surprised how some “simple” tasks are, in fact, not.

I created a workspace that is primarily designed around putting all the palettes I want on the screen with limited scrolling.

I support this request, I just don’t support justifying it with such heavy-handed language. If I was asking, I’d explain the benefits, not why the people who don’t build it are wrong.

I don’t use any of the standard development palettes, only the Smart Workspace buttons. I like to keep the interface simple and clean. In my attachment you can see the palettes I do use and how my entire screen is configured without any of the Smart Workspace buttons selected.

Just using the Smart Workspace button palettes for development works very similarly to Solo mode. It only shows the selected button palette. Long ago I used a combination of standard and custom palettes but eventually decided it was too cluttering. I quickly got accustomed to the Smart buttons and have never looked back.



The DPL UI has been developed using the Microsoft .Net framework. I have been teaching and using this technology for years. I have also been a Microsoft Development MVP for years and have been invited to Redmond in the MS labs where the .Net technology was developed to discuss some critical points in the development environment (this was why the MVP status was invented : getting feedback from external professionals). I also had permanent contacts with the french team. Just to say that I’m not talking to the air. So, I know this framework well and I’m pretty confident that implementing the Solo mode is simple, easy and can be done quickly. Actually, the code for opening/closing palettes is already there. The only additional code that is needed is to add the new “Solo mode” toggle and decide which events will trigger the close/open routine. Not a big deal.

However, there might inhibitors :

  • A lack of resources at DxO (although this feature doesn’t need much time and knowledge to be implemented)
  • A design mistake that prevents the feature from being implemented without changing a lot of things in the UI code.

If one of these assumptions applies, that would be the second one, I suspect. There are other indications that the UI design has not been very well thought out. For example, one might wonder why the mere idea of workspace only applies to the Customize mode. Strange idea. What prevents it to also apply to the Library mode ? I have always wondered about this surprising choice. Why are they unable to implement a full recording of the application’s UI state when quitting ?

If I’m correct, both assumptions are much more bothering than the lack of a Solo mode when thinking about the product’s future. This would explain why obvious enhancements requested since years are still waiting to be implemented. I’m not doing DPL bashing. This is a very good product. I need it and I recommend it. Just, there’s obviously a problem with the UI and they don’t seem to have the necessary resources to fix it. Why bother if one can get good processing results anyway ? They should not forget that the UI is the first feature that a new user sees and uses. People coming from LR, Capture One or other similar products may wonder why features available in all these environments could not be implemented in DPL. This is not something that will encourage the adoption of the product.

As for the “heavy-handed” language, let me tell you something. I’m a DxO customer since they are on the software market. I have also been a beta tester for a while. I have promoted their products everywhere I could. I have taken the time to report and explain why their implementation of some features (and by the way, their technical documentation) was… surprising, to say the least. So, after all these years, these obvious design quirks are still there, waiting to be fixed and this is irritating. So am I, irritated. I have not been impolite nor aggressive. But if they can’t implement features that are requested/expected by many users (12 votes within a few days for a multiple times repeated request, which is not common), they have to explain why.

And I’ve seen more than enough bad code written in good tools/languages to know it’s possible to ruin anything.

Aaand here I stopped reading. It’s right there in the second clause. Unfollowing this thread.

I think the most needed thing in this area (the most, but not the only one at all) is the ability to put the main window (the one showing the edited photo in customize mode) alone on one screen and all the pallets and anyting else on a second screen : the ability to work on an image seing it full screen.
Being able to see as much details as possible when working seems an evidence to me.
Not being able to do so is an aberration; but this is anyway consistent with noise reduction preview window size (outdated).

Agreed. Please see this request from 2018 (the original request is even older than 2018) :

Of course this would be even better if DPL could fully record the UI state when quitting and restore it upon relaunch.

You mean like this?

1 Like

Yes. I know that.
But you have to undock all palets and this is not as handy and organized than what should provide a modern interface.

1 Like

And edition window isn’t full screen.

If it hadn’t been for the screenshots in this thread, I would never have used a user palette. I started off always using the filter buttons (light, colour etc.) and got used to it so I almost always had one on.

I’ve had several empty user palettes for months - I did not realise the filter buttons have to be off to see them :roll_eyes:

@Pat91 is it not possible for someone with your dev knowledge to create a UI that basically works on top of PL’s UI (i.e. “remote controlling” PL through a custom UI?)

:slight_smile: Interesting and subversive idea but this would imply a few prerequisites :

  • A documented programming interface, that is, entry points allowing to an external module to interact with DPL. Remember, you can’t even develop a plugin for DPL. There is no (known) SDK (software development kit) for DPL.

  • A (team of) developer(s) wanting to spend a lot of time developing this new interface.

Don’t even dream of this. But a SDK would certainly be welcome. A well thought out SDK would certainly allow to develop a plugin implementing Solo mode, for example. But developing a SDK for DPL “after the fact” will be difficult. Such features must be anticipated in the initial design. For example, Lightroom has had a SDK from the very begining and missing features have been implemented by external authors. Soft proofing is a good example : we had a soft proofing plugin in Lightroom long before Adobe implemented it in the product itself.

Adding a SDK to a product is a good way to allow external developers to add features that the in-house development team doesn’t want or can’t develop due to lack of resources. Photoshop, Lightroom, Capture One… have a SDK. DPL doesn’t and I’m not sure this will be made available very soon.

This reminds me an old now dead software for which users created this kind of stuffes to organise interface because it was not as efficient as needed, and shared them onthe web.
But this was about 15, 20 years ago …