hi it's me again
i just wanted to say something about two of the requests that i am agreeing with, the conflicts box and the sticky tabs.
1.) conflicts box. i know that this has been proposed several times, but i just wanted to add to the suggestion. one of the major selling points of opus is that it can do many threads such that a lister can still be used while some other job is being
taken care of. i think that this can be applied to a conflicts box. it has been requested that a list popup or is shown
after the end of a copy/move/delete, or in some cases before it. i think this is a good idea, but i think that what i would like is a conflicts box that updates dynamically, perhaps in the background.
the end user would have some preference that would say, defer a instance as 'conflict' after x seconds. let's say you are trying to move a great many things. in the middle of the transfer a box would appear asking you what to do. if you are at your computer at the time, you can simply say what you want done and that is all. if you are away, however, you don't have that luxury. the x seconds timer would count say, 10 seconds, and that window would be open asking for what to do (rather than automatically defer just in case you are brb and not afk) and if the end user doesn't say what to do, mark it as conflict and move on until the next conflict.
now, in the x seconds 'timeout' box (i think the timeout is one really important thing) one can put a '0' which would tell opus to not wait at all and automatically defer as conflict, don't even bother to ask the user. this mode could be very useful and it would be nice to have a separate timer for: network transfers, local transfers, ftp, removable drives, etc. the timer would tell the box to wait for 0, 10, 15, or what ever the user specifies in the box.
the real thing that i would like to suggest is that the conflicts NOT be some list. i don't think it should be a simple list of conflicts that have to be taken care of; i think that it should be a dynamic, ever updating list of conflicts. this way there is no matter of 'do i display it at the end of the transfer or the beginning or in the middle.' as soon as there is one conflict there is a list. no conflict, no list. no timeout, no conflict.
should there actually be a 'conflicts box'? i dunno. i was thinking there could be a separate box JUST for conflicts that the user can address in an order picking one here and there until empty. it could just be a button 'show conflicts' on a regular copy dialogue. i was thinking though, that the conflicts box would best be a tab in the output window that updates in the background, or if the user specifies that pops up on first conflict. whether or not the conflicts output tab/box/whatever pops up would be up to the user, but one thing that would always happen is this: the regular transfer bar is normally green, perhaps orange when prompting the user for input, finally red if there is at least one conflict. also, if there is at least one conflict, the transfer window will stay open so the user can see the red progress bar. when the user sees this, he or she can perhaps double click the red conflict progress bar and have the output window open automatically to the conflicts tab.
what happens next? well, since conflicts would appear in the output window as they happen, they can be dynamically address EVEN while the parent transfer is occuring, or a selection could be made and the handling of the conflict can be queued to the end of the current job (good for ftp i think). since this is not a simple list of things that couldn't finish, there would be more information in the conflicts tab/box. this information should(?) include things like when the conflict happened, what was the destination, what was the source folder, but most importantly WHY it conflicted. oh, note that i am using conflict for any event that had to be deferred for any reason. the reason why i say WHY it conflicted is important is this. perhaps there could be an implementation of automatic handling of the major causes of a need for deferment. one could have it automatically rename if it's 'something already in that folder with that name' is the reason, or automatic overwrite if is same name, but the new file is larger, or any ruleset that can be applied automatically OR by input from the user as he or she browses the conflicts in the window. there needn't be any reason to have to handle the conflicts in the order in which they happened this way. in fact, they could even be numbered by opus itself such that new opus commands could be made like: Conflict REASON ALREADYEXIST DELETE or Conflict NUMBER 1 MOVE.
The conflicts could be saved for opus itself as an xml file dynamically written as they occur, displayed for the user when the conflicts tab is opened and exported as a batch file later on. also, one can just double click a conflict one by one, in any order to get a standard rename/copy/whatever box come up since the actual file transfer was skipped (if that's the last file in a folder, delete folder could be a checkbox, too).
if the user fails to clear conflicts before starting another copy/move/rename/whatever process related or unrelated to the current requested job, then opus can notify the user with a sound or flash WHILE still allowing the current job to continue. or the progress bar could be red from the start signifying that conflicts still need to be addressed. also, one can opt to 'ignore' a conflict to have it removed from the conflicts tab/box/window so that it being there will not affect the color of another transfer job bar at all if he or she whishes.
i feel that since opus is about flexibility, this would be a so-so implementation of something that i know at least i would like. this way would provide a meaningful, convenient way of handling conflicts in one's own time in one's own way in one's own order without being bogged down by a hardcoded lists, or chunks of untransfered files stranded behind one that didn't know where to go.
in short:
[] the user can set a timer. as soon as the 'what do you want me to do' window that we are all familair with appear, the timer starts. this timer needn't be visible to the end user, opus uses it. while this timer counts down, the progress bar halts and turns orange. once this timer counts to zero, the bar turns red, the conflict is skipped and deferred to, perhaps, a new tab in the output window called 'conflicts'
[] since the conflict has been deferred, not really 'skipped' since the user can, at any moment of whim simply go to the conflicts tab and address it EVEN while current job is running (if it's ftp, the user's request can be queued if need be). there is no 'list' that appears at the end of a job, just a dynamic running list of conflicts, addressable in any order the user sees fit.
[] since the conflicts would be datestamped, the user could leave them as conflict for as long as he or she wants and still come back later to address the issue (most prolly won't wait, but to know one COULD is nice).
[] to aid the user in seeing that conflicts exist and are being tallied in the background, the progress bar turns red. at any time the progress bar, or some button, or the system tray icon, can be double clicked to bring up the conflicts tab. if conflicts are not address before the end of a job, the progress bar remains open, perhaps pulsating red to get the users attention.
[] conflicts can be ignoreed and removed from list as user wants.
[] conflicts in list can be sorted by reason, time, date, locations.
[] a event can be tethered to a conflict reason to automatically, if the user pleases, handle the conflicts on its own. these events can be set by user, or come predefined. such as 'if conflict is reason: already exist AND smaller, automatically overwrite (or in the case of ftp) or resume
[] i forgot some other things
2.) sticky tabs. i lvoe this idea so much. i was thinking, if you see my thread about other stuff i would like, that the sticky tabs can be put together with 'favorites groups.'
the favorites groups is an idea that i think i came up with that combines many different already exist opus features into one in a way that i feel would be quite useful, not at first to many, but eventually. like if you wanted a certain wallpaper to be in all folders in the 'Beatles' favorites group, it would be done. but read that thread for more, verbose ; ; , about this.
back to sticky tabs. even if the 'favorites groups' idea never happened, i agree with all who suggested before me that it's a great idea. i also think it would be nice to have a small mini icon overlay (think the little arrow thing on shortcuts) that appears in a sticky tab's icon. this overlay could be a 'do not' sign (the O with the / in it) or a sticky goo or w/e. the tab overlay icon could be one color, say grey or blue, if a tab is 'loose sticky' meaning you can browse in it, but if you leave that tab it will go back to the folder that was stickied. another color, say red, if a tab is 'super sticky' such taht any attempt to use this tab to browse will automatically spawn a new tab populated by the desired, clicked folder.
these states could be toggled by perhaps right clicking on the tab's icon (if you hold right, you could get the current tab menu, or you could just right click any nontabbed area of the tabbar).
that's my take for now, i hope i haven't typed too much, thanks for reading! hope to see you all again~
