Re: Review Request: Fix the import of Locale Gallery

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105227/#review14659
---

Ship it!


Ship It!

- Marco Martin


On June 12, 2012, 1:13 p.m., Giorgos Tsiapaliwkas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105227/
> ---
> 
> (Updated June 12, 2012, 1:13 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Hello,
> 
> I fixed the import of the locale gallery.
> I replaced import org.kde.plasma.locale 0.1 with import org.kde.locale 0.1.
> 
> 
> Diffs
> -
> 
>   plasma/declarative/localegallery/contents/ui/main.qml 3110e91 
> 
> Diff: http://git.reviewboard.kde.org/r/105227/diff/
> 
> 
> Testing
> ---
> 
> it works
> 
> 
> Thanks,
> 
> Giorgos Tsiapaliwkas
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix value not being updated when dragging slider, also fix animation when using keys.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105236/#review14708
---


makes sense, the slider background should follow the handle otherwise you can 
see the man behind the curtain ;)


plasma/declarativeimports/plasmacomponents/qml/Slider.qml
<http://git.reviewboard.kde.org/r/105236/#comment11614>

whitespace ;)


- Marco Martin


On June 13, 2012, 8:09 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105236/
> ---
> 
> (Updated June 13, 2012, 8:09 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> When using the keyboard to adjust the slider use the same animation for the 
> groove (the blue line showing amount) and the drag handle. This fixes a bug 
> in which the bar would move then the handle would animate to catch up.
> 
> In the same patch (and different commit) fix a bug where the value would not 
> be changed whilst dragging, only when released. This has caused issues in the 
> battery applet where the brightness cannot be seen and has bugs reported.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/Slider.qml d8b66db 
> 
> Diff: http://git.reviewboard.kde.org/r/105236/diff/
> 
> 
> Testing
> ---
> 
> Tested on battery plasmoid.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix value not being updated when dragging slider, also fix animation when using keys.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105236/#review14709
---

Ship it!


- Marco Martin


On June 13, 2012, 8:09 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105236/
> ---
> 
> (Updated June 13, 2012, 8:09 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> When using the keyboard to adjust the slider use the same animation for the 
> groove (the blue line showing amount) and the drag handle. This fixes a bug 
> in which the bar would move then the handle would animate to catch up.
> 
> In the same patch (and different commit) fix a bug where the value would not 
> be changed whilst dragging, only when released. This has caused issues in the 
> battery applet where the brightness cannot be seen and has bugs reported.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/Slider.qml d8b66db 
> 
> Diff: http://git.reviewboard.kde.org/r/105236/diff/
> 
> 
> Testing
> ---
> 
> Tested on battery plasmoid.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Quality Team: LCD weather station and calendar (in panel) are really broken

[Marco Martin]

On Thu, Jun 14, 2012 at 5:58 PM, David Edmundson
 wrote:

this is just about a little point of this, more of this later

> Have you discussed the weather LCD applet with the team before denying
> the request. I've not seen anything? Either you haven't, and have just
> decided on behalf of your entire team which isn't a good example of
> communication, or there's a communication channel which doesn't
> include me...which again isn't a good example of good inclusive
> communication.

i take responsibility on this, i was part of the irc discussion, and i
was agreeing with the decision.
so i was agreeing completely against the removal of the applet.
unfortunaltely i did not document it, so there wasn't indeed much discussion :/

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Quality Team: LCD weather station and calendar (in panel) are really broken

[Marco Martin]

On Thu, Jun 14, 2012 at 10:36 PM, Sebastian Kügler  wrote:
> Hey all,
>
>> We hope these can be fixed as well as the regressions regularly sent to
>> the list.
>
> I think things we can take away from this thread:
>
> - We want each other to look at commits more
> - Just removing components or reverting commits is not a way to fix bugs, it
>  probably leads to more regressions even
> - We need to improve on our collaboration
> - New people coming into the team, in which form however, need to learn the
>  ropes, and screwups once in a while are quite natural. It's growing pains,
>  though, and growing is a good thing
> - We share the same goals, and should all try to not step on each other's
>  toes. (Ok, the last thing hasn't been mentioned explicitely, but still seems
>  quite well backed by evidence. :P)
>

+1

as i said, personally i didn't see problems... i agreed with the
revert of the revert, i agreed with leaving weatherstation in. i
didn't see a problem of that decision being seen as unilateral.

this seems to hurt new people, adapting to a workflow is difficult,
and the workflow is for sure far from perfect.

for this thread: let's everybody think about those points, and let's
use what we learnt dealing with the next issue, being an important
review request, or a decision about what action to take over a severe
bug.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: blogs from the sprint?

[Marco Martin]

On Thu, Jun 14, 2012 at 10:18 PM, Aaron J. Seigo  wrote:
> hello to everyone at the workspace sprint:
>
> can we have a blog or two about the happenings? i think we're probably all
> interested in what's happening there ...
>
> thanks ...

to be brief for now:
something out of it very good, but slowly gaining energy like a
spring, hopefully with fgreat results in the end.
 in contrast to a devel one where we have more little developments :)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No "remaining time" option in battery monitor?

[Marco Martin]

On Fri, Jun 15, 2012 at 12:54 AM, Viranch Mehta  wrote:
> Hi,
>
> I just noticed there is no option of "remaining time" in the latest stable
> released
> version of the c++ battery applet (4.8.4). Have we discarded it? I want to
> know this
> so I can know whether I should keep this in the qml version.

there was an old discussion about  it.

basically there are several problem wit the remaining time (is false
information)
http://osdir.com/ml/plasma-devel/2009-05/msg00269.html

i think the qml version should be for now coherent with the c++ applet
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No "remaining time" option in battery monitor?

[Marco Martin]

On Fri, Jun 15, 2012 at 2:08 AM, Shaun Reich  wrote:
> To me it looks less like a "discussion" and more like a "aaron got pissed
> because it didn't work for him, who himself is one person therefore nobody
> should have it".
>

how you exactly expect we engage in a productiive conversation about
the topic if you start like that? can we start on a different foot on
this or is not worth to continue, sorry.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: moving forward

[Marco Martin]

On Fri, Jun 15, 2012 at 9:11 AM, Aaron J. Seigo  wrote:
> hello...
>
> it has become apparent that we need to do something here about the attitude
> demonstrated by some of those who have chosen to participate in plasma.
>
> to address this, i invite you all to an irc meeting next week. below is a
> doodle where you can register which times work for you and we'll select
> whatever works best for most people:
>
>        http://www.doodle.com/8dxigcxwr6527z5t

it'a moment where a lot of people is starting to get near and all at once.
it's awesome but we clearlysee ot's causing a big traffic jam.
to avoid to run over each other let's take a step back and reflect about this.
i support the irc meeting idea
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: No "remaining time" option in battery monitor?

[Marco Martin]

On Friday 15 June 2012, Shaun Reich wrote:
> Was it ever even mainlined? Thought it was just in some branch..
> 
yes is in 4.9


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make sure the views don't get overscrolled when clicking the scrollbar arrows

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105268/#review14779
---

Ship it!


Ship It!

- Marco Martin


On June 15, 2012, 11:46 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105268/
> ---
> 
> (Updated June 15, 2012, 11:46 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Right now when you move the scrollbar handle at the end (bottom if it's 
> vertical scrollbar) and click the scrollbar down arrow/press the down key, 
> the view continues to move up, which results in the content going outside of 
> the view.
> 
> This patch prevents this from happening.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/ScrollBar.qml 719b83f 
> 
> Diff: http://git.reviewboard.kde.org/r/105268/diff/
> 
> 
> Testing
> ---
> 
> Tested on widgets gallery.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make sure vertical slider's handle have the same shadow as the horizontal one

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105269/#review14781
---

Ship it!


for now this patch already makes things a bit better, so +1.

however, i think the proper solution that should be done is not using rotations 
at all, but handle the vertical/horizontal case more separately, even tough it 
leads to a more complicate code

- Marco Martin


On June 16, 2012, 12:23 a.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105269/
> ---
> 
> (Updated June 16, 2012, 12:23 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> The vertical sliders are rotated horizontal sliders including all the light 
> effects, which looks bad as it appears like there are two different light 
> sources. This patch rotates back the slider handle, so all the handles have 
> consistent shadowing. The grooves should also have consistent shadow, but 
> that may come in later patch (also it's way less visible).
> 
> See screenshots.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/Slider.qml 5867164 
> 
> Diff: http://git.reviewboard.kde.org/r/105269/diff/
> 
> 
> Testing
> ---
> 
> Tested on widget gallery.
> 
> 
> Screenshots
> ---
> 
> Before
>   http://git.reviewboard.kde.org/r/105269/s/603/
> After
>   http://git.reviewboard.kde.org/r/105269/s/604/
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix sourceFilter to actually filter the sources in QML DataModel

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105267/#review14782
---

Ship it!


good catch

- Marco Martin


On June 15, 2012, 10:20 p.m., Viranch Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105267/
> ---
> 
> (Updated June 15, 2012, 10:20 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This fixes a bug in PlasmaCore.DataModel. The DataModel does not correctly 
> filter the sources when sourceFilter is provided.
> 
> The dataUpdated function does terminate when sourceName does not match the 
> sourceFilter, but when it does match, all sources from the data engine are 
> added to the said DataModel instead of checking for the sourceFilter again. 
> This patch introduces that check.
> 
> (the patch is clearer than the description)
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/core/datamodel.cpp 9400dbe 
> 
> Diff: http://git.reviewboard.kde.org/r/105267/diff/
> 
> 
> Testing
> ---
> 
> Tested with Battery Monitor applet when there are multiple batteries and a 
> model is required consisting of only the battery sources from powermanagement 
> engine.
> 
> Works as expected with the patch.
> 
> 
> Thanks,
> 
> Viranch Mehta
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make sure vertical slider's handle have the same shadow as the horizontal one

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105269/#review14788
---


i like the last patch update, i think it should go in

- Marco Martin


On June 16, 2012, 12:03 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105269/
> ---
> 
> (Updated June 16, 2012, 12:03 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> The vertical sliders are rotated horizontal sliders including all the light 
> effects, which looks bad as it appears like there are two different light 
> sources. This patch rotates back the slider handle, so all the handles have 
> consistent shadowing. The grooves should also have consistent shadow, but 
> that may come in later patch (also it's way less visible).
> 
> See screenshots.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/Slider.qml 5867164 
> 
> Diff: http://git.reviewboard.kde.org/r/105269/diff/
> 
> 
> Testing
> ---
> 
> Tested on widget gallery.
> 
> 
> Screenshots
> ---
> 
> Before
>   http://git.reviewboard.kde.org/r/105269/s/603/
> After
>   http://git.reviewboard.kde.org/r/105269/s/604/
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Activities vs Virtual Desktop document on the wiki

[Marco Martin]

On Saturday 16 June 2012, Aurélien Gâteau wrote:
> Hi,
> 
> One of the output of the KDE Vision sprint is a document I started to write
> to define activities and how they relate to virtual desktops. You can find
> it here:
> http://community.kde.org/Plasma/Workspace_Sprint/ActivitiesAndVirtualDeskt
> ops

This comes out of probably some views that are being adjusted over time:
the old idea was to keep activities and virtual desktops as orhogonal 
functions:
activities is about separing tasks by well.. activity, while virtual desktops 
becomes intended as a purely spatial organization of windows (just poor man 
multimonitor)

now, since virtual desktops can also be used as a (very, very) primitive 
version of activities (separing windows as activities) are very often seen as 
overlapping concepts, therefore confusing.

I would like to keep this definition of orthogonality between activities and 
virtual desktops in the definition, describing use cases for
a) separation by activity
b) spatial organization
then describe how b) is coveed by activities.
If a) is something that should stay in the long years to come, is an open 
question.

I clearly see (and clearly came out from the Tree game) that in the end in the 
practical use VDs and Activities often end up overlapping.
Also virtual desktops are so limited by x11 and netwm tecnicalities that may 
become a slowly fading away legacy.

> If you are involved in activities can you review it? If it makes sense I'll
> move it to /Plasma/ActivitiesAndVirtualDesktops and link to it from
> /Plasma.

I think it still needs a bit of work before, but should definitely end up 
there in the end.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Support for multiple batteries in battery monitor applet

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105277/#review14800
---


i think the change is on the right path, but should wait for the unfreeze, 
since is not a "trivial" fix

- Marco Martin


On June 16, 2012, 3:25 p.m., Viranch Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105277/
> ---
> 
> (Updated June 16, 2012, 3:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch implements support for computers with multiple batteries in the 
> battery monitor applet.
> 
> I'm not sure if I should push it now or after the unfreeze. This review 
> addresses the bug #301533
> 
> 
> This addresses bug 301533.
> http://bugs.kde.org/show_bug.cgi?id=301533
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/batterymonitor/contents/code/logic.js PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a 
>   plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml 
> 08a46ec 
> 
> Diff: http://git.reviewboard.kde.org/r/105277/diff/
> 
> 
> Testing
> ---
> 
> Added dummy battery sources in power management engine and tested with it. 
> Works fine, as expected with such sources.
> 
> Can someone with multiple batteries please test the patch? since I don't have 
> a computer with multiple batteries.
> 
> 
> Thanks,
> 
> Viranch Mehta
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Support for multiple batteries in battery monitor applet

[Marco Martin]

> On June 16, 2012, 6:40 p.m., Marco Martin wrote:
> > i think the change is on the right path, but should wait for the unfreeze, 
> > since is not a "trivial" fix
> 
> David Edmundson wrote:
> Given this patch is untested (due to Viranch having only one battery) and 
> that we will have a lot of angry users complaining that the feature is 
> missing, can I suggest we submit a version with this patch to kde-look.org, 
> so that it is available in "get new stuff".
> 
> This will give us the extra testing before we merge in 4.10, and at least 
> provide a workaround we can share for those users, and the people giving 
> support.

actually a good idea, would give a fixed place to sent people.


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105277/#review14800
---


On June 16, 2012, 3:25 p.m., Viranch Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105277/
> ---
> 
> (Updated June 16, 2012, 3:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch implements support for computers with multiple batteries in the 
> battery monitor applet.
> 
> I'm not sure if I should push it now or after the unfreeze. This review 
> addresses the bug #301533
> 
> 
> This addresses bug 301533.
> http://bugs.kde.org/show_bug.cgi?id=301533
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/batterymonitor/contents/code/logic.js PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a 
>   plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml 
> 08a46ec 
> 
> Diff: http://git.reviewboard.kde.org/r/105277/diff/
> 
> 
> Testing
> ---
> 
> Added dummy battery sources in power management engine and tested with it. 
> Works fine, as expected with such sources.
> 
> Can someone with multiple batteries please test the patch? since I don't have 
> a computer with multiple batteries.
> 
> 
> Thanks,
> 
> Viranch Mehta
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Support for multiple batteries in battery monitor applet

[Marco Martin]

> On June 16, 2012, 6:40 p.m., Marco Martin wrote:
> > i think the change is on the right path, but should wait for the unfreeze, 
> > since is not a "trivial" fix
> 
> David Edmundson wrote:
> Given this patch is untested (due to Viranch having only one battery) and 
> that we will have a lot of angry users complaining that the feature is 
> missing, can I suggest we submit a version with this patch to kde-look.org, 
> so that it is available in "get new stuff".
> 
> This will give us the extra testing before we merge in 4.10, and at least 
> provide a workaround we can share for those users, and the people giving 
> support.
> 
> Marco Martin wrote:
> actually a good idea, would give a fixed place to sent people.

uh, this screams syncrotron as well :p


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105277/#review14800
---


On June 16, 2012, 3:25 p.m., Viranch Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105277/
> ---
> 
> (Updated June 16, 2012, 3:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch implements support for computers with multiple batteries in the 
> battery monitor applet.
> 
> I'm not sure if I should push it now or after the unfreeze. This review 
> addresses the bug #301533
> 
> 
> This addresses bug 301533.
> http://bugs.kde.org/show_bug.cgi?id=301533
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/batterymonitor/contents/code/logic.js PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml a2ab72a 
>   plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml 
> 08a46ec 
> 
> Diff: http://git.reviewboard.kde.org/r/105277/diff/
> 
> 
> Testing
> ---
> 
> Added dummy battery sources in power management engine and tested with it. 
> Works fine, as expected with such sources.
> 
> Can someone with multiple batteries please test the patch? since I don't have 
> a computer with multiple batteries.
> 
> 
> Thanks,
> 
> Viranch Mehta
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Activities vs Virtual Desktop document on the wiki

[Marco Martin]

On Sunday 17 June 2012, Ivan Cukic wrote:
> > In short: we identified activities as one of the core features of our
> > workspaces and VDs are close to fall off the tree.
> 
> A brave decision. Brave indeed.
> 
> If that is really going to happen we need a kicking activities UI.
> Activities are not even close to the usability of VDs unfortunately.
> 
> So, IMO, we need dozens of mockups by the most diverse kind of users we've
> ever seen :)

yeah, that's why vds won't go away for the foresable future, will probably be 
a long l long phasing out period ;)

and yes the number one problem identified in activities is that the effort 
right now that has to be used to create, manage, switch them is a very high 
barries "one should not even notice he's using them"
easier said than done uh? :p


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add a keyboard shortcut to stop the current activity

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105279/#review14815
---

Ship it!


well, ship it but not now ;)
should be indeed when master opens again, but the patch is fine

- Marco Martin


On June 16, 2012, 11:39 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105279/
> ---
> 
> (Updated June 16, 2012, 11:39 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Add a keyboard shortcut to stop the current activity. This was suggested at 
> the KDE Workspace sprint in order to improve workflow.
> 
> Intend to merge into 4.10 after freeze not 4.9. Also happy to discuss 
> alternate default key shortcuts. 
> 
> 
> This addresses bug 302003.
> http://bugs.kde.org/show_bug.cgi?id=302003
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/desktopcorona.h df111b2 
>   plasma/desktop/shell/desktopcorona.cpp c7f3eec 
> 
> Diff: http://git.reviewboard.kde.org/r/105279/diff/
> 
> 
> Testing
> ---
> 
> Pressed shortcut, tested current activity closed, and that I could not close 
> the last activity.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tooltips to QML: PlasmaCore.Dialog questions

[Marco Martin]

On Monday 18 June 2012, Mark wrote:
> 
> Here is what's wrong with it.
> 1. I "need" to use the popupPosition function. But for which purpose?
> I can perfectly align my tooltip using X and Y based on the component.
> Actually, my earlier issue of having a default 100x100 sized dialog is
> because i wasn't using popupPosition! Yeah, go figure that one out. I
> just don't like the fact that i need to use that function. What i am
> doing right now is calling popupPosition (because it has to be done)
> then just use my own X and Y since the popupPosition isn't even
> working as i want it. So yeah, i'm really doing
> dialog.popupPosition(null, Qt.AlignCenter) because i have to..

yes, this function is ugly, however, let's backtrack a bit to see why it does 
exists:
this is about positioning an x11 top level window on screen, coordinates you 
have no idea in qml because they don't have a relationship with the position x 
and y of an item or even the position mapped to the scene coordinates, so you 
need somebody that tells you a "correct" position
that has also to take into accound problems like actially fitting into the 
screen (and not cut a piece away), popping up in the right screen, taking into 
account extended struts to take panels into account.

that's why as soon you touch an x11 window things get ugly ;)

> 2. This is a very important one which is not possible in the current
> dialog. When you hover your taskbar to some element that has a bigger
> tooltip (like the network manager icon) i want the tooltip to resize
> in an animated way. That's not possible because width and height are
> read-only!

resizing X11 windows is quite slow (and asynchronous, even), so accessing it 
directly from qml would have quite slow and cpu intensive results.
until wayland the only possibility would be approximating smooth resizing with 
a kwin plugin

> 3. The margin stuff that's done somewhere in the dialog C++ side is
> not always working correctly when you animate the dialog. For
> instance, my dialog is the right size, but when animation it kinda
> "jumps" just when the animation is done thus screwing the layout!
> 4. The way that i need to set a "main item" inside the
> PlasmaCore.Dialog looks really really really ugly!
> 
> So here we are again. I'm still working on the same issue and the darn
> popup dialog thing with it's custom security measures to prevent full
> screen stuff is really irritating me! So i would like to ask - again!
> - to allow me to implement the Window in QML just like it is in Qt
> Desktop Components and add it to probably QtExtraComponents. Right now
> these dialog issues are blocking me to continue since it's not that
> obvious when i hit another snag if it's in the dialog (again) or in my
> code.

seriously, top level windows are too hard to get right if any kind of control 
is given:
* the window background has to be done in the c++ part: it needs to change svg 
if composite is off, and in this case to set a window mask to get the window 
shape right (no usecase without compositing isn't going to be dropped as long 
as we are on X11)
* window positioning is hard to get right: it has zero relationship with scene 
positioning of the items and has some corner cases to get right multimonitor 
and extended struts
* plasma components are mostly for plasmoids, where creation of windows is a 
corner use case, normally they just should not. Again, they are not for 
desktop applications, something else would be needed. I know that at the 
moment there isn't any solution we can depend of to do desktop applications, 
but doesn't change the scope of qml in plasma (that is a limited subset of the 
use of qml in the future)

> I understand that you guys (marco only?) want to prevent abusive
> applications popping up that make fullscreen plasmoids, but that
> argument is really faulty. I already made a fullscreen dialog just to
> see if it's possible. Obviously it is and it's easy once you know how
> to. You can make it as hard as possible like it is now, but that is
> really making it limited (and ugly) for other real world usages like
> these tooltips.
> 
> Lastly, i noticed there is a PlasmaCore.Dialog and a
> PlasmaComponents.Dialog ... Does anyone know what the difference is
> and why there are 2 of them? I also added

yep, that sucks (but reading documentation of them helps :p)
after Dialog was binded in plasmacore, qtcomponents got a standard-ish Dialog 
component, but that one is higher level:
it's a message dialog with optional ok/cancel buttons, titlebar and what not

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tooltips to QML: PlasmaCore.Dialog questions

[Marco Martin]

On Monday 18 June 2012, Mark wrote:
> On Mon, Jun 18, 2012 at 1:52 PM, Marco Martin  wrote:
> > On Monday 18 June 2012, Mark wrote:
> >> Here is what's wrong with it.
> >> 1. I "need" to use the popupPosition function. But for which purpose?
> >> I can perfectly align my tooltip using X and Y based on the component.
> >> Actually, my earlier issue of having a default 100x100 sized dialog is
> >> because i wasn't using popupPosition! Yeah, go figure that one out. I
> >> just don't like the fact that i need to use that function. What i am
> >> doing right now is calling popupPosition (because it has to be done)
> >> then just use my own X and Y since the popupPosition isn't even
> >> working as i want it. So yeah, i'm really doing
> >> dialog.popupPosition(null, Qt.AlignCenter) because i have to..
> > 
> > yes, this function is ugly, however, let's backtrack a bit to see why it
> > does exists:
> > this is about positioning an x11 top level window on screen, coordinates
> > you have no idea in qml because they don't have a relationship with the
> > position x and y of an item or even the position mapped to the scene
> > coordinates, so you need somebody that tells you a "correct" position
> > that has also to take into accound problems like actially fitting into
> > the screen (and not cut a piece away), popping up in the right screen,
> > taking into account extended struts to take panels into account.
> > 
> > that's why as soon you touch an x11 window things get ugly ;)
> 
> I fully understand your case and it makes sense. No issue about that.
> The issue i have have is that i simply don't have an Item object to
> run popupPosition against! What i'm getting is just a simple QRect

so, two different problems here:
is the dialog not appearing if you don't run popupposition before? if this is 
the case this is indeed a bug that should be fixed, but is completely 
unrelated from what is needed there.

let's take a step back, so what's needed here.. a tooltip.
that's how they work in plasma:
an item (qgraphicswidget at the moment, what we want is for them to work on 
any graphical item, ie any object with x,y,width,height properties) has some 
extra information attached to it (TooltipData in libplasma) and after some 
trigger (ie mouse over) it get displayed.
maybe in a tooltip, maybe discarded on touchscreen, maybe spoken with 
texttospeech if some accessibility option is on. (note that in libplasma, the 
ToolTip class is private and not exposed in any way)
in the idealworld(tm) the fact that the actual representation is a tooltip is 
utterly irrelevant.
I would also love if the qml version would still be as private as the old one, 
but unfortunately is very difficult to have properly private qml components.

so, the two actually relevant things here (and thus that should be api 
accessible in some way) are the information and the item is attached to.

> with the position of where a given widget is positioned that should
> have a Dialog on top of it. Then i manually calculate the position in
> QML with this exact code: http://paste.kde.org/502508/

positions should never, ever be calculated in javascript, there are corner 
cases that you can't even notice because you don't have info on the usable 
work area geometry.
 
> Now i could go a few ways here.
> - Don't send the QRect to QML, but send the QGraphicsWidget to QML
> which seems to be very well hidden. I won't say it's impossible
> because nothing is in C++, but it certainly is very difficult and
> something i'd like to prevent

that is the way is designed to work and certainly the way it should work. so 
if it has become very difficult for some reason, there is some layer of 
implementation that is not doing the right thing.

the code that actually positions windows should be only a centralised one, for 
behavior consistency and for the previously mentioned corner cases that may 
lead to an incorrect position in so many ways.
and that centralised libplasma function is binded there in popupposition.

> In my case i simply don't need popupPosition and i don't even have a
> use for it. What i would really like is if PlasmaCore.Dialog could
> start working without that function. That would really help me.

again, it is indeed a bug if the dialog doesn't appear without having called 
it once. however it should never, ever be manually positioned

> >> 2. This is a very important one which is not possible in the current
> >> dialog. When you hover your taskbar to some element that has a bigger
> >> tooltip (like the network manager icon) i want the tooltip to resize
> >> in an

Re: QML Tooltip progression. Hitting a few snags.

[Marco Martin]

ne/view.

in the end the easiest solution would be taking the current ToolTip private 
class, showel a QDeclarativeView in it as the main layout element and be done.

the reasons why Dialog is at the moment suitable are mainly two:
* it removes the borders when it goes at the edge of the screen
* it uses dialogs/background.svgz instead of widgets/tooltip.svgz for its 
background

i would really rather not add api to control those two things, given kdelibs 
is frozen and i don't think would be a good approach anyways.

> So these are the options i currently see:
> 
> - Abandon PlasmaCore.Dialog, copy the C++ side behind it and fix it
> according to my needs. This also means that i will have a custom QML
> import where that new component will be living. Added dependency of
> plasma.

no, it doesn't have to be an import there are several other ways to do it, 
that in this case are more suitable.

a class name that will instantiate a c++ object can be registered from the c++ 
part with qmlRegisterType
or in this case even better, the whole qgraphicsview would be instantiated 
from the c++ part in the tooltipmanager itself (would be what is the ToolTip 
private class nowdays) so the qml would only manage the layout and won't know 
about the window at all (if in the end is decided to do an independent thing 
where is not an issue to have its own private scene it may even be a 
qdeclarativeview).
this is imo the best option.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: QML Tooltip progression. Hitting a few snags.

[Marco Martin]

On Tuesday 19 June 2012, Mark wrote:
> Op dinsdag 19 juni 2012 schreef Marco Martin (notm...@gmail.com) het
> 
> volgende:
> > On Tuesday 19 June 2012, Mark wrote:
> > > Hi,
> > > 
> > > Today was quite an interesting day with QML tooltips. One issue after
> > > the other popped up.
> > 
> > but it's *very* useful that you made those issues pop up, don't see it as
> > wasted time ;)
> 
> Yeah, well... I hate the fact that everytime i want to do something big in
> kde i hit a very hard blocking issue. The last one was with adding just one
> more QAction (KAction) shortcut, that turned out to be a design issue in
> kde's kaction and kshortcut that mobes back into qt itself! I don't see
> this one as wasted time, but it is frustrating at times.
> 
> > > What i have right now are working tooltips in a very rough shape. The
> > > icon provided is also being shown in the tooltip and overall it looks
> > > somewhat decent to continue to the next step. That would be to make
> > > Dolphin and System Settings usable with these tooltips.
> > > 
> > > Sadly, while improving it further, i've hit a blocking issue that i
> > > can't fix. The following issues arose of which the 2nd one is blocking
> > > me right now.
> > > 1. Somehow when moving the cursor from an item that shows a tooltip
> > > (like the tasks) to another item that shows a bigger tooltip (like the
> > > pager) the result is a messed up layout: http://ompldr.org/vZWUyNw
> > 
> > having seen a bit of the code, i think there is still the possibility
> > that is
> > the tooltip mainitem having the wrong size (otherwise would be clipped
> > only at
> > bottom)
> > would need some debug to say what is the size of mainitem and what is the
> > size
> > of the things it contains
> 
> Could you?
> 
> > > This doesn't happen if i directly hover over the pager icon for the
> > > tooltip. I haven't found a cause for this. (note, the position itself
> > > is OK here, but done manually which is wrong)
> > > 2. Tooltips positioned using popupPosition are positioned directly
> > > above the item where they need to be positioned:
> > > http://ompldr.org/vZWUyNg This is the way it's currently designed and
> > > Marco doesn't want to break the design in the KDE 4.x series. This is
> > > something he will look into for KF5.
> > 
> > this doesn't depend from the position, that is correct.
> > depends from the fact that Dialog doesn't paint the borders that are near
> > to
> > the screen edge or to a panel.
> > 
> > now, this is ok for the use case of popups, because a) they are designed
> > as objects that come out from the panel, b) when is attached to the
> > screen edge
> > it will accept input from the mouse until the very border (fitts law)
> > 
> > > 3. The height of the tooltips cannot be animated because height (and
> > > width) are read-only. Furthermore, since it's a window, it's likely to
> > > be slow as well due to X11 resizing stuff.
> > 
> > yeah, i don't much see solutions to this one on x11 (waylaaand;).
> > iirc there was a kwin plugin in the works that tried to fake a smooth
> > resize
> > of windows with a transition of their pixmaps? is that thing still alive?
> > 
> > in brief, is not pretty, bit don't worry about size animation for now
> 
>  As said, i'm oke with this limitation.
> 
> > > 4. added to this is my dislike against PlasmaCore.Dialog. I simply
> > > don't like it but gave it my best try to use it.
> > > 
> > > The first one is something i can work around. Third is also something
> > > i can live with, but combined with the issues i had before and along
> > > with my dislike for PlasmaCore.Dialog and the fundamental design
> > > change that needs to happen to make it usable for tooltips makes me
> > > think that i should perhaps do things a bit differently.
> > 
> > It's done for popups, and in order for popups to be consistent, freedom
> > to do
> > whatever with it must be sacrified
> > 
> > > Marco also suggested that i copy the current PlasmaCore.Dialog C++
> > > side and adjust it for the tooltip needs. That's the part where i
> > > really could use some help in deciding how i should go further with
> > > this. The side effects are not really what i'd like to see. If i
> > > follow this approach it means that the (to be made) 

