Re: share-like-connect icons
Has there been progress on this? If more design work for the new SLC icons is still needed, I could lend a hand now. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: KDE Activity Manager Daemon 2
Em Friday 09 March 2012, Marco Martin escreveu: > On Friday 09 March 2012, Ivan Cukic wrote: > > Hi all, > > > > I'm happy to announce the immediate availability of the activity manager > > version 2.0 (aka The Doctor) which is available from The Master (pun > > intended). > > right now on the meego image seems that activity switching works only when > an activity is created, but 2 of them get created. I do not have problems with activity switching anymore here. Only one activity gets created here and I can switch between them normally (encrypted and non-encrypted). The only problem I had was because a sintax error in PasswordDialog.qml because I test I was doing. When there is any error in the password dialog kamd freezes waiting for the password, which never comes since the dialog was never been created. The homescreen simply freezes too, the panel still works but you cannot launch programs. You need to reboot the device to use it again. There is something wrong with activity renaming: it renames the activity but does not save the new name. If you reboot the device the old names re- appear. Right now I am trying to fix another problem: the password dialog only increase in size, never shrinks. For example, if you try to disable encryption a long message appears and the dialog increase to accomodate the message. If you dismiss the dialog and try to switch to another encrypted activity the dialog is too big for the new message. It seems Item's chilldrenRect only increases, never shrinks. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: KDE Activity Manager Daemon 2
On Friday 09 March 2012, Ivan Cukic wrote: > Hi all, > > I'm happy to announce the immediate availability of the activity manager > version 2.0 (aka The Doctor) which is available from The Master (pun > intended). > right now on the meego image seems that activity switching works only when an activity is created, but 2 of them get created. -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Plasma Active SDK Notes
Em Friday 09 March 2012, Aleix Pol escreveu: > > Hi! > I know that right now it might sound weird, but now I've just seen these > conclusions and I feel like I was not at the same place. > > Right now there's no SDK whatsoever, the only way I could get to run some > of my applications on Active was to actually do it on the device. I guess > that applications must be important in active in the future, so a solution > must be provided. > > As I said on the "workout", having a device image is good for having an > overview of what the end result looks like, but I don't really think that > this is going to scale: > - Having two snapshots of the source code can be misleading to the > developer. We can hack around ways to minimize this, but this is all logic > that we'll have to work out. > - It means to run a full-blown system virtualized on a qemu (or something > similar) and compiling stuff on it. It's going to be slow. Not only slow, things like touchscreen-ony features (pinch and zoom), wifi, battery and kwin+opengl do not work in VirtualBox for example, you have to test them in a real device. Sound only works if you use the opensource version of VirtualBox plus the correct plugin or, for the binary-only version of VirtualBox, if you manually enable sdl's dlopen feature (sdl developers consider it broken). Shared folders do not work because VirtualBox is not able to compile its add-ons against the kernel in the image, of course, we could provide a rpm package with the add-ons to fix this problem (as long as that is permitted by VirtualBox's license). I do not own a tablet, I only use VirtualBox and have obs installed in my notebook to build rpm packages. Obs is also slow because for every package you build it firstly uninstalls any package that is not needed to build it and that takes time. There is also the fact that rpmbuild does not continue to build a package from the last error (after the error is fixed), you have to start from the begining. > I understand that the plan is that people keep compiling and testing the > programs against a locally installed KDE installation and they only compile > it against ARM when they want to test it on the device, so why do we need > an emulated system at all? Additionally, this solution overlaps with > MerSDK in many levels. For people like me that do not own a device? :-D > Also, as I said on the workout, I'd propose to look into something like > MADDE or something like they're doing in QtonPi. Interesting, for those using QtCreator MADDE looks nice. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Plasma Active SDK Notes
On Fri, Mar 9, 2012 at 6:25 PM, martin brook wrote: > Aleix Hi, > > Your right that we don't have an app developers SDK story at the moment bit > work is going on in the Mer area, > see http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.html. > I note the next stage is to concentrate on the app development area. > > I did take notes from you during the sprint about your current workflow with > madde and kdevelop and will feed these into the work going on in the Mer SDK > area, The next Mer SDK meeting will be next Friday in #mermeeting and you > are welcome there to make sure we are going in the right direction for your > workflow. > > BR > > vgrade > > > On Fri, Mar 9, 2012 at 5:02 PM, Aleix Pol wrote: >> >> On Friday 09 March 2012 01:27:03 Sebastian Kügler wrote: >> > Hi all, >> > >> > Here are the notes from the breakout session at the sprint about the >> > Plasma >> > SDK and Developer story. >> > >> > >> > Plasma Active SDK >> > = >> > - Three "levels": >> > (0) Simple App / Widget / "fart app" (purely Plasma Quick): >> > Plasmate, >> > (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer >> > Plasma >> > Active SDK >> > - VM image of Mer SDK >> > - additional packages (kdelibs, etc) preinstalled >> > - IDE / editor installed on the host machine, way to mount >> > source >> > code inside VM >> > - possibly IDE integration plugins to make building and >> > installing >> > easier >> > - also possibe to SSH into the VM and build >> > - easy to set up! >> > (2) System / Core development >> > - Mer PDK (not further specified at this point >> > - ask fellow developers at this point ;) >> > >> > OBS Workflow >> > >> > >> > - package it, .spec file (examples on OBS) >> > - write yaml file, pass it through command >> > - coolo has a tool to import Debian packages >> > >> > - upload to OBS: >> > - official repo (for example for Spark): reviewed and vetted apps >> > - contrib repo for third parties: no guarantees, basic checks to >> > uploaders >> > >> > Things we need to do: >> > - set up official and contrib repos >> > - document for app developer how these steps work >> > - ensure apps are actually maintainaned, not just dumped and let >> > bitrot >> > >> > Cheers, >> >> Hi! >> I know that right now it might sound weird, but now I've just seen these >> conclusions and I feel like I was not at the same place. >> >> Right now there's no SDK whatsoever, the only way I could get to run some >> of >> my applications on Active was to actually do it on the device. I guess >> that >> applications must be important in active in the future, so a solution must >> be >> provided. >> >> As I said on the "workout", having a device image is good for having an >> overview of what the end result looks like, but I don't really think that >> this >> is going to scale: >> - Having two snapshots of the source code can be misleading to the >> developer. >> We can hack around ways to minimize this, but this is all logic that we'll >> have to work out. >> - It means to run a full-blown system virtualized on a qemu (or something >> similar) and compiling stuff on it. It's going to be slow. >> >> I understand that the plan is that people keep compiling and testing the >> programs against a locally installed KDE installation and they only >> compile it >> against ARM when they want to test it on the device, so why do we need an >> emulated system at all? Additionally, this solution overlaps with MerSDK >> in >> many levels. >> >> Also, as I said on the workout, I'd propose to look into something like >> MADDE >> or something like they're doing in QtonPi. >> >> Aleix >> >> ___ >> Active mailing list >> Active@kde.org >> https://mail.kde.org/mailman/listinfo/active > Hi! I'll try to be there. At what time? Aleix ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Plasma Active SDK Notes
Aleix Hi, Your right that we don't have an app developers SDK story at the moment bit work is going on in the Mer area, see http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.html. I note the next stage is to concentrate on the app development area. I did take notes from you during the sprint about your current workflow with madde and kdevelop and will feed these into the work going on in the Mer SDK area, The next Mer SDK meeting will be next Friday in #mermeeting and you are welcome there to make sure we are going in the right direction for your workflow. BR vgrade On Fri, Mar 9, 2012 at 5:02 PM, Aleix Pol wrote: > On Friday 09 March 2012 01:27:03 Sebastian Kügler wrote: > > Hi all, > > > > Here are the notes from the breakout session at the sprint about the > Plasma > > SDK and Developer story. > > > > > > Plasma Active SDK > > = > > - Three "levels": > > (0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate, > > (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer > Plasma > > Active SDK > > - VM image of Mer SDK > > - additional packages (kdelibs, etc) preinstalled > > - IDE / editor installed on the host machine, way to mount source > > code inside VM > > - possibly IDE integration plugins to make building and > installing > > easier > > - also possibe to SSH into the VM and build > > - easy to set up! > > (2) System / Core development > > - Mer PDK (not further specified at this point > > - ask fellow developers at this point ;) > > > > OBS Workflow > > > > > > - package it, .spec file (examples on OBS) > > - write yaml file, pass it through command > > - coolo has a tool to import Debian packages > > > > - upload to OBS: > > - official repo (for example for Spark): reviewed and vetted apps > > - contrib repo for third parties: no guarantees, basic checks to > > uploaders > > > > Things we need to do: > > - set up official and contrib repos > > - document for app developer how these steps work > > - ensure apps are actually maintainaned, not just dumped and let > bitrot > > > > Cheers, > > Hi! > I know that right now it might sound weird, but now I've just seen these > conclusions and I feel like I was not at the same place. > > Right now there's no SDK whatsoever, the only way I could get to run some > of > my applications on Active was to actually do it on the device. I guess that > applications must be important in active in the future, so a solution must > be > provided. > > As I said on the "workout", having a device image is good for having an > overview of what the end result looks like, but I don't really think that > this > is going to scale: > - Having two snapshots of the source code can be misleading to the > developer. > We can hack around ways to minimize this, but this is all logic that we'll > have to work out. > - It means to run a full-blown system virtualized on a qemu (or something > similar) and compiling stuff on it. It's going to be slow. > > I understand that the plan is that people keep compiling and testing the > programs against a locally installed KDE installation and they only > compile it > against ARM when they want to test it on the device, so why do we need an > emulated system at all? Additionally, this solution overlaps with MerSDK in > many levels. > > Also, as I said on the workout, I'd propose to look into something like > MADDE > or something like they're doing in QtonPi. > > Aleix > > ___ > Active mailing list > Active@kde.org > https://mail.kde.org/mailman/listinfo/active > ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Plasma Active SDK Notes
On Friday 09 March 2012 01:27:03 Sebastian Kügler wrote: > Hi all, > > Here are the notes from the breakout session at the sprint about the Plasma > SDK and Developer story. > > > Plasma Active SDK > = > - Three "levels": > (0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate, > (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer Plasma > Active SDK > - VM image of Mer SDK > - additional packages (kdelibs, etc) preinstalled > - IDE / editor installed on the host machine, way to mount source > code inside VM > - possibly IDE integration plugins to make building and installing > easier > - also possibe to SSH into the VM and build > - easy to set up! > (2) System / Core development > - Mer PDK (not further specified at this point > - ask fellow developers at this point ;) > > OBS Workflow > > > - package it, .spec file (examples on OBS) > - write yaml file, pass it through command > - coolo has a tool to import Debian packages > > - upload to OBS: > - official repo (for example for Spark): reviewed and vetted apps > - contrib repo for third parties: no guarantees, basic checks to > uploaders > > Things we need to do: > - set up official and contrib repos > - document for app developer how these steps work > - ensure apps are actually maintainaned, not just dumped and let bitrot > > Cheers, Hi! I know that right now it might sound weird, but now I've just seen these conclusions and I feel like I was not at the same place. Right now there's no SDK whatsoever, the only way I could get to run some of my applications on Active was to actually do it on the device. I guess that applications must be important in active in the future, so a solution must be provided. As I said on the "workout", having a device image is good for having an overview of what the end result looks like, but I don't really think that this is going to scale: - Having two snapshots of the source code can be misleading to the developer. We can hack around ways to minimize this, but this is all logic that we'll have to work out. - It means to run a full-blown system virtualized on a qemu (or something similar) and compiling stuff on it. It's going to be slow. I understand that the plan is that people keep compiling and testing the programs against a locally installed KDE installation and they only compile it against ARM when they want to test it on the device, so why do we need an emulated system at all? Additionally, this solution overlaps with MerSDK in many levels. Also, as I said on the workout, I'd propose to look into something like MADDE or something like they're doing in QtonPi. Aleix ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
On March 9, 2012 at 3:45 PM "Lamarque V. Souza" wrote: > Em Friday 09 March 2012, Maurice de la Ferte escreveu: > > On March 9, 2012 at 1:43 PM "Lamarque V. Souza" > wrote: > > > Em Friday 09 March 2012, Maurice de la Ferte escreveu: > > > > Hi all, > > > > > > Hi, > > > > > > > > > > at the moment we have a well tested and improved state of Plasma Active > > > > 2 in our testing project. We like to ship this state into the > > > > Project:KDE:Trunk project this afternoon which is the package feed of > > > > our MeeGo/Mer end-user images. We still have some small bugs but users > > > > in the field will benefit from this update and Mer based images are > > > > getting possible. > > > > > > Does that also mean users who want to update their PA2 > > >installations can > > > > > > point zypper to Project:KDE:Trunk repo and trigger the update? > > > > > > This depends on the installation image, in case a "demo" or "stable release > > image" was taken (e.g. > > http://share.basyskom.com/contour/Deployment/latest-meego-plasma-active-st > > able.html) zypper is pointing to the Project:KDE:Trunk OBS project and will > > get those updates by just "zypper up" in a few hours. > > Good that is what I wanted to know. > > > In case you have a "Testing" image installation zypper is pointing to > > Project:KDE:Trunk:Testing OBS project, which is the gate for updates on > > "Project:KDE:Trunk". This means it does not make sense to add the > > 'Project:KDE:Trunk' repo because the updates are allready available. > > For some more background about the purpose of different images please see: > > http://mail.kde.org/pipermail/active/2011-October/001440.html > > > > I hope this will clearify it a bit. > > Yes, it does. The name "Trunk" in Project:KDE:Trunk is misleading > though. In subversion jargon trunk is the development branch but by the e-mail > above Project:KDE:Trunk is the stable version, Project:KDE:Devel is the > development version (this one makes sense) and Project:KDE:Trunk:Testing is > the intermediate version (the yet to be Project:KDE:Trunk). > > -- Yes this name is misleading but this a adaption of a common MeeGo project setup. Please note, to get the new security features running there is a additional command after updating needed: root@device# echo "modprobe fuse" >> /etc/rc.local This makes sure needed kernel modules get loaded at boot-up. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
Em Friday 09 March 2012, Maurice de la Ferte escreveu: > On March 9, 2012 at 1:43 PM "Lamarque V. Souza" wrote: > > Em Friday 09 March 2012, Maurice de la Ferte escreveu: > > > Hi all, > > > > Hi, > > > > > > > at the moment we have a well tested and improved state of Plasma Active > > > 2 in our testing project. We like to ship this state into the > > > Project:KDE:Trunk project this afternoon which is the package feed of > > > our MeeGo/Mer end-user images. We still have some small bugs but users > > > in the field will benefit from this update and Mer based images are > > > getting possible. > > > > Does that also mean users who want to update their PA2 > >installations can > > > > point zypper to Project:KDE:Trunk repo and trigger the update? > > > This depends on the installation image, in case a "demo" or "stable release > image" was taken (e.g. > http://share.basyskom.com/contour/Deployment/latest-meego-plasma-active-st > able.html) zypper is pointing to the Project:KDE:Trunk OBS project and will > get those updates by just "zypper up" in a few hours. Good that is what I wanted to know. > In case you have a "Testing" image installation zypper is pointing to > Project:KDE:Trunk:Testing OBS project, which is the gate for updates on > "Project:KDE:Trunk". This means it does not make sense to add the > 'Project:KDE:Trunk' repo because the updates are allready available. > For some more background about the purpose of different images please see: > http://mail.kde.org/pipermail/active/2011-October/001440.html > > I hope this will clearify it a bit. Yes, it does. The name "Trunk" in Project:KDE:Trunk is misleading though. In subversion jargon trunk is the development branch but by the e-mail above Project:KDE:Trunk is the stable version, Project:KDE:Devel is the development version (this one makes sense) and Project:KDE:Trunk:Testing is the intermediate version (the yet to be Project:KDE:Trunk). -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
On March 9, 2012 at 1:43 PM "Lamarque V. Souza" wrote: > Em Friday 09 March 2012, Maurice de la Ferte escreveu: > > Hi all, > > Hi, > > > at the moment we have a well tested and improved state of Plasma Active 2 > > in our testing project. We like to ship this state into the > > Project:KDE:Trunk project this afternoon which is the package feed of our > > MeeGo/Mer end-user images. We still have some small bugs but users in the > > field will benefit from this update and Mer based images are getting > > possible. > > Does that also mean users who want to update their PA2 installations >can > point zypper to Project:KDE:Trunk repo and trigger the update? This depends on the installation image, in case a "demo" or "stable release image" was taken (e.g. http://share.basyskom.com/contour/Deployment/latest-meego-plasma-active-stable.html) zypper is pointing to the Project:KDE:Trunk OBS project and will get those updates by just "zypper up" in a few hours. In case you have a "Testing" image installation zypper is pointing to Project:KDE:Trunk:Testing OBS project, which is the gate for updates on "Project:KDE:Trunk". This means it does not make sense to add the 'Project:KDE:Trunk' repo because the updates are allready available. For some more background about the purpose of different images please see: http://mail.kde.org/pipermail/active/2011-October/001440.html I hope this will clearify it a bit. Cheers Maurice ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Mer Platform SDK Meeting and Latest Status
Sebas Hi, Find the latest from the Mer side at http://wiki.merproject.org/wiki/Platform_SDK and also the meeting notes from today at http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.html and http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.html for the full log. Cross posting to Mer General to log the notes below from the Plasma Active Sprint from Wednesday. BR vgrade On Fri, Mar 9, 2012 at 12:27 AM, Sebastian Kügler wrote: > Hi all, > > Here are the notes from the breakout session at the sprint about the Plasma > SDK and Developer story. > > > Plasma Active SDK > = > - Three "levels": >(0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate, >(1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer Plasma > Active SDK >- VM image of Mer SDK >- additional packages (kdelibs, etc) preinstalled >- IDE / editor installed on the host machine, way to mount source > code > inside VM >- possibly IDE integration plugins to make building and installing > easier >- also possibe to SSH into the VM and build >- easy to set up! >(2) System / Core development >- Mer PDK (not further specified at this point >- ask fellow developers at this point ;) > > OBS Workflow > > > - package it, .spec file (examples on OBS) >- write yaml file, pass it through command >- coolo has a tool to import Debian packages > > - upload to OBS: >- official repo (for example for Spark): reviewed and vetted apps >- contrib repo for third parties: no guarantees, basic checks to > uploaders > > Things we need to do: >- set up official and contrib repos >- document for app developer how these steps work >- ensure apps are actually maintainaned, not just dumped and let bitrot > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > ___ > Active mailing list > Active@kde.org > https://mail.kde.org/mailman/listinfo/active > ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
Em Friday 09 March 2012, Maurice de la Ferte escreveu: > Hi all, Hi, > at the moment we have a well tested and improved state of Plasma Active 2 > in our testing project. We like to ship this state into the > Project:KDE:Trunk project this afternoon which is the package feed of our > MeeGo/Mer end-user images. We still have some small bugs but users in the > field will benefit from this update and Mer based images are getting > possible. Does that also mean users who want to update their PA2 installations can point zypper to Project:KDE:Trunk repo and trigger the update? -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Plasma Active SDK Notes
Em Thursday 08 March 2012, Sebastian Kügler escreveu: > Hi all, > > Here are the notes from the breakout session at the sprint about the Plasma > SDK and Developer story. > > > Plasma Active SDK > = > - Three "levels": > (0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate, > (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer > Plasma Active SDK > - VM image of Mer SDK > - additional packages (kdelibs, etc) preinstalled > - IDE / editor installed on the host machine, way to mount source > code inside VM With VirtualBox as long as we can install the "guest add-ons" this part is very simple (VBox menu -> Devices -> Shared folders). To install the "guest add-ons" we need to compile its kernel module against the guest's kernel though. > - possibly IDE integration plugins to make building and installing > easier > - also possibe to SSH into the VM and build The ssh part is easy with VBox, just configure the VM network card as NAT and, in the same dialog, click on "Redirect ports" and redirect any port of the host machine (I use ) to port 22 of the guest IP address in the local network (10.0.2.15 here). This way the guest can access Internet and you can connect to its sshd, if with any other configuration I tried either you cannot connect to the sshd or the guest cannot access the Internet (at least not without manually configuring the guest gateway and DNS addressess). > - easy to set up! > (2) System / Core development > - Mer PDK (not further specified at this point > - ask fellow developers at this point ;) > > OBS Workflow > > > - package it, .spec file (examples on OBS) > - write yaml file, pass it through command > - coolo has a tool to import Debian packages > > - upload to OBS: > - official repo (for example for Spark): reviewed and vetted apps > - contrib repo for third parties: no guarantees, basic checks to > uploaders > > Things we need to do: > - set up official and contrib repos > - document for app developer how these steps work > - ensure apps are actually maintainaned, not just dumped and let bitrot > > Cheers, -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Plasma Active SDK Notes
Hi all, Here are the notes from the breakout session at the sprint about the Plasma SDK and Developer story. Plasma Active SDK = - Three "levels": (0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate, (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer Plasma Active SDK - VM image of Mer SDK - additional packages (kdelibs, etc) preinstalled - IDE / editor installed on the host machine, way to mount source code inside VM - possibly IDE integration plugins to make building and installing easier - also possibe to SSH into the VM and build - easy to set up! (2) System / Core development - Mer PDK (not further specified at this point - ask fellow developers at this point ;) OBS Workflow - package it, .spec file (examples on OBS) - write yaml file, pass it through command - coolo has a tool to import Debian packages - upload to OBS: - official repo (for example for Spark): reviewed and vetted apps - contrib repo for third parties: no guarantees, basic checks to uploaders Things we need to do: - set up official and contrib repos - document for app developer how these steps work - ensure apps are actually maintainaned, not just dumped and let bitrot Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Updating Project:KDE:Trunk project on build.pub.meego.com
Hi all, at the moment we have a well tested and improved state of Plasma Active 2 in our testing project. We like to ship this state into the Project:KDE:Trunk project this afternoon which is the package feed of our MeeGo/Mer end-user images. We still have some small bugs but users in the field will benefit from this update and Mer based images are getting possible. Cheers Maurice ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 291475] Pull-Down on Task Switcher no longer possible
https://bugs.kde.org/show_bug.cgi?id=291475 Thomas Pfeiffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Pfeiffer --- I can confirm that it has been fixed by now. -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
KDE Activity Manager Daemon 2
Hi all, I'm happy to announce the immediate availability of the activity manager version 2.0 (aka The Doctor) which is available from The Master (pun intended). Changes: - The main change is that the internals are completely revamped while the beast looks the same from outside. Most things inside are now job-based, with a strange job declaration syntax which is somewhere between a rock and a crazy place... but still looks more sane than the entangled code that was in it before. Unfortunately, until we start requiring modern C++ compilers, the code will look a bit strange, and will not be as optimised as it would be with C++11* - the second is that kext:Activity is abandoned, it is now replaced by kao:Activity (kao - kde activities ontology) - and, I guess, a lot of fixes also got in as a side-effect :) Consequences: 1 - the new version will eat all your pets 2 - will work better than the previous one after it is done with (1) Further: - Soon, I'll push the moving the files from/to private activities, and the directory reorganization. Cheerio * I've implemented an analogous mechanism using variadic templates, lambdas some other fancy stuff, which has absolutely no overhead both cpu instruction and memory-wise. But it needs the latest gcc to work... -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun -- Pink Floyd ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
