This forum has been archived. All content is frozen. Please use KDE Discuss instead.

[Design Help Needed] KGet redesign for KF5

Tags: None
(comma "," separated)
boom1992
Registered Member
Posts
20
Karma
0
Hey!

This is going to be a long post. I hope I didn't miss any questions/suggestions. If I did, just tell me, I'll answer them afterwards.

First of all, Heiko, the dialog you are experiencing is indeed not normal. The downloads are supposed to be acting like regular file copy operations in the notification area. Do you use Plasma5?

I really see great progress in the last mockups, they start to look really awesome. I'll go through the suggestions one by one.

Browser integration:
I think this is the main reason why people don't use KGet. Even with the FlashGot plugin in Firefox, it is very poorly integrated. From what I see, we would need to write a custom Firefox plugin for this. Currently when I'm for example trying to download from protected sites (e.g. when you have to login first), it fails, because we don't send the correct request header (session data etc). This has to be fixed to get a smoother experience.

That means we have to write plugins for both Firefox and Chrome. I certainly have never done it, if you have, please speak up!

@Andreas: I'm not sure if the browser-integrated-downloads-view is that useful. In KDE I'd imagine any running tasks to sit in the notifications area. Once a file is selected as to be downloaded, the scope changes and it should not be handled by the browser anymore.

Adding new transfers:

We have seen some mockups for this dialog in this thread. My current opinion on this is that this dialog should not exist anymore. I think currently KGet "interrupts" the user too much whereas it should probably just start to download the file. The destination would be selected from the configured transfergroups, mimetypes and one default download location (~/Downloads). Once the download is added it can be changed in some sort of transfer settings dialog.
At least in my experience users don't want to configure programs, they should just work. For example I would probably not configure KGet, but instead just always go to the file browser to move files manually, even if I knew better or it would even save me time. In order to catch this, we should probably detect if a certain mimetype or files from a certain host were always moved to the same destination and "suggest" the user to configure a transfergroup automagically.
I only got this idea today, so it is very rough. I think we could somehow query Baloo for something like that.

Desktop integration:
As I already said above, the running downloads should be in the notifications area per default.

Activities integration:
I'm not exactly sure how it'd look like exactly especially as I don't really use them myself. I'm open to suggestions though. This is a topic which we should definitely tackle.

Main Window:
I really like that downloads and history are now integrated in the same view and also the new list view. I also love that you can search the downloads view, probably there should be an option to filter file types even?
My stance on sorting is that it should represent the priorization of downloads, for sake of easyness we can imo remove the custom sorting options.
I'd like to refrain from commenting too much on this now, it seems to be a moving target here and we are moving into the right direction. We have to think about the features we want to keep in KGet and which ones to remove.

Streaming support:
Yes, this is already implemented for MMS streams, so it can be done definitely. I think it mostly needs browser integration plus a lot of streams on websites are done within a Flashwidget. I'm not sure how to technically get the data out of it.

What do you think? :) Sorry that it took a while for me to answer this thread.

Lukas
boom1992
Registered Member
Posts
20
Karma
0
And I totally forgot to comment about the minimal mode! Sorry!

Well, I like the idea of having the downloads "only" in the notifications area. Not sure if an additional "program mode" is needed for this though. After all, when we start downloads automatically, the user does not have to open the KGet window anymore.

Did I miss something in the proposal?

Lukas
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
KDE Connect integration ;-)
boom1992
Registered Member
Posts
20
Karma
0
andreas_k wrote:KDE Connect integration ;-)


Ahh yes, definitely +1. I'd refrain from doing DWD things yet, but KDE Connect definitely! This could possibly done in a global way though, that all running operations in the notification area are in your smartphone as well.
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
the "porting" of the notification center was a global approach but when you want to add an download from your phone to KGet desktop app this was an KGet task.

I'm very happy that you work with us and I'm very excited how the finished result was.
boom1992
Registered Member
Posts
20
Karma
0
andreas_k wrote:the "porting" of the notification center was a global approach but when you want to add an download from your phone to KGet desktop app this was an KGet task.

I'm very happy that you work with us and I'm very excited how the finished result was.

Yes true! Sorry! We should add this yes!

Lukas

PS: Please don't get your hopes up too high. I'm usually pretty busy, but I hope we can implement everything still!
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
We make a vision together, when this vision will be real is not important.
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
CTown wrote:@HeikoI do like your simple mode as I see a need for it.


