Actually save tag bookmark and check if it already exists before adding
+1 on the test, can't comment on how to resolve this unfortunately
There is no KDE wide service to indicate absences or unavailability at the moment i'm afraid.
I've made the requested changes.
@nicolasfella Speaking for Gwenview: That sounds just like an idea I had a couple of months ago (I might even have mentioned it here and there). However, in the meantime I read more of the codebase and realized it's not as easy as it sounds.
Looks good to me. If @mgallien doesn't give you an "accept" in a reasonable timeframe i guess you can count this as me accepting it ;)
Thanks! BTW, It's now technically acceptable for the BUG: keyword to go at the beginning. Sysadmins fixed the bug that was preventing this from working before.
Thanks for the update!
Sorry for the delay @ngraham . I've been traveling. I'll have these changes complete by the end of today.
@tmarshall, any update on this?
classes renamed to fooUnstableV1, but i need comments, i'm not sure about the naming or how to manage the fact that's unstable..
Most of the unstable protocols just have the protocol implementation as unstable, but already kinda commit to stability to the c++ interface (as opposed to have a name which has unstable, and an incompatible version would have another class that can be as incompatible as it wants)
- fix initial state on createresource
- send done to new clients
- desktops shouldn't be deleted when the clients go away
- iget rid of setActiveDesktop
- rename the virtual desktop to Unstable
Tue, Jul 17
Dialog icons are correct on Linux with Breeze
Thanks for noticing, LGTM and restores the proper icon indeed.
Thanks! Had to workaround this earlier today.
I'd say make the casing consistent, otherwise it's a clear improvement in my opinion.
Ping? Is the proposed wording good enough, or should we maybe instead just remove the word "this" and make it use "Remove <widget name>?
- Add hint getter
- Add since keyword
Yes, I can reproduce too. qmlplugindump-qt5 org.kde.bluezqt 1.0 returns 2 for some reason. Will have to investigate.
Events from the window system seem to be handled after normal events.
Is there a way to send the event so qt processes it as window system event? Have tried looking through code and documentation, but everything that deals with window system events is private.
@dfaure great.. thanks
Rebased to master