plasma theme documentation junior job?
hi :) would anyone like to go through this page: http://techbase.kde.org/Projects/Plasma/Theme and compare it against kdebase/runtime/desktoptheme/default/? it doesn't take a coder, just someone with kdebase and inkscape :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
KDE/kdebase/workspace/plasma/generic/applets/battery
SVN commit 1054869 by sebas:
Re-enable the hidden config option to show the remaining time in the battery
applet
You can enable showing the remaining time in your plasma-desktop-appletsrc (or
plasma-netbook-appletsrc), locate the section for the "battery" plugin and add
"showRemainingTime=true" on a new line. Make sure you're not editing the section
for the battery's extenderitem, but the battery itself.) In my config, this
looks like:
[Containments][3][Applets][7][Configuration][Applets][30]
geometry=140,2.5,30,24
immutability=1
plugin=battery
zvalue=0
[Containments][3][Applets][7][Configuration][Applets][30][Configuration]
Share=false
showBatteryString=false
showRemainingTime=true
(Obviously, the last line is relevant.)
We're not offering this as an option in the GUI since this information is,
for a lot of users not reliable enough. The label for the time remaining
option is disabled for now since I couldn't re-use the existing string.
Should be uncommented once 4.5 opens.
I hope we can all be happy now :)
CCMAIL:plasma-devel@kde.org
M +48 -46battery.cpp
M +2 -0 battery.h
--- trunk/KDE/kdebase/workspace/plasma/generic/applets/battery/battery.cpp
#1054868:1054869
@@ -390,6 +390,15 @@
m_controlsLayout->addItem(m_acInfoLabel, row, 1);
row++;
+m_remainingTimeLabel = new Plasma::Label(controls);
+m_remainingTimeLabel->setAlignment(Qt::AlignRight);
+//m_remainingTimeLabel->setText(i18nc("Label for remaining time",
"Time Remaining:"));
+m_remainingInfoLabel = new Plasma::Label(controls);
+m_remainingInfoLabel->nativeWidget()->setWordWrap(false);
+m_controlsLayout->addItem(m_remainingTimeLabel, row, 0);
+m_controlsLayout->addItem(m_remainingInfoLabel, row, 1);
+row++;
+
Battery *m_extenderApplet =
static_cast(Plasma::Applet::load("battery"));
int s = 64;
if (m_extenderApplet) {
@@ -536,58 +545,40 @@
if (m_numOfBattery && m_batteryLabelLabel) {
QHashIterator >
battery_data(m_batteries_data);
int bnum = 0;
+QString state;
while (battery_data.hasNext()) {
bnum++;
battery_data.next();
-QString state = battery_data.value()["State"].toString();
-m_remainingMSecs = battery_data.value()["Remaining msec"].toInt();
-//kDebug() << "time left:" << m_remainingMSecs;
-/*
-if (state == "Discharging" && m_remainingMSecs > 0 &&
m_showRemainingTime) {
-
-// FIXME: Somehow, m_extenderApplet is null here, so the label
never becomes visible
-if (m_extenderApplet) {
-m_extenderApplet->showBatteryLabel(true);
-}
-// we don't have too much accuracy so only give hours and
minutes
-batteryLabelText.append(i18n("Time remaining: %1", KGlobal::locale()->prettyFormatDuration(m_remainingMSecs)));
-} else {
-*/
-//if (m_extenderApplet) {
-//m_extenderApplet->showBatteryLabel(false);
-//}
-if (m_numOfBattery == 0) {
-//kDebug() << "zero batteries ...";
-} else if (m_numOfBattery == 1) {
-m_batteryLabelLabel->setText(i18n("Battery:"));
-if (battery_data.value()["Plugged in"].toBool()) {
-if (state == "NoCharge") {
-m_batteryInfoLabel->setText(i18n("%1% (charged)",
battery_data.value()["Percent"].toString()));
-} else if (state == "Discharging") {
-m_batteryInfoLabel->setText(i18nc("Shown when a
time estimate is not available", "%1% (discharging)\n",
battery_data.value()["Percent"].toString()));
-} else {
-m_batteryInfoLabel->setText(i18n("%1% (charging)",
battery_data.value()["Percent"].toString()));
-}
-} else {
-m_batteryInfoLabel->setText(i18nc("Battery is not
plugged in", "Not present"));
-}
-} else {
-//kDebug() << "More batteries ...";
-// FIXME: we're overwriting the text
-if (bnum > 1) {
-batteriesLabel.append("");
-batteriesInfo.append("");
-}
-batteriesLabel.append(i18nc("Placeholder is the battery
ID", "Battery %1: ", bnum));
+state = battery_data.value()["State"].toString();
+if (m_numOfBattery == 1) {
+m_batteryLabelLabel->setText(i18n("Battery:"));
+if (battery_data.value()["Plugged in"].toBool()) {
if (state == "NoCharge") {
-batteriesInfo.append(i18n("%1% (charged)",
battery_data.value()["Perc
Re: Review Request: Add a tooltip to battery monitor applet
On November 26, 2009, Sebastian Kügler wrote: > Should I commit this one? sure. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Add a tooltip to battery monitor applet
On Thursday 26 November 2009 18:01:19 Aaron J. Seigo wrote:
> On November 26, 2009, Kåre Särs wrote:
> > I also thought about extragear/base/plasma/applets/, but that one is
> > empty (dead?).
>
> anything that you wish to package, ship and support can go into extragear
> (and yes, we do need to open a plasma module in extragear again). a forked
> version won't happen in addons, however. i mean, really, two battery
> monitors in the default packages?
>
> in this particular case, i'm ok with a hidden config option. usually i
> really dislike these things, but it's trivial, will get this issue off my
> back and will be a nice example later on for why hidden config options do
> or don't work.
Here's a patch that re-enables this option, with the hidden config option
"showRemainingTime=true". I've commented out the i18n for the label since we're
in
string freeze.
It basically moves around a bit of code I had disabled temporarily when I
reworked
the layout of the popup and adapts to the better alignment. No tooltip in
there,
however.
Should I commit this one?
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
diff --git a/workspace/plasma/generic/applets/battery/battery.cpp b/workspace/plasma/generic/applets/battery/battery.cpp
index 23c..538237b 100644
--- a/workspace/plasma/generic/applets/battery/battery.cpp
+++ b/workspace/plasma/generic/applets/battery/battery.cpp
@@ -390,6 +390,15 @@ void Battery::initExtenderItem(Plasma::ExtenderItem *item)
m_controlsLayout->addItem(m_acInfoLabel, row, 1);
row++;
+m_remainingTimeLabel = new Plasma::Label(controls);
+m_remainingTimeLabel->setAlignment(Qt::AlignRight);
+//m_remainingTimeLabel->setText(i18nc("Label for remaining time", "Time Remaining:"));
+m_remainingInfoLabel = new Plasma::Label(controls);
+m_remainingInfoLabel->nativeWidget()->setWordWrap(false);
+m_controlsLayout->addItem(m_remainingTimeLabel, row, 0);
+m_controlsLayout->addItem(m_remainingInfoLabel, row, 1);
+row++;
+
Battery *m_extenderApplet = static_cast(Plasma::Applet::load("battery"));
int s = 64;
if (m_extenderApplet) {
@@ -536,58 +545,40 @@ void Battery::updateStatus()
if (m_numOfBattery && m_batteryLabelLabel) {
QHashIterator > battery_data(m_batteries_data);
int bnum = 0;
+QString state;
while (battery_data.hasNext()) {
bnum++;
battery_data.next();
-QString state = battery_data.value()["State"].toString();
-m_remainingMSecs = battery_data.value()["Remaining msec"].toInt();
-//kDebug() << "time left:" << m_remainingMSecs;
-/*
-if (state == "Discharging" && m_remainingMSecs > 0 && m_showRemainingTime) {
-
-// FIXME: Somehow, m_extenderApplet is null here, so the label never becomes visible
-if (m_extenderApplet) {
-m_extenderApplet->showBatteryLabel(true);
-}
-// we don't have too much accuracy so only give hours and minutes
-batteryLabelText.append(i18n("Time remaining: %1", KGlobal::locale()->prettyFormatDuration(m_remainingMSecs)));
-} else {
-*/
-//if (m_extenderApplet) {
-//m_extenderApplet->showBatteryLabel(false);
-//}
-if (m_numOfBattery == 0) {
-//kDebug() << "zero batteries ...";
-} else if (m_numOfBattery == 1) {
-m_batteryLabelLabel->setText(i18n("Battery:"));
-if (battery_data.value()["Plugged in"].toBool()) {
-if (state == "NoCharge") {
-m_batteryInfoLabel->setText(i18n("%1% (charged)", battery_data.value()["Percent"].toString()));
-} else if (state == "Discharging") {
-m_batteryInfoLabel->setText(i18nc("Shown when a time estimate is not available", "%1% (discharging)\n", battery_data.value()["Percent"].toString()));
-} else {
-m_batteryInfoLabel->setText(i18n("%1% (charging)", battery_data.value()["Percent"].toString()));
-}
-} else {
-m_batteryInfoLabel->setText(i18nc("Battery is not plugged in", "Not present"));
-}
-} else {
-//kDebug() << "More batteries ...";
-// FIXME: we're overwriting the text
-if (bnum > 1) {
-batteriesLabel.append("");
-batteriesInfo.append("");
-}
-batteriesLabel.append(i18nc("Placeholder is the battery ID", "Battery %1: ", bnum));
+state = battery_data.value()["State"].toString();
+if (
Re: microblog kubuntu patch
On November 26, 2009, Sebastian Kügler wrote: > On Thursday 26 November 2009 18:28:50 Aaron J. Seigo wrote: > > On November 26, 2009, Marco Martin wrote: > > > I think there should be a global identity configurator in kde where > > > you set the various accounts, from email to identica, then a microblog > > > applet could be added with those credentials > > > > that's being worked on as part of the open social work Frank is > > sponsoring. > > Good to know, a "web identity" configuration is also planned as part of > Silk. Should talk to Frank more ... :) i think Frank knows of the effort within Silk and wants to work on it there. but yes, coordinating with him would be ++good. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: t4 wiki page
On November 26, 2009, Lukas Appelhans wrote: > Am Donnerstag 26 November 2009 15:57:17 schrieb Will Stephenson: > > On Wednesday 25 November 2009 19:46:05 Aaron J. Seigo wrote: > > > i know it's a few months off, but as more and more people become > > > interested in this crazy thing called "plasma" ;) i had a need for a > > > wiki page to point people at for T4. behold: > > > > > > http://techbase.kde.org/Projects/Plasma/Tokamak4 > > > > > > it's skeletal at the moment, but we can start filling it in. if you are > > > going to be attending, please add yourself sooner rather than later. > > > > Also as the local organizer, please let me know if you have any odd > > requirements. The usual KDE meeting reqts of bandwidth, cheap veggie > > eats and places to sleep are already on my list. > > Here! > > I'd need a computer to hack on... No laptop available :/ i've added a "special needs" section under Participants on the wiki page and noted this down there. if anyone else needs a system or has other special needs, please note them there. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Time dataengine invalid sunrise and sunset results
Petri Damstén wrote:
> On Thursday 26 November 2009 06:56:09 Amos Kariuki wrote:
>> I have some test code to obtain the sunrise and sunset time given a
>> longitude and latitude for a location:
>
> There are problems in KDE 4.3 calculation. In KDE 4.4
Thanks. (I tested and verified it works with a 4.4 build)
> America/New York|DateTime=2009-11-24T12:00:00|Solar|Latitude=40|Longitude=-75
>
> Gives:
> Sunrise: QVariant(QDateTime, QDateTime("Tue Nov 24 06:55:32 2009") )
> Sunset: QVariant(QDateTime, QDateTime("Tue Nov 24 16:37:55 2009") )
>
> And noaa for the same time zone:
> Sunrise: 06:56
> Sunset: 16:38
>
> Petri
Amos Kariuki
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: t4 wiki page
Am Donnerstag 26 November 2009 15:57:17 schrieb Will Stephenson: > On Wednesday 25 November 2009 19:46:05 Aaron J. Seigo wrote: > > i know it's a few months off, but as more and more people become > > interested in this crazy thing called "plasma" ;) i had a need for a wiki > > page to point people at for T4. behold: > > > > http://techbase.kde.org/Projects/Plasma/Tokamak4 > > > > it's skeletal at the moment, but we can start filling it in. if you are > > going to be attending, please add yourself sooner rather than later. > > Also as the local organizer, please let me know if you have any odd > requirements. The usual KDE meeting reqts of bandwidth, cheap veggie eats > and places to sleep are already on my list. Here! I'd need a computer to hack on... No laptop available :/ Lukas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: microblog kubuntu patch
On Thursday 26 November 2009 18:28:50 Aaron J. Seigo wrote: > On November 26, 2009, Marco Martin wrote: > > I think there should be a global identity configurator in kde where > > you set the various accounts, from email to identica, then a microblog > > applet could be added with those credentials > > that's being worked on as part of the open social work Frank is sponsoring. Good to know, a "web identity" configuration is also planned as part of Silk. Should talk to Frank more ... :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reuse calendar applet
On Thursday 26 November 2009, Flavio Castelli wrote: > I'm trying to reuse the plasma calendar applet inside my application. > > Currently I've been able to embed the applet but I have not been able to > handle the date selection events. > > This signal is emitted by the Plasma::Calendar class defined by > kdebase/workspace/libs/plasmaclock/calendar.h. > There's an instance of Plasma::Calendar inside of CalendarApplet which is > accessible by the CalendarApplet::graphicsWidget(). > > The CalendarApplet class is declared inside of > kdebase/workspace/plasma/generic/applets/calendar/calendar.h but this file > is not installed. > > Am I missing something? > > Thanks in advance > Flavio this fits in the idea of the reusable plasma part... yes, would be nice some way of communication between the outside application and the applets. right now blindly connecting to graphicsWidget() should work. the calendar widget right now is kept private since is used just by the clocks, if there will be enough use cases it could make into the other widgets some day perhaps -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: microblog kubuntu patch
On November 26, 2009, Marco Martin wrote: > I think there should be a global identity configurator in kde where > you set the various accounts, from email to identica, then a microblog > applet could be added with those credentials that's being worked on as part of the open social work Frank is sponsoring. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: messaging-indicator in kdereview?
On November 26, 2009, Jonathan Riddell wrote: > On Tue, Nov 24, 2009 at 05:49:22PM +0100, Sebastian K?gler wrote: > > It seems there's a messaging indicator applet in kdereview since the > > start of November. It doesn't build however (with karmic's packaged > > libindicate-qt) and didn't get any non-scripty activity in more than two > > months. Also, it's built unconditionally, even if its dependency > > (libindicate-qt) isn't there, another breakage. Feature freeze is > > looming, and I've not seen it proposed for review or at least a build > > fix. > > > > I'd suggest to remove it from kdereview. > > It was proposed a while ago but rejected because it doesn't use the > new systray/notifier item spec (a shame the spec dosen't make it clear > that this is an intended use). a protocol specification should not indicate all possible uses. that steps outside what a protocol specification does and gets into application-of-the- technology territory. the intent of the spec is to allow for both known and unforeseen application of status notification, so it's really unreasonable to expect such things in the spec itself as it would be instantly limiting (besides being off topic). it would be like describing how a webbrowser's tabs and location bar should look like in the html spec ;) now, that said, i did, *repeatedly* communicate this aspect of the technology to people who were working on this code at Canonical. so the "it's a shame.." thing feels pretty unfair. it wasn't a secret, it was just impossible to get it heard through the iron curtain of Ayatana. i also don't believe that had this been spelled out in the spec that it would have changed what happened in the least. there was already a decided upon path, and i've discovered through years of watching that those decisions are ultimately unflexible. i understand this is a tradeoff made for project control and release marketing reliability. > It's still a > great deal better than what's in KDE currently the UI is nice, the idea is good, the implementation is, tbh, ungreat. our shared users will suffer as a consequence. i looked at the code and had this been developed openly with upstream coordination, i would have offered feedback on it that would have highlighted a few issues. but if a group doesn't play by the rules of the game, i refuse to play the game with them at all. this is not petty, btw, it's protecting the value of the commons. i will not offer feedback on efforts that subvert the established process, no matter how good an idea it represents in the moment. the long term consequences of separate silos, non-open-consensus development and downstream fracturing are simply too severe. now, i really dislike treating an ally like that, but i simply can't abide the behaviour. it is not welcome here and it will never be welcome here. were that to continue, your would become increasingly isolated in your efforts and while pushing on with your self-grown agenda we would compete for developers. given project Timelord, i don't think that aligns with your goals at all. that's the crappy doom, but here's the happy glow: the recent meeting we had about using status notifier spec in Ubuntu's gnome and working on integrating dbusmenu into both KDE and GNOME's implementations is a great step towards playing by the rules of the commons. it's consensus in action, it's getting needs met, it's communicating and coordinating our plans. i'm really, really hopeful that's the way it continues and currently am committed to supporting those movements. let's try to ensure that those sorts of efforts are what the Kubuntu - KDE relationship are characterized by going forward. let's make that the reality and not accept anything less. (interestingly, i recently came across some academic literature via a friend that documents how societies with successful long term commons often have ultra-strong us-and-them, in-and-out boundaries with very real consequences for those on the other side of them.) > and continues to > be developed as a standalone project with support upstream in KMail and > Quassel now. personally, i find such ad-hoc-additions-to-upstream to be absolutely repugnant. it's not a sustainable development model because we have so many actors who would 'innovate' and if we chase after every cool cat that comes into the neighbourhood our software is going to become riddled with things that have no consensus support and which in many cases will fade away. yes, yes, yes, i know, consensus is hard to get. but it prevents most (granted, not all) fuck ups. if you look at the majority of really big fuck ups in the last few years on the Linux desktop, it's been when some cowboy somewhere or another decides "this is the way to go!" without any consensus generation outside his little circle of BFFs and often in direct opposition to the general consensus. there are a few people in this world who can get away with that kind of
Re: microblog kubuntu patch
On Thursday 26 November 2009 17:10:24 Marco Martin wrote: > I think there should be a global identity configurator in kde where > you set the various accounts, from email to identica, then a microblog > applet could be added with those credentials I could be interested on that, right now each application which uses "2.0 web services" are using his own way to storage identities which is something that imho we should centralize. Maybe we should talk with the kde-silk project about that, I'm also sure that luka (from kipi-plugins team) will join us too. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: microblog kubuntu patch
On Thu, Nov 26, 2009 at 3:54 PM, Jonathan Riddell wrote: > > For Kubuntu I add the microblog applet to the desktop by default. The > intention is to integrate online services with KDE from first use > (social from the start). Because forcing users to configure apps on > first use it evil I patched it to default to a kubuntu feed by > default, this turns out to be a more complex patch than I anticipated > and I'm not entirely certain the quality of the patch is as it should > be, but I still think it's a good idea to have it do something useful > without configuration. > > http://bazaar.launchpad.net/%7Ekubuntu-members/kdeplasma-addons/ubuntu/annotate/head%3A/debian/patches/kubuntu_02_microblog_default_configuration.diff > > Jonathan I think there should be a global identity configurator in kde where you set the various accounts, from email to identica, then a microblog applet could be added with those credentials Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
On November 26, 2009, Kåre Särs wrote: > I also thought about extragear/base/plasma/applets/, but that one is empty > (dead?). anything that you wish to package, ship and support can go into extragear (and yes, we do need to open a plasma module in extragear again). a forked version won't happen in addons, however. i mean, really, two battery monitors in the default packages? in this particular case, i'm ok with a hidden config option. usually i really dislike these things, but it's trivial, will get this issue off my back and will be a nice example later on for why hidden config options do or don't work. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Upstream bugs... (Qt)
On November 26, 2009, Alexis Ménard wrote: > So if you marked the bug CLOSED UPSTREAM please create one in the Qt > bugtracker and link it into the KDE bugtracker so people can follow it. yes, good point. given that we've suffered so long without such a bug tracker available for Qt, we've got some habits we'll need to retrain ourselves on. thanks for the reminder. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: messaging-indicator in kdereview?
On Tue, Nov 24, 2009 at 05:49:22PM +0100, Sebastian K?gler wrote: > It seems there's a messaging indicator applet in kdereview since the start of > November. It doesn't build however (with karmic's packaged libindicate-qt) > and didn't > get any non-scripty activity in more than two months. Also, it's built > unconditionally, even if its dependency (libindicate-qt) isn't there, another > breakage. Feature freeze is looming, and I've not seen it proposed for review > or at > least a build fix. > > I'd suggest to remove it from kdereview. It was proposed a while ago but rejected because it doesn't use the new systray/notifier item spec (a shame the spec dosen't make it clear that this is an intended use). So deleting is fine. It's still a great deal better than what's in KDE currently and continues to be developed as a standalone project with support upstream in KMail and Quassel now. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: t4 wiki page
On Wednesday 25 November 2009 19:46:05 Aaron J. Seigo wrote: > i know it's a few months off, but as more and more people become interested > in this crazy thing called "plasma" ;) i had a need for a wiki page to > point people at for T4. behold: > > http://techbase.kde.org/Projects/Plasma/Tokamak4 > > it's skeletal at the moment, but we can start filling it in. if you are > going to be attending, please add yourself sooner rather than later. Also as the local organizer, please let me know if you have any odd requirements. The usual KDE meeting reqts of bandwidth, cheap veggie eats and places to sleep are already on my list. > if we are lucky, we'll have devices with Nokia and Intel provenance there > for us to hack on/with. so for the mobile interested among us, it could be > quite a fun meeting. Are any usability-interested people thinking of coming? The Usability Lab has been placed at Plasma's disposal by a certain entepreneur from Boston, consisting of an eye tracking workstation and a multiple-camera user observation setup so we could do some research as well as hacking. I was at a usability symposium last night, the local uni has a research group who would be very interested to see how Plasma does usability in practice. Will ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
microblog kubuntu patch
For Kubuntu I add the microblog applet to the desktop by default. The intention is to integrate online services with KDE from first use (social from the start). Because forcing users to configure apps on first use it evil I patched it to default to a kubuntu feed by default, this turns out to be a more complex patch than I anticipated and I'm not entirely certain the quality of the patch is as it should be, but I still think it's a good idea to have it do something useful without configuration. http://bazaar.launchpad.net/%7Ekubuntu-members/kdeplasma-addons/ubuntu/annotate/head%3A/debian/patches/kubuntu_02_microblog_default_configuration.diff Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Upstream bugs... (Qt)
Hello, Since Qt Development Frameworks have an open bug tracker i would like to invite people to report bugs into it. As you can see in this bug (https://bugs.kde.org/show_bug.cgi?id=210146), it's marked as CLOSED UPSTREAM. But if nobody reports the bug in Qt's bugtracker, there is no way for Qt developers to know that the bug exists (i knew it because i'm following Plasma). Right now filtering by closed/upstream gives Trolls nothing since there is not enough information. I'm sure there are some other bugs that need a proper report. So if you marked the bug CLOSED UPSTREAM please create one in the Qt bugtracker and link it into the KDE bugtracker so people can follow it. Don't be afraid Qt's bugtracker is friendly :D. Thanks. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: t4 wiki page
Also relevant for the kwin devs, it would be great and invaluable to have some of you at Tokamak4. Lubos, Lucas, will you be able to make it? Martin, I saw you're on the list already -- cool :) The dates are 19-26th February, openSUSE offices, Nuremberg, Germany. On Wednesday 25 November 2009 19:46:05 Aaron J. Seigo wrote: > hi all ... > > i know it's a few months off, but as more and more people become interested > in this crazy thing called "plasma" ;) i had a need for a wiki page to > point people at for T4. behold: > > http://techbase.kde.org/Projects/Plasma/Tokamak4 > > it's skeletal at the moment, but we can start filling it in. if you are > going to be attending, please add yourself sooner rather than later. > > if we are lucky, we'll have devices with Nokia and Intel provenance there > for us to hack on/with. so for the mobile interested among us, it could be > quite a fun meeting. > > we'll have lots to keep everyone else busy as well, from activities to > charting the plasma 4.5 roadmap. > -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
2009/11/26 Kåre Särs > > > perhaps you could add other statistics n'stuff too, or experiment with > time > > estimation methods... :) > Would that increase the chance of being accepted? > > Okay, so predicting remaining battery time needs artificial intelligence - the research question is to predict how many minutes of battery life remain given the current state of the machine, and knowledge of what happened in the past. Simple linear regression (reported battery remaining divided by reported power draw) is bogus for two reasons: 1) Accurate models of battery discharge are inherently non-linear, depending on the power draw itself, temperature, age of the battery. 2) Much like the stock market, current power draw alone does not accurately predict future power draw. If you want to do the prediction properly, you need to learn a predictive model based on past data for each user on each computer for each battery, rather than pretending it's linear. The model would be updated periodically (say, once a minute) to account for discrepencies between what it predicted and what was actually the case, thereby gradually improving over time. The choice of prediction machinery isn't so hard (pick a form of neural net, e.g. a radial basis function), but the difficultly lies in the feature set: how, in a few numbers (to avoid the curse of dimensionality) can you characterise the current system state? If you can get this nailed, it should be possible to predict battery life with better accuracy than can be done at the moment. Andrew (PhD in AI) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
Just do as sebas said. make a hidden option for the current battery plasmoid, this will most probably be accepted. If you are still motivated later, you can write a plasmoid that is dedicated to statistics about the battery. This one too will probably be accepted. The difference is, only a minority of people will probably add such a plasmoid to their desktop, but most have the battery plasmoid. So the biggest impact would probably be to work on the battery plasmoid with a hidden option Am Donnerstag 26 November 2009 11.48:59 schrieb Kåre Särs: > On Thursday 26 November 2009, Chani wrote: > > > I disagree about the usefulness of time-remaining, but since it is not > > > my code I'll let it be. > > > > > > That said, would I get objections if I would fork "Battery Monitor" > > > into a "Battery Time" and then later push it to kdeplasma-addons? > > > > I don't know if it would make it into kdeplasma-addons. you can fork > > whatever you like in playground, though. > > Well, that was the ting. Why would I spend time on it, if it still won't be > accepted :) > > I also thought about extragear/base/plasma/applets/, but that one is empty > (dead?). > > > perhaps you could add other statistics n'stuff too, or experiment with > > time estimation methods... :) > > Would that increase the chance of being accepted? > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
On Thursday 26 November 2009, Chani wrote: > > > > I disagree about the usefulness of time-remaining, but since it is not my > > code I'll let it be. > > > > That said, would I get objections if I would fork "Battery Monitor" into > > a "Battery Time" and then later push it to kdeplasma-addons? > > I don't know if it would make it into kdeplasma-addons. you can fork > whatever you like in playground, though. Well, that was the ting. Why would I spend time on it, if it still won't be accepted :) I also thought about extragear/base/plasma/applets/, but that one is empty (dead?). > perhaps you could add other statistics n'stuff too, or experiment with time > estimation methods... :) Would that increase the chance of being accepted? -- Kåre ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
On November 26, 2009 02:36:22 Sebastian Kügler wrote: > On Thursday 26 November 2009 11:00:17 Kåre Särs wrote: > > That said, would I get objections if I would fork "Battery Monitor" into > > a "Battery Time" and then later push it to kdeplasma-addons? > > I would prefer the hidden config option, for the obvious problems that > having two copies of the same applet (with only a minor difference) brings > with it. I'm not looking forward to finding out which applet is used when > bugs occur... > hrm, good point. a completely separate widget that showed detailed battery statistics might be fun to write, though? :) -- This message brought to you by eevil bananas and the number 3. www.chani3.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: Add a tooltip to battery monitor applet
On Thursday 26 November 2009 11:00:17 Kåre Särs wrote: > That said, would I get objections if I would fork "Battery Monitor" into a > "Battery Time" and then later push it to kdeplasma-addons? I would prefer the hidden config option, for the obvious problems that having two copies of the same applet (with only a minor difference) brings with it. I'm not looking forward to finding out which applet is used when bugs occur... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
On November 26, 2009 02:00:17 Kåre Särs wrote: > > On 2009-11-25 17:27:53, Cyberbeat wrote: > > > I really like the estimated time. And it really helps. And for not > > > being precise, it is "estimated" :) Would really like to see this in > > > kde-4.4, and perhaps also backported to kde-4.3? > > > > Kåre Särs wrote: > > I'm afraid it is a bit too late for KDE 4.4 with the hard freeze in > > just a couple of hours, and I have not gotten a "ship it" > > > > Chani Armitage wrote: > > there wasn't a "ship it" because it turned into a "fork it in > > playground". for the time-remaining part at least. > > > > as for having a tooltip in the first place... well, my battery > > plasmoid just shows the info on hover directly, no need for a tooltip. I > > have a large panel, though; does it still do that in small panels? > > I wanted to add the tool-tip to add the time-remaining part without > touching the hover info. As the time-remaining was not wanted I'm not sure > either if there is a need for a popup that does not give any extra > information. > > I disagree about the usefulness of time-remaining, but since it is not my > code I'll let it be. > > That said, would I get objections if I would fork "Battery Monitor" into a > "Battery Time" and then later push it to kdeplasma-addons? I don't know if it would make it into kdeplasma-addons. you can fork whatever you like in playground, though. perhaps you could add other statistics n'stuff too, or experiment with time estimation methods... :) -- This message brought to you by eevil bananas and the number 3. www.chani3.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: Add a tooltip to battery monitor applet
> On 2009-11-25 17:27:53, Cyberbeat wrote: > > I really like the estimated time. And it really helps. And for not being > > precise, it is "estimated" :) Would really like to see this in kde-4.4, and > > perhaps also backported to kde-4.3? > > Kåre Särs wrote: > I'm afraid it is a bit too late for KDE 4.4 with the hard freeze in just > a couple of hours, and I have not gotten a "ship it" > > Chani Armitage wrote: > there wasn't a "ship it" because it turned into a "fork it in > playground". for the time-remaining part at least. > > as for having a tooltip in the first place... well, my battery plasmoid > just shows the info on hover directly, no need for a tooltip. I have a large > panel, though; does it still do that in small panels? I wanted to add the tool-tip to add the time-remaining part without touching the hover info. As the time-remaining was not wanted I'm not sure either if there is a need for a popup that does not give any extra information. I disagree about the usefulness of time-remaining, but since it is not my code I'll let it be. That said, would I get objections if I would fork "Battery Monitor" into a "Battery Time" and then later push it to kdeplasma-addons? - Kåre --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2010/#review3267 --- On 2009-11-01 09:34:16, Kåre Särs wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/2010/ > --- > > (Updated 2009-11-01 09:34:16) > > > Review request for Plasma. > > > Summary > --- > > This path adds a tool-tip for the battery-monitor applet. The tool-tip > contains charge percentage and estimated time left. > > > Diffs > - > > trunk/KDE/kdebase/workspace/plasma/generic/applets/battery/battery.h > 1041319 > trunk/KDE/kdebase/workspace/plasma/generic/applets/battery/battery.cpp > 1041319 > > Diff: http://reviewboard.kde.org/r/2010/diff > > > Testing > --- > > I'm not running trunk, so I had to comment out the setStatus() functions (not > done in the patch). > > > Thanks, > > Kåre > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add a tooltip to battery monitor applet
On Thursday 26 November 2009 08:18:22 Chani Armitage wrote: > as for having a tooltip in the first place... well, my battery plasmoid > just shows the info on hover directly, no need for a tooltip. I have a > large panel, though; does it still do that in small panels? Yep. -- 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
