TOC
B31 on OSX 10.12.6.
Since I now can play with other things, I've started with the TOC sidebar. First, I love it! Great way to move around a really large document like the one I'm working on, and the drag and drop from there is fantastic.
In using it for (only) a few minutes, a question and a problem(?).
1. The (aesthetic) problem is that the cursor isn't staying a pointer in the sidebar. If I'm hovering over the editor section, then the cursor is the normal text cursor (like a stick person holding their hands up; if that has a name other than "text cursor," I don't know what it is). When I move the (hovering) cursor over the TOC sidebar, it changes to a pointer cursor, which is what I would expect. It stays that way until I actually click something. Once I click, it immediately changes to the text cursor, and won't change back (I can still click and open/close sections) unless I move it back over the editor section and back to the TOC sidebar. I'm assuming/hoping it should stay a pointer cursor as long as we're in the sidebar section.
2. The question/request (and I realize this is 4.x, not 4.0) is a way to open/close all levels in the TOC, i.e. close everything to level 1, etc. I looked around (and even searched in Help! And watched the video!) for that capability, but don't see it. That would make TOC eminently more useful (to me, at least); that's why I want the TOC, is to quickly go to a header 1 topic, and I had to manually close everything down so I had all my level 1's together. You could put that on a menu somewhere and either assign hotkeys or not; I'm fine with having to assign my own. I would include at least open everything (all the way), close everything (to level 1), and then however many levels you feel like (at least 2-3).
3. And actually, two questions — is there a key that will move to the sidebar search field, or does that have to be done with a mouse? I searched the menus, didn't see anything. I halfway thought that if I did a cmd-1 to move context to there, that a cmd-F would search using that field instead of the main one. I understand (probably) why it doesn't, but it would be nice to have a key that does.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Vince on 05 Sep, 2017 07:50 PM
And this just happened, which I consider a more serious bug. (Still B31.)
I closed everything in the TOC sidebar down to level 1. I clicked on one of the level 1's and moved it up in the document. It immediately fully opened everything in the sidebar again. Urgh! What's up with that?
I can see it opening a (single) level 1 if I hovered over it so I could move it within that level 1's structure, but I didn't — it stayed at level 1. There was no reason to open anything, much less everything.
Support Staff 2 Posted by Fletcher on 05 Sep, 2017 07:51 PM
1. Can you send a video? I can't reproduce this no matter what I try.
2. I'll look back at this -- I had code that handled some of this
before, but I apparently didn't migrate it to v4. I probably *will* get
this done for 4.0.
3. As you noted -- Cmd-1 goes the left sidebar. Tab from there will
take you the search box. Cmd-F always searches text.
3 Posted by Vince Rice on 05 Sep, 2017 07:59 PM
Yes, I'll send a video (it just did it again), but it will have to be tonight. And while I'm at it I hope I can show you that although I move it that level 1 to be between two other level 1's, it's splitting the text of the first level 1.
# Topic A
# Topic B
…
# Topic G
That's the way the sidebar looks — everything is closed to level 1. I click and grab Topic G, move it until the horizontal cursor is between A and B, and drop it. And it does drop in between, but some of the text of Topic A are now after Topic G, and everything is open.
Ahh, tab. That makes sense. Two keystrokes to search instead of one, but that's livable.
Oh, wait, I just realized. You replied 1.2.3 like my original email, but you replied to my second email. What can't you replicate — the cursor changing to text, or the TOC opening everything when I move something?
Support Staff 4 Posted by Fletcher on 05 Sep, 2017 08:42 PM
The TOC *should* open if needed while dragging (e.g. to drop inside a
parent between two children).
It currently *does* open after a drop, but that's because it currently
always expands when the text has been changed and the TOC refreshes
(that's the part I have to look back at).
What I can't replicate is cursor.
Weird -- now I can. I couldn't make it change to insertion caret for
anything, but now I can. I'll try to look at this some time, but
honestly it will be very low on the list.
5 Posted by Vince Rice on 05 Sep, 2017 08:52 PM
> The TOC *should* open if needed while dragging (e.g. to drop inside a
> parent between two children).
>
Yes, I understand that, and said it should. That's not what I'm doing, though. (And, for the record, it should only "hinge" open, i.e. open while we're hovering over it and/or when we drop it. If we change our mind while we're still hovering and move on to somewhere else, it should close again.)
>
> It currently *does* open after a drop, but that's because it currently
> always expands when the text has been changed and the TOC refreshes
> (that's the part I have to look back at).
>
That's what I'm talking about. So I'll await your looking. :)
> Weird -- now I can. I couldn't make it change to insertion caret for
> anything, but now I can. I'll try to look at this some time, but
> honestly it will be very low on the list.
>
Right, that's why I said it was an aesthetic problem. :)
Support Staff 6 Posted by Fletcher on 05 Sep, 2017 09:53 PM
b33 fixes some issues related to proper positioning of text during drag/drop (there was a loophole in the previous fix for character/byte offsets)
The open/close part is coming. (I try to prioritize any fixes that could potentially cause data loss)
7 Posted by Vince Rice on 05 Sep, 2017 10:04 PM
Awesome, look forward to it; I had to resort to cutting/pasting in the editor section for now, it was causing too many problems in TOC.
Here's another aesthetic one you won't care about for initial release (and maybe not at all :); I'll send some screen prints if you care and can't duplicate it.
Opening the TOC causes some artifacts to appear on the editor side of the splitter between editor and preview. The artifacts appear to be the first few (2-3?) pixels from the first character on each line in the Preview. The Preview itself is fine (IOW the pixels aren't missing there), they appear to be just leftover artifacts from moving the Preview when the TOC opened.
To see it, open a document (better if it's at least a full-screen worth, and that editor/Preview are in sync). The line dividing editor/preview is pristine. Open the TOC. That line now has very small artifacts just inside the left (editor) portion of that line all the way up and down it. It's only a couple of pixels, and it's only on the rows that have characters in Preview; blank lines in Preview obviously don't leave any artifacts. Closing the TOC returns the line to pristine condition. Repeatable every time the TOC is opened/closed.
Support Staff 8 Posted by Fletcher on 05 Sep, 2017 10:10 PM
I can't replicate that, and have never seen it in the thousands of times I have toggled preview/TOC/etc.
I'll probably need a video on this one, a static image probably won't help tell me much about what's going on (but if a screen shot is faster I can start there).
Support Staff 9 Posted by Fletcher on 06 Sep, 2017 01:03 AM
The expansion issue is fixed -- the code I mentioned was in fact there. The preference to turn it off was not. ;)
10 Posted by Vince Rice on 06 Sep, 2017 04:06 AM
You should by now — I'm special, things happen to me that never happen. :)
Video uploaded. This is on a late 2013 MBP Retina using the built-in graphics.
On my this year's iMac, I haven't yet gotten the artifacts leftover. However, I can see them appear and disappear in the transition.
Support Staff 11 Posted by Fletcher on 06 Sep, 2017 10:13 AM
Hmmm.... Definitely have never seen that.
After artifacts appear, what happens when you scroll? Do they track with scrolling or remain static (or disappear)? If they track, do they track with preview or with editor?
12 Posted by Vince Rice on 06 Sep, 2017 03:32 PM
Now on B36 (I know it doesn't matter for this, just noting the change.)
They remain static, no matter which side is scrolled; it's like they're part of the splitter (hmm, that gives me an idea…). They also remain present after alt-tabbing away from MMD and back to it.
The idea: move the splitter (between editor/preview) and see what happens. Very interesting. Sometimes that makes the artifacts go away, sometimes that makes them appear. So, e.g. if they're already visible, I've been able to move the splitter and make them disappear, i.e. they're no longer present when I release it. But other times, when they're not visible, I can move the splitter and make them appear, i.e. they're present after I release it. And I've gotten them moving it both directions, which puts the kabosh on a theory I had (that they only appear when moving to the right).
So, not unique to TOC (that's just where I saw it first), I've now had it happen when moving the splitter, as well as messing with the other sidebars (CriticMarkup, Reference).
Support Staff 13 Posted by Fletcher on 06 Sep, 2017 03:50 PM
So it sounds like something is making the splitter "dirty" (term used when a particular rectangle on screen has been modified and needs to be redrawn) and the splitter is not recognizing the need to redraw that rectangle?
Just to confirm I'm not missing anything:
1) The artifacts are always within that 1 pixel line (2 on retina displays)?
2) They do not interfere with the editor or preview, per se?
3) The issue is purely cosmetic?
4) If I understand correctly, the issue appears on your Retina computer, but not the non-retina computer? I don't have a retina Mac, only retina iPad/iPhones and resizing the splitter doesn't work on touch screens (not yet) and I don't have any sidebars implemented on iOS to toggle on/off.
I tried increasing the thickness of the divider to 10 pixels, and still did not see anything.
As long as this is purely cosmetic, I'm going to let it go for now. I am thinking about rewriting the code I use to layout the GUI, which would replace what I use now. If I do that, this issue would likely disappear. However, rewriting this is not something I want to do before releasing 4.0, and it would make more sense to rewrite as I get further along in iOS development (what I use works fine on iOS, but I want to experiment with some other ideas).
Am I missing anything?
14 Posted by Vince Rice on 06 Sep, 2017 04:17 PM
?? iOS? There's an app for iOS? How did I miss that? I just looked on the store and didn't see anything.
1. I am not smart enough to know how many pixels are displaying. Nor do I have any non-retina displays. I would guess it's 1-4 pixels, but that's all it would be, a guess.
2. No. As I said at the beginning, aesthetic.
3. Yes.
4. No, both of my computers are retina. But I haven't had the issue yet on the iMac, although as I said, I can see the artifacts as it moves, they just don't happen to stick on the iMac. (At least in my admittedly small testing sample there.)
I'm fine with not worrying about it, I only reported it to be thorough, and because sometimes small things like indicate bigger problems behind the scenes.
Support Staff 15 Posted by Fletcher on 06 Sep, 2017 04:21 PM
*I* have an iOS app, it's not ready for use or sale though (it's
basically the editor, preview, and info bar (word count, etc) but no
"wrapper" that does everything else (files, save, open, print, sync, etc.).
Right now it's just proof of concept that the editor works, and helps
provide me with another way of bug checking.
I had a beta iOS app back in 2012 or so(?) but wasn't happy with it and
didn't have time to work on it after Composer 2, then 3, for the Mac.
But it will move back up the priority list once the macOS version is
"finished."
1. The divider is set to 1 pixel, but that should be doubled to 2 pixels
on Retina display automatically.
In this instance, this should not (never say never, and all that) be
related to any bigger issue.
16 Posted by Vince Rice on 06 Sep, 2017 07:27 PM
Ahhh. Well, I look forward to the Testflight invitation for that. :)
Just to confirm your suspicions, here's a screen print I took of a very small section of the bar with the artifacts. They do all seem to be one or two pixels wide (I just loaded it in Preview and then zoomed way in.)
Support Staff 17 Posted by Fletcher on 06 Sep, 2017 08:00 PM
Interesting -- it's one pixel wide, and I would have expected it to be
two pixels wide on a retina display. I'll play around and see if I can
make it 2 pixels wide on retina displays -- maybe that will help both
issues?
18 Posted by Vince Rice on 06 Sep, 2017 08:12 PM
Did you see my other email/video? :) How wide's the one between TOC and Editor? 'Cause I get a splitter cursor there.
But I assume it can't hurt, and is probably the right thing to do, regardless.
Support Staff 19 Posted by Fletcher on 06 Sep, 2017 08:18 PM
They are built using the same code, so same thickness -- it's hardcoded
in and I don't change that, except to 0.0 when a view is toggled off.
But I *was* able to replicate the artifact in fake retina mode on my
laptop, so next build will use thicker divider if a retina display is
detected.
We'll see whether that helps one or both issues.
F-
20 Posted by Vince Rice on 06 Sep, 2017 08:42 PM
But now that I look at it more closely, the one between TOC and editor (in my case, technically between TOC and line numbers) does look wider than the one between editor and Preview. So maybe that does the solve at least the "can't get splitter cursor" problem. Might solve the other, too, but I can't imagine it would make it worse. (He says confidently like he knows what he's talking about.)
> On Sep 6, 2017, at 3:12 PM, Vince Rice <[email blocked]> wrote:
>
> Did you see my other email/video? :) How wide's the one between TOC and Editor? 'Cause I get a splitter cursor there.
>
> But I assume it can't hurt, and is probably the right thing to do, regardless.
>
>
>> On Sep 6, 2017, at 3:00 PM, Fletcher <[email blocked] <mailto:[email blocked]>> wrote:
>>
Support Staff 21 Posted by Fletcher on 06 Sep, 2017 08:58 PM
Apple's developer site is down, so I can't sign and release a new build.
(Who knew that Xcode needs the web site in order to be able to manage
that...)
Will try again this evening.
Support Staff 22 Posted by Fletcher on 07 Sep, 2017 01:41 AM
Apple back up, update pushed.
23 Posted by Vince Rice on 07 Sep, 2017 01:53 AM
It does seem to help with the splitter cursor showing up between editor/preview, and I haven't so far been able to coax any artifacts from sticking around.
The issue with the splitter cursor sticking over the TOC didn't change, though.
But still, two out of three ain't bad!
Support Staff 24 Posted by Fletcher on 07 Sep, 2017 01:54 AM
I was only hoping for two, so two out of two is great!!
;)
Support Staff 25 Posted by Fletcher on 07 Sep, 2017 05:57 PM
Is the expanding/collapsing behavior doing better for you? (I assume you turned off the preference forcing expand always)
26 Posted by Vince Rice on 07 Sep, 2017 07:08 PM
Yes! Although I didn't have to uncheck it — it was already unchecked. (It took me a while to find it intially, being under "Advanced Preview Preferences" and having nothing to do with Preview. :)
And I haven't had further issues with dropping things in the middle of text, either.
Another two for two!
Fletcher closed this discussion on 07 Sep, 2017 08:50 PM.