theme cleanups and hidpi branch merged

Hi all, I've merged my sebas/hidpi branches into plasma-framework[master] and kde- workspace[master]. It's quite a number of small patches, so let me summarize some interesting bits. If you read all of this, there are screenshots looming at the end of this email. :) Theme Cleanup We wanted to

Review Request 115348: Create a MimeDatabase component that maps QMimeDatabase

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115348/ --- Review request for Plasma. Repository: plasma-framework Description ---

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

Re: KQuickControls

On Mon, Jan 27, 2014 at 10:52 PM, David Edmundson wrote: > On Mon, Jan 27, 2014 at 8:19 PM, Mark Gaiser wrote: >> >>> Alternatively we can make a new framework for all KDE bindings. (such >>> as KIO which is being discussed right now) >> >> Do you have more information about that? >> >> I'm aski

Re: KQuickControls

On Mon, Jan 27, 2014 at 8:19 PM, Mark Gaiser wrote: > >> Alternatively we can make a new framework for all KDE bindings. (such >> as KIO which is being discussed right now) > > Do you have more information about that? > > I'm asking because i probably have much of that already. Remember my > Accr

Re: KQuickControls

On Monday, 2014-01-27, 19:29:33, Marco Martin wrote: > > Alternatively we can make a new framework for all KDE bindings. (such > > as KIO which is being discussed right now) > > > > Thoughts? > > i would really like one of the following scenarios: > * qml binding that use a particular framework i

Re: KQuickControls

> Alternatively we can make a new framework for all KDE bindings. (such > as KIO which is being discussed right now) Do you have more information about that? I'm asking because i probably have much of that already. Remember my Accretion project. It uses KIO and is fully written in QML. _

Re: kde-workspace/plasma/generic/scriptengines

Done: Applet parts are gone. DataEngine parts are moved into plasma-framework. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [kde-promo] Plasma Next Naming - Take 2

El Dilluns, 27 de gener de 2014, a les 15:05:43, Jos Poortvliet va escriure: > On Monday 27 January 2014 14:37:03 Martin Klapetek wrote: > > Hey all, > > > > I've processed the discussion in the previous thread, we discussed it a > > bit > > in today's Plasma Monday hangout and here is a reiterati

Re: KQuickControls

On Monday 27 January 2014 19:15:56 David Edmundson wrote: > For a task in Plasma I've had to port KKeySequence to render on > QtQuick, using QtQuickControls. > > I expect over time we will see more KDE widgets having QtQuick > implementations as well. I expect a colour picker coming soon at > leas

Re: KQuickControls

On Monday 27 January 2014, David Edmundson wrote: > For a task in Plasma I've had to port KKeySequence to render on > QtQuick, using QtQuickControls. > > I expect over time we will see more KDE widgets having QtQuick > implementations as well. I expect a colour picker coming soon at > least. btw

KQuickControls

For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. I expect a colour picker coming soon at least. I can either add these components to KDeclarative, and create a ne

Re: Minutes Monday Plasma hangout

On Monday 27 January 2014, Sebastian Kügler wrote: > Plasma Meeting January, 27th, 2014 > Present: Martin Gräßlin, Marco Martin, Sebastian Kügler, Martin Klapetek, > Alex Fiestas > > sebas > - finish and merge hidpi branch > - to review notmart's branch > - collecting tasks for designer >

Re: Proposed fix for issue 330115

you have added build dir to your commit, you should not do that. The diff you get should look like this http://pastebin.kde.org/pcydxtqcg . The easier thing imo would be to make a fresh clone, re-apply your changes and remember not to add the build dir to your commits. On Mon, Jan 27, 2014 at 9:0

Re: Review Request 115326: fix theme cache cleanup and discarding

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115326/#review48389 --- Ship it! Seems good to me plasma/theme.cpp

kde-workspace/plasma/generic/scriptengines

Am I writing in thinking we should delete all the applet parts of the scriptengines in workspace? We can leave the python and ruby dataengine interfaces. I think everything else is outdated? If so I'll remove them. David ___ Plasma-devel mailing list P

Re: kde-workspace/plasma/generic/scriptengines

On Monday 27 January 2014, David Edmundson wrote: > Am I writing in thinking we should delete all the applet parts of the > scriptengines in workspace? > > We can leave the python and ruby dataengine interfaces. > I think everything else is outdated? > > If so I'll remove them. yes, applet scrip

