'Re: Review Request: Initial work on the flexible controller of the'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Initial work on the flexible controller of the
From:       "Shantanu Tushar Jha" <jhahoneyk () gmail ! com>
Date:       2010-03-26 12:56:24
Message-ID: 20100326125624.10894.9634 () localhost
[Download RAW message or body]

> On 2010-03-26 10:04:12, Marco Martin wrote:
> > still can't comment on how it looks, i hope to have time to try it today.
> > in general i agree it should behave quite differently with diffrent type of \
> > medis, but i would also like being able to browse in a folder and being able to \
> > see anything it could contain, regardless if it's audio/video/pictures whatever, \
> > so it wouldn't be a type in particular.. 
> > also i feel that defining a set of "modes" this way it can be quite rigid. i can \
> > see in the future people wanting to write plugins to make it do radically \
> > different types of things. i would like for instance being able to browse \
> > launchers of applications to be able to have a "games" section for instance and i \
> > think it would be possible only by keeping things as more generic as possible. 
> > when i'll have played a bit with it i will have clearer ideas perhaps. however i \
> > do think the general idea is correct, a rigid set of "modes" is a bit too much \
> > however
> 
> Shantanu Tushar Jha wrote:
> Ok, so a flexible collection of modes will be fine I guess?
> As per the use case you suggested, we can have a plugin to add a new mode. Though \
> we'll need some discussion on IRC over this. See you there :) 
> Marco Martin wrote:
> ok, trying the patch i can see what it's trying to do and i like it, it basically \
> boils down to: for some media type a particular control may or may not be neede \
> (with maybe some behavioural differences in single controls) so what i think would \
>                 be rocking is:
> -as is obvious and was aleady been done 2 modes: browsing and playing, would be \
> basically if something is being played or not and react by showning or hiding \
> controls by default) 
> when browsing:
> see what are the mimetypes disaplayed in the folder, if the focus of the current \
> item changes, change the displayed controls accordingly. when playing change the \
> controls according to the currently played mime type. 
> so what is available is mmetype dependent, a plugin could want to register an \
> association mimetype->what i want, so a picture won't have play/stop buttons and \
> the playlist would be visible by default only for music... 
> if we will be able to play different mimetypes at once (the example of \
> photos+music) the available stuff will be the sum of all the available controls for \
> each mimetype. 
> similarly we could define a way to allow a mimetype to be played together another \
> one (always examples of music+photos) 
> it's still a very abstract idea but hope t kinda gives it ;)

> see what are the mimetypes disaplayed in the folder, if the focus of the current \
> item changes, change the displayed controls accordingly. when playing change the \
> controls according to the currently played mime type.

We'd need to have capabilities to organize Music by Artist, Album etc, so we won't be \
restricted to folders always.

> so what is available is mmetype dependent, a plugin could want to register an \
> association mimetype->what i want, so a picture won't have play/stop buttons and \
> the playlist would be visible by default only for music...

A playlist will be not shown in the browsing mode anyway. And just to make sure the \
point isn't missed, no pictures in playlist, its ugly.

> if we will be able to play different mimetypes at once (the example of \
> photos+music) the available stuff will be the sum of all the available controls for \
> each mimetype.

Wouldn't there be loads of controls then? Well actually the idea of different modes \
is to simplify the UI and to make it the workflow more concerned with one "activity" \
(not the Plasma one ;) at a time.

For example, I open the MC, goto the music mode and play my favorite playlist, switch \
to Pictures mode and enjoy my slideshow while the music plays in the background :)

So what I suggest is to keep modes for playing, and let a plugin add a new mode, just \
like we add a new wallpaper plugin in Plasma, for example. Then we can have another \
plugin for, say, Games as you said in the previous post.

- Shantanu

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

On 2010-03-25 19:01:32, Christophe Olinger wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3396/
> -----------------------------------------------------------
> 
> (Updated 2010-03-25 19:01:32)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> This patch extends the controller applet by having 6 different layout modes which \
> are adapted to what the media center is currently used for, i.e. browsing pictures, \
> playing videos, etc. It sends a signal to the containment with the current mode. \
> The containment then relayouts the other applets and configures them for the \
>                 current Mode. These modes are defined as enum in the libs.
> *The browser no longer has any controls. Those are now in the controller.
> *The controller also has a show/hide playlist button and a toggle autohide button \
>                 for itself.
> *The different modes do not have sensible functions yet. I also need to work on \
> configuring the applets for each mode, like telling the browser to hide, or the \
>                 player to show.
> *The controller is not really beautiful. I want animations for show(hide icons. I \
> want the modeswitch button in a "drawer" perhaps. The toggle buttons need effects. 
> 
> Diffs
> -----
> 
> /trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/mediabrowser.h \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/mediabrowser.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.h \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.h \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/medialayout.h \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/medialayout.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/browser.cpp \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenter.h \
>                 1107457 
> /trunk/playground/base/plasma/MediaCenterComponents/shells/plasmediacenter/mainwindow.cpp \
> 1107457  
> Diff: http://reviewboard.kde.org/r/3396/diff
> 
> 
> Testing
> -------
> 
> I tested the controller itself. The actual effect on the other applets when \
> changing modes still needs work. 
> 
> Thanks,
> 
> Christophe
> 
> 

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

[prev in list] [next in list] [prev in thread] [next in thread] 