Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable e.g. a
dataengine please use the new namespace syntax in target_link_libraries. E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt in Plasma.)
Thanks,
-- sebas
-- Forwarded Message
Hey,
Import names. As we can't use our setContextProperty tricks in subclassed
Applets anymore, we'll have to resort more often to installing imports that
are very specific (i.e. not libraries per se, but more like C++ portions
needed for a certain applet). Examples are Kickoff, Icon, and the
Hey,
As I've been working quite a lot on KService's plugin infra lately, I have
some ideas about changes in Plasma.
Background: KPluginTrader is new API in KService. It can replace
KServiceTypeTrader, and thus the need to separately install .desktop files for
plugins. Feature-wise, it's very
Hello!
On Wed, Sep 25, 2013 at 3:11 PM, Sebastian Kügler se...@kde.org wrote:
I suggest to use org.kde.plasma.private.$widgetname
If I remember notmart suggested me to use, private.$pluginname
Log : * notmart would like private.org.kde.icon, and in general
private.plasmoid plugin name
On Wednesday 25 September 2013 11:41:36 Sebastian Kügler wrote:
Hey,
Import names. As we can't use our setContextProperty tricks in subclassed
Applets anymore, we'll have to resort more often to installing imports that
are very specific (i.e. not libraries per se, but more like C++ portions
On Wednesday, September 25, 2013 12:07:55 Marco Martin wrote:
On Wednesday 25 September 2013 11:41:36 Sebastian Kügler wrote:
Import names. As we can't use our setContextProperty tricks in subclassed
Applets anymore, we'll have to resort more often to installing imports
that
are very
On Wed, Sep 25, 2013 at 11:22 AM, Sebastian Kügler se...@kde.org wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt
On Wednesday 25 September 2013 12:17:52 Sebastian Kügler wrote:
so something like private.org.kde.plasma.widgetname or
.org.kde.private.plasma.widgetname
The leading . is purposeful?
ah, no ;)
the first would take a private at the first level, that maybe is not too
nice, but the nice
Sebastian Kügler wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have
a specialist opinion before going around and changing every single
CMakeLists.txt in Plasma.)
Running
git log -S
On Wednesday, September 25, 2013 12:40:12 Stephen Kelly wrote:
Sebastian Kügler wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have
a specialist opinion before going around and changing every
On Wednesday 25 September 2013 11:22:57 Sebastian Kügler wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt in
On Wed, Sep 25, 2013 at 10:41 AM, Sebastian Kügler se...@kde.org wrote:
Hey,
Import names. As we can't use our setContextProperty tricks in subclassed
Applets anymore, we'll have to resort more often to installing imports that
are very specific (i.e. not libraries per se, but more like C++
Hey all,
In Plasma, we've been looking into privatizing parts of the QML API we offer.
With Qt5, we rely less on setContextProperty() and friends, and use imports
more. That's a technical necessity that makes one problem more evident: It's
unclear what QML-facing API is reliable and stable,
On Tuesday, September 24, 2013 10:46:24 Matthias Klumpp wrote:
Sorry, I confused the naming here... And I am aware offen the previous
discussion (followed it, but was not involved) I just think that it might
make sense to start a New attempt on this, now that everyone is working
towards
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler se...@kde.org wrote:
Hey all,
In Plasma, we've been looking into privatizing parts of the QML API we
offer.
With Qt5, we rely less on setContextProperty() and friends, and use imports
more. That's a technical necessity that makes one problem
hidden under org.kde.* but that isn't the case anymore if you
introduce private.org.kde.*
From my POV, Sebastian's proposal is spot-on for that reason alone - it is
not a (public) 'qml kde import'. It is a private thing.
Cheerio,
Ivan
p.s. and, in all honesty grepping for org.kde will return
Hi guys, please CC me on replies, I'm not subscribed
With the new kde-workspace code, scripty says that all these .pot are not
generated anymore
+2013-05-08 templates/messages/kde-workspace/plasma_applet_clock.pot
+2013-05-08 templates/messages/kde-workspace/plasma_applet_dig_clock.pot
Hi Shantanu,
Thank you so much for putting so much effort on re-factoring fabian's
branch. I checked almost all major/minor features which i remember and all
of them works absolutely fine. There are some UI issues which can be fixed
later, but functionality wise most of the stuff works fine.
If
On Wednesday, September 25, 2013 11:48:50 Sebastian Kügler wrote:
I'd like to install our binary plugins into subdirectories. This is in line
+1
with how we'll do it across KF5. These plugins won't need .desktop files
+10
The new API also allows us to use packages' metadata for querying. It
On Wednesday, September 25, 2013 21:47:59 Aaron J. Seigo wrote:
On Wednesday, September 25, 2013 11:48:50 Sebastian Kügler wrote:
I'd like to install our binary plugins into subdirectories. This is in
line
+1
with how we'll do it across KF5. These plugins won't need .desktop files
Hey Albert,
On Wednesday, September 25, 2013 19:48:36 Albert Astals Cid wrote:
With the new kde-workspace code, scripty says that all these .pot are not
generated anymore
+2013-05-08 templates/messages/kde-workspace/plasma_applet_clock.pot
+2013-05-08
On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote:
When I asked Martin if he knew a way to do the xembed, he replied (being
Martin ;)) asking if we can just kill it and quoted starwars. I wonder: Can
we kill it yet?
I just had a discussion on G+ with a couple of our friends with
Git commit 5b33844a0b9e49759289dc839a31c0bc8f417d37 by Sebastian Kügler.
Committed on 25/09/2013 at 23:34.
Pushed by sebas into branch 'master'.
Look up dataengines in kf5/plasma/dataengines
This changes the path where to find dataengines to the
subdirectory-per-servicetype setup.
Note: You'll
On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote:
This changes the path where to find dataengines to the
subdirectory-per-servicetype setup.
for shit’s ‘n giggles: has anyone done any performance profiling of this new
system?
--
Aaron J. Seigo
El Dimecres, 25 de setembre de 2013, a les 23:32:18, Sebastian Kügler va
escriure:
Hey Albert,
On Wednesday, September 25, 2013 19:48:36 Albert Astals Cid wrote:
With the new kde-workspace code, scripty says that all these .pot are not
generated anymore
+2013-05-08
On Sept. 24, 2013, 10:31 a.m., Martin Gräßlin wrote:
no idea whether that's acceptable
shouldn't be much of an issue. KWindowSystem is emitting a signal, isn't
it? activeWindowChanged()
There's been concerns about waking up when windows were moved and KWindowSystem
has no
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler se...@kde.org wrote:
Hey all,
In Plasma, we've been looking into privatizing parts of the QML API we
offer.
With Qt5, we rely less on setContextProperty() and friends, and use imports
more. That's a technical necessity that makes one problem
On Thursday, September 26, 2013 02:05:12 Albert Astals Cid wrote:
They're all very much alive and kicking. Question: are those files not
generated anymore because no i18n calls are found, or is the Messages.sh
simply missing?
Either of the cases can be the reason, you'll have to look at
Hola,
On Thursday, September 26, 2013 02:23:31 Aleix Pol wrote:
Reducing API to maintain is a good thing, at least for complexity sake. But
of course there will be always the case where somebody needs (part of) the
private API.
The question would be then, why is it that there's some API
On Thursday, September 26, 2013 01:50:54 Aaron J. Seigo wrote:
On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote:
This changes the path where to find dataengines to the
subdirectory-per-servicetype setup.
for shit’s ‘n giggles: has anyone done any performance profiling of
On Thursday, September 26, 2013 04:21:21 Sebastian Kügler wrote:
You can find numbers of the SSD runs in my email Plugin locator performance
ballpark to kde-frameworks-devel from September, 5. I haven't cleaned up
my measurements on rotating metal.
oh wow, that is not encouraging. :/ i’m
On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote:
On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote:
When I asked Martin if he knew a way to do the xembed, he replied (being
Martin ;)) asking if we can just kill it and quoted starwars. I wonder:
Can
we kill it yet?
33 matches
Mail list logo
