Re: multi-screen management

2010-08-19 Thread Marco Martin
On Wednesday 18 August 2010, Chani wrote:
 On August 18, 2010 03:15:13 Marco Martin wrote:
  On Wednesday 18 August 2010, Chani wrote:
   so... we had planned to have a little tool for managing the
   containments of multiple screens, in 4.5 - but there wasn't time.
   multiscreen has improvements, but also regressions - well, *a*
   regression - you can't access the containment of a screen that's not
   plugged in. the same applies to the per-desktop view stuff (they have
   a lot in common).
[...]
   Oh, and as for where to go to open this UI: well, it has to run
   in-process, but it's not common enough to warrant a toolbox entry, so I
   had a crazy idea: what if whatever kcm is relevant to this stuff
   (plasma settings + wherever the PDV setting lives?) had a button that
   sent a dbus signal to plasma-desktop to show the UI?
  
  i think should be reachable from the activity manager (either right
  click, another action icon, whatever)
 
 it's not related to activities, though. it's just made necessary by the way
 I did the activities.

yes, but still i think is the logical place to reach it

   TODO: clean up the above rambling into a more structured document. :)
   
   [edit]Under the Hood
   
[...]
  
  uhm, i think the authority shuld just be corona, but in case of
  plasma-desktop corona use the Activity to make the decision...
 
 well, right now the corona isn't the authority on anything. and for non-
 running activities, the containments' settings are the only authority.

yes, i think the containments eing a source of authority for themselvescan be 
potentially problematic

   * Might it be easier to leave the config in plasma-desktop-appletsrc,
   and have the startup loading skip containments assigned to nonexistant
   screens/desktops?
  
  in the end, where you have the configuration is the same thing, depends
  if it's ever wanted having running containments not associated with
  screens. the exceptions are the mobile and netbook launchers, but they
  could have -1 (instead of a number  than available screens)
 
 no, any containment that was never associated with a screen will be
 completely ignored by all of this code. :)
 also... at the moment, code that wants to work with desktop containments
 checks whether a containment is in offscreenwidgets in order to skip any
 dashboards.
 
   * Once this is implemented, I believe panels should behave the same
   way, instead of migrating. It's more consistent that way. thoughts?
  
  agree
  
   * It'd be nice to investigate whether any delay would be helpful - is
   it likely for several screen changes to happen within a few seconds?
   either from drivers being fidgety or from a loose cable or something?
   I don't know enough to be sure.
  
  yes, two things likely to happen
 
 do we have any evidence for this, though? do you *think* it's likely or
 *know* it's likely? :)

at the moment just thinking it's likely

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


Re: multi-screen management

2010-08-19 Thread Marco Martin
On Wednesday 18 August 2010, Aaron J. Seigo wrote:

 ok .. so given that these are use cases ... how about this as an idea:
 
 in the Activity Manager panel, if there is more than one containment in the
 current activity, it is shown expanded with a snapshot of each containment.
 so, in a two screen system, the current activity would be represented by
 two screenshots next to each other instead of the one icon. click on one
 or the other would switch the current screen to be using that containment.
 
 this doesn't touch the bring that containment from Activity 1 over to
 Activity 3 issue, but that seems like more of an edge case, one that is
 harder to solve nicely and which probably requires a whole big arrange
 stuff around tool like in your proposal.

those expanded little screenshots could support drag and drop around in the 
activity manager itself tough

 if we just try and solve the above 2 use cases, though, we could perhaps do
 it right from inside the existing activity manager UI. thoughts?
 
  3) user tried out the PDV feature, but didn't like it and turned it off.
  now their system is slow, and someone on irc tells them it's because all
  those other desktops are still running. they use the tool to delete all
  those extra containments that aren't being used.
 
 should turning off PDV just automatically remove all those other
 containments, or offer the option to do so when it is turned off?
 Per-desktop views have been turned off and there are now several unused
 widget layouts. Would you like them to be removed automatically for you?
 This can result in a significant performance improvements. Remove Unused
 Layouts Keep The Unused Layouts

uhm, not sure, it's a too technical question, just deleting could piss people 
off tough so yeah :/

When a screen is disconnected (or in PDV, a desktop removed) the
associated containment and view (for each running activity) should be
automatically stopped - and resumed again when the screen/desktop
returns. We can migrate panels, but not desktops, and it doesn't make
sense to leave something running and inaccessible (having to manually
stop it would also be Wrong).
   
   it does make sense to leave something running if one can switch to it,
   though. if the switcher UI allows the user to do that, then it's
   probably fine.
  
  except that I'm not sure how many users will realise they might have
  stuff running still and check this tool. they'll just think their system
  got slower because it's bloated or something :P
  
  me, I plug in an external monitor (actually a tv) a couple of times a
  week to watch movies. I don't want the containment for it running for
  the rest of the week, and I don't really want to manually delete or
  close it every time. and the multiscreen tool would then need a feature
  to manually close things instead of deleting them, too.
 
 how much weight (start up time, memory usage) does this use case incur
 right now? wallpapers on loaded on first-paint only, if there are no
 widgets then none are loaded or set up ... it might be very negligable and
 not work worrying about.

