Jump to content
You must now use your email address to sign in [click for more info] ×

LCamachoDesign

Members
  • Posts

    363
  • Joined

  • Last visited

Everything posted by LCamachoDesign

  1. Small UI bug when the Swatches Panel view option is "Show as list" and a swatch is set to overprint. This is how the documentation shows how the swatches should look: This is how the show in "normal" (?) mode, and it's correct: And finally, this is how the look like in "Shows as list" mode, we can clearly see the grey circles are not being correctly cropped and overlap the swatches above: Thanks!
  2. Just to let you know this is still happening, and only in Affinity apps. No other apps have this problem, so I'm not changing system settings just for this. Can you please look up what's wrong with your icons? More importantly, whatever happened to the mini icon over the file explorer thumbnails? Attached is an example of how Blender does it. Affinity used to do this as well, but somewhere along the way this was lost, and it never came back. So now, when we export a PNG file next to the source file, both thumbnails look exactly the same. The only way to tell them apart is by hovering the file and waiting for Explorer to say what file type it is. Thanks!
  3. I see. But in that case, it's still a problem in Affinity, and not with my system. You should be using the value marked in green, "decimal separator", since that's literally what it is. Instead you seem to be using the "list separator" value marked in red, which is the incorrect value to use (and also; is the correct value for a list separator, so I'm not changing it, it would break stuff elsewhere). Thanks!
  4. I've posted about this before, but Serif could simply use SAM-HQ and be done with it: GitHub - SysCV/sam-hq: Segment Anything in High Quality
  5. That just speaks to exactly what I was saying. The field changes too fast for wasting any time doing custom solutions. When I posted, the only thing you could run locally was Stable Diffusion 1.5. While that works, the quality was pretty substandard, but you only needed a GPU with 4Gb VRAM. Yes, you could use custom checkpoints and LoRAs for waifus, but... that's not the scope here. Jump forward to today, and now you can run SDXL locally. And the quality is much higher than 1.5, vanilla SDXL is ballpark MidJourney 4 I'd say. With ControlNet and LoRA / LyCORIS I'd say you get MidJourney 5 level of generation. But you also no longer can run with 4Gb VRAM, you need at minimum 8Gb, with 12Gb being the recommended value. Basically, you need a 3070 or 4070 and up. Yes, you can use quantization and other fiddly trickery to run below that. I can run SDXL locally on my M1 iPad Pro, but you're looking at 5 minutes per image, it's just not realistically usable. But like you said, it doesn't actually change my initial point, it's still better to have a plugin to connect to these generators. Again, looking at back to when I first posted, Automatic1111 was the way to run SD locally. Fast forward to now, and ComfyUI is the way to do it. Even when A1111 tries to catch up, with the 1.6 release a few days ago, it still can't catch Comfy, it doesn't have support for Control LoRA, and that's a massive downside IMHO. If Serif were, back then, to try porting A1111 into the Affinity suite, that time would've been wasted, they'd need to scrap everything and start again with ComfyUI to be competitive. So yeah, have a plugin system, and let others do that job. This is not speculation either. Just look at Krita, people spent time doing A1111 plugins for it last year... fast forward to today, and both top plugins have gone belly up. The development is now on the ComfyUI plugin hosted at CivitAI.
  6. Bumping this to let you know it's still happening in 2.1.1 and literally all other document icons from all other apps I have installed do not have this problem. Also, none of the options you listed on your workaround @Callum would work as they simply do not exist anymore. These were for Windows 10, and I'm on Windows 11 (and was on 11 too at the time of my OP) where they no longer exist. Thanks!
  7. Steps to reproduce: Create a new document Draw any vector shape Attribute a fill colour to the shape (for easier bug visualisation) Attribute a stroke colour to the shape Set the stroke width to a large value (for easier bug visualisation) Set the stroke colour to none, but leave the stroke width unchanged Notice the object is only showing the fill colour as expected Use the command Layer > Expand Stroke Expected result is for nothing to happen, as the object has no visible stroke. Instead an empty shape in the form of the invisible stroke is created. See attached video for a visual guide to this bug. I can see the logic of why this is happening, the stroke is still "there", it just has the colour of none. But that's not what a user would be expecting when using this command. It particularly aggravating if you have hundreds of objects with tiny stroke widths (the 0.2pt default), and then you expand everything at one to "bake" the design for print production. And do printers hate invisible objects with a passion, it can really mess their low memory equipment. You can't even use the Select Same command to catch all these objects because of this other issue I reported: Suggested remediations: Make the Expand Stroke command ignore any strokes with the colour of "none" Force the object's stroke style to "No Line Style" when it has its colour is set to "none" Either remediation would fix the problem, but implementing both would probably be the ideal as that's what I'd expect the app behaviour to be anyway. EDIT: Additionally, setting an object stroke style to "No Line Style" should force the stroke colour to be none. Otherwise you end up with the situation you select a shape apparently without a stroke, then use the Select Same > Stroke Colour and... nothing happens. The object you selected happened to have a orange stroke set to 0pt width. You can still try to use the Select Same > Stroke Weight > Equal to try and get around this, but it sure is a lot of workarounds to workarounds. Also, why is it Select Same > Stroke Weight if the Stroke panel refers to this object property as Width? Temporary workaround: Select one object with the stroke colour of none Use the command Select > Select Same > Stroke Colour Open the Stroke panel and set the stroke style to "No Line Style" Expand Stroke should now be safe to use (maybe, triple check just in case, you don't want to rouse the anger of a print plant operator) Thanks! Gravação 2023-07-20 144004.mp4
  8. That's a good workaround. It worked. It would still be better to have this fixed in a future build. Thanks!
  9. I know there's a number of Expand Stroke bug reports, but I don't think I've seen any reporting on this particular behaviour? The best bug description is actually show it visually. I've also attached a sample Affinity file for the development team to investigate. Thanks! sample file.afdesign
  10. I'm just going to add what I think it's an important technical point, rather than discussing thread locking vagaries. Serif themselves should not add any AI related features to Affinity. This field is in constant change at this point in time. Plus, due to the nature of how it works, i.e.: needing vast amounts of compute power that are unavailable locally to nearly all users, the most likely future will be that a considerable number of cloud AI image generator and editor APIs will exist in the market. As such, what Serif should be focusing is what I've already mentioned dozens of times. Plugins and scripting. Plugins and scripting should be their top and only priority. Then users and API providers will be free to add whatever generative AI they fancy. Or none if they dislike, do not have use for, or simply disapprove of its usage. Furthermore, when the field inevitably changes, all that needs to change is the plugin/script, and that will be the responsibility of the creator, be it a user or API provider. Serif should not, and must not, spend their time chasing this industry. It changes too fast, it contains too much, it's just too much for any single company to keep up. It also gives the user freedom to use any provider they personally like, rather than being forced to use whatever Serif would choose. Thanks!
  11. Ok, I can see the argument here. I'm not sure why anyone would want to select layers and groups in this way, but maybe it's useful to someone? Maybe this could be an option on the Select Same menu, like the Select Hidden Objects. It could be called "Select Layers & Groups" and be disabled by default? Thanks all!
  12. Bumping this again to add that the same thing happens to groups! Select an unfilled object -> do the Select Same Fill command -> all layers and groups are selected (and deleted if the user presses delete). Will try to edit the first post to include this.
  13. Pretty much. I don't think anyone considers layers to be objects? Layers contain objects, but they are not in themselves objects. At least that's the way I see it. I never expect an object selection command to select a layer. Thanks!
  14. Steps to reproduce: Create a new document Create 3 text objects Lock one of them Deselect all objects Shift select one unlocked text object, then the other, all is well and as expected Without letting go of Shift, try to select the locked text object The app will hang, Affinity Design will start using a lot of CPU time See video below for a visual guide. Workaround for this bug is... waiting. The app will eventually unfreeze itself, but it might take a while. On a Ryzen 3700x it takes around 3 minutes to become responsive again. EDIT: The first time you trigger this bug, the app will take the longest to regain responsiveness again. On subsequent triggers the app will still become unresponsive, but recover much faster... 🤔 Thanks! Gravação 2023-07-13 122658.mp4
  15. I've noticed this bug does not happen if you hold the Alt key to duplicate the object. In this case, the Layers panel behaves as expected, both on moving the object along and trying to nest it within another. Just another detail to help with this. I've also updated the tags on this post to include "affinity publisher". I don't know if this messed with your own bug tag, AFB-6825. My apologies, if possible, please review the tags again. Thanks!
  16. Selecting all unfilled/unstroked objects and deleting them is a common and useful command to clean up files. Sometimes our own, but often those supplied by third parties. However, with this issue, trying to do that will lead to have all your layers deleted, even layers containing objects. Steps to reproduce: Create a new document Draw a few coloured objects, place some in one or more layers Draw an object with cleared fill and stroke Select the unfilled object and use the command Select Same > Fill Colour Notice that all layers and groups in the document will also be select Press Delete, the unfilled object will be deleted, along with all layers and all objects within I've attached a video with a visual guide for this bug. Stroked bug variant: Follow steps 1. to 3. from the list above again Select the unstroked object, but this time use the command Select Same > Stroke Colour Follow the steps 5. and 6. from the list above No video for this variant as it's exactly the same as above, just a different command. There are no workarounds for this bug to the best of my knowledge. Thanks! Gravação 2023-07-13 115028.mp4
  17. Steps to reproduce: Create a new document Draw 2 or more picture frames Open the Layers panel Try to change the frame's stacking order Expected result is for the frame's stacking order to change, instead the moved frame will nest within the frame immediately below its new stacking order position. See attached video for a visual explanation. Bonus bug: if I actually want to nest the frames, I cannot trigger it intentionally. Trying to place a frame within another in the Layers panel never triggers the "filled layer" visual effect that indicates an object will be nested within another. This bug is, to the best of my knowledge, limited to picture frames, square and round. Other objects are unaffected and behave normally. Temporary workaround, use the layer arrange commands. Either on the application menu at Layer > Arrange (and their respective keyboard shortcuts), or the layer arrange buttons on the application toolbar. Both are imune to this bug. Thanks! Gravação 2023-07-13 112345.mp4
  18. Thank you very much. I thought I was going crazy, I was really second guessing myself on this. 😁👍
  19. Using Affinity Designer 2.1.1 on Windows. In the Export persona and using the Slice Tool, I've tried to snap a few slices to objects on the artboard, and they don't snap... but I honestly can't remember if it has always been like this, or if it's a new bug? I've tried looking up the documentation but it says nothing about this. Trying to determine if I simply forgot this was always been like this before submitting a bug report. Snapping to the artboard edges and other slices works fine though, sooo...?? Thanks!
  20. Minor cosmetic issue, when moving guides the delta values show, for example, as 78;3 instead of the expected 78,3 or 78.3. Steps to reproduce: Move a guide 🙂 See attached video for reference. Thanks! Gravação 2023-07-10 150451.mp4
  21. I'm just going to leave this here: GitHub - SysCV/sam-hq: Segment Anything in High Quality Then tell me AI has no uses in real projects.
  22. Yes, that's what I meant. Although I don't think I've ever customized my toolbar, and I did not have the icon anyway. Maybe the toolbar from 1.0 carried over, and counts as customized, or I just forgot. 🤪 This also happened on Publisher by the way, I did not see the icon on Designer persona until I reset the toolbar. I'd do something simple like this. Put the new icon after the last toolbar icon, even on a customized bar like this. Show a small popup simply saying NEW, with a "Learn more" link to https://affinity.serif.com/whats-new/#2-1-vector-flood-fill-tool User wants it, great, it's there. User does not want, they can hide it in 10 seconds. You can't please everyone, but this is the least intrusive way to expose the new tool that I can think. Thanks!
  23. Can't you just put it at the end of the list. What of the user hid those? No logical place left, but putting it at the end of the list always works. Not the best, but better than nothing. Maybe with a little popup right next to it saying "NEW" and showing a short gif animation exemplifying what it does. Plenty of apps do these popups, users are familiar with them. I've already wrote extensively about this here: I think I've said all I had to say about this. Thanks! EDIT: Actually, I haven't said everything. I've tried the tool, and the way it works is pretty clever! I thought it was going to be like Illustrator's Live Paint feature that, while it works very "automagically", as soon as you need to do further adjustment, or even accidentally move the wrong anchor point without noticing, the entire thing breaks without much of a way to recover it if you've missed the damage before closing. This happened to me enough times that I've gave up on the tool altogether. Affinity's way is much better, while not as "magical" it's much more sturdy, resilient, and easy to edit. Great work!! Just don't hide it from new users pretty please. 😁
  24. I had not edited the layout, or at least I cannot recall it. And even if I did, it makes no difference. At the bottom, after the last tool on the toolbar. Ignore. The set of users that will never find the tool is larger, and more important. That's what I meant by Twitter whining. I've been rather busy, but I did come across the topic mentioning the vector flood tool. If I hadn't, I wouldn't even know a new tool was available. I was pretty confused the tool I saw mentioned was nowhere to be found, for a second I thought it had been cancelled. And no, I'm not going to read several pages of FAQs if I'm busy. I'm going to take my free time after work to do other stuff. You have to remember forum users are a miniscule minority. The vast, vast majority of users will barely ever open the basic help section. To imagine they'll read FAQs or announcements to find a new tool is just not knowing how people behave. Hence why I find pretty baffling that time was spent coding a tool, only to hide it in a way that ensures the vast majority of the user base will never find it. EDIT: There's a reason why corporations like Google or Microsoft shove their new tools right in front of users, in pretty obvious and in your face places, or they have onboarding in the form of a tutorial, or a "NEW" tag/popover next to the feature. They spent time and money on these, and they know that without putting these front and center, users will not find them, users will not care to hunt for new functionality. They know this for absolute certain, that's why they do it. The extremely obnoxious actions start when they do not provide the user with a way to hide the new stuff. Microsoft does this often. Or is when they change the UI in such a way that it cannot be undone anymore, and the sole purpose of that change was to shove stuff down users throat. Google is an example that comes to mind on this. In any case, I think I've said and explained enough on this. Thanks for the attention, and apologies for the walls of text.
×
×
  • Create New...

Important Information

Terms of Use | 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.