Re: Review Request: Plasm qml-components: also highlight the dualstate button on keyboard-focus

[Marco Martin]

> On June 14, 2012, 6:18 p.m., Aaron J. Seigo wrote:
> > plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml, 
> > lines 77-78
> > 
> >
> > loos like this will work but i dislike how shadowLoader.state is being 
> > set all over the place in a rather procedural manner. much nicer imho would 
> > be sth like:
> > 
> > Loader {
> > id: shadowLoader
> > anchors.fill: surfaceLoader
> > state: (duableButton.enabled && dualButton.focus) ? "hover" : 
> > "shadow"
> > }
> > 
> > and then do the right thing in Keys.onSpacePressed, 
> > Keys.onReturnPressed, etc.
> > 
> > this would also get rid of the entered() function and maybe even clean 
> > up the MouseArea below as well.
> > 
> > to me this would just feel "more QML"
> > 
> > Marco: what do you think?

yeah, i agree.
to me apart this small issue the change in behaviour is correct, so correct it 
and can be pushed


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105232/#review14727
---


On June 12, 2012, 10:25 p.m., Johannes Tröscher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105232/
> ---
> 
> (Updated June 12, 2012, 10:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> this will enable the highlight on a dualstatebutton (like a checkbox) also if 
> the button has keyboardfocus.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml 
> 1579e88 
> 
> Diff: http://git.reviewboard.kde.org/r/105232/diff/
> 
> 
> Testing
> ---
> 
> tested, works
> 
> 
> Thanks,
> 
> Johannes Tröscher
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Save scrollbar position on plasma exit

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104258/#review14906
---


what is the status of this? has been pushed? is pretty old, should be either 
dropped or submitted but not left dangling

- Marco Martin


On March 16, 2012, 4:31 p.m., Ignat Semenov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104258/
> ---
> 
> (Updated March 16, 2012, 4:31 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 (max>0)" 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 94efe44 
> 
> 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: Review Request: Plasm qml-components: also highlight the dualstate button on keyboard-focus

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105232/#review14909
---

Ship it!


can you push it?

- Marco Martin


On June 20, 2012, 12:15 p.m., Johannes Tröscher wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105232/
> ---
> 
> (Updated June 20, 2012, 12:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> this will enable the highlight on a dualstatebutton (like a checkbox) also if 
> the button has keyboardfocus.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/private/DualStateButton.qml 
> 1579e88 
> 
> Diff: http://git.reviewboard.kde.org/r/105232/diff/
> 
> 
> Testing
> ---
> 
> tested, works
> 
> 
> Thanks,
> 
> Johannes Tröscher
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Team meeting today

[Marco Martin]

On Wednesday 20 June 2012, Anne-Marie Mahfouf wrote:
> I won't be there at the meeting unfortunately. I'll log it to read it.
> Personally I like things to be said face to face that's why I take time
> to write these mails. And I do feel targeted.
> In any case I hope I clarified my position and if this one reverted
> commit by me was not done properly (I think I never behaved unfairly
> within KDE, have I?), this happens quite often. Happened from you too.
> Let's then have a rule of review everything properly.
> 
> If Valorie's mail had not come I was about to mail Kevin (ervin) in
> order to have a mediator of some sort, because I was uncomfortable with
> this, not for me but for all plasma caring people (which may be or not
> "The Plasma Team").

yes, many thanks to Valorie from me as well for taking care of this.

as what should be the content of the meeting:

it should be about methodology: there is obviously a problem in how issues are 
dealth with.
what i hope for the meeting is to come out about an agreed procedure on how to 
deal with when there is a disagreement about a particular thing, in the end 
accepted conditions where one says "i still don't agree, but i'll accept the 
decision"


to be clear, there shouldn't be personal issues discussed there, since is a 
public discussion.
there may be some, but if it is the case they should be solved in private

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Team meeting today

[Marco Martin]

Hi all,
this is a very raw synopsis of the meeting, i hope we can now transform it in 
something very productive (i think the meeting especially the last part  was 
useful)

The meeting started from the realization that there is an 1% of cases where 
the discussion doesn't go well and can get people too emotional, making it not 
productive, for the project and for the morale.
Some cases of recent discussions where at first there was disagreement, but 
the discussion gone completely smoothly were analized (the 99% when things 
goes like they should), such as:

http://old.nabble.com/RFC%3A-Removing-of-decorations-td33476065.html
https://bugs.kde.org/show_bug.cgi?id=302077

some points in common have been individuated:

* we can see in those discussions the tone never escalated, even with 
disagreements, they look more like stimulating debates
* when someone wants the mantainer to change his mind stays on exclusively 
technical points: raises concerns and arguments them, like needing an use case 
for window decoration for remote sessions, that weren't considered in the 
original decision
* the maintainer proposes a third solution, balanced between the problem the 
original solution tries to address and the problem this causes. like waiting 
until a particular lightweight window decoration is here
* The discussion always stays focused, in topic

So that's how we want those discussions to happen.
There can be done a series of recommendations in order to do so, and we can 
point to people when those aren't followed.

note that those are just copied/pasted from points made over irc, so if they 
are incorrect, not completely understandable or if others missing feel free to 
correct:

* we see that there is need to document more
* especially if a discussion turns out to be recurring: document the reasons 
and point out to those
* it doesn't need to be done for everything, otherwise becomes not 
maintainable with bad signal/noise ratio
* we have established guidelines on how to interact with each other
* we don't want to blame community members for things which happened in the 
past
* We concentrate too much on energy eaters, rather than on progress
* we remind each other about our common goals if we see that a discussion goes 
in the wrong direction
* there's a lack of trust  we need to address
* if anyone breaks the guidelines (whoever they are) breaks these we point it 
out, and not write a (more angry) reply which escalates
* code reverting or being a bit invasive in non familiar areas should at least 
contact the ML or person affected
* we need a list of component and maintainer
* we respect maintainer decisions
* and, "respect the elders!"
* think about the bigger project, if an issue of disagreement risks of 
damaging/slowing down the project, is maybe the time to step back and say "i 
stil ldon't agree but i respect the decision"
* same thing if the maintainer and/or several other maintainers of related 
components didn't change their mind: respect the decision even if you still 
disagree

raw mammoth irc log: http://paste.opensuse.org/43938417 (not filtered from ot)
-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: When should a bug be considered as a regression or a release_blocker?

[Marco Martin]

On Wednesday 20 June 2012, Mark wrote:
> https://bugs.kde.org/show_bug.cgi?id=301854, that bug described the
> KGet Piechart applet as being broken. I tested that and verified that
> it indeed is completely broken and even renders outside it's applet
> space. So i marked that one as release blocker as well because it's
> useless in it's current state.

they are annoying problems indeed, but don't prevent you from using the 
workspace, that's what a blocker is

> Both issues are not something that obstruct normal KDE usage, but they
> do render some parts of KDE completely useless. I'm a bit unsure if i
> should mark such bugs as release blockers. Perhaps there should be a
> keyword called "component_blocker" indicating that a specific
> component (specified in the component field on bugzilla) is not fit to
> be shipped with the release.

i don't think we should make releases with random pieces cutted out, or they 
will never be complete


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Containment default setting

[Marco Martin]

On Thursday 21 June 2012, Aaron J. Seigo wrote:
> On Wednesday, June 20, 2012 23:54:57 Martin Klapetek wrote:
> > I imagine this could then be used in Dolphin's context menu 'Actions' and
> > possibly in Gwenview too. Should there be such dbus-interface, I would
> > add those patches to Dolphin and Gwenview.
> 
> the things i look at and weigh are:
> 
> * will the feature work consistently (multiple screens, per-virtual desktop
> containments, etc..) and not just work for some configurations

i would see a thing like that being coherent when is always the "current" one, 
ie current containment of the current desktop of the screen the mouse is in..
now if it brings to an acceptable complexity i don't know

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Containment default setting

[Marco Martin]

On Thursday 21 June 2012, Aaron J. Seigo wrote:
> On Wednesday, June 20, 2012 23:54:57 Martin Klapetek wrote:
> > I imagine this could then be used in Dolphin's context menu 'Actions' and
> > possibly in Gwenview too.
> 
> crazy idea: what about using SLC for this? Like -> Use as wallpaper
> 
> (not share because you aren't sharing with anyone; not really connecting it
> to anything; and you use it as a wallpaper because you like it that much
> :)
> 
> downside: it's not particularly discoverable because people are not used to
> SLC. i think once someone is used to SLC as a concept it will feel very
> natural .. but before then it will be a mystery.
> 
> upside: we would not need to patch each application, and we wouldn't even
> need to expose a dbus interface (this screams Plasma::Service to me...)
> 
> thoughts?

is something that could work if is publicised enough, because is not obvious, 
but when learned makes sense.

in my mind this idea gone in those 6 steps:
1) wtf?
2)WTF?
3)oh..
4)...
5)oh.. cool
6)OMG, that's so cool O.o

