Arrival in BCN
Hi all, on sprints.kde.org I see that lots of people arrive on Friday. As I don't speak the language and are totally lost in foreign places [1] it would be awesome if we meet at the airport and find the way into the city together. So for the reference I will arrive with LH1126 from Frankfurt at 12:05. Cheers Martin [1] not really, but it helps my point 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: kscreenlock_greet insecure with multiple X screens
On Thursday 02 January 2014 17:50:42 Harald Sitter wrote: > alohas, > > it would be really great if someone could have a look at the patch for > [1], seems like a rather ugly bug and the patch looks straight > forward. I just looked at the bug and I have the feeling that the patch is wrong, but I cannot verify as I don't have multiple X screens. It clearly is potentially crashy as it uses the iterator over the views is a valid index of the screens by QDesktopWidget. The real question is: why is the user using multiple X screens (out of experience: in 101 of 100 cases it's not what the user wants ;-) 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: Students to work on Plasma
On Friday 27 December 2013 19:47:36 Artur Souza wrote: > Hello my friends! > > You probably have seen my post on planet.kde > (http://blog.morpheuz.cc/26/12/2013/open-academy-and-kde/) about > OpenAcademy and the possibility of sponsoring students to work on KDE. > > I would love to have some students working on Plasma, but for that we > need mentors. Anyone willing to take the challenge? :) I don't think we will have problems finding mentors, I think the problem is finding topics ;-) Currently it's difficult as we are in the middle of porting and I assume that tasks like "port n plasmoids" is unsuited for OpenAcademy. The only ideas I have for projects goes in the direction of unit testing. We are lacking here in Plasma and need to think about it. In that area I would be willing to mentor and have already experience in mentoring (mentored a BSc for unit testing KWin which is still unmerged). 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: Framework licenses
On Monday 23 December 2013 19:45:36 Alex Merry wrote: > On 23/12/13 18:46, Aurélien Gâteau wrote: > > - plasma-framework: this framework uses multiple licenses, but majority is > > LGPL (this is the case for many other frameworks). Should we use a LGPL > > 2.1 > > COPYING.LIB file? > > A quick attack with git grep shows the majority of code to be LGPL 2 > (+), with the odd LGPL 2.1 (+) file, in the libraries, along with some > GPL2 code (in the examples etc). As such, I committed an LGPL 2.1 > COPYING.LIB file (since that should work for all the LGPL files) and a > GPL2 COPYING file. Is my assumption correct that the examples are from the former kde-examples repository. If yes the number of authors should be rather small. Could we try to relicense them? 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
bug mails on the mailinglist
Hi, could we please get the bug mails away from the list? Those who are interested can either look at the bug tracker or just follow the bug user. Having bug mails sent to the list is a bad idea. Been there, done that, don't want to go there again :-D 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: Monday meeting
I love to soliloquize, so I will do the hangout nevertheless :-D 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: No co-installability of plasma 1 and 2
On Tuesday 26 November 2013 12:23:18 Maximiliano Curia wrote: > In article <25673324.XNmJUoyzAe@martin-desktop> you wrote: > > in todays hangout Alex asked whether kwin binary is going to be renamed to > > kwin5 to make it possible to co-install plasma 1 and plasma 2. > > > > My opinion of that is, that we don't need to have things co-installable. > > After all kde-workspace doesn't provide libraries where it is useful to > > have them co-installable. It's applications. > > What do you mean kde-workspace doesn't provide useful libraries? There are a > number of third party applications that depend on them. according to Debian package information we have the following libraries which non-kde-workspace packages depend on: * libkdecoration: useless as it requires KWin (Compiz case is no longer supported since 4.11) * libkephal: got deleted yesterday * libkscreensaver5: either already deleted or should be deleted * libksignalplotter4: no idea what it is, if useful should go into a framework * libkworkspace4abi2: no idea why external packages use it. The frameworks 5 version doesn't look like it has anything of interest for external applications - Debian name indicates that it's a bad idea to use it * libprocessui4a: probably should go into a framework. It's strange that kdevelop depends on kde-workspace, isn't it ;-) * libtaskmanager4abi3: the name of the library as adjusted by Debian should indicate why it's a bad idea to use it outside kde-workspace. Only used inside task applets, that should become a non-issue in Plasma 2 * libweather-ion6: same as taskmanager There are a few more libraries, but all of them are either clearly "plasma" (libplasmaclock) or only used inside kde-workspace module > > Anybody who disagrees? Your arguments please :-) > > I think that this should be discussed in the packagers list, which will help > to sync our points of views among different distributions. I can take it there, but only if packagers are willing to do the work ;-) I took it here to discuss whether we as the developers think that it is worth the effort to provide plasma 1 and 2 at the same time. I think we have agreement that co-installable plasma versions is not considered a valid use- case by the developers. If distros think different, then we need help there. That said: I would prefer that if at all the plasma 1 version gets adjusted. I don't want to type the rest of my life kwin5 and would prefer to still have it as kwin. So if co-installable the existing version should be called kwin4. Same for all the libraries. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE_PLATFORM_PROFILE in kde-workspace
On Sunday 24 November 2013 18:12:48 David Faure wrote: > kde-workspace still uses this cmake variable, set by kdelibs, > but KF5 itself doesn't use it at all. > > What's the plan about this in kde-workspace? > It's currently used to disable the compilation of a large number of > applications (kdm, systemsettings, klipper, krunner, etc.) > > I can just move the bit of cmake logic from kdelibs to kde-workspace, but if > you have bigger plans, please let me know. > > plasma itself doesn't use this cmake var (anymore). my opinion is to remove the logic as I think we just want to have everything available to make a good runtime switching experience between the various shells. 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: minutes Monday Plasma hangout
On Tuesday 05 November 2013 20:11:47 David Edmundson wrote: > - I'm not too convinced by the notion that this needs to be changed > /now/. I was under the impression we were going for a 'port first, > then when it works look at new things' policy; rather than try to do > lots of things at once and end up with many broken 'in development' > things. It kind of makes sense to not just port completely KSplash as there is also the XEvent filter which needs to be rewritten. It's painful work and just to throw it away would be sad. So if we think about moving it somewhere else it makes sense to do it properly. 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: Semi-modal sidebar paradigm
On Monday 04 November 2013 20:29:26 Aaron J. Seigo wrote: > On Monday, November 4, 2013 20:25:44 Marco Martin wrote: > > > Pushing the desktop to the side is definitely nice but due to the lack > > > of > > > input redirection in an X world, we cannot move all the window over a > > > bit, > > > too.(?) > > > > yeah, that's my concern as well, i would love to have it, but since is > > "semi" modal on X we would lose input for all windows, therefore becoming > > fully modal again. > > unless they are actually moved instead of just translated (don't know how > > smoothly could be done in kwin and most important how much hackish) > > i should have wrapped that whole suggestion in tags. it > is certainly not possible to do in a nice fashion on X11. we could fake it > to some extent, but it would never be perfect. we can experiment with the window switcher. KWin grabs input anyway in that case so a simple visual translate in a KWin effect could work. 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: PW2 - can't get it to work
On Wednesday 23 October 2013 15:30:47 Martin Klapetek wrote: > Update: I know what's wrong. And I fixed it. > > It was a simple forgotten string, which tried to load "org.kde.desktop" > containment as default while the default containment is actually > "org.kde.desktopcontainment". > > As to why it was working for everyone else - either stale files around or > your config files are to "blame" as that value is first read from config > file, only if it reads nothing, it reverts to the default string, which was > wrong. wohoo - thanks for tracking that down! And we should all put something in our workflows: when doing a clean rebuild also delete the config files. 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: Removing kcontrol/screensaver
On Friday 18 October 2013 17:37:10 Aaron J. Seigo wrote: > On Friday, October 18, 2013 13:03:19 Martin Graesslin wrote: > > I just had a look at it whether there is anything which could be reused > > once we have a new locker without XScreenSaver support. > > we already have a locker which can have the XScreenSaver support dropped in > about 10 minutes of removing code. so that isn’t a “when” but should be a > "now" As it looks like monday will be a git rm day for me, I can include that (and will happily do so). > > > After all there are the > > grace timeout settings. But after looking at it, I think it's a better > > idea > > to just delete the module. > > er... and what will you replace the grace timeout settings with? > > or ... does nobody know what they are for? > > and yes, you will bring fire down on your head by removing those settings. looks like bad wording on my side. What I meant is "it's easier to just implement a new module with those settings than trying to strip out all the other code from the module which is no longer needed". Sorry for the confusion. 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: Can we drop kcontrol/workspaceoptions?
On Friday 18 October 2013 14:29:23 Marco Martin wrote: > On Thursday 17 October 2013 19:51:24 Martin Graesslin wrote: > > Hi all, > > > > and another KCM, but for this one I'm not sure whether it still has > > something useful: kcontrol/workspaceoptions > > > > It offers the following features: > > * switch between workspace type "Desktop" and "Netbook" > > will be partially automatic, but as ivan notes will need the possibility to > be overridable by the user could go together with the new grand masterplan theming kcm. > > * checkbox for "show informational tips" (whatever that is) > > is a global switch to enable and disable tooltips: also partially managed > automatically by the shell switching, but needs to be configurable by the > user somewhere does it? Is it really a valid usecase to disable tooltips? That would be an interesting thing to see how many users changed that option at all... 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
Removing kcontrol/screensaver
Hi all, kcontrol janitor has found another module to remove: screensaver. I just had a look at it whether there is anything which could be reused once we have a new locker without XScreenSaver support. After all there are the grace timeout settings. But after looking at it, I think it's a better idea to just delete the module. So if nobody objects, I go to delete also this on Monday. And with that all modules which are not going to be deleted on Monday are ported \o/ 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
Can we drop kcontrol/workspaceoptions?
Hi all, and another KCM, but for this one I'm not sure whether it still has something useful: kcontrol/workspaceoptions It offers the following features: * switch between workspace type "Desktop" and "Netbook" * configure dashboard to "show Desktop widgets" or "Show an independent widget set" * checkbox for "show informational tips" (whatever that is) The first one should be obsoleted by the new dynamic shell switcher. The second one is a questionable feature where I think some devs would like to see it go away and the last one I don't know what it is about. As I'm unsure I ask for confirmation (hello Marco, Aaron or Sebas!) before git rming that kcm. 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
Removing kcontrol/smartcard
Hi all, the KCM for smartcards in kcontrol/smartcard got never ported to KDE4. I think after five years and 12 releases of coma it's time to perform active euthanasia as I consider it as unlikely that someone will come and revive by porting from kdelibs3 to frameworks 5 directly. So same game as yesterday: if nobody yells no till Monday I'm going to git rm that module. Whoever speaks up volunteers to port the module. 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
Removing kcontrol/randr
Hi all, I hope we all agree that for Plasma2 kscreen is our solution for multiple monitors. Because of that I intend to delete the old configuration module and kded found in kcontrol/randr from our master branch. I will do so by Monday if nobody objects. If someone objects he/she is invited to port it to KF5 :-) 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: kill the systray?
On Tuesday 24 September 2013 20:48:23 Kevin Krammer wrote: > On Tuesday, 2013-09-24, Sebastian Kügler wrote: > > * Qt5 doesn't seem to have the API we need to do our xembed tricks > > anymore, > > > > especially QX11EmbedContainer is gone. If we even get it to work under > > > > X11, it seems entirely futile to expect this to be feasible in a Wayland > > world. > > I think QWindow::fromWinId(), added in Qt5.1, is the respective replacement. > The XCB QPA plugin, for example, supports that (the capabiliy is called > ForeignWindows). I just wanted to reply that it's for something else (thought it only reparents to the window without implementing the protocol), then started to read the code and yes it looks like xembed is supported by the xcb implementation of QWindow. QWindow *foreign = QWindow::fromWinId(idOfForeignWindow); foreign->setParent(idOfOurQQuickWindow); should do the trick. 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: kill the systray?
On Tuesday 24 September 2013 18:04:55 Aaron J. Seigo wrote: > > * Qt5 doesn't seem to have the API we need to do our xembed tricks > > anymore, > > > > especially QX11EmbedContainer is gone. > > it’s missing more than gone; i’ve heard several times that someone or > another was working on it. which wouldn't be in time for Qt 5.2 anymore. So earliest is Qt 5.3 which might be too late for our needs. > > > If we even get it to work under > > > > X11, it seems entirely futile to expect this to be feasible in a Wayland > > world. > > agreed ... well for supporting legacy applications it would be needed in the same way as for supporting GTK+ application on X11. > > When I asked Martin if he knew a way to do the xembed, he replied (being > > Martin ;)) asking if we can just kill it and quoted starwars. I wonder: > > Can > > we kill it yet? > > if Gtk+ supported status notifiers natively, then i’d say “yes”. it doesn’t, > so anyone who uses a Gtk+ application with a system tray icon will suddenly > not be able to access it. i’m pretty sure that’s going to cause problems. what's the status of the Ubuntu implementation? Is it that an app has to explicitly link against it? > > as the GNOME devs are currently porting to Wayland as well, now would be a > good time to find out what they plan to do with their xembed system tray. I just tried to find some information on how they are using it and somehow I'm not sure whether the xembed systray is available at all in GNOME... > > oh, and the tasks widget ought to gain support for application based status > notifiers (so that the system tray can opt out of them) as well as > skiplists. what i’d really like to see is this become a part of the wayland > specific support that we can build around the “every window has an > associated .desktop file” thing. Martin? sounds good to me. 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: 4.11 is out .. kde-workspace to qt5?
On Monday 16 September 2013 16:35:58 Sebastian Kügler wrote: > > * the CMakeLists.txt needs to output a usefully verbose error message when > > it only finds kdelibs 4.x and not kf5. > > > > * we need to test with the latest version of kdesrc-build and make it do > > the right thing by choosing the 4.11 branch by default > > Those two tasks are on my list for this week. what's the state on this? I cannot find an update to CMakeLists.txt which would print out a warning ;-) > > > Switch tasks: > > > > * merge the frameworks branch into master > > Martin volunteered to do this, planned for next Monday. blocked by pre-switch task 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: 4.11 is out .. kde-workspace to qt5?
On Monday 23 September 2013 19:58:08 Martin Graesslin wrote: > > > Switch tasks: > > > > > > * merge the frameworks branch into master > > > > Martin volunteered to do this, planned for next Monday. > > blocked by pre-switch task I just tried to merge master into frameworks-scratch but gave up due to changes in taskmanager where I have no idea how to do the merges. @Eike: can we try to do that together, tomorrow? Cheers Martin P.S.: this is a clear sign to me that we should split the kde-workspace repo. It would make the merging way easier. 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: Activities API
On Thursday 12 September 2013 15:51:55 Aaron J. Seigo wrote: > On Thursday, September 12, 2013 15:26:50 Marco Martin wrote: > > in general to c++ it's maybe slightly clunkier, since one has to call > > model-> > > >data(role) and then try to convert the qvariant. > > > > (perhaps it may have some api to ease fetch data from c++) > > > > on QML... would be awesome :D > > i’d be lazy (the programmer’s mantra? ;) and not bother with any such API > until it is shown to be necessary. i would not be surprised if every user of > KActivities::Info ends up being some QML code somewhere. do you want to be proofed wrong? ;-) kwin/useractions.cpp line 691 following (frameworks-scratch branch) 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: macro_add_compile_flags under kf5
On Wednesday 28 August 2013 16:35:39 Heena Mahour wrote: > Hi , > I am getting Unknown CMake command "macro_add_compile_flags". in kioclient > cmake under kf5 . > I found out that it is not to be used under kf5 as > macro_optional_find_package is replaced to find_package in a recent commit > Could you suggest how could I fix it ? Have a look at http://techbase.kde.org/Development/ECM_SourceIncompatChanges which explains what to do for the changes. 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: kcmodule under kf5
On Tuesday 27 August 2013 19:56:16 Heena Mahour wrote: > but that is also giving following errors : > http://pastebin.com/raw.php?i=C5qePwbt this looks like some includes are missing. KDE_VERSION_STRING is deprecated AFAIK but still available (used in KWin). Just add: #include KAboutData is more difficult. As I guess that's code you are porting you have to rename it to K4AboutData to get it compile again and include the appropriate header. 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: naming the next major release
On Wednesday 21 August 2013 20:38:05 Martin Graesslin wrote: > On Monday 19 August 2013 21:56:35 Aaron J. Seigo wrote: > > Other proposals, ideas, tweaks to the above most welcome, but let’s try to > > come to a consensus on this matter before the end of this month. > > another idea: let's drop the version number completely and only use it > internally (bugtracker, libs, etc.). and yet another idea: code names instead of release numbers. And as we have such nice codenames all over our code base (hello Corona) I would suggest code names out of the field of Physics/Science e.g. * Plasma Higgs-Boson Cheers Martin P.S. and that would give us a wonderful opportunity to bike-shed about a name each other month ;-) 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: naming the next major release
On Thursday 22 August 2013 20:36:24 Giorgos Tsiapaliokas wrote: > Hello, > > On 21 August 2013 12:49, Marco Martin wrote: > > My vote would go for Plasma. > > +1, just "Plasma" without "KDE". > > On 21 August 2013 21:38, Martin Graesslin wrote: > > another idea: let's drop the version number completely and only use it > > internally (bugtracker, libs, etc.) > > I was thinking this too. But when a new version comes out how could we > promote it? Quoting our release announcement for 4.11: "KDE is delighted to announce its latest set of releases, providing major updates to KDE Plasma Workspaces, KDE Applications, and the KDE Platform." > Also if a product doesn't have a version then this could mean that it is > rolling. > Yes not always but this is the first thought that goes through the mind. No? And a rolling release might have version numbers. I'm using a rolling distro and it has version numbers, but I never know which one it is. So that argument works in both direction. I think there is no real sign that rolling releases do not have a version number. 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: Smart d-ptr in Plasma
On Thursday 22 August 2013 14:23:57 Kevin Ottens wrote: > On Thursday 22 August 2013 13:39:39 Ivan Čukić wrote: > > > Well, I can add one more. They use variadic templates which are not in > > > the > > > list of C++11 features which can be used unconditionally in > > > plasma-framework. Can be spared if you loose the forwarded constructor > > > arguments though. > > > > The older MSVC (which I guess is the problem for including variadics) > > supports IIRC up to n (where n is as low as around 12 arguments). This > > needs to be tested though by someone who has that compiler. > > > > Anyhow, the private class constructors rarely have more than one argument. > > So, we could support most use-cases by providing fwd constructors for up > > to, for example, 5 args. > > Yep, let's do that as fallback if Q_COMPILER_VARIADIC_TEMPLATES is not > defined. > > BTW, during lunch I thought about sebas comment, and maybe he got a point... > That looks useful, so what about putting it in KCoreAddons? It wouldn't > cost an extra dependency for plasma-framework which already uses it, and > it'd give it more exposure. Of course means other tier 1 frameworks > wouldn't use it, but that gives it more chance than plasma-framework > already. Maybe it would even be an idea for an own (tier 0) framework which could contain useful C++11 magic? I guess we will soon have more useful C++11 stuff which might make sense to be used in more places. > > If you're interested please bring it up on k-f-d and we'll see where it > goes. yes, please :-) 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: naming the next major release
On Wednesday 21 August 2013 19:36:21 Daniel Nicoletti wrote: > 2013/8/21 Sebastian Kügler : > > On Wednesday, August 21, 2013 17:12:10 Daniel Nicoletti wrote: > >> 2013/8/21 Martin Graesslin : > >> > Yes I noticed that for example you still talk about KDE as software in > >> > your > >> > blog posts. To be honest I have to cringe if I read it, because it > >> > makes > >> > the task of everyone more difficult who tries to work on the > >> > repositioning of the brand. > >> > >> Well if I write an app using Qt people call it a Qt app, when you use KDE > >> FW it becomes a KDE app. So what should I call the software I write when > >> using KDE FW? > > > > Just to chime in here, this is clearly wrong. A KDE App (or project, if > > you > > will) is not defined by its technical dependencies, but by the people who > > write it, see manifesto.kde.org. > > Ok, then what am I doing wrong in calling my stuff KDE stuff? > http://manifesto.kde.org/benefits.html lists what I do on my > projects, I was arguing about Martin saying that I talk KDE as software > but KDE projects are mostly software no? This is too controversial, > I know the idea is the we KDE are a community, but it's a community > that have projects and software hence why am wrong in saying > KDE software? It's software made by KDE people. Look for example at your rant about switches. It's always saying "KDE 4.11", which is just wrong. That's what I meant. Just by scrolling down your blog I see two posts with "KDE 4.11" in the title. This is working against the rebranding. How are we supposed to have the media get it right, if even the developers continue to use the old wording. 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: naming the next major release
On Wednesday 21 August 2013 15:58:03 Daniel Nicoletti wrote: > 2013/8/21 Martin Graesslin : > > On Wednesday 21 August 2013 13:52:06 Daniel Nicoletti wrote: > >> 2013/8/21 Martin Graesslin : > >> > On Wednesday 21 August 2013 11:29:52 Daniel Nicoletti wrote: > >> > this might change. Consider Razor/LXDE joining the KDE umbrella. What > >> > then? > >> > From one day to another it would be obvious that using "the KDE > >> > desktop" > >> > is > >> > not working any more. > >> > >> In that case what we will end up is with just KDE libraries? I mean > >> people are used to "install/use KDE" which means the SC. > > > > no?!? I fail to see what you want to tell us, I cannot follow your > > thought. I guess it's based on you still think that KDE is not the > > community but all the software we tend to release once half a year. > > Sorry if it's hard to understand, so I'll try to put it into another way: > * First I just wanted to say that I prefer Plasma 2 instead of 5, because it > helps understanding the age and we have lots of other KDE components with > different versions than 5. > > * Second I'm saying that KDE is also the software because we do release a >KDE Software Compilation which has the KDE name. ok, that I did not get at all :-) I personally also don't like 5 for the .0 reason. > > * I know we don't market the KDE desktop anymore, all the blog posts >around KDE still talk about it as a DE. Lots of friends that use KDE SC >don't even know what is plasma-desktop because for them it's KDE. Yes I noticed that for example you still talk about KDE as software in your blog posts. To be honest I have to cringe if I read it, because it makes the task of everyone more difficult who tries to work on the repositioning of the brand. It is important. If people from the outside think it's one coherent thing we wouldn't need efforts like frameworks to make it more attractive for 3rd party developers and it also makes any attempts to get KWin as the window manager for all Qt based shells much more difficult. Which is a reason why I do care about it. > > For example what happens if I want my own shell (no I didn't write one :P ) > on the KDE SC? > > The KDE community has to decide which will be the included, since plasma > got there first there isn't much chance for a replacement, then better > do like Razor. does the KDE community have to decide? Did the community ever decide that there can only be one file manager in the SC? Also does software have to be in the SC? Or is software more blessed by being in the SC? Large part of the release announcement for 4.11 is about KScreen - to my knowledge it's not even released as part of the SC. What do you think is the more prominent music player by KDE? Amarok which is not part of the SC or juk which is part of the SC? Same for IM - kopete vs kpt. > > I'm not against the KDE renaming, but I think we are getting > to a point that having an Software Compilation becomes a > problem. If Razor is now a KDE project they why only plasma > is included? Who said there will be a software compilation in the KF 5 world or that the Plasma Workspaces will be part of such a maybe existing software compilation? Please note that this has not yet been discussed, but I know that a few people in the Plasma team (me included) would favor to not have the SC anymore. The reasons you mention are a part of it. In fact the whole discussion highlights it. We would not need to think about a version number if Plasma would be part of the software compilation. 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: naming the next major release
On Monday 19 August 2013 21:56:35 Aaron J. Seigo wrote: > Other proposals, ideas, tweaks to the above most welcome, but let’s try to > come to a consensus on this matter before the end of this month. another idea: let's drop the version number completely and only use it internally (bugtracker, libs, etc.). Got that idea while reading a news that Cryengine 3 got renamed to Cryengine 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: naming the next major release
On Wednesday 21 August 2013 13:52:06 Daniel Nicoletti wrote: > 2013/8/21 Martin Graesslin : > > On Wednesday 21 August 2013 11:29:52 Daniel Nicoletti wrote: > >> My 2c, > >> > >> On KDE 4 aka KDE SC 4, plasma was always just plasma, > >> no user says I'm using the plasma shell (as there isn't another > >> KDE option). > > > > this might change. Consider Razor/LXDE joining the KDE umbrella. What > > then? > > From one day to another it would be obvious that using "the KDE desktop" > > is > > not working any more. > > In that case what we will end up is with just KDE libraries? I mean > people are used to "install/use KDE" which means the SC. no?!? I fail to see what you want to tell us, I cannot follow your thought. I guess it's based on you still think that KDE is not the community but all the software we tend to release once half a year. > > If we are going to drop the "KDE desktop" then imho it should > be better to put some marketing on the "Plasma desktop" > which uses KDE technology. We haven't marketed a "KDE desktop" for years now. > > The same imho happens to Razor/LXDE, they will keep being > Razor/LXDE maybe using KDE pieces. At some point KDE > might vanish completely as the more things from the > frameworks are upstreamed (not that this is bad!). Why should KDE vanish if Razor uses frameworks? I fail to follow your reasoning. > > This of course end up being completely ok with the new > KDE = comunity branding which to me is a shame that > the shell looses it's identity. I somehow imagine in the > future people talking about plasma people or lxde people > and the KDE name being left only for frameworks. Why should they only talk about Plasma? > > Of course I'm just supposing. > > > I'm in fact aware of at least three desktop shells by the KDE community. > > The only thing those three share is the window manager. > > But at some level "the" KDE shell is plasma, and if these others want > to be known > the have to do the promoting themselves. Just for the record: one of the three desktop shells I meant is Plasma :-) As far as I know the other shells don't want to be promoted, but they would get obviously the same level of promotion. The dot is open to every KDE project. > > > Given that we know that we want to open us for more projects and that we > > want to get our technologies into other Qt based desktops, it would be a > > really bad idea to ignore this fact when we do the planning for the next > > version. > No, I'm not saying to ignore this fact. It's just that imho > the idea of pushing Plasma to version 5 is bad for the > reasons I mentioned. If plasma will keep being included > into KDE SC the SC version is what users see. I really have problems understanding your arguments. They seem to be centered around "I don't like the renaming of KDE, thus I do not like this". I think the renaming was a good step and reflects much better what we as a community do. I can only recommend to open up on it and see the positive aspects of it. > > An example is that when someone fill a bug against > say print-manager I care which KDE version they have > and not if p-m is at version 0.3, because I know which > version was included in that SC. then you should fix this. In KWin we include also information about kdelibs version (compilation, runtime) and Qt. It helps a lot. Personal remark: I sometimes have problems following your arguments and recently I had the feeling that you jump to wrong conclusions based on incorrect and incomplete data. I think this is also here the case. You jump directly to the conclusion but seem to miss the reasons and the good advantages of the renaming of KDE. Just look at the manifesto - without the renaming that would not have happened. As you have not been at Akademy I recommend to watch the recordings of Kevin's keynote. 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: naming the next major release
On Wednesday 21 August 2013 11:29:52 Daniel Nicoletti wrote: > My 2c, > > On KDE 4 aka KDE SC 4, plasma was always just plasma, > no user says I'm using the plasma shell (as there isn't another > KDE option). this might change. Consider Razor/LXDE joining the KDE umbrella. What then? >From one day to another it would be obvious that using "the KDE desktop" is not working any more. I'm in fact aware of at least three desktop shells by the KDE community. The only thing those three share is the window manager. Given that we know that we want to open us for more projects and that we want to get our technologies into other Qt based desktops, it would be a really bad idea to ignore this fact when we do the planning for the next version. > some components happen to have survived since > KDE 1 (kwin/konqueror maybe?), Just for the record: both KWin and Konqueror got introduced in KDE (SC) 2. The oldest to my knowledge still being developed application is KMail. 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: naming the next major release
On Tuesday 20 August 2013 09:56:59 Aaron J. Seigo wrote: > one tempting idea is to promote “Plasma Active” up as the name used for all > the workspaces ... I would vote against "Plasma Active" as that might end up at the users (and media and they can get it wrong big times) as we drop the desktop system in favor of the tablet thingy. For many users Active is just the tablet shell. I fear that this could end up being seen in exactly the opposite way as we want to achieve with the one device shell approach. If you want to get it wrong, you'll get it wrong and lately I have the feeling that the media is getting it wrong on purpose just to have more clicks. > > the most minimalist thing would be to just call it all “Plasma” and be done > with it and not try at all to differentiate the new release from the old by > the product name. > > another approach would be to shift weight to “Active” and drop “Plasma” from > the name, though “KDE Active” is not as google-able and we lose whatever > value we’ve put into Plasma as a brand. I agree that we should somehow keep Plasma in it. > > *sigh* this needs more thought :/ > > > I do want to promote KWin for the usage in LXDE/Razor as in the next > > version we will hardly have any build-time dependencies from frameworks > > higher than tier1. I'm concerned that a generic name "Plasma" would work > > against that as it would be difficult to communicate that although being > > part of Plasma not being part of Plasma. > > i suppose it comes down to the following two things: > > * do we feel we can communicate clearly, developer to developer, what Plasma > is, and how components like KWin fit within that > * do we expect LXDE / Razor developers to be intelligent people who will > understand technical communication > > my experience with both of those things is “yes” I'm also not concerned with devs. I'm quite sure that this will be not of an issue. I'm more concerned about the users as they will have to choose OpenBox or KWin. If they think that with KWin they get the full "bloat" of Plasma on a lightweight desktop they will not use it out of principle. We already see that LXDE has to fight against the bloat perspective since they started using Qt - which is a pity. 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: Can not find XCB modules.
On Tuesday 20 August 2013 12:23:50 Bhushan Shah wrote: > On Tue, Aug 20, 2013 at 12:23 PM, Martin Graesslin wrote: > > wait, did you apply the patch from the review request I posted yesterday? > > Because that requires adjustments in kde-workspace, too. > > Yes! I have applied patch to ECM. try to remove it again. Sorry I should have mentioned that this needs adjustments to where it is used. 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: Can not find XCB modules.
On Tuesday 20 August 2013 12:14:28 Bhushan Shah wrote: > Hello, > > Here is relevant cmake --trace log, if that helps.. > http://paste.kde.org/p48e12dc6/ wait, did you apply the patch from the review request I posted yesterday? Because that requires adjustments in kde-workspace, too. > > Thanks > > On Tue, Aug 20, 2013 at 11:52 AM, Martin Graesslin wrote: > > On Tuesday 20 August 2013 11:36:58 Bhushan Shah wrote: > >> Hello, > >> > >> Even I have tried with complete re installation of KUbuntu and fresh > >> clone of the kde-workspace, but something is still wrong. Here is what > >> I do to compile. > > > > it looks fine. I'm out of ideas. Maybe talk to the neon devs on IRC > > (#kubuntu- devel). The neon setup is able to compile it, so it just needs > > to be possible. > > > > Cheers > > Martin > > > >> $ cd ~/kde-workspace > >> $ git checkout frameworks-scratch > >> $ mkdir build && cd build > >> $ neon5-env > >> $ neon5-cmake .. > >> > >> and also > >> > >> cmake .. > >> > >> Thanks! > >> > >> On Tue, Aug 20, 2013 at 11:33 AM, Bhushan Shah > > > > wrote: > >> > Hello, > >> > > >> > Now that's double annoying to me, I have more packages installed then > >> > you, > >> > still > >> > > >> > bshah@kubuntu:~$ aptitude search xcb | grep dev > >> > i libx11-xcb-dev - Xlib/XCB interface library > >> > (development he i libxcb-composite0-dev - X C Binding, > >> > composite extension, developm i libxcb-damage0-dev - X C > >> > Binding, damage extension, development i libxcb-doc > >> > > >> > - X C Binding, development documentation i libxcb-dpms0-dev > >> > > >> > - X C Binding, dpms extension, development f i libxcb-dri2-0-dev > >> > > >> >- X C Binding, dri2 extension, development f i > >> > > >> > libxcb-ewmh-dev - utility libraries for X C Binding -- > >> > ewmh, i libxcb-glx0-dev - X C Binding, glx extension, > >> > development fi i libxcb-icccm4-dev - utility libraries > >> > for X C Binding -- icccm i libxcb-image0-dev - utility > >> > libraries for X C Binding -- image i libxcb-keysyms1-dev > >> > - > >> > utility libraries for X C Binding -- keysy i libxcb-randr0-dev > >> > > >> > - X C Binding, randr extension, development i libxcb-record0-dev > >> > > >> >- X C Binding, record extension, development i > >> > > >> > libxcb-render-util0-dev - utility libraries for X C Binding -- > >> > rende i libxcb-render0-dev - X C Binding, render > >> > extension, development i libxcb-res0-dev - X C > >> > Binding, > >> > res extension, development fi i libxcb-screensaver0-dev - X C > >> > Binding, screensaver extension, develo i libxcb-shape0-dev > >> > > >> > - X C Binding, shape extension, development i libxcb-shm0-dev > >> > > >> >- X C Binding, shm extension, development fi i > >> >libxcb-sync0-dev > >> > > >> > - X C Binding, sync extension, development f i > >> > > >> > libxcb-util0-dev- utility libraries for X C Binding -- > >> > atom, i libxcb-xevie0-dev - X C Binding, xevie > >> > extension, > >> > development i libxcb-xf86dri0-dev - X C Binding, xf86dri > >> > extension, developmen i libxcb-xfixes0-dev - X C > >> > Binding, > >> > xfixes extension, development i libxcb-xinerama0-dev- X C > >> > Binding, xinerama extension, developme i libxcb-xprint0-dev > >> > > >> > - X C Binding, xprint extension, development i libxcb-xtest0-dev > >> > > >> > - X C Binding, xtest extension, development i libxcb-xv0-dev > >> > > >> > - X C Binding, xv extension, development fil i > >> > > >> > libxcb-xvmc0-dev- X C Binding, xvmc extension, > >> > development f i libxcb1-dev - X C
Re: Can not find XCB modules.
On Tuesday 20 August 2013 11:36:58 Bhushan Shah wrote: > Hello, > > Even I have tried with complete re installation of KUbuntu and fresh > clone of the kde-workspace, but something is still wrong. Here is what > I do to compile. it looks fine. I'm out of ideas. Maybe talk to the neon devs on IRC (#kubuntu- devel). The neon setup is able to compile it, so it just needs to be possible. Cheers Martin > > $ cd ~/kde-workspace > $ git checkout frameworks-scratch > $ mkdir build && cd build > $ neon5-env > $ neon5-cmake .. > > and also > > cmake .. > > Thanks! > > On Tue, Aug 20, 2013 at 11:33 AM, Bhushan Shah wrote: > > Hello, > > > > Now that's double annoying to me, I have more packages installed then you, > > still > > > > bshah@kubuntu:~$ aptitude search xcb | grep dev > > i libx11-xcb-dev - Xlib/XCB interface library > > (development he i libxcb-composite0-dev - X C Binding, > > composite extension, developm i libxcb-damage0-dev - X C > > Binding, damage extension, development i libxcb-doc > > - X C Binding, development documentation i libxcb-dpms0-dev > > - X C Binding, dpms extension, development f i libxcb-dri2-0-dev > >- X C Binding, dri2 extension, development f i > > libxcb-ewmh-dev - utility libraries for X C Binding -- > > ewmh, i libxcb-glx0-dev - X C Binding, glx extension, > > development fi i libxcb-icccm4-dev - utility libraries > > for X C Binding -- icccm i libxcb-image0-dev - utility > > libraries for X C Binding -- image i libxcb-keysyms1-dev - > > utility libraries for X C Binding -- keysy i libxcb-randr0-dev > > - X C Binding, randr extension, development i libxcb-record0-dev > >- X C Binding, record extension, development i > > libxcb-render-util0-dev - utility libraries for X C Binding -- > > rende i libxcb-render0-dev - X C Binding, render > > extension, development i libxcb-res0-dev - X C Binding, > > res extension, development fi i libxcb-screensaver0-dev - X C > > Binding, screensaver extension, develo i libxcb-shape0-dev > > - X C Binding, shape extension, development i libxcb-shm0-dev > >- X C Binding, shm extension, development fi i libxcb-sync0-dev > > - X C Binding, sync extension, development f i > > libxcb-util0-dev- utility libraries for X C Binding -- > > atom, i libxcb-xevie0-dev - X C Binding, xevie extension, > > development i libxcb-xf86dri0-dev - X C Binding, xf86dri > > extension, developmen i libxcb-xfixes0-dev - X C Binding, > > xfixes extension, development i libxcb-xinerama0-dev- X C > > Binding, xinerama extension, developme i libxcb-xprint0-dev > > - X C Binding, xprint extension, development i libxcb-xtest0-dev > > - X C Binding, xtest extension, development i libxcb-xv0-dev > > - X C Binding, xv extension, development fil i > > libxcb-xvmc0-dev - X C Binding, xvmc extension, > > development f i libxcb1-dev - X C Binding, > > development files > > > > Thanks. > > > > On Tue, Aug 20, 2013 at 10:39 AM, Martin Graesslin wrote: > >> On Tuesday 20 August 2013 10:21:21 Bhushan Shah wrote: > >>> On Tue, Aug 20, 2013 at 12:25 AM, Martin Graesslin > >> > >> wrote: > >>> > I'm pretty sure that some dev package is missing and that they are > >>> > available on Ubuntu otherwise project-neon could not compile 4.11 ;-) > >>> > >>> So only thing I am missing is libxcb-cursor-dev and it is not > >>> available for raring or saucy(?) > >> > >> did you check what's installed and what not. Because libxcb-cursor-dev is > >> marked as not-installed on the output I gave you (The "p" stands for > >> available package, you have to look for the "i"). > >> > >>> ... Can you check with available > >>> libraries on my system? and also my env output? > >> > >> I saw that output, but it didn't include any of the dev packages. > >> > >> Cheers > >> Martin > >> ___ > >> 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 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: Can not find XCB modules.
On Tuesday 20 August 2013 10:21:21 Bhushan Shah wrote: > On Tue, Aug 20, 2013 at 12:25 AM, Martin Graesslin wrote: > > I'm pretty sure that some dev package is missing and that they are > > available on Ubuntu otherwise project-neon could not compile 4.11 ;-) > > So only thing I am missing is libxcb-cursor-dev and it is not > available for raring or saucy(?) did you check what's installed and what not. Because libxcb-cursor-dev is marked as not-installed on the output I gave you (The "p" stands for available package, you have to look for the "i"). > ... Can you check with available > libraries on my system? and also my env output? I saw that output, but it didn't include any of the dev packages. 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: naming the next major release
On Monday 19 August 2013 21:56:35 Aaron J. Seigo wrote: > 3. ‘2’ ... why “two” if this is version 5? well, libplasma is actually going > to be version 6 iirc, so it isn’t the library. i also am not a big believer > in branding after version numbers. neither are any of our proprietary > competitors who have a lot more marketing and communications savvy than we > tend to. ;) what i like about 2 is: > > * it communicates this is something after the first. it’s that whole “two > point oh” thing, though hopefully less hype than, say, “web 2.0” ;) > > * it’s simple and direct > > * ‘2’ is a couple, and a couple is a nice human idea :) this is borne out by > the “1, 2, many” pattern in many ancient languages. we know 1, we know 2, > after that it’s just an abstract concept. I would like to get rid of version numbers in the traditional way. If the numbers are small, it's fine. But looking at many projects I am not able to get how old software is based on the number. So instead I suggest that we go by year and numbering: * 2014.1.4 * 2014.2.2 * 2014.3.1 -> year.major.minor It would also prevent the confusion that several parts of our software has now different versions and especially that 4+1=2 :-) > > > > Sooo ... here is my proposal: > > We call it Plasma 2 and use that as a rallying call to > focus on its unified user experience > across the spectrum of devices people use today. I do want to promote KWin for the usage in LXDE/Razor as in the next version we will hardly have any build-time dependencies from frameworks higher than tier1. I'm concerned that a generic name "Plasma" would work against that as it would be difficult to communicate that although being part of Plasma not being part of Plasma. If someone has a good idea on how to properly communicate this without being confusing (especially for users who want the lightweight aspect of LXDE and Plasma is for people in that user group unfortunately the definition of bloat) I consider this as a non-blocking issue for the naming. We should also think about what the name would mean for bug reporting. We don't want that all bugs for everything what is in kde-workspaces nowadays ends up in the component plasma. Cheers Martin P.S. Thanks for bringing the topic to the mailing list. 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: Can not find XCB modules.
On Monday 19 August 2013 20:55:49 Martin Graesslin wrote: > On Monday 19 August 2013 22:38:09 Bhushan Shah wrote: > > Hello, > > > > I am using project-neon5 on KUbuntu 13.04. I have every packages > > installed on my computer which is required to build. I can not build > > kwin, kstyles and powermanagement data engine so I have to disable it > > for building kde-workspace. > > > > CMake exits saying that XCB Libraries are not installed. [1] Well I > > have every xcb* packages installed on my computer. And related library > > files are present on my computer [2]. > > > > Invoking pkg-config with --debug prints that xcb packages are > > installed. [3]. And here is my env output. I still can not figure out > > what is wrong? My system? Project Neon 5? Extra cmake modules? Or > > myself? :-| > > give a try to: > aptitude search xcb | grep dev > > and compare to my output: > http://paste.kde.org/p23fb1d84/ > > I'm pretty sure that some dev package is missing and that they are available > on Ubuntu otherwise project-neon could not compile 4.11 ;-) and obviously you could just do: apt-get build-dep kde-workspace 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: Can not find XCB modules.
On Monday 19 August 2013 22:38:09 Bhushan Shah wrote: > Hello, > > I am using project-neon5 on KUbuntu 13.04. I have every packages > installed on my computer which is required to build. I can not build > kwin, kstyles and powermanagement data engine so I have to disable it > for building kde-workspace. > > CMake exits saying that XCB Libraries are not installed. [1] Well I > have every xcb* packages installed on my computer. And related library > files are present on my computer [2]. > > Invoking pkg-config with --debug prints that xcb packages are > installed. [3]. And here is my env output. I still can not figure out > what is wrong? My system? Project Neon 5? Extra cmake modules? Or > myself? :-| give a try to: aptitude search xcb | grep dev and compare to my output: http://paste.kde.org/p23fb1d84/ I'm pretty sure that some dev package is missing and that they are available on Ubuntu otherwise project-neon could not compile 4.11 ;-) 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: Need help to setup build environment of KF5
On Monday 19 August 2013 07:40:11 Kevin Ottens wrote: > On Sunday 18 August 2013 09:50:48 Bhushan Shah wrote: > > Hello, > > > > On Sat, Aug 17, 2013 at 11:55 PM, Giorgos Tsiapaliokas > > > > wrote: > > > show us the cmake errors :) > > > > http://paste.kde.org/pd1e6e267/ > > > > I have XCB development library installed in my computer but still I am > > getting this error.. > > XCB packages are generally modularized by distros. Are you sure you have the > devel packages for xcb keysyms and xcb xtest? Those two are reported as > missing. And to fix this problem I just split XCB into components: https://git.reviewboard.kde.org/r/112151/ 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: How to build KDE Workspace on top of KF5?
On Friday 16 August 2013 14:10:46 Bhushan Shah wrote: > Hello, > > I have installed the project-neon5-session in my KUbuntu installation and > now want to build frameworks-scratch branch of the kde-workspace. > > What are the next steps? Please someone give me guide to build it. it's not really different. Just use kdesrc-build as instructed on https://community.kde.org/Frameworks/Building 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: Compiling QT5 for KF5
On Wednesday 14 August 2013 13:13:19 Bhushan Shah wrote: > Hello, I am using Arch Linux i686. Thanks! I'm not the Arch expert, but it seems like something exists: https://bbs.archlinux.org/viewtopic.php?id=164647 Cheers Martin > > On 8/14/13, Martin Graesslin wrote: > > On Wednesday 14 August 2013 12:36:18 Bhushan Shah wrote: > >> Hello, > >> > >> I want to compile QT 5.2 for compiling kde-framework 5, So want to ask if > >> I > >> can ignore some submodules to speedup compiling process? Like qt > >> multimedia > >> package etc? > > > > depending on your distribution there might be "daily" built packages of Qt > > 5.2 > > available. So which distro are you using? > > > > Cheers > > Martin > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel 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: Compiling QT5 for KF5
On Wednesday 14 August 2013 12:36:18 Bhushan Shah wrote: > Hello, > > I want to compile QT 5.2 for compiling kde-framework 5, So want to ask if I > can ignore some submodules to speedup compiling process? Like qt multimedia > package etc? depending on your distribution there might be "daily" built packages of Qt 5.2 available. So which distro are you using? 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
Announcing kwindoweffectsplugin
Hi all, to help me with working on KWindowEffects I decided to write a small qml plugin which exports all the methods of KWindowEffects to qml. I just pushed this plugin to a personal scratch repository: kde:scratch/graesslin/kwindoweffectsplugin [1] It contains an example.qml which can be loaded in qmlscene and shows how to use the plugin and also is a nice example of what we can do with the KWindowEffects. I am not sure whether this plugin is of use for more things than just an example. So feel free to do with it as you wish or tell me that it is useful and what I should do with it. Cheers Martin [1] http://commits.kde.org/scratch/graesslin/kwindoweffectsplugin/edc6bbb6c23d1cde45362f8a5433a548a2651081 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
Libtaskmanager ported to Qt5/KF5
Hi all, on special request by Eike I looked into porting libtaskmanager to Qt5/KF5. And after a surprisingly easy port I just pushed to frameworks-scratch branch a commit which enables building of libtaskmanager again. As a side effect I also had to port ksysguard/processcore. Obviously I have not tested whether the code works but we should notice soon enough when the tasks applet gets ported ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: framework5/plasma2
On Monday 29 July 2013 08:14:20 Heena Mahour wrote: > I did heena@heena-Aspire-5750:~/plasma-framework$ plasma-shell > plasma-shell: symbol lookup error: > /home/heena/kf5/lib/i386-linux-gnu/libKDE4Support.so.5: undefined symbol: > kde_kiosk_admin > How to exactly test the plasma2 plasmoid (as plasmoidviewer can not be used that's a problem currently under investigation on the frameworks mailinglist [1]. The sad truth is that it's currently probably not possible to test at all. I hope this issue will be resolved shortly, and if it is not I will schedule some time for it this week as it starts to block my work. Cheers Martin [1] http://thread.gmane.org/gmane.comp.kde.devel.frameworks/3822 > _ > Regards > > > On Sat, Jul 27, 2013 at 12:21 PM, Giorgos Tsiapaliokas > > wrote: > > Hello, > > > > On 26 July 2013 22:26, Heena Mahour wrote: > >> Yeah , so how to proceed with porting plasma2 plasmoids. > >> I want to ask how plasma2 plasmoid would be tested as > > > > just start plasma-shell and load your plasmoid, then in order to reload it > > remove your plasmoid and load it again. > > > > -- > > Giorgos Tsiapaliokas (terietor) > > > > terietor.org > > > > ___ > > 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: Mondaily pow-wow at 12
On Monday 29 July 2013 01:11:52 Sebastian Kügler wrote: > Hi all, > > Let's do our weekly Plasma hangout at 12.00 Europe/Amsterdam (and most of > Europe, except Greece). > > If you'd like to join in, show up in #plasma right before, and shout my > name. Should we start having a public part (on air) again? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework compile error
On Friday 26 July 2013 22:27:01 Heena Mahour wrote: > Hi , > I am getting cmake error when I build plasma-framework > http://pastebin.com/raw.php?i=aHbnWHbn .I have build framework branch of > kdelibs .KIndly suggest something . This should be fixed already, but you need to rebuild kdelibs-frameworks. Nevertheless it's currently failing, see [1]. But you can workaround this build error by hacking CMakeLists.txt and disable build of src/declarativeimports/dirmodel Cheers Martin [1] http://build.kde.org/view/kdelibs/job/plasma-framework_master_qt5/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to read and write clipboard in plasma qml?
On Friday 19 July 2013 21:50:18 Nowardev-Team wrote: > i mean qdbus org.kde.klipper /klipper > org.kde.klipper.klipper.setClipboardContents "text to paste" > > get the stuff in klipper > > qdbus org.kde.klipper /klipper > org.kde.klipper.klipper.getClipboardContents note: this only works in case klipper is running. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-shell and -std=c++0x flag
On Saturday 22 June 2013 16:38:56 Ivan Čukić wrote: > Hi all, > > Following the previous discussions on k-c-d where it was concluded that the > workspace-related code (as opposed to the libs) can use more modern c++ > features as long as those are not introduced after gcc 4.5, I'd like to ask > whether there are objections to add the -std=c++0x flag to the plasma-shell > (plasma2) build? obvious +1 (will do the same for KWin once 4.11 is branched). What about clang? Does it need an additional parameter? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Keyboard detection and a test request
On Friday 21 June 2013 18:17:19 Àlex Fiestas wrote: > On Friday 21 June 2013 17:41:57 Ivan Čukić wrote: > > > What I did was: > > > -Detect if any keyboard was present > > > -Detect Mouse/touchpad > > > > > > you have a Qt wrapper of udev in kdelibs/solid. > > > > Great to know, will try it out later. Though I'm wondering whether this > > could lead to recognizing the devices that don't work with X. > > > > Anyhow, Aaron's idea to track the device property and this are the most > > viable choices for keyboard detection. > > Note that Xorg uses udev underneath, and its little what Xorg adds on top as > far as I know. and when using udev you don't have to care about Wayland ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Animate style hint
On Wednesday 12 June 2013 10:39:17 Aaron J. Seigo wrote: > i seriously think most people[1] who "don't like animations" should get over > it. i can't imagine how they survive in the real world where everything is > "animated" I completely agree with everything Aaron wrote but just want to point out that it would be super awesome if we could disable the animations in PW2 in case of llvmpipe. This could turn the system from "unusable" to "don't notice". Best that would be added directly to Qt, though and I just at the moment fail to see how one could implement this. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Tuesday 28 May 2013 14:25:08 Thomas Pfeiffer wrote: > On 28.05.2013 14:17, Luiz Romário Santana Rios wrote: > > 2013/5/28 Thomas Pfeiffer : > >> If developers start actively searching for very specific brainstorm > >> topics, > >> the whole point of moving there would be moot. > >> The goal is that the forum does the filtering and developers only have to > >> look at the most upvoted ideas and move those that seem to be worthy of > >> implementation back into bugzilla. > > > > So, the idea is to move wishlist bugs away from bugzilla, repost them > > in the brainstorm forum, and then post the most upvoted ideas back > > into bugzilla, where interested devs will actually look for ideas? > > I don't know how exactly the KWin team does it, but I only see benefit > if only the most useful and wanted ideas even reach developers. If they > still have to sift through dozens of ideas with the only difference that > they have a vote number attached to them, I don't see too much of an > advantage. I'm subscribed to all ideas coming in on brainstorm. It's not much - comparable to what we get as feature requests still on bugzilla. The point is not to get the number of votes, but to get the downvotes. I am not aware that I ever implemented an idea. So the number of bad ideas is way higher than the number of good ones. That's the key to the success. If we want to have useable feature requests we need to get rid off the useless ones. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Monday 27 May 2013 14:48:52 Thomas Pfeiffer wrote: > On 27.05.2013 14:03, Martin Graesslin wrote: > > On Monday 27 May 2013 13:25:35 Mario Fux KDE ML wrote: > >> Do you plan as well to remove the option to send "bugs" with severity > >> "wishlist" on bugs.kde.org (and probably just leave it for some > >> brainstorm > >> moderators). Would be two steps less for "wishlist submitters" and the > >> above message just for the submitters who already sent their wishlists. > > > > We cannot do that (yet). This would be an overall change to the > > bugs.kde.org workflow. For smaller projects having the wishlist entries > > in bugzilla might be useful, so I doubt we would be able to get an > > overall change in bugs.kde.org. > On the other hand, consistency would be very useful here. It would get > quite confusing for users if they had to know for each project whether > it accepts wishlist items on bugzilla or on brainstorm. I don't think this matters at all. KWin uses this policy for at least a year and we have not had any complaint from users about it. Reality is that hardly any feature requests get created in the first place. We are talking here about 150 reports per year. So a maximum of 150 users can be confused by it. > If all of KDE > moved to brainstorm for wishes, we could just post on the Dot "From now > on, all feature requests for KDE projects will be handled on > brainstorm.forum.kde.org". This is clearly too early. We first need the infrastructure to handle it. As forum people have pointed out: if Plasma would start to use it, we will need more people moderating. I'm confident about this, but I am not for all of KDE. > > So why not start this discussion again on kde-devel and see what the > other projects think? I'm not going to start a bike-shed discussion :-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Monday 27 May 2013 13:25:35 Mario Fux KDE ML wrote: > Do you plan as well to remove the option to send "bugs" with severity > "wishlist" on bugs.kde.org (and probably just leave it for some brainstorm > moderators). Would be two steps less for "wishlist submitters" and the above > message just for the submitters who already sent their wishlists. We cannot do that (yet). This would be an overall change to the bugs.kde.org workflow. For smaller projects having the wishlist entries in bugzilla might be useful, so I doubt we would be able to get an overall change in bugs.kde.org. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Sunday 26 May 2013 18:07:14 Thomas Pfeiffer wrote: > On Sunday 26 May 2013 00:05:56 Marco Martin wrote: > > On Saturday 25 May 2013 14:32:29 Martin Graesslin wrote: > > > > And this is clearly the case let's work around something we don't want > > > > to > > > > fix. Switches are a clear improvement over checkboxes depending on the > > > > context even my 60yo mom got it much quickier than a checkbox would be > > > > able > > > > to on my plasmoids. > > > > > > And I would completely fail to use the switch. I have huge problems > > > understanding those switches and I have not seen any implementation of > > > the > > > switch where I got which one is on and which one is off. > > > > that's for me as well. > > I have to spend a second or more every time to figure/remember if the "on" > > that is written on the switch (or being colored vs greyed, same thing) > > means "it's on now" or "it's an action, so it's telling me it becomes on > > if i click on it" > > Well actually, there is an easy way to make it absolutely clear which is > which, although it takes lots of horizontal space and probably looks very > ugly if you have many switches in the same UI: Just add text labels on each > side, _next to_ the button, not inside of it. E.g. "OFF" or "O" on the left > side, "ON" or "I" on the right side. That makes things perfectly clear. Yes, it does. That clearly would work for me. As I mentioned in one of the replies if I see both states with a label, I am able to recognize what means on and what means off. As mentioned I found exactly one switch similar to the touch switches in my flat and it has distinct labels and I never failed to use that one ;-) > So if ambiguity is the only reason against using switches on Desktop, we > should use them. At least for me there is another reason: given the way how the switch component is designed (again no matter which one) I am inclined to drag it from left to right. I don't try to click, I have to drag. There is no visual hint that clicking would adjust the state. It doesn't look like a clickable button. This makes the component really difficult to use. While on a touch screen it's much easier to use than a check box. Now I could learn to click (so far I failed to do so), but I can think of many people who would no longer be able to learn this. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable bug reporting till Bugzilla situation is improved
On Sunday 26 May 2013 13:26:45 Aaron J. Seigo wrote: > On Sunday, May 26, 2013 12:05:25 Martin Graesslin wrote: > > this is probably a controversial proposal: Let's disable bug reporting for > > Plasma until the current situation is improved. > > .. > > > Opinions? > > I would expect this to piss off users even more than the current situation. > Saying "we don't even want your input" is one step worse than "add your > input, it may not be immediately addressed". It will also teach people not > to try and we'll lose future reports. If we would sell it as part of a quality offensive... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Disable bug reporting till Bugzilla situation is improved
Hi all, this is probably a controversial proposal: Let's disable bug reporting for Plasma until the current situation is improved. Reason: the bugtracker in it's current state gets flooded by new incoming reports and we are not able to get the water out of our cellar as long as new water is coming in. So let's put a plug into the leaking pipe and then start to get the water out and let's fix the leak properly and then turn on the water again. I don't know whether it's possible (need to talk to sysadmins), but I would keep it open for kde devs, so that we would get reports for newly introduced regressions/bugs in master. This has to be absolutely temporarily and should be stopped before the release of 4.11. If I had to set a hard date I would say June, 26th, which is the beta 2 release. Opinions? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Saturday 25 May 2013 15:55:50 Luca Beltrame wrote: > In data sabato 25 maggio 2013 11:28:46, Martin Graesslin ha scritto: > > Hello, > > > Of course that can only work if users are willing to participate in > > brainstorm to do the voting and the selection of good reports. If that > > Since you mention it: more Idea Moderators (those who used to do some basic > triaging on the ideas) would be nice, they don't need to be developers but > any good (and with some basic understanding of recent developments) member > of the community with time on their hands could do that. > > Currently the count is at the all time high of... 0. That is why, should > this proposal proceed forward, we'd need to attract a few people to help so > that we avoid the dumping ground phenomenon. good to know. I am optimistic that we will find a solution to it. Our community is large and forum is a much nicer place to work with than bugzilla ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [Bugsquad] Something for the bugsquad :)
On Saturday 25 May 2013 21:50:25 Jekyll Wu wrote: > On 2013年05月25日 20:59, Martin Graesslin wrote: > > My aims are: > > * get the number of bugs down without having humans looking at the reports > > > > * reduce the number of bugs coming in > > Now that plasma-desktop uses KDE_VERSION_STRING (since 4.10.3) instead > of the never changing stone 0.4 version, we can make use of bugzilla's > new feature of rejecting reports against disabled versions to reduce > received crash reports. Since the plasma product is already receiving > too many reports, I think it can apply a very strict policy with active > versions: only make the current stable and current development version > active. That means only making 4.10.3(current stable) and 4.10.60 > (current development) active. It's already using the same policy as KWin: latest two minor of latest two major. It works quite well for KWin, so that should be fine. > > Actually, since all plasma-desktops form KDE SC 4.10.2 and older use the > same 0.4 version, we can simply add and disable that 0.4 version. Once > that simple operation is done, plasma product won't receive any > plamsa-desktop crash report from KDE SC 4.10.2 and older. I generally > won't recommend such a strict or rude policy, but that is indeed one > option if really needed. Oh I didn't know about the 0.4 thing. Just created that version and disabled it. Let's see how this improves the situation ;-) > > > * filter out new bugs quicker (I have some ideas especially for crashes) > > would like to hear about that. Will do once I have done the first experiments with the idea. In my head it looks like a sane approach ;-) > > > * introduce more components > > Yes, one component for each plasmoid > > > * assign maintainers to the components > > assign each component to the fake plasma--b...@kde.org user, > and add real maintainer and plasma-b...@kde.org into default CC list of > each component. We all know the horrible traffic brought by watching > plasma-b...@kde.org. Divide and conqueror. Seriously, I always wonder > how many plasma developers are watching plasma-b...@kde.org ? No blame, > I just think the horrible traffic would easily defeat most watchers. > > > Never make real users as the default assignee, because that only causes > trouble for maintain-ship handover, and make bug watching painful > (assume I'm the default assignee of kickoff component and super active > in the whole bugs.kde.org ,but some potential contributor is currently > only interested with kickoff bugs...) Very good suggestion! > > > * get the maintainers to care;-) > > My impression is many components/plasmoids just do not have dedicate > maintainer, or has some no longer active maintainer. Much more plasmoids have a maintainer than one would think. For example I think just this week we found a new maintainer for the battery plasmoid ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Saturday 25 May 2013 14:47:38 Aaron J. Seigo wrote: > what we could do for the plasma ones is schedule an hour a week (or twice a > week?) and take them in batches and see if it is possible to work through > them quickly enough. if not, we can take the Big Hatchet to them all. i > don't want to do this on my own, but if we can get 2-3 others, we could > parallelize this into submission. we'll need to be brutal: only compelling > and implementable feature requests would be kept. It's hard work, but it's doable, though 1000 reports are a lot. What worked well for me, when doing it for KWin, was while watching TV (boring football matches are awesome for that). Also we need templates. And we need to subscribe to the bugs to get informed about further comments. Did I mention that I would love to have an automated tool for doing the same tasks again and again ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Saturday 25 May 2013 09:43:26 Daniel Nicoletti wrote: > 2013/5/25 Martin Graesslin : > > And I would completely fail to use the switch. I have huge problems > > understanding those switches and I have not seen any implementation of the > > switch where I got which one is on and which one is off. > > You are totally right, because they need fixing, even if they are only to > be used in Plasma Active. > Here are a few examples of how a good switch should look like (IMO): > http://developer.android.com/design/media/settings_master_on_off_2.png > http://1.bp.blogspot.com/-AXi56wp5zVE/T6pAZj-MXdI/ACM/-wT0w1PpcJ4/s1 > 600/device-2012-05-09-152937.png Both I don't get what is on and what is off. Especially the second one is problematic as I don't know whether it's on right now or whether I have to drag the switch over to turn it on. The first one shows me that something is on but I wouldn't get that it is a switch. It looks like an indicator. > > This is the one I like the most (it's the one on my Xperia phone): > http://i582.photobucket.com/albums/ss269/netbookc/XB1/XperiaSICSFirmware_12. > png This one would work for me as long as both sides are shown. If I would just have the disabled or the enabled state without the other one I would fail as well. > > These switches are very useful in certain parts of the world (e.g. US) > > where every light switch is like that. It was quite an epiphany to me > > when I visited the US last year - I finally got what these switches are > > supposed to be. For me this switch is just a not working metaphor as we > > don't have switches like that in this part of the world [1]. > > > > Just something to remember when it comes to metaphors. They might be > > awesome for some, but if one doesn't understand it, it makes it much more > > difficult. > I don't think Switches are only about metaphors, actually here in Brazil we > also don't have those, but look at some China toy, or some table clock and > you will see them, so what it misses is how does it present it's states. You know what I just did? I went through my flat and looked at all switches to see whether I have any of them. Almost all switches do not indicate whether they are in an on or off state. The state is mostly indicated by some other indicator (e.g. a LED). I found only two switches which also indicate the on/off state. One of them is [1], which is quite clear, but wouldn't work in software. The other one is similar to the typical touch switches, but both possible states are labeled, so I get how it is meant to be used. But a switch like the one in typical touch world doesn't exist at least in my flat. > > In print-manager for instance I make the text and icon disabled trying to > improve the poor situation. do you have a screenshot? I bet I will fail again. Cheers Martin [1] http://commons.wikimedia.org/wiki/File:Mechanischer_Schalter.jpg ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [Bugsquad] Something for the bugsquad :)
On Saturday 25 May 2013 14:11:57 Myriam Schweingruber wrote: > You don't care for the users? Don't release anything to the public and > keep it to yourselves! But if you release an boast about it, do your > homework, and that means handling the bug database yourself! I don't think that the blame game is helping anything here. I think we need to figure out what's going wrong and how to fix the problems. That's what I'm trying to do. Plasma is different to all other products in KDE. For example over the last year 1885 new bugs were reported against Plasma. The second largest project in top ten is KMail with 706. The difference here is that KMail is just in a difficult state and Plasma is by now quite a mature product. KWin got 849 but there are two developers constantly working on it. And yes I think our time would be better spent. Amarok got 808 and that they survive is largely thanks to you. Both have something in common: we get crashes in a lower layer which are relatively easy to triage. We just have to accept that Plasma gets more bugs than the developers can handle. That's a bad situation but probably also part of the frustration. Even if the developers would work perfectly on the bugs it would still be like Sisyphos. The developer base is hardly larger than what KWin has. But we would not be able to handle twice the number of bug reports. So we need to stop the flood. We need to get the bug tracker into a workable state and triaging is not the solution. My aims are: * get the number of bugs down without having humans looking at the reports * reduce the number of bugs coming in * filter out new bugs quicker (I have some ideas especially for crashes) * introduce more components * assign maintainers to the components * get the maintainers to care ;-) Yes we need some rethinking, but I think that will come when the bugtracker gets into a useable state. I know it also from own experience. When KWin had more than 400 bugs it just was unusable. We were fixing bugs but the report stayed open because we couldn't find it. Now it's not a problem any more, since we have components it's even trivial. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
On Saturday 25 May 2013 09:14:03 Daniel Nicoletti wrote: > 2013/5/25 Aaron J. Seigo : > > Switches are not to be used on Desktop. For 4.11 the QML switch component > > appears as a checkbox, so you really don't have a choice in the end. The > > reasons are: > > > > * consistency > > * input device appropriateness > > * people use them poorly on desktop (just look at UIs that use them > > extensively on desktop and what the layouts end up looking like .. > > horrendous, often with labels on the left and switch crammed far off to > > the right. just like in this draft of the battery, actually, which ends > > up having an odd widget floating off on its own) > > I'm sorry but I've been hearing the same phrase over and over KDE people, > "if something is broken go fix it instead of working around". > > And this is clearly the case let's work around something we don't want to > fix. Switches are a clear improvement over checkboxes depending on the > context even my 60yo mom got it much quickier than a checkbox would be able > to on my plasmoids. And I would completely fail to use the switch. I have huge problems understanding those switches and I have not seen any implementation of the switch where I got which one is on and which one is off. These switches are very useful in certain parts of the world (e.g. US) where every light switch is like that. It was quite an epiphany to me when I visited the US last year - I finally got what these switches are supposed to be. For me this switch is just a not working metaphor as we don't have switches like that in this part of the world [1]. Just something to remember when it comes to metaphors. They might be awesome for some, but if one doesn't understand it, it makes it much more difficult. Cheers Martin [1] http://commons.wikimedia.org/wiki/File:Lichtschalter.jpg ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Closing outdated crash reports
On Saturday 25 May 2013 17:40:10 Jekyll Wu wrote: > On 2013年05月25日 15:19, Martin Graesslin wrote: > > Hi all, > > > > Plasma has many open crash reports for outdated versions [1]. I would > > suggest to close them all as: > > a) Stack traces most likely do not match any more > > b) It's quite likely that it's a duplicate > > c) Users can easily reopen if it's still valid with latest version > > d) If it's a crash and still valid it will be reported again (given enough > > eyes...) > > I like the idea in general, but the suggested bug list is a little > dangerous (meaning it might cause very bad public image) : > > 1. it contains quite a few "CONFIRMED" and "REOPENED" reports, so > closing them will certainly make users angry and be reopened again > later. For such reports, we could ask "can someone try and see whether > it is still valid in 4.10.3 ?" but really should not close it and wait > for angry users to shout and reopen it. oh that was just an example query. I would have tried to get it more fine- grained. I think your one looks really good, but I will probably also have a look at the CONFIRMED and REOPENED ones - personal experience: it doesn't mean anything, especially REOPENED. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Saturday 25 May 2013 11:13:31 Myriam Schweingruber wrote: > While I salute your idea I fear it will not work, as it needs Plasma > people to actively work on Brainstorm, and that is already not the > case on bugzilla. Moving the wishes elsewhere is just moving the > problem elsewhere. > > As long as the Plasma Team doesn't really, really do what they boost > they do ( as in maintaining a codebase which implies also maintaining > a bugs list like we do in Amarok and many other projects) and really > look at the bugs list and work on the existing bugs that will simply > not work. feature requests are not bug reports! Whether Plasma devs look at bug reports or not is irrelevant on the question of feature requests. Saying for KWin: we did an awesome work on the bugs but did an awful work on the feature requests. Feature requests is something we need the help of the users or anybody. It doesn't need devs to say that an idea is bad because it would be unusable. Anybody can do that. Brainstorm is suited for this, bugzilla isn't. I think it's not the task of the developers to look on the feature requests[1]. That's something the userbase can and should do. If an idea gets approved through the brainstorm process, then it can be passed to the developers to have a look at for technically feasibility. This would be in most cases just a few minutes of work. If brainstorm would produce one request per month (that's highly optimistic) it would reduce the work load a lot. Of course that can only work if users are willing to participate in brainstorm to do the voting and the selection of good reports. If that doesn't help we can just stop to think we need feature requests. Cheers Martin [1] In the end it's also not the task of the developers to look at the bug reports. We developers are the third level support and are doing first level support tasks. Hilarious. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Moving Wishlist Items to Brainstorm
On Saturday 25 May 2013 10:03:16 Luca Beltrame wrote: > That said, voting etc might be useful to do some pre-screening on feature. > Although votes are not a useful metric per se, my last experiment with > scoring Brainstorm ideas put genuinely useful ideas at top. For me the feature of down voting is the most important one as that automatically removes the stupid ideas. And out of experience: those are the most annoying ones. The users don't accept a "sorry, this doesn't make sense because a, b, c". They start to argue and that's binding time. Getting this to be downvoted by users helps solving the problem. > > But keep in mind point 2 from above: if it's just a dumping ground, you'll > get rid of a frustration to get another one in. It doesn't have to be a dumping ground. If the voting and discussions work, the system should produce high quality ideas. Whether they get implemented is then a different question (c.f. shutdown of Ubuntu brainstorm). But if it really a good idea and not dream concert (e.g. Plasmoids in own processes) I don't see a reason why someone would not want to get a good idea into the product. And that could be crowed sourced ,too - doesn't have to be the main developers to implement ideas. > > Also, if there is a plan on using Brainstorm as is, perhaps some pubicity > might be needed (currently it's very low on the radar). Yeah that could be a good idea to do it in the same step and e.g. announce on the dot that Plasma moves over to brainstorm for feature suggestions. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Closing outdated crash reports
Hi all, Plasma has many open crash reports for outdated versions [1]. I would suggest to close them all as: a) Stack traces most likely do not match any more b) It's quite likely that it's a duplicate c) Users can easily reopen if it's still valid with latest version d) If it's a crash and still valid it will be reported again (given enough eyes...) I would suggest the following template for closing (native speakers: please correct): "Thank you for this crash report and helping to improve our software. Unfortunately we were not able to work on this specific report yet. Nowadays the version this crash was reported against is no longer maintained and this makes it very difficult to work on this report as the source code might have changed and the information in the backtrace is no longer valid. Also it is quite likely that this problem got fixed in a later version. Crash reports are very often reported multiple times. If you are able to reproduce this crash with the latest version of KDE Plasma (4.10.3) please reopen this report and adjust the version information in the dropdown above and please also include a new backtrace as generated by the crash reporting tool. Please also make sure that the steps on how to reproduce the crash are precise and correct. Thank you!" As new status I would suggest RESOLVED/UNMAINTAINED. Comments? Cheers Martin [1] https://bugs.kde.org/buglist.cgi?list_id=661950&bug_severity=crash&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&version=unspecified&version=4.5%20and%20older&version=4.6.0&version=4.6.1&version=4.6.2&version=4.6.3&version=4.6.4&version=4.6.5&version=4.7.0&version=4.7.1&version=4.7.2&version=4.7.3&version=4.7.4&version=4.8.0&version=4.8.1&version=4.8.2&version=4.8.3&version=4.9-git&version=4.7.90&version=4.7.95&version=4.8.80%20%28beta1%29&version=4.7.80&version=4.7.97&version=4.8.4&version=4.8.90%20%28beta2%29&version=4.8.95%20%28RC1%29&version=4.8.97%28RC2%29&version=4.9.0&version=4.8.5&version=4.9.1&version=4.9.2&version=4.9.3&version=4.9.80%20Beta1&version=4.9.90%20Beta2&version=4.9.95%20RC1&version=4.9.97%20RC2&version=4.9.98%20RC3&product=plasma ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Moving Wishlist Items to Brainstorm
Hi all, based on yesterdays discussion with Aaron about the bugtracker I want to provide a few suggestions on how we can start to clean up the bugtracker and get it into a workable state again. My first suggestion is to move from now on all "wishes" to brainstorm.forum.kde.org. Bugzilla is quite unsuited for feature requests as we don't have any way to figure out whether the feature is just a one users dream concert or a valid need. Brainstorm allows to filter out the bad requests. The only indication we have is the voting feature and that is well not very useful. For KWin I use the following template when we get a new feature request: > Thank you for your feature suggestion. Unfortunately bugzilla is not the > best place to discuss feature requests. We hardly have any users here, so we > don't get an evaluation whether the feature is needed. > > We therefore recommend to use http://brainstorm.forum.kde.org to suggest > this idea. Users are able to up/down-vote the feature request and by that we > get an idea whether it's something our users wish to see and whether it is > worth to invest time into it. > > If the feature request is supported on brainstorm it will automatically be > recreated here in the bug tracker. Given that I'm marking this feature > request as WONTFIX for now. This has nothing to do with whether we think > this is a good or bad feature request. > > I'm very sorry that our software does not allow to send users to brainstorm > in the first place. This is something easily doable from now on. Now the more difficult topic as it involves the existing database: closing all existing wishlist items. In my opinion if we agree on using brainstorm the logical consequence is to close also all existing feature requests. That's again something I did for KWin just with a difference. For KWin we were able to look at each feature request and give a reason on why the feature request doesn't make sense. I had a look at whether Plasma devs use the wishlist reports. So here are some stats: * 1137 open reports * 123 reports were not touched over the last four years * 385 reports were not touched over the last three years * 591 reports were not touched over the last two years * 22 reports got fixed over the last year * 6 reports got fixed by a commit over the last year Given that I think we can safely assume that having those wishlist items is not useful. The question I cannot answer is whether to automatically close all reports or just those not touched for n years? This is something the Plasma devs have to tell me whether they think there is anything useful in the still open reports. Things to agree on: 1. Send users to brainstorm when creating a wishlist item from now on 2. Close existing wishlist items 2a) how many items to close If we agree on 2 I will prepare a message, but will need a native speaker to cross-read it. And we need sysadmins to do the closing otherwise they will be unhappy because we kill the mail server ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Default activity naming issues
On Wednesday 15 May 2013 16:21:28 Aaron J. Seigo wrote: > On Wednesday, May 15, 2013 15:31:16 Ivan ÄukiÄ wrote: > > Welcome is nice, but again, not a real activity (link to Welcome and > > similar). > > If we want a meangingful default name, then I think we have to ask the user > ... which brings us back to how nice it would be to have a first-run welcome > app that lets you set up your online accounts and things like your user > information what are you using your system primarily for? * work * videos * Internet * Lolcats * Other: -> name of default activity -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Remove remote plasmoids in 4.11
Hi all, I'm in the unlucky situation that a certain person, let's call him David E. [1], had the great idea to demonstrate how reliable Plasmoid Sharing over the network works. The result: 1. every time I connect to the same network as D's notebook I get several notifications that a new Applet is available 2. Adding the Applet does not work 3. Stopping the export on D's system does not work [2] My proposal for 4.11: let's remove remote plasmoids. They don't work and they are a rather annoying way to annoy people around you. AFAIK they have already been removed from libplasma2. Comments? Cheers Martin [1] no that is too obvious, let's change to D. Edmundson [2] restarting plasma-desktop seems to have fixed that problem ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
On Saturday 04 May 2013 22:34:04 Kevin Kofler wrote: > On Friday 03 May 2013 at 17:04:44, Matthias Klumpp wrote: > > @Kevin: I am only remotely following this issue, but as PackageKit > > developer, I would of course like to see our project in Plasma > > Workspaces as soon as possible. But I don't know the exact issues > > here. Also, having KSecrets merged would be a nice goal too. (The > > SecretService API is very stable, and has the potential to become a > > new de-facto XDG standard soon) > > The issues are the same in both cases: They're kdelibs features and kdelibs > does not accept any features. By the time the first release of the Plasma > Workspaces based on KF5 is planned, kdelibs will have been feature-frozen > for THREE YEARS!!! (And I'm not even speaking of applications there!) @Kevin: a small tip. People might consider your arguments as valid if you would calm down a little bit in your writing. I cannot consider arguments of people as serious if they scream, neither in spoken communication nor in written communication. As I already wrote in my last mail to this thread: yes everybody knows your opinion of how kdelibs freeze should be handled. Repeating it in every single thread which might even be slightly related to the freeze, won't change anything. All the arguments you bring up were valid or not two years ago and that hasn't change. Don't expect that people just change their mind because Kevin just pointed out that it will be a freeze of three years in the end. It would be really awesome if you could switch your passion on that topic in constructive work and help making kde-framworks rock so that the freeze is not that long. I don't see why one wouldn't want to start integrating new features right now. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Use user wallpaper for dm, splashscreen and locksreen
On Saturday 27 April 2013 14:09:32 Davide Bettio wrote: > Hello, > > During boot process background is changed several times, to avoid this > I think that current activity wallpaper should be used as background > for display manager, splashscreen and lockscreen. > To get this feature working we just need to save current wallpaper to > a configuration file every time current activity is changed. > > Any comment? I think we discussed this situation at the sprint last week and decided against it. The idea to use the configured wallpaper falls short in a few ways: * It can only work with image, but not with animated, marble or whatever wallpaper plugin * it cannot handle the multi screen case. * we would need to know the activity before kactivity manager is started. Especially the login manager cannot know which user will log in, before the user logged in. One of the ideas discussed at the sprint was to define a global theme package which is used by all themable elements such as login manager, splash screen, etc. etc. This would ensure that all our elements are consistent. What is currently still missing would be a plymouth theme being shipped directly by us (best would be a ). Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC]: Drop support for Compiz in KDecoration
On Friday 15 March 2013 14:38:45 Martin Gräßlin wrote: > * Mageia is shipping an up to date version of Compiz (!), whether it > includes compiz-kde I couldn't figure out [8] Looked again: it's not included. Summary: no distribution of the top ten on distrowatch is shipping compiz KDE integration in an up to date version. /me is going to prepare a review request. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kdev4 files in repositories
On Tuesday 12 March 2013 19:57:53 Ralf Jung wrote: > Hi, > > file cleaning up my ~/src, I stumbled upon two .kdev4 files which can be > found in KDE git repositories (current master): > kde-runtime/plasma/kpart/kpart.kdev4 > kdelibs/plasma/plasma.kdev4 > Were these committed on purpose? what does git blame tell? > That seems quite unlikely to me, but > nevertheless I don't want to just git rm them without prior confirmation ;-) I'm 99.99 % sure that it's a relict of svn and just add all. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Draft for Components Overview
Hi all, back in the QA discussion I proposed that we setup a list of all components of the Plasma workspaces, find a maintainer for each of it and document all of that. I have finally got around to setup a draft page in my wiki namespace [1]. The list of components is derived from source code structure and not from existing bugzilla components. So far I have included everything underneath the plasma directory in kde-workspaces.git. The basic idea is shown for Kickoff: * Bugzilla component as link to bug query * Link to source code * Maintainer (not yet filled out) If people agree with this general structure, I'll fill out the information which is already present and move it to the public namespace and then we start assigning maintainers and add more areas like KRunner, KSMServer, etc. Comments? Cheers Martin [1] http://community.kde.org/User:Mgraesslin/Plasma_Components ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Invite Razor-Qt to next Workspaces Sprint
On Sunday 17 February 2013 02:08:57 Aaron J. Seigo wrote: > On Saturday, February 16, 2013 16:54:03 Martin Graesslin wrote: > > I wouldn't call KDE Plasma lightweight > > indeed; those 1Ghz ARM cpus with 512MB of RAM running it are just *beasts* > of the modern age I tell you. ;) > > razorqt may be lighter still (i haven't looked, but i can imagine all sorts > of ways of making a lighter system), but let's keep some perspective here. notice: I put the first lightweight into "" ;-) Personal assumption is that it's users don't like Plasma because we: * pull in Akonadi * which pulls in MySQL * and pulls in Nepomuk * which pulls in Virtuoso and there's no way denying that those pieces of the stack (even if much better now) have not been anything like lightweight. And it doesn't help that it's all optional in Plasma, users don't care about that. > > Personally I would like to get razor on the long road into the KDE > > community. I would love to see razor being hosted on our infrastructure > > and > > hosting and sharing technology indeed makes sense. > > as Marco noted this next sprint is going to be focused on the libplasma-and- > friends code, but as long as that isn't going to be completely > uninteresting for them it'd be great to have some of razorqt devs there. we need of course to point that out > > > That is whenever a user complains about Plasma we can suggest > > them to use razor. > > having a multiplicity of options for people to choose from is fine. ensuring > that the messaging does not become confusing would need to be cared for, > but that's not hard. > > that said, i'd also like to think we can address valid issues rather than > just push them off to someone else's pile. Of course, though I don't think we can make everybody happy and we should not strive for it. Let's put it different: I prefer internal competition and competition with a Qt based desktop over LXDE/XFCE ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Invite Razor-Qt to next Workspaces Sprint
On Saturday 16 February 2013 18:55:17 Sebastian Kügler wrote: > All good points. From my side, they're totally welcome. (I'd need to know in > time in order to make space for them during the sprint.) Are you in contact > with the developers already? Maybe in that case, you could ask if they're > interested? I had been in contact with them regarding KWin and we talked after the talk at FOSDEM and I (and also Will and Thiago) encouraged them to go to Akademy/Qt CS and the Plasma sprint. Though it was not an "official" invitation and the speaker is not one of the core devs. If people agree I would send a mail once we have a date set :-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Invite Razor-Qt to next Workspaces Sprint
Hi all, I want to suggest that we invite Razor-Qt developers to our next Workspaces Sprint in Nuremberg. *Why?* At FOSDEM there was a presentation about Razor-Qt and I attended it together with many other KDE developers. For me the most important information I took out of that talk was that Razor-Qt is not in competition with us, but an addendum to our offerings. Razor-Qt started from the assumption that there is no "lightweight" desktop environment based on Qt. This is actually the case - I wouldn't call KDE Plasma lightweight. And they aim for a userbase who don't want to use KDE Plasma (for whatever reasons, whether valid or not does not matter). Overall Razor-Qt seems to be rather open to use KDE technologies. What I noticed during the talk: * strong usage of Plasma themes * Oxygen Widget Style * KWin (though the recommendation seems to be openbox) I see here lots of possibilities for collaboration and to ensure that razor does not move into a direction that it would become a competition (valid question: how to prevent feature creep?) but also that we help the razor devs to not re-invent the wheel and use our frameworks (from the talk it seems that they are afraid of using K-technology). Overall to me razor looks like what a Kicker/KDesktop port to Qt4 would have looked like and it's nothing like Trinity. It's a modern approach, clean code and looking to the future (talk mentioned Qt5 and Wayland). Also I had made very positive experiences on discussing the usage of KWin on razor. *Evil white cat petting master plan* Personally I would like to get razor on the long road into the KDE community. I would love to see razor being hosted on our infrastructure and would love to see it as an alternative shell to Plasma offered by the KDE community. That is whenever a user complains about Plasma we can suggest them to use razor. And I think we all (razor and KDE) would truly benefit from that. *Comments?* Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Rethinking global shortcuts
On Saturday 09 February 2013 16:51:16 Mark wrote: > A window manager should in my opinion do just that, manage windows. It > has no business in managing global shortcut keys. Or is my logic > flawed? If so, please do correct me. In a Wayland world the compositor is responsible for input and there is no "Window Manager" any more. So yes handling global shortcuts is a feature KWin has to provide in the Wayland world. Also in the X world it would be very useful to have all input events filtered through KWin, which is just not possible with the X Architecture. Btw. having it in KWin does not mean that it doesn't work together with other window managers any more. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Rethinking global shortcuts
On Thursday 07 February 2013 18:51:41 Kevin Ottens wrote: > On Thursday 7 February 2013 14:33:47 Aaron J. Seigo wrote: > > this would mean work on our part in the kglobalshortcut code in kdelibs > > for > > frameworks 5 and would imply that we take full maintainership of this area > > of things. > > Please! > > Especially because a) I love what I read so far in that thread and b) I want > to see that gone from KAction (it's in my way ATM). oh yeah I hate to have it on KAction. It's just so stupid as one can only set one global shortcut... -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Screen Edge handling in 4.11
On Monday 21 January 2013 13:48:22 Aaron J. Seigo wrote: > On Monday, January 21, 2013 13:10:36 Martin Graesslin wrote: > > > > * which edge to monitor (left/right/top/bottom) > > > > * offset on edge > > > > * length on edge > > > > > > screen #? > > > > very unsure as we need to have a consistent screen numbering and I don't > > think that exists. > > don't we have the screen id's as used in QDesktopWidget and friends? yes, but where does QDesktopWidget get it from? Is it the XRandR id or some internal numbering? The documentation does not state anything and if we want to go for a fdo approach we cannot use an id which is Qt internal ;-) > > would that work with e.g. KRunner registering the top-center area of each > > screen? > > it just means 1 screen edge trigger object per screen, all connected to the > same slot in krunner. so this is absolutely fine good :-) > > > * code of this in SNI > > kde-workspace/statusnotifierwatcher > > > * SNI spec? > > http://www.notmart.org/misc/statusnotifieritem/index.html what an interesting place to keep specifications (even if FDO is unlikely: maybe somewhere on .kde.org?) -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Screen Edge handling in 4.11
On Monday 21 January 2013 12:53:21 Aaron J. Seigo wrote:
> On Monday, January 21, 2013 11:03:53 Martin Gräßlin wrote:
> > The protocol I would suggest is:
> > 1. Application calls D-Bus function in KWin with the following information
>
> imo this should be a new DBus service name (e.g. org.kde.screenedges) with
> an eye of perhaps even getting org.freedesktop.screenedges so that other
> environments / window managers can elect to provide this same service.
>
> kwin could continue to provide it, but i'd like to avoid poking org.kde.kwin
> directly for this service.
fine with me. It would have got a "subdomain" anyway. freedesktop I imagine
will be difficult as it doesn't match the design of GNOME Shell/Unity.
>
> the worst part of this is that we'll be breaking hiding panels with any
> other window manager out there. the original idea was to have this in kded
> (or as a separate process, even, if need be) so that it remained
> independent and have window manager, desktop shell and applications use
> this.
kded is difficult as KWin is interacting very intensely with the edges and
going
to another process would be bad(tm) for that (e.g. when moving a window with
switch desktop when moving windows only, the edges get activated when moving
starts and deactivated on ending)
>
> as for applications using this ... i can't imagine many applications wanting
> to rely on kwin for screen edge features.
>
> > * which edge to monitor (left/right/top/bottom)
> > * offset on edge
> > * length on edge
>
> screen #?
very unsure as we need to have a consistent screen numbering and I don't think
that exists.
>
> we will also want to be able to update the screen edges being monitored. in
> the case where uinique IDs + signals are used, being able to update an
> existing screen edge request ID would be preferred as otherwise a client
> application needs to send 2 dbus calls (both of which are in theory async
> ..)
Fine with me, no problem adding that.
>
> (the same is true of the callback method described below)
>
> > 2. KWin returns a unique identifier for the registered area
> > 3. Whenever this area is triggered, KWin emits a dbus signal with the
> > unique identifier as parameter
>
> another possibility is to do it as we do the system tray: the application
> ("client") registers a dbus callback with the screen edge ("server"). when
> the trigger criterion (screen/edge/offset/length) is met, the server calls
> all the matching callback method.
>
> this has advantages:
>
> * server can monitor client dbus service to know when it goes away
> * instead of emitting a signal to all clients, only the client(s) that
> should be notified will be notified by calling the client callbacks. this
> allows the server to supress the call to some registered clients even if
> they requested that screen edge (use case: panels and full screen windows)
> * applications can remove their dbus service to remove the screen edge
> requests, rather than call into the server directly. this also happens to
> cover the "application quit or crashed" scenario.
> * no tokens to manage (just client-side service names)
>
> if we want to make it so that one client service can handle mulptiple edges,
> then it gets trickier. but if we assert that each screen edge requires its
> own dbus service for callback, then it is quite trivial:
>
> org.kde.screenedges:
> registerTrigger(int screen, int edge, int offset, int length, string
> clientService, string objectPath)
>
> application side:
> screenEdgeEvent()
>
> calls to registerTrigger with the same clientService+objectPath would update
> the geometry for that trigger, so a special call for that is not necessary.
> the objectPath allows multiple triggers in the same application while
> keeping the application api simple (and avoiding having to send any data
> over the bus from the server to the client)
>
> if we want just one client service, however, to handle all requests for a
> single application it becomes trickier...
>
> given that it is unlikely for any given application to have more than a few
> such triggers (even plasma-desktop with multiple screens is unlikely to have
> more than a handful), the one-dbus-object-per-trigger should not result in
> overhead issues.
would that work with e.g. KRunner registering the top-center area of each
screen?
Otherwise I'm fine with that, too. Seems cleaner the way you describe it - I
had thought about it, but kind of preferred the signal approach. But having a
similar approach to SNI sounds reasonable to me. Do you have me pointers to:
* code of this in SNI
* SNI spec?
--
Martin Gräßlin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kwin thumbnail effect in Workspaces 2
On Monday 21 January 2013 12:52:07 Marco Martin wrote: > On Monday 21 January 2013, Martin Graesslin wrote: > > > in QML terms, the perfect solution would be an item than knows the > > > geometry of the thumbnail it will be rendering, and then all of the > > > above problems go away. > > > > > > but if that QML item is not in kwin (something that should be avoided), > > > that implies making information available from kwin about thumbnail > > > sizes for specific windows. > > > > The logic to determine the size of the thumbnail is not very difficult. We > > could provide a QML item (outside KWin) which has the same algorithm > > implemented and annotate code in KWin and the item to keep it in sync. > > > > Not perfect, but better than setting some X properties... > > now more difficult! would be possible to even tell the thumbnail to be > clipped? I'm thinking if one wants to show thumbnails in a scrolling list, > which has not 100% width or height (unlike in active) use Alt+tab with thumbnails and notice that they are clipped in a scrolling list :-) Yes already built-in, should not be difficult to add some properties to make that work. > > (i get it won't be possible to draw on top of it for obvious reasons, but > can live without it) maybe we also find a solution to that problem... -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kwin thumbnail effect in Workspaces 2
On Monday 21 January 2013 12:03:54 Aaron J. Seigo wrote: > On Thursday, January 17, 2013 08:04:14 Martin Gräßlin wrote: > > So my suggestion is to send updates for needed thumbnails together with > > the > > damage events. We have to look into how we can achieve it, but it would > > bring some advantages: > > * existing code path inside KWin can be reused > > * thumbnail is always the latest version > > * no memory read-backs from GPU > > * if thumbnail is not needed (because area is not rendered) it can be > > discarded > > sounds good, particularly as it would keep all the UI interaction in the > host application (e.g. the shell). > > as you noted, it would need to be *fast* as that was one problem we had in > the past with "kwin renders the thumbnails, but the UI is managed in the > host application": the UI would update/change and the thumbnail painting > would be out of sync with it. yes, the information must be available at the same time. It needs to come together with the damage events. That was the problem with the thumbnail effect: updating the property and the rendering where not in sync. > in QML terms, the perfect solution would be an item than knows the geometry > of the thumbnail it will be rendering, and then all of the above problems > go away. > > but if that QML item is not in kwin (something that should be avoided), that > implies making information available from kwin about thumbnail sizes for > specific windows. The logic to determine the size of the thumbnail is not very difficult. We could provide a QML item (outside KWin) which has the same algorithm implemented and annotate code in KWin and the item to keep it in sync. Not perfect, but better than setting some X properties... -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Screen Edge handling in 4.11
On Monday 21 January 2013 11:33:23 Aurélien Gâteau wrote: > Le Monday 21 January 2013 11:03:53 Martin Gräßlin a écrit : > > Hi workspace devs, > > > > I just finished a rewrite of the Screen Edge handling in KWin [1] and now > > I > > want to tackle one of the long standing issues: hidden panel activation. > > For those who do not know the plans first designed years ago: instead of > > Plasma keeping track of where the panel is and reacting on the screen > > edge, we just let KWin handle this edge for Plasma and notify Plasma when > > the Panel should be shown. This brings the advantage that KWin and Plasma > > do not fight over the edge (normally KWin should win, though there are > > hacks to make Plasma win) and there is a consistent user experience on > > how to interact with screen edges. > > > > The new architecture has been implemented in a way to make that possible > > and I have thought about how we can setup a protocol which does not only > > suit the Plasma Panel case but also the Gwenview fullscreen & co cases. > Overall, I like the idea. I assume this should not interfere with > applications which do it the old way (checking the mouse cursor position > over a fullscreen window) see my reply to Marco's mail > > I take it this system will be implemented in a library. Do you plan for a > fallback plan, in case the system is using another window manager? For > example when running on Gnome, Openbox, Windows, Mac OS? I don't have any plans for a library yet and I at the moment cannot see how to have a fallback for GNOME or even Windows or MacOS. I don't know whether foreign systems provide such an API. Let's first add it for Plasma bits and then see whether it is needed for apps at all. In case we go for "no edge triggering if there is fullscreen app", we don't need to provide a lib for apps. -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Screen Edge handling in 4.11
On Monday 21 January 2013 11:27:13 Marco Martin wrote: > so if i understood correctly if two apps register the same area, in case of > triggering both apps will be informed, right? yes > > this looks certainly like an improvement, but maybe not in a specific case.. > what about there is a fullscreen window (regardless it registered for an > edge or not)? in this case the event should be passed only to the > fullscreen window i think? in that case I would propose to not activate the edge if there is currently an active fullscreen window on the screen. So it would not interfere at all. If that's wanted I add some code to it. > > about api, seems sane to me (maybe only thing is that an application can > listen to all activations (even if won't know what the edge is) and decide > to do stuff of such activations (an evil and by purpose misuse, but just > thinking if it couldn't have bad implications) we cannot prevent abuse ;-) > > last thing, more on the look stuff. what about making kwin draw the halo > that is now drawn for panels? so would look the same no matter what app > needs it. Yes I want that, that's why I asked where to find the code of the panel glow :-) -- Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some thoughts on screensavers in Plasma Workspaces 2
On Sunday 13 January 2013 19:48:48 Aaron J. Seigo wrote: > hi .. > > side note 1: i've taken to refering to "future releases of Plasma Worskpaces > that will use Frameworks 5 with libplasma2, Qt 5.1+ and QtQuick2" as Plasma > Workspaces 2 (PW2) inside my head. if anyone has a better idea, speak up > before it becomes a commonly used term :) sounds good to me. In my last mail I referred to it as "Plasma 2". > a) drop xscreensaver support altogether. +1 > c) the current implementation of Widgets-on-screensaver is dropped > completely. it woudl be replaced with a QML containment that also loads the > unlock UI. this could in theory even be provided as a QML component itself > so other unlockers could have widgets. this path means lockers will need to > advertise whether or not they support widgets (default should probably be > "yes" in such a case) +1, keep in mind that currently we don't default to the widgets-on- screensavers due to long loading and high probability of screen locker loads after system comes from suspend to RAM. I hope that the startup time of a shell get's better with PW2 - especially being able to delay loading of elements through a QML LoaderItem and better threading should improve the situation. Nevertheless it has to be a design goal to have more or less instant locking. If the widgets are not loaded I don't care as long as there is at least the background item loaded. > > something else we'll run into: > > the unlock greeter needs to be ported to QML properly. right now and > GreeterItem and KeyboardItem use QGraphicsProxyWidgets and this will break > in QML2 w/scenegraph. that means kxkb needs to provide a proper QML > component and the kgreet plugins in libs/kdm/ will need to turned into QML > bits. the complication there is that kdm uses them as well ... so maybe > some library duplication there, or .. we look at alternatives to kdm. Back when I started to work on this I run into this issue. The keyboard item should not be that difficult but the kgreet plugin will be a nightmare. The complete logic is implemented inside a QWidget. The individual greeters just add further widgets to the base widgets. My fear is that we have to start from a blank sheet of paper and given that it is security related I must say that I don't like it. I'm not sure whether we have any experts on security in the workspaces team? Random thought: we might have a look on whether we can do some re-usage of LightDM greeter bits. Maybe that's easier - David might give input on that. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma and new shadow mess
On Monday 24 December 2012 17:12:22 Weng Xuetian wrote: > I think some action need to be taken before the release, some possible > solutions. > 1. Revert the changes of new plasma air theme, so old shadow can be used. > and try to fix all the things in KDE 4.11 Personal opinion: the change should be reverted, as: a) it was basically a break of public API (yes even if it is not considered public API, the fact that everybody used it, makes it public API) b) there is no need for a break now with KF 5 in front of us, we could have used that to do the break c) it causes unnecessary work for everybody > or 2. get some header exposed to avoid duplication of the code, and fixed > every custom widget, at least including: kwin, kmix, powerdevil, icontasks. at least for KWin I will *not* accept a fix for 4.10. It's too late in the cycle, it cannot be exposed to user testing any more. I rather have a visual regression than the risk of breakage. I would also encourage to not risk anything with the other components which are affected, that late in the cycle. I must say that I am a little bit disappointed by the mess this introduced. It should have been noticed that this breaks even the Plasma styled dialogs of the application which is responsible for rendering the shadows. Best Regards Martin Gräßn ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switch and Checkbox items
On Thursday 13 December 2012 16:41:58 Aaron J. Seigo wrote: > I currently favour the second solution (making Switch a Checkbox on > desktop), +1 Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] New (QML) Desktop Containment
On Monday 10 December 2012 13:51:02 Alex Fiestas wrote: > Maybe we can get some feedback from the forums ? we have to be careful about that. From all I have seen over the last years I think that the toolbox is in the top 3 most hated features all over KDE software. So if we ask the question in the wrong way we only get the haters and not those who use it and like it (nobody is going to reply to a thread if he has the feeling he will be ripped apart). And forums does not reflect our userbase - it has only the users who are interested in KDE and do know that KDE exists in the first place. So overall for this particular question I'm rather sceptical. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Getting started on plasma2
On Friday 07 December 2012 20:16:39 Marco Martin wrote: > I would like people to try to set up the thing, ie have qt5, build > frameworks and try to build the test app. This makes solving the issues > definitely faster :) do we have a wiki page with pointers on how to setup all the bits (links to e.g. docs for building Qt5/frameworks would be fine)? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bug component for lockscreen?
On Saturday 24 November 2012 20:01:53 you wrote: > Product "kscreensaver" has a "locker" component. with bugs going back to 2010 - that's exactly what I meant with I wouldn't reuse the existing product/component as it's for the legacy locker which is still available. I think it should be a dedicated component. Otherwise triaging and fixing bugs will become difficult. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [KDE Bugtracking System] REMINDER: current Plasma regressions
On Monday 02 July 2012 16:02:35 Mark wrote: > On Mon, Jul 2, 2012 at 9:11 AM, Aaron J. Seigo wrote: > > can we have this query changed so that it does not post every single day > > to > > the mailing list but perhaps do it just 1-2 times per week? i'd be happy > > with once per week, tbh.. > > > > thanks :) > > I think mails like this should be depending on the state of the current > release. So while we are in development mode for 4.9 (4.10 as the next one) > the mails don't even need to be send or once a month. > When we enter beta 1 i would say a mail once a week is enough. > Once we enter RC it really should stabilize and the mails should > probably be send a few times a week or once every 3 days or so. During development it would probably best to notify the maintainer of the affected component as soon as quickly - as sooner a regression is spotted the easier it is to fix. That is instead of reminders a single mail would be enough. Right now I agree that once a week would be enough given that everybody could just add the search to the personal saved searches, so that it's just one click away in bugzilla, which you should have open in one browser tab anyway ;-) Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: mailing list disclaimer in every source file
On Monday 02 July 2012 18:16:53 Davide Bettio wrote: > Hello, > > Sometimes it happens that somone writes to me to ask something > releated to plasma development. As a reply I usually point him to the > plasma mailing list, that's not a problem for me but there are some > plasma contributors that are not reachable anymore. > That might be a problem on the communication side so I think that we > should add a notice to every source file after the copyright > disclaimer that states that the best thing to ask anything related to > plasma should be to send a mail to the plasma mailing list. what gives you the feeling that people send you the mail because of the license header in the source code? I ask because I received a mail last week where the user got it through bugzilla. Also more likely than the source code is probably the .desktop file and the about data shown inside the add-widget explorer. If we add some boilerplate to the author list of the license header it would probably (?) break the GPL requirements? On the other hand putting it below is useless as people would not look there. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Windows previews in qml plasmoid?
On Monday 02 July 2012 12:07:08 Michail Vourlakos wrote: > During the day I will upload a video showing the plasmoid in its > current development status > with window previews in the dashboard. If you want I can also upload a > second video > showing the use case you are describing for a proof of concept case. I > dont know why > I havent noticed any serious concerning issues maybe it's my spesific > hardware... I watched the video and I'm not sure whether you have the actual filter activated - it's too fluent. Do not animate the window preview. It is not supported by KWin. If we need to animate it we actually change properties inside KWin to have it with good performance. If you go through the taskbar thumbnails effect KWin cannot know that you actually animate the thumbnail - we have no way to specify that through the API. Animating just the position is fine, but changing the size is the problem. If you want to see that use the Present Windows effect and set the animation speed to very slow to notice it. During the animations the windows look "different" compared to after the animations stopped. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Windows previews in qml plasmoid?
On Monday 02 July 2012 00:09:00 Michail Vourlakos wrote: > In a month I will upload > a video showing my current use case and from so far I havent noticed any > drawbacks with > Plasma::WindowEffects::showWindowThumbnails. I dont know what are the > issues but I havent > noticed any in my implementation so far... I totally believe you that you have not noticed any issues so far. On your hardware you might even never notice it. If you want to see the issues, try the following: put your applet on the desktop, put a few window on top of it, start a video player (and play a video) and run it in not fullscreen and not overlapping the thumbnails in your applet. Now enable the show paint effect (only if you do not suffer of epilepsy) and watch what gets repainted. And please note that rendering the thumbnail is very expensive because we do have a filter on it (if you have Intel graphics you won't notice that because Intel graphics prior to Sandybridge was not able to do this expensive filter). Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Kickoff-QML and classic launcher
Hi all, in case this mail appears twice, please excuse. It seems to me like Akonadi ate my mail :-( given that master is going to open soon, I have been thinking about merging the Kickoff-QML branch to master. Most is done only minor parts are missing except the classic menu. Due to the fact that I had to fix the models first I doubt that the classic menu would compile or work. Now you can imagine that I am not really interested in working on it :-) So a few questions to discuss: * Do I have to provide a working classic menu in order to merge the Kickoff branch? If yes, would a QML port be OK or should I fix the C++ code? * Would it be acceptable to have classic menu broken for some time and do the porting later on? * Would it be acceptable to drop the classic menu completely? This would be more consistent with the general concept of having only one applet per area. Optionally the classic menu could be re-added in Plasma-Addons just like Lancelot. My personal favorite is option 3. What do you think? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