however it won't be negligable on netbook and mobile, but i was thinking about 
explicity stopping and restarting activities here


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


Re: multi-screen management

2010-08-19 Thread Marco Martin
On Wednesday 18 August 2010, Jeremy Whiting wrote:
  
  it does make sense to leave something running if one can switch to it,
  though.
  if the switcher UI allows the user to do that, then it's probably fine.
 
 Umm, is there a glossary somewhere of plasma terms? I've no clue what PDV,
 or such mean.

per virtual desktop activities, a different containment on each virtual 
desktop.
it's a feature that turned out to be really troublesome to adapt in the 
current activities development, but unfortunately turned out to be loved quite 
a bit, so will have to stay :/

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


mentors needed

2010-08-19 Thread Lydia Pintscher
Heya folks :)

I need mentors for a GSoC-like program in Canada asap so please get
back to me within the next two days.
What's needed:
- a mentor who can come to Toronto from October 1-3.
- a chunk of work that's suitable for a group of 5-10 upper-year
computer science students to work on for a semester. They have about
10 hours a week available between September and the beginning of
December.

Let me know if you're interested to mentor, have a project for them
and can travel to Toronto on these days. Let's get some more students
to write code for KDE  :)

You can find out more about the program at http://ucosp.ca/about/


Cheers
Lydia

-- 
Lydia Pintscher
Amarok community manager
kde.org - amarok.kde.org - kubuntu.org
claimid.com/nightrose
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


Re: Review Request: Enabling ShowDashboard widget to show Dashboard while anything is dragged and hovered over it.

2010-08-19 Thread Sinny Kumari

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

(Updated 2010-08-19 16:09:42.922115)


Review request for Plasma.


Changes
---

Changed it as per suggestion.


Summary
---

Added feature to drag anything and adding it directly to the DashBoard.
It can be done by dragging anything like file/widget and hovering it over 
ShowDashBoard widget .


Diffs (updated)
-

  trunk/KDE/kdeplasma-addons/applets/showdashboard/showdashboard.h 1164952 
  trunk/KDE/kdeplasma-addons/applets/showdashboard/showdashboard.cpp 1164952 

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


Testing
---

Tested it on trunk.It's working absolutely fine and i really enjoyed it while 
doing :)


Thanks,

Sinny

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


Re: Review Request: Enabling ShowDashboard widget to show Dashboard while anything is dragged and hovered over it.

2010-08-19 Thread Aaron Seigo

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

Ship it!


one small comment about the timeout #, but this patch can go in.. cheers and 
thanks for the patch :)


trunk/KDE/kdeplasma-addons/applets/showdashboard/showdashboard.cpp
http://reviewboard.kde.org/r/5063/#comment7277

testing with this, i found 750ms more natural feeling: it didn't trigger 
accidentally as easily and it didn't feel like it took very long to trigger it 
either.


- Aaron


On 2010-08-19 16:09:42, Sinny Kumari wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/5063/
 ---
 
 (Updated 2010-08-19 16:09:42)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Added feature to drag anything and adding it directly to the DashBoard.
 It can be done by dragging anything like file/widget and hovering it over 
 ShowDashBoard widget .
 
 
 Diffs
 -
 
   trunk/KDE/kdeplasma-addons/applets/showdashboard/showdashboard.h 1164952 
   trunk/KDE/kdeplasma-addons/applets/showdashboard/showdashboard.cpp 1164952 
 
 Diff: http://reviewboard.kde.org/r/5063/diff
 
 
 Testing
 ---
 
 Tested it on trunk.It's working absolutely fine and i really enjoyed it while 
 doing :)
 
 
 Thanks,
 
 Sinny
 


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


Re: mentors needed

2010-08-19 Thread Chani
On August 19, 2010 09:17:27 Aaron J. Seigo wrote:
 On Thursday, August 19, 2010, Lydia Pintscher wrote:
  Heya folks :)
  
  I need mentors for a GSoC-like program in Canada asap so please get
  back to me within the next two days.
  What's needed:
  - a mentor who can come to Toronto from October 1-3.
 
 well, i'm only 3354 km away. ;) same country though, and convenient
 flights. beginning of oct is still open for me schedule-wise as well.
 there are lots of great projects available in Plasma for varying levels of
 experience, expertise, time allowance, interest, etc. so we should be able
 to send a few options along and we should be able to provide mentorship as
 well.

yay! :)
some of the students will be from UBC and SFU, btw... the SFU co-ordinator is 
probably still ted kirkpatrick. great teacher. :)

as for me, I'll be gone by october - but I will be back for the january 
semester if you guys can get the ball rolling. :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel