Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Brad Brighton

Members
  • Posts

    302
  • Joined

  • Last visited

About Brad Brighton

  • Birthday 04/30/1968

Contact Methods

  • Website URL
    https://bmb.photos

Profile Information

  • Gender
    Male
  • Location
    : Nevada, USA
  • Interests
    Stretching boundaries (literally) with extreme stitched panoramas, capturing light in all its forms, software development, team and business coaching, and a few other things that seem even more completely out of place in this list.

Recent Profile Visitors

1,441 profile views
  1. Given that the app opened normally (for all indications) immediately afterward, it's probably something that will be maddening to attempt to track down. 😄 Also, since I'm mostly in Photo, not Designer, it doesn't mean much one way or the other when I say that there have been no further similar issues.
  2. Posting for documentation purposes since I have the crash report. * Launch 1.9.x (most current, I _think_) * Install and relaunch * On auto-relaunch, crashy * Manual launch after that seemed fine Affinity Designer_2021-08-05-072623_SpamBook2018.crash
  3. Hi @Sean P Sorry, I lost track of this over the week. Here is what I have. -brad 2021_cc_rally.afdesign
  4. The only thing I did that's unusual is dragging the width of the studio to be able to see the dimensions I'm typing in. I had entered values into these fields prior to drag-expanding. The first variation seems to work ok, the second on these slices does not. macOS 11.4 (20F71), AD 1.9.3, MBP 2018 32GB/Radeon Pro Vega 20, external monitor. * moving the AD editor window to the main screen does not make the problem go away * Shrinking the studio does not make the problem change (though I don't know what the exact original width is) * Resetting Studio lost my values in that variation but did not set the editing field back to the full visible width * No, I haven't tried to repro this from a clean start (yet) because I'm trying to get work out under a deadline * However, deleting that variation and adding another for the same slice while the studio is expanded *does* allow proper editing. Screen capture of the oddness attached. Screen Recording 2021-07-17 at 4.16.03 PM.mov
  5. Short version: The vast majority of the style of cruft that you're referring to that made PPC->x86 painful was/is weeded out by the 64bit-only transition well before the Apple Silicon transition. If a developer wants to bring something pre-64bit over, yes, it's going to involve work. If that work has already been done or if the app is natively friendly to the current world anyway, this transition promises to be _relatively_ painless (excepting certain categories like device and/or kernel drivers, etc) which is more a function of the increased security layers that the OS is getting than the drive to Apple Silicon itself.
  6. I'm not a Serif rep however... While the App Store purchase allows you to use the app across multiple iPads, it does not allow you to cross to macOS. You would need to purchase that version separately (either through the Mac App Store or directly from Serif depending on your personal preferences - there are other threads that discuss the differences between the two options).
  7. Also, since Serif are European, your issuing bank may be blocking the charge as possible fraud. You may need to contact your issuer on that.
  8. I have an old bug report on the topic lying around somewhere... my SWAG based on experience is that the tabs are filled in in order of _completion of load_, not _initiation of load_. Larger files in a group will wind up later in the tab order on launch/open group. Predictability among larger files is not high given variations of code performance at the time of file open, available required system resources that may vary depending on the content of the file, and speed of retrieval from underlying storage.
  9. Getting even further off-topic, revision control is notoriously awful with binary files. Bloats the repository since there's not often a meaningful diff between one binary and another that can be applied. You wind up storing the entire file each time. Good when you genuinely need documented reproducibility at a point in time, terrible for most other workflows.
  10. That's only effective if you know where in the history the last notable save was. If you're like me and always (manually for every file, feh) have "save with history" turned on, then you're back to the close-without-saving option only.
  11. Silly questions but the first things to check: are you (1) sure you're logged in at all at the App Store (it's been known to log people out and it not be obvious) and (2) logged in as the Apple ID under which the purchase has been made?
  12. Given the ways the App Stores intentionally separate developers and purchasers with basically the only line through that medium being reviews and developer responses, it's challenging. There is, as you found, a way to interact with Serif directly here and hopefully your feedback about the content of their responses will be taken into consideration for future messaging. I don't think I can add anything useful further to this so cheers for now!
  13. While I can understand and appreciate this, Greg, I doubt there's anything Serif could have done except explain it better. I cannot speak on the MS side but as an Apple developer, had this situation been on the Mac side, there's no one for the developer to talk to. Apple specifically tells developers they CANNOT initiate refund requests. The user/customer MUST do so. I suspect it's similar on the Microsoft side.
  14. To get this out of the way, I do NOT work for Serif nor am I an apologist. I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally. App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways: There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues. Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.
  15. Yeah, I'd have to agree, there are several suspicious elements here. I would recommend running First Aid on the disk but if you're going to have it looked at anyway, leave it alone and let that person see it as it is (to avoid hiding any symptoms or messages that inform the situation).
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.