can it repeat those steps trough users mind as well? don't know, but is worth 
trying.



this gets back to a technical issue of slc..
do we want to massively introduce its ui before frameworks?

if so, perhaps the kparts patch in kdelibs really needs to go in the 4.8 
branch?

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Containment default setting

[Marco Martin]

On Thursday 21 June 2012, Martin Klapetek wrote:
> On Thu, Jun 21, 2012 at 12:40 PM, Aaron J. Seigo  wrote:
> > On Wednesday, June 20, 2012 23:54:57 Martin Klapetek wrote:
> > > I imagine this could then be used in Dolphin's context menu 'Actions'
> > > and possibly in Gwenview too.
> > 
> > crazy idea: what about using SLC for this? Like -> Use as wallpaper
> > 
> > (not share because you aren't sharing with anyone; not really connecting
> > it to
> > anything; and you use it as a wallpaper because you like it that much :)
> > 
> > downside: it's not particularly discoverable because people are not used
> > to SLC. i think once someone is used to SLC as a concept it will feel
> > very natural .. but before then it will be a mystery.
> > 
> > upside: we would not need to patch each application, and we wouldn't even
> > need
> > to expose a dbus interface (this screams Plasma::Service to me...)
> > 
> > thoughts?
> 
> Speaking as someone "not used to SLC", do I understand it right, that when
> clicking "Like" it will popup a menu letting you select the "Like" action
> you like? That could be an option, but at least on the desktop, without SLC
> settled in, I wouldn't see it as the "number one place" for this action
> (setting picture as a wallpaper). At least not yet ;)
> 
> Thing is - is SLC going to be sort of mandatory on desktop and/or active?
> What if people don't want to use it? In that case, we still need some sort
> of fallback.

chicken and egg problem..
until is not used enough by apps why put it in, until is not in why using it 
in apps...

so should start from somewhere.

as being mandatory..
i think it should be part of the default workspace in the future, if the user 
wants to remove it, he can remove it, but also the systray can be removed, and 
there is no fallback.


maybe using SLC is not the right place, i don't know, my stance on it for now 
is: not intuitive, but awesome once discovered.

but if it is, reimplementing this function elsewhere "in the meantime" is not 
a good way to go, becuase leads to duplication, so not really in the direction 
of elegance we should strive for.
since it won't be possible to remove it from the other places without pain: 
another thing to cosider when adding a feature somewhere, is what will be the 
price ("social" price?) of removing it in the future, or even just moving it 
somewhere else

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Containment default setting

[Marco Martin]

On Thursday 21 June 2012, Luca Beltrame wrote:
> In data giovedì 21 giugno 2012 15:15:48, Aaron J. Seigo ha scritto:
> > it had imports for them, but no components from MobileComponents were
> > actually being used .. so: no :)
> 
> Sorry for being a drag but it seems they are used somewhere. ;)
> 
> slccomponents/MenuItem.qml requires some bits from plasma-mobile
> components, as far as I can tell (but I don't know if those could be
> replaced with "generic" variants).

i also think it will need a slightly different behavior between touch and not 
touch case, this has also to be fixed

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: When should a bug be considered as a regression or a release_blocker?

[Marco Martin]

On Thursday 21 June 2012, Mark wrote:
> >> Both issues are not something that obstruct normal KDE usage, but they
> >> do render some parts of KDE completely useless. I'm a bit unsure if i
> >> should mark such bugs as release blockers.
> > 
> > not when they are this minor, no.
> 
> True and i completely agree with it.
> But this doesn't make it any easier. Marco said (above): "i don't
> think we should make releases with random pieces cutted out, or they
> will never be complete" so we don't cut out pieces that don't work yet
> we also don't want to release pieces that don't work.
> 
> If you follow that reasoning it is... a blocker :p

sometimes we just have to release with known issues or release never.

maybe documenting the worst 10 or so somewhere near the release would be a 
good thing, as many products do:

http://en.opensuse.org/openSUSE:Most_annoying_bugs
http://helpx.adobe.com/photoshop/kb/known-issues-bugs-photoshop-cs5.html

Cheers, 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: When should a bug be considered as a regression or a release_blocker?

[Marco Martin]

On Thursday 21 June 2012, Mark wrote:
> > Nobody said we don't want to release pieces that don't work.  We do
> > release pieces that don't work.  Then those bugs are much more visible
> > and developers (hopefully) have more motivation to fix them. :)
> > 
> > Just my 2c,
> > Jeremy
> 
> Ehhh, that's a very strange reasoning :p That way you could release a
> completely broken KDE SC (like KDE 4.0 was ;p) then developers will
> certainly be motivated to fix it asap. That is bad publicity for KDE
> and a bad KDE image that you should never want to have.

i'm just failing to see connection "a bouncing ball doesn't work with 2 
screens" and "the whole desktop is completely broken"

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PMC discussions to move back to #plasma

[Marco Martin]

