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.
1 Like
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.
- Load Scapple and do some stuff.
- Jump to another app and do some stuff there.
- 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).
- 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.
1 Like
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:
- With Scapple in the background, double-click to add a note and type.
- 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
Escto 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.
Okay, firstly, thanks for all of the data you’ve sent. I’m going through that along with the video you sent and will see if I can come up with anything interesting.
One thing worth noting is the copy and paste issue you pointed out: that’s expected. Older boards have less padding around the text, and Scapple is programmed to respect that when opening these older files. Copying and pasting notes into a newer board will “upgrade” the padding, and cause the smaller sizing and word wrapping issues you spotted. So that part is fine, that is where the Auto-Fit command would come in handy, and that is precisely why we respect older board settings so the layout doesn’t change, as you see it change on copy and paste.
That difference is in and of itself probably the most interesting and impactful change between how an old board would work and a new one, and as such is the most promising lead—even though on the surface it wouldn’t seem to matter that the padding being slightly different would change whether or not a note auto-sizes at all upon conclusion of editing.
Further troubleshooting:
- One thing I do not see mentioned specifically: did you get a chance to check and see if the older 1.4.0 version I referred to also demonstrates the bug?
- When you get a chance, I’d be curious to see if this problem reproduces in a clean slate condition on your machine. That can be tested by creating a new Mac account just for the purposes of this test, logging into it, leaving pretty much everything default that you can, and seeing if the problem persists in that environment. If it does not, you could audit any background utilities you use on a regular basis, by logging out of your main account, logging back in with the Shift key held down immediately after password entry, and keeping it held down until fully logged in. That will suppress start-up items. Scapple can then be tested with only it and Finder running, and if that is clean, gradually bringing things back up to how you normally run the system, testing between each launch to see what, if anything makes a difference. It’s a bit of a long shot I’ll be honest, as it would seem unlikely to me that any external program could make a difference like this—but given how some things can impact accessibility functions (like window enhancement tools), we can’t entirely rule it out.
Try setting your default font to “Helvetica Neue” (from “Helvetica”).
I just bought Scapple. The autosize is only intermittently working. Settings have autosize selected. Scapple 1.4.2 . Mac M2 Pro running 14.2.1 .
Sometimes, the autosize works great. Other times it doesn’t resize when I end the note (a note being the single bubble within a document, right?). Often, the first note in a series of additions is autosized, but subsequent notes are not autosized. Sometimes, if I go back and edit an unsized note, it will resize after I edit the note. It’s inconsistent and frustrating.
Here is a link where I’m able to reproduce it once or twice: https://youtu.be/L9ZKO38imqY but it is pretty inconsistent. In my other file, it happens more. I included a key press display, which is what you see pop-up. Also, I switched to another window for a moment and edited that out because yall don’t need to see my desktop 
Hmm, on Windows you get this behaviour when you double-click to start a New Note and type nothing, so “New Note” appears with an extended cell. Typing anything else auto-sizes the cell to the text’s length.
In your video, it happens with “New Note” as the default text placeholder and in some other cases as well.
Thanks for the report and video. I’ve merged this with the existing bug report for it. We have two known conditions that can break auto-size, one being very simple and that is having more than one line in a note. The second is more difficult, what you are seeing. It seems to happen more when zoomed than not, and might have to do with rounding issues internally. The ticket does have a fix posted, so what I’d do is keep an eye on the public beta thread, because that’s where fixes for this will pop up first.
1 Like
On my larger map, it happens about 50% of the notes. Would you like a video of that? Or would it be rehashing known information?