D27353: Allow Activity Switcher to move/add windows to activities by drag and drop from the taskbar

[Will Stephenson]

wstephenson added a comment.


  In D27353#618452 , @ivan wrote:
  
  > This looks cool. The thing I'm missing (correct me if I'm wrong - I'm yet 
to test the patch) is for it to open the switcher when dragging the window over 
the switcher applet icon.
  
  
  That would be org.kde.plasma.showActivityManager, I assume? If so, yes, that 
would be good for completeness. I will also need to add the drop functionality 
to org.kde.plasma.activitybar then I think this is feature complete.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27353

To: wstephenson, #plasma, ivan, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27353: Allow Activity Switcher to move/add windows to activities by drag and drop from the taskbar

[Will Stephenson]

wstephenson updated this revision to Diff 75898.
wstephenson added a comment.


  Removed debug statement;
  Added changed qml file to diff.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27353?vs=75562&id=75898

REVISION DETAIL
  https://phabricator.kde.org/D27353

AFFECTED FILES
  desktoppackage/contents/activitymanager/ActivityItem.qml
  imports/activitymanager/CMakeLists.txt
  imports/activitymanager/switcherbackend.cpp
  imports/activitymanager/switcherbackend.h

To: wstephenson, #plasma, ivan, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27353: Allow Activity Switcher to move/add windows to activities by drag and drop from the taskbar

[Will Stephenson]

wstephenson added a comment.


  There is a change to the QML missing from this diff as it stands, will amend 
it tomorrow

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27353

To: wstephenson, #plasma, ivan, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27322: Allow move or add window to Activities during Dnd using Ctrl modifier

[Will Stephenson]

wstephenson added a comment.


  In D27322#612156 , @ivan wrote:
  
  > Cool idea, I'll have to think of something similar for the regular activity 
switcher
  
  
  @ivan it's here: https://phabricator.kde.org/D27353

REVISION DETAIL
  https://phabricator.kde.org/D27322

To: wstephenson, davidedmundson, #plasma, hein
Cc: ivan, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27353: Allow Activity Switcher to move/add windows to activities by drag and drop from the taskbar

[Will Stephenson]

wstephenson created this revision.
wstephenson added reviewers: Plasma, ivan, davidedmundson.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
wstephenson requested review of this revision.

REVISION SUMMARY
  In the same way that the Activity Pager should (see 
https://phabricator.kde.org/D27322 for fix) accept dragged windows to move them 
between Activities, this patch allows the Activity Switcher (meta+q) to 
move/add (ctrl-drag) windows between/to Activities.
  
  Compare to 
https://cukic.co/2014/07/15/a-screencast-of-the-activity-switcher-in-plasma-5-1/
 (video at https://www.youtube.com/watch?v=uxaDaXW67Oo).

TEST PLAN
  > Move window between activities
  
  1. Setup desktop with two activities, taskbar, window on one activity, 
activate activity with the window on it
  2. Open Activity Switcher, Drag window's taskbar entry to the other 
activity's item.
  3. Observe window moves to other activity
  
  > Add window to another activity
  
  1. Setup remaining from previous test
  2. Open Activity Switcher, Ctrl-drag window's taskbar entry to the other 
activity's item.
  3. Observe window is now on all activities
  
  > Move window from all activities to a single activity
  
  1. Setup remaining from previous test. Window is on all activities
  2. Open Activity Switcher, Drag window's taskbar entry to an activity item
  3. Observe window is now only on one activity
  
  > Add window to two out of three activities
  
  1. Setup remaining from previous test. Window is on 1/2 activities
  2. Open Activity Switcher, Add 3rd activity using Activity Manager
  3. Ctrl-drag window's taskbar entry to the new activity.
  4. Observe window is now on 2/3 activities
  
  > Move window to a different 2/3 activities
  
  1. Setup remaining from previous test. Window is on 2/3 activities
  2. Open Activity Switcher, Activate an activity the window is present on
  3. Drag window's taskbar entry to the activity it is not on
  4. Observe window is now moved to the activity it was dropped on, and is no 
longer on the current activity
  
  > Add window to the only activity it is not on
  
  1. Setup remaining from previous test. Window is on 2/3 activities
  2. Open Activity Switcher, Activate an activity the window is present on
  3. Ctrl-drag window's taskbar entry to the activity it is not on
  4. Observe window is now present on all activities

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27353

AFFECTED FILES
  imports/activitymanager/CMakeLists.txt
  imports/activitymanager/switcherbackend.cpp
  imports/activitymanager/switcherbackend.h

To: wstephenson, #plasma, ivan, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27319: Fix dragging windows from taskbar to activity pager applet to add to activity

[Will Stephenson]

wstephenson abandoned this revision.
wstephenson added a comment.


  @broulik Thanks!

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27319

To: wstephenson, hein, davidedmundson, #plasma
Cc: broulik, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
ahiemstra, mart

D27319: Fix dragging windows from taskbar to activity pager applet to add to activity

[Will Stephenson]

wstephenson added a comment.


  Changes integrated into https://phabricator.kde.org/D27322 - how do I 
withdraw/close a posted diff in phabricator? :)

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27319

To: wstephenson, hein, davidedmundson, #plasma
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27322: Allow move or add window to Activities during Dnd using Ctrl modifier

[Will Stephenson]

wstephenson added a comment.


  I tried to test dragging multiple windows (as a grouped taskbar entry) but 
this fails at the first test, outside of my changes, so I think there's an 
unrelated bug hiding in TaskManager::XWindowTasksModel::winIdsFromMimeData(), 
which can wait for another patch.

REVISION DETAIL
  https://phabricator.kde.org/D27322

To: wstephenson, davidedmundson, #plasma, hein
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27322: Allow move or add window to Activities during Dnd using Ctrl modifier

[Will Stephenson]

wstephenson updated this revision to Diff 75496.
wstephenson added a comment.


  Implement feedback from d_ed
  
  Integrate logic fix from https://phabricator.kde.org/D27319

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27322?vs=75472&id=75496

REVISION DETAIL
  https://phabricator.kde.org/D27322

AFFECTED FILES
  applets/pager/package/contents/ui/main.qml
  applets/pager/plugin/pagermodel.cpp
  applets/pager/plugin/pagermodel.h

To: wstephenson, davidedmundson, #plasma, hein
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27322: Allow move or add window to Activities during Dnd using Ctrl modifier

[Will Stephenson]

wstephenson created this revision.
wstephenson added reviewers: davidedmundson, Plasma, hein.
wstephenson added a project: Plasma.
Herald added a subscriber: plasma-devel.
wstephenson requested review of this revision.

REVISION SUMMARY
  This allows the familiar file manager semantics of ctrl+drag = copy,
  drag = move to be used when dragging and dropping windows between
  activities using the taskbar and the activity pager applet.

TEST PLAN
  - Move window between activities
  - Setup desktop with two activities, taskbar and activity pager, test window 
on one activity, activate activity with the window on it
  - Drag window's taskbar entry to the other activity's pager item.
  - Observe window moves to other activity
  
  - Add window to another activity
  - Setup remaining from previous test
  - Ctrl-drag window's taskbar entry to the other activity's pager item.
  - Observe window is now on all activities
  
  - Move window from all activities to a single activity
  - Setup remaining from previous test. Window is on all activities
  - Drag window's taskbar entry to an activity pager item
  - Observe window is now only on one activity
  
  - Add window to two out of three activities
  - Setup remaining from previous test. Window is on 1/2 activities
  - Add 3rd activity using Activity Manager
  - Ctrl-drag window's taskbar entry to the new activity.
  - Observe window is now on 2/3 activities
  
  - Move window to a different 2/3 activities
  - Setup remaining from previous test. Window is on 2/3 activities
  - Activate an activity the window is present on
  - Drag window's taskbar entry to the activity it is not on
  - Observe window is now moved to the activity it was dropped on, and is no 
longer on the current activity
  
  - Add window to the only activity it is not on
  - Setup remaining from previous test. Window is on 2/3 activities
  - Activate an activity the window is present on
  - Ctrl-drag window's taskbar entry to the activity it is not on
  - Observe window is now present on all activities

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27322

AFFECTED FILES
  applets/pager/package/contents/ui/main.qml
  applets/pager/plugin/pagermodel.cpp
  applets/pager/plugin/pagermodel.h

To: wstephenson, davidedmundson, #plasma, hein
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27319: Fix dragging windows from taskbar to activity pager applet to add to activity

[Will Stephenson]

wstephenson created this revision.
wstephenson added reviewers: hein, davidedmundson.
wstephenson added a project: Plasma.
Herald added a subscriber: plasma-devel.
wstephenson requested review of this revision.

REVISION SUMMARY
  The code to handle a window drag from the taskbar to drop on the
  Activity Pager to add the window to an Activity was broken,
  because the test to see if the drop location is a running activity
  still treated the itemId as an integer indexing into an array of running
  activity indices, rather than an id string that could be a member of the
  list of running activities.
  

This commit fixes that logic and simplifies the no-op return logic.

TEST PLAN
  0) add activity pager widget[to panel]
  
  1. Create 2nd activity
  2. Open a window.
  3. Set that window via the window menu to only appear on the first activity
  4. Check that the 2nd activity is empty
  5. Drag the window's taskbar entry to the pager item for the 2nd activity
  6. check that the dropped window is now also present on the 2nd activity.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27319

AFFECTED FILES
  applets/pager/plugin/pagermodel.cpp

To: wstephenson, hein, davidedmundson
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: Review Request 110216: Rename Screen Locker screensaver KCM to Lock Screen

[Will Stephenson]

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

(Updated ago. 11, 2014, 7:14 p.m.)


Status
--

This change has been discarded.


Review request for Plasma and Marco Martin.


Repository: kde-workspace


Description
---

'Screen Locker' sounds wrong, a locker is something you keep your books at 
school in.

'Lock Screen' is currently frequently used in English on phones and is also 
used by Gnome Shell for their screensaver replacement.


Diffs
-

  kcontrol/screensaver/screensaver.desktop d1f887a 

Diff: https://git.reviewboard.kde.org/r/110216/diff/


Testing
-------


Thanks,

Will Stephenson

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

Review Request 110216: Rename Screen Locker screensaver KCM to Lock Screen

[Will Stephenson]

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

Review request for Plasma and Marco Martin.


Description
---

'Screen Locker' sounds wrong, a locker is something you keep your books at 
school in.

