Re: Breadcrumbs in Kickoff
On Wednesday, December 28, 2011 09:42:35 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Yes and that's why I moved it to the left in the new implementation. note that this then puts it in a different location to all the other headers in the other tabs. so you switch from Favourites to Applications - header switches location. Applications to System - header swtiches location again. if the breadcrumbs are moved to the left and/or get a specialized visual treatment (neither of which are bad ideas imho) then the other headers should similarly be adjusted for consistency across the tabs. -- 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 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: Kickoff-QML and classic launcher
On Saturday, December 24, 2011 03:21:07 Kevin Kofler wrote: Martin Graesslin wrote: * Would it be acceptable to drop the classic menu completely? This would be more consistent with the general concept of having only one applet per area. Optionally the classic menu could be re-added in Plasma-Addons just like Lancelot. You can pry my classic menu from my cold, dead hands! while i appreciate humour and energetic discussion, this gets really close to falling into the category of contentless input presented in a confrontational manner. to remind everyone: please participate constructively and ensure your input is more than one-liner zingers, grumpiness and/or repeatition of whinging. thanks ... -- 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 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: Kickoff-QML and classic launcher
On Saturday, December 24, 2011 03:29:19 Kevin Kofler wrote: Aaron J. Seigo wrote: it's really a horrible hack and i'd suggest getting rid of it. people can add the classic menu from the widget explorer like all the rest. This is just going to make it much harder to switch to a menu people like me can actually use. :-( Especially for people switching to Plasma from other environments still using old-school menus, this will make it harder for them to get started. the assumption here is that not enabling the classic menu is a dead stop preventer from using Plasma Desktop at all for a significant enough number of people that it must be made so simple that even violating the rest of the UI consistency and guidelines is ok. that assumption seems weak and i have not seen evidence to back it. yes, people who like the classic menu are loud and provide feedback. however, it's usually of the overly aggressive get off my lawn! type and that leads me to believe it is not a mainstream need. looking at people's desktops as i travel from event to event around the world, it also seems that this is not a widely used option. as it completely violates the UI consistency, it should therefore be removed. And I'm not at all convinced that a UI which replaces the entire panel with a different template which happens to include a different menu is a good UI to replace that. seeing as for most people who wish this configuration also want things like win98-style icons on the desktop by default (again, this is based on feedback) and other similar make it like win98 tweaks, this is likely going to save such individuals a TON of time on first set up. it is also on first set up that this gets done, so other tweaks and set up is unlikely to be at risk. if we really are concerned about this, however, the javascript framework is more than flexible enough to accomodate such a use case. it just doesn't seem necessary given the real world usage. -- 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 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: Kickoff w/Breadcrumbs in QML
On Friday, December 23, 2011 13:15:22 Xavier Sythe wrote: Just to confirm, does the QML Kickoff still have keyboard navigation? I think that it would be a good idea to not only add support for a mouse's back button, but also the standard backspace key on keyboards. This would enable full navigation of Kickoff solely with the keyboard, a feature which, until now, has been limited by the lack of a back button shortcut. yes, it should be fully keyboard navigable. and btw, i'm tired of these discussions of the back button. if they are continuing in a week from now without being accompanied by patches to Martin's QML branch, i will start moderating the list to weed them out. :) As for the UI back button, Novell's usability team did determine that it was needed. Who are we, as non-UX professionals, to argue against this decision? *sigh* so, while not a UX professional in terms of having a degree behind it, i have what i like to think of as a reasonable amount of experience in these matters. i could point out a few things in Active, for instance, that would be different had i not weighed in, with reasons provided, with adjustments that went against the original UX pro's recommendations which, upon user testing, turned out better. i'm not a noob, and there are others here with increasing skills in this area as well. furthermore, this study was done some years ago. these trends shift (see the impact the web has had on UIs in general in the last 5-8 years, or mobile in the last 2-3). and there is often more than one good answer. while i love research and reallye njoy working with UX people, i also dislike the concept that they are untouchable high priests of the UI. in fact, i often find UX people have a blind spot for aesthetics and an emphasis on the theoretical over the practical. so ... everything with moderation. included in Plasma by default. Available from KDE-Look, certainly, but KDE3's days were long ago. we have people asking for it, and it's a feature we can add easily enough. -- 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 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: Geolocation DataEngine broken?
On Monday, December 26, 2011 15:51:33 Luca Beltrame wrote: What should be done? Disable the non-gpsd part of the geolocation dataengine, or find a different solution? As mgraesslin noted on IRC, this issue will also affect *all* released versions of plasma so far. best solution: * fix the dataengine * make it use JS for interacting with the web service so we can easily update it via synchrotron, including older (in the future ;) releases. -- 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 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: Re: Geolocation DataEngine broken?
In data sabato 31 dicembre 2011 09:45:37, Aaron J. Seigo ha scritto: * fix the dataengine This poses the problem that the current service used by the dataengine now requires an API key to operate, and in turn requires a signup. Probably a different service is required. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: Re: Breadcrumbs in Kickoff
On Saturday 31 December 2011 09:30:25 Aaron J. Seigo wrote: On Wednesday, December 28, 2011 09:42:35 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Yes and that's why I moved it to the left in the new implementation. note that this then puts it in a different location to all the other headers in the other tabs. so you switch from Favourites to Applications - header switches location. Applications to System - header swtiches location again. if the breadcrumbs are moved to the left and/or get a specialized visual treatment (neither of which are bad ideas imho) then the other headers should similarly be adjusted for consistency across the tabs. so far I synchronized the position with other Plasma elements and moved the headers into the center. Personally I would prefer to have a consistent UI throughout all Plasma elements (at least for the default shipped widgets). So the question is whether the breadcrumbs need to be moved from Left to Center. I will give that a try, but are not sure whether it is a good idea as it causes changes when traversing the menu. Cheers Martin 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: question about panel size guideline
On Tuesday, December 27, 2011 21:16:19 Reza Shah wrote: Hi, While doing bug triaging, i found some bugs related to the panel behavior or property. so, do we have some guideline regarding the panel for example: - minimum size or maximum size max size is currently 1/3rd of the screen min size is currently 16px. - behavior of each component put inside panel when panel grow or shrink they must shrink down to an appropriate size (this can include hiding/showing parts of the UI) and/or or become a popup when there is not enough room. the system tray currently violates this as the xembed icons have a set minimum size that we can do very little about as they are out of process embedded windows. probably all xembed icons should be moved to the hidden area when the area allow for the tray is less than the height/width of an xembed entry. the tasks widget similarly does not scale visually down below 22px very nicely. the count below the arrow on groups is too tall, the frame too thick on small panels. -- 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 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: QML plasmoid porting status needs updating?
The optimal solution would be qml imports for klocale and kcalendarsystem, only qobject no graphics elements at all and then a qml only component for the calendar that can be put in an advanced component set (many of the stuff in mobilecomponents is not really mobile but should go there as well) On 12/31/11, Viranch Mehta viranch.me...@gmail.com wrote: On Fri, Dec 30, 2011 at 10:03 PM, Mark mark...@gmail.com wrote: Aren't the Digital Clock and Calendar one big element? Yes, Calendar is used in Digital Clock and Analog Clock and that's where I'm somewhat stuck now. It all depends on KLocale and KCalendarSystem. I still have to see how to get those into QML. Viranch ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
OpenGL and Plasma::Wallpaper
Is there a way to use opengl in a Plasma::Wallpaper. Maybe by passing a opengl surface to QPainter then having Plasma::Wallpaper display it or does the Plasma::Wallpaper except opengl calls? Thanks for your thoughts. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix plasma popup alignment
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103595/ --- Review request for Plasma. Description --- Right-aligned popups are one pixel away from right edge of the screen and top-aligned popups (when the panel is on top) are one pixel inside panel. This is because the bug in QRect, where right() and bottom() value return value that is less than the true value by one. This is a feature-bug that Qt developers aren't going to fix because of compatiability reasons. My patch replaces rect.right() and rect.bottom() with (rect.x() + rect.width()) and (rect.y() + rect.height()) respectively. Diffs - plasma/corona.cpp 366a9df Diff: http://git.reviewboard.kde.org/r/103595/diff/diff Testing --- Works as expected. Thanks, Nikita Churaev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix bug https://bugs.kde.org/show_bug.cgi?id=270252
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103597/ --- Review request for Plasma. Description --- For some reason, QGraphicsView must be focused too for its children to receive events. Diffs - plasma/desktop/shell/controllerwindow.cpp 6f3064f Diff: http://git.reviewboard.kde.org/r/103597/diff/diff Testing --- Works as expected. Thanks, Nikita Churaev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix bug https://bugs.kde.org/show_bug.cgi?id=270252
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103597/ --- (Updated Dec. 31, 2011, 7:27 a.m.) Review request for Plasma. Description (updated) --- For some reason, QGraphicsView must be focused too for its children to receive events. This however looks hacky. Please explain why it works to me. Diffs - plasma/desktop/shell/controllerwindow.cpp 6f3064f Diff: http://git.reviewboard.kde.org/r/103597/diff/diff Testing --- Works as expected. Thanks, Nikita Churaev ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OpenGL and Plasma::Wallpaper
On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Is there a way to use opengl in a Plasma::Wallpaper. Maybe by passing a opengl surface to QPainter then having Plasma::Wallpaper display it or does the Plasma::Wallpaper except opengl calls? You could do the same as the GLApplet [1] does: paint to a PBO or FBO, convert it to QImage and render the image. But this looks like a memory intensive operation and probably not a good idea. My recommendation would be to wait till we have QML 2 where everything is done in OpenGL :-) Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Cheers Martin [1] https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/plasma/glapplet.cpp 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: Kickoff-QML and classic launcher
On Saturday 31 December 2011, Aaron J. Seigo wrote: that assumption seems weak and i have not seen evidence to back it. yes, people who like the classic menu are loud and provide feedback. however, it's usually of the overly aggressive get off my lawn! type and that leads me to believe it is not a mainstream need. looking at people's desktops as i travel from event to event around the world, it also seems that this is not a widely used option. as it completely violates the UI consistency, it should therefore be removed. just for the record, while working on the qml widget explorer i had to improve the Menu bindings, now a complete definition of a qmenu feeded by a model with submenus is possible btw, the fact that is aqmenu is a detail, with the design i have in mind when using the mobile components the same applet would weirdly look like kickoff :p so, a classic menu in qml would definitely be possible, i'm not really going to do it, but if someone fancies trying, they're welcome :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On Saturday 31 December 2011, Martin Gräßlin wrote: if the breadcrumbs are moved to the left and/or get a specialized visual treatment (neither of which are bad ideas imho) then the other headers should similarly be adjusted for consistency across the tabs. so far I synchronized the position with other Plasma elements and moved the headers into the center. Personally I would prefer to have a consistent UI throughout all Plasma elements (at least for the default shipped widgets). So the question is whether the breadcrumbs need to be moved from Left to Center. I will give that a try, but are not sure whether it is a good idea as it causes changes when traversing the menu. i think on the left is more sane -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: question about panel size guideline
On Saturday 31 December 2011, Aaron J. Seigo wrote: the system tray currently violates this as the xembed icons have a set minimum size that we can do very little about as they are out of process embedded windows. probably all xembed icons should be moved to the hidden area when the area allow for the tray is less than the height/width of an xembed entry. the tasks widget similarly does not scale visually down below 22px very nicely. the count below the arrow on groups is too tall, the frame too thick on small panels. idea that i was toying with for a while: what about hiding by default all xembed icons no matter what? they just break our systray paradigm (would always be possible to make them visible one by one with the usual ui) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dictionary
On Wednesday 28 December 2011, David Hart wrote: Hi folks. Dictionary was one of the most useful applications in plasma world - at least for me. It no longer works. I suspect that dict.org changed their interface. works fine here. maybe the site was down for a while? btw the protocol is a standard published in a very very old rcf http://www.rfc-editor.org/rfc/rfc2229.txt i think it's quite unlikely to change, unless they completely dump it for something new Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Integrate Plasma Scripting Console with KWin scripting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/#review9396 --- This review has been submitted with commit e366d57db2fe99592df0bfcd4140c2a78e4484f4 by Martin Gräßlin to branch master. - Commit Hook On Dec. 26, 2011, 9:06 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/ --- (Updated Dec. 26, 2011, 9:06 a.m.) Review request for kwin and Plasma. Description --- * KWin scripting becomes partly controllable through D-Bus * Desktop Scripting Console can control KWin scripts. For that two new methods to PlasmaApp's D-Bus interface are added. If in KWin mode the script is passed to KWin through D-Bus * Plasma Desktop Runner gains new keyword wm console to start Desktop Scripting Console in KWin mode. Diffs - kwin/scripting/scripting.h b0d00f9 kwin/scripting/scripting.cpp 0a71849 plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.h 227748d plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.cpp 617bc69 plasma/desktop/shell/dbus/org.kde.plasma.App.xml e9b6482 plasma/desktop/shell/interactiveconsole.h f94b997 plasma/desktop/shell/interactiveconsole.cpp 6f2ff75 plasma/desktop/shell/plasmaapp.h 3c7289c plasma/desktop/shell/plasmaapp.cpp b630225 Diff: http://git.reviewboard.kde.org/r/103518/diff/diff Testing --- Screenshots --- Desktop Scripting console with KWin integration http://git.reviewboard.kde.org/r/103518/s/379/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
QML widget explorer
Hi all, After almost a year of stopped development, I think the qml rewrite of the widget explorer and activity manager are almost ready for merge :D there are still some layout/behaviour annoyances especially on vertical panels, but should all be easy fix. (biggest annoyance is that the mouse wheel doesn't work in horizontal mode and is probably a problem of Flickable, so it could need a new c++ binding just for the mouse wheel :/) apart from that, aestetically is much better, is smooth, fast and the diff is +1887 lines of mostly qml -4617 lines of mostly c++ ease of maintainace ftw ;) the branch is plasma/mart/declarativeWidgetsExplorer if nobody complains i'll merge it in master shortly (tm) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML widget explorer
Oh Awesome, hurray for less code to maintain! Merge that in, so that we can all suffer and fix it ;-p The mouse wheel isn't a big deal by far yet(too bad it sounds like a hassle to fix though), considering the original's mouse wheel implementation would scroll 2px at a time, making it quite useless :-) -- Shaun Reich, KDE Software Developer (kde.org) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OpenGL and Plasma::Wallpaper
On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. Also, I don't think you should be against OGL wallpapers, considering some really sweet/impressive things could be done with them which could really make KDE stand out. e.g. a wallpaper playing a moving OGL scene, movies, virus wallpaper (which is currently a large CPU drain, and has no HW accel afik). Take Win 7 for instance, how they have Dreamscene™ or whatever. Having features like this is similar to having neat and incredibly useless OGL window animations (e.g. cube), ergo...everybody wants them, haha ;) -- Shaun Reich, KDE Software Developer (kde.org) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
