On 2023-11-05 18:35, christ...@cullmann.io wrote:
On 2023-11-05 18:01, Nate Graham wrote:
On 11/5/23 07:42, Kevin Ottens wrote:
I was clumsily advocating for this Akademy 2021 or 2022 (can't
remember
which).
This way it's clearer to application authors when they tie themselves
to a
given wo
On 11/7/23 12:22, Jonathan Esk-Riddell wrote:
On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:
kactivities and kactivities-stats: please consider proper de-KF-ication now
Hi,
with plasma-framework, kactivities and kactivities entering the Plasma product
bundle, I assum
On Wed, Nov 8, 2023 at 12:22 AM Jonathan Esk-Riddell
wrote:
> On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:
> > kactivities and kactivities-stats: please consider proper de-KF-ication
> now
> >
> > Hi,
> >
> > with plasma-framework, kactivities and kactivities entering
On Sun, Nov 05, 2023 at 12:59:28PM +0100, Friedrich W. H. Kossebau wrote:
> kactivities and kactivities-stats: please consider proper de-KF-ication now
>
> Hi,
>
> with plasma-framework, kactivities and kactivities entering the Plasma
> product
> bundle, I assume they also will adapt to Plasma
Hi,
+1 to what Carl said. Right now my Elisa barely needs any time to read my
music library, presumably because Baloo already has it indexed. It'll be
quite a shame if apps did their own indexing, wasting time and power.
The effects (of removing Baloo support) are even more pronounced if we
consi
On Sunday, November 5, 2023 6:01:38 PM CET Nate Graham wrote:
> On 11/5/23 07:42, Kevin Ottens wrote:
> > I was clumsily advocating for this Akademy 2021 or 2022 (can't remember
> > which).
> >
> > This way it's clearer to application authors when they tie themselves to a
> > given workspace or no
On 2023-11-05 18:01, Nate Graham wrote:
On 11/5/23 07:42, Kevin Ottens wrote:
I was clumsily advocating for this Akademy 2021 or 2022 (can't
remember
which).
This way it's clearer to application authors when they tie themselves
to a
given workspace or not.
Also, isn't Elisa able to work wit
On 11/5/23 07:42, Kevin Ottens wrote:
I was clumsily advocating for this Akademy 2021 or 2022 (can't remember
which).
This way it's clearer to application authors when they tie themselves to a
given workspace or not.
Also, isn't Elisa able to work without Baloo? It even seems to do the right
th
Am Sonntag, 5. November 2023, 15:32:21 CET schrieb christ...@cullmann.io:
> On 2023-11-05 15:11, Nate Graham wrote:
> > On 11/5/23 07:09, christ...@cullmann.io wrote:
> >> if we are atm moving stuff, might it make sense to move Baloo, too,
> >> given it only
> >> is usable with the daemon inside Pl
Hello,
On Sunday, 5 November 2023 15:32:21 CET christ...@cullmann.io wrote:
> On 2023-11-05 15:11, Nate Graham wrote:
> > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make
> > them haul in Plasma stuff.
>
> some applications link to kactivities, too.
> I think it just makes it
On 2023-11-05 15:11, Nate Graham wrote:
On 11/5/23 07:09, christ...@cullmann.io wrote:
On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote:
Hi,
with plasma-framework, kactivities and kactivities entering the
Plasma product
bundle, I assume they also will adapt to Plasma versioning.
Hi,
if
On 11/5/23 07:09, christ...@cullmann.io wrote:
On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote:
Hi,
with plasma-framework, kactivities and kactivities entering the Plasma
product
bundle, I assume they also will adapt to Plasma versioning.
Hi,
if we are atm moving stuff, might it make s
On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote:
Hi,
with plasma-framework, kactivities and kactivities entering the Plasma
product
bundle, I assume they also will adapt to Plasma versioning.
Hi,
if we are atm moving stuff, might it make sense to move Baloo, too,
given it only
is usab
One down:
https://invent.kde.org/frameworks/kirigami/-/merge_requests/200
El dia 29 febr. 2016 5:34 p. m., "Marco Martin" va
escriure:
>
> Git commit 40b99a91222f59a6172b8673536c3c15c0458bf6 by Marco Martin.
> Committed on 29/02/2016 at 16:31.
> Pushed by mart into branch 'master'.
>
> if path is passed, pick the tail
>
> PluginLoader::loadApplet works both by passing a
On Wed, Aug 26, 2015 at 5:38 AM, Christoph Feck wrote:
> On Wednesday 26 August 2015 11:27:05 Leslie Zhai wrote:
> > Git commit 4e9b32d80d6b43ad3d1ddd47c948ad066608b052 by Leslie
> Zhai.
> > Committed on 26/08/2015 at 09:24.
> > Pushed by lesliezhai into branch 'master'.
> >
> > plasma: Fix apple
On Wednesday 26 August 2015 11:27:05 Leslie Zhai wrote:
> Git commit 4e9b32d80d6b43ad3d1ddd47c948ad066608b052 by Leslie
Zhai.
> Committed on 26/08/2015 at 09:24.
> Pushed by lesliezhai into branch 'master'.
>
> plasma: Fix applet actions might be nullptr
> BUG:351777
>
> M +1-1src/plasm
On Friday 10 of October 2014 16:23:41 David Edmundson wrote:
> Packagers,
>
> It seems Plasma 5.0 does NOT run smoothly against Plasma Framework 5.3.
>
> It would be easiest if distros hold off shipping frameworks 5.3 until
> Plasma 5.1 when Plasma5.1 is released.
>
> Clearly this is a screw-up
On Fri, May 23, 2014 at 12:22 PM, Sebastian Kügler wrote:
> On Friday, May 23, 2014 12:18:55 Marco Martin wrote:
> > I think it's a counter-effect of when i removed KConfigWidgets from
> > libplasma. there is definitely a problem in the cmake there, qt5::gui
> > should be in public in libplasma,
On Friday, May 23, 2014 12:18:55 Marco Martin wrote:
> I think it's a counter-effect of when i removed KConfigWidgets from
> libplasma. there is definitely a problem in the cmake there, qt5::gui
> should be in public in libplasma, right?
That's how I understand Aleix.
--
sebas
http://www.kde.org
I think it's a counter-effect of when i removed KConfigWidgets from libplasma.
there is definitely a problem in the cmake there, qt5::gui should be in public
in libplasma, right?
On Friday 23 May 2014, Sebastian Kügler wrote:
> CC:ing plasma-devel. Any input on this? (I just fixed the build in th
CC:ing plasma-devel. Any input on this? (I just fixed the build in the most
obvious way, perhaps someone knows why Qt5::Gui had been removed from the
implicit public targets in the first place?
On Friday, May 23, 2014 00:54:17 Aleix Pol wrote:
> KF5::Plasma should have Qt5::Gui as public depende
I have just removed components component from the plasma-shell product
and reassigned all the (closed) bugs to plasma-framework.
You may have received some email spam from this, if so I apologise.
David
___
Plasma-devel mailing list
Plasma-devel@kde.org
On Tue, Apr 29, 2014 at 5:15 PM, Marco Martin wrote:
> try it again?
here is correct link
https://bugs.kde.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=framework-plasma&sharer_id=69245&list_id=1007520
--
Bhushan Shah
http://bhush9.github.io
IRC Nick : bshah on Freenode
___
On Tuesday 29 April 2014 13:39:58 Sebastian Kügler wrote:
> On Tuesday, April 29, 2014 13:37:24 Marco Martin wrote:
> > now that plasma-framework is in frameworks, it has its own product in
> > bugzilla, the search is this:
> >
> > https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=framewo
On Tuesday, April 29, 2014 13:37:24 Marco Martin wrote:
> now that plasma-framework is in frameworks, it has its own product in
> bugzilla, the search is this:
>
> https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=framework-plasma&;
> list_id=1007509
The search doesn't exist, you'll nee
On Friday 25 of April 2014 15:43:39 Marco Martin wrote:
> On Friday 25 April 2014 15:24:50 Luigi Toscano wrote:
> > On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> > > Moving plasma-framework to frameworks means that we will loose
> > > flexibility
> > > since we won't be able to break ap
On Saturday, April 26, 2014, David Faure wrote:
>> David is acting on the move as I'm typing that email. Stay tuned! :-)
>
> plasma-framework is now under frameworks/.
>
> kdesrc-build users, remember to do
> rm -rf kdereview/plasma-framework playground/libs/plasma-framework
> to avoid hacking in
On Saturday 26 April 2014 10:56:00 Kevin Ottens wrote:
> Hello,
>
> On Saturday 26 April 2014 02:33:07 Kevin Ottens wrote:
> > On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> > > El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va
>
> escriure:
> > > > since it was don
On 4/26/14, David Edmundson wrote:
> foreach (KConfigSkeletonItem *item, loader.items()) {
> d->operationsMap[item->group()][item->key()] = item->property();
> }
>
> I ran plasmaengineexplorer and the UI for the activities service
> appeared properly.
ok, if it works, good for me
Hello,
On Saturday 26 April 2014 02:33:07 Kevin Ottens wrote:
> On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> > El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va
escriure:
> > > since it was done earlier this week, better announce it formally, so
> > > everybody ca
Hello,
On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va escriure:
> > since it was done earlier this week, better announce it formally, so
> > everybody can actually do the -review part ;)
>
> Had a look and i18n wise
I don't think we can tap into the parser too easily, we're not using
the ConfigLoaderHandler for actually loading a config; we're just
sharing the XML parser.
It seems there's a very simple option that works.
KConfigSkeleton keeps track of groups already.
If we replace the core of Service::setOpe
On Friday 25 April 2014 20:32:32 you wrote:
>
> so, on one hand exposing ConfigLoaderHandler in kconfig doesn't seem too
> clean, on the other hand, not being able to tap in the parsing in subclasses
> may be a limitation as well tough
so, how do we proceed?
personally i'll sleep on it a few day
On Friday 25 April 2014 22:01:42 you wrote:
> >
> > Any idea what it might be for?
>
> ha.
> looking in p1, was used for extender items, so it can be removed, both the
> method and the member
removed it
--
Marco Martin
___
Plasma-devel mailing list
P
On Friday 25 April 2014 21:44:13 David Edmundson wrote:
> In Plasma::Service there's a method called dummyGroup() which will
> always return an empty KConfigGroup in an overly complicated way. It
> seems to be completely unused.
>
> Any idea what it might be for?
ha.
looking in p1, was used for e
In Plasma::Service there's a method called dummyGroup() which will
always return an empty KConfigGroup in an overly complicated way. It
seems to be completely unused.
Any idea what it might be for?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https
Hi Everyone,
Indeed, there was an intention to use some plasma components in Skrooge, but it
never materialized in any official release. Today, this is mostly abandoned
code, to my disappointment, but I never committed myself enough on finishing
this part...
As far as Skrooge is concerned, you
On Friday 25 April 2014 20:10:31 Martin Gräßlin wrote:
> > argh :/, I wasn't aware at all about that :/
> > I would have ported the users of it removing it from libplasma.
> > when was this done? why wasn't notified/things weren't ported to it?
>
> sorry about that, would be me to blame. I did th
>> argh :/, I wasn't aware at all about that :/
>> I would have ported the users of it removing it from libplasma.
>> when was this done? why wasn't notified/things weren't ported to it?
>
> sorry about that, would be me to blame. I did the integration into KConfig. No
> idea how it could happen th
On Friday 25 April 2014 10:39:32 Marco Martin wrote:
> On Friday 25 April 2014 19:28:59 David Edmundson wrote:
> > > parse kconfigskeletons at runtime for what i'm concerned), that's the
> > > call
> > > of the application developer, as any workspace.
> >
> > That KConfigLoader already moved to KC
On Friday 25 April 2014 19:16:43 Kevin Ottens wrote:
> I think these statements show you totally ignore the history behind
> libplasma or how applications can use it... They (at least Amarok, not 100%
> sure for Skrooge) benefit from the component model used in libplasma:
> packages, dataengines,
On Friday 25 April 2014 19:28:59 David Edmundson wrote:
> > parse kconfigskeletons at runtime for what i'm concerned), that's the call
> > of the application developer, as any workspace.
>
> That KConfigLoader already moved to KConfigGui.
>
> (and I agree that class is really really useful)
argh
On Fri, Apr 25, 2014 at 6:56 PM, Marco Martin wrote:
> On Friday 25 April 2014 17:46:23 David Edmundson wrote:
>> > Well... it's been planned this way for three years if not more. Before
>> > that it was in kdelibs.
>> >
>> >> Also, right now there is only one user of this framework
>> >> (plasma-
On Friday 25 April 2014 17:46:23 David Edmundson wrote:
> > Well... it's been planned this way for three years if not more. Before
> > that it was in kdelibs.
> >
> >> Also, right now there is only one user of this framework
> >> (plasma-desktop),
> >
> > That's because the other users weren't po
On Friday 25 April 2014 17:46:23 David Edmundson wrote:
> > Well... it's been planned this way for three years if not more. Before
> > that it was in kdelibs.
> >
> >> Also, right now there is only one user of this framework
> >> (plasma-desktop),
> >
> > That's because the other users weren't po
> Well... it's been planned this way for three years if not more. Before that it
> was in kdelibs.
>
>> Also, right now there is only one user of this framework (plasma-desktop),
>
> That's because the other users weren't ported to KF5 yet. But there's
> definitely more plasma users (amarok comes t
On Friday 25 April 2014 15:14:46 Àlex Fiestas wrote:
> On Friday 25 April 2014 12:34:32 Marco Martin wrote:
> > Hi all,
> > since it was done earlier this week, better announce it formally, so
> > everybody can actually do the -review part ;)
> >
> > the plasma-framework repository has been moved
On Friday 25 April 2014 15:24:50 Luigi Toscano wrote:
> On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> > Moving plasma-framework to frameworks means that we will loose flexibility
> > since we won't be able to break api/abi.
> >
> > So, do we really have to move it there? Imho would be
On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> Moving plasma-framework to frameworks means that we will loose flexibility
> since we won't be able to break api/abi.
>
> So, do we really have to move it there? Imho would be prudent to keep it
> somewhere else where api/abi stability is n
On Friday 25 April 2014 15:14:46 you wrote:
> > * there was the plasma shell: has been removed and moved to
> > plasma-workspace, decreasing dependencies
>
> Moving plasma-framework to frameworks means that we will loose flexibility
> since we won't be able to break api/abi.
that's exactly why i
On Friday 25 April 2014 12:34:32 Marco Martin wrote:
> Hi all,
> since it was done earlier this week, better announce it formally, so
> everybody can actually do the -review part ;)
>
> the plasma-framework repository has been moved in kdereview, headed
> hopefully in frameworks.
> what it contain
On Thursday, September 26, 2013 15:24:46 Sebastian Kügler wrote:
> Hi Antonis,
>
> On Thursday, September 26, 2013 16:10:21 Antonis Tsiapaliokas wrote:
> > I was trying to build plasma-framework but cmake fails.
> > The installation was with a clean install/build dir of everything.
> >
> > If you
Hi Antonis,
On Thursday, September 26, 2013 16:10:21 Antonis Tsiapaliokas wrote:
> I was trying to build plasma-framework but cmake fails.
> The installation was with a clean install/build dir of everything.
>
> If you need more info, please let me know...
>
> P.S. I have attached the cmake erro
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 s
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
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
___
builds now .
On Sat, Sep 14, 2013 at 2:41 PM, Heena Mahour wrote:
> Hi
> I have build kde libs though I got a error regarding kdetoolstarget but it
> did build out too . http://pastebin.com/raw.php?i=PfgBiJft
> Here is my plasma framework error http://pastebin.com/raw.php?i=qthyDrue
>
> Do let
Now I am able to build but on $plasma-shell I am getting this
http://pastebin.com/raw.php?i=ZeK1kquz ...
On Wed, Aug 14, 2013 at 7:21 PM, Heena Mahour wrote:
> This is my runtime set up http://pastebin.com/raw.php?i=hu9BfWmV .Please
> suggest what I am missing out.
> And this is output of $env
This is my runtime set up http://pastebin.com/raw.php?i=hu9BfWmV .Please
suggest what I am missing out.
And this is output of $env http://pastebin.com/raw.php?i=9wRZyPg3
Regards
On Wed, Aug 14, 2013 at 11:49 AM, Heena Mahour wrote:
> I used cmake -DCMAKE_INSTALL_PREFIX=$KF5 ..
>
>
>
> On Tue,
I used cmake -DCMAKE_INSTALL_PREFIX=$KF5 ..
On Tue, Aug 13, 2013 at 7:36 PM, Marco Martin wrote:
> On Tuesday 13 August 2013 16:26:08 Heena Mahour wrote:
> > Hi ,
> > In order to make use of data engine tasks in plasma 2 .I did git pull
> > --rebase in extra-cmake-module and kdelibs and rebui
On Tuesday 13 August 2013 16:26:08 Heena Mahour wrote:
> Hi ,
> In order to make use of data engine tasks in plasma 2 .I did git pull
> --rebase in extra-cmake-module and kdelibs and rebuild it using runtime
> setup .Then I did the same with plasma-framework .But getting cmake error
> on plasma-fra
On Monday, July 29, 2013 11:42:40 Heena Mahour wrote:
> Now, plasma-shell is giving out error
>
> :~/plasma-framework$ plasma-shell
>
> plasma-shell: symbol lookup error:
> /home/heena/kf5/lib/i386-linux-gnu/libKDE4Support.so.5: undefined symbol:
> kde_kiosk_admin
Look into your LD_LIBRARY_PATH
wow ,it just build right now ;)
hugs to plasma people :D
^_^
On Sun, Jul 28, 2013 at 10:54 PM, Sebastian Kügler wrote:
> On Sunday, July 28, 2013 18:03:19 Heena Mahour wrote:
> > > heena@heena-Aspire-5750:~/extra-cmake-modules/build$ cmake
> > > -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=
On Sunday, July 28, 2013 18:03:19 Heena Mahour wrote:
> > heena@heena-Aspire-5750:~/extra-cmake-modules/build$ cmake
> > -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5
> http://pastebin.com/raw.php?i=iZ6TtNpT
The KF5 environmental variable is not set. You can only use the cmake command
l
http://pastebin.com/raw.php?i=iZ6TtNpT
On Sun, Jul 28, 2013 at 5:03 PM, Sebastian Kügler wrote:
> On Sunday, July 28, 2013 12:04:17 Heena Mahour wrote:
> > I tried cmake in build directory
> > but then also
> > heena@heena-Aspire-5750:~/extra-cmake-modules/build$ cmake
> > -DCMAKE_INSTALL_PREF
On Sunday, July 28, 2013 12:04:17 Heena Mahour wrote:
> I tried cmake in build directory
> but then also
> heena@heena-Aspire-5750:~/extra-cmake-modules/build$ cmake
> -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 .. CMake Error at
> /usr/share/cmake-2.8/Modules/CMakePackageConfigHelpers.
I tried cmake in build directory
but then also
heena@heena-Aspire-5750:~/extra-cmake-modules/build$ cmake
-DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at
/usr/share/cmake-2.8/Modules/CMakePackageConfigHelpers.cmake:177 (file):
file RELATIVE_PATH must be passed a full path
On Sunday, July 28, 2013 11:26:30 Heena Mahour wrote:
> Hi Sebastian ,
> I did $git pull --rebase now getting build errors :
> heena@heena-Aspire-5750:~/extra-cmake-modules$ git pull --rebase
> Current branch master is up to date.
> heena@heena-Aspire-5750:~/extra-cmake-modules$ cmake
> -DCMAKE_INS
Hi Sebastian ,
I did $git pull --rebase now getting build errors :
heena@heena-Aspire-5750:~/extra-cmake-modules$ git pull --rebase
Current branch master is up to date.
heena@heena-Aspire-5750:~/extra-cmake-modules$ cmake
-DCMAKE_INSTALL_PREFIX=$KF5 .
CMake Error at
/usr/share/cmake-2.8/Modules/CMa
On Saturday, July 27, 2013 09:33:27 Heena Mahour wrote:
> I rebuild kdelibs after disabling src/declarativeimports/dirmodel still
> same error
You'll also need to update extra-cmake-modules.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
I rebuild kdelibs after disabling src/declarativeimports/dirmodel still
same error
On Sat, Jul 27, 2013 at 7:50 AM, Martin Graesslin wrote:
> On Friday 26 July 2013 22:27:01 Heena Mahour wrote:
> > Hi ,
> > I am getting cmake error when I build plasma-framework
> > http://pastebin.com/raw.php?i=
On Friday 26 July 2013 22:27:01 Heena Mahour wrote:
> Hi ,
> I am getting cmake error when I build plasma-framework
> http://pastebin.com/raw.php?i=aHbnWHbn .I have build framework branch of
> kdelibs .KIndly suggest something .
This should be fixed already, but you need to rebuild kdelibs-framewor
and this one:
heena@heena-Aspire-5750:~/plasma-framework/build$ cmake
-DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
CMake Error at /home/heena/kf5/share/ECM/find-modules/FindKF5.cmake:124
(message):
KF5: requested unknown components KIO;KUnitConversion;KDE4Attic
Call Stack (most recent
Hello,
On Monday 01 July 2013 07:05:03 Kevin Ottens wrote:
> On Sunday 30 June 2013 22:48:50 Ivan Čukić wrote:
> > > > +1 ABI should be the same in both versions (unlike gcc's std::list
> > > > iirc)
> > >
> > > Just wondering, was this email as "OK, I see where you come from", or
> > > was
> > >
On Sunday 30 June 2013 22:48:50 Ivan Čukić wrote:
> > > +1 ABI should be the same in both versions (unlike gcc's std::list iirc)
> >
> > Just wondering, was this email as "OK, I see where you come from", or was
> > it
> I think we should discuss this at Akademy (with Aaron, Martin and Marco as a
>
> > +1 ABI should be the same in both versions (unlike gcc's std::list iirc)
>
> Just wondering, was this email as "OK, I see where you come from", or was it
I think we should discuss this at Akademy (with Aaron, Martin and Marco as a
minimal WG).
I'd separate the discussion in three parts tha
Hello,
On Saturday 29 June 2013 18:51:38 Ivan Čukić wrote:
> > > I don't agree that these /additional/ features are about the api.
> > > is an (IMO) immensely useful, especially with lambdas and
> > > std::bind for actual non exposed parts.
> >
> > Well, yes that's all useful. That's the type of
> > I don't agree that these /additional/ features are about the api.
> > is an (IMO) immensely useful, especially with lambdas and
> > std::bind for actual non exposed parts.
>
> Well, yes that's all useful. That's the type of things I'd like to use
> everywhere too. I badly worded that above t
On Friday 28 June 2013 23:58:21 Ivan Čukić wrote:
> > OK, then we got a misunderstanding somewhere...
> >
> > Using those Q_* macros is perfectly fine (and even encouraged, we already
> > use Q_DECL_OVERRIDE and I'd like to see more Q_NULLPTR for instance). They
> > enable exactly what I was descr
> OK, then we got a misunderstanding somewhere...
>
> Using those Q_* macros is perfectly fine (and even encouraged, we already
> use Q_DECL_OVERRIDE and I'd like to see more Q_NULLPTR for instance). They
> enable exactly what I was describing earlier: works without C++11 support,
> you get extra
On Friday 28 June 2013 23:13:34 Ivan Čukić wrote:
> > such a premise VS2012 has a very partial C++11 support, Android NDK uses
> > gcc 4.6 by default (apparently you can upgrade that to 4.7 but we can't
> > expect third parties to do it by default, means partial support in both
> > cases), BB10 cro
> such a premise VS2012 has a very partial C++11 support, Android NDK uses
> gcc 4.6 by default (apparently you can upgrade that to 4.7 but we can't
> expect third parties to do it by default, means partial support in both
> cases), BB10 cross- compiler doesn't properly support C++11. We're not
T
On Friday 28 June 2013 20:52:59 Aaron J. Seigo wrote:
> On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
> > Just to clarify: It's not a "no-no" to using C++11, it's to make sure
> > we're able to build without them.
>
> We have no interest in trying to maintain a build that does not require
On Fri, Jun 28, 2013 at 2:52 PM, Aaron J. Seigo wrote:
> On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
>> Just to clarify: It's not a "no-no" to using C++11, it's to make sure we're
>> able to build without them.
>
> We have no interest in trying to maintain a build that does not require C
On Friday, June 28, 2013 13:08:49 Kevin Ottens wrote:
> Just to clarify: It's not a "no-no" to using C++11, it's to make sure we're
> able to build without them.
We have no interest in trying to maintain a build that does not require C++11.
There are too many useful features that we can take adva
> > Isn't the point of a dependency (on C++11) to make it required?
>
> Well, we have required and optional dependencies. C++11 is not special in
> that regard, we can make it either required or optional.
So, essentially, the issue is that Plasma keeps both the framework and the
shells in the s
On Friday 28 June 2013 07:33:43 Shaun Reich wrote:
> On Fri, Jun 28, 2013 at 7:08 AM, Kevin Ottens wrote:
> > On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
> >> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> >> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> >>
On Fri, Jun 28, 2013 at 7:08 AM, Kevin Ottens wrote:
> On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
>> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
>> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
>> > Committed on 28/06/2013 at 08:07.
>> > Pushed by ervin into
On Friday 28 June 2013 11:02:25 Ivan Čukić wrote:
> On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> > Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> > Committed on 28/06/2013 at 08:07.
> > Pushed by ervin into branch 'master'.
> >
> > Revert "Enabling C++11 flags for
On Friday 28 June 2013 08:13:32 Kevin Ottens wrote:
> Git commit 597397b41f5450f24ddc784e0faa13133fed6bd5 by Kevin Ottens.
> Committed on 28/06/2013 at 08:07.
> Pushed by ervin into branch 'master'.
>
> Revert "Enabling C++11 flags for clang and gcc"
This request [1] got a green light by Aaron [2
91 matches
Mail list logo
