Re: ToolTip regression?
On Tue, Apr 6, 2010 at 12:00 PM, Aaron J. Seigo ase...@kde.org wrote: Plasma::TreeView is just a thin wrapper around a QGraphicsProxyWidget containing a QTreeView. can you try to replicate the problem by replacing Plasma::TreeView in your Plasmoid with a QGraphicsProxyWidget and a QTreeView directly? or, even better, a simple test case that is qt-only with a QGraphicsProxyWidget-QTreeView combination on a QGraphicScene? I have already tried a native QTreeView inside a dialog, and that works fine. I will try a QGraphicsProxyWidget. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ToolTip regression?
On Tue, Apr 6, 2010 at 12:48 PM, Rob Hasselbaum r...@hasselbaum.net wrote: On Tue, Apr 6, 2010 at 12:00 PM, Aaron J. Seigo ase...@kde.org wrote: Plasma::TreeView is just a thin wrapper around a QGraphicsProxyWidget containing a QTreeView. can you try to replicate the problem by replacing Plasma::TreeView in your Plasmoid with a QGraphicsProxyWidget and a QTreeView directly? or, even better, a simple test case that is qt-only with a QGraphicsProxyWidget-QTreeView combination on a QGraphicScene? I have already tried a native QTreeView inside a dialog, and that works fine. I will try a QGraphicsProxyWidget. Same problem exists with a QGraphicsProxyWidget in a standalone QGraphicsView, so I guess this is a Qt bug. Thanks. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Saving size of PopupApplet
On Sun, Apr 4, 2010 at 5:08 PM, Aaron J. Seigo ase...@kde.org wrote: in any case, the code is in PopupAppletPrivate::dialogSizeChanged() in kdelibs/plasma/popupapplet.cpp if you wish to investigate further. note that if you change the size of the graphicsWidget() that it will change the size the dialog. a common mistake in writing plasmoids is to resize the plasmoid in init() or some other place which will result in overriding the size the user set. OK, I will investigate more on my side. Thanks. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
ToolTip regression?
Howdy. I noticed while testing my Plasmoid on KDE 4.4.2 that tooltips are not working in my Plasma::TreeView. From what I can tell, the Qt::ToolTipRole does not get queried in the model at all. It's possible this was happening in earlier releases of 4.4, but I didn't notice it until now. It works fine in 4.3. Is this a bug? Or is there a trick to get this to work in 4.4? Thanks, -Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Saving size of PopupApplet
Hi all. How can I coax Plasma into saving the size of a PopupApplet after a user has changed it? This happens automatically when the applet is placed on the desktop, but not when it's iconified on a panel. Thanks! -Rob FWIW- This is KDE 4.3. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Saving size of PopupApplet
On Sat, Apr 3, 2010 at 9:52 PM, Aaron J. Seigo ase...@kde.org wrote: On April 3, 2010, Rob Hasselbaum wrote: Hi all. How can I coax Plasma into saving the size of a PopupApplet after a user has changed it? This happens automatically when the applet is placed on the desktop, but not when it's iconified on a panel. Thanks! this seems to be working in trunk. can you provide a more detailed how-to- reproduce? thanks. I add my widget to a panel, pop it up, resize it by dragging a corner, hide it again, then restart Plasma (kquitapp plasma-desktop or logout/login). When the desktop comes back up and I click on the panel icon again for the widget, it's back to its original size. Happens in KDE 4.3 and 4.4.2. Must be something I'm doing in my code, but I don't know what. When/how is the size saved? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Socket Sentry applet
Hi all. Sorry if this is not an appropriate use of the list, but since several of you helped me out on this, I thought I would mention that the first release of my Plasma applet and data engine is finished. It's a network traffic monitor called Socket Sentry that tries to combine features of iftop and netstat in a Plasmoid. I'd certainly appreciate feedback from Plasma developers. Here's a link to the project home page: http://code.google.com/p/socket-sentry Shameless plug over. Thanks. -Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Socket Sentry applet
Hi Aaron. Thanks for the feedback. My replies below. On Mon, Mar 29, 2010 at 9:10 PM, Aaron J. Seigo ase...@kde.org wrote: * is there any particular reason why the global settings are global instead of local? Efficiency, mainly. All widget instances that watch the same network interface are getting shared updates from a single data engine source. So actually, the global settings could be broken down by source. But just to keep things simple, I made them apply across sources for now. I might revisit that decision if there's demand for more granularity. * show subdomain levels could be done with a single spinbox and a special value (which is what shows when the value of a spinbox is the minimum) of All OK, thanks. I will remember that if I need to claim more real estate. The radio buttons do take up a lot of space. * Show one per row - is that essentially grouping? (Show one row per...)Yes, exactly. * any particular reason the column sorting couldn't happen by just right clicking on the table headers as usual? Yup, it does. Sorting and column resize happen as you'd expect if you click on the column headers, and the widget's context menu lets you pick the columns you want to see. The column selector in the config dialog is just another way to get at that functionality and--more importantly--increases the visibility of the column choices in case the user doesn't think to try the context menu. * Search boxes are usually[1] in the upper right corner, and with setClickMessage you can put the string Search right inside the searchbox itself. (a little less clutter :) I hadn't run across setClickMessage. I like that. Thanks, I'll incorporate that. i suppose you've published this on kde-look.org? Yup. * instead of Freeze sort perhaps just Sort and reverse the logic of the checkbox I'm not quite sold on this one. What I'm hoping is that freeze sort gives the user the impression that this is a temporary override of the default behavior, which is to sort. So the sort indicator on the header doesn't disappear when you check freeze sort, and when you uncheck it again, the same sort order you had before will apply again. Clicking a column header also turns off the freeze. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Restart Plasma during package installation/upgrade
Hi Aaron. Thanks for the quick reply. On Tue, Mar 23, 2010 at 5:53 PM, Aaron J. Seigo ase...@kde.org wrote: my guess would be that the dbus service does not exist yet. the code probably just needs to track the service coming and going. in fact, given your description, i assume that it probably also breaks if you stop the service and start it again while plasma-* is running. see kdebase/workspace/plasma/desktop/runners/plasma-desktop for a small and simple example of how to watch for a dbus service being available. Based on what I see, I don't think this is the case. The service is configured to automatically start up when a client tries to connect to it. I've set this up via configuration in /usr/share/dbus-1/system-services and it works fine, but only after I restart Plasma, not before. In fact, once the service is up and running, I can pkill it, and it starts right back up again if a data engine is using it, which is kinda cool. The only problem is that none of this works until I bounce Plasma. Even if I start up the service manually (i.e. not relying D-Bus auto-activation), I get an error when the data engine tries to connect. Not the same error, but an error nonetheless. I have tried sending SIGHUP to the dbus-daemon processes, but that doesn't help. The only way I've been able to make it work is by restarting Plasma. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Restart Plasma during package installation/upgrade
On Wed, Mar 24, 2010 at 11:29 AM, Aaron J. Seigo ase...@kde.org wrote: what's the error? because something is not right somewhere, and the answer isn't restart plasma-desktop If the data engine tries to start the service automatically via D-Bus activation, I get this back from D-Bus: ---snip--- Launch helper exited with unknown return code 254 ---snip--- If I start the service manually and then start the widget and data engine, I get this instead: ---snip--- Rejected send message, 1 matched rules; type=method_call, sender=:1.25 (uid=1000 pid=1664 comm=kdeinit4: plasma-desktop [kdeinit]) interface=org.socketsentry.Watcher member=findDevices error name=(unset) requested_reply=0 destination=org.socketsentry.Watcher (uid=0 pid=1872 comm=socksent-service)) ---snip--- In the second case (at least), it looks like D-Bus doesn't think the plasma-desktop process is authorized to access the service. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Restart Plasma during package installation/upgrade
On Wed, Mar 24, 2010 at 2:41 PM, Aaron J. Seigo ase...@kde.org wrote: is this running on the system bus? if so, then it's probably rejecting the call in dbus due to: deny send_type=method_call log=true/ in /etc/dbus-1/system.conf (or your system's equivalent). or perhaps it's on a different session bus than the one started automatically for the x session? thiat might explain why it would allow it after a restart of plasma-desktop, as the restarted plasma-desktop might be using the second dbus session? so it could be that the dbus service has an improperly crafter dbus interface or there's something screwy with the dbus setup (e.g. multiple session buses; check with ps?) It's on the system bus, so there's no danger of the client (data engine) and the service ending up on different session buses. The D-bus security policy for the service does deny access to all users except those at the local console (at_console=true in the config file) or those of a certain user group. That's intentional. But in my case, my user account meets both criteria. This may very well be a D-Bus bug/feature. Maybe it always denies access to processes that were created before a new service is configured. But I have to work around it somehow or communicate to users that they have to restart in order to get things to work. Obviously, I'd like to avoid bothering the user over this. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Restart Plasma during package installation/upgrade
Is there any way to restart Plasma as part of a package installation or upgrade? I have a data engine that interacts with a D-Bus system bus service, which gets installed at the same time. Unfortunately, the data engine and applet don't start correctly when they're first installed. It seems the data engine can't activate or communicate with the D-Bus service until I restart Plasma, which seems to give it enough of a kick that things work fine after that. (Not sure why restarting Plasma should affect D-Bus in this way, but it does.) Anyway, I'd like to automate this as part of the package installation or find some other solution that doesn't require user intervention. Any pointers would be much appreciated. Thanks! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Thu, Mar 18, 2010 at 1:23 PM, Rob Hasselbaum r...@hasselbaum.net wrote:
On Thu, Mar 18, 2010 at 10:56 AM, Sebastian Kügler se...@kde.org wrote:
You can, because you can find out if it's on the desktop by calling
formFactor().
Ahh, OK, so if the form factor is either Horizontal or Vertical, it's
guaranteed that the applet is a panel icon?
Here is the code I ended up with. Seems to work:
bool MyApplet::isOpen() const {
if (formFactor() == Plasma::Horizontal || formFactor() ==
Plasma::Vertical) {
return isPopupShowing();
} else {
return true;
}
}
Any chance of getting this (or something like it) added to the
PopupApplet API? Seems generally useful, since it gives applets an
opportunity to reduce their resource footprint when they're not
displayed.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 10:03 AM, Sebastian Kügler se...@kde.org wrote: I think the heuristics for this would be more complicated, but in general, it might be a good idea to quiesce dataengines as long as no *visible* applet is connected. Yeah, that would be generally useful, although the approach would need to differ depending on whether the data engine is pushing updates or the applet is polling. It's easy enough to stop polling. But in my case, since my data engine is pushing changes asynchronously and sources are created through sourceRequestEvent, I have to disconnect the source in order to silence it. I'm fine with managing that myself, but I need a method similar to the one I posted so can know when to disconnect/reconnect. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 12:21 PM, Aaron J. Seigo ase...@kde.org wrote: my only question now is how to handle notification of the change. my first thought would be to add a new Contraint (IconifiedConstraint?) and then the applet could respond in constraintsEvent. I'm currently doing this by listening for popupEvent. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 12:43 PM, Sebastian Kügler se...@kde.org wrote: I wonder if we could just offer queueing updates from dataengines until an applet is about to be shown. Especially for mobile devices, this not waking up unless shown can be very important. In my case, the act of getting the data is what I'm trying to prevent. It's expensive. So just blocking the updates from propagating between the data engine and the applet isn't enough. And a nice benefit of pausing the data engine's work is that the applet becomes idle on its own. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 1:19 PM, Sebastian Kügler se...@kde.org wrote: There are two cases for dataUpdated that matter here, indeed: (1) polling / timer-based, for example refreshing RSS feeds (2) events, for example from Solid We want to delay (1) and just keep (2) from propagation until shown. The thing is that the dataEngine then would need to know about the Applet's status (is it shown so should I update?). My case falls under #2, but as I said, stopping propagation isn't sufficient because the work that the data engine has to do to produce the data is expensive and so I want to avoid it if the data won't be seen by anybody. I think you can address both cases, though, by having the applet disconnect from sources when it's not displayed and reconnect when it is displayed. Or alternatively, give developers the tools (i.e. an isDisplayed or similar method) so they can implement that strategy themselves if they want to. The heuristics of figuring out whether the applet is visible or not is the only hard part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 2:05 PM, Aaron J. Seigo ase...@kde.org wrote: On March 19, 2010, Rob Hasselbaum wrote: It's expensive. So just blocking the updates from propagating between the data engine and the applet isn't enough. if nothing it connected to a source and the source was created using sourceRequestEvent() it is automatically removed. Yup. That's exactly what I'm relying on. When the applet becomes hidden, I'm disconnecting from the source and the data engine becomes idle unless there is some other visualization connected to that source or a different one. Works as advertised. And a nice benefit of pausing the data engine's work is that the applet becomes idle on its own. * dataengines are inherently shared between visualizations (that's actually kind of the entire point of them); so this won't work if one visualization (applet, e.g.) is shown and the other isn't Right, I should have mentioned that my dataUpdate slot also throws away any data it gets for the source after it has disconnected, so it truly becomes idle. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 1:57 PM, Aaron J. Seigo ase...@kde.org wrote: On March 19, 2010, Rob Hasselbaum wrote: I'm currently doing this by listening for popupEvent. my concern is that this won't work in all cases. i bet (translation: haven't tested, but judging from the code) that if you took an iconified popup applet from the panel and drag it to the desktop where it unfolds the applet won't update. You might be right here. I couldn't test it because I can't drag it to the desktop. Is that a 4.5 feature? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Fri, Mar 19, 2010 at 2:15 PM, Rob Hasselbaum r...@hasselbaum.net wrote: On Fri, Mar 19, 2010 at 2:05 PM, Aaron J. Seigo ase...@kde.org wrote: * dataengines are inherently shared between visualizations (that's actually kind of the entire point of them); so this won't work if one visualization (applet, e.g.) is shown and the other isn't Right, I should have mentioned that my dataUpdate slot also throws away any data it gets for the source after it has disconnected, so it truly becomes idle. Actually, the dataUpdated slot won't get invoked anyway if the applet isn't connected to that source, right? So it probably doesn't matter that I filter it out. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Detecting when PopupApplet is iconified
On Thu, Mar 18, 2010 at 9:54 AM, Sebastian Kügler se...@kde.org wrote: On Thursday 18 March 2010 14:32:07 Rob Hasselbaum wrote: Hi all. How can I tell if a PopupApplet is iconified and therefore not displaying its content? I was hoping I could override popupEvent and/or check isPopupShowing, but that approach doesn't work if the applet was added to the desktop instead of a panel. I'm guessing I should look at the applet's containment, but what property or properties should I check? This looks like what you're looking for: bool Plasma::PopupApplet::isPopupShowing()const [virtual] Unfortunately, no, because that returns false when the applet is placed on the desktop. So it doesn't help me distinguish between visible because it's on the desktop versus visible because it's popped up. And isVisible() returns true even when it's an icon, so that doesn't help either. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
