Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Should docklib be able to tell you whether a dock is default/uncustomized? #33

Open
homebysix opened this issue May 23, 2021 · 0 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@homebysix
Copy link
Owner

homebysix commented May 23, 2021

Proposal

Thus far in its history, docklib has objectively read/written dock configurations without imposing any sort of subjective judgment on them. However, it may be useful to make an exception to that rule in order to more easily determine the customization status of the current dock config. An is_default class attribute that returns True/False could provide this status.

Example

This boolean would be useful when writing docklib scripts that rely on idempotency to only take action under certain circumstances, like when the dock still contains Apple's default items.

If implemented, the boolean could be used like this:

from docklib import Dock
dock = Dock()
if dock.is_default:
    # customize the dock
else:
    print('Dock has already been modified from Apple default')

Questions

I have two questions to the community of docklib scripters:

What criteria should be used?

In my exploration, I've collected a few loose criteria for determining whether a dock is default:

  • Contents of persistent-apps and persistent-others: This is the criteria I've found most palatable. I have collected a list of apps listed in Apple's default dock from the last few major versions of macOS. If the dock only contains items in this list, there's a high probability that the dock is default. However, this doesn't take into account two categories of users:

    • Users who genuinely prefer first-party apps and modify their dock very lightly from Apple's configuration, perhaps just removing 2-3 apps they don't use and keeping the rest as is.
    • Users who remove ALL items from the dock, possibly because they intend to hide the dock and use a different solution (e.g. uBar), or perhaps because they don't use the dock at all.
  • mod-count: In an ideal world, uncustomized docks would have a mod-count of zero and our job would be done. However, user modification actions don't appear to be the sole trigger for mod-count to increment: Apple's dock "fixups," which add newly featured apps to the dock after OS upgrades, can increment the count. Automated processes can increment the count, even if they don't actually modify the dock contents. And user modifications that have no meaningful effect (like changing the position of a default icon) also increment the count, even though such modifications should likely not prevent the dock from being considered "default." Therefore, in my implementations I have ignored mod-count.

  • Length of dock: Not to be considered in isolation, but rather combined with one or both of the criteria above — the minimum and maximum length of a default Apple dock should be knowable and used to eliminate false positives.

Is this useful?

Big picture: There's something to be said for keeping docklib as simple as possible. One good example of this: I've decided not to have docklib offer any feature that backs up the dock plist prior to making changes. This is something administrators can handle their own way.

In my view, whether is_default should be left to each admin to implement or provided by docklib itself depends upon (a) how many people would find it genuinely useful, and (b) how many people would contribute to maintaining the feature as Apple's default dock changes in the future.

If we decide docklib should not include is_default, then I'd probably put together a reference script that administrators can use to get a head start on adding their own version of the feature.

I'll stop here and listen to some community feedback. What do you think?

@homebysix homebysix self-assigned this May 23, 2021
@homebysix homebysix added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels May 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant