Re: 4.5 - Activities

[Ivan Čukić]

> the important motivator for nepomuk is "applications using it". aka
> "relevance".

I agree on this one, I just wanted to point out that our usage of Nepomuk is 
not that advanced, thrilling or anything to be a driving force for devels. As 
for relevance, your statement stands ;)

> how can i say "no" when you look at me with those eyes? ;)

A, so swet :D

Cheerio,
Ivan


-- 
I am a spokesman for a better way of living
Love is the word and it can be heard
If you are young the message can be sung
-- Deep Purple
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasmate hacking during Akademy-BR ?

[Sandro Andrade]

Hi folks,

As you may already know, we are going to have Akademy-BR in next
weekend and I was
wondering about taking some hours and two or three developers to work
on Plasmate.

So, you guys wanting to point out some required feature/improvement would be
great. Is the plasmate webpage up to date ? Could someone rank the to-do's or
select one or two most wanted task ? We'll have two or three artwork
guys also looking for
hacking activities.

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

Re: Review Request: split widget-explorer classes

[Aaron Seigo]

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

Ship it!


looks good (modulo the tooltip thing); the other comments are relevant to the 
code that already exists before your adjustments. so i'd say commit what you 
have here, and we can work on those other issues after that.


/dev/null


it definitely doesn't need to start from scratch; this should really be 
changed to just showing/hiding items that do/don't match. i think this was done 
this way for ease of initial development only.



/dev/null


setting the orientation and filtering ought to be separate, yes.

when the list itself changes orientation, only the layout's orientation 
needs adjusting, not all the relayouting.



/dev/null


yes, this also handles wheel event stuff. probably should just be 
"scrollRight" and "scrollLeft". the IconList::Wheel bit can also be killed as 
there is no difference anymore between how wheeling and keyboard animations are 
handled.


- Aaron


On 2010-03-31 20:12:41, Chani Armitage wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3470/
> ---
> 
> (Updated 2010-03-31 20:12:41)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> this factors out the appletbrowser code into separate classes so that it can 
> be shared with the as-yet-unwritten activity manager UI. I created two new 
> classes, IconList and IconListElement, which AppletsList and AppletIconWidget 
> now inherit.
> 
> I think the class names kinda suck, so I'd be fine with renaming them if 
> someone has a better suggestion :) hrm, actually I was thinking of 
> AbstractIconList and AbstractIcon, since both have pure virtuals.
> 
> since I haven't actually written the activity manager there'll probably be a 
> bit of code moved around later, but I think it'll stay fairly close to this 
> initial split, and I want to get the code in before any merge conflicts come 
> up.
> 
> I haven't attempted to fix any bugs; I just split up the code, and made a 
> note of anything that needs attention later.
> 
> 
> Diffs
> -
> 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /dev/null PRE-CREATION 
>   /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/CMakeLists.txt 1106791 
>   
> /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appleticon.h
>  1106791 
>   
> /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appleticon.cpp
>  1106791 
>   
> /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appletslist.h
>  1106791 
>   
> /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appletslist.cpp
>  1106791 
> 
> Diff: http://reviewboard.kde.org/r/3470/diff
> 
> 
> Testing
> ---
> 
> it seems to work as before.
> there's just one regression: the tooltips aren't updated on scroll. shouldn't 
> be too hard to fix, just slipped my mind.
> 
> 
> Thanks,
> 
> Chani
> 
>

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

Review Request: split widget-explorer classes

[Chani Armitage]

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

Review request for Plasma.


Summary
---

this factors out the appletbrowser code into separate classes so that it can be 
shared with the as-yet-unwritten activity manager UI. I created two new 
classes, IconList and IconListElement, which AppletsList and AppletIconWidget 
now inherit.

I think the class names kinda suck, so I'd be fine with renaming them if 
someone has a better suggestion :) hrm, actually I was thinking of 
AbstractIconList and AbstractIcon, since both have pure virtuals.

since I haven't actually written the activity manager there'll probably be a 
bit of code moved around later, but I think it'll stay fairly close to this 
initial split, and I want to get the code in before any merge conflicts come up.

I haven't attempted to fix any bugs; I just split up the code, and made a note 
of anything that needs attention later.