'Lock Screen' is currently frequently used in English on phones and is also 
used by Gnome Shell for their screensaver replacement.


Diffs
-

  kcontrol/screensaver/screensaver.desktop d1f887a 

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


Testing
-------


Thanks,

Will Stephenson

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

Disabled python scriptengine

[Will Stephenson]

kdebase/workspace/plasma/generic/scriptengines/python has been disabled since 
August, any idea why?

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

Re: plasmate status?

[Will Stephenson]

On Monday 18 October 2010 16:08:33 Chani wrote:
> are there plasmate packages or anything? my system is a bit old, but maybe
> the  image we'll be using for the workshop will have the dependencies I'm
> missing...
Version 0.1alpha2 is packaged here, and builds vs trunk still:

https://build.opensuse.org/package/show?package=plasmate&project=KDE:Unstable:Playground

I can include it on the image if it is still useful.

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

Re: Review Request: Manual panel hiding [WIP]

[Will Stephenson]

On Tuesday 17 August 2010 23:56:04 Marco Martin wrote:
> On Tuesday 17 August 2010, Will Stephenson wrote:
> > > On 2010-05-04 03:49:54, Aaron Seigo wrote:
> > > > any updates on this?
> > > 
> > > Will Stephenson wrote:
> > > Ditto - our users are still asking for it - as they do on every
> > > release.
> > > 
> > > Aaron Seigo wrote:
> > > *gasp* all of them? ;)
> > > 
> > > more seriously, "our users" as a generic term is not a very
> > > interesting metric, since in reality it could be 10 loud users out
> > > of 1000 or it could be an actually significant %. :)
> > > 
> > > that said ... looks like this patch is abandoned. would be nice if
> > > someone picked it up and finished it out.
> > > 
> > > Will Stephenson wrote:
> > > It's the loud and unhelpful crew.
> > 
> > Stephenson picks up the ball^Wpatch and runs with it.  Currently I've
> > switched to Plasma::Toolbutton for the hiding buttons, using layouts
> 
> isn't a but risky to assume there will be a layout in the panel contaiment?

Did I misread you on the diff then? 

> > instead of manual hiding, made it work with vertical panels and am
> > currently trying to figure out how to do something GlowBar-like instead
> > of showing QToolButtons in screen corners when the panel is hidden. 
> > I'll
> 
> yeah, would look nice
> 
> > post a new diff for review tomorrow.
> > 
> > Oh and is there any way to get the right hiding button past the Panel
> > Tool Box button?  containment()->layout() does not seem to include it.
> 
> i guess the space for the toolbox is reserved with setContentmargins, so
> the layout can't be used there
> 
> just had crazy idea:
> the panel ackground would be painted by the view (just as Plasma::Dialog)
> (except for CustomPanels)
> the hide buttons would be qwidgets childs of the view, but would be easy to
> include them in the background since the background itself would be painted
> by the view.

I'll have to look at that code and see how it works.  At the moment I am just 
hacking with a superficial knowledge of Plasma's internals.

If the hide buttons would be qwidgets, but we want to have the right themeing, 
would this make them Plasma::Toolbuttons drawn on separate Views as QWidgets?

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

Re: Review Request: Manual panel hiding [WIP]

[Will Stephenson]

> On 2010-05-04 03:49:54, Aaron Seigo wrote:
> > any updates on this?
> 
> Will Stephenson wrote:
> Ditto - our users are still asking for it - as they do on every release.
> 
> Aaron Seigo wrote:
> *gasp* all of them? ;)
> 
> more seriously, "our users" as a generic term is not a very interesting 
> metric, since in reality it could be 10 loud users out of 1000 or it could be 
> an actually significant %. :)
> 
> that said ... looks like this patch is abandoned. would be nice if 
> someone picked it up and finished it out.
> 
> Will Stephenson wrote:
> It's the loud and unhelpful crew.

Stephenson picks up the ball^Wpatch and runs with it.  Currently I've switched 
to Plasma::Toolbutton for the hiding buttons, using layouts instead of manual 
hiding, made it work with vertical panels and am currently trying to figure out 
how to do something GlowBar-like instead of showing QToolButtons in screen 
corners when the panel is hidden.  I'll post a new diff for review tomorrow.  

Oh and is there any way to get the right hiding button past the Panel Tool Box 
button?  containment()->layout() does not seem to include it. 


- Will


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


On 2010-03-04 19:19:53, Andrzej JR Hunt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3121/
> ---
> 
> (Updated 2010-03-04 19:19:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Manual panel hiding patch (still in progress). Currently only horizontal 
> panels are properly implemented, there is still a display bug whereby the 
> plasma toolbox (cashew) ignores the contentsMargins set on the containment 
> and thus gets covered by the hiding buttons.
> 
> 
> This addresses bug 158556.
> https://bugs.kde.org/show_bug.cgi?id=158556
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 
> 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.cpp 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/panel.cpp 
> 1097398 
> 
> Diff: http://reviewboard.kde.org/r/3121/diff
> 
> 
> Testing
> ---
> 
> Hiding the panels, changing states, changing positions and sizes.
> 
> 
> Thanks,
> 
> Andrzej JR
> 
>

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

Re: Review Request: Manual panel hiding [WIP]

[Will Stephenson]

> On 2010-05-04 03:49:54, Aaron Seigo wrote:
> > any updates on this?
> 
> Will Stephenson wrote:
> Ditto - our users are still asking for it - as they do on every release.
> 
> Aaron Seigo wrote:
> *gasp* all of them? ;)
> 
> more seriously, "our users" as a generic term is not a very interesting 
> metric, since in reality it could be 10 loud users out of 1000 or it could be 
> an actually significant %. :)
> 
> that said ... looks like this patch is abandoned. would be nice if 
> someone picked it up and finished it out.

It's the loud and unhelpful crew.


- Will


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


On 2010-03-04 19:19:53, Andrzej JR Hunt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3121/
> ---
> 
> (Updated 2010-03-04 19:19:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Manual panel hiding patch (still in progress). Currently only horizontal 
> panels are properly implemented, there is still a display bug whereby the 
> plasma toolbox (cashew) ignores the contentsMargins set on the containment 
> and thus gets covered by the hiding buttons.
> 
> 
> This addresses bug 158556.
> https://bugs.kde.org/show_bug.cgi?id=158556
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 
> 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.cpp 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/panel.cpp 
> 1097398 
> 
> Diff: http://reviewboard.kde.org/r/3121/diff
> 
> 
> Testing
> ---
> 
> Hiding the panels, changing states, changing positions and sizes.
> 
> 
> Thanks,
> 
> Andrzej JR
> 
>

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

Wallpaper plugins in default rendering mode

[Will Stephenson]

I've been looking at a bug in the Image plugin where dropping an image file
on the desktop when the Image wallpaper plugin is not in use causes Image to
start up in Slideshow mode.  This is because Containment tries to set the
default rendering mode using an empty string, whereas Image's logic falls
through to Slideshow if the mode is empty.

The documentation for
Plasma::Wallpaper::setRenderingMode( const QString & mode) says that /mode/
should be "One of the modes supported by the plugin, or an empty string for
the default mode".

Should Plasma::Wallpaper::setRenderingMode() discover
the wallpaper's default mode and set it explicitly, if an empty string is
passed?  Or should each wallpaper plugin's logic be written to treat an
empty renderingMode().name() as its default
mode?

Bug:
https://bugs.kde.org/show_bug.cgi?id=245606

Monkey patch to
Image:
https://build.opensuse.org/package/view_file?file=bko245606_no_slides
how_for_dnd_image_wallpaper.diff&package=kdebase4-workspace&project=KDE:Distr
o:Stable

I think it would be simpler for wallpaper plugin writers if they
did not have to consider this case.  What's the correct reading of the
API?

Will


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

Re: Review Request: Manual panel hiding [WIP]

[Will Stephenson]

> On 2010-05-04 03:49:54, Aaron Seigo wrote:
> > any updates on this?

Ditto - our users are still asking for it - as they do on every release.


- Will


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


On 2010-03-04 19:19:53, Andrzej JR Hunt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3121/
> ---
> 
> (Updated 2010-03-04 19:19:53)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Manual panel hiding patch (still in progress). Currently only horizontal 
> panels are properly implemented, there is still a display bug whereby the 
> plasma toolbox (cashew) ignores the contentsMargins set on the containment 
> and thus gets covered by the hiding buttons.
> 
> 
> This addresses bug 158556.
> https://bugs.kde.org/show_bug.cgi?id=158556
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelcontroller.cpp 
> 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.h 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/panelview.cpp 1097398 
>   /trunk/KDE/kdebase/workspace/plasma/desktop/shell/scripting/panel.cpp 
> 1097398 
> 
> Diff: http://reviewboard.kde.org/r/3121/diff
> 
> 
> Testing
> ---
> 
> Hiding the panels, changing states, changing positions and sizes.
> 
> 
> Thanks,
> 
> Andrzej JR
> 
>

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

Review Request: Stop using oxygen as a theme element fallback before 'default' (Air)

[Will Stephenson]

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

Review request for Plasma.


Summary
---

If a user starts Plasma on a machine where the configured desktop theme is not 
available, a fallback is used for each element.  If the theme is completely 
missing, default fallbacks, in order "oxygen" and "default" are used.  This 
means that Oxygen elements are used in preference to Air elements.  With common 
configurations, this results in black text on the black/dark Oxygen elements, 
which is unusable.

This patch removes oxygen from the fallbacks, leaving "default" (Air).  Since 
both oxygen and air are installed by kdebase-workspace they are equally likely 
to be present.


Diffs
-

  trunk/KDE/kdelibs/plasma/theme.cpp 1123666 

Diff: http://reviewboard.kde.org/r/3903/diff


Testing
---


Thanks,

Will

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

Re: Manual Hiding of Plasma Panel (desktop shell)

[Will Stephenson]

On Wednesday 10 March 2010 18:11:55 Andrzej JR Hunt wrote:
> Ok, I think I'm finally on the right track now.

Any more progress? My users are asking...

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Sunday 04 April 2010 22:24:11 Aaron J. Seigo wrote:
> On April 4, 2010, Detlev Casanova wrote:
> > Is the current Kephal API correct ?
> 
> i haven't done a thorough API review of it myself. using it has been quite
> straightforward.

The only parts of Kephal currently in use are the Screens API and its 
associated ScreenUtils helper, though.
 
> there are some small things missing still, though, like
> being able to get the available screen geometry using a Kephal screen id.
> right now we have to go back to KWindowSystem for that; and while it
> works, it feels a bit inconsistent to have to mix Kephal and KWindwoSystem
> calls.

I think that should be possible using Kephal's Output class.  Can you point me 
to somewhere in the code where these are mixed 

> > What Aike said seems ok but it has to be well documented so people don't
> > mix everything up.
> 
> yes..

Note, I've just committed a fundamental reorganisation of the Kephal sources 
to make the code easier to understand.  The build result is the same though.

I've started to add some API docs and notes as I work through the code and get 
my head around it.

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Sunday 04 April 2010 23:30:38 Zack Rusin wrote:
> On Sunday 04 April 2010 15:48:32 Sebastian Kügler wrote:
> > On Saturday 03 April 2010 21:06:00 Aaron J. Seigo wrote:
> > > On April 2, 2010, Detlev Casanova wrote:
> > > > On Thursday 01 April 2010 20:15:40 Aaron J. Seigo wrote:
> > > > > On April 1, 2010, Will Stephenson wrote:
> > > > > > Aaron, do you think there's another GSoC project in completing
> > > > > > Kephal?
> > > > > 
> > > > > yes, particularly on the storing / restoring of configurations and
> > > > > integrating it with the existing UI elements (device notifier and
> > > > > providing a more user- friendly alternative to the current kandr
> > > > > icon, which is highly functional but also tricky to use)
> > > > 
> > > > Ok, Can I write a proposal for this then ?
> > > 
> > > imho: +1 on that.
> > > 
> > > > At first glance, it looks a bit light to make it as a GSoC but I can
> > > > be wrong about that.
> > > 
> > > honestly, i think there will be enough to keep you busy for an entire
> > > GSoC.  besides getting a plasmoid up to snuff there will be Kephal work
> > > that needs to be done. getting thoe workflows as elegant as possible
> > > can take as much time as we can throw at it :)
> > 
> > Having done this myself a couple of years ago (and being one of those who
> > 
> >  got burnt by the ever-changing monster that is X configuration and
> >  therefore eventually gave up on the idea. (Google for "guidance
> >  displayconfig" if you want to see how far we got). BTW, did you know
> >  that the upcoming release of X Server again changes configuration
> >  options!?), I can tell you one thing: It will not be easy, especially
> >  not if you want it to work with different drivers (and possibly
> >  different versions at that).
> > 
> > The amount of opportunities to tear your hair out in X.org land is near
> > 
> >  inifinite.
> 
> Well, it's a lot like feeding a tiger - it's not that really difficult,
> it's just a bit dangerous especially if you try to stuff the food down the
> wrong hole. As you seemed to have been doing =)
> 
> It's worth to remember that X should be policy less, what and how it does
> should really be done higher. You never want to change the X config,
> especially nowadays when the there's really nothing there worth changing
> and it's not like "hey, you've just started kpresenter, please restart X
> so that new output config can take be in effect " is a good strategy
> anyway.
 
