Re: Review Request: Save scrollbar position on plasma exit
On March 13, 2012, 1:12 p.m., Marco Martin wrote: looks good, a thing i would like to be tested is when the saved position is invalid, like either negative or an enormous value. this shouldn't break it (is even quite probable a value not being valid anymore because there are less files than the previous session) Fredrik Höglund wrote: I think it would be a good idea to save the modification time for the folder and use that to check if the saved scrollbar value is likely to be invalid. If the user is able to scroll the view while the layout is in progress, this should also abort restoring the position. Also, I'm wondering if we really need to save the position separately for the iconview and the listview, or if we should use the same key. Otherwise the patch looks good to me. Ignat Semenov wrote: Well I've been thinking about separate vs single key and I think separate is easier to read and maintain, less checks and branches. The main problem with a single key would be when the applet is put into a panel, first the icon view gets created and grabs the value, then the list view gets created and gets a 0. Two keys are easier to work with I think. As for scrolling when the layout is in progress, this method is intended to be used at startup only, so the user can not scroll the view. Or do you mean that some dev could use restoreScrollbarPosition() manually after startup? Folder mtime is a nice idea, one more corner case, will try to implement. Ignat Semenov wrote: Actually, aborting the automatic scrolling works just fine, as smoothScroll(savedPosition) is used and that one can be interrupted easily. OK, as discussed with fredrikh on IRC yesterday, the patch now accounts for multiple layout passes. As far as the dir mtime issue goes, I think that actually falls into the range check case, that is, if the dir content changes, but the number of rows does not, it's probably ok to restore the scroll position. If the number of rows changes, then the scrollbar range changes and that is caught by the check in scrollToSavedPosition(). Same for the list view. Now the only relevant issue is actually aborting the restore if scrolling the view between layout passes in a slow dir. - Ignat --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/#review11354 --- On March 13, 2012, 6:44 p.m., Ignat Semenov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/ --- (Updated March 13, 2012, 6:44 p.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Description --- This patch implements scrolbar position saving on plasma exit. The change is fairly trivial, however, due to the fact that the view is not populated and layouted immediately simply scrolling to the desired position on creating the view does not work. Instead a signal is emitted on finishing the item layout, when the view has a valid size and the scrollbar has a valid range. The signal is connected to a slot which scrolls the view to the desired position and then disconnects the signal. For the user, a public function in AbstractItemView is introduced, which performs the connection. The only problem is that ListView turned out not to have any layout method. It just paints the items one by one, calculating their position on the fly, so I put the signal at the end of updateScrollbar to ensure the scrollbar range is valid. Maybe it should go into the if (max0) branch? This addresses bug 261139. http://bugs.kde.org/show_bug.cgi?id=261139 Diffs - plasma/applets/folderview/abstractitemview.h aa68b90 plasma/applets/folderview/abstractitemview.cpp 3debb70 plasma/applets/folderview/folderview.h 4e441eb plasma/applets/folderview/folderview.cpp a94ce87 plasma/applets/folderview/iconview.h 12e93b3 plasma/applets/folderview/iconview.cpp 5c4e086 plasma/applets/folderview/listview.cpp b17e7c4 Diff: http://git.reviewboard.kde.org/r/104258/diff/ Testing --- Tested both the icon view and the list view, works fine. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: March Iteration of Frameworks epic
On Friday, March 9, 2012 17:58:35 Martin Gräßlin wrote: * getting kwindowsystem as a Tier 1 library (currently it's planned as a Tier 2) it's already very close to this and shouldn't need much more work. it relies currently on some classed from libkdecore, but that's it. * moving Plasma::WindowEffects into this library this is already done. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Removing of decorations
On Sunday, March 11, 2012 11:01:11 Martin Gräßlin wrote: Do we have to include by default a visually outdated theme (Laptop) or an even broken theme (Plastik) just for thin clients? given that i don't want to have to answer all the problems and complaints from our large user base of thin client installs: imho, yes. at the very least, pick one, clean it up a little bit if needed and drop the rest. but not having something for thin clients at this point would be a disasterous mistake in terms of user relations and existing user base support. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Friday, March 9, 2012 00:27:51 Alex Fiestas wrote: - Keep the 6 month release period release periods and development periods are not the same thing. the release period is, imho, uninteresting in these kinds of dicussions. we're discussing development process, which is only marginally related to release processes. regardless of the development process, the release process must continue and be aided. - Keep the current schedule (soft freeze, hard freeze...) this, however, is very relevant. :) for release coordination it is fine, but keeping development tied to this is a mistake imo. this should only direct when merging into master can happen, but not constrain what development is actually happening. keep in mind that those who may be creating products around this software, as we have learned in plasma active, simply can not be tied to kde's release cycles. on the other hand, kde needs release cycles and can never time those to match every downstream's needs simultaneously (there are too many downstream schedule conflicts and variance in needs). - Move to a review based workflow before hard freeze (we need gerrit). for certain components, yes. for other non-critical ones, this will just kill what development efforts were put into them for no real gain. every time we raise the bar on development, we shrink the pool of people who will engage. so i'm 100% supportive of the idea to ensure core components are more stable and purposefully developed and less chaotic, but would like to see a process that keeps additional components more freely developed. - Once we are on hard freeze, open merge for everyone so we can continue fixing things easily. review is also important here, of course, as fixes can (and sometimes do) break things. that said: things we have right now and it will allow us to explore the benefits of the merge based workflow. this is what really piques my interest: merge based workflow. an integration branch would be fantastic. that branch should rebase periodically off of master and only be used to merge feature branches. this branch would largely take the place of current master: where development happens. feature branches should be merged into integration on a regular basis and developers and testers should track this integration branch in their day-to-day usage integration should always be open to feature branch merging. master should only be open for feature merge when not in freeze, however. when in freeze, either a stabilization branch could be made off of master for this purpose (probably a very good idea for larger fixes) which is then merged down in master at known good points .. or .. master is opened for bug fixes directly in those periods. the latter is probably not as good from a stability POV, but may be more reasonable and less of a workload for people doing the actual work. so what i'm interested in hearing is what sort of branch management scheme would work for people. i'm happy to maintain either an integration or the master branch (but not both). in any case, i'm personally less interested about the details of the review process (many different ways to do that) and more interested in the branching strategy. note that the methods being (slowly) adopted for frameworks devel are also moving in the direction noted above. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activity aware plasmoids
On Monday, March 12, 2012 13:12:40 Martin Klapetek wrote: shield the apps themselves from account credentials, ie. the apps will work only with an auth token provided by the auth library. This library is almost done btw. *drool* is the code already in git somewhere that i can check out? if not, please let me know when! i already have 2 projects that will have need of this, not counting the obvious SLC :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSOC 2012 project: Make plasmate ready for release
On Thursday, March 8, 2012 21:04:49 Giorgos Tsiapaliwkas wrote: Hello, this is my modified proposal, -Task 1 --Problem 1 Right now plasmate doesn't support all the debugging tools which we offer. Those debugging tools live under kde-workspace/plasma/generic/tools. --Solution 1 a.Move all the debugging tools from kde-workspace/plasma/generic/tools and kde-runtime/plasma/tools into plasmate's repository(maybe we should rename the repository to Plasma SDK) for kde-workspace/plasma/generic/tools i think it makes sense to put them all into the plasmate repo. the runtime tools need to stay where they are as they are used by 3rd party apps for things like package installation, and plasmate can rely on them being there as well. Expected time: this task has to be done by a sysadmin since I don't have that kind of access. nah .. you can do this. you just need to run a git branch history over the plasma-workspace/plasma/generic/tools directory and run those commits into plasmate, then remove the directory from plasma-workspace. c.our debugging tools will still live as standalone applications and also us plasmate's plugins. sounds good. -Task 2 --Problem 2 Plasmate and plasmoidviewer have duplicate code. Also plasma-previewer(the plasmate's code for plasmoid debugging) is more modular than the plasmoidviewer's code. Plasma-previewer is more modular but plasmoidviewer has more features than the plasma-previewer. --Solution 2 Replace plasma-previewer's code with plasmoidviewer's and make plasmoidviewer's code more modular in order to be reused by plasmate. i would like to see the menus from plasma-prevewier in plasmoidviewer, however. having to restart plasmoidviewer to get different results sucks :) otherwise, +1 variable. Plasmoidviewer should provide an option for that (I will add this option). +1 the rest of the tasks look excellent and well though out. if you can put a page together on the wiki documenting this that would be great, and i might even blog about it to hopefully drum up some more participation. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activity aware plasmoids
On Wed, Mar 14, 2012 at 14:41, Aaron J. Seigo ase...@kde.org wrote: On Monday, March 12, 2012 13:12:40 Martin Klapetek wrote: shield the apps themselves from account credentials, ie. the apps will work only with an auth token provided by the auth library. This library is almost done btw. *drool* is the code already in git somewhere that i can check out? if not, please let me know when! i already have 2 projects that will have need of this, not counting the obvious SLC :) Not yet, it's under Dario's charge, but should be released soon. I'll let you know, if he won't do it before me ;) -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix biggestId in systray-to-notifications-widget.js
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104086/#review11401
---
This review has been submitted with commit
2ee1b5deb98f1c493cf342fc0f459b4028cedbab by Aaron Seigo to branch KDE/4.8.
- Commit Hook
On Feb. 26, 2012, 10:18 p.m., Luc Menut wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104086/
---
(Updated Feb. 26, 2012, 10:18 p.m.)
Review request for Plasma, Aaron J. Seigo and Marco Martin.
Description
---
When I try in the plasma desktop console the algorithm that calculate the
biggestId in systray-to-notifications-widget.js, it gives me a wrong result
for biggestId and biggestId+1.
The real biggestId in my plasma-desktop-appletsrc is 82
([Containments][76][Applets][82]).
The current algorithm gives me:
print(biggestId) - 5
print(biggestId+1)- 51
print(typeof(biggestId)) - string
because in
for (var j in activity.widgetIds) {
if (j biggestId) {
biggestId = j
}
j is the key (string key) of the array activity.widgetIds.
The suggested patch gives the good result.
regards,
Luc Menut - Mageia
PS: I don't have write access to kde git, so could you commit the change for
me if the patch looks fine. Thanks.
Diffs
-
plasma/desktop/shell/configupdates/systray-to-notifications-widget.js
7a31de6
Diff: http://git.reviewboard.kde.org/r/104086/diff/
Testing
---
tested with KDE 4.8.0 (Mageia Cauldron)
Thanks,
Luc Menut
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix biggestId in systray-to-notifications-widget.js
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104086/#review11402
---
This review has been submitted with commit
297b3e42e796afe1cd37df101d8b2c240b4625b0 by Aaron Seigo to branch master.
- Commit Hook
On Feb. 26, 2012, 10:18 p.m., Luc Menut wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104086/
---
(Updated Feb. 26, 2012, 10:18 p.m.)
Review request for Plasma, Aaron J. Seigo and Marco Martin.
Description
---
When I try in the plasma desktop console the algorithm that calculate the
biggestId in systray-to-notifications-widget.js, it gives me a wrong result
for biggestId and biggestId+1.
The real biggestId in my plasma-desktop-appletsrc is 82
([Containments][76][Applets][82]).
The current algorithm gives me:
print(biggestId) - 5
print(biggestId+1)- 51
print(typeof(biggestId)) - string
because in
for (var j in activity.widgetIds) {
if (j biggestId) {
biggestId = j
}
j is the key (string key) of the array activity.widgetIds.
The suggested patch gives the good result.
regards,
Luc Menut - Mageia
PS: I don't have write access to kde git, so could you commit the change for
me if the patch looks fine. Thanks.
Diffs
-
plasma/desktop/shell/configupdates/systray-to-notifications-widget.js
7a31de6
Diff: http://git.reviewboard.kde.org/r/104086/diff/
Testing
---
tested with KDE 4.8.0 (Mageia Cauldron)
Thanks,
Luc Menut
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: plasmoid qalculate - menu button
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103052/#review11403 --- Ship it! looks good :) - Aaron J. Seigo On March 6, 2012, 8:54 p.m., Greg T wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103052/ --- (Updated March 6, 2012, 8:54 p.m.) Review request for Plasma. Description --- Hey dudes, I implemented a little menu that displays the last 10 results. improvement ideas? I found this task in the plasma task list: http://community.kde.org/Plasma/Tasks#Kalgebra_and_Qalculate_Plasmoid Diffs - applets/qalculate/qalculate_applet.h aee14c0 applets/qalculate/qalculate_applet.cpp 4da9241 applets/qalculate/qalculate_history.h 59185ee applets/qalculate/qalculate_history.cpp 35592a7 applets/qalculate/qalculate_settings.h 4ce4e73 applets/qalculate/qalculate_settings.cpp b62145b Diff: http://git.reviewboard.kde.org/r/103052/diff/ Testing --- seems to work Thanks, Greg T ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Merge the final and fixed QML battery monitor to master.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104226/ --- (Updated March 14, 2012, 5:48 p.m.) Review request for Plasma. Changes --- Properly translates all displayed text with comments to translators wherever necessary (all of the i18n/i18nc/i18np are taken from C++ version). Description --- I fixed the QML battery monitor to be fairly usable and this diff merges it to master. Diffs (updated) - plasma/generic/applets/CMakeLists.txt 2dedcb2 plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION plasma/generic/applets/batterymonitor/README.txt PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen-inkscape.svgz PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen.svgz PRE-CREATION plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/config.ui PRE-CREATION plasma/generic/applets/batterymonitor/metadata.desktop PRE-CREATION plasma/generic/dataengines/powermanagement/powermanagementengine.h 20642c2 plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 5572fcb plasma/generic/dataengines/powermanagement/powermanagementjob.h 2c32015 plasma/generic/dataengines/powermanagement/powermanagementjob.cpp e205bb0 plasma/generic/dataengines/powermanagement/powermanagementservice.operations ad1301f Diff: http://git.reviewboard.kde.org/r/104226/diff/ Testing --- Applet and dataengine both tested and work fine. Thanks, Viranch Mehta ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Merge the final and fixed QML battery monitor to master.
On March 13, 2012, 5:32 p.m., David Edmundson wrote:
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml, line 66
http://git.reviewboard.kde.org/r/104226/diff/5/?file=53015#file53015line66
This i18n string doesn't really work.
1) This string doesn't really contain any words, so it's not really
suitable for translation. At least use i18nc() so translators have context
of what it is.
2) the state (i.e charging, charged, discharging) is never translated.
I have adopted the translation straight from the C++ applet now (except the
if-else logic):
if (pluggedIn) {
if (percent100) return i18n(%1 (charging), percent);
else return i18n(%1 (charged), percent);
} else {
return i18n(%1 (discharging), percent);
}
On March 13, 2012, 5:32 p.m., David Edmundson wrote:
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml, line 101
http://git.reviewboard.kde.org/r/104226/diff/5/?file=53015#file53015line101
This isn't translated.
Also this is a word puzzle.
http://techbase.kde.org/Development/Tutorials/Localization/i18n_Mistakes#Pitfall_.232:_Word_Puzzles
You also can't do
if (hrs==1) {
hour
} else {
hours
}
for some languages plurals come after 1st, 11th 111th.. it's not as
simple as you just wrote.
use i18np.
We can achieve completely formatted and translated string only by
KLocale::prettyFormatDuration() as far as I know. But since we don't yet have
KLocale QML bindings, I have a temporary work around:
var time = new Date(remainingMsec);
var hrs = i18np(1 hour, %1 hours, time.getUTCHours());
var mins = i18np(1 minute, %1 minutes, time.getUTCMinutes());
return hrs+, +mins;
On March 13, 2012, 5:32 p.m., David Edmundson wrote:
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml, line 108
http://git.reviewboard.kde.org/r/104226/diff/5/?file=53015#file53015line108
Don't do this to determine how wide something should be.
What if the japanese for power management enabled is only 3
characters long and the time remaining is larger?
Even if you could garauntee it's the longest string right now, what if
someone changes this in the future?
set the Grid to be
width:childRect.width.
and remove the call to width on all these labels, and that /should/
work. (I've not tested that and could be wrong.)
Discarded.
This was done to achieve right alignment to the labels (on the left side). For
now, they are all left-aligned due to this change.
- Viranch
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104226/#review11360
---
On March 14, 2012, 5:48 p.m., Viranch Mehta wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104226/
---
(Updated March 14, 2012, 5:48 p.m.)
Review request for Plasma.
Description
---
I fixed the QML battery monitor to be fairly usable and this diff merges it
to master.
Diffs
-
plasma/generic/applets/CMakeLists.txt 2dedcb2
plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION
plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION
plasma/generic/applets/batterymonitor/README.txt PRE-CREATION
plasma/generic/applets/batterymonitor/battery-oxygen-inkscape.svgz
PRE-CREATION
plasma/generic/applets/batterymonitor/battery-oxygen.svgz PRE-CREATION
plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION
plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml
PRE-CREATION
plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml
PRE-CREATION
plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml
PRE-CREATION
plasma/generic/applets/batterymonitor/contents/ui/config.ui PRE-CREATION
plasma/generic/applets/batterymonitor/metadata.desktop PRE-CREATION
plasma/generic/dataengines/powermanagement/powermanagementengine.h 20642c2
plasma/generic/dataengines/powermanagement/powermanagementengine.cpp
5572fcb
plasma/generic/dataengines/powermanagement/powermanagementjob.h 2c32015
plasma/generic/dataengines/powermanagement/powermanagementjob.cpp e205bb0
plasma/generic/dataengines/powermanagement/powermanagementservice.operations
ad1301f
Diff: http://git.reviewboard.kde.org/r/104226/diff/
Testing
---
Applet and dataengine both tested and work fine.
Thanks,
Viranch Mehta
___
Plasma-devel mailing list
Plasma-devel@kde.org
Re: Review Request: Merge the final and fixed QML battery monitor to master.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104226/ --- (Updated March 14, 2012, 6:39 p.m.) Review request for Plasma. Changes --- Add screenshot. Description --- I fixed the QML battery monitor to be fairly usable and this diff merges it to master. Diffs - plasma/generic/applets/CMakeLists.txt 2dedcb2 plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION plasma/generic/applets/batterymonitor/README.txt PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen-inkscape.svgz PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen.svgz PRE-CREATION plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/config.ui PRE-CREATION plasma/generic/applets/batterymonitor/metadata.desktop PRE-CREATION plasma/generic/dataengines/powermanagement/powermanagementengine.h 20642c2 plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 5572fcb plasma/generic/dataengines/powermanagement/powermanagementjob.h 2c32015 plasma/generic/dataengines/powermanagement/powermanagementjob.cpp e205bb0 plasma/generic/dataengines/powermanagement/powermanagementservice.operations ad1301f Diff: http://git.reviewboard.kde.org/r/104226/diff/ Testing --- Applet and dataengine both tested and work fine. Screenshots (updated) --- http://git.reviewboard.kde.org/r/104226/s/464/ Thanks, Viranch Mehta ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Merge the final and fixed QML battery monitor to master.
On March 13, 2012, 5:32 p.m., David Edmundson wrote: Read up on i18n, ideally most of http://techbase.kde.org/Development/Tutorials/Localization/ and double check everything again. Also personally I like to submit a screenshot with any very visual change. Thanks for the link. Screenshot uploaded. - Viranch --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104226/#review11360 --- On March 14, 2012, 6:39 p.m., Viranch Mehta wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104226/ --- (Updated March 14, 2012, 6:39 p.m.) Review request for Plasma. Description --- I fixed the QML battery monitor to be fairly usable and this diff merges it to master. Diffs - plasma/generic/applets/CMakeLists.txt 2dedcb2 plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION plasma/generic/applets/batterymonitor/README.txt PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen-inkscape.svgz PRE-CREATION plasma/generic/applets/batterymonitor/battery-oxygen.svgz PRE-CREATION plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/config.ui PRE-CREATION plasma/generic/applets/batterymonitor/metadata.desktop PRE-CREATION plasma/generic/dataengines/powermanagement/powermanagementengine.h 20642c2 plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 5572fcb plasma/generic/dataengines/powermanagement/powermanagementjob.h 2c32015 plasma/generic/dataengines/powermanagement/powermanagementjob.cpp e205bb0 plasma/generic/dataengines/powermanagement/powermanagementservice.operations ad1301f Diff: http://git.reviewboard.kde.org/r/104226/diff/ Testing --- Applet and dataengine both tested and work fine. Screenshots --- http://git.reviewboard.kde.org/r/104226/s/464/ Thanks, Viranch Mehta ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Merge the final and fixed QML battery monitor to master.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104226/ --- (Updated March 14, 2012, 6:46 p.m.) Review request for Plasma. Changes --- Fix the typo i18n(%1...) to i18n(%1%...) to show the '%' sign in Battery: field of the popup. Description --- I fixed the QML battery monitor to be fairly usable and this diff merges it to master. Diffs (updated) - plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION plasma/generic/applets/batterymonitor/README.txt PRE-CREATION plasma/generic/applets/CMakeLists.txt 2dedcb2 plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml PRE-CREATION plasma/generic/applets/batterymonitor/contents/ui/config.ui PRE-CREATION plasma/generic/applets/batterymonitor/metadata.desktop PRE-CREATION plasma/generic/dataengines/powermanagement/powermanagementengine.h 20642c2 plasma/generic/dataengines/powermanagement/powermanagementengine.cpp 5572fcb plasma/generic/dataengines/powermanagement/powermanagementjob.h 2c32015 plasma/generic/dataengines/powermanagement/powermanagementjob.cpp e205bb0 plasma/generic/dataengines/powermanagement/powermanagementservice.operations ad1301f Diff: http://git.reviewboard.kde.org/r/104226/diff/ Testing --- Applet and dataengine both tested and work fine. Screenshots --- http://git.reviewboard.kde.org/r/104226/s/464/ Thanks, Viranch Mehta ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Removing of decorations
On Mar 15, 2012 1:22 AM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, March 11, 2012 11:01:11 Martin Gräßlin wrote: Do we have to include by default a visually outdated theme (Laptop) or an even broken theme (Plastik) just for thin clients? given that i don't want to have to answer all the problems and complaints from our large user base of thin client installs: imho, yes. at the very least, pick one, clean it up a little bit if needed and drop the rest. but not having something for thin clients at this point would be a disasterous mistake in terms of user relations and existing user base support. It will also be a problem for those who use desktops remotely for a variety of reasons. It also helps to have a simpler style when diagnosing graphics card related problems. -- Aaron J. Seigo Regards, Ben ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: RFC: Removing of decorations
On Wednesday 14 March 2012 13:22:40 Aaron J. Seigo wrote: On Sunday, March 11, 2012 11:01:11 Martin Gräßlin wrote: Do we have to include by default a visually outdated theme (Laptop) or an even broken theme (Plastik) just for thin clients? given that i don't want to have to answer all the problems and complaints from our large user base of thin client installs: imho, yes. at the very least, pick one, clean it up a little bit if needed and drop the rest. but not having something for thin clients at this point would be a disasterous mistake in terms of user relations and existing user base support. I take this as a veto from the workspace coordinator ;-) In that case I propose to only drop b2 and Plastik and keep laptop under a new name (maybe just lightweight or thin client). I would drop Plastik due to the fact that it is broken with compositing and I don't see anybody starting to fix it. For 4.10 I would like to see a new modern style for thin clients being implemented. I'll talk to Nuno. Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Removing of decorations
On Wednesday, March 14, 2012 20:11:29 Martin Gräßlin wrote: propose to only drop b2 and Plastik and keep laptop under a new name (maybe just lightweight or thin client). I would drop Plastik due to the fact that it is broken with compositing and I don't see anybody starting to fix it. sounds like a good plan. i would avoid the term lightweight however (it implies the wrong things about oxygen ;) and perhaps use something like simple or minimal. oxygen is elegant, laptop would be minimal (or similar) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
unity-like interface
I'm sure almost everyone here has seen the videos which make the Plasma Desktop shell like the Unity interface. I think these setups are beautiful, but my my gripe with them is that when a window is maximized, the window isn't integrated with the default panel on top. So when you sling your mouse to the top right of the screen and left click, you aren't closing the window like you do in Unity or in the default setup for Plasma Desktop, which makes for an accessibility problem. Because I find the oxygenized Unity-like interface appealing, I want to fix this problem and I'm going to dedicate some of my time to working on this; but I need guidance. This is where you guys can help! ...hopefully :) Ideally this work can be downloaded as an activity template, right? Or should activities not be confused with shells? There's someone else working on a Kwin-QML interface similar to what you would get combining Moblin and Gnome, and he's looking at making it a shell. Aaron, you mentioned that there is some work needed so that script packages can advertise a bit more clearly what they do (e.g. 'remake the whole desktop') and then present that in the UI, are you referring to shells or activities? You also stated, we just need to add the ability to run a kwin js after the plasma-desktop js for the full effect, how do you propose doing this? Assuming activities are the way forward for this oxygenized-Unity interface idea (henceforth called Amity) , here's a link which may be relevant to this work: http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting#Templates In the metadata.desktop file, can you specify in X-KDE-PluginInfo-Depends= other widgets the activity depends uses? In my case, initially, I need the Icon-only task manager and Takeoff widgets. Also, what do I need to look into in integrating a maximized window's titlebar into the default panel? This should be enough to get me started. Best regards Plasma dev team! -- Heath Matlock +1 256 274 4225 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
New location of Plasma Active forum
Hi, Just a heads up - we've made some minor modifications to the forum structure at forum.kde.org and the Plasma Active forum has been moved to the Workspace subforum http://forum.kde.org/viewforum.php?f=66. Note that the forum URL stays the same, so there shouldn't be any broken links. Please let me know if you have any concerns. With best regards, Hans ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
