Re: API Review: Tracking down the last beasties
On Monday 27 October 2008, Kevin Ottens wrote: > Hello all, i'm fine with all those changes. the most dubious imho is WebContent -> WebView, which must mean it's pretty good. i do prefer WebContent since that's, well, what it is. it would be like calling Plasma::Label a Plasma::TextView ;) anyways, thanks for taking this on... look forwrd to the patches hitting svn. it'll give me something to look forward to building in between boring meetings =P -- 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 Software 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: crash in Plasma::Meter
2008/10/28 Sebastian Kügler <[EMAIL PROTECTED]>: > I'm running into a crash, apparently in Plasma::Meter. It happens when I > initialize it. > > I've tried checking for a non empty (valid, not null) size in Plasma::Meter, > but that didn't seem to help. > > Can somebody make sense of it? It looks like d->image is NULL. > -- > 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 > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
crash in Plasma::Meter
I'm running into a crash, apparently in Plasma::Meter. It happens when I
initialize it.
I've tried checking for a non empty (valid, not null) size in Plasma::Meter,
but that didn't seem to help.
Can somebody make sense of it?
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Application: Plasma Widget Viewer (plasmoidviewer), signal SIGSEGV
Thread 1 (Thread 0xb57f48e0 (LWP 15612)):
[KCrash Handler]
#6 0xb7ebcc95 in Plasma::Svg::size (this=0x0) at
/data/kdedev/kde/src/kdebase/workspace/libs/plasma/svg.cpp:398
#7 0xb7ed854c in Plasma::Meter::paint (this=0x9dd66f8, p=0xbf871fec,
option=0x9e11558, widget=0x9de58e0) at
/data/kdedev/kde/src/kdebase/workspace/libs/plasma/widgets/meter.cpp:353
#8 0xb7a53804 in _q_paintItem (item=, painter=0xbf871fec,
option=0x9e11558, widget=0x9de58e0, useWindowOpacity=true,
painterStateProtection=true)
at graphicsview/qgraphicsscene.cpp:3783
#9 0xb7a5601a in QGraphicsScenePrivate::drawItemHelper (item=0x9dd6700,
painter=0xbf871fec, option=0x9e11558, widget=0x9de58e0,
painterStateProtection=)
at graphicsview/qgraphicsscene.cpp:3810
#10 0xb7a571a0 in QGraphicsScene::drawItems (this=0xbf8733f8,
painter=0xbf871fec, numItems=36, items=0x9e0e170, options=0x9e10874,
widget=0x9de58e0) at graphicsview/qgraphicsscene.cpp:4036
#11 0xb7a691bc in QGraphicsView::drawItems (this=0x968, painter=0xbf871fec,
numItems=36, items=0x9e0e170, options=0x9e10874) at
graphicsview/qgraphicsview.cpp:3351
#12 0xb7a71a11 in QGraphicsView::paintEvent (this=0x968, event=0xbf87254c)
at graphicsview/qgraphicsview.cpp:3096
#13 0xb758aed1 in QWidget::event (this=0x968, event=0xbf87254c) at
kernel/qwidget.cpp:7301
#14 0xb787b903 in QFrame::event (this=0x968, e=0xbf87254c) at
widgets/qframe.cpp:651
#15 0xb79059ff in QAbstractScrollArea::viewportEvent (this=0x968,
e=0xbf870df8) at widgets/qabstractscrollarea.cpp:943
#16 0xb7a7001f in QGraphicsView::viewportEvent (this=0x968,
event=0xbf87254c) at graphicsview/qgraphicsview.cpp:2337
#17 0xb7907e25 in QAbstractScrollAreaFilter::eventFilter (this=0x9deb6f8,
o=0x9de58e0, e=0xbf87254c) at widgets/qabstractscrollarea_p.h:96
#18 0xb6f9f56a in QCoreApplicationPrivate::sendThroughObjectEventFilters
(this=0x9c12288, receiver=0x9de58e0, event=0xbf87254c) at
kernel/qcoreapplication.cpp:694
#19 0xb753873a in QApplicationPrivate::notify_helper (this=0x9c12288,
receiver=0x9de58e0, e=0xbf87254c) at kernel/qapplication.cpp:3799
#20 0xb753f90a in QApplication::notify (this=0xbf87348c, receiver=0x9de58e0,
e=0xbf87254c) at kernel/qapplication.cpp:3768
#21 0xb72558d3 in KApplication::notify (this=0xbf87348c, receiver=0x9de58e0,
event=0xbf87254c) at
/data/kdedev/kde/src/kdelibs/kdeui/kernel/kapplication.cpp:307
#22 0xb6fa0361 in QCoreApplication::notifyInternal (this=0xbf87348c,
receiver=0x9de58e0, event=0xbf87254c) at kernel/qcoreapplication.cpp:583
#23 0xb759188e in qt_sendSpontaneousEvent (receiver=0x9de58e0,
event=0xbf870df8) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:212
#24 0xb75879e0 in QWidgetPrivate::drawWidget (this=0x9dc61a0, pdev=0x9de2574,
[EMAIL PROTECTED], [EMAIL PROTECTED], flags=,
sharedPainter=0x9de7668) at kernel/qwidget.cpp:4636
#25 0xb7588254 in QWidgetPrivate::paintSiblingsRecursive (this=0x988,
pdev=0x9de2574, [EMAIL PROTECTED], index=2, [EMAIL PROTECTED], [EMAIL
PROTECTED], flags=4, sharedPainter=0x9de7668)
at kernel/qwidget.cpp:4735
#26 0xb7587757 in QWidgetPrivate::drawWidget (this=0x988, pdev=0x9de2574,
[EMAIL PROTECTED], [EMAIL PROTECTED], flags=4, sharedPainter=0x9de7668) at
kernel/qwidget.cpp:4677
#27 0xb7588254 in QWidgetPrivate::paintSiblingsRecursive (this=0x9de20d0,
pdev=0x9de2574, [EMAIL PROTECTED], index=2, [EMAIL PROTECTED], [EMAIL
PROTECTED], flags=4, sharedPainter=0x9de7668)
at kernel/qwidget.cpp:4735
#28 0xb7587757 in QWidgetPrivate::drawWidget (this=0x9de20d0, pdev=0x9de2574,
[EMAIL PROTECTED], [EMAIL PROTECTED], flags=4, sharedPainter=0x9de7668) at
kernel/qwidget.cpp:4677
#29 0xb76dc68c in QWidgetBackingStore::cleanRegion (this=0x9d30730, [EMAIL
PROTECTED], widget=0x9ddf6a8, recursiveCopyToScreen=true) at
painting/qbackingstore.cpp:1035
#30 0xb76dc9d5 in qt_syncBackingStore (rgn={d = 0xbf872bac, static shared_empty
= {ref = {_q_value = 123}, rgn = 0x0, xrectangles = 0x0, qt_rgn = 0x0}},
widget=0x9ddf6a8,
recursive=) at painting/qbackingstore.cpp:232
#31 0xb76dca40 in qt_syncBackingStore (rgn={d = 0xbf872c58, static shared_empty
= {ref = {_q_value = 123}, rgn = 0x0, xrectangles = 0x0, qt_rgn = 0x0}},
widget=0x9ddf6a8)
at painting/qbackingstore.cpp:239
#32 0xb7593076 in QETWidget::translatePaintEvent (this=0x9ddf6a8,
event=0xbf87311c) at kernel/qapplication_x11.cpp:4628
#33 0xb759cd98 in QApplication::x11ProcessEvent (this=0xbf87348c,
event=0xbf87311c) at kernel/qapplication_x11.cpp:3060
#34 0xb75c3c3a in x11EventSourceDispatch (s=0x9c15058, callback=0,
user_data=0x0) at kernel/qguieventd
Re: pixmap leak in plasma?
On Saturday 25 October 2008, you wrote: > On Saturday 25 October 2008, Thomas Fjellstrom wrote: > > On Friday 24 October 2008, you wrote: > > > On Friday 24 October 2008, Thomas Fjellstrom wrote: > > > > nearly 300MB in pixmaps. I'm using trunk as of a day or two ago. > > > > > > things to try: > > > > > > * remove the tasks widget from the panel, see if that goes down > > > > From min/maxing windows I got up to 115xxxK pixmap mem, then I removed > > both my task trays and usage went down in xrestop to 86527K a fairly > > significant drop. > > yes, far too much. 86MB is also still too much though. > > > > * if not, try other widgets ;) > > > > I tried removing things such as a couple folder views, and some of the > > new system status plasmoids, and usage has only gone down to 81190K > > > > I tried to re add the task bars, and plasma crashed, with no debug > > window... But using the task bar to minimize and maximize an app causes > > usage to jump several MB. per app. sometimes 10MB. > > is this with compositing and window thumbnails turned on? if so, if you > turn thumbnails off does the problem lessen or even go away? Its with gl compositing and thumbnails turned on, the problem does lessen. plasma seems to be sitting at 166MB in pixmaps now with thumbnails turned off and having been using the desktop for a day or so. or at least since the last time I had to CTRL+ALT+BS it... > > > * see how big the pixmap cache is reported to be in the debug output > > > when plasma first starts (you can get this by starting it from a > > > konsole) > > > > plasma(7544) PlasmaApp::PlasmaApp: Setting the pixmap cache size to 20630 > > kilobytes > > > > thats the first line that says anything about the cache. > > that's the line i was looking for.. thanks.. > > > and using 'kquitapp plasma', plasma auto restarted.. and it didn't > > remember that I added the task bars back, so they are gone again. > > so you have a widget that is crashing on exit; if you're building from > source, the first place to look would be plugins that need to be rebuilt. > if you can get a bt that'd be great. > > keeping this on plasma-devel@kde.org would also be good =) I figured since I only received a message directly from you, with no copy to the list you wanted to keep it off the list. But CCing the list now. > > > not surprisingly, everyone reporting seems to be using nvidia. are you? > > > if so, could you switch temporarily to the open source nv driver adn > > > see if that fixes it? > > > > I'll try this later.. But it'll be hard to test it with the same > > parameters... no GL with the nv drivers. > > yes, it won't be the same parameters: they aren't the same drivers. > > you could also try turning compositing on / off (assuming you have it on > given your reference to GL) and see how that affects things. disabling and re enabling compositing with system settings makes the pixmap usage go up to 200MB from 160MB. > > It also seems to be impossible to get to the taskbar's settings if its > > filling up all the space. ctrl+s does nothing and theres no place to > > right click. > > click on the toolbox button on the right (the "cashew") and then you can > right click on the taskbar to get at its settings and what not. Ah.. I hope theres a more convenient way at some point. -- Thomas Fjellstrom [EMAIL PROTECTED] ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
API Review: Tracking down the last beasties
Hello all, I've been taking some time to complete the API reviews, we only have a few smallish issues left. Since Aaron basically said he'd not be really around this week[*], but still we've to move on we'll proceed in the following way: - This mail contains the list of changes I'm planning; - I'll wait for two days to see if any big problems with my changes appear (aka I'll ignore bikeshedding); - After the two days period I'll apply the changes which didn't raise problems. I'm not exactly confortable with doing that without some ack. from the maintainer, especially since we had quite a few disagreement in the past, but that's probably the best plan I can come up with to still meet the deadline on the 31st[**]. So, without more babbling on my side, here is the list of changes I'm proposing: - ConfigXml will become ConfigLoader Rationale: move away from the Xml naming (implementation detail, not relevant at use time), make it more consistent with UiLoader (similar use for ui files) - Containment::(add|remove)ToolBoxTool(QAction *action) will become Containment::(add|remove)ToolBoxAction(QAction *action) Rationale: avoid the redundancy in the name, also make it consistent with the type of the parameter (QAction*) - Flash will become FlashingLabel Rationale: instances of this class are not instances of a super-hero. Just be more precise in what it is. - Icon will become IconWidget Rationale: Assess that it's really a widget, not a representation of an Icon (like KIcon or QIcon). - PanelSvg will become FrameSvg Note: This one got discussed at lengths. It'll also impact method names in there: * resizePanel() => resizeFrame() * panelSize() => frameSize() * setCacheAllRenderedPanels() => setCacheAllRenderedFrames() * cacheAllRenderedPanels() => cacheAllRenderedFrames() * panelPixmap() => framePixmap() * paintPanel() => paintFrame() Note2: Just in case I did the same exercise with "BorderSvg", trust me it's really not as pleasant, naming the methods was really painful and didn't deliver anything interesting. Also, interestingly Plasma::Frame uses Plasma::PanelSvg, so that's probably a good match. - WebContent will become WebView Rationale: consistency with Qt API, and TreeView. As you can see we're pretty close to be done, which is good, I'll (at last) be able to work on some other funnier stuff. :-) So not many changes planned. Thanks for your attention. Regards. [*] http://aseigo.blogspot.com/2008/10/scheduling.html [**] That unfortunately excludes AbstractRunner and Service for this deadline, but I really don't see a way to meet this deadline for those ones and not have a rushed proposal at this point. That's why they'll have to be in the next batch (aka they'll prolly make it for 4.2, just not for the 31st). -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance." 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: plasma apps and screen information
On Monday 27 October 2008, Guillaume Pothier wrote: > 2008/10/27 Aaron J. Seigo <[EMAIL PROTECTED]>: > >> The latter should probably return a QRegion instead, according to what > >> you said about toolbox placement. > > > > yes, it should be a QRegion. > > ok, I'll use QRegion in the API, but for now the region will be > rectangular and the toolbox positioning code will rely on the region's > bounding box. Later I'll see how to improve that. Is that ok? absolutely. it's a good pragmatic "one step at a time" approach > >> - Added a ViewerCorona class to plasmoidviewer, as Plasma::Corona is > >> now has pure virtual methods. > > > > shouldn't be necessary if they aren't pure virtual. that you had to do > > this work was probably a good hint something could be better =) > > I think plasmoidviewer needs its own corona anyway so as to report the > actual window size instead of a meaningless value? no; it should just set the sceneRect to be equal to the window size. i'm pretty sure it already does that, actually. -- 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 Software 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: [PATCH-API-DOCU] AbstractRunner documentation
On Monday 27 October 2008, Sebastian Trüg wrote: > Hi guys, > > while implementing the Nepomuk Search runner I stumbled over the > incomplete, partially outdated, and partially wrong documentation of > Plasma::AbstractRunner. I tried to fix it as far as I could from looking at > the code. Please review the attached patch. > The patch also contains a few comments on the API; mainly questions. As you > want to move libplasma to kdelibs soon, this is maybe the last opportunity > to fix a few issues. i haven't read through your added docu (i trust you on that =), but did take a look at the questions and here are some answers: + // trueg: why is this method not protected? because it can be called by other classes if they don't care to do async matching in threads (or external processes, i suppose). at this point we could probably make it protected if we wanted to as nothing probably uses it. + // trueg: why having a reference to the context. This is very weird when storing it + // for async operations you can make copies of the context just fine; it's a non-const reference to allow for future features where runners can add their own bits of information to the context during processing. maybe we'll take advantage of that someday =P + // trueg: what do we need the term for? It is stored in the context anyway! Plus: matches() does not have a term parameter! it's needed to match the term with the context's current term. since it's threaded the following can happen: * match is called with term "kon" * runner goes off looks up "konsole" and "konqueror" * meanwhile the user types 's' * the runner tries to register its two matches with term "kon"; the context has changed, however (the runner doesn't know that yet!), and so it knows it can discard it iow, it's there to fix race conditions between the user input and runner returning matches =) > Sidenote: is it intended to not support async runners directly? well, it is what it is. we don't need async runners now that we use threads, i guess =) -- 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 Software 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: TaskManager::windowChangedGeometry() displacable?
On Monday 27 October 2008, christian mollekopf wrote: > I noticed in > void TaskManager::windowChanged(WId w, unsigned int dirty) > the windowChangedGeometry(t) signal isn't neccessary anymore and we can > easely switch to the windowChanged(changes) signal. > > Should i change this or is this on purpose? the long story is that i made this change back in the kde3 days (!) so that we could avoid tons and tons of signals making painting updates just because of geometry changes. now that we have a proper windowChanged signal, we can indeed get rid of the geometryChanged signal. let's just be certain to keep the feature that it doesn't actually track geomtry changes unless asked to =)) -- 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 Software 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: Replacing Xesam runner with Nepomuk runner
On Monday 27 October 2008, Sebastian Trüg wrote: > Kevin (who wrote the Xesam runner) agrees with me on this. Now the only > trouble is that I forgot to add the runner to the 4.2 feature list. I hope it's a bug fix: it doesn't work now, but it will. put it in. more good work from the nepomukers =) -- 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 Software 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: tasks painting semplification
On Monday 27 October 2008, Jamboarder wrote: > > From: Marco Martin <[EMAIL PROTECTED]> > > aaanyways, the painting function it's really a mess because when i added > > the support for svg theming i decided to add a fallback for every > > element, so when it does not exist in the svg just paints a rounded > > rectangle, so the code is 80% manual qpainter cruft. > > now, would be interesting as a general rule how to behave in this cases, > > i think that just removing the fallbackswould make way more cleaner code. > > i kinda remember chatting with aaron on a similar situation (don't > > remember what was the theme/plasmoid in particular) was decided to just > > consider it a problem of who makes the theme to ensure all the elements > > are in what do you guys think? > > As long as the default theme tasks.svg has the required elements, it should > behave much the same as other theme elements: When the theme author omits > the svg, use the default theme svg. I'm all for doing away with the > qpainter cruft. +1 -- 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 Software 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
not overly available this week
hi everyone... i just spent the last 36-ish hours flying from calgary to chicago to london where i had 3 hours of meetings (and an hour and a half of commuting) after which flew from london to helsinki in time to get to sleep at half past midnight or so. i'm up tomorrow at 06:30 and my last scheduled meeting starts at 18:00. which is to say ... i probably won't be overly available this week. this is really bad timing for obvious reasons, and perhaps we will end up pushing back the move of libplasma to kdelibs by a week so we can regain a week with me around =) or who knows, maybe i'll find the time and you guys will do your usual brilliant work and we'll be fine anyways. but if you do try and get a hold of me this week, please don't get too frustrated if it's hard to do so. i wish i could share with you what i'm working on here, but i can't =( what i can say is that if the groundwork that is being laid here comes to fruition, and there's no reason not to expect it at this point, it will be huge for KDE and plasma in particular. still .. nasty timing =) -- 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 Software 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: Make sure that focused result item is visible when navigating with Tab key
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/245/ --- (Updated 2008-10-26 16:13:07.755803) Review request for Plasma and Aaron Seigo. Summary --- This patch makes krunner's ResultScene correctly update current page when navigating through items using Tab key. Without this patch it works correctly (i.e. page is changed as user focuses some item on a next page) only if Up/Down/Left/Right keys are pressed. As we can't catch Key_Tab in keyPressEvent, we'll watch for item selection events. Diffs - /trunk/KDE/kdebase/workspace/krunner/resultscene.h /trunk/KDE/kdebase/workspace/krunner/resultscene.cpp Diff: http://reviewboard.vidsolbach.de/r/245/diff Testing --- Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Make sure that focused result item is visible when navigating with Tab key
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.vidsolbach.de/r/245/ --- (Updated 2008-10-26 16:11:43.080868) Review request for Plasma and Aaron Seigo. Summary --- This patch makes krunner's ResultScene correctly update current page when navigating through items using Tab key. Currently it works correctly (i.e. page is changed as user focuses some item on a next page) only if Up/Down/Left/Right keys are pressed. As we can't catch Key_Tab in keyPressEvent, we'll watch for item selection events. Diffs - /trunk/KDE/kdebase/workspace/krunner/resultscene.h /trunk/KDE/kdebase/workspace/krunner/resultscene.cpp Diff: http://reviewboard.vidsolbach.de/r/245/diff Testing --- Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
TaskManager::windowChangedGeometry() displacable?
I noticed in
void TaskManager::windowChanged(WId w, unsigned int dirty)
the windowChangedGeometry(t) signal isn't neccessary anymore and we can easely
switch to the
windowChanged(changes) signal.
Should i change this or is this on purpose?
This is the questionable code.
TaskChanges changes = TaskUnchanged;
//kDebug() << "got changes, but will we refresh?" << dirty;
if (dirty) {
// only refresh this stuff if we have other changes besides icons
changes = t->refresh(dirty);
}
if (changes & GeometryChanged) {
changes ^= GeometryChanged;
emit windowChangedGeometry(t);
}
if (changes != TaskUnchanged) {
emit windowChanged(t, changes);
}
}
Regards,
Christian
_
Die neue Generation der Windows Live Services - jetzt downloaden!
http://get.live.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Replacing Xesam runner with Nepomuk runner
On Monday 27 October 2008 19:32:02 Sebastian Kügler wrote: > I think replacing a known-broken runner with a working one is reasonable at > this stage. +1 -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Replacing Xesam runner with Nepomuk runner
On Monday 27 October 2008 17:10:20 Sebastian Trüg wrote: > Kevin (who wrote the Xesam runner) agrees with me on this. Now the only > trouble is that I forgot to add the runner to the 4.2 feature list. I hope > that we could make an exception here and see the Nepomuk runner as a fix to > the Xesam runner. ;) I think replacing a known-broken runner with a working one is reasonable at this stage. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: tasks painting semplification
On Monday 27 October 2008, Chani wrote: > > however still speaking of the taskbar but on a totally different area: > > there are some issues i don't really know how and where to fix them since > > i > > > don't know very well the libtaskmanager code: the issue of show only > > minimized tasks we talked briefly on irc yesterday (sorry, didn't have > > much time :) it seems that if the task applet starts with windows already > > loaded the show only minimized behaves correctly but not for windows that > > starts > > > after the taskbar is loaded, so perhaps is something that has to do with > > starting tasks? they shouldn't be listed at all when this option is on i > > guess > > that would be part of it: when a new task comes along the code that adds it > to the taskbar should check the minimized status (as well as any other > options that might make it not show). but how many windows *start* > minimised? > are you saying that if I add a taskbar, then open a window, then minimise > that window it still shows? then I'd look into how the existing minimize > code works - does it hook up signals&slots that aren't getting hooked up > for new windows? some examples of the behaviour: start a new program, its icon will be shown in the taskbar, minimize and restore and its icon will be gone if you make just show tasks of the current desktop and start a program that incorrectly shows up in the taskbar switching desktop back and forth the entry will disappear but really didn't spend much time looking at the why :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On October 27, 2008 02:51:17 Dmitry Suzdalev wrote: > On Wednesday 22 October 2008 19:26:22 Sebastian Kügler wrote: > > Only the ones that open popups automatically. The power management > > control extender from the battery and the calendar should have focus. > > (But I think it's fine to make that explicit in the applet itself.) > > Ok, so we need some function in popup applet which will allow its > subclasses to specify desired behavior. > > Before that I guess we need to find some combination of Qt::WindowFlags or > NET::* flags which make popups focusless and don't break extenders at the > same time :) I was hacking on the screensaver this weekend and banged my head against window flags for a while. As far as I can tell, Qt::Popup does something magical and wonderful which makes Plasma::Dialogs not break plasma-overlay. I can't find any way to make them work without that flag; the best I can get is input passing straight through them (which is at least better than users having to drop to a tty and kill plasma-overlay). and yet, Qt::Popup also does something magical which breaks extenders. blah. oh, and the flags being used in trunk cause another bug for me: when I clicked the button to bring up hte powerdevil config dialog, the battery popup stayed *above* that and would not go away until I clicked on the battery *applet*. that doesn't happen using plain Qt::Popup. http://chani.ccdevnet.org/sshots/powerdevil.png so just now I tried Qt::Popup | Qt::WindowStaysOnTopHint which doesn't really help :) the popup stayed above the dialog - but this time it went away when I clicked the dialog, which is good. extenders were still broken, though. I'm wondering what exactly triggers the popup-hide that breaks extenders, and if we can isolate it and fix it without breaking other things... but I have to go to school. of course, if anyone can figure out how to make popupapplet work on the screensaver without using Qt::Popup, be my guest :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tasks painting semplification
> however still speaking of the taskbar but on a totally different area: > there are some issues i don't really know how and where to fix them since i > don't know very well the libtaskmanager code: the issue of show only > minimized tasks we talked briefly on irc yesterday (sorry, didn't have much > time :) it seems that if the task applet starts with windows already loaded > the show only minimized behaves correctly but not for windows that starts > after the taskbar is loaded, so perhaps is something that has to do with > starting tasks? they shouldn't be listed at all when this option is on i > guess that would be part of it: when a new task comes along the code that adds it to the taskbar should check the minimized status (as well as any other options that might make it not show). but how many windows *start* minimised? are you saying that if I add a taskbar, then open a window, then minimise that window it still shows? then I'd look into how the existing minimize code works - does it hook up signals&slots that aren't getting hooked up for new windows? -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tasks painting semplification
On Monday 27 October 2008, christian mollekopf wrote: > > From: [EMAIL PROTECTED]> To: plasma-devel@kde.org> Subject: tasks > > painting semplification> Date: Mon, 27 Oct 2008 16:32:03 +0100> > Hi > > guys,> with Nuno we are starting to design the new plasma theme for 4.2, > > of course > this time won't be a total redesign like for 4.1, but just > > some tweaks here > and there.> a thing that however will look quite > > different is the taskbar theme, since > there are some usability problems > > with the current one (hard to tell apart the > focused task with the > > requesting attention ones)> even it will be mostly just a changing the > > svg tipe of work it's a good > occasion to take a look at the painting > > code. > > Very good idea, the painting is really quite hard to understand ;-) ok, so later today i will slash away that stuff with great pleasure :) > It would also be nice if could make some kind of theming for expanded > groups (or maybe collapsed as well). It could be based on the group color > (available in the lib), but then we would have to make this color either > editable, or chosen by the theme, or whatever. if done by theme we can't change the color stored in the svg unfortunately for expanded groups don't know if it would look a bit busy drawing a kind of a background of the whole group (maybe should be used something very subtle), will talk to nuno about that for collapsed group there is the arrow indicator, wouldn't make it that different, a thing that i would do perhaps is to add a number of the groups members, so a collapsed entry would look something like Dolphin (3) > However it should make expanded groups distingushable from other items and > it should work with split groups. > > Unfortunatley i don't have a clue how to do such things =(, but i'm always > ready to learn if you need my help for some coding =), i still don't really know exactly what should be done but shouldn't be that much however still speaking of the taskbar but on a totally different area: there are some issues i don't really know how and where to fix them since i don't know very well the libtaskmanager code: the issue of show only minimized tasks we talked briefly on irc yesterday (sorry, didn't have much time :) it seems that if the task applet starts with windows already loaded the show only minimized behaves correctly but not for windows that starts after the taskbar is loaded, so perhaps is something that has to do with starting tasks? they shouldn't be listed at all when this option is on i guess oh and another thing, perhaps the only major thing still missing is the grouping only when the taskbar is full, so kinda of an enabling/disabling it on the fly, would be feasible with the current architecture? personally i like it always on or always off, but received some complaints about that ... Cheers, Marco Martin > > Regards > > > I wanted to make it look nicer, so would be easy to add some fancy effect > > that > are neeever enough (well, sort of:p) > in svn there is some new > > bling already...> > aaanyways, the painting function it's really a mess > > because when i added the > support for svg theming i decided to add a > > fallback for every element, so when > it does not exist in the svg just > > paints a rounded rectangle, so the code is > 80% manual qpainter cruft.> > > now, would be interesting as a general rule how to behave in this cases, > > i > think that just removing the fallbackswould make way more cleaner > > code.> i kinda remember chatting with aaron on a similar situation (don't > > remember > what was the theme/plasmoid in particular) was decided to just > > consider it a > problem of who makes the theme to ensure all the elements > > are in> what do you guys think?> > Cheers,> Marco Martin> > > ___> Plasma-devel mailing > > list> Plasma-devel@kde.org> > > https://mail.kde.org/mailman/listinfo/plasma-devel > > _ > Die neue Generation der Windows Live Services - jetzt downloaden! > http://get.live.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Replacing Xesam runner with Nepomuk runner
As mentioned in my other email I implemented a Nepomuk search runner. It is currently in playground/base/nepomuk-kde/krunner/search in case you want to give it a spin. I propose to replace the Xesam runner in kdebase with my nepomuk runner. Why? 1. The Xesam runner does not work since we have no Xesam in KDE. 2. The Xesam runner would never handle tags and such. 3. The Xesam runner does not support relevance (always 1) and uses the same icon for each result. Kevin (who wrote the Xesam runner) agrees with me on this. Now the only trouble is that I forgot to add the runner to the 4.2 feature list. I hope that we could make an exception here and see the Nepomuk runner as a fix to the Xesam runner. ;) Cheers, Sebastian -- Sebastian Trueg Sponsored by Mandriva to work on Nepomuk-KDE. http://nepomuk.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: tasks painting semplification
> From: Marco Martin <[EMAIL PROTECTED]> > aaanyways, the painting function it's really a mess because when i added the > support for svg theming i decided to add a fallback for every element, so > when > it does not exist in the svg just paints a rounded rectangle, so the code is > 80% manual qpainter cruft. > now, would be interesting as a general rule how to behave in this cases, i > think that just removing the fallbackswould make way more cleaner code. > i kinda remember chatting with aaron on a similar situation (don't remember > what was the theme/plasmoid in particular) was decided to just consider it a > problem of who makes the theme to ensure all the elements are in > what do you guys think? As long as the default theme tasks.svg has the required elements, it should behave much the same as other theme elements: When the theme author omits the svg, use the default theme svg. I'm all for doing away with the qpainter cruft. Hope this helps, Andrew (Jamboarder) Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PATCH-API-DOCU] AbstractRunner documentation
Hi guys,
while implementing the Nepomuk Search runner I stumbled over the incomplete,
partially outdated, and partially wrong documentation of
Plasma::AbstractRunner. I tried to fix it as far as I could from looking at
the code. Please review the attached patch.
The patch also contains a few comments on the API; mainly questions. As you
want to move libplasma to kdelibs soon, this is maybe the last opportunity to
fix a few issues.
Sidenote: is it intended to not support async runners directly?
Cheers,
Sebastian
--
Sebastian Trueg
Sponsored by Mandriva to work on Nepomuk-KDE.
http://nepomuk.kde.org
Index: abstractrunner.h
===
--- abstractrunner.h (revision 872605)
+++ abstractrunner.h (working copy)
@@ -47,10 +47,9 @@
*
* @short An abstract base class for Plasma Runner plugins.
*
- * Be aware that runners have to be thread-safe. This is due to
- * the fact that each runner is executed in its own thread for
- * each new term. Thus, a runner may be executed more than once
- * at the same time.
+ * Be aware that runners have to be thread-safe. This is due to the fact that
+ * each runner is executed in its own thread for each new term. Thus, a runner
+ * may be executed more than once at the same time. See match() for details.
*/
class PLASMA_EXPORT AbstractRunner : public QObject
{
@@ -79,31 +78,58 @@
/**
* This is the main query method. It should trigger creation of
- * QueryMatch instances through RunnerContext::addInformationalMatch,
- * RunnerContext::addExactMatch, and RunnerContext::addPossibleMatch.
+ * QueryMatch instances through RunnerContext::addMatch and
+ * RunnerContext::addMatches. It is called internally by performMatch().
*
* If the runner can run precisely the requested term (RunnerContext::query()),
- * it should create an exact match (RunnerContext::addExactMatch).
+ * it should create an exact match by setting the type to RunnerContext::ExactMatch.
* The first runner that creates a QueryMatch will be the
* default runner. Other runner's matches will be suggested in the
- * interface. Non-exact matches should be offered via RunnerContext::addPossibleMatch.
+ * interface. Non-exact matches should be offered via RunnerContext::PossibleMatch.
*
- * The match will be activated if the user selects it.
+ * The match will be activated via run() if the user selects it.
*
- * If this runner's exact match is selected, it will be passed into
- * the run method.
- * @see run
+ * Each runner is executed in its own thread. Whenever the user input changes this
+ * method is called again. Thus, it needs to be thread-safe. Also, all matches need
+ * to be reported once this method returns. Asyncroneous runners therefore need
+ * to make use of a local event loop to wait for all matches.
*
- * Since each runner is executed in its own thread there is no need
- * to return from this method right away, nor to create all matches
- * here.
+ * It is recommended to use local status data in async runners. The simplest way is
+ * to have a separate class doing all the work like so:
+ *
+ * \code
+ * void MyFancyAsyncRunner::match( RunnerContext& context )
+ * {
+ * QEventLoop loop;
+ * MyAsyncWorker worker( context );
+ * connect( &worker, SIGNAL(finished()),
+ * &loop, SLOT(quit()) );
+ * worker.work();
+ * loop.exec();
+ * }
+ * \endcode
+ *
+ * Here MyAsyncWorker creates all the matches and calls RunnerContext::addMatch
+ * in some internal slot. It emits the finished() signal once done which will
+ * quit the loop and make the match() method return. The local status is kept
+ * entirely in MyAsyncWorker which makes match() trivially thread-safe.
+ *
+ * @caution This method needs to be thread-safe since KRunner will simply
+ * start a new thread for each new term.
+ *
+ * @caution Returning from this method means to end execution of the runner.
+ *
+ * @sa run(), RunnerContext::addMatch, RunnerContext::addMatches, QueryMatch
*/
+// trueg: why is this method not protected?
+// trueg: why having a reference to the context. This is very weird when storing it
+//for async operations
virtual void match(Plasma::RunnerContext &context);
/**
- * Triggers a call to match.
+ * Triggers a call to match. This will call match() internally.
*
- * @arg globalContext the search context used in executing this match.
+ * @arg context the search context used i
RE: tasks painting semplification
> From: [EMAIL PROTECTED]> To: plasma-devel@kde.org> Subject: tasks painting > semplification> Date: Mon, 27 Oct 2008 16:32:03 +0100> > Hi guys,> with Nuno > we are starting to design the new plasma theme for 4.2, of course > this time > won't be a total redesign like for 4.1, but just some tweaks here > and > there.> a thing that however will look quite different is the taskbar theme, > since > there are some usability problems with the current one (hard to tell > apart the > focused task with the requesting attention ones)> even it will be > mostly just a changing the svg tipe of work it's a good > occasion to take a > look at the painting code. Very good idea, the painting is really quite hard to understand ;-) It would also be nice if could make some kind of theming for expanded groups (or maybe collapsed as well). It could be based on the group color (available in the lib), but then we would have to make this color either editable, or chosen by the theme, or whatever. However it should make expanded groups distingushable from other items and it should work with split groups. Unfortunatley i don't have a clue how to do such things =(, but i'm always ready to learn if you need my help for some coding =), Regards > I wanted to make it look nicer, so would be easy to add some fancy effect > that > are neeever enough (well, sort of:p) > in svn there is some new bling > already...> > aaanyways, the painting function it's really a mess because > when i added the > support for svg theming i decided to add a fallback for > every element, so when > it does not exist in the svg just paints a rounded > rectangle, so the code is > 80% manual qpainter cruft.> now, would be > interesting as a general rule how to behave in this cases, i > think that > just removing the fallbackswould make way more cleaner code.> i kinda > remember chatting with aaron on a similar situation (don't remember > what > was the theme/plasmoid in particular) was decided to just consider it a > > problem of who makes the theme to ensure all the elements are in> what do you > guys think?> > Cheers,> Marco Martin> > ___> Plasma-devel mailing list> > Plasma-devel@kde.org> https://mail.kde.org/mailman/listinfo/plasma-devel _ Die neue Generation der Windows Live Services - jetzt downloaden! http://get.live.com___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
tasks painting semplification
Hi guys, with Nuno we are starting to design the new plasma theme for 4.2, of course this time won't be a total redesign like for 4.1, but just some tweaks here and there. a thing that however will look quite different is the taskbar theme, since there are some usability problems with the current one (hard to tell apart the focused task with the requesting attention ones) even it will be mostly just a changing the svg tipe of work it's a good occasion to take a look at the painting code. I wanted to make it look nicer, so would be easy to add some fancy effect that are neeever enough (well, sort of:p) in svn there is some new bling already... aaanyways, the painting function it's really a mess because when i added the support for svg theming i decided to add a fallback for every element, so when it does not exist in the svg just paints a rounded rectangle, so the code is 80% manual qpainter cruft. now, would be interesting as a general rule how to behave in this cases, i think that just removing the fallbackswould make way more cleaner code. i kinda remember chatting with aaron on a similar situation (don't remember what was the theme/plasmoid in particular) was decided to just consider it a problem of who makes the theme to ensure all the elements are in what do you guys think? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma apps and screen information
2008/10/27 Aaron J. Seigo <[EMAIL PROTECTED]>: >> - Added three methods to Corona: >>int numScreens() >>QRect screenGeometry(int) >>QRect availableScreenGeometry(int) > > these shouldn't be pure virtual. they can return silly values like by default, > of course: > ok > >> The latter should probably return a QRegion instead, according to what >> you said about toolbox placement. > > yes, it should be a QRegion. ok, I'll use QRegion in the API, but for now the region will be rectangular and the toolbox positioning code will rely on the region's bounding box. Later I'll see how to improve that. Is that ok? >> - Added Corona* parameter to Plasma::popupPosition > > if it relies on Corona, perhaps it should move *to* corona? Ok I'll move it. > >> - Added a corona() method to Plasma::Applet. This is needed for calls >> to Plasma::popupPosition. > > applet->containment()->corona(); > > yes, it's one more hoop to jump through but it: > > * keeps Applet API clean > * discourages use of corona() from Applets > * makes it clear what the object hierarchy is (Corona -> Containments -> > Applets) > >> - Also added a corona() method to Plasma::View for consistency's sake. > > containment()->corona(). > > littering the API with every conceivable convenience method is nonsensical and > destroys the ability to glean the design by reading the API. ok > >> - Corona is friends with ToolTipManager, as ToolTipManager needs to >> call Plasma::popupPosition and thus needs a Corona. Thus, Corona >> registers itself with the ToolTipManager. I think this is the ugliest >> part of the patch, please tell me if there is a better solution. > > yes, this is amazingly ugly indeed. Any idea how the ToolTipManager could get access to the corona? > >> - Added a ViewerCorona class to plasmoidviewer, as Plasma::Corona is >> now has pure virtual methods. > > shouldn't be necessary if they aren't pure virtual. that you had to do this > work was probably a good hint something could be better =) I think plasmoidviewer needs its own corona anyway so as to report the actual window size instead of a meaningless value? Thanks for the comments! Cheers, g > > -- > 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 Software > > > > ___ > 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: Taskbar with only one opened window
Works like a charm now, you guys are the best, thanks a lot! On Sun, Oct 26, 2008 at 12:53 PM, Marco Martin <[EMAIL PROTECTED]> wrote: > On Saturday 25 October 2008, Aaron J. Seigo wrote: > > On Saturday 25 October 2008, Rodrigo Pelorosso wrote: > > > Sometimes it can be a little annoying, for when the opened window > changes > > > focus there's a big change on the taskbar*. It would be great to be > able > > > to tell the taskbar the max width of an item (a percentage of the total > > > width, 30%, for instance). > > > > the taskbar should simply figure this out itself with a reasonable > maximum > > size on columns. > done, 3 lines, doesn't seem to be any particular counter effects :) > > Cheers, > Marco Martin > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Dark Designs Soluciones de Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma apps and screen information
On Friday 24 October 2008, Guillaume Pothier wrote:
> 2008/10/23 Aaron J. Seigo <[EMAIL PROTECTED]>:
> > On Wednesday 22 October 2008, Guillaume Pothier wrote:
> >> Just tell me if you want me to go ahead.
> >
> > please do =)
>
> Ok, here comes the patch. In summary:
> - Added three methods to Corona:
>int numScreens()
>QRect screenGeometry(int)
>QRect availableScreenGeometry(int)
these shouldn't be pure virtual. they can return silly values like by default,
of course:
int numScreens() { return 1; }
QRect screenGeometry(int) { return sceneRect(); }
etc...
> The latter should probably return a QRegion instead, according to what
> you said about toolbox placement.
yes, it should be a QRegion.
> - QDesktopWidget is not used anymore in libplasma, entirely replaced
> by calls to the new Corona methods.
great.
> - Added Corona* parameter to Plasma::popupPosition
if it relies on Corona, perhaps it should move *to* corona?
> - Added a corona() method to Plasma::Applet. This is needed for calls
> to Plasma::popupPosition.
applet->containment()->corona();
yes, it's one more hoop to jump through but it:
* keeps Applet API clean
* discourages use of corona() from Applets
* makes it clear what the object hierarchy is (Corona -> Containments ->
Applets)
> - Also added a corona() method to Plasma::View for consistency's sake.
containment()->corona().
littering the API with every conceivable convenience method is nonsensical and
destroys the ability to glean the design by reading the API.
> - Corona is friends with ToolTipManager, as ToolTipManager needs to
> call Plasma::popupPosition and thus needs a Corona. Thus, Corona
> registers itself with the ToolTipManager. I think this is the ugliest
> part of the patch, please tell me if there is a better solution.
yes, this is amazingly ugly indeed.
> - Added a ViewerCorona class to plasmoidviewer, as Plasma::Corona is
> now has pure virtual methods.
shouldn't be necessary if they aren't pure virtual. that you had to do this
work was probably a good hint something could be better =)
--
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 Software
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: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 19:26:22 Sebastian Kügler wrote: > Only the ones that open popups automatically. The power management control > extender from the battery and the calendar should have focus. (But I think > it's fine to make that explicit in the applet itself.) Ok, so we need some function in popup applet which will allow its subclasses to specify desired behavior. Before that I guess we need to find some combination of Qt::WindowFlags or NET::* flags which make popups focusless and don't break extenders at the same time :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