Diffs
-

  /dev/null PRE-CREATION 
  /dev/null PRE-CREATION 
  /dev/null PRE-CREATION 
  /dev/null PRE-CREATION 
  /dev/null PRE-CREATION 
  /trunk/KDE/kdebase/workspace/libs/plasmagenericshell/CMakeLists.txt 1106791 
  
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appleticon.h
 1106791 
  
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appleticon.cpp
 1106791 
  
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appletslist.h
 1106791 
  
/trunk/KDE/kdebase/workspace/libs/plasmagenericshell/widgetsexplorer/appletslist.cpp
 1106791 

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


Testing
---

it seems to work as before.
there's just one regression: the tooltips aren't updated on scroll. shouldn't 
be too hard to fix, just slipped my mind.


Thanks,

Chani

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

Re: 4.5 - Activities

[Aaron J. Seigo]

On March 31, 2010, Ivan Čukić wrote:
> > can we get together on irc soon and do a once-over of this and then get
> > it moved into kdereview?
> 
> Ok, I'll try to be online tomorrow. If not, then the weekend?

sounds great; i'll be around :)

> > if we work around subsystems because "they don't work well yet" then the
> > odds they ever will work well goes down as there is less reason /
> > motivation to get them working well. if those subsystems can't be made to
> > work well, then we shouldn't have them in our stack. otherwise, the aim
> > should be to make them work.
> 
> I know, and I understand your point, but activities can't really be
> considered to be an important motivator for nepomuk's development anyway.

the important motivator for nepomuk is "applications using it". aka 
"relevance".

> I have no problem with hard-dependence on nepomuk, but that was something
> that was agreed upon due to request from kwin guys - we had a small
> meeting consisted of John, Lubos, Chani, Martin and me.

ok; understood. i disagree, but if that's the consensus, so be it :)

> > it's that simple. please stop working around
> > brokenness.
> 
> I'm aware of your stance on temporary solutions and their tendencies to
> become permanent. If I promise it will not, will you trust me? :) 

how can i say "no" when you look at me with those eyes? ;)

-- 
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

Re: 4.5 - Activities

[Ivan Čukić]

> can we get together on irc soon and do a once-over of this and then get it
> moved into kdereview?

Ok, I'll try to be online tomorrow. If not, then the weekend?

> if we work around subsystems because "they don't work well yet" then the
> odds they ever will work well goes down as there is less reason /
> motivation to get them working well. if those subsystems can't be made to
> work well, then we shouldn't have them in our stack. otherwise, the aim
> should be to make them work.

I know, and I understand your point, but activities can't really be considered 
to be an important motivator for nepomuk's development anyway.

I have no problem with hard-dependence on nepomuk, but that was something that 
was agreed upon due to request from kwin guys - we had a small meeting 
consisted of John, Lubos, Chani, Martin and me.

> it's that simple. please stop working around
> brokenness.

I'm aware of your stance on temporary solutions and their tendencies to become 
permanent. If I promise it will not, will you trust me? :) (from my POV, if 
kwin guys change their mind, and if we decide that nepomuk is ready in 4.5 we 
could remove the cache in final 4.5)

Cheerio,
Ivan
-- 
I am a spokesman for a better way of living
Love is the word and it can be heard
If you are young the message can be sung
-- Deep Purple
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Prefetching in Comic Strip plasmoid

[Matthias Fuchs]

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


I am sorry it took so long for me to answer, I simply overlooked your review 
request.

I haven't yet tried your patch, though it sounds very interesting -- depending 
on the comic I often had the same problem as well :) -- and I am going to try 
it the next days.

- Matthias


On 2010-01-25 10:19:38, Miha Cancula wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2636/
> ---
> 
> (Updated 2010-01-25 10:19:38)
> 
> 
> Review request for Plasma and Matthias Fuchs.
> 
> 
> Summary
> ---
> 
> When a new strip is loaded, it caches both the previous and the next one, 
> without interfering with the currently displayed comic. This is very useful 
> if you're reading throug a particular comic, especially on slower 
> connections. It's a two-line patch, but it greatly improves the experience 
> for this use-case. Caching is done by the DataEngine, so no further 
> modifications were needed.
> 
> After a discussion in the mailing list, the decision was to have no 
> configuration for this, as the cost of downloading a single picture is qiute 
> low.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdeplasma-addons/applets/comic/comic.cpp 1075738 
> 
> Diff: http://reviewboard.kde.org/r/2636/diff
> 
> 
> Testing
> ---
> 
> I tested it on my Ubuntu machine with todays trunk. It works as expected, and 
> I haven't noticed any regressions.
> 
> 
> Thanks,
> 
> Miha
> 
>

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

