[Differential] [Commented On] D2983: Support solid colour and image backgrounds with a configurable background colour in the SDDM theme
markuss added a comment. This patch modifies an existing file. Removing the original copyright is illégal. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2983 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bgupta, davidedmundson Cc: markuss, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas
Re: [kde-promo] Plasma Next Naming
Am Donnerstag, 23. Januar 2014, 11:36:12 schrieb Martin Klapetek: Given that we're dropping the name KDE from the working desktop almost completely and changing it for Plasma (so you'll no longer run KDE on your PC but you'll run Plasma) I hope this will prevent that. Nothing will be prevented if the Plasma maintainers actually opt for August 2014 Update of the May 2014 release of Plasma by KDE. If they call it Plasma 2 in the media, I don't care that much as long as it's clear what it actually is and that it has a clear relation to KDE. Just yesterday I saw this blog post by our own KDE guys at Fedora and I quote: If you install kde5-workspace package, you can also have a sneak peek at what Plasma guys are doing for Plasma 2! Your display manager should have “KDE Plasma Workspace 2” entry in session types list, which will log you into Plasma 2 session. http://www.progdan.cz/2014/01/kde-frameworks-5-and-plasma-2-on-fedora/ KDE5 Workspace, Plasma Worspace 2, and Plasma 2 all mixed in a single paragraph. Oh, and no word about these things just being tentative names. Apparently our own guys are confused by the whole situation and that's even before any public announcement of throwing even more confusing date-based version numbers into the mix. The media, btw, also reads Planet KDE. Therefore any informal developer slang is adopted by them as well. August 2014 Update of the May 2014 release of Plasma by KDE is NOT sane marketing. Oh, and btw: The plasma2 package has the version number 4.90.1 over there at Fedora. Plasma 2 version 4.90.1 ... so unconfusing and by no means a road to KDE5... Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
Am Mittwoch, 22. Januar 2014, 18:24:08 schrieb Martin Klapetek: Let me give a different example from the same area - do you remember Windows Longhorn? Everyone was talking about Longhorn always and how revolutionary and new it will be...and then, Windows Vista came out. From the very same company, Windows Vienna turned into Windows 7. And many others could be found. And Microsoft also had the MSN Messenger. Later .NET Messenger, later Windows Live Messenger, Microsoft Messenger, and Windows Messenger. Everybody kept calling it MSN Messenger, just as almost everybody today STILL says KDE4. Even within our very own community KDE4 is still used and some even use KDE5: https://projects.kde.org/projects/kde/kdebindings/python/pykde5 Oh, and btw: Microsoft went back to version numbers (7, 8, 8.1,...) because they are not confusing. Plasma 2.0.3 is easy (people using computing devices encounter such version numbers all the time). August 2014 Update of the May 2014 release of Plasma by KDE is not easy. All you achieve with such a hard to comprehend version number is that people will call it KDE5. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming
Am Freitag, 17. Januar 2014, 18:37:27 schrieb Ivan Čukić: It seems we mostly agree on the Plasma Year Month, and Plasma by KDE* naming, at least in principle. Which is awesome. Considering that we already released official announcements de facto using Plasma (Workspaces) 2 as branding for almost one year[1], I cannot see any positive thing about changing version numbering once again. In addition there were countless blog posts published also through our Planet KDE aggregator using Plasma (Workspaces) 2. You may rightfully argue that Plasma2 is just a codename but since the Dot stories did not write Next generation workspaces, tentatively called Plasma2 in the first sentence of every single article touching that topic, the de facto branding already exists. Using an entirely new versioning is just grist to the mill of all the people who actually believe that following our upstream branding makes no sense in the first place because it'll be changed a few months down the road anyway (a few of them write about FOSS stuff on heise.de). I suggest you guys just use Plasma 2.0, Plasma 2.1, ... People have no problems understanding version numbers as long as they are coherent. Markus [1] http://dot.kde.org/2013/04/24/plasma-pow-wow-produces-detailed-plans-workspace-convergence http://dot.kde.org/2013/09/04/kde-release-structure-evolves http://dot.kde.org/2013/12/09/early-kde-plasma-2-images-now-available http://dot.kde.org/2013/12/20/plasma-2-technology-preview ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Media Query: KDE's Support For Android Tablets
As far as I'm aware, existing MTP access methods (DigiKam, Amarok) were seen as good enough, so nobody so far found the need to write a MTP KIO Slave to mount MTP devices in Dolphin. (Well, not exactly true: In 2007 a 3rd party wrote it but it died in alpha stage: http://kde-apps.org/content/show.php/kio_mtp?content=55618 ) I don't have an MTP device so I can't tell how good Amarok and DigiKam in that respect. Markus On Dienstag 22 November 2011 11:44:38 Swapnil Bhartiya wrote: Hi Aaron, I have been trying to reach you but just can't get hold of you at all. Thus posting it here. I represent Muktware.com and I am working on a story about Android support in Linux. While Gnome can detect and mount the Android 3.x + tablets, allowing users to drag/drop content to the tablets and crate folders (it can't see content inside folders). So, at least a user can copy content -- movie/music to the tablet. On the contrary KDE mounts it as a Camera and can't see content on the tablet, can create folders and can't drag/drop or paste content in the tablet which makes it hard for a user to use KDE to manage tablets. What is the reason KDE can't mounts Android Honeycomb tablets which use MTP? With increasing use of tablets, what is the KDE team doing to fix this problem? Best Sapnil Bhartiya ___ 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: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 10:52:04 Marco Martin wrote: that's what the support of plamoids on screensaver is for ;) I already understood that but as a screensaver (you know: to actually save screens from damage, incl. LCDs) a few additional features are required. At the very least, plasmoids would need to move. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 12:36:12 Aaron J. Seigo wrote: we should also stress that if things like OpenGL screensavers are important enough to people, that support for things to draw moving things on screen when locked can be created anew. We already have KWin effects – even gimmicky ones like Snow. Apart from some (I imagine relatively simple to implement) call “stop effect XY on any input” isn't that enough? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
On Samstag 01 Oktober 2011 14:10:39 Marco Martin wrote: for saving from damage, there is a thing called power saving :p Doesn't help the people who want a huge clock as screensaver without damaging their displays. It has to move. A Plasma containment whose widgets can float and bounce from another (like soap bubbles) should be enough. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The case for a kdelibs 4.8
On Donnerstag 29 September 2011 18:11:12 Kevin Kofler wrote: Wait and see the chaos that will come up when users open their Help/About in Konqueror and it tells them that they're using Konqueror 4.8.0 under KDE 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked 4.7 or 4.8 for whether that's fixed there.) True but only in one line ans the explanation that the Dev Platform is meant, is written in About KDE. That said, I'm toying with ideas about a complete redesign of the About window for KF5. When/If I come up with a somewhat presentable mock-up, I'll post it and hopefully a programmer implements something based on that. A completely new About window will also fix legacy issues like that string. and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing to most users. Actually, that was (and still is) quite confusing to many users. Look at the mailing lists and forums. I really don't think it was the majority and the Kontact case is user-visible software unlike Frameworks/Platform which normal users usually do not care about. MS Office 2003 also ran on Windows 2000 and the majority of users had no problems understanding that. ;-) And we better continue to educate our users that Platform version and Workspace version does not need to match. I have yet to see any ideas for KDE Plasma Desktop 5.0 which means that maybe KPD 4.9 in summer 2012 will require KF 5.0. So unless someone completely rewrites KPD for the summer release (maybe basing it on Plasma Active) and therefore justifying a major version jump to 5.0, as a promo person I'd rather educate our users now before we see people (at worst: reviewers) complaining that KDE 5 looks just like KDE 4.8. (As a side note I also think that KDE Applications should completely lose their version number and get date-based versioning because any application can get major new features at any time – see Dolphin 2.0 in SC 4.8.) Fedora 15 actually has KDE SC 4.6.x, not 4.7. Just a few days ago someone on your mailing list claimed otherwise but whatever... that's not the main topic here. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Is anybody aware of empiric studies for what (if at all) people use screensavers these days? Personally I'd expect clock, news headlines, and photo slideshows to be the top answers. QML replacements should be available for the top uses once the xscreensaver code is dropped. (IMHO at least.) On Donnerstag 29 September 2011 22:14:59 Martin Gräßlin wrote: Hi all, the work on the new screen locker implementation is nearly done (I can unlock again :-) and that brings me to an issue where I wanted to have more opinions: screensaver. What's important to see: screen locker and screen saver are two different things mixed together for historic reasons. The screen locker implements the security aspect of preventing someone else to use the screen. The screen saver shows an animation so that the hardware is not damaged. For some reasons those two things come together and also the old implementation is together. The new implementation is about screen locking and not saving. My idea is to improve the screen locking experience which kind of looks like 1995. Let's reuse the background of the splash screen and show a nice QML-ified dialog for unlocking. Instead of showing the unlock dialog only when someone moves the mouse, it would always be present. If the screen has been locked for long time DPMS kicks in and disables the screen (yeah for energy saving). This means there is no more place for screen savers. It would just not be visible. This also means we don't have the Plasma Screensaver any more (this might be fixable by using a Plasma containment as the screen locker in the first place). But when compositing is turned off, you currently get the plain old implementation including screen savers. And I don't want to change that code. So there are some solutions: * drop screensaver support altogether, probably would create some troubles as evil KDE removed screensavers * add Plasma widget support to new screen locker implementation but drop screensaver support (same problems as first option) * add a fallback to legacy mode if a screen saver is configured. Means same security problems are present again which were the reason for moving the screen locker to KWin in the first place Personally I would prefer option 1 with a later implementation of option 2 (if time allows even for 4.8). Option 2 needs support from Plasma hackers who are all currently fixing up a tablet ;-) A possible solution for the user issue could be to clearly advertise that security reasons are responsible for removing screensaver support. Also an improved login process I have in my mind: with only one user configured do not stop at KDM but log in directly with screen locked. The unlock dialog would then be shown after the complete session has been loaded, so instant usage after typing in the password. So looking forward to your comments on the subject. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The case for a kdelibs 4.8
On Donnerstag 29 September 2011 14:01:50 Kevin Kofler wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. Since almost exactly 2 years we (esp. the promo team) are communicating that Platform/Frameworks, Applications and Workspaces are three separate products that just happen to be shipped on the same date. One of the reasons why the rebranding still didn't get to everybody is that some distributions (mostly Fedora!) still spread the wrong message about some “KDE 4.7” to its users. (see eg. https://fedoraproject.org/wiki/SIGs/KDE/KDE47Packaging#KDE_4.7_Packaging ) Users of other distributions do not have such problems and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing to most users. The rule so far has always been that the kdelibs version must be the same as the KDE SC version. There is no rule – at most a common practise and that was broken as well after Fedora 15 has packages for SC 4.7 with Kontact 4.4. Changing this will also break all our Fedora KDE SC specfiles Then fix your specfiles. AFAIK Fedora is also the last big distribution that still has monolithic packages like kdemultimedia, kdenetwork, and so on. Take the opportunity to fix that as well. openSUSE doesn't seem to have problems packaging 4.8 already: https://build.opensuse.org/project/show?project=KDE%3AUnstable%3ASC And what will kde4-config --kdeversion output? The version of kdelibs? Of course. What else? Want to see the Plasma version, enter plasma-desktop --version If you want the version of Dolphin, enter dolphin --version and so on. Users are going to be confused: Hey, I installed KDE SC 4.8, why does it say 4.7? Then you refer them to Wikipedia which holds that info since quite some time: https://secure.wikimedia.org/wikipedia/en/wiki/KDE_Software_Compilation_4#KDE_Plasma_Workspaces_and_Applications_4.8 you will break Fedora packages even further. Then – again – fix Fedora. The main reason that was given for dropping kdelibs 4.8 is that this means one less branch to worry about for the people working on kdelibs, but the people who'd work on 4.8 and 5.0 are NOT the same people! Do you hereby declare that Red Hat will provide resources to create KDE Platform 4.8 and an cherrypick useful developments from the frameworks branch to Platform 4.8? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Menubar in Workspace 4.8
On Sonntag 25 September 2011 18:24:40 Marco Martin wrote: i'm quite against the panel, it promotes the menubar to an importance it lost since ages, while i'm really in favor of burying it into a menu under the windeco, since this decreases its importance ;) There are no window decorations in Plasma Netbook. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Menubar in Workspace 4.8
On Sonntag 25 September 2011 17:58:18 Martin Gräßlin wrote: * license of required Canonical library is incompatible with license used by decoration API (GPLv3-only + Copyright Assignment (personal notice: I rather reinvent the wheel in chinese wall style than contributing to a GPLv3 only + CA library) vs BSD) Not that different from how Qt was licensed for years and even with open governance Qt contributions will require giving Nokia the exclusive right to relicense (as opposed to LGPL or Apache License for everyone). * It needs Qt 4.8. Currently we still depend on Qt 4.7 and I don't know whether Qt 4.8 will become a requirement for KDE 4.8. Canonical maintains the patch for the Qt 4.7 series. It can be applied to qt-copy and declared mandatory for KR 4.8, therefore distributions would have to ship it in order to have a compliant KR 4.8. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Menubar in Workspace 4.8
On Montag 26 September 2011 14:27:19 Martin Gräßlin wrote: qt-copy is dead and because of that no option. Quite frankly, I wouldn't be surprised if we'll see a LibreOffice-like fork of Qt in the future because of Nokia's CLA for Qt contributions... Btw what is KR? Short version of the term KDE Releases the promo team came up with a year or so ago (usually in headlines as KDE ships 4.6 releases of Workspaces, Platform, and Applications or something like that). The openSUSE-KDE community uses the KR abbreviation even longer because the releases are published in the KDE:/Release/4x repositories. At lest in openSUSE mailing lists everyone uses KR as opposed to eg. SC 4.6 which is the reason I didn't even think about the term when I typed my mail. It just came naturally. Sorry for the confusion. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: RFC: Remove Opacity from Alt+F3 menu
On Donnerstag 18 August 2011 19:20:08 Martin Gräßlin wrote: Hi all, just an idea I had today: do we really need the opacity menu in the Alt+F3 menu? Don't know if you need it, I use it regularly. Wouldn't mind moving it into the Advanced sub-menu, though. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Setting a plasmoid on desktop border
I don't get the problem. If you want a contact list integrated into Plasma Desktop, add a panel and drop the list onto it, like it's already possible since ages with Lancelot's contacts IM plasmoid. With a panel you can set size, visibility, etc. That has also the advantage that you can set how windows react to it. Eg it can act as edge of the workspace, meaning that maximized windows don't overlap it. Markus Am Freitag 01 Juli 2011, 16:49:48 schrieb Francesco Nwokeka: Hi devs. As suggested today by sebas, I'm writing to the ML to ask info about a problem I have and what you suggest would be the best way to solve this. The effect I want to achieve is the same as the cashew icon. That is being attached to the desktop borders or being able to know the desktop boundaries. I was told that to be able to achieve this, I would have to add my plasmoid to the KDE desktop containment and then set my plasmoid to stay on the edge. Another option given to me was that I were to write my own containment. But so would this involve writing code for the Plasma desktop. Do you guys have any proposals? P.S - Attached to the mail is one of my mockups so you can get the idea I have in mind. Thanks, Francesco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
(Mockup) Re: [RFC] Enforcing Compositing
Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: I don't want to remove the workaround, I only do not longer want to expose it in the UI. That's a big difference. And I really like Markus' idea with the None compositing backend. I took a few minutes of time to squeeze out a mockup: http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png To my own surprise it reduces clutter to a greater degree than I thought it would while also not losing any features. As a side note: In the All effects tab the categories are sorted alphabetically. While in theory that sounds good, seeing Tools above Window Management makes no sense. Tools is probably no used by anyone besides a handful of people who develop KWin and benchmarking geeks. I'd also merge a few effect entries that are mutually exclusive: There are at least two Minimize effects which could be merged into one entry with Normal or Genie as radio buttons in the effect's config window. Same for closing windows, magnification lens, etc. Bye. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us in 4.5 are finally gone (...) What do you think about this idea? Well, it's hard to predict the future. Drivers could get regressions again. I think the problem is less the ability to turn off compositing, it's the wording. IMO the Enable desktop effects checkbox should only apply to the actual effects but not the compositing support. I've seen people in forums who are not interested in shadows, transparent windows etc. They dislike eye candy. What they don't get in some cases is that enabled compositing and all effects turned off should be better in most situations (unless the driver is broken). For disabling compositing, people could use the Advanced tab with the new option None added to the Compositing type drop down menu. I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) Could the shortcut call dbus? What I experienced when occasionally turning off composite support manually is that the shortcut does not flip the composite switch plasmoid and the shortcut always overrules the plasmoid which means that I can't turn it on again using the plasmoid. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Featurlets for 4.7
Am Sonntag 13 Februar 2011, 20:21:56 schrieb Aaron J. Seigo: 2. Have a custom wallpaper position option. This would let you set the position and scaling in both horizontal and vertical dimensions, either to presets like align top or bottom, or to custom values in pixels. This is useful for people who want to have one wallpaper span multiple desktops, they can set the same image but show different parts of that image. -1; there are better ways of acheiving that, e.g. actually dividing up the image in a proper, competent image editor. One of the advantages of using many different operating systems is to getting to know some nifty tricks for certain features. BeOS had a move (not scale) wallpaper feature and it was solved very well: In the fake monitor thumbnail (Plasma had this until 4.4 or 4.5) one could simply drag and drop the image to move its position. I don't know how many people used that feature (I didn't) but how it was implemented was unobtrusive. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
Am Dienstag 01 Februar 2011, 13:17:51 schrieb Sebastian Kügler: Actually, Aaron expressed my thoughts about your comments exactly. If that's the case, you guys really should work on your self esteem. Just because someone tells his opinion he certainly does not necessarily demand his opinion to turn into reality as if you guys were his slaves. My initial mail does not contain a single word of harsh language or a demand of any kind. OTOH Aaron's mail implied lots of negative stuff about me that cannot be farther from the truth. It's not about calming down, but about having a useful discussion among Plasma developers. People don't just take part to advance their own agenda, we're having this discussion to determine direction. I stand by my opinion that turning the focus towards Activities benefits mostly the kind of user who uses many applications simultaneously. If you agree: Fine. If not: The world doesn't collapse either. I never have and never will bitch about defaults that may not suit my taste, just as I never bitched about my Plasma Netbook mockup from a few months ago not being received well. Believe it or not: Whatever you will come up with, I'll stay grateful for your work. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
Dude, calm down a little. I was blaming no one of anything. You need to understand that when somebody simply states what he observes (that programmers with many programs and windows open tend to like Activities more than people who execute only 3 applications) it's not an insult against anyone. In fact I feel it's perfectly valid to scratch an itch of people who tend to execute many applications. You asked for comments and I commented. So don't be a bitch just because my opinion differs from yours! Am Montag 31 Januar 2011, 20:37:22 schrieb Aaron J. Seigo: On Sunday, January 30, 2011, Markus Slopianka wrote: let's try something big and new. let's make that Big Move and step away from ~/Desktop. Frankly, I like my dumping ground. and you can retain it. nobody is taking it away from you. even though i personally think you'd find far better ways of working if you forced yourself away from the comfortable known, i'm not selfish enough to make you do that :) my proposal is this: * by default, Search and Launch on the desktop What do you mean by that? Full screen SAL like on Plasma Netbook? Then one could just use that. go compare the netbook shell with the desktop shell and you'll find that they differ far, far more than just in the use of SAL. due to those differences, just use Plasma Netbook is absurd. As long as KDE's file search and indexing mechanism is still broken http://kdeatopensuse.wordpress.com/2011/01/30/opensuse-11-4-kde-testing/ , I see more frustration than benefit. I could be wrong, though. wtf does file indexing have to do with SAL? * improve the tasks widget to have some of the nice features of widgets like smooth tasks with the mouse over highlights I'd be happy if I could disable the scroll wheel for starters... i've outlined numerous times what such a patch that would be accepted would look like. so far nobody has felt like stepping up and scratching their itch. * an activities widget (i'll hapilly write it) that sits next to the app launcher and when clicked brings up the actvities manager * an activities switcher as a kwin effect (!) * have all activities avaiable in kactivitmanagerd, even if they are stopped in plasma-desktop It seems to me that programmers with their fully cramped task bars (IDE, terminals, debuggers, SCM frontends,...) are bigger fans of activities than the common persons with music player and browser open alone and -- if they are cutting edge -- even separate chat and mail clients. let me be frank with you: when someone blames us developers for catering to our own needs and so that's why things must obviously suck in some way or another, it really bugs me. you know why? because what you just wrote there is a pile of rubbish. we hear back fairly regularly from people in a multitude of differing situations that use activities and have even come to rely on them. but no, you don't like them and/or see the need for them so then, ipso facto, it must be something the developers have done just for ourselves with no other reason or research having been done, right? do you even know where the idea for activities came from? good old fashion field research with people who use their computers to do content creation. yes, that isn't the average web browser centric user, but they can very handily ignore activities altogether if they wish as they are not in their way at all. but of course, we should all stop what we're working on because it's so obviously unuseful and instead immediately do what you personally want: Personally, I'd rather have an actually good Dock implementation that merges launcher, task switcher, and systray in a single icon for each app. we added launcher support in 4.6 and we re-engineered the system tray protocol to make this possible. so yes, that's generally where we're headed. if you wish to see it all come together sooner, then you need to get involved and start making patches. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: the next step on the desktop
Am Montag 31 Januar 2011, 02:22:41 schrieb Aaron J. Seigo: hi... back when we started the path towards plasma i said that we needed to slowly evolve the desktop beyond the desktop folder with icons littered on the desktop. now we have activities, kick-ass containments like search and launch and grouping desktop. it is time to go to that next step and move people away from the old ways. i was at a friend's house last night where a bunch of people gathered to hang out, chat, play games, etc. there was a desktop system there running plasma desktop with the search and launch containment and a gorgeous translucent panel couresty of kwin. i saw it and hardly recognized it: it looked new, amazing, the next thing. it looked amazing. so, here's my suggestion for 4.7: let's try something big and new. let's make that Big Move and step away from ~/Desktop. Frankly, I like my dumping ground. my proposal is this: * by default, Search and Launch on the desktop What do you mean by that? Full screen SAL like on Plasma Netbook? Then one could just use that. However, if you mean a SAL plasmoid is the corner of the screen or a new top bar with a search bar and an extender than displays the icons (or another approach that combines both metaphors), I'd be fine with that. As long as KDE's file search and indexing mechanism is still broken http://kdeatopensuse.wordpress.com/2011/01/30/opensuse-11-4-kde-testing/, I see more frustration than benefit. I could be wrong, though. * improve the tasks widget to have some of the nice features of widgets like smooth tasks with the mouse over highlights I'd be happy if I could disable the scroll wheel for starters... * an activities widget (i'll hapilly write it) that sits next to the app launcher and when clicked brings up the actvities manager * an activities switcher as a kwin effect (!) * have all activities avaiable in kactivitmanagerd, even if they are stopped in plasma-desktop It seems to me that programmers with their fully cramped task bars (IDE, terminals, debuggers, SCM frontends,...) are bigger fans of activities than the common persons with music player and browser open alone and -- if they are cutting edge -- even separate chat and mail clients. Personally, I'd rather have an actually good Dock implementation that merges launcher, task switcher, and systray in a single icon for each app. But that's possibly the former Mac user speaking inside me. I'm willing to try alternative approaches with an open mind, though. Especially when I can try them in my 4.6 installation (I'm assuming QML plasmoids and activity templates can be used for that kind of stuff). Maybe I can come up with a mockup for something different myself in the coming days. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
On Sunday 26 December 2010 14:19:37 Martin Gräßlin wrote: I just cannot understand that problems like slowness of Present Windows with NVIDIA is reported by users in the beta phase several month after the code hit trunk! I would be cool if there was a separate kwin-test (or so) package that depends on the latest stable Platform/Workspace and whose KWin binary also has a different file name and whose settings are stored in different files. I have only one PC available for personal use and as long as the stable/unstable choice is exclusive, I simply can't afford to switch to a SC version that is not at the very least in RC stage. That would also enable me to occasionally use kwin-test on the PC at work (for which I have root rights) and leave all the others of its users with the stable KWin version. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: trunk open for 4.7, remember to backport :)
Am Donnerstag 23 Dezember 2010, 10:30:28 schrieb Ben Cooksley: The git transition, due to concerns about the ability to release 4.6 from Git, has been delayed until 4.6 is released. So trunk could be on git right now? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fancy Panel and pre-existing users
Users who have the Fancy Tasks plasmoid installed have the Fancy Panel option. Users who don't have the plasmoid don't have it. On Thursday 23 December 2010 23:13:53 Ben Cooksley wrote: Hi all, I have been made aware [1] that the options in terms of new panels available to users can differ if they are using a fresh profile or a pre-4.6 profile with their new 4.6 installation. For a new user, they have a Fancy Panel which those with older profiles do not have. Is there an explanation for why this occurs? Regards, Ben KDE Forums Administrator [1] http://forum.kde.org/viewtopic.php?f=202t=92170 ___ 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 themes set in kdeartwork
Stupid question: Why do we need Plasma themes in kdeartwork at all? They are not like KWin decorations and have to be compiled. Isn't GHNS enough? Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma: Folder View: Icon displays 'pressed' on non-activating clicks
On 2010-11-09 18:37:25, Aaron Seigo wrote: Lindsay Roberts wrote: If there are no objections could I request that someone check this in? Does it change the behavior described in https://bugs.kde.org/show_bug.cgi?id=256465 (always using the large 256x256 icon for the scaling effect)? If no, I suggest to tweak the patch because ever since Nuno changed the hi-res icons to look completely different from the smaller ones, the scaling effect looks really weird. - Markus --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5805/#review8589 --- On 2010-11-09 11:50:55, Lindsay Roberts wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5805/ --- (Updated 2010-11-09 11:50:55) Review request for Plasma. Summary --- The folder view employs a 'pressed' effect to show when an icon is activated. This works as expected when global settings are set to single click: the icon is scaled to 90% on press, and rescales back up on activate. Under double click the icon scales on the first click, and weirdly stays scaled until the mouse leaves the hover area. Further, the same issue applies when modifier keys are used to change selection. This addresses bug 256297. https://bugs.kde.org/show_bug.cgi?id=256297 Diffs - /trunk/KDE/kdebase/apps/plasma/applets/folderview/iconview.cpp 1193797 Diff: http://svn.reviewboard.kde.org/r/5805/diff Testing --- Tested with both single and double click settings. Thanks, Lindsay ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notification text
Am Montag 25 Oktober 2010, 13:11:21 schrieb Chani: ...after googling the part I could read, I got my account unlocked (phew!) but my point still stands :) I'd rather see clickable URLs than copyable ones... also, if anyone can recommend a reliable imap server, I would be willing to pay for an account. I hear http://gmx.com/ is good with free IMAP an such. I'm in Germany and can't register, so I can't tell how good it is. German GMX only offers POP3 for free. IMAP is a premium service here. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notification text
Am Montag 25 Oktober 2010, 15:53:39 schrieb Marco Martin: here you go, in trunk text is selectable and links clickable In case I never told you: You are my personal hero. :-) Does it also work with Kopete which AFAIK sends HTML-formatted notifications for URLs? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: digiclock looks
The new clock in Air looks good, in Oxygen it looks weird. I thing Todd's suggestion about a sunken look could would improve it. The clock is also very big. Maybe the date could be displayed by default. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: digiclock looks
Am Samstag 23 Oktober 2010, 01:40:52 schrieb Sebastian Kügler: On Friday, October 22, 2010 23:43:52 Markus Slopianka wrote: The clock is also very big. Maybe the date could be displayed by default. That leads to too much visual clutter. The date is available in the tooltip anyway, showing it by default in the panel would really be a bit too much. This was just an idea for one approach. Don't you think the clock looks really big? Maybe some other method to decrease its size can be found ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Why rotate widgets?
on a screen laying flat or which can be tilted: to make for a more appropriate viewing angle. Isn't that the responsibility of RandR? Personally I'd rather have a global tool (KRandR or some other rotate Activity tool) that to rotate Plasmoids individually. from a development POV it allows us to ensure testing of rotation so we know it works for other shells that need it even more so but get less testing, particularly pre-release. Sounds more like a hidden option. why do you ask? I wondered about that option for a longer time. I never used it and I never found it useful. Today I once again stumbled over a forum post by someone who wondered why that useless option is present anyway. Personally, I'm slightly against it but not with my full heart. What I found interesting is the idea by someone in this thread to add a context sensitive button. With images, rotation seems somewhat useful. A transparency slider might be somewhat useful for other widgets... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Why rotate widgets?
On Wednesday 08 September 2010 15:04:40 Giulio Camuffo wrote: I really can't understand what's the problem here. If you don't want to rotate your plasmoids, fine. But i really don't find why a tiny icon is that a problem. Does it get in the way when you want to do something? no. Is it broken? no. So what's the problem? I really don't like to repeat myself: The feature is (IMO) useless and adds clutter to the GUI and apparently I'm not the only one who thinks this way. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma version numbers
Hi there. Out of curiosity I happened to enter those commands into Konsole: # plasma-desktop --version Plasma Workspace: 0.3 # plasma-netbook --version Plasma Netbook: 0.1 See the printed version numbers. I guess those numbers are leftovers from a time both were still in pre-release. IMO both should now match the overall KDE Platform version number (and the term Plasma Workspace changed to Plasma Desktop). Bye. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Why rotate widgets?
Hi. I wonder why Plasma widgets in Plasma Desktop can be rotated. Why would anyone need individual widgets to be upside down? Isn't this one of those micro-options we once stated to get rid of? Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: BoF session at the MeeGo conference
On Thursday 26 August 2010 15:22:03 Bart Cerneels wrote: Has anyone on this list already send a BoF session proposal? I was thinking of the following: We (KDE) and others (Qt) developers have written a lot of Qt code already. It makes perfect sense to try and reuse this code on the latest and most exiting Qt platform: MeeGo. This BoF session will be an open, example led discussion between developers who want to port whole applications or use existing libraries and technologies on the MeeGo platform. This session is intended for anyone with existing Qt code, not just KDE but obviously we have a lot of experience already. We can also get into more specific KDE stuff during or after the session. How about it KOffice-mobile devs? Any interest? We've got until tomorrow. Bart Maybe a Plasma developer is interested in presenting Qt-based Plasma Netbook and maybe even show advantages over Clutter-based MeeGo Netbook. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
On Thursday 15 July 2010 17:57:11 Aaron J. Seigo wrote: aaron's advocatei really dislike text-on-graphics from a design perspective. text is fine detail, and a progress bar is visually fairly complex. maybe it's time to think outside the box. e.g. maybe colourize the device icon showing what % of it is filled and provide the usage text where the current progress bar is. the pie chart solution as seen in Lancelot would likely break up the layout in visually unpleasing ways here, so i wouldn't consider that too much./aaron's advocate I guess you don't have a portable MP3 player. If you had one, you wouldn't make such ridiculous proposals. Colors, pie charts, etc. are OK for quick and dirty checks -- for disks that have hundreds of gigs available and a single MB isn't of any significance. With common MP3 players a single MB makes the difference if I can have a song stored on the device or not. Design decisions that require tooltips or additional clicks to find out basic information (be it space available on external drives such as MP3 players or Plasmoid descriptions) are counter usability and may have their space in the realm of GNOME. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
On Wednesday 14 July 2010 20:10:42 Jacopo De Simoi wrote: SVN commit 1149977 by jacopods: First attempt to get rid of the capacity bar in the device notifier: use a Plasma::Meter with tooltips. Screenshot: http://imagebin.ca/view/ccJ3dD.html No longer displays amount of free space -- regression. Avoidable tooltips - Usability problem. Bug you mentioned - Qt bug (fixed in 4.7). What are the actual improvements then? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Tuesday 13 July 2010 22:35:50 Aaron J. Seigo wrote: sorry, but it's not coming back. Oh, then offloading all useful info into tooltips is good? Is this how you definition of elegance? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KDE/kdebase/workspace/plasma/generic/applets/devicenotifier
On Wednesday 14 July 2010 23:46:41 Jacopo De Simoi wrote: No longer displays amount of free space -- regression. Avoidable tooltips - Usability problem. I agree, suggestions? How about extending Plasma::Meter to show text/numbers in the progress bar? Maybe it could look like the percentage display on the battery Plasma applet. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Thursday 15 July 2010 00:04:45 Artur Souza (MoRpHeUz) wrote: Yep, it's way more elegant than having an icon with an i that when clicked shows all the useful information. In the old window as well as Aurelien's mockup the applet description is visible right away, without the need to click i, so your argument simply isn't valid. Specially that my mother doesn't need to figure out what the hell the i icon means (it could be something related to uninstall on my native language) I take this as a proposal to remove the i from the systray. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
Oh, and btw: It's impossible to click on URLs in those Plasma tooltips, while it's perfectly possible in all other About windows. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Tuesday 13 July 2010 07:34:35 Chani wrote: how would you suggest that be done? Ask Celeste to come up with something great :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Launcher support for libtaskmanager
On 2010-07-10 19:13:13, Markus Slopianka wrote: GPL for library files? Sounds strange to me. I'd expect at least LGPL... Marco Martin wrote: this library is a big mess it already contains pieces in gpl, lgpl and bsd this really should be fixed Combining LGPL and more permissive licenses (BSD, MIT) isn't such a big deal, but I'd avoid GPL for libraries. While it's not a violation of KDE's Licensing Policies (that one only demands LGPL or more permissive for kdelibs, kdepimlibs and kdebase-runtime), it's at least inconsistent with KDE's general LGPL for libraries and GPL for applications approach. I suggest to Anton to use LGPL for both to at least make the situation not more messy than it already is. - Markus --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/#review6471 --- On 2010-07-10 18:21:39, Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/ --- (Updated 2010-07-10 18:21:39) Review request for Plasma. Summary --- Adds support for Windows 7 like launchers in libtaskmanager. (I'm on holliday from 12th July until 1st August so I will not be able to reply during this time.) Diffs - /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 Diff: http://reviewboard.kde.org/r/4585/diff Testing --- Tested with a small test-applett and everything works. Thanks, Anton ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
Aren't icons supposed to be meaningful? How do those random patterns represent activities in an iconic way? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday 12 July 2010 11:47:51 Marco Martin wrote: or do you have a better idea to -magically- find an image that represent that activity without user intervention? Why would Activities be created without user intervention? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday 12 July 2010 11:55:50 Marco Martin wrote: unfortunately, i see that having something already done is often enough to make people not wanting to use those Maybe it should be easily discoverable what Activities actually are. Maybe I'm uninformed, but I see them as virtual desktops with individual Plasmoid setups. Plasma in SC 4.4 had a quirky GUI for selecting activities, but at least showed thumbnails of them. In 4.5 thumbnails were replaced with random patterns and I still don't see the benefit of pattern over thumbnails. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday 12 July 2010 12:58:23 Alessandro Diaferia wrote: Well, I don't completely see the point of avoiding any type of configuration to the user. IMO, when creating a new activity, the user might be prompted to choose among a set of default activities. Those activities might already have a name and a default icon together with some default plasmoids already loaded. Then the user might eventually choose to create his custom activity and in that case he would choose a name and an icon in place of a default, generic one. Exactly my thoughts. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Monday 12 July 2010 13:53:10 Aurélien Gâteau wrote: I agree. I made a proposal for an alternative version which would requires no hovering to get the widget descriptions but it was rejected. Huh? Why? Was it like the one in 4.3? I had absolutely no problems with the 4.3 one. Therefore I am trying to get some less drastic changes in. Thanks. Better than nothing. While you're at it, fix the text input field, please. It does not have focus by default. :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Monday 12 July 2010 15:33:24 Aurélien Gâteau wrote: It looked like this: http://agateau.files.wordpress.com/2010/07/add-widget-e1278885892283.png It was rejected because it had the same problems as the KDE 4.3 dialog: taking too much screen space. The people who rejected it obviously never saw KRunner, because your proposal looks exactly the same. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activity identicons v 1.99 :) (post-akademy)
On Monday 12 July 2010 23:40:42 Chani wrote: if you want details, go read my blog posts on activities :) http://chani.wordpress.com/?s=activities Yeah, I could do that, but while I'm not afraid of reading blogs, typical users won't do that. It'd be really great if by SC 4.6 it was easily discoverable for common users (and advanced users alike) what activities are and how to use them. :-) Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Launcher support for libtaskmanager
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/#review6469 --- Um, I think that was done by accident: /kdebase/workspace/libs/taskmanager/launcheritem.h is GPL while /kdebase/workspace/libs/taskmanager/launcheritem.cpp is under a BSD license. Shouldn't both be BSDL'ed? - Markus On 2010-07-10 17:21:34, Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/ --- (Updated 2010-07-10 17:21:34) Review request for Plasma. Summary --- Adds support for Windows 7 like launchers in libtaskmanager. (I'm on holliday from 12th July until 1st August so I will not be able to reply during this time.) Diffs - /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 Diff: http://reviewboard.kde.org/r/4585/diff Testing --- Tested with a small test-applett and everything works. Thanks, Anton ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scrollbars in add widget ui
On Monday 12 July 2010 00:18:03 Aurélien Gâteau wrote: What do you think? I think that the scrollbars are an improvement, but I like the window from 4.3 better: The current one requires to hover over an icon to see the description. I have yet to see any improvement of the Add widget bar over the window, but I also didn't participate in the discussion before SC 4.4 over which one is better. So I'm not aware of the exchanged arguments. (I hope there was a discussion.) Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Launcher support for libtaskmanager
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/#review6471 --- GPL for library files? Sounds strange to me. I'd expect at least LGPL... - Markus On 2010-07-10 18:21:39, Anton Kreuzkamp wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4585/ --- (Updated 2010-07-10 18:21:39) Review request for Plasma. Summary --- Adds support for Windows 7 like launchers in libtaskmanager. (I'm on holliday from 12th July until 1st August so I will not be able to reply during this time.) Diffs - /trunk/KDE/kdebase/workspace/libs/taskmanager/taskitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/taskgroup.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/strategies/programgroupingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.cpp PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/launcheritem.h PRE-CREATION /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/groupmanager.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractgroupableitem.h 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/abstractsortingstrategy.cpp 1148442 /trunk/KDE/kdebase/workspace/libs/taskmanager/CMakeLists.txt 1148442 Diff: http://reviewboard.kde.org/r/4585/diff Testing --- Tested with a small test-applett and everything works. Thanks, Anton ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma Mediacenter: Inroduce displaying and modifying of nepomuk tags
On 2010-06-07 22:45:45, Markus Slopianka wrote: Correct me if I missed anything, but as I skimmed through the diff, it looked to me that this is only about Nepomuk tags. Correct? I may be splitting hairs here, but when I hear tag editing in the context of media players, I think of ID3 tags and such. Will ID3 tags later be edited with the same mechanism? (At least Artist, Title, Year, ans such) If yes, the wording is OK to me and not editing ID3 tags is just a transitional bug. However, if ID3 tags will be edited with a different tool/window, I suggest to change the name of Nepomuk tags to something else, like Label or so, to avoid confusion. - Markus --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4252/#review6028 --- On 2010-06-08 08:03:13, Christophe Olinger wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4252/ --- (Updated 2010-06-08 08:03:13) Review request for Plasma and Alessandro Diaferia. Summary --- This patch introduces a new label in the bottom bar. When playing/looking at a media file, it displays its nepomuk tags. When clicking on the label, the user can add/edit tags to an item (comma separated). When multiple items are selected, tags are applied to all of them. P.S. The videostate.cpp contains comments. Diffs - trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.cpp 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.h 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.cpp 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.h 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.cpp 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.h 1135839 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.cpp 1135839 trunk/playground/base/plasma/MediaCenterComponents/shells/plasmediacenter/mainwindow.cpp 1135839 Diff: http://reviewboard.kde.org/r/4252/diff Testing --- Adding, editing tags was tested extensively. No more bugs should remain (TM) Thanks, Christophe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasma Mediacenter: Inroduce displaying and modifying tags
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4252/#review6028 --- Correct me if I missed anything, but as I skimmed through the diff, it looked to me that this is only about Nepomuk tags. Correct? I may be splitting hairs here, but when I hear tag editing in the context of media players, I think of ID3 tags and such. - Markus On 2010-06-07 21:43:23, Christophe Olinger wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/4252/ --- (Updated 2010-06-07 21:43:23) Review request for Plasma and Alessandro Diaferia. Summary --- This patch introduces a new label in the bottom bar. When playing/looking at a media file, it displays its tags. When clicking on the label, the user can add/edit tags to an item. When multiple items are selected, tags are applied to all of them. P.S. The videostate.cpp contains comments. Diffs - trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.h 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/mediacenterstate.cpp 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.h 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/musicstate.cpp 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.h 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/picturestate.cpp 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.h 1135632 trunk/playground/base/plasma/MediaCenterComponents/libs/mediacenter/videostate.cpp 1135632 trunk/playground/base/plasma/MediaCenterComponents/shells/plasmediacenter/mainwindow.cpp 1135632 Diff: http://reviewboard.kde.org/r/4252/diff Testing --- Adding, editing tags was tested extensively. No more bugs should remain (TM) Thanks, Christophe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
