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.
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).
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
@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?)
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 …
Photolab v8 News - #78 by Joanna, which shows this functionality has been present since PL4 for palette title bars and PL5 since PL5 for tool title bars
If you open a new palette, your first have to “Collapse All” to cleanup the real estate in the tab. Solo Mode does that for you. Since it is an option, everyone can select the preferred behavior.
Even if you cautiously close all palettes in all tabs by using “Collapse all” and take care of closing everything else manually each time you open a new palette a new palette, you’ll have to redo everything after relaunching DPL : all palettes (except the last used one) will be opened again in all tabs because DPL is still unable to remember its state over sessions. So, even if you cautiously apply point #1, the messy tab layout will be quickly back.
This is inconsistent
Once again, the minimum that could be done is at least to give the palette’s title a different background color than the palette contents background. This very little and easy change would make the whole tab’s contents much more readable. But the very strange and unusual underlying window structure of the main window and of both left and right tabs makes me think that even this very simple change could be a problem.
As I already mentioned, this strange window structure can be easily observed by using any window explorer like Windows Spy or Windows Detective.
Interesting and subversive idea but this would imply a few prerequisites :