Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101182/ --- Review request for Plasma. Summary --- Smart lists in Remember The Milk are essentially special lists which contain tasks filtered by certain criteria. Most common smart list is 'All tasks'. The bug is that on adding/deleting/modifying any task smart lists aren't updated in RTM plasmoid. One just have to wait for the next timeout update. And it turned out that the bug concerns the design of RTM library quite deeply. So the fix contains some certain changes to several places of the RTM lib (fixes to applet and dataengine are quite cosmetic). The main idea is to make all the smart lists be updated on every change to tasks. Few words about changes: 1. I added 'read-only' attribute to Request class (request.h) so that split read-only requests and read-write requests which should trigger smart lists update. 2. I made few changes to xmlreaders and Session class to keep the initial request and smart lists update inside one user action (i.e. so that 'loading' is shown during all these operations). Diffs - libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06 libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408 libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802 libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630 libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd applets/rememberthemilk/taskmodel.cpp 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8 dataengines/rememberthemilk/rtmengine.cpp 7e231efe7b0a977648c40e8438fd25a0154f0a50 libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9 Diff: http://git.reviewboard.kde.org/r/101182/diff Testing --- I've tested the code hugely with all the mentioned operations (add task, modify task, delete task) and smart lists are updated correctly with this patch. Updating smart lists on every modifying request makes it longer mainly because 1s interval between requests and slight duplication of requests here and there but I'm currently testing another patch which removes most of duplications to speed up the overall process. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Don't create another timeline on every timeout refresh in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101212/ --- Review request for Plasma. Summary --- Currently RTM plasmoid creates new timeline on every refresh triggered by timeout (usually 5 minutes) of any action with tasks. Timeline is something like user session and every user action can be undone while still staying in the same timeline. I think, creating a new timeline on every refresh isn't so wise, especially as it triggeres the massive update of all the tasks and lists. Diffs - dataengines/rememberthemilk/taskssource.cpp 06d354f9a6facfe8dc1ba42683078ab02ff39900 Diff: http://git.reviewboard.kde.org/r/101212/diff Testing --- The comment to the line of code says: "Allow us to get new information that people entered on the website or in another api". I tested the version without the line quite deeply performing task edits in both RTM web service and plasmoid and they were always synchronized with each other correctly (for plasmoid - as current timeout expired). So I see no reason in this. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Don't create another timeline on every timeout refresh in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101212/ --- (Updated April 24, 2011, 9:25 p.m.) Review request for Plasma. Summary (updated) --- Currently RTM plasmoid creates new timeline on every refresh triggered by timeout (usually 5 minutes) of any action with tasks. Timeline is something like user session and every user action can be undone while still staying in the same timeline (http://www.rememberthemilk.com/services/api/timelines.rtm). I think, creating a new timeline on every refresh isn't so wise, especially as it triggeres the massive update of all the tasks and lists. Diffs - dataengines/rememberthemilk/taskssource.cpp 06d354f9a6facfe8dc1ba42683078ab02ff39900 Diff: http://git.reviewboard.kde.org/r/101212/diff Testing --- The comment to the line of code says: "Allow us to get new information that people entered on the website or in another api". I tested the version without the line quite deeply performing task edits in both RTM web service and plasmoid and they were always synchronized with each other correctly (for plasmoid - as current timeout expired). So I see no reason in this. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: libRTM: Allow to delete completed task
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101213/#review2874 --- I think it's a bug for sure, especially provided that it's not possible to delete tasks in RTM plasmoid now. - Alexey On April 23, 2011, 11:31 p.m., Anton Kreuzkamp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101213/ > --- > > (Updated April 23, 2011, 11:31 p.m.) > > > Review request for Plasma. > > > Summary > --- > > I'm mainly filing this review request to be sure that this is indeed a bug > and doesn't have a good reason I just cannot see. > > > Diffs > - > > libs/rtm/task.cpp de36693 > > Diff: http://git.reviewboard.kde.org/r/101213/diff > > > Testing > --- > > Compiles and works, as far as I can see. > > > Thanks, > > Anton > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101182/ --- (Updated May 1, 2011, 5:38 p.m.) Review request for Plasma and Aaron J. Seigo. Summary --- Smart lists in Remember The Milk are essentially special lists which contain tasks filtered by certain criteria. Most common smart list is 'All tasks'. The bug is that on adding/deleting/modifying any task smart lists aren't updated in RTM plasmoid. One just have to wait for the next timeout update. And it turned out that the bug concerns the design of RTM library quite deeply. So the fix contains some certain changes to several places of the RTM lib (fixes to applet and dataengine are quite cosmetic). The main idea is to make all the smart lists be updated on every change to tasks. Few words about changes: 1. I added 'read-only' attribute to Request class (request.h) so that split read-only requests and read-write requests which should trigger smart lists update. 2. I made few changes to xmlreaders and Session class to keep the initial request and smart lists update inside one user action (i.e. so that 'loading' is shown during all these operations). Diffs - libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06 libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408 libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802 libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630 libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd applets/rememberthemilk/taskmodel.cpp 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8 dataengines/rememberthemilk/rtmengine.cpp 7e231efe7b0a977648c40e8438fd25a0154f0a50 libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9 Diff: http://git.reviewboard.kde.org/r/101182/diff Testing --- I've tested the code hugely with all the mentioned operations (add task, modify task, delete task) and smart lists are updated correctly with this patch. Updating smart lists on every modifying request makes it longer mainly because 1s interval between requests and slight duplication of requests here and there but I'm currently testing another patch which removes most of duplications to speed up the overall process. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Don't create another timeline on every timeout refresh in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101212/ --- (Updated May 1, 2011, 5:39 p.m.) Review request for Plasma and Aaron J. Seigo. Summary --- Currently RTM plasmoid creates new timeline on every refresh triggered by timeout (usually 5 minutes) of any action with tasks. Timeline is something like user session and every user action can be undone while still staying in the same timeline (http://www.rememberthemilk.com/services/api/timelines.rtm). I think, creating a new timeline on every refresh isn't so wise, especially as it triggeres the massive update of all the tasks and lists. Diffs - dataengines/rememberthemilk/taskssource.cpp 06d354f9a6facfe8dc1ba42683078ab02ff39900 Diff: http://git.reviewboard.kde.org/r/101212/diff Testing --- The comment to the line of code says: "Allow us to get new information that people entered on the website or in another api". I tested the version without the line quite deeply performing task edits in both RTM web service and plasmoid and they were always synchronized with each other correctly (for plasmoid - as current timeout expired). So I see no reason in this. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Don't create another timeline on every timeout refresh in Remember The Milk plasmoid
> On May 1, 2011, 8:07 p.m., Marco Martin wrote: > > Thank you. Committed it. - Alexey --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101212/#review3021 --- On May 1, 2011, 5:39 p.m., Alexey Chernov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101212/ > --- > > (Updated May 1, 2011, 5:39 p.m.) > > > Review request for Plasma and Aaron J. Seigo. > > > Summary > --- > > Currently RTM plasmoid creates new timeline on every refresh triggered by > timeout (usually 5 minutes) of any action with tasks. Timeline is something > like user session and every user action can be undone while still staying in > the same timeline > (http://www.rememberthemilk.com/services/api/timelines.rtm). I think, > creating a new timeline on every refresh isn't so wise, especially as it > triggeres the massive update of all the tasks and lists. > > > Diffs > - > > dataengines/rememberthemilk/taskssource.cpp > 06d354f9a6facfe8dc1ba42683078ab02ff39900 > > Diff: http://git.reviewboard.kde.org/r/101212/diff > > > Testing > --- > > The comment to the line of code says: "Allow us to get new information that > people entered on the website or in another api". I tested the version > without the line quite deeply performing task edits in both RTM web service > and plasmoid and they were always synchronized with each other correctly (for > plasmoid - as current timeout expired). So I see no reason in this. > > > Thanks, > > Alexey > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
> On May 1, 2011, 10:25 p.m., Marco Martin wrote:
> > generally seems correct.
> > to watch out the coding style.
> > it's quite a big patch, but given enough testing (and assuming this will be
> > multiple commits) i think it could go in
Thanks, Marco. Coding style will be fixed, thanks for comments on it. I'll try
to split the patch to several commits, but I'm afraid the one for librtm will
still remain quite significant as changes are connected to each other.
> On May 1, 2011, 10:25 p.m., Marco Martin wrote:
> > applets/rememberthemilk/taskmodel.cpp, line 250
> > <http://git.reviewboard.kde.org/r/101182/diff/1/?file=15159#file15159line250>
> >
> > } else {
> > engine->connectSource("List:" + QString::number(listId), this);
> > }
Do you mean to restore this branch? 'else' branch is removed in my patch (the
code is actually goes to 'then' branch due to 'if' condition change)
> On May 1, 2011, 10:25 p.m., Marco Martin wrote:
> > applets/rememberthemilk/taskmodel.cpp, line 243
> > <http://git.reviewboard.kde.org/r/101182/diff/1/?file=15159#file15159line243>
> >
> > this looks a bit risky..
I'll look on how to avoid it, if possible
- Alexey
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101182/#review3020
---
On May 1, 2011, 5:38 p.m., Alexey Chernov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101182/
> ---
>
> (Updated May 1, 2011, 5:38 p.m.)
>
>
> Review request for Plasma and Aaron J. Seigo.
>
>
> Summary
> ---
>
> Smart lists in Remember The Milk are essentially special lists which contain
> tasks filtered by certain criteria. Most common smart list is 'All tasks'.
>
> The bug is that on adding/deleting/modifying any task smart lists aren't
> updated in RTM plasmoid. One just have to wait for the next timeout update.
> And it turned out that the bug concerns the design of RTM library quite
> deeply. So the fix contains some certain changes to several places of the RTM
> lib (fixes to applet and dataengine are quite cosmetic). The main idea is to
> make all the smart lists be updated on every change to tasks.
>
> Few words about changes:
> 1. I added 'read-only' attribute to Request class (request.h) so that split
> read-only requests and read-write requests which should trigger smart lists
> update.
> 2. I made few changes to xmlreaders and Session class to keep the initial
> request and smart lists update inside one user action (i.e. so that 'loading'
> is shown during all these operations).
>
>
> Diffs
> -
>
> libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06
> libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b
> libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce
> libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408
> libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802
> libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630
> libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd
> applets/rememberthemilk/taskmodel.cpp
> 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8
> dataengines/rememberthemilk/rtmengine.cpp
> 7e231efe7b0a977648c40e8438fd25a0154f0a50
> libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9
>
> Diff: http://git.reviewboard.kde.org/r/101182/diff
>
>
> Testing
> ---
>
> I've tested the code hugely with all the mentioned operations (add task,
> modify task, delete task) and smart lists are updated correctly with this
> patch. Updating smart lists on every modifying request makes it longer mainly
> because 1s interval between requests and slight duplication of requests here
> and there but I'm currently testing another patch which removes most of
> duplications to speed up the overall process.
>
>
> Thanks,
>
> Alexey
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101182/ --- (Updated May 2, 2011, 5:51 p.m.) Review request for Plasma and Aaron J. Seigo. Changes --- Updated diff. Removed listUpdate recursive call and fixed coding style issues according comments by Marco. Summary --- Smart lists in Remember The Milk are essentially special lists which contain tasks filtered by certain criteria. Most common smart list is 'All tasks'. The bug is that on adding/deleting/modifying any task smart lists aren't updated in RTM plasmoid. One just have to wait for the next timeout update. And it turned out that the bug concerns the design of RTM library quite deeply. So the fix contains some certain changes to several places of the RTM lib (fixes to applet and dataengine are quite cosmetic). The main idea is to make all the smart lists be updated on every change to tasks. Few words about changes: 1. I added 'read-only' attribute to Request class (request.h) so that split read-only requests and read-write requests which should trigger smart lists update. 2. I made few changes to xmlreaders and Session class to keep the initial request and smart lists update inside one user action (i.e. so that 'loading' is shown during all these operations). Diffs (updated) - dataengines/rememberthemilk/rtmengine.cpp 7e231efe7b0a977648c40e8438fd25a0154f0a50 libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9 libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802 libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408 libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630 applets/rememberthemilk/taskmodel.cpp 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8 libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06 Diff: http://git.reviewboard.kde.org/r/101182/diff Testing --- I've tested the code hugely with all the mentioned operations (add task, modify task, delete task) and smart lists are updated correctly with this patch. Updating smart lists on every modifying request makes it longer mainly because 1s interval between requests and slight duplication of requests here and there but I'm currently testing another patch which removes most of duplications to speed up the overall process. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
> On May 1, 2011, 10:25 p.m., Marco Martin wrote: > > generally seems correct. > > to watch out the coding style. > > it's quite a big patch, but given enough testing (and assuming this will be > > multiple commits) i think it could go in > > Alexey Chernov wrote: > Thanks, Marco. Coding style will be fixed, thanks for comments on it. > I'll try to split the patch to several commits, but I'm afraid the one for > librtm will still remain quite significant as changes are connected to each > other. So can I commit it using the updated diff? - Alexey --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101182/#review3020 ------- On May 2, 2011, 5:51 p.m., Alexey Chernov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101182/ > --- > > (Updated May 2, 2011, 5:51 p.m.) > > > Review request for Plasma and Aaron J. Seigo. > > > Summary > --- > > Smart lists in Remember The Milk are essentially special lists which contain > tasks filtered by certain criteria. Most common smart list is 'All tasks'. > > The bug is that on adding/deleting/modifying any task smart lists aren't > updated in RTM plasmoid. One just have to wait for the next timeout update. > And it turned out that the bug concerns the design of RTM library quite > deeply. So the fix contains some certain changes to several places of the RTM > lib (fixes to applet and dataengine are quite cosmetic). The main idea is to > make all the smart lists be updated on every change to tasks. > > Few words about changes: > 1. I added 'read-only' attribute to Request class (request.h) so that split > read-only requests and read-write requests which should trigger smart lists > update. > 2. I made few changes to xmlreaders and Session class to keep the initial > request and smart lists update inside one user action (i.e. so that 'loading' > is shown during all these operations). > > > Diffs > - > > dataengines/rememberthemilk/rtmengine.cpp > 7e231efe7b0a977648c40e8438fd25a0154f0a50 > libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9 > libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce > libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b > libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802 > libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408 > libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd > libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630 > applets/rememberthemilk/taskmodel.cpp > 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8 > libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06 > > Diff: http://git.reviewboard.kde.org/r/101182/diff > > > Testing > --- > > I've tested the code hugely with all the mentioned operations (add task, > modify task, delete task) and smart lists are updated correctly with this > patch. Updating smart lists on every modifying request makes it longer mainly > because 1s interval between requests and slight duplication of requests here > and there but I'm currently testing another patch which removes most of > duplications to speed up the overall process. > > > Thanks, > > Alexey > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Ensure smart lists are updated on any task change in Remember The Milk plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101182/ --- (Updated May 21, 2011, 8:28 p.m.) Review request for Plasma and Aaron J. Seigo. Changes --- Updated diff with fixes according Aaron's comment and updateSmartLists() method moved to session_p.h. Summary --- Smart lists in Remember The Milk are essentially special lists which contain tasks filtered by certain criteria. Most common smart list is 'All tasks'. The bug is that on adding/deleting/modifying any task smart lists aren't updated in RTM plasmoid. One just have to wait for the next timeout update. And it turned out that the bug concerns the design of RTM library quite deeply. So the fix contains some certain changes to several places of the RTM lib (fixes to applet and dataengine are quite cosmetic). The main idea is to make all the smart lists be updated on every change to tasks. Few words about changes: 1. I added 'read-only' attribute to Request class (request.h) so that split read-only requests and read-write requests which should trigger smart lists update. 2. I made few changes to xmlreaders and Session class to keep the initial request and smart lists update inside one user action (i.e. so that 'loading' is shown during all these operations). Diffs (updated) - applets/rememberthemilk/taskmodel.cpp 8e2ab387996ec81c6c6471c8e845ad3a881a4ce8 dataengines/rememberthemilk/rtmengine.cpp 7e231efe7b0a977648c40e8438fd25a0154f0a50 libs/rtm/request.h 58cb7daec491b652c5de2a1e18214df5e7baa5e9 libs/rtm/request.cpp a2983300b989acd278e855623457a743948e1cdd libs/rtm/session.cpp dfd5db27c7a48a24921fd1ddbd4c4acf82fe9408 libs/rtm/session_p.h 34c2063a5a2015bed0e2bd8b9681df5c7b9e2802 libs/rtm/task_p.h 00c794e75457f4de3680f0689dc4b741f15db4ce libs/rtm/xmlreaders.h 882f0500c7178bf5982a65b01b3cc2268ba1fe8b libs/rtm/xmlreaders.cpp 507ac0d1c7f85e7e53c57ef022a78e78c619dd06 Diff: http://git.reviewboard.kde.org/r/101182/diff Testing --- I've tested the code hugely with all the mentioned operations (add task, modify task, delete task) and smart lists are updated correctly with this patch. Updating smart lists on every modifying request makes it longer mainly because 1s interval between requests and slight duplication of requests here and there but I'm currently testing another patch which removes most of duplications to speed up the overall process. Thanks, Alexey ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On 20 дек 2011 11:20:23 Aaron J. Seigo wrote: > On Tuesday, December 20, 2011 00:33:20 4ernov wrote: > > unclear why you so against to approve such a work. > > i think it is perfectly fine if you wish to create a modified kickoff and > ship it as a separate plasmoid. this is what we've done for a few different > plasmoids, including the tasks plasmoid (and that's ended up turning out > rather well for everyone i think :). No, I mean a contribution with config option or something which can return the Back button. I don't think it's perfect idea to fork kickoff because of one function. > i do not want plasma desktop to become a collection of everyone's pet > features with a thousand configuration tweaks. Exactly. I agree. But as I remember Martin said that we're discussing only config option and reverting to Back button wasn't an option. I think, nobody also wants Plasma desktop to become a collection of wrong decisions, it's even worse. > the back button was not > serving everyone well (we got lots of feedback on it ...) I didn't say the Back button was ideal. I think a serious usability research should be performed to find the better solution instead of it. And I can't believe any usability expert could suggest breadcrumbs instead of back button as it's just against the basic things one could learn in usability. > and the > breadcrumbs are more consistent with what we see elsewhere (file dialog, > dolphin, ..) That's right. But there're areas (URL string in browser, date and time string in clock applications, rich text editors etc.) where breadcrumbs look more natural but in spite of it it's not used there. Yes, it will probably make something more consistent but will spoil things in many other areas. I don't think consistency is the key factor here. As to me, my solution is: keep both Back button and breadcrumbs. Here's my arguments: - no config and no tweaks required - users can use both ways - no redundancy or duplication as it's just two methods to reach the same result (there're thousands of examples with such implementations, e.g. same features in main menu, toolbar and context menus in one application) - minimum of code required I don't mean that it's a bad code or something and I respect all the efforts of Martin and whole Plasma team to improve navigation, to find some better decisions. But I think such a things should be discussed especially given a significant number of critical comments. If something was wrong I don't see any problems to solve it. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On 20 дек 2011 19:31:06 Rick Stockton wrote: > Alexey, you have two of KDE's smartest people (Aaron and Martin) in > agreement that we probably want to provide this via the "Back" Button on > the Mouse. (Less new code, less confusion, less maintenance headache.) > That's the option on the table, with tentative "+1" assessments. Would > that alternative be INADEQUATE, in a REALLY IMPORTANT way? > > If it's got a defect, I really don't see it. Please advise. No, nothing against except that mouse buttons can be easily rearranged (for instance, I have 'back' and 'forward' buttons on my mouse but arranged them as 'copy' and 'paste'). Anyway it's definitely better to have it if it's easy to implement as you describe, so thank you for a good idea. In my opinion, the main discussion here is around GUI elements and this approach is quite similar to hotkeys, it's a little bit different story. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On 21 дек 2011 08:25:03 Martin Gräßlin wrote:
> but that's the point. Now in a month someone else wants something completely
> different. Then it's still not the perfect idea to fork Kickoff because of
> one function. A month later the next config option creeps in and another
> one and another one. And a nice small applet becaume a Frankenstein.
>
> Either you decide that no non-valid config options go in or you have
> discussions about it each other day.
As I said before, I agree with it. I don't know the whole background but it
seems to be right.
>
> > > i do not want plasma desktop to become a collection of everyone's
> > > pet
> > > features with a thousand configuration tweaks.
> >
> > Exactly. I agree. But as I remember Martin said that we're discussing
> > only config option and reverting to Back button wasn't an option. I
> > think, nobody also wants Plasma desktop to become a collection of wrong
> > decisions, it's even worse.
>
> Yes, I said we can discuss the need of a config option. For that we require
> good arguments why such an option is required. That has not yet presented
> here. Neither we can do it, nor but it was there is a good argument.
Yes, we discuss it as you propose it as the only way "with the Back button".
Now you give an argument that config options are bad in general. Does it mean
it never was an option?
> So you are a usability expert? I didn't know that. I am no usability expert,
> because of that I do not argue with usability. (Just look through my mails
> you will nowhere find that I say the breadcrumbs are better and the back
> button is worse from a usability point of view). If you have not studied
> usability, I would appreciate that you don't pull such arguments. It a
> serious field of research and we should not do like we know better.
Nope, I'm not. But since you mentioned millions of users somewhere below I
would expect some usability research to be performed for such kind of cases.
So my question is: how then it was decided that Back button should be replaced
with breadcrumbs? Is it right that you don't know whether it's better or worse
than Back button in terms of usability but still make such a decision?
> I'm sorry but all your examples are bad ones. Let's consider them:
> * main menu is normally dropped. Finding an option there is a complicated
> task. See for example Unity which basically removed the menu completely.
> * context menu you have to explicitly trigger, you have to know that the
> functionality is there.
I meant application main menu (File, Edit, View etc.), sorry if it wasn't
expressed clear. Also I wouldn't say Unity is an ideal example for this, but
AFAIK it just moves application main menu to global level so main menu isn't
gone completely. Anyway, it was example that multiple ways to the same
functionality aren't necessary evil, redundancy or duplication, it was just a
description for my argument ('no redundancy or duplication').
> With Kickoff we are talking about two always visible and directly reachable
> UI elements. This is something completely different. We also have to
> consider how close these UI elements are. Given the new QML design they
> would border each other. That is one of my main concerns that it visually
> clutters the view, makes them inconsistent (only one of four views uses the
> back button) and confusing. I don't see why the average user would need
> this always there. To me this looks like you realized that you don't get
> your config option and now you try to adjust your argument ;-)
No, not really, I initially wanted to keep both methods, you can see it in my
bug report (http://bugs.kde.org/show_bug.cgi?id=285401) which is now a
duplicate to more famous one. We just began to discuss a config option but
Aaron and you pointed to the problems with config and I tend to agree.
> > - minimum of code required
>
> this is just not true. This would significantly increase the code size. See
> my other mail on that subject. As I wrote I expect an increase of code size
> for one QML file by at least 10 %.
Hmm.. OK.
> > I don't mean that it's a bad code or something and I respect all the
> > efforts of Martin and whole Plasma team to improve navigation, to find
> > some better decisions. But I think such a things should be discussed
> > especially given a significant number of critical comments. If
> > something was wrong I don't see any problems to solve it.
>
> Which significant number of critical comments? How many users have commented
> here in the thread and reported bugs? 5? 10? 20? We are talking about a
> feature which will be used by millions of users. If we get to a thousand
> users complaining we can start to think about significant numbers.
Well, it depends. For someone every single user is significant, other projects
can lose thousands of users and feel good. For me it seems significant.
> A small anectode: we had a recent event in the state where I live. In our
> state capital
[kio-extras] [Bug 348163] New: NFS configuration fails on absence of xdr_u_int64_t type
https://bugs.kde.org/show_bug.cgi?id=348163 Bug ID: 348163 Summary: NFS configuration fails on absence of xdr_u_int64_t type Product: kio-extras Version: 5.3.0 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: default Assignee: plasma-devel@kde.org Reporter: 4er...@gmail.com KIO extras fail to configure because of absense of xdr_u_int64_t in RPC. As far as I found, that's due to deprecation of rpc part in modern Glibc. I also think that the problem is connected to this review: https://git.reviewboard.kde.org/r/120969/. I've added includes of headers from libtirpc, NFS kio seems to build and work fine. Perhaps, it makes sense to migrate it to libtirpc completely for GNU/Linux. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
