Rework QSTask.

[tiennou]

This supersedes #1603 and #1265.

Major surgery on QSTask, this makes QSTask a real model-only object, kills the deadlock issues between QSTaskController and QSTaskViewer and fixes the auto-show/hide behavior once and for all (at least it seems to behave right, now ;-)) :

• It will show if there's a new task and the prefs says it (it was).
• It won't show if during the time the task was created and the time the viewer reacts the task is done. This should fix Task viewer pops up continually #1040, and stop me wanting to bash it each time I open a new tab.
• It won't try to auto-close the window if you open it manually and a task finishes (this fixes a never reported issue ;-)).

Known issues/discussion:

• The first time it opens (set it to automatically open, quit and restart so you get the catalog startup scan), the view is messed up because it extends all the way to the right, which looks weird.
• I've setup minimal code to correctly to handle subtasks, but there's no viewer suppport, and I'm not sure it's worth it. It was mostly present, but the only thing I can think that would use that is the catalog scanning, and maybe the update system.
• I'm tempted to push up the HIDE_DELAY by a few millisec, so you can see the task completed. Right now it just closes before you can even see the task has ended (which looks the same to the user, but could be nicer).
• I've killed the target/action mechanism it had for task cancellation, instead relying on a cancelBlock.
• Documentation. I really want to do this one, but I need some more time.
• This could break plugins that used tasks (there was a -(QSObject *)result method I've killed, plus the effects of the major surgery). But I don't think that many plugins did that, and I think the API as it is is sufficient for "general user information". But if you find I broke some plugin, I'll happily revise and provide at least a private runtime equivalent.
• Maybe the preferences settings should be also specified in the Extras pref pane ? I think it's pretty hidden atm, IIRC by default it won't autoshow, and you can't change those settings unless you open it first and fiddle with the gear menu. TaskViewer not reliably loading correctly #119 talks about that a little.

All in all, eyes are welcome so I'm breaking anything, and if you stop a thing I didn't point out in the list above, the

[skurfer]

Maybe the preferences settings should be also specified in the Extras pref pane…

You mean something like “Preferences → Extras → Show the Task Viewer automatically when tasks are created”? 😃

I've always thought that things created with “Run After Delay…” and “Run at Time…” should appear in the Task Viewer. That will let you see that they exist, when they will run, and there should be a way to remove/cancel them from there. I'm not saying you need to implement any of this now, but if we're doing major surgery, we should at least make sure the design will allow for it to be added easily later. Agreed?

I’ll take a look at this tomorrow.

[skurfer]

Does this also obviate #1598, since it includes the renames?

[tiennou]

Yep, forgot to point that out ;-).

Le 19 sept. 2013 à 06:09, Rob McBroom notifications@github.com a écrit :

Does this also obviate #1598, since it includes the renames?

—
Reply to this email directly or view it on GitHub.

[skurfer]

The assertion happens if the condition is false, so this should be == YES, right?

[skurfer]

I found a couple of things by trying to implement the stuff I was talking about with “Run after Delay…” (which isn’t going to be that hard at all).

• The Hidden property in QSTaskView.xib needs to be hooked up to the inverse of task.showProgress.
• I know I’ve used -[QSTask stopTask:] in at least one (never released) plug-in. Could there be others using it?

Other than the cancel method, and the progress bar issues, all seems to be working well with this.

[skurfer]

If you're busy, I can add the finishing touches mentioned above and do another pull.

[tiennou]

I'm looking at it atm.

The Hidden property in QSTaskView.xib needs to be hooked up to the inverse of task.showProgress.

Which hidden property ? There are many I can choose from ;-).

I know I’ve used -[QSTask stopTask:] in at least one (never released) plug-in. Could there be others using it?

If you think there's a need to, I can put in (deprecated) wrappers for the old names.

[skurfer]

Which hidden property ?

I mean the one literally named “Hidden”. The one that controls whether or not the progress bar is visible. 😃

