Re: Planning merging the single qqml engine

[Marco Martin]

On Monday 18 May 2015, Ivan Čukić wrote:
> While I'm usually more conservative, I do think that something more
> decisive should be done in this case (and cases like these). While we
> do not want to break everything with each new release (wink wink ghm
> ghm nudge nudge), I don't think we want to support every
> not-still-preferred-approach-of-implementing-something we made before
> indefinitely.

a very crude approach may be maintaining a white list of name+version of the 
applets that needs this, just to make old workspace work for a while and 
eventually removing it

> If there are important 3rd-party plasma 5 applets (are there?) that we
> really need to keep back-compatibility for, I'd propose this:

we should goover kdelook i gues, there should be 5-6 plasmoids there

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[Marco Martin]

On Tuesday 19 May 2015, Marco Martin wrote:
> On Monday 18 May 2015, Ivan Čukić wrote:
> > While I'm usually more conservative, I do think that something more
> > decisive should be done in this case (and cases like these). While we
> > do not want to break everything with each new release (wink wink ghm
> > ghm nudge nudge), I don't think we want to support every
> > not-still-preferred-approach-of-implementing-something we made before
> > indefinitely.
> 
> a very crude approach may be maintaining a white list of name+version of
> the applets that needs this, just to make old workspace work for a while
> and eventually removing it

the applets are:
http://lxr.kde.org/search?_filestring=&_string=plasmapackage%3A%2F

- bluetooth
- pager
- desktop cont
- panel cont
- analog clock
- battery
- notifications
- systray

the check can be done on those plugin names on appletquickitem line 52 
so if the plugin name is one of them and the plugin version is less than some 
value bigger than all of them, go multiple engines

and yeah, that check in ~6 months or so would be removed

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[Marco Martin]

On Monday 18 May 2015, David Edmundson wrote:
> Now to make you hate me.
> I have a crash, https://paste.kde.org/ppeqjl1c1
> 
> That's running:
> kdeclarative - your branch
> plasma-framework - your branch
> plsama-workspace - master
> (which is pretty close to running latest frameworks with Plasma 5.3)
> 
> It's possibly unrelated, but I switched the top two back to master and it
> went away.

tried to run with p-w master, not getting that crash