Re: 4.5 - Activities

[Chani]

> > After the time comes when we can rely on nepomuk 24/7, we can remove
> > the caching kded service since all of this is hidden behind the API.
> 
> if we work around subsystems because "they don't work well yet" then the
> odds they ever will work well goes down as there is less reason /
> motivation to get them working well. if those subsystems can't be made to
> work well, then we shouldn't have them in our stack. otherwise, the aim
> should be to make them work. it's that simple. please stop working around
> brokenness.

erg.
while you're right... my desktop has already developed a tendency to fall half 
to pieces when nepomuk goes down. or maybe it's dbus having trouble, I'm not 
100% certain, but in any case we've gotta get those subsystems working *first* 
because if I have to reboot my computer every couple of days to keep it 
working-ish I'm going to throw it out the fucking window.

oh crap I'm late for school now byebye

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com


signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: 4.5 - Activities

[Marco Martin]

On Wednesday 31 March 2010, Aaron J. Seigo wrote:
> On March 30, 2010, Chani wrote:
> > AppletIconWidget? it does all its own painting, and has some odd-looking
> > sizing code,
> 
> i suppose you are refering to resizeEvent? if so, it simply reserves enough
> space for one line of text below the icon and makes the icon size big
> enough to fill the rest.
> 
> > and I'm wondering if I can't just replace it with a subclass
> > of Icon and get things like corner-icons for free.
> 
> you might be able to; try it? Ana was running into all kinds of "doesn't
> look quite right" problems when using Plasma::Icon, but the widget
> explorer code has changed quite a bit since then so maybe things are
> better now. give it a try.
i suspect was mostly due to how difficult it is to have icons all of the same 
size
also layouting in IconWidget changed a bit, still gives a bit of headaches but 
should be slightly better

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

Re: 4.5 - Activities

[Aaron J. Seigo]

On March 26, 2010, Ivan Čukić wrote:
>  - all manager signals converted into listener objects

this is the registeredActivityControllers stuff in the kded service? if so: 
turns out that dbus signals aren't as bad as i had been led to believe. it 
turns out that some of kdelibs were using certain dbus signals poorly which 
was resulting in the "every process is waking up" behaviour. this had been 
blamed on dbus signals by some, but turned out not to be the case. i still 
think that registering controlers in this manner is "the way to go" though, as 
it will make it far easier to debug issues with multiple controllers, give us 
the option of controlling who can control and when in the future, etc.

>  - consumer signals left as is (they are not invoked that often, and are
>something most applications should respond to eventually)

as noted above, this is even a moot point now that we know that dbus signals 
are indeed more discretionary. :)

>  - changed d-bus API to fit the style of other KDE services

looks good

>  - added test shell script for nepomuk service
>  - added test implementation of a manager application

tests ftw!

>  - added location resource type
>  - changed a LOT of API

can we get together on irc soon and do a once-over of this and then get it 
moved into kdereview?  

> I need to do some more testing, but this should work well enough (TM)
> for other parts (UI) to be developed.
> 
> I've still retained the kded service <-> nepomuk service organization
> for the before mentioned reasons, including another (IMO) important
> one:
>  - the present packaging of nepomuk is easily breakable (I don't want
> to say that Nepomuk itself is not stable, but that installations of it
> are :) )

then it's an installation issue, and not our concern (at the code level)

> and while, for example, Akonadi can show a message like "blah
> blah not available, akonadi-based apps are not usable", we
> (Plasma/KWin) don't have that luxury.

activities are not a required feature.

> After the time comes when we can rely on nepomuk 24/7, we can remove
> the caching kded service since all of this is hidden behind the API.

