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

Cleanup catalog entry API #2049

Merged
merged 55 commits into from May 1, 2015
Merged

Cleanup catalog entry API #2049

merged 55 commits into from May 1, 2015

Conversation

tiennou
Copy link
Member

@tiennou tiennou commented Apr 14, 2015

This is a rebase of #1601.

  • Fix the auto-reenabling presets after a restart

Also remove the direct accesses to the `info` ivar.
This one adds a bunch of warnings, which I plan to fix.
This fixes a bug introduced in the previous commit that caused all preset entries to disappear. This makes the prune loop cleaner by :
- testing for entries being presets or not (the previous test depended on the ordering of presets relative to custom entries, which the previous commit changed).
- not making a copy at all.
Also updates accesses to keyed-subscript + document the keys in the `_Private` file.
…disappeared.

Also giggle the code around so it's easier to understand.
I've put a warning in because I want to check that it works, but it never would have worked in the first place (the pref pane was placing image data in the info dict, which QSCatalogEntry was parsing as an image name). We're lucky that nobody ever tried to customize their catalog entries icons ;).
@skurfer
Copy link
Member

skurfer commented Apr 14, 2015

Awesome. I guess that checkbox is there because you haven’t fixed it yet?

This fixes an issue where the pref pane would load, QSUserDefinedProxySource would register its notification without a NIB loaded (so synonymName = nil), and then it would perform saves on behalf of whatever control whose editing stopped — like in that case, changing a preset's name.

The XIB change is just wiring the control's delegate to File Owner.
@tiennou
Copy link
Member Author

tiennou commented Apr 14, 2015

Yeah, now it is checked ! I also fixed one of your... own ;-).

@tiennou
Copy link
Member Author

tiennou commented Apr 14, 2015

Commit Of The Day : 1e7a5d4.

Take a good look at it, and tell me that's the only occurrence :-S. I literally ran QS 3 times in a row just while intently looking at this dealloc method before The Big Picture struck me.

@skurfer
Copy link
Member

skurfer commented Apr 14, 2015

Other things I found going through my comments. If you don’t want to deal with these, I can do another PR after this is merged.

  • get rid of shouldIndex and bind NIB to canBeIndexed
  • replace canBeIndexed checkbox with a label that's invisible when false
  • rename “Include in Global Catalog” to “Entry Enabled”
  • call [loopItem scanForced:YES] in -[QSLibrarian reloadSource:]

@skurfer
Copy link
Member

skurfer commented Apr 14, 2015

Take a good look at it, and tell me that's the only occurrence :-S.

Heh. Nice. I haven’t checked, but it wouldn’t surprise me if the registry, plug-in manager, trigger manager, etc. all had a pointless dealloc.

@tiennou
Copy link
Member Author

tiennou commented Apr 14, 2015

I'll try to take a look at those. Since I'm in the process of rebasing the bunch of stuff I have lying around that, what would be the best way to go ? I might have a few ideas on how to calm down that -writeCatalog: method, as well as a pending Librarian rewrite I'm currently rebasing. I suppose this one PR is mostly tested, so I'll do another for the Lib stuff, and then continue piling on this one for more fixes. Does that suit you ?

@tiennou
Copy link
Member Author

tiennou commented Apr 14, 2015

I'm not sure about some of your points above so let's discuss them ;-).

get rid of shouldIndex and bind NIB to canBeIndexed

shouldIndex and canBeIndexed seem to have different semantics (the first is plain-ol' enabled (eg "should be scanned", the other is relative to whether an entry can get its index saved).

replace canBeIndexed checkbox with a label that's invisible when false

As per above, I don't think it means what you think it means ;-).

rename “Include in Global Catalog” to “Entry Enabled”

I'm mostly against... for now. Since I plan on inflicting the same kind of heavy rewrite to the Librarian, I had a plan to maybe handle those inner... catalogs or something. I guess we'll see what comes out.

@tiennou
Copy link
Member Author

tiennou commented Apr 14, 2015

Also — because my eyes hurt of looking at that messy indentation and I already stepped all over that file — what was the project's Most Preferable Indentation Character already ? ;-)

@skurfer
Copy link
Member

skurfer commented Apr 15, 2015

what was the project's Most Preferable Indentation Character already ?

4 spaces, which you will helpfully find not documented at http://qsapp.com/wiki/Github 😐

@skurfer
Copy link
Member

skurfer commented Apr 15, 2015

I'm not sure about some of your points above so let's discuss them ;-).

Neither am I. :-)

It's been a long time. I was just looking at comments, but don't remember the reasons behind them all. I'll review and comment here.

shouldIndex and canBeIndexed seem to have different semantics (the first is plain-ol' enabled (eg "should be scanned", the other is relative to whether an entry can get its index saved).

Yes, they are different, which is why we should use canBeIndexed instead.

The checkbox control on the Attributes tab labelled "Maintain an index of contents" (in the English translation) is bound to shouldIndex which, as you said, is just isEnabled so it's always exactly the same value as the checkbox above. I think “Maintain an index…” should be bound to canBeIndexed instead.

replace canBeIndexed checkbox with a label that's invisible when false

As per above, I don't think it means what you think it means ;-).

Referring to the same “Maintain an index” checkbox… Since it’s always disabled, why does it need to be a checkbox at all. Why not make it a label that says "Indexed" and make it visible when canBeIndexed is true?

rename “Include in Global Catalog” to “Entry Enabled”

I'm mostly against... for now. Since I plan on inflicting the same kind of heavy rewrite to the Librarian, I had a plan to maybe handle those inner... catalogs or something. I guess we'll see what comes out.

OK. We can wait on that.

@skurfer
Copy link
Member

skurfer commented Apr 15, 2015

I suppose this one PR is mostly tested, so I'll do another for the Lib stuff, and then continue piling on this one for more fixes. Does that suit you ?

Yeah, that sounds good.

@tiennou
Copy link
Member Author

tiennou commented Apr 15, 2015

Again, I don't think canBeIndexed means what you think. It's a (optional) property of an object source that controls whether that source supports being serialized to a qsindex file.

Now that I reread your 2 points, I understand they aren't actually 2 points : you want a way to tell if a given entry supports being indexed, which actually makes sense. I'm not too fond of that, as it gives insight into something almost no user will care about.

@skurfer
Copy link
Member

skurfer commented Apr 15, 2015

Again, I don't think canBeIndexed means what you think. It's a (optional) property of an object source that controls whether that source supports being serialized to a qsindex file.

I know what it is. Just look at the iTunes plug-in. 😛

Now that I reread your 2 points, I understand they aren't actually 2 points : you want a way to tell if a given entry supports being indexed, which actually makes sense. I'm not too fond of that, as it gives insight into something almost no user will care about.

I had just noticed that the two checkboxes ultimately showed the same value. What I want in the end is to stop doing that. I tried to figure out what the checkboxes’ original intent was and change them to reflect that, but getting rid of one entirely would also work. I agree that knowing if something supports indexing provides no practical benefit to users.

@skurfer
Copy link
Member

skurfer commented Apr 20, 2015

Are you planning to remove the “Maintain an index of contents” checkbox here? If so, I’ll wait. Otherwise, I think this is good to merge.

skurfer added a commit that referenced this pull request May 1, 2015
@skurfer skurfer merged commit 5be448f into master May 1, 2015
@skurfer skurfer deleted the t/catalog/entry-cleanup branch May 1, 2015 15:18
skurfer added a commit that referenced this pull request May 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants