Re: HIG standards (from KDE-Frameworks)
Le jeudi 17 mai 2012 09:28:49 Rick Stockton a écrit : While looking at the shortcut for switching tabs i notice that kde' own SC apps are not even following it. According to the docs: Next tab: Ctrl+PageUp Previous tab: Ctrl+PageDown Doesn't work in: Dolphin (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) Konsole (uses Shift+left and Shift+right) Rekonq (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) Konqueror (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) then i stopped testing... I would like to propose to follow the browsers here and make their de-facto standard the HIG guideline. As an alternative i would add the current konsole ones. That would mean: Next tab: - Primary: Ctrl + tab - Alternate: Shift + Right Previous tab: - Primary: Ctrl + shift + tab - Alternate: Shift + Left I would warn against using Shift + (Left|Right) as an alternate shortcut: I assume Konsole does this because it has special handling of Tab, but Shift + Left|Right is most likely already used for other purposes in several applications, for example moving from word to word in an editor. I'm guessing that all current KDE SC apps that use tabs are to be adjusted to either follow the current HIG or to follow my proposal. What's your opinion on using the browser tab shortcuts as the shortcuts? I personally prefer ctrl + page up|down as I find them more symetrict and intuitive, but I may be the minority here. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Testing for 4.9
On Monday 21 May 2012 00:37:07 Viranch Mehta wrote: On Thu, May 17, 2012 at 3:58 AM, David Edmundson da...@davidedmundson.co.uk wrote: - a list of all the new QML-based applets (by the time of the first beta) (afaik, nowplaying, battery, locklogout, activitymanager.. but there are so many more random branches about, and I don't know the status of these) As for the status, device notifier was shipped in last release, Indeed, but many features have not yet been tested extensively, so please do not neglect it in your tests even if it has been out there for a while :) Also, any usability feedback is very much welcome __J -- KDE Plasma Device Notifier mantainer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Applet Testing for 4.9
On 05/22/2012 10:51 AM, Jacopo De Simoi wrote: On Monday 21 May 2012 00:37:07 Viranch Mehta wrote: On Thu, May 17, 2012 at 3:58 AM, David Edmundsonda...@davidedmundson.co.uk wrote: - a list of all the new QML-based applets (by the time of the first beta) (afaik, nowplaying, battery, locklogout, activitymanager.. but there are so many more random branches about, and I don't know the status of these) As for the status, device notifier was shipped in last release, Indeed, but many features have not yet been tested extensively, so please do not neglect it in your tests even if it has been out there for a while :) Also, any usability feedback is very much welcome __J Hi Jacopo, I agree that Device Notifier and all applets shipped by KDE should be tested. I used to do this informally a few releases ago. Usability is usually not included in Beta Testing as it implies design decisions which cannot be really considered as bugs. Maybe we can do some usability tests in the next release in coordination with the Usability Team which could be revived! Best regards, Anne-Marie ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Backport 'Fixed Lancelot build when pimlibs are not present'
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104875/#review14044 --- Ship it! Ship It! - Aaron J. Seigo On May 6, 2012, 7:27 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104875/ --- (Updated May 6, 2012, 7:27 p.m.) Review request for Plasma. Description --- This patch is currently in master and works great, but the problem is still present in KDE/4.8. Any objection to backporting it? Diffs - libs/lancelot-datamodels/MessagesKmail.cpp 7c663704dfa2079a99f58935784559de73abb03a Diff: http://git.reviewboard.kde.org/r/104875/diff/ Testing --- Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: qml port of showActivityManager (it's just an icon)
On May 20, 2012, 10:24 p.m., Mark Gaiser wrote:
Ehm, sorry for nitpicking but why is shipping allowed?
It (probably) can't be closed by pressing CTRL+Q and the glow hover is
missing...
There is an import to import org.kde.plasma.graphicswidgets 0.1 as
PlasmaWidgets which seems useless.
As a side note, i think we need a Icon component to mimic
Plasma::IconWidget --
http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/classPlasma_1_1IconWidget.html.
David Edmundson wrote:
We sort of do:
org.kde.qtextracomponents 0.1
QIconItem
Mark Gaiser wrote:
No, we just do.
http://quickgit.kde.org/index.php?p=kde-runtime.gita=blobh=6cc3011319d750cb70c4cb98eb5290bf042c4d78hb=51170ba2615cb695647b07b2b26c9345be318dd6f=plasma%2Fdeclarativeimports%2Fgraphicswidgets%2Fgraphicswidgetsbindingsplugin.cpp
PlasmaWidgets.IconWidget should be the one required. Though it seems to
be working a bit differently then PlasmaCore.Svg. Judging from the properties
(http://quickgit.kde.org/index.php?p=kdelibs.gita=blobh=78f392ee91fc44b218bb1e2fe059628b6dfcd4e4hb=b91488ff46f0798511447b0b98ffaf81db2b0efbf=plasma%2Fwidgets%2Ficonwidget.h)
it should work somewhat like this:
PlasmaWidgets.IconWidget
{
svg: widgets/activities
}
Note: it uses svg rather then imagePath.. long live consistency ^_-
That widget also has the clicked (and double clicked) signal so i think
that should be used. No need to put a mousearea on top of it i guess.
My guess for this components (without testing! just writing it down here):
import QtQuick 1.1
import org.kde.plasma.core 0.1 as PlasmaCore
import org.kde.plasma.graphicswidgets 0.1 as PlasmaWidgets
Item
{
id: iconContainer
property string activeSource: Status
PlasmaCore.DataSource
{
id: dataSource
engine: org.kde.activities
connectedSources: [activeSource]
}
PlasmaCore.ToolTip
{
id: tooltip
mainText: i18n(Show Activity Manager)
subText: i18n(Click to show the activity manager)
target: iconContainer
image: preferences-activities
}
PlasmaWidgets.IconWidget
{
svg: widgets/activities
onClicked:
{
var service = dataSource.serviceForSource(activeSource)
var operation =
service.operationDescription(toggleActivityManager)
service.startOperationCall(operation)
}
}
}
Just my 5 cents.. or 1 euro in this case ;)
Greg T wrote:
Thanks for your input, guys!
It (probably) can't be closed by pressing CTRL+Q
I'am able to close the activity manager by pressing alt+f4, or what are
you talking about? ctrl+q doesn't even work with the old version.
Mark Gaiser wrote:
Sorry, my mistake. The current one works with Meta + Q. Which i
actually find a very strange combination for closing a window... I don't mind
if Meta+Q isn't working. I don't have more nitpicking for you, it's oke by
me. ^_^
I do would like someone else of this area to agree again since the code
changed quite a bit compared to revision 1.
meta+q comes from the default configuration included with plasma-desktop. it
isn't a feature of the plasmoid itself :)
- Aaron J.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104959/#review14005
---
On May 21, 2012, 6:46 p.m., Greg T wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104959/
---
(Updated May 21, 2012, 6:46 p.m.)
Review request for Plasma.
Description
---
Hello, I've played around a bit with the new qml stuff. Basically this port
works the same way as the c++ version. Though the icon doesn't glow on mouse
hover. How can I fix that?
Diffs
-
plasma/desktop/applets/CMakeLists.txt 731c70c
plasma/desktop/applets/showActivityManager/CMakeLists.txt 592f38f
plasma/desktop/applets/showActivityManager/Messages.sh 0f07ff5
plasma/desktop/applets/showActivityManager/package/contents/ui/main.qml
PRE-CREATION
plasma/desktop/applets/showActivityManager/package/metadata.desktop
PRE-CREATION
plasma/desktop/applets/showActivityManager/plasma-applet-org.kde.showActivityManager.desktop
98e9bd6
plasma/desktop/applets/showActivityManager/showActivityManager.h f58fbb7
plasma/desktop/applets/showActivityManager/showActivityManager.cpp e77df0d
Re: Review Request: Plasmate: fix publisher's combobox and doCMake slot
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104969/#review14046 --- publisher/publisher.cpp http://git.reviewboard.kde.org/r/104969/#comment4 looks like a stray change... (though signign could be fixed to signing ;) publisher/publisher.cpp http://git.reviewboard.kde.org/r/104969/#comment5 QDir has a cd(const QString ) method that is what you are looking for - Aaron J. Seigo On May 16, 2012, 6:38 p.m., Giorgos Tsiapaliwkas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104969/ --- (Updated May 16, 2012, 6:38 p.m.) Review request for Plasma. Description --- Hello, those are some issues which plasmate's publisher has problem 1: the publisher's combobox wasn't aware for the right slot. When currentIndex was emitted both slots(doPlasmaPkg and doCMake was called.) I fixed that. problem 2: publisher's cmake process was trying to install a projectName.plasmoid file and not projectPath/CMakeLists.txt. I fixed that. problem 3: when the cmake slot is called, cmake creates the known temporary files in directory like ~/.kde4/share/apps/plasmate/projectName. I haven't fixed that. How can I change the current directory with Qt? Diffs - publisher/publisher.h 6eba693 publisher/publisher.cpp 3fcd268 Diff: http://git.reviewboard.kde.org/r/104969/diff/ Testing --- WIP Thanks, Giorgos Tsiapaliwkas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use Config to Provide Activity Icons
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/#review14047 --- nepomuk works differently should not be a reason for this particular change. the question is whether to store the icons in nepomuk or not. if they are stored in nepomuk, then the information stays with the activities. if they are stored outside of nepomuk, then when we want to do things like migrate activities it becomes messier and we lose visibility on the connection between the image and the activity. - Aaron J. Seigo On May 22, 2012, 3:12 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/ --- (Updated May 22, 2012, 3:12 a.m.) Review request for Plasma and Ivan Čukić. Description --- Since we can't trust Nepomuk anymore now that ontologies are loaded asynchronously, we better implement the approach we have in master. This addresses bug 298684. http://bugs.kde.org/show_bug.cgi?id=298684 Diffs - service/ActivityManager.cpp 8927c43 service/ActivityManager_p.h 3ea1d8a Diff: http://git.reviewboard.kde.org/r/105008/diff/ Testing --- Log out and back in. Before this patch, icons would probably load later, or not load at all. Now icons are displayed right away when desktop is loaded. Thanks, David Narváez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use Config to Provide Activity Icons
On May 22, 2012, 12:52 p.m., Aaron J. Seigo wrote: nepomuk works differently should not be a reason for this particular change. the question is whether to store the icons in nepomuk or not. if they are stored in nepomuk, then the information stays with the activities. if they are stored outside of nepomuk, then when we want to do things like migrate activities it becomes messier and we lose visibility on the connection between the image and the activity. This review request has nothing to do with storing icons in Nepomuk or not. It has to do with what is returned to a client when it requests an icon for an activity - if we wait for Nepomuk to start and then return the icon there or just use the config file which already has the info. Icons are still stored in Nepomuk and sync'ed later in the code once Nepomuk is available. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/#review14047 --- On May 22, 2012, 3:12 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/ --- (Updated May 22, 2012, 3:12 a.m.) Review request for Plasma and Ivan Čukić. Description --- Since we can't trust Nepomuk anymore now that ontologies are loaded asynchronously, we better implement the approach we have in master. This addresses bug 298684. http://bugs.kde.org/show_bug.cgi?id=298684 Diffs - service/ActivityManager.cpp 8927c43 service/ActivityManager_p.h 3ea1d8a Diff: http://git.reviewboard.kde.org/r/105008/diff/ Testing --- Log out and back in. Before this patch, icons would probably load later, or not load at all. Now icons are displayed right away when desktop is loaded. Thanks, David Narváez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use Config to Provide Activity Icons
On May 22, 2012, 12:52 p.m., Aaron J. Seigo wrote: nepomuk works differently should not be a reason for this particular change. the question is whether to store the icons in nepomuk or not. if they are stored in nepomuk, then the information stays with the activities. if they are stored outside of nepomuk, then when we want to do things like migrate activities it becomes messier and we lose visibility on the connection between the image and the activity. David Narváez wrote: This review request has nothing to do with storing icons in Nepomuk or not. It has to do with what is returned to a client when it requests an icon for an activity - if we wait for Nepomuk to start and then return the icon there or just use the config file which already has the info. Icons are still stored in Nepomuk and sync'ed later in the code once Nepomuk is available. let me rephrase for clarity: storing activity data (esp duplicate data) outside of nepomuk all to work around annoyances (like the one your patch addresses) or to placate people who insist they won't enable nepomuk makes no sense at this point. it would be far more sensible to ensure that this data is consistently and quickly available from nepomuk than keeping another cache of this information outside of nepomuk. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/#review14047 --- On May 22, 2012, 3:12 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/ --- (Updated May 22, 2012, 3:12 a.m.) Review request for Plasma and Ivan Čukić. Description --- Since we can't trust Nepomuk anymore now that ontologies are loaded asynchronously, we better implement the approach we have in master. This addresses bug 298684. http://bugs.kde.org/show_bug.cgi?id=298684 Diffs - service/ActivityManager.cpp 8927c43 service/ActivityManager_p.h 3ea1d8a Diff: http://git.reviewboard.kde.org/r/105008/diff/ Testing --- Log out and back in. Before this patch, icons would probably load later, or not load at all. Now icons are displayed right away when desktop is loaded. Thanks, David Narváez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use Config to Provide Activity Icons
On May 22, 2012, 12:52 p.m., Aaron J. Seigo wrote: nepomuk works differently should not be a reason for this particular change. the question is whether to store the icons in nepomuk or not. if they are stored in nepomuk, then the information stays with the activities. if they are stored outside of nepomuk, then when we want to do things like migrate activities it becomes messier and we lose visibility on the connection between the image and the activity. David Narváez wrote: This review request has nothing to do with storing icons in Nepomuk or not. It has to do with what is returned to a client when it requests an icon for an activity - if we wait for Nepomuk to start and then return the icon there or just use the config file which already has the info. Icons are still stored in Nepomuk and sync'ed later in the code once Nepomuk is available. Aaron J. Seigo wrote: let me rephrase for clarity: storing activity data (esp duplicate data) outside of nepomuk all to work around annoyances (like the one your patch addresses) or to placate people who insist they won't enable nepomuk makes no sense at this point. it would be far more sensible to ensure that this data is consistently and quickly available from nepomuk than keeping another cache of this information outside of nepomuk. libkactivities' master has moved far into the direction of caching the info in the config while syncing with Nepomuk when available. The behavior proposed in this patch is actually sort of a backport of master's behavior. I, on the other hand, tried my best to depend on Nepomuk to get the info but there seems to be no reliable way of getting the info in every possible case without at least breaking the ABI - not to mention anything about quickly. I could elaborate but I don't know if this is the best place to do so. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/#review14047 --- On May 22, 2012, 3:12 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/ --- (Updated May 22, 2012, 3:12 a.m.) Review request for Plasma and Ivan Čukić. Description --- Since we can't trust Nepomuk anymore now that ontologies are loaded asynchronously, we better implement the approach we have in master. This addresses bug 298684. http://bugs.kde.org/show_bug.cgi?id=298684 Diffs - service/ActivityManager.cpp 8927c43 service/ActivityManager_p.h 3ea1d8a Diff: http://git.reviewboard.kde.org/r/105008/diff/ Testing --- Log out and back in. Before this patch, icons would probably load later, or not load at all. Now icons are displayed right away when desktop is loaded. Thanks, David Narváez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Use Config to Provide Activity Icons
On May 22, 2012, 12:52 p.m., Aaron J. Seigo wrote: nepomuk works differently should not be a reason for this particular change. the question is whether to store the icons in nepomuk or not. if they are stored in nepomuk, then the information stays with the activities. if they are stored outside of nepomuk, then when we want to do things like migrate activities it becomes messier and we lose visibility on the connection between the image and the activity. David Narváez wrote: This review request has nothing to do with storing icons in Nepomuk or not. It has to do with what is returned to a client when it requests an icon for an activity - if we wait for Nepomuk to start and then return the icon there or just use the config file which already has the info. Icons are still stored in Nepomuk and sync'ed later in the code once Nepomuk is available. Aaron J. Seigo wrote: let me rephrase for clarity: storing activity data (esp duplicate data) outside of nepomuk all to work around annoyances (like the one your patch addresses) or to placate people who insist they won't enable nepomuk makes no sense at this point. it would be far more sensible to ensure that this data is consistently and quickly available from nepomuk than keeping another cache of this information outside of nepomuk. David Narváez wrote: libkactivities' master has moved far into the direction of caching the info in the config while syncing with Nepomuk when available. The behavior proposed in this patch is actually sort of a backport of master's behavior. I, on the other hand, tried my best to depend on Nepomuk to get the info but there seems to be no reliable way of getting the info in every possible case without at least breaking the ABI - not to mention anything about quickly. I could elaborate but I don't know if this is the best place to do so. I don't know how important this is for 4.8 when we are approaching the next release. Data duplication in this case is not necessarily a bad thing. Nepomuk is a rather nice tool for sharing data to other applications. It is not that nice when managing the internal data is concerned. So, in a manner of speaking, the config file is not the cache - it *is* the data. Stuff in Nepomuk is the export of the data to the public. I know you had the idea of kamd becoming a nepomuk service so that we could skip some of the indirections that currently exist. It wouldn't change a thing - there is really no difference between a nepomuk service and any other process using nepomuk apart from the way they are started. No speed improvements, everything goes via d-bus, and graph-database is as slow as any other graph database etc. Abstractions for the things in a database would be needed as they are in any other system - so that we can control and know what goes in and out of the database, and don't need to create resource watchers (a problem that dolphin ppl are currently having, according to a thread on the ml) ... But, all this should be in a separate discussion. Don't want to hog the review request. - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/#review14047 --- On May 22, 2012, 3:12 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105008/ --- (Updated May 22, 2012, 3:12 a.m.) Review request for Plasma and Ivan Čukić. Description --- Since we can't trust Nepomuk anymore now that ontologies are loaded asynchronously, we better implement the approach we have in master. This addresses bug 298684. http://bugs.kde.org/show_bug.cgi?id=298684 Diffs - service/ActivityManager.cpp 8927c43 service/ActivityManager_p.h 3ea1d8a Diff: http://git.reviewboard.kde.org/r/105008/diff/ Testing --- Log out and back in. Before this patch, icons would probably load later, or not load at all. Now icons are displayed right away when desktop is loaded. Thanks, David Narváez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: HIG standards (from KDE-Frameworks)
On Tue, May 22, 2012 at 10:51 AM, Aurélien Gâteau agat...@kde.org wrote: Le jeudi 17 mai 2012 09:28:49 Rick Stockton a écrit : While looking at the shortcut for switching tabs i notice that kde' own SC apps are not even following it. According to the docs: Next tab: Ctrl+PageUp Previous tab: Ctrl+PageDown Doesn't work in: Dolphin (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) Konsole (uses Shift+left and Shift+right) Rekonq (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) Konqueror (uses Ctrl+tab for forward and Ctrl+shift+tab for backward) then i stopped testing... I would like to propose to follow the browsers here and make their de-facto standard the HIG guideline. As an alternative i would add the current konsole ones. That would mean: Next tab: - Primary: Ctrl + tab - Alternate: Shift + Right Previous tab: - Primary: Ctrl + shift + tab - Alternate: Shift + Left I would warn against using Shift + (Left|Right) as an alternate shortcut: I assume Konsole does this because it has special handling of Tab, but Shift + Left|Right is most likely already used for other purposes in several applications, for example moving from word to word in an editor. I'm guessing that all current KDE SC apps that use tabs are to be adjusted to either follow the current HIG or to follow my proposal. What's your opinion on using the browser tab shortcuts as the shortcuts? I personally prefer ctrl + page up|down as I find them more symetrict and intuitive, but I may be the minority here. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Problem with Ctrl + Page Up/Page Down is that it can bee a little more dificult to press with your left hand. Most people are right handed and they use the mouse with their right hand and have the the left hand on the left part of the keyboard and this is probably the reason people like the Ctrl + Tab shortcut. Just my 2c... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasmate: fix publisher's combobox and doCMake slot
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104969/#review14069 --- Looks like a sensible change, otherwise. If you've fixed the issues aseigo notes, please go ahead and merge into master. In the same part, there's an interaction problem, however: Assumption: installing an app is quite a common thing during development (correct me if you think otherwise) Right now, there is no button to trigger installation with the currently selected mode, so one has to switch the combo to empty, then to the preferred installation method. A button Install! would fix that. Also, doing the installtion when the combobox changes is quite uncommon, as it is not explicit that the installation actually already happens when you choose something. This should move into a button, which can conveniently go right next to the combo, and then the combo changed to not install on indexChanged. Also, it would make sense to add an action andshortcut for installation to the toolbar above. This is not an issue with this patch, just how we should improve that part of the UI. I used it for a development task yesterday, and this installatio workflow issue struck me as overly complex and have to learn it rather than understand it without thinking. - Sebastian Kügler On May 16, 2012, 6:38 p.m., Giorgos Tsiapaliwkas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104969/ --- (Updated May 16, 2012, 6:38 p.m.) Review request for Plasma. Description --- Hello, those are some issues which plasmate's publisher has problem 1: the publisher's combobox wasn't aware for the right slot. When currentIndex was emitted both slots(doPlasmaPkg and doCMake was called.) I fixed that. problem 2: publisher's cmake process was trying to install a projectName.plasmoid file and not projectPath/CMakeLists.txt. I fixed that. problem 3: when the cmake slot is called, cmake creates the known temporary files in directory like ~/.kde4/share/apps/plasmate/projectName. I haven't fixed that. How can I change the current directory with Qt? Diffs - publisher/publisher.h 6eba693 publisher/publisher.cpp 3fcd268 Diff: http://git.reviewboard.kde.org/r/104969/diff/ Testing --- WIP Thanks, Giorgos Tsiapaliwkas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasmate: Add Tabbox support to the startpage
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105011/ --- (Updated May 23, 2012, 5:20 a.m.) Review request for kwin, Plasma and Martin Gräßlin. Changes --- Add kwin and plasma to the groups Description --- Hello, This is the first task of my GSoC. I have add the tabbox support to the startpage of the plasmate. NOTES: 1)The service type of the tabbox is Kwin/Tabbox,Plasma/Applet, because the Plasma::PackageStructure requires the Plasma/Applet in order to be able to be used. Also the plasmapkg and the plasmoidview require the Plasma/Applet service type. 2)Some lines doesn't have any differences because i have remove some whitespaces and tabs... ISSUES: 1)The icons for the tabbox are wrong. I have some issues with my PCs and i cannot open a new session of the KDE. So i wasn't able to find the icon. Sorry for that. 2)The template of the tabbox that i have put is located in the kde-workspace/kwin/kcmkwin/kwintabbox/qml/main.qml. The main.qml cannot be installed becuase it uses some Q_PROPERTY elements. Any ideas about how to fix that? 3)I think that the starting comments of the tabbox should become better. I would prefer something like the mainPlasmoid.qml Diffs - templates/CMakeLists.txt 6a82772 templates/mainTabbox.qml PRE-CREATION startpage.h 0df4c21 startpage.cpp 9774b48 editors/metadata/metadataeditor.cpp fce65fd editors/editpage.cpp a331ae5 Diff: http://git.reviewboard.kde.org/r/105011/diff/ Testing --- Screenshots --- http://git.reviewboard.kde.org/r/105011/s/574/ Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