if we work around subsystems because "they don't work well yet" then the odds 
they ever will work well goes down as there is less reason / motivation to get 
them working well. if those subsystems can't be made to work well, then we 
shouldn't have them in our stack. otherwise, the aim should be to make them 
work. it's that simple. please stop working around brokenness.

-- 
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

Re: 4.5 - Activities

[Aaron J. Seigo]

On March 30, 2010, Chani wrote:
> AppletIconWidget? it does all its own painting, and has some odd-looking
> sizing code, 

i suppose you are refering to resizeEvent? if so, it simply reserves enough 
space for one line of text below the icon and makes the icon size big enough 
to fill the rest.

> and I'm wondering if I can't just replace it with a subclass
> of Icon and get things like corner-icons for free.

you might be able to; try it? Ana was running into all kinds of "doesn't look 
quite right" problems when using Plasma::Icon, but the widget explorer code 
has changed quite a bit since then so maybe things are better now. give it a 
try.

-- 
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

Re: PMC use case

[Aaron J. Seigo]

On March 31, 2010, daithe...@free.fr wrote:
> I'd rather put the whole "mode access" to a dedicated panel that wouldn't
> change. 

this is the home page.

> And keep the controls in the top bar or wherever you want. (I'm

that's the idea.

> still not convinced that a common control bar is the best thing, even if
> available buttons and controls change according to the mode).

on-screen controls are required, and our choice is to make them common and 
shared so that the code is kept minimal and the look 'n feel is consistent.

> So just have
> to make it appear and select the mode you want, from wherever you are. If
> the mode is already playing, it just gains focus.

this adds visual clutter and adds button presses ("expensive" with a remote 
control) all to avoid one jump to the home page. not worth it imho.

> Exceptions aren't good *imho* because they are hard to deal with, because
> anytime someone will add a mode, you'll have to decide what exceptions to
> make. And those probably won't be everyone's.

with the mechanism i described, this isn't a problem. each mode describes the 
control layout it needs, but it's up to the MediaController itself to do the 
layout based on that description. it can keep the consistent things 
consistent, while the mode provides the custom bits.

-- 
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

Re: PMC use case

[Aaron J. Seigo]