the bt says that  Plasma::PluginLoader::self()->loadApplet() is somehow 
failing and returning a null ptr, that suggests it's not finding a valid 
package for it (wonder if i should return a new Applet * in any case there to 
be at least sure it's a valid pointer)

can you see in console output at the last time that says
"Loading applet: "
what applet name says?

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[Marco Martin]

On Monday 18 May 2015, Ivan Čukić wrote:
>  - make it opt-in (as Marco says)
>  - deprecate it
>  - report notifications to the user 'this applet might make your
> desktop unstable' for all used applets that haven't opted-in - this
> would serve as a notification both to the users and the developers of
> said applets
>  - schedule marking the support for these applets for the release
> after next, or something.

this is with the explicitly white list
is a thing that kills kittens and is over the top weird behavior, but at least 
doesn't force to litter metadatas and makes possible to definitely drop the 
legacy at some point

-- 
Marco Martin
diff --git a/src/plasmaquick/appletquickitem.cpp b/src/plasmaquick/appletquickitem.cpp
index 3ffe269..b6d23d3 100644
--- a/src/plasmaquick/appletquickitem.cpp
+++ b/src/plasmaquick/appletquickitem.cpp
@@ -42,6 +42,9 @@ namespace PlasmaQuick
 
 QHash AppletQuickItemPrivate::s_rootObjects = QHash();
 
+QSet AppletQuickItemPrivate::s_legacyApplets = QSet({"org.kde.plasma.bluetooth", "org.kde.plasma.pager", "org.kde.desktopcontainment", "org.kde.plasma.folder", "org.kde.panel", "org.kde.plasma.analogclock", "org.kde.plasma.battery", "org.kde.plasma.systemtray"});
+
+
 AppletQuickItemPrivate::AppletQuickItemPrivate(Plasma::Applet *a, AppletQuickItem *item)
 : q(item),
   switchWidth(-1),
@@ -49,7 +52,13 @@ AppletQuickItemPrivate::AppletQuickItemPrivate(Plasma::Applet *a, AppletQuickIte
   applet(a),
   expanded(false)
 {
-if (a->pluginInfo().property("X-Plasma-RequiredExtensions").toStringList().contains("SharedEngine")) {
+//TODO: remove the legacy support at some point
+//use the shared engine only for applets that are nt in the legacy list
+//if they are, use the shared engine if their mayor version is at least 3
+const QStringList version = a->pluginInfo().version().split(".");
+if (!AppletQuickItemPrivate::s_legacyApplets.contains(a->pluginInfo().pluginName()) ||
+ (!version.isEmpty() && version.first().toInt() >= 3)) {
+
 qmlObject = new KDeclarative::QmlObjectSharedEngine(q);
 if (!qmlObject->engine()->urlInterceptor()) {
 PackageUrlInterceptor *interceptor = new PackageUrlInterceptor(qmlObject->engine(), Plasma::Package());
diff --git a/src/plasmaquick/private/appletquickitem_p.h b/src/plasmaquick/private/appletquickitem_p.h
index c754a80..79c1a2e 100644
--- a/src/plasmaquick/private/appletquickitem_p.h
+++ b/src/plasmaquick/private/appletquickitem_p.h
@@ -104,6 +104,7 @@ public:
 bool expanded : 1;
 
 static QHash s_rootObjects;
+static QSet s_legacyApplets;
 };
 
 }
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[David Edmundson]

On Mon, May 18, 2015 at 8:28 PM, Marco Martin  wrote:

> Hi all,
>
> I think the branches for the single shared qqmlengine are pretty much ready
> (few cleanups upcoming days), seems pretty stable here.. did someone ran
> the
> branch for a while as well?
>
> In the end i managed to get a single engine for the whole session, views
> included (had to duplicate the View class in plasmaquick and kept the old
> one
> as deprecated for retrocompatibility unfortunately)
>
> the memory save seems pretty good, i *hope* stability improved as well :p
>
> what still uses separed engines are the applet configuration dialogs: this
> is
> necessary because they are supposed to use a different style for the
> qquickcontrols, and being the settings object that decides the style a qml
> singleton (qml singletons are unique by engine), the engine has to be
> different from the desktop/panel. The good thing is that config dialogs are
> instantiated relatively rarely, in most sessions not at all, so shouldn't
> touch too much a "normal run"
>
> For retrocompatibility the applets unfortunately have to specify explicitly
> they can share the engine in their metadata file (or eventual
> plasmapackage:/
> urls break)
>
> at the moment it's using
> X-Plasma-RequiredExtensions=SharedEngine
>
> but I'm leaning more on the direction of something like
> X-Plasma-MinimumAPIVersion=5.11
>
> I would like to have all set before frameworks 5.11
>
> One thing you and I talked about once was having the shell have a hook in
p-f to call a static method setting what version of plasma-framework it was
expecting.
Would that be a suitable solution here?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Planning merging the single qqml engine

[Marco Martin]

On Tuesday 19 May 2015, David Edmundson wrote:
> > I would like to have all set before frameworks 5.11
> > 
> > One thing you and I talked about once was having the shell have a hook in
> 
> p-f to call a static method setting what version of plasma-framework it was
> expecting.
> Would that be a suitable solution here?

who would cann that on what?

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123846: Enable translations for devicenotifications dataengine

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123846/#review80617
---


+1 on the plasma side, for backporting too

- David Edmundson


On May 18, 2015, 11:21 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123846/
> ---
> 
> (Updated May 18, 2015, 11:21 p.m.)
> 
> 
> Review request for Localization and Translation (l10n) and Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The patch should be quite straightforward, but see below.
> 
> If correct, can I apply it to Plasma/5.3 as well? Allowing translations of 
> previously untranslatable strings does not break the string freeze.
> 
> 
> Diffs
> -
> 
>   dataengines/devicenotifications/CMakeLists.txt 0b89b5e 
>   dataengines/devicenotifications/Messages.sh PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123846/diff/
> 
> 
> Testing
> ---
> 
> I could not test it, sorry, but I had to report it before forgetting.
> 
> 
> Thanks,
> 
> Luigi Toscano
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 is awesome...and some help required with build instructions

[David Edmundson]

On Tue, May 19, 2015 at 2:10 AM, Siddhartha  wrote:

> On 18 May 2015 at 22:58, David Edmundson 
> wrote:
>
>> Just setting up on a new machine and thought I'd try following these
>> instructions exactly, the way a new developer would.
>>
>> I got stuck on something I don't know how to solve.
>>
>> Under Kubuntu because Qt is compiled with a hardcoded plugindir for some
>> reason.
>> This means setting QT_PLUGIN_PATH env variables does nothing, which means
>> you'll always be loading any plugins from /usr/ rather than the ones we
>> just built.
>>
>> How did you get round that? Any ideas?
>>
>
> By using Arch Linux? :P
>
> >I did not do anything special in this regard, so I guess on my system
QT_PLUGIN_PATH is being picked up properly.


Yes, it's only a problem on Kubuntu.

But someone who wrote this must have been a Kubuntu user, there is a list
of dependencies.

It's also solvable by compiling Qt, but I don't really want to have to
force new devs to do that unless I have to.


>
Btw, you commented out QTDIR in the wiki script, so a few of the later
> variables will have weird paths (QTDIR/plugins=/plugins)
>

Ah, yes, it's better to have it try to access a folder that doesn't exist.
Thanks, fixed.


>
>
> ___
> 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 5 is awesome...and some help required with build instructions

[Martin Klapetek]

On Tue, May 19, 2015 at 12:30 PM, David Edmundson <
da...@davidedmundson.co.uk> wrote:

>
> But someone who wrote this must have been a Kubuntu user, there is a list
> of dependencies.
>

That was added by me about 2 weeks ago when I tried to follow
that setup as well on a clean system where I had to figure out all
the deps. So I thought it might come handy to others and added
it there.

Nevertheless, I also hit the same problem as you did. I didn't solve
it yet because my laptop has other (more severe) issues with
Linux currently.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 123854: Add missing TRANSLATION_DOMAIN for dataengines keystae, network, rss, weather

[Burkhard Lück]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123854/
---

Review request for Localization and Translation (l10n) and Plasma.


Repository: plasma-workspace


Description
---

Should be applied to Plasma/5.3 as well


Diffs
-

  dataengines/network/CMakeLists.txt a9b0e29 
  dataengines/keystate/CMakeLists.txt 589a72b 
  dataengines/rss/CMakeLists.txt 65b5070 
  dataengines/weather/CMakeLists.txt fda6cc7 

Diff: https://git.reviewboard.kde.org/r/123854/diff/


Testing
---


Thanks,

Burkhard Lück

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123854: Add missing TRANSLATION_DOMAIN for dataengines keystae, network, rss, weather

[Burkhard Lück]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123854/
---

(Updated Mai 19, 2015, 12:02 nachm.)


Review request for Localization and Translation (l10n) and Plasma.


Repository: plasma-workspace


Description (updated)
---

Should be applied to Plasma/5.3 as well ?


Diffs
-

  dataengines/network/CMakeLists.txt a9b0e29 
  dataengines/keystate/CMakeLists.txt 589a72b 
  dataengines/rss/CMakeLists.txt 65b5070 
  dataengines/weather/CMakeLists.txt fda6cc7 

Diff: https://git.reviewboard.kde.org/r/123854/diff/


Testing
---


Thanks,

Burkhard Lück

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123682: Plasma-Desktop: Port kcm fonts to QML.

[Antonis Tsiapaliokas]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123682/
---

(Updated May 19, 2015, 2:47 p.m.)


Review request for Plasma.


Changes
---

I have fix the layouting issues. (see screenshot)

Should i merge this one in the kcmQmlPorts branch?


Repository: plasma-desktop


Description
---

This patch ports the kcm fonts to QML.


Diffs (updated)
-

  kcms/fonts/CMakeLists.txt d73636e 
  kcms/fonts/fonts.cpp 74da799 
  kcms/fonts/fonts.desktop 5b486ed 
  kcms/fonts/fonts.h d98bbe2 
  kcms/fonts/kcm_fonts.desktop PRE-CREATION 
  kcms/fonts/package/contents/ui/main.qml PRE-CREATION 
  kcms/fonts/package/metadata.desktop PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/123682/diff/


Testing
---

Everything works execpt from the ComboBox and the FontDialog ("Configure Font").

* FontDialog

If you open the kcm inside from the system settings, everything is ok.

If you use kcmshell5 fonts, the FontDialog is opening behing the kcm window.
In order to solve this issue we must use the setTransientParent, but how can
i do that in the FontDialog?

* ComboBox

If you open the kcm with the "kcmshell5 fonts", the dropdown menu renders fine.

But if you open it inside from the system settings, the dropdown menu, renders
in the left of the ComboBox.


Also these two signals (main.qml line 295)

onDpiChanged 
onAliasingChanged 

are being emitted but the kcm.needsSave doesn't work...


File Attachments (updated)


fonts qml port
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/05/19/467d70b7-69c8-4ad1-8da5-db0e9320bc03__fonts_qml2.png


Thanks,

Antonis Tsiapaliokas

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123735: version of QmlObject with a static engine

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123735/#review80630
---



src/kdeclarative/qmlobjectsharedengine.cpp (line 41)


On first run `s_engine` is 0, so this will not actually clean up the 
`QQmlEngine`



src/kdeclarative/qmlobjectsharedengine.cpp (line 60)


I'm probably missing some parts of the picture. Could you please explain 
why this needs to be static?

Also, you could just combine the QSharedPointer and the normal pointer.


- Vishesh Handa


On May 18, 2015, 8 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123735/
> ---
> 
> (Updated May 18, 2015, 8 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> to make easier doing applications like plasma that use a lot of qml to have a 
> single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
> has a single, static QQmlEngine
> 
> Adds a class called QuickViewSharedEngine that has the same behavior as 
> QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() 
> for each instance.
> This is used by desktopviews and panelviews to share their engine.
> 
> Unfortunately it may not be possible to get the applet configuration dialogs 
> to use this, since they still need a separed engine in order to have a 
> different controls style (qstyle based) than the stuff in the desktop/panel
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt d73bff0 
>   src/kdeclarative/kdeclarative.cpp b3906e2 
>   src/kdeclarative/qmlobject.h f26b67d 
>   src/kdeclarative/qmlobject.cpp c483665 
>   src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
>   src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
>   src/quickaddons/CMakeLists.txt 777d07c 
>   src/quickaddons/quickviewsharedengine.h PRE-CREATION 
>   src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123735: version of QmlObject with a static engine

[Marco Martin]

> On May 19, 2015, 3:04 p.m., Vishesh Handa wrote:
> > src/kdeclarative/qmlobjectsharedengine.cpp, line 60
> > 
> >
> > I'm probably missing some parts of the picture. Could you please 
> > explain why this needs to be static?
> > 
> > Also, you could just combine the QSharedPointer and the normal pointer.

the whole point is to have a single instance per process...
or could be done differently, like with a Q_GLOBAL_STATIC...


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123735/#review80630
---


On May 18, 2015, 8 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123735/
> ---
> 
> (Updated May 18, 2015, 8 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> to make easier doing applications like plasma that use a lot of qml to have a 
> single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
> has a single, static QQmlEngine
> 
> Adds a class called QuickViewSharedEngine that has the same behavior as 
> QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() 
> for each instance.
> This is used by desktopviews and panelviews to share their engine.
> 
> Unfortunately it may not be possible to get the applet configuration dialogs 
> to use this, since they still need a separed engine in order to have a 
> different controls style (qstyle based) than the stuff in the desktop/panel
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt d73bff0 
>   src/kdeclarative/kdeclarative.cpp b3906e2 
>   src/kdeclarative/qmlobject.h f26b67d 
>   src/kdeclarative/qmlobject.cpp c483665 
>   src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
>   src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
>   src/quickaddons/CMakeLists.txt 777d07c 
>   src/quickaddons/quickviewsharedengine.h PRE-CREATION 
>   src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123735: version of QmlObject with a static engine

[Vishesh Handa]

> On May 19, 2015, 3:04 p.m., Vishesh Handa wrote:
> > src/kdeclarative/qmlobjectsharedengine.cpp, line 60
> > 
> >
> > I'm probably missing some parts of the picture. Could you please 
> > explain why this needs to be static?
> > 
> > Also, you could just combine the QSharedPointer and the normal pointer.
> 
> Marco Martin wrote:
> the whole point is to have a single instance per process...
> or could be done differently, like with a Q_GLOBAL_STATIC...

So does each applet construct its own `QmlObjectSharedEngine`?

Maybe we can disable this class's constructor and just have a `static 
QQmlObjectSharedEngine* instance()` method? It'll make the semantics much 
clearer.


- Vishesh


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123735/#review80630
---


On May 18, 2015, 8 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123735/
> ---
> 
> (Updated May 18, 2015, 8 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> to make easier doing applications like plasma that use a lot of qml to have a 
> single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
> has a single, static QQmlEngine
> 
> Adds a class called QuickViewSharedEngine that has the same behavior as 
> QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() 
> for each instance.
> This is used by desktopviews and panelviews to share their engine.
> 
> Unfortunately it may not be possible to get the applet configuration dialogs 
> to use this, since they still need a separed engine in order to have a 
> different controls style (qstyle based) than the stuff in the desktop/panel
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt d73bff0 
>   src/kdeclarative/kdeclarative.cpp b3906e2 
>   src/kdeclarative/qmlobject.h f26b67d 
>   src/kdeclarative/qmlobject.cpp c483665 
>   src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
>   src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
>   src/quickaddons/CMakeLists.txt 777d07c 
>   src/quickaddons/quickviewsharedengine.h PRE-CREATION 
>   src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123735: version of QmlObject with a static engine

[Marco Martin]

> On May 19, 2015, 3:04 p.m., Vishesh Handa wrote:
> > src/kdeclarative/qmlobjectsharedengine.cpp, line 60
> > 
> >
> > I'm probably missing some parts of the picture. Could you please 
> > explain why this needs to be static?
> > 
> > Also, you could just combine the QSharedPointer and the normal pointer.
> 
> Marco Martin wrote:
> the whole point is to have a single instance per process...
> or could be done differently, like with a Q_GLOBAL_STATIC...
> 
> Vishesh Handa wrote:
> So does each applet construct its own `QmlObjectSharedEngine`?
> 
> Maybe we can disable this class's constructor and just have a `static 
> QQmlObjectSharedEngine* instance()` method? It'll make the semantics much 
> clearer.

yes, it must have its own QmlObjectSharedEngine, it can't be a singleton by 
itself, because each applet must have a different root QQmlContext


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123735/#review80630
---


On May 18, 2015, 8 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123735/
> ---
> 
> (Updated May 18, 2015, 8 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> to make easier doing applications like plasma that use a lot of qml to have a 
> single engine make a subclass of QmlObject called QmlObjectSharedEngine that 
> has a single, static QQmlEngine
> 
> Adds a class called QuickViewSharedEngine that has the same behavior as 
> QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() 
> for each instance.
> This is used by desktopviews and panelviews to share their engine.
> 
> Unfortunately it may not be possible to get the applet configuration dialogs 
> to use this, since they still need a separed engine in order to have a 
> different controls style (qstyle based) than the stuff in the desktop/panel
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/CMakeLists.txt d73bff0 
>   src/kdeclarative/kdeclarative.cpp b3906e2 
>   src/kdeclarative/qmlobject.h f26b67d 
>   src/kdeclarative/qmlobject.cpp c483665 
>   src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION 
>   src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION 
>   src/quickaddons/CMakeLists.txt 777d07c 
>   src/quickaddons/quickviewsharedengine.h PRE-CREATION 
>   src/quickaddons/quickviewsharedengine.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/123735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 123855: Split obsolete language docbook into translations + format docbook

[Burkhard Lück]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123855/
---

Review request for Documentation, Plasma, John Layt, and Sebastian Kügler.


Repository: plasma-desktop


Description
---

The obsolete language docbook is splitted into translations + format docbook 
with updated content

I added a FIXME in the translations docbook about the (for me) 
strange/unexpected behavior of the "Available Languages" list
and need some input whether my findings are correct and what of the FIXME 
content should be visible in the docbook


Diffs
-

  doc/kcontrol/CMakeLists.txt c2f27d5 
  doc/kcontrol/formats/CMakeLists.txt PRE-CREATION 
  doc/kcontrol/formats/index.docbook PRE-CREATION 
  doc/kcontrol/language/CMakeLists.txt c0fb059 
  doc/kcontrol/language/index.docbook ea9f4ef 
  doc/kcontrol/language/oxygen-22x22-document-revert.png 75ff210 
  doc/kcontrol/translations/CMakeLists.txt PRE-CREATION 
  doc/kcontrol/translations/index.docbook PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/123855/diff/


Testing
---

Builds


Thanks,

Burkhard Lück

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123854: Add missing TRANSLATION_DOMAIN for dataengines keystae, network, rss, weather

[Lukáš Tinkl]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123854/#review80637
---

Ship it!


Yes, please backport as well

- Lukáš Tinkl


On Kvě. 19, 2015, 2:02 odp., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123854/
> ---
> 
> (Updated Kvě. 19, 2015, 2:02 odp.)
> 
> 
> Review request for Localization and Translation (l10n) and Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Should be applied to Plasma/5.3 as well ?
> 
> 
> Diffs
> -
> 
>   dataengines/network/CMakeLists.txt a9b0e29 
>   dataengines/keystate/CMakeLists.txt 589a72b 
>   dataengines/rss/CMakeLists.txt 65b5070 
>   dataengines/weather/CMakeLists.txt fda6cc7 
> 
> Diff: https://git.reviewboard.kde.org/r/123854/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123854: Add missing TRANSLATION_DOMAIN for dataengines keystae, network, rss, weather

[Luigi Toscano]

> On May 19, 2015, 7:21 p.m., Lukáš Tinkl wrote:
> > Yes, please backport as well

Burkhard, please commit to Plasma/5.3; I will do the same, then merge into 
master.


- Luigi


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123854/#review80637
---


On May 19, 2015, 2:02 p.m., Burkhard Lück wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123854/
> ---
> 
> (Updated May 19, 2015, 2:02 p.m.)
> 
> 
> Review request for Localization and Translation (l10n) and Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Should be applied to Plasma/5.3 as well ?
> 
> 
> Diffs
> -
> 
>   dataengines/network/CMakeLists.txt a9b0e29 
>   dataengines/keystate/CMakeLists.txt 589a72b 
>   dataengines/rss/CMakeLists.txt 65b5070 
>   dataengines/weather/CMakeLists.txt fda6cc7 
> 
> Diff: https://git.reviewboard.kde.org/r/123854/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Burkhard Lück
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 is awesome...and some help required with build instructions

[Siddhartha]

On 19 May 2015 at 16:00, David Edmundson  wrote:
> Yes, it's only a problem on Kubuntu.
>
> It's also solvable by compiling Qt, but I don't really want to have to force 
> new devs to do that unless I have to.

We should talk to the Kubuntu devs to see why its hardcoded that way,
and ask them to remove that config option if possible. If not, the
other way would be to use KDE_INSTALL_USE_QT_SYS_PATHS as Alex
mentioned and add 'make-install-prefix sudo' to the kdesrc-build
config.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123854: Add missing TRANSLATION_DOMAIN for dataengines keystae, network, rss, weather

[Burkhard Lück]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123854/
---

(Updated May 19, 2015, 6:26 p.m.)


Status
--

This change has been marked as submitted.


Review request for Localization and Translation (l10n) and Plasma.


Changes
---

Submitted with commit 205f04ca2d0c71cdd4443618cd097e1514280b89 by Burkhard Lück 
to branch Plasma/5.3.


Repository: plasma-workspace


Description
---

Should be applied to Plasma/5.3 as well ?


Diffs
-

  dataengines/network/CMakeLists.txt a9b0e29 
  dataengines/keystate/CMakeLists.txt 589a72b 
  dataengines/rss/CMakeLists.txt 65b5070 
  dataengines/weather/CMakeLists.txt fda6cc7 

Diff: https://git.reviewboard.kde.org/r/123854/diff/


Testing
---


Thanks,

Burkhard Lück

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Breeze] [Bug 347547] Qt4 applications use wrong palette and icons w/ Breeze

[Matthias Dahl]

https://bugs.kde.org/show_bug.cgi?id=347547

--- Comment #8 from Matthias Dahl  ---
Further investigation revealed the following:

1)
If KDE_SESSION_VERSION=5, kdeglobals is first searched for in "~/.kde/" while
with KDE_SESSION_VERSION=4 it is "~/.kde4/". This comes as a surprise since
kdelibs is configured properly with kde4 and kcoreaddons with prefix "4". And
since KShareConfig and alike use KStandardDirs (which should all be ".kde4"), I
don't see where the ".kde" comes from at all. The environment is clean as well,
no KDEHOME or alike is set.

2)
Setting a symlink .kde -> .kde4 works around the problem and no matter what
KDE_SESSION_VERSION (4 or 5), Qt4 apps show properly.

3)
The color that doesn't get picked up when not everything is properly in place
is "BackgroundNormal" from the "Colors:Selection" section of kdeglobals.

4)
I filed a bug downstream with Gentoo as well
(https://bugs.gentoo.org/show_bug.cgi?id=549824), since this might very well be
a packaging bug (or perhaps partly) since I am not able to reproduce this on
either OpenSuSE Tumbleweed nor Kubuntu. Nevertheless, any help on this matter
would be greatly appreciated since I have spent countless hours trying to hunt
this problem down and I am still at it, unfortunately. :(

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Breeze] [Bug 347547] Qt4 applications use wrong palette and icons w/ Breeze

[Matthias Dahl]

https://bugs.kde.org/show_bug.cgi?id=347547

--- Comment #9 from Matthias Dahl  ---
I forgot to mention in (1): Setting KDE_SESSION_VERSION to either 4 or 5 only
influences whether ".kde4" or ".kde" is first searched, but after that, ".kde4"
is always searched as well. So setting K_S_V to 5 does not result in ".kde"
exclusively being searched at all... it is just searched first while with 4 it
is not searched at all ever.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123846: Enable translations for devicenotifications dataengine

[Luigi Toscano]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123846/
---

(Updated May 19, 2015, 8:39 p.m.)


Status
--

This change has been marked as submitted.


Review request for Localization and Translation (l10n) and Plasma.


Changes
---

Submitted with commit b174a3c92601853bc499d9c2dc62fd8b440cbba8 by Luigi Toscano 
to branch Plasma/5.3.


Repository: plasma-workspace


Description
---

The patch should be quite straightforward, but see below.

If correct, can I apply it to Plasma/5.3 as well? Allowing translations of 
previously untranslatable strings does not break the string freeze.


Diffs
-

  dataengines/devicenotifications/CMakeLists.txt 0b89b5e 
  dataengines/devicenotifications/Messages.sh PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/123846/diff/


Testing
---

I could not test it, sorry, but I had to report it before forgetting.


Thanks,

Luigi Toscano

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123783: Adjust showing desktop behavior

[Thomas Lübking]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123783/
---

(Updated May 19, 2015, 9:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin 
Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer.


Changes
---

Submitted with commit f3b69b0ed0d3fa863ed4b2233ac5ce6c5fcdd9c3 by Thomas 
Lübking to branch Plasma/5.3.


Bugs: 346837, 346933 and 347212
https://bugs.kde.org/show_bug.cgi?id=346837
https://bugs.kde.org/show_bug.cgi?id=346933
https://bugs.kde.org/show_bug.cgi?id=347212


Repository: kwin


Description
---

Errhe... while we're waiting for final comments of the HIG group ;-)
Here's a patch that *mostly* restores the 5.2 behavior

Notable differences:

1) The minimizability of windows is ignored. It's a cornercase, but the former 
behavior was a side-effect of the implementation. (At least I don't know a 
reason to keep them)

2) The state is broken with the *activation* of windows, not them becoming 
visible. Latter doesn't work for most cases (unminimizing) for obvious reasons 
(they're not minimized ;-) and when a new window is mapped, the focus stealing 
prevention seems a good filter (if it's not good enough to gain the focus, it's 
not good enough to break the state either ;-)

3) Keep above windows remain visible and do not break the state (as if they'd 
belong to the desktop) for a request by the HIG group. I'm frankly not sure 
about the background of this behavior (hopefully not krunner - that doesn't 
work)

4) Windows in the desktop group initially remain above the desktop and can be 
activated w/ breaking the state, but can also hide behind the desktop (notably 
when that is clicked/activated)


Diffs
-

  activation.cpp fe0a51f 
  client.h 40d503c 
  client.cpp a6fbf3e 
  layers.cpp b6d5b75 
  manage.cpp 75af4e5 
  workspace.cpp 09ae9a2 

Diff: https://git.reviewboard.kde.org/r/123783/diff/


Testing
---


Thanks,

Thomas Lübking

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel