Jump to content

Scotto74

Level 2
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Scotto74

  1. I run EN on macOS in fullscreen. Since upgrading to 6.12.x, clicking "+ New Note in <notebook>" opens the new note window in fullscreen as well (see attached screenshot "New_Note.png"). This is slightly confusing, as there is no obvious way to close the new note and return to the main EN window (in full screen, standard macOS window controls are only shown by moving the mouse pointer up to the top edge of the screen). Prior to 6.12.x, opening an new note would open a non-full screen window; similar to what double-clicking an existing note still does in 6.12.x (see attached screenshot "Existing_note.png"). Is this change to the new note intentional? (and if so, why doesn't opening an existing note by double clicking also open full screen?). In my opinion, the old behaviour (opening notes as smaller, non-full screen windows) is preferred. Or at least provide a user preference (e.g. "Open Note windows full screen (Y/N)"). This is what happens when a note is double-clicked: (Existing_Note.png) This is what happens when "+ New Note in <notebook>" is clicked: (New_Note.png)
  2. I'm seeing the same issue. It often manifests when I enter a code block in the Mac app, then later open that same note in the iOS app, where the code formatting is as described above. This only started with the recent 6.12 Mac update, I believe.
  3. Too many times, I've been caught out by quickly adding / editing a note then putting my Mac to sleep without manually clicking the sync button. Later when I pull up EN on my phone, tablet or other laptop; those last minute changes aren't there (because sync never had a chance to run before the machine was put to sleep). I already have my sync frequency set to the lowest setting (5 mins); and yes, it is entirely my own fault for not remembering to manually sync...but it's still frustrating. Software, after all, is supposed make our lives better; doing things automatically so that we don't have to. Two years ago, in 2012, when OSX 10.8 (Mountain Lion) was announced with its "Power Nap" feature, I posted a suggestion here that EN for Mac could possibly mitigate this by attempting a sync during one of the OS "DarkWake" events; but it seems unlikely that's ever going to happen. Recently I've been toying with the idea of an AppleScript, i.e. tell application "Evernote" synchronizeend tell...in conjunction with a 3rd party utility such as SleepWatcher, Scenario or ControlPlane; that will trigger the script automatically when the OS is entering sleep (to force a sync). But it occurs to me that the root problem isn't really sync frequency, or detecting a sleep event, or even me forgetting to click the sync button. The problem is that the sync still runs on a schedule, rather than automatically whenever changes are made. The mobile apps don't have this problem, simply because they don't sync to a schedule. When you edit a note in the iPhone app (assuming you have an Internet connection); those changes are synced automatically as soon as you exit the note (perhaps even while you're still editing the note too? I haven't actually paid much attention, as it all "just works"). So it begs the question: why don't the desktop apps also do this? Obviously one issue on the desktop is that there's no "< Back" button to exit from a note back to a list; so there's no clear trigger to indicate that the user is "done" making changes. But is that, too, actually necessary? If I'm typing away in a note, and I stop typing for say, 5 seconds (or whatever); shouldn't that be a trigger for EN to sync (at least that one particular note)? Or if switch to a different note, any pending changes to previous note should be automatically synced there and then; rather than waiting for the next 5 min cycle to elapse. Clearly there's a balance to be found, between being too "chatty" (ie. syncing on every keystroke), and not enough. But think about how Google Docs works. When was the last time you ever missed an edit in one of your Google Docs because it hadn't synced? Me neither... The underlying sync architecture doesn't need to be completely replaced either. I'm assuming that, today, notes that are 'dirty' (i.e. have unsynced changes) are held in a queue somewhere, and the sync process works off that queue. That wouldn't change; it's just that instead of the only sync triggers being manual (clicking Sync) or scheduled (based on a frequency); there would be an additional set of sync triggers associated with editing/navigating between notes. It just seems odd to me that the mobile apps have this problem perfectly solved (and have had for a number of years now); while the desktop apps are still subject to notes been held hostage by a sleeping computer.
  4. Oh, wow. I'm now convinced that the EN engineers are trained monkeys. You couldn't possibly ***** this up three times in a row....but yet they have. Let's recap: Version 6.x: Worked perfectly. Version 7.0.0: Saved searches with negative "-tag:" simply did not work (did not exclude notes with the specified tag or wildcard) Version 7.0.1: Saved searches with negative "-tag:" now fixed; but if combined with positive "tag:" would crash EN (as described above) Version 7.0.2: Saved searches with both negative "-tag:" and postive "tag:" combination no longer crashes EN; but the search return duplicates of every note (sometimes up to 4 four of the same note are shown). Let's see if 7.0.3 finally fixes the problem once and for all, shall we? Evernote engineers: Can I suggest something? It's pretty simple, I think you'll agree. 1) create a UNIT TEST that tests the above situation (negative "-tag:" combined with positive "tag:"); and assert that the correct results are returned. 2) run this unit test against the build. 3) only if the test passes, proceed publishing to Apple. It's really not that hard.
  5. The commonality between your Crash scenarios and mine would seem to be (from the examples above) where the search contains both a positive "tag:" and a negative "-tag:". That would be where I would be looking, if I were an EN engineer. Thanks for providing your examples, jmsotvall.
  6. I use EN as a GTD-style tool. My naming convention for tags is as follows: context tags start with '@' (eg. @Home, @Work, @Computer etc.)priority tags start with '!' (eg. !Next Action, !Someday)project tags start with '#' (eg. #Renovations, #Garden, #School etc.)All notes eventually get assigned a context, a priority and (optionally) a project. I have saved searches as follows: Inbox (-tag:@*) - any notes not yet tagged with a context (@). This is the 'dumping' ground for new notes into the system, that need to be further processed. Next Action @ Home (tag:@Home, tag:!Next Action) - stuff to work on immediately when at HomeWaiting @ Home (tag:@Home, -tag:"!Next Action", -tag:!Someday) - notes tagged as @Home, but not !Next Action or !Someday. This implies that they're waiting on something.Someday @ Home (tag@Home, tag:!Someday) - stuff to work on some day when at Home Next Action @ Work (tag:@Work, tag:!Next Action)Waiting @ Work (tag:@Work, -tag:"!Next Action", -tag:!Someday)Someday @ Work (tag:@Work, tag:!Someday) Next Action @ Computer (tag:@Computer, tag:!Next Action)Waiting @ Computer (tag:@Computer, -tag:"!Next Action", -tag:!Someday)Someday @ Computer (tag:@Computer, tag:!Someday) As of v7.0; the "Inbox" and "Waiting @ ..." searches returned no notes. Other users reported similar issues using "-tag:*" search criteria. As of v7.0.1; the "Inbox" search now works correctly (so the problem with "-tag:*" appears to be resolved); however the "Waiting @ ..." searches now crash EN). The only difference seems to be that -tag:"!Next Action" has quotes around it (required because "!Next Action" tag has a space in it).
  7. Just updated to 7.0.1...the issue with -tag:* now seems to be fixed (at least in my case). I have an "Inbox" saved search defined as "-tag:*" (ie. any notes that have not yet been tagged), which was not working in the previous 7.0 version and now works in 7.0.1.
  8. I'm pretty sure I know the answer to this, but I'll ask anyway: will it be possible in a future EN version for a sync to occur while the machine is sleeping, using OS X 10.8's Power Nap feature? From what I've read (which is why I'm pretty sure I know the answer), Power Nap doesn't have an API that 3rd party apps can hook into (so apps can't trigger a "DarkWake" event, nor can they be notified when one occurs). It's unclear if this is just a initial limitation that will change in the future. I'm also aware that Power Nap is only supported on Macs with built-in flash storage (rMBP, or 2012 MBAs). However, I'm also lead to believe that when one of these "DarkWake" events happens; the machine's CPU/disk/memory systems are all fully active (video and audio are not), so any open applications can still execute...they just need to gracefully handle the fact that there's no video or audio present. So in theory, if you have EN configured to auto sync every 5 mins; and that happens to coincide with a Power Nap "DarkWake"; then it's possible that it will actually sync. That said, it's probably down to pure luck whether these two events happen concurrently. So I guess the question would be: assuming that Apple doesn't open up Power Nap to allow 3rd party apps like EN to sync while sleeping; would be possible to have a much shorter sync interval in EN (say, "sync every minute") for when the system is asleep; to greatly increase the chances of catching one of these "DarkWake" events? Even if it was just once (ie. sync every minute, until successful). The scenario I'm hinting at here is one I often encounter (as I'm sure many others do): you add/edit a note in EN, then close the lid of you machine before the next scheduled sync. Later when you fire up EN on your phone, you can't find the note because it still sitting in "pending synchronization" state on your Mac. Of course, remembering to manually trigger a sync before sleeping avoids this issue; but I don't always remember to do that.
×
×
  • Create New...