Re: Review Request: Add keyboard navigation support to PlasmaComponents.ToolButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104727/#review12902 --- Ship it! It makes sense. - Artur Duque de Souza On April 25, 2012, 4:32 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104727/ > --- > > (Updated April 25, 2012, 4:32 p.m.) > > > Review request for Plasma and David Edmundson. > > > Description > --- > > ToolButton does not support keyboard navigation. The attached patch fixes > this by: > > - Using the "surface" item to indicate focus when the "flat" property is set > to true > > - Not giving focus on click if keyboard navigation is not defined. This is a > bit tricky, but I figured it would be odd to have a focus border around a > button which is part of a toolbar. I could not think of a better way to > figure out whether giving focus on click made sense or not. > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 9e7e715 > > Diff: http://git.reviewboard.kde.org/r/104727/diff/ > > > Testing > --- > > Running attached test script without the patch, "Focusable Button 1" starts > focused (this can be seen by pressing "space") but there is no indication > that it is. With the patch, an hover frame appears around the focused button. > Pressing tab moves the focus to "Focusable Button 2" which gets the hover > frame. > Clicking one of the focusable buttons gives them focus as well, but clicking > one of the toolbar buttons does not, since keyboard navigation is not defined > for them. > > > Thanks, > > Aurélien Gâteau > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Password character support in PlasmaComponents.TextField
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104726/#review12901 --- Ship it! looks good :) - Artur Duque de Souza On April 25, 2012, 4:10 p.m., Aurélien Gâteau wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104726/ > --- > > (Updated April 25, 2012, 4:10 p.m.) > > > Review request for Plasma and David Edmundson. > > > Description > --- > > TextField password character defaults to the old '*' character. Attached > patch sets it to unicode bullet, which is more common nowadays and also > expose the property to the outside world (though I am not sure this is really > needed, tell me if you'd rather drop it). > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10c4cee > > Diff: http://git.reviewboard.kde.org/r/104726/diff/ > > > Testing > --- > > > Thanks, > > Aurélien Gâteau > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: RSSNOW QML:reset the timer on click and some coding style fixes.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103347/#review8755 --- Ship it! Ship It! - Artur Duque de Souza On Dec. 6, 2011, 2:28 p.m., Giorgos Tsiapaliwkas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/103347/ > --- > > (Updated Dec. 6, 2011, 2:28 p.m.) > > > Review request for Plasma. > > > Description > --- > > Hello, > > the Timer component will reset to zero when the user clicks the arrows. > Also i made some fixes in the coding style. > > thanks in advance > > > Diffs > - > > rssnow/package/contents/ui/ListItemEntry.qml dac3f93 > rssnow/package/contents/ui/main.qml e39a1f6 > > Diff: http://git.reviewboard.kde.org/r/103347/diff/diff > > > Testing > --- > > everything is ok > > > Thanks, > > Giorgos Tsiapaliwkas > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[kde-workspace] plasma/generic/applets/notifications/ui: Automatically delete the notification when action clicked
Git commit 71642957d337be6e9327b10e618b4d7927eed38e by Artur Duque de Souza.
Committed on 28/04/2011 at 21:18.
Pushed by asouza into branch 'master'.
Automatically delete the notification when action clicked
When the user clicks on the button that will trigger the action of
the notification, we delete the notification so it doesn't hang there
'forever'. Let's see how it goes, but I think it improves the usability.
CCMAIL:plasma-devel@kde.org
Signed-off-by: Artur Duque de Souza
Reviewed-by: Marco Martin
M +1-1plasma/generic/applets/notifications/ui/notificationwidget.cpp
http://commits.kde.org/kde-workspace/71642957d337be6e9327b10e618b4d7927eed38e
diff --git a/plasma/generic/applets/notifications/ui/notificationwidget.cpp
b/plasma/generic/applets/notifications/ui/notificationwidget.cpp
index 3f87cfe..72bb108 100644
--- a/plasma/generic/applets/notifications/ui/notificationwidget.cpp
+++ b/plasma/generic/applets/notifications/ui/notificationwidget.cpp
@@ -433,7 +433,7 @@ void NotificationWidgetPrivate::buttonClicked()
{
//a decsion has already been taken
if (actionsWidget) {
-actionsWidget->hide();
+notification.data()->deleteLater();
}
emit q->actionTriggered(notification.data());
}
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: First try on Git repo for kdebase-workspace
On Wednesday 08 December 2010 21:09:07 Ian Monroe wrote: > http://gitweb.kde.org/scratch/ianmonroe/kdebase-workspace.git >From what I could see (that I knew the history of by heart :P) it seems perfect. Thanks Ian, you rock :) Cheers, -- --- Artur Duque de Souza - MoRpHeUz --- http://claimid.com/morpheuz Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- 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: Declarative appletscript: last touches
Hey Marco! On Thursday 09 December 2010 00:32:44 Marco Martin wrote: > import "plasmapackage:/ui/MeegoComponents" > > in generic/ui there will be a MeegoComponents subfolder (in this case a > qmldirs file listing everything is needed) that folder will have a fallback. > it's better than nothing but still not overly pretty. This one seems the best so far? :) I'll try to brainstorm something but it seems you already spent a lot of time thinking about this issue. If I would need to choose between the 4 options that you gave, I would take the last one (the one above), even if it needs the qmldir file. Cheers! -- ----------- Artur Duque de Souza - MoRpHeUz --- http://claimid.com/morpheuz Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- 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: QML and Plasma -> progress()
On Thursday 16 September 2010 15:11:42 Marco Martin wrote:
> * Plasma widgets are binded in the QML language, with the Plasma.* prefix
> * QGraphicsLayouts are binded in plasma bindings themselves, it is not going
> to be in Qt sadly (but QGraphicsWidget subclasses are starting to work
> pretty well with anchors/positioners as well)
> * Plasma::Svg and FrameSvg are implemented as QDeclarativeItem subclasses
> binded as Svg and FrameSvg. in the future plasma widgets are going to be
> reimplemented in QML probably, those will be the classes for theming
Awesome work Marco! :D
> To use QML in Plasma there are 2 ways:
> * Plasma::QMLWidget -> i a qgraphicswidget that loads a qml file in it, and
> keeps the context/engine/etc, it shortens an otherwise long and repetitive
> task of loding qml files with eventiual parse error management, to be used
> in c++ plasmoids, where complex logic is needed.
Maybe call it Plasma::DeclarativeWidget instead of Plasma::QMLWidget? Not sure
about this though, just something that crossed my mind (as the Qt item is
QDeclarativeItem).
> * Theme: defining a Plasma.Theme{} element in qml will obtain an object with
> the Plasma colors as properties -> should be an object always registered
> to the root context instead? maybe by QMLWidget itself so it is always
> accessible?
Good question. At first I thought about "sure, let's put it directly on the
root context". Now I'm not so sure again :P But I would say that yes, it may
be a good idea to already put in the root context :)
> * DataEngine: a Plasma.DataSource{} object can be defined in QML, this
> connects to a single dataengine source, das the source, dataengine and
> interval properties. its Data property is a QDeclarativePropertyMap, that
> maps perfectly DataEngine::Data (but is a qobject, so it can notify all
> properties that change) to access the time of the tiime dataengine one can
> do: dataSource.data.time .
\o/
> This can be used from both qml plasmoids or outside. I'm not completely
> sure it's the right approach, alternatively in the dataUpdated of the
> AppletScript QDeclarativePropertyMaps named as something like
> dataengine+source could be assigned to the root context, connections would
> be done in the oncomplete{} slot of qml items. uhm... in the end i think
> i'll leave the DataSource approach.
It seems more "declarative" using the DataSource approachthe other being
"too magical". I don't think it's bad, but the DataSource approach seems just
more "declarative" and then I would stick with that...
> * Service: still to be defined, if Plasma.DataSource is the right way to go,
> it could have a service() method that would essentially call
> serviceForSource, then bindings for kconfig would be needed, but this part
> is still fggy to me.
Aaron did something regarding services for the JS bindings. Or at least he had
a very good idea for it AFAIR.
> * paintInterface -> no, no access to qpainters here (and was quickly
> becoming deprecated anyways)
Another great shoot! +1 for you :D
> * constraintsEvent -> formfactor, location, immutable and currentActivity
> become notifying properties -> property binding
Nice..
> Unique "plasmoid" oject registered in the root context
> shamelessy copied from the js bindings has the following stuff:
This is something that we need to work out: kde-pim also copies some stuff
from the js binding. If we could share all this stuff it would be great
(instead of duplicating code). But we need to figure out a way of doing this
without having proper access to QML's script engine.
> * popupIcon -> needs QIcon bindings for QML
The binding could just return directly the pixmap maybe?
> Should all properties that are not CONSTANT have a NOTIFY signal? that is
> needed for qml property binding.
I think so
===
Great job Marco, and awesome mail :) Thanks for the follow up!
Cheers,
--
---
Artur Duque de Souza - MoRpHeUz
---
http://claimid.com/morpheuz
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
---
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: configChanged coverage for 4.6
On Tuesday 14 September 2010 10:18:42 Marco Martin wrote: > i think it's one of the very few ways to get this sort of small, long > repetitive and boring things done ;) +1. It also works as an excellent way of team-building ;) Cheers! -- --- Artur Duque de Souza - MoRpHeUz --- http://claimid.com/morpheuz Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- 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: today's meeting notes
Hi Marco, On Monday 13 September 2010 16:10:54 Marco Martin wrote: > now, maybe when qtcomponents will be ready it could be decided to just use > those widgets, again if they will be good enough for the desktop. That's what I'm trying to say: qt-components will probably never be "ready" as the conclusion of the project is that it's not worth it providing a widget set in QML. It's up to platform makers (this is where we enter with plasma *library*) to provide the widgets. Of course, qt-components may offer an implementation reference but it doesn't make sense to offer widgets as they differ from platform to platform and trying to do that is just a ton of hacks on top of other hacks (I say this from experience as we already tried to do so). So don't expect a widget set that we can just "use" as we have today with QWidgets. Application developers can expect that, but platform developers don't. That's why if we may want to provide this in the future: so applications using libplasma (kdeui maybe) may use directly the "KDE widgets" without pain. Summary: qt-components is not going to solve the problem for platform developers. They will need to write their widgets. Qt-components just show how to do in with less pain. Another path is to just do the bindings, but they will not work 100%...if we don't create "false hopes" that everything is going to work it's fine :) (example, without 4.7.1 the qgw exported to QML just don't work on Flickable items - nobody is maintaining this so regressions can also be expected). > Or alternatively we can also decide that we really need to wait for them ad > delay the complete bindings at this point, but wouldn't seem a particularly > wise move for me, also because would basically mean plasma mobile not > happening. I'm not saying that we choose one or another. My point is: we can do something (bindings) for the short term, but for long term we should start thinking about doing it as it's expected. Also to avoid headaches for us :) From my point of view it's not orthogonal: either bindings or proper components. From my point of view we can use the bindings for short term (4.6) and should start thinking about components for the long term. > until then, a solution already is in there, judging from a couple of pretty > complex uis i did with it, works quite good, so i don't much see the point > of all of this discussion, because the real problem is one and completely > unrelated: the use of the private class for dataengine bindings. The point of the discussion is just that you got a sentence out of context and is thinking that I'm arguing that is either one or another. My options are not exclusive - just the opposite: I think we should go for both. For the use of private classes on dataengine bindings: also don't expect for 4.7 the export of classes...it may happen on 4.8 but no idea when it's going out :P So we need to think together about a way of getting rid of it. Which private classes are being used? > as far i see from the sources a caching seems involved > (qdeclarativepixmapcache), but looks like only memory and no svg renderer > sharing, i could be wrong. I would need to check too. Don't remember about this > it is also not possible to have a borderimage that gets elements of an svg > with a certain prefix, it only gets the whole image, all of this it would > make impossible to use current themes, in brief break compatibility of wat > there is already in. Ok. This justifies the creation of a declarative item that has proper support for our svgs. Cheers, -- --- Artur Duque de Souza - MoRpHeUz --- http://claimid.com/morpheuz Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net --- 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/kdelibs/experimental/knotificationitem
SVN commit 997964 by asouza:
Only disconnect the signal if everything was ok. Before we were disconnecting
and connecting again if something went wrong.
CCMAIL: plasma-devel@kde.org
M +1 -3 knotificationitem.cpp
--- trunk/KDE/kdelibs/experimental/knotificationitem/knotificationitem.cpp
#997963:997964
@@ -630,14 +630,12 @@
if (notificationItemWatcher->isValid() &&
notificationItemWatcher->ProtocolVersion() == s_protocolVersion) {
-QObject::disconnect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
if (notificationItemWatcher->IsNotificationHostRegistered()) {
kDebug() << "service is" << notificationItemDbus->service();
notificationItemWatcher->RegisterService(notificationItemDbus->service());
setLegacySystemTrayEnabled(false);
-} else {
-QObject::connect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
+QObject::disconnect(notificationItemWatcher,
SIGNAL(NotificationHostRegistered()), q, SLOT(registerToDaemon()));
}
} else {
kDebug()<<"System tray daemon not reachable or no registered system
trays";
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdeplasma-addons/applets/pastebin
SVN commit 993753 by asouza:
TinyURL support on pastebin
Now if you drop an http url on pastebin it will give you back a
tinyurl. Right now I didn't implement this as a backend as we do
not have others for tinyurl, but we may want this to be a backend
for the sake of cleaness.
CCMAIL:plasma-devel@kde.org
M +25 -0 pastebin.cpp
M +5 -0 pastebin.h
--- trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.cpp #993752:993753
@@ -693,6 +693,23 @@
#endif //Q_WS_WIN
}
+void Pastebin::processTinyUrl(QNetworkReply *reply)
+{
+QByteArray dataRaw(reply->readAll());
+QString data(dataRaw);
+
+QRegExp re(".*([^<]+).*");
+
+if (!re.exactMatch(data)) {
+// couldn't find url
+showErrors();
+return;
+}
+
+QString tinyUrl = re.cap(1);
+showResults(tinyUrl);
+}
+
void Pastebin::postContent(QString text, QImage imageData)
{
bool image = false;
@@ -722,6 +739,14 @@
file.open(QIODevice::ReadOnly);
QTextStream in(&file);
text = in.readAll();
+} else if (testPath.scheme().toLower() == QString("http")) {
+// lets make use of tiny url ;)
+QString tinyUrl =
QString("http://tinyurl.com/create.php?url=%1";).arg(testPath.prettyUrl());
+manager = new QNetworkAccessManager(this);
+connect(manager, SIGNAL(finished(QNetworkReply*)),
+this, SLOT(processTinyUrl(QNetworkReply*)));
+manager->get(QNetworkRequest(tinyUrl));
+return;
}
// upload text
--- trunk/KDE/kdeplasma-addons/applets/pastebin/pastebin.h #993752:993753
@@ -34,6 +34,7 @@
#include
#include
+#include
class QSignalMapper;
class KAction;
@@ -86,6 +87,7 @@
void showErrors();
void openLink();
void postClipboard();
+void processTinyUrl(QNetworkReply *reply);
protected:
virtual void mousePressEvent(QGraphicsSceneMouseEvent *event);
@@ -146,6 +148,9 @@
QAction *m_topSeparator;
QAction *m_bottomSeparator;
+// to handle request to tinyUrl
+QNetworkAccessManager *manager;
+
Ui::pastebinConfig uiConfig;
Ui::pastebinServersConfig uiServers;
};
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
playground/base/plasma/applets
SVN commit 850694 by asouza: Created QEdje's plasmoid. You'll need to specify an edje file and an edje group to be loaded. In order to build the plasmoid, please install QEdje 0.2 and also QZion 0.2 (this will require EET too). I recommend downloading the KDE logo animation from: http://labs.morpheuz.eng.br/blog/wp-content/uploads/2008/08/kdelogo.edj CCMAIL: plasma-devel@kde.org A qedje (directory) A qedje/CMakeLists.txt A qedje/edjes (directory) A qedje/edjes/kdelogo.edc A qedje/plasma-applet-qedje.desktop A qedje/plasma-qedje.cpp [License: UNKNOWN] A qedje/plasma-qedje.h [License: UNKNOWN] A qedje/qedjeConfig.ui ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
