Re: Selecting a Plasma logo
After some consideration I think I would pick anditosan's proposal. With my second being Kver's fourth icon. My reasoning is the following: - It's so simple a child could draw it - It's easily recognizable without being noisy - It's simplicity allows both flexibility and works well at different sizes All of the above fits Ken's 4th too. Now since I implicitly rejected the others I want to give some feedback on them too, as I sadly didn't have time to do so on the forum. Quiralta's proposal is simple and uses a metaphor potential users are very familiar with. However, it appears noisy. That mostly stems from 3 things: - there are overlaps - the overlaps have different sizes - it shows a line of action Now one can argue the first two point for anditosan's proposal too, however, in combination these really stand out. For anyone who wants to draw comics/mangas/anything involving moving objects one will eventually find the "line of action" technique¹. Basically, we are able to infer that objects/persons in picture/drawing have a motion to them because one can draw an imaginary line through the object around which the object[s] are structured. The more the line is bent, the more dramatic the movement is. AlexL's proposal probably fits best to the KDE logo and it is simply and easily recognizable. However, it also suffers from the same problems as the K-logo. The details of the gear are lost on smaller sizes, and width at the base of the teeth is much bigger than the line connecting the actual teeth with each other. Which especially at smaller sizes looks muddled. Then there's also the problem that the cog icon, while abstract, is not abstract enough. It's an often use metaphor or settings/mechanism etc. Combining the arrow with the cog does not manage to separate it from the settings metaphor. So the unknowing will most likely search for meaning in the cog metaphor first before exploring other possibilities when trying to interpret the icon. Which leads to it looking strange, as on the one hand it has a clear metaphor, while inducing ambiguity about its actual meaning. Contrast that with anditosan's icon, which is abstract enough to not immediately associate it with a common metaphor, while not being completely foreign. And last but not least the cog is quite harsh. It's associated with industry, manual labour, and – more abstract – thinking, analysis and work. While the round shapes for anditosan's proposal are more humanizing, soft and overall more inviting and friendlier. With all that being said: I would caution against on choosing the one™ solution too quickly. I think Ken has shown nicely that anditosan's proposal is worthy of further investigation. We ought to flash out its usage in different scenarios (think different styles, sizes, contrasts etc.), so I would propose to hold a second round, so to speak where we investigate the concept further to finalize it. [1] An example from a carton visualizing the concept http://photos1.blogger.com/blogger/1250/2135/1600/LofA.jpg One can apply the same for real world situations. Am 25.07.2016 um 20:54 schrieb Thomas Pfeiffer: Dear Plasma development team, dear VDG, the official deadline for the Plasma logo contest has passed yesterday. We have five entries into the contest, with one actually consisting of five different mash-ups and modifications of the other entries, and one being Plasma's current logo. You can find all the proposals here: https://forum.kde.org/viewtopic.php?f=285=133836 I think we have quite a good selection here, and hope that we can find something here which we can agree on. In the contest thread, I promised a jury consisting of VDG members and Plasma team members. Now I've decided that since the whole Plasma team has to be able to identify themselves with the logo, and all VDG members should have the possibility to chip in as well, everyone who participates in the discussion is part of the jury. There won't be a voting process. Either we can agree on a logo, or everything stays like it is (the official Plasma logo still being what we have now, and the K logo being used for the launchers). I'd give us a discussion period until Sunday, unless a clear agreement can be reached before that. Please refer to the logo proposals by the creator's forum name (remember that our current logo is Uri's, not mine ;) ), and for Ken's just say e.g. "Ken's fourth logo". Happy discussions, here is to us finding a logo we can all (at least more or less) identify with! Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New SDDM Theme
Hello everyone, as many of you surely have seen by now: the new SDDM theme in the Plasma 5.7 beta announcement has cause many very negative reactions. After a few hours of deliberation and weighting our options the VDG came to the conclusion that it is better to postpone the release of the new SDDM theme and accompanying artwork to the 5.8 cycle. That mostly means that the "old" 5.6 SDDM theme will be used and both SDDM and ksplash will use the 5.7 default wallpaper as background. Please let me explain our reasoning: because of our less than ideal communication the new SDDM theme got started very late in the 5.7 cycle. Judging by reactions on multiple sites people did not understand that the new theme is part of the ongoing project of ours to get a unified experience from boot to shutdown. It's likely that users updating to 5.7 would feel the same. So even if we would manage to bring the new SDDM theme as it currently stands to the point envisioned by the design it would still be the odd one out in combination with the current logout dialogue. One idea was to simply get rid of the much detested blue background and use the default 5.7 one instead while trying to get the UI closer to the design i.e. fixing the bugs until the end of the beta phase. However, this would still leave us with two clashing UIs as stated above. In essence we would go from a similar login and lock screen theme in 5.6 to a dissimilar one in 5.7. This would clash with our goal of offering a more unified experience, even if it was for just one cycle. So all in all we think it will be better to land the new UI as a whole and not step by step. This will give us much more time to refine the UI design than what would be possible in the little time left and also present users with a coherent experience from day 1. Cheers, Philipp Stefan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[plasmashell] [Bug 340063] Please make KDE fade to black before turning screen off
https://bugs.kde.org/show_bug.cgi?id=340063 Philipp Stefan neptuneca...@gmail.com changed: What|Removed |Added CC||neptuneca...@gmail.com --- Comment #1 from Philipp Stefan neptuneca...@gmail.com --- Valid criticism. Having it fade to warn the user that the screen is about to turn off is a sensible thing to do. A go from me. -- 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
Re: ISO for 2014-12-12
On 14.12.2014 19:03, Harald Sitter wrote: Another thing, that may or may not be related: In the font management tab all the font previews are rendered … fuzzy. Is that a graphics related issue too, or is that an unrelated issue? Doesn't seem fuzzy to me. Can you post a screenshot? Here's the screenshot http://i.imgur.com/YSLIHVd.png ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ISO for 2014-12-12
On 12.12.2014 15:47, Harald Sitter wrote: # virtual machines virtual machines have a bit of trouble with the graphics. At least with virtualbox you can workaround the problem by temporarily switching to a different TTY (right-ctrl+f1 - right-ctrl+f7) I just tried it. Any idea when we can expect these glitches to be gone? Is it some qt issue? Another thing, that may or may not be related: In the font management tab all the font previews are rendered … fuzzy. Is that a graphics related issue too, or is that an unrelated issue? Thanks Phil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 14:32, Sebastian Kügler wrote: On Thursday, August 28, 2014 13:38:49 Marco Martin wrote: it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like not having any removable storage device attached would require some more complex rules I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. For this case, to allow to configure this basic functionality we came up with greying them out if the plasmoid is not configured to show non-removable devices. This way it's clear that it currently does not hold any information, however the configuration dialogue is still available. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 17:52, Marco Martin wrote: On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. so ,as a conclusion, I want to try to do a very bare bone recap: * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. * completely hide vs an extra layer of show/collapse what's better? * As a first action item, completely hide really empty plasmoids (it would be up to the plasmoid logic to decide that with setting the proper state on itself) * Still open problem: less crowded popup, but still being able to access applications that are accessible only by their systray icon I'd also add that Unity's and Plasma's interpretation of the spec are currently not compatible. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 08:16, Martin Gräßlin wrote: On Wednesday 27 August 2014 06:02:11 Philipp Stefan wrote: If the status notifiers are used like we intend them to, then the passive status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. This goes into the very broad topic of application life- cycle. The technical reality right now is that we do need to explicitly communicate lifecycle state to users because we don't have perfect state serialization - whether an app is running or not matters, because it may not come back up in the same state as when it was quit. Hmm, could you give me some examples for applications with status notifiers that handles this that way? I mean, sure applications like Inkscape and LibreOffice won't start up in the same state like when they were closed, however, applications like them don't seem to use status notifiers. I found that mostly media centred applications and those that provide background functionality like update notifiers seem to use status notifiers. Most of the ones I saw had a way or another to realize a state that is consistent with when you close the application. The only difference was startup time, but that's another story. I see your concern though. there's a technical difference: with the status notifiers the applications do not quit. They continue to run and only the main window gets hidden which can easily be restored. What you want is to quit it, but that requires application life cycle to get the application back to the state where you left it. In reality this does not exist (yet). No, we want applications to behave and use status notifiers sensibly. If your application has finished its job like e.g. an update notifier but should continue to run in the background, then use the passive flag. If you want to misuse the system tray as second task bar, then do not use the passive flag, but let it remain active. And if your application has finished its job and should not continue to run in the background then, quit the application upon closing the main window and do not continue to use the status notifier, nothing forces you to. We're not advocating to simply kick these applications out, but for them to examine if they use the status notifier in a consistent manner. Overall I'm with Eike here in this discussion. Just from my experience: people want to use the system tray as a kind of task bar for some windows. I regularly get bug reports about it not working or not working as expected. I don't like this taskbar feature of the system tray but we cannot deny that it's a real use case and we would piss off large numbers of users if we remove the support for passive notifiers (not to think about all the old xembed items we transform to systemtray icons). Yes it is a valid use case, however, you one has to weight it against its downside. This use case starts to collide with others and more importantly starts to clutter the system tray, because the system tray can not guess the intend of the application. It can not discriminate between applications that are in I'm useless, please hide me mode, the ones in Hey, I'm using this to preserve my state mode and the ones in the I'm still doing something that could impact you negatively, but don't mind me please mode. If there was a way for system tray to tell these apart then that would be rad, but I don't think there is. What's important to notice is that there are applications which would break if you remove it. Yes we are aware of that and have acknowledge it several times now. Please start to look at it from the other side. Look at what the applications provide in the system tray icon and why they are doing it. Then come up with an idea how to solve the use case, which we can then implement and after that deprecate the usage in the system tray. I did and I am trying to do that. I do not like to remove functionality, especially because that is one of KDE's strength and to avoid the notion hurr durr all design is the same, it's GNOME all over again. My personal suggestion (which won't surprise anyone on this list) is to move the application status notifiers into the tasks applet. But that's not a really easy task and would not interact well with the remaining tasks. From my experience it's obvious that users don't want their ktorrent to take up any useable space from other applications, but it needs to be easily reachable when they want to interact with it. That's an interesting idea, but I believe it's even less enforceable and coherent than our idea, which already does not seem to be liked well :D. One question remains though, why do users not want KTorrent to take up 22px, but are okay with an indicator for the music player while having the music
Re: VDG suggestions and wishes about the system tray
I think I should maybe clarify a few things here as I feel that my original post has left behind the idea in some that we sought a solution in search for a problem. So what is the problem we are trying to solve? The problem is that currently the system tray icons behave unpredictable to the user or formulated differently: The user can not predict the status of an application based on where its icon shows up in the system tray, so the burden of differentiating and rating if an application provides important information lays on the user instead of the application/application developer. This problem exists to some extent in the panel part of the system tray, but it is most apparent in the popup. In the popup we have plasmoids which hold no information for the user except when they do, like the battery plasmoid when the battery is fully charged but is still used to adjust the monitor brightness. The same thing can be said about status notifiers. So the popup loses its function as an area for information that is still somewhat relevant to the user, but not relevant enough to warrant constant display, because the actual important parts are buried beneath a flood of icons/notifiers with no relevant information at all. The idea of this area is sound, but it does not work with the tool at hand. The very best solution would be to add a 4th state to SNI, a needsHiding state, if you will. However, we share this specification with another DE, Unity. So there are several possibilities how things could play out: 1. Canonical accepts the changes and changes their system tray to accommodate the new behaviour. All applications using status notifiers would have to be adapted. This would also solve the issue that some KDE applications' notifier is broken in Unity e.g. KTorrent. I'm not sure how realistic this option is, given that they seem very happy with how their implementation works. 2. We adopt Unity's policy in handling the passive status. Only some applications like KTorrent would have to be adapted, but would now be working in both Plasma and Unity again. 3. We add a 4th status to SNI without Canonical's agreement. We'd end up with xembed, GNOME Shell's thing, appindicators, and our new SNI – 4 with each other incompatible solutions. The only place where we can realistically pull this off is system tray plasmoids, as they would not work in Unity anyway to my information. 4. Do nothing, the system tray popup remains as cluttered and space wasting as always. Another thing to clarify: The proposal of the changes on plasmoids and status notifiers are _not_ independent of each other. If the changes to plasmoids are accepted, then we would have improved the their usefulness, but the overall problem would still be there. We need to have a way to separate the useful passive icons from the useless in order to improve the situation. We think that the most realistic option is 2., but the best solution would of course be 1. I have tried to reach out to Canonical, but I had not much luck, probably because I do not know the right people. What's important to note is that we really did not came up with this out of the blue, and we did assess the situation, what applications are doing and why. We really just want to improve the situation and think that 2. is the most realistic option while encompassing relatively little work. We don't like to break work flows either. If we can pull of 1. that would be rad, but I really doubt it's going to happen any time soon. Cheers Phil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
VDG suggestions and wishes about the system tray
Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. Status Notifiers Current status: * Passive ones often don't provide useful services (as intended by the specification) * Other DEs hide them [passive notifiers] completely * Some applications can only be resumed after clicking the notifier in the popup One key problem I have found is that status notifiers are somewhat abused on the desktop. Plasma migrates status notifiers that are in a passive state into the system tray popup. The specification mentions that this state should only be used when the applications does nothing of interest. Many applications follow that line of thought, some don't. The question is, when the notifiers don't do anything interesting in their passive state, then why show them at all? I don't think that the process of terminating an applications warrants the need for their own notifier. Unity, the only other DE to my knowledge that uses status notifiers, hides these too. We think that is a sensible approach. It would de-clutter the system tray popup and provide a more consistent behaviour in general. Our dream system tray would handle status notifier like that: * Passive notifiers would be hidden completely, there's no way to interact with them * Active notifiers reside in the panel area of the system tray * NeedsAttention notifiers change their icon. We'd recommend a change of color This would, of course, break some applications like KTorrent. How would it behave ideally? When you open KTorren and there are no torrents configured there should not be an indicator as the applications simply does nothing for now (passive). As soon as one adds a torrent a notifiers should be shown (active). The user can then close or minimize the window and do what they do. When a torrent finishes downloading the status of the indicator should change to needsAttention to notify the user that the download has finished. If the user then does not remove the torrent from KTorrent i.e. it continues seeding, the indicator should stay in an active state, not passive as it is now. Because this would break some applications we think that it would be a good idea to announce these plans now but only enforce them in say 4 release cycles. Plasmoids Plasmoids in the system tray are those programs that draw these fancy looking dialogues in the system tray popup. * Purpose of icons in popup is not clear – often only lead to an empty page * Can not be hidden, because some the user decides what's important or not * Use differently coloured icons in popup, even though those different colours don't indicate a functional difference. For now, (almost) all system tray plasmoids don't do anything useful when their icon resides in the popup, similar to status notifiers. When one open e.g. the network manager plasmoid and decides to check what this notification icon is they are greeted with No new notifications. When one goes through the list it's always the same No battery detected, No removable media found etc. Additionally there is/was a bug that some plasmoid icons would use a lighter shade of grey in the popup. This was a bit confusing as there is no functional difference between. We propose to act on this bug and and desaturate the icons of plasmoids in the popup when the plasmoid can not provide anything of interest to the user e.g. no new notifications. Additionally we either want to make these plasmoids immune to left clicks or take the user to the configuration dialogue of the plasmoid upon a left click. We are not quite sure about that yet. It was pointed out to us that some users may wish to change the default setting, so that plasmoids which hold information for the user do not migrate to the system tray. If the user does this, then this plasmoid should retain its original color in the popup. Additionally the plasmoid icons should be sorted from top to bottom, relevant (saturated) to irrelevant (desaturated). Expander The expander is this little upward pointing arrow to the right of the system tray. We were not able to find out what the actual name of it is. Clicking on it takes the user to an overview page, where the plasmoids/indicators are listed with their names and icons. However, if our plans are to be realised then this page is not needed. Status notifiers will not show up in the popup and the name of plasmoids is easily discovered by hovering over the icon, or clicking on the icon. Unless someone here has any
Re: VDG suggestions and wishes about the system tray
On 26.08.2014 22:58, Eike Hein wrote: On 26.08.2014 22:35, Philipp Stefan wrote: Hmm, we felt that these applications should not be hidden from the user. When a user e.g. uses KTorrent and closes the window while it is only seeding, there's no telling that the application is still running, unless of course you check the popup. Except sometimes you *want* to hide things and remove them from your immediate attention. It's a I know where I put it kind of thing. Facilities for spatial organization are one of the key things a workspace provides. But yes, there are different approaches to this, as the dock pattern vs. Win-style window list dichotomy indicates ... But you didn't not put them there, system tray did. In this case, the developer decided that to put the application to position X when is has reached state Y. The user does have to learn what this happens in both cases unless they configured system tray to handle certain indicators differently.To be clear, we only want to change the defaults, if the user wants to hide certain applications or not than that's ok with us. We do not want to take away any configuration features. In case of music players and similar, we feel like these applications should not provide their own status notifiers. E.g. a music player should be controlled via their mpris2 interface, which can be accessed by a separate plasmoid in the system tray. This limits what music players can provide to the lowest common denominator of the MPRIS2 spec and our UI frontend for it. Apps are great things and app developers have a lot of neat ideas. I feel that limiting that idea potential would be a bad idea. Also because it's nice when apps can try out new things and prove them before they get added to the lowest common denominator. Never do things that limit what innovation can happen on your platform, I say :). That's certainly not what we want to do, I assure you :) Thing is, these are guidelines, not rules. If a music player has awesome new features then they can of course implement a status notifier, nothing prevents them from that. It's just that we do no recommend it by default. I'm sure lots of applications will have one thing or the other where they ignore the guidelines for good. If the status notifiers are used like we intend them to, then the passive status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. This goes into the very broad topic of application life- cycle. The technical reality right now is that we do need to explicitly communicate lifecycle state to users because we don't have perfect state serialization - whether an app is running or not matters, because it may not come back up in the same state as when it was quit. Hmm, could you give me some examples for applications with status notifiers that handles this that way? I mean, sure applications like Inkscape and LibreOffice won't start up in the same state like when they were closed, however, applications like them don't seem to use status notifiers. I found that mostly media centred applications and those that provide background functionality like update notifiers seem to use status notifiers. Most of the ones I saw had a way or another to realize a state that is consistent with when you close the application. The only difference was startup time, but that's another story. I see your concern though. This begs the question how many people use status notifiers that way. Currently there's a mix between apps that use status notifier like we intend them to i.e. when one opens the window again they are blank/the program is doing nothing; and then there are applications which treat the passive state differently. Which we would break. I think that's wishful thinking, see above - very few apps actually will come up the same way in a restart vs. an un- hide. Our application platform simply doesn't work that way yet. It might be nice if it would, and it might be sensible to decide to move into that direction. But that's a process with many steps from beginning to end. That's why I am here to discuss it. Maybe I haven't made this clear enough before, if so I apologize, but we don't want to take this into action in the near future. We know that this would break some applications, that's why we want to discuss it now. We don't see this coming to fruition till at least 5.4, well except the plasmoid part. However, as of now we feel that this destructive path is the better one to take in the long run. I'm generally not a fan of arguments along the lines of let's intentionally break this for users to exert pressure. Change can be for the better, but there should be recourse available before a switch gets thrown IMHO. We are aware of that, we don't
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 03:24, Eike Hein wrote: On August 26, 2014 10:58:39 PM CEST, Eike Hein h...@kde.org wrote: Except sometimes you *want* to hide things and remove them from your immediate attention. It's a I know where I put it kind of thing. As a side note: Many use cases of virtual desktops and activities come down to this as well, as do Yakuake and other implementations of the enduringly popular drop-down terminal pattern. It's clearly a thing. And I find it really odd how the repeated let's redesign the tray plans always ignore how and why people actually use the thing (because investigating this points to user needs, and then you can ponder how to best meet them - instead of developing theoretical this would be cleaner models). Different users want different things and we want to make this as non-destructive as possible, however, we don't think that the current state of things is acceptable. I can assure you that we did not sit together and went hurr durr, let's reorganise the system tray for fun ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
