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
Conversation
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 ;).
…ad of going though `info`.
Because *somehow* some observation info would end up attached at the wrong object.
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.
Yeah, now it is checked ! I also fixed one of your... own ;-). |
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. |
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.
|
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 |
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 ? |
This will get tackled by the Librarian rewrite
I'm not sure about some of your points above so let's discuss them ;-).
As per above, I don't think it means what you think it means ;-).
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. |
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 ? ;-) |
4 spaces, which you will helpfully find not documented at http://qsapp.com/wiki/Github |
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.
Yes, they are different, which is why we should use The checkbox control on the Attributes tab labelled "Maintain an index of contents" (in the English translation) is bound to
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
OK. We can wait on that. |
Yeah, that sounds good. |
Again, I don't think 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 know what it is. Just look at the iTunes plug-in.
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. |
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. |
This is a rebase of #1601.