Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MusicHawk]

I'm making this request, again, because it's still difficult to work with the Tag action window.

I know, the Tag action window has been improved to have two heights: fixed, showing approximately 20 fields (I call this Small), and max height showing whatever fits in the left column (I call this Large). Those are both useful states.

But the missing state is Medium -- larger but not max. This is necessary so more tags can be accessed while keeping some of the tree exposed for navigation.

Two possible solutions:

Make the Tag action window fully resizable.

OR

Give the Tag action window a Medium size option.

The Medium option could be done two ways:

Simple is to define a Medium size that is quite a bit larger than the current Small size, which itself is perhaps a holdover from when we all used smaller screens. Maybe 1/3 tree, 2/3 Tag area? But ideally, the Medium size would be based on the columns in the current view.

There's already an option to Show Tags in Current View, but it doesn't affect the Tag action window size. With the Small window this mode usually requires scrolling. With the Large window this mode can result in empty area if the window is larger than the tags in the view. That blank area would be more useful if it was the navigation tree.

The perfect option would be a Tag action window mode to show all the fields (tags/columns) in the current view, that ALSO automatically sizes the Tag window to the right height to show all the same fields. In my experience, this would usually result in a Tag window filling about 2/3 of the left column, so about 1/3 could be the navigation tree. (Scrolling within the Tag window should happen only if the number of fields exceeds the available space.)

[Mars]

In addition, I would also like a "floating" Tag action window, which could be unlocked from its initial position and be moved on top the screen to a more comfortable position. It could also have "next" and "previous" buttons for selecting files, that would allow to minimize main GUI, or even doing tag tasks files while in full screen view.

[lise]

In addition, I would also like a "floating" Tag action window [...] It could also have "next" and "previous" buttons

Excellent suggestion. I second this.

[rossp]

In addition, I would also like a "floating" Tag action window [...] It could also have "next" and "previous" buttons

+1, this is the solution

[Mars]

Another idea could be adding an alternative library view to panes, maybe called "Tags", in which, instead of seeing the items of each category, it showed the fields as the Tag action window does ("show defaults", "show tags in current view"...). This alternative view could also be invoked from the tab title, to switch between "panes" and "Tags".

[kewe65]

one thing i find annoying - and it was in 14 too - is the tag drop downs dont stay to the right of the label, but drop down to one row below the label that's being edited.  when tabbing through the fields i have to keep this in mind because i have no other application that does this. 

and its not like there is anything to view or edit in the actual space to the right of the label, so i dont see the point.  why can't it just drop right there?

[rick.ca]

why can't it just drop right there?

Since you ask, the point seems to be to provide the edit box a full column width. That has to be useful for those who use a narrow column for the tree and who would rather not widen it every time they need to edit something. But you're certainly not alone in finding the behaviour annoying. It might be easier to take if you consider how much you benefit by the developers' willingness to stray from the conventional.

[rhgh]

i would like The tageditor should open in a detach window as the DSP window

[MusicHawk]

Tag editing seems to be sort of schizophrenic -- there are two places/ways to work with tags and they behave differently.

The Tag Action window seems to be the primary place to work with tags. But, the width of an editing field is constrained to remain within the Tag action window, which can be insufficient. This is helped a bit the behavior of opening the slightly-wider field below the label, but still, the nav/tree/action column width determines the max tag field width, yet they have different purposes. It can be quite difficult to work with longish comments, names, artists, etc. Of course, the user can widen this column, but an appropriate width for tree navigation is very different from the ideal width for tag editing. Tying them together is the root of the current "problem"

In contrast, editing a tag in a view column can open a field much wider, apparently up to the width of the longest value of that field in the current view, limited by the width of the view to the right of the field. This can be quite large, MUCH larger than in the Tag Action window. However, a column in the right area of the view opened for editing can be squeezed quite small. And opening a list associated with a field can be clunky depending on the position of the selected field column/row in the view. Plus, tag edtiing in a view is limited to fields/columns that are shown in the view, while the Tag Action window can provide access to any or all tags.

Several alternatives, suggested here and in prior threads, would help this. A larger Tag action window is the basic need. It could be the existing window, detachable/floatable and resizable, with MC remembering this (sticky) so it can be closed/opened/closed/opened consistently. And/or, the Tag Action window could have an option to auto-zoom to a larger width and height. (For example, I requested medium-tall, which could be even better if combined with multi-line display of longer field contents)

The idea to show all fields of a record on a separate tab would be a nice option, but not as the only mode because many times I want to see other rows of the view while editing, to remind of related record settings and to help make tags consistent across records.

The need to also see other data in the view is why a detachable/floatable/resizable sticky-position Tag Action window seems to be the ideal solution.

Various photo/video/layout tools, such as Photoshop, InDesign, QuarkXpress and similar have the same need -- lots of property/editing boxes, configurable by the user. Some products let the user set up desired property/editing windows and positions, then save that configuration. Then set up another set of windows, sizes, locations, and save that configuration. Etc. Then the user can open the desired layout based on the current task. This could really be wonderful in MC because it handles the spectrum of media types. The optimum properties/tool boxes layout for working with music might be very different from working with photos, with videos, etc.

[rick.ca]

The need to also see other data in the view is why a detachable/floatable/resizable sticky-position Tag Action window seems to be the ideal solution.

I'm in favour of this because it's the most versatile solution. It can be used effectively in a number of different situations—when the view is in full-screen, or the main interface is minimized, or you just prefer using floating window that can be moved wherever it works best.

But surely the current window is the closest to an "ideal solution" for the most common usage scenario. Floating, it's going to be on top of something—as is, it's not. The column width is easy to change—easier than opening a detachable window, resizing it, and moving it to where it's not covering something important. The tree can be left in view, or the whole column used for tagging—and the controls for changing back and forth are more convenient than resizing and/or moving a window. The fact optimal width for the tagging window (while in use) is wider than necessary for the tree is not a significant issue—it represents about a 5% "waste" of screen space (for the kind of displays most of us are using). A detached window is likely going to be wasting more space—because it's not fully utilizing the space under the tree. Keeping the window to one side of the other information is also the best solution, considering the nature of that other information. When editing an image, it's handy to be able to move such windows to a part of the edit window not currently being used. That's quite different from a grid view—all of which needs to be in view.

There seem to be more complaints about the edit boxes opening below the field than about having to widen the column. Maybe that's because most users are happy to widen the column to an optimal width for tag editing, and therefore don't appreciate the edit box behaviour. If there is enough width for editing-in-place, it is odd and disconcerting. Fast editors must be put off simply because it causes unnecessary movement the eye and mouse have to follow.

[MusicHawk]

I'm still hoping for two things: 1) More tags visible at once, but still having some nav-tree exposed to use. 2) Wider edit fields. With these improvements, there wouldn't be much need for a floatable Tag window.

1) To show more tags, provide an in-between "Medium" size Tag Action window, as an alternative to the current "Small" and "Max" sizes. Medium would show more rows of tags by using most of the left column's height. But it would still show a bit of the navigation tree. Best-case it would be resizable up/down, worst-case it would be fixed size, maybe 80% tag window, 20% nav tree. 

