Re: Konqueror- GSOC idea
On Sun, Feb 12, 2012 at 2:09 AM, Abhishek Sood A wrote: > Hii I was just thinking if its possible to categorize the downloads in > konqueror depending on file types and target it to respective folders which > would make it easier to access. It's probably not enough for a full GSoC. Once you found the code which downloads files, it's a matter of adding some lines to distinguish filetypes, and adding a configuration UI. By the way, if you want to sort downloads by file types, using Nepomuk is the obvious solution. Aren't downloaded files tagged by the downloading application automatically? If so, it should be enough to add a file type tag if necessary. Greetings Stefan >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
> By the way, if you want to sort downloads by file types, using Nepomuk > is the obvious solution. I like this idea but please consider there are some people, for which Nepomuk is disabled. This can be because Nepomuk impacts the performance of their desktop in some way, or simply because the benefits of Nepomuk aren't perceived to be significant enough to jusitfy running it. A simple folder picker would be a very low overhead way to filter files. For those running Nepomuk, it is probably far more flexible and users can take advantage of that. Kind regards Andrew >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
I was not thinking of using Nepomuk. I was thinking of sorting based on file types and directing the downloads to different pre-set subfolders in Downloads(like Downloads\Music or Downloads\Documents). The downloading application identifies the file types and the application that open the file but does not categorize the same. I think this involves significant amount of work in terms of adding a UI to set the target folders for different file types and creating download filters. @Andrew: I would like to get your feedback on this and it would be great if you could let me know on how should I proceed with this. Also your thoughts on this from GSoC perspective Thanks On Mon, Feb 13, 2012 at 5:08 PM, Andrew Mason wrote: > > By the way, if you want to sort downloads by file types, using Nepomuk > > is the obvious solution. > > I like this idea but please consider there are some people, for which > Nepomuk > is disabled. This can be because Nepomuk impacts the performance of their > desktop in some way, or simply because the benefits of Nepomuk aren't > perceived to be significant enough to jusitfy running it. > > A simple folder picker would be a very low overhead way to filter files. > For > those running Nepomuk, it is probably far more flexible and users can take > advantage of that. > > Kind regards > Andrew > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > unsubscribe << > -- Abhishek Sood A Graduate Masters Student Northwestern University, >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
Hi Abhishek, >@Andrew: I would like to get your feedback on this and it would be great if >you could let me know on how should I proceed with this. Also your thoughts >on this from GSoC perspective I think it's a great idea, however I'm not a core developer so from a mentor perspective you would need to find someone who knows more. I only threw in my 2c as something that maybe worth consideration. It probably isn't enough for a gsoc project, but once again, that is not my call. Kind regards Andrew On Mon, Feb 13, 2012 at 5:08 PM, Andrew Mason wrote: > By the way, if you want to sort downloads by file types, using Nepomuk > is the obvious solution. I like this idea but please consider there are some people, for which Nepomuk is disabled. This can be because Nepomuk impacts the performance of their desktop in some way, or simply because the benefits of Nepomuk aren't perceived to be significant enough to jusitfy running it. A simple folder picker would be a very low overhead way to filter files. For those running Nepomuk, it is probably far more flexible and users can take advantage of that. Kind regards Andrew >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << -- Abhishek Sood A Graduate Masters Student Northwestern University, >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
Am 14.02.2012, 01:22 Uhr, schrieb Abhishek Sood A : I think this involves significant amount of work in terms of adding a UI to set the target folders for different file types and creating download filters. Like adding a KUrlRequester to the File association kcm ...? The problem should rather be that the path would ideally be added to KMimeType, since this should not be limited to Konqueror but also expand to ReKonq, KGet, etc. - KMimeType is however part of kdelibs/kdecore, so the change would have to go to frameworks and i don't know how this will collide with GSoC (and to be frank: i doubt this task as is would be accepted for it's scale, sorry) Cheers, Thomas Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
On 2012-02-13, Andrew Mason wrote: >> By the way, if you want to sort downloads by file types, using Nepomuk >> is the obvious solution. > > I like this idea but please consider there are some people, for which Nepomuk > is disabled. This can be because Nepomuk impacts the performance of their > desktop in some way, or simply because the benefits of Nepomuk aren't > perceived to be significant enough to jusitfy running it. I don't think these people should be our main target audience. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Konqueror- GSOC idea
> > I don't think these people should be our main target audience. We all have intel core-i5's at work and were forced turn Nepomuk off for performance issues with kde 4.7.4 / 4.8. That is not new hardware but there would still be a reasonable portion of people with lesser hardware using KDE. My Thinkpad X200 (core2duo) laptop still has alot of life left in it. For every other aspect of KDE it's very fast. Perhaps it's worth waiting for a just a few more hardware revisions before discounting that portion of users. Andrew >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