I can put in (deprecated) wrappers for the old names.

Looks like the plug-ins mainly use updateTask: and removeTask: from QSTaskController, so as long as those still work, it should be fine. I can update the Cloud plug-in before release.

[tiennou]

I mean the one literally named “Hidden”. The one that controls whether or not the progress bar is visible. 😃

I was wondering which one — from the 10-or-so controls/views that are hideable in that XIB — you were talking about (or the NSView itself). Now I now, though still pretty indirectly ;-). Damn, text-based communication isn't getting any easier.

On a branch-related note, it seems like it doesn't work as well as when I first wrote it. I'm really wondering what's happening now because I clearly remember noticing the progress bar bug at startup, trying to debug the auto-show/hide behavior, then running it for a whole evening while in a 3-hour-long browsing and drooling in contempt that I didn't get bothered by empty task viewers popping in and out all the time ;-). Now, it won't show itself at startup (I actually chown root ~/Library/Quicksilver/Cachesed) no matter what I do, so I can't check the startup bar bug. The only difference I have is that I merged in master before starting to work on that, and I'm now on Xcode 5.

If you get the time, can you confirm whether I'm going crazy or something ? ;-)

[skurfer]

I see it during the initial scan when I launch from the Debugger (Xcode 5 here too).

Are you asking about a bug with the window or the progress bar?

It's too fast to see if the progress bar looks correct, but the initial position of the panel is strange. For me, it appears at the top of the screen (behind the menu bar) and right of the screen's center.

[tiennou]

Okay, updated. This fixes the infinite progress bar issue, tries to make it dockable (since we're using a dockable window), and "various bug fixes".

I said "tries" because — as I pointed out in the dev group a while ago — QSInterface is a mess, like in that case, the docked Task Viewer won't undock if you tickle it with you mouse because I don't know, it doesn't. I imagine it has to do with the fact that -[NSWindow isVisible] and -[QSWindow hidden] aren't agreeing, but you can't just override it without breaking animations. So let's hope that nobody has a use case for tickling the Task Viewer out — personnally I can't see one, because if it's docked, then it's empty.

Okay, just noticed it doesn't animate when popping in...

[pjrobertson]

I'm always keen for a tickle. If you want to try and figure out why it's not working, I know a bit about it whilst I fixed the forever bug with the clipboard/shelf windows sometimes disappearing etc. I think the main thing was to do with canBecomeKeyWindow and resignsKey. Basically it was important to only let the window become key when absolutely necessary.

Since you've rebased nicely, I'll have a play. This doesn't depend on any other PR right? Do we still have any 'PR dependencies'? If so, I'll concentrate on those first

[tiennou]

Please do ;-), it should stands alone now. You can see a side-effect of all that mess in the new toggleViewer: I had to add (does it make you go "WTF" when you read it ? good, because it did when I wrote it ;-)). I can tell that QSWindow is forced to reimplement "hide" itself because the standard "orderOut:" method closes the window, which ought to prevent events like mouse-in/out to be delivered to it, breaking the docking thing. I think there's a better way, but I don't feel like going down QSWindow hierarchy one method at a time and rewrite/document it.

[pjrobertson]

A few minor usability things:

• Do we really need the debug Will show for task NSLog?
• I think the SHOW_DELAY should be shortened. I like 0.05s
• I tried increasing the HIDE_DELAY to 0.4s, since I think the tasks are disappearing too quickly. That didn't solve my problem, since it just causes the window to stay open, even after the task has disappeared. Perhaps the removeTask: code should be dispatch_delayed as well (see note below^)
• The window doesn't seem to have an autosave poision - move it, quit QS, and relaunch - it appears in the original (annoying/behind the QS interface) place

