Review Request: Change behaviour of 'Next Wallpaper Image' menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/ --- Review request for Plasma. Summary --- This patch change the behaviour of displaying wallpaper in slideshow mode. In old behaviour it's possible the next slide selected from 'Next Wallpaper Image' menu from context menu, will not be displayed in proper interval. So in new behaviour timer is stopped before advancing to next slide. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1112767 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1112767 Diff: http://reviewboard.kde.org/r/3529/diff Testing --- Thanks, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: State machine architecture for PMC
On 2010-04-07 22:25:15, Alessandro Diaferia wrote: trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h, line 73 http://reviewboard.kde.org/r/3396/diff/7/?file=22868#file22868line73 A method of a library cannot rely on a particular implementation. You are asking for a MediaLayout* to be passed in as a parameter but that class is something defined within the MediaContainment, that is within the application level. We, here, are at a library level instead.. This is indicates that probably we have do re-design this. Yesterday I took the medialyout header from mediacenterstate.cpp and included it into the mediacenterstate header file. The forward declaration of the class MediaLayout I also removed from the header file. I then removed the comments in the mediacontainment.cpp file which now calls this and the function below from the mediacenterstate object but also from objects of the subclasses. For example in the musicstate class, the configureMediaLayout function tells the plalyist to become visible and the connectMediaLayout function connects a toggle Playlist button a slot in the medialyout. Strangely, the connection works, but as soon as I uncomment the call to the mediaLayout-setPlaylistVisible(true) function in the configureMedialayout function I get an undefined reference error for that function (checked spelling). ( the call to the configureMedialyout function from the containment to the musicstate (m_musicState-configureMedialyout(m_layout)) is not in svn right now, but the rest is. So there might we a reasoning error on my side as you said in this comment. I'll try to catch one of you guys this weekend. Marco tried to help me yesterday with good ideas but I had to leave on short notice :-/ - Christophe --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3396/#review4918 --- On 2010-04-07 20:59:11, Christophe Olinger wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3396/ --- (Updated 2010-04-07 20:59:11) Review request for Plasma. Summary --- This is the first try to get state machines working. I will of course not forget the previous comments. It builds and runs and state switching is possible. No playbackbuttons or other useful stuff yet, but is easy to get back. What I did: Created a mediacenterstate class which contains info about shared (so called Main) subcomponents. subcomponents are little widgets like buttons and sliders which will appear in the control bar. I sublcassed QState for this. Then I created a picturestate and videostate class, subclasses of the follwoing which are loaded on state switch. The containment does the state switch, the state classes do all the rest: connections, conficurations and hading out subcomponents to the controlbar. The controlbar now has a class to add widgets to itself. Diffs - trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/abstractmediaitemview.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/mediabrowser.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediabrowser/mediabrowser.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediacontroller/controller.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediaplayer/mediaplayer.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/applets/mediaplayer/mediaplayer.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/mediacontainment.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/medialayout.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/containments/mediacontainment/medialayout.cpp 1112197 trunk/playground/base/plasma/MediaCenterComponents/libs/CMakeLists.txt 1112197 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/CMakeLists.txt 1112197 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/browser.h 1112197 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/browser.cpp 1112197
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Tuesday 06 April 2010, Caio Marcelo de Oliveira Filho wrote: what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). Regarding animation/states: it seems like it's something to be implemented by specific styles and/or widgets. The idea here is to provide a Styling mechanism that is flexible enough to support whatever look and feel designers want. That includes animations, but no dedicated infrastructure was thought for that. the style shouldn't be more targeted about provide the right graphical elements? state tracking seems more a job for the populator if i understood correctly the first descryption of it? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change behaviour of 'Next Wallpaper Image' menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/#review4939 --- trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp http://reviewboard.kde.org/r/3529/#comment4398 this looks sensible, however is there any reason that this couldn't be put directly into nextSlide? would make the patch simpler and avoid similar problems in future. - Aaron On 2010-04-09 06:53:02, Reza Shah wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/ --- (Updated 2010-04-09 06:53:02) Review request for Plasma. Summary --- This patch change the behaviour of displaying wallpaper in slideshow mode. In old behaviour it's possible the next slide selected from 'Next Wallpaper Image' menu from context menu, will not be displayed in proper interval. So in new behaviour timer is stopped before advancing to next slide. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1112767 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1112767 Diff: http://reviewboard.kde.org/r/3529/diff Testing --- Thanks, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change behaviour of 'Next Wallpaper Image' menu
On 2010-04-09 16:03:45, Aaron Seigo wrote: at trunk nextSlide is called on timeout signal and 'next wallpaper image' context menu action. since the trigger of nextSlide coming from different source, so my idea was to add a simple guard to allow the wallpaper selected from 'Next wallpaper image' menu to be displayed on proper interval. looking at the source code again, it's possible to add the patch directly to nextSlide function like below: m_timer.stop(); renderWallpaper(current); m_timer.start(m_delay * 1000); but i'm not sure if this is better or not. - Reza --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/#review4939 --- On 2010-04-09 06:53:02, Reza Shah wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/ --- (Updated 2010-04-09 06:53:02) Review request for Plasma. Summary --- This patch change the behaviour of displaying wallpaper in slideshow mode. In old behaviour it's possible the next slide selected from 'Next Wallpaper Image' menu from context menu, will not be displayed in proper interval. So in new behaviour timer is stopped before advancing to next slide. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1112767 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1112767 Diff: http://reviewboard.kde.org/r/3529/diff Testing --- Thanks, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change behaviour of 'Next Wallpaper Image' menu
On 2010-04-09 16:03:45, Aaron Seigo wrote: Reza Shah wrote: at trunk nextSlide is called on timeout signal and 'next wallpaper image' context menu action. since the trigger of nextSlide coming from different source, so my idea was to add a simple guard to allow the wallpaper selected from 'Next wallpaper image' menu to be displayed on proper interval. looking at the source code again, it's possible to add the patch directly to nextSlide function like below: m_timer.stop(); renderWallpaper(current); m_timer.start(m_delay * 1000); but i'm not sure if this is better or not. it's fewer code paths to test and maintain which can't be a bad thing :) with that small change, please commit... - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/#review4939 --- On 2010-04-09 06:53:02, Reza Shah wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/ --- (Updated 2010-04-09 06:53:02) Review request for Plasma. Summary --- This patch change the behaviour of displaying wallpaper in slideshow mode. In old behaviour it's possible the next slide selected from 'Next Wallpaper Image' menu from context menu, will not be displayed in proper interval. So in new behaviour timer is stopped before advancing to next slide. Diffs - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.h 1112767 trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1112767 Diff: http://reviewboard.kde.org/r/3529/diff Testing --- Thanks, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Friday 09 April 2010, Markus wrote: Dear readers. I had some ideas how to possibly improve Plasma's netbook interface. ideas are always welcome :) (I published this set of suggestions also in my blog. Maybe it's easier to read there: http://kamikazow.wordpress.com/2010/04/09/plasma-netbook-mockup/ ) While my task within KDE is mainly to translate K3b, I see myself as a usability geek as well. So while cycling through parks in my hometown and enjoying the spring weather, I thought about improving the netbook experience. And while I continued to think about it Plasma applets I already know exist and how they could be incorporated and refined. I also remembered using classic Mac OS which featured a pointer-based GUI that was targeted at screens that have roughly the same proportions as today’s netbooks. I have to add that I don’t know how in what shape Plasma Netbook in current trunk is, so my suggestions may even already be obsolete. I also lack any talent to code, so obviously I’m hoping for an actual programmer to pick up my ideas. So, enough introduction talk. Let’s get started. Plasma Netbook how it looks today: http://kamikazow.files.wordpress.com/2010/04/netbook1.png Page One displays various Plasma applets in an aligned way. So overall I think this screenshot is pretty self explanatory. One aspect is worth pointing out: How task switching currently works. You click on the Running Apps button and get an Exposé view of all open windows. This IMHO has some drawbacks. A.) it requires compositing (not available to everyone) and B.) totally breaks down if many windows are open. Well, classic Mac OS had a simple drop-down list of running apps. Hardly fancy, but worked really well, so this is what I came up with: http://kamikazow.files.wordpress.com/2010/04/netbook2.png (No active app) right now, when compositing is off, exactly such a menu is displayed. i think however the exposè effect has more informational value, so i would keep the menu as fallback. i agree that the current effect is lacking, what would be nice is: layout as a grid when we are in netbook mode (will make the workspace kcm configure it as so) -having the possibility to scroll if too many windows are open (a crappy device is supposed to not have garzillions of apps open at the same time btw) -maybe a close button on the thumbnails I moved clock and tray to the far right where IMO it’s expected by many users anyway. Show all windows triggers the Exposé effect, so no functionality is lost. The menu could also be assigned to a keyboard shortcut. there was a reason for the strange layout we have now: the close and maximize buttons are epected to be at right, and i think it's really weird if as in your screenshot those buttons are separed from the applet that gives the title, even if they could mae sense at opposite sides of the screen. When an application runs, the top bar changes: http://kamikazow.files.wordpress.com/2010/04/netbook3.png (App active) On the left side is still the app switcher, but now also featuring the options to hide or quit the app (Quit and Show All maybe should switch positions). The button title switches to the app name to indicate what’s running. The pages bar is changed to the app’s menu bar. Plasma Netbook works in a similar fashion already, but by simply launching apps in full screen and hiding the window decoration. My proposal should look better esp. if smoothly transitioned from pages bar to menu bar (eg. using a slide effect). A similar menu bar is already implemented by Bespin’s XBar applet. http://kde-look.org/content/show.php/Bespin?content=63928 Another approach seems to be in development. http://mail.kde.org/pipermail/plasma-devel/2010-March/010989.html as discussed here some days ago, a menubar like that is quite challenging. and problem will be that probably only kde applications will be able to use it. it could make sense a layout like that, but i would like to have it really feasible witout being an hack like is now. On the far left side, window control buttons move clock and tray. I figured that in this case it’s more important to keep users’ muscle memory for window operations intact rather than tray interaction. The window controls are what we are all used to: Minimize/Hide — Unmaximize — Close. It can be argued that netbook users should run their application always in full screen anyway, but this would effectively kill the usage of multi-window apps. I also saw several people connect bigger screens at home to their netbooks. An unmaximized window can more easily be moved to the other screen. That feature is also already developed. http://majewsky.wordpress.com/2010/03/29/blog-relaunch-update-on-kwin-butt on- applet/ i am really on the fence right now between splitting the window controls from the title/switcher applet or not. both have advantages, but having controls for the current window in two
Re: Plasma-Netbook Mockups
Thanks for your comments. I'd like to further share my reasons for the decisions. Am Freitag 09 April 2010 19:59:28 schrieb Marco Martin: i think however the exposè effect has more informational value As someone who used Mac OS X for years, I know Exposé inside out. I also know that when I wanted to switch whole apps (even if it were only three or so) with many windows, the practical aspect shrunk. I also remember that using it with a touchpad only was very cumbersome. My reason for including both -- Exposé and menu -- was that the user can adapt his/her workflow according to the attached input devices rather than the capabilities of GPU and drivers. a crappy device is supposed to not have garzillions of apps open at the same time btw Well, it's not our decision what the user runs, right? ;-) Today's netbooks are more powerful than the iBook I bought 6 years ago and I've seen market data that indicates that not so few people buy netbooks as their only PCs and even Atom CPUs advance. Who knows how powerful these machines get 2 years from now. That's why I thought that the user should still be able to conveniently switch between 10 apps that add to 50 windows -- whether we think it's a good idea or not. there was a reason for the strange layout we have now: the close and maximize buttons are epected to be at right, Correct me if I'm wrong but from everything I saw of Plasma Netbook, there weren't any close or maximize buttons at all. and i think it's really weird if as in your screenshot those buttons are separed from the applet that gives the title, even if they could mae sense at opposite sides of the screen. Given that it's all Plasma, I thought that all positions can be changed anyway if the user decides. I also thought to mirror Mac OS 9's layout where the close button was on the left and a similar menu was on the right. http://wrds.files.wordpress.com/2007/04/mac_os_9_screenshot_2.png The main point on my mockups were not to present the ultimate applet positions, but instead a feature set I believe would be beneficial to have available in the default setup of Plasma Netbook. as discussed here some days ago, a menubar like that is quite challenging. and problem will be that probably only kde applications will be able to use it. I remember a blog posting by some Chinese KDE contributor (who also wrote a Scim-based input method panel for Plasma) that he modified Xbar to be compatible with GNOME/GTK applications. That was one, two or so years ago, though. having controls for the current window in two opposite parts of the screen really looks strange to me. It's just a thing of getting used to. In the early 2000s I used BeOS (dual boot with Win98) at home and occasionally Mac OS 9 at work. Both share the concept to separate window size modification (Zoom and on OS9 also Window Shade) from the Close button. This was something I could adapt to within minutes. And as I said: My mockups don't have the goal to hinder users to rearrange the Plasmoids on the bar. Bye ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
Written by MoRpHeUz — April 9, 2010 @ 19:01: Hi! Regarding some points: – Exposè vs List of Windows A) Most (if not all) netbooks today have a graphics card capable of doing composite. Graphic cards: Yes. Drivers: Not often. There were several announcements of ARM-based netbooks. Is any of the current drivers even compatible with GPUs that work in conjunction with ARM CPUs? Does Nouveau work with Tegra for example? I tried to look it up a while ago and found nothing. And if composite is not available, it fallbacks exactly to a list of windows, so it seems that your idea is “quite already implemented”. I on purpose made my menu switch between apps and not individual windows. B) From our research with users, they usually do not open that many applications on a netbook. Certainly possible. Your research is likely better than my limited research using a handful of netbook owners and some market statistic about people who replace their PCs with netbooks. One of the goals of my proposal was to enable easier switching between many apps without hurting the work flow for users who don't run many apps. However if this happens, then it would be a good idea to think about a good solution for “too many windows” and Exposè effect. – Titlebar Without closing the application, from your mockup there is no way to switch between activities without closing the application as the app’s menu is using the panel. If by activities you mean the pages? Well, the app doesn't need to be closed in that case, only hidden/minimized. My rationales: A.) Vertical space is more important than switching pages if one application has focus. B.) Netbooks are probably usually used for single apps in full screen. My proposal was made on this assumption, even though I'd like to enable users to switch between 10 apps if they choose to run that many. Just now I had another idea: Wouldn't it be possible to implement multitouch gestures on touchpads that support them? Eg swipe left/right to switch between activities/pages? What if I open an application that has a lot of menu options ? What should we do in this case ? Same as with normal windows of Qt apps: Show an expander. Apple “fixes” this on OSX limiting the number of menu options that one can create. The window’s actions on the right are already implemented as a plasmoid and there is no need to show the minimize button: if you want to switch between applications you just do it, if you want to go to an activity you just use the panel for that and if you want to close, the button is there. In your mockup you’re duplicating the functionality: the same action can be triggered by the list of windows and in the right side of the panel. No, it's not duplication. Here's why: In my proposal the menu allows to hide the whole application = all windows at once. The Minimize button only hides the active window. If you're running only single-window apps, it does not make a difference, but if an app has multiple windows, it is a difference. – Bigger screens vs Average netbook user In our research with *average* netbook users (not geeks), they usually don’t connect output monitors/keyboards and specially they don’t do much multitasking (when they do, the applications are always maximized anyway). I'm not arguing against your research. My proposal is not targeted against them, but just a collection of ideas that aims to make it easier if one user decides to either connect external monitors and/or do more multitasking. Btw, I know no geek with a netbook. Are geeks even allowed to posses such things? :-) That’s why we took the path of making all applications to run maximized too. This came from user feedback. In my proposal all apps are fullscreen by default as well. One thing that we could improve, is the ability to switch to a regular Plasma desktop view if there is a monitor plugged in, as this is the case where you have a bigger place to do your mess A fried of mine (non-geek) uses such a setup and in fact she's the reason why I even started to think about Plasma Netbook. The built-in screen is 10 inches or so and her traditional GNOME layout totally cramps the screen. The external 22 inch screen OTOH is almost empty. Then I asked myself what could be done to still use the small screen effectively and make it easy to move windows to the big screen. I think my proposal helps some people while OTOH hurting no one. That said, it's difficult to know without actually trying this out and I only have a 15,4 notebook, so I couldn't try my own proposal even if someone implemented it... :-( ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Friday 09 April 2010, Markus wrote: Thanks for your comments. I'd like to further share my reasons for the decisions. Am Freitag 09 April 2010 19:59:28 schrieb Marco Martin: i think however the exposè effect has more informational value As someone who used Mac OS X for years, I know Exposé inside out. I also know that when I wanted to switch whole apps (even if it were only three or so) with many windows, the practical aspect shrunk. I also remember that using it with a touchpad only was very cumbersome. My reason for including both -- Exposé and menu -- was that the user can adapt his/her workflow according to the attached input devices rather than the capabilities of GPU and drivers. a crappy device is supposed to not have garzillions of apps open at the same time btw Well, it's not our decision what the user runs, right? ;-) Today's netbooks are more powerful than the iBook I bought 6 years ago and I've seen market data that indicates that not so few people buy netbooks as their only PCs and even Atom CPUs advance. Who knows how powerful these machines get 2 years from now. as Artur said, tests with joe sixpack users is quite rare. other users can add a real taskbar or use a desktop shell, if their use of the device is actually what would be a desktop (since the use case of the netbook shell is quite different) i could mke configurable to always use the list, however. That's why I thought that the user should still be able to conveniently switch between 10 apps that add to 50 windows -- whether we think it's a good idea or not. there was a reason for the strange layout we have now: the close and maximize buttons are epected to be at right, Correct me if I'm wrong but from everything I saw of Plasma Netbook, there weren't any close or maximize buttons at all. no buttons when plasma itself is focused, they appear when an application is focused and i think it's really weird if as in your screenshot those buttons are separed from the applet that gives the title, even if they could mae sense at opposite sides of the screen. Given that it's all Plasma, I thought that all positions can be changed anyway if the user decides. I also thought to mirror Mac OS 9's layout where the close button was on the left and a similar menu was on the right. http://wrds.files.wordpress.com/2007/04/mac_os_9_screenshot_2.png at the moment no, because the close/maximize and the title are the same applet Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
I had commented on the original blog archive, and I'll continue discussion here. Well, maybe I'm an exception, but I don't follow the netbook users run a single application at a time. For instance, many times I have firefox, dolphin, konsole, amarok, gimp (yes, gimp, with a wacom tablet attached) running at the same time in a 10.2 netbook, with 1024x600 resolution and 2GB RAM. And it works well with Kubuntu Lucid beta. Here is an explanation for the points i've stated in that comment: * I'd rather have a task manager which shows only icons for background apps and the title and maximize / restore buttons for the foreground app replacing the current activity switcher, which takes more than half of the available screen width. And I agree with Markus that the clock should be by default in the extreme right side. It's where users of all platforms expect to see a clock and a system tray. Also, in the current form, depending on the window title length, the clock position changes, and keeps jumping when switching applications. * About the single / double click: Search and Launch is there basically replacing the menu. It doesn't makes sense to make it honor the single / double click settings, which is supposed to be to navigate in files. In files, 1 click selects, 2 clicks open. In the SAL, 1 click does nothing. Having it honoring the setting is just like making Kickoff requiring double clicks to navigate in menus. This is the same complaint I have with system settings: if I choose double clicks to navigate in files, the system settings also requires double clicks. * About the texts in SAL: if someone which has never seen it is shown just a screenshot, like the first one presented in the article (http://kamikazow.wordpress.com/2010/04/09/plasma-netbook-mockup), he sees some icons on top, a search box, some other icons and widgets at the bottom. There is no obvious statement that: these are the favorites, here are the applications, and so on. On Kickoff, there's the Favorites and Applications tab. The ubuntu netbook remix has the sections on the left side. Having such an indication would be more intuitive. Perhaps, I'm thinking that having an intermediate solution, with just borderless maximized windows (which currently can be set via config file), that hacked task manager and a default kickoff menu would be perfect for netbooks... -- Luis Fernando Planella Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Friday 09 April 2010, Markus wrote: Written by MoRpHeUz — April 9, 2010 @ 19:01: Hi! Regarding some points: – Exposè vs List of Windows A) Most (if not all) netbooks today have a graphics card capable of doing composite. Graphic cards: Yes. Drivers: Not often. There were several announcements of ARM-based netbooks. Is any of the current drivers even compatible with GPUs that work in conjunction with ARM CPUs? Does Nouveau work with Tegra for example? I tried to look it up a while ago and found nothing. And if composite is not available, it fallbacks exactly to a list of windows, so it seems that your idea is “quite already implemented”. I on purpose made my menu switch between apps and not individual windows. well, it's not really easy to identify what windows belong to the same app, that's one of the reasons the taskbar in plasma-desktop right now lists windows, and they are grouped by name, that is an heuristic that may or may not be the correct B) From our research with users, they usually do not open that many applications on a netbook. Certainly possible. Your research is likely better than my limited research using a handful of netbook owners and some market statistic about people who replace their PCs with netbooks. One of the goals of my proposal was to enable easier switching between many apps without hurting the work flow for users who don't run many apps. However if this happens, then it would be a good idea to think about a good solution for “too many windows” and Exposè effect. – Titlebar Without closing the application, from your mockup there is no way to switch between activities without closing the application as the app’s menu is using the panel. If by activities you mean the pages? Well, the app doesn't need to be closed in that case, only hidden/minimized. My rationales: A.) Vertical space is more important than switching pages if one application has focus. B.) Netbooks are probably usually used for single apps in full screen. My proposal was made on this assumption, even though I'd like to enable users to switch between 10 apps if they choose to run that many. Just now I had another idea: Wouldn't it be possible to implement multitouch gestures on touchpads that support them? Eg swipe left/right to switch between activities/pages? no multitouch on X for now. What if I open an application that has a lot of menu options ? What should we do in this case ? Same as with normal windows of Qt apps: Show an expander. Apple “fixes” this on OSX limiting the number of menu options that one can create. The window’s actions on the right are already implemented as a plasmoid and there is no need to show the minimize button: if you want to switch between applications you just do it, if you want to go to an activity you just use the panel for that and if you want to close, the button is there. In your mockup you’re duplicating the functionality: the same action can be triggered by the list of windows and in the right side of the panel. No, it's not duplication. Here's why: In my proposal the menu allows to hide the whole application = all windows at once. The Minimize button only hides the active window. If you're running only single-window apps, it does not make a difference, but if an app has multiple windows, it is a difference. right no you don't have a minimize button at all in netbook mode: if there is no taskbar and if the desktop can be selected as any other window, the minizmize button has exactly no use. – Bigger screens vs Average netbook user In our research with *average* netbook users (not geeks), they usually don’t connect output monitors/keyboards and specially they don’t do much multitasking (when they do, the applications are always maximized anyway). I'm not arguing against your research. My proposal is not targeted against them, but just a collection of ideas that aims to make it easier if one user decides to either connect external monitors and/or do more multitasking. Btw, I know no geek with a netbook. Are geeks even allowed to posses such things? :-) That’s why we took the path of making all applications to run maximized too. This came from user feedback. In my proposal all apps are fullscreen by default as well. One thing that we could improve, is the ability to switch to a regular Plasma desktop view if there is a monitor plugged in, as this is the case where you have a bigger place to do your mess A fried of mine (non-geek) uses such a setup and in fact she's the reason why I even started to think about Plasma Netbook. The built-in screen is 10 inches or so and her traditional GNOME layout totally cramps the screen. The external 22 inch screen OTOH is almost empty. Then I asked myself what could be done to still use the small screen effectively and make it easy to move windows to the big screen.
Re: Plasma-Netbook Mockups
The window’s actions on the right are already implemented as a plasmoid and there is no need to show the minimize button: if you want to switch between applications you just do it, if you want to go to an activity you just use the panel for that and if you want to close, the button is there. In your mockup you’re duplicating the functionality: the same action can be triggered by the list of windows and in the right side of the panel. No, it's not duplication. Here's why: In my proposal the menu allows to hide the whole application = all windows at once. The Minimize button only hides the active window. If you're running only single-window apps, it does not make a difference, but if an app has multiple windows, it is a difference. while I can see this being handy for something like Qt Designer, it'd be a PITA for something like a web browser or okular. I don't care that all my .pdf files are open in something called Okular, I care about getting to the document about magical ponies :) and guess which sort of app Joe Sixpack is more likely to be using... -- 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: Plasma-Netbook Mockups
On Friday 09 April 2010, 17:57 Luis Fernando Planella Gonzalez wrote: Well, maybe I'm an exception, but I don't follow the netbook users run a single application at a time. For instance, many times I have firefox, dolphin, konsole, amarok, gimp (yes, gimp, with a wacom tablet attached) running at the same time in a 10.2 netbook, with 1024x600 resolution and 2GB RAM. And it works well with Kubuntu Lucid beta. Yep, you're an exception :) You're a geek using a netbook. Average users doesn't have this many applications open at the same time, specially because netbooks are awesome for consuming content, but horrible for creating them. That doesn't mean that there aren't people out there (like you :) ) that can handle these tasks. For you I would just recommend the regular Plasma Desktop or that you tune Plasma Netbook. * I'd rather have a task manager which shows only icons for background apps and the title and maximize / restore buttons for the foreground app replacing the current activity switcher, which takes more than half of the available screen width. And I agree with Markus that the clock should be by default in the extreme right side. It's where users of all platforms expect to see a clock and a system tray. Also, in the current form, depending on the window title length, the clock position changes, and keeps jumping when switching applications. The clock point is a valid one that we must deal, but the task manager solution you're proposing just doesn't solve the main issue. That's why we are using Exposè for showing your tasks. Where your I mean the average user and not someone who has firefox, dolphin, konsole and gimp open (average users doesn't even want to know what konsole is. Average users are my mother, your grandmother, etc... not us ;) ). * About the single / double click: Search and Launch is there basically replacing the menu. It doesn't makes sense to make it honor the single / double click settings, which is supposed to be to navigate in files. In files, 1 click selects, 2 clicks open. In the SAL, 1 click does nothing. Having it honoring the setting is just like making Kickoff requiring double clicks to navigate in menus. This is the same complaint I have with system settings: if I choose double clicks to navigate in files, the system settings also requires double clicks. The icons are just shortcuts if you like the regular menu. The first rule of SAL is to be a nice way to use KRunner where Marco's mom doesn't need to know that the web browser calls firefox or arora but she can just type web browse and then it's offered to her a list of applications. And this 1 click does nothing is probably just a bug. Just 1 clicking any item on SAL activates it here. * About the texts in SAL: if someone which has never seen it is shown just a screenshot, like the first one presented in the article (http://kamikazow.wordpress.com/2010/04/09/plasma-netbook-mockup), he sees some icons on top, a search box, some other icons and widgets at the bottom. There is no obvious statement that: these are the favorites, here are the applications, and so on. On Kickoff, there's the Favorites and Applications tab. The ubuntu netbook remix has the sections on the left side. Having such an indication would be more intuitive. +1 here. We can find a way of making it easier to discover what which area of SAL is meant for. Perhaps, I'm thinking that having an intermediate solution, with just borderless maximized windows (which currently can be set via config file), that hacked task manager and a default kickoff menu would be perfect for netbooks... That's what your needs are :) Maybe that's what you should do because for your workflow this is just the better solution. What we are proposing with Plasma Netbook is a solution for average users of netbooks: moms, fathers, grandfathers, sons, etc... It's even interesting that geeks get/doesn't get something about the UI that this kind of users just accept and it works very well for them (just check the example of P man using the netbook interface in plasma-devel archive). Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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: Plasma-Netbook Mockups
On Friday 09 April 2010, Luis Fernando Planella Gonzalez wrote: I had commented on the original blog archive, and I'll continue discussion here. Well, maybe I'm an exception, but I don't follow the netbook users run a single application at a time. For instance, many times I have firefox, dolphin, konsole, amarok, gimp (yes, gimp, with a wacom tablet attached) running at the same time in a 10.2 netbook, with 1024x600 resolution and 2GB RAM. And it works well with Kubuntu Lucid beta. Here is an explanation for the points i've stated in that comment: * I'd rather have a task manager which shows only icons for background apps and the title and maximize / restore buttons for the foreground app replacing the current activity switcher, which takes more than half of the available screen width. And I agree with Markus that the luckily, everything is customizable, and is possible to have a regular taskbar there clock should be by default in the extreme right side. It's where users of all platforms expect to see a clock and a system tray. Also, in the current form, depending on the window title length, the clock position changes, and keeps jumping when switching applications. nope, it's in a fixed position in trunk. the point is that the close button has to be up there, because an action (that is always here) to be in th corner of the screen, it wins against a clock that has a content merely informational * About the single / double click: Search and Launch is there basically replacing the menu. It doesn't makes sense to make it honor the single / double click settings, which is supposed to be to navigate in files. In files, 1 click selects, 2 clicks open. In the SAL, 1 click does nothing. Having it honoring the setting is just like making Kickoff requiring double clicks to navigate in menus. This is the same complaint I have with system settings: if I choose double clicks to navigate in files, the system settings also requires double clicks. that is a bug and will be fixed :) * About the texts in SAL: if someone which has never seen it is shown just a screenshot, like the first one presented in the article (http://kamikazow.wordpress.com/2010/04/09/plasma-netbook-mockup), he sees some icons on top, a search box, some other icons and widgets at the bottom. There is no obvious statement that: these are the favorites, here are the applications, and so on. On Kickoff, there's the Favorites and Applications tab. The ubuntu netbook remix has the sections on the left side. Having such an indication would be more intuitive. there could be labels, however after they make discover what thise are are for (the first uhm, 3 seconds of use), they become just wasted space and visual noise -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Friday 09 April 2010, Artur Souza (MoRpHeUz) wrote: The clock point is a valid one that we must deal, but the task manager solution you're proposing just doesn't solve the main issue. That's why we are using Exposè for showing your tasks. Where your I mean the average user and not someone who has firefox, dolphin, konsole and gimp open (average users doesn't even want to know what konsole is. Average users ..let alone what they think a gimp is :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
Am Freitag 09 April 2010 23:10:48 schrieb Chani: while I can see this being handy for something like Qt Designer, it'd be a PITA for something like a web browser or okular. Web browsers and Okular are single-window apps by design. Sure, you can show more than one window at the same time, but usually those do not need to be shown at the same time. So with only a single document being displayed and the netbook GUI defaulting to fullscreen app execution anyway, in those cases the Minimize button and the Hide menu do the same thing: Hide the current window and showing the Newspaper activity. I don't know about Qt Designer -- I was more thinking about GIMP and such. In some cases websites spawn small popup windows, often resulting in interaction with the smaller windows having effects on the main window (eg. a web forum opens a new login window). Both in this case and GIMP-like apps, the smaller windows are clearly connected to. I don't care that all my .pdf files are open in something called Okular, I care about getting to the document about magical ponies :) and guess which sort of app Joe Sixpack is more likely to be using... Maybe I'm spoiled by my Mac experience, but I can't remember that Mac OS (X) was ever regarded as geek-only platform. On the contrary: Mac OS X is usually highly praised for its high usability up to a point where trolls call it a girl and gay platform, because it's so easy and real men use Windows. OSX too has the metaphor to minimize individual windows, hide the whole app and even the option to hide all non-focused apps. While I don't claim to have infinite wisdom ;-), I've used Mac OS X for 3 or 4 years, many versions of Windows, BeOS, and since 2 or 3 years KDE/Linux pretty much exclusively (and occasionally before then) and hence think that I know a broad spectrum of GUIs and think that I'm able to spot GUI features that are good. :-p ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Fri 9 April 2010 2:08:48 pm Marco Martin wrote: no multitouch on X for now. Synaptic touchpad driver worked though. I had an old shell script which implemented similar things using synclient on my eeepc. swipe with two fingers to change desktop -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == 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: Plasma-Netbook Mockups
Am Freitag 09 April 2010 23:08:48 schrieb Marco Martin: well, it's not really easy to identify what windows belong to the same app, that's one of the reasons the taskbar in plasma-desktop right now lists windows, and they are grouped by name, that is an heuristic that may or may not be the correct Ugh. I thought in times of dbus such evil hacks are no longer needed. ;-) Just now I had another idea: Wouldn't it be possible to implement multitouch gestures on touchpads that support them? Eg swipe left/right to switch between activities/pages? no multitouch on X for now. And as an idea for the future? right no you don't have a minimize button at all in netbook mode: if there is no taskbar and if the desktop can be selected as any other window, the minizmize button has exactly no use. Right. well, dragging a window to the other screen is quite easy :) (interestingly enough, one could also experimen on running plasma desktop on the second monitor and netbook on the little one, if the computer is powerful enough... Is this possible? Surely as different X screens, but within one session? xephyr, virtualbox.. way suboptimal but gives an idea I also get a rough idea by launching plasma-netbook on my notebook. I meant a real-world scenario with an actual netbook and an external monitor. I don't think my friend lets me abuse her netbook for my experiments. :-p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-Netbook Mockups
On Friday 09 April 2010, 18:57 Markus wrote: Maybe I'm spoiled by my Mac experience, but I can't remember that Mac OS (X) was ever regarded as geek-only platform. On the contrary: Mac OS X is usually highly praised for its high usability up to a point where trolls call it a girl and gay platform, because it's so easy and real men use Windows. OSX too has the metaphor to minimize individual windows, hide the whole app and even the option to hide all non-focused apps. But they still dropped it for the iPhone and even for the iPad ;) Desktops and netbooks and mobiles are different beasts and that's the whole point, right ? Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- 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: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Wed, Apr 7, 2010 at 7:18 AM, Caio Marcelo de Oliveira Filho caio.olive...@openbossa.org wrote: Marco Martin notm...@gmail.com writes: Hello Marco, on one hand, i feel in order to succeed the normal qwidgets need to use this (so until qt5 their api would be a mis of model and view related stuff), but this brings to the question: what about subclasses of qwidgets that subclassed it for functionality? (i.e. kpushbutton) The current KPushButton would not be affected as there will not be a break in Qt's binary compatibility. See below if you were talking about migrating the current KPushButton to the new approach. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. uh, so would be the primitive qobjects? Yes, they have to be at least QObjects because we want to make use of properties and notify signals in those models. Note that this is the point of view of the Style, for the Style class, its really not important the exact type here, only that it is a QObject. The fact that it has a more specific type may or may not be important, if you are populating your widget with a QML component, it isn't, you simply will load the Button.qml with a property 'model' available and put the model there. However, if you're building a C++-based style, you can either use just the QObject interface, or (in the case of our populator system) cast the correct type of the Model that you expect from that widget type. who would decide what the binding is? The Style. That has to do with look and feel, only the Style knows which primitives should react to changes in the widget/model. And also which primitives should affect the model and widget (the MouseArea for instance). It's a sane approach, however, my concern is how it goes together everything it exists right now: as i said many qwidget are subclassed for a mix of look and functionality requirements, so while wouldn't be possible to change kpushbutton and the likes to the new system overnight, even if it wouldn't be necessary to do big binary incompatible changes. i don't have clear answers, but it should be done in the way it would provide the smootherst transition path compared to what we have now Our proposal suggests that widgets are implemented in a way that the logic parts are separated. This logic parts of widgets can be reused internally by existing Qt4 QWidgets -- some of those parts even can be extracted from the Qt4 QWidgets themselves. Those parts, if made public, could be used internally by KWidgets as well. Imagine a QButtonModel, that could be extended with more functionality (let's say, KAuth integration) and a KButtonModel could be created. This KButtonModel could be used as implementation detail of both KPushButton and Plasma::PushButton. We understand that this by itself already is a good thing for KDE, that uses the entire KPushButton to get the behaviour for Plasma::PushButton. Even better, if a new environment appear (let's say, Qt make a new canvas or this new Style approach in a future version of Qt), will be easy to just reuse the logic in KButtonModel. For the Style part, we are not so sure if today's QWidget can benefit from that, but we are trying to propose something that minimize (and in some cases even reduce to zero) the need of redoing it all over again for the next Canvas. The graph scene assumption that is in the Style proposal probably will be still appliable in the next Canvas, so even if the basic types change, the core of a Style (and of the widgets visual parts) can still be easily portable. Hope that it clarified a little bit the issue. Glad to hear that is exactly the idea i had back in January...I think I talked about it to Marius, Artur and Gabriel. Dude seriously I need to come to Recife! Cheers, -- Caio Marcelo de Oliveira Filho OpenBossa - INdT ___ 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: Plasma-Netbook Mockups
Am Samstag 10 April 2010 00:12:00 schrieb Artur Souza (MoRpHeUz): But they still dropped it for the iPhone and even for the iPad ;) Both are touch-based devices and almost everybody who these days develops GUIs for such devices gets more than only inspiration from Apple. Desktops and netbooks and mobiles are different beasts and that's the whole point, right ? Compare Apple's early PowerBooks (eg. http://en.wikipedia.org/wiki/File:Powerbook_duo_2300c.jpg ) to a modern netbook: No, not different at all (from a usability standpoint): 9 screen for display and keyboard + touchpad for input. If sold today, everybody would call them netbooks. I'm not saying that Apple has to be copied at all costs. No. I'm merely suggesting that some conventions that were researched over years could be adapted. That's all. :-) And if you all say Bah, your ideas suck. IT stone age's over., then I'm fine with it as well. :-) I just reply to almost every mail, because I simply don't want to be misunderstood. :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Change behaviour of 'Next Wallpaper Image' menu
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3529/ --- (Updated 2010-04-10 01:49:31.072417) Review request for Plasma. Changes --- apply the patch only inside nextSlide() function. Summary --- This patch change the behaviour of displaying wallpaper in slideshow mode. In old behaviour it's possible the next slide selected from 'Next Wallpaper Image' menu from context menu, will not be displayed in proper interval. So in new behaviour timer is stopped before advancing to next slide. Diffs (updated) - trunk/KDE/kdebase/workspace/plasma/generic/wallpapers/image/image.cpp 1113111 Diff: http://reviewboard.kde.org/r/3529/diff Testing --- Thanks, Reza ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
