What Changed - default width notes

I’m a hardcore Scapple user with thousands of scapple files. Been using it forever.

Something changed lately. I haven’t changed how I do things but I keep getting a new and undesirable width of items that I am adding. My general workflow is this:

Type in idea
double-click somewhere and add another (perhaps I am single-clicking then double-clicking)

The result is that some text items are width-adjusted to fit whatever I type in. Others are stuck in their default width (200 on my machine).

This never used to happen.

What changed? (see my comment in brackets above - perhaps Scapple does something different when if I single-click and my new item loses focus).

Scapple remains one of the most powerful tools I use but this is bugging me enough to ask!

1 Like

Do you mean the notes with less text are staying at the 200pt rather than shrinking? It could be that Auto-size notes got deselected in your general Options.

Yes that’s what I mean (Thak you!). But, I have “Auto-size notes” selected (on).

Well then. You mentioned that it’s a recent change; did it coincide with a Scapple or system upgrade? Since you didn’t post this in the beta section, I’m assuming you’re not on that, but it’d be helpful if you could confirm the specific number in Scapple ▸ About Scapple and say what version of macOS you’re on (and if it’s Intel or an M1/M2 processor).

For the notes themselves, is there any discernible pattern to which notes are auto-sizing properly and which aren’t? Is it all the notes shorter than 200pt or just some of them? Does the same problem happen if you use a keyboard shortcut to create a new note rather than the mouse click?

1 Like

I am not on the beta.

I don’t recall when I noticed it. I’m a scatterbrain (tech executive) and use Scapple daily. I thought I was crazy at first, but it’s been happening at least a month. I am on a MacBook Pro, M1 Max.

It seems to be the first few notes that I add. Once I am adding a ton of them (often) I don’t notice it.

The notes are short.

I tried to paste an example - funny enough I am workign on a digital trust paper - and I am not at a high enough Trust level to post!

I have three notes - the last one (not sure what order I added them in) is at 200pt width.

  • Data
  • Semantics
  • Interactions

I wasn’t doing anything different, just somehow triggered the bug.

I’ve fixed that, so you should be able to include an image now!

Here is the image. I don’t know what order I added them as I was dumping text in and then went back to format and link things.

I am not able to reproduce the phenomenon so far on my Scapple (1.4.2) installation on MacOS Ventura (13.4.1) when I type the text into the nodes.

When you say you were “dumping text in” what do you mean? Is some of the text in these nodes pasted from other sources rather than typed? If so, that is probably the source of your problem.

For example if you selected the word 'Interactions ’ from some other source and that word was followed by some unexpected/non-evident white space characters (tab, for example), then you can get a widened node. If it is ordinary white space, the text is editable to delete the trailing characters, so it is easy to check if this is the issue.

((There can be unusual no-space characters, for example, in copied web-coded text that I imagine might produce anomalous behavior and not be obviously editable like whitespace characters.))

Hi! This isn’t a paste issue.

When I say “dumping text in” I am just jumping into a new or existing Scapple document and double-clicking to add words and phrases to capture ideas in discussion. I will then start linking them, adding borders, etc. That’s when I notice that some items are 200pt and others are not.

I am having trouble duplicating the issue myself but note that it happens in the earlier stages of capture. So if I am adding 10-20 things the item(s) that are 200pt tend to be in the first few.

As a former software developer, I know how frustrating this is. I am going to see what I can do to get something reproducible!

OK - I think I have duplicated the problem and was able to reproduce it.

  1. Load Scapple and do some stuff.
  2. Jump to another app and do some stuff there.
  3. Switch back to Scapple (I have it open in another window so just moved my mouse over it - i.e. didnt’ tab or anything) and double-click to add a note (“refocus” in screenshot).
  4. Double-click to add another note (“second note”) in my example.

The first note you add (item 3 in list; “refocus” in screenshot) will remain at default (200pt for me) width.

I still can’t reproduce the problem. Following the above steps (letting you slide on the vagary of “do some stuff”) does not reproduce the effect in my installation.

Could there be some utility you are running that is running interference? Just scrambling for ideas here.

I don’t know what utility I may be running but it’s possible.

I am having trouble duplicating it myself. I will keep an eye on it and try to get it fully duplicated and perhaps record a Loom video.

Update (2023-10-04) - I recorded a video of this issue the other day,. lhttps://www.loom.com/share/b73df3138a424c77b2b40466d9c853b4?sid=51c20212-b926-4af9-8ab8-a57ec8a2522c

As of now, for me (macOS Sonoma, M1 Max) all new text items that I add, after the first one, are full width. I have tried uninstalling and reinstalling with no luck.

I haven’t checked out the video yet (the site was running slow for me), but I think I may have the reproduction checklist:

  1. With Scapple in the background, double-click to add a note and type.
  2. When finished, do not click anywhere in Scapple or press Esc to close note editing, instead, click anywhere outside of the window, like the Desktop background.

Does that sound like what you would typically do? If so I am seeing that happen 100% of the time, and we can at least look into that manifestation.

Edit: Hmm, that doesn’t seem to fully work either, now that I play a bit more with it. It stays full width while you go off and do other things, but it is still actively edited in the background, and once you return, it then fits to the width of the text.

Okay, the video site was running much better today. That’s a peculiar one! You aren’t doing anything unusual at all.

I’d be curious to know whether this same problem happens using any of the other methods you could use to create a note, other than double-clicking:

  • Pressing Esc to close editing rather than just double-clicking off somewhere else while the note is still open.
  • Using ⌘↩ to create a new note (either with one selected or not selected, or while editing).
  • Dragging a style out of the inspector—specifically form a style that does not have the width saved into it, naturally (none of the defaults will).
  • And overall, trying with notes selected and notes not selected, as by default that can make a difference (not in this regard, but by default any appearance attributes will carry over from the previously selected note into the new one).

I’m looking to see if there are any potential conditions where it works, while the problem is ongoing otherwise. We can then look at that route, and see if there is something different in the code between these methods, since we don’t have a reproduction as yet, that’s the next best thing.

And by the way, in case you are not aware you can always select all (⌘A) and then use the Notes ▸ Auto-Fit menu command to clean everything up to the widths they need. That should at least help keep things tidy until we get this figured out.

No joy with Esc, Command+Enter.

Pre-selecting (see “preclick” in image) did work for the first item added.

Thanks for the Notes->Auto-Fit item - that will help me clean things up at least.

Okay! Well that isn’t too surprising as they should all be routing through the same common method that generates a new note, with maybe a few little exceptions here and there regarding placement (getting a stacked note with ⌘↩ when another note is selected)… but nothing that should impact something so far down the line as after you’re done typing, what to do about its size.

Let’s see if the previous version (before so much of the recent overhauls to Swift took place) causes this. You can download 1.4.0 from this page. I don’t actually recommend using this for real work, as this release came out three years ago and is thus missing fixes made for subsequent operating system versions. But if it works fine, we can do some comparisons between how it did things and how things are being done now, in this area.

Here is something that I am trying to figure out as I thought I had the answer earlier, but didn’t.

Over a year ago I set my defaults for all new documents as I don’t like the default parchment/beige colour. I raise that as input.

Earlier today I opened up a Scapple document that I had started in June 2021 and it was working just fine. Then I touched another (already open) document and went back to it and it was back in this “fixed width” state.

I then reset my Scapple to defaults hoping that would fix the issue but it didn’t.

I don’t know if that helps debug or not but figured I would share.

Well that could be an interesting data point. If you have any other older boards, even pre-2021 if possible, that are on backup somewhere, I’d first right-click in Finder to compress it to a zip file—that way you have a copy that hasn’t been touched in the new version yet, and then see if that copy exhibits the odd behaviour. If it does, we could take a look at the zipped copy.

It’s not ideal, because since we can’t reproduce the problem at all, both copies are going to act the same on our end. But comparing what worked for a few seconds to what doesn’t work is more data than nothing at any rate.

You can send a private message to attach it, if you prefer, by clicking on my avatar and clicking the large Message button.

Thanks for the patience. It has been a busy week. I will message you with a video recording and some data.

summary: Old .scap file is fine. New ones are not.