GSoC: PMC: JavaScript backends progress
Hey guys!
Here is a quick update about the Plasma Media Center backends in writing a
dataengine in JS.
The DateEngine really runs (thanks to aaron :) )
For now, it can make a flickr.photo.search requests get the response and
parse the xml, and display it on the dataEngine.
I had to paste the xml to script lib into my dataengine, due to include
problems. I know that a JS plasmoid has a command
plasmoid.include('libsomething.js');
however it doesn't work with my dataengine (although i used
engine.include('libsomething.js'); )
If you are wondering why the dataengine data, such as published date or
keywords is empty, then it is because of flickr: there should be a
specific getPhotoInfo request when you want to get the information.
the next thing is to write the fetch addons function (waiting for aaron ;)
) in this DataEngine and extract my request-response-parseXml code into an
Addon.
btw. i remember that the addon should have some kind of a main function? how
should the addon give its information to the DateEngine?
Another thing I was wondering about the MediaData API: since we merged the
video and photo API together, there are still attributes that are
disjunct. should i just drop them for now?
the code can be found here:
git://gitorious.org/lilflickr/lilflickr.git
cheers
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC: PMC: JavaScript backends progress
2010/6/28 Hayri Bakici theha...@gmail.com
Hey guys!
Here is a quick update about the Plasma Media Center backends in writing a
dataengine in JS.
The DateEngine really runs (thanks to aaron :) )
For now, it can make a flickr.photo.search requests get the response and
parse the xml, and display it on the dataEngine.
I had to paste the xml to script lib into my dataengine, due to include
problems. I know that a JS plasmoid has a command
plasmoid.include('libsomething.js');
however it doesn't work with my dataengine (although i used
engine.include('libsomething.js'); )
If you are wondering why the dataengine data, such as published date or
keywords is empty, then it is because of flickr: there should be a
specific getPhotoInfo request when you want to get the information.
the next thing is to write the fetch addons function (waiting for aaron
;) ) in this DataEngine and extract my request-response-parseXml code into
an Addon.
btw. i remember that the addon should have some kind of a main function?
how should the addon give its information to the DateEngine?
Another thing I was wondering about the MediaData API: since we merged the
video and photo API together, there are still attributes that are
disjunct. should i just drop them for now?
Which one of them? We can eventually use an associative array though.
the code can be found here:
git://gitorious.org/lilflickr/lilflickr.git
cheers
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
I'm really happy with the progresses you reached so far! Keep rocking :)
Cheers.
--
Alessandro Diaferia
KDE Developer
KDE e.V. member
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC: PMC: JavaScript backends progress
On Mon, Jun 28, 2010 at 1:11 PM, Alessandro Diaferia
alediafe...@gmail.comwrote:
2010/6/28 Hayri Bakici theha...@gmail.com
Hey guys!
Here is a quick update about the Plasma Media Center backends in writing a
dataengine in JS.
The DateEngine really runs (thanks to aaron :) )
For now, it can make a flickr.photo.search requests get the response and
parse the xml, and display it on the dataEngine.
I had to paste the xml to script lib into my dataengine, due to include
problems. I know that a JS plasmoid has a command
plasmoid.include('libsomething.js');
however it doesn't work with my dataengine (although i used
engine.include('libsomething.js'); )
If you are wondering why the dataengine data, such as published date or
keywords is empty, then it is because of flickr: there should be a
specific getPhotoInfo request when you want to get the information.
the next thing is to write the fetch addons function (waiting for aaron
;) ) in this DataEngine and extract my request-response-parseXml code into
an Addon.
btw. i remember that the addon should have some kind of a main function?
how should the addon give its information to the DateEngine?
Another thing I was wondering about the MediaData API: since we merged the
video and photo API together, there are still attributes that are
disjunct. should i just drop them for now?
Which one of them? We can eventually use an associative array though.
it was duration, and embeddedHTML for Video. for Photo there is albumID, but
i think we can firstly ignore that.
the code can be found here:
git://gitorious.org/lilflickr/lilflickr.git
cheers
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
I'm really happy with the progresses you reached so far! Keep rocking :)
Cheers.
--
Alessandro Diaferia
KDE Developer
KDE e.V. member
___
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: Info about Tokamak 4
Hi, On Sun, Jun 27, 2010 at 5:57 PM, Cornelius Schumacher schumac...@kde.org wrote: While collecting information about the developer sprints, which happended in the last twelve months, I noticed that the Tokamak 4 landing page at http://community.kde.org/KDE_e.V./Sprints/Tokamak4 still is incomplete. There is a more dot stories forthcoming notice and I don't see a link to the nice videos you recorded at the meeting. Could someone please update the page? AFAIK the videos were with Billie or Sebas but not sure. And definitely we need more dot stories. Maybe by the same time we launch the videos? Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Backporting
Hi all, just a friendly reminder. if you fix a bug now, remember to backport it to the 4.5 branch. svnbackport script in kdesdk has already been updated to default to 4.5 Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Don't span activities and add widget dialog over the two screens
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4478/ --- Review request for Plasma. Summary --- Use kephal for the screen geometry. Intersect with working area as suggested by notmart because of another bug that would be triggered then. This addresses bug 242963. https://bugs.kde.org/show_bug.cgi?id=242963 Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp 1143057 Diff: http://reviewboard.kde.org/r/4478/diff Testing --- Tested with panels at different locations. Thanks, Beat ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Don't span activities and add widget dialog over the two screens
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4478/#review6313 --- Ship it! seems correct to me. positioning could still need some love tough - Marco On 2010-06-28 15:20:38, Beat Wolf wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4478/ --- (Updated 2010-06-28 15:20:38) Review request for Plasma. Summary --- Use kephal for the screen geometry. Intersect with working area as suggested by notmart because of another bug that would be triggered then. This addresses bug 242963. https://bugs.kde.org/show_bug.cgi?id=242963 Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/shell/controllerwindow.cpp 1143057 Diff: http://reviewboard.kde.org/r/4478/diff Testing --- Tested with panels at different locations. Thanks, Beat ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC: DataEngine caching progress.
On June 27, 2010, Marco Martin wrote: caching only at exit, there is risk to lose data due sudden network loss or plasma crash. in which cases does loss of network result in loss of data? as for a crash, is caching the data that important? -- 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: Applet resizing (Python)
On June 28, 2010, Thomas Olsen wrote: def collapse_or_expand(self): if not self.collapsed: # snippet for brevity - hiding controls self.collapsed = True self.collapse_button.nativeWidget().setIcon(KIcon(arrow-down)) print Resizing to: %i % self.collapsed_height self.applet.resize(self.applet.geometry().width(), self.collapsed_height) else: # snippet for brevity - showing controls self.collapsed = False self.collapse_button.nativeWidget().setIcon(KIcon(arrow-up)) self.applet.resize(self.applet.geometry().width(), self.full_height) self.cfg.writeEntry(collapsed, self.collapsed) self.layout_widgets() When collapsing resize() is called with the correct values but straight after that new_geometry get's triggered again with a height value of ~60 pixels more... first, when an applet changes its own size (which is generally frowned upon, thought not always avoidable) it needs to emit the appletTransformedItself() signal. beyond that, it could be an issue with the default sizes of the elements in your layout, so when the layout is recalculated they say they are larger again? dunno.. -- 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: Fix some issues with resizing panels
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4463/#review6314 --- Ship it! looks good and the improvement is quite noticeable. great work. i'll commit and backport to the 4.5 branch shortly. and yes, please consider getting an svn account: http://techbase.kde.org/Contribute/Get_a_SVN_Account :) - Aaron On 2010-06-27 11:52:59, Anthony Bryant wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4463/ --- (Updated 2010-06-27 11:52:59) Review request for Plasma. Summary --- Resizing a horizontal panel's height or a vertical panel's width currently has some problems, which make it look like the size is randomly adjusting while you drag it. The cause turns out to be a sequence of calls resulting in setContainment() being called on every resize: 1. Containment::resizeEvent() - from Qt 2. ContainmentPrivate::positionPanel() 3. Containment::setPos() - to Qt 4. Containment::geometryChanged() signal - from Qt 5. ViewPrivate::updateSceneRect() slot 6. View::sceneRectAboutToChange() signal 7. PanelView::pinchContainmentToCurrentScreen() slot 8. PanelView::pinchContainment() 9. PanelController::setContainment() Whenever setContainment() is called, some of the tool buttons in the controller are removed and re-added. Since this happens on every resize event, resizing the panel is very slow and jerky, and if local coordinates from the mouse event are being compared it turns out in the wrong place. To fix this, I have used global coordinates to find the new position of the controller, and removed the call to setContainment() from pinchContainment() - it should only be called on initialization afaics. Another issue this fixes is to always resize with something, even if the mouse is out of the allowed range. In this case, it bounds the new size to the allowed range, so that resizing past the limit works as expected. Diffs - /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1143346 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 1143346 /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.cpp 1143346 Diff: http://reviewboard.kde.org/r/4463/diff Testing --- Tried moving and resizing both horizontal and vertical panels. I noticed some visible relayouting of the controller and repainting issues in the panel, but they seem to have existed before this patch as well. Thanks, Anthony ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Applet resizing (Python)
On Monday 28 June 2010 18:28:12 Aaron J. Seigo wrote: first, when an applet changes its own size (which is generally frowned upon, thought not always avoidable) it needs to emit the appletTransformedItself() signal. Aha. Didn't know about that signal. beyond that, it could be an issue with the default sizes of the elements in your layout, so when the layout is recalculated they say they are larger again? dunno.. I don't really set any sizes on the elements but I could of course try to print out their sizeHints during resize. Thanks. -- Best Regards / Med venlig hilsen Thomas Olsen 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
error while including
hi. i'm an absoulute beginner and try to make my own plasmoid. in my source code's header section, i code; #include QDBusInterface in the main function i want to create a QDBusInterface instance but the error below appears (both at my work and at home) dbus_deneme1.cpp:1:26: error: QDBusInterface: No such file or directory dbus_deneme1.cpp: In function 'int main()': dbus_deneme1.cpp:8: error: 'QDBusInterface' was not declared in this scope dbus_deneme1.cpp:8: error: expected `;' before 'plasmaApp' dbus_deneme1.cpp:9: error: 'plasmaApp' was not declared in this scope i am sure that i installed all the necessary libraries like qt, libplasma etc. where is the problem? (in addition to this i, want to compile some codes that i downloaded from the internet, if there is a QDBusInterface, QDBus or sth similar the same problem occurs.) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KDE/kdebase/workspace/plasma/desktop/shell
SVN commit 1143845 by mart:
avoid a crash in the following scenario: change the activity type of a
containment, then try to stop the activity.
it still misbehaves, because the new containment it gets created is not added
to the activity and the activity manager, that will list the activity as
stopped.
this should be backported, but it has to be right before :)
CCMAIL:plasma-devel@kde.org
M +16 -0 activity.cpp
M +1 -0 activity.h
--- trunk/KDE/kdebase/workspace/plasma/desktop/shell/activity.cpp
#1143844:1143845
@@ -315,8 +315,24 @@
connect(context, SIGNAL(activityChanged(Plasma::Context*)), this,
SLOT(updateActivityName(Plasma::Context*)), Qt::UniqueConnection);
m_containments.insert(QPairint,int(screen, desktop), containment);
+connect(containment, SIGNAL(destroyed(QObject *)), this,
SLOT(containmentDestroyed(QObject *)));
}
+void Activity::containmentDestroyed(QObject *object)
+{
+//safe here because we are not accessing it
+Plasma::Containment *deletedCont = static_castPlasma::Containment
*(object);
+
+QHashQPairint,int, Plasma::Containment*::iterator i;
+for (i = m_containments.begin(); i != m_containments.end(); ++i) {
+Plasma::Containment *cont = i.value();
+if (cont == deletedCont) {
+m_containments.remove(i.key());
+break;
+}
+}
+}
+
void Activity::open()
{
QString fileName = activities/;
--- trunk/KDE/kdebase/workspace/plasma/desktop/shell/activity.h #1143844:1143845
@@ -112,6 +112,7 @@
private slots:
void updateActivityName(Plasma::Context *context);
+void containmentDestroyed(QObject *object);
private:
void activateContainment(int screen, int desktop);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/desktop/shell
On Monday 28 June 2010, Marco Martin wrote: SVN commit 1143845 by mart: avoid a crash in the following scenario: change the activity type of a containment, then try to stop the activity. it still misbehaves, because the new containment it gets created is not added to the activity and the activity manager, that will list the activity as stopped. this should be backported, but it has to be right before :) CCMAIL:plasma-devel@kde.org any proper solutions on this? ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Quicklaunch: Migrating storage to kio bookmarks
Hi there, since you are probably all rather busy with fixing RC bugs, I'll make it short ;) One of the things I'd like to work on for the 4.6 version of the quicklaunch applet is getting rid of the more icons popup in favor a more modular concept like folders. Since I need some way to store the hierarchical structure and I would rather not reinvent the wheel here, I thought I'd migrate the storage of which icons are displayed to an XBEL file and access it through the kio bookmarks API. Not only is this a pretty good match for what I need, but it would also have a few other advantages (like not having to create .desktop files for every entry just for storing custom names/icons/descriptions). So my questions are: - Are there any objections (dependency-wise or other) to this idea? I couldn't find a policy regarding allowed dependencies for applets in kdebase- workspace, so I just assumed everything in kdelibs is ok? - Since I already made some progress and trunk is unfrozen, is it ok to check in in the half-finished and still broken version or should I work in private (maybe setting up a personal VCS) and commit only after the applet is in a usable state again? That's all I can think of for now. Best regards, Ingo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
