Hi there, Thanks for your answer Christophe,
----- "Christophe Olinger" <oling...@binarylooks.com> a écrit : > On Wed, Mar 31, 2010 at 12:31 PM, <daithe...@free.fr> 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] <aseigo> personally, i'd recommend something a lot simpler: a home button, and a button for each actively playing module [01:44] <Shaan7> aseigo: good point [01:44] <aseigo> so if i'm playing music and go to view images i get: Home | Audio [01:45] <aseigo> if i'm just viewing photo albums i get: Home [01:45] <aseigo> if i have a video playing, i get: Home | Video [01:45] <Shaan7> got it [01:45] <aseigo> when i go to the audio player and i've got a photo album open, i get: Home | Audio Photo [01:46] <aseigo> 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] <aseigo> the Pause button would apply to all open players [01:46] <aseigo> 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, Could someone hook me up with screenshots of current PMC ? > > > > > 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. np. Again, that was just an idea. And irc isn't oldfashioned at all. Great thing about Wave is that it mixes real-time discussion and you can still have access to it afterwards, and complete, edit, or answer later. It also provides tools that can be very handy (such as a white board, which was missing yesterday ;) ). > > > Anyway, greetings to Strasbourg an thank you for discussing with us. You're welcome :) I've a strong hope in PMC. I just want to see where you guys are going before I decide whether I abandon my own mediacenter project or not. That's pretty cool that you're open to discussion :) -- François _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel