Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough Martin Gräßlin wrote: so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes Fredrik Höglund wrote: For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. * So that the appearance and behavior of the KCM is consistent with that of the icon theme KCM. * So that the listview looks and behaves identically to other listviews. * To enable the user to get a quick overview of the installed themes without having to scroll. * Each item in the listview provides three key points of data so as to not overwhelm the user with information; a single large image of the most important cursor, the name of the theme, and finally a short description. Every design decision was make
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough Martin Gräßlin wrote: so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes Fredrik Höglund wrote: For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. * So that the appearance and behavior of the KCM is consistent with that of the icon theme KCM. * So that the listview looks and behaves identically to other listviews. * To enable the user to get a quick overview of the installed themes without having to scroll. * Each item in the listview provides three key points of data so as to not overwhelm the user with information; a single large image of the most important cursor, the name of the theme, and finally a short description. Every design decision was make
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough Martin Gräßlin wrote: so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes Fredrik Höglund wrote: For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. * So that the appearance and behavior of the KCM is consistent with that of the icon theme KCM. * So that the listview looks and behaves identically to other listviews. * To enable the user to get a quick overview of the installed themes without having to scroll. * Each item in the listview provides three key points of data so as to not overwhelm the user with information; a single large image of the most important cursor, the name of the theme, and finally a short description. Every design decision was make
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough Martin Gräßlin wrote: so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes Fredrik Höglund wrote: For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. * So that the appearance and behavior of the KCM is consistent with that of the icon theme KCM. * So that the listview looks and behaves identically to other listviews. * To enable the user to get a quick overview of the installed themes without having to scroll. * Each item in the listview provides three key points of data so as to not overwhelm the user with information; a single large image of the most important cursor, the name of the theme, and finally a short description. Every design decision was make
Re: Review Request 123224: KIO::suggestName suggests wrong name for some filenames
On April 6, 2015, 1:12 p.m., Martin Klapetek wrote: autotests/globaltest.cpp, line 96 https://git.reviewboard.kde.org/r/123224/diff/2/?file=359784#file359784line96 This should be (1).txt? Ashish Bansal wrote: imho if my any file starts with ., that's my dot file and I would not like suggestName to remove the dotness of file instead it should append/increment no. at end. But if you still find no. at the starting as better use case, then no problem I'll change it right away. David Faure wrote: I agree, a dot file should keep starting with a dot. Martin Klapetek wrote: Indeed. I'd suggest .(1).txt maybe to also keep the file extension in tact? Yeah that sounds good. Changed it to . (1).txt :) - Ashish --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123224/#review78559 --- On April 26, 2015, 12:19 p.m., Ashish Bansal wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123224/ --- (Updated April 26, 2015, 12:19 p.m.) Review request for KDE Frameworks, Plasma and Aleix Pol Gonzalez. Repository: kio Description --- For filenames like filename-1.6.tar.gz, KIO::suggestName suggests wrong name(something like filename-1 2.6.tar.gz). Expected name: filename-1.6 (1).tar.gz Diffs - autotests/globaltest.cpp ff8725d src/core/global.cpp f18ac10 Diff: https://git.reviewboard.kde.org/r/123224/diff/ Testing --- Works fine! Thanks, Ashish Bansal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 123506: Match window switch dialog borders with addwidgets/switch activity
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123506/ --- Review request for kwin and Plasma. Repository: plasma-workspace Description --- BUG: 345614 Diffs - lookandfeel/contents/windowswitcher/WindowSwitcher.qml e4a46366c2a4e157860f55d2cb0e3781a239cb66 Diff: https://git.reviewboard.kde.org/r/123506/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123224: KIO::suggestName suggests wrong name for some filenames
On April 25, 2015, 7:42 p.m., David Faure wrote: src/core/global.cpp, line 397 https://git.reviewboard.kde.org/r/123224/diff/2/?file=359785#file359785line397 Why do you assemble a list, and then only look at the last element? You just need an int and a QMimeType, if only the last element matters. Also, why loop over every character? Is the goal to handle .foo.txt vs .tar.gz? There's API for that in QMimeDatabase, it can return the mimetype and even the known suffix without any iteration needed, see QMimeDatabase::suffixForFileName. Ah sorry, I didn't know that QMimeDatabase::suffixForFileName can handle .foo.txt vs .tar.gz :) - Ashish --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123224/#review79509 --- On April 26, 2015, 12:19 p.m., Ashish Bansal wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123224/ --- (Updated April 26, 2015, 12:19 p.m.) Review request for KDE Frameworks, Plasma and Aleix Pol Gonzalez. Repository: kio Description --- For filenames like filename-1.6.tar.gz, KIO::suggestName suggests wrong name(something like filename-1 2.6.tar.gz). Expected name: filename-1.6 (1).tar.gz Diffs - autotests/globaltest.cpp ff8725d src/core/global.cpp f18ac10 Diff: https://git.reviewboard.kde.org/r/123224/diff/ Testing --- Works fine! Thanks, Ashish Bansal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123224: KIO::suggestName suggests wrong name for some filenames
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123224/ --- (Updated April 26, 2015, 12:19 p.m.) Review request for KDE Frameworks, Plasma and Aleix Pol Gonzalez. Changes --- fixed issues Repository: kio Description --- For filenames like filename-1.6.tar.gz, KIO::suggestName suggests wrong name(something like filename-1 2.6.tar.gz). Expected name: filename-1.6 (1).tar.gz Diffs (updated) - autotests/globaltest.cpp ff8725d src/core/global.cpp f18ac10 Diff: https://git.reviewboard.kde.org/r/123224/diff/ Testing --- Works fine! Thanks, Ashish Bansal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123506/ --- (Updated April 26, 2015, 11:41 p.m.) Review request for kwin and Plasma. Bugs: 345614 https://bugs.kde.org/show_bug.cgi?id=345614 Repository: plasma-workspace Description --- BUG: 345614 Diffs - lookandfeel/contents/windowswitcher/WindowSwitcher.qml e4a46366c2a4e157860f55d2cb0e3781a239cb66 Diff: https://git.reviewboard.kde.org/r/123506/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123506: Match window switch dialog borders with addwidgets/switch activity
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123506/#review79544 --- +1 - Aleix Pol Gonzalez On April 26, 2015, 11:41 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123506/ --- (Updated April 26, 2015, 11:41 p.m.) Review request for kwin and Plasma. Bugs: 345614 https://bugs.kde.org/show_bug.cgi?id=345614 Repository: plasma-workspace Description --- BUG: 345614 Diffs - lookandfeel/contents/windowswitcher/WindowSwitcher.qml e4a46366c2a4e157860f55d2cb0e3781a239cb66 Diff: https://git.reviewboard.kde.org/r/123506/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123501: Improve suspended job appearance
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123501/ --- (Updated April 26, 2015, 5:10 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Martin Klapetek. Changes --- Submitted with commit 2b503ba920e44f629fe83ec6a1382239dcb7c6a2 by Kai Uwe Broulik to branch master. Repository: plasma-workspace Description --- Today I noticed that a paused job is not really obvious, other than the tiny pause button turning into a play button. This adds (Paused) to the title, such as Copying (Paused) in that case. Also turns off the indeterminate animation then since it's not really doing anything. Diffs - applets/notifications/package/contents/ui/JobDelegate.qml f3f091d Diff: https://git.reviewboard.kde.org/r/123501/diff/ Testing --- Works fine Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123502: Manually keep track of jobs sources
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123502/ --- (Updated April 26, 2015, 5:24 nachm.) Review request for Plasma and Martin Klapetek. Changes --- Rebased to current master Bugs: 346673 https://bugs.kde.org/show_bug.cgi?id=346673 Repository: plasma-workspace Description --- DataSource sources is a QStringList property which means changes within cannot be tracked causing all the job delegates to be destroyed and re-created when sourcesChanged it emitted. This is pretty wasteful but also causes the delegate to lose their sate (eg. details expanded). Diffs (updated) - applets/notifications/package/contents/ui/JobDelegate.qml 709b7fd applets/notifications/package/contents/ui/Jobs.qml 6ecf366 Diff: https://git.reviewboard.kde.org/r/123502/diff/ Testing --- Adding, removing and pausing jobs works as expected, when a job appears or disappears the other delegates keep their state. The only slight imperfection is now that the indeterminate state of multiple jobs is no longer move in sync because the items are no longer created at the same time. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
