StephenBooth_uk

It would be useful, especially if the whole suite could share the same library of symbols.

I organise most of my documents into projects in Designer. When I save documents they go into the default save location, whether they are in a project or not they all go into the same folder. I should like to request that when a document is saved: If it is not part of a project then it defaults to the default save location If is part of a project and a folder with the same name as the project exists then it is saved to that folder If it is part of a project and there is no folder with the same name as the project then Designer creates the folder and saves the file to it I should also like to request that a save option be added at the Project Level that will save any documents newer than the existing saved version. This would be helpful where different projects may have documents with the same name, it will also lead to tidier folders and easier archiving of old projects. Thanks Stephen

Embedded is different, you're generally much closer to the metal. You say you're getting into C#. The same C# source code can, so long as you're not using any custom, platform specific libraries (e.g. you're expecting to run under Sharepoint and so call Sharepoint services), be compiled for Windows, Linux and (if memory serves) Mac. You don't need rewrite the code for each platform, which some here have been claiming, just use the appropriate compiler. On Windows you're code will probably use .Net and on Linux and Mac it will be Mono, but you don't need to care, all that is handled for you and the code will run the same on each platform and (window manager on Linux allowing) look pretty much the same except for minor details like on Windows the Minimise/Maximise/Close buttons are on the top right of each window and on Mac they are top left (Linux it depends on your window manager). This is the only application I've thus far found where you need to buy a separate licence to run on Windows and Mac. Some of the enterprise vertical apps we support at work have different license models for different platforms but that's due to being licensed per core and not all cores are created equal. Even those will generally let you port from one platform for another and only pay the difference.

I work in IT, in most cases writing for more than one OS is for all intents and purposes the same as writing for one. The actual application code is the same, just when it is compiled (the human readable code is converted to the code the computer actually runs) it is linked to different libraries. Think of these libraries as being like a travel adaptor. Your location is given as Italy where, a quick Google search tells me, mains plugs are two or three prongs arranged in a row and the mains voltage is 230v. If you came to the UK (where mains plugs have three pins arranged in a triangle and the mains voltage is 230v) and brought your laptop then would you expect to have to buy a new laptop, or just use an adaptor?

Not really an equivalent situation or apropos analogy, you're talking about a physical object that has consumed resources and once you have it the seller cannot sell it to another person. A closer analogy would be buying a book to read on a Kindle Keyboard and later wanting to read the same book on a Kindle Paperwhite, then Amazon want charge you for it again because you are reading it on a different platform.

That's a lot of snark for a reply to a post checking that I'd understood the situation correctly. I'm aware that MacOS and Windows are different operating systems and so you need different compiles of the application, 30+ years in the IT/Computing industry, and still going, kinda makes that clear. The norm, however, for cross-platform application development for about 25 years now has been to use abstraction libraries so the same code is compiled for each platform, just using different libraries to abstract the application from the OS services, the developer only needs to think about the application they are writing, not the differences in the OSes they might run on. If your suppliers are telling you they need to code separately for each platform and aren't writing drivers or embedded code (and actually a lot of driver writers are using abstraction libraries these days) then they are ripping you off or need to give their development team a Vegas funeral. This is the first time I can recall an application where you needed a different license depending on which desktop platform you were running it on for quite some time. It's kinda inherent in the language of software licenses, you're buying a license to run the code, not the code itself. This is why in most cases you can install the same application on more than one machine (same or different OS) and so long as you only run it on one machine at a time you're fine with a single user license. The price point for Affinity is not that dissimilar to other packages with similar functionality from what I've seen, it's the same as I'd pay to upgrade PSP and about £25 less than the new cost of PSP. I think what you really mean is that 'Affinity isn't a rip off price like PhotoShop can afford to be due to its name recognition." The issue for me (and possibly the OP) is that wanting to run on both Windows and Mac is about convenience. Do I want to double my cost, and learn a new application, to avoid having to carry two laptops once in a while when I need to carry the Mac for some other reason, or do I only pay about the same and stick with the application I know but 4-5 times a year I'll have to carry my Windows laptop and my MacBook or put down my MacBook and go into the other room to get my Windows laptop. I'll have to think about it.

So, for clarity and avoidance of doubt, if I want to run Affinity on my Windows PC and my Macbook then I have to buy two licenses and pay two license fees. Like the OP I was looking for the ability to use the same software on my existing Windows machines and my Macbook so I could use whichever was to hand at the time. I currently use PaintShop Pro on Windows but they don't have a Mac version. My level of usage doesn't justify the cost of a Photoshop subscription so the price point of Affinity Photo was appealing. If you're now saying that I need to pay twice as much then that appeal reduces a lot.