On March 31, 2010, daithe...@free.fr wrote:
> menu (or whatever you call it, for me it's just a menu) has to be the same
> everywhere.

it isn't a menu, it's a contextual controls bar.
it can't be the same everywhere, since neither the context is consistent nor 
could we fit everything on there without putting a hard limit on the number of 
possible modes (or "home page entries" if you wish)

> Instead of adding buttons in the top bar, I propose an
> overlaying menu with autohide capability.

you're thinking of the home page and/or browsing UI. this is something 
completely different.

> This menu would show what mode
> is currently in use and would allow fast switching / starting. The Mac OS
> X Dock is a good example of what I'm thinking about. You can put it on the
> bottom/left/top/right side of your desk, make it autohide and reappear
> when the mouse pointer comes close to it.

we can't rely on a pointer / mouse. this is a media center with the goal of a 
remote control drivable 10' UI.

> this idea, a long-click on an icon could make a "submenu" appear with
> quick access to basic functionnalities like "Quit this mode", "Pause" or
> anything, without switching to the mode.

mouse based UIs are not permisable.
 
-- 
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

Re: PMC use case

[daitheflu]

Hi there,

Thanks for your answer Christophe,


- "Christophe Olinger"  a écrit :

> On Wed, Mar 31, 2010 at 12:31 PM,   wrote:
> 
> >
> > About the top bar discussion, I would strongly recommend not to do
> that. A menu (or whatever you call it, for me it's just a menu) has to
> be the same everywhere.
> I do not really agree here. When viewing pictures, I do not neet a
> seek slider and when I view videos, I do not need "turn picture"
> icons. The playlist is not useful for when I view pictures. There are
> some that will be there for all modes, like rating, tagging, the home
> button, possibly the skip forward and skip backward buttons and the
> "turn on autohiding" button.

Yep, sure. What I dislike in this idea is that, according to aseigo proposal 
(see quote below), the top bar will provide access to both modes and controls 
(and maybe more) : 

[01:44]  personally, i'd recommend something a lot simpler: a home 
button, and a button for each actively playing module
[01:44]  aseigo: good point
[01:44]  so if i'm playing music and go to view images i get: Home | 
Audio
[01:45]  if i'm just viewing photo albums i get: Home
[01:45]  if i have a video playing, i get: Home | Video
[01:45]  got it
[01:45]  when i go to the audio player and i've got a photo album open, 
i get: Home | Audio Photo
[01:46]  this will allow it to do tripple duty: show what's currently 
running, shortcut jumps to those items, a way to go back to home
[01:46]  the Pause button would apply to all open players
[01:46]  that means players need a "stop for a moment" slot

I'd rather put the whole "mode access" to a dedicated panel that wouldn't 
change. And keep the controls in the top bar or wherever you want. (I'm still 
not convinced that a common control bar is the best thing, even if available 
buttons and controls change according to the mode).


> 
> > Instead of adding buttons in the top bar, I propose an overlaying
> menu with autohide capability. This menu would show what mode is
> currently in use and would allow fast switching / starting. The Mac OS
> X Dock is a good example of what I'm thinking about.
> 
> What is your definiton of menu? The Mac dock is nothing but a panel
> with buttons. Sorry if I do not understand you corretly.
> 

Yep, that's what I'm talking about. A simple panel with buttons.


> You can put it on the bottom/left/top/right side of your desk, make
> it
> autohide and reappear when the mouse pointer comes close to it. You
> can launch any app that has an icon in it. For us, we would need a
> Music icon, a Video icon, etc... Already running apps icons have an
> indicator showing the user that it's already running. We would just
> need to add a "Home" icon that would "minimize" all running stuff and
> show the Home applet.
> 
> Hmmm, I think you actually describe what we are currently doing. we
> will have a panel (menu?) with a home button that hides everything
> except a home screen. We decided to remove buttons for every mode,
> because screen estate is sometimes rare. Instead you have to pass via
> the home screen to get to a different mode (maybe with the exception
> of when having music in the background while looking at pictures,
> where I could imagine a music button on the panel.

My idea is to separate the modes buttons and keep them in their own panel (what 
I call a menu and what I compared to Mac Os X' Dock).
So just have to make it appear and select the mode you want, from wherever you 
are. If the mode is already playing, it just gains focus.

I'd rather make some mockup. That will be easier to understand :)

Exceptions aren't good *imho* because they are hard to deal with, because 
anytime someone will add a mode, you'll have to decide what exceptions to make. 
And those probably won't be everyone's. See ?


> 
> 
> > Furthermore, with this idea, a long-click on an icon could make a
> "submenu" appear with quick access to basic functionnalities like
> "Quit this mode", "Pause" or anything, without switching to the mode.
> 
> Lets first see how many button we really noeed for everymode. Long
> clicking them could be an option for special cases, but not really
> often used things like pause or quit. I think this could frustrate
> users a bit :-)

Yep, that was just an idea :)


> 
> >
> > I might be totally wrong about the thing -never tried PMC and noone
> pointed me to a doc...- but that's what I'm understanding from the
> last discussions. So please bash me gently if I'm wrong (and hook me
> up with doc !) :D
> 
> As you said, we are still discussing. there is a doc on the wiki
> where
> we collect things:
> http://techbase.kde.org/Projects/Plasma/Plasma_Media_Center
> 
> but nothing is final. So keep on coming with the ideas and make sure
> to test PMC. Currently everything is on PMC. I will give out a git
> server as soon as the current developers agree on where to do this
> thing (probably gitsvn?? )

I've a lot of ideas. I've worked on mediacenter since 2005 :)
By the way, Cou

Re: PMC use case

[Christophe Olinger]

On Wed, Mar 31, 2010 at 12:31 PM,   wrote:

