Unable to acess Status Log

[zer0]

Encouraged by a "pimped up" look of XYcopy's Status Log, I have not been able to access it as it keeps being greyed out. "Background processing" and "Queue File Operations" are enabled, I shuffled a few files about for the sake of testing but that context menu entry is still the same status Is something else needed for "Status Log" to be enabled?

P.S. "Triggered" should be replaced with "Started". Just sounds better and is the direct antonym of "Completed"

[nas8e9]

Encouraged by a "pimped up" look of XYcopy's Status Log, I have not been able to access it as it keeps being greyed out. "Background processing" and "Queue File Operations" are enabled, I shuffled a few files about for the sake of testing but that context menu entry is still the same status Is something else needed for "Status Log" to be enabled?

Can't reproduce. Just to be sure, you copied/moved files outside of the originating partition or in UI terms, you did see XYcopy's icon appear during these operations?

[zer0]

Can't reproduce. Just to be sure, you copied/moved files outside of the originating partition or in UI terms, you did see XYcopy's icon appear during these operations?

Ah, you have nailed it. It was an intra-partition move. It turns out that Status Log isn't created for that. Shame, as it means that I have to go do Action Log and doesn't have the useful info that Status Log has

[nas8e9]

Can't reproduce. Just to be sure, you copied/moved files outside of the originating partition or in UI terms, you did see XYcopy's icon appear during these operations?

Ah, you have nailed it. It was an intra-partition move. It turns out that Status Log isn't created for that. Shame, as it means that I have to go do Action Log and doesn't have the useful info that Status Log has

Personally, I find the Action Log to be more informative than the Status Log in that it lists the item name. I'm hoping that XYcopy 2.0 will somehow merge the two logs, depending on whether all file operations (including deletes and intra-partition moves) are handled by it.

Edited to add: The Status Log only logs XYcopy's work. Since deletes and intra-partition moves are not handled by XYcopy, they don't appear in the Status Log.

[zer0]

Ah, there is a bug there after all! Status Log appears to show status of file queue at the time of being called and doesn't update in real-time. Granted, it doesn't say that it is supposed to be real-time, but it doesn't say it's not real-time either and Status Log's information is a lot more relevant if it's actually correct

[nas8e9]

Ah, there is a bug there after all! Status Log appears to show status of file queue at the time of being called and doesn't update in real-time. Granted, it doesn't say that it is supposed to be real-time, but it doesn't say it's not real-time either and Status Log's information is a lot more relevant if it's actually correct

If I understand you correctly, the word Status implies a real-time view of operations (which it doesn't do) whereas the word Log is correct because it (merely) records XYcopy's activity.

If I were guessing (and guess what, I am ), I think the name Status Log could be renamed to XYcopy or Queue File Operations Log, with a real-time status view only fully possible when XYcopy 2.0 (with the hand-rolled kernel file functions allowing much greater control and real-time feedback) comes along. I guess with XYcopy 1.0, at completion time the Status Log could update the time completed when still open, but given XYcopy 1.0's limitations I'm not sure it would be worth the effort.

In short: Status Log may be a slightly incorrect name at present, but it's currently probably only a diagnostic tool for XYcopy. The Action Log logs everything, whether queued or done immediately and is the place to get a view of what actions are taken (and optionally to undo those actions). From that perspective, I wouldn't assume a bug personally. Just my $0,02...

[zer0]

It could be a matter of calling it better but, with no "Refresh" button, I really don't fancy closing and re-opening it to check how the queue is doing. If I can have it open while file operations are happening in the background then it is logical for it to provide real-time info. If it not currently [technically] possible to have it real-time then that's one thing, but if it is then I'd say it's a bug as that's the best-case function for Status Log.

[nas8e9]

It could be a matter of calling it better but, with no "Refresh" button, I really don't fancy closing and re-opening it to check how the queue is doing. If I can have it open while file operations are happening in the background then it is logical for it to provide real-time info.

I agree that a queue *status* window as you describe would be useful even with the current limitations of XYcopy 1.0. Having such a window non-modal would seem to be an improvement for such a use case.

If it not currently [technically] possible to have it real-time then that's one thing, but if it is then I'd say it's a bug as that's the best-case function for Status Log.

It seems Don is currently in marketing rather than programming mode; only he can answer what can and cannot be done. I believe XYplorer only gets start and completion information from the Windows Shell. Propagating that information to the opened status window may be possible.

[admin]

Replying from marketing mode:

1) Triggered > Started. Yep, good idea.