^ The removeTask: methods (in both QSTaskController and QSTaskViewer are confusing me. It seems the QSTaskController one never gets called, the QSTaskViewer one does, since it's called when a QSTaskRemovedNotification notif is sent.

EDIT: I like this:

• Change HIDE_DELAY to 1.0
• in removeTask: wrap lines 171-173 in a dispatch_after block. Means you can see the last task that was run - that's the whole point of the task viewer right?! :P

[pjrobertson]

One more thing:

• If you resize the task viewer to be too small for the task, it stays that way. Should it resize to show the full task? I think automatic resizing should be standard. Why would you ever want the Task Viewer to be bigger/smaller than it needs to be?

[skurfer]

What about my comment on line 103. That should be self.isRunning == YES, shouldn’t it?

[pjrobertson]

Yeah I think you're right @skurfer

[tiennou]

Minor update to that one. I've fixed most things you guys pointed out.

Interesting points :

• I've tweaked the GCD helpers a little (added a delayed variant and noticed this wasn't DRY).
• I've left (some of my) debugging statements in there, in case you want to take a peek at it (mostly the add/remove task ones).
• I got an exception once and only once at soon as I started working, and fixed it by serializing accesses (see b6ae632).

Sadly, that last point creates a visual glitch visible at startup because the QSDelayedScan task finishes before the QSCatalogScan task does, and it still displays through because it's not redrawn correctly when it should, and whatever -setNeedsDisplay: I've thrown at it, I haven't been able to fis that. Now, I'm utterly bored with how this whole window is built/managed, so if one of you guys wants to switch to a View-Based TableView or something, feel free to do so. I'm happy with the low-level changes at that point even though I marked stuff as deprecated and didn't update every place yet. I still have a TODO on subtask-management but hey, it's not like it's used anywhere.

[pjrobertson]

so if one of you guys wants to switch to a View-Based TableView or something, feel free to do so.

I like those as well, so I’ll try and take a look… although I’m bogged with stuff right now, so maybe not soon.

On 17 Chwef 2014, at 00:35, Etienne Samson notifications@github.com wrote:

Minor update to that one. I've fixed most things you guys pointed out.

Interesting points :

I've tweaked the GCD helpers a little (added a delayed variant and noticed this wasn't DRY).
I've left (some of my) debugging statements in there, in case you want to take a peek at it (mostly the add/remove task ones).
I got an exception once and only once at soon as I started working, and fixed it by serializing accesses (see b6ae632).
Sadly, that last point creates a visual glitch visible at startup because the QSDelayedScan task finishes before the QSCatalogScan task does, and it still displays through because it's not redrawn correctly when it should, and whatever -setNeedsDisplay: I've thrown at it, I haven't been able to fis that. Now, I'm utterly bored with how this whole window is built/managed, so if one of you guys wants to switch to a View-Based TableView or something, feel free to do so. I'm happy with the low-level changes at that point even though I marked stuff as deprecated and didn't update every place yet. I still have a TODO on subtask-management but hey, it's not like it's used anywhere.

—
Reply to this email directly or view it on GitHub.

[skurfer]

Should this be reversed to >? Or to put it another way, why do we need animateProgress and indeterminateProgress if they’re identical?

[skurfer]

Is it just the name of the delayed scan that shows through, or would that explain the progress bar problems I see as well?

The position of the progress varies, but it never appears to finish and the list never goes blank. There’s always the delayed scan overlapped with an unfinished catalog scanning task.

Also, the progress bar should be hidden when showProgress is NO. Right now, it’s shown no matter what.

[skurfer]

OK, I’m running with this once again. I know I’ve looked over the code like 3 times, so I’ll just test for real-world functionality.

If it looks good, I’ll also update the NIB deployment targets (unless you want to add that here) and I’ll finally be able to work on adding “run after delay” and “run at time” commands to the task viewer. 😃

[skurfer]

Three years later… Never give up hope!

The change log for this might take the rest of the day.

[skurfer]

If I missed anything in 8636c0e, feel free to push change log updates straight to master.

[tiennou]

I think that covers it all.

[pjrobertson]

wow, awesome work guys!