I believe the ZEPs below are mine, but surely some must have been inspired by the fine folks over in the ZTree forum. These ZEPs reflect my established patterns of ZTree usage.
Contents |
Removing this XTree legacy would give a more consistent and logical UI. For example, it is not present (and not missed) in the Viewer.
Contents |
Hitting F9 followed by Ctrl+% would considerably outperform the (sometimes slow and ambiguous) first-letter navigation.
For example, I currently publish all my web contents from a script called "Web publish %1", to which I navigate with a few 'W' hits. However, there is no guarantee that another item starting with 'W' will be eventually created (this had actually happened in the past). Having a rock-solid Ctrl+W bookmark would instantly solve this problem and allow a simple macro (F9,CTRL_w,RET,FTPpassword,RET) to implement "1-key web publishing".
Contents |
The extremely useful ordinals display in DW and FW would come handy in F9 as well. Some expanded menus can be very long, and knowing the approximate location of an item could help. When combined together, item contents may go beyond thousands of lines, with no easy way to reach them. My main .ZDB file has close to 9000 lines when viewed with the Viewer and with the Line option activated.
I propose an F9 ordinal display in the usual place, but with the following format:
item#/line1#-line2#
where item# starts at 1 (the root item) and behaves exactly as in DW -- it's recalculated as branches are expanded and collapsed. It may change at any time.
The line1#-line2# range part that follows should correspond to the absolute line numbers occupied by the item's contents. All scripts are actually segments (a range of lines) from the currently open ZTW.ZAM, and we are here to pinpoint those lines. (Note: ZTW.ZAM is not a pure text file, although it is perfectly viewable in View. All lines can be seen in Alpha mode as numbered when the Line option is on, but many of these "lines" are binary control data. We need to determine how to actually reference these lines with acceptable precision.)
Once the ordinals display is in place, the problem of searching the current F9 can be solved relatively easily, for example, from within F9 (or using eXecute, or View/Searching on ZTW.ZAM directly):
It's still largely manual, though. Therefore, we should strive for a more elegant solution to the problem of locating text in F9 that does not rely on ordinals or any special mental effort.
Contents |
With no Split, we see why the second border exists: F9 is inserted into the main DW or FW pane, leaving the STATS pane visible. Here, the extra border makes more sense and is visually acceptable -- it is clear to the user that the F9 window has been displayed inside the DW or FW left pane. It also fits in nicely.
Still, even here the extra border could be eliminated without confusing the user in any way -- on the contrary. There is no extra border in DW and FW after all, so why should there be one around F9? The F9 window could snap into the exact same area as DW and FW, not as an embedded window.
The possible benefits are: somewhat more visual consistency and a gain in screen estate, notably: two full lines for two more menu items to be visible!
Contents |
Contents |
1. Insert item description
2. Insert item contents
3. Insert both (item description followed by the contents)
Currently, the only way to this is with the mouse, using a file, or, while editing a line, selecting it and using Ctrl+C -- it's slow and boring when done more than a few times in a row...
This would somewhat overlap with the already powerful 'Copy item', 'cOpy scrap' and 'Write > F4 Copy to Clipboard' functions, but would be very consistent with the overall ZTree UI. In addition, F9 being somewhat specific, the stage would be set for inserting other F9 objects into the Clipboard.
Contents |
Extending this set to include more printable characters would automatically add more ways of organizing and accessing menu items. (more...)
For example, the user could dedicate special characters to marking different groups of scripts and allowing instant access to them. Rarely used (or hard-to-enter) characters could be used to protect the scripts from accidental access, etc.
Certain characters could be reserved by ZEDTEK for special, future enhancements. For example, items could become non-editable, non-executable, hidden, encrypted or otherwise used by the database system...
Contents |
Such items would clearly stand out as comments and attract special attention -- or be ignored, depending what one is doing at the time. These items could be either in a different color, or low-lighted (dimmed).
Contents |
Implemented as #ZTmenu and %#ZTmenu%
A variable named #ZTdb (or #ZTdatabase, #ZTdbname) would allow
a database creator to give the database a unique, internal name.
When a database is loaded, this value becomes available to all scripts in that database, so the scripts will know exactly that they are part of, say, MAIN.ZDB, JOKES.ZDB, TUTORIAL.ZDB, and so on.
This is a user-defined variable, unlike the automatic #ZThome or #ZTdrive ones generated by ZTree.
Active databases are all (currently) associated with a single ZTW.ZAM file. When a database is saved, it is always to ZTW.ZAM, making it easy to lose work. This new token would make the following script code possible and very practical:
--------------------------------------------------------------------------
|
This will make database switching more reliable, because all databases can reside in their own disk files. The last database used will always be in #ZThome\ZTW.ZAM and be opened by default, so it may be wise to think of #ZThome\ZTW.ZAM as a volatile, temporary, database.
Contents |
(Of course, the benefits are best seen by those users who organize their tool collections under a single directory branch!)
It is in this area the scripts would look for non-standard utilities (those not found down the standard PATH variable or otherwise). These include archivers, editors, converters, formatters, filters, unix-like tools, etc.
All advanced users tend to accumulate such programs, but there is no agreed upon standard location. Thus, path hard-coding in every single script is often unavoidable. Script portability and database sharing would be less painful if this variable existed.
The reason that not many databases are being shared is the enormous work needed to adapt them to each user's environment.
Since user-defined variables would be defined only once in a given database, such adaptation and script maintenance would become trivial.
#ZTtoolspath (or #ZTtools) could thus be compared to the %ProgramFiles% environment variable of the F9 system.
Implemented as #ZTtools and %#ZTtools%
Contents |
We must think of a way of defining the proposed user variables (such as #ZTdb and #ZTtoolspath) conveniently.
One approach could be to reserve the very first script (or one with a reserved name) as the database "header". Whenever F9 is opened, this script would always be parsed and the variables found there initialized.
The user would edit the "header" script as usual, but executing it manually would never be needed -- ZTree will do it anyway.
In addition to providing the two proposed variables (#ZTdb and #ZTtoolspath), a generic mechanism could be set up to allow the user to define maybe 5 or 10 other variables. These strings would then be used in scripts just like all other #ZTxxx tokens, boosting portability, sharing and simplifying modifications. (more...)
--------------------------------------------------------------------------
|
Note that the hypothetical "Upload active database to web server" script that exist elsewhere in the database will know how to connect to the FTP server (#ZTuser7) using the access information (#ZTuser1 and #ZTuser2) and the name of the file to send (#ZTdb). This script can be totally generic, because it is driven by external parameters, all residing in the startup script.
Note also that (provided F9 bookmarking gets implemented) the user just needs to hit Ctrl+W (or some other key) to activate the script that will handle sending the current database anywhere while the user continues to work on the database without leaving the F9 environment.
Contents |
"C:\Documents and Settings\user\My Documents"
"C:\Documents and Settings\user\Desktop"
"C:\Documents and Settings\user\Favorites"
"C:\Documents and Settings\user\Start Menu"
or some other subdirectory in the home tree. However, this does not work across language variants, making F9 scripts non-portable. In addition, earlier Windows versions (95, 98) do not even implement %USERPROFILE%.
A certain number of tokens of the #ZT[userdir] type (#ZTmyDocuments, #ZTmyDesktop...) would eliminate large chunks of code used to determine where the most common user files reside. A reliable value, generated directly by an API, would be a of great help. (more...)
Implemented: #ZTDesktop, #ZTFavorites, #ZTMyDocuments, #ZTStartMenu
Contents |
This technique for generating unique file names (for example, 20040326_1833_Tue.LOG) is used frequently, and the code often takes a larger part of the script! This would help script writers a great deal, because time formats tend to vary greatly from version to version, and locale to locale.
A few more date related tokens could be added for completeness: #ZTdow, #ZTdoy, #ZTmoy.
Using #ZTdow (Day of Week) may be used to control tasks that should not be performed on days other than Friday, for example: IF NOT "#ZTdow"=="Fri" GOTO EXIT
Tokens #ZTdoy (1-366) and #ZTmoy (Jan..Dec) may come handy as well...
Contents |
Replicating this type of code in many scripts within the same database is currently mandatory and indispensable, for proper functioning and script portability. A reliable value, generated directly by an API, would be a of great help.
Contents |
Currently, managing F9 user "databases" (a collection of *.ZDB files) is achieved with external tools and creative use of F9 and shell scripts.
But this may be risky and time-consuming, and probably the reason why most users never venture into exploring the immense possibilities offered by this unique feature. It would be nice to make these management tasks available naturally and safely from within F9.
In fact, there are only a few operations (creation, switching, searching...) involved, and they could be grouped behind an option added to the F9 bottom menu. A key (F2, for example) could be assigned to open this sub-menu.
Another option is adding a standard CTRL MENU COMMANDS, to match the same UI mechanism found in FW and DW. This second choice would follow nicely the consistency of the UI, but the vastness of the Ctrl+% class of keys could be put to better use in the future: bookmarks to a large number of favorite items!)
Possible options in the proposed Database Management sub-menu:
There would be a new option added to View (visible only when ZTW.ZAM is loaded!), that would essentially say: "Go to F9 and select the item that contains the current line". Thus, browsing ZTW.ZAM would be similar to browsing a web page: hit Ctrl+F9 (or some other key) to immediately find yourself in F9 with the current item selected.
Furthermore, Alt+F9 could launch F9 followed by Alt+E, with the cursor already on the line in question, ready for editing!
Contents |
On a daily basis, users need to spend time coming up with temporary directory names when performing tasks like downloading, extracting from archives, installing new products, etc. Because one's attention is elsewhere, this often results in a messy disk organization.
It would be useful for the Make command followed by Enter to create a default directory name, similar to Explorer's "New Folder". But the name should be more useful and meaningful -- "yyyymmddhhnnss", for example. Also, if the new directory is immediately brought into focus, it can be ready for renaming and further work.
This has many benefits: time is saved; even if not renamed, the new directory will reflect the moment it was created; it will sort very well with other such temporary directories next to it. Such names would also serve as reminders that we have unfinished work to do in those directories, which is not easy to spot with names like "x", "temp", "new", "download", "kit", "test", "New Folder"...
Contents |
Contents |
Split Mode: Statistics None Current Both (None )
UnSplit Mode: Statistics Yes No (No )
One of my older ZEPs (from 80-column days) is optionally hiding the Attr column -- months go by between me looking at them as I don't use them for backups or anything else. If you are dealing with network drives, DVDs, etc., they are not really useful and just take up space. Optionally suppressing them from view would gain 5 more columns. Hence, the above ZEP could be extended to:
Split Mode: Statistics None Current Both (None ) Attributes Visible Invisible (Invisible)
UnSplit Mode: Statistics Yes No (No ) Attributes Visible Invisible (Invisible)
Contents |
But in addition to today and yesterday, our lives and activities are strongly delimited and influenced by weeks, months, years, and other intuitive, culturally established, date units. There is no reason why huge amounts of files living on our storage media should not be instantly selectable by those date units as well, when so desired. The feature of selecting and grouping by date (age) is not uncommon in various other tools.
However, TODAY can not reliably reference a time range like "since start of week", since TODAY-N must be changed every 24 hours to remain valid. In addition, the week notion is ambiguous and depends on culture, so there should be a way for users to configure this concept as they please.
Similarly, month and year beginnings currently need to be hard-coded as yyyy-mm-01 and yyyy-01-01 and updated when changes occur (every month). This is extremely risky if an automated procedure depends on this value, and not simply a question of the user being too lazy to type in a new date string once in a while.
Examples of new tokens that could solve this potential risk and make date filespecs saved in histories permanently valid and safe for automation could be:
"week" (SUNDAY seems a good choice, allowing referencing all other days easily with SUNDAY+N)
MONTH (start of current month)
YEAR (start of current year)
This would allow Filespec bookmarks like
T *.*,-*.TMP,>s0,=TODAY
M *.*,-*.TMP,>s0,>=MONTH
Y *.*,-*.TMP,>s0,>=YEAR
W *.*,-*.TMP,>s0,>=SUNDAY+1
to be permanently stored in history.
Date tokens are not simple text shortcuts, but dynamic variables with all the advantages this brings, like programmability!
Macros could grab these entries and perform monthly/yearly archiving, synchronization, searches, etc. For example, it would be trivial to write a macro to ZIP all files from the previous month (and older), then move/delete them, leaving only files less than thirty days ago. Currently, no such macro is possible.
Simple date arithmetic that works with TODAY, should work with the above tokens as well, where it makes sense.
ZTree's New date command allows HH:NN:SS stamps, but the Filespec date specification does not go below 24 hours. Rather, all explicit dates and TODAY default to 00:00:00, as would the proposed SUNDAY, MONTH and YEAR. Hence, if HH:NN:SS is ever introduced into Filespec, the tokens will not break anything.
As a side-effect of enhancing coloring (of file extensions only), ZCOLORS.INI now permits coloring by date (and size) filespecs as well. This allows a visual grouping by date, similar to what Outlook and some other tools do. For example:
; ZCOLORS.INI =TODAY:Bri Cyan ; Today >=TODAY-4:Yellow ; "week" -- must edit daily >=2009-02-01:Bri White ; month -- must edit monthly >=2009-01-01:White ; year -- must edit yearly
Here too, hard-coded date filespecs could be eliminated by using date tokens, thus sparing the user from periodically editing what should be a static file.
; ZCOLORS.INI =TODAY:Bri Cyan >=WEEK:Yellow >=MONTH:Bri White >=YEAR:WhiteRelated: ZEP014: #ZTyy, #ZTyyyy, #ZTmm, #ZTdd, #ZThh, #ZTmin, #ZTsec
Contents |
Sorting by color is a natural way of file grouping by yet another criterion, without touching the current filter and other conditions. I saw this decades ago when color appeared on the Mac and still dream about it in my daily work...
To complement Sorting by color, Filtering could also be enhanced to select only objects of certain color(s), giving the user a new file organization playground. Color is the only user-assigned attribute in ZTree, so why not allow Sorting, Filtering, Tagging, etc. based on it?
Another example: I color junction points (dirs) magenta, but it's next to impossible to locate all of them and show in a list. If I could Sort by color, they would appear next to each other instantly. Better yet, if I could Filter/Tag for the "Color=magenta" condition, I could automate the task with a macro.
Web 2.0 is all about hashtags, ZTree is halfway there with "colortagging"!
Contents |
Of course, even a single command line can often be considered complex code, due to the large number of cryptic options and parameters, piping, redirection, and so on. Just consider archivers and their command line switches.
In ZTree, macros allow simple comments (using the STOP directive), and F9 is ideal for documenting almost anything. Filespec also allows the wonderful "PICS: *.jpg, *.gif, *.tif" commenting construct!
But history entries for Batch, Rename masks, and possibly other commands, do not allow comments, forcing the user to often wonder what an entry exactly does, or sacrifice a history slot to document an adjacent one (which, of course, is no longer adjacent after execution).
Note that in case of eXecute, it is possible to append a "& REM blah blah" or "& :: blah blah" to the command line, so this is taken care of. (Thanks Liviu!)
However, there is no reason to not allow trailing comments (of the "user input ... // comment ..." or similar type) to be entered by the user and stored in all command histories globally. Since '//' may be used by Rename, a better separator is needed.
Before the command is executed, the comment part would be stripped off, so the commands would work just as today, but the user will finally know what some of the obscure, forgotten, entries actually do.
(My experience with OpenVMS command language, DCL, has convinced me of the utmost importance of commenting every single line (if needed, of course). No other shell language seems to offer this, leading to the well-known unix (s)hell, which, among other flaws, does not allow adding a trailing '#' to commands. It only works at the start of line...)
Contents |
This same problem exists in the Windows Command Prompt, but here two possibilities exist:
1. Using the mouse on the scroll bar
2. Alt+SPACE,E,L to invoke a deeply hidden option that
enables arrows and PgUp/PgDn to function as scroll keys.
Neither is acceptable: professional terminal emulators usually have keys like Ctrl+ARROWS and Ctrl+PgUp/PgDn pre-wired for this.
Would it be possible to add this feature to ZTree's eXecute?
This could be a feature where it wins over the "DOS box" hands down, and could attract certain power users who must work in command line extensively. Imagine, no more mousing around and forgetting about "| MORE" or "| LESS"?
Contents |
However, it is often necessary, as in all other programming languages, to embed comments. A pair of tokens like COMMENT_START/COMMENT_END, or some other (preferably shorter) string pair, would tell the macro processor to ignore anything in between.
ZTree allows placing comments in .ZTM files by placing a ';' character
at the beginning of a line. This solves the problem of commenting
long and complex macros, which should probably be stored in files,
rather than executed in direct mode.
ZEP401: IF_W95/IF_W98/IF_NT/IF_W2K/IF_XP
There are subtle differences in Windows versions that may break
certain macros. For example, the "C:\...\Profiles" directory is "C:\Documents and Settings" in W2K and later.
Detecting the correct OS version will help create more portable macros.
ZEP402: CONFIRM_ON|OFF
This would override the Configuration preference for
confirmation in Rename and similar operations, making the macros more portable. In fact, CONFIRM_ON does
not make sense in macros, because the number of keystrokes for Yes or No is unknown; all depends on
the user's decisions at the time of macro execution. Macros, by definition, must have all the answers
already prepared in the macro stream. Hence, any interaction with the user should be delegated to
external programs (eXecute) or the application menu (F9).
ZEP403: SAVE/RESTORE
These directives would save/restore the current state of
ZTree. For example, SAVE,SPLIT,...,RESTORE would make sure that the split mode
is restored to the original state after the macro exits.
ZEP404: More directives
Contents |
In other words, starting the macro execution with F12 (and Alt+F12) forces the repeat counter to 1, whereas Shift+F12 allows for increasing this number. If the user enters "t" or "T", ZTree will set the counter to the number of tagged files -- if there are none, no action will be done, of course.
Note: If, for some reason, Shift+F12 is not available to ZTree, another approach, consistent with ZTree, could be used: an option could be added to the F12 menu (similar to the already existing F3). For example, the option may look similar to F4: 1 time(s). Pressing F4 would prompt the user for a positive integer value. The input is terminated with Enter, and the macro to be executed will be repeated the specified number of times. Pressing ESC instead of Enter at this point would abort the operation and keep the old repeat count value. (It's debatable whether this number should remain sticky or not...)
Macros now accept a counter (F4), so the Shift+F12 key is still free for some future use.
Contents |
This would make View a powerful grep-like utility for gathering only relevant information from a large number of files.
Contents |
The fact that it works so naturally in Autoview, gives me hope it shouldn't be a problem to add it to (V)iew proper.
Contents |
In the 25x80 screen mode, the user would see no difference, but "modern" users would see this, instead of a huge blank area surrounding this smallish window.
The overlay should leave the top two lines visible, allowing the user to view current paths and filespecs.
The same ZEP is applicable to the Alt+F10 (Configuration menu) window, which has the same 25x80 geometry. It comes from an external program, ZTW_CFG.EXE, so it's probably not as easy, but it would be more consistent and pleasing to the user if it were an overaly.
Contents |
A new Ctrl+Insert option to copy the current file or directory ordinal number to the Clipboard may come handy.
This would make it easy to later reach this object, either manually or via a macro (Alt+\,SHIFT_INS,RET) -- provided no intermediate additions, deletions, or reordering of the list took place.
This would enable keeping track of (anchoring) a certain file, or position in a list. Even if changes do take place, returning to the vicinity of the original point would be useful.
Today, it is not easy to bookmark and later return to a certain object in a list, the way it is doable in almost all editors.
If ordinals become available in F9, this option would apply there as well.
Contents |
This ZEP is probably obsolete after recently added command line switches (/T0, TD, TF,...).
The ZTree window title bar (and Taskbar button) are not large chunk of screen estate, but are almost always visible. If made more dynamic by allowing the user, as well as ZTree to write to it, some new features will appear:
Contents |
However, it seems perfectly reasonable for the user to decide to hide all other files from view, in other words, invoke F(ilespec) and enter the string *parser*_*v14*2005*.log.
Currently, there seems to be no faster way of doing it, other than copying (Ctrl+Insert) the string *while* in search mode, and pasting it (Shift+Insert) into the Filespec prompt. This has the side-effect of destroying the Clipboard.
A function key (like F4) in the Filespec dialog seems like the most direct way of doing it. F3 already inserts the last Filespec used, so the mechanism seems to be there.
Another possibility is extending the F(ilespec) cycle (using TAB), but maybe it is quite long as it is...
Contents |
Rather than locating such objects visually, navigational key(s) could be assigned to cycle through them. Granted, it is easy to locate zero-length files, thanks to Filespec and sorting, but this is not possible for directories and F9 items that are empty.
Highlighting such objects in some way should also be considered as a unique feature: -- it's both a visual alert, and a built-in annotation tool!
Contents |
However, portions of the name still must be re-typed in a different case. (By the way, this also applies to the extensive editing taking place in F9 descriptions, and any other editing throughout ZTree.)
Hence, it would be useful if selected characters only in text entry fields could be converted to UPPER/lower/Capitalized using the existing TAB key cycle. If no selection exists, TAB would work as today; otherwise, it would operate on the selected portion only.
(Note that using keys like Ctrl+U, Ctrl+L, and Ctrl+C -- as used in some editors -- is not possible, because this may fetch any existing bookmarked history entries.)
If a selection exists, Shift+Insert (Windows Clipboard paste) fully respects the above rule, so demanding this from the TAB cycle is quite legitimate. In fact, it is an established standard for any editing operations to always apply to the selected object (if any) first.
Contents |
There are so many factors involved that the only valid measurement is the one you obtain in your environment. With real numbers to show, there is no arguing which storage options or network setup works best for you at a given moment!
Because ZTree is often used to move about huge amounts of data locally and remotely, it seems like an almost perfect (but not scientific) tool for measuring data throughput.
ZTree could be enhanced (minimally) to show the transfer rate when performing certain selected commands, like Log, Copy, Move, Mirror, Compare, etc.
ZTree already has useful progress bars and Time Remaining displays, as well as the current transfer rate, but they only give the user a rough feeling of the speed (and then disappear forever); we need data averaged over the entire duration of the operation so that we can compare it against other similar data.
Above all, the information must remain on the screen long enough for the user to glance at and analyze. The information would disappear the moment a subsequent command (or just one of the commands that actually update this display?) is executed.
Since the spinner area is strongly associated with data movement, the last calculated average transfer rate could be displayed right before the spinner.
Contents |
Currently, whatever is fetched from a ZTree history REPLACES the current input line entirely, be it a filespec, search string, date stamp, shell command, rename mask, batch line mask, and so on. This happens with both Ctrl+% and Alt+% history fetch action. If the user wants to preserve current text, he must first save it (Ctrl+Insert), fetch a history item, and then restore the text to a convenient location on the input line (Shift+Insert).
The above is doable, but I propose enhancing the history fetching behaviour with a new mode that will PRESERVE the current input line and allow pasting into it. The user will never worry about losing whatever is on the command line. Consider the following scenario:
What we see is a regular PASTE operation we all understand and love, but the goodies are not coming from the system Clipboard, but rather from ZTree's private (40 or so *per* history) collection of sticky clipboards!
For example, if there is a frequent need to create new batch files, the user would type:
test[F5][Alt+B]
which would result in "test.bat", provided bookmark B points to the ".bat" string.
This would work in all histories, making it possible to insert bits and pieces as needed. This will give us a new way of building, say, the tricky Rename patters, line masks (in Batch), appending "| more" to shell commands, and so on. ZTree would certainly have one of the most advanced and unique line-editing features that brings text re-use to a new level.
The standard Shift+Ins would continue to work, of course, as well as case conversions and all other editing features. (Using Shift+Ins is recommended for pasting in ZTree. Using Ctrl+V should be avoided because it will clash with any entries bookmarked with a "V".)
I've been downloading certain TV shows for the past several years and naming them using the
yyyymmdd_TV_SHOW_NAME_Details_About_Guests_and_Subject.rm
convention. The problem is that the shows are invariably named "ab.rm", "0205.rm", and similar useless, short names, requiring plenty of time crafting the name. The most boring part is typing in the TV_SHOW_NAMEs, which may be long and have never changed over the years.
I'd like to re-use what I've done dozens of times when renaming a file like "ab.rm" with steps like these:
Contents |
It would be useful to consider a prefix (like '@' used elsewhere) that would prevent Filespecs getting into the history in the first place. Automated tools and macros would not need to worry about flashing screens and history pollution.
Since finding the perfect prefix may not be easy, maybe the best approach would be terminating user input with, say, Ctrl+Enter, rather than Enter as a signal to ZTree to not use the history. This is similar to the already familiar Application Menu and eXecute Ctrl+Enter feature.
For example, many macros today use ...cmd,ENTER,UP,DEL,ESC,ESC as the cleanup mechanism.
This could be reduced to a simple ...cmd,CTRL_ENTER!
Many of the programs I use update their taskbar button when active.
For example, 1by1 (MP3 player) displays the time left and elapsed
("MM:SS, MM:SS Song name") for the current song. This is actually
the truncated window title, so not much of the song name is seen --
but I find the time left value useful!
CD burners, file copiers, fragmenters, downloaders, etc., also
make use of this regularly.
In ZTree, you need to have the status line (or at least the spinner corner)
visible to "check the pulse".
It would be useful (and consistent with the Windows environment) to
have the Taskbar button updated for all lengthy operations, freeing
the user from switching to/from ZTree for the sole purpose of performing
this visual checking.
In addition, if an error occurs, the Taskbar could/should flash, alerting
the user to attend to ZTree. How many times have you
launched a long operation in the background and forgetten about
it, only to find that it stopped very early on?
What I don't know is whether the Taskbar button can be
treated separately from the app's window title and if this
would mess something else up...
Contents ZEP610: Taskbar Progress indicator (spinner)
Contents