Re: When should there be a screen brightness OSD?
On Tuesday 21 January 2014 22:55:14 Thomas Pfeiffer wrote: On Tuesday 21 January 2014 22:45:44 Kai Uwe Broulik wrote: Hi, +1 as well! Especially it popping up on session start where the compositor isn't fully ready. :/ So to summarize: - never ever show it when the brightness changes automatically (session start, mouse movement, screen timeout, ...) - if user changes, it show the OSD on the primary/internal monitor as this is probably the affected one When dragging the slider in the battery monitor it shouldn't be shown either, the slider (and the dimming screem, of course) provides the feedback already. Cheers, Kai Uwe +1, that sounds exactly like it should behave! Funny thing, I fixed this behavior in one previous release and then in the next release it regressed, nobody fixed it then. I can take a look and fix it for 4.11.6, it shouldn't be *that* hard. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
Am Freitag, 17. Januar 2014, 18:37:27 schrieb Ivan Čukić: It seems we mostly agree on the Plasma Year Month, and Plasma by KDE* naming, at least in principle. Which is awesome. Considering that we already released official announcements de facto using Plasma (Workspaces) 2 as branding for almost one year[1], I cannot see any positive thing about changing version numbering once again. In addition there were countless blog posts published also through our Planet KDE aggregator using Plasma (Workspaces) 2. You may rightfully argue that Plasma2 is just a codename but since the Dot stories did not write Next generation workspaces, tentatively called Plasma2 in the first sentence of every single article touching that topic, the de facto branding already exists. Using an entirely new versioning is just grist to the mill of all the people who actually believe that following our upstream branding makes no sense in the first place because it'll be changed a few months down the road anyway (a few of them write about FOSS stuff on heise.de). I suggest you guys just use Plasma 2.0, Plasma 2.1, ... People have no problems understanding version numbers as long as they are coherent. Markus [1] http://dot.kde.org/2013/04/24/plasma-pow-wow-produces-detailed-plans-workspace-convergence http://dot.kde.org/2013/09/04/kde-release-structure-evolves http://dot.kde.org/2013/12/09/early-kde-plasma-2-images-now-available http://dot.kde.org/2013/12/20/plasma-2-technology-preview ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: [kde-promo] Plasma Next Naming
On Tuesday 21 January 2014 02:43:04 Markus Slopianka wrote: Am Freitag, 17. Januar 2014, 18:37:27 schrieb Ivan Čukić: It seems we mostly agree on the Plasma Year Month, and Plasma by KDE* naming, at least in principle. Which is awesome. Considering that we already released official announcements de facto using Plasma (Workspaces) 2 as branding for almost one year[1], I cannot see any positive thing about changing version numbering once again. We made it always quite clear that this is a working title - at least it was always quite clear to us. I don't see a reason why we should keep to a working title just because we used it in communication. 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
Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/ --- Review request for Plasma and Martin Klapetek. Repository: kde-workspace Description --- $summary + KDE4Support-- + cleanup Diffs - plasma/generic/dataengines/time/CMakeLists.txt e4aebab plasma/generic/dataengines/time/timeengine.cpp 5155527 Diff: https://git.reviewboard.kde.org/r/115219/diff/ Testing --- compiles, links and tested in plasmaengineexplorer Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115219/#review47994
---
plasma/generic/dataengines/time/timeengine.cpp
https://git.reviewboard.kde.org/r/115219/#comment34003
I think this can be nicer by doing
Q_FOREACH(const QByteArray tz, QTimeZone::availableTimeZoneIds()) {
sources QString(tz.constData());
}
- Martin Klapetek
On Jan. 22, 2014, 12:26 p.m., Bhushan Shah wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115219/
---
(Updated Jan. 22, 2014, 12:26 p.m.)
Review request for Plasma and Martin Klapetek.
Repository: kde-workspace
Description
---
$summary + KDE4Support-- + cleanup
Diffs
-
plasma/generic/dataengines/time/CMakeLists.txt e4aebab
plasma/generic/dataengines/time/timeengine.cpp 5155527
Diff: https://git.reviewboard.kde.org/r/115219/diff/
Testing
---
compiles, links and tested in plasmaengineexplorer
Thanks,
Bhushan Shah
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/ --- (Updated Jan. 22, 2014, 5:06 p.m.) Review request for Plasma and Martin Klapetek. Changes --- fix issues Repository: kde-workspace Description --- $summary + KDE4Support-- + cleanup Diffs (updated) - plasma/generic/dataengines/time/CMakeLists.txt e4aebab plasma/generic/dataengines/time/timeengine.cpp 5155527 Diff: https://git.reviewboard.kde.org/r/115219/diff/ Testing --- compiles, links and tested in plasmaengineexplorer Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/ --- (Updated Jan. 22, 2014, 11:38 a.m.) Status -- This change has been marked as submitted. Review request for Plasma and Martin Klapetek. Repository: kde-workspace Description --- $summary + KDE4Support-- + cleanup Diffs - plasma/generic/dataengines/time/CMakeLists.txt e4aebab plasma/generic/dataengines/time/timeengine.cpp 5155527 Diff: https://git.reviewboard.kde.org/r/115219/diff/ Testing --- compiles, links and tested in plasmaengineexplorer Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/#review47998 --- This review has been submitted with commit 8eb47ae007ca0fc49a378f6a4092e14635ad4451 by Bhushan Shah to branch master. - Commit Hook On Jan. 22, 2014, 11:36 a.m., Bhushan Shah wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/ --- (Updated Jan. 22, 2014, 11:36 a.m.) Review request for Plasma and Martin Klapetek. Repository: kde-workspace Description --- $summary + KDE4Support-- + cleanup Diffs - plasma/generic/dataengines/time/CMakeLists.txt e4aebab plasma/generic/dataengines/time/timeengine.cpp 5155527 Diff: https://git.reviewboard.kde.org/r/115219/diff/ Testing --- compiles, links and tested in plasmaengineexplorer Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115219: Remove KTimeZone usage in time dataengine and port it to QTimeZone
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/#review47999 --- Ship it! Ship It! - Martin Klapetek On Jan. 22, 2014, 12:38 p.m., Bhushan Shah wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115219/ --- (Updated Jan. 22, 2014, 12:38 p.m.) Review request for Plasma and Martin Klapetek. Repository: kde-workspace Description --- $summary + KDE4Support-- + cleanup Diffs - plasma/generic/dataengines/time/CMakeLists.txt e4aebab plasma/generic/dataengines/time/timeengine.cpp 5155527 Diff: https://git.reviewboard.kde.org/r/115219/diff/ Testing --- compiles, links and tested in plasmaengineexplorer Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Applet component, current status
Hi all,
I have a now basic working Applet (and Containment) component on the branch
mart/AppletComponent of plasma-framework
to test it, it needs a branch of the same name in kde-workspace and plasmate.
since there is exactly one applet (compactrepresentation in examples) and one
containment (desktop) ported to it, it works only in plasmoidviewer for now.
plasmoidviewer -a org.kde.example.compactrepresentation
the code is still quite rough, since appletinterface and containment interface
(that are now qml imports) still contain a ton of cruft that should be washed
out.
the components are applet and Containment, right now in the org.kde.shell
import. (needed a separate one since it still lives in the scriptengine .so,
it may be transferred to plasmacore in the future)
I would like to ask people to try it and find eventual issues, since i'm still
not convinced by it. issues may be.
* significant regressions compared to current master?
* how hard is to port all plasmoids? can it cause unwanted delays in the
release?
* how this affects the systray? makes its implementation harder or easier? (+:
no more duplicate appletInterface, -: a pointer to an applet() is needed and
may be necessary to implement systray specific workarounds in the component
itself)
* are people comfortable with the api on plasmoid side?
Main things i don't like are:
* The applet component is completely meaningless if used in any other context
than the root object of a plasmoid
* For a containment, you'll have to explicitly use the Containment object
instead of Applet: using an Applet will work, but no containment specific api
will be accessible (and no plasmoid in the containment visible). while using
Containment when is a normal applet, it will work (and it should,since
containment may be applets) but all the containment specific api witll be just
dead and not working
* declaration of containments is really odd, that's the new main.qml of the
desktop containment:
import QtQuick 2.0
import org.kde.plasma.core 2.0 as PlasmaCore
import org.kde.plasma.shell 2.0
Containment {
id: root
fullRepresentation: FullRepresentation {}
}
while FullRepresentation.qml is the old main.qml .. this kindof screams of
boilerplate ;)
All in all, even if i'm not sure this branch is the definite way to go, there
are some things that i'm quite sure are:
* use the Layout attached property for size hints in applets: it's an
official
api for it so familiar to 3rd party qml developers and easy to propagate from
RowLayouts, gridLayouts etc, getting rid of minimumWidth etc properties
* propagate the Layout sizehints to the plasmacore.Dialog's QWindow
minimum/maximum sizes (still not done, will enhance behavior of stuff
dramatically)
* have the size in which we switch representation independent from it, like
switchWidth/switchHeight, if not specified, keep a fixed representation based
on
formfactors (full on desktops, iconified on panels)
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 3:03 PM, Markus Slopianka kamika...@gmx.de wrote: Am Mittwoch, 22. Januar 2014, 10:56:02 schrieb Martin Gräßlin: We made it always quite clear that this is a working title No, you didn't. *I* know that it was meant to be a working title but it was not always made clear in public communication. Mistakes happen. But what's preventing us on publishing another article stating what the new version will be? And/or putting a special paragraph to alpha/beta announcement, clearly stating we're dropping the working name and switch to new version naming. That should just work, right? Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
Hi, [please keep plasma-devel cq. kde-promo in CC:] On Wednesday, January 22, 2014 15:03:20 Markus Slopianka wrote: Am Mittwoch, 22. Januar 2014, 10:56:02 schrieb Martin Gräßlin: We made it always quite clear that this is a working title No, you didn't. *I* know that it was meant to be a working title but it was not always made clear in public communication. You know, an incomplete quote is not going to help in this discussion: Martin wrote: We made it always quite clear that this is a working title - at least it was always quite clear to us. The latter part is highly relevant here. Maybe removing it makes it easier to get your point across, but accuracy is quite important as well. Quite frankly I cannot understand how you could have read my mail, which includes links to four articles, and still claim that the working title disclaimer has always been put in them... To me, it was always clear that it's a working title. Besides, out of 4 articles you link to, two don't even have Plasma 2 in them (there's Plasma Workspaces 2, which we don't want for other reasons). Most importantly: We are free to change the name, and given there are good reasons for it, and we haven't invested a lot in Plasma 2 as a name, to me it's completely fine. In the professional world, the final name is almost never the same as the working title, it even can give some extra boost to the actual release. Bottom line: we can go on discussing this for ages, what we need is a decision (which we've proposed, and which has been further refined). Taking a few steps back and going over the same discussion again is not going to get any work done, it's just hindering. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 115224: Remove unused property drawWallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/#review48028 --- well, actually ContainmentInterface of the qml scruiptengine does use it, to store wether loading and draw a wallpaper or not. The issue is to keep it in Containment, or having it only in ContaimentInterface. Either choice is fine with me... Personally i would limit the amount of api that is only in containmentinterface and not containment (basically the concept now is that Applet and Containment are models for appletintterface/containmentinterface) - Marco Martin On Jan. 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 2:24 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
On Jan. 22, 2014, 2:32 p.m., Marco Martin wrote: well, actually ContainmentInterface of the qml scruiptengine does use it, to store wether loading and draw a wallpaper or not. The issue is to keep it in Containment, or having it only in ContaimentInterface. Either choice is fine with me... Personally i would limit the amount of api that is only in containmentinterface and not containment (basically the concept now is that Applet and Containment are models for appletintterface/containmentinterface) Sebastian Kügler wrote: I agree. appletinterface and containmentinterface should stay as small as possible and only have things in there that are specific for the QtQuick implementation. That reduces boilerplate and keeps Plasma::Applet and Plasma::Containment useful. David Edmundson wrote: Why would a containment not want to draw a wallpaper? depends from the shell's decision, not really from the containment itself, for instance panels are containments but won't have wallpapers. also, if the dashboard with own containment feature is kept or will return, it would be a normal desktop containment but wothout a wallpaper. - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/#review48028 --- On Jan. 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 2:24 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
On Jan. 22, 2014, 2:32 p.m., Marco Martin wrote: well, actually ContainmentInterface of the qml scruiptengine does use it, to store wether loading and draw a wallpaper or not. The issue is to keep it in Containment, or having it only in ContaimentInterface. Either choice is fine with me... Personally i would limit the amount of api that is only in containmentinterface and not containment (basically the concept now is that Applet and Containment are models for appletintterface/containmentinterface) Sebastian Kügler wrote: I agree. appletinterface and containmentinterface should stay as small as possible and only have things in there that are specific for the QtQuick implementation. That reduces boilerplate and keeps Plasma::Applet and Plasma::Containment useful. Why would a containment not want to draw a wallpaper? - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/#review48028 --- On Jan. 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 2:24 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
On Jan. 22, 2014, 2:32 p.m., Marco Martin wrote: well, actually ContainmentInterface of the qml scruiptengine does use it, to store wether loading and draw a wallpaper or not. The issue is to keep it in Containment, or having it only in ContaimentInterface. Either choice is fine with me... Personally i would limit the amount of api that is only in containmentinterface and not containment (basically the concept now is that Applet and Containment are models for appletintterface/containmentinterface) Sebastian Kügler wrote: I agree. appletinterface and containmentinterface should stay as small as possible and only have things in there that are specific for the QtQuick implementation. That reduces boilerplate and keeps Plasma::Applet and Plasma::Containment useful. David Edmundson wrote: Why would a containment not want to draw a wallpaper? Marco Martin wrote: depends from the shell's decision, not really from the containment itself, for instance panels are containments but won't have wallpapers. also, if the dashboard with own containment feature is kept or will return, it would be a normal desktop containment but wothout a wallpaper. OK, thanks. I'll restore it in the containment interface and make it a private bool there. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/#review48028 --- On Jan. 22, 2014, 2:24 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 2:24 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 4:54 p.m.) Review request for Plasma. Changes --- depends from the shell's decision, not really from the containment itself, for instance panels are containments but won't have wallpapers. We may as well move that in here then. That logic was in plasma view, where we altered a property on the root object which we then use in loadWallpaper(); also, if the dashboard with own containment feature is kept or will return, it would be a normal desktop containment but wothout a wallpaper. containment-setWallpaper(QString()); will remove it. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs (updated) - src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 3:13 PM, Sebastian Kügler se...@kde.org wrote: Hi, [please keep plasma-devel cq. kde-promo in CC:] On Wednesday, January 22, 2014 15:03:20 Markus Slopianka wrote: Am Mittwoch, 22. Januar 2014, 10:56:02 schrieb Martin Gräßlin: We made it always quite clear that this is a working title No, you didn't. *I* know that it was meant to be a working title but it was not always made clear in public communication. You know, an incomplete quote is not going to help in this discussion: Martin wrote: We made it always quite clear that this is a working title - at least it was always quite clear to us. The latter part is highly relevant here. Maybe removing it makes it easier to get your point across, but accuracy is quite important as well. Quite frankly I cannot understand how you could have read my mail, which includes links to four articles, and still claim that the working title disclaimer has always been put in them... To me, it was always clear that it's a working title. Besides, out of 4 articles you link to, two don't even have Plasma 2 in them (there's Plasma Workspaces 2, which we don't want for other reasons). Most importantly: We are free to change the name, and given there are good reasons for it, and we haven't invested a lot in Plasma 2 as a name, to me it's completely fine. In the professional world, the final name is almost never the same as the working title, it even can give some extra boost to the actual release. Bottom line: we can go on discussing this for ages, what we need is a decision (which we've proposed, and which has been further refined). Taking a few steps back and going over the same discussion again is not going to get any work done, it's just hindering. It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Splitting kde-workspace and kde-runtime proposal
On Tuesday 21 January 2014 12:05:26 Antonis Tsiapaliokas wrote: 1) Create two different groups named plasma-workspace and plasma-desktop like frameworks 2) Split out every component into individual repos 3) Assign repos to the related group. Advantages: 1) Easy to assign maintainer to individual component. 2) If we split only some repos, we can not mark it as part of workspace but this way we can do it. 3) More, may be? That's my humble suggestion. :) Again, this is a proposal so please! send any feedback you might have. Thanks! I think that splitting each individual component to its own repo might be a bit confusing. Because if we don't have two groups (plasma-desktop and plasma- workspace), then we will not be able to provide something as a standard solution. So each person will consider Plasma Desktop as something entirely different. Note however that it's not a proper argument for splitting repos or not since nowadays our infrastructure has the concept of grouping independently of the repos. So we could split in their own repo and still have a way to make a plasma-desktop and a plasma-workspace group. OTOH Sebas argument is much more compelling. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 115224: Remove unused property drawWallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/#review48066 --- Ship it! since adding api is easy as opposed to removing, this can be tried, and the api reintroduced if we'll need it - Marco Martin On Jan. 22, 2014, 4:54 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115224/ --- (Updated Jan. 22, 2014, 4:54 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Remove unused property drawWallpaper As suggested here: http://community.kde.org/Plasma/libplasma2/API_Review/Containment kde-workspace doesn't use it. Diffs - src/plasma/containment.h 1d747c6 src/plasma/containment.cpp 590402a src/plasma/corona.cpp 9a937b0 src/plasma/private/containment_p.h 597f26e src/plasma/scripting/appletscript.h 65301d4 src/plasma/scripting/appletscript.cpp cb9df7d src/plasmaquick/plasmaquickview.cpp 03fe00e src/scriptengines/qml/plasmoid/containmentinterface.h 0ed5868 src/scriptengines/qml/plasmoid/containmentinterface.cpp 23edb67 Diff: https://git.reviewboard.kde.org/r/115224/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On 01/22/2014 09:13 AM, Sebastian Kügler wrote: Hi, [please keep plasma-devel cq. kde-promo in CC:] On Wednesday, January 22, 2014 15:03:20 Markus Slopianka wrote: Am Mittwoch, 22. Januar 2014, 10:56:02 schrieb Martin Gräßlin: We made it always quite clear that this is a working title No, you didn't. *I* know that it was meant to be a working title but it was not always made clear in public communication. You know, an incomplete quote is not going to help in this discussion: Martin wrote: We made it always quite clear that this is a working title - at least it was always quite clear to us. The latter part is highly relevant here. Maybe removing it makes it easier to get your point across, but accuracy is quite important as well. Quite frankly I cannot understand how you could have read my mail, which includes links to four articles, and still claim that the working title disclaimer has always been put in them... To me, it was always clear that it's a working title. Besides, out of 4 articles you link to, two don't even have Plasma 2 in them (there's Plasma Workspaces 2, which we don't want for other reasons). Most importantly: We are free to change the name, and given there are good reasons for it, and we haven't invested a lot in Plasma 2 as a name, to me it's completely fine. In the professional world, the final name is almost never the same as the working title, it even can give some extra boost to the actual release. Bottom line: we can go on discussing this for ages, what we need is a decision (which we've proposed, and which has been further refined). Taking a few steps back and going over the same discussion again is not going to get any work done, it's just hindering. Cheers, Plasma (by KDE) is the user-visible brand. Whether it is the fourth update to the 2014 release is technical to me. I'm a user of the KDE software product. I'm impressed with the underlying technologies, but engage with them mainly because they become available in my distribution upgrade channels. I get to benefit when the changes are positive and am occasionally bothered when some sort of glitch shows up. Plasma, with a turbo boost, semi-hemi engine or whatever. The extra information is marketing which might make me seek out the software. Version numbers are informational, indicating the maturity of a particular installation. With backports, etc. even that can become confused. But KDE's latest update of Plasma is available today for your computer, your laptop, your tablet, your smart-wrist-bangel...Look for it in your favorite distribution soon. Adding the details for the excitement and education of users comes next. Good luck. Keep the good work coming. I love the stuff I can do with my Plasma powered laptop (thanks to the hard work of the KDE community). --Algot -- - Algot Runeman algot.rune...@verizon.net Web Site: http://www.runeman.org Twitter: http://twitter.com/algotruneman/ Open Source Blog: http://mosssig.wordpress.com MOSS SIG Mailing List: http://groups.google.com/group/mosssig2 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 6:05 PM, Mark Gaiser mark...@gmail.com wrote: It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. So suddenly entirely dropping de facto (public) names is not that uncommon in our area and I personally think it's not unreasonable to drop working names either. Think of it as developers working with some name because they need to call it somehow, then when they are done, the marketing phase starts and the marketing people think of a new name for it. And we could sell the new name exactly like this - Unveiling the final Plasma by KDE, done. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 6:24 PM, Martin Klapetek martin.klape...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:05 PM, Mark Gaiser mark...@gmail.com wrote: It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. The comparison isn't fair. The name change from Longhorn to Vista had cost Microsoft billions! Literally. The change from Vienna to 7 wasn't that big of a deal since it was already mostly known as windows 7 before it became the official name. Big company's can pull these stunts. They have the marketing budget. We - KDE - can't pull that stunt. There is no marketing capital like those big company's have. We need to slowly build momentum starting from the very first blog about a new piece of software and sticking to it's name or change it slightly. But the general structure should remain the same i think. So suddenly entirely dropping de facto (public) names is not that uncommon in our area and I personally think it's not unreasonable to drop working names either. Think of it as developers working with some name because they need to call it somehow, then when they are done, the marketing phase starts and the marketing people think of a new name for it. And we could sell the new name exactly like this - Unveiling the final Plasma by KDE, done. Cheers -- Martin Klapetek | KDE Developer ___ 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: [kde-promo] Plasma Next Naming
On Wednesday 22 January 2014 19:29:24 Mark Gaiser wrote: On Wed, Jan 22, 2014 at 6:24 PM, Martin Klapetek martin.klape...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:05 PM, Mark Gaiser mark...@gmail.com wrote: It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. The comparison isn't fair. The name change from Longhorn to Vista had cost Microsoft billions! Literally. The change from Vienna to 7 wasn't that big of a deal since it was already mostly known as windows 7 before it became the official name. I think this comparison is fair and I had it already written in my reply to Markus (removed it as I don't like referring to the competition). Btw. how do you know that it cost Microsoft billions? AFAIK normal users didn't know that the next version was called Longhorn in the development. We shouldn't expect that we as a group of engineers know these names, means that anybody else knows the name. The comparison is fair as it shows that it is a normal thing in IT development to rename the working title once the software goes into production. Big company's can pull these stunts. They have the marketing budget. We - KDE - can't pull that stunt. There is no marketing capital like those big company's have. We need to slowly build momentum starting from the very first blog about a new piece of software and sticking to it's name or change it slightly. But the general structure should remain the same i think. That's just not realistic to assume that we can get the name of the product before we start developing. Should we not blog about our process just because we haven't named it yet? We work in an environment where our development process is extremely open. We have to work with that and make the best out of it and not stick our head in the sand and say that it's already too late. We are not driven by Phoronix reporting everything we do. Following this we are not allowed to change the version number for KWin, right - it has to be 5, /5 or next which I used in the blog posts? Or what about giving KWin/Wayland a different name? All not possible because I already blogged about it before talking to the marketing team? That doesn't make sense, marketing comes last. 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: [kde-promo] Plasma Next Naming
On Wednesday 22 January 2014 19:29:24 Mark Gaiser wrote: Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. The comparison isn't fair. The name change from Longhorn to Vista had cost Microsoft billions! Literally. The change from Vienna to 7 wasn't that big of a deal since not that the fact that vista sucked had anything to do with the name.. they always did it btw, their most successful release ever was named whistler until days before the release, not that anybody cared or most people even knew the codename of xp... -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 7:46 PM, Martin Graesslin mgraess...@kde.org wrote: On Wednesday 22 January 2014 19:29:24 Mark Gaiser wrote: On Wed, Jan 22, 2014 at 6:24 PM, Martin Klapetek martin.klape...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:05 PM, Mark Gaiser mark...@gmail.com wrote: It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. The comparison isn't fair. The name change from Longhorn to Vista had cost Microsoft billions! Literally. The change from Vienna to 7 wasn't that big of a deal since it was already mostly known as windows 7 before it became the official name. I think this comparison is fair and I had it already written in my reply to Markus (removed it as I don't like referring to the competition). Btw. how do you know that it cost Microsoft billions? AFAIK normal users didn't know that the next version was called Longhorn in the development. We shouldn't expect that we as a group of engineers know these names, means that anybody else knows the name. I can't find raw numbers on windows 7, but remember an article where a number in billions (1.7?) was named. I could find one from Windows Phone 7 which is 1 billion http://techcrunch.com/2010/08/26/microsoft-half-billion-dollars-windows-phone-7/ However, only 500 million was for marketing in that article. The comparison is fair as it shows that it is a normal thing in IT development to rename the working title once the software goes into production. Big company's can pull these stunts. They have the marketing budget. We - KDE - can't pull that stunt. There is no marketing capital like those big company's have. We need to slowly build momentum starting from the very first blog about a new piece of software and sticking to it's name or change it slightly. But the general structure should remain the same i think. That's just not realistic to assume that we can get the name of the product before we start developing. Should we not blog about our process just because we haven't named it yet? We work in an environment where our development process is extremely open. We have to work with that and make the best out of it and not stick our head in the sand and say that it's already too late. We are not driven by Phoronix reporting everything we do. Do you really have to pull in Phoronix? That makes no sense. Following this we are not allowed to change the version number for KWin, right - it has to be 5, /5 or next which I used in the blog posts? Or what about giving KWin/Wayland a different name? All not possible because I already blogged about it before talking to the marketing team? That doesn't make sense, marketing comes last. For what it's worth. I don't give a thing about marketing value behind a name for marketing purposes. If i pick a name i want one with a meaning to me. For example my QML file browser Accretion. At that time it looked like a awesome name since i only looked at one meaning that fitted my reasoning very well. Recently i have learned that it might have more negative then positive meanings so i probably have to figure out a new name for that. That sucks hard, but isn't that big a deal since nearly nobody is using it (it's unusable anyway). Thus i'm in a different position. But for well settled names it makes no sense to drastically change it. Which is about to happen for Plasma. For you - for KWin - there isn't an issue. KWin is a well established name and you only increase the version number. That's how it should be done imho. In my opinion a new name should be chosen when you make a completely new project. Like the new name of Nepomuk: Baloo. It's worth it because it's entirely different. Apparently my view on these things is wildly different then most other people in this thread. That is also the beauty in KDE. We can openly discuss this. I'm a minority with just a few others agreeing. I have no roots in plasma, just an opinion. I think my point is clear (and not shared by many others). So be it, no harm taken :) Just out of curiosity, what is the final naming conclusion for the next plasma version now? A
Re: [kde-promo] Plasma Next Naming
Mark, You pointed out that not everybody is happy with this. That is fair and probably true. But is it relevant? Consensus does not mean everybody agrees. It doesn't even have to mean everybody is happy. That is simply not always possible in a community. It means you're willing to step out of the way of making a decision to not block the process. That does not mean 'admitting defeat' or anything like that. More like a realization that at some point, 'perfect' is the enemy of good. Now I (nor, clearly, sebas, the martins and others) want to FORCE this issue. If we did, they wouldn't continue to discuss with you. Your input is considered valuable, otherwise it would have been ignored. So don't think that this is meant to be a power play. And for sure, if you are certain that this will destroy plasma, KDE and Open Source, you can and SHOULD continue to try and turn this decision around. I just think that you can agree that that is not the case; nor does it seem likely that you can sway the opinions of everybody who cared enough to discuss it. And expect the silent majority to either agree with the proposal or not care. There is little point to the discussion. Anyway, not trying to slap you here, just trying to friendly ask you to think deep about the value of more discussion. (and I would have send this privately if I didn't know you well enough that I think you won't be offended and I think this might be valuable for some lurkers on the list) Boatload of hugs, Jos On Wednesday 22 January 2014 20:29:33 Mark Gaiser wrote: On Wed, Jan 22, 2014 at 7:46 PM, Martin Graesslin mgraess...@kde.org wrote: On Wednesday 22 January 2014 19:29:24 Mark Gaiser wrote: On Wed, Jan 22, 2014 at 6:24 PM, Martin Klapetek martin.klape...@gmail.com wrote: On Wed, Jan 22, 2014 at 6:05 PM, Mark Gaiser mark...@gmail.com wrote: It just shows that not everyone is happy with the initial proposal. The next version of plasma has always been made public under the names: - PW2 - Plasma Workpaces 2 - Plasma 2 Yes, we right now have Plasma 4.xx We call it Plasma. We hardly ever put a version behind it. I really think it makes perfect sense to just call it Plasma 2. It's very much in the direction you folks (those blogging about plasma) have always named it. To me it just doesn't make much sense to suddenly entirely drop that de facto new name for Plasma June/2014 or Plasma Angelfish date or whatever the order is. Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. The comparison isn't fair. The name change from Longhorn to Vista had cost Microsoft billions! Literally. The change from Vienna to 7 wasn't that big of a deal since it was already mostly known as windows 7 before it became the official name. I think this comparison is fair and I had it already written in my reply to Markus (removed it as I don't like referring to the competition). Btw. how do you know that it cost Microsoft billions? AFAIK normal users didn't know that the next version was called Longhorn in the development. We shouldn't expect that we as a group of engineers know these names, means that anybody else knows the name. I can't find raw numbers on windows 7, but remember an article where a number in billions (1.7?) was named. I could find one from Windows Phone 7 which is 1 billion http://techcrunch.com/2010/08/26/microsoft-half-billion-dollars-windows-phon e-7/ However, only 500 million was for marketing in that article. The comparison is fair as it shows that it is a normal thing in IT development to rename the working title once the software goes into production. Big company's can pull these stunts. They have the marketing budget. We - KDE - can't pull that stunt. There is no marketing capital like those big company's have. We need to slowly build momentum starting from the very first blog about a new piece of software and sticking to it's name or change it slightly. But the general structure should remain the same i think. That's just not realistic to assume that we can get the name of the product before we start developing. Should we not blog about our process just because we haven't named it yet? We work in an environment where our development process is extremely open. We have to work with that and make the best out of it and not stick our head in the sand and say that it's already too late. We are not driven by Phoronix reporting everything we do. Do you really have to pull in Phoronix? That makes no sense. Following this we are not allowed to change the version number for KWin, right - it has to be 5, /5 or next
Re: [kde-promo] Plasma Next Naming
On Wed, Jan 22, 2014 at 9:38 PM, Jos Poortvliet jospoortvl...@gmail.com wrote: Mark, You pointed out that not everybody is happy with this. That is fair and probably true. But is it relevant? Consensus does not mean everybody agrees. It doesn't even have to mean everybody is happy. That is simply not always possible in a community. It means you're willing to step out of the way of making a decision to not block the process. That does not mean 'admitting defeat' or anything like that. More like a realization that at some point, 'perfect' is the enemy of good. Now I (nor, clearly, sebas, the martins and others) want to FORCE this issue. If we did, they wouldn't continue to discuss with you. Your input is considered valuable, otherwise it would have been ignored. So don't think that this is meant to be a power play. And for sure, if you are certain that this will destroy plasma, KDE and Open Source, you can and SHOULD continue to try and turn this decision around. I just think that you can agree that that is not the case; nor does it seem likely that you can sway the opinions of everybody who cared enough to discuss it. And expect the silent majority to either agree with the proposal or not care. There is little point to the discussion. Anyway, not trying to slap you here, just trying to friendly ask you to think deep about the value of more discussion. (and I would have send this privately if I didn't know you well enough that I think you won't be offended and I think this might be valuable for some lurkers on the list) Boatload of hugs, Jos I know. My last mail was meant as a conclusion. Ending with: I think my point is clear (and not shared by many others). So be it, no harm taken :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
find_package(KActivities) in Plasma Framework
Hi, I see that CMakeLists.cmake in plasma-framework has find_package(KActivities 5.0.0 CONFIG REQUIRED) and I assume 5.0.0 there means find the framework version, but the KDE4 version of KActivites is actually 6.2.0 which is OK for that find_package so when I tried building plasma-framework withouth kde-kactivities, it picked my KDE4 version. Is this a known issue and are there any plans to fix this? One possible fix would be renaming the frameworks version. David E. Narvaez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