On Thursday 21 June 2012, Shantanu Tushar Jha wrote:
> this, #plasma-mediacenter shall *no longer* be used for discussions around
> Plasma Media Center.

i agree with that, it helps to fight non esistent divisions ;)

> Finally, it will be nice if somebody could add
> https://projects.kde.org/projects/playground/multimedia/plasma-mediacenter/
> repositoryto #plasma's CIA bot so it can spit out commits, any takers?

from the configuration of CIA-19 i see this should already be the case

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Akademy2012 BoF for WebAccounts

[Marco Martin]

On Thursday 21 June 2012, Alex Fiestas wrote:
> Taking a look at the schedule, it seems that the best slot is Monday from
> 09:30 to 14:00, we will have a break for lunch between 12:30 and 13:00 (uh
> too small maybe?).
> 
> If you think 4h is too much we can do 2h and if needed schedule another
> BoF.
> 
> Personally I think that only discussing *how* we want the final product to
> look like will take us 2h, so another 2h for technical discussions seems
> logic.
> 
> Feedback? ideas?

good idea,
i think should be tried to be kept on monday (i have some doubt many people 
would show up at 9:30 tough :p)

i am not sure is something will need a lot to discuss per se, is on the 
needing a lot of work side tough ;)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Containment default setting

[Marco Martin]

On Thursday 21 June 2012, Varun Herale wrote:
> > * will the feature work consistently (multiple screens, per-virtual
> > desktop containments, etc..) and not just work for some configurations
> 
> I have written some code <http://pastebin.com/E9NK0Cxu> for this. It hosts
> a dbus-interface from which wallpaper plugins can be loaded. From what I've
> tested it works for per-virtual desktop containments and should also work
> with multiple screens. Please do review, it'll help with my understanding
> of Plasma atleast.
> 
> crazy idea: what about using SLC for this? Like -> Use as wallpaper
> 
> > I am new here and I haven't come across this before. So please bear with
> 
> me. Is the feature currently available or is it being worked on right now ?
> I only find Plasma::Mobile links on searching for it!

the ui and services are in the share-like-connect repository.
it's still in playground because still needs improvements in the ui and 
backend sides.
the api to advertise content to it is in kactivities tough, so available in 
4.9 already.

> From what I understand this will also help applications communicate with
> plasma, am I right ?
> 
> > Yes, but this discussion started exactly because there's a need
> > (justified or not) for a different solution. That's what that "fallback"
> > referred to (again, think the non-drag enabled envs and/or the
> > convenience mention previously).
> > 
> > Yes, but if SLC helps applications communicate with plasma then
> 
> applications can provide their own solution for this problem. Where can I
> find out more about this ?

http://ivan.fomentgroup.org/blog/2011/06/06/contouring-the-share-like-connect/
http://www.notmart.org/index.php/Software/Share,_Like_and_Connect
http://community.kde.org/Plasma/Active/Info/FAQ#Share.2FLike.2FConnect

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Hello... WorkFlow Plasmoid

[Marco Martin]

On Friday 22 June 2012, Michail V. wrote:
> Hello everyone,
> 
> I am developing a plasmoid called Workflow, the project's webpage can be
> found here:
> http://opentoolsandspace.org/en/projects/development/plasmoid-workflow
> 
> I'd love to have your feedback, as I have a deadline in my head for the
> first version
> mid-of September. The pieces are starting to get into place, it's almost
> usable right now
> but until now I have faced the following issues, I am developing it in
> KDE 4.8.4 at opensuse

Hi,
first of all, this is a very cool project, (there may be even some concepts of 
it that may make sense to be implemented in the default workspace)

how is written? c++? qml? a combination of the two?

> 1) I am using the following code to remove an activity:
> 
> void ActivityManager::remove(QString id) {
>  ActivityManager::stop(id);
> 
>  Plasma::Service *service = plasmaActEngine->serviceForSource(id);
>  KConfigGroup op = service->operationDescription("remove");
>  op.writeEntry("Id", id);
>  Plasma::ServiceJob *job = service->startOperationCall(op);
>  connect(job, SIGNAL(finished(KJob*)), service, SLOT(deleteLater()));
> 
> }
> 
> plasmaActEngine is org.kde.activities,
> the behavior is that the activity is not removed from the dataengine,
> there is a ghost activity
> in the dataengine that doesnt have some fields, name, icon etc...
> In order for someone to delete it completely the user must use the
> ActivityManager or make
> a logout/login

i seen this problem in the past.
seems that to be correctly deleted the deletion should happen at least an 
event loop after the stop. (like being done by a slot connected with a timer 
with 0 timeout).

if this is still the case in master is worth investigating why this happens.

> 
> 2) The plasmoid is developed as a PopupApplet in order to be able to be
> placed in a panel,
> I have tried many things but I can not restore the plasmoid in its
> previous used size after a logout/login,
> the popupapplet changes the DialogWidth,DialogHeight properties
> correctly in the plasmoids settings
> but after a logout/login the plasmoid remains in its default size.

is the size correctly saved in plasma-desktop-appletsrc?

in theory shouldn't be necessary to do anything
(may be a problem in the qml binding of popupapplet itself?)

> 3) I have tried to find a way to clone an activity through the plasmoid
> but I did not have any success.
> I have seen that the ActivitiesEngine, in plasma/desktop/shell, is using
> class PlasmaApp for most of the
> operations and not the dataengine, Is there a way to use PlasmaApp also?
> or in the future cloning an activity
> is going to be supported through the dataengine?

there aren't any exposed way, i don't think.
this because the implementation of activities/containment correspondence is in 
the shell executable, so not reachable by the plasma library.

i see several ways in which the containments cloning may be reached from a 
library tough.
what is needed is:
* a client asks the activity manager to duplicate an activity
* the activity manager signals this, the plasma shell duplicates the 
containments
* the activity manager duplicates the associations nepomuk resource/activity 
as well
* kwin duplicates the window association

i think the last two points are not done in any way for now.

this may also sparkle a discussion on what is the optimal workflow to create 
an activity:
* an empty one can be created
* or a duplicate of the current
* or one with all the files and windows currently open, regardless if they are 
associated or not
* or the union of last two points: all open stuff plus all currently 
associated to the current one

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Hello... WorkFlow Plasmoid

[Marco Martin]

On Friday 22 June 2012, Ivan Čukić wrote:
> > i seen this problem in the past.
> > seems that to be correctly deleted the deletion should happen at least an
> > event loop after the stop. (like being done by a slot connected with a
> > timer with 0 timeout).
> > 
> > if this is still the case in master is worth investigating why this
> > happens.
> 
> Ok, as I said in the last mail, (repeating just for the sake of
> records) I'd go for using libkactivities for this, and not the data
> engine.
> 
> IMO, the data engine shouldn't have any service related to the
> management of activities - I don't think that a regular plasmoid has
> to do anything in that area - we have even separated the API in two
> classes for that sole reason - KActivities::Consumer and
> KActivities::Controller. Marco, does this exist because of Active?

yeah, the activity switcher in active is pure qml (not even a plasmoid) so 
needs bindings for that.
there could be a binded qobject instead of passing trough a service, but it 
wouldn't change that much in the end, still the same code path

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma applets inside QML applet

[Marco Martin]

On Saturday 23 June 2012, 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?
 
this is a case where one needs to take a step back and consider exactly what 
is the final needed result whitout assumptions on how to get there "ie applets 
in applets"

putting applets inside other applets instead of directly in  a containment is 
generally not a good idea. the systray plasmoid does this mostly for 
functional requisites, but this is causing quite some problems there as well, 
since the applet base class codebase is designed for having its lifecycle 
managed by a containment instance.

