Page 19 of 26
Re: Tough words about GUI
Posted: 30 Mar 2011 19:42
by TheQwerty
admin wrote:nas8e9 wrote:admin wrote:...will only be available to Pro licensees? Hmmm... was that a joke? Did I say that somewhere?
Per the
roadmap:
- XYcopy 2.0: Kernel based copy with live progress and verification [Pro Version Only]
Huh, wow.

Well, ok, then it shall be so.

I was under the impression that this was saying that verification would only be in the pro version. *shrugs*
Re: Tough words about GUI
Posted: 30 Mar 2011 19:49
by admin
TheQwerty wrote:admin wrote:nas8e9 wrote:admin wrote:...will only be available to Pro licensees? Hmmm... was that a joke? Did I say that somewhere?
Per the
roadmap:
- XYcopy 2.0: Kernel based copy with live progress and verification [Pro Version Only]
Huh, wow.

Well, ok, then it shall be so.

I was under the impression that this was saying that verification would only be in the pro version. *shrugs*
I think I meant all of it. But this is just a business decision. Currently no head for this. I'll see later...
Re: Tough words about GUI
Posted: 30 Mar 2011 19:49
by admin
nas8e9 wrote:admin wrote:nas8e9 wrote:For backgrounded operations, I hope that on Windows 7 the new XYcopy.exe will support the progress indication in its taskbar icon, which for me would be sufficient feedback when working in the main XYplorer window.
If I find an API for this, OK.
Google returns many hits for this, but
these two seem a decent primer.
Good, when the basics are done and working, I'll have a look at the candy stuff...
Re: Tough words about GUI
Posted: 30 Mar 2011 20:08
by zer0
admin wrote:Yes, kernel-based copy functionality will be integrated in XYplorer.exe AND in XYcopy.exe. You can chose whether you want Shell Copy or Kernel Copy when you do a file Copy/Move operation in XY, and whether you want it foregrounded or backgrounded.
OK -- to completely get rid of my increasing confusion -- which permutation of the above would allow me to use kernel-based copy functionality with a progress window that I would be able to minimise/maximise as I please and not freeze the GUI? I think part of my confusion is because currently XYcopy = background processing. But IMO, to background something is to move it to the background visually.
Re: Tough words about GUI
Posted: 30 Mar 2011 20:17
by admin
zer0 wrote:admin wrote:Yes, kernel-based copy functionality will be integrated in XYplorer.exe AND in XYcopy.exe. You can chose whether you want Shell Copy or Kernel Copy when you do a file Copy/Move operation in XY, and whether you want it foregrounded or backgrounded.
OK -- to completely get rid of my increasing confusion -- which permutation of the above would allow me to use kernel-based copy functionality with a progress window that I would be able to minimise/maximise as I please and not freeze the GUI?
Yes.
Re: Tough words about GUI
Posted: 30 Mar 2011 20:31
by nas8e9
zer0 wrote:admin wrote:Yes, kernel-based copy functionality will be integrated in XYplorer.exe AND in XYcopy.exe. You can chose whether you want Shell Copy or Kernel Copy when you do a file Copy/Move operation in XY, and whether you want it foregrounded or backgrounded.
OK -- to completely get rid of my increasing confusion -- which permutation of the above would allow me to use kernel-based copy functionality with a progress window that I would be able to minimise/maximise as I please and not freeze the GUI? I think part of my confusion is because currently XYcopy = background processing. But IMO, to background something is to move it to the background visually.
Currently, there's the Background Bar in the Status Bar to indicate whether background operations are running. Clicking this opens the Background Jobs window listing currently running jobs and if queuing is enabled, queued jobs. Out-of-window so to speak, on Windows Vista and later, the Windows shell file functions called by XYcopy.exe, display a separate, minimisable window which on Windows 7, shows its progress in its taskbar icon. Assuming you're running Windows 7 (you are, according to your sig) and have backgrounding enabled, that should be what XYcopy 2.0 in kernel-based mode, offers as well (depending on whether Don incorporates the progress bar in taskbar icon-eye candy).
The one thing I'd think be a nice improvement, is to have the Background Jobs window list more real-time information about currently running jobs, although I can imagine performance problems with real-time data exchange between potentially several XYcopy.exe instances and XYplorer.exe: since XYcopy.exe is also single-threaded, it may not have enough resources to handle all of the file operation, its own UI as well as the data exchange with XYplorer.exe, while XYplorer.exe having to listen to several XYcopy.exe instances might also be expensive.
Re: Tough words about GUI
Posted: 30 Mar 2011 21:07
by zer0
nas8e9 wrote:Currently, there's the Background Bar in the Status Bar to indicate whether background operations are running. Clicking this opens the Background Jobs window listing currently running jobs and if queuing is enabled, queued jobs. Out-of-window so to speak, on Windows Vista and later, the Windows shell file functions called by XYcopy.exe, display a separate, minimisable window which on Windows 7, shows its progress in its taskbar icon. Assuming you're running Windows 7 (you are, according to your sig) and have backgrounding enabled, that should be what XYcopy 2.0 in kernel-based mode, offers as well (depending on whether Don incorporates the progress bar in taskbar icon-eye candy).
OK, the world is right again then. Too much pasta took blood away from the brain