2) Live and non-modal Status Log: should come with XYcopy 2.0.

3) Better name for the current static "Status Log". With pleasure, but I have no idea...

[nas8e9]

In (slightly unfortunate ) Monday morning mode:

3) Better name for the current static "Status Log". With pleasure, but I have no idea...

The window title of the Status Log is currently Status of Background File Operations, which is a bit long for the context menu of the toolbar button, I guess. Since this window can list both scheduled, in-progress as well as completed operations (any of which may be queued), the name Status Log could be seen as a contraction of Status view and Log? I guess the Status Log simply does too much to name it easily...

OTOH, completed jobs also have a status. Would "Status view" suffice?

[admin]

In (slightly unfortunate ) Monday morning mode:

3) Better name for the current static "Status Log". With pleasure, but I have no idea...

The window title of the Status Log is currently Status of Background File Operations, which is a bit long for the context menu of the toolbar button, I guess. Since this window can list both scheduled, in-progress as well as completed operations (any of which may be queued), the name Status Log could be seen as a contraction of Status view and Log? I guess the Status Log simply does too much to name it easily...

OTOH, completed jobs also have a status. Would "Status view" suffice?

New food for thought: I just made it live and non-modal.

Is "Status view" still the preferred choice?

[nas8e9]

New food for thought: I just made it live and non-modal.

Wonderful! In terms of accessing it, would something like Firefox's Downloads window be an idea: when backgrounded file operations are active, text in the status bar would say something like "x jobs pending, y running, z completed". When single-clicking this text, the Status view window would pop up.

Is "Status view" still the preferred choice?

I'm curious what others will make of it. It feels more correct than Status log to me.

[admin]

New food for thought: I just made it live and non-modal.

Wonderful! In terms of accessing it, would something like Firefox's Downloads window be an idea: when backgrounded file operations are active, text in the status bar would say something like "x jobs pending, y running, z completed". When single-clicking this text, the Status view window would pop up.

Is "Status view" still the preferred choice?

I'm curious what others will make of it. It feels more correct than Status log to me.

I don't think the Status Bar should be bothered with this -- it would conflict with its other duties.

I also prefer Status View.

[nas8e9]

I don't think the Status Bar should be bothered with this -- it would conflict with its other duties.

I'd personally like to have abbreviated status information accessible from the corner of my eye (i.e. without having to open the Status view to get the full picture); the status bar seems the logical place for it.

In terms of impact on its current duties, the status bar currently has three sections, all of which are left-aligned. By adding a fourth section in the right-most corner and keeping it small (for instance, something like "P: x, R: y, C: z" with the text "Idle" when there are no operations) and having a tooltip explaining and possibly expanding this info, impact on the rest of the status bar seems minimal to me while adding control. When backgrounding is disabled, this fourth section could disappear.

Edited to add: Regardless of whether the status bar would allow access to the Status view, it's currently awfully well hidden (you need to add a toolbar button, which you then have to right-click). Making it more discoverable might be a good idea. My preference would be the way described above, of course.

[admin]

I don't think the Status Bar should be bothered with this -- it would conflict with its other duties.

I'd personally like to have abbreviated status information accessible from the corner of my eye (i.e. without having to open the Status view to get the full picture); the status bar seems the logical place for it.

In terms of impact on its current duties, the status bar currently has three sections, all of which are left-aligned. By adding a fourth section in the right-most corner and keeping it small (for instance, something like "P: x, R: y, C: z" with the text "Idle" when there are no operations) and having a tooltip explaining and possibly expanding this info, impact on the rest of the status bar seems minimal to me while adding control. When backgrounding is disabled, this fourth section could disappear.

Edited to add: Regardless of whether the status bar would allow access to the Status view, it's currently awfully well hidden (you need to add a toolbar button, which you then have to right-click). Making it more discoverable might be a good idea. My preference would be the way described above, of course.

I'll meditate about it...

Edited to add: A nice place for corner of the eye info could be the titlebar of the Status View window, which is now visible in the taskbar.