- User Since
- Feb 5 2015, 10:18 AM (240 w, 3 d)
Thu, Sep 12
Alright, now we "just" need to port the rest.
Wed, Sep 11
Tue, Sep 10
Looks good to me. Glad the network here is not great, that helped finally nailing that one down. :-)
Sun, Aug 25
Tue, Aug 20
Looks good to me.
Sat, Aug 17
Aug 16 2019
Aug 15 2019
Jul 20 2019
Oh, right, so it follows styling but just doesn't react to change. It's minor enough that I'd be willing to just ignore it. Otherwise we're good for the proxy style route...
Honestly, I'm not too thrilled about that. I'm surprised about the mentioned bugs from stylesheets though, I thought it was proxying to the real style nowadays?
Jun 25 2019
Jun 24 2019
Addressing dfaure's comments
Did the arc amend locally to reflect the description change, that should address your comment.
Right, that's because in fact I authored this before your own patch. :-)
It was stuck in my own queue because I wanted to validate it with the following commit which I struggled with. I'll change the description.
Jun 23 2019
This seems very focused on deployments, which is good in itself. Now with my "I work in dev services" hat on, I think the scope should be slightly extended to also encompassing the amount of people looking for KDE related services beyond deployments.
Although, I can't wait to see us switching to Wayland. I think this is slightly too "focused on one tech" as a goal. I'd rather see a lot of Wayland influence in the T11054 and T11057 goals mentioned than having a Wayland goal on its own which would overlook input methods for instance (which is exactly what the people who already switched for good did AFAICT).
I don't think it is *all* doable indeed... but if the author of that goal put some more research effort into it to improve the wording it could become a strong follow-up goal to the on-boarding one. Indeed, helping users to turn into contributors would be really nice. Even though some of the point in there are a bit shoot-to-the-moon like, some others are actually very doable I think and would help a lot. Please, take time to improve it, I think it could pay off. ;-)
I agree with the other comments, and would go even one step further: anything which is aiming at improving performance and at the same time pointing finger to a particular component or framework should come with measurements. That's how profiling anything starts.
That would be a nice follow-up to the privacy goal. The wording still is a bit weak though. I might be slightly confused but I read it a bit like "be more like Qubes" which won't be enough to attract votes to that goal. I'd advise giving more details on how our world would look if the goal was reached. Also I suspect it would work only by further integration with the underlying platform: how would that be achieved? what would be needed or missing? The list of existing libraries fall a bit short there.
I agree with Lydia here, maybe it's too early to get in technical details on how to achieve it. It's maybe better for that one to focus on the constraints we want to have and the success criteria.
Jun 21 2019
Jun 20 2019
Stupid me! Adding the missing file.
May 21 2019
May 20 2019
Apr 7 2019
Mar 25 2019
Looks fine to me.
I agree moving the promote implementation in the base class could make sense now. Rather in a separate commit though.
Mar 22 2019
I'm not sure the promotion a problem in practice in this view. Yes, the promoted task would disappear, but you'd have a project appearing instead and its children would still be there I guess. It's what I'd expect.
Mar 19 2019
Mar 18 2019
Makes me wonder if we shouldn't also fix findInboxTopLevel() indeed your improved findTopLevel() makes a better job at verifying the related-to field doesn't contain a broken reference to a parent... which the inbox doesn't (and should). Would be a separate patch I guess.
Hehe, clearly I don't have the use, hence the oversight. Thanks!
It almost asks for unit testing the behavior... but that looks really gruesome to test, so except if you got an idea let's get it merged.