Re: Tough words about GUI
Posted: 24 May 2011 14:11
by zer0
I like the new live filter feature, but I don't like its placement, look and functions in the GUI.

- list_management.PNG (161.72 KiB) Viewed 3051 times
I would prefer if Editor Mode button is condensed to just Editor and moved along the right side with the rest. This would allow for the filter box to line up in the bottom left hand corner. Also, I would suggest the following:
a) Make its dimensions be 125x24 (WxH) as that's what's recommended.
b) Move the magnifying glass to the right edge to give space on the left.
c) Have "Type to filter" prompt text in the box for clarity of functionality.
d) Have "No items match your filter" as caption when a filter doesn't show any items.
Re: Tough words about GUI
Posted: 24 May 2011 14:47
by TheQwerty
zer0 wrote:I would prefer if Editor Mode button is condensed to just Editor and moved along the right side with the rest. This would allow for the filter box to line up in the bottom left hand corner.
While I agree it should be left aligned and bigger (and also don't have any issue shortening the caption to Editor), I'm not sure moving the button to the right is good either. Recall that this dialog is reused for all lists and there is sometimes a "Tips..." button to the right of the "Editor" button (check Color Filters), so that would mean four buttons in the right corner which seems a bit too cramped and busy.
Plus, "Editor"/"Tips" have very different usages than "OK"/"Cancel" and placing them close to each other increases the likelihood of accidentally clicking the wrong button and committing changes when you meant to enter the Editor.
I'm more of the mind that the list box should be embedded in a tab control with two tabs one for the list control and one for the edit control.
The Tips button should be converted to a small image button (like the orange arrow in the Raw/Preview tab), and I'm thinking moved to the right side of the white header or to one of the right-side corners.
Then the filter field could be the nearly the same width as the list, and it probably makes sense to make the window a little wider so that the widths do match.
At that point the magnifying glass could stay on the left in an attempt to get the input text to line up with the list text (ie be the same width as the number column).
zer0 wrote:a) Make its dimensions be 125x24 (WxH) as that's what's recommended.
By whom?
Re: Tough words about GUI
Posted: 24 May 2011 15:37
by j_c_hallgren
TheQwerty wrote:zer0 wrote:I would prefer if Editor Mode button is condensed to just Editor and moved along the right side with the rest.
While I agree it should be left aligned and bigger (and also don't have any issue shortening the caption to Editor), I'm not sure moving the button to the right is good either.
Plus, "Editor"/"Tips" have very different usages than "OK"/"Cancel" and placing them close to each other increases the likelihood of accidentally clicking the wrong button and committing changes when you meant to enter the Editor.
I think the "Mode" is needed to better clarify what it does for new users.
And I agree w/TheQwerty's reasoning for why it should stay isolated from the other buttons...because it's not
what you're doing to the list but
how you're doing it.
Re: Tough words about GUI
Posted: 24 May 2011 16:09
by zer0
Up/Down buttons can be converted to arrows and put side-by-side. This would free up space to shift Sort up and Editor in its place.
TheQwerty wrote:zer0 wrote:a) Make its dimensions be 125x24 (WxH) as that's what's recommended.
By whom?
By Microsoft's user experience guidelines.
Re: Tough words about GUI
Posted: 24 May 2011 16:58
by TheQwerty
zer0 wrote:By Microsoft's user experience guidelines.
Care to link to where this is addressed, I'm not having any luck finding it.

Re: Tough words about GUI
Posted: 24 May 2011 17:14
by zer0
TheQwerty wrote:zer0 wrote:By Microsoft's user experience guidelines.
Care to link to where this is addressed, I'm not having any luck finding it.

No problem. Here is the link:
http://msdn.microsoft.com/en-us/library ... spx#sizing Bear in mind, it talks about search boxes. However, since we're searching through a pre-existing set of data for results that match a pattern, it's essentially the same principle.
Re: Tough words about GUI
Posted: 24 May 2011 18:03
by TheQwerty
zer0 wrote:No problem. Here is the link:
http://msdn.microsoft.com/en-us/library ... spx#sizing Bear in mind, it talks about search boxes. However, since we're searching through a pre-existing set of data for results that match a pattern, it's essentially the same principle.
Ah, I missed the Search Box entry. Thanks!
I agree then that makes sense, as do many of the other suggestions.
Though note that you mixed units earlier - they suggest 125 x 15 DLUs.
While we're on the topic of the List Management dialog, I think everyone is in agreement that they should all be combined into a single dialog, right? One dialog where you select which list you want to view/modify instead of a long menu of options that you have to jump back and forth with.
What is everyone's thoughts on how List selection should be handled? Like CKS where the Lists are in a drop-down or list Configuration with a list of lists on the left-side?
Re: Tough words about GUI
Posted: 24 May 2011 18:21
by zer0
TheQwerty wrote:While we're on the topic of the List Management dialog, I think everyone is in agreement that they should all be combined into a single dialog, right? One dialog where you select which list you want to view/modify instead of a long menu of options that you have to jump back and forth with.
I have been bashing about this for quite some time. In fact, it was one of my original complaints a year and a half ago that started this thread (
http://i49.tinypic.com/m8k192.png)