> The output config should be stored as part of the KDE config (Kephal I
> guess)

+1, and this is where KDE really falls behind the competition now that fewer 
Xorgs have fixed configuration files, and we don't have store/restorable X 
configuration in the user session.

> , and when I say output config I mean "when an output with this
> identifier (and maybe even this exact edid) is connected we should do A"
> where A is mirroring, setting up a new screen, doing nothing or doing
> whatever user picked the first time this action was performed. Once you
> know what you want to do, you simply use xrandr to actually do it.

This is what Kephal set out to do, has code for but does not actually achieve 
yet.

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Friday 02 April 2010 14:13:03 Aike J Sommer wrote:
> Well.. A Screen is the logical area to which you can maximize a window
> for example, or which has a panel at the bottom!
> An output is the actual physical hardware / monitor...
> 
> So, for each connector that appears when calling xrandr there will be
> one Output created, some enabled, some disabled... On my netbook those
> are "VGA" and "LVDS", on my notebook something like "VGA", "LVDS" and
> "TMDS-1" and on my HTPC "VGA" and "TV-1"!
> 
> How many Screens there are depends on your configuration:
> - If you have only one enabled Output, you will have one Screen with the
> same geometry
> - If you have 2 or more overlapping Outputs, one Screen will be created
> which spans all of those
> - If you have multiple non-overlapping Outputs, one Screen will be
> created per Output
> 
> One of the ideas was to be able to configure even non-overlapping
> Outputs to be combined in one Screen, but that is not implemented...
> 
> Hope that helps!

Thanks, it cleared a lot of questions up.

Will

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Thursday 01 April 2010 21:28:38 Detlev Casanova wrote:
> On Thursday 01 April 2010 18:13:09 Will Stephenson wrote:
> > On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote:
> > > What do you think ?
> > 
> > All great features, but you should look at
> > http://techbase.kde.org/Projects/Plasma/ScreenManagement
> 
> Well, that's almost exactly what I had in mind :-)
> 
> > http://aike.me/site/blog/20090407/multihead_in_kde_422
> 
> This is more like a bug fixes list. But I see the idea of improving
> multihead management is at least 1 year old.

That was Aike (the previous GSoC student)'s introduction.

> > http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/
> 
> I'll have a look at it, but it seems to be exactly what I wanted to do.

It doesn't _do_ everything it claims to do though.
 
> > http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/
> 
> So you think another plasma widget than the device notifier should be used
> for monitors ? Is the Device Notifier widget only for mass storage devices
> ?

I didn't say anything, just pointing out Aike's prototype UI plasmoid.  I 
think these events should be displayed using Device Notifier.
 
> > This was already the subject of a GSoC project in 2008, which was
> > successful but stopped short of applying policies to restore previous
> > configuration, doing KNotifications or events or providing UI to edit
> > configurations.
> > 
> > KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some
> > SUSE patches to launch an improved version of the KRandR KCM, and does
> > not use Kephal.
> 
> But couldn't KRandR use Kephal eventually ?

Yes.

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Friday 02 April 2010 00:09:01 Björn Ruberg wrote:
> > I have to check the difference between "Monitor", "Screen", "Display" and
> > "Head" or are those actually the same thing ?
> 
> "Monitor", "Display" and "Head" are probably the same - in Kephal they are
> named as "Output". "Screen" ist actually something different. A screen can
> have several outputs ordered left to right. If you have two monitors with
> 1600x1200 pixels beside each other, you have a screen of 3200x1200 pixels
> and two outputs in it. One at position 0x0 and one at 1600x0.

Aike, could you shed some light on this question?  Or Aaron, if you have the 
overview of how Kephal works from mentoring Aike?

Björn's description matches the xrandr model, but not the Kephal one.  Xrandr 
1.3 has a single Screen numbered 0 but does not support additional Screens; 
xrandr Screens are distinct from the screennumber in X's $DISPLAY, and 
multiple Screen support is being discussed again for xrandr 1.4 according to 
one of our local Xorg guys.

Kephal has both multiple Outputs and multiple Screens in its model.  A screen 
owns zero or more Outputs, But it also seems that one Screen per output is 
created, looking at the usage of Kephal in KRunner, Plasma and KWin, which 
iterate, because they iterate the screens, react to screen added/removed 
signals, and use screen ids for panel and popup placement.  If this is the 
case I'm not sure why there are both Screens and Outputs.   Perhaps it's 
future-proofing for when xrandr supports multiple Screens.  But if that is 
true, I don't know why Plasma and KWin react to Screen changes but not Output 
changes.

Will


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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Thursday 01 April 2010 20:07:14 Chani wrote:
> On April 1, 2010 09:40:12 Björn Ruberg wrote:
> > Hello,
> > 
> > I fully agree with Detlev's points. The multiscreen management is very
> > bad in KDE currently, although in KDE 4.4 it is a little better than in
> > KDE 4.3. Every time I want to plug a beamer to my laptop in university I
> > have to fight up to one minute getting every thing correct
> 
> I have *very* little experience with multiscreen, but... how much of this
> is a distro or driver thing? 

Distro/driver is not important; the multiscreen features discussed above are 
simply missing even with a perfect driver/distro combination.

> when I plugged my tv into my laptop running
> arch, the video seemed to Just Work - I opened up krandr, set the new
> screen to the first resolution and there it was. later I thought maybe I
> wanted the other screen on top, so I tried that, and it worked too.
> 
> when I tried the netbook reference thing, though, it didn't really want to
> obey the settings I chose. it just wanted to clone the laptop screen onto
> the tv screen. weird stuff happened as I fought with it... :/
> 
> I'm not saying multiscreen is in a *good* state, just that I had two very
> different experiences on different distros.

The intel driver can cause this behaviour, since contemporary releases of 
different distros ship different X servers *and* different intel drivers, and 
intel's feature set varies from release to release.  The intel driver in the 
openSUSE 11.2 build of Plasma Netbook Reference Platform is especially bad at 
detecting the correct native monitor resolution from the EDID.

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

Re: GSoC : Multiscreen management

[Will Stephenson]

On Thursday 01 April 2010 16:35:59 Detlev Casanova wrote:
> I'd like to work with you this summer (and even longer after that :-) ).
> So, there's something in KDE that I find not really nice, It's the
> multiscreen management.
> For instance, I have an extra monitor for my laptop which I use every day
> but I also unplug it every day. The problem is that the screen
> configuration is never kept and sometimes, the screen is deactivated and
> KRandr says the screen is configured in 1980x1200...
> 
> So, my point is : there are problems.
> So far, what's the link with plasma you might ask. Well, I'd like the
> device notifier to react when a monitor is plugged in, showing the screen.
> 2 actions should be possible : Auto configure and manual configuration.
>  -> Auto configure would try to find the best configuration depending on
> the screen capabilities (read resolutions).
>  -> Manual configuration would open KRandr.
> 
> In KRandr, there should be a possibility to keep configurations depending
> on the plugged device :
>   I'd like the university projector to be on the right of my laptop 
> screen.
>   I'd like my 26" screen to be a clone of my laptop screen.
> 
> If a configuration exists for a monitor when it's plugged in, the
> configuration should directly be applied with the monitor entry still in
> the device notifier (so that it can be modified).
> 
> KRandr could also be more handy : the view could be used to move screens to
> place them at the wanted position (like a widget is moved on the desktop).
> 
> What do you think ?

