D27544: Fix update scenarios with no explicit downloadlink selected

[Dan Leinir Turthra Jensen]

leinir added a comment.


  In D27544#622272 <https://phabricator.kde.org/D27544#622272>, @ngraham wrote:
  
  > As an aside, I'm somewhat dissatisfied with the current UX when there are multiple files. :( I converted a friend of mine to Plasma the other day and he was very confused by the multiple items available when he was downloading new stuff using the new GHNS window. I know that some of this is the fault of content uploaders, but if so, there has to be a way to guide them to upload only one file, or to mark a specific file as the real/primary one, and to label everything properly etc.
  
  
  We are at least two people not too happy with that situation... The label we're using for that now is technically a free-text field, so it certainly should be possible to fix in a backwards-compatible sort of way (as it's a question of what the server provides us with)... but as for "the real one", that's not a thing that makes sense except in very specific cases (for example, it makes no sense conceptually when you have e.g. icon sets or mouse cursor sets with multiple variants...). However, each downloaditem does have a tags section, and while that would need some thought put into it, i think we could do something clever with that. A bit outside the scope of this patch, of course, but something to spent some braining time on :)
  
  In the meantime, the situation needs some work anyway, as what currently happens when there's crazy long downloaditem names is that it gets elided on the right... which would be sort of fine, if you could get to that information some other way, which you can't, so... yup, wants fixing ;) (also outside the scope of this patch, mind, but still)

REPOSITORY
  R304 KNewStuff

REVISION DETAIL
  https://phabricator.kde.org/D27544

To: leinir, #knewstuff, #frameworks, #plasma, ngraham, apol, #discover_software_store
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200305/3fe5c8c2/attachment.html>