Re: Proposed fix for issue 330115

On Mon, Jan 27, 2014 at 8:45 PM, Shantanu Tushar Jha wrote: > where COMMIT is the SHA of the commit just before your commits. > What does this mean ? In your example, you need to run "git diff > 166b33610ceb4e06976570c66ad9fbc3c60470f9" > I ran it and this is what I get as the output log : http

Re: Proposed fix for issue 330115

Hey Harish, It was a typo from my end, I meant "git show HEAD" but it would only show the diff of one commit. I see you have multiple commits in which case it is easier to do "git diff COMMIT" where COMMIT is the SHA of the commit just before your commits. In your example, you need to run "git dif

Re: [kde-promo] Plasma Next Naming - Take 2

On Monday, January 27, 2014 15:30:09 Martin Gräßlin wrote: > I remember several cases where we had issues which were not large enough to > stop the rolling of all of KDE SC, but there were certainly enough issues > which should have stopped a Plasma release. So I do hope that we use this > chance

Re: Re: [kde-promo] Plasma Next Naming - Take 2

On Monday 27 January 2014 15:14:46 Sebastian Kügler wrote: > On Monday, January 27, 2014 15:05:43 Jos Poortvliet wrote: > > > * Inside Plasma team, we'll start referring to the next version simply > > > as > > > > > > "Plasma Next". This will always be the "next major version to be > > > release

Re: Splitting kde-workspace and kde-runtime proposal

There is an existing page about slitting runtime here: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization linked to from http://community.kde.org/Frameworks/Epics Alex's wiki page looks far more populated. We should make sure we avoid wiki duplication. David _

Re: Proposed fix for issue 330115

Sorry for the late reply . Like I said earlier I was a bit busy shifting rooms . Anyways , I don't quite understand why git diff doesn't seem to work . Even "git diff HEAD" gives me a blank screen. I'm posting the output of "git log" if it helps in anyway . Here it is : http://pastebin.ubuntu.com/

Re: [kde-promo] Plasma Next Naming - Take 2

On Monday, January 27, 2014 15:05:43 Jos Poortvliet wrote: > > * Inside Plasma team, we'll start referring to the next version simply as > > > > "Plasma Next". This will always be the "next major version to be > > released". > > We encourage everyone to start using "Plasma Next", we don't want thi

Re: [kde-promo] Plasma Next Naming - Take 2

On Monday 27 January 2014 14:37:03 Martin Klapetek wrote: > Hey all, > > I've processed the discussion in the previous thread, we discussed it a bit > in today's Plasma Monday hangout and here is a reiteration of the naming > proposal. Please please /always/ keep plasma-devel in CC, if not, I'll >

Plasma Next Naming - Take 2

Hey all, I've processed the discussion in the previous thread, we discussed it a bit in today's Plasma Monday hangout and here is a reiteration of the naming proposal. Please please /always/ keep plasma-devel in CC, if not, I'll hunt you down at Akademy and give you a disapproving look. Alright,

Re: Minutes Monday Plasma hangout

On Monday 27 January 2014 13:07:30 Sebastian Kügler wrote: > mgraesslin > - Wayland porting: KWindowInfo seems to work now "working" here means "don't crash". It's clearly not working in the normal definition of working yet > - builtin kwineffects no longer a plugin, but a lib -> more secure o

Minutes Monday Plasma hangout

Plasma Meeting January, 27th, 2014 Present: Martin Gräßlin, Marco Martin, Sebastian Kügler, Martin Klapetek, Alex Fiestas sebas - finish and merge hidpi branch - to review notmart's branch - collecting tasks for designer - start release schedule discussion on plasma-devel - fix sytemt

Review Request 115326: fix theme cache cleanup and discarding

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115326/ --- Review request for Plasma, Aaron J. Seigo and Martin Klapetek. Repository

Re: Splitting kde-workspace and kde-runtime proposal

I don't clearly understand why KUriFilter-Plugins should go to plasma- workspace. I noticed KUriFilter is defined in kio and its plugins are used e.g. in kparts (browserextension). Shouldn't these go to kio? 2014/1/22 Kevin Ottens > On Tuesday 21 January 2014 12:05:26 Antonis Tsiapaliokas wrote

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 sam

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