Heiko and CTown that's a great idea. I make an save dialogue research and therefore I compare the existing save dialogue, simple mode as Heiko propose, KDE save dialogue, gnome dialogue, windows IE save dialogue and gimp save.

save one and save selected files

I prefer gimps save dialogue, because it is really simple but you can extend them. So the changed mockup for one and more selected file.
- On top save folder has changed to the last mockups, because at the kde-dialogue you have first to select the save folder and than the save name. so I change the arrangement to have nearly the save view than the standard kde save dialogue. The other destination will open the full folder selection.
- save file shows one or the selected files. when you have one file selected the dialogue show the filename selected to change the name. if you have only one mimetype selected you have an additional dialogue for download the mimetype automatically.

I removed the tag section, because tagging should be discussed as a global approach in kde and than we can use the tag style of the KDE save dialogue.

Save all from one url

And for save all files from one url. Everything is exteded.

I hope everyone can see how well workflow design work when people work together. If I look to the first draft, ...
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
You place confirmation buttons according MacOS style but not KDE. We have the positive finalization (Save) right hand. And I would make Save the default.
The first dialogs are not really simple with 8 options in order to just confirm to save a file. Maybe it's due to the number of simple controls (save-all dialog looks "normal"). Is it necessary to have different confirmation dialogs?
User avatar
colomar
Registered Member
Posts
947
Karma
2
OS
Heiko Tietze wrote:You place confirmation buttons according MacOS style but not KDE. We have the positive finalization (Save) right hand


Um... I guess you're confusing something here. Having the confirm button on the right is OS X style, KDE style is cancel on the right ;)
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
colomar wrote:I guess you're confusing something here.

Absolutely right. Cancel is on the right side (https://techbase.kde.org/Projects/Usability/HIG/Dialogs). I should read the HIG ;-)
I very much apologize, Andreas.
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
Heiko do you think it is a good idea to start with the detailed view with the sections URL, Save in folder and Save files and if the user has select one or more files via the webbrowser integration the user see the compact selection and when he want to see more to use the button on the right. also for the save folder standard = last selection and with the right button you can change.
I know the mockups don't look like the standard kde safe file dialog but my vision is to have a mix between the gimp and the kde dialogue. you start with the gimp dialogue where you have everything preselected and can extand to the kde dialogue, where you have on the left side the places, disk, download groups, filters, .. items and on the right an list view of the files on the disk (where you want to save) or the webserver (where the files to download are).
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
andreas_k wrote:Heiko do you think it is a good idea to start with the detailed view with the sections URL, Save in folder and Save files...

Yes, I think consistency cannot be overrated. Gimp or Inkscape make their own dialogs and add problems by doing so instead of solving. Take Inkscape's export bitmap (I don't remember Gimp right now): when I change the file name the selection is saved immediately and the obvious action 'export' leads to confirmation to override a file. It would be appropriate in my opinion to get the standard save dialog on clicking export. In short: Use the default UI for standard functions.
CTown
Registered Member
Posts
40
Karma
0
OS
Yeah, we need options to make it easy to skip the download dialog without just being an alternative download manager that does the same exact thing that a web browser does but actually needed to be set up...

One way could be that the user downloads a file (say a mp4 or webm video file) and it goes to ~/Downloads/video (lowercased could mean it was autogenerated by a program where capital could mean the main folders: Music, Documents, Video, etc.). The user can easily move those into the main folders later.

Another way could be to just use the main folders right away. A mp3 could go to ~/Music right away. Most music is somewhat tagged anyways, which should be enough for the music player to show the file in a meaningful manner. On Deskop Linux, music players are given specific folders to use for the music library. So, just make KGet put the music there directly by default. The same could be said about videos and pics (with Dragon player and Gwenview respectively). The music player could also rename files based on tags (the default pattern should be "sane" or just plain good enough until/if the user changes it). If the user wants to add music/video/pics/etc. to a device, it should be drag/drop from the respective media app to the device. Also, since the VDG is designing all of these types of apps from scratch it should be for possible for a future where the user is never hassled about files, folders, or dialogs (oh my!). The internet is where most files come from - perhaps putting them all into one single place is "old school".

These main folders could be either derived through system settings or by checking where most music files are stored using something like Baloo.

Plasma Base Apps (or whatever they are called), yeeaaahhhh!

What do you guys think?


Bookmarks



Who is online

Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]