2) To allow editing of longer text, allow the current edit field to flow to the right beyond the tag window edge (instead of dropping down a line to become slightly wider). Do this the same way that currently happens when editing a field in the view area, where the edit field flows across other columns. This would allow editing of longer text without having to resize the left column. (Doing so, while easy, nudges off-screen the far-right view columns, so there's a sacrifice of visible info just as there would be with a flotable window.) Perhaps this behavior can be user-enabled/disabled as desired. 

BTW, now that I've adapted to it, I can edit fast with the current Tag window one-row-down edit field. I use Tab and Shift+Tab to move among the fields so don't usually need to play target practice with the mouse. But it's still jarring and at times I have to stop and think, what am I editing? And at times, I end up editing the wrong field.

[lise]

But surely the current window is the closest to an "ideal solution" for the most common usage scenario. Floating, it's going to be on top of something—as is, it's not. The column width is easy to change—easier than opening a detachable window, resizing it, and moving it to where it's not covering something important.

I didn't realize it could go the full height of that column!  This is great.

1. See what we are tagging

To address the issue of not knowing which file is being tagged, perhaps the first entries in the tagging window next to the cover image (the first 3 rows) could be customizable per Media Type or on the fly, so that instead of displaying

======= MP3-4:34 - 4.2 MB
 image     never played
======= * * * * *

we could have a custom area here much like the way we decide what gets displayed under thumbnails.


======= Artist
 image     Track # - Track
======= Album - Year

2. Where we are in the tree

As for displaying some of the tree for nagivation purposes, I would prefer to keep the tagging window maximized, but perhaps the very first item in the tagging window could be a drop-down menu that displays items in the tree. You select the empty drop-down field, then select Audio > One Of The View Schemes and there you go, the right becomes what you selected, the left remains the tagging window, and the top of the tagging window displays the drop-down menu with your selection, for example, Audio > Favourite Albums

3. Save custom "tagging area" per view scheme

The thing I would like to see is the ability to save a tagging space to go along with a scheme. I've got a scheme called "Tagging Emusic" in which I use panes and the tagging window to do my stuff, but there are some fields I complete here that I don't really complete elsewhere. So it would be nice to save the tagging window for this view in particular such that whenever it is selected and tagging is selected, the two are connected and my fields are displayed. I wouldn't want to do this for all view schemes, so a saved default "Audio" and "Image" etc.  tagging window is fine for most of the stuff.

[rick.ca]

1) To show more tags, provide an in-between "Medium" size Tag Action window, as an alternative to the current "Small" and "Max" sizes. Medium would show more rows of tags by using most of the left column's height. But it would still show a bit of the navigation tree. Best-case it would be resizable up/down, worst-case it would be fixed size, maybe 80% tag window, 20% nav tree.

Note the window height already adapts to the amount of space occupied by the tree. I think that, combined with the fact it can be toggled to 100%, provides enough flexibility. Introducing other behaviours is only going to make it awkward and confusing.

...This would allow editing of longer text without having to resize the left column...

This would also remove my ability to control the width of my edit window by changing the column width. I'd rather have control of it, rather than letting the program decide how much width I need. And I can easily adjust my view columns so the information I need is in view. I'll commonly drag a column to the left so it's more prominent while editing anyway—I'm not concerned about far-right columns disappearing off-screen.

As for displaying some of the tree for nagivation purposes, I would prefer to keep the tagging window maximized, but perhaps the very first item in the tagging window could be a drop-down menu that displays items in the tree.

Why not just restore the (maximized) tag window, use the tree, and then maximize the tag window again?

So it would be nice to save the tagging window for this view in particular such that whenever it is selected and tagging is selected, the two are connected and my fields are displayed.

This sounds very much like the existing "Show tags in current view" setting. Just create a view that includes whatever fields you might want to edit, and then use that setting.

[lise]

This sounds very much like the existing "Show tags in current view" setting. Just create a view that includes whatever fields you might want to edit, and then use that setting.

Actually, it's not. I use panes to do my tagging with about 6 fields being displayed. I don't need them to be displayed both in my panes AND in the tag view. What I want is to display other fields that will not fit in my panes without them getting so narrow as to be useless.

Example: tagging classical music
Panes:
Period | Date of Composition | Composer | Subgenre | Work Type | Country |
Tag window used for Orchestra, Album Year, Comments, Description, etc.

[rick.ca]

OIC. It's not the same thing, but you can select Show default tags and Also show the additional tags you want to edit there. There are only six default tags (eight for images), and while you may not want to edit them, they do serve the purpose of indicating what records are selected (e.g., an artist or album). It won't retain those settings by view, but it does save the Also show settings separately with each of the other "show" settings. So it is possible to use Show default tags + Also show for what you describe, while the other settings remain for other purposes.

[lise]

it does save the Also show settings separately with each of the other "show" settings. So it is possible to use Show default tags + Also show for what you describe, while the other settings remain for other purposes.

Yes, that's what I do now. I use the defaults + Also Show. And while they are saved, I'm not sure they are saved per view scheme (ie show these fields for the Classical Music Tagging view and these for Music Tagging), I'll have to test that. But now it sort of seems irrelevant anyway. I wanted this because not knowing the window could take up the whole tree, I was always dealing with a tiny window that only displayed a few fields at a time. The last thing I wanted were fields I didn't need!  But now that I know it goes full height, this isn't an issue anymore.

[MusicHawk]