All great features, but you should look at  
http://techbase.kde.org/Projects/Plasma/ScreenManagement
http://aike.me/site/blog/20090407/multihead_in_kde_422
http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/kephal/
http://websvn.kde.org/trunk/playground/base/plasma/screenmanagement/

This was already the subject of a GSoC project in 2008, which was successful 
but stopped short of applying policies to restore previous configuration, 
doing KNotifications or events or providing UI to edit configurations.

KRandR is a separate codebase which Lubos Lunak updated for 4.4 with some SUSE 
patches to launch an improved version of the KRandR KCM, and does not use 
Kephal.

I feel the same itch as you do and have spent the last couple of days getting 
into the Kephal code - it's been hardly touched since 2008 and could do with a 
clean up, so I'll see how far I get with it over the weekend.  

Aaron, do you think there's another GSoC project in completing Kephal?

> I already posted the idea on #plasma but had to leave before you could
> answer so, it might feel familiar.
> 
> I know though that there are problems with xrandr and some drivers, like
> the NVidia driver. I'm not sure how big are the problems but interfacing
> with the NVidia tools is maybe possible.

I know the disper tool tries to abstract both systems, but haven't used it.

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

Re: XML layouts for onscreen keyboard

[Will Stephenson]

On Sunday 21 March 2010 17:12:25 Björn Ruberg wrote:
> I'm reworking the onscreen keyboard we already have in 4.4. One of the big
> improvements is that I want to come away from hard coded key layouts and
> use something (user-) configuerable. So it would be very easy to add a
> layout for mobile phones - currently its aimed at bigger tablets.
> 
> So I want to use xml files for storing the layouts in it. This is only
> partially about localisation, because that is done mainly by the X-server.
> Main goal is to have different or customized layouts for different usages.
> 
> I want to use a XML file similar like matchbox-keyboard uses:
> http://wiki.openmoko.org/wiki/Change_keyboard_layout
> 
> My questions are:
> - What c++ library should I use for reading in the xml-file?

Qt: http://doc.trolltech.com/4.6/xml-processing.html

> - How can I get a xml file to be installed by cmake?

install( FILES file1.xml file2.xml DESTINATION  
${DATA_INSTALL_DIR}/yourappname )

> - And where should it be installed to?

the above installs in $PREFIX/share/apps/yourappname where KStandardDirs can 
find it.

For this kind of question you'll get a lot more help on kde-de...@kde.org.

HTH

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

Re: netbook reference, the polishing details

[Will Stephenson]

On Friday 19 March 2010 19:49:32 Marco Martin wrote:
> so when the netbook ui starts send quit to krunner, hmm, this should be
> done  all the times...
> there should probably be a global configuration switch that would be hitted
> by  the workspace config module.
> and herewe go in one of my pet annoyances about how the things work now:
> we need something prettier to manage this wanted difference of behaviour
> in  applications when we are in netbook mode, right now we have:
> -main plasma shell, start another one ;p
> -kwin: maximize windows by default, don't show iconify button and another 
> thing i would like, use a regular grid for the present windows effect, with
> a  small screen with windows all of the same size makes way more sense
> -and now don't start krunner
> 
> i'm seeing possibly other apps that would want a different space saving
> setup  in this case?
> 
> i can continue changing their config files under their feet in the
> workspace  kcm like now but kinda feels wrong(tm) to me :/

As a sanity check, is switching between netbook and desktop workspaces a use 
case that is important enough to spend effort on it?

A) Netbook users who just want one interface that works well.

B) Netbook users who want to use p-d with an external monitor

C) Netbook users who primarily use p-n but are curious about p-d

D) Developers and testers who sometimes use p-n on non-netbook machines 

At a guess the first group is the largest and the later groups are much 
smaller.

Will


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

Re: Workaround in WebView...

[Will Stephenson]

On Monday 22 March 2010 10:37:08 Marco Martin wrote:
> On Monday 22 March 2010, Alexis Ménard wrote:
> > Hello,
> > 
> > 
> > May i know where was the crash? Because i'm sure the workaround is not
> > needed anymore...
> > 
> > QVariant WebView::itemChange(GraphicsItemChange change, const QVariant
> > &value) {
> > 
> > if (change == QGraphicsItem::ItemSceneHasChanged) {
> > 
> > //FIXME: QWebPage _requires_ a QWidget view to not crash in
> > 
> > places such as
> > 
> > // WebCore::PopupMenu::show() due to
> > 
> > hostWindow()->platformPageClient() == NULL
> > 
> > // because QWebPage::d->client is NULL
> > d->webView->page()->setView(viewFor(this));
> > 
> > }
> > return QGraphicsWidget::itemChange(change, value);
> > 
> > }
> > 
> > Thank you
> 
> iirc the crash was opening a combobox in a webpage.
> right now this workaround causes many other crashes with a quite random
> behaviour, and one for which Amarok is being beaten quite a lot lately:
> https://bugs.kde.org/show_bug.cgi?id=227639

And you'll notice that Amarok just workarounded this bug by delaying the 
QWebView instantiation from the applet ctor to the applet's init() function, 
which I presume is then after the 'QWidget view' is setup.

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

Re: KDE's Plasma: How not to do lists...

[Will Stephenson]

On Wednesday 17 March 2010 14:14:17 Sebastian Kügler wrote:
> By the way, just strikes me that I've implemented VPN support in the new
> Network Manager Plasmoid last week, and I've already some reports that it
> seems to work well. What kind of VPN are you using?

You know that anything you can do in the plasmoid won't make a hair of 
difference to the business end of how the VPN connections appear on the bus to 
NetworkManager and whether or not they work.

As Reinhold is already using knetworkmanager and is taking a critical user's 
stance in his blogs, telling him about a new UI that is not yet production 
ready and doesn't resolve the underlying issue is not likely impress him, 
whereas as a hacker he might be distracted by the new shiny.  

Let's get on with fixing things.

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

Re: Netbook Reference

[Will Stephenson]

On Friday 12 March 2010 22:15:17 Christophe Olinger wrote:
> Putting the image on a stick instructions done.
> 
> Please check the source link to get the image. I was forwarded to the
> opensuse build service where I needed a login. Is this wanted?

I've changed that link to the download.opensuse.org link which is a mirror and 
does not require a login.  Users only need an OBS login to start changing 
things.  Note that the main KDE:Netbook project has a short list of 
developers; new contributors should use the branch and submit request method 
of contributing their changes for review.

Will


> Cheers.
> 
> Christophe
> 
> On Fri, Mar 12, 2010 at 9:27 PM, Aaron J. Seigo  wrote:
> > On March 12, 2010, Will Stephenson wrote:
> >> I've fixed the branding (all upstream now), the keymap question on boot
> >> and
> > 
> > .. awesome progress :)
> > 
> > i've started this page on community.kde.org:
> > 
> >http://community.kde.org/Plasma_Netbook_Reference_Platform
> > 
> > it's very skeletal right now. we should document as much of the "what's
> > going on, how to get involved" here as possible. eventually we'll link
> > to this page from an appropriate place in plasma.kde.org.
> > 
> > Will: could you help with documenting how to do the build service bits?
> > 
> > Christoph: could you add something there about the process to get it onto
> > a USB stick?
> > 
> > everyone else should also feel free to add to and improve that page :)
> > 
> > --
> > Aaron J. Seigo
> > humru othro a kohnu se
> > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
> > 
> > KDE core developer sponsored by Qt Development Frameworks
> > ___
> > Plasma-devel mailing list
> > Plasma-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> 
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Netbook Reference

[Will Stephenson]

On Friday 12 March 2010 21:27:19 Aaron J. Seigo wrote:
> Will: could you help with documenting how to do the build service bits?

I'd already done this here:

http://techbase.kde.org/Projects/Plasma/NetbookReference

I have copied it into community.k.o now.

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

Re: Netbook Reference

[Will Stephenson]

On Friday 12 March 2010 13:58:32 Marco Martin wrote:
> > * At 1024x768 the activities bar is so wide that the part of the panel
> > with the window title/close plasmoid is off the right edge of the screen
> 
> it's something that appears to happen only on the first start (and being a 
> live cd is always the frst start)
> have to indagate about this

It's not a Live CD, it's a disk image - changes are persistent.  And you're 
right, it goes away after logout/login.

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

Netbook Reference

[Will Stephenson]

I've fixed the branding (all upstream now), the keymap question on boot and 
the low disk space notification popup on login.  

I have a problem with wireless (iwl3945) that the module needs to be removed 
and reinserted before wireless works.  Not sure why this happens, the vanilla 
image does not have this problem.

Other plasma-netbook specific things I noticed: 
* The fullscreen dialog from the opendesktop.org plasmoid is still there and 
annoying.
* At 1024x768 the activities bar is so wide that the part of the panel with 
the window title/close plasmoid is off the right edge of the screen
* I need to package and include an up to date Network Management plasmoid.

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

minutes of IRC meeting for 4.5 coordination

[Will Stephenson]

Are at 

http://techbase.kde.org/Projects/Plasma/20100306

and referenced from Projects/Plasma

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

Re: Manual Hiding of Plasma Panel (desktop shell)

[Will Stephenson]

On Friday 05 March 2010 21:09:17 Emdek wrote:
> But having DBus call for that purpose isn't something wrong, I think.
> And how it can be used is different story.

If you do this, it should be in a structured way, so that we get a proper tree 
of Plasma objects with access to their properties eg

$ qdbus org.kde.plasma-desktop

/
/Plasma/
/Plasma/Containments
/Plasma/Containments/0
/Plasma/Containments/0/Applets
/Plasma/Containments/0/Applets/0
/Plasma/Containments/1/Applets
/Plasma/Corona
...

And there somewhere on the org.kde.Plasma.Panel interface exposed by 
/Plasma/Containments/0 you would have the setVisible(bool) method that you're 
asking for.  

Wouldn't that be a nice GSoC project?

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

Re: Strange ampersand in Plasma tooltips

[Will Stephenson]

On Monday 01 March 2010 08:32:55 Mark Kretschmann wrote:
> I'm having a weird issue here, and I wonder if it's just me, or if
> it's maybe a bug in Plasma:
> 
> Many of the tooltips of the Plasma::IconWidget buttons we use in
> Amarok (like in the toolbar and in applets) contain weird ampersand
> characters, that is "&". I assume they come from keyboard shortcuts,
> but surely they shouldn't be shown in the tooltip, no?
> 
> I've asked about this in the #plasma IRC channel before, but noone had
> an idea. Do you have any? :)

