Summary: | open/close (show/hide) contactlist from presence applet | ||
---|---|---|---|
Product: | [Unmaintained] telepathy | Reporter: | kavol <kavol> |
Component: | presence-applet | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | ddomenichelli, fraph24, heri+kde, kde, kde, lamarque, marcus.moeller, matej, mklapetek, nicklkde, post, rad.n, szo |
Priority: | NOR | ||
Version: | git-latest | ||
Target Milestone: | 0.6.0 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/telepathy-contact-applet/5b609fe8d5d14fd4fa17f3475d00deadea59dc98 | Version Fixed In: | 0.6.0 |
Sentry Crash Report: |
Description
kavol
2012-02-28 12:15:35 UTC
note that it is the same with standalone presence applet on the panel, not just with the systray icon (In reply to comment #0) > 1) it cannot be configured as a default for left-click (in fact, left-click > does nothing right now) ahem, actually, it can, sorry - I was looking in a wrong place (systemsettings) We can maybe make it an option to show/hide, but I'm not sure your suggestion is a "sane default", I imagine it would appears as "clicking it does something completely random each time". David, a lot of instant messaging applications have the same behaviour. Many users that are migrating from Kopete to ktp are used to it. I believe it would be more like "expected" then "random" behaviour. It would be even better if the keyboard shortcut for the widget would work the same - press it to show contact list (or move it on top, to another desktop) and press it again when the window is active to hide it. (In reply to comment #4) > David, > > a lot of instant messaging applications have the same behaviour. (If I may add, along with various other applications that have a system tray icon, BitTorrent clients (e.g. ktorrent, qbittorrent, transmission), IRC clients (e.g. Konversation, Quassel), media players (e.g. smplayer, gnome-mplayer, vlc), so such behaviour is well known/understood by users). *** Bug 295785 has been marked as a duplicate of this bug. *** To close the window you can just call the quit() method in the org.kde.ktp-contactlist service /MainApplication object org.kde.KApplication interface if the service exists on dbus, otherwise start it, and it's actually quite easy to do. The problem is that hiding/showing is different from starting closing an application, it's slower (models are reloaded, etc), you don't get the animations (so the user won't realise that the window is closed) and i'm not sure if the status of the window is restored exactly as it was before closing. I'm not really sure if this is a good idea, but I'm not against it, if this isn't the default behaviour and someone wants to do it... I'm marking it as a Junior Job, because the implementation should be quite trivial I'm not sure this is a junior job. The coding may be simple, but getting a patch that I disagree with past me isn't easy at all :) What you suggested doesn't handle this whole notion of behaving differently if it's on a different virtual desktop, or activity. With what you just said, you'll end up just closing it if it's on a different desktop - and depending on settings you'll just respawn it on a different desktop when you click on it too. This turns into a right pain, and I'm not even sure we want it. Not every comment on bugzilla is actually sensible, and on this I just can't decide at all. A working demo would maybe sway me, but that would be really disheartening for a JJ person's first patch if it doesn't. I would maybe suggest to actually delay/close it and integrate it with the plasma/qml contact list. Thoughts? Why not just making a function that calls either start() (I mean the method that activates the contact list) or quit() (I mean the method that hides the contact list) methods depending on a flag that indicates if the list is active or not? Any button would just check on this flag and change its state, accordingly to what that button is made to do..... I did just this and will post for review over the weekend. *** Bug 312199 has been marked as a duplicate of this bug. *** (In reply to comment #11) > I did just this and will post for review over the weekend. Did anything happen with this? When I click the presence icon in the systray while the contact list is open, it still does not close. (Telepathy/KDE 0.5.1) Nope. We went back and forth with it, discussed different ideas etc. and it got nowhere. Right now (all) the plasmoids are being moved, so I'll fix this after the weekend when all is in the new place. This is one bug that is stopping me to move over to telepathy. I hope it will be implemented soon. :) I think the desirable behaviour would be the same as the kopete works: 1, if the window is hidden, show it 2, if the window is shown and on the same screen, hide it 3, if the window is shown and not on the same screen, switch to the screen containing the window (alternatively, 3 can be bring the window to the current screen) Git commit 4316858b1d897a00c334d9ed846c8dc3e99b2172 by Martin Klapetek. Committed on 20/03/2013 at 13:31. Pushed by mklapetek into branch 'master'. Add small D-Bus interface to bring the window forward or close This is now used from the presence plasmoid, if the contact list is running, it calls the toggleWindowVisibility() and decides itself if it should bring the window forward or be closed. REVIEW: 109600 M +10 -0 main-widget.cpp M +4 -0 main-widget.h http://commits.kde.org/telepathy-contact-list/4316858b1d897a00c334d9ed846c8dc3e99b2172 Git commit 5b609fe8d5d14fd4fa17f3475d00deadea59dc98 by Martin Klapetek. Committed on 21/03/2013 at 11:02. Pushed by mklapetek into branch 'master'. Open & close contact list when clicking the presence plasmoid If the contact list is opened already, it will be given focus and made an active window. If it's active window, it will close. If it's not running, it will be started. REVIEW: 109599 FIXED-IN: 0.6.0 M +62 -5 presence/src/presence-applet.cpp M +8 -1 presence/src/presence-applet.h http://commits.kde.org/telepathy-contact-applet/5b609fe8d5d14fd4fa17f3475d00deadea59dc98 Great, thanks! This was the last ktp regression over Kopete I've faced. |