Jump to content
Samoreen

AP for Windows - Saving workspace

Recommended Posts

18 hours ago, Samoreen said:

one or two hours of coding and testing would be enough to implement a native solution.

When the Devs start spending just one or two hours of coding and testing on a feature like this is when I'll stop using the Affinity products as there will be way too many bugs with them.


Due to the fact that Boris Johnson is now our Prime Minister, punctuation, spelling and grammar will never be worried about ever again.  We now have far bigger problems to be concerned about.

Share this post


Link to post
Share on other sites
1 minute ago, carl123 said:

When the Devs start spending just one or two hours of coding and testing on a feature like this is when I'll stop using the Affinity products as there will be way too many bugs with it.

Actually, one or two hours are more than sufficient. As I explained somewhere else, the code for saving and loading a workspace already exists in the program and, with exception of a few glitches, it works. So the only code that has to be added is 1) a workspace naming procedure and 2) small changes to how and where the workspaces are stored. Nothing more. This can be done by a summer student.


--Patrick

Share this post


Link to post
Share on other sites
7 hours ago, Samoreen said:

Actually, one or two hours are more than sufficient. As I explained somewhere else, the code for saving and loading a workspace already exists in the program and, with exception of a few glitches, it works. So the only code that has to be added is 1) a workspace naming procedure and 2) small changes to how and where the workspaces are stored. Nothing more. This can be done by a summer student.

Sorry, what? How are you drawing that conclusion?


I like turtles!

Windows 10

Pentax K3 and K3-ii

Sony RX10 Mkiii

Canon G5x

Share this post


Link to post
Share on other sites
8 hours ago, Samoreen said:

Actually, one or two hours are more than sufficient. 

Nothing takes one or two hours if it's done properly. I've just spent all night working on a tiny form interface, and that's not even starting coding. Switching the workspace data is gonna be easy as they already have it saved in a separate file by the sound of it, but you then have to refresh the display to change to the new layout and reorganise any open documents, deciding how to treat floating windows to fit any change in available space, whether to zoom or crop tabbed documents etc. You also have to decide on a palette-by-palette basis whether to preserve any working changes, such as the currently loaded colour palettes or brush files, or to revert to specific sets as saved with the workspace definitions.  It's not a massive task, I agree, but everything takes time - and you need to spend more time testing it than you do coding it.

Share this post


Link to post
Share on other sites
8 hours ago, Samoreen said:

So the only code that has to be added is 1) a workspace naming procedure and 2) small changes to how and where the workspaces are stored. Nothing more.

Other things you don't seem to have considered:

  1. A command or panel in the UI for the user to save them, with a user-chosen name and possibly a user-chosen location.
  2. Translation for all of that.
  3. Possible differences needed for Mac, Windows, and iPadOS.
  4. Automatic detection of the monitor layout (how many monitors, what sizes, what orientation) so that the proper saved layout can be automatically restored. Also, saving all of that information in the configuration file to facilitate automatic restoration.
  5. Any potential interactions between Photo, Designer, and Publisher to achieve consistent results across the 3 applications.
  6. Any potential interactions between Photo and Designer and the StudioLink Personas in Publisher so the layout remains consistent whether you're in the Photo Persona in the Photo application or in the Publisher application. Same for Designer Persona in the two applications that support it.
  7. Options to allow the user to achieve that consistency between the applications and the Publisher Personas, or not, as the user chooses.
  8. Testing for all those different monitor layouts, on Mac and Windows. As well as testing of all the added UI.

-- Walt

Windows 10 Home, version 1903 (18362.356), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.3.481 and 1.8.0.486 Beta   / Affinity Designer 1.7.3.481 and 1.8.0.486 Beta  / Affinity Publisher 1.7.3.481 and 1.8.0.502 Beta

Share this post


Link to post
Share on other sites
8 hours ago, walt.farrell said:

4. Automatic detection of the monitor layout (how many monitors, what sizes, what orientation) so that the proper saved layout can be automatically restored. Also, saving all of that information in the configuration file to facilitate automatic restoration.