So is not something that is going to be supported in qml, i don't think
(i would like also to think about an alternate way for the systray in plasma2 
that wouldn't have those problems) 

if in the end what you need can be done with a classical containment, but done 
in qml, there are several examples in the plasma-mobile repository.
it's still a bit quirky because in plasma1 applets are qgraphicswidgets and 
this doesn't play extremely well with qml, but it works already.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma applets inside QML applet

[Marco Martin]

On Sunday 24 June 2012, David Edmundson wrote:

> > this is a case where one needs to take a step back and consider exactly
> > what is the final needed result whitout assumptions on how to get there
> > "ie applets in applets"
> > 
> > putting applets inside other applets instead of directly in  a
> > containment is generally not a good idea. the systray plasmoid does this
> > mostly for functional requisites, but this is causing quite some
> > problems there as well, since the applet base class codebase is designed
> > for having its lifecycle managed by a containment instance.
> 
> What about the case of the calendar in the digital clock?

i think the calendar should be a qml component in plasmaextras.
all the machinery typical of the Applet class is not really needed for a 
calendar, but i think there is a case for a reusable calendar.
then the calendar applet would just be an applet that has only that component 
and that's it.

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Rework layout of widget explorer and activity manager in vertical mode

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105329/#review15100
---


in general the patch looks good...
i don't like the stretched buttons tough

- Marco Martin


On June 25, 2012, 8:23 a.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105329/
> ---
> 
> (Updated June 25, 2012, 8:23 a.m.)
> 
> 
> Review request for Plasma, KDE Usability and Marco Martin.
> 
> 
> Description
> ---
> 
> I made a few changes to make widget explorer nicer in vertical mode
> 
> - Fix cropped list items.
> - Make buttons use full width.
> - Move "Get new widgets" and action buttons to the bottom so that:
>   - different label alignments do not look odd (category button vs others)
>   - category button is closer to the list it controls
> 
> Additionally it would be much better if tooltips could appear on the right 
> (or left) of the current list item instead of on top of it because it easily 
> gets in the way, but I don't know how to do this. Any idea? An alternative 
> would be to just drop the tooltip, it currently does more harm than good imo.
> 
> There is also something weird going on with the backgrounds: the "after" 
> screenshots use a opaque background, but that is not part of the patch and I 
> don't understand what makes the code pick the opaque or transparent 
> background. It should be fixed to use the opaque background, again, any idea 
> where that bug could be?
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/main.qml 
> 4beecec 
>   plasma/desktop/shell/activitymanager/package/contents/ui/main.qml 1886529 
> 
> Diff: http://git.reviewboard.kde.org/r/105329/diff/
> 
> 
> Testing
> ---
> 
> - Looks better in vertical mode.
> - No regression in horizontal mode.
> 
> 
> Screenshots
> ---
> 
> before-after
>   http://git.reviewboard.kde.org/r/105329/s/610/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Rework layout of widget explorer and activity manager in vertical mode

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105329/#review15101
---



Screenshot: before-after
<http://git.reviewboard.kde.org//r/105329/#scomment51>
buttons with icons are never centered (already discussed) if they are 
stacked the unaligned icons become too ugly

- Marco Martin


On June 25, 2012, 8:23 a.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105329/
> ---
> 
> (Updated June 25, 2012, 8:23 a.m.)
> 
> 
> Review request for Plasma, KDE Usability and Marco Martin.
> 
> 
> Description
> ---
> 
> I made a few changes to make widget explorer nicer in vertical mode
> 
> - Fix cropped list items.
> - Make buttons use full width.
> - Move "Get new widgets" and action buttons to the bottom so that:
>   - different label alignments do not look odd (category button vs others)
>   - category button is closer to the list it controls
> 
> Additionally it would be much better if tooltips could appear on the right 
> (or left) of the current list item instead of on top of it because it easily 
> gets in the way, but I don't know how to do this. Any idea? An alternative 
> would be to just drop the tooltip, it currently does more harm than good imo.
> 
> There is also something weird going on with the backgrounds: the "after" 
> screenshots use a opaque background, but that is not part of the patch and I 
> don't understand what makes the code pick the opaque or transparent 
> background. It should be fixed to use the opaque background, again, any idea 
> where that bug could be?
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/main.qml 
> 4beecec 
>   plasma/desktop/shell/activitymanager/package/contents/ui/main.qml 1886529 
> 
> Diff: http://git.reviewboard.kde.org/r/105329/diff/
> 
> 
> Testing
> ---
> 
> - Looks better in vertical mode.
> - No regression in horizontal mode.
> 
> 
> Screenshots
> ---
> 
> before-after
>   http://git.reviewboard.kde.org/r/105329/s/610/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma applets inside QML applet

[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

Re: Review Request: Rework layout of widget explorer and activity manager in vertical mode

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105329/#review15115
---

Ship it!


anyways i think is already a significative improvement, go for it

- Marco Martin


On June 25, 2012, 12:15 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105329/
> ---
> 
> (Updated June 25, 2012, 12:15 p.m.)
> 
> 
> Review request for Plasma, KDE Usability and Marco Martin.
> 
> 
> Description
> ---
> 
> I made a few changes to make widget explorer nicer in vertical mode
> 
> - Fix cropped list items.
> - Make buttons use full width.
> - Move "Get new widgets" and action buttons to the bottom so that:
>   - different label alignments do not look odd (category button vs others)
>   - category button is closer to the list it controls
> 
> Additionally it would be much better if tooltips could appear on the right 
> (or left) of the current list item instead of on top of it because it easily 
> gets in the way, but I don't know how to do this. Any idea? An alternative 
> would be to just drop the tooltip, it currently does more harm than good imo.
> 
> There is also something weird going on with the backgrounds: the "after" 
> screenshots use a opaque background, but that is not part of the patch and I 
> don't understand what makes the code pick the opaque or transparent 
> background. It should be fixed to use the opaque background, again, any idea 
> where that bug could be?
> 
> 
> Diffs
> -
> 
>   
> libs/plasmagenericshell/widgetsexplorer/package/contents/ui/AppletDelegate.qml
>  68fad80 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/main.qml 
> 4beecec 
>   plasma/desktop/shell/activitymanager/package/contents/ui/main.qml 1886529 
> 
> Diff: http://git.reviewboard.kde.org/r/105329/diff/
> 
> 
> Testing
> ---
> 
> - Looks better in vertical mode.
> - No regression in horizontal mode.
> 
> 
> Screenshots
> ---
> 
> before-after
>   http://git.reviewboard.kde.org/r/105329/s/611/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma applets inside QML applet

[Marco Martin]

On Monday 25 June 2012, Dmitry wrote:
> > ___
> > 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.
> 

would be interesting an eventual future integration in the default plasmoids, 
since the plasma systemtray will have to be rewritten in qml as well

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Windows previews in qml plasmoid?

[Marco Martin]

On Thursday 28 June 2012, Aaron J. Seigo wrote:
> On Thursday, June 28, 2012 08:56:21 Michail V. wrote:
> > Is there a way to have windows previews in a qml plasmoid?
> 
> the ToolTip QML item (which isn't documented on api.kde.org with the other
> QML elements since it is written in C++ *sigh*) does not expose the
> requisite property in Plasma::ToolTipContent: windowsToPreview.

those c++ elements do have api docs, what's necessary to make it indexed?

> there are two ways to address this:
> 
> * add this functionality to the existing ToolTip element in kde-
> runtime/plasma/declarativeimports/core/tooltip.cpp
> 
> * include a bit of C++ with the QML task manager applet which exposes this

i'm for the second, i'm not tooo happy about exposing thumbnails in the import


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Change the text of the "Category" button when a category is selected

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105412/#review15314
---

Ship it!


- Marco Martin


On July 2, 2012, 2:21 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105412/
> ---
> 
> (Updated July 2, 2012, 2:21 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Set the text of the "Category" button when a category is selected, so that 
> the user knows which category the content is filtered on.
> 
> Also fixes the position of the category menu in horizontal mode.
> 
> 
> This addresses bug 301459.
> http://bugs.kde.org/show_bug.cgi?id=301459
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/main.qml 
> 3a3b7d2 
> 
> Diff: http://git.reviewboard.kde.org/r/105412/diff/
> 
> 
> Testing
> ---
> 
> Tested in horizontal and vertical mode.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: How to access calendar using javascript?

[Marco Martin]

On Mon, Jul 2, 2012 at 4:24 AM, gaoxiang  wrote:
> On Thursday 28 June 2012 15:46:09 qasdfgtyuiop wrote:
>> I want to let my widget add some events to the calendar.  But I can
>> not find the api doc, where can I find them?
>> I have read these tutorials/documentations but I find nothing helpful:
>>
>> http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API-DataEngi
>> nesServices
>> http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API
>

for the graphical part, davide is doing a gsoc to do a calendar
component in qml, hopefully reusable

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Offset from Plasma Theme?

[Marco Martin]

On Mon, Jul 2, 2012 at 6:01 PM, Michail Vourlakos  wrote:
> actually it works as you can see in the second video but in order to find
> proper x,y for each
> window thumbnail I need:
> 1. x,y of the plasmoid,
> 2. offset of Plasma Theme decoration
> 3. x,y inside the main QML Element
> -so the real x,y is 1+2+3,
> 1. I can find it through the plasmoid geometry,
> 2. I am searching to find, (???)
> 3. I know it of course from inside QML.
>
> Plasma::WindowEffects::showWindowThumbnails needs as first parameter a WId.
> A plasmoid
> I think does not have a WId, instead desktops WId or Dashboard WId is used I
> think through:
>
> view()->winId();

this is correct, is the most reliable (even tough never 100%) way to
get the actual window that is the qgraphicsview.
in cases of popups may be that the view is child of another widget, so
try with view()->effectiveWinId()

then, while you can't really know the width of the plasmoid borders
you don't need it here, you need only to know the borders of the
thumbnails borders, that is whatever svg you used. in FrameSvg you use
getMargins/marginsSize

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix position of widget explorer tooltip

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105447/#review15421
---

Ship it!


yes, i think right now is the least painful way to have it right.

the code is ok.
 what we have to remember is for plasma2 we may want to not have to do that 
again, so api in libplasma may heve to be retought.

but +1 for doing this way for now

- Marco Martin


On July 5, 2012, 9:05 a.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105447/
> ---
> 
> (Updated July 5, 2012, 9:05 a.m.)
> 
> 
> Review request for Plasma, KDE Usability and Marco Martin.
> 
> 
> Description
> ---
> 
> When the widget explorer is oriented vertically, applet tooltips shows on top 
> of other applets instead of showing on the right or on the left. This patch 
> fixes it in a not-too intrusive way (original patch affected kdelibs and 
> kde-runtime as well). If possible I would like this patch to be applied to 
> the KDE/4.9 branch as well.
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/main.qml 
> cc84e6c 
>   libs/plasmagenericshell/widgetsexplorer/widgetexplorer.h 31308d2 
>   libs/plasmagenericshell/widgetsexplorer/widgetexplorer.cpp 9b19f88 
> 
> Diff: http://git.reviewboard.kde.org/r/105447/diff/
> 
> 
> Testing
> ---
> 
> Tested with panels on all edges.
> 
> 
> Screenshots
> ---
> 
> before-after
>   http://git.reviewboard.kde.org/r/105447/s/616/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Please, if you port something to QML, make it at the very least exactly the same as the C++ version!

[Marco Martin]

On Monday 09 July 2012, Mark wrote:
> Hi folks,
> 
> I really have to stress this out. It annoys me to even see it since it
> seems so obvious (to me).
> When you port some GUI part of KDE from C++ to QML i would expect the
> porter to keep:
> - feature parity
> - visual parity
> - functional parity
> 
> So, i just installed KDE 4.9 RC 1 with high hopes of QML in some
> places thus i happily started testing that. That's when i got some
> "WTF" "No, you got to be joking!" moments.

may be better? yes.
however this is not the right attitude at all to tackle it, it's not helping 
anyone.

> The first thing i tested out was the shutdown dialog which is in QML
> now. While it may have feature parity, it certainly lacks visual
> parity and probably some functional parity as well. The first thing i
> noticed was missing drop down shadows in corners. I leave the rest up
> to the bug reports i made for it:
> https://bugs.kde.org/show_bug.cgi?id=303216
just reproduces the old behavior

> https://bugs.kde.org/show_bug.cgi?id=303215
weird drivers issue, not really reproducible

> https://bugs.kde.org/show_bug.cgi?id=303214
fixed

> https://bugs.kde.org/show_bug.cgi?id=303213
old problem in the theme, not a regression, fixed now.

> 
> Lets make KDE 4.9 rock solid!
> 

indeed

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: master pushed to KDE/4.9

[Marco Martin]

On Monday 09 July 2012, Viranch Mehta wrote:
> Hi,
> 
> While I was trying to push my commit to KDE/4.9 after pushing to master,
> I landed pushing all of master to KDE/4.9 branch. I was asked to give a
> request for reverting this to the project's git maintainers.
> 
> So can someone please look into this? My apologies for the inconvenience.
> 
> Cheers,
> Viranch
is it kde-workspace? did you do a merge of master into 4.9?

seems there is a merge at 6e34d9b604240bda7d6ebdc46ff12470c8f17b9f

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

porting stuff to Nepomuk2

[Marco Martin]

Yo all,
I tried to port some stuff to Nepomuk2, namely kactivities and plasma-mobile

porting kactivities went smooth, and is now in the branch mart/nepomuk2 of the 
kactivities repository.
the only thing still to fix is that is exposing a Nepomuk::Resource in a 
method, so it will have to provide both that and a new one with a 
Nepomuk2::Resource

for plasma-mobile (mart/nepomuk2 branch on the plasma-mobile git repo) is a 
bit more tricky:
it needs nepomuk_add_ontology_classes that is still generating code with 
Nepomuk:: namespace.
this will be a problem for a lot of code to port i guess

I did a mart/rcgenNepomuk2 branch on the nepomuk-core repo.
this builds that copy of rcgen with the name nepomuk2-rcgen and generates code 
with Nepomuk2:: namespace (a bit of generated code is disabled because it was 
using old functions from ResourceManager that are removed and were very slow)

i tought at start to make the namespace command line dependent but the result 
vas an ugly bunch of spaghetti and the kdelibs copy would have to be modified 
(not good)

it also needs an updated cmake file NepomukAddOntologyClasses (attached), 
which adds the NEPOMUK2 option and in that case uses nepomuk2-rcgen. all 
should be retrocompatible,

Vishes: what's the best way to proceed now?

Cheers,
Marco Martin
#
# Use the Nepomuk resource class generator to generate convinient Resource subclasses
# from ontologies.
#
# Usage:
#   NEPOMUK_ADD_ONTOLOGY_CLASSES(
# [FAST]
# [ONTOLOGIES]  [ ...]
# [CLASSES  [ ...]]
# [VISIBILITY ]
#   )
#
# If FAST is specified the rcgen parameter --fast will be used which results in resource classes
# not based on Nepomuk::Resource but on a custom class which does not perform any checks and simply
# writes the data to Nepomuk (hence the name fast).
#
# The optional CLASSES parameter allows to specify the classes to be generated (RDF URIs) in
# case one does not want all classes in the ontologies to be generated.
#
# The optional VISIBILITY parameter can only be used in non-fast mode and allows to set the gcc visibility
# to make the generated classes usable in a publically exported API. The  is used to create
# the name of the export macro and the export include file. Thus, when using "VISIBILITY foobar" include
# file "foobar_export.h" needs to define FOOBAR_EXPORT.
#
# Copyright (c) 2009 Sebastian Trueg 
#
# Redistribution and use is allowed according to the terms of the BSD license.
# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
#
macro(NEPOMUK_ADD_ONTOLOGY_CLASSES _sources)
  # extract arguments
  set(_current_arg_type "onto")
  foreach(_arg ${ARGN})
if(${_arg} STREQUAL "ONTOLOGIES")
  set(_current_arg_type "onto")
elseif(${_arg} STREQUAL "VISIBILITY")
  set(_current_arg_type "visib")
elseif(${_arg} STREQUAL "CLASSES")
  set(_current_arg_type "class")
elseif(${_arg} STREQUAL "FAST")
  set(_fastmode "--fast")
elseif(${_arg} STREQUAL "NEPOMUK2")
  set(_nepomuk2 TRUE)
else(${_arg} STREQUAL "ONTOLOGIES")
  if(${_current_arg_type} STREQUAL "onto")
list(APPEND _ontologies ${_arg})
get_filename_component(_filename ${_arg} NAME)
list(APPEND _ontofilenames ${_filename})
  elseif(${_current_arg_type} STREQUAL "class")
list(APPEND _classes "--class" "${_arg}")
  else(${_current_arg_type} STREQUAL "onto")
set(_visibility "--visibility" "${_arg}")
  endif(${_current_arg_type} STREQUAL "onto")
endif(${_arg} STREQUAL "ONTOLOGIES")
  endforeach(_arg)

  # find our helper program (first in the install dir, then everywhere)
  if (_nepomuk2)
if(NOT WINCE)
find_program(RCGEN nepomuk2-rcgen PATHS ${KDE4_BIN_INSTALL_DIR} ${BIN_INSTALL_DIR} NO_DEFAULT_PATH)
find_program(RCGEN nepomuk2-rcgen)
else(NOT WINCE)
find_program(RCGEN nepomuk2-rcgen PATHS ${HOST_BINDIR} NO_DEFAULT_PATH)
endif(NOT WINCE)
  else(_nepomuk2)
if(NOT WINCE)
find_program(RCGEN nepomuk-rcgen PATHS ${KDE4_BIN_INSTALL_DIR} ${BIN_INSTALL_DIR} NO_DEFAULT_PATH)
find_program(RCGEN nepomuk-rcgen)
else(NOT WINCE)
find_program(RCGEN nepomuk-rcgen PATHS ${HOST_BINDIR} NO_DEFAULT_PATH)
endif(NOT WINCE)
  endif(_nepomuk2)

  if(NOT RCGEN)
message(SEND_ERROR "Failed to find the Nepomuk source generator" )
  else(NOT RCGEN)
file(TO_NATIVE_PATH ${RCGEN} RCGEN)

# we generate the files in the current binary dir
set(_targetdir ${CMAKE_CURRENT_BINARY_DIR})

# generate the list of source and header files
execute_process(
  COMMAND ${RCGEN} ${_fastmode} --listheaders --prefix ${_targetdir}/ ${_classes} ${_visibility} ${_ontologies}
  OUTPUT_VARIABLE _out_headers
  RESULT_VA

Re: [Nepomuk] porting stuff to Nepomuk2

[Marco Martin]

On Wednesday 11 July 2012, Vishesh Handa wrote:
> On Tue, Jul 10, 2012 at 3:25 PM, Marco Martin  wrote:
> > Yo all,
> > I tried to port some stuff to Nepomuk2, namely kactivities and
> > plasma-mobile
> > 
> > porting kactivities went smooth, and is now in the branch mart/nepomuk2
> > of the
> > kactivities repository.
> > the only thing still to fix is that is exposing a Nepomuk::Resource in a
> > method, so it will have to provide both that and a new one with a
> > Nepomuk2::Resource
> 
> Why both? Can't everyone just use Nepomuk2::Resource?

is released with kde 4.9 and is a public library -> binary compatibility 
promise

(Ivan: correct me if i am wrong, that should be the only nepomuk symbol 
exported there?)

> > 
> > Vishesh: what's the best way to proceed now?
> 
> I think for now it would make sense to push your
> NepomukAddOntologyClasses.cmake in that branch, and then we can merge it
> into master. I don't want this going into 4.9 cause there are some problems
> with the current rcgen which I would like to fix at some point.

problem is that it is in kdelibs so there is no master.
it may be added to nepomuk-core, but in this case since kdelibs still has to 
have the old one it would be called Nepomuk2AddOntologyClasses
and use only nepomuk2_rcgen

I'm not sure what is the policy of cmake files, if they should be scattered 
together their framework or if they are still wanted in a single repo

> Btw, I don't really understand the NepomukAddOntologyClasses.cmake, so I
> hope it works :)

seems to work for both nepomuk1 and 2 cases, the issue is more where tp put 
the thing ;)

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Nepomuk] porting stuff to Nepomuk2

[Marco Martin]

On Wednesday 11 July 2012, Vishesh Handa wrote:
> > 
> > I'm not sure what is the policy of cmake files, if they should be
> > scattered together their framework or if they are still wanted in a
> > single repo
> 
> I think then in makes sense to have a Nepomuk2AddOntologyClasses which only
> uses nepomuk2_rcgen. Cause I don't think the packagers would like us having
> 2 pacakges (nepomuk-core and kdelibs) install the same cmake file.

i added it now in the nepomuk-core repo, same mart/rcgenNepomuk2 branch

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: add little margin to tooltip position

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105520/#review15718
---

Ship it!


the code of the "real" tooltips is completely different, is not done by the 
Dialog class.

now, try to update kdelibs and kde-workspace, i attempted to solve the problem 
in a slightly different way.
if a Dialog has Qt.toolTip among the window flags it shouldn't cut the borders 
anymore.
if bad countereffects will be encountered we can still fall back to this way

- Marco Martin


On July 12, 2012, 2:55 a.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105520/
> ---
> 
> (Updated July 12, 2012, 2:55 a.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> In current widget explorer, the tooltip for leftmost item is clipped, 
> this makes the appearance of tooltip and text inside it not properly 
> displayed.
> 
> The margin value is hardcoded, i like to have the same margin as the tooltip 
> of kickoff plasmoid when placed at leftmost of the screen.
> But not sure which file should i read to get kickoff tooltip value.
> 
> I will commit this to KDE/4.9 and master if accepted.
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/widgetexplorer.cpp 2651371 
> 
> Diff: http://git.reviewboard.kde.org/r/105520/diff/
> 
> 
> Testing
> ---
> 
> tested againts master.
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Nepomuk] porting stuff to Nepomuk2

[Marco Martin]

On Wednesday 11 July 2012, Vishesh Handa wrote:
> > > uses nepomuk2_rcgen. Cause I don't think the packagers would like us
> > 
> > having
> > 
> > > 2 pacakges (nepomuk-core and kdelibs) install the same cmake file.
> > 
> > i added it now in the nepomuk-core repo, same mart/rcgenNepomuk2 branch
> 
> great.
> 
> If you could just test it out a bit more, then we can merge it into master.
> 

i ported the share-like-connect repo to nepomuk2 as well, so far so good (even 
tough will need setsymbols again)

now only takes some volunteer porting something else that was using 
NepomukAddOntologyClasses to be really safe :p

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: fixed calendar plasmoid configuration not saved

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105569/#review15840
---

Ship it!


good catch.

i think thatthe redundant call is fine tough

- Marco Martin


On July 14, 2012, 11:49 a.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105569/
> ---
> 
> (Updated July 14, 2012, 11:49 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This patch tries to fix bug which caused calendar configuration is not saved.
> as mention in this bug: https://bugs.kde.org/show_bug.cgi?id=302958
> 
> Inside this function
> void Calendar::applyConfiguration(KConfigGroup cg)
> {
> const bool details = isDisplayingDateDetails();
> calendarTable()->applyConfiguration(cg);
> if (details != isDisplayingDateDetails()) {
> d->updatePreferredSize();
> }
> }
> 
> Should i remove calendarTable()->applyConfiguration(cg); too?
> Seems it redundant with calendarTable()->configAccepted(cg);
> 
> 
> This addresses bug 302958.
> http://bugs.kde.org/show_bug.cgi?id=302958
> 
> 
> Diffs
> -
> 
>   libs/plasmaclock/calendar.cpp e2b3b41 
> 
> Diff: http://git.reviewboard.kde.org/r/105569/diff/
> 
> 
> Testing
> ---
> 
> against master
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: added mouse middle button support to scrollbar qml

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105576/#review16007
---

Ship it!


the last version is fine for both master and 4.9

- Marco Martin


On July 17, 2012, 11:01 a.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105576/
> ---
> 
> (Updated July 17, 2012, 11:01 a.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> trying to fix https://bugs.kde.org/show_bug.cgi?id=272934
> by adding mouse middle button click support to scrollbar qml.
> 
> if accepted i will push to KDE/4.9 too.
> 
> 
> This addresses bug 272934.
> http://bugs.kde.org/show_bug.cgi?id=272934
> 
> 
> Diffs
> -
> 
>   
> plasma/declarativeimports/plasmacomponents/qml/private/ScrollBarDelegate.qml 
> 02a869e 
> 
> Diff: http://git.reviewboard.kde.org/r/105576/diff/
> 
> 
> Testing
> ---
> 
> tested against widget explorer in master
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Complex configuration dialog for pure QML applet

[Marco Martin]

On Tuesday 17 July 2012, Dmitry wrote:
> 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!

unfortunately is not possible.

kconfigxt is quite limited, what would be needed is qml files used for the 
config ui.
this has never been done because to make sense it would need to be styled like 
qwidgets, but we don't have desktop components at the moment (luckily are in 
development, but unlikely before qt5)

so no, at the moment the only way really is doing a c++ applet that uses qml 
just for ui.

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


Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Complex configuration dialog for pure QML applet

[Marco Martin]

On Tuesday 17 July 2012, Dmitry wrote:
> 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!

yep, sure :)

the thing that has to be weighed in more toroughly when done is the plasmoid 
writing its own plugin
(something that ends up like import org.whatever.myplasmoidstuff 0.1 as 
MyPlasmoid)
because that will become public api for everyone else to use, so i usually 
prefer if there are c++ pieces needed that aren't on the system imports to end 
up in a c++ plasmoid instead.

otherwise it would have to get in kde-runtime with a bit more strict 
requirements of api quality longer review period etc ;)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: kickoff-qml: TabBar button width

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105405/#review16103
---