This sounds very much like the existing "Show tags in current view" setting. Just create a view that includes whatever fields you might want to edit, and then use that setting.

That is EXACTLY what I do (have done for years) but I need to tag more fields than show (without scrolling) in the Tag action window.

Yes,  the Tag action window resizes based on the number of tags in current view, but ONLY UP TO A POINT, then it stops enlarging and adds a vertical scroll bar. Often the height it chooses is less than the number of tags in my "fields-I-need-to-see-while-tagging" custom view (and/or available column height).

But the REAL problem seems to be this: MC puts priority on showing the Navigation tree rather than showing the Tag action window. Whether set to show tags in current view or ALL Tags, the Tag window's height jumps up/down based on Navigation tree items and expansion.

This is a big source of the frustration, because it is difficult to develop smooth workflow when a key element -- Tag window -- keeps resizing itself. Eye-hand coordination is challenged by an ever-moving target. (To be accurate, there seems to be a min/max sharing of the column; both Tag and Nav panes will auto-resize only to a point.)

Obviously with two different "large" elements sharing one column, something has to be scrolled. But I suggest that MC has it backwards. Since the navigation tree by its nature requires scrolling, the sizing priority should be given to a large and stable Tag action window.

MC can recognize when the user cares about tagging, because the user has opened the Tag action window. In that mode, MC can give the Tag action window a FIXED large percentage of MC window height (I suggested 80% max Tag, 20% min Nav).  Once the Tag window is closed, revert to show the max Navigation area.

And/or -- allow drag-resize (sticky) of the Tag action window HEIGHT, same as already provided for the WIDTH. Why not?

Above all, it would help a lot if MC did not constantly resize the Tag action window height. Resize the navigation pane height instead. Have this happen only when the Tag action window is open, so only active tagging activity is affected -- and helped.

[rick.ca]

This is a big source of the frustration, because it is difficult to develop smooth workflow when a key element -- Tag window -- keeps resizing itself.

Clearly, the purpose of the current design is to allow the tag window and tree to be used at the same time. If the tree is not being used, it can be collapsed—which will give the tag window all the remaining height. If that's not enough, and/or the tree is not needed "on standby," the tag window can be maximized. In any case, it's going to use all the available height, and it's only going to resize if it's set to Show tags with values. That, of course, is going to result in the window resizing as records with differing numbers of tags with values are displayed.

I don't use the tagging window all that much. Now that I'm taking a closer look, I'm very impressed with the subtleties of the design. It automatically adapts to whatever the user is doing, making both the tree and tag window as usable as possible in the circumstances. If the tree isn't needed, the tag window can be maximized. If the tag window isn't needed, it can be closed. Changing this so the tagging window would occupy a fixed space and/or have a resizable height would be a big step backwards. It would just result in more fiddling—for no good reason. Maybe this is another point in favour of providing a detachable window. That would allow users to do whatever they wanted with it—without messing up the otherwise excellent design of the docked window.

[MusicHawk]

I don't use the tagging window all that much

Might I suggest that, if you did you the Tag action window a lot -- such as to tag tens of thousands of files (music, photos, whatever) -- you'd crave efficiency in both navigating and tagging, but biased toward tagging, which would be hugely aided by a large and stable tag window, plus useful but small navigation window.


Of course the Tag window resizes based on "Show tags with values", but that's not a mode I'd ever use. I want access to particular tag fields, to add/change tags as needed. This is readily accomplished via a custom view that has the desired tags combined with Show tags in view, or by using the Show feature to add tags. Either way, the problem lies with how MC keeps resizing the Tag window due to moving around the Navigation tree, so the list of visible tags keeps growing/shrinking, as does their place on the screen.

