Sync reminder notification & notification actions #689
Conversation
…omber/rojo into sync-reminder-notification
boatbomber
added
type: enhancement
There was a problem hiding this comment.
Good addition - I'm happy there's a setting to turn it on and off. Can you just edit the PR title to say that it adds notification actions?
I also noticed some perhaps surprising behavior on unpublished Roblox template places (for example, the Baseplate resulting from File>New): DataModel.PlaceId is equal to the original template's before publishing, so if the user has ever synced to an unpublished template, they will get a reminder to sync whenever they create one.
Something similar happens with local place files, which have a DataModel.PlaceId always equal to zero. Not sure what to do about these (maybe just avoid showing the reminder if we're on an unpublished local place file or an unpublished template?), but at the same time, it's probably way more common for the user to want to sync to places that are already published, and they can just turn the reminder off if they're not. Dunno, interested to hear your thoughts here.
boatbomber
changed the title
|
Ooh, I honestly forgot those have consistent place ids. I think(?) we can ignorelist them, since the reminder doesn't make sense in their context. |
It's straightforward for local place files, but Roblox could change the template places without warning, and then we'd be right back to spurious notification land. Argh.... well, they don't change very often, do they? Maybe a hard coded check against template place IDs is okay. |
|
Fixed it. It was tedious to gather all those place ids initially but it should be literally one liner PRs when they add more. |
Co-authored-by: Chris Chang <51393127+chriscerie@users.noreply.github.com>
| }), | ||
|
|
||
| LogLevel = e(Setting, { | ||
| id = "logLevel", | ||
| name = "Log Level", | ||
| description = "Plugin output verbosity level", | ||
| transparency = self.props.transparency, | ||
| layoutOrder = 5, | ||
| layoutOrder = 100, |
There was a problem hiding this comment.
Why is the layout order for this and the typechecking setting so high? I'm not intimately familiar with the plugin, so forgive me if this is an obvious question.
There was a problem hiding this comment.
These are dev settings, not really used by consumers, so they're set really high so that they'll always be last in the list and out of the way of users without us having to manually update their layoutorder by one every time we add a setting.
| RojoNotifications = e("ScreenGui", { | ||
| ZIndexBehavior = Enum.ZIndexBehavior.Sibling, | ||
| ResetOnSpawn = false, | ||
| DisplayOrder = 100, |
There was a problem hiding this comment.
Same question as with the LayoutOrders; what's the reason this is so large?
There was a problem hiding this comment.
Rojo Notifications need to display on top for users to see. We don't know what else may be in their CoreGui, so we just use a high display order to increase our odds of having notifications viewable.
Co-authored-by: Micah <dekkonot@rocketmail.com>
Implements and closes rojo-rbx#652. --------- Co-authored-by: Chris Chang <51393127+chriscerie@users.noreply.github.com> Co-authored-by: Micah <git@dekkonot.com>
Implements and closes #652.