>
> About the top bar discussion, I would strongly recommend not to do that. A 
> menu (or whatever you call it, for me it's just a menu) has to be the same 
> everywhere.
I do not really agree here. When viewing pictures, I do not neet a
seek slider and when I view videos, I do not need "turn picture"
icons. The playlist is not useful for when I view pictures. There are
some that will be there for all modes, like rating, tagging, the home
button, possibly the skip forward and skip backward buttons and the
"turn on autohiding" button.

> Instead of adding buttons in the top bar, I propose an overlaying menu with 
> autohide capability. This menu would show what mode is currently in use and 
> would allow fast switching / starting. The Mac OS X Dock is a good example of 
> what I'm thinking about.

What is your definiton of menu? The Mac dock is nothing but a panel
with buttons. Sorry if I do not understand you corretly.

You can put it on the bottom/left/top/right side of your desk, make it
autohide and reappear when the mouse pointer comes close to it. You
can launch any app that has an icon in it. For us, we would need a
Music icon, a Video icon, etc... Already running apps icons have an
indicator showing the user that it's already running. We would just
need to add a "Home" icon that would "minimize" all running stuff and
show the Home applet.

Hmmm, I think you actually describe what we are currently doing. we
will have a panel (menu?) with a home button that hides everything
except a home screen. We decided to remove buttons for every mode,
because screen estate is sometimes rare. Instead you have to pass via
the home screen to get to a different mode (maybe with the exception
of when having music in the background while looking at pictures,
where I could imagine a music button on the panel.


> Furthermore, with this idea, a long-click on an icon could make a "submenu" 
> appear with quick access to basic functionnalities like "Quit this mode", 
> "Pause" or anything, without switching to the mode.

Lets first see how many button we really noeed for everymode. Long
clicking them could be an option for special cases, but not really
often used things like pause or quit. I think this could frustrate
users a bit :-)

>
> I might be totally wrong about the thing -never tried PMC and noone pointed 
> me to a doc...- but that's what I'm understanding from the last discussions. 
> So please bash me gently if I'm wrong (and hook me up with doc !) :D

As you said, we are still discussing. there is a doc on the wiki where
we collect things:
http://techbase.kde.org/Projects/Plasma/Plasma_Media_Center

but nothing is final. So keep on coming with the ideas and make sure
to test PMC. Currently everything is on PMC. I will give out a git
server as soon as the current developers agree on where to do this
thing (probably gitsvn?? )

>
> Also, I've several Google Wave invitations. This can be really useful to 
> collaborate. It provides files sharing, powerful editing and even polls or 
> white board through extensions. Just tell me if you're interested in using 
> such a tool.

Hmm, I never used that. I really like irc. Maybe I am oldfashioned but
currently I have almost already a communication possibilities
overdose.


Anyway, greetings to Strasbourg an thank you for discussing with us.

>
> Cheers,
>
> --
> François
>
> ___
> 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: PMC use case

[Sebastian Kügler]

On Wednesday 31 March 2010 09:37:30 Alexis Ménard wrote:
> > The key is really to support commodity hardware, things people already
> > have or can get rather inexpensively and turn it into a media center
> > with little effort (basically install PMC, and hook up the TV to it).
> 
> And why not targeting the problem at the source, integrating the
> software into the TV directly.

Because in that case, you need a very special and high-end TV, it definitely 
doesn't 
fall into the category of commodity hardware, and thus greatly reduce the 
potential 
userbase of PMC.

For the future, sure, I want my TV to have that kind of functionality, and 
maybe 
MeeGo will bring that. Mid-term, you'll have to hook up something to your TV if 
you 
want this kind of functionality and that's what we'll have to work with.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PMC use case

[daitheflu]

Hi guys,


- "Christophe Olinger"  a écrit :

> I'll try to update the wiki page today adding the things we discussed
> here and also the StateMachine Rewriting.

About the top bar discussion, I would strongly recommend not to do that. A menu 
(or whatever you call it, for me it's just a menu) has to be the same 
everywhere.
Instead of adding buttons in the top bar, I propose an overlaying menu with 
autohide capability. This menu would show what mode is currently in use and 
would allow fast switching / starting. The Mac OS X Dock is a good example of 
what I'm thinking about. You can put it on the bottom/left/top/right side of 
your desk, make it autohide and reappear when the mouse pointer comes close to 
it. You can launch any app that has an icon in it. For us, we would need a 
Music icon, a Video icon, etc... Already running apps icons have an indicator 
showing the user that it's already running. We would just need to add a "Home" 
icon that would "minimize" all running stuff and show the Home applet.
Furthermore, with this idea, a long-click on an icon could make a "submenu" 
appear with quick access to basic functionnalities like "Quit this mode", 
"Pause" or anything, without switching to the mode.

I might be totally wrong about the thing -never tried PMC and noone pointed me 
to a doc...- but that's what I'm understanding from the last discussions. So 
please bash me gently if I'm wrong (and hook me up with doc !) :D

Also, I've several Google Wave invitations. This can be really useful to 
collaborate. It provides files sharing, powerful editing and even polls or 
white board through extensions. Just tell me if you're interested in using such 
a tool.

Cheers,

-- 
François

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

Re: playground/base/plasma/MediaCenterComponents

[Marco Martin]

On Wednesday 31 March 2010, Sebastian Kügler wrote:
> SVN commit 1109276 by sebas:
> 
> New class to interact with a Wiimote
> 
> The class uses the cwiid library from http://abstrakraft.org/cwiid/
> to detect the wiimote, read its settings and receive events.
> 
> Currently supported:
>  - buttons
>  - switching LEDs on and off
>  - rumble to switch haptic feedback on and off
>  - accelerometers: x, y and z
> 
> There's a small demo application called wiimote-demo that can be used
> as an example how to use this class, or to just play around with the
> device. When starting wiimote-demo, press the 1 and 2 buttons on your
> wiimote and it will connect to it. This happens in two steps, first
> the address of the wiimote needs to be found, then the actual
> connection is established.
> 
> The class is async, it does interaction with the wiimote (which is
> often blocking) in its own thread, sending over information using
> signals.
> 
> Have fun :)

you rock dude :D

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

Re: PMC use case

[Alexis Ménard]

On Tue, Mar 30, 2010 at 12:42 PM, Sebastian Kügler  wrote:
> On Monday 29 March 2010 21:02:06 Aaron J. Seigo wrote:
>> thoughts?
>
> I don't agree with the "PMC should target notebooks" as primary usecase bit. 
> I really
> think that this thing should be developed to have its UI run on a TV, 
> preferably HD-
> Ready or Full-HD resolution. Those devices tend to be easily hooked up with a
> computer nowadays (as Jane knows), (ours has both HDMI and D-Sub and is also 
> a fine
> monitor). The key difference is wether to rely on a mouse pointer or not, and 
> how
> interaction looks like otherwise.
>
> Now that's of course me being selfish, because I, at some point, want to use 
> PMC on
> this kind of device as my Media Center. What I have in mind is roughly:
>
> - PMC running on a netbook or comparatively cheap hardware
> - easily controllable from a 10 foot distance, using a remote control or a 
> wiimote
> - connected to the Internet, so web video (youtube, blip, miro, ...) should 
> be first
>  class citizens
> - access to the local and networked media library (in the same way ("it 
> doesn't
>  matter where it's stored") via SMB, uPnP, HTTP
> - built-in web browser that's basically usable by a remote / wiimote(*) as 
> well
> - full-screen media player with overlaid Plasma widgets to control playback 
> and
>  playlist
> - good bookmarking support (favourites for web and local videos, easy way to
>  find/remember the current/next episode of a TV show)
> - contextual information for content (Nepomuk, IMDB, discogs, ...)
> - Remotely editable playlist (pull up your notebook / n900 and edit the 
> playlist on
>  the PMC without interrupting playback)
>
> The key is really to support commodity hardware, things people already have 
> or can
> get rather inexpensively and turn it into a media center with little effort
> (basically install PMC, and hook up the TV to it).

And why not targeting the problem at the source, integrating the
software into the TV directly.

>
> (*) I've played around with a wiimote last weekend and now have a Qt-style 
> class that
> can be used to interact with the features of a wiimote, buttons, LEDs, 
> accelerometers
> and haptic feedback at this point. I've got myself a copy of O'Reilly's 
> "designing
> gestural interfaces", and I think we can get quite far, from a functionality 
> and an
> intuitiveness point of view by using such a device as main controller. That's
> something I work on in a lost hour here and there.
>
> Some of the above are quite specific ideas, and it might be different from 
> what other
> people think about it. In any event, while developing, please keep the above 
> in mind,
> so I won't have to do it all myself when I scratch my itches. :)
>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> 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