The Navigation tree, by its very nature, changes as users move around, expanding branches, etc. (In an alphabetical grouped view, there's a huge nav tree size difference between clicking S and Z.) So, let the tree window area be dynamically sized -- as it already is.

In contrast, the Tag window, once set by the user to show the fields the user is working with, has no intrinsic need to repeatedly change size -- yet it does as the nav windows is used. This moves fields around, switches tags in and out of requiring scrolling, etc. Everything is do-able as-is, it's simply annoying and inefficient to constantly be forced to play "chase the field".

I'm simply arguing that when the Tag window is opened by the user, it should be treated as primary, not fluidly resized at the whim of the Navigation tree's state.

[rick.ca]

Might I suggest that, if you did you the Tag action window a lot...

You must be using the tree to navigate categories. Yes, I can see how that would be a PITA. Used that way, both the tree and the tag window are going to compete for most of the column. You can't collapse the tree without undoing the selection. I don't see any satisfactory solution to that circumstance, and that's probably why I've never bothered to try. I get the same functionality in a much more efficient form by using a Panes view. That's much faster and more versatile than selecting items using the tree. And it doesn't require any of the space needed by the tagging window. I use the tree only to select the most appropriate view for what I'm tagging at the time. When tagging a large number of files of the same type, I don't need that, and will likely maximize the tag window for the entire session.

But to each his own. This is why I'm in favour of providing a detached tagging window. If you insist on using the tree to select categories, it just doesn't make any sense for the tagging window to share the same space. You'd be better off with a detachable window you could place beside the tree or to the right of the view. And that doesn't require messing up a design that works perfectly well for me.

BTW, panes offer more than just a better way to select items—they make "pane tagging" available. In many situations, that's the most efficient way to tag. For versatility and efficiency, surely nothing beats a Panes view (configured for the type and genre of media) and a fixed, maximized tagging pane. That allows efficient file selection and tagging by whatever means is most effective: pane tagging, in view editing, or using the tagging window. The only improvement I can think of is the option to do that full screen, with a detached tagging window.

[MusicHawk]

Panes view doesn't do what I want with audio files -- I've tried many times but it is optimized for different purposes. For example, it seems many music users organize by albums, but I don't.

For tagging, I work very efficiently with rows and columns of data records. For navigation I like working with a nested tree based on a custom field. While doing a large tagging audio project I have no need to see cover art or album groupings or anything else except lots of fields (and I don't use many of MC's standard library fields). Perhaps this is because I've used MC for so long (starting with Media Jukebox 7), and over the years have been able to customize it to work much like radio station music systems I used to use, so now MC is highly-evolved to work well for my needs.

For example, I was organizing/tagging some historic recordings (1890s-1910s). Back then, many performers were in multiple groups, and/or performed under multiple names, and/or recorded the same song under multiple names and/or for multiple record companies. Chaos reigned. To work through this, I built a view grouped by a custom list-type Artists field (to list all the individual performers along with their groups), also showing song titles and record labels, and dates and more. I then opened different sections of the same view on different tabs. And sometimes I opened a different view, expanding only certain sections, to quickly see what they contained. I suppose there are other ways to do this but it was fast to set up and use and did the job. Except for the "bouncing" Tag action window size.

BTW, when using MC for photo tagging and management, I use panes. As you say, to each his own, but also, ideally, for each different need a different MC layout.

But regardless of alternative ways to view and work with data, I think the Tag action window -- since it exists and is a prominent MC object that shows categorized fields -- should ALSO work as well as possible to use what it shows. Specifically it should be more visually stable. Its size and visible tags should be static per user desire, not constantly re-jiggered by clicks in the Navigation window. I don't see how this improvement would harm any other areas or modes of MC, so why not?

[JimH]

For tagging, I work very efficiently with rows and columns of data records.

You may know this, but...

You can edit in the content window on the right, when it's in list view.  Just do a "slow" double click on the field you want to change.  When you finish, press an arrow key to move to the next.  You can also use F2 to enter this mode.

[rick.ca]

Panes view doesn't do what I want with audio files -- I've tried many times but it is optimized for different purposes. For example, it seems many music users organize by albums, but I don't.

I'm sorry, but that's simply not true. You can change your view type to Panes and get exactly the same categories in the same order as you're now using in the tree. There's no requirement to group by Album. You can, in fact, group by whatever you like.

I don't see how this improvement would harm any other areas or modes of MC, so why not?

I've already explained why not. It's not an improvement. The current design is not only perfect for the intended purpose, the changes you propose would render it annoying for that purpose. If you really believe using the tree to navigate categories while tagging is a sensible and necessary practice, you should be asking for a separate column or a detachable tagging window. Or an option to facilitate your unusual preference. But not for changes clearly not suitable to the method others use and for which it was clearly designed.

[MusicHawk]

I didn't say anything about a REQUIREMENT to group by album, I cited an example that got mis-read.

I've tried Panes many times and for the HUNDREDS of categories I need to list, it is not an efficient way to work compared with the Navigation tree. I'm all about efficiency.

I know how to edit in the view grid and do so, but as cited in an earlier message some aspects behave differently than in the Tag window.

It's not a "perfect" design to have the tag window be constantly resized by an unrelated action in another window. Do Pane sizes, or view widths, or other major elements get bounced around in the same way?

[rick.ca]

I think the horse is dead.

[kewe65]

except "full column width" is not a fixed width.  i can pull out the column to the right as far as it will go inside the frame of the window and it still drops down.

Since you ask, the point seems to be to provide the edit box a full column width. That has to be useful for those who use a narrow column for the tree and who would rather not widen it every time they need to edit something. But you're certainly not alone in finding the behaviour annoying. It might be easier to take if you consider how much you benefit by the developers' willingness to stray from the conventional.

i'm all for developers straying from the conventional - when it actually serves a purpose that provides benefit.  i dont see the benefit of dropping down the field just to gain that tiny amount of field width, which is the same regardless of how wide i make it - it looks like i gain maybe 8-10 characters in 7 or 8 point type?

sometimes straying from the conventional is just causing problems.  in other words, there is a good reason there's such a thing as ANSI.

thanks for the reply

[rick.ca]

in other words, there is a good reason there's such a thing as ANSI.

No argument there, but what standard is being violated?

[MusicHawk]

The reason the Tree must be used, therefore its display size is important (vs. Tag window size) is that the Tree does things that a Categorized view can't seem to do, when the categorized field is multi-value/List type.

For instance, I use custom field Artists to identify all the important artists of a recording. My main view is sorted and grouped by Artists.

When a recording has, say, 3 artists, the recording appears at EACH alphabetical position in the view, under the name of each artist. Perfect!  

For instance, if recording "Help!" has Artists of "Beatles";"Paul McCartney";"John Lennon", the Tree shows this this:
B
  Beatles
    Help!
J
  John Lennon
    Help!
P
  Paul McCartney
    Help!

Click on any of these to view exactly the same database record for "Help!". This virtual-record behavior is exactly what a database should provide in a view.
  
However, if the view is set to View As Categories and Artists is the order and grouping field, and the clicking is via the alphabetical groupings in the view area, displayed information is not useful. Instead of handling the list-type field by showing each Artists name as a category, MC shows [Varies]. It shows this at EACH alphabetical position where the record appears. Where the Tree shows "John Lennon", the Category shows [Varies].

So, View As Categories is doing the list expansion into categories, but that's just half of the need. I can't find any way to get View As Categories to show anything but [Varies] for multi-value fields. Because many (maybe most) of my 60-thousand tracks have multiple values in Artists (and I also use several other similar views, each with dozens and dozens of list values), the current behavior of a lengthy list of [Varies] is useless to me. (If there's a solution to this, please share it...)

However, if View As Categories gets changed to display list-type values the same as the Tree currently does, the Tree would not be essential for navigation, and could be hidden by an expanded Tag window. But for now, I need both, hence the suggestions for tweaking options for how they are relatively sized.


(Note, I don't actually put Paul McCartney and John Lennon in my Artists field, I put "McCartney, Paul;Lennon, John". But that doesn't affect how the views behave, it's just how I like to organize my library.)

[rick.ca]

The reason the Tree must be used, therefore its display size is important (vs. Tag window size) is that the Tree does things that a Categorized view can't seem to do, when the categorized field is multi-value/List type.

Have you tried a Panes view?

You can change your view type to Panes and get exactly the same categories in the same order as you're now using in the tree.

[MusicHawk]

Yes, should have mentioned that Panes view works as the Tree does. But since my need is to view and work with many tracks at once -- dozens or hundreds in a particular category/artist/keyword/year (all views I use), I don't like having to give up any view rows space to the pane, even sized down, when the Tree can do the same thing. And, when the pane is sized down, I can't see very many items in the list...

But (to be fair and balanced), using Panes allows the Tag window height to be maximized, which is helpful, and it keeps the fields in the same vertical location from record to record, which is very helpful for efficient viewing, and fast clicking and typing. (When the Tag window is non-maximized, it keeps getting resized by MC as the tree is navigated.)

Of course, everything is a trade-off, and there's no desire to remove or reduce anything MC does now (though the View As Categories mode seems to be semi-implemented). I toss in ideas that arise when I spend hours trying to optimize my MC work flow, in case there's "one more" way MC can help get 'er done.

[rick.ca]

I don't like having to give up any view rows space to the pane, even sized down, when the Tree can do the same thing.

Panes can be vertical (on the left or right) where they won't reduce the number of rows in the display, or they may be in a drop-down where they won't use any space at all.

I toss in ideas that arise when I spend hours trying to optimize my MC work flow, in case there's "one more" way MC can help get 'er done.

That's fine. But, having done that, it's also fair I point out how the problem can be solved or the need satisfied by using a different approach. In this case, I think it's fundamental in determining whether the need to use the tree should be favoured when considering the behaviour of the tag window. The fact there's another way to select categories suggests it's not a critical consideration. IMO, that alternative is superior, so it follows the current behaviour is perfect. It allows access to the tree (which is still necessary for changing views, even if categories are not there) while making as much space as possible available to the tag window.

[MusicHawk]

Update: I've been experimenting with Panes, as suggested. They work better than I thought from earlier tries, but there are still some quirks, maybe bugs, to mention.

In my context, which is a working in a very large library with lots of custom fields:

1. Using Panes in dropdown mode preserves max screen space, except the currently selected category values keep getting forgotten by MC. For instance, I select M in the first pane, then maybe artist "Montenegro" in the second pane, then go into the displayed records to listen and tag. When I then click back on the dropdown, MC usually has forgotten where it was. If I click the first pane it is back at the top of the alphabet, so I have to scroll down to "M". If instead (and more commonly) I click the second pane to move to the the next artist, the list is back to the top of the "M" artists, which is 614, which means a lot of scrolling to get back to where I was at "Montenegro". This behavior seems like a bug; if fixed, dropdown is probably the best Panes mode for my project.

2. Using Panes in top or sidebar mode, the above "forgetting" does not happen, but of course this mode consumes more screen space so I lose a few rows (top) or a couple of visible columns (left or right). Since this mode is more stable I'm trying to get used to it -- top Panes seems best.

3. Using Panes allows the Tag window to be maximized, which is a big help. It lets me see all the fields I need without scrolling tags, and it holds the fields in a consistent position (vs. bouncing up/down when the left column is shared by the Tree and Tag areas). This is marred by the Tag window losing maximization upon certain actions (reported by me and others in a different thread), which seems like a bug.

Regarding the situation of a maximized Tag window covering up the views list, perhaps the same list (top level only) could be dynamically listed under the top Views menu, or another top menu item, so any view/playlist can be jumped to without using the navigation tree, thereby leaving Tag maximized (if desired).

Assuming the quirks / bugs get improved, dropdown Panes seems to be the best available mode for what I'm doing. I still prefer the visual nested tree to see the scope of library, but I can get reasonable work done using Panes.

However, I still wish there could be a Tag editing enlargement mode, especially for fields that often have (very) long text, notably Comments.

Thanks for the suggestions.

[kewe65]

No argument there, but what standard is being violated?

i just meant to contest the position that looking at different ways of doing things outweighs the standard ways most applications work for the sake of being different.  just like there are web page design standards...

so far, the design logic for having the field drop down to gain the space to the left of it doesn't hold much water.  i get the point of expanding out fields that work like memo fields for (almost) limited text, but at the expense of the majority of fields that have will always have fairly limited lengths?

it just doesnt make sense.

[rick.ca]

i just meant to contest the position that looking at different ways of doing things outweighs the standard ways most applications work for the sake of being different.  just like there are web page design standards.

In the context in which you're using the word, there aren't any applicable "standards." I think you mean "convention." There are disadvantages in deviating from the conventional, but those may be outweighed by the advantages. In any case, it's certainly not fair or helpful to suggest the purpose of doing so is "for the sake of being different." It was clearly for the sake of providing more editing width.

We've already made the argument the behaviour in question isn't really necessary and makes editing more awkward and error-prone, aside from being unconventional. I expect the developers will consider changing it—in due course.