Jump to content

Samoreen

Members
  • Content count

    93
  • Joined

  • Last visited

About Samoreen

  • Rank
    Member
  • Birthday 04/26/1948

Contact Methods

  • Website URL
    http://www.ppphoto.fr

Profile Information

  • Gender
    Male
  • Location
    Samoreau, France
  • Interests
    Photography

Recent Profile Visitors

553 profile views
  1. Hi, Please have a look there :
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Gabriel was even able to create a .bat file doing the job (thanks, by the way). But it's a pity to have to resort to such solutions when one or two hours of coding and testing would be enough to implement a native solution.
  8. Don't hold your breath. I think there's some kind of mind blocking problem with this request. Coding this feature would be easy and quick. No need to be a top notch developer to do this. The reasons given for not implementing it are irrelevant. So, I guess there's something else preventing the development team to satisfy this request for a feature that is implemented by design in any other similar software. This is the same kind of problem as the questionable Save as... implementation in AP. No intention to listen to what the users say even if the request is easy to satisfy. This is surprising for a software that is otherwise gaining in popularity and for very good reasons.
  9. Hi, I could reproduce. I think that the problem can be narrowed down to the Alt key handling in AP. Normally, when hitting the Alt key, the application's main menu switches to a special mode where it expects a character key to be hit. If this character corresponds to an underlined letter in the currently active menu, the corresponding command is executed. In any application, using alt-tab enables this special state in the application that currently has the focus but then, Windows tries to show the other running apps, allowing the user to select one to switch to. If the user returns to the application that had the focus when alt-tab was hit, the special "Alt" mode is then disabled. This doesn't seem to be the case in AP. So, the program is still expecting a character key to be hit and all keyboard shortcuts are disabled. Hitting the Alt key releases the special mode and things then works as usual. My two cents...
  10. I can confirm that AP is an excellent Photoshop replacement for photographers. For quality RAW development, just use a dedicated tool (Lightroom, Capture One, DxO Photolab, etc.). For this task, AP still has a lot of progress to do. Actually, I think that a version of AP without the Development Persona and focusing on image editing would be welcome.
  11. Hi, In the french version, both Screen and Overlay have been translated as Superposition which therefore appears twice in the menu. Moreover, Overlay had been translated as Incrustation in previous versions which adds to confusion. To be consistent with Photoshop, Screen should actually remain translated as Superposition and Overlay should be translated like before as Incrustation.
  12. OK. Got it. The translations for Affinity Photo are stored in C:\Program Files\Affinity\Affinity Photo\xx\Serif.Interop.Persona.resources.dll , xx being the relevant language subfolder. However, they are not stored there as standard string resources but as a binary stream. This makes impossible to edit them in a classical way (that is, with a resource editor without affecting the program's behavior). Corrections could probably be made with an hex editor but care should be taken to use the same string length when editing the translation. Moreover, this appears to be UTF-8, so accented characters will be a problem. Minor fixes could be made this way but unfortunately, more important changes are practically not possible without recompiling the DLL. If the DLL CRC is checked when loaded (which is likely to happen with .Net stuff), any change is impossible. The DLL should be backed up before any attempt to modify it. Not making the translation strings accessible to the user is a rather unfortunate decision, especially when corrections are made at a very slow rate.
  13. Actually, some translated strings are stored in sub-folders of C:\Program Files\Affinity\Affinity Photo\Resources\Affinity Photo. Unfortunately, not all. For example, the translations for the blend modes are not there. This is very strange. I looked at the various resources compiled into binaries (exe+DLLs), no strings there. I also discovered other strange things : - The .dic files used by the program are the same those used by other applications like the CEWE book editing program, Photoshop, Lightroom or Bridge. Maybe are they used only for spell checking ? - Strangely enough, I could find in the Lightroom string files a sequence of translations that exactly reflects the translation in AP for blend modes. In the file for french, for example : "$$$/Menu/TransferMode/ColorDodge=Densité couleur -" "$$$/Menu/TransferMode/Darken=Obscurcir" "$$$/Menu/TransferMode/DarkerColor=Couleur plus foncée" "$$$/Menu/TransferMode/HardLight=Lumière crue" "$$$/Menu/TransferMode/HardMix=Mélange maximal" "$$$/Menu/TransferMode/Lighten=Eclaircir" "$$$/Menu/TransferMode/LighterColor=Couleur plus claire" "$$$/Menu/TransferMode/LinearBurn=Densité linéaire +" "$$$/Menu/TransferMode/LinearDodge=Densité linéaire - (Ajout)" "$$$/Menu/TransferMode/LinearLight=Lumière linéaire" "$$$/Menu/TransferMode/Multiply=Produit" "$$$/Menu/TransferMode/Overlay=Incrustation" "$$$/Menu/TransferMode/PinLight=Lumière ponctuelle" "$$$/Menu/TransferMode/Screen=Ecran" "$$$/Menu/TransferMode/SoftLight=Lumière tamisée" "$$$/Menu/TransferMode/VividLight=Lumière vive" This is exactly the same translation as in AP (note that Lightroom doesn't use blend modes since it has no layers - so, I'm wondering what are these strings for in LR but that's not the problem).
  14. Hi, What technique is used to support multiple languages in Affinity Photo ? Sometimes, it’s necessary to fix some translation errors without having to wait for the next release (which will not necessarily fix the error). Usually, skilled users can fix the problem by editing string files or by modifying the resources in an executable or a DLL. AP seems to use a different technique that I could not identify but that seems to be used in other commercial applications. For example in Lightroom, all the localization can be made by editing string files. It’s rather easy. Some information about the system used by AP would be welcome. Thanks.
  15. Hi, As I already explained in another thread, the workspace saving mechanism exists but we have no user interface element allowing to trigger it. We just need a menu with 3 commands : - One command (Save workspace as...) allowing to save the current workspace under a specific name in C:\Users\<user>\AppData\Roaming\Affinity\Photo\1.0\Workspaces\Photo - One command allowing to list the existing saved workspaces and to load one of them - One command allowing to delete an existing workspace. That's it. The workspace loading and saving code already exists. The missing code can be written in a snap. That they insist on ignoring this request is beyond me, especially because any other serious image processing program has this capability. Inexplicable. It's just a pity to see that users are now writing batch files in order to manage these workspaces from outside the program.
×

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.