Re: Notes from Tooling for Plasma2
On Wednesday 15 January 2014 16:37:20 Valorie Zimmerman wrote: On Mon, Jan 13, 2014 at 10:02 AM, Martin Graesslin mgraess...@kde.org wrote: On Monday 13 January 2014 18:38:49 Martin Klapetek wrote: Plasma bug situation - Martin Graesslin wanted me to put Best practices here with that the series on bugzilla usage I did on my blog [1] was meant and other best practices in KDE (e.g. telepathy) Cheers Martin [1] http://blog.martin-graesslin.com/blog/2012/04/blog-series-bugs-kde-org-fo r-developers/ Martin, I hope you will consider putting your conclusions on Techbase once your blog series is up and going. We need to get our new devels used to using BKO as one of their essential developer tools. That's a very good suggestion. I hope to find time for it and if not anybody could take it :-) Might have been a nice idea for GCI. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115046: Reduce timeout of startupfeedback to a sensible default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115046/#review47491 --- Ship it! Ship It! - Martin Klapetek On Jan. 16, 2014, 12:37 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115046/ --- (Updated Jan. 16, 2014, 12:37 p.m.) Review request for Plasma. Repository: kde-workspace Description --- It's 2014 and we don't have to wait half a minute for an application to start. In fact we mostly get false positives due to applications not handling correctly startup notifications for already running instances (e.g. click on link in email). So let's reduce to a default which doesn't look like a broken setup. Diffs - kcontrol/launch/kcmlaunch.cpp fc9543e kwin/effects/startupfeedback/startupfeedback.cpp d700138 libs/taskmanager/taskmanager.cpp 2b3bdc5 Diff: https://git.reviewboard.kde.org/r/115046/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from Async and representation
On Wednesday, January 15, 2014 20:36:24 Mark Gaiser wrote:
On Wed, Jan 15, 2014 at 6:19 PM, Marco Martin notm...@gmail.com wrote:
On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
As for the Applet name. Why that name? I'm making a plasmoid, right?
So name it as such:
Plasmoid {
...
}
That is also easier to explain to a user:
To create a plasmoid you have to create a root QML item named
Plasmoid { ... } which must contain the following properties ... bla
bla, you get the point.
i would call it Plasmoid if i can merge it with the plasmoid object, that
is now an object registered in the root context. i'm not sure it's
possible, would like to tough.
From my relative outsider view Plasmoid {} seems far more obvious
then Applet {} so if the plasma folks agree on that then i would go
for that.
Applet is the API name for this, so it should be called Applet, cf.
Plasma::Applet, which is what this really implements. Plasmoid is more like
the package format we ship these things in.
As for the current Plasmoid in the root context.. That can go and be
merged in this Plasmoid {}. You always need to have that object anyway
thus the result will be the same. Only now it will be created
because you defined it and not just injected in the root context :)
Sounds like a win/win to me.
The only downside is required refactoring :p
Then yet another note.
You say users must provide a:
minimumWidth: ...
minimumHeight: ...
which is being defined in the root item (whatever it ends up being).
But why there? I mean, the compactRepresentation and
fullRepresentation are likely to have their own different minimal
width/height. It could be the same, yes. But it could also be wildly
The idea is that compactrepresentation does not have a minimum size, it's the
fallback when things don't fit. Applets don't control their own size, they
have to deal with the space they get.
good point, compactRepresentation and fullRepresentation should export
those as attached properties, and the root object should not.
Just so that it's clear. So you just basically decided that the bare
minimum for a plasmoid (in plasma 2) is likely going to look like
this:
Plasmoid {
compactRepresentation: Component {
minimumWidth: ...
minimumHeight: ...
}
fullRepresentation: Component {
minimumWidth: ...
minimumHeight: ...
}
}
right?
Nope, even simpler:
Applet {
mininumWidth: ...
minimumHeight: ...
compactRepresentation: Component { }
fullRepresenation: Component { }
/* shared logic goes here, for example: */
DataSource {
...
}
function fooMyBar(argument) {
...
}
}
The point of having minimum* in the Applet object is easy: it's the Item's
size (as allowed by the containment) fits within minumum*, fullRepresentation
is loaded and rendered (and parented to the surrounding Item, if not,
compactRepresentation is used. Only one of them is loaded, reducing overhead
in many cases.
Now i'm starting to like it since - to me - it now makes sense.
For those two representations. I would say that one must exist.
Neither is mandatory on it's own, but one must be there at all time.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wednesday, January 15, 2014 20:02:05 Ivan Cukic wrote: KDE releases the First/Second/Third Update to the October 2014 release of Plasma Yes please! Same here. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Thu, Jan 16, 2014 at 12:09 PM, Aleix Pol aleix...@kde.org wrote: On Wed, Jan 15, 2014 at 9:48 AM, Marco Calignano marco.calign...@gmail.com wrote: Why do we have to start with A? I guess we can (at least for the first release name) find the name of the fish that better represent the characteristic of Plasma 2 . Like a fish that is fast and pretty to look at, or maybe rare but wanted because is good. All other release can go in alphabetical order or not, why do we have to, if we also have the version year and month that tells us the chronology? Only because Kubuntu does that? I think it is limiting, I suggest to stick with a marine name but forget the alphabetical order, or at least the starting point being A. Cheers Marco Using alphabetical order is useful to be able to compare two release names and be able to know which one is older and more or less how far apart. Wasn't one of the concerns (I think by Alex) that Kubuntu devs are always talking raring or saucy and we never know which version it is; so that we should always talk the version numbers instead (and even not knowing the fish name beforehand)? If people agreed on always using the date version when talking about a release, using random names would not be a problem I think. However using an alphabetical order seems just more practical because people will keep using fish names when communicating, so it would at least make our (as in developers) lives easier. *shrug* Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
Hello, On Mon, Jan 13, 2014 at 11:16 PM, Martin Klapetek martin.klape...@gmail.com wrote: This would be handled over DBus with custom QML files doing the rendering. Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Thu, Jan 16, 2014 at 2:02 PM, Bhushan Shah bhus...@gmail.com wrote: Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Currently shell, but since it will be installing those QML files, I guess apps/themes will be able to override it. I need to talk to someone more knowledgeable about that first, but they should definitely be themeable. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
If you load a qml file from lookfeel that should be fine. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from Async and representation
On Thu, Jan 16, 2014 at 12:59 PM, Sebastian Kügler se...@kde.org wrote:
On Wednesday, January 15, 2014 20:36:24 Mark Gaiser wrote:
On Wed, Jan 15, 2014 at 6:19 PM, Marco Martin notm...@gmail.com wrote:
On Wednesday 15 January 2014 16:43:43 Mark Gaiser wrote:
As for the Applet name. Why that name? I'm making a plasmoid, right?
So name it as such:
Plasmoid {
...
}
That is also easier to explain to a user:
To create a plasmoid you have to create a root QML item named
Plasmoid { ... } which must contain the following properties ... bla
bla, you get the point.
i would call it Plasmoid if i can merge it with the plasmoid object, that
is now an object registered in the root context. i'm not sure it's
possible, would like to tough.
From my relative outsider view Plasmoid {} seems far more obvious
then Applet {} so if the plasma folks agree on that then i would go
for that.
Applet is the API name for this, so it should be called Applet, cf.
Plasma::Applet, which is what this really implements. Plasmoid is more like
the package format we ship these things in.
I disagree with that.
Look at it from an outsider perspective. I am a relative outsider when
it comes to plasma.
If i want to make a QML application for plasma i would assume it's
called plasmoid since it's called like that in KDE and on kde-look
as well. If i would want to make one i would probably search for
something like creating plasmoid in qml or plasmoid qml example.
Do you see the common word? I never ever even think of applet yet
somehow the root of a plasmoid object is... Applet {..}. This just
seems vague to me.
If you search for kde applets (on google) the very first link you get
is explaining plasmoids!
http://techbase.kde.org/Projects/Plasma/Plasmoids
Everything just leads me to think that it should be called Plasmoid.
Applet seems vague to me.
So please, do thoroughly reconsider calling it Applet { .. }. If you
persist with Applet then you might as well call it Widget. Since the
common name for this stuff is widgets [1] anyhow. It which even seems
to have a web standard nowadays [2]. And a real novice user that
doesn't know plasmoids might just know the term widgets since that
is more commonly used and would thus search for something like
widgets for kde which funnily enough brings you to plasma's
predecessor superkaramba [3] which even more funnily calls the
plasmoids Plasma widgets on that very same page.
snip
The point of having minimum* in the Applet object is easy: it's the Item's
size (as allowed by the containment) fits within minumum*, fullRepresentation
is loaded and rendered (and parented to the surrounding Item, if not,
compactRepresentation is used. Only one of them is loaded, reducing overhead
in many cases.
Sorry, but i don't understand what you're trying to say here.
I've re-read your text at least a dozen times (seriously!).
What do you mean by: it's (if) the Item's size (as allowed by the
containment) fits within minumum*?
Please stick to the naming we're discussing here. Since now we're
using another name for the same thing: item.. I'm getting really
confused right now!
- as allowed by the containment .. What do you mean?
- if not... I don't even get the first condition.
[1] http://www.apple.com/downloads/dashboard/
[2] http://www.w3.org/TR/widgets/
[3] http://www.kde.org/applications/utilities/superkaramba/
Now i'm starting to like it since - to me - it now makes sense.
For those two representations. I would say that one must exist.
Neither is mandatory on it's own, but one must be there at all time.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
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
Re: Notes from Tooling for Plasma2
Currently there is a bit of a problem tracking what everyone is doing, and we all hate updating tables on the wiki. We also had a play with https://github.com/onepiecejs/nodejs-cantas an open source clone of Trello. Martin G uses Trello for kwin tracking, and we have used it before in the company I work for. It certainly seems very interesting, it has a Import From Bugzilla feature which can import an entire list of bugs from bugzilla. Could be very useful. Currently it has two auth systems; kerberos and Google auth. However it's built on the nodeJS passport system, so hopefully we can just load the LDAP backend and use it with kde identity. Maybe we can try it in plasma on someone's personal server, and if we like it we can ask the sysadmins to set up an official instance for everyone. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Thu, Jan 16, 2014 at 3:56 PM, Aaron J. Seigo ase...@kde.org wrote: - Version numbers seem confusing an not very expressive, these should rather be a technical detail (for example to group bugzilla entries) Maybe a silly question: but who finds version numbers confusing? The point was I think that 4.11.3 tells you nothing (as in when it was released for example), in that regard having the version as month/year combination is expressive enough to say for example this is old version, please update. * The version number used is Month (as name) + year Including what gets reported in about UI and command line switches? How will this work with plugin compat checking, or will there be another numerical version? I would think so. Like 2013-02 or in better format. * Plasma by KDE (don't use KDE Plasma, but rather by KDE”) What benefit does this aim to bring? This was my idea and the idea is to bring more clear separation between KDE and Plasma. You would be surprised, but every single article about KDE SC in Czech republic still names it KDE. Imho if we explicitely say This is product Plasma, done by KDE (ie. Plasma by KDE), this should help the redefinition effort. Also it's inspired by real-world success rebranding - for example Brise, the nice smell company, is now Glade and you can see Glade, by Brise - makes a clear connection to the estabilished brand of Brise and also draws a lot more clearer picture - we renamed this product to Glade, but it's still made by us. Will this be the recommendation in login screens as well? (So soon after we finally got most/all using “KDE Plasma” instead of just KDE) I would leave just Plasma [fish] here. Should other KDE applications / libraries adopt this naming for consistency? Why / why not? If not, do we expect our users and downstream to get that sorted out correctly? I think this is already mostly the case, no? We have Dolphin, not KDE Dolphin...we do have KDE Telepathy, but, well, ok...that could use a change. Everyone calls it KTp anyway, maybe we'll adopt it for good. *shrug* There are certainly products that use this naming scheme, such as perfumes and clothing, but it’ll be a bit of a stand-out in the tech space. More points for us, then? ;) * Each release gets a codename based on a marine animal (*1), in alphabetical order, one for each feature release * Please file a bug against Plasma June/2014 * KDE Releases Plasma Angelfish Having both a date/year and a code-name seems counterproductive for communication: do bug reports go against Angelfish or June/2014? (probably neither: a version number, which is a third piece of information, is used). User A says “I’m using Plasma Angelfish” and the other says “I’m using June 2014”. Seems to work for *Ubuntu. The bugzilla entries could even be 2014-06 (Anglefish). Having announcements that use “Plasma Anglefish” but “file a bug again Plasma Jun/2014” highlights how this will be difficult to understand for the casual user (and probably many non-casual users). If “Plasma Zebrafish” compatible with “Plasma Jellyfish”? This is something that version numbers actually tell you without having to look it up on a table. A date contains some implicit information, while a naming scheme needs both additional information to be understandable (e.g. knowing that it is alphabetical; a look-up table for how old a given codename is versus another) and doesn’t relate anything beyond sequence. Fwiw, I don't think users would ask these questions. I think it's anyway up to distros to provide what's compatible to the users. And distro people are imho capable of handling that. Would be nice to have some packagers input from packager's perspective. A name based on animals seems very gimicky imho and a step towards a rather more informal approach. It may also be perceived as a me-too move in reference to MacOS and Unity. I think informal is good direction with this. We gave /a lot/ of ideas, wild ones too. This just seemed to be the best one we came up with. What particular challenge(s) is the code naming idea trying to address? These are stated in the original email. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Error(Cmake) while building PMC
Hi all , I finally got the kubuntu 13.10 ISO and installed it on VBox . It was all going fine and I was just beginning to install the required packages . I think I finished installing build-essentials , after which I locked the screen and went out for dinner and when I returned and tried to login , I was(am) unable to . Even the splash screen doesn't load after entering the password . I just get a still screen with the elarun background . I'm trying to fix this as I am desperate not to have to install it all over again(albeit it is just on a Vbox !) Has anyone else encountered this problem ? It'd be great if anyone could share a solution if any . Warm Regards. Thanking You, R.Harish Navnit The Enigma http://harishnavnit.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Error(Cmake) while building PMC
My guess is your disk might be full. How much disk space did you allocate the VM? Also, it might be helpful to take a look at the file .xsession-errors in your home dir. On Thu, Jan 16, 2014 at 9:13 PM, R.Harish Navnit harishnav...@gmail.comwrote: Hi all , I finally got the kubuntu 13.10 ISO and installed it on VBox . It was all going fine and I was just beginning to install the required packages . I think I finished installing build-essentials , after which I locked the screen and went out for dinner and when I returned and tried to login , I was(am) unable to . Even the splash screen doesn't load after entering the password . I just get a still screen with the elarun background . I'm trying to fix this as I am desperate not to have to install it all over again(albeit it is just on a Vbox !) Has anyone else encountered this problem ? It'd be great if anyone could share a solution if any . Warm Regards. Thanking You, R.Harish Navnit The Enigma http://harishnavnit.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from New OSD in Plasma 2
On Thursday, January 16, 2014 14:40:43 Martin Klapetek wrote: On Thu, Jan 16, 2014 at 2:02 PM, Bhushan Shah bhus...@gmail.com wrote: Small question, will shell define this QML files or apps? If shell, will it be possible for applications to override it? Currently shell, but since it will be installing those QML files, I guess apps/themes will be able to override it. I need to talk to someone more knowledgeable about that first, but they should definitely be themeable. Themable, yes, by means of Look and Feel package. Overridden by apps: no, for the sake of consistency. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Error(Cmake) while building PMC
On Thu, Jan 16, 2014 at 9:21 PM, R.Harish Navnit harishnav...@gmail.comwrote: R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:18 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: My guess is your disk might be full. How much disk space did you allocate the VM? Yes , that was an error initially , I'd allocated more than 50% !!! I did resize it however and now in trying to fix this , I dropped down to the root shell and I guess I really messed it up :P 50% of how much? Tell me in GB Also, it might be helpful to take a look at the file .xsession-errors in your home dir. I'm unable to reach even the grub now :) I'll check it if possible , else another fresh install again . #Screwed You must have a special power that attracts errors your way :P Thanks a lot . Regards. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Error(Cmake) while building PMC
R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:18 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: My guess is your disk might be full. How much disk space did you allocate the VM? Yes , that was an error initially , I'd allocated more than 50% !!! I did resize it however and now in trying to fix this , I dropped down to the root shell and I guess I really messed it up :P Also, it might be helpful to take a look at the file .xsession-errors in your home dir. I'm unable to reach even the grub now :) I'll check it if possible , else another fresh install again . #Screwed Thanks a lot . Regards. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Error(Cmake) while building PMC
R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:23 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: On Thu, Jan 16, 2014 at 9:21 PM, R.Harish Navnit harishnav...@gmail.comwrote: R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:18 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: My guess is your disk might be full. How much disk space did you allocate the VM? Yes , that was an error initially , I'd allocated more than 50% !!! I did resize it however and now in trying to fix this , I dropped down to the root shell and I guess I really messed it up :P 50% of how much? Tell me in GB 2 GB out of 3.46 GB . I was warned against it , but I thought that can be changed later on . Also, it might be helpful to take a look at the file .xsession-errors in your home dir. I'm unable to reach even the grub now :) I'll check it if possible , else another fresh install again . #Screwed You must have a special power that attracts errors your way :P I hope to get rid of it soon :P Thanks a lot . Regards. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ 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
Re: Error(Cmake) while building PMC
Ah, I'm not talking about RAM, I'm asking about how much virtual hard disk space you allocated to the VM. (Also, with just 4 gigs of RAM, development on a VM might be pretty frustrating for you) On Thu, Jan 16, 2014 at 9:25 PM, R.Harish Navnit harishnav...@gmail.comwrote: R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:23 PM, Shantanu Tushar Jha shaan...@gmail.comwrote: On Thu, Jan 16, 2014 at 9:21 PM, R.Harish Navnit harishnav...@gmail.comwrote: R.Harish Navnit The Enigma http://harishnavnit.wordpress.com On Thu, Jan 16, 2014 at 9:18 PM, Shantanu Tushar Jha shaan...@gmail.com wrote: My guess is your disk might be full. How much disk space did you allocate the VM? Yes , that was an error initially , I'd allocated more than 50% !!! I did resize it however and now in trying to fix this , I dropped down to the root shell and I guess I really messed it up :P 50% of how much? Tell me in GB 2 GB out of 3.46 GB . I was warned against it , but I thought that can be changed later on . Also, it might be helpful to take a look at the file .xsession-errors in your home dir. I'm unable to reach even the grub now :) I'll check it if possible , else another fresh install again . #Screwed You must have a special power that attracts errors your way :P I hope to get rid of it soon :P Thanks a lot . Regards. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ 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 -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Systemtray breakout notes
Hey, During the sprint here in Barcelona, we've talked about the rework of the notification area / systemtray and had a critical look at its concept and direction. I've extracted some notes from it, which I plan to address in the coming weeks. Here's a quick run-down: Goal of the system tray: Showing messages, hardware status and system status This includes: - Essential hardware interaction (e.g. network, battery, brightness) - Essential system interaction (notifications, running jobs) - Social / messages / email status (This means we explicitely don't see the system tray as a taskbar replacement) One question that came up: How can we remove stuff that doesn't belong here (according to above definition) elsewhere? Some ideas: - When no devices are plugged in, the device notifier should be completely hidden - No bluetooth device - no icon for bluetooth - The menu popup of statusnotifieritems should go into the systray popup - We should be able to dbus-activate plasmoids (so for example, when a bluetooth device is plugged in, the systray can load a plasmoid) - The systray can override statusnotifiers with plasmoids, allowing an improved functionality for some apps - the calendar should move into the systray popup Calendar-related changes: - Calendar events should only be shown when Akonadi is running, otherwise, the interface can be collapsed there. - the event view becomes Day's details - Adding an event should be possible directly from the calendar The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. We would like to redesign Klipper's functionality to make it more integrated. This will likely result in a reimplementation of Klipper as Plasmoid. Some applications nest in the systemtray, and appear in both taskbar and systemtray. We'd like to merge their entries. Example: Kmail's taskbar item could show the number of unread emails as an overlay, instead of having a separate icon in the systray. Overall, the direction of systemtray was met positively. This is quite a lot of work, and perhaps not achievable in one go. We'll see about this in the coming weeks, I'll work on the items in a way that prioritizes for impact and stability. Feedback, as usual, welcome. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray breakout notes
On Thu, Jan 16, 2014 at 6:01 PM, Sebastian Kügler se...@kde.org wrote: Hey, During the sprint here in Barcelona, we've talked about the rework of the notification area / systemtray and had a critical look at its concept and direction. I've extracted some notes from it, which I plan to address in the coming weeks. Here's a quick run-down: Goal of the system tray: Showing messages, hardware status and system status This includes: - Essential hardware interaction (e.g. network, battery, brightness) - Essential system interaction (notifications, running jobs) - Social / messages / email status (This means we explicitely don't see the system tray as a taskbar replacement) One question that came up: How can we remove stuff that doesn't belong here (according to above definition) elsewhere? Some ideas: - When no devices are plugged in, the device notifier should be completely hidden - No bluetooth device - no icon for bluetooth - The menu popup of statusnotifieritems should go into the systray popup - We should be able to dbus-activate plasmoids (so for example, when a bluetooth device is plugged in, the systray can load a plasmoid) - The systray can override statusnotifiers with plasmoids, allowing an improved functionality for some apps - the calendar should move into the systray popup Why? The calendar is part of the clock, that will remain the same i suppose? Following that logic, it will never be in the systray at all. Calendar-related changes: - Calendar events should only be shown when Akonadi is running, otherwise, the interface can be collapsed there. - the event view becomes Day's details - Adding an event should be possible directly from the calendar +1 to all of that. The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. Please don't use excuses as Other desktops are going a similar route.. They might, but they suck at doing it in my opinion. I'm guessing you aim at windows 8 and perhaps gnome here. Otherwise, please do share more details. We would like to redesign Klipper's functionality to make it more integrated. This will likely result in a reimplementation of Klipper as Plasmoid. Some applications nest in the systemtray, and appear in both taskbar and systemtray. We'd like to merge their entries. Example: Kmail's taskbar item could show the number of unread emails as an overlay, instead of having a separate icon in the systray. Overall, the direction of systemtray was met positively. This is quite a lot of work, and perhaps not achievable in one go. We'll see about this in the coming weeks, I'll work on the items in a way that prioritizes for impact and stability. Feedback, as usual, welcome. :) Most of it sounds good, but it's a bit difficult to picture it. Could you make some before and after mockups in conditions where this would be visible to the user? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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
Re: Systemtray breakout notes
On Thursday 16 January 2014 19:38:30 Mark Gaiser wrote: The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. Please don't use excuses as Other desktops are going a similar route.. They might, but they suck at doing it in my opinion. I'm guessing you aim at windows 8 and perhaps gnome here. Otherwise, please do share more details. We are only dropping XEmded, this doesn't mean dropping all application system trays but only the ones that don't support any modern way of doing it. Meaning that only old apps, Java, and some other old stuff will break. As for other apps using statusnotifier the idea is to merge this in the taskbar (or at least try and see what happens) and save the systemtray only for things that belong to the system, system being whatever we want it to be. BTW, the reason to drop XEmbded is that it is too complicated to integrate it right and even if we do it literally doesn't scale (since the windows have fixed size), so the result is something like this: http://www.omgubuntu.co.uk/wp-content/uploads/2013/01/search.jpg Notice the dropbox icon. So let's see if we can move systemtray forward on freedesktop, we might need to implement GNOME's in case they are not using statusnotifier (iirc gnome- shell is has support for it already). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray breakout notes
On Thursday, January 16, 2014 19:38:30 Mark Gaiser wrote: On Thu, Jan 16, 2014 at 6:01 PM, Sebastian Kügler se...@kde.org wrote: - the calendar should move into the systray popup Why? Same reason for moving all the others into the same popup: less visually jarring transitions, less different popups. The calendar is part of the clock, that will remain the same i suppose? Following that logic, it will never be in the systray at all. They're supposed to share the same popup. Let's see how this pans out. If it doesn't work well, bummer. If it does, it could be a really nice improvement. The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. Please don't use excuses as Other desktops are going a similar route.. They might, but they suck at doing it in my opinion. I'm guessing you aim at windows 8 and perhaps gnome here. Otherwise, please do share more details. Patches to implement it are welcome. :) Seriously, have you looked at the protocol? Have you looked at the implementations that would be possible? It's easy to say I want that, but that ignores the whole decision space for this. It's impossible to integrate it, there's no way that's even remotely sane to implement this on Wayland, it's impossible to do this in a way that's visually consistent, and that's just the tip of the iceberg. Feedback, as usual, welcome. :) Most of it sounds good, but it's a bit difficult to picture it. Could you make some before and after mockups in conditions where this would be visible to the user? Lacking imagination, I think you'll have to wait for this work to appear in code. I lack both time and skills to do mock-ups of all of this. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systemtray breakout notes
On Thu, Jan 16, 2014 at 8:09 PM, Sebastian Kügler se...@kde.org wrote: On Thursday, January 16, 2014 19:38:30 Mark Gaiser wrote: On Thu, Jan 16, 2014 at 6:01 PM, Sebastian Kügler se...@kde.org wrote: - the calendar should move into the systray popup Why? Same reason for moving all the others into the same popup: less visually jarring transitions, less different popups. The calendar is part of the clock, that will remain the same i suppose? Following that logic, it will never be in the systray at all. They're supposed to share the same popup. Let's see how this pans out. If it doesn't work well, bummer. If it does, it could be a really nice improvement. err.. Another thread, and another place where i completely lost you. Sebas, be a bit more _verbose_ in your answers. I don't know the deep internals of plasma or how it currently looks. From what you just said it sounds like the clock popup and notification popup are one and the same? That's not the impression i have when looking at your own screenshots: https://plus.google.com/+SebastianK%C3%BCgler/posts/DQ33L9Ejq5P There the calendar/clock popup seems to be two completely different things. So my question still stands: The calendar is part of the clock, that will remain the same i suppose? Following that logic, it will never be in the systray at all. The XEmbed systemtray mechanism will not be supported anymore, instead we will attempt to merge support for statusnotifieritems into Qt (for QSystemTray). Other desktops are going a similar route. Please don't use excuses as Other desktops are going a similar route.. They might, but they suck at doing it in my opinion. I'm guessing you aim at windows 8 and perhaps gnome here. Otherwise, please do share more details. Patches to implement it are welcome. :) Seriously, have you looked at the protocol? Have you looked at the implementations that would be possible? It's easy to say I want that, but that ignores the whole decision space for this. It's impossible to integrate it, there's no way that's even remotely sane to implement this on Wayland, it's impossible to do this in a way that's visually consistent, and that's just the tip of the iceberg. That's not at all what i tried to say. Whatever you do in the systemtray, be extremely careful with it. You will alienate the users extremely fast if it doesn't work out for them. I - personally - just don't know. I just have to see it and judge based on that i guess :) Feedback, as usual, welcome. :) Most of it sounds good, but it's a bit difficult to picture it. Could you make some before and after mockups in conditions where this would be visible to the user? Lacking imagination, I think you'll have to wait for this work to appear in code. I lack both time and skills to do mock-ups of all of this. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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
Re: Systemtray breakout notes
That's not at all what i tried to say. Whatever you do in the systemtray, be extremely careful with it. You will alienate the users extremely fast if it doesn't work out for them. I - personally - just don't know. I just have to see it and judge based on that i guess :) We can do wire frames of these ideas, slap them together, perhaps with some simplistic animations to show various ways in which the system tray can be handled visually without breaking workflow or creating a completely new set of tools for the users to learn. The thing is not to emulate others just to emulate them - but to keep a close eye at what works and what doesn't. Similarly - remaining the same just based on the idea that by never changing we never alienate any user would be equally harmful. The system tray is the one major interactive point most users have with their hardware - its where not only stability but continuity is the most relevant. By merging the system tray windows for example (having an identical window for wifi as it is for battery, with shortcut-icons that can be used to move within this unified system tray popup) that sensation of continuity can be strengthened and enhanced. (wireframes and animation are coming, just not this weekend, but they are coming and you'll see the brilliance of them then and join the dark side ;) ) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Notes from KRunner Breakout
Hey everyone These are the notes from the KRunner breakout session - * We would ideally love to use Sprinter. However the author does not want it to be a part of the Plasma workspace. This can be re-evaluated in the future. Additionally, its GPL license can be rather limiting. It prevents us from making it a framework and having proprietary runners. * Interface - We want to use the Milou [1] interface [2] as much as possible. It is already in QML, so no porting will be required. * We want to move the runner library out of plasma, so that it can be easily replaced in the future. This also makes it more attractive to other desktop environments. The KRunner code shall be moved to Milou (preserving history), and future development can continue over there. * There should be both a plasmoid and a stand-alone application available. The plasmoid can either be called Milou or some generic name. * The current krunner process also has some additional responsibilities which are unrelated to the runner part - - lock screen management - Already moved - Session Switching - Move to KSMServer - Ctrl + Esc and showing ksysguard - Should be moved to an independent process. The suggested name was kdumpster, but that was in gest. An actual name still has to be decided. The KSysGuard icon should still be added in the new UI for maintaining visual consistency. * The KRunner task-oriented UI will be dropped * Runner Library needs a certain amount of work - Add item type capabilities to the results - Add preview capabilities - Refactor so that async runners do not need to spawn an event loop and block There was a lot of debate about the internal threading in RunnerManager on if each runner really needs a separate thread or can some / all be combined or if each runner should manage threading on their own. There was no real conclusion except that there is no magical answer for everything. * Discovering and managing runners is quite hard. A new KCM should be created for that purpose. * There was a discussion on if one wants two search bars - One for searching / launcing applications and another for searching. Some people were of the opinion that two search bars might be better while some were of the opinion that it confuses the user. For now we're going with the one search bar approach. Nothing stated above is set in stone. So, comments and opinions are welcome. -- Vishesh Handa [1] https://projects.kde.org/projects/playground/base/milou [2] http://vhanda.in/milou.png ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from KRunner Breakout
One missing point, it will be possible to change the interface of Milou, so if somebody wants to write a task oriented GUI (old katapoult was mentioned) it will a matter of throwing some QMl files :p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notes from KRunner Breakout
On 16/01/14 20:15, Vishesh Handa wrote: * Discovering and managing runners is quite hard. A new KCM should be created for that purpose. I would also add that runner help is quite hard to navigate at the moment; some thought probably needs to go into how that should work (it would be nice if it was searchable, for example). It's possible Milou already has this figured out; I haven't actually tried it out. Alex ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
