Re: Review Request 125395: Mutex around usage of m_connectedEvents which may be called from any thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125395/#review86139 --- Ship it! Oh I missed the queued call to timer->start(), so it indeed is better, since afaik queued calls also require mutexes I first though that having to lookup the matching slot and having a mutex either way could at least avoid that the meta lookup... Thanks for the patch :) - Daniel Nicoletti On Set. 29, 2015, 3:48 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125395/ > --- > > (Updated Set. 29, 2015, 3:48 p.m.) > > > Review request for Plasma, Daniel Nicoletti and Harald Sitter. > > > Repository: print-manager > > > Description > --- > > m_connectedEvents is modified in connectNotify which according to the > docs will be called from the thread of the caller, not this. > > A mutex around all places that use/modify it should prevent print manager > from making plasmashell crash. > > BUG: 345862 > > > Diffs > - > > libkcups/KCupsConnection.h f61ccb53078766e7f5e96dedec879b52b9083b66 > libkcups/KCupsConnection.cpp 482a0bcc9afdee9e0fa131da158988d349dd0da6 > > Diff: https://git.reviewboard.kde.org/r/125395/diff/ > > > Testing > --- > > Applet still loads..though I don't have any printers, so can't test too much. > > > Thanks, > > David Edmundson > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125395: Mutex around usage of m_connectedEvents which may be called from any thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125395/#review86120 --- Why is it better? I found the first less intrusive, simpler and likely faster - Daniel Nicoletti On Set. 29, 2015, 3:48 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125395/ > --- > > (Updated Set. 29, 2015, 3:48 p.m.) > > > Review request for Plasma, Daniel Nicoletti and Harald Sitter. > > > Repository: print-manager > > > Description > --- > > m_connectedEvents is modified in connectNotify which according to the > docs will be called from the thread of the caller, not this. > > A mutex around all places that use/modify it should prevent print manager > from making plasmashell crash. > > BUG: 345862 > > > Diffs > - > > libkcups/KCupsConnection.h f61ccb53078766e7f5e96dedec879b52b9083b66 > libkcups/KCupsConnection.cpp 482a0bcc9afdee9e0fa131da158988d349dd0da6 > > Diff: https://git.reviewboard.kde.org/r/125395/diff/ > > > Testing > --- > > Applet still loads..though I don't have any printers, so can't test too much. > > > Thanks, > > David Edmundson > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 125395: Mutex around usage of m_connectedEvents which may be called from any thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125395/#review85930 --- Ship it! Ship It! - Daniel Nicoletti On Set. 25, 2015, 3:10 p.m., David Edmundson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125395/ > --- > > (Updated Set. 25, 2015, 3:10 p.m.) > > > Review request for Plasma, Daniel Nicoletti and Harald Sitter. > > > Repository: print-manager > > > Description > --- > > m_connectedEvents is modified in connectNotify which according to the > docs will be called from the thread of the caller, not this. > > A mutex around all places that use/modify it should prevent print manager > from making plasmashell crash. > > BUG: 345862 > > > Diffs > - > > libkcups/KCupsConnection.h f61ccb53078766e7f5e96dedec879b52b9083b66 > libkcups/KCupsConnection.cpp 482a0bcc9afdee9e0fa131da158988d349dd0da6 > > Diff: https://git.reviewboard.kde.org/r/125395/diff/ > > > Testing > --- > > Applet still loads..though I don't have any printers, so can't test too much. > > > Thanks, > > David Edmundson > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure
2014-11-13 13:03 GMT-02:00 Aleix Pol : > On Thu, Nov 13, 2014 at 3:50 PM, Albert Astals Cid wrote: >> >> Aleix, can you please explain to us why Mion Discover and Apper are two >> different things in principle? >> >> Seems the Apper guys disagree. >> >> Cheers, >> Albert >> > > There's 2 main differences: > 1. Muon Discover has historically used OS metadata to define what are > applications an what's relevant to the users (AKA end-user applications). > Although they claim it will be done eventually on Apper as well. In any case > Muon Discover doesn't aim to manage packages, it aims to provide a library > of resources for the user to enhance his KDE/Plasma experience. Apper uses metadata to define application for years now, it also provided Plasma integration for removing applictions directly from kickoff thanks to PackageKit session interface. However on the point of managing packages Apper doesn't tries to merge the two things in a way you don' t need to open another application to install a package... > 2. Muon has different backends, so we're not solely relying on PackageKit > which means it can act as a frontend to different technologies other than > packagekit, currently bodega, KNS/OCS and Apt (the last one for historic and > practical reasons). Support for different technologies could also be added to Apper but no one ever stepped up to give a hand, and I myself don't like much these others to do it... > > Aleix -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120130: to prevent a compiler error
This os Wong please use constBeging() Em 10/09/2014 14:45, "Guy Maurel" escreveu: >This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120130/ > Review request for Plasma, Daniel Nicoletti, Jan Grulich, Kevin > Krammer, and Lukáš Tinkl. > By Guy Maurel. > *Repository: * plasma-nm > Description > > with gcc 4.9.1 under ArchLinux > > to prevent the error: > > conversion from ‘QMap::iterator’ to non-scalar type > ‘QMap::const_iterator’ requested > > Diffs > >- kded/secretagent.cpp (3e4fe82672f0d034779b1dd4e8c433d9c4a22e27) > > View Diff <https://git.reviewboard.kde.org/r/120130/diff/> > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120130: to prevent a compiler error
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120130/#review66193 --- Please use secrets.constBegin() and secrets.constEnd(), that code was very broken the way it is, I think I even had crashes with similar codes... - Daniel Nicoletti On Set. 10, 2014, 5:45 p.m., Guy Maurel wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120130/ > --- > > (Updated Set. 10, 2014, 5:45 p.m.) > > > Review request for Plasma, Daniel Nicoletti, Jan Grulich, Kevin Krammer, and > Lukáš Tinkl. > > > Repository: plasma-nm > > > Description > --- > > with gcc 4.9.1 under ArchLinux > to prevent the error: > conversion from ‘QMap::iterator’ to non-scalar type > ‘QMap::const_iterator’ requested > > > Diffs > - > > kded/secretagent.cpp 3e4fe82672f0d034779b1dd4e8c433d9c4a22e27 > > Diff: https://git.reviewboard.kde.org/r/120130/diff/ > > > Testing > --- > > > Thanks, > > Guy Maurel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma-next-nm
2014-03-14 7:21 GMT-03:00 Jan Grulich : > For libnm-qt we decided to port master branch to Qt5 and make it work with > the current stable version of > NM and also with the current development version (future NM 0.9.10). In > libmm-qt it is also ported to Qt5 in > master, but we set minimum required version of ModemManager to 1.1, which was > previous development I've been using libnm-qt Qt5 branch for quite a while on my nm applet, so did you merge it back to master? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma Next Naming - Take 2
2014-01-27 Albert Astals Cid : > El Dilluns, 27 de gener de 2014, a les 15:05:43, Jos Poortvliet va escriure: >> I recall seeing -x often as distro-package-versions, so 2014.06.2 might be >> better. Then the fourth packaging of 2014.06.2 will be 2014.06.2-4. > > Just after reading the email I also thought that 2014.06.2 looks "more > consistent" than 2014.06-2, on the other hand 2014.06.2 may "easily" be > confused with a date while 2014.06-2 not so much, so I'm not really sure what > I like better :D I just want to see this thread to end :P so maybe (because indeed distros use -X as their packaging versions): 2014.06.r1 2014.06.r2 2014.06.r3 Or 2014.06.I 2014.06.II 2014.06.III Or 2014.06.A 2014.06.B 2014.06.C ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
2013/8/21 Sebastian Kügler : > On Wednesday, August 21, 2013 17:12:10 Daniel Nicoletti wrote: >> 2013/8/21 Martin Graesslin : >> > Yes I noticed that for example you still talk about KDE as software in >> > your >> > blog posts. To be honest I have to cringe if I read it, because it makes >> > the task of everyone more difficult who tries to work on the >> > repositioning of the brand. >> >> Well if I write an app using Qt people call it a Qt app, when you use KDE FW >> it becomes a KDE app. So what should I call the software I write when using >> KDE FW? > > Just to chime in here, this is clearly wrong. A KDE App (or project, if you > will) is not defined by its technical dependencies, but by the people who > write it, see manifesto.kde.org. Ok, then what am I doing wrong in calling my stuff KDE stuff? http://manifesto.kde.org/benefits.html lists what I do on my projects, I was arguing about Martin saying that I talk KDE as software but KDE projects are mostly software no? This is too controversial, I know the idea is the we KDE are a community, but it's a community that have projects and software hence why am wrong in saying KDE software? It's software made by KDE people. > Daniel, I think you've gone a few years back in time, stuck your fingers > firmly into your ears as to the reasoning of the whole rebranding, and are now > trying to turn back the clocks for no good reason. I never intended to question the rebranding thing, I really don't care about it, KDE has always been a community just like Gnome and Linux are, making sure KDE isn't more just a desktop isn't the point I'm making. What I'm saying is that people still install distros choosing the "KDE desktop", and not the Plasma desktop, and this is one of the reasons why I believe Plasma 2, is the right name, this way people can know what plasma shell is and use this. In short don't you think the whole new 5 cycle needs more coordinating between all parts, will it be an SC, will there be an official shell of course if this is really going to happen? As you said the rebranding happened years ago but somehow I'm only seeing it affect software (as in releases) now. > Would you mind giving the rebranding another try to actually understand it, > and not work against what has been years of work, and not an easy, but very > much necessary endeavour? Then we could actually move forward, instead of one > step ahead, two steps back. Just forget I mentioned KDE and SC, just take my +1 on Plasma 2, this is becoming an endless and unnecessary discussion, already regret for giving my 2c please give them back :P ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
2013/8/21 Martin Graesslin : > Yes I noticed that for example you still talk about KDE as software in your > blog posts. To be honest I have to cringe if I read it, because it makes the > task of everyone more difficult who tries to work on the repositioning of the > brand. Well if I write an app using Qt people call it a Qt app, when you use KDE FW it becomes a KDE app. So what should I call the software I write when using KDE FW? > It is important. If people from the outside think it's one coherent thing we > wouldn't need efforts like frameworks to make it more attractive for 3rd party > developers and it also makes any attempts to get KWin as the window manager > for all Qt based shells much more difficult. Which is a reason why I do care > about it. Well re-branding is really hard, it's for a reason companies fight for names... Clearly I'm not alone in not know how to properly brand things now. >> The KDE community has to decide which will be the included, since plasma >> got there first there isn't much chance for a replacement, then better >> do like Razor. > does the KDE community have to decide? Yes, look at the old Oyranos vs colord-kde thread, in the end colord-kde probably has more usage where KWin color correction only works with Oyranos (I don't plan to fix this before we have wayland). And Kolor-manager ended up in extragear... > Did the community ever decide that > there can only be one file manager in the SC? The fact that Konqueror is also a file manager could be tagged as historical reason imho. > Also does software have to be in > the SC? Or is software more blessed by being in the SC? Sure it is, most distros have meta packages which installing kde-utils brings a bunch of "utils" stuff, if your app is in there it gets more attention. > Large part of the > release announcement for 4.11 is about KScreen - to my knowledge it's not even > released as part of the SC. Right, it got good promoting due to being an important thing to many users, would a new clock applet (not part of the SC) get on the announcement page? > What do you think is the more prominent music > player by KDE? Amarok which is not part of the SC or juk which is part of the > SC? Same for IM - kopete vs kpt. I do agree with you it's not needed to be in the SC, but notice the core apps vs regular apps difference, if I write another window manager that happens to replace kwin in the SC would people still want to install KWin? Sure if you promote it better (or have more quality) downstream might use it as default. > Who said there will be a software compilation in the KF 5 world or that the > Plasma Workspaces will be part of such a maybe existing software compilation? Nobody (afaik) said the opposite either :) > Please note that this has not yet been discussed, but I know that a few people > in the Plasma team (me included) would favor to not have the SC anymore. The > reasons you mention are a part of it. In fact the whole discussion highlights > it. OK, then imho we could have modules SC ie kde utils/edu... SC, the SC is good because it help with the coordination of small modules that doesn't have to worry when to release their stuff. > We would not need to think about a version number if Plasma would be part > of the software compilation. Well if that's the reason shouldn't the discussion about having/being part of SC take place first? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
2013/8/21 Martin Graesslin : > On Wednesday 21 August 2013 13:52:06 Daniel Nicoletti wrote: >> 2013/8/21 Martin Graesslin : >> > On Wednesday 21 August 2013 11:29:52 Daniel Nicoletti wrote: >> > this might change. Consider Razor/LXDE joining the KDE umbrella. What >> > then? >> > From one day to another it would be obvious that using "the KDE desktop" >> > is >> > not working any more. >> >> In that case what we will end up is with just KDE libraries? I mean >> people are used to "install/use KDE" which means the SC. > no?!? I fail to see what you want to tell us, I cannot follow your thought. I > guess it's based on you still think that KDE is not the community but all the > software we tend to release once half a year. Sorry if it's hard to understand, so I'll try to put it into another way: * First I just wanted to say that I prefer Plasma 2 instead of 5, because it helps understanding the age and we have lots of other KDE components with different versions than 5. * Second I'm saying that KDE is also the software because we do release a KDE Software Compilation which has the KDE name. * I know we don't market the KDE desktop anymore, all the blog posts around KDE still talk about it as a DE. Lots of friends that use KDE SC don't even know what is plasma-desktop because for them it's KDE. For example what happens if I want my own shell (no I didn't write one :P ) on the KDE SC? The KDE community has to decide which will be the included, since plasma got there first there isn't much chance for a replacement, then better do like Razor. I'm not against the KDE renaming, but I think we are getting to a point that having an Software Compilation becomes a problem. If Razor is now a KDE project they why only plasma is included? About print-manager the user can see it's version using the about module of system-settings, but since KDE does the branching/tagging it's easier to just rely on the KDE version, the 0.3 vesion is something useless when on SC. But to me as a developer tells me how much I change it, and since it's mostly complete 4.10 has 0.3 and 4.11 has 0.3 because most commits where just bugfixes. Also dpkg -l print-manager shows the KDE SC version (so it does for dolphin). PS I don't care much what plasma does as I'm mostly a user of plasma shell and API, but as a user I just felt that jumping into 5 just because the KDE FW is at 5 seems wrong, as after all KDE is just the community. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
2013/8/21 Martin Graesslin : > On Wednesday 21 August 2013 11:29:52 Daniel Nicoletti wrote: >> My 2c, >> >> On KDE 4 aka KDE SC 4, plasma was always just plasma, >> no user says I'm using the plasma shell (as there isn't another >> KDE option). > this might change. Consider Razor/LXDE joining the KDE umbrella. What then? > From one day to another it would be obvious that using "the KDE desktop" is > not working any more. In that case what we will end up is with just KDE libraries? I mean people are used to "install/use KDE" which means the SC. If we are going to drop the "KDE desktop" then imho it should be better to put some marketing on the "Plasma desktop" which uses KDE technology. The same imho happens to Razor/LXDE, they will keep being Razor/LXDE maybe using KDE pieces. At some point KDE might vanish completely as the more things from the frameworks are upstreamed (not that this is bad!). This of course end up being completely ok with the new KDE = comunity branding which to me is a shame that the shell looses it's identity. I somehow imagine in the future people talking about plasma people or lxde people and the KDE name being left only for frameworks. Of course I'm just supposing. > I'm in fact aware of at least three desktop shells by the KDE community. The > only thing those three share is the window manager. But at some level "the" KDE shell is plasma, and if these others want to be known the have to do the promoting themselves. > Given that we know that we want to open us for more projects and that we want > to get our technologies into other Qt based desktops, it would be a really bad > idea to ignore this fact when we do the planning for the next version. No, I'm not saying to ignore this fact. It's just that imho the idea of pushing Plasma to version 5 is bad for the reasons I mentioned. If plasma will keep being included into KDE SC the SC version is what users see. An example is that when someone fill a bug against say print-manager I care which KDE version they have and not if p-m is at version 0.3, because I know which version was included in that SC. Best ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
2013/8/21 Marco Martin : > On Wednesday 21 August 2013, Daniel Nicoletti wrote: >> My 2c, >> >> On KDE 4 aka KDE SC 4, plasma was always just plasma, >> no user says I'm using the plasma shell (as there isn't another >> KDE option). > > Incidently, the whole SC stuff, was never intended for marketing and public > communication, but it ended up that way, and sure enough press reaction to SC > was overwhelmingly negative. Sure, just to clarify what I was trying to state is that most users know the KDE version not the components of it. For the SC maybe in 5 we could go back to "we are KDE and KDE is also the software" I think people can tell the difference without an "SC" :P but whatever that's another (endless) discussion and off topic... ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: naming the next major release
My 2c, On KDE 4 aka KDE SC 4, plasma was always just plasma, no user says I'm using the plasma shell (as there isn't another KDE option). I think even if Plasma is numbered after 2, users will still say they have installed KDE 5 or KDE SC 5, the marketing imo must go to the whole SC 5 and not to single components, for example I go to dolphin look at it's version and I have 2.2 but my KDE is 4.10.5, when the user report bugs most of the time they specify the whole KDE version and not the component one. Having KDE as just as people (bad thing imho) brings these issues, do we install KDE software? Or would I install KDE people? IMHO the core of the KDE is it's libraries/frameworks which will be named at 5. One can write another KDE shell (iirc there is kor) (and don't make it in SC) but that will still be a KDE shell. enough talking to summarize I'd say we should go for KDE SC 5 which includes 2nd gen of Plasma, 3rd gen of dolphin and so on, some components happen to have survived since KDE 1 (kwin/konqueror maybe?), naming Plasma as 5 doesn't reflect it's real age. Regards, -- Daniel Nicoletti - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Actual width of checkbox element
This is the reason in Apper updater the checkbox doesn't use the text property, instead I have a checkbox with no text and a Text element next to it and eliding right. I don't think you can do it other way as there is no other properties exposed, but I might be wrong... 2013/8/15 Kai Uwe Broulik : > Hi there, > > I got a bug report [1] about that the popup width might get so small that the > PM checkbox doesn't fit entirely. > Is there a way to determin the actual width of the checkbox including its > label? > So I could do minimumWidth: Math.max( currentminimumwidth, checkboxwidth) > Or should I just use a fixed, say, 250px minimum width? > > Best, > Kai Uwe > > [1] https://bugs.kde.org/show_bug.cgi?id=323530 > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how to draw a transparent / semi-transparent area in plasma-qml ?
a rectangle with color: "transparent" will be fully transparent regardless of it's opacity, though the opacity will be applied to all of it's children. if you want something semi-transparent you can try color: "white" and opacity: 0.5 2013/8/9 Bruce Ouyang : > i have tried rectrangle with opacity:0.5 and color:"transparent", but this > doesn't work. > looking forward for your reply! > thanks advance! > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Missing commit from kdelibs KDE/4.10 and master. Kde-workspace fails to build.
I believe Kai Uwe reads this list but CCing him just in case, he probably forgot to merge master :) Best 2013/6/1 Antonis Tsiapaliokas : > Hello, > > Today i try to build the kde-workspace and i came across to the following > issue. > > Right now kde-workspace doesn't build because a commit from master branch > (kdelibs repo) is missing from the KDE/4.10 branch (kdelibs repo). The > commit which is causing the issue is this one > > http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=b86adffd69a972f612e0fb00f8c4e8154142c730 > > Kde-workspace fails to build, because it cannot find the method > "isPowerSupply". line 134. > > http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=4b184facab7eb7ab841b4185a7288fb3b6126fbd&hb=bb659f206d747c42784fa7f2d2045e6866bf6b87&f=plasma%2Fgeneric%2Fdataengines%2Fpowermanagement%2Fpowermanagementengine.cpp > > > I hope the above information helps. > > P.S. Should i cc the release-team ML? > > Regards, > Antonis > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switches around the world and broken metaphors [Was: Battery Monitor revamp]
2013/5/25 Martin Graesslin : > And I would completely fail to use the switch. I have huge problems > understanding those switches and I have not seen any implementation of the > switch where I got which one is on and which one is off. You are totally right, because they need fixing, even if they are only to be used in Plasma Active. Here are a few examples of how a good switch should look like (IMO): http://developer.android.com/design/media/settings_master_on_off_2.png http://1.bp.blogspot.com/-AXi56wp5zVE/T6pAZj-MXdI/ACM/-wT0w1PpcJ4/s1600/device-2012-05-09-152937.png This is the one I like the most (it's the one on my Xperia phone): http://i582.photobucket.com/albums/ss269/netbookc/XB1/XperiaSICSFirmware_12.png > These switches are very useful in certain parts of the world (e.g. US) where > every light switch is like that. It was quite an epiphany to me when I visited > the US last year - I finally got what these switches are supposed to be. For > me > this switch is just a not working metaphor as we don't have switches like that > in this part of the world [1]. > > Just something to remember when it comes to metaphors. They might be awesome > for some, but if one doesn't understand it, it makes it much more difficult. I don't think Switches are only about metaphors, actually here in Brazil we also don't have those, but look at some China toy, or some table clock and you will see them, so what it misses is how does it present it's states. In print-manager for instance I make the text and icon disabled trying to improve the poor situation. Cheers, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reshuffling startup to start activity manager after ksmserver
It's started by kdeinit on phase 0 or 1 don't remember now, just add the X-KDE-Init-Phase=2 to the desktop file and it should work 2013/5/25 Simon Persson : > Hello, > > After seeing Kevin Ottens suggestion for a "Welcome" activity (1) I decided > to try setting up such an activity. > > I want this to be the only activity that is started at boot/login to give a > fast boot since many times I'm not gonna do same activity as what I did when > I last shut down my laptop. > I also agree that this first activity should not be made special other than > by configuration. It could perhaps be an idea to make a special "welcome" > applet or desktop containment and by default have that one configured to be > shown only in this default activity. That welcome applet can then show a > list of other available activities for easy starting. It could also have a > button for the discussed function of "move all windows from this activity to > a newly created one". > > For my experiment I decided to show the desktop component of homerun in the > "Welcome" activity which gets me pretty close to what I want. > > So much for the background, now the problem: > I wanted to use the "restore manually saved session" option of ksmserver in > order to always start the "Welcome" activity and nothing else. > But kactivitymanagerd does not communicate with the session manager, it > always keeps its rc-file updated with which activities are running and which > is the current one. It then resumes to that state upon startup. > > I started looking into making the activity manager speak to the session > manager, but ten years of writing kde applications and using kde full time > has taught me very little about how the session startup works. > > Currently it seems kactivitymanagerd is started via klauncher by some kded > module, and that happens before the start of ksmserver. If I add "--no-kded" > option to kdeinit4 in the startkde script then the activity manager gets > started after ksmserver and can work the way I want it to. > > 1: Ivan, do you agree that it would be desirable to make kactivitymanagerd > only save state in the QApplication::saveState() function? At least when the > "resume last session" option is not active? > > 2: If so, how should things be reshuffled to make it start after the session > manager? Is it even possible? Looks possible to me, first thing that seems > to need it is kwin, which is started after ksmserver. > > I'm not currently involved in any of these projects but I have been thinking > of the need for a session manager in a wayland-world and that it could be > interesting for me to get involved with that. This issue then serves as a > good reason to learn more about these things. I've already spent two days on > this and learned a lot. > > If you read all the way here, thank you. > Simon > > (1) http://mail.kde.org/pipermail/plasma-devel/2013-May/025153.html > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Battery Monitor revamp
2013/5/25 Aaron J. Seigo : > Switches are not to be used on Desktop. For 4.11 the QML switch component > appears as a checkbox, so you really don't have a choice in the end. The > reasons are: > > * consistency > * input device appropriateness > * people use them poorly on desktop (just look at UIs that use them > extensively on desktop and what the layouts end up looking like .. horrendous, > often with labels on the left and switch crammed far off to the right. just > like in this draft of the battery, actually, which ends up having an odd > widget floating off on its own) I'm sorry but I've been hearing the same phrase over and over KDE people, "if something is broken go fix it instead of working around". And this is clearly the case let's work around something we don't want to fix. Switches are a clear improvement over checkboxes depending on the context even my 60yo mom got it much quickier than a checkbox would be able to on my plasmoids. So because no one created guidelines on how/when to use them let's just remove it? I'm not trying to sound rude but this has to stop, GNOME is ripping out features and guess what? Unhappy users. Battery remaining time: Unhappy users. Now really try to replace a Switch with a CheckBox and a Checkbox with a Switch: http://wstaw.org/m/2013/05/25/plasma-desktopyB6013.png You can of course do whatever you want to stuff you maintain, but the health way imo would be to question people. And yes, if 4.11 is not going to have Switches, I as the maintainer of my own stuff will simply fork it and be happy. How does that fix any issue now? How is that good if it makes me and a bunch of other developers to carry a copy (which I might even improve and not give back) of a component multiple times instead of sharing? Best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Remove remote plasmoids in 4.11
+1 2013/5/7 Martin Graesslin : > Hi all, > > I'm in the unlucky situation that a certain person, let's call him David E. > [1], had the great idea to demonstrate how reliable Plasmoid Sharing over the > network works. > > The result: > 1. every time I connect to the same network as D's notebook I get several > notifications that a new Applet is available > 2. Adding the Applet does not work > 3. Stopping the export on D's system does not work [2] > > My proposal for 4.11: let's remove remote plasmoids. They don't work and they > are a rather annoying way to annoy people around you. AFAIK they have already > been removed from libplasma2. > > Comments? > > Cheers > Martin > > > [1] no that is too obvious, let's change to D. Edmundson > [2] restarting plasma-desktop seems to have fixed that problem > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Disable DrKonqi for KWin in stable releases
The crash reports are there normally to help you fix a some bug
in the code, I know a flood of crash reports is a pain but what's the
biggest issue in them? I mean is the backtrace useless or the
description or even too many duplicates?
Aren't you afraid of losing good crash reports? and if Dr Konqui
could be tweaked to only send only good crash reports would that help?
2013/4/30 Martin Gräßlin :
> Hi all,
>
> KWin gets too many crash reports, let's disable DrKonqi
>
> the latest post-Ubuntu-release crash report flood made me think that all the
> crashes we get are only causing work. There is no value in it except that we
> know that KWin once again crashed because Ubuntu is *insertrandominsulthere*.
> My initial idea was to discuss with Jonathan and Harald whether we could
> disable crash reporting just on Ubuntu.
>
> But thinking more about it: there is no benefit at all in the crash reports
> reported against stable packages. It's all upstream or downstream issues.
> Since January 1st, 132 crash reports were created but only 10 of them have
> been fixed. Out of these 10 fixed reports only two are for 4.10.0 (with one of
> them from a Kubuntu dev running pre-alpha of raring) and one is for 4.10.1.
> All the other reports are for the alphas and betas.
>
> My suggestion is therefore to push the following patch to stable branch and to
> future stable branches on final tagging day:
> diff --git a/kwin/main.cpp b/kwin/main.cpp
> index ed051f8..710c16d 100644
> --- a/kwin/main.cpp
> +++ b/kwin/main.cpp
> @@ -273,6 +273,7 @@ Application::Application()
> connect(&owner, SIGNAL(lostOwnership()), SLOT(lostSelection()));
>
> KCrash::setEmergencySaveFunction(Application::crashHandler);
> +KCrash::setDrKonqiEnabled(false);
> crashes = args->getOption("crashes").toInt();
> if (crashes >= 4) {
> // Something has gone seriously wrong
>
> We would still get the crash reports in master and during beta and RC for
> which we are interested, but all the junk would be disabled.
>
> The nice side effect would be that it would look like improved quality as
> normaly a user wouldn't notice a KWin crash. It's a short flicker during which
> the window decorations got recrated, but that's it. Has there been a crash if
> nobody is there to notice it?
>
> Opinions? Can somone convince me to not do it?
>
> --
> Martin Gräßlin
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Init KDEDModule after kamd?
> if(watcher->connection().isConnected())
> init.
This afaik is wrong, is connected with DBus.
You should actuall setup the watcher and at
the init do a call like:
QDBusMessage message;
message =
QDBusMessage::createMethodCall(QLatin1String("org.freedesktop.DBus"),
QLatin1String("/"),
QLatin1String("org.freedesktop.DBus"),
QLatin1String("NameHasOwner"));
message << qVariantFromValue("org.kde.kamd.");
QDBusReply reply = connection.call(message);
bool connected = reply.value();
This call will block KDED so please adjust to the non-blocking call.
--
Daniel Nicoletti
KDE Developer - http://dantti.wordpress.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plans and status Frameworks5, Plasma2, Qt5 and Wayland
Hi, I don't know if this is off topic or no, but some people said to me there won't be a KDE 5 naming, I dunno if this is true or not, but if this is true I missed the discussion. Could someone clarify this to me? Thanks. 2013/1/16 Sebastian Kügler : > Hi all, > > I've compiled a document that contains our technical direction and its status. > This hopefully gives us a common understanding of where we're going and where > we are right now. > > Feedback is of course welcome. :) > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: reflecting on 4.10
2013/1/10 Aaron J. Seigo : > hello. Hi > we're nearly at the point of releasing 4.10. with this development cycle very > fresh in mind, it is a reasonble time to reflect on how it went. this thread > can be a place for us to do so, if we so wish. and i hope we do so that we can > improve our processes in the future. > > so how do you think 4.10 went? > > what do you feel are the "defining" accomplishments for the desktop workspace > in 4.10? (e.g. the positive things people will talk about when they get 4.10 > on their machines) > > what do you personally like about the results of 4.10? I really like we are going further on the QML land, means the transition to KDE5 might happen sooner and less traumatic as it was with KDE4 > what, if anything, did you not like about the 4.10 development cycle? I really think quality could be improved, currently if you run plasma-desktop on your console you can clearly see tons of warnings what not only make it slower but clearly means something is broken, be it an anchor loop or undefined values. Don't take it personal as everyone has it's own priorities but I can easily think a closer look to the console warning wouldn't let them pass so easily, from my own experience even when something looks well rendered but you have some anchors warning things are very likely to break, I'm not a plasma developer right now but I fell like I'll want to spend some time polishing it since now I have a few plasmoids relying on it working nicely. Also I'd really like it to start faster. > what, if anything, would you like to be done the same way in 4.11? > > what, if anything, would you like to be done differently in 4.11? Maybe it would make sense to have some sort of KDE Alpha where we can have distro packaging KDE right after feature freeze so we get some early testers to get it polished sooner, but well this all depends on distros willing to package it as it means more work to them.. All in all thank everyone that make KDE happen :) Cheers :) -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switch and Checkbox items
2012/12/13 Nuno Pinheiro > you guys know the mains reason for radio butons and check boxes beeing > kiiled > on the touch world dont you? > My Android 4 phone has tons of checkboxes... They are shrodingers cats, wile you pressthem they are at the same time > bowth > pressed and unpresssed since the phinguer covers all of them and for that > periud you dont know its status, plus makes it terribly hard to change up > your > mind wille pressing them, solution was the switcher. > That's not the problem, you can't know the state of a switch while holding it either, you can also change your mind about a checkbox if you move your mouse (finger) away while pressing. > > in the desktop we dont need them and they mostly just brake alignements > Alignments can be adjusted, is the switcher size too tall? make it smaller, does a I / O makes it easier to read? then do it. And use QML anchors to align... Cheers, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switch and Checkbox items
2012/12/13 Aaron J. Seigo > On Thursday, December 13, 2012 14:00:51 Daniel Nicoletti wrote: > > I really don't think one replaces the other. I have switches and > checkboxes, > > on my Android phone and I clearly sees that depending on the context it > > fits better. > > yes, on touch (such as Android type use cases) we'll be keeping both. the > question is about desktop. > Tho, I'm not in favor of one UI fit's them all, I think switches on the other hand can make "reading" an UI easier. > > > For example, in print manager I used a switch on each printer, > > since it's a device and I find more natural to turn it on/off. > > do you have any user testing or external research that supports this? > I normally keep an eye on my friends/family using the desktop to see how they can interact with it, but nothing scientific. > > i wonder how well people can accurately determine if something is a > hardware > device or not (networking is probably a minefield) and if there is benefit > to > introducing additional metaphores on the already complex desktop. > I think it's not a new metaphore, people are already used to switches on real life, and even on smart phones. > personally, i really don't want to see Switches start appearing in random > places on the desktop UI (consistency) and there are so many use cases to > cover to know if they can be properly integrated or not. the *last* thing > we > need is something like "use Switches for hardware devices .. except if > UI limitation>" leading to a mix of switches and checkboxes for the same > kind > of functionality. > Agreed, though I think it's impossible to try to hold HIG to be missused, if we start looking at System Settings, without one switch it's quite a mess of different UI styles... (one thing I hope to be able to help address in future). > > > I don't think droping one in favour the other is the way to go. Good > > and easy to read guidelines are. > > can you address the Cons i raised about this approach, namely: > > * Much more work for developers (one UI for touch, one for desktop, all > because of Switch vs Checkbox) > > * if we change our mind in the future, all that work needs to be re-done > > * relies on people caring about and implementing HIG-compliant UIs (this is > the big problem IMHO) Agreed, but I think it's much better to provide good guidelines than dropping a functionality. So: * for instance those who like switches will just copy the QML file and ship with their own plasmoids ( I think this is the biggest problem ) * if people ship switches we loose bug fixes * Most checkboxes need a good expanation text, where if you show [] Wifi People just recgnize it's for turning the Wifi on/off vs [ X ] Enable Wifi On the other hand when you have long lists of options switches are really hard to read. We could even do some research showing users screenshots of both, and create such document. Best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Switch and Checkbox items
I really don't think one replaces the other. I have switches and checkboxes, on my Android phone and I clearly sees that depending on the context it fits better. I think what's missing is a switch widget on the desktop and guidelines when to use either of them. For example, in print manager I used a switch on each printer, since it's a device and I find more natural to turn it on/off. On Apper updater only checkboxes are used since I'm checking and update not, turning it on or off. So as a general rule I think switches makes sense to things like turn the whole network off (like with have switches on our laptops), turn bluetooth on/off, but if you have to pick options that usually require some text checkbox is the right choice. I don't think droping one in favour the other is the way to go. Good and easy to read guidelines are. Best. 2012/12/13 Marco Martin > On Thursday 13 December 2012, Aaron J. Seigo wrote: > > > * implement Switch in the desktop components as a checkbox. > > > > Pros: this is very easy to do (API compatible; just need to move > Switch.qml > > to touch components and make a new Switch.qml in the default desktop > > components that simply creates a Checkbox); people can use Switch if they > > want and things remain consistent > > > > Cons: it means you can never have a Switch element on a desktop app, even > > if you really want to (and use Checkboxes elsewhere in your UI). however, > > this is perhaps a weak con, as it implies there is a valid use case for > > switches on the desktop. as we've lived without them until now ... > perhaps > > there aren't. > > > yes, i think making switch a checkbox on the desktop makes sense. > > would make sense the other way around as well? (checkboxes as switch on > touch) > probably not i guess... > > -- > Marco Martin > _______ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving screen locking away from krunner
2012/12/7 Aaron J. Seigo > ah.. you got the message reversed! > > krunner may crash because it can load random plugins (runners) which may > misbehave; krunner crashing would prevent the screen locker from > activating. > > ksmserver does not load random code (because it has no reason to, and we > need > it to be guaranteed stable as you noted) so does not suffer from this > issue. > Thanks for the clarification :) -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving screen locking away from krunner
2012/12/7 Aaron J. Seigo > not only are you late to the discussion, but you apparently have not looked > into how it is done: a separate process is started for the screenlocker / > screensaver. it does not run in the ksmserver process. this is how it was > also > done in krunner .. and kdesktop before that. > Ok, then sorry for the noise :P Yes I didn't look, I took some assumption from previous posts to this thread. It's just someone said that krunner could crash and we wouldn't have the session locked, then it was said it was moved to kcmserver and I got a bit scared of kcmserver crashing now... i would like to see the performance of this increased by having the greeter > launch time reduced ... but that's a different matter. > Yes, I was doing some tests to see what could be improved on kde startup to make it faster, I have some ideas to make kded more reliable and a bit faster, but from my tests the big killer was still plasma, I really would like to do something about this but my time is quite limited and I think it's best to wait for Qt5 and QML be used... anyway as you said it's a different matter :P Best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving screen locking away from krunner
Sorry for being a bit late to this thread, but I need to say that moving the screen saver from krunner to ksmserver was a very bad decision, let me explain why: - Screen savers can be made by third parties, meaning we can't guarantee their quality - Screen savers might enter in some loop locking kcmserver - Screen savers might crash which will close the whole KDE session. No I'm not kidding about the last one. Look at the startkde script, you will see this line: kwrapper4 ksmserver $KDEWM If you know better the script you know it locks at this point, so as long as ksmserver is running the script doesn't quit. Crashing ksmserver means the script will exit that line and finish execution then the DM will close the session. I really wouldn't like to lose all my open apps just because of a broken screen saver. Please, rethink the move, and move away from ksmserver it's the most important app not to crash in a KDE session. (if you are not convinced kill it) Best, 2012/12/3 Alex Merry > On 03/12/12 14:42, Davide Bettio wrote: > > Nice, I missed that change. Is it possible to backport any fix for > > plasma-netbook? > > Hacky fix for old versions of plasma-netbook: > > http://randomguy3.wordpress.com/2011/09/04/screen-locking-with-the-plasma-netbook-interface/ > > Alex > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Display Configuration KCM design review
You should also place the main view inside a framed view, so it looks more like native QWidgets. Another nice option would have no background in QML view and just be rendered into the huge gray area, maybe with an horizontal line to delimit the area with buttons.. Also copy this class to your code so you get the edid info parsed for "free" :D https://projects.kde.org/projects/playground/graphics/colord-kde/repository/revisions/master/entry/colord-kded/Edid.h Best, 2012/10/2 Dan Vrátil : > On Tuesday 02 of October 2012 14:48:25 Sebastian Kügler wrote: >> On Tuesday, October 02, 2012 14:29:24 Dan Vrátil wrote: >> > As some might notice [0], we are working with Alex Fiestas on new display >> > management for KDE. I'm now working on new KCM. Aaron suggested in >> > comments >> > below the blog post that it would be nice to discuss design of the KCM >> > with >> > you, Plasma guys. >> > >> > As d_ed and few others suggested, I have rewritten the bottom control pane >> > to use standard QWidgets rather then QML, so now it looks like this: [1]. >> > >> > Still, I really suck at UI design, so I would appreciate any input from >> > you >> > on what can improve not just integration with the rest of Workspaces but >> > also user experience. >> > >> > There are two problems with icons I already know about, but I'm unsure of >> > >> > the what the best step would be: >> > 1) icons for rotation - should I make special "90 deg clockwise" >> > and >> > >> > "90 deg counterclockwise" icons, as shown here [2]? >> > >> > 2) icon for primary output - some people did not understand that >> > >> > the bookmark icon represents primary monitor. Is it OK or should I try to >> > find something better (and what do you think would fit best)? >> > >> > If you want to try it, you need my "fork" of Alex's libkscreen (contains >> > things I didn't send to Alex for review yet) from >> > scratch/dvratil/libkscreen- clone.git and the KCM from >> > scratch/dvratil/displayconfiguration.git >> > >> > Note: the KCM can be already used to configure monitors, but does not yet >> > react to changes (i.e. it won't update when you unplug a monitor) >> >> Could you post a screenshot using the default color scheme? I'm a bit >> confused how it would look like for "normal" users... > > Sure, sorry. > > http://i.imgur.com/1GnRV.png > > It does not look exactly like I expected (I'm so used to my theme it did not > occur to me to try the default one), the background should not be white, but > rather...darker gray, possibly the same like in krandr KCM now. > > Dan > >> -- >> sebas >> >> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > -- > -- > dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt > GPG Key: 0xC59D614F6F4AE348 > Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: development settings panel in Active Settings
2012/9/27 Marco Martin : > On Thursday 27 September 2012, Aaron J. Seigo wrote: >> one thing it does not yet do that i would like it to is to install konsole >> if there is no terminal application on the device. this probably means >> some PackageKit hacking. > > maybe take a look at the packagekit plugin in the addons app, i think is > almost the minimum amount of code necessary to install a package Apper/Gnome PackageKit exposes a simple interface on the user session for this task, maybe it might make sense to have the same interface on plasma active... -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: System tray
2012/9/18 Aaron J. Seigo : > On Tuesday, September 18, 2012 10:58:32 Marco Martin wrote: >> - for the popup as just icons: not overly strong opinion, but I tend to >> prefer using text as well. > > agreed. it makes it clearer what each icon is, but also gives a much bigger > hit area and allows them to be easily scanned (a grid is difficult for many to > scan quickly). Would it be hard to add an option to instead of a popup expand the plasmoid and show the remaining icons? I really dislike the popup expecially because when I click on a plasmoid there it opens in the middle of the screen, and not close to the panel. best, -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: *** GMX Spamverdacht *** Re: Review Request: replace old kickoff with kickoff-qml
Hmm, well I thought you had a dataengine for the applications model, so uninstall, favorite, sort would all be exposed as services, but it seems it's not the case, sure it makes sence since from my experience dataengines are slow with a good amount of data. Anyway I just tought having a dataengine "packagekit" didn't worth the trouble, I'd embed it in your model since it's just a DBus call.. so maybe it makes sence for you to add a sort(), uninstall(index), favorite(index)... up to you anyway, if you think this is best I'll just take a look to see it the calls are fine :) 2012/9/16 Marco Martin : > On Sunday 16 September 2012, Gregor Tätzner wrote: >> You mean all of them? We have planned to create a dataengine for adding >> launcher items to the panel but why would you want to expose a 'Sort menu >> from A-Z'? It's strongly tied to the kickoff model. > > yes, stuff like sorting should be just internal in the applet, no poit for a > dataengine here > > -- > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: replace old kickoff with kickoff-qml
;(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/KickoffButton.qml >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/KickoffItem.qml >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/MainView.qml >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/SearchView.qml >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/config.ui >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/contents/ui/kickoff.qml >(PRE-CREATION) >- plasma/desktop/applets/kickoff/package/metadata.desktop >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/CMakeLists.txt (PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekit.operations >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitengine.h >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitengine.cpp >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitjob.h (PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitjob.cpp >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitservice.h >(PRE-CREATION) >- plasma/generic/dataengines/packagekit/packagekitservice.cpp >(PRE-CREATION) >- > plasma/generic/dataengines/packagekit/plasma-dataengine-packagekit.desktop >(PRE-CREATION) > > View Diff <http://git.reviewboard.kde.org/r/106448/diff/> > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: replace old kickoff with kickoff-qml
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106448/#review18978 --- Hi, I took a quick look over the diffs and using search I could not find what I was looking so let me question you :) Kickoff-C++ has context menus, used to add applications to favorites, clean history, and the feature I added "Uninstall applications" using PackageKit. From what I know about QML (not recent plasma API changed) there's no way to create top level windows to be used as a context menu, so I'm curious since you said it has feature parity how did you created this feature or that's still a missing thing? Best - Daniel Nicoletti On Sept. 14, 2012, 7:04 p.m., Greg T wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106448/ > --- > > (Updated Sept. 14, 2012, 7:04 p.m.) > > > Review request for Plasma and Martin Gräßlin. > > > Description > --- > > I think it's time now to get the new kickoff into master so we can polish it > for KDE 4.10. the qml plasmoid is still using the old model code (though > slightly adjusted). This could cause issues for the c++ menu launcher > "simpleapplet"...I'm not using it but actually it doesn't even compile. > Probably would be better to port it to qml as well...opinions? > > The qml code resides in the package dir. It's a pure qml widget with c++ > model extensions...obviously :) > > Add to Panel/Desktop is still not supported but overall I think we have > reached feature parity with kickoff c++ > > I'm also worried about the upgrade path from kickoff-c++ to kickoff-qml. How > can we ensure a smooth transition for devs and users? > > > Diffs > - > > ksplash/ksplashqml/SplashWindow.cpp > 94e6dedfddcac20516686a7a3b30651d48bc26e7 > plasma/desktop/applets/kickoff/CMakeLists.txt > 4b0d32a9d0e7d46d05c4efdef9dc39fd653cc2f9 > plasma/desktop/applets/kickoff/core/CMakeLists.txt PRE-CREATION > plasma/desktop/applets/kickoff/core/applicationmodel.h > f0f8872255956321292151cdd82326cdf88c5508 > plasma/desktop/applets/kickoff/core/applicationmodel.cpp > 74b2595ba67de1cdd2f93d3e9e7c2eebd68f6df2 > plasma/desktop/applets/kickoff/core/favoritesmodel.h > 8ee3e9a9eb16780131d59b150b50641e5a03a34c > plasma/desktop/applets/kickoff/core/favoritesmodel.cpp > 14e35cdced82384f0cdf86caec9a4045bfaf2912 > plasma/desktop/applets/kickoff/core/itemhandlers.h > ec72cbe51b6e2da604ba6eba96f9e6f3f5935f67 > plasma/desktop/applets/kickoff/core/itemhandlers.cpp > 4e83c37588af1ebab331082e2eaccb40a0f8155c > plasma/desktop/applets/kickoff/core/kickoffabstractmodel.cpp > 7e2e64d22e9e274ffe3d37fdd0ac2c33a622ea3a > plasma/desktop/applets/kickoff/core/kickoffmodel.cpp > 8149cac20ce8ab246d8f484ca7567fc6e32d548c > plasma/desktop/applets/kickoff/core/kickoffplugin.h PRE-CREATION > plasma/desktop/applets/kickoff/core/kickoffplugin.cpp PRE-CREATION > plasma/desktop/applets/kickoff/core/kickoffproxymodel.cpp > f92bca971e0f9fcb644cadab6aa39a3e36291c00 > plasma/desktop/applets/kickoff/core/krunnermodel.h > 93a8b152a673eb6233727a82eefd70739ffc5a0f > plasma/desktop/applets/kickoff/core/krunnermodel.cpp > 452ebbe81311f8e3e95b5eda5fb9217344852d06 > plasma/desktop/applets/kickoff/core/leavemodel.h > 0676fb9358bdfd5e3cffce7eb3a0ea5e4ff70989 > plasma/desktop/applets/kickoff/core/leavemodel.cpp > 31467acc6654decb2800cf9a5acc398ccaaeccc7 > plasma/desktop/applets/kickoff/core/models.h > 3332ba9608808b353c32d96c37b84ddd82aabddf > plasma/desktop/applets/kickoff/core/models.cpp > c787df6e2f2c7c88ff97c64c7cd7640cce32365b > plasma/desktop/applets/kickoff/core/qmldir PRE-CREATION > plasma/desktop/applets/kickoff/core/recentapplications.h > a0feddca1cebbeb556623216bcc6c5c30e13a2a4 > plasma/desktop/applets/kickoff/core/recentapplications.cpp > 3e0538958564ae690e41791bdb5af76fa2ca9a8f > plasma/desktop/applets/kickoff/core/recentlyusedmodel.h > 841eb2b77aee778a85c76eafa61d38016f6ade58 > plasma/desktop/applets/kickoff/core/recentlyusedmodel.cpp > 2762d6d63a7b0592a7e87cd99603cc7c418292c5 > plasma/desktop/applets/kickoff/core/systemmodel.h > b04a7871883edd5ea7281d9853ec9203ce019894 > plasma/desktop/applets/kickoff/core/systemmodel.cpp > cb9bf650bab36c6415d37db795e766b743d5e25d > plasma/desktop/applets/kickoff/core/urlitemlauncher.h > 26b638fc02f42505e29857b5c18736e6778a580e >
Re: Re: [RFC] Merging LightDM into KDE Workspaces
Though I have nothing against this move, I'd like to ask a dumb question (well maybe not that dumb): Since lightDM-kde greeter is (AFAIK) pretty much just an interface for lightDM, and since I myself find the user interface much more user friendly than KDM's one, isn't it possible to remove the GUI bits from KDM and have it to use the same interface as when using lightDM? Surely it isn't a trivial change, but the benefit of having one unified greeter interface would help people doing themes, I imagine distros having to create two different themes the both UIs. Thus making KDM an alternative backend for lightDM-kde. anyway just my 2cents.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Merge the final and fixed QML battery monitor to master.
2012/4/3 Viranch Mehta :
> On Tue, Apr 3, 2012 at 1:45 PM, Marco Martin wrote:
>>
>> here the biggest challenge i guess is making all resize correctly in
>> horizontal/vertical panels.
>
>
> Yes, just spent 5 hours on this. Finally resizing works almost fine inside
> and outside panels, except:
>
> * it does not resize/change when the orientation of a panel changes (eg, top
> panel is moved to right). i tried addEventListener('FormFactorChanged',
> formFactorChanged); but the callback is never called.
>
> * if the applet is on the desktop, the last visible icon in the list
> flickers _a lot_
> when the applet is resized. this happens for more than one icons visible,
> and
> happens to only the last icon.
>
> * the c++ applet shows a confirmation box for suspend & hibernate,
> how can this be done in QML? how about showing our regular applet-popup
> like in the battery monitor? with this option, the user also wouldn't have
> to move the mouse too much around the screen.
doesn't the kworskspace API handle the confirmation already?
(I know it does for Shutdown, logoff and restart)
Best
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Review Request: KMix Declarative Applet - First attempt
2012/3/28 Alex Fiestas : > On Wednesday, March 28, 2012 07:22:12 PM Daniel Nicoletti wrote: >> > From a quick look of the code, there's the chance to build the daemon >> > too.. If so, there's no need to do all that work :) About the need of the >> > complete UI, we need it only for one purpose: select which channel will >> > be the Master channel. I can't list all the available channels inside the >> > standard config page (the one which appears when you click on the wrench >> > icon in the applet handle), because of scripted plasmoid limitiations. >> > But, thanks to the awesome progress made with plasmacomponents, I could >> > use your fancy Dialog item to show all the channels available, and allow >> > the user to choose which one will be the Master channel :) In this way, >> > we could drop the KMix windowed app, keep only the daemon, and talk to it >> > with one (or more) kmix applet. What do you think? >> > From my point of view you should: >> * Create a KDED module to talk to Alsa/Pulse Audio/OSS/whatever kmix talks >> to, expose all this information with a DBus API. > This is already donde afaik, KMix kded >> * Create a DataEngine (which I guess you have already written) to talk to >> the KDED module. > Also done somewhere iirc > > I believe that we should write a plasmoid focused on PulseAudio to take the > 100% from that system, and then write a plasmoid for KMix to support non PA > systems. Don't you think this would confuse users? To me I'd only worry about PA since it's what I use, but we have wine that can use OSS (some games needs this to work well) and BSD too iirc. So if a plasmoid only talks to PA maybe it won't work well when some user is using wine with OSS plugin. (But I'm not sure here). > Coling has a master plan of how PulseAudio should be integrated in a > worksapce, maybe you can talk with him in case you are interested. Ok, the plasmoid in question is already a good start tho I'd change some stuff like removing the 38% as the user is already seem percentage because of the slider that duplicates the information. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: KMix Declarative Applet - First attempt
> > From a quick look of the code, there's the chance to build the daemon too.. > If so, there's no need to do all that work :) > About the need of the complete UI, we need it only for one purpose: select > which channel will be the Master channel. I can't list all the available > channels inside the standard config page (the one which appears when you > click on the wrench icon in the applet handle), because of scripted plasmoid > limitiations. But, thanks to the awesome progress made with plasmacomponents, > I could use your fancy Dialog item to show all the channels available, and > allow the user to choose which one will be the Master channel :) > In this way, we could drop the KMix windowed app, keep only the daemon, and > talk to it with one (or more) kmix applet. What do you think? > > From my point of view you should: * Create a KDED module to talk to Alsa/Pulse Audio/OSS/whatever kmix talks to, expose all this information with a DBus API. * Create a DataEngine (which I guess you have already written) to talk to the KDED module. * Make your plasmoid talk to this. I was planning on doing this once I have finished some stuff I'm doing but since you already started this is what I think you should do. I can even give a hand if need to. My idea about the plasmoid applet would be to show master channel when you click on the tray area, and have a "mixer" button that expands the plasmoid to show all channels like KMix does today. Also this new "mixer" should have all Pulse Audio Volume Control features so we (KDE users and devs) don't need that installed again. Best, Daniel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Kickoff application uninstaller
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/5974/ --- (Updated 2010-11-25 23:44:39.182743) Review request for Plasma and Aaron Seigo. Summary --- Patch to use PackageKit session interface to "Uninstall" the applications. When kickoff starts it checks if the session interface is available, if it's not available the right click option to "Uninstall" applications will not be displayed. Diffs - /trunk/KDE/kdebase/workspace/plasma/desktop/applets/kickoff/ui/contextmenufactory.cpp 1200785 Diff: http://svn.reviewboard.kde.org/r/5974/diff Testing --- Screenshots (updated) --- Kickoff Uninstaller http://svn.reviewboard.kde.org/r/5974/s/563/ Thanks, Daniel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
