QML and paths to images
Hello! I'm working on implementation of system tray in QML. Is it possible to get absolute path to icon/image/movie in QML? I need to put into QML code AnimatedImage item, but it requires a full path to a movie (animation). I have only name of movie instead of its full path. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and paths to images
09.06.2012 18:39, Aaron J. Seigo пишет: On Saturday, June 9, 2012 16:27:38 Dmitry wrote: I'm working on implementation of system tray in QML. Is it possible to get absolute path to icon/image/movie in QML? I need to put into QML code AnimatedImage item, but it requires a full path to a movie (animation). I have only name of movie instead of its full path. if the animation is in the package, then you can use a MobileComponents.Package object i have no idea what that is still in MobileComponents instead of Core.. marco? if the animation is NOT in the package ... where is it? (somewhere in $KDEDIRS? somewhere application specific? etc..) Hello! Animations are in /usr/share/icons// and if I use C++ I'll load them using KIconLoader::loadMovie(). Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML and paths to images
09.06.2012 19:21, Aaron J. Seigo пишет: On Saturday, June 9, 2012 18:56:46 Dmitry wrote: Animations are in /usr/share/icons// and if I use C++ I'll load them using KIconLoader::loadMovie(). ah .. from icons. hm. question: is the QML implementation you are working on pure QML, or is it a mix of C++ and QML? I'm trying to use only QML (or minimal usage of C++). I think it's good idea to extend interface of PlasmaCore.theme to make KIconLoader::pathMovie() and KIconLoader::iconPath() accessible from QML., or implement MovieItem like SvgItem. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma applets inside QML applet
Hello!
I'm developing an applet in QML. I need to load an external applet and
to place it into my applet like containment applet, like panel or
system tray. But at the same time my applet isn't a pure containment
applet [it doesn't contain only applets]. Do You know how I can do it or
it's not possible?
I'd like to do like next:
Applet { // like Svg
id: battery_applet
name: "battery" // name of applet to be loaded (like argument of
function Plasma::Applet::load(name, ...) )
}
AppletItem { // like SvgItem
applet: battery_applet
width: 20
height: width
...
}
Thank you!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma applets inside QML applet
25.06.2012 13:24, Marco Martin пишет: On Monday 25 June 2012, Dmitry Ashkadov wrote: Hello! I'm trying to implement a system tray in QML. So, I have a trouble with applets such as battery, notifier, notifications. They [applets] should be mixed with icons of applications and tray must have an arrow to show popup dialog. Thank you a qml based systray will be very useful indeed! however i think in this case will have to be mixed with c++, so reusing part of the code of the old one, for two things: * embedding applets (plasmoidtaskprotocol) * and for the legacy xembed based systray icons, that should continue to be supported while we are still on X11 (killing it with joy when we'll move to wayland ;) so i think you should basically take the current c++ systray, strip it from all the ui code, then start to embed a qml ui in it Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Hello! I'm using C++ as a plugin for QML applet, not C++ applet with UI in QML. As for now it [systray applet] contains applets (but it isn't a good way) mixed with icons of other applications. I'm trying to find better way to place applets into tray. Thank you, Martin, for your help. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma applets inside QML applet
Hello! I've found out a strange behaviour. If I place embedded applet into panel part of tray then the embedded applets look well and work. But If I place them into popup dialog then they look strange and don't work at all. It seems that plasma automatically places their extended/popup form instead of compact/iconized form. Do you have any ideas? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Pop-up dialog of embedded applets
Hello, Marco! I'm implementing system tray in QML. I've found a solution how to place embedded applet into pop-up window of tray. But there is one difference between my system tray [in QML] and your current system tray [in pure C++]. If some embedded applet is placed in pop-up window of system tray (pop-up part of the tray) and user clicks on it [embedded applet] then the pop-up dialog of embedded applet will arise at the cursor coordinates and either it looks like separated window or it overlaps the panel. It looks weird. If user clicks on an applet embedded in pop-up window of current C++ system tray then pop-up window of the embedded applet arises docked to the panel and never overlap it. Do You know what is a reason of such strange behaviour? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Pop-up dialog of embedded applets
03.07.2012 16:44, Dmitry ?:
Hello, Marco!
I'm implementing system tray in QML. I've found a solution how to
place embedded applet into pop-up window of tray. But there is one
difference between my system tray [in QML] and your current system
tray [in pure C++]. If some embedded applet is placed in pop-up window
of system tray (pop-up part of the tray) and user clicks on it
[embedded applet] then the pop-up dialog of embedded applet will arise
at the cursor coordinates and either it looks like separated window or
it overlaps the panel. It looks weird. If user clicks on an applet
embedded in pop-up window of current C++ system tray then pop-up
window of the embedded applet arises docked to the panel and never
overlap it. Do You know what is a reason of such strange behaviour?
Thank you!
Hello!
It seems that PopupApplet uses global coordinates to place popup dialog.
If applet is located outside of a panel then its popup dialog won't be
docked to the panel (will be shown like a separate window). I think the
current system tray in C++ doesn't have such problem because an order of
actions is next:
1. User clicks on embedded applet
2. Embedded applet changes its status
3. Previous action causes system tray in C++ to move embedded applet
from popup dialog to panel part
4. Embedded applet shows its pop-up window docked to panel because it
is located in panel.
So, I've found next solution to described problem:
* First of all, I handle mouse click event. If user clicks on
embedded applet then I check if this applet is a pop-up applet like
this:
Plasma::PopupApplet *popup = qobject_cast(applet)
if (popup) { /* Applet is a pop-up applet */}
* Next I hide applet to disable its redrawing:
popup->hide();
* Reparent popup. It becomes located in panel:
popup->setParentItem(panel); // panel is a panel part of system tray
* Show pop-up of embedded applet:
popup->showPopup();
I think that this way isn't good, but it is only one way I have found to
solve the problem. What do you think about solution? Maybe do you have
another ideas?
Thank you.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Complex configuration dialog for pure QML applet
Hello! I'm trying to implement system tray in QML. I'm trying to implement configuration dialog (widget). Pure QML-based applet "devicenotifier" is an example of implementation of configuration dialog for QML applet. But it has only 3 simple radio buttons in its configuration dialog. Its way to implement configs dialog isn't possible in my case. The configuration dialog (widget) of system tray is complex and it isn't possible to get access to this dialog from QML/JS. Moreover, it isn't possible from C++ also, because the function Plasma::Applet::createConfigurationInterface() isn't accessible (I cann't extend Plasma::Applet because applet is QML-based). Do you have any ideas what can I do? Is extending of functionality expected in the future? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Complex configuration dialog for pure QML applet
17.07.2012 18:18, Marco Martin пишет: in this particular case, i would say is the best way to go anyways, since a systray replacement to be complete needs to support also the old x11 protocol and i really want to avoid applets with their own c++ import, thinking to formalize this requirement (nothing installed in imports) for plasmoids to be included by default What do you think about "import org.kde.plasma.core 0.1 as PlasmaCore" ? Can plasmoid [included by default] import such modules? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Complex configuration dialog for pure QML applet
17.07.2012 18:18, Marco Martin пишет: i really want to avoid applets with their own c++ import, thinking to formalize this requirement (nothing installed in imports) for plasmoids to be included by default Does such list of requirements exist? Is it published? Thank you/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System tray: configuration dialog
Hello! What do you think about removing column allowing setting the hot-keys (shortcuts) for every tray task/application/embedded applet? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System tray: project
Hello, Marco! What do you think about: * should I use code of current system tray (i.e. git clone & git branch ) to include system tray in QML in KDE or create new clean project (i.e. git init) and push it [new project] to playground? Should system tray in QML be an continuation of tray in C++ (git branch) or it [system tray in QML] should be a project, new applet (git init)? * should I save project structure (files and directories, classes, etc) or I can feel free creating project (new/different files, directories and classes, etc)? * should I access to data engine "statusnotifieritem" from C++ code or can do this from QML directly? The answers to these question are required me to understand how I can organize code to avoid problems with integration of system tray in KDE. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray: project
20.07.2012 14:15, Marco Martin пишет: in this case it should be a branch of the kde-workspace repo, they are usually named project/youraccountname/featurename, so would be something like plasma/dmitry/qmlsystemtray So, can I create new branch in kde-workspace (I'm asking for a permission to push)? I can create a new repository and add it and kde-workspace as 2 different remotes. One more question: can I use C++11 features inside system tray subproject or it isn't possible for now? Qt supports some C++11 features and, I think, KDE will use C++11 in the future. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PlasmaCore.ToolTip
Hello! Does PlasmaCore.ToolTip support icons specified as QIcon (not by name of icon) ? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PlasmaCore.ToolTip
30.07.2012 13:33, Marco Martin пишет: On Monday 30 July 2012, Dmitry wrote: Hello! Does PlasmaCore.ToolTip support icons specified as QIcon (not by name of icon) ? Thank you! no, at the moment only icon name. i guess is to support both types of systray icons? it should be possible to change it to a variant making it accept multiple data types in 4.10 maintaining compatibility Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel At the moment I know workaround for this problem. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
07.08.2012 12:25, Marco Martin пишет: On Tuesday 07 August 2012, Peter Hartmann wrote: Hello I'd like to inquire if QML port of System Monitor applet is in work or in plans for near future. There is only C++ code in repo, but revision history tells me that there were such attempts in the past. Will hypothetical patches won't be rejected on the basis of "major rewrite incoming"? hi, a major port isn't in progress yet as far i know. a qml port would be teoretically possible except for the plotter widget, the old widget should be used (is binded to qml even if not optimal to use from there) but would be useful already. patches on the c++ version are anyways welcome, even tough i would keep them mostly bugfixes right now Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Hello! I'm working on my new system monitor applet. I hate current default C++ applet. So, I've decided to implement my simple system monitor in pure QML (no C++ code at all). At the same time I don't know would KDE team include my applet in the future. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
07.08.2012 13:16, Marco Martin пишет: On Tuesday 07 August 2012, Dmitry wrote: Hello! I'm working on my new system monitor applet. I hate current default C++ applet. So, I've decided to implement my simple system monitor in pure QML (no C++ code at all). At the same time I don't know would KDE team include my applet in the future. i would like to replace the current c++ applet(s) however to make a painless transition for users it should look as similar as possible to the current ones (and then make eventual visual modifications a second time) I don't really need graphical visualization of history of values (plotter). Current monitor applet acquires too many space on panel and at the same time it shows current value incorrectly. So, I don't want to replace current system monitor because it is intended to be placed on a desktop and I need more simple monitor applet on panel. I usually don't see my desktop (and never place applets on it) and I think it is better that system monitor applet is placed on panel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
08.08.2012 17:13, Mark пишет: On Tue, Aug 7, 2012 at 12:55 PM, Dmitry wrote: 07.08.2012 13:16, Marco Martin пишет: On Tuesday 07 August 2012, Dmitry wrote: Hello! I'm working on my new system monitor applet. I hate current default C++ applet. So, I've decided to implement my simple system monitor in pure QML (no C++ code at all). At the same time I don't know would KDE team include my applet in the future. i would like to replace the current c++ applet(s) however to make a painless transition for users it should look as similar as possible to the current ones (and then make eventual visual modifications a second time) I don't really need graphical visualization of history of values (plotter). Current monitor applet acquires too many space on panel and at the same time it shows current value incorrectly. So, I don't want to replace current system monitor because it is intended to be placed on a desktop and I need more simple monitor applet on panel. I usually don't see my desktop (and never place applets on it) and I think it is better that system monitor applet is placed on panel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel My advice would be to use the current KDE Plasma ported components [1] in QML. You can find the documentation of each of those bindings in the C++ docs [2] note that you also need to look at the header files to figure out which values are usable in QML (Q_PROPERTY and Q_INVOKABLE) If you need a canvas, make a QML wrapper around the Plasma::SignalPlotter component that implements the same functions as [3]. It's a bit of a hassle and not optimal, but it will make your code ready to port to Qt5 thus makes your life a lot easier + doing that also - likely - allows your plasmoid to be accepted in KDE. (no guarantees!) [1] http://quickgit.kde.org/index.php?p=kde-runtime.git&a=blob&h=6cc3011319d750cb70c4cb98eb5290bf042c4d78&hb=944cbca008962f41c33c994ef320771ec7fed161&f=plasma%2Fdeclarativeimports%2Fgraphicswidgets%2Fgraphicswidgetsbindingsplugin.cpp [2] http://api.kde.org/4.8-api/kdelibs-apidocs/plasma/html/namespacePlasma.html [3] http://doc-snapshot.qt-project.org/5.0/qml-qtquick2-context2d.html Hello, Mark! I think, you haven't understood me right. I don't want to port current C++ system monitor applet because it hasn't been intended to be placed on a panel. I don't need visualization (plotter) at all. If I put current system monitor applet on panel it will looks strange and acquires too much space. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
09.08.2012 14:27, Marco Martin пишет: On Thursday 09 August 2012, Dmitry wrote: http://doc-snapshot.qt-project.org/5.0/qml-qtquick2-context2d.html Hello, Mark! I think, you haven't understood me right. I don't want to port current C++ system monitor applet because it hasn't been intended to be placed on a panel. I don't need visualization (plotter) at all. If I put current system monitor applet on panel it will looks strange and acquires too much space. by the way that's what the formfactor mechanism for plasmoids is for. the same plasmoid should adapt itself for an optimal visualization wether is in the desktop, an horizontal panel or a vertical one, just check the plasmoid.formFactor property and adapt the layout by consequence ;) Hmmm If I create pure QML applet then it isn't possible to handle changing of plasmoid.formFactor & plasmoid.location (: ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
09.08.2012 15:10, Marco Martin пишет:
On Thursday 09 August 2012, Dmitry wrote:
by the way that's what the formfactor mechanism for plasmoids is for.
the same plasmoid should adapt itself for an optimal visualization wether
is in the desktop, an horizontal panel or a vertical one, just check the
plasmoid.formFactor property and adapt the layout by consequence ;)
Hmmm If I create pure QML applet then it isn't possible to handle
changing of plasmoid.formFactor& plasmoid.location (:
why?
you are notified about the change of those 2 properties
and in qml is easy to dinamically change layouts, create and destroy
components and so on (with the state machine even easier)
I've tried but if plasma starts then the plasmoid has right value of
formFactor and location (and others). But if I change location of panel
then plasmoid wont change formFactor and location. For example, for me
the next doesn't work:
...
states: [
State {
when: plasmoid.location == LeftEdge
},
State {
when: plasmoid.location == RightEdge
}
]
...
Properly state is set at the startup, but will never change if I move panel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Current state of System Monitor
09.08.2012 18:08, Marco Martin пишет:
On Thursday 09 August 2012, Dmitry wrote:
09.08.2012 15:10, Marco Martin пишет:
On Thursday 09 August 2012, Dmitry wrote:
by the way that's what the formfactor mechanism for plasmoids is for.
the same plasmoid should adapt itself for an optimal visualization
wether is in the desktop, an horizontal panel or a vertical one, just
check the plasmoid.formFactor property and adapt the layout by
consequence ;)
Hmmm If I create pure QML applet then it isn't possible to handle
changing of plasmoid.formFactor& plasmoid.location (:
why?
you are notified about the change of those 2 properties
and in qml is easy to dinamically change layouts, create and destroy
components and so on (with the state machine even easier)
I've tried but if plasma starts then the plasmoid has right value of
formFactor and location (and others). But if I change location of panel
then plasmoid wont change formFactor and location. For example, for me
the next doesn't work:
Yeah, seems to not work indeed, thanks for noticing ;)
the signals weren't emitted, i fixed that in both master and 4.9 branch.
unfortunately the property bindings still seem to not work, so unfortunately a
slightly more verbose code should be used, like:
Connections {
target: plasmoid
onLocationChanged: {
//code to change state accordingly
}
onFormFactorChanged: {
//code to change state accordingly
}
}
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Marco, please, check all properties. As I know plasmoid works partially
to fit to requirements of devicenotifier.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Translations
Hello! If current C++ system tray applet doesn't run then QML system tray will have configuration dialog with untranslated string. Do you know why it may occur? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System tray: size of icons
Hello! I thought that all icons in tray have to be the same size (i.e. to be limited in size), but current C++ system tray doesn't fix size of icons (plasmoids). For example, battery may be larger that other icons. It looks very strange: I assumed that all icons have to have the same size and I fixed their size in QML implementation of system tray. So, my assumption causes battery be smaller or be clipped: What do you think about such behavior? I think if plasmoid have large size then it should be placed on panel. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray: size of icons
14.08.2012 21:01, Marco Martin пишет: On Tuesday 14 August 2012, Dmitry wrote: Hello! I thought that all icons in tray have to be the same size (i.e. to be limited in size), but current C++ system tray doesn't fix size of icons (plasmoids). For example, battery may be larger that other icons. It looks very strange: SysTray will look strange if battery applet shows percent I assumed that all icons have to have the same size and I fixed their size in QML implementation of system tray. So, my assumption causes battery be smaller or be clipped: Clipped battery plasmoid in system tray What do you think about such behavior? I think if plasmoid have large size then it should be placed on panel. hmm, that sounds like a bug, the battery shouldn't have a too big minimum size.. are you setting an actual clip to the items that contain the plasmoids? (it may get a bit expensive on performances) Yes, I've set "clip" to on. But if I set "clip" to off, battery will look the same, because I set its maximum size (and minimum size otherwise networkmanager applet wont be visible). I set the maximum size because applets may want to be large then other icons: (it may get a bit expensive on performances) OK, I can disable clipping. <>___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray: size of icons
14.08.2012 21:59, Dmitry пишет: 14.08.2012 21:01, Marco Martin пишет: On Tuesday 14 August 2012, Dmitry wrote: Hello! I thought that all icons in tray have to be the same size (i.e. to be limited in size), but current C++ system tray doesn't fix size of icons (plasmoids). For example, battery may be larger that other icons. It looks very strange: SysTray will look strange if battery applet shows percent I assumed that all icons have to have the same size and I fixed their size in QML implementation of system tray. So, my assumption causes battery be smaller or be clipped: Clipped battery plasmoid in system tray What do you think about such behavior? I think if plasmoid have large size then it should be placed on panel. hmm, that sounds like a bug, the battery shouldn't have a too big minimum size.. are you setting an actual clip to the items that contain the plasmoids? (it may get a bit expensive on performances) Yes, I've set "clip" to on. But if I set "clip" to off, battery will look the same, because I set its maximum size (and minimum size otherwise networkmanager applet wont be visible). I set the maximum size because applets may want to be large then other icons: (it may get a bit expensive on performances) OK, I can disable clipping. At the same time there is interesting situation if user's computer has 2 batteries. Battery applet has option "show icon for every battery". If user enables it then battery applet will show 2 very small batteries: <>___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Translations
15.08.2012 03:19, Alexander Potashev пишет: Hi Dmitry, (I'm CC'ing the KDE localization mailing list.) This happens due to missing code that would import required translation catalogs (.po files), for example: KGlobal::locale()->insertCatalog( "kcm_akonadi" ); or static const KCatalogLoader loader( "libincidenceeditors" ); I may sound stupid, but I can't find the sources of the QML system tray you are talking about. Could you please point to them? Hello, Alexander! I can't find such code in current C++ system tray applet. Maybe KDE translation framework loads translation corresponding to applet automatically? Now QML system tray isn't published, because I cannot build KDE locally: CMake Error at …/build/kde/inst/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198 (MESSAGE): Could NOT find Nepomuk (missing: SOPRANO_PLUGIN_RAPTORPARSER_FOUND SOPRANO_PLUGIN_REDLANDBACKEND_FOUND) Call Stack (most recent call first): …/build/kde/inst/share/apps/cmake/modules/FindNepomuk.cmake:80 (find_package_handle_standard_args) services/fileindexer/indexer/CMakeLists.txt:3 (find_package) So, I can't develop in kde-workspace (((. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
System tray
Hello, Marco! Could you try a system tray from plasma/dmitrya/systemtray-qml branch of kde-workspace? What do you think about popup window? Maybe will it better if icons in popup are placed like a grid? Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PopupApplet and setFocus() behaviour
Hi guys and girls! While making some progress on klipper engine+applet I discovered some oddities with focus behavior. I hope you can give me some hints about my situation (don't get scared by amount of text below, i tried to make it simple to follow). General layout of applet widgets is the following: Applet is a PopupApplet. It has a QGraphicsProxyWidget as graphicsWidget(), which has embedded QWidget (named KlipperWidget) which has a QListView inside (it displays clipboard history entries). What I'm trying to do is to make sure that this QListView will always have keyboard focus when popup is shown. I'm doing it by overriding a PopupApplet::popupEvent() and calling KlipperWidget's setFocus() function. KlipperWidget has a QListView set as a focus proxy for this to work. And it works... but only when I launch applet in "plasmoidviewer -f horizontal klipper". Problem: When applet is inside plasma-desktop, no focus gets set. I tried to debug this and found that when running as a part of plasma-desktop, QListView actually gets only FocusOut event, and not a single FocusIn. After looking through souces of a popup applet and debugging a bit, i also found that probably the following happens when running in plasma-desktop: 1. PopupApplet::popupEvent() arrives before popup gets WindowActivated event 2. I call setFocus() 3. Immediately after this eventloop delivers WindowActivated event ( for "dialog" widget inside popupapplet.cpp) 4. WindowActivated event gets inside a QGraphicsScene, after this scene sends FocusOut event to any active focus item inside it 5. FocusIn is sent to popupapplet's toplevel dialog, but my widget gets only FocusOut Somehow this doesn't happen for plasmoidviewer. Maybe order of Activation/FocusIn event differs there, dunno. Anyway, if someone has read until here, let me and with a question: What to do? :-) It might be a bug somewhere, it might be not. I'm not sure. I can't find a mechanism to defer my setFocus() until i know that popup dialog has been shown. I don't want to use a timer as that's not 100% fix and can lead to users noticing a slight delay. In the end I want to simply ensure that my widget will always have focus when shown in a popup. Is this possible? Is there some potential workaround you see? Thanks in advance, Dmitry. PS. If you want to look at the code it can be found here: http://websvn.kde.org/trunk/playground/base/klipper-ng/plasmoid/applet/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PopupApplet and setFocus() behaviour
Hi guys and girls! While making some progress on klipper engine+applet I discovered some oddities with focus behavior. I hope you can give me some hints about my situation (don't get scared by amount of text below, i tried to make it simple to follow). General layout of applet widgets is the following: Applet is a PopupApplet. It has a QGraphicsProxyWidget as graphicsWidget(), which has embedded QWidget (named KlipperWidget) which has a QListView inside (it displays clipboard history entries). What I'm trying to do is to make sure that this QListView will always have keyboard focus when popup is shown. I'm doing it by overriding a PopupApplet::popupEvent() and calling KlipperWidget's setFocus() function. KlipperWidget has a QListView set as a focus proxy for this to work. And it works... but only when I launch applet in "plasmoidviewer -f horizontal klipper". Problem: When applet is inside plasma-desktop, no focus gets set. I tried to debug this and found that when running as a part of plasma-desktop, QListView actually gets only FocusOut event, and not a single FocusIn. After looking through souces of a popup applet and debugging a bit, i also found that probably the following happens when running in plasma-desktop: 1. PopupApplet::popupEvent() arrives before popup gets WindowActivated event 2. I call setFocus() 3. Immediately after this eventloop delivers WindowActivated event ( for "dialog" widget inside popupapplet.cpp) 4. WindowActivated event gets inside a QGraphicsScene, after this scene sends FocusOut event to any active focus item inside it 5. FocusIn is sent to popupapplet's toplevel dialog, but my widget gets only FocusOut Somehow this doesn't happen for plasmoidviewer. Maybe order of Activation/FocusIn event differs there, dunno. Anyway, if someone has read until here, let me and with a question: What to do? :-) It might be a bug somewhere, it might be not. I'm not sure. I can't find a mechanism to defer my setFocus() until i know that popup dialog has been shown. I don't want to use a timer as that's not 100% fix and can lead to users noticing a slight delay. In the end I want to simply ensure that my widget will always have focus when shown in a popup. Is this possible? Is there some potential workaround you see? Thanks in advance, Dmitry. PS. If you want to look at the code it can be found here: http://websvn.kde.org/trunk/playground/base/klipper-ng/plasmoid/applet/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet and setFocus() behaviour
On Friday 14 August 2009 00:32:09 Marco Martin wrote: > On Thursday 13 August 2009, Dmitry Suzdalev wrote: > > Hi guys and girls! > > > > While making some progress on klipper engine+applet I discovered some > > oddities with focus behavior. I hope you can give me some hints about my > > situation (don't get scared by amount of text below, i tried to make it > > simple to follow). > > in the microblogging plasmoid the focus to the input field seems to be > correctly given. > it sets the focus to the input field in the focusIn event of the applet > (that always happens after a popup event) would be useful to you? I just tried that. This works ok when I invoke popup by clicking on the applet's icon in a panel - focus is set correctly. But if I assign a keyboard shortcut for the applet, focus isn't being set to my widget in focusInEvent(). On the contrary, if I use my previous method of calling setFocus() in a popupEvent(), this works when I trigger a popup by a shortcut, but doesn't work when I click on icon in panel :) Any ideas why is this so? > i am wondering if a setMainInputWidget() api call could be added to the > popupapplet api, if it's a common case enough If this is indeed a common case, that would be nice. Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet and setFocus() behaviour
On Tuesday 18 August 2009 02:20:25 Aaron J. Seigo wrote: > ugly; perhaps we should allow plasmoids to set a keyboard focus widget .. > thinks Yep, but the only workaround I found currently working is this: - In my KlipperApplet::focusInEvent() call mywidget->setFocus(). This ensures focus gets set when clicking on an icon in a panel with mouse. Or else I can't get the focus set right while clicking (at least in the ways i tried) - In KlipperApplet::popupEvent() call mywidget->setFocus() too. This ensures that focus gets set when invoking popup with a global shortcut assigned to it. If I'm not calling it here, focus doesn't get set on keyboard invocation of the popup. Yeah, these are workarounds, not very good. > actually, when a popup occurs, we should probably shift keyboard focus to t > he > first widget in the keyboard focus chain automatically. then it would simp > ly be up to you to ensure that the list view is the first item in the tab- > switching order :) Would be nice I think. But we'll need to ensure that focus gets set only after d->dialog inside a popupapplet will be activated. Or any other possible (temporary or offscreen for ex) widget on the scene. That is we don't wont a focusOut event coming to the widget right after we told it to focusIn :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- Review request for Plasma. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-18 21:59:39.951021) Review request for Plasma and Aaron Seigo. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs - trunk/KDE/kdelibs/plasma/delegate.h 1011618 trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
> On 2009-08-20 10:03:58, Aaron Seigo wrote: > > why isn't the model returning an appropriate negative value for the > > subtitle? This whole discussion raised because of this: by default, Plasma::Delegate has the policy of automatically adding subtitles if two adjasent items are of the same content. I questioned why this should be the default - for example while writing a klipper plasmoid I found this as a surprise - and we discussed the addition of such api. Though later (after i published the review), me and mart agreed that maybe it's not really necessary to have the api changed, maybe the only change in the end would be the addition of that part of logic which would not try to be that clever if QVariant() is returned for SubTitleMandatoryRole (i.e. if model doesn't implement returning something for this role). Otherwise it appears that model cannot have exact control where to show and where not to show title. For example, even if it implements returning 'true' for some items and 'false' for other items, the items with 'false' will still be auto-disambiguated inside a delegate. So the main point now is to leave only checking for data validity of SubTitleMandatoryRole, and do disambiguating *only* if model doesn't care. I've yet to update this review with the actual patch. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/#review2091 --- On 2009-08-18 21:59:39, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/1357/ > --- > > (Updated 2009-08-18 21:59:39) > > > Review request for Plasma and Aaron Seigo. > > > Summary > --- > > This adds more control of showing subtitles with Plasma::Delegate by adding a > setSubtitlePolicy() method to its API. > Discussed briefly on #plasma with notmart, now on to review :) > > > Diffs > - > > trunk/KDE/kdelibs/plasma/delegate.h 1011618 > trunk/KDE/kdelibs/plasma/delegate.cpp 1011618 > > Diff: http://reviewboard.kde.org/r/1357/diff > > > Testing > --- > > Tested with klipper applet by putting it in all modes possible (at least all > i can come up with :)) > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add setSubTitlePolicy() method to Plasma::Delegate
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1357/ --- (Updated 2009-08-21 15:50:26.488754) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- Updated patch as discussed with mart on irc: removed the API addition, left only logic that disables auto-addition of subtitles to non-unique items - disabling is done if model does provide some valid data for SubTitleMandatoryRole. This indicates model wants to have a full control for subtitle visibility. Summary --- This adds more control of showing subtitles with Plasma::Delegate by adding a setSubtitlePolicy() method to its API. Discussed briefly on #plasma with notmart, now on to review :) Diffs (updated) - trunk/KDE/kdelibs/plasma/delegate.h 1010706 trunk/KDE/kdelibs/plasma/delegate.cpp 1010706 Diff: http://reviewboard.kde.org/r/1357/diff Testing --- Tested with klipper applet by putting it in all modes possible (at least all i can come up with :)) Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/ --- Review request for Plasma. Summary --- This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager lib. Summary: When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of by_desktop+by_winTitle as it is now. More details: Currently in "by desktop" sorting mode tasks are sorted by desktop and then by name. This leads to inconvenient things, here are some examples: - I have a browser with several tabs open. Whenever I change a tab, browser changes window title. This makes task jump in a task bar from one position to another while I'm simply changing tabs. - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title is changed, task jumps - Some other situations caused this too, don't recall, but you got the idea :) What I've done: Instead of sorting by name, i made it to sort by winId. Tasks without winId are sorted out to the end of the list and sorted by name there. Typically these are the startup-in-progress items. As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: invalid sorting order due to wrong comparison of regular items with "starting up" items. Long description, short patch ;) This addresses bug 219528. https://bugs.kde.org/show_bug.cgi?id=219528 Diffs - trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp 1105743 Diff: http://reviewboard.kde.org/r/3375/diff Testing --- Tested on trunk. Task items retain their sort order, not reacting to title changes, charming :) It affects only task applets with sort mode set to "by desktop" Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
> On 2010-03-23 22:05:51, Aaron Seigo wrote: > > so essentially it removes any sorting within the desktop sorting. i'm fine > > with that change (though perhaps others will now complain ;), though i have > > some thoughts below. Hmm, I just realized that some people might like to keep tasks sub-sorted by name indeed. For some reason I don't care about that a bit, but otoh this constant "jumping" of tasks always made me eager to write this patch :) So now i'm really confused - will the majority of people be like me or the opposite? :) Usability advice needed. If i'm in the minority, then I guess I can perfectly keep these changes local > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 66 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line66> > > > > so window groups will shuffle randomly when windows leave or join or > > anything else that may cause winIds() to shift order. seems like trading > > one issue for another. > > > > i wonder if it wouldn't be nicer to have a stable way to identify > > AbstractGroupableTasks (a QUuid? or an integer based sequence?) for such > > occasions. > > > > that would also make things such as leftWinIdIsValid unecessary. the > > winId is just as random to the user; the only downside i can see is a small > > amount more memory consumption. Yes, this would be better indeed. In my klipper experiments i used QUuids to identify history items. but are there some downsides of simply assigning each new task an integer id++ as it's ID? That would be lighter that quuid :) > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 70 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line70> > > > > can be just "else if (leftWinIdIsValid)" since we know both aren't due > > to the initial if. yes, thanks > On 2010-03-23 22:05:51, Aaron Seigo wrote: > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp, > > line 78 > > <http://reviewboard.kde.org/r/3375/diff/2/?file=21517#file21517line78> > > > > why storing in a temp var which is returned? nice one :) will change. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/#review4637 --- On 2010-03-23 20:48:15, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3375/ > --- > > (Updated 2010-03-23 20:48:15) > > > Review request for Plasma. > > > Summary > --- > > This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager > lib. > > Summary: > When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of > by_desktop+by_winTitle as it is now. > > More details: > Currently in "by desktop" sorting mode tasks are sorted by desktop and then > by name. > This leads to inconvenient things, here are some examples: > > - I have a browser with several tabs open. Whenever I change a tab, browser > changes window title. > This makes task jump in a task bar from one position to another while I'm > simply changing tabs. > - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, > title is changed, task jumps > - Some other situations caused this too, don't recall, but you got the idea :) > > What I've done: > Instead of sorting by name, i made it to sort by winId. Tasks without winId > are sorted out to the end of the list > and sorted by name there. Typically these are the startup-in-progress items. > > As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 > which has the same roots: > invalid sorting order due to wrong comparison of regular items with "starting > up" items. > > Long description, short patch ;) > > > This addresses bug 219528. > https://bugs.kde.org/show_bug.cgi?id=219528 > > > Diffs > - > > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp > 1105743 > > Diff: http://reviewboard.kde.org/r/3375/diff > > > Testing > --- > > Tested on trunk. Task items retain their sort order, not reacting to title > changes, charming :) > > It affects only task applets with sort mode set to "by desktop" > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/ --- (Updated 2010-03-29 17:08:22.316461) Review request for Plasma. Changes --- Added an id() method to AbstractGroupableItem class which assigns a new int-based id to each new instance of the class. New id is based on a static field inside AbstractGroupableItem. Also note that winIds() stuff inside comparison function is still needed to correctly sort out startup tasks to the end of the list. If it won't be done, they'll spoil the party because having startup items in the middle of the list confuses layouting algorithm and makes the items "jump" as they get clicked. Summary --- This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager lib. Summary: When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of by_desktop+by_winTitle as it is now. More details: Currently in "by desktop" sorting mode tasks are sorted by desktop and then by name. This leads to inconvenient things, here are some examples: - I have a browser with several tabs open. Whenever I change a tab, browser changes window title. This makes task jump in a task bar from one position to another while I'm simply changing tabs. - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, title is changed, task jumps - Some other situations caused this too, don't recall, but you got the idea :) What I've done: Instead of sorting by name, i made it to sort by winId. Tasks without winId are sorted out to the end of the list and sorted by name there. Typically these are the startup-in-progress items. As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 which has the same roots: invalid sorting order due to wrong comparison of regular items with "starting up" items. Long description, short patch ;) This addresses bug 219528. https://bugs.kde.org/show_bug.cgi?id=219528 Diffs (updated) - trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1105271 trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp 1105271 trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp 1105271 Diff: http://reviewboard.kde.org/r/3375/diff Testing --- Tested on trunk. Task items retain their sort order, not reacting to title changes, charming :) It affects only task applets with sort mode set to "by desktop" Thanks, Dmitry ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3375/#review4742 --- trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h <http://reviewboard.kde.org/r/3375/#comment4263> Hmm, just thought that I probably should make it non-virtual. having it to be virtual might be useful, but it will break the guarantee of non-repeatable IDs that is currently provided by a base class. - Dmitry On 2010-03-29 17:08:22, Dmitry Suzdalev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3375/ > --- > > (Updated 2010-03-29 17:08:22) > > > Review request for Plasma. > > > Summary > --- > > This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager > lib. > > Summary: > When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of > by_desktop+by_winTitle as it is now. > > More details: > Currently in "by desktop" sorting mode tasks are sorted by desktop and then > by name. > This leads to inconvenient things, here are some examples: > > - I have a browser with several tabs open. Whenever I change a tab, browser > changes window title. > This makes task jump in a task bar from one position to another while I'm > simply changing tabs. > - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc, > title is changed, task jumps > - Some other situations caused this too, don't recall, but you got the idea :) > > What I've done: > Instead of sorting by name, i made it to sort by winId. Tasks without winId > are sorted out to the end of the list > and sorted by name there. Typically these are the startup-in-progress items. > > As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528 > which has the same roots: > invalid sorting order due to wrong comparison of regular items with "starting > up" items. > > Long description, short patch ;) > > > This addresses bug 219528. > https://bugs.kde.org/show_bug.cgi?id=219528 > > > Diffs > - > > trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h > 1105271 > trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp > 1105271 > > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp > 1105271 > > Diff: http://reviewboard.kde.org/r/3375/diff > > > Testing > --- > > Tested on trunk. Task items retain their sort order, not reacting to title > changes, charming :) > > It affects only task applets with sort mode set to "by desktop" > > > Thanks, > > Dmitry > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix taskmanager's "by desktop" sorting mode
> On 2010-03-29 18:34:53, Aaron Seigo wrote:
> > trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp,
> > lines 59-71
> > <http://reviewboard.kde.org/r/3375/diff/3/?file=21852#file21852line59>
> >
> > all of the winIds() stuff can be gotten rid of now that there is the
> > id() method. if winIds().isEmpty(), then desktop() is going to be 0. and
> > since the winIds() list isn't beig used, then it's probably enough to just
> > do this:
> >
> > const int leftDesktop = left->desktop();
> > const int rightDesktop = right->desktop();
> > if (leftDesktop() == rightDesktop) {
> > return left->id() < right->id();
> > }
> >
> > return leftDesktop < rightDesktop;
This really should work, but it doesn't. Exactly startup items pose the problem:
if they are not in the end of the *whole* list, then tasks layouting class
1) Sees that some new task (start up one) appeared in the middle of the list
and rearranges the items, reassigning their indexes
2) At the same time it tries to keep "startup items" in the end, and because of
this user observes "strange" moves of tasks in the middle, while startup ones
are still in the end (visually).
Putting startup tasks explicitly in the end of the list and ensuring they'll
always be there solves these problems.
But I guess the real fix should be in layouting classes in tasks applet, but
it's source is not so trivial, I need to study the code more.
So perhaps it'll need to wait to fix this in the right place.
I'll try to dig in and report when done :)
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3375/#review4747
---
On 2010-03-29 17:08:22, Dmitry Suzdalev wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3375/
> ---
>
> (Updated 2010-03-29 17:08:22)
>
>
> Review request for Plasma.
>
>
> Summary
> ---
>
> This patch fixes a sorting order for "Sort by Desktop" mode of taskmanager
> lib.
>
> Summary:
> When in "Sort by Desktop" mode, sort by_desktop+by_winId, instead of
> by_desktop+by_winTitle as it is now.
>
> More details:
> Currently in "by desktop" sorting mode tasks are sorted by desktop and then
> by name.
> This leads to inconvenient things, here are some examples:
>
> - I have a browser with several tabs open. Whenever I change a tab, browser
> changes window title.
> This makes task jump in a task bar from one position to another while I'm
> simply changing tabs.
> - I have a 'konsole' window and as I do 'cd onedir', 'cd zletter_dir', etc,
> title is changed, task jumps
> - Some other situations caused this too, don't recall, but you got the idea :)
>
> What I've done:
> Instead of sorting by name, i made it to sort by winId. Tasks without winId
> are sorted out to the end of the list
> and sorted by name there. Typically these are the startup-in-progress items.
>
> As a side effect this fixes bug https://bugs.kde.org/show_bug.cgi?id=219528
> which has the same roots:
> invalid sorting order due to wrong comparison of regular items with "starting
> up" items.
>
> Long description, short patch ;)
>
>
> This addresses bug 219528.
> https://bugs.kde.org/show_bug.cgi?id=219528
>
>
> Diffs
> -
>
> trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h
> 1105271
> trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.cpp
> 1105271
>
> trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/desktopsortingstrategy.cpp
> 1105271
>
> Diff: http://reviewboard.kde.org/r/3375/diff
>
>
> Testing
> ---
>
> Tested on trunk. Task items retain their sort order, not reacting to title
> changes, charming :)
>
> It affects only task applets with sort mode set to "by desktop"
>
>
> Thanks,
>
> Dmitry
>
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-windowed moved to kdereview
On Tuesday 27 April 2010 00:31:51 Aaron J. Seigo wrote: > hi all :) > > plasma-windowed is a helper application that run Plasma widgets in their > own windows. while a nice feature for the desktop, it's fill an important > role for the mobile shell: running widgets as full screen "apps". > > it has been moved into kdereview/plasma/shells/plasma-windowed > > the plan is to move it into kdebase/workspace/plasma/generic/shells/ wow that sounds like catching a two hares at once :) Nice feature(s) :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma applets inside QML applet
Djuro Drljaca написал(а):
Hello,
it would probably useful if you also provided an example where you want to use
this. I don't know enough about what this, but you will probably get better
information or even another way to do what you want to achieve if there is more
information on the background of the problem.
Regards,
Djuro Drljaca
On Sat, Jun 23, 2012 at 10:33 PM, Dmitry wrote:
Hello!
I'm developing an applet in QML. I need to load an external applet and to place
it into my applet like containment applet, like panel or system tray. But at
the same time my applet isn't a pure containment applet [it doesn't contain
only applets]. Do You know how I can do it or it's not possible?
I'd like to do like next:
Applet { // like Svg
id: battery_applet
name: "battery" // name of applet to be loaded (like argument of function
Plasma::Applet::load(name, ...) )
}
AppletItem { // like SvgItem
applet: battery_applet
width: 20
height: width
...
}
Thank you!
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Hello!
I'm trying to implement a system tray in QML. So, I have a trouble with applets
such as battery, notifier, notifications. They [applets] should be mixed with
icons of applications and tray must have an arrow to show popup dialog.
Thank you
--
Отправлено с мобильного телефона через К-9 Mail. Извините за краткость,
пожалуйста.___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #2
15.10.2012 20:20, Aaron J. Seigo ?: On Monday, October 15, 2012 19:20:13 Dmitry Ashkadov wrote: i do notice some small visual issues in the screenshots (thanks for providing those, btw!), mostly to do with spacing and margins in the popup. as you can see in image 05, there is not enough margin around the item and so the background item appears too close and even touches the icon. similarly, there should be a bit more space between the icon and the text imo (0.5 or even 1 em?) I'll compare it to C++ applet and try increase margins. case of C++ system tray applet. I can see many messages: .../apps/plasma/plasmoids/battery/contents/ui/batterymonitor.qml:183: TypeError: Result of expression 'pmSource.data["PowerDevil"]' hm.. and if you put the battery widget directly into the panel, or on the desktop or dashboard, it works? Battery works if I click on its icon, but if I click on name (text) then battery doesn't work. I think it is a regression, because I've found out several facts: * Old C++ tray has the same problem (git checkout master to switch to C++ tray) * Battery applet doesn't work but applet for Network manager works if I click on its name * KDE 4.8 is now system KDE and battery works as expected, but in locally installed KDE (master or 4.9) battery doesn't work, it doesn't work on KDE 4.9 -- future release of my distro. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #2
Hello! 15.10.2012 21:36, Marco Martin пишет: as aaron also noted, if the text is very large seems it can go out of boundaries (seen in http://wstaw.org/m/2012/10/15/plasma-desktopO28633.png), probably the popup should expand until a certain width in characters, and then elide the entries text if they are really too long. To compute width of popup window I use ListView.onAdd() and ListView.onRemove() attached signals. I thought that they are called every time an item is added or removed from ListView, but my assumption is wrong. Sometimes onAdd() and onRemove() isn't called. I have another idea how to compute width of popup window. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
SystemTray: QML version #3
Hello! I've made several changes to system tray with interface in QML (plasma/dmitrya/systemtray-qml branch of kde-workspace): * Now the arrow will hide if popup dialog contains no items * Some distances between items in popup dialog have been increased * A new approach to the problem of computing width of popup dialog has been implemented * Now the popup dialog will move to a new position if some item is added to popup dialog or removed from it I think some problems, you reported yesterday, must go away. Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #2
18.10.2012 22:29, Aaron J. Seigo пишет: On Wednesday, October 17, 2012 17:52:58 Dmitry Ashkadov wrote: 15.10.2012 20:20, Aaron J. Seigo ?: i do notice some small visual issues in the screenshots (thanks for providing those, btw!), mostly to do with spacing and margins in the popup. as you can see in image 05, there is not enough margin around the item and so the background item appears too close and even touches the icon. similarly, there should be a bit more space between the icon and the text imo (0.5 or even 1 em?) Hello! What do you think about next screenshots: Old system tray in C++New system tray in QML Left screenshot is old C++ system tray and right one is a screenshot of new QML system tray. looks terrific :) we should get this merged into master sooner rather than later. if it has all the features of the C++ one, i'd like to see that happen, well, tomorrow :) Hello! QML tray have all features of C++ tray. Should I write and send a review request? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Where should QML stuff be placed to?
Hello! I'm working on QML implementation of system tray for desktop. But I don't know where the QML stuff (files *.qml & *.js) should be placed to. I have found out that there are 3 places. Let be share directory for applications (usually it /usr/share/apps ) and be a name of application/plasmoid, so the possible places, I found out, are: 1. / 2. /plasma/plasmoids/ — as I know this is only for QML pure plasmoids 3. /plasma/packages/ So, where should the QML stuff be placed to in case of: 1. C++ applet with QML interface like system tray from kde-workspace (it consists of *.so library and QML stuff) 2. Simple pure QML applet (only *.qml & *.js files) 3. C++ applet with QML interface but from playground or isn't a part of KDE at all Thank you! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #2
19.10.2012 11:59, Marco Martin пишет: On Friday 19 October 2012, Dmitry Ashkadov wrote: we should get this merged into master sooner rather than later. if it has all the features of the C++ one, i'd like to see that happen, well, tomorrow :) Hello! QML tray have all features of C++ tray. Should I write and send a review request? a review request may be useful to quickly go over the code once more. would like to have it in next few days btw It may contain too large diff. Is it OK? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implementation of System tray in QML
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106965/ --- (Updated Oct. 22, 2012, 9:03 a.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- Group 'plasma' has been added Description --- Implementation of GUI part of System tray in QML. All code accessible from specified branch of kde-workspace Diffs - plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b plasma/generic/applets/systemtray/TODO 257fbe4 plasma/generic/applets/systemtray/config.h.in aac3113 plasma/generic/applets/systemtray/core/task.h 31d5949 plasma/generic/applets/systemtray/core/task.cpp 55c9a1a plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h aa6050e plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp f4e8424 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 2847b25 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp d4cb309 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h 0c6daf0 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp 33cf0b1 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368 plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp 8c1ebba plasma/generic/applets/systemtray/ui/applet.h d6cc509 plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a plasma/generic/applets/systemtray/ui/compactlayout.h c330cee plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff plasma/generic/applets/systemtray/ui/dialog.h PRE-CREATION plasma/generic/applets/systemtray/ui/dialog.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.h PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/taskarea.h 0e73ead plasma/generic/applets/systemtray/ui/taskarea.cpp 4c2d120 plasma/generic/applets/systemtray/ui/taskarea_p.h fc93661 plasma/generic/applets/systemtray/ui/taskspool.h PRE-CREATION plasma/generic/applets/systemtray/ui/taskspool.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.h PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/wheelarea.h PRE-CREATION plasma/generic/applets/systemtray/ui/wheelarea.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.h PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106965/diff/ Testing --- Screenshots --- Example http://git.reviewboard.kde.org/r/106965/s/788/ Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implementation of System tray in QML
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106965/ --- (Updated Oct. 22, 2012, 9:19 a.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- http://commits.kde.org/kde-workspace/e5e8469981a146247d906e69f7727f202fd38131 WheelArea has been replaced with org.kde.qtextracomponents.MouseEventListener Description --- Implementation of GUI part of System tray in QML. All code accessible from specified branch of kde-workspace Diffs (updated) - plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b plasma/generic/applets/systemtray/TODO 257fbe4 plasma/generic/applets/systemtray/config.h.in aac3113 plasma/generic/applets/systemtray/core/task.h 31d5949 plasma/generic/applets/systemtray/core/task.cpp 55c9a1a plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h aa6050e plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp f4e8424 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 2847b25 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp d4cb309 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h 0c6daf0 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp 33cf0b1 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368 plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp 8c1ebba plasma/generic/applets/systemtray/ui/applet.h d6cc509 plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a plasma/generic/applets/systemtray/ui/compactlayout.h c330cee plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff plasma/generic/applets/systemtray/ui/dialog.h PRE-CREATION plasma/generic/applets/systemtray/ui/dialog.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.h PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/taskarea.h 0e73ead plasma/generic/applets/systemtray/ui/taskarea.cpp 4c2d120 plasma/generic/applets/systemtray/ui/taskarea_p.h fc93661 plasma/generic/applets/systemtray/ui/taskspool.h PRE-CREATION plasma/generic/applets/systemtray/ui/taskspool.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.h PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.h PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106965/diff/ Testing --- Screenshots --- Example http://git.reviewboard.kde.org/r/106965/s/788/ Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implementation of System tray in QML
> On Oct. 20, 2012, 11:18 a.m., Marco Martin wrote:
> > plasma/generic/applets/systemtray/ui/wheelarea.h, line 1
> > <http://git.reviewboard.kde.org/r/106965/diff/1/?file=91357#file91357line1>
> >
> > this implementation is not necessary, a wheelevent was added in
> > org.kde.qtextracomponents in MouseEventListener
> >
> > the TODO of replacing this in qt5 stays, but is a c++ file less
> >
> > see
> > http://api.kde.org/4.x-api/kde-runtime-apidocs/plasma/html/classMouseEventListener.html
> > wheelEvent
OK, I have replaced WheelArea with MouseEventListener. But I have some
questions:
1. Does the workflow
(http://www.reviewboard.org/docs/manual/1.6/users/getting-started/workflow/)
oblige me to update full diff? It may difficalt to find changed in full diff.
2. Who have to click on "Fixed"/"Drop" buttons? On the one hand, who requires
changes should check changes and apply them or reject, on the second hand,
these buttons may notify review about fixed issue.
3. Some MouseEventListener's signals give objects named wheel or mouse, but
mouse.button/wheel.button have type QVariant, so it's impossible to use switch
(mouse.button) { case Qt.LeftButton: ... }. At the same time Qt's MouseArea has
different behaviour — switch (mouse.button) { case Qt.RightButton: ... } works
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106965/#review20597
---
On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106965/
> ---
>
> (Updated Oct. 22, 2012, 9:19 a.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Implementation of GUI part of System tray in QML. All code accessible from
> specified branch of kde-workspace
>
>
> Diffs
> -
>
> plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b
> plasma/generic/applets/systemtray/TODO 257fbe4
> plasma/generic/applets/systemtray/config.h.in aac3113
> plasma/generic/applets/systemtray/core/task.h 31d5949
> plasma/generic/applets/systemtray/core/task.cpp 55c9a1a
> plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml
> PRE-CREATION
>
> plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h
> aa6050e
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
> f4e8424
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h
> 2847b25
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp
> d4cb309
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h
> 0c6daf0
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp
> 33cf0b1
> plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368
> plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625
> plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120
> plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp
> 8c1ebba
> plasma/generic/applets/systemtray/ui/applet.h d6cc509
> plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a
> plasma/generic/applets/systemtray/ui/compactlayout.h c330cee
> plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff
> plasma/generic/applets/systemtray/ui/dialog.h PRE-CREATION
> plasma/generic/applets/systemtray/ui/dialog.cpp PRE-CREATION
> plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION
> plasma/generic/applets/systemtray/ui/mouseredirectarea.cp
Re: Review Request: Implementation of System tray in QML
> On Oct. 21, 2012, 12:14 a.m., Kai Uwe Broulik wrote: > > plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml, line 29 > > <http://git.reviewboard.kde.org/r/106965/diff/1/?file=91322#file91322line29> > > > > Can you make the size honour the global KDE icon size settings? This > > would fix a long standing wish Bug 133936, and more importantly: This will > > make the systray work on high-dpi monitors. > > We have SVG tray icons, so why not take advantage of this? Only > > drawback are XEmbed tray icons which cannot be scaled(?) since they are not > > actual icons, but I think they should be shown centered inside the bigger > > cell then. (and the only app I regularly use that still uses XEmbed is > > Skype) I can try do this, But how can user set size of icons? There is no such option now. I need to know how can I get size from KDE settings. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106965/#review20608 --- On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106965/ > --- > > (Updated Oct. 22, 2012, 9:19 a.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Implementation of GUI part of System tray in QML. All code accessible from > specified branch of kde-workspace > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b > plasma/generic/applets/systemtray/TODO 257fbe4 > plasma/generic/applets/systemtray/config.h.in aac3113 > plasma/generic/applets/systemtray/core/task.h 31d5949 > plasma/generic/applets/systemtray/core/task.cpp 55c9a1a > plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsList.js > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml > PRE-CREATION > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h > aa6050e > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp > f4e8424 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 2847b25 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > d4cb309 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h > 0c6daf0 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp > 33cf0b1 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp > 8c1ebba > plasma/generic/applets/systemtray/ui/applet.h d6cc509 > plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a > plasma/generic/applets/systemtray/ui/compactlayout.h c330cee > plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff > plasma/generic/applets/systemtray/ui/dialog.h PRE-CREATION > plasma/generic/applets/systemtray/ui/dialog.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION > plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/plasmoid.h PRE-CREATION > plasma/generic/applets/systemtray/ui/plasmoid.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/taskarea.h 0e73ead > plasma/generic/applets/systemtray/ui/taskarea.cpp 4c2d120 > plasma/generic/applets/systemtray/ui/taskarea_p.h fc93661 > plasma/generic/applets/systemtray/ui/taskspool.h PRE-CREATION > plasma/generic/applets/syst
Re: Review Request: Implementation of System tray in QML
> On Oct. 20, 2012, 11:18 a.m., Marco Martin wrote:
> > plasma/generic/applets/systemtray/ui/wheelarea.h, line 1
> > <http://git.reviewboard.kde.org/r/106965/diff/1/?file=91357#file91357line1>
> >
> > this implementation is not necessary, a wheelevent was added in
> > org.kde.qtextracomponents in MouseEventListener
> >
> > the TODO of replacing this in qt5 stays, but is a c++ file less
> >
> > see
> > http://api.kde.org/4.x-api/kde-runtime-apidocs/plasma/html/classMouseEventListener.html
> > wheelEvent
>
> Dmitry Ashkadov wrote:
> OK, I have replaced WheelArea with MouseEventListener. But I have some
> questions:
> 1. Does the workflow
> (http://www.reviewboard.org/docs/manual/1.6/users/getting-started/workflow/)
> oblige me to update full diff? It may difficalt to find changed in full diff.
> 2. Who have to click on "Fixed"/"Drop" buttons? On the one hand, who
> requires changes should check changes and apply them or reject, on the second
> hand, these buttons may notify review about fixed issue.
> 3. Some MouseEventListener's signals give objects named wheel or mouse,
> but mouse.button/wheel.button have type QVariant, so it's impossible to use
> switch (mouse.button) { case Qt.LeftButton: ... }. At the same time Qt's
> MouseArea has different behaviour — switch (mouse.button) { case
> Qt.RightButton: ... } works
>
> Marco Martin wrote:
> 1) yeah, sometimes is a bit of a mess.. a new diff from master should
> work tough (if is not possible to make a clean diff, just state that the
> branch has been updated accordingly)
> 2) for the issues on those comments, you can just mark them as fixed them
> after you made that change, to signal that.
> 3) that's weird, the mouse event object just exports buttons as
> Qt::MouseButton enum, like upstream mousearea does, something strange
> happening at binding level...
>
> anyways, mouseeventlistener should be used just when is really needed
> something that mousearea can't provide, that at the moment is:
> * wheel
> * screen coordinates for events
> * the main usecase of the class, litening to events that are happening to
> its children, but without interfering withthem in any way
>
3) I think that the difference in Q_PROPERTY(Qt::MouseButton button). In Qt
type int is used instead of Qt::MouseButton:
http://qt.gitorious.org/qt/qt/blobs/4.8/src/declarative/graphicsitems/qdeclarativeevents_p_p.h
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106965/#review20597
---
On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106965/
> ---
>
> (Updated Oct. 22, 2012, 9:19 a.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Implementation of GUI part of System tray in QML. All code accessible from
> specified branch of kde-workspace
>
>
> Diffs
> -
>
> plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b
> plasma/generic/applets/systemtray/TODO 257fbe4
> plasma/generic/applets/systemtray/config.h.in aac3113
> plasma/generic/applets/systemtray/core/task.h 31d5949
> plasma/generic/applets/systemtray/core/task.cpp 55c9a1a
> plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml
> PRE-CREATION
>
> plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h
> aa6050e
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
> f4e8424
>
> plasma/generic/applets/systemtra
Re: Review Request: Implementation of System tray in QML
> On Oct. 21, 2012, 12:14 a.m., Kai Uwe Broulik wrote:
> > plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml, line 29
> > <http://git.reviewboard.kde.org/r/106965/diff/1/?file=91322#file91322line29>
> >
> > Can you make the size honour the global KDE icon size settings? This
> > would fix a long standing wish Bug 133936, and more importantly: This will
> > make the systray work on high-dpi monitors.
> > We have SVG tray icons, so why not take advantage of this? Only
> > drawback are XEmbed tray icons which cannot be scaled(?) since they are not
> > actual icons, but I think they should be shown centered inside the bigger
> > cell then. (and the only app I regularly use that still uses XEmbed is
> > Skype)
>
> Dmitry Ashkadov wrote:
> I can try do this, But how can user set size of icons? There is no such
> option now. I need to know how can I get size from KDE settings.
>
> Kai Uwe Broulik wrote:
> Have a look at:
> http://www.purinchu.net/kdelibs-apidocs/kdeui/html/classKIconLoader.html
>
> IconSize(KIconLoader::Toolbar) should return a matching size as int.
> There is a KIconLoader::Panel but it is 32 by default and on my machine
> 48, whereas the Toolbar defaults to 22 which should match the current systray
> icons.
> Probably do a: if (IconSize… > 22) { use iconsize; } else { use default
> 24; }
>
> Marco Martin wrote:
> systray icons (as in xembed ones) can only be 24 pixels (in theory the
> spec says they should be resizable, in practice none are)
> nearest kiconloader size is 22 (SmallMedium) so is not really possible to
> not hardcode in this case
>
> they should be 24 or less (only statusnotifiers will be correctly resized
> in this case)
> in case of statusnotifiers the icons to be drawn 22 pixels
> (theme.smallMediumIconSize in qml) inside a 24x24 item
>
>
It would be better if Plasma::IconWidget has elementId property. I think, we
should consider addition of property elementId to Plasma::IconWidget. This can
simplify code of SystemTray. I don't want to write too much imperative code
because it makes QML like C++. The advantage of QML is its declarative style.
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106965/#review20608
---
On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106965/
> ---
>
> (Updated Oct. 22, 2012, 9:19 a.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Implementation of GUI part of System tray in QML. All code accessible from
> specified branch of kde-workspace
>
>
> Diffs
> -
>
> plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b
> plasma/generic/applets/systemtray/TODO 257fbe4
> plasma/generic/applets/systemtray/config.h.in aac3113
> plasma/generic/applets/systemtray/core/task.h 31d5949
> plasma/generic/applets/systemtray/core/task.cpp 55c9a1a
> plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml
> PRE-CREATION
>
> plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h
> aa6050e
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp
> f4e8424
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h
> 2847b25
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp
> d4cb309
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h
> 0c6daf0
>
> plasma/generic/app
Re: Review Request: Implementation of System tray in QML
> On Oct. 21, 2012, 12:14 a.m., Kai Uwe Broulik wrote:
> > plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml, line 29
> > <http://git.reviewboard.kde.org/r/106965/diff/1/?file=91322#file91322line29>
> >
> > Can you make the size honour the global KDE icon size settings? This
> > would fix a long standing wish Bug 133936, and more importantly: This will
> > make the systray work on high-dpi monitors.
> > We have SVG tray icons, so why not take advantage of this? Only
> > drawback are XEmbed tray icons which cannot be scaled(?) since they are not
> > actual icons, but I think they should be shown centered inside the bigger
> > cell then. (and the only app I regularly use that still uses XEmbed is
> > Skype)
>
> Dmitry Ashkadov wrote:
> I can try do this, But how can user set size of icons? There is no such
> option now. I need to know how can I get size from KDE settings.
>
> Kai Uwe Broulik wrote:
> Have a look at:
> http://www.purinchu.net/kdelibs-apidocs/kdeui/html/classKIconLoader.html
>
> IconSize(KIconLoader::Toolbar) should return a matching size as int.
> There is a KIconLoader::Panel but it is 32 by default and on my machine
> 48, whereas the Toolbar defaults to 22 which should match the current systray
> icons.
> Probably do a: if (IconSize… > 22) { use iconsize; } else { use default
> 24; }
>
> Marco Martin wrote:
> systray icons (as in xembed ones) can only be 24 pixels (in theory the
> spec says they should be resizable, in practice none are)
> nearest kiconloader size is 22 (SmallMedium) so is not really possible to
> not hardcode in this case
>
> they should be 24 or less (only statusnotifiers will be correctly resized
> in this case)
> in case of statusnotifiers the icons to be drawn 22 pixels
> (theme.smallMediumIconSize in qml) inside a 24x24 item
>
>
>
> Dmitry Ashkadov wrote:
> It would be better if Plasma::IconWidget has elementId property. I think,
> we should consider addition of property elementId to Plasma::IconWidget. This
> can simplify code of SystemTray. I don't want to write too much imperative
> code because it makes QML like C++. The advantage of QML is its declarative
> style.
Some application give only icon with fixed size and such applications cannot
handle size of icons in tray (:. So, applets may be resized, most default
statusnotify items may be resized, but other tasks has fixed size (or them has
discrete icon with small size or size of icon isn't possible to determine) (
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106965/#review20608
---
On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106965/
> ---
>
> (Updated Oct. 22, 2012, 9:19 a.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Implementation of GUI part of System tray in QML. All code accessible from
> specified branch of kde-workspace
>
>
> Diffs
> -
>
> plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b
> plasma/generic/applets/systemtray/TODO 257fbe4
> plasma/generic/applets/systemtray/config.h.in aac3113
> plasma/generic/applets/systemtray/core/task.h 31d5949
> plasma/generic/applets/systemtray/core/task.cpp 55c9a1a
> plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml
> PRE-CREATION
>
> plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml
> PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION
> plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h
> aa6050e
>
> plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotoco
Re: Review Request: Implementation of System tray in QML
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106965/#review20690 --- Since 4.9 it is possible to use special property windowId of org.kde.core.Dialog to hide dialog from taskbar. So, custom implementation of dialog may be removed. - Dmitry Ashkadov On Oct. 22, 2012, 9:19 a.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106965/ > --- > > (Updated Oct. 22, 2012, 9:19 a.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Implementation of GUI part of System tray in QML. All code accessible from > specified branch of kde-workspace > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b > plasma/generic/applets/systemtray/TODO 257fbe4 > plasma/generic/applets/systemtray/config.h.in aac3113 > plasma/generic/applets/systemtray/core/task.h 31d5949 > plasma/generic/applets/systemtray/core/task.cpp 55c9a1a > plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsList.js > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml > PRE-CREATION > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml > PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION > plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h > aa6050e > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp > f4e8424 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 2847b25 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > d4cb309 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h > 0c6daf0 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp > 33cf0b1 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp > 8c1ebba > plasma/generic/applets/systemtray/ui/applet.h d6cc509 > plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a > plasma/generic/applets/systemtray/ui/compactlayout.h c330cee > plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff > plasma/generic/applets/systemtray/ui/dialog.h PRE-CREATION > plasma/generic/applets/systemtray/ui/dialog.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION > plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/plasmoid.h PRE-CREATION > plasma/generic/applets/systemtray/ui/plasmoid.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/taskarea.h 0e73ead > plasma/generic/applets/systemtray/ui/taskarea.cpp 4c2d120 > plasma/generic/applets/systemtray/ui/taskarea_p.h fc93661 > plasma/generic/applets/systemtray/ui/taskspool.h PRE-CREATION > plasma/generic/applets/systemtray/ui/taskspool.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/uitask.h PRE-CREATION > plasma/generic/applets/systemtray/ui/uitask.cpp PRE-CREATION > plasma/generic/applets/systemtray/ui/widgetitem.h PRE-CREATION > plasma/generic/applets/systemtray/ui/widgetitem.cpp PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/106965/diff/ > > > Testing > --- > > > Screenshots > --- > > Example > http://git.reviewboard.kde.org/r/106965/s/788/ > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implementation of System tray in QML
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106965/ --- (Updated Oct. 22, 2012, 6:51 p.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- http://commits.kde.org/kde-workspace/c3e4327bf85a99a2fab67fa693091f8e393d3a4d Custom implementation of dialog has been dropped. Description --- Implementation of GUI part of System tray in QML. All code accessible from specified branch of kde-workspace Diffs (updated) - plasma/generic/applets/systemtray/CMakeLists.txt d3ce33b plasma/generic/applets/systemtray/TODO 257fbe4 plasma/generic/applets/systemtray/config.h.in aac3113 plasma/generic/applets/systemtray/core/task.h 31d5949 plasma/generic/applets/systemtray/core/task.cpp 55c9a1a plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsGrid.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TasksSet.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/TrayIcon.qml PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.js PRE-CREATION plasma/generic/applets/systemtray/package/contents/ui/main.qml PRE-CREATION plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.h aa6050e plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtrayprotocol.cpp f4e8424 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 2847b25 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp d4cb309 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.h 0c6daf0 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraywidget.cpp 33cf0b1 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 4cb5368 plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp 69cd625 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 3e8d120 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp 8c1ebba plasma/generic/applets/systemtray/ui/applet.h d6cc509 plasma/generic/applets/systemtray/ui/applet.cpp f3c6d9a plasma/generic/applets/systemtray/ui/compactlayout.h c330cee plasma/generic/applets/systemtray/ui/compactlayout.cpp e8d02ff plasma/generic/applets/systemtray/ui/mouseredirectarea.h PRE-CREATION plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.h PRE-CREATION plasma/generic/applets/systemtray/ui/plasmoid.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/taskarea.h 0e73ead plasma/generic/applets/systemtray/ui/taskarea.cpp 4c2d120 plasma/generic/applets/systemtray/ui/taskarea_p.h fc93661 plasma/generic/applets/systemtray/ui/taskspool.h PRE-CREATION plasma/generic/applets/systemtray/ui/taskspool.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.h PRE-CREATION plasma/generic/applets/systemtray/ui/uitask.cpp PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.h PRE-CREATION plasma/generic/applets/systemtray/ui/widgetitem.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/106965/diff/ Testing --- Screenshots --- Example http://git.reviewboard.kde.org/r/106965/s/788/ Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #3
22.10.2012 19:17, Luca Beltrame пишет: In data giovedì 18 ottobre 2012 09:50:49, Dmitry Ashkadov ha scritto: Hello, I've made several changes to system tray with interface in QML (plasma/dmitrya/systemtray-qml branch of kde-workspace): I've been playing with this for a bit and I noticed a regression with applications that paint over their tray icon (examples include kmail's unread mail count, or choqok's new post count): the icon does not change (i.e. nothing is painted over it). Not that it would be a showstopper for merging, but I thought I'd let you know: I will file a BR as reminder once it is merged. Hello! Thank you for your feedback. I never use clients for microblogging. But I tried setup kmail. It [kmail] doesn't show number of unread messages, it shows only dark blue circle. I've fixed this blue circle. Now blue circle of kmail works for me. Could you try choqok & kmail again? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #3
23.10.2012 12:44, Marco Martin пишет: On Tuesday 23 October 2012, Luca Beltrame wrote: In data martedì 23 ottobre 2012 12:28:44, Dmitry Ashkadov ha scritto: it shows only dark blue circle. I've fixed this blue circle. Now blue circle of kmail works for me. Could you try choqok& kmail again? I tried with Choqok and it works now. Thanks. i really think it should be merged now (today?) then problems fixed when they surface, but not delayed anymore So, should I merge it today into master? Should I use git merge or git rebase? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: SystemTray: QML version #3
23.10.2012 12:51, Marco Martin пишет: On Tuesday 23 October 2012, Dmitry Ashkadov wrote: 23.10.2012 12:44, Marco Martin пишет: On Tuesday 23 October 2012, Luca Beltrame wrote: In data martedì 23 ottobre 2012 12:28:44, Dmitry Ashkadov ha scritto: it shows only dark blue circle. I've fixed this blue circle. Now blue circle of kmail works for me. Could you try choqok& kmail again? I tried with Choqok and it works now. Thanks. i really think it should be merged now (today?) then problems fixed when they surface, but not delayed anymore So, should I merge it today into master? Should I use git merge or git rebase? yep, let's do that ;) git merge is fine. It has been shipped [in master]. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Possibility to set QIcon to PlasmaCore.Tooltip
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107013/ --- Review request for Plasma. Description --- PlasmaCore.Tooltip [org.kde.plasma.core] QML item can handle only name of icon. Some system tray tasks give QIcon as a tooltip icon. It would be better if Tooltip QML item can handle QIcon. Diffs - plasma/declarativeimports/core/tooltip.h 3c8a930 plasma/declarativeimports/core/tooltip.cpp 9f5836c Diff: http://git.reviewboard.kde.org/r/107013/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Possibility to change an element ID of svg image in IconWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107017/ --- Review request for Plasma. Description --- New System tray uses IconWidget QML item, but it isn't possible to set svg image with specified element id. Now I use Svg QML item to load svg and then pass icon to IconWidget, moreover svg is converted to pixmap (: . At the same time IconWidget can handle svg images, so these small changes make me happy :) because I will can eliminate usage of Svg QML items for arrow and Dbus tasks in system tray. Diffs - plasma/widgets/iconwidget.h 78f392e plasma/widgets/iconwidget.cpp a2092a4 Diff: http://git.reviewboard.kde.org/r/107017/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Possibility to change an element ID of svg image in IconWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107017/ --- (Updated Oct. 24, 2012, 10:50 a.m.) Review request for kdelibs and Plasma. Description --- New System tray uses IconWidget QML item, but it isn't possible to set svg image with specified element id. Now I use Svg QML item to load svg and then pass icon to IconWidget, moreover svg is converted to pixmap (: . At the same time IconWidget can handle svg images, so these small changes make me happy :) because I will can eliminate usage of Svg QML items for arrow and Dbus tasks in system tray. Diffs - plasma/widgets/iconwidget.h 78f392e plasma/widgets/iconwidget.cpp a2092a4 Diff: http://git.reviewboard.kde.org/r/107017/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Possibility to change an element ID of svg image in IconWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107017/ --- (Updated Oct. 24, 2012, 1:02 p.m.) Review request for kdelibs and Plasma. Changes --- IconWidget's properties 'svg' and 'elementId' should be independent Description --- New System tray uses IconWidget QML item, but it isn't possible to set svg image with specified element id. Now I use Svg QML item to load svg and then pass icon to IconWidget, moreover svg is converted to pixmap (: . At the same time IconWidget can handle svg images, so these small changes make me happy :) because I will can eliminate usage of Svg QML items for arrow and Dbus tasks in system tray. Diffs (updated) - plasma/widgets/iconwidget.h 78f392e plasma/widgets/iconwidget.cpp a2092a4 Diff: http://git.reviewboard.kde.org/r/107017/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Possibility to change an element ID of svg image in IconWidget
> On Oct. 25, 2012, 11:36 a.m., Aaron J. Seigo wrote: > > the real fix here is to not use IconWidget :) that's a QGraphicsWidget > > thing and will need to be replaced eventually anyways. > > > > this should be using the Button QML element, which does support using SVG > > files. IconWidget supports QAction so it's possible to handle global shortcuts. Does QML Button support QAction? Or is is another way to handle global shortcuts from QML? - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107017/#review20863 --- On Oct. 24, 2012, 1:02 p.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107017/ > --- > > (Updated Oct. 24, 2012, 1:02 p.m.) > > > Review request for kdelibs and Plasma. > > > Description > --- > > New System tray uses IconWidget QML item, but it isn't possible to set svg > image with specified element id. Now I use Svg QML item to load svg and then > pass icon to IconWidget, moreover svg is converted to pixmap (: . At the same > time IconWidget can handle svg images, so these small changes make me happy > :) because I will can eliminate usage of Svg QML items for arrow and Dbus > tasks in system tray. > > > Diffs > - > > plasma/widgets/iconwidget.h 78f392e > plasma/widgets/iconwidget.cpp a2092a4 > > Diff: http://git.reviewboard.kde.org/r/107017/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
26.10.2012 00:43, Aaron J. Seigo пишет: hi... i suppose this is mostly for Dmitry, but its nice to have these discussions here :) so .. system tray plasmoid. works pretty well it seems. :) Hello! Thank you for your questions! But first of all, I'd like to know what branch should I use to make some refactoring/changes? As I know today 4.10 branch must be created. I don't understand why every task can have different widgets for different hosts (applets): QHash widgetsByHost() const; Is it really possible to have few applets in one applet? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
26.10.2012 09:51, Luca Beltrame пишет: In data venerdì 26 ottobre 2012 09:40:25, Dmitry Ashkadov ha scritto: branch should I use to make some refactoring/changes? As I know today 4.10 branch must be created. Today marks the *soft* feature freeze: in other words, not yet frozen for new features, there's just a limit to new features being introduced (but these adjustments don't qualify IMO as completely new features). Hard feature freeze (a proper freeze, in that case) is later on. So for now I think you can work directly in master. Thank you for your answer. What workflow does KDE team use to bring changes from master branch to KDE4.X branch? For example, some fixes should be applied to master and KDE4.X branches at the same time. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
26.10.2012 10:50, Aaron J. Seigo пишет: On Friday, October 26, 2012 10:04:24 Dmitry Ashkadov wrote: Thank you for your answer. What workflow does KDE team use to bring changes from master branch to KDE4.X branch? For example, some fixes should be applied to master and KDE4.X branches at the same time. if they are bug fixes, then the preferred means is to do them in the latest stable branch (e.g. 4.10 or whatever) and then merge that into master; if merge fails due to conflicts (which often happens eventually over the course of a devel cycle) then we restor to cherry-picks from branch into master. Thank you! Is somebody who periodically merges KDE 4.X to master or it must be made by who fixes bug? If I do some refactoring what branch should I use? As I understand I should use master and my changes will be brought to next KDE release (4.11) only? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: qml systemtray: small refactorings
26.10.2012 12:38, Aaron J. Seigo пишет: On Friday, October 26, 2012 11:35:57 Dmitry Ashkadov wrote: Thank you! Is somebody who periodically merges KDE 4.X to master or it must be made by who fixes bug? the bug fixer; kdelibs is different -> it is merged periodically by someone (usually dfaure). hopefully in future all our core modules will be like this. but we're missing integration maintainers right now. i'm going to be dong this for plasma-mobile, btw, and when kde-workspace moves eventually to the future Frameworks 5 libraries i'd like at that point to also move kde-workspace to an "integration maintainer" style. but for now .. yes, it's up to each bug fixer (meh! :) If I do some refactoring what branch should I use? As I understand I should use master and my changes will be brought to next KDE release (4.11) only? master is still 4.10 .. 4.10 has not yet been branched and won't be until sometime around the Release Candidates in a couple months time. so just go to work in master; or better -> work in a local branch and when it's in good shape then merge your local branch into master and push to origin/master. i suggest this because it lets you quickly switch back to master without losing work and if your refactoring goes badly then you can just start again very easily :) this tends to be what i do in such situations and it has saved me lots of effort more than once! I thought that soft freeze ends with creating KDE4.10 branch... I'd like create new branch from master and delete old branch (plasma/dmitrya/systemtray-qml), but I can't delete old branch (: Remote git server refuses my attempts ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
Hello!
First of all, it a good idea!
1. I think you should explain why you have chosen such style instead of
another one. Your decision should be justified. For example: I don't
understand why you put brace on new line in case of function. As for me
it's terrible because I need always remember that there is one exception
for function definition and every time check functions. It's easier
remember that I must always put brace on the same line. At the same time
definition of function looks awfully against definitions of other items.
2. Why you put JS into code directory? IMHO, import "../../code/.."
looks awfully. Some JS can be an adjunct to QML file and cannot be used
outside of this QML file. Such JS can provide stuff for only one QML. To
simplify understanding such situation such JS and QML files may be named
similar: main.js & main.qml. And it may be better to put them into the
same directory.
3. What is better:
Variant 1:
Button.qml:
Button {
anchors.fill: parent
...
}
main.qml:
Item {
Button {}
}
Variant 2:
Button.qml:
Button {
...
}
main.qml:
Item {
Button {
anchors.fill: parent
}
}
Q: who is responsible to set geometry properties: parent or child ?
I think, parent. Child should use width and height only to draw itself.
4. What is about private functions? What is about private properties?
Should they go first or last in QML files? Should they have special naming?
5. Vim:
The {{{ and }}} are just for the sakes of vim's automatic folding.
Do we all use vim? I think no. So, we must never force developers use vim.
6.
i'm ok either way, but declared properties before geometry properties means we
need to alter nearly every single QML file to meet that guideline.
Let them be unchanged until somebody want to do it. Old code will always
stop you to make new code better. Refuse new code made in old style.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
30.10.2012 13:15, Aaron J. Seigo пишет:
On Tuesday, October 30, 2012 12:25:14 Dmitry Ashkadov wrote:
First of all, it a good idea!
:)
1. I think you should explain why you have chosen such style instead of
another one. Your decision should be justified.
this is the death of style guides. for many style decisions there is no
justification that can be made; it is simply a matter of custom and personal
taste. tabs vs spaces is the classic example.
I think you are wrong. Any decision has its justification. Fox example,
if you use spaces it may be due to old code.
Some JS can be an adjunct to QML file and cannot be used
outside of this QML file. Such JS can provide stuff for only one QML. To
should each QML file go into its own directory?
contents/main/main.qml
contents/main/main.js
contents/itemdelegate/delegate.qml
contents/itemdelegate/delegate.js
No, no, no.
contents/ui/main.qml
contents/ui/main.js
contents/ui/delegate.qml
contents/ui/delegate.js
contents/code/statelesslib.js
We see that main.qml and main.js, delegate.qml and delegate.js may be
considered in pairs. main.qml cannot exist without main.js. At the same time
there is statelesslib.js that may be shared between main.qml and delegate.qml
5. Vim:
The {{{ and }}} are just for the sakes of vim's automatic folding.
Do we all use vim? I think no. So, we must never force developers use vim.
i mostly agree :) i don't think this forces anyone to use vim, but i would
like to see a solution that works with katepart before adding it to the style
guide.
Do you want force developers use kate?
6.
i'm ok either way, but declared properties before geometry properties
means we need to alter nearly every single QML file to meet that
guideline.
Let them be unchanged until somebody want to do it. Old code will always
stop you to make new code better. Refuse new code made in old style.
so your vote is to live with it being inconsistent for now, and in new code
put geometry properties with the other inhereted properties, correct?
Current code may be unchanged for now.
I see 2 branches:
1. Developer can implement some item as a separate component (it must be
in separate file). It may be used from many QML files. Such item must
never set its geometry but very often such it declares its own
properties. And these public properties should, I think, go after id
property immediately, then should be declared public functions, signals
and then its implementation: subitems, states, etc.
2. Some item is an implementation of parent item (it usually should be
in the same QML file). In this case geometry properties usually defined
and there should be no declaration of properties (may be exceptions)
For example:
Button.qml: // separate component, use case: developer who want use
Button searches public interface (properties, functions, signals)
Button {
property string text
function setText()
{
}
signal ...
// usually geometry properties isn't defined
// but if it's really need they are part of implementation of
button and should be defined here
}
main.qml:
Item {
// Button is used for implementation, use case: developer tries to
understand implementation of parent item
Button {
anchors.fill: parent
text: "blablabla"
// property bool state // this property should not be declared,
it should be declared in Button.qml
}
}
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
30.10.2012 14:35, Aaron J. Seigo пишет:
5. Vim:
The {{{ and }}} are just for the sakes of vim's automatic folding.
Do we all use vim? I think no. So, we must never force developers use
vim.
i mostly agree :) i don't think this forces anyone to use vim, but i would
like to see a solution that works with katepart before adding it to the
style guide.
Do you want force developers use kate?
of course not :)
but i'd like to make the lives of people who use kate, vim, etc. easier if
possible. if we have to chose between "no one benefits from code folding" or
"some people get to benefit", we should pick "some people" every single time.
"some" is better than "none".
this does not prevent you from using any editor you wish -> you might not get
the cute little bonus of code folding, but otherwise it's the same as it is
right now already.
An editor should handle braces and provide folding functionality. I
don't think, that forcing all developer always put "{{{" and "}}}" in
addition to braces { }, is good idea.
6.
i'm ok either way, but declared properties before geometry properties
means we need to alter nearly every single QML file to meet that
guideline.
Let them be unchanged until somebody want to do it. Old code will always
stop you to make new code better. Refuse new code made in old style.
so your vote is to live with it being inconsistent for now, and in new
code
put geometry properties with the other inhereted properties, correct?
Current code may be unchanged for now.
I see 2 branches:
1. Developer can implement some item as a separate component (it must be
...
2. Some item is an implementation of parent item (it usually should be
this has nothing to do with parent-vs-child geometry setting. rather, when
geometry properties are set, where do they appear in that block? what you are
discussing is a separate topic, one that should go into a "best practices"
section (and i agree with you that setting it in the parent is usually better
than in the child)
what we're discussing is:
Item {
id: foo
anchors.fill: parent
signal foo
property bar: true
inheritedProperty: false
}
vs
Item {
id: foo
signal foo
property bar: true
anchors.fill: parent
inheritedProperty: false
}
Let it be first (geometry goes first):
Item {
id: foo
anchors.fill: parent
signal foo
property bar: true
inheritedProperty: false
}
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
30.10.2012 16:01, Sebastian Kügler пишет: There, the JS code should probably be in the QML file itself, as that's the only place where it's used. For the shared code, you'd import: import "plasmapackage:/code/statelesslib.js" as StatelessLib There is page in documentation http://qt-project.org/doc/qt-4.8/qml-variant.html A problem is next: I need have some variable of some type like list, I need have access to it from QML and it should be possible to change items of this list (variable). A variant: property variant myList: [] // doesn't work as expected So, how can I do this in QML? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
30.10.2012 17:20, Marco Martin пишет: On Tuesday 30 October 2012, Dmitry Ashkadov wrote: 30.10.2012 16:01, Sebastian Kügler пишет: There, the JS code should probably be in the QML file itself, as that's the only place where it's used. For the shared code, you'd import: import "plasmapackage:/code/statelesslib.js" as StatelessLib There is page in documentation http://qt-project.org/doc/qt-4.8/qml-variant.html A problem is next: I need have some variable of some type like list, I need have access to it from QML and it should be possible to change items of this list (variable). A variant: property variant myList: [] // doesn't work as expected So, how can I do this in QML? yep, that is a known problem of qml, luckily in qml2 there will be Array and Object types for properties. in the meantime, semms the only reliable way to have kind of js arrays as properties is to put them in an imported .js file So, yes, no need put QML and JS together more. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML style guide
30.10.2012 21:33, Martin Gräßlin пишет:
On Tuesday 30 October 2012 18:16:26 Aurélien Gâteau wrote:
The only part I don't really like is putting left curly brace on its own
line for functions because:
- having different conventions for event-handlers and function code blocks
look inconsistent
- it differs from many coding styles: Qt QML JavaScript, Douglas Crockford,
jQuery, Node... so I think it is going to look odd and unfamiliar to many
newcomers.
+1 - I am even not sure whether putting curly brace on new line is JSLint
compliant in this case.
+1 for brace on the same line for JS. jslint.com: Expected exactly one
space between ')' and '{'.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/ --- Review request for Plasma, Aaron J. Seigo and Marco Martin. Description --- Aaron has noticed in his mail to plasma-devel that the system tray requires some refactoring. This is a first step of refactoring. If it is approved I'll continue work on system tray. Diffs - plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 plasma/generic/applets/systemtray/core/manager.h 3b6b6f8 plasma/generic/applets/systemtray/core/manager.cpp c23225e plasma/generic/applets/systemtray/core/task.h 66bf6e1 plasma/generic/applets/systemtray/core/task.cpp 8754785 plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml 27d476a plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 34aae74 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp 6364272 plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.h b006967 plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.cpp c1bb8b1 plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.h c86a2d5 plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp 4257202 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp d1a18df plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp 761a62f plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtaskprotocol.cpp 505e0c4 plasma/generic/applets/systemtray/ui/applet.h bab8d9c plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d plasma/generic/applets/systemtray/ui/uitask.h 7b20bde plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 Diff: http://git.reviewboard.kde.org/r/107160/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 1, 2012, 9:47 a.m., Aaron J. Seigo wrote: > > plasma/generic/applets/systemtray/core/manager.h, line 54 > > <http://git.reviewboard.kde.org/r/107160/diff/1/?file=93099#file93099line54> > > > > the manager is shared across all instances of the system tray plasmoid. > > (look for s_manager) this keeps memory usage and dbus activity down. so > > this approach can not work. So, task will have no widget property and WidgetItem will know about Task (not only QGraphicsWidget). - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/#review21280 ------- On Oct. 31, 2012, 7 p.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107160/ > --- > > (Updated Oct. 31, 2012, 7 p.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Aaron has noticed in his mail to plasma-devel that the system tray requires > some refactoring. This is a first step of refactoring. If it is approved I'll > continue work on system tray. > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 > plasma/generic/applets/systemtray/core/manager.h 3b6b6f8 > plasma/generic/applets/systemtray/core/manager.cpp c23225e > plasma/generic/applets/systemtray/core/task.h 66bf6e1 > plasma/generic/applets/systemtray/core/task.cpp 8754785 > plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > 27d476a > plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 34aae74 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > 6364272 > plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.h b006967 > plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.cpp c1bb8b1 > plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.h > c86a2d5 > plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp > 4257202 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp d1a18df > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp > 761a62f > > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtaskprotocol.cpp > 505e0c4 > plasma/generic/applets/systemtray/ui/applet.h bab8d9c > plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 > plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b > plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 > plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 > plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d > plasma/generic/applets/systemtray/ui/uitask.h 7b20bde > plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 > plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d > plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 > > Diff: http://git.reviewboard.kde.org/r/107160/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 1, 2012, 9:47 a.m., Aaron J. Seigo wrote: > > plasma/generic/applets/systemtray/core/manager.h, line 54 > > <http://git.reviewboard.kde.org/r/107160/diff/1/?file=93099#file93099line54> > > > > the manager is shared across all instances of the system tray plasmoid. > > (look for s_manager) this keeps memory usage and dbus activity down. so > > this approach can not work. > > Dmitry Ashkadov wrote: > So, task will have no widget property and WidgetItem will know about Task > (not only QGraphicsWidget). And does somebody really need 2 or more trays ? And I don't know will X11 tasks be shown by all trays at the same time? - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/#review21280 ------- On Oct. 31, 2012, 7 p.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107160/ > --- > > (Updated Oct. 31, 2012, 7 p.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Aaron has noticed in his mail to plasma-devel that the system tray requires > some refactoring. This is a first step of refactoring. If it is approved I'll > continue work on system tray. > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 > plasma/generic/applets/systemtray/core/manager.h 3b6b6f8 > plasma/generic/applets/systemtray/core/manager.cpp c23225e > plasma/generic/applets/systemtray/core/task.h 66bf6e1 > plasma/generic/applets/systemtray/core/task.cpp 8754785 > plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > 27d476a > plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 34aae74 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.cpp > 6364272 > plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.h b006967 > plasma/generic/applets/systemtray/protocols/fdo/fdoprotocol.cpp c1bb8b1 > plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.h > c86a2d5 > plasma/generic/applets/systemtray/protocols/fdo/fdoselectionmanager.cpp > 4257202 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.cpp d1a18df > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp > 761a62f > > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtaskprotocol.cpp > 505e0c4 > plasma/generic/applets/systemtray/ui/applet.h bab8d9c > plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 > plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b > plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 > plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 > plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d > plasma/generic/applets/systemtray/ui/uitask.h 7b20bde > plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 > plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d > plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 > > Diff: http://git.reviewboard.kde.org/r/107160/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/ --- (Updated Nov. 2, 2012, 12:40 p.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- I've made last 2 commits in another way described by Aaron. So, new diff and new branch plasma/dmitrya/systemtray-refactoring-2. Description --- Aaron has noticed in his mail to plasma-devel that the system tray requires some refactoring. This is a first step of refactoring. If it is approved I'll continue work on system tray. Diffs (updated) - plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 plasma/generic/applets/systemtray/core/task.h 66bf6e1 plasma/generic/applets/systemtray/core/task.cpp 8754785 plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml 27d476a plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 34aae74 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 plasma/generic/applets/systemtray/ui/applet.h bab8d9c plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 plasma/generic/applets/systemtray/ui/mouseredirectarea.h 91c40c0 plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp aac2a53 plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d plasma/generic/applets/systemtray/ui/uitask.h 7b20bde plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 Diff: http://git.reviewboard.kde.org/r/107160/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 6, 2012, 1:39 p.m., Aaron J. Seigo wrote: > > one small issue with where hiding status is kept. > > > > it may be useful to keep in mind the difference between the data and the > > visualization -> anything that the use can see (e.g. whether an icon is > > hidden or not) is visualization and must not be in the data classes; but > > any data that is used to populate the visualization (e.g. the current > > attention status of an item) should be handled by the data classes. this > > data/visualization split is common in plasma, and once one gets used to it > > things become easier :) > > > > anyways.. this one small change of moving the hiding status from Task to > > WidgetItem and this can be pushed into master :) > > > > thanks ... Moving hiding property from Task to WidgetItem won't work, because it is used in QML to determine the location/area where the task will be placed (popup dialog or panel). - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/#review21486 --- On Nov. 2, 2012, 12:40 p.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107160/ > --- > > (Updated Nov. 2, 2012, 12:40 p.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Aaron has noticed in his mail to plasma-devel that the system tray requires > some refactoring. This is a first step of refactoring. If it is approved I'll > continue work on system tray. > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 > plasma/generic/applets/systemtray/core/task.h 66bf6e1 > plasma/generic/applets/systemtray/core/task.cpp 8754785 > plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > 27d476a > plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 34aae74 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 > plasma/generic/applets/systemtray/ui/applet.h bab8d9c > plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 > plasma/generic/applets/systemtray/ui/mouseredirectarea.h 91c40c0 > plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp aac2a53 > plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b > plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 > plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 > plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d > plasma/generic/applets/systemtray/ui/uitask.h 7b20bde > plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 > plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d > plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 > > Diff: http://git.reviewboard.kde.org/r/107160/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 6, 2012, 1:39 p.m., Aaron J. Seigo wrote: > > one small issue with where hiding status is kept. > > > > it may be useful to keep in mind the difference between the data and the > > visualization -> anything that the use can see (e.g. whether an icon is > > hidden or not) is visualization and must not be in the data classes; but > > any data that is used to populate the visualization (e.g. the current > > attention status of an item) should be handled by the data classes. this > > data/visualization split is common in plasma, and once one gets used to it > > things become easier :) > > > > anyways.. this one small change of moving the hiding status from Task to > > WidgetItem and this can be pushed into master :) > > > > thanks ... > > Dmitry Ashkadov wrote: > Moving hiding property from Task to WidgetItem won't work, because it is > used in QML to determine the location/area where the task will be placed > (popup dialog or panel). And this is a reason to create UiTask for visualization: Task - data, UiTask - visualization - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/#review21486 --- On Nov. 2, 2012, 12:40 p.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107160/ > --- > > (Updated Nov. 2, 2012, 12:40 p.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Aaron has noticed in his mail to plasma-devel that the system tray requires > some refactoring. This is a first step of refactoring. If it is approved I'll > continue work on system tray. > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 > plasma/generic/applets/systemtray/core/task.h 66bf6e1 > plasma/generic/applets/systemtray/core/task.cpp 8754785 > plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 > > plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml > 27d476a > plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 > > plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h > 34aae74 > plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 > plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 > plasma/generic/applets/systemtray/ui/applet.h bab8d9c > plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 > plasma/generic/applets/systemtray/ui/mouseredirectarea.h 91c40c0 > plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp aac2a53 > plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b > plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 > plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 > plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d > plasma/generic/applets/systemtray/ui/uitask.h 7b20bde > plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 > plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d > plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 > > Diff: http://git.reviewboard.kde.org/r/107160/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: SystemTray: Removing IconWidget for an arrow
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107239/ --- Review request for Plasma, Aaron J. Seigo and Marco Martin. Description --- IconWidget should be removed from QML. It may be replaced with SvgItem for an arrow. Diffs - plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml a3d7f39 Diff: http://git.reviewboard.kde.org/r/107239/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 6, 2012, 1:39 p.m., Aaron J. Seigo wrote:
> > one small issue with where hiding status is kept.
> >
> > it may be useful to keep in mind the difference between the data and the
> > visualization -> anything that the use can see (e.g. whether an icon is
> > hidden or not) is visualization and must not be in the data classes; but
> > any data that is used to populate the visualization (e.g. the current
> > attention status of an item) should be handled by the data classes. this
> > data/visualization split is common in plasma, and once one gets used to it
> > things become easier :)
> >
> > anyways.. this one small change of moving the hiding status from Task to
> > WidgetItem and this can be pushed into master :)
> >
> > thanks ...
>
> Dmitry Ashkadov wrote:
> Moving hiding property from Task to WidgetItem won't work, because it is
> used in QML to determine the location/area where the task will be placed
> (popup dialog or panel).
>
> Dmitry Ashkadov wrote:
> And this is a reason to create UiTask for visualization: Task - data,
> UiTask - visualization
>
> Aaron J. Seigo wrote:
> WidgetItem is that same thing, however.
>
> right now in the code there is the getLocationForTask function. it does
> this:
>
>
> var loc = getDefaultLocationForTask(task)
> if (loc === JS.LOCATION_TRAY && task.typeId ==
> JS.TASK_NOTIFICATIONS_TYPEID)
> return JS.LOCATION_NOTIFICATION // redefine location for
> notifications applet
> return loc
>
> getDefaultLocationForTask is:
>
> /// Returns location depending on status and hide state of task
> function getDefaultLocationForTask(task) {
> if (task.status === TaskStatusAttention || task.hideState ===
> TaskHideStateShown) return JS.LOCATION_TRAY
> if (task.hideState === TaskHideStateHidden || (task.status !==
> TaskStatusActive && task.status !== TaskStatusUnknown)) {
> return JS.LOCATION_POPUP
> }
> return JS.LOCATION_TRAY
> }
>
>
> in all cases where this is used, the code already has a WidgetItem or a
> StatusNotifierItem. so getDefaultLocationForTask could just as easily take a
> WidgetItem or a StatusNotifierItem and these (C++) classes could provide the
> same function as Task::visibilityPreference().
>
> the onVisibilityPreference signal is also used only in WidgetItem and
> StatusNotifierItem .. so they could just as well do that internally in the
> C++. i don't see anywhere that needs this information that does not already
> have a WidgetItem or a StatusNotifierItem?
QML is intended to provide a simple way to describe GUI and GUI logic. No more.
C++ code provides user's preference about visibility of task: he can want to
see item always or not. But the real responsibility for visibility of task
belongs to GUI logic (QML code). QML code handles changing of status of task,
takes a decision on location (popup/panel) of task. GUI part/QML code is a
representation of tray tasks and it may not take into account user's preference
at all. So, I don't want split GUI logic, I don't want duplicate the same code
in StatusNotifierItem and WidgetItem. Moreover StatusNotifierItem is
implemented in QML.
I think C++ should provide user's preference and signal if he changes his
preference.
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107160/#review21486
---
On Nov. 2, 2012, 12:40 p.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107160/
> ---
>
> (Updated Nov. 2, 2012, 12:40 p.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Aaron has noticed in his mail to plasma-devel that the system tray requires
> some refactoring. This is a first step of refactoring. If it is approved I'll
> continue work on system tray.
>
>
> Diffs
> -
>
> plasma/generic/applets/systemtray/CMakeLists.txt d3478a8
> plasma/generic/applets/systemtray/core/task.h 66bf6e1
> plasma/generic/applets/systemtray/core/task.cpp 8754785
> plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd
> plasma/generic/applets/systemtray/package/cont
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107160/ --- (Updated Nov. 7, 2012, 3:20 p.m.) Review request for Plasma, Aaron J. Seigo and Marco Martin. Changes --- Visibility preference is not a property of Task. Description --- Aaron has noticed in his mail to plasma-devel that the system tray requires some refactoring. This is a first step of refactoring. If it is approved I'll continue work on system tray. Diffs (updated) - plasma/generic/applets/systemtray/CMakeLists.txt d3478a8 plasma/generic/applets/systemtray/core/task.h 66bf6e1 plasma/generic/applets/systemtray/core/task.cpp 8754785 plasma/generic/applets/systemtray/package/contents/code/main.js 10518cd plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml f251cc5 plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml 27d476a plasma/generic/applets/systemtray/package/contents/ui/main.qml f80abc7 plasma/generic/applets/systemtray/protocols/dbussystemtray/dbussystemtraytask.h 34aae74 plasma/generic/applets/systemtray/protocols/fdo/fdotask.h 85a9ec5 plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.h 1913986 plasma/generic/applets/systemtray/ui/applet.h bab8d9c plasma/generic/applets/systemtray/ui/applet.cpp 41efb10 plasma/generic/applets/systemtray/ui/mouseredirectarea.h 91c40c0 plasma/generic/applets/systemtray/ui/mouseredirectarea.cpp aac2a53 plasma/generic/applets/systemtray/ui/plasmoid.h 01a7c5b plasma/generic/applets/systemtray/ui/plasmoid.cpp d3e1937 plasma/generic/applets/systemtray/ui/taskspool.h 4b5bcd4 plasma/generic/applets/systemtray/ui/taskspool.cpp df39e3d plasma/generic/applets/systemtray/ui/uitask.h 7b20bde plasma/generic/applets/systemtray/ui/uitask.cpp 2a15800 plasma/generic/applets/systemtray/ui/widgetitem.h 40aa92d plasma/generic/applets/systemtray/ui/widgetitem.cpp 9d2c622 Diff: http://git.reviewboard.kde.org/r/107160/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 6, 2012, 1:39 p.m., Aaron J. Seigo wrote:
> > one small issue with where hiding status is kept.
> >
> > it may be useful to keep in mind the difference between the data and the
> > visualization -> anything that the use can see (e.g. whether an icon is
> > hidden or not) is visualization and must not be in the data classes; but
> > any data that is used to populate the visualization (e.g. the current
> > attention status of an item) should be handled by the data classes. this
> > data/visualization split is common in plasma, and once one gets used to it
> > things become easier :)
> >
> > anyways.. this one small change of moving the hiding status from Task to
> > WidgetItem and this can be pushed into master :)
> >
> > thanks ...
>
> Dmitry Ashkadov wrote:
> Moving hiding property from Task to WidgetItem won't work, because it is
> used in QML to determine the location/area where the task will be placed
> (popup dialog or panel).
>
> Dmitry Ashkadov wrote:
> And this is a reason to create UiTask for visualization: Task - data,
> UiTask - visualization
>
> Aaron J. Seigo wrote:
> WidgetItem is that same thing, however.
>
> right now in the code there is the getLocationForTask function. it does
> this:
>
>
> var loc = getDefaultLocationForTask(task)
> if (loc === JS.LOCATION_TRAY && task.typeId ==
> JS.TASK_NOTIFICATIONS_TYPEID)
> return JS.LOCATION_NOTIFICATION // redefine location for
> notifications applet
> return loc
>
> getDefaultLocationForTask is:
>
> /// Returns location depending on status and hide state of task
> function getDefaultLocationForTask(task) {
> if (task.status === TaskStatusAttention || task.hideState ===
> TaskHideStateShown) return JS.LOCATION_TRAY
> if (task.hideState === TaskHideStateHidden || (task.status !==
> TaskStatusActive && task.status !== TaskStatusUnknown)) {
> return JS.LOCATION_POPUP
> }
> return JS.LOCATION_TRAY
> }
>
>
> in all cases where this is used, the code already has a WidgetItem or a
> StatusNotifierItem. so getDefaultLocationForTask could just as easily take a
> WidgetItem or a StatusNotifierItem and these (C++) classes could provide the
> same function as Task::visibilityPreference().
>
> the onVisibilityPreference signal is also used only in WidgetItem and
> StatusNotifierItem .. so they could just as well do that internally in the
> C++. i don't see anywhere that needs this information that does not already
> have a WidgetItem or a StatusNotifierItem?
>
> Dmitry Ashkadov wrote:
> QML is intended to provide a simple way to describe GUI and GUI logic. No
> more.
> C++ code provides user's preference about visibility of task: he can want
> to see item always or not. But the real responsibility for visibility of task
> belongs to GUI logic (QML code). QML code handles changing of status of task,
> takes a decision on location (popup/panel) of task. GUI part/QML code is a
> representation of tray tasks and it may not take into account user's
> preference at all. So, I don't want split GUI logic, I don't want duplicate
> the same code in StatusNotifierItem and WidgetItem. Moreover
> StatusNotifierItem is implemented in QML.
> I think C++ should provide user's preference and signal if he changes his
> preference.
I think Plasmoid class may be merged to Applet. If formFactor and location
properties were implemented in Plasma::Applet, I would remove them from
Plasmoid class during merging.
- Dmitry
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107160/#review21486
---
On Nov. 7, 2012, 3:20 p.m., Dmitry Ashkadov wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107160/
> ---
>
> (Updated Nov. 7, 2012, 3:20 p.m.)
>
>
> Review request for Plasma, Aaron J. Seigo and Marco Martin.
>
>
> Description
> ---
>
> Aaron has noticed in his mail to plasma-devel that the system tray requires
> some refactoring. This is a first step of refactoring. If it is approved I'll
> continue work on system tray.
>
>
> Diffs
> -
>
> plasma/generic/applets/system
Re: Review Request: SystemTray: Refactoring: UiTask and TasksPool have been removed
> On Nov. 6, 2012, 1:39 p.m., Aaron J. Seigo wrote:
> > one small issue with where hiding status is kept.
> >
> > it may be useful to keep in mind the difference between the data and the
> > visualization -> anything that the use can see (e.g. whether an icon is
> > hidden or not) is visualization and must not be in the data classes; but
> > any data that is used to populate the visualization (e.g. the current
> > attention status of an item) should be handled by the data classes. this
> > data/visualization split is common in plasma, and once one gets used to it
> > things become easier :)
> >
> > anyways.. this one small change of moving the hiding status from Task to
> > WidgetItem and this can be pushed into master :)
> >
> > thanks ...
>
> Dmitry Ashkadov wrote:
> Moving hiding property from Task to WidgetItem won't work, because it is
> used in QML to determine the location/area where the task will be placed
> (popup dialog or panel).
>
> Dmitry Ashkadov wrote:
> And this is a reason to create UiTask for visualization: Task - data,
> UiTask - visualization
>
> Aaron J. Seigo wrote:
> WidgetItem is that same thing, however.
>
> right now in the code there is the getLocationForTask function. it does
> this:
>
>
> var loc = getDefaultLocationForTask(task)
> if (loc === JS.LOCATION_TRAY && task.typeId ==
> JS.TASK_NOTIFICATIONS_TYPEID)
> return JS.LOCATION_NOTIFICATION // redefine location for
> notifications applet
> return loc
>
> getDefaultLocationForTask is:
>
> /// Returns location depending on status and hide state of task
> function getDefaultLocationForTask(task) {
> if (task.status === TaskStatusAttention || task.hideState ===
> TaskHideStateShown) return JS.LOCATION_TRAY
> if (task.hideState === TaskHideStateHidden || (task.status !==
> TaskStatusActive && task.status !== TaskStatusUnknown)) {
> return JS.LOCATION_POPUP
> }
> return JS.LOCATION_TRAY
> }
>
>
> in all cases where this is used, the code already has a WidgetItem or a
> StatusNotifierItem. so getDefaultLocationForTask could just as easily take a
> WidgetItem or a StatusNotifierItem and these (C++) classes could provide the
> same function as Task::visibilityPreference().
>
> the onVisibilityPreference signal is also used only in WidgetItem and
> StatusNotifierItem .. so they could just as well do that internally in the
> C++. i don't see anywhere that needs this information that does not already
> have a WidgetItem or a StatusNotifierItem?
>
> Dmitry Ashkadov wrote:
> QML is intended to provide a simple way to describe GUI and GUI logic. No
> more.
> C++ code provides user's preference about visibility of task: he can want
> to see item always or not. But the real responsibility for visibility of task
> belongs to GUI logic (QML code). QML code handles changing of status of task,
> takes a decision on location (popup/panel) of task. GUI part/QML code is a
> representation of tray tasks and it may not take into account user's
> preference at all. So, I don't want split GUI logic, I don't want duplicate
> the same code in StatusNotifierItem and WidgetItem. Moreover
> StatusNotifierItem is implemented in QML.
> I think C++ should provide user's preference and signal if he changes his
> preference.
>
> Dmitry Ashkadov wrote:
> I think Plasmoid class may be merged to Applet. If formFactor and
> location properties were implemented in Plasma::Applet, I would remove them
> from Plasmoid class during merging.
>
> Aaron J. Seigo wrote:
> "I don't want duplicate the same code in StatusNotifierItem and
> WidgetItem."
>
> they could share the code by creating a common super-class that they both
> subclass. alternatively, you could create a small C++ class that only tracks
> this one visibility property and create one as a property in each
> StatusNotifierItem or WidgetItem
>
> "Moreover StatusNotifierItem is implemented in QML."
>
> the visbility property class would resolve that; or it can be done in C++
> as WidgetItem was. probably the visbility property object is easiest and the
> overhead is pretty low.
>
> "I don't want split GUI logic"
>
> sorry, but this is not optional. putting this GUI property in Task breaks
> the system tray as you can no
Review Request: Class Plasmoid is merged to SystemTray::Applet
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107262/ --- Review request for Plasma, Aaron J. Seigo and Marco Martin. Description --- Special class Plasmoid no more need, for QML code SystemTray::Applet is sufficient Diffs - plasma/generic/applets/systemtray/CMakeLists.txt 78031fd plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml 6d35beb plasma/generic/applets/systemtray/package/contents/ui/main.qml d942fba plasma/generic/applets/systemtray/ui/applet.h 30c6214 plasma/generic/applets/systemtray/ui/applet.cpp ecac20c plasma/generic/applets/systemtray/ui/plasmoid.h d0bbf61 plasma/generic/applets/systemtray/ui/plasmoid.cpp 1491595 Diff: http://git.reviewboard.kde.org/r/107262/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Class Plasmoid is merged to SystemTray::Applet
> On Nov. 9, 2012, 10:52 a.m., Aaron J. Seigo wrote: > > nice work :) it's really coming into a very good shape ... But there is one problem: property id of Plasma::Applet isn't a constant for now, so, there are warnings in stdout. - Dmitry --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107262/#review21689 --- On Nov. 9, 2012, 9:59 a.m., Dmitry Ashkadov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107262/ > --- > > (Updated Nov. 9, 2012, 9:59 a.m.) > > > Review request for Plasma, Aaron J. Seigo and Marco Martin. > > > Description > --- > > Special class Plasmoid no more need, for QML code SystemTray::Applet is > sufficient > > > Diffs > - > > plasma/generic/applets/systemtray/CMakeLists.txt 78031fd > plasma/generic/applets/systemtray/package/contents/ui/IconsList.qml 6d35beb > plasma/generic/applets/systemtray/package/contents/ui/main.qml d942fba > plasma/generic/applets/systemtray/ui/applet.h 30c6214 > plasma/generic/applets/systemtray/ui/applet.cpp ecac20c > plasma/generic/applets/systemtray/ui/plasmoid.h d0bbf61 > plasma/generic/applets/systemtray/ui/plasmoid.cpp 1491595 > > Diff: http://git.reviewboard.kde.org/r/107262/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Ashkadov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: SystemTray: alignment of popup dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107378/ --- Review request for Plasma. Description --- Alignment of pop-up dialog of system tray has been fixed and set to Qt.AlignCenter Diffs - plasma/generic/applets/systemtray/package/contents/ui/ArrowArea.qml 336f052 Diff: http://git.reviewboard.kde.org/r/107378/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Move IconItem into MouseArea
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107886/ --- Review request for Plasma. Description --- I've choosen konversatio for testing purpose. When I had clicked on konversation's tray icon, it gots higlighted. After mouse cursor had left systemtray, an icon of konversation was highlighted. I think, moving PlasmaCore.IconItem into MouseArea should fix bug. This addresses bug 311961. http://bugs.kde.org/show_bug.cgi?id=311961 Diffs - plasma/generic/applets/systemtray/package/contents/ui/StatusNotifierItem.qml 8c1af92 Diff: http://git.reviewboard.kde.org/r/107886/diff/ Testing --- Thanks, Dmitry Ashkadov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/ --- Review request for Plasma. Bugs: 317066 http://bugs.kde.org/show_bug.cgi?id=317066 Repository: kde-workspace Description --- It is a proposed fix for bug 317066. The fix is a very simple one-liner setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware FullViewportUpdate has negative performance impact but I also know it efficiently leaves out any graphical glitches happening due to no repaint of widget when necessary (which is what the bug is about). I have tested my solution for a couple of days: the bug no longer reproduced and I also didn't see any noticeable performance problems. I'm still not sure what I propose is acceptable since it may seem like a hack to more experienced developers, however I just didn't want my patch attempt to get lost and forgotten in the bugzilla. Please have a look and decide whether the patch is good enough to be applied to the next bugfixing release of KDE 4.x series, thank you. Diffs - plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 1baa23daa5abd5deaab986dc65cec7b9d1031e6c Diff: https://git.reviewboard.kde.org/r/114910/diff/ Testing --- I rebuilt plasma_applet_systemtray.so with the patch and replaced the package version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can no longer reproduce bug 317066 and I don't see any noticeable performance problems of system tray applet. Thanks, Dmitry Ivanov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/ --- (Updated Jan. 8, 2014, 12:59 p.m.) Review request for kde-workspace and Plasma. Bugs: 317066 http://bugs.kde.org/show_bug.cgi?id=317066 Repository: kde-workspace Description --- It is a proposed fix for bug 317066. The fix is a very simple one-liner setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware FullViewportUpdate has negative performance impact but I also know it efficiently leaves out any graphical glitches happening due to no repaint of widget when necessary (which is what the bug is about). I have tested my solution for a couple of days: the bug no longer reproduced and I also didn't see any noticeable performance problems. I'm still not sure what I propose is acceptable since it may seem like a hack to more experienced developers, however I just didn't want my patch attempt to get lost and forgotten in the bugzilla. Please have a look and decide whether the patch is good enough to be applied to the next bugfixing release of KDE 4.x series, thank you. Diffs - plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 1baa23daa5abd5deaab986dc65cec7b9d1031e6c Diff: https://git.reviewboard.kde.org/r/114910/diff/ Testing --- I rebuilt plasma_applet_systemtray.so with the patch and replaced the package version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can no longer reproduce bug 317066 and I don't see any noticeable performance problems of system tray applet. Thanks, Dmitry Ivanov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
> On Jan. 8, 2014, 5:06 p.m., Thomas Lübking wrote: > > briefly looking at the bug - wouldn't it be better to only cause a full > > parent repaint when adding/removing an (fdo) icon? I have tried it but without success. Adding/removing/changing visibility preference of icons is done on QML side (plasma/generic/applets/systemtray/package/contents/ui/main.qml). I tried to create a Q_INVOKABLE method in Applet class which would call repaint of m_widget's parent view and call this method from QML right after the task is added/removed/visibility preference changed. It didn't work, the bug reproduced. I also tried to call the method from QML right after the height/width of the plasmoid is adjusted, still no success. I'm out of ideas, tbh (I forgot to mention in the description that other viewport update modes rather than full one also failed to fix the issue). There's "TODO" file in plasma/generic/applets/systemtray with item "Fix sizing on desktop" which seems at least related to the discussed bug. Perhaps I should email to the creator of this file to ask whether he has any ideas how to fix it properly. - Dmitry --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/#review47049 ------- On Jan. 8, 2014, 12:59 p.m., Dmitry Ivanov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/114910/ > --- > > (Updated Jan. 8, 2014, 12:59 p.m.) > > > Review request for kde-workspace and Plasma. > > > Bugs: 317066 > http://bugs.kde.org/show_bug.cgi?id=317066 > > > Repository: kde-workspace > > > Description > --- > > It is a proposed fix for bug 317066. The fix is a very simple one-liner > setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware > FullViewportUpdate has negative performance impact but I also know it > efficiently leaves out any graphical glitches happening due to no repaint of > widget when necessary (which is what the bug is about). I have tested my > solution for a couple of days: the bug no longer reproduced and I also didn't > see any noticeable performance problems. I'm still not sure what I propose is > acceptable since it may seem like a hack to more experienced developers, > however I just didn't want my patch attempt to get lost and forgotten in the > bugzilla. Please have a look and decide whether the patch is good enough to > be applied to the next bugfixing release of KDE 4.x series, thank you. > > > Diffs > - > > plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp > 1baa23daa5abd5deaab986dc65cec7b9d1031e6c > > Diff: https://git.reviewboard.kde.org/r/114910/diff/ > > > Testing > --- > > I rebuilt plasma_applet_systemtray.so with the patch and replaced the package > version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can > no longer reproduce bug 317066 and I don't see any noticeable performance > problems of system tray applet. > > > Thanks, > > Dmitry Ivanov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/ --- (Updated Jan. 8, 2014, 8:25 p.m.) Review request for kde-workspace and Plasma. Changes --- Uploaded a modified working patch which is no longer a one-line addition inside FdoGraphicsWidget::paint method but a dozen of new lines setting the full viewport update mode for parent view of FdoGraphicsWidget inside its constructor. So far it is the most proper working solution I can come up with. Bugs: 317066 http://bugs.kde.org/show_bug.cgi?id=317066 Repository: kde-workspace Description --- It is a proposed fix for bug 317066. The fix is a very simple one-liner setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware FullViewportUpdate has negative performance impact but I also know it efficiently leaves out any graphical glitches happening due to no repaint of widget when necessary (which is what the bug is about). I have tested my solution for a couple of days: the bug no longer reproduced and I also didn't see any noticeable performance problems. I'm still not sure what I propose is acceptable since it may seem like a hack to more experienced developers, however I just didn't want my patch attempt to get lost and forgotten in the bugzilla. Please have a look and decide whether the patch is good enough to be applied to the next bugfixing release of KDE 4.x series, thank you. Diffs (updated) - plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 1baa23d Diff: https://git.reviewboard.kde.org/r/114910/diff/ Testing --- I rebuilt plasma_applet_systemtray.so with the patch and replaced the package version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can no longer reproduce bug 317066 and I don't see any noticeable performance problems of system tray applet. Thanks, Dmitry Ivanov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
> On Июль 29, 2014, 2:31 п.п., Marco Martin wrote: > > this would require some testing before pushing to 4.x, too delicate to just > > commit Well, I've been living with this patch for half a year already, since January 8 :) I used it with a number of KDE 4.x versions from 4.11.3 to 4.13.1 (coming with Linux Mint updates). Could it be counted as some testing? - Dmitry --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/#review63413 --- On Янв. 8, 2014, 8:25 п.п., Dmitry Ivanov wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/114910/ > --- > > (Updated Янв. 8, 2014, 8:25 п.п.) > > > Review request for kde-workspace and Plasma. > > > Bugs: 317066 > http://bugs.kde.org/show_bug.cgi?id=317066 > > > Repository: kde-workspace > > > Description > --- > > It is a proposed fix for bug 317066. The fix is a very simple one-liner > setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware > FullViewportUpdate has negative performance impact but I also know it > efficiently leaves out any graphical glitches happening due to no repaint of > widget when necessary (which is what the bug is about). I have tested my > solution for a couple of days: the bug no longer reproduced and I also didn't > see any noticeable performance problems. I'm still not sure what I propose is > acceptable since it may seem like a hack to more experienced developers, > however I just didn't want my patch attempt to get lost and forgotten in the > bugzilla. Please have a look and decide whether the patch is good enough to > be applied to the next bugfixing release of KDE 4.x series, thank you. > > > Diffs > - > > plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp > 1baa23d > > Diff: https://git.reviewboard.kde.org/r/114910/diff/ > > > Testing > --- > > I rebuilt plasma_applet_systemtray.so with the patch and replaced the package > version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can > no longer reproduce bug 317066 and I don't see any noticeable performance > problems of system tray applet. > > > Thanks, > > Dmitry Ivanov > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114910: Patch for bug 317066 ("systray leaves garbage on the panel when resizing ")
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114910/ --- (Updated July 29, 2014, 9:03 p.m.) Status -- This change has been marked as submitted. Review request for kde-workspace and Plasma. Bugs: 317066 http://bugs.kde.org/show_bug.cgi?id=317066 Repository: kde-workspace Description --- It is a proposed fix for bug 317066. The fix is a very simple one-liner setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware FullViewportUpdate has negative performance impact but I also know it efficiently leaves out any graphical glitches happening due to no repaint of widget when necessary (which is what the bug is about). I have tested my solution for a couple of days: the bug no longer reproduced and I also didn't see any noticeable performance problems. I'm still not sure what I propose is acceptable since it may seem like a hack to more experienced developers, however I just didn't want my patch attempt to get lost and forgotten in the bugzilla. Please have a look and decide whether the patch is good enough to be applied to the next bugfixing release of KDE 4.x series, thank you. Diffs - plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 1baa23d Diff: https://git.reviewboard.kde.org/r/114910/diff/ Testing --- I rebuilt plasma_applet_systemtray.so with the patch and replaced the package version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can no longer reproduce bug 317066 and I don't see any noticeable performance problems of system tray applet. Thanks, Dmitry Ivanov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121439/ --- (Updated Dec. 11, 2014, 9:26 a.m.) Review request for Plasma and Martin Gräßlin. Changes --- Added plasma review group Repository: frameworkintegration Description --- Documentation of KStatusNotifierItem::showMessage() says: const QString &icon | icon to be shown to the user So we need name of the icon here, not name of the theme. Diffs - src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad Diff: https://git.reviewboard.kde.org/r/121439/diff/ Testing --- Thanks, Dmitry Shachnev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121439/#review71787 --- Ship it! Ship It! - Dmitry Shachnev On Dez. 11, 2014, 8:26 vorm., Dmitry Shachnev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121439/ > --- > > (Updated Dez. 11, 2014, 8:26 vorm.) > > > Review request for Plasma and Martin Gräßlin. > > > Repository: frameworkintegration > > > Description > --- > > Documentation of KStatusNotifierItem::showMessage() says: > > const QString &icon | icon to be shown to the user > > So we need name of the icon here, not name of the theme. > > > Diffs > - > > src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad > > Diff: https://git.reviewboard.kde.org/r/121439/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Shachnev > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121439: systemtrayicon: pass icon’s name(), not themeName() to showMessage
> On Dez. 11, 2014, 10:42 vorm., Dmitry Shachnev wrote: > > Ship It! > > Martin Gräßlin wrote: > do you have commit rights or should someone push the change for you? No, I don't have rights. Actually this is my first contribution to KDE :) So please push it for me (and sorry for useless noise). - Dmitry --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121439/#review71787 --- On Dez. 11, 2014, 8:26 vorm., Dmitry Shachnev wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121439/ > --- > > (Updated Dez. 11, 2014, 8:26 vorm.) > > > Review request for Plasma and Martin Gräßlin. > > > Repository: frameworkintegration > > > Description > --- > > Documentation of KStatusNotifierItem::showMessage() says: > > const QString &icon | icon to be shown to the user > > So we need name of the icon here, not name of the theme. > > > Diffs > - > > src/platformtheme/kdeplatformsystemtrayicon.cpp 51f31ad > > Diff: https://git.reviewboard.kde.org/r/121439/diff/ > > > Testing > --- > > > Thanks, > > Dmitry Shachnev > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