thanks, wouldn;t have remembered ;)

the changes seems good, but i'm not sure about giving kickoff a copy of the 
tabbar.

any reason this is not proposed as a patch for the tabbar component itself?

- Marco Martin


On July 1, 2012, 8:42 p.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105405/
> ---
> 
> (Updated July 1, 2012, 8:42 p.m.)
> 
> 
> Review request for Plasma, Marco Martin and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> Heda,
> This patch addresses the layout of the tab bar. The tab buttons are now sized 
> depending of their text width.
> 
> I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. 
> My main question is: Can I do this more elegantly without copying TabBar.qml?
> 
> 
> Diffs
> -
> 
>   plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 
> 
> Diff: http://git.reviewboard.kde.org/r/105405/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg T
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: kickoff-qml: TabBar button width

[Marco Martin]

> On July 19, 2012, 9:04 a.m., Marco Martin wrote:
> > thanks, wouldn;t have remembered ;)
> > 
> > the changes seems good, but i'm not sure about giving kickoff a copy of the 
> > tabbar.
> > 
> > any reason this is not proposed as a patch for the tabbar component itself?
> 
> Greg T wrote:
> Of course I could do that. But I didn't know if such a general change 
> would be welcome. Maybe people love equally sized blocks?

i really think we shouldn't start to customize the components in a single 
applet like that.

what could be done is:
as implicit width of the tabbar should be a width such that all tabs have the 
same width that is the one of the largest tab, so by default it would attempt 
to never elide (probably some work in the bindings is needed to export this as 
preferred width of the applet).

if it's forced to be smaller it starts to elide the text.


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105405/#review16103
---


On July 1, 2012, 8:42 p.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105405/
> ---
> 
> (Updated July 1, 2012, 8:42 p.m.)
> 
> 
> Review request for Plasma, Marco Martin and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> Heda,
> This patch addresses the layout of the tab bar. The tab buttons are now sized 
> depending of their text width.
> 
> I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. 
> My main question is: Can I do this more elegantly without copying TabBar.qml?
> 
> 
> Diffs
> -
> 
>   plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 
> 
> Diff: http://git.reviewboard.kde.org/r/105405/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg T
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

some work and api design on plasma2

[Marco Martin]

Hi all,

as you know the hardest thing, by far in plasma2 is splitting anything related 
to qgraphics* out of libplasma.
that basically means graphics-less Applet, Containment and Corona, and this 
will have to happen in time for frameworks5, regardless having a qml2 version 
ready or not (i would go as far as  putting that as completely secondary and 
eventually releasing it only in a second time)
the quantity of work still to be done is huge, and the time not much.

i have now a branch in kdelibs: plasma/mart/simpleapplet

it's a branch of frameworks and had the following work:

corona, containment and applet are for now disabled from build (libplsmaqgv 
that's the legacy qgraphics* library doesn't build atm)
there are AbsrtactApplet and AbstractContainment: they are still not finished, 
but are intended to be qobject-only versions, with only the logic. all the 
other parts in libplasma that were depending from applet or containment are 
now using abstractapplet or abstractcontainment.


problem: the old qgv based Applet and Containment should inherit from 
AbstractApplet and AbstractContainment, but this means abstract* cannot be 
QObjects, but they need some signals and slots (besides needing to be able to 
be loaded as plugins: required to be qobject?)

so basically there are 2 options:
a) abstractapplet/containment are not qobjects (exposing a qobject member for 
needed signals/slots? kinda ugly)

b) make them qobjects and make Applet/Containment not a subclass but having 
abstractapplet as a member property, so that would become a sort of a "model" 
(kinda ugly as well)

in both cases it may be needed and a completely separated implementation of 
Corona (that in turn poses the same problem, at the moment it has a partial 
separation to a CoronaBase class that is following the model b) approach, but 
can be changed)


comments? suggestions? volunteers for the work? :p

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some work and api design on plasma2

[Marco Martin]

On Thursday 19 July 2012, Aleix Pol wrote:
> On Thu, Jul 19, 2012 at 7:27 PM, Marco Martin  wrote:
> > Hi all,
> > 
> > as you know the hardest thing, by far in plasma2 is splitting anything
> > related to qgraphics* out of libplasma.
> > that basically means graphics-less Applet, Containment and Corona, and
> > this will have to happen in time for frameworks5, regardless having a
> > qml2 version ready or not (i would go as far as  putting that as
> > completely secondary and eventually releasing it only in a second time)
> > the quantity of work still to be done is huge, and the time not much.
> > 
> > i have now a branch in kdelibs: plasma/mart/simpleapplet
> > 
> > it's a branch of frameworks and had the following work:
> > 
> > corona, containment and applet are for now disabled from build
> > (libplsmaqgv that's the legacy qgraphics* library doesn't build atm)
> > there are AbsrtactApplet and AbstractContainment: they are still not
> > finished, but are intended to be qobject-only versions, with only the
> > logic. all the other parts in libplasma that were depending from applet
> > or containment are now using abstractapplet or abstractcontainment.
> > 
> > 
> > problem: the old qgv based Applet and Containment should inherit from
> > AbstractApplet and AbstractContainment, but this means abstract* cannot
> > be QObjects, but they need some signals and slots (besides needing to be
> > able to be loaded as plugins: required to be qobject?)
> > 
> > so basically there are 2 options:
> > a) abstractapplet/containment are not qobjects (exposing a qobject member
> > for needed signals/slots? kinda ugly)
> > 
> > b) make them qobjects and make Applet/Containment not a subclass but
> > having abstractapplet as a member property, so that would become a sort
> > of a "model" (kinda ugly as well)
> > 
> > in both cases it may be needed and a completely separated implementation
> > of Corona (that in turn poses the same problem, at the moment it has a
> > partial separation to a CoronaBase class that is following the model b)
> > approach, but can be changed)
> > 
> > 
> > comments? suggestions? volunteers for the work? :p
> > 
> > Cheers,
> > Marco Martin
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> 
> Do we really need to have this for KF 5.0? It should keep working with
> Qt5, so rushing could be a problem...

well, right now what's in frameworks is a quite in between status that is not 
really working, so has to be brought in a state working without too many 
regressions.

but the most important thing is that kf5 is kinda the last chance for big 
incompatime changes, at least for a long while.

> On the other hand, I agree that it's something we want to have stable ASAP.
> 
> It would be good if someone could step forward and organize a little
> bit how this refactoring should happen and what would be the scope of

i think basically having two libraries, a libplasma and libplasmaqgv, with 
libplasma not depending from qgraphicsview.

an application linking to libplasmaqgv should maintain at least a good extent 
of source compatibility with current shells/applets.

that opens the possibility of having a libplasmaqml2 in the future, even tough 
on which i don't really want to think about yet ;)

for this basically is quite trivial for most classes, except the usual 
corona/containment/applet.

now i don't know how far from working is my branch, but i guess a quite scary 
amount of hours is still needed (and in which may not be trivial working in 
more than one person on it ;)

> the port. I might be able to dedicate some time on this, but I must
> make sure it's not a time drainer.

eh, that's quite a possibility :/


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some work and api design on plasma2

[Marco Martin]

On Thursday 19 July 2012, Martin Gräßlin wrote:
> On Thursday 19 July 2012 20:35:51 Marco Martin wrote:
> > but the most important thing is that kf5 is kinda the last chance for big
> > incompatime changes, at least for a long while.
> 
> do we need a libplasma in KF 5.0? Would it be a huge issue to say libplasma
> is split out of frameworks but not released as part of 5.0, but will enter
> in 5.1 or 5.2. Or having a split-out libplasma API compatible might be a
> quite nice thing in fact for 3rd-party applications using Plasma and don't
> want to do heavy porting. Remember KF 5 should be easy to port to, right
> ;-)

personally, would not be a problem and would give quite some room to breathe 
;)

anybody can think about technical problems about it that may be lurking?
it may mean a release of the workspace that doesn't use completely frameworks, 
so both old kdelibs and the frameworks will have to be distributed for some 
time, may this be a problem? (but not avoidable probably)


Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some work and api design on plasma2

[Marco Martin]

On Friday 20 July 2012, Alex Fiestas wrote:
> On Thursday 19 July 2012 21:18:50 Marco Martin wrote:
> > anybody can think about technical problems about it that may be lurking?
> > it may mean a release of the workspace that doesn't use completely
> > frameworks, so both old kdelibs and the frameworks will have to be
> > distributed for some time, may this be a problem? (but not avoidable
> > probably)
> 
> Uh... please don't eat me :)
> 
> Do we really want to support qgv? it is a super big chunk of code we will
> have to maintain for, waht gain?
> 

keep in mind the instant the qgv part is dropped 100% of the shells, all 
plasmoids, all bindings and a good chunk of 3rd party plasmoids needs to be 
ported (and i would be surprised if the qml1 plasmoids would work in a qml2 
version without being touched)
so dropping the qgv part even if really applealing from the developer pov (it 
would solve quite some problems) is not feasible, because it really means 
another 4.0 :/

it will probably take years, in which probably a qml2 shell will coexist 
without being released for the use by developers

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: System tray: project

[Marco Martin]

On Friday 20 July 2012, Dmitry wrote:
> 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.

Hi Dmitry,
If you want to integrate your systray in kde-workspace to eventually replace 
the default one would be great :)

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

in that branch an applet with the same name and plugin name would be here in 
place of the old systray.

technically i think it should derive from the current c++ systray even tough 
there is a lot of code to throw away.

basically the parts that are really needed is the plasmoid inclusion code and 
the old x11 protocol (a qml only systray that supports only statusnotifieritem 
can be found in plasma-mobile as an example)

i think that it should have a kind of model that presents and sorts an entry 
for each icon, of all supported protocols, then the qml implementation would 
either take a qgraphicsitem provided by the model (for plasmoid and x11 case) 
or create an icon by itself (statusnotifieritem case)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: some work and api design on plasma2

[Marco Martin]

On Friday 20 July 2012, Aleix Pol wrote:
> > keep in mind the instant the qgv part is dropped 100% of the shells, all
> > plasmoids, all bindings and a good chunk of 3rd party plasmoids needs to
> > be ported (and i would be surprised if the qml1 plasmoids would work in
> > a qml2 version without being touched)
> > so dropping the qgv part even if really applealing from the developer pov
> > (it would solve quite some problems) is not feasible, because it really
> > means another 4.0 :/
> > 
> > it will probably take years, in which probably a qml2 shell will coexist
> > without being released for the use by developers
> > 
> 
> Well, can we even mix qtquick 1 and qtquick 2?
> 

on the c++ side no, they are 2 forked and different code bases in the qt5 
sources.

on the qml language side, i know the differences should be minimal but i think 
there is some detail that has changed in the language/base api

so i don't know how much effort will be to make current qml plasmoids run 
unchanged in qml2, but for a while should be possible to have a plasmoid that 
runs on both, even if will mean for a while conditional  inclusion of files 
with the mechanism for the device specific stuff

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Clean up rtm headers and move private data from Auth and Request classes into private classes.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105734/#review16463
---

Ship it!


nice refactor, +1 for me


libs/rtm/auth.cpp
<http://git.reviewboard.kde.org/r/105734/#comment12851>

unneeded whitespace lines


- Marco Martin