What KUIT tags are you using in the i18n'ed strings? Some @info KUIT markup 
adds rich text for use in actions which looks weird in a widget not expecting 
it.

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

Re: TokamakIV update

[Will Stephenson]

On Wednesday 03 February 2010 23:22:20 Lukas Appelhans wrote:
> PS: Will, do you take care of having a development computer for me? Thanks!
> :)

Sorry, I just saw this.

I'm sure we can find you something - do you want openSUSE 11.2 on it or will I 
just leave it to you to install?

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

Re: About pastebin applet

[Will Stephenson]

On Thursday 28 Jan 2010 17:41:09 Artur Souza (MoRpHeUz) wrote:
> So, what do you think ? Pastebin turns into "Share It!" with a better
> architecture.

I dream of a desktop where these kinds of sharing are all accessible in the 
same way:

Sources:
local files
clipboard
URLs

Destinations:
Paste into widgets
Online paste/image/file bins
Online galleries (flickr/picasa/...)
Contacts (mail attachment, IM file xfer, bluetooth obex, zeroconf file xfer eg 
kepas[1])
'Facebook Wall' (for URLs), digg

On the face of it you would need a list of mimetypes that each destination 
would accept, config UI for destinations requiring registration, and a UI 
plugin to provide additional metadata needed (eg user name for *bins, url 
comment text for facebook wall, image title for galleries.  For the 
heavyweight media like email and IM I assume the plugin would just call KMail 
or Kopete and tell them to open a message composer or file transfer window 
primed with the content to send, and let them use their existing UI to select 
the contact to send it to (I implemented the Send To->Contact function in KDE 
3's kuick konqueror plugin and it was always a bit slow to fetch the list of 
online contacts in a slot connected to the context menu's aboutToShow() 
signal).

You could then use this Share it! broker in a plasma drop widget, Klipper and 
Copy To... in file managers.

So while you're rethinking things, go for the biggest picture, it's the KDE 
way! 

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

Re: documenting javascript DataEgine and Runners

[Will Stephenson]

On Monday 01 Feb 2010 17:35:24 Aaron J. Seigo wrote:
> On January 31, 2010, Will Stephenson wrote:
> > Speaking of this, was there a JS API change between 4.4 and trunk?
> 
> there shouldn't be; they should be identical. the idea is to keep strict 
> compat in the JS API from 4.4.0 onward.
> 
> > Specifically, the plasmoid.dataEngine() method appears to have moved from
> > a global variable in 4.4 to a member of plasmoid.
> 
> i don't think that's changed at all, actually. the code is identical in
> both  4.4 and 4.5. i just tested with trunk and dataEngine is still,
> indeed, a global function.
> 
> i think that plasmoid.dataEngine would actually be better and more
> consistent,  but i'm not sure it's worth breaking whatever JS plasmoids
> exist prior to 4.4. there are already published JS plasmoids using the
> top-level method and while it is a wart it's a smallish one and probably
> not worth changing.

Ok, plasmoid.dataEngine() is used in 
 http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/DataEngine
- is that just wrong?

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

Re: documenting javascript DataEgine and Runners

[Will Stephenson]

On Thursday 21 Jan 2010 00:29:36 Aaron J. Seigo wrote:
> i've got my hands pretty full right now with documenting the JavaScript
> Plasmoid API:
> 
> http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API

Speaking of this, was there a JS API change between 4.4 and trunk?  
Specifically, the plasmoid.dataEngine() method appears to have moved from a 
global variable in 4.4 to a member of plasmoid.  

Also debug()  is a top level function but plasmoid.print() is not - 
http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API#Print_and_Debug
 
describes them both as top level.

Is the JS API supposed to be fixed as of 4.4?

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

T4: Local stuff

[Will Stephenson]

Hi all

Some things to think about:

Open Tokamak:
We talked about this a bit yesterday on irc, can we do this on Monday 
afternoon/evening so that SUSE staff can be there, and external people can 
attend talks after they finish work?

Infrastructure:
We have a camera/mic setup here to record talks and of course projectors to 
give them.

We also have a usability lab (split screen testing workstation and eye 
tracker).  Would you be interested in making use of this?  Or would it be a 
distraction from hacking?  Usability work usually involves external test 
subjects.

Since Marco is taking care of the small screen devices, I'll point out that 
there is a large flat screen display in the rooms that could be used for the 
'10 foot' media device Plasma interfaces.

Socials: 
We (openSUSE) are going to sponsor a dinner.  I couldn't get veggie friendly 
food for 25 organised during the first weekend due to the organic trade fair 
that is in town at the same time so it is on Tuesday 23rd Feb.   

On the Saturday night I suggest we go to a large thai buffet place, it is in 
the same block as the SUSE building and meets our dietary requirements.

The Guest House accommodation for the Friday and Saturday nights is out of 
town (couldn't be helped) so it would help us to have an idea where everyone 
will be on Friday afternoon/evening.  I have the event space at SUSE booked 
from Friday so you can use that as you arrive, and either come straight there 
and check in at the Guest House later or drop off your stuff and then come 
into town.  There is a regular bus service, takes about 25 minutes, I'll put 
details on the wiki, or a taxi would cost about 10 euro.

At Nightrose's instigation I have added a late KDE 4.4 Release Party/End of 
Tokamak night to the list for the Thursday night in a local bar.   Of course 
there are lots of other social options for the rest of the week.

If you have any other needs or questions, just ask.

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

Re: t4 wiki page

[Will Stephenson]

On Thursday 31 December 2009 13:07:25 Will Stephenson wrote:
> On Wednesday 30 December 2009 13:39:14 you wrote:
> > We also need a quote from the hotel, so please also make sure you've
> > filled in when you will be there. Will, there's a convenient hotel option
> > I recall?
> 
> The cheapest option will be the youth hostel (5 mins away) which is 23 or
>  22 euro/night + hostelling membership which for the german organisation is
>  12 eur (<26 years old) or 21 eur if older.
> 
> http://www.jugendherberge.de/jh/bayern/nuernberg/preise/03878.shtml.en
> 
> The Eurohotel (also 5 minutes away) is quoting me 92 eur/night but I can
>  see about a group discount
> when I'm back in nuernberg.
> 
> http://www.azimuthotels.de/page.asp?id=142
> 
> http://www.jugendherberge.de/jh/bayern/nuernberg/preise/03878.shtml.en
> 
> There are the usual discount hotel chains for about 60 eur/night but which
>  are a 10-15 minute walk away, and there are many budget non-chain hotels
>  around in the 35-50 eur/night range depending on how many to a room.
> 
> eg www.smilehotel.de (the former SUSE default hotel, but not convenient for
> the current office - there must be similar places nearer).

I have contacted a few places and many rooms are already booked out due to a 
trade fair in the city on the nights of the 19th and 20th, so please confirm 
the dates you will attend as soon as possible so I can book what is available.

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

Re: t4 wiki page

[Will Stephenson]

On Wednesday 30 December 2009 13:39:14 you wrote:
> On Wednesday 30 December 2009 08:18:32 Aaron J. Seigo wrote:
> >   On December 29, 2009, Chani wrote:
> > > aaron, do we need more of those filled in or can we email the board
> > > now?
> > > 
> > > :)
> > 
> > the board should be emailed; i wasn't aware that i was coordinating this,
> > however. if i am, i'll get right on it, however. sebas?
> 
> I can do it as well. (Having a slow couple of days, but was actually
> planning to.)
> 
> If those with incomplete information (or that aren't on the Wiki yet) could
> fill it in, in particular the expected travel cost column, we can start
> raising funds.
> 
> We also need a quote from the hotel, so please also make sure you've filled
> in when you will be there. Will, there's a convenient hotel option I
> recall?

The cheapest option will be the youth hostel (5 mins away) which is 23 or 22 
euro/night + hostelling membership which for the german organisation is 12 eur 
(<26 years old) or 21 eur if older.

http://www.jugendherberge.de/jh/bayern/nuernberg/preise/03878.shtml.en

The Eurohotel (also 5 minutes away) is quoting me 92 eur/night but I can see 
about a group discount 
when I'm back in nuernberg.

http://www.azimuthotels.de/page.asp?id=142

http://www.jugendherberge.de/jh/bayern/nuernberg/preise/03878.shtml.en

There are the usual discount hotel chains for about 60 eur/night but which are 
a 10-15 minute walk away, and there are many budget non-chain hotels around in 
the 35-50 eur/night range depending on how many to a room.  

eg www.smilehotel.de (the former SUSE default hotel, but not convenient for 
the current office - there must be similar places nearer).

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

Re: t4 wiki page

[Will Stephenson]

On Wednesday 25 November 2009 19:46:05 Aaron J. Seigo wrote:
> i know it's a few months off, but as more and more people become interested
>  in this crazy thing called "plasma" ;) i had a need for a wiki page to
>  point people at for T4. behold:
> 
>   http://techbase.kde.org/Projects/Plasma/Tokamak4
> 
> it's skeletal at the moment, but we can start filling it in. if you are
>  going to be attending, please add yourself sooner rather than later.

Also as the local organizer, please let me know if you have any odd 
requirements.  The usual KDE meeting reqts of bandwidth, cheap veggie eats and 
places to sleep are already on my list.

> if we are lucky, we'll have devices with Nokia and Intel provenance there
>  for us to hack on/with. so for the mobile interested among us, it could be
>  quite a fun meeting.

Are any usability-interested people thinking of coming?   The Usability Lab 
has been placed at Plasma's disposal by a certain entepreneur from Boston, 
consisting of an eye tracking workstation and a multiple-camera user 
observation setup so we could do some research as well as hacking.

I was at a usability symposium last night, the local uni has a research group 
who would be very interested to see how Plasma does usability in practice.

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

Re: Network Management Plasmoid TODOs

[Will Stephenson]

On Monday 09 November 2009 21:32:30 Aaron J. Seigo wrote:
> On November 9, 2009, Petri Damstén wrote:
> > On Monday 09 November 2009 15:06:40 Sebastian Kügler wrote:
> > > Note that I can't test VPN or mobile broadband stuff. If nobody can do
> > >  that, we should disable it before the release.
> >
> > It would be nice if there could be a simpler configuration dialog shown
> >  first on add like:
> 
> imho, it would be nice if it didn't pop up a second dialog at all and just
>  ask for the username and pasword right inside the nm applet itself; the
>  "advanced" settings could pop up a dialog perhaps, but there is a lot of
>  room in that new dialog for a simple "put in your username, password"
>  interface with a couple of buttons.

This will only work for WPA-PSK wireless connections though, for EAP, cellular 
and VPN connections there are just too many mandatory settings to show even a 
simplified view in the popup.  Do you want to introduce a second interaction 
path just for a different type of wifi connection?

Providing secrets in-popup also requires changing the separation between the 
config UI and the control UIs.  Right now the control UIs have no way to 
modify connections at all.  We'd need a way for the control UI to tell the 
backend to create a default-configured connection for a given SSID (or 
cellular device, or whatever), activate it, receive the resulting GetSecrets 
call from NM and forward that to the control UI, get secrets, then pass the 
secrets back to NM.

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

Re: Network Management Plasmoid TODOs

[Will Stephenson]

On Monday 09 November 2009 15:36:17 Sebastian Kügler wrote:
> On Monday 09 November 2009 14:20:26 Will Stephenson wrote:
> > On Monday 09 November 2009 14:06:40 Sebastian Kügler wrote:
> > > > * Make main interface (not popup) able to show connecting, connected,
> > > > VPN active states
> 
> I'd do it as follows:
> 
> - we have a progress bar sitting in the bottom (horizontal, seems visually
>  more like a progress bar). That ones laid over the icon dynamically. This
>  progress bar is used for connecting *any* connection. (For wireless you'll
>  see it while
> 
> - an overlay icon, possibly top-right, half-width and height of the
>  "parent" icon: - it shows a checkmark for a couple of seconds after
>  connections are established - it shows a permanent overlay (on top of the
>  hardware icon) for connected VPNs - it shows a "(!)" when user interaction
>  is required (for example a password dialog waits to be filled in)
> 
> We'll have to see how much visual clutter this adds, though. In
>  knetworkmanager, you have something similar (progress bar + overlay icon),
>  I think that's OK visually, but "normally" I'd like to hide the progress
>  bar.

Can we come up with one design for these extra info overlays in the mails 
we're exchanging with ademmer and pinheiro that we can use in both KNM and the 
applet?

 
> > > Which main interface are you talking about?
> >
> > What's the proper name for the plasmoid as it appears in a containment in
> >  non- popped-up state?  That interface.
> 
> Let's call it "panel view" (yeah, just made that up). :)
> 
> > > > * A plasma-esque way to show the list of all wireless networks (not
> > > > in the main popup, so this doesn't explode out of the screen).
> > > > KNetworkManager uses a regular KDialog for this
> > >
> > > Again, what exactly do you mean?
> >
> > I mean 'do what KNetworkManager does' and don't fill the popup with
> > unconfigured wireless networks that we are not interested in most of the
> >  time and just add noise.
> 
> I'll have a look at how knetworkmanager does it. Maybe some sort of toggle
>  for the list of activatables for showing or hiding those unconfigured
>  networks, possibly with some magic in the background (i.e. toggle to "show
>  all" when there's no preconfigured network found).
> 
> > Instead show configured wireless networks (WirelessInterfaceConnections)
> > in the popup, and show other WirelessNetworks and all
> > HiddenWirelessNetworks (so that people can connect to their configured
> > hidden networks in a second level dialog.
> 
> We should sort the "known" ones on top (note: need an icon for that, right
>  now using the bookmarks one since that's semantically closest to "known
>  network").

IF you show unconfigured networks in the popup you should have 2 things
* scrollview instead of expanding the popup
* a searchline for use in densely populated areas

> > > > * (Optional) icon per interface support
> >
> > Is this off the table for 4.4?
> 
> I'd say no, though not a priority right now. It shouldn't be very hard to
>  do now.

I would try to plan for this now by having a list of interface UNIs that the 
popup knows about to display info for

> > > > * The service needs either properly kded-modulizing or splitting out
> > > > into a separate process like kwalletd
> > > >
> > > > I'm sure we'll come up more in the meeting starting NOW in #plasma
> > >
> > > Over the weekend, I've done the following:
> > >
> > > - removed SVGs, use KIcon all over
> > > - fix up tooltips and interface item's title
> > > - less code duplication, new class UiUtils (in libs/ui now)
> > >
> > > Next to tackle:
> > > 1 connection progress in the panel icon
> > > 2 buglet in sorting connection list, an interface that is connecting
> > > should be more important than an inactive one
> > > 3 layouting bug where the activatablelist overflows its scrollwidget
> > > (looks like a parenting problem)
> > > 4 I'm asked more than once for the connection's password, I think
> > >  knetworkmanager has the same problem
> >
> > When exactly?  The known 'bug' is that since knetworkmanager, and the
> > KCM, are distinct apps, KWallet policy has to be set independently on
> > those, so you get one KWallet dialog when first creating a connection,
> > and another one when knetworkmanager (or the kded module, for the
> > plasmoid) tries to open the wallet to provide NM with the password.
> 
> After creating the account, it's trying to connect and then immediately it
>  brings up the password dialog again (with password now filled in).
> 
> It's not a kwallet dialog.

Ok then NM is re-issuing GetSecrets when you try to collect, look at the NM 
logs to see why it might be doing this.

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

Re: Network Management Plasmoid TODOs

[Will Stephenson]

On Monday 09 November 2009 14:34:11 Petri Damstén wrote:
> On Monday 09 November 2009 15:06:40 Sebastian Kügler wrote:
> > Note that I can't test VPN or mobile broadband stuff. If nobody can do
> >  that, we should disable it before the release.
> 
> It would be nice if there could be a simpler configuration dialog shown
>  first on add like:
> 
> Add wireless:
> 
>  Network: [ Strongest net   v]
> Password: [  ]
>  [Advanced...]
> 
> Add mobile:
> 
>  Country: [ From geolocation?  v]
> Operator: [v]
> [Advanced...]
> 
> nm-applet has country/operator selection for mobile and it's pretty useful.

These are both on the TODO list already.

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

Re: Network Management Plasmoid TODOs

[Will Stephenson]

On Monday 09 November 2009 14:06:40 Sebastian Kügler wrote:
> Status update...
> 
> On Friday 06 November 2009 19:00:54 Will Stephenson wrote:
> > Off the top of my head:
> >
> > * Check that RemoteVpnConnectionitem and
> > RemoteHiddenWirelessNetworkConnectionitem are complete (service side)
> > * Implement these including Disconnect button
> > * Design the Plasma side graphicsitem family for minimum code duplication
> > * Tooltips
> 
> Should both be OK, modulo some smallish fixes that will creep in.
> 
> > * Make main interface (not popup) able to show connecting, connected, VPN
> > active states
> 
> Which main interface are you talking about?

What's the proper name for the plasmoid as it appears in a containment in non-
popped-up state?  That interface.

> > * A plasma-esque way to show the list of all wireless networks (not in
> > the main popup, so this doesn't explode out of the screen).
> > KNetworkManager uses a regular KDialog for this
> 
> Again, what exactly do you mean?

I mean 'do what KNetworkManager does' and don't fill the popup with 
unconfigured wireless networks that we are not interested in most of the time 
and just add noise.

Instead show configured wireless networks (WirelessInterfaceConnections) in 
the popup, and show other WirelessNetworks and all HiddenWirelessNetworks (so 
that people can connect to their configured hidden networks in a second level 
dialog.

> > * (Optional) icon per interface support

Is this off the table for 4.4?

> > * The service needs either properly kded-modulizing or splitting out into
> > a separate process like kwalletd
> >
> > I'm sure we'll come up more in the meeting starting NOW in #plasma
> 
> Over the weekend, I've done the following:
> 
> - removed SVGs, use KIcon all over
> - fix up tooltips and interface item's title
> - less code duplication, new class UiUtils (in libs/ui now)
> 
> Next to tackle:
> 1 connection progress in the panel icon
> 2 buglet in sorting connection list, an interface that is connecting should
>  be more important than an inactive one
> 3 layouting bug where the activatablelist overflows its scrollwidget (looks
>  like a parenting problem)
> 4 I'm asked more than once for the connection's password, I think
>  knetworkmanager has the same problem

When exactly?  The known 'bug' is that since knetworkmanager, and the KCM, are 
distinct apps, KWallet policy has to be set independently on those, so you get 
one KWallet dialog when first creating a connection, and another one when 
knetworkmanager (or the kded module, for the plasmoid) tries to open the 
wallet to provide NM with the password.

> I'd appreciate if someone could look into the latter two (3 and 4), I've
>  been banging my head against the layoutwall enough already.
> 
> Note that I can't test VPN or mobile broadband stuff. If nobody can do
>  that, we should disable it before the release.

I can test those.  The main things to do for those are make sure there is a 
disconnect button shown when they are connected (doesn't need hardware or a 
VPN login) and check that the 'main UI' (as defined above) shows the right 
icon when those are active (needs hardware or a VPN login).

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

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

> On 2009-11-03 17:31:01, Will Stephenson wrote:
> > You could work out the "Current Conditions" and "Condition Icon" data on 
> > each update using the current system time and the UTC time in the forecast 
> > periods, and set these on the data source.  This would AFAICS get rid of 
> > the 'missing icon' icon and make the applet usable in panels.
> 
> Thilo-Alexander Ginkel wrote:
> I thought about that before, but found it rather weird to call an 
> interpolated value from the forecast a "current" weather condition. Of 
> course, it would be much more pleasing to the eye to have an icon to display. 
> An alternative would be to fix the weather applet to display no icon instead 
> of a broken one if no data is supplied for the current condition.
> 
> Shawn Starr wrote:
> I used dptrs because I didn't want to break the internal API, which is 
> public in a way. As more people use the backend changing things get more 
> risky. the dptrs are for the member data vs functions. But, if we don't need 
> the dptrs in the ions, we can get 'em out.
> 
> Aaron Seigo wrote:
> in classes which are linked to by the ion plugins (e.g. Ion), it makes 
> sense. for the ion plugins themselves it doesn't: those symbols aren't 
> exported or used by anything that needs binary compatibility in their 
> interfaces.

(Umm, threading, folks?)

Re Current Conditions - I see your point.  ATM on wetter.com the current 
weather is 'cloudy' here but both their morning and midday values are 'rainy' 
so an interpolation would be off.  Is it worth asking wetter.com to expose this 
too, since they obviously have it on the site.  If other providers do give this 
data directly, perhaps they will feel it's ok to.

However what icon should the applet use when it's in a panel with no Current 
Conditions data?  


- Will


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


On 2009-11-03 19:51:12, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-11-03 19:51:12)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: Q

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

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


You could work out the "Current Conditions" and "Condition Icon" data on each 
update using the current system time and the UTC time in the forecast periods, 
and set these on the data source.  This would AFAICS get rid of the 'missing 
icon' icon and make the applet usable in panels.

- Will


On 2009-11-01 18:31:18, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-11-01 18:31:18)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: QUrl::isValid() const (qurl.cpp:4124)
>by 0x5A23B5A: KUrl::_setEncodedUrl(QByteArray const&) (kurl.cpp:1538)
>by 0x5A23F19: KUrl::KUrl(QString const&) (kurl.cpp:411)
>by 0x1FAE37D6: WetterComIon::getForecast(QString const&) 
> (ion_wettercom.cpp:504)
>by 0x1FAE5BAA: WetterComIon::updateIonSource(QString const&) 
> (ion_wettercom.cpp:320)
>by 0x1F267CBE: IonInterface::sourceRequestEvent(QString const&) 
> (ion.cpp:47)
> 
> 176 (32 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss 
> record 882 of 1,156
>at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
>by 0x1F267795: IonInterface::IonInterface(QObject*, QList 
> const&) (ion.cpp:36)
>by 0x1FAE151D: WetterComIon::WetterComIon(QObject*, QList 
> const&) (ion_wettercom.cpp:68)
>by 0x1FAEE366: QObject* KPluginFactory::createInstance QObject>(QWidget*, QObject*, QList const&) (kpluginfactory.h:461)
>by 0x5B3367B: KPluginFactory::create(char const*, QWidget*, QObject*, 
> QList const&, QString const&) (kpluginfactory.cpp:191)
>by 0x5594EB5: Plasma::DataEngineManager::loadEngine(QString const&) 
> (kpluginfactory.h:515)
>by 0x1F6C813F: WeatherEngine::loadIon(QString const&) 
> (weatherengine.cpp:92)
>by 0x1F6C8C7C: WeatherEngine::sourceRequestEvent(QString const&) 
> (weatherengine.cpp:226)
>by 0x55913AC: Plasma::DataEnginePrivate::requestSource(QString const&, 
> bool*) (dataengine.cpp:670)
>by 0x5591421: Plasma::DataEngine::connectSource(QString const&, QObject*, 
> unsigned int, Plasma::IntervalAlignment) const (dataengine.cpp:89)
>by 0x1F05608D: WeatherPopupApplet::connectToEngine() 
> (weatherpopupapplet.cpp:234)
>by 0x1F05815E: WeatherPopupApplet::init() (weatherpopupapplet.cpp:223)
> 
> 
> Thanks,
> 
> Thilo-Alexander
> 
>

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

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

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



/trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp


By convention, public member variables of pimpl classes are not names with 
m_ prefixes - since accessing them via d-> in the outer class makes it obvious 
that they belong  to the pimpl


- Will


On 2009-11-01 18:31:18, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-11-01 18:31:18)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: QUrl::isValid() const (qurl.cpp:4124)
>by 0x5A23B5A: KUrl::_setEncodedUrl(QByteArray const&) (kurl.cpp:1538)
>by 0x5A23F19: KUrl::KUrl(QString const&) (kurl.cpp:411)
>by 0x1FAE37D6: WetterComIon::getForecast(QString const&) 
> (ion_wettercom.cpp:504)
>by 0x1FAE5BAA: WetterComIon::updateIonSource(QString const&) 
> (ion_wettercom.cpp:320)
>by 0x1F267CBE: IonInterface::sourceRequestEvent(QString const&) 
> (ion.cpp:47)
> 
> 176 (32 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss 
> record 882 of 1,156
>at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
>by 0x1F267795: IonInterface::IonInterface(QObject*, QList 
> const&) (ion.cpp:36)
>by 0x1FAE151D: WetterComIon::WetterComIon(QObject*, QList 
> const&) (ion_wettercom.cpp:68)
>by 0x1FAEE366: QObject* KPluginFactory::createInstance QObject>(QWidget*, QObject*, QList const&) (kpluginfactory.h:461)
>by 0x5B3367B: KPluginFactory::create(char const*, QWidget*, QObject*, 
> QList const&, QString const&) (kpluginfactory.cpp:191)
>by 0x5594EB5: Plasma::DataEngineManager::loadEngine(QString const&) 
> (kpluginfactory.h:515)
>by 0x1F6C813F: WeatherEngine::loadIon(QString const&) 
> (weatherengine.cpp:92)
>by 0x1F6C8C7C: WeatherEngine::sourceRequestEvent(QString const&) 
> (weatherengine.cpp:226)
>by 0x55913AC: Plasma::DataEnginePrivate::requestSource(QString const&, 
> bool*) (dataengine.cpp:670)
>by 0x5591421: Plasma::DataEngine::connectSource(QString const&, QObject*, 
> unsigned int, Plasma::IntervalAlignment) const (dataengine.cpp:89)
>by 0x1F05608D: WeatherPopupApplet::connectToEngine() 
> (weatherpopupapplet.cpp:234)
>by 0x1F05815E: WeatherPopupApplet::init() (weatherpopupapplet.cpp:223)
> 
> 
> Thanks,
> 
> Thilo-Alexander
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.k

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

> On 2009-11-01 08:46:19, Will Stephenson wrote:
> > I don't see a reason for the first leak you highlight in your code.  You 
> > should create the url using QLatin1String as this saves QString having to 
> > guess the encoding -see 
> > http://labs.trolltech.com/blogs/2008/04/28/string-theory/ for details.
> > 
> > The second leak is due to the main IonInterface (outside your code) leaking 
> > its d-pointer.  I can't see why it or your WetterComIon::Private need to be 
> > QObjects, when they don't do any QObject-type things, so I'd remove this 
> > unless I am wrong for some subtle reason.  I fixed this with r1043227 but 
> > you should probably also remove the QObject inheritance from your code.
> 
> Thilo-Alexander Ginkel wrote:
> Thanks for the info.
> 
> Regarding the QLatin1String: The wetter.com API requires the search term 
> to be passed as part of the URL, so I'd assume that using a QLatin1String for 
> that URL would break queries for non-western city names. Apart from that all 
> those QString usages make use of QString's .arg() method, for which 
> QLatin1String provides no replacement. I'd propose to use QString::fromLatin1 
> instead wherever possible, which should get rid of the necessity to guess the 
> encoding while preserving the flexibility of QString.
> 
> I have removed the QObject inheritance in my current working copy.
> 
> Aaron Seigo wrote:
> the Ions are QObjects primarily for memory management; since the Ion 
> plugins tend to have signal/slot connections they'd end up subclassing 
> QObject and so it just made sense to make Ion a QObject as well and use the 
> benefits inherent to that. also, if we ever make scripted Ions, having Ion as 
> a QObject makes it easier to bind.

We're talking the Ion's pimpl class here, not the Ion itself.


- Will


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


On 2009-11-01 18:31:18, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-11-01 18:31:18)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: QUrl::i

Re: Firefox Bookmark runner

[Will Stephenson]

On Monday 02 November 2009 15:53:24 Eduardo Robles Elvira wrote:
> BTW, I'm working on the new konqueror bookmarks system. I'm not sure
> if it will be finally in KDE 4.4 because it still needs some work. In
> this bookmarks system, bookmarks are going to be stored in Nepomuk.
> Hence, I have a patch for the Nepomuk search runner that modifies it
> to show the bookmarks results a bit better (patch available in
> http://github.com/edulix/gsoc/blob/master/kdebase-bookmarks.patch,
> take a look only at the workspace/plasma part of it). In case this new
> bookmarks system ships in, I don't know if mixing the firefox and
> konqueror bookmarks in nepomuk runner would be a good idea? What could
> be the best way in that case?

Possibly just watching the FF bookmarks file and copying them into Nepomuk. 
This is effectively what Zeitgeist does with web browsing history- it has its 
own metadata database but they are talking about merging it with Tracker.  Of 
course watching the file, copying and reading it is inefficient.  Maybe the 
best way is to do this directly in FF with a FF KDE helper, as we use for the 
FF KDE file dialog integration in openSUSE.

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

Re: Firefox Bookmark runner

[Will Stephenson]

On Sunday 01 November 2009 22:49:04 Eduardo Robles Elvira wrote:
> I have some questions about the runner. It seems to access to firefox
> places sqlite database. What happens if (much likely if you use this
> runner) firefox is running and thus also connected to the sqlite
> database, can't the database get corrupted? AFAIK sqlite does not run
> as external server process to which the applications can connect to,
> so both the runner and firefox would be accessing to the database at
> the same time, and that seems to ask for data corruption. I might be
> talking shit because I don't much about sqlite, so please enlighten
> me.

Zeitgeist (for gnome) work by accessing Firefox' sqlite databases, and does 
this apparently safely by taking a copy of the file before reading it.  No 
guarantee if this is right, I may be talking somebody else's shit too.

Will

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

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

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


I don't see a reason for the first leak you highlight in your code.  You should 
create the url using QLatin1String as this saves QString having to guess the 
encoding -see http://labs.trolltech.com/blogs/2008/04/28/string-theory/ for 
details.

The second leak is due to the main IonInterface (outside your code) leaking its 
d-pointer.  I can't see why it or your WetterComIon::Private need to be 
QObjects, when they don't do any QObject-type things, so I'd remove this unless 
I am wrong for some subtle reason.  I fixed this with r1043227 but you should 
probably also remove the QObject inheritance from your code.

- Will


On 2009-10-31 14:02:05, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-10-31 14:02:05)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: QUrl::isValid() const (qurl.cpp:4124)
>by 0x5A23B5A: KUrl::_setEncodedUrl(QByteArray const&) (kurl.cpp:1538)
>by 0x5A23F19: KUrl::KUrl(QString const&) (kurl.cpp:411)
>by 0x1FAE37D6: WetterComIon::getForecast(QString const&) 
> (ion_wettercom.cpp:504)
>by 0x1FAE5BAA: WetterComIon::updateIonSource(QString const&) 
> (ion_wettercom.cpp:320)
>by 0x1F267CBE: IonInterface::sourceRequestEvent(QString const&) 
> (ion.cpp:47)
> 
> 176 (32 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss 
> record 882 of 1,156
>at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
>by 0x1F267795: IonInterface::IonInterface(QObject*, QList 
> const&) (ion.cpp:36)
>by 0x1FAE151D: WetterComIon::WetterComIon(QObject*, QList 
> const&) (ion_wettercom.cpp:68)
>by 0x1FAEE366: QObject* KPluginFactory::createInstance QObject>(QWidget*, QObject*, QList const&) (kpluginfactory.h:461)
>by 0x5B3367B: KPluginFactory::create(char const*, QWidget*, QObject*, 
> QList const&, QString const&) (kpluginfactory.cpp:191)
>by 0x5594EB5: Plasma::DataEngineManager::loadEngine(QString const&) 
> (kpluginfactory.h:515)
>by 0x1F6C813F: WeatherEngine::loadIon(QString const&) 
> (weatherengine.cpp:92)
>by 0x1F6C8C7C: WeatherEngine::sourceRequestEvent(QString const&) 
> (weatherengine.cpp:226)
>by 0x55913AC: Plasma::DataEnginePrivate::requestSource(QString const&, 
> bool*) (dataengine.cpp:670)
>by 0x5591421: Plasma::DataEngine::connectSource(QString const&, QObject*, 
> unsigned int, Plasma::IntervalAlignment) const (dataengine.cpp:89)
>by

Re: Review Request: wetter.com Weather Ion

[Will Stephenson]

On 2009-10-31 18:48:39, Thilo-Alexander Ginkel wrote:
> > Oh, and personally I would use some kind of shared pointer for the 
> > WeatherData::Forecast[Period|INFO]* objects. But this is just something 
> > personal. I try to avoid memory I have to delete explicitly these days.

When I search for 'Nürnberg' with umlaut, I get a list of hits that does not 
include Nürnberg.  Then i close the hits, close the location dialog, reopen the 
location dialog, and it is set to 'Nürnberg, Bayern, DE'.  Expected behaviour - 
find the city in the hit list


- Will


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


On 2009-10-31 14:02:05, Thilo-Alexander Ginkel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> ---
> 
> (Updated 2009-10-31 14:02:05)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> ---
> 
> This change brings support for wetter.com (a weather forecast web site 
> especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API 
> supports forecasts for up to three days, so the Ion does not supply any 
> information about the current weather conditions. The forecast for the 
> current day is split between night and day whereas the following two days are 
> provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
> https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h 
> PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp 
> PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> ---
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy 
> warnings before the move to kdereview. Profiled it for memory leaks using 
> Valgrind, which did not bring up any leaks in the control of the Ion. Those 
> two still look somewhat suspicious, so I'd like to get your opinion about 
> them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>at 0x4C25153: malloc (vg_replace_malloc.c:195)
>by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, 
> QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const 
> (qurl.cpp:3781)
>by 0x61534FE: QUrl::isValid() const (qurl.cpp:4124)
>by 0x5A23B5A: KUrl::_setEncodedUrl(QByteArray const&) (kurl.cpp:1538)
>by 0x5A23F19: KUrl::KUrl(QString const&) (kurl.cpp:411)
>by 0x1FAE37D6: WetterComIon::getForecast(QString const&) 
> (ion_wettercom.cpp:504)
>by 0x1FAE5BAA: WetterComIon::updateIonSource(QString const&) 
> (ion_wettercom.cpp:320)
>by 0x1F267CBE: IonInterface::sourceRequestEvent(QString const&) 
> (ion.cpp:47)
> 
> 176 (32 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss 
> record 882 of 1,156
>at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
>by 0x1F267795: IonInterface::IonInterface(QObject*, QList 
> const&) (ion.cpp:36)
>by 0x1FAE151D: WetterComIon::WetterComIon(QObject*, QList 
> const&) (ion_wettercom.cpp:68)
>by 0x1FAEE366: QObject* KPluginFactory::createInstance QObject>(QWidget*, QObject*, QList const&) (kpluginfactory.h:461)
>by 0x5B3367B: KPluginFactory::create(char const*, QWidget*, QObject*, 
> QList const&, QString const&) (kpluginfactory.cpp:191)
>by 0x5594EB5: Plasma::DataEngineManager::loadEngine(QString const&) 
> (kpluginfactory.h:515)
>by 0x1F6C813F: WeatherEngine::loadIon(QString const&) 
> (weatherengine.cpp:92)
>by 0x1F6C8C7C: WeatherEngine::sourceRequestEvent(QString const&) 
> (weatherengine.cpp:226)
>by 0x55913AC: Plasma::DataEnginePrivate::requestSource(QString const&, 
> bool*) (dataengine.cpp:670)
>by 0x5591421: Plasma::DataEngine::connectSource(QString const&, QObject*, 
> unsigned int, Plasma::IntervalAlignment) const (dataengine.cpp:89)
>by 0x1F05608D: WeatherPopupApplet::connectToEngine() 
> (weatherpopupap

Re: Activities service in KDEreview

[Will Stephenson]

On Thursday 29 October 2009 10:41:01 Ivan Čukić wrote:
> > As I understand the code, current activity is globally modal?
> 
> Yes. Although plasma will be the main manager of activities, other
> applications can be as well.

That's interesting, but I am interested in the UI implications of having a 
single modal current activity.  That implies that exactly one activity is 
visible at one time - including in such exotic setups as second monitors.  How 
does your model handle that?

I have reviewed all the old "activity", "overview" and "nepomuk" threads on 
panel-devel@ but I couldn't find an answer - please point me if it was 
discussed already elsewhere.

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

Re: Activities service in KDEreview

[Will Stephenson]

On Wednesday 21 October 2009 21:46:39 Ivan Čukić wrote:
> After some time I spent "on the ice" due to problems with compiling Qt 4.6,
> I've finally been able to polish the activities service.
> 
> It is now in kdereview/nepomuk-activities-service

As I understand the code, current activity is globally modal? 

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

Review Request: reimplement adding application launcher submenus to panels and desktops

[Will Stephenson]

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

Review request for Plasma.


Summary
---

Make it possible to add Kickoff and simple-launcher submenus to panels and 
desktops.  

This works by storing the relative path and icon name of KServiceGroups (== 
submenus) in the application model used by the menu

When an 'Add to Panel/Desktop' context menu action is triggered, add a 
simplelauncher applet (instead of an Icon).

This receives the relative path of the submenu and the icon name in its args, 
and when it builds its menu, it walks the applications model and locates the 
submenu, rooting the menu at that index rather than the real root, and setting 
the icon for the launcher to that of the submenu.

When the applet is showing a submenu, the view types  and number of recent 
applications to shown are not shown in the config UI.

TODO: set tooltip to title of submenu instead of 'Application Launcher Menu'.


This addresses bug 189583.
https://bugs.kde.org/show_bug.cgi?id=189583


Diffs
-

  trunk/KDE/kdebase/workspace/plasma/applets/kickoff/ui/contextmenufactory.cpp 
1013494 
  
trunk/KDE/kdebase/workspace/plasma/applets/kickoff/simpleapplet/simpleapplet.cpp
 1013494 
  trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/applicationmodel.cpp 
1013494 
  trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/models.h 1013494 
  trunk/KDE/kdebase/workspace/plasma/applets/kickoff/simpleapplet/menuview.h 
1013494 
  trunk/KDE/kdebase/workspace/plasma/applets/kickoff/simpleapplet/menuview.cpp 
1013494 

Diff: http://reviewboard.kde.org/r/1389/diff


Testing
---

Add submenus

Add sub-submenus

Add as desktop icon

Add as panel icon

Quit and restart Plasma

Reconfigure application launchers
  Menu titles
  Description vs app name
  Icons


Thanks,

Will

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

Re: [Fwd: openSUSE Community Week / KDE]

[Will Stephenson]

On Monday 11 May 2009 17:03:56 Jeff Mitchell wrote:
> I met Joe (the openSUSE community manager) at LinuxFest Northwest a
> couple of weeks ago and he sent this to me...passing it on in case
> anyone is interested in hosting a session.
>
> --Jeff

I'm hosting a session right now actually in #opensuse-kde.

Marco is there, and please, if anyone else from the Plasma dev crowd would 
like to attend, you might pick up some useful feedback from the community

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

Re: Review Request: support brightness keys in the battery applet.

[Will Stephenson]

> On 2009-01-19 08:24:39, Sebastian Kügler wrote:
> > Thanks for having a look into it. (I've not tested it yet.)

Don't ship it!   
"
dannyK says your brightness keys patch will be problematic with most current 
machines, as they do brightness control in hardware. apparently there's a hal 
property you could check to find that out;
otherwise you are potentially causing a double increment on every keypress.

The hal property is to find out if the brightness keys control brightness in 
hardware already.  only then do you want to start doing that in software.
"


- Will


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.vidsolbach.de/r/335/#review328
---


On 2009-01-18 12:22:12, Matt Rogers wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.vidsolbach.de/r/335/
> ---
> 
> (Updated 2009-01-18 12:22:12)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch adds support for laptop brightness keys on X11. Qt doesn't support 
> these keys yet, so this has to be implemented in a platform specific way and 
> I have provided support for them on X11. 
> 
> There is no OSD or other indication that the keys work other than the change 
> in brightness.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/plasma/applets/battery/CMakeLists.txt
>   /trunk/KDE/kdebase/workspace/plasma/applets/battery/battery.h
>   /trunk/KDE/kdebase/workspace/plasma/applets/battery/battery.cpp
> 
> Diff: http://reviewboard.vidsolbach.de/r/335/diff
> 
> 
> Testing
> ---
> 
> compiled, installed, and verified the keys do work.
> 
> 
> Thanks,
> 
> Matt
> 
>

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

Re: Review Request: Also save extender item config when not detached, and save collapsed state.

[Will Stephenson]

On Friday 16 January 2009 18:31:02 Rob Scheepmaker wrote:
> The question is, do we want this change in behavior? I personally think
> it's worth it. Second question is, do we want this backported to 4.2.
> Again, I think yes, but can we do this considering the freeze?

Oh and another behaviour change that might be worth making in this area:
ExtenderItems' titles are persisted. These are translated, which is probably 
bad news if the user changes their desktop language, especially if applet 
programmers start doing things like depending on the saved title for something 
else, then the locale changes, then some test compares the saved (old-
language) value with some value from the new-language.

Will

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