This would probably be the most difficult thing to code. It would need to include fallback layouts so that if the number of monitors changes, no panels or document windows are 'orphaned' (not on any screen) if fewer monitors are connected, while still remembering & resorting the layout when the other monitor(s) are reconnected. And at least for Macs, it would have to take into account the different ways multi-monitor support has been implemented in different versions of the Mac OS.

The idea that coding even just this much would take just a few hours or could be done by a "summer student" is absurd.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
16 hours ago, walt.farrell said:
  • A command or panel in the UI for the user to save them, with a user-chosen name and possibly a user-chosen location.
  • Translation for all of that.

This is what I call a workspace naming procedure which obviously implies interacting with the user.

All the remarks made above are certainly relevant but sorry, they are supposed to have been already taken into account even if the program insists on supporting only one workspace. Reacting on configuration changes, proper isolation of the workspace loading code, handling of opened palettes when quitting the application, interaction with other Affinity applications, etc. All of this is hopefully already handled in the current code. For example, what if I remove a secondary display and then relaunch AP while the latest recorded workspace space included palettes formerly displayed on the secondary display ? This has nothing to do with the fact that multiple workspaces are supported or not.

If AP is properly designed, all these points are necessarily already handled. So I insist, coding a workspace saving and reloading mechanism is easy and should not take much time. If AP has been coded in such a way that adding such a mechanism is long and difficult, I name this a design flaw. This request has been made years ago. So, I'm wondering why it takes so much time to implement this feature the same way as in similar software. If this possibility has been overseen in the initial design, it's another problem and this could explain why the development team are reluctant to do something about it.


--Patrick

Share this post


Link to post
Share on other sites
1 hour ago, Samoreen said:

All of this is hopefully already handled in the current code. For example, what if I remove a secondary display and then relaunch AP while the latest recorded workspace space included palettes formerly displayed on the secondary display ?

Today, from what I've read, that procedure will cause problems.


-- Walt

Windows 10 Home, version 1903 (18362.356), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.3.481 and 1.8.0.486 Beta   / Affinity Designer 1.7.3.481 and 1.8.0.486 Beta  / Affinity Publisher 1.7.3.481 and 1.8.0.502 Beta

Share this post


Link to post
Share on other sites
2 hours ago, walt.farrell said:

Today, from what I've read, that procedure will cause problems.

It often does, not just with the Affinity apps but with other apps as well. It is much harder to get this right than it might seem, particularly considering the different implementations of multi-monitor support that different OS versions have provided. (Apple has changed this several times over the years & it still can be problematic.)

As it is, it usually requires restarting the app just to reinitialize the UI (which means closing all open documents & saving any changes as needed) & then (ideally) reopening all the documents that had to be closed. Even so that still may not work as expected, for example because some other process is running concurrently that interferes with the timing of the reinitialization process, or with reloading the documents afterwards if that is part of it.

It is really a lot trickier to make this reasonably bulletproof than it seems, certainly not something that could be done in a few hours by a senior coder, much less by an intern.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
34 minutes ago, R C-R said:

It is really a lot trickier to make this reasonably bulletproof than it seems, certainly not something that could be done in a few hours by a senior coder, much less by an intern.

Implementing an application model that makes window management flexible and adaptive is certainly something that requires some work but this kind of model already exists. For example, many application frameworks implement the Model-View-Controller model. It's just a matter of using it. Any application based on such a model can easily implement workspace management. Implementing a well-designed window management code is different from managing multiple workspaces. The latter (and that's what I'm talking about) is a breeze if the underlying window management code is correctly designed. As stated above, if managing multiple workspaces can't be done at all or at least not easily, it's because there's something wrong with how windows are managed in the app. Maybe the designers of AP shot themselves in the foot by not adding the multiple workspaces feature to their initial specifications from the very beginning. And maybe it's too late now. Photoshop does it, DxO Photolab does it, Capture One does it, Silkypix Developer Studio does it,... I'm not sure that we'll ever see this feature implemented in AP.


--Patrick

Share this post


Link to post
Share on other sites

Just a wee point. I use XNView (just switched from ACDSee) to keep track of all my images in my life as a professional photographer and it is a free piece of software although I paid the suggested $29 cos I'm nice like that. I can save and restore layouts in that. I believe it is written by one German fellow in his bedroom (cannot provide evidence it's not in his living room!) If he can do it...


I like turtles!

Windows 10

Pentax K3 and K3-ii

Sony RX10 Mkiii

Canon G5x

Share this post


Link to post
Share on other sites
8 hours ago, Phil_rose said:

Just a wee point. I use XNView (just switched from ACDSee) to keep track of all my images in my life as a professional photographer and it is a free piece of software although I paid the suggested $29 cos I'm nice like that. I can save and restore layouts in that. I believe it is written by one German fellow in his bedroom (cannot provide evidence it's not in his living room!) If he can do it...

Ever tried using XnViewPM with a multi-monitor setup?


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
8 hours ago, Samoreen said:

Implementing an application model that makes window management flexible and adaptive is certainly something that requires some work but this kind of model already exists. For example, many application frameworks implement the Model-View-Controller model.

Can you name a few example apps that do this ... & work flawlessly on all the desktop OS versions (both Mac & Windows) that the Affinity apps support?


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
8 hours ago, R C-R said:

Can you name a few example apps that do this ... & work flawlessly on all the desktop OS versions (both Mac & Windows) that the Affinity apps support?

Fair question. But to answer it, I would need to have access to the source code of such applications. However, I have been teaching software design and development for years, I have made a lot of development myself, and I do know what is possible when using such models like MVC. PS probably doesn't use MVC, DxO Photolab probably does,... I can't be sure.

Anyway, I think that we are shifting from the initial question. The applications that I have mentioned above (PS, etc.) have implemented a workspace management system which works with any stable display setup, whatever their internal design. I'm not requesting more. I can accept a few glitches when adding or removing a display, when changing the definition of a display, etc. Not a big issue since this will not happen very often. I don't see any good reason for which AP should be unable to provide such a feature.


--Patrick

Share this post


Link to post
Share on other sites
4 minutes ago, Samoreen said:

The applications that I have mentioned above (PS, etc.) have implemented a workspace management system which works with any stable display setup, whatever their internal design.

What specifically do you mean by "stable display setup"? That could mean any of several different things, particularly regarding changing among multiple workspace layouts that involve different numbers of monitors at different times.

11 minutes ago, Samoreen said:

I can accept a few glitches when adding or removing a display, when changing the definition of a display, etc. Not a big issue since this will not happen very often.

How do you know how often users other than yourself might want or need to change the number of displays or what glitches they would find acceptable? IOW, who should the developers choose as the target user type for this feature, taking into account the differences in platforms & OS versions they must support?


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites
1 hour ago, R C-R said:

That could mean any of several different things, particularly regarding changing among multiple workspace layouts that involve different numbers of monitors at different times.

Now, you're quibbling. Again, the way the workspace management feature is implemented in the apps I mentioned above is satisfactory for most users. If the AP development team is waiting for a perfect solution that will work in absolutely all cases, I was right when suspecting that we'll never see such a feature in AP.


--Patrick

Share this post


Link to post
Share on other sites
3 minutes ago, Samoreen said:

Now, you're quibbling.

I am just trying to be realistic about how difficult it would be to get this to work in a way that most users would find acceptable.

Maybe it is different for Windows but I know of no Mac app, PS included, that reliably handles changing workspace layouts when the number of monitors and/or Spaces and/or any of their screen resolution changes. What works OK with one version of the Mac OS may not with another, for example by not restoring every window to the same absolute or relative location each time any of these things change, or reopening some windows on a screen that isn't actually connected, or even causing the pointer to freeze.

These are not minor glitches. Eliminating them is extremely difficult because there are so many different display configurations to support & several timing, memory use, & other issues that apps can't control directly, any of which could contribute to a failure.

So while it would not be impossible for the Affinity apps to offer some form of this, it would be nowhere even close to as simple & easy as you first claimed it would be.


Affinity Photo 1.7.3, Affinity Designer 1.7.3, Affinity Publisher 1.7.3; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.7.3.155 & Affinity Designer 1.7.3.1 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 13.1.2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.