👍
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Aug 6 2019
Mar 10 2019
Jun 6 2018
Sep 1 2017
The horizontal alignment of the label is off compared to the rest of the labels, I guess it's because it's not in a groupbox.
The horizontal alignment of the label is off compared to the rest of the labels, I guess it's because it's not in a groupbox.
Jul 28 2017
@dvratil has slightly more elaborate solution at https://phabricator.kde.org/D6960
Jun 2 2017
That's up to Kai/VDG, I guess. I was just wondering what changed
from the previous patch where everyone agreed to not do it because
it would be confusing.
Jun 1 2017
This was discussed at length in https://phabricator.kde.org/D4215
May 8 2017
Well, technically you cannot add new strings only
and new features only, adding the busy spinner
would be ok as it's a fix for a bug.
I think this could also use some loading
indicator? Like the busy widget or at least
some label somewhere saying "Please wait"?
May 5 2017
Apr 19 2017
+1 looks good, although "Dialog hesla" je zvláštní češtin :)
Apr 15 2017
Ah, I see. Good to go then, unless you want to wait for VDG input.
While I like this, I wonder - for apps that will send "settings"
action there will now be no way to access the KNotification
settings, right (from the notification itself)? As in, the app can
use the "settings" action for an entirely different thing, thus
blocking the standard config UI, maybe?
Apr 11 2017
Same as the other diff, if safe, good to go.
...provided the usage of uiLanguages[0] is safe like this.
Apr 6 2017
I disagree with this because we currently don't have any
easy and/or sensible way to change date formats and so
we simply suggest using different locales for the different
formats. However, if your UI language is all Spanish and
you want to use the US date formatting, the month name
labels would suddenly be in English while they should
remain Spanish (and this is what the code you're removing
does).
Mar 9 2017
Looks like this could work. The KDE_FULL_SESSION check is
really old, I'm not sure if this has any implications.
Feb 26 2017
- A quick check if KSplashQML is found in the processes list (afaics, there's no alternatives to ksplash)
- KNotifications could send an async call to KSplash with a very quick timeout and start deciding on its queued notifications if/after the answer arrives
To expand on what Thomas said, SNI is just a specification,
the implementation is fully up to the shells. We chose to
implement it as systray icons, but some innovation there
could take it to much different places. So far nobody has
come with ideas of what that innovation may be, however.
Thanks for the patch! I wanted to do exactly this a long
time ago. However this solution brings a burden to all
apps using KNotification in form of a blocking dbus call
which is further only relevant when used in Plasma.
Feb 25 2017
Are you sure this doesn't break any existing stuff that is using these headers?
Feb 23 2017
I think this is good. Might look a bit weird when you
have a whole bunch of services with default icons
but oh well.
Feb 22 2017
Ok, can you perhaps put some other/generic/nice icon
if the iconName() is empty? Just to keep the list consistent?
Or maybe put the icon elsewhere so that it won't affect the
alignment? But I ain't no designer..
What happens when the service provides no icon
name or an icon that cannot be found? Can you
please test that?
I don't think that KNotification as a framework should hide this feature from the developer.
Feb 21 2017
Well, I would argue that Android is using exactly indicators
which we know as SNIs. It's the same thing - it's an icon in
your top panel and when you pull the panel down, you see
the title, text and available actions. This is _exactly_ what
SNI does, it just so happens that on desktop the representation
is always an icon with context menu. It has title, text and
actions and is often accompanied by a popup notification.
Feb 18 2017
I'm happy to (try to) hand over the access to the set of keys used for KAccounts if there's some action towards that. It should probably be handled by sysadmin in the name of KDE e.V. while granting manage rights to (KAccounts) developers.
I see your usecase, but I think there might be better solution overall
and that would involve not actually depending on the notification. As
you say, servers should enforce maximum timeout, Plasma does just
that and there's no safe way to predict what other servers would do.
This was discussed couple times before and the reason
this was never added is because of potential misuse of
this by setting extremely high value, making the bubble
virtually sticked to your screen forever. This should be
handled by the server that should do the right thing(tm)
like eg. Plasma does a word count and then with simple
heuristic determines the display time. Regardless of
Plasma however, the server should always have a sensible
default that all apps should follow, therefore this option
was never added and I still think it shouldn't be there
today; I can't see a reason why would you want the
bubble to be displayed for either very short time or very
long time. For anything in between the server default
should be good enough.
so that it's all managed "centrally".
Feb 17 2017
Ok, it's enabled now, but please beware that there are quotas in effect:
I'll see if I still have access.
Feb 16 2017
it's quite a mess
Feb 13 2017
Can we please fix and ship this quickly? https://phabricator.kde.org/D4142 shouldn't really have been shipped in that state.
Feb 4 2017
In D4416#82951, @hein wrote:Gnome-only spec? Why aren't they contributing to fd.o?
Feb 1 2017
Looks good, should be fine.
Jan 24 2017
Thanks, that's a nice list. I think real examples using actual native apps would provide better insight (like calendar, low battery or music player notification), but that'd be like a weekend project, so it's ok.
Jan 23 2017
Fair enough.
Jan 21 2017
Well there you go then. Just implement the default action to be always the top-most button in our actions list and make clicking the popup always execute the first action in the list. That way, if there are buttons, the user will know that clicking the popup will trigger the first action. No buttons means clicking won't do anything.
I think Plasma is the only notification system that does close-on-activate instead of executing some action
Jan 20 2017
I have never considered unpredictable on Android that when I press the "new e-mail" notification I get the e-mail client with the new e-mail.
If you just want to close then you have the big X, no?
-1, I don't want to keep thinking "am I now going to close the notification or execute an action" everytime I'm about to click the notification popup.
Jan 9 2017
If I may add a slightly unrelated comment - the circly parts of the new logo seem to throw the spinner a bit off visually, I think it could use some larger spacing in between those two.
Jan 3 2017
Code looks good to me but I also don't have a setup to test this on anymore.
Sep 10 2016
Jul 20 2016
In D2212#41055, @drosca wrote:The calendar popup size is fine for me (with patched plasma-framework), what I *still* think is broken is the gridSize scaling - see https://git.reviewboard.kde.org/r/125773/
You can also test it simply by switching font to DejaVu Sans.
Jul 19 2016
Can you post a screenshot of before/after?