|
|
This will be consequence of fix of 0020464, tracklist control is only in the upper part now, so the space below is already not tracklist, so does not accept dropping of files. |
|
|
Not very good excuse, I am sure you could do it better. I already have trouble making my skin because the tracklist is not covering the whole main view. Not to mention that such behavior where drag&drop is not accepted is not standard and something that users don't expect. I didn't analyze your code, but I suppose you could have a resize event handler which could make the tracklist always covering the main view, just as much as it should, without letting the additional scrollbar to appear. |
|
|
@zvezdan it was note for Petr, where the problem started, really no need for your traditional scathing remarks. Thanks. |
|
|
I misinterpreted your post as your traditional excuse for why something cannot/shouldn't be done. Of course, there is really no need that I waste my time on your product. |
|
|
Closed as duplicate of 0020794 in order to address it on global app level. |
|
|
Peke pointed out at 0020794 that the issue occurs not only occurs for D&D to the space below the tracks in the Playing node, but also when dragging tracks from any node to the blank space below the tracks in the Playing list element. He therefore suggests that a generic solution is required (see implementation suggestion there). I've triaged this back to 5.1 as this is a regression and drag and drop to the Playing list is basic behavior. |
|
|
Test note: Even now playing is set to List view D&D to Empty Space works while Playing in list view do not eg. Now playing acts more like MM4 than Playing node. |
|
|
I am sorry, but I don't understand what are you talking about. I didn't say that D&D doesn't work for the Playing panel element with List layout. It works fine. I talked about the traclist in the main panel instead. I said that empty space below tracks in the tracklist of Playing node doesn't accept drop of files, and It doesn't work either with List or List (by Album) view. |
|
|
Thx Zvezdan, that was things we talked about in 0020528:0074910 and why I created 0020794 to globally address this issue with unified object that you and other Scripters can utilize in future more easily as generally empty space in Main track browser works differently than same empty space in Now Playing as noted in https://www.mediamonkey.com/forum/viewtopic.php?p=517990#p517990 Feel free to suggest best approach (combining both bugs) in order to make things easier for you as scripter. |
|
|
@Peke, I am sorry, but I still don't understand how the bug that you reported several months after mine is any different. It is the same bug, just said with another words. The point in both reports is that the empty space below tracklist in Playing node doesn't accept dropping of files. Why this happens and how will you resolve that, by adding another control below tracklist, or whatever else, is all up to you. I already gave you one suggestion, but it seems that you guys don't like my suggestions. However, since you already asked me, I will answer. I don't like adding new controls below tracklists just to serve as a D&D target. I think it would be better if the existing listview control is resized to vertically fill its parent control(s) (Scroller > NowPlayingView) whenever the parent control is resized. As I already mentioned, you have the similar situation with tracklists in the main view when any static playlist node is selected, and such tracklists accept D&D on empty space below tracks just fine. These listviews of playlists are also children of Scroller control and they vertically fill it. |
|
|
You are right, Playing List view in main track browser space is one that behaves different than rest of List view tree nodes. Like you pointed Static Playlists that have only few tracks (eg. have space below tracks) works (1st pic) and same view in Playing List view fail (2nd Pic). I'll close My bug as duplicate, as now after further testing I agree with you that adding new controls is not right approach, even I would like to clearly see empty space as separate FLEX DIV when inspecting UI like List of track is separate DIV eg. point of 0020794 What I see if you agree is that Playing (List view) should act/behave same as Static Playlist (which works) on D&D and by code should be same? image.png (92,057 bytes) image-2.png (80,364 bytes) |
|
|
Of course, that was what I suggested from the start. Here is somewhat more explanation why I think it would be better if the existing listview control is vertically resized to fill its parent, instead of adding a new control. I mentioned before that I had trouble with my skin when the tracklist is not covering the whole main view. Maybe it was not so obvious because the listviews in your skins are not skinned like mine. My listviews have borders and sometimes they have margins. Your skins don't have either of that. I am using these design elements to make them look similar to the Windows File Explorer and tracklists in other programs when Windows Contrast themes are enabled. If you didn't try them already, you should know one important thing about them: since they have limited set of colors (only eight), the borders are very important part of design that is used everywhere. Now, imagine the bottom border of the listview that appears not on the bottom of the view, right above status bar, but in the middle of view, right bellow the last track row. That looks strange, inconsistent and unprofessional. Well, I already resolved that problem long time ago, much before I reported this issue, but I still think that the listview should vertically fill its parent in the Playing node, just like everywhere else in the program, including those nodes from the Playlists branch. |
|
|
I think the problem with the 0020464 issue causing double scrollbars and reported by me was not because the listview vertically filled its parent, even when it has just a few files leaving empty space below them. And I think the implemented solution for that issue was not the best, which just vertically shrinked the listview to covers only tracks. The problem is general, I have reported the new similar issues with double or unneeded scrollbars in meantime: 0020773, 0020800, beside of those that I reported before which are resolved: 0020534, 0020401. If I may guess, the problem is because the program incorrectly calculate the size of lvViewport. I think the program is calculating its min-height based only on the number of visible rows and their height, without taking in account the size of borders, paddings and/or margins of listview, lvHeader, lvBody, lvFill, lvCanvas, lvViewport or any other contained control that could cause appearance of scrollbars in their major parent, which is Scroller. I noticed that when I add margins to listviews > lvBody in my skin, the vertical scrollbars appear where they shouldn't (0020790)., which is basically the same thing that is happening in all mentioned issues. |
|
|
Fixed in build 3011. |
|
|
Verified 3011 |
- Anonymous