On July 26, 2012, 4:55 a.m., Jeremy Paul Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105734/
> ---
> 
> (Updated July 26, 2012, 4:55 a.m.)
> 
> 
> Review request for Plasma and Andrew Stromme.
> 
> 
> Description
> ---
> 
> rtm: Move Request private data into RequestPrivate class in .cpp file. rtm: 
> Move Auth private data into AuthPrivate class in .cpp file. rtm: Clean up 
> auth.h and request.h files.
> 
> 
> rtm: Clean up rtm header files.
> 
> 
> Add #include  since we use Task * (and session.h has been cleaned 
> up).
> 
> 
> Diffs
> -
> 
>   dataengines/rememberthemilk/taskservice.cpp 
> d738093ffd7c5183cf24f9f932d0c7f934b6634b 
>   libs/rtm/auth.h 5f693fa53fc273e2a3782ac57e8c1ca3f8b194a1 
>   libs/rtm/auth.cpp 16fd5f0c28004dcc12140556e8d6727c483c2ed9 
>   libs/rtm/note.h af4cfd20c6ddaf1a4943f76f148c79918b5ec633 
>   libs/rtm/request.h d371714c144bf9bc6c7304a861840334f0846cdb 
>   libs/rtm/request.cpp 1304cb5d1a547d08b7f82e44cd319097991c8425 
>   libs/rtm/rtm.h 1a542f6007c63df13b79dd60da0cfcfe294f8e16 
>   libs/rtm/session.h aad145c44c70fb28fe1496b93d991667e918f630 
>   libs/rtm/xmlreaders.h b9ea78ca567e32aceb70361a2735b7b005d15777 
> 
> Diff: http://git.reviewboard.kde.org/r/105734/diff/
> 
> 
> Testing
> ---
> 
> It builds and runs ok here (the rtm applet logs in and loads data ok).
> 
> 
> Thanks,
> 
> Jeremy Paul Whiting
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix misplaced panel (especially when more than one monitor is involved)

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105596/#review16464
---


setGeometry(geom) should really, really have no effect.

it's probably masking some deeper level bug.

if it's reliable as workaround, so be it.

- Marco Martin


On July 16, 2012, 4:34 p.m., Rolf Eike Beer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105596/
> ---
> 
> (Updated July 16, 2012, 4:34 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This fixes the misplaced panel I and several others see since a while.
> 
> This fix was provided by Kai Dombrowe in bugzilla.
> 
> 
> This addresses bug 283974.
> http://bugs.kde.org/show_bug.cgi?id=283974
> 
> 
> Diffs
> -
> 
>   plasma/desktop/shell/panelview.cpp 50826a8 
> 
> Diff: http://git.reviewboard.kde.org/r/105596/diff/
> 
> 
> Testing
> ---
> 
> Rebuild with that change, panel was placed properly after login. Using plain 
> package immediately showed the problem again.
> 
> 
> Thanks,
> 
> Rolf Eike Beer
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add comment to blackboard applet

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105704/#review16465
---


the patch doesn't apply cleanly, so is probably to be redone (desktop file 
changed by scripty in the meantime)

however, i'm fine to add a comment in the blackboard applet in the master 
branch.

- Marco Martin


On July 24, 2012, 4:16 p.m., Maarten De Meyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105704/
> ---
> 
> (Updated July 24, 2012, 4:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> Add a comment (description) to the blackboard applet.
> Feedback welcome.
> 
> I do not have commit access. This introduces a new string.
> 
> 
> This addresses bug 302636.
> http://bugs.kde.org/show_bug.cgi?id=302636
> 
> 
> Diffs
> -
> 
>   applets/blackboard/plasma-applet-blackboard.desktop 298316e 
> 
> Diff: http://git.reviewboard.kde.org/r/105704/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Maarten De Meyer
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Plasmapkg: Add KWin/Decoration support to Plasmapkg

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105677/#review16466
---

Ship it!


Ship It!

- Marco Martin


On July 23, 2012, 2:47 p.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105677/
> ---
> 
> (Updated July 23, 2012, 2:47 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> Hello,
> 
> This patch is adding support for "plasmapkg -t kwindecoration"
> 
> 
> Diffs
> -
> 
>   plasma/tools/plasmapkg/main.cpp 3dc061c 
> 
> Diff: http://git.reviewboard.kde.org/r/105677/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Plasmapkg: Add KWin/Decoration support to Plasmapkg

[Marco Martin]

> On July 26, 2012, 10:17 a.m., Marco Martin wrote:
> > Ship It!

scratch it, wait for final green flag by martin ;)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105677/#review16466
---


On July 23, 2012, 2:47 p.m., Antonis Tsiapaliokas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105677/
> ---
> 
> (Updated July 23, 2012, 2:47 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> Hello,
> 
> This patch is adding support for "plasmapkg -t kwindecoration"
> 
> 
> Diffs
> -
> 
>   plasma/tools/plasmapkg/main.cpp 3dc061c 
> 
> Diff: http://git.reviewboard.kde.org/r/105677/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Antonis Tsiapaliokas
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KRunner Bookmarks: implement Chrome/Chromium support

[Marco Martin]

> On July 22, 2012, 11:17 p.m., Aleix Pol Gonzalez wrote:
> > I don't see the patch...?
> 
> Marco Gulino wrote:
> it's in a separate branch (the one specified above) , there are too many 
> files, a patch wouldn't be handy :-)

posting a git diff here to master would be useful anyways ;)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105673/#review16244
---


On July 22, 2012, 10:27 p.m., Marco Gulino wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105673/
> ---
> 
> (Updated July 22, 2012, 10:27 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> I've nearly finished my work on the Bookmarks krunner, at least I think it's 
> ready for a review.
> Main focus: add support for chrome (and chromium).
> Side effects: refactoring, a few unit tests, and Favicons for firefox (it's 
> very similar for chrome, they're stored as sqlite blob, so adding favicon for 
> chrome meant making easy to add them to firefox too).
> I also removed some code seeming dead, or duplicated.
> 
> I'm mostly unhappy with the favicon fetch from firefox and chrome: i had to 
> save them to temp file since it's impossible to load QPixmap in krunner 
> plugins.
> 
> What's still missing: maybe a little more testing (both unit and manual) and 
> cleanup.
> 
> branch: plasma/bookmarksrunner-chrome-gulino, path 
> /plasma/generic/runners/bookmarks
> 
> 
> Diffs
> -
> 
> 
> Diff: http://git.reviewboard.kde.org/r/105673/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Gulino
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: kickoff-qml: TabBar button width

[Marco Martin]

> On July 19, 2012, 9:04 a.m., Marco Martin wrote:
> > thanks, wouldn;t have remembered ;)
> > 
> > the changes seems good, but i'm not sure about giving kickoff a copy of the 
> > tabbar.
> > 
> > any reason this is not proposed as a patch for the tabbar component itself?
> 
> Greg T wrote:
> Of course I could do that. But I didn't know if such a general change 
> would be welcome. Maybe people love equally sized blocks?
> 
> Marco Martin wrote:
> i really think we shouldn't start to customize the components in a single 
> applet like that.
> 
> what could be done is:
> as implicit width of the tabbar should be a width such that all tabs have 
> the same width that is the one of the largest tab, so by default it would 
> attempt to never elide (probably some work in the bindings is needed to 
> export this as preferred width of the applet).
> 
> if it's forced to be smaller it starts to elide the text.
> 
> Greg T wrote:
> I'm not sure if I can follow you, but basically you describe the current 
> behavior. Every TabButton got a 'implicitHeight: label.paintedHeight' and the 
> layout calculates a minimum implicitWidth that doesn't elide text. The export 
> is missing, though.

basically would be kickoff opening by default wide enough to make all text fit 
(maybe still not going over a maximum width)

i'm not sure what's still missing in the bindings to make this feasible tough


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105405/#review16103
---


On July 1, 2012, 8:42 p.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105405/
> ---
> 
> (Updated July 1, 2012, 8:42 p.m.)
> 
> 
> Review request for Plasma, Marco Martin and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> Heda,
> This patch addresses the layout of the tab bar. The tab buttons are now sized 
> depending of their text width.
> 
> I just copied the tabbar code from kde-runtime and exchanged taskbarLayout. 
> My main question is: Can I do this more elegantly without copying TabBar.qml?
> 
> 
> Diffs
> -
> 
>   plasma/desktop/applets/kickoff/package/contents/ui/KickoffTabBar.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/Private/TabBarLayout.qml 
> PRE-CREATION 
>   plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml 4d53208 
> 
> Diff: http://git.reviewboard.kde.org/r/105405/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg T
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: increased binary clock applet minimum size

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105577/#review16470
---


it should depend from the border size as well.
right now it would break panels less that 40 px tall.

- Marco Martin


On July 15, 2012, 12:19 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105577/
> ---
> 
> (Updated July 15, 2012, 12:19 p.m.)
> 
> 
> Review request for Plasma and Davide Bettio.
> 
> 
> Description
> ---
> 
> bug reference: https://bugs.kde.org/show_bug.cgi?id=301674
> using previous minimum size the applet drawn incorrectly.
> this patch slightly increased the minimum size of binary clock applet when 
> placed in desktop.
> 
> 
> This addresses bug 301674.
> http://bugs.kde.org/show_bug.cgi?id=301674
> 
> 
> Diffs
> -
> 
>   applets/binary-clock/binaryclock.cpp 6e706de 
> 
> Diff: http://git.reviewboard.kde.org/r/105577/diff/
> 
> 
> Testing
> ---
> 
> master
> 
> 
> Screenshots
> ---
> 
> before - after
>   http://git.reviewboard.kde.org/r/105577/s/637/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: DrKonqi should report the crashes of kactivitymanagerd to the kactivities product in BKO

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105483/#review16471
---

Ship it!


Ship It!

- Marco Martin


On July 9, 2012, 12:27 p.m., Jekyll Wu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105483/
> ---
> 
> (Updated July 9, 2012, 12:27 p.m.)
> 
> 
> Review request for KDE Runtime, Plasma, Ivan Čukić, and George Kiagiadakis.
> 
> 
> Description
> ---
> 
> There is now the "kactivities" product in BKO (corresponding to the 
> kactivities repository where kactivitymanagerd lives)   So I think DrKonqi 
> should forward the crashes of kactivitymanagerd to the "kactivies" product.
> 
> 
> Diffs
> -
> 
>   drkonqi/data/mappings 147bcdc 
> 
> Diff: http://git.reviewboard.kde.org/r/105483/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jekyll Wu
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: change default config of taskmanager

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105374/#review16473
---

Ship it!


- Marco Martin


On June 28, 2012, 7:03 p.m., Greg T wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105374/
> ---
> 
> (Updated June 28, 2012, 7:03 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> libtaskmanager can't remove those ("browser", "preferred://browser, , , ") 
> entrys, so I moved them to the Items list. I don't know why they were 
> separated in the first place. That's why I'm opening this review request.
> 
> 
> This addresses bug 278724.
> http://bugs.kde.org/show_bug.cgi?id=278724
> 
> 
> Diffs
> -
> 
>   libs/taskmanager/groupmanager.cpp 5ca0159 
> 
> Diff: http://git.reviewboard.kde.org/r/105374/diff/
> 
> 
> Testing
> ---
> 
> no regressions noted.
> 
> 
> Thanks,
> 
> Greg T
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix the minimum size of some applets

[Marco Martin]

> On June 14, 2012, 10:33 a.m., Aaron J. Seigo wrote:
> > applets/pastebin/pastebin.cpp, line 263
> > 
> >
> > why 33?
> 
> Maarten De Meyer wrote:
> As I explained to David:
> "If it is 32 the iconSize() method (as I understand it) selects a smaller 
> icon.
> iconSize() returns the biggest fitting icon, if the rectangle is 32x32 
> the biggest fitting icon is 16x16. This looks way too small on the desktop 
> and is not consistent with other applets.
> If the rectangle is 1 pixel higher and wider it works and looks better."
> 
> However it still seems to select a smaller icon now anyway so I changed 
> it.

instead of 32 and 33 you may use KIconLoader::SizeMedium (that is usually 32, 
but cleaner)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105234/#review14728
---


On June 29, 2012, 11:13 a.m., Maarten De Meyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105234/
> ---
> 
> (Updated June 29, 2012, 11:13 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> This fixes the minimum size of the following applets: showdashboard, 
> systemloadviewer, pastebin, weatherstation and timer.
> Some sizes were to small, so there were visual glitches and some applets had 
> no minimum value set.
> 
> I have no commit rights.
> 
> 
> Diffs
> -
> 
>   applets/pastebin/pastebin.cpp 208e6a3 
>   applets/showdashboard/showdashboard.h 695347f 
>   applets/showdashboard/showdashboard.cpp 1c2f623 
>   applets/systemloadviewer/systemloadviewer.cpp b852256 
>   applets/timer/timer.cpp ba5ee66 
>   applets/weatherstation/weatherstation.h 6d4ae24 
>   applets/weatherstation/weatherstation.cpp 8ada9c2 
> 
> Diff: http://git.reviewboard.kde.org/r/105234/diff/
> 
> 
> Testing
> ---
> 
> Run the applets with their new minimum size, and minimized.
> 
> 
> Thanks,
> 
> Maarten De Meyer
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add missing email addresses back into add widget tooltip.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105312/#review16475
---


this was partly committed.
what's still missing in master is the clickable email.

- Marco Martin


On June 21, 2012, 4:39 a.m., Matthew John Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105312/
> ---
> 
> (Updated June 21, 2012, 4:39 a.m.)
> 
> 
> Review request for Plasma, Ivan Čukić and Marco Martin.
> 
> 
> Description
> ---
> 
> When the QML port of the add widget dialog occured, the creator's email 
> address got chopped off.  This commit fixes a bug hidding the email address, 
> and also starts displaying it again in the tooltip.
> 
> There are a couple of issue left with this patch:
> 1) I have to disable wrapping, otherwise the text wraps at odd points for no 
> reason (it fits fine otherwise).
> 2) The link currently doesn't work as I'm not sure how to hook it up to send 
> mail.  Should it be left as is, or just remove the link for 4.9 and update 
> with a link for 4.10?
> 
> 
> Diffs
> -
> 
>   libs/plasmagenericshell/widgetsexplorer/package/contents/ui/Tooltip.qml 
> ba804fd006496ee4a7118e97fe44038f0617eec7 
>   libs/plasmagenericshell/widgetsexplorer/plasmaappletitemmodel_p.h 
> e745ef58533ab0e22d2109d5beeff6c29c4d18b4 
> 
> Diff: http://git.reviewboard.kde.org/r/105312/diff/
> 
> 
> Testing
> ---
> 
> Tested locally in Xephyr.  The tooltip now contains the email address.
> 
> 
> Thanks,
> 
> Matthew John Dawson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KRunner Bookmarks: implement Chrome/Chromium support

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105673/#review16476
---


what i can say quickly looking at it is that it looks cleaner and more 
expandible than the old one.
of course is a bit big, so will indeed need more testing, but most important 
thing for the first merge is that there aren't significant regressions compared 
to what there is already (konq, firefox, opera)

- Marco Martin


On July 26, 2012, 10:23 a.m., Marco Gulino wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105673/
> ---
> 
> (Updated July 26, 2012, 10:23 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> I've nearly finished my work on the Bookmarks krunner, at least I think it's 
> ready for a review.
> Main focus: add support for chrome (and chromium).
> Side effects: refactoring, a few unit tests, and Favicons for firefox (it's 
> very similar for chrome, they're stored as sqlite blob, so adding favicon for 
> chrome meant making easy to add them to firefox too).
> I also removed some code seeming dead, or duplicated.
> 
> I'm mostly unhappy with the favicon fetch from firefox and chrome: i had to 
> save them to temp file since it's impossible to load QPixmap in krunner 
> plugins.
> 
> What's still missing: maybe a little more testing (both unit and manual) and 
> cleanup.
> 
> branch: plasma/bookmarksrunner-chrome-gulino, path 
> /plasma/generic/runners/bookmarks
> 
> 
> Diffs
> -
> 
>   plasma/generic/runners/bookmarks/.gitignore PRE-CREATION 
>   plasma/generic/runners/bookmarks/CMakeLists.txt 39d7834 
>   plasma/generic/runners/bookmarks/bookmarkmatch.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/bookmarkmatch.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/bookmarksrunner.h d7545af 
>   plasma/generic/runners/bookmarks/bookmarksrunner.cpp aa3d45d 
>   plasma/generic/runners/bookmarks/bookmarksrunner_defs.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browser.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browserfactory.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browserfactory.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/chrome.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/chrome.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/chromefindprofile.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/chromefindprofile.cpp 
> PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/findprofile.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/firefox.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/firefox.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/kdebrowser.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/kdebrowser.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/opera.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/browsers/opera.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/favicon.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/favicon.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/faviconfromblob.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/faviconfromblob.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/fetchsqlite.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/fetchsqlite.cpp PRE-CREATION 
>   plasma/generic/runners/bookmarks/plasma-runner-bookmarks.desktop b752591 
>   plasma/generic/runners/bookmarks/tests/CMakeLists.txt PRE-CREATION 
>   
> plasma/generic/runners/bookmarks/tests/chrome-config-home/.config/chromium/Local
>  PRE-CREATION 
>   
> plasma/generic/runners/bookmarks/tests/chrome-config-home/Chrome-Bookmarks-Sample.json
>  PRE-CREATION 
>   
> plasma/generic/runners/bookmarks/tests/chrome-config-home/Chrome-Bookmarks-SecondProfile.json
>  PRE-CREATION 
>   plasma/generic/runners/bookmarks/tests/testchromebookmarks.h PRE-CREATION 
>   plasma/generic/runners/bookmarks/tests/testchromebookmarks.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/105673/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Gulino
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: increased binary clock applet minimum size

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105577/#review16546
---

Ship it!


Ship It!

- Marco Martin


On July 15, 2012, 12:19 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105577/
> ---
> 
> (Updated July 15, 2012, 12:19 p.m.)
> 
> 
> Review request for Plasma and Davide Bettio.
> 
> 
> Description
> ---
> 
> bug reference: https://bugs.kde.org/show_bug.cgi?id=301674
> using previous minimum size the applet drawn incorrectly.
> this patch slightly increased the minimum size of binary clock applet when 
> placed in desktop.
> 
> 
> This addresses bug 301674.
> http://bugs.kde.org/show_bug.cgi?id=301674
> 
> 
> Diffs
> -
> 
>   applets/binary-clock/binaryclock.cpp 6e706de 
> 
> Diff: http://git.reviewboard.kde.org/r/105577/diff/
> 
> 
> Testing
> ---
> 
> master
> 
> 
> Screenshots
> ---
> 
> before - after
>   http://git.reviewboard.kde.org/r/105577/s/637/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: increased binary clock applet minimum size

[Marco Martin]

> On July 26, 2012, 10:23 a.m., Marco Martin wrote:
> > it should depend from the border size as well.
> > right now it would break panels less that 40 px tall.
> 
> Reza Shah wrote:
> My patch only for placement at desktop. 
> Does it also affect the placement at panel?

yeah, in this case the patch is fine


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105577/#review16470
---


On July 15, 2012, 12:19 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105577/
> ---
> 
> (Updated July 15, 2012, 12:19 p.m.)
> 
> 
> Review request for Plasma and Davide Bettio.
> 
> 
> Description
> ---
> 
> bug reference: https://bugs.kde.org/show_bug.cgi?id=301674
> using previous minimum size the applet drawn incorrectly.
> this patch slightly increased the minimum size of binary clock applet when 
> placed in desktop.
> 
> 
> This addresses bug 301674.
> http://bugs.kde.org/show_bug.cgi?id=301674
> 
> 
> Diffs
> -
> 
>   applets/binary-clock/binaryclock.cpp 6e706de 
> 
> Diff: http://git.reviewboard.kde.org/r/105577/diff/
> 
> 
> Testing
> ---
> 
> master
> 
> 
> Screenshots
> ---
> 
> before - after
>   http://git.reviewboard.kde.org/r/105577/s/637/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: increased binary clock applet minimum size

[Marco Martin]

> On July 27, 2012, 7:41 p.m., Marco Martin wrote:
> > Ship It!
> 
> Reza Shah wrote:
> Other than master. Is it ok to push to 4.9.0? Or should go to 4.9.1?

KDE/4.9 branch is fine, yes


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105577/#review16546
---


On July 15, 2012, 12:19 p.m., Reza Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105577/
> ---
> 
> (Updated July 15, 2012, 12:19 p.m.)
> 
> 
> Review request for Plasma and Davide Bettio.
> 
> 
> Description
> ---
> 
> bug reference: https://bugs.kde.org/show_bug.cgi?id=301674
> using previous minimum size the applet drawn incorrectly.
> this patch slightly increased the minimum size of binary clock applet when 
> placed in desktop.
> 
> 
> This addresses bug 301674.
> http://bugs.kde.org/show_bug.cgi?id=301674
> 
> 
> Diffs
> -
> 
>   applets/binary-clock/binaryclock.cpp 6e706de 
> 
> Diff: http://git.reviewboard.kde.org/r/105577/diff/
> 
> 
> Testing
> ---
> 
> master
> 
> 
> Screenshots
> ---
> 
> before - after
>   http://git.reviewboard.kde.org/r/105577/s/637/
> 
> 
> Thanks,
> 
> Reza Shah
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PlasmaCore.ToolTip

[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

Review Request: Nepomuk2 port of Kactivities

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105790/
---

Review request for Plasma and Ivan Čukić.


Description
---

this is the diff from master of the branch mart/nepomuk2 in kactivities (the 
branch has a more comprehensible history of changes ;).
it ports all the nepomuk usage to nepomuk2


Diffs
-

  src/service/CMakeLists.txt f6d7f9c 
  src/service/NepomukActivityManager.h ba6e75b 
  src/service/NepomukActivityManager.cpp e06ded3 
  src/service/jobs/nepomuk/Move.h 23db0b7 
  src/service/jobs/nepomuk/Move.cpp 8342aef 
  src/service/plugins/sqlite/CMakeLists.txt 1664630 
  src/service/plugins/sqlite/NepomukCommon.h c3ecacf 
  src/workspace/CMakeLists.txt 2fcd194 
  src/workspace/kio/CMakeLists.txt 7dfb50c 
  src/workspace/kio/kio_activities.cpp 8ef1f7b 

Diff: http://git.reviewboard.kde.org/r/105790/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Nepomuk2 port of Kactivities

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105790/#review16639
---



src/service/NepomukActivityManager.h
<http://git.reviewboard.kde.org/r/105790/#comment12981>

This is the only probable potential problem:
should it still have a retrocompatibility method returning a 
Nepomuk::Resource?


- Marco Martin


On July 30, 2012, 12:02 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105790/
> ---
> 
> (Updated July 30, 2012, 12:02 p.m.)
> 
> 
> Review request for Plasma and Ivan Čukić.
> 
> 
> Description
> ---
> 
> this is the diff from master of the branch mart/nepomuk2 in kactivities (the 
> branch has a more comprehensible history of changes ;).
> it ports all the nepomuk usage to nepomuk2
> 
> 
> Diffs
> -
> 
>   src/service/CMakeLists.txt f6d7f9c 
>   src/service/NepomukActivityManager.h ba6e75b 
>   src/service/NepomukActivityManager.cpp e06ded3 
>   src/service/jobs/nepomuk/Move.h 23db0b7 
>   src/service/jobs/nepomuk/Move.cpp 8342aef 
>   src/service/plugins/sqlite/CMakeLists.txt 1664630 
>   src/service/plugins/sqlite/NepomukCommon.h c3ecacf 
>   src/workspace/CMakeLists.txt 2fcd194 
>   src/workspace/kio/CMakeLists.txt 7dfb50c 
>   src/workspace/kio/kio_activities.cpp 8ef1f7b 
> 
> Diff: http://git.reviewboard.kde.org/r/105790/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PlasmaComponents ScrollBar is broken

[Marco Martin]

On Monday 30 July 2012, Aleix Pol wrote:
> Hi,
> I've been trying to get two applications to work properly that use the
> PlasmaComponents: the QuickChat plasmoid (ktp-text-ui) and muon
> discover. On both of them I've had big problems while using Flickable
> elements programatically (that is, playing with the contentY property)
> while having a scrollbar. Note that the test case attached works
> without a scrollbar, but with the scrollbar it starts to do weird
> stuff.
> 
> I've been looking through the code, and to me it seems like the
> RangeModel is messing the whole implementations. There are two
> important properties there value and position. And changing any of
> those make the other change so we enter quite some big loops of
> changes that are a bit annoying.
> 
> I've been thinking of rewriting the ScrollBar without this RangeModel,
> but maybe that's only because I don't understand it enough. Can
> anybody look into this and give me a hand? I think it would be really
> interesting to sort this one out!
> 
> Aleix

yep, i see the binding loops, i can look into it. (daker, are you still there? 
;)

are you experiencing also problems in the behavior? the testcase seems to 
behave fine here

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

LinuxCon Barcelona

[Marco Martin]

Hi all,
Albert just mentioned me
https://events.linuxfoundation.org/events/linuxcon-europe/cfp

deadline of cfp is midnight 31 lug - 1aug, so very short notice.

anybody wanting to give it a try? (maybe ale.* that you are from barcelona? ;)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Logout QML dialog theming and Caledonia

[Marco Martin]

On Tuesday 31 July 2012, Aleix Pol wrote:
> Hi Plasma,
> I've been discussing with Caledonia's [1] designer recently, he has
> told me that he can't theme that dialog that used to integrate
> properly, he sent me this screenshot [2].
> 
> Does anybody have an idea of what is Caledonia theme missing?
> [2]
> https://lh3.googleusercontent.com/-1nBvlC03n7g/UBZl92ZW2BI/A4c/T_q
> jFZmF-_o/s607/KDE+QML+logout.png
i guess this is the screenshot of the dialog broken?

what is missing? it shouldmake the dialog smaller without the left part?


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PlasmaComponents ScrollBar is broken

[Marco Martin]

On Monday 30 July 2012, Aleix Pol wrote:
> I've been thinking of rewriting the ScrollBar without this RangeModel,
> but maybe that's only because I don't understand it enough. Can
> anybody look into this and give me a hand? I think it would be really
> interesting to sort this one out!
> 
> Aleix

try to update to current master, binding loop warnings are gone.

the test case seems to work fine for me but don't know what was the intended 
behavior, so give it a try ;)

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Logout QML dialog theming and Caledonia

[Marco Martin]

On Tuesday 31 July 2012, Aleix Pol wrote:
> Hi Plasma,
> I've been discussing with Caledonia's [1] designer recently, he has
> told me that he can't theme that dialog that used to integrate
> properly, he sent me this screenshot [2].
> 
> Does anybody have an idea of what is Caledonia theme missing?

now it should look again like 

http://kde-
help.org/content/preview.php?preview=2&id=142424&file1=142424-1.jpeg&file2=142424-2.png&file3=142424-3.png&name=Caledonia

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Logout QML dialog theming and Caledonia

[Marco Martin]

On Tuesday 31 July 2012, Aleix Pol wrote:

> > 
> > now it should look again like
> > 
> > http://kde-
> > help.org/content/preview.php?preview=2&id=142424&file1=142424-1.jpeg&file
> > 2=142424-2.png&file3=142424-3.png&name=Caledonia

> 
> Does that mean you changed something? :P

yes, the ksmserver ui qml file in kde-workspace, 4.9 and master


-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Don't warn when using a page without toolbar

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105803/#review16701
---

Ship it!


good catch

- Marco Martin


On July 31, 2012, 11:24 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105803/
> ---
> 
> (Updated July 31, 2012, 11:24 a.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> When executing Muon Discover, I had this warning sometimes. It's not really 
> something that's forbidded, so we better adapt the code to this situation.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/ToolBar.qml 17b2939 
> 
> Diff: http://git.reviewboard.kde.org/r/105803/diff/
> 
> 
> Testing
> ---
> 
> Changed it and ran discover again, everything worked fine.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Polishing ScrollBar

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105808/#review16738
---

Ship it!


the changes are fine, but is probably not enough to completely fix the problem?

- Marco Martin


On Aug. 1, 2012, 1:59 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105808/
> ---
> 
> (Updated Aug. 1, 2012, 1:59 a.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch changes two things:
> - When non-interactive or not enabled, don't make the handle responsible of 
> the flickable position.
> - When the Flickable.contentHeight property changes, update the value 
> according to Flickable.contentY. This is important because if both properties 
> are updated at the same time we get in weird states because of RangeModel.
> 
> Also, I'd like this patch to get in for 4.9 (4.9.1 if too late for 4.9.0 :P). 
> It is important because without this KTP's QuickChat Plasmoid is __very__ 
> annoying.
> 
> 
> Diffs
> -
> 
>   plasma/declarativeimports/plasmacomponents/qml/ScrollBar.qml 430de05 
> 
> Diff: http://git.reviewboard.kde.org/r/105808/diff/
> 
> 
> Testing
> ---
> 
> Played around with http://proli.net/meu/kde/testcase.qml
> Also made sure it fixes my issue in ktp-text-ui
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PlasmaComponents ScrollBar is broken

[Marco Martin]

On Wednesday 01 August 2012, Aleix Pol wrote:
> 
> Well, I've just tried it, it's definitely better without the warning
> but not fixed yet.
> 
> The idea of this example is that it will go to the end of the list
> every time a new data enters (like in a chat or the log when you're
> updating your system, that's the two places I was planning to use
> this).
> 
> If you see in my example (you can run it using
> kde:scratch/apol/kdeqmlviewer if you want) you can see that if the
> scrollbar has "interactive: false" it works just fine (or if you
> removethe scrollbar, of course), but if you have it there it doesn't
> scroll until the end but halfway, like to the end but 6 px.
> 

from what i understood besides the position the handle must correctly update 
its size too, and if both are not correct, the range position will be 
miscalculated.
i've now committed a small delay to the range position update trough a timer 
and seems to work corretly now

Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel