Re: Moving Baloo and Baloo-widgets into KDE SC
Hey, On Friday, January 10, 2014 11:02:22 Mario Fux KDE ML wrote: > Am Donnerstag, 09. Januar 2014, 23.26:01 schrieb Àlex Fiestas: > > If the breakage is minimal (which I know it is, but I will let vHanda > > reply > > to that) I vote to replace it even if we make a bit worse the experience > > using some weird application that nobody has heard of. > > The release schedule for 4.13 is really short (4 month). With the feature > freeze in approx. 1.5 months, see [1]. > > As 4.13 will be one of our last release in the 4 era I think we should be > quite sure that we don't break anything or even more to be 110% sure to > have fallbacks, migration, APIs for Nepomuk apps to access Baloo data etc. > > And even though I know that Vishesh is doing a great and a hell of a job > I'm not too sure if one single person can manage all of this (not just the > implementation but I think it needs a lot of testing as well). > > IIRC it's still not clear for all the current Nepomuk apps if they work > after 4.13. Let's try to list them again. > > - Amarok (got Nepomuk support with 2.7, will it work after 4.13? If it's ported... > - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? > - Dolphin > - Gwenview > - Conquiere > - KPhotoalbum > - Kamoso (seems so be ready in time) > - Kdenlive (out of the most popular KDE apps, with some man power problems > atm, ok, but nonetheless) > - Nepomuk-webminer and Nepomuktvnamer Let me point out the obvious here: We can discuss possible quality problems for a few more weeks, *OR* we use the time to actually test the code on a wider range of systems. This way we wouldn't have to guess so much about possible impact to other apps, and we can judge much better how ready Baloo is. Don't see Baloo as a third party service that someone else has to fix and debug, rather get on the train, test it, report your experience and make it possible to get it solidly working. > - Plasma Active/Plasma mobile with Share-Like-Connect There's no Plasma Active release planned based on 4.x APIs, so this one can just be ignored until there's a clear and concrete roadmap. Likely, the next Plasma Active release will be folded into the Plasma workspaces anyway. Besides that, Plasma Active will be benefitting a lot from Baloo, since it's typically run on smaller devices. The pain here is limited since there are not too many users currently, and the parts of the system interfacing with Nepomuk (and Baloo in the future) are rather well defined. > And another question. Will people who used Nepomuk extensively lose data? I > know that Nepomuk was one of the most hated software, but there were and > are people who like(d) and love(d) it. I think this question has been answered a few times already, even in this thread. > So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a > 100% (very very well tested!) migration plan and testing is a no-go (from > my side, just me). I've the strong feeling that such big changes are for > something like kf5 and a port of the apps to kf5. I'm not strictly against this. Actually, we have some lenience with the long term support workspace out, so we can recommend people to use that, if they're slightly more adventurous, run 4.13, if they are completely mad, help us getting Plasma 2 in shape. That's quite a nice array of options. Communicated in the right way to our downstreams, this helps us to avoid problems. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 115056: rename knotifications StatusNotifierItem dbus interface in kde-workspace
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115056/#review47524 --- Looks good from my side. I'll let Martin have the final ship-it say. Thanks for the patch! - Sebastian Kügler On Jan. 16, 2014, 5:02 p.m., Jonathan Riddell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115056/ > --- > > (Updated Jan. 16, 2014, 5:02 p.m.) > > > Review request for kde-workspace and Martin Klapetek. > > > Repository: kde-workspace > > > Description > --- > > Rename the knotifications StatusNotifier dbus interface. This prevents > installing interface files which overlap with the kdelibs4 equivalents. > Goes with https://git.reviewboard.kde.org/r/115055/ > > > Diffs > - > > plasma/generic/dataengines/statusnotifieritem/CMakeLists.txt 4e3724b > plasma/generic/dataengines/statusnotifieritem/statusnotifieritem_engine.cpp > 04db8e0 > statusnotifierwatcher/CMakeLists.txt d2ffeec > statusnotifierwatcher/statusnotifierwatcher.cpp 647d093 > > Diff: https://git.reviewboard.kde.org/r/115056/diff/ > > > Testing > --- > > > Thanks, > > Jonathan Riddell > >
Re: Splitting kde-workspace and kde-runtime proposal
On Tuesday, January 21, 2014 11:03:57 Bhushan Shah wrote: > On Tue, Jan 21, 2014 at 1:19 AM, Àlex Fiestas wrote: > > In the plasma sprint we have done a session to plan what we are going to > > do > > with kde-workspace/kde-runtime repositories, here is the proposal we came > > with. > > > > We are going to create 2 new repos called plasma-desktop and > > plasma-workspace, we decided to use plasma as a prefix so in the future > > we can have more workspaces and desktops without being in the awkward > > situation of having one wrongly labeled as "KDE" while others are not > > (thinking on for example having Razorqt/lxde as part of KDE in the > > future). Current kde-workspace and kde- runtime will be kept for history > > reasons. > > I want to suggest something different, > > 1) Create two different groups named plasma-workspace and > plasma-desktop like frameworks How is this granularity useful? To me, it sounds like way too much, too hard to move code around within the same domain, for example. We don't want to flood people with hundreds of repositories. The generic workspace vs. specific formfactor split is well in line with how we see people deploying Plasma, you install the framework, the generic workspace, and then a package for a specific formfactor. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems
On Monday, January 20, 2014 14:40:17 Thiago Macieira wrote: > See subject. We're trying to decide whether we should enable journald by > default on Linux distributions that carry it. If we do, it means any > application that is not launched from a terminal would automatically write > to journald instead. > > KDE applications are the largest users of qDebug today. > > If we changed the default, it would mean ~/.xsession-errors would probably > become rather empty. Is that ok for KDE? One thing that may concern me is how to clean the system from debugging messages then. Sometimes applications go rogue on qDebug() (recent example the message from QPainter in Qt5, which has just been fixed), so the journal will end up pretty big, and also in the home directory. I like how it's easy to delete all that spam with just one file. I would not quite like it to end up on my / partition, since that one is usually pretty small, and it can prevent the system from booting when the journal is filled up. I'm not objecting, but the above questions concern my systems. Answers to how this could be done nicely are appreciated. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Moving Baloo forward
On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: > in the best case you'll have two totally different codepaths > that you'll have to manage. This should be "worst case", I think. In the best case, there's xattr support, meaning another code path isn't needed. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 115260: Add default OSD to look&feel package (screenshot included)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115260/#review48193 --- Ship it! Looking good. Some niggles, and it's good to go in. plasma/desktop/qmlpackages/lookandfeel/contents/osd/Osd.qml <https://git.reviewboard.kde.org/r/115260/#comment34086> I think currently, the timeout is 2500, that seems enough for me. plasma/desktop/qmlpackages/lookandfeel/contents/osd/Osd.qml <https://git.reviewboard.kde.org/r/115260/#comment34087> ; at the end in scripts - Sebastian Kügler On Jan. 24, 2014, 11:42 a.m., Martin Klapetek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115260/ > --- > > (Updated Jan. 24, 2014, 11:42 a.m.) > > > Review request for kde-workspace and Plasma. > > > Repository: kde-workspace > > > Description > --- > > Adds the default OSD look&feel file to the default package. > > The OSD features just an icon and (a progress bar OR a text). It uses > standard Plasma components for drawing things, Marco has on his todo list to > turn the progress bar black, will look better when that's done. > > When the OSD is showing progress, no text is shown (can be overriden by the > look&feel package). > > > Diffs > - > > plasma/desktop/qmlpackages/lookandfeel/contents/osd/Osd.qml PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/115260/diff/ > > > Testing > --- > > > File Attachments > > > screenshot with default theme > > https://git.reviewboard.kde.org/media/uploaded/files/2014/01/23/a864bc46-27b8-411b-9362-03c1fb6a3bbc__osd.png > > > Thanks, > > Martin Klapetek > >
Re: Using kqmlgraphplugin in Plasma Next
On Friday, January 31, 2014 14:56:24 Mark Gaiser wrote: > 2. The Qt4 based graph-plugin from sebas with quite a bit of features. Not me, but Sebastian Gottfried. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Using kqmlgraphplugin in Plasma Next
Hi, On Friday, January 31, 2014 21:34:47 Mark Gaiser wrote: > > > > Canvas based: I have no experience with that but I guess performance is > > should be better than with QPaintedItem, since it directly renders to a > > GPU framebuffer and painting can be done in an separate thread. > > As far as i know both (canvas and qpainter) are software rendered. > However, canvas apparently has some option to set the render target > "Canvas.FramebufferObject" (the default btw) which makes the GPU do > something the CPU would otherwise do. But it's by far GPU rendered > otherwise you would be able to do fluid animations with it. Which you > can't. For a simple graph, we don't need animations. Sure, we can come up with a huge number of usecases, all from a "this would look cool, and maybe someone would even use it, but perhaps not"-point of view, but that has little bearing on what we actually want and need to do. The point really is that the Plasma 1 implementation also uses software rendering, and does a few tricks to limit the repainted area. We can achieve a similar performance with both, QQuickPaintedItem and canvas, it seems. So to fill our needs, we're almost good. (Modulo Bhushan finishing the code, but that means not overloading him with unreasonable expectations.) >From experiments, Bhushan's code seemed very well able to cover the usecases we have in Plasma (namely painting a simple, relatively small graph). > My guess - and i haven't looked in the canvas code - is that canvas is > using QPainter internally to render everything smooth and sharp and > then moves the resulting image as a texture to the GPU. Or something > along those lines. That's what QQuickPaintedItem does, no? > For a real hardware accelerates canvas you should open up Chrome and > go to this link: http://fhtr.org/gravityring/sprites.html I doubt that > would be possible with the same performance in the QML canvas ;) This is entirely unrelated. I could post a link to Halflife 2 and say that it's probably not possible with a canvas. It totally ignores the point, though: the usecase is completely different (is there a usecase for your example, anyway?), and a canvas seems to be the wrong tool for the job in this case as well. Does it have anything to do with graphs? I don't think so. I think it would be very cool if this would be a shard component in the end, so both, KTouch and Plasma can utilize it, and improve it further. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Plasma Next Release Plans
Hi all, The Plasma team has settled on a release schedule for the first stable released based on Qt5 and KF5. You can find the schedule here: http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule For those too lazy to click: We'll release .0 on 17th June, two alphas, a beta and an RC before. Feature freeze is looming in March already. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Moving Baloo forward
On Thursday, February 20, 2014 08:58:48 GEO wrote: > Maybe a strange idea, but it would resolve the privacy problem: Baloo could > optionally encrypt all the attributes using a user defined password, meaning > baloo stores encrypted strings as file attributes. I have no experience > with file attributes, but I suppose the performance of search queries would > suck, because of the decryption. Use an encrypted filesystem. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 116077: KRunner patch so it detects Iceweasel bookmarks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116077/#review50930 --- Ship it! Patch looks sensible. Do you have a Git account at KDE? - Sebastian Kügler On Feb. 26, 2014, 10:48 a.m., Maximiliano Curia wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116077/ > --- > > (Updated Feb. 26, 2014, 10:48 a.m.) > > > Review request for kde-workspace. > > > Bugs: 322399 > http://bugs.kde.org/show_bug.cgi?id=322399 > > > Repository: kde-workspace > > > Description > --- > > Hi, > > This patch was submitted to the bug tracker some time ago, and even longer in > the debian bug tracker, here is the original report: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646612 > > Thanks, > > > Diffs > - > > plasma/generic/runners/bookmarks/browserfactory.cpp > 7f29f5efd8817983db67c496b850d1caba4d8046 > > Diff: https://git.reviewboard.kde.org/r/116077/diff/ > > > Testing > --- > > > Thanks, > > Maximiliano Curia > >
Re: Review Request 116117: Place new panels to bottom by default
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116117/#review51913 --- Ship it! Ship It! - Sebastian Kügler On March 4, 2014, 5:07 p.m., Jan Grulich wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116117/ > --- > > (Updated March 4, 2014, 5:07 p.m.) > > > Review request for kde-workspace, Plasma, Aaron J. Seigo, Marco Martin, and > Sebastian Kügler. > > > Repository: kde-workspace > > > Description > --- > > When adding a new empty panel, it's placed at top by default, but it should > be placed to bottom, when it's possible. Also when adding a new "Default > Panel" to second screen without any panel and you already have one on your > first screen, then it's also placed to top instead of bottom. This is just a > simple fix, which changes order of checking free edges for empty panels and > adds a check for screenId when executing a script for default panel layout. > I'm not much sure with the javascript part, but it works. > > > Diffs > - > > > plasma/desktop/shell/data/layouts/org.kde.plasma-desktop.defaultPanel/contents/layout.js > 356e689 > > Diff: https://git.reviewboard.kde.org/r/116117/diff/ > > > Testing > --- > > > Thanks, > > Jan Grulich > >
Re: Review Request 109792: Update 'dim display' algorithm.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109792/#review53070 --- What's the status here? Please mark as shipped, discarded or update otherwise. Thanks... - Sebastian Kügler On April 13, 2013, noon, Danny Baumann wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/109792/ > --- > > (Updated April 13, 2013, noon) > > > Review request for kde-workspace, Solid, Dario Freddi, and Oliver Henshaw. > > > Bugs: 304696 > http://bugs.kde.org/show_bug.cgi?id=304696 > > > Repository: kde-workspace > > > Description > --- > > This change does two things: > - No longer dim display before the dim time set by the user elapses. > This fixes bug #304696 > - No longer assume that 0% display brightness produces a visible result. > This doesn't work with the intel-backlight backlight interface (as it > turns off the backlight at 0% brightness). According to the kernel > developers (see [1] and [2]), this isn't a safe assumption to make for > other backlight interfaces either. Instead of always dimming to 0%, > make the amount of dimming configurable. > > [1] > http://lists.freedesktop.org/archives/intel-gfx/2013-March/026152.html > [2] > http://lists.freedesktop.org/archives/intel-gfx/2013-March/026140.html > > > Diffs > - > > powerdevil/daemon/actions/bundled/dimdisplay.cpp > 11554e3ba5d2f67d4d1de9d61c744c6c40a32d27 > > Diff: https://git.reviewboard.kde.org/r/109792/diff/ > > > Testing > --- > > > Thanks, > > Danny Baumann > >
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117174/#review54702
---
plasma/packagestructure.cpp
<https://git.reviewboard.kde.org/r/117174/#comment38226>
{ go on the next line (here and elsewhere)
plasma/packagestructure.cpp
<https://git.reviewboard.kde.org/r/117174/#comment38225>
This is going to be funny if you have multiple packages in the path you're
specifying here, it will rely on directory listing ordering then -- perhaps not
what you want. If it's random anyway, why parse all, and not just pick the
first one?
- Sebastian Kügler
On March 30, 2014, 1:14 p.m., Andrei Amuraritei wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117174/
> ---
>
> (Updated March 30, 2014, 1:14 p.m.)
>
>
> Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure,
> and Ian Monroe.
>
>
> Bugs: 149479
> http://bugs.kde.org/show_bug.cgi?id=149479
>
>
> Repository: kdelibs
>
>
> Description
> ---
>
> Even though the bug appears RESOLVED it is not.
>
> Minor hack to packagestructure.cpp to search for the metadata.desktop file
> recursively. This helps with installing desktop themes and removing them.
> I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing
> themes ignore SoftSand for example, it's metadata.desktop is not properly
> formatted. There are others too which are not formatted which I guess could
> be fixed by setting a new format standard, maybe even a check package script
> to check new uploads on kde-look.org.
>
>
> Diffs
> -
>
> plasma/packagestructure.cpp 71148e1
>
> Diff: https://git.reviewboard.kde.org/r/117174/diff/
>
>
> Testing
> ---
>
> Compiled, run systemsettings, go to Desktop Themes, install / remove away.
> Some themes are broken so they won't work (not install).
>
>
> Thanks,
>
> Andrei Amuraritei
>
>
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
> On March 31, 2014, 4:04 p.m., Sebastian Kügler wrote:
> > plasma/packagestructure.cpp, line 653
> > <https://git.reviewboard.kde.org/r/117174/diff/2/?file=258228#file258228line653>
> >
> > { go on the next line (here and elsewhere)
>
> Andrei Amuraritei wrote:
> Sorry don't get what you mean here?
Yeah, I meant on the same line, so
while (...) {
Same for if (...) {
Sorry for causing confusion.
> On March 31, 2014, 4:04 p.m., Sebastian Kügler wrote:
> > plasma/packagestructure.cpp, line 659
> > <https://git.reviewboard.kde.org/r/117174/diff/2/?file=258228#file258228line659>
> >
> > This is going to be funny if you have multiple packages in the path
> > you're specifying here, it will rely on directory listing ordering then --
> > perhaps not what you want. If it's random anyway, why parse all, and not
> > just pick the first one?
>
> Andrei Amuraritei wrote:
> Hi there, so this // Question: Would it be better to search just the
> first level dirs for metadata.desktop file? would be yes then ?
> Or do you mean just grab the first "Directory" found and search there ?
I've done something similar in Plasma Next, and there it tries to find a
metadata.desktop file in the current directory, if that fails, it searches the
subdirectories, but not recursively. In this case, we want to be a bit
flexible, but not go overboard scanning whole file system structures just
because a wrong path has been issued.
- Sebastian
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117174/#review54702
---
On March 30, 2014, 1:14 p.m., Andrei Amuraritei wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117174/
> ---
>
> (Updated March 30, 2014, 1:14 p.m.)
>
>
> Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure,
> and Ian Monroe.
>
>
> Bugs: 149479
> http://bugs.kde.org/show_bug.cgi?id=149479
>
>
> Repository: kdelibs
>
>
> Description
> ---
>
> Even though the bug appears RESOLVED it is not.
>
> Minor hack to packagestructure.cpp to search for the metadata.desktop file
> recursively. This helps with installing desktop themes and removing them.
> I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing
> themes ignore SoftSand for example, it's metadata.desktop is not properly
> formatted. There are others too which are not formatted which I guess could
> be fixed by setting a new format standard, maybe even a check package script
> to check new uploads on kde-look.org.
>
>
> Diffs
> -
>
> plasma/packagestructure.cpp 71148e1
>
> Diff: https://git.reviewboard.kde.org/r/117174/diff/
>
>
> Testing
> ---
>
> Compiled, run systemsettings, go to Desktop Themes, install / remove away.
> Some themes are broken so they won't work (not install).
>
>
> Thanks,
>
> Andrei Amuraritei
>
>
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/#review54754 --- I'm OK with this last version, except for one whitespace issue, " " before filename, please. Also, you can update the patch shown in Reviewboard, that makes it way easier to read. Don't just upload a file, but "Update diff" from the top menu instead. Someone else should have a look over it and ship it, I'll be unavailable in the next days. - Sebastian Kügler On April 1, 2014, 12:18 a.m., Andrei Amuraritei wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117174/ > --- > > (Updated April 1, 2014, 12:18 a.m.) > > > Review request for kdelibs, Albert Astals Cid, Aaron J. Seigo, David Faure, > and Ian Monroe. > > > Bugs: 149479 > http://bugs.kde.org/show_bug.cgi?id=149479 > > > Repository: kdelibs > > > Description > --- > > Even though the bug appears RESOLVED it is not. > > Minor hack to packagestructure.cpp to search for the metadata.desktop file > recursively. This helps with installing desktop themes and removing them. > I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing > themes ignore SoftSand for example, it's metadata.desktop is not properly > formatted. There are others too which are not formatted which I guess could > be fixed by setting a new format standard, maybe even a check package script > to check new uploads on kde-look.org. > > > Diffs > - > > plasma/packagestructure.cpp 71148e1 > > Diff: https://git.reviewboard.kde.org/r/117174/diff/ > > > Testing > --- > > Compiled, run systemsettings, go to Desktop Themes, install / remove away. > Some themes are broken so they won't work (not install). > > > File Attachments > > > Limit the extra search to first subdirectory.patch > > https://git.reviewboard.kde.org/media/uploaded/files/2014/04/01/c9b4a3ee-bd3b-498a-b18c-a4eb13b349d3__0002-Limit-the-search-to-include-the-first-directory-only.patch > > > Thanks, > > Andrei Amuraritei > >
Re: Review Request 117174: Fix installing and removing desktop plasma theme packages.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117174/#review56363 --- Ship it! Looks good to me. - Sebastian Kügler On April 23, 2014, 11:04 p.m., Andrei Amuraritei wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117174/ > --- > > (Updated April 23, 2014, 11:04 p.m.) > > > Review request for kdelibs, Aaron J. Seigo, David Faure, and Ian Monroe. > > > Bugs: 149479 > http://bugs.kde.org/show_bug.cgi?id=149479 > > > Repository: kdelibs > > > Description > --- > > Even though the bug appears RESOLVED it is not. > > Minor hack to packagestructure.cpp to search for the metadata.desktop file > recursively. This helps with installing desktop themes and removing them. > I have tested this on kdelibs 4.13 compiled with kdesrc-build. When testing > themes ignore SoftSand for example, it's metadata.desktop is not properly > formatted. There are others too which are not formatted which I guess could > be fixed by setting a new format standard, maybe even a check package script > to check new uploads on kde-look.org. > > > EDIT: It seems I was wrong regarding the specified bug , where it's stated > that the fix was for the themes to be removed from khotnewstuff and it is > correct, so the bug is fixed in that regard. But the theme is not removed > from the system or the list in the kcm desktoptheme module, when removing it > with ghns, it only is not listed as installed. This fixes the "remove", so > the theme is correctly removed completely from > share/apps/desktoptheme/$theme_name and ghns. The fix consists of making > libplasma/packagestructure look in another subfolder for the metadata.desktop > file if the file is not found in the specified current path. > > > Diffs > - > > plasma/packagestructure.cpp 71148e1 > > Diff: https://git.reviewboard.kde.org/r/117174/diff/ > > > Testing > --- > > Compiled, run systemsettings, go to Desktop Themes, install / remove away. > Some themes are broken so they won't work (not install). > > > Thanks, > > Andrei Amuraritei > >
Re: Review Request 117044: Avoid unnecessary automounting in KDiskFreeSpaceInfo::freeSpaceInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117044/#review57500 --- Note that this change won't make it automatically into Plasma Next, it needs forward-porting. - Sebastian Kügler On May 6, 2014, 8:01 p.m., Tomáš Trnka wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117044/ > --- > > (Updated May 6, 2014, 8:01 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > Avoid unnecessary automounting in KDiskFreeSpaceInfo::freeSpaceInfo > > Previously, all unmounted autofs mountpoints were always mounted > by krunner/plasma-desktop on startup, defeating the purpose of > automounting. Let's ignore the unmounted filesystems instead when > gathering free space stats, just like the "df" utility does. > > Everything still gets mounted properly on first real access. > > The change itself is pretty trivial and I would regard it as a bugfix > (and thus eligible for 4.13), but I'm posting it for review to see > what you kdelibs people think. > > > Diffs > - > > kio/kfile/kdiskfreespaceinfo.cpp f11eb0998f0e718e9b366f8c26da30586bfa44ef > > Diff: https://git.reviewboard.kde.org/r/117044/diff/ > > > Testing > --- > > I'm using this patch on kdelibs since 4.11 and I have noted no problems > in connection with ~4 automounted filesystems. > > > Thanks, > > Tomáš Trnka > >
Re: KDE Frameworks Release Cycle
On Monday, May 05, 2014 11:11:53 Martin Klapetek wrote: > However this highly depends on the distro policies - if some of the big > distros say "we will not update KF5 every month because our policies", then > the 6 months buffer is just moved elsewhere, at the distro level because > they will update only with the new release. Worse, they'll stack up: Wait for new kdelibs first (could take up to 7 months, including freezes, and only then the distro freeze period (imagine the target kdelibs release is just past the distro freeze deadline). You'll easily end up with "this bug will be fixed in one year". -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Compatibility problems with latest GTK+ applications
On Thursday, May 08, 2014 14:39:49 Matthias Klumpp wrote: > However, to support the cross-desktop efforts, the GNOME people should > maybe make a few compromises (e.g. make GTK+ behave differently on > other DEs), especially since GTK+ is not just for GNOME but also used > by other projects. This is actually at the root of all these problems. The GTK developers have at some point decided to couple the toolkit with the GNOME desktop, so GTK is -- in their view -- the toolkit for GNOME. It seems, the developers lost interest in keeping their cross-platform and cross-desktop promise. This is visible in other areas as well, such as theming: Theming APIs have been unstable and changed will-nilly for some time now, and the revolt of theme creators has calmed down by now (I suppose they all just walked away). I suppose this CSD episode will just speed up this exodus. We might be looking at a completely different GTK here than we did a few years ago, and that's pretty bad news for interoperability on the freedesktop. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 117957: kcm_fonts: correctly restore default configuration values
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117957/#review58136 --- This will likely need a backport to Plasma 5. The code there has moved to the plasma-desktop repo, under kcms/fonts. - Sebastian Kügler On May 18, 2014, 12:38 a.m., Andrea Iacovitti wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117957/ > --- > > (Updated May 18, 2014, 12:38 a.m.) > > > Review request for kde-workspace. > > > Bugs: 324728 > http://bugs.kde.org/show_bug.cgi?id=324728 > > > Repository: kde-workspace > > > Description > --- > > When restoring default configuration: > - Disable "Exclude range checkbox" > - Enable/Disable "Configure..." button accordingly to antialias setting > > > Diffs > - > > kcontrol/fonts/fonts.cpp cf21cb1 > > Diff: https://git.reviewboard.kde.org/r/117957/diff/ > > > Testing > --- > > Tested it compiles and works as expected > > > Thanks, > > Andrea Iacovitti > >
Re: Moving plasma-nm to extragear
On Friday, May 30, 2014 10:31:37 Lamarque Souza wrote: > I agree that Plasma NM should go to kde/workspace. In the past the only > thing that prevented that was the fact that we needed to change > translatable strings from time to time, which obviously does not comply > with the string freeze. Now that kde/workspace is released more often that > should not be a problem anymore. We just wait until the next release cycle > to change strings. Note that we have not talked about a release schedule for plasma so far, that would only make sense once the discussions around the frameworks scheduling have concluded. Otherwise, I agree, plasma-nm is essential and should be part of kde- workspace, and also release together with it (at least, intermediate releases might be possible and make sense, but that would need some further discussion). Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 118763: Remove find_package(XCB) call as it is handled already by the top-level cmake file
On Sunday, June 15, 2014 12:47:57 Bernd Steinhauser wrote: > No idea if kde-workspace is still the right group, if not, please change. You can use "plasma" as group. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 118366: Porting keyboard module to Framework5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118366/#review60787 --- Can you please try to generate a proper diff? The one you uploaded contains intermediate changes, and makes it really hard to read. We're just interested in the difference between current version and your result. - Sebastian Kügler On June 20, 2014, 9:24 p.m., shivam makkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118366/ > --- > > (Updated June 20, 2014, 9:24 p.m.) > > > Review request for kde-workspace, KDE Frameworks and Andriy Rysin. > > > Repository: plasma-desktop > > > Description > --- > > Removed deprecated statements and ported keyboard module to framework 5. > > > Diffs > - > > kcms/keyboard/bindings.h c576455 > kcms/keyboard/bindings.cpp 21541e0 > kcms/keyboard/bindings.cpp 21541e0 > kcms/keyboard/bindings.cpp 325dd3c > kcms/keyboard/flags.cpp b768586 > kcms/keyboard/flags.cpp b768586 > kcms/keyboard/flags.cpp 6d25443 > kcms/keyboard/flags.cpp 3fb98e5 > kcms/keyboard/iso_codes.h 6a33739 > kcms/keyboard/iso_codes.cpp 3e3b210 > kcms/keyboard/kcm_keyboard.cpp 42b7fe4 > kcms/keyboard/kcm_keyboard.ui 0062d1c > kcms/keyboard/kcm_keyboard.ui 0062d1c > kcms/keyboard/kcm_keyboard_widget.h 657ddda > kcms/keyboard/kcm_keyboard_widget.cpp 21685eb > kcms/keyboard/kcm_keyboard_widget.cpp 21685eb > kcms/keyboard/kcm_keyboard_widget.cpp 2840e26 > kcms/keyboard/kcm_keyboard_widget.cpp 9b0f584 > kcms/keyboard/kcmmisc.h 411bdd2 > kcms/keyboard/kcmmisc.h 411bdd2 > kcms/keyboard/kcmmisc.h 1183fb1 > kcms/keyboard/kcmmisc.cpp 6f787ea > kcms/keyboard/kcmmisc.cpp 6f787ea > kcms/keyboard/kcmmisc.cpp d14ac2e > kcms/keyboard/kcmmisc.cpp 3327ce5 > kcms/keyboard/kcmmiscwidget.ui 37fbaf4 > kcms/keyboard/kcmmiscwidget.ui 37fbaf4 > kcms/keyboard/keyboard_config.h b86418d > kcms/keyboard/keyboard_config.cpp f3ff97c > kcms/keyboard/keyboard_config.cpp f3ff97c > kcms/keyboard/keyboard_config.cpp 49f059c > kcms/keyboard/keyboard_config.cpp a227a34 > kcms/keyboard/keyboard_daemon.h 4edb968 > kcms/keyboard/keyboard_daemon.cpp 25673b0 > kcms/keyboard/keyboard_daemon.cpp 25673b0 > kcms/keyboard/keyboard_daemon.cpp dcda1ec > kcms/keyboard/keyboard_hardware.cpp dca49b6 > kcms/keyboard/keyboard_hardware.cpp dca49b6 > kcms/keyboard/keyboard_hardware.cpp 9a61159 > kcms/keyboard/layout_memory.h df8568c > kcms/keyboard/layout_memory.cpp 9e72361 > kcms/keyboard/layout_memory.cpp 9e72361 > kcms/keyboard/layout_memory.cpp d78e677 > kcms/keyboard/layout_memory_persister.h 8c4b3c5 > kcms/keyboard/layout_memory_persister.cpp 8a6118a > kcms/keyboard/layout_memory_persister.cpp 8a6118a > kcms/keyboard/layout_memory_persister.cpp 1dba024 > kcms/keyboard/layout_widget.cpp e67b2d7 > kcms/keyboard/layouts_menu.h db2f3ff > kcms/keyboard/layouts_menu.cpp fd436c4 > kcms/keyboard/layouts_menu.cpp fd436c4 > kcms/keyboard/layouts_menu.cpp e357c6a > kcms/keyboard/layouts_menu.cpp 7d4c4d6 > kcms/keyboard/x11_helper.h 719b13f > kcms/keyboard/x11_helper.h 385ae28 > kcms/keyboard/x11_helper.cpp 0e2806e > kcms/keyboard/x11_helper.cpp cbb2cfc > kcms/keyboard/xinput_helper.h 343d7ed > kcms/keyboard/xinput_helper.h 343d7ed > kcms/keyboard/xinput_helper.cpp b311579 > kcms/keyboard/xinput_helper.cpp b311579 > kcms/keyboard/xinput_helper.cpp b245e91 > kcms/keyboard/xinput_helper.cpp 980338e > kcms/keyboard/xinput_helper.cpp 1c9604b > kcms/keyboard/xinput_helper.cpp 2b374ae > kcms/keyboard/xkb_helper.cpp 967399e > kcms/keyboard/xkb_rules.h 2be8562 > kcms/keyboard/xkb_rules.cpp f09e675 > > Diff: https://git.reviewboard.kde.org/r/118366/diff/ > > > Testing > --- > > > Thanks, > > shivam makkar > >
Re: Review Request 118898: KGamma: Apply user setting at login/startup
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118898/#review60795
---
I think there's a couple of problems with this approach:
- This slows down startup for everybody, not just those who changed the
setting. I'm not super-familiar with this, but isn't kcminit for this use-case?
- Changing startup procedure this late in the game (Plasma 4.x has been on LTS
for almost a year, feature frozen for much longer)
- This particular KCM is dead in Plasma 5 (not really a reason to not "fix it"
in 4.x, but the feature will be lost again
Again, not super-privvy of the whole picture, but isn't color correction the
correct solution here?
- Sebastian Kügler
On June 23, 2014, 1:06 p.m., Wolfgang Bauer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118898/
> ---
>
> (Updated June 23, 2014, 1:06 p.m.)
>
>
> Review request for kde-workspace, Plasma and Marcel Wiesweg.
>
>
> Bugs: 218668
> http://bugs.kde.org/show_bug.cgi?id=218668
>
>
> Repository: kgamma
>
>
> Description
> ---
>
> KGamma's saved user settings are not applied on startup/login. The user has
> to enter the KCM to apply them.
> This makes it rather useless, as not even saving the settings system-wide
> really works any more. (this requires an xorg.conf which normally doesn't
> exist nowadays)
>
> This patch factors out the function init_kgamma() into its own source file
> (init_kgamma.cpp), adds a small executable (applykgammasettings) that just
> applies those settings by calling that function, and installs
> applykgammasettings.desktop to ${AUTOSTART_INSTALL_DIR} that runs
> applykgammasettings on login.
>
> PS: As there seems to be no kgamma group and this is desktop-related, I
> decided to add the kde-workspace and plasma groups for review. I hope that's
> ok... ;)
>
>
> Diffs
> -
>
> kcmkgamma/CMakeLists.txt 3980023
> kcmkgamma/applykgammasettings.cpp PRE-CREATION
> kcmkgamma/applykgammasettings.desktop PRE-CREATION
> kcmkgamma/init_kgamma.cpp PRE-CREATION
> kcmkgamma/kgamma.cpp 890ba99
>
> Diff: https://git.reviewboard.kde.org/r/118898/diff/
>
>
> Testing
> ---
>
> Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value
> gets set correctly.
>
> If there's no kgammarc file (or it contains no actual gamma settings), the
> Gamma value is not changed. It stays at what is configured for X (or its
> default).
>
>
> Thanks,
>
> Wolfgang Bauer
>
>
Re: Review Request 118898: KGamma: Apply user setting at login/startup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118898/#review60887 --- Ship it! Cool, this looks much less intrusive. - Sebastian Kügler On June 24, 2014, 8:04 a.m., Wolfgang Bauer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118898/ > --- > > (Updated June 24, 2014, 8:04 a.m.) > > > Review request for kde-workspace, KDE Graphics, Plasma, and Marcel Wiesweg. > > > Bugs: 218668 > http://bugs.kde.org/show_bug.cgi?id=218668 > > > Repository: kgamma > > > Description > --- > > KGamma's saved user settings are not applied on startup/login. The user has > to enter the KCM to apply them. > This makes it rather useless, as not even saving the settings system-wide > really works any more. (this requires an xorg.conf which normally doesn't > exist nowadays) > > This patch uses kcminit to apply these settings again on login. Apparently > this has been forgotten when moving/porting kgamma to KDE4. > > PS: As there seems to be no kgamma group and this is desktop-related, I > decided to add the kde-workspace and plasma groups for review. I hope that's > ok... ;) > > > Diffs > - > > kcmkgamma/kgamma.cpp 890ba99 > kcmkgamma/kgamma.desktop 3d87513 > > Diff: https://git.reviewboard.kde.org/r/118898/diff/ > > > Testing > --- > > Set a gamma value in the KGamma KCM, logout/login (or reboot), Gamma value > gets set correctly. > > If there's no kgammarc file (or it contains no actual gamma settings), the > Gamma value is not changed. It stays at what is configured for X (or its > default). > > > Thanks, > > Wolfgang Bauer > >
Re: Review Request 118180: slideshow BUG patch fix
> On July 21, 2014, 12:39 p.m., Martin Gräßlin wrote: > > > > TOM Harrison wrote: > what kind of issue? tab and space different ? Yes, don't use tabs at all for code indentation, use 4 spaces. It should look consistent with the surrounding code after that. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118180/#review62779 --- On June 5, 2014, 10:32 a.m., TOM Harrison wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118180/ > --- > > (Updated June 5, 2014, 10:32 a.m.) > > > Review request for kde-workspace and Plasma. > > > Bugs: 327580 > http://bugs.kde.org/show_bug.cgi?id=327580 > > > Repository: kde-workspace > > > Description > --- > > bug patch for slideshow dir list missing > > > Diffs > - > > libs/plasmagenericshell/backgrounddialog.cpp 645de3f > > Diff: https://git.reviewboard.kde.org/r/118180/diff/ > > > Testing > --- > > > Thanks, > > TOM Harrison > >
Re: Killing kdelibs master branch
On Monday, August 11, 2014 00:23:15 Albert Astals Cid wrote: > Hi there, I'm sending this e-mail to propose removing the master branch of > kdelibs. > > We kind of already tried that when we froze it, but i am proposing to > actually delete it (and enforce with hooks it doesn't come back) from git. > > Why I want to kill it now? > > Next release is not going to be "KDE SC 4.15" but simply "KDE Applications > 2014.12". > > It does not make sense to release kdelibs 4.15 as part of "KDE > Applications 2014.12", since it kind of defeats the purpose of the name. > > So we should not have a kdelibs 4.15 release, we should just be killing > master and just doing some further releases of 4.14.x as bugfix, this way > we avoid people using a branch of kdelibs that will never be released > again. > > In the past we argued about the need to have new kdelibs versions since > some applications use KDE_VERSION_NUMBER as their version number and we > didn't want to break those apps. > > Well, applications using KDE_VERSION_NUMBER as their > version number "are doing it wrong", as it will stop working once we move > to KF5, since there's no such concept as "KDE VERSION" there, so we may as > well fix them now. > > Any objection? No objection, since I don't commit to the kdelibs repo that much, but a "but". Not having a master branch would be confusing to me. It would be much more logical (and making kdelibs less special) to make the master branch what is currently KDE/4.14 and branch releases off of that, so KDE/4.15 would be branched off of master again. The policy of no features would still be in place, just that master always has all the latest patches, and releases come from that. Reason, if I'm building kdelibs from git, my "autopilot" way would be cloning (which gives you the master branch, dunno what'd happen if there's no remote master in the origin), see master, and assume that I now have "latest" and that it is what I should do patches against. Just a thought, ignore at will. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [kde-community] Closing the kde-core-devel mailing list
On Tuesday, August 05, 2014 21:28:14 Kevin Krammer wrote: > On Tuesday, 2014-08-05, 20:29:05, Albert Astals Cid wrote: > > El Dilluns, 4 d'agost de 2014, a les 20:36:44, Vishesh Handa va escriure: > > > > > > Random Idea: How about we close the k-c-d mailing list? It's main > > > purpose > > > used to be to discuss kdelibs changes, but now since we have > > > kde-frameworks, the mailing list seems less useful. We already have > > > kde-devel for other generic kde stuff. > > > > kde-core-devel main purpose may had been discuss kdelibs changes, but it > > has trascended that purspose a while ago. > > I agree with Albert. > > k-c-d is the list to for things that happen in development, like kde-review > requests, inter-module coordination, etc. > It is more like a "kde-community-technical" list. > > kde-devel is more a list for question regarding developing with the KDE > platform. > If there is really a need to fold one list with kde-frameworks its this one. Assuming you mean "folding frameworks-devel", I'd agree. (We could "merge" these lists, of course.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Location of Dr Konqi in Frameworks/KF 5
Hi Ian, On Friday, September 05, 2014 16:36:25 Ian Wadham wrote: > I have heard that Dr Konqi source code for Frameworks/KF 5 > has been placed in plasma-workspace. > > Please could you consider keeping it in some location that is > common to all platforms? This includes both Linux platforms and > non-Linux platforms, such as Windows and Apple OS X, where > Plasma is not usually required. > > Dr K used to be in kde-runtime on KDE 4 and is needed on > every platform, along with KCrash. I thought we discussed that a while ago, and concluded to put it into kde- workspace -- I think due to dependencies. This doesn't mean that it has to stay there, it just means that I don't recall the exact details. I'm including plasma-devel to ask someone who knows to weigh in. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 120535: attica: Add const to getter methods.
> On Oct. 8, 2014, 9:22 p.m., Albert Astals Cid wrote: > > According to > > https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ > > "changing the const/volatile qualifiers of the function" is BIC > > > > Now the thing is if we allow BIC changes in frameworks like attica or not > > is for someone else to answer. > > Jeremy Whiting wrote: > Yes, I saw that, the real question is if we allow BIC changes or not. > Also I guess if we don't allow BIC changes in frameworks anymore we should > change that page to not say BIC changes should all happen on Monday's anymore > :) > > Aleix Pol Gonzalez wrote: > Also you can add a TODO KF5 comment. And yes, fix the wiki... :/ > > Jeremy Whiting wrote: > Do you mean TODO KF6 ? If it's released as part of Frameworks, we don't allow BIC changes. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120535/#review68095 --- On Oct. 8, 2014, 9:20 p.m., Jeremy Whiting wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120535/ > --- > > (Updated Oct. 8, 2014, 9:20 p.m.) > > > Review request for KDE Frameworks, kdelibs and Frederik Gladhorn. > > > Repository: attica > > > Description > --- > > Add const to getter methods. > > > Diffs > - > > src/downloaddescription.h 08796c9283d1412386f6e096b981c3afa2b1f55e > src/downloaddescription.cpp f76a1601a53e66b836623f4ac7a67ceeb543c1f0 > > Diff: https://git.reviewboard.kde.org/r/120535/diff/ > > > Testing > --- > > This builds and an improved knewstuff (with const AtticaDescription &foo, > bar) in foreach lines builds. > > My only question about committing this is if it's allowed since it's a binary > incompatible change. If it's not allowed I will add duplicates of these > methods that are const and deprecate these non-const ones instead. > > > Thanks, > > Jeremy Whiting > >
Re: desktoptojson and list properties
On Monday, November 17, 2014 02:04:51 Aleix Pol wrote: > On Mon, Nov 17, 2014 at 12:24 AM, Milian Wolff wrote: > On Sunday 16 November 2014 23:52:25 Milian Wolff wrote: > > KDevelop is currently bitten hard by a bug/limitation in desktoptojson. It > > does not actually understand the .desktop files and custom properties get > > converted to plain JSON strings. Looking at the sources it's also clear > > why, only a selected list of .desktop properties is interpreted as lists. > > > > We have a custom kdevelopplugin.desktop file that describes our custom > > properties via something like: > > > > [Desktop Entry] > > Type=ServiceType > > X-KDE-ServiceType=KDevelop/Plugin > > X-KDE-Derived=KPluginInfo > > Name=KDevelop Plugin > > ... > > [PropertyDef::X-KDevelop-Interfaces] > > Type=QStringList > > ... > > > > To me it looks like I'll have to add support for such files to > > desktoptojson. But I wonder: Where was/is the code for the above files > > (how > > are they called?)? > > Apparently these are KServiceType's and the code can be found in kservice. > In kservice.cpp's KServicePrivate::property we see code like this: > > // No luck, let's ask KServiceTypeFactory what the type of this property > // is supposed to be. > // # this looks in all servicetypes, not just the ones this service > // supports! > KServiceTypeFactory::self()->findPropertyTypeByName(...) You can't do this, desktoptojson is in kcoreaddons nowadays, and doesn't allow KService as a dependency. Currently, the list properties are hardcoded in desktoptojson. I suppose you could also add it in there, but that feels quite meh, since ... well... hardcoded. > Fine, I could add similar code to desktoptojson, but: > > Since desktoptojson will be called for the plugins we ship in > > KDevplatform, > > how would/could I make desktoptojson "know" about the > > kdevelopplugin.desktop file without it being installed yet? > > that would not work here as our service type is still unknown to > kbuildsycoca! > > Or can we nowadays write the .json files directly, i.e. can scripty/ki18n > > cope with them nowadays? > > So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. > I guess a solution would be to be able to provide the servicetype file as an > argument to desktoptojson? Also given how the plan is to move away from > kbuildsycoca database for these files (no?) maybe it would make sense to > have an alternative way to look them up by path? The problem is not so much looking them up, but reading them, as far as I understand, those bits are really central to KService, and quite entangled at that. I don't think you'll have much luck cutting that out there to make it usable on its own -- but then, maybe you find a way... Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 121084: Rename libmolletnetwork to avoid conflict with KDE4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121084/#review70581 --- Ship it! Looks sane to me, also solves a real-world problem. Thanks! - Sebastian Kügler On Nov. 9, 2014, 4:10 p.m., Armin K. wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121084/ > --- > > (Updated Nov. 9, 2014, 4:10 p.m.) > > > Review request for KDE Runtime, KDE Frameworks and Plasma. > > > Repository: kio-extras > > > Description > --- > > KDE-Runtime already provides libmolletnetwork, so lets rename > this one to include 5 as a suffix since many apps outside of > KDE still depend on KDE-Runtime. > > > Diffs > - > > network/ioslave/CMakeLists.txt 06a964d > network/kded/CMakeLists.txt 3be676e > network/network/CMakeLists.txt c0fb43e > > Diff: https://git.reviewboard.kde.org/r/121084/diff/ > > > Testing > --- > > > Thanks, > > Armin K. > >
Re: desktoptojson and list properties
On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: > > > > Or can we nowadays write the .json files directly, i.e. can > > > > scripty/ki18n > > > > cope with them nowadays? > > > > > > So, any chance we can use .json directly here? > > > > That should be possible, you can just drop the json file in there, and > > reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. > > So scripty and the ki18n crew can cope with .json files nowadays? No reason > to use .desktop at all anymore? > > That would be an acceptable solution for me. Though I guess desktoptojson > should get a big fat warning that this it is deprecated and one should > better write .json directly to prevent such issues from occurring randomly > in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request 121086: Rename jpegcreatorsettings.kcfg to avoid conflicts with KDE4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121086/#review70583 --- thumbnail/CMakeLists.txt <https://git.reviewboard.kde.org/r/121086/#comment49407> whitespace What I'm missing is migration of the setting, is that relevant, any other reason why it's missing? - Sebastian Kügler On Nov. 9, 2014, 4:09 p.m., Armin K. wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121086/ > --- > > (Updated Nov. 9, 2014, 4:09 p.m.) > > > Review request for KDE Runtime, KDE Frameworks and Plasma. > > > Repository: kio-extras > > > Description > --- > > Simply add 5 as a suffix to avoid conflicts with KDE 4 version which > is shipped in KDE-Runtime which isn't going away any time now. > > > Diffs > - > > thumbnail/CMakeLists.txt e9ab79b > thumbnail/jpegcreator.cpp de4902b > thumbnail/jpegcreatorsettings.kcfg 8f68f46 > thumbnail/jpegcreatorsettings.kcfgc 3f6cdab > thumbnail/jpegcreatorsettings5.kcfg PRE-CREATION > thumbnail/jpegcreatorsettings5.kcfgc PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/121086/diff/ > > > Testing > --- > > > Thanks, > > Armin K. > >
Re: [owncloud-devel] research question
On Thursday, November 20, 2014 17:11:12 Jos Poortvliet wrote: > A research question for you: how common is 'episodic volunteering', that > is, how often do people do short, one-off or irregular contributions, as > opposed to more long-term contributions, in your project? > > "Episodic volunteers are volunteers who choose short-term volunteering > assignments or specific projects. Episodic volunteers may be one-off > contributors or they can 'bounce-back' by returning for future assignments." > > I think it varies between projects - so, just look at what you're involved > with. What % of work comes from regular contributors, and what comes from > occasional/one-off contributors? And what are your thoughts on quality and > importance? > > It's for a scientific research project (not mine), if something interesting > comes out I'll be sure to share. I think Paul Adams has scripts to measure exactly this. Talk to him! -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: > > 2.2 is easier (if possible to change the code in 1 to do it) since it does > > not involve writing back strings to the json file. > > In kf5 using "LANGUAGE=foo kate" or LANGUAGE=foo kdevelop" (both projects > do not install desktop files but use json files generated at build time > from desktop files) I see the name/description (from the json files) of > plugins in the settings dialog translated in language "foo". > > So apparently in kf5 using json files with translated Name/Description as > provided by Kevin's example kdevpatchreview.json I get the proper > translations in the GUI. > Please check that, you do not need to have language "foo" installed, just > launch kate or kdevelop using x-test/uk/de/fr... as value for "foo". > > If that works we could treat json and desktop files in the same way from > devel/translators pov, because what is the difference between desktop and > json files? > Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 18:46:28 Milian Wolff wrote: > > Looks to me like translations are not supported via json files. > > Please check the above. Anyhow, imo it should be our goal to get this > supported. In the ideal scenario, a plugin would be just a .so installed > into the right directory. No .desktop, no sycoca cache. That's exactly the idea. The json metadata baked into the plugin should have all necessary information, in the right form (so also the list properties Milian started this thread about) and be translatable . This ultimately allows us to get rid of installing desktop files, and plugins just become one single file (the .so file), instead of an .so file and a .desktop file in two different places. > So again, what is necessary to get this done? A translation expert / i18n dude should be able to answer this, I know too little about translations. :/ Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 23:00:57 Albert Astals Cid wrote: > > So again, what is necessary to get this done? > > Well, there's two steps about this: > > 1) Know where the code is that gets the Name/Comment/Description from the > json I don't understand this. What do you mean exactly? > 2) Decide how you want to translate stuff (which may depend on 1) > > For 2) there's broadly two options: > 2.1: Make the .json file have the translations and make sure the code from > 1 reads it properly > 2.2: Make the translations be in the .po and then make the code from 1 read > the english variant and call i18n(englishText) > > 2.2 is easier (if possible to change the code in 1 to do it) since it does > not involve writing back strings to the json file. I'd prefer 2.1, since we have to write the json metadata into the plugins, so we'd have to assemble the original (untranslated) and translated data into one json structure anyway. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 18:46:28 Milian Wolff wrote: > > Looks to me like translations are not supported via json files. > > Please check the above. Anyhow, imo it should be our goal to get this > supported. In the ideal scenario, a plugin would be just a .so installed > into the right directory. No .desktop, no sycoca cache. That's exactly the idea. The json metadata baked into the plugin should have all necessary information, in the right form (so also the list properties Milian started this thread about) and be translatable . This ultimately allows us to get rid of installing desktop files, and plugins just become one single file (the .so file), instead of an .so file and a .desktop file in two different places. > So again, what is necessary to get this done? A translation expert / i18n dude should be able to answer this, I know too little about translations. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 23:00:57 Albert Astals Cid wrote: > > So again, what is necessary to get this done? > > Well, there's two steps about this: > > 1) Know where the code is that gets the Name/Comment/Description from the > json I don't understand this. What do you mean exactly? > 2) Decide how you want to translate stuff (which may depend on 1) > > For 2) there's broadly two options: > 2.1: Make the .json file have the translations and make sure the code from > 1 reads it properly > 2.2: Make the translations be in the .po and then make the code from 1 read > the english variant and call i18n(englishText) > > 2.2 is easier (if possible to change the code in 1 to do it) since it does > not involve writing back strings to the json file. I'd prefer 2.1, since we have to write the json metadata into the plugins, so we'd have to assemble the original (untranslated) and translated data into one json structure anyway. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: Review Request for KDecoration
On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote: > > Given that you call it "fundamental", I suggest to allow qreal here. > > A "millimeter" is really small, and if you only allow integer values, > > the precision might be too coarse. > > The documentation is copied from Plasma. I don't know anything about high > DPI, so maybe sebas can answer that. Context? :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request for KDecoration
On Friday, November 28, 2014 14:16:38 Martin Gräßlin wrote: > On Friday 28 November 2014 13:53:07 Sebastian Kügler wrote: > > On Friday, November 28, 2014 12:00:43 Martin Gräßlin wrote: > > > > > > The documentation is copied from Plasma. I don't know anything about > > > high > > > DPI, so maybe sebas can answer that. > > > > Context? > > the context is High-DPI in particular the gridUnit which I also introduced > in KDecoration2 with exactly the same documentation. Verbatim quote: > /** > * The fundamental unit of space that should be used for sizes, > expressed in pixels. > * Given the screen has an accurate DPI settings, it corresponds to a > millimeter > */ > Q_PROPERTY(int gridUnit READ gridUnit NOTIFY gridUnitChanged) Ah, right. int is used here to prevent sub-pixel alignment problems. We always want to align stuff at full pixels. Does this clarify? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: desktoptojson and list properties / i18n of JSON files
On Thursday, November 20, 2014 20:18:29 Burkhard Lück wrote: > Am Donnerstag, 20. November 2014, 20:05:19 schrieb Sebastian Kügler: > > On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: > > > > 2.2 is easier (if possible to change the code in 1 to do it) since it > > > > does > > > > not involve writing back strings to the json file. > > > > > > In kf5 using "LANGUAGE=foo kate" or LANGUAGE=foo kdevelop" (both > > > projects > > > do not install desktop files but use json files generated at build time > > > from desktop files) I see the name/description (from the json files) of > > > plugins in the settings dialog translated in language "foo". > > > > > > So apparently in kf5 using json files with translated Name/Description > > > as > > > provided by Kevin's example kdevpatchreview.json I get the proper > > > translations in the GUI. > > > Please check that, you do not need to have language "foo" installed, > > > just > > > launch kate or kdevelop using x-test/uk/de/fr... as value for "foo". > > > > > > If that works we could treat json and desktop files in the same way from > > > devel/translators pov, because what is the difference between desktop > > > and > > > json files? > > > Name and format, nothing else. > > > > The json embedded in plugins is created using the desktoptojson tool. This > > tool runs at build time, it converts a .desktop file (including its > > translations) to a .json file, which is then embedded into the plugin > > binary. This tool has only limited understanding of list properties (this > > limitation is what Milian's problem triggering this thread is about). An > > idea is to not do a conversion, but rather add a json file to the > > repository, which can directly be included. Since translations are done in > > the .desktop file, the json file would not be translated. This is the root > > of the problem. > > Please launch "LANGUAGE=nl kdevelop" or "LANGUAGE=nl kate" in Konsole. > Do you have translated Names/Description in the settings dialog page > Plugins? Again, and sorry for not making myself clear, this problem is only secondary about translations, it's mainly about the metadata in the plugins being wrong for custom keys that use a list, i.e. QStringLists. Fixing localization in kdevelop is really a different issue -- not less important, just different. cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: Review Request 121361: DeviceAutomounter Settings ui texts are misleading, if not plain wrong.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121361/#review71555 --- The patch just fixes two occurrences of confusion, but leaves others. (See inline for one example.) It should probably be an approach that fixes the confusion once and for all. With the naming wrong in the code, bugs are bound to creep in again at a later point. solid-device-automounter/kcm/DeviceAutomounterKCM.ui <https://git.reviewboard.kde.org/r/121361/#comment49907> Well, with this change, the whatsthis and I suppose the function of this checkbox does the exact opposite of its name. automountUnknownDevices now means "only automount know devices". - Sebastian Kügler On Dec. 5, 2014, 7:06 p.m., Frank Schütte wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121361/ > --- > > (Updated Dec. 5, 2014, 7:06 p.m.) > > > Review request for kdelibs, Solid, Christoph Feck, and Helio Castro. > > > Bugs: 243046 and 261376 > http://bugs.kde.org/show_bug.cgi?id=243046 > http://bugs.kde.org/show_bug.cgi?id=261376 > > > Repository: kde-runtime > > > Description > --- > > automounterrc has four settings: > [General] > AutomountEnabled=true > AutomountOnLogin=false > AutomountOnPlugin=false > AutomountUnknownDevices=true > > The ui text for AutomountUnknownDevices says the opposite of its > functionality. This is repaired by the patch. Login/Plugin enable/disable > overrides. I tried to clarify this a little bit. > > > Diffs > - > > solid-device-automounter/kcm/DeviceAutomounterKCM.ui 3827e95 > > Diff: https://git.reviewboard.kde.org/r/121361/diff/ > > > Testing > --- > > > Thanks, > > Frank Schütte > >
Re: [Kde-pim] Problems with infrastructure
[I love our infrastructure, just this bit triggered my reply-to-email reflex] On Wednesday, December 10, 2014 10:28:59 Christian Mollekopf wrote: > * deleting branches: This is the only major gripe I have with the kde > infrastructure. I think everyone should be able to delete branches (except > some blacklisted ones). If I cannot delete my branches when I no longer > need them I try to avoid pushing them, which doesn't help. Personal clones > are not a solution IMO because you have to manage additional remotes. IMO > the benefits outweigh the danger of someone accidentally deleting someone > else's branch. Perhaps a naming scheme could be established for such > branches, such as: dev/$foo or feature/$foo In Plasma, we usually name branches /, so for example sebas/breakpluginloader. It'd be supersweet if the user who "owns" this branch would be able to delete it. I often leave these branches lingering for too long before I ask notmart to delete them, so that would be a useful addition. I quite like not being able to delete arbitrary branches. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: New framework to review: KPackage
On Monday, December 15, 2014 10:31:04 David Edmundson wrote: > On Mon, Dec 15, 2014 at 10:25 AM, Marco Martin wrote: > > On Thursday 11 December 2014, Kevin Kofler wrote: > > > Marco Martin wrote: > > > > In the past weeks I have been working on a new framework, called > > > > KPackage. > > > > > > You ARE aware that KPackage was the name of an old frontend for RPM and > > > other package managers that used to be part of the KDE Software > > > > Compilation > > > > > 4? > > > > open for suggestions for names.. > > KPackage isn't a user facing name, I don't think we need to rename anything. Same thought here. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [Kde-pim] Problems with infrastructure
On Wednesday, December 17, 2014 08:47:09 Jeff Mitchell wrote: > I understood that to be the case -- I'm really meaning for a general, > KDE-wide solution. > > Personally I don't have an issue with volunteers taking care of > non-official systems if it helps their productivity. If Gerrit wasn't > where KDE as a whole went, and you wanted to put the effort in to keep > Gerrit working for you and integrated with the rest of the KDE systems, > more power to you. > > The issue I see (which doesn't necessarily reflect my personal views) is > that KDE projects have been required to use KDE infrastructure. I forget > where that's written/required, but I do know that that it exists. The > purpose of this was to avoid fragmentation or making it difficult to > find the full breadth of KDE projects, or requiring KDE developers to > sign up for multiple e.g. bugtracking systems just to comment on another > KDE project. I think you're referring to manifesto.kde.org. There's nothing in there about Reviewboard, or a requirement that project have to use infrastructure hosted at kde.org, so I don't see that as a blocker. Of course it would be prudent to give KDE's sysadmin's access at some point, but it's not required per se. > I tend to be productivity-oriented rather than dogmatic, but I certainly > don't speak for everyone on that point. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [Kde-pim] Problems with infrastructure
On Tuesday, December 16, 2014 16:12:05 Ben Cooksley wrote: > For deleting branches, I think we can allow this - given some > protection for certain branches (like the KDE/* branches for > instance). Note that courtesy of the backup functionality in our > hooks, no branch or tag is ever truly deleted from a repository on > git.kde.org. I don't know how easy it would be to alter this behaviour > based on the account name of the developer. What I would find helpful, concretely: - being allowed to delete "own" branches - force push for "own" branches since I could delete and recreate a branch, I may just as well directly be allowed to force-push, this makes it a bit easier to keep branches as clean as possible where "own" means "branchname starts with username/", for example "sebas/hacking". Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [Kde-pim] Problems with infrastructure
On Friday, December 19, 2014 23:26:15 Albert Astals Cid wrote: > El Dijous, 18 de desembre de 2014, a les 14:52:12, Sebastian Kügler va > > On Wednesday, December 17, 2014 08:47:09 Jeff Mitchell wrote: > > > I understood that to be the case -- I'm really meaning for a general, > > > KDE-wide solution. > > > > > > Personally I don't have an issue with volunteers taking care of > > > non-official systems if it helps their productivity. If Gerrit wasn't > > > where KDE as a whole went, and you wanted to put the effort in to keep > > > Gerrit working for you and integrated with the rest of the KDE systems, > > > more power to you. > > > > > > The issue I see (which doesn't necessarily reflect my personal views) is > > > that KDE projects have been required to use KDE infrastructure. I forget > > > where that's written/required, but I do know that that it exists. The > > > purpose of this was to avoid fragmentation or making it difficult to > > > find the full breadth of KDE projects, or requiring KDE developers to > > > sign up for multiple e.g. bugtracking systems just to comment on another > > > KDE project. > > > > I think you're referring to manifesto.kde.org. There's nothing in there > > about Reviewboard, or a requirement that project have to use > > infrastructure > > hosted at kde.org, so I don't see that as a blocker. > > I don't agree with that you said, manifesto says > > "Online services associated with the project are either hosted on KDE > infrastructure or have an action plan that ensures continuity which is > approved by the KDE system administration team" I stand corrected. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). I'd add "frameworks" to that, it has a status very similar to "master" for many projects. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma 5.2 bits for kdereview
On Friday, December 19, 2014 18:46:11 Luigi Toscano wrote: > > kscreen and libkscreen maintained by Dan Vrátil. libkscreen is already > > released with Plasma but isn't in kde/workspace. > > > > https://projects.kde.org/projects/extragear/libs/libkscreen > > https://projects.kde.org/projects/extragear/base/kscreen > > I disagree with moving libkscreen to kde/workspace. It is a dependency for > at least one application (Okular), which has no Framework version for now > but it will have it. It would make more sense to have libkscreen in > Frameworks, like libnm* libkscreen is not ready for that, currently. It's not API stable enough to warrant such a step. It is used mainly in Plasma, but also by others (you name Okular). I don't see that as a problem, you won't have to install all of Plasma just to get libkscreen. It's at least a much better place to be grouped under than "playground". If you're still against moving it from playground, where would you rather see it? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
On Tuesday, December 23, 2014 06:27:01 Albert Astals Cid wrote: > El Dimarts, 23 de desembre de 2014, a les 14:48:21, Sebastian Kügler va > > escriure: > > On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > > > The first seems the least contentious: allowing all developers to > > > delete branches on our mainline repositories, except for certain > > > protected branches (like "master" and "KDE/*" for instance). > > > > > > > > I'd add "frameworks" to that, it has a status very similar to "master" for > > many projects. > > Has it? As far as i understand frameworks is "just" a work branch that will > eventually merged into "master" when it's done. IMO, yes. It's a branch shared across many people and often being the base for yet another branch, so the annoyance of someone doing a force-push there would be quite high. I'm in favor of only relaxing the permissions for "personal" branches (i.e. branches that you've created yourself (in Plasma, we're using username/branchname quite consistently, so just matching for "starts with $username" would work well enough for me). Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
On Tuesday, December 23, 2014 17:29:05 Ivan Čukić wrote: > > I'd add Applications/* and Plasma/* to this. > > > >Would it be possible to add the Calligra/* release branches to that > > Seems that release branches are starting with capital letters. Would that > be possible and sufficient for the deletable-branch heuristic? Sounds very cryptic to me, to be honest. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Fwd: Plasma 5.2 bits for kdereview
On Wednesday, January 07, 2015 20:31:57 Albert Astals Cid wrote: > > Albert has said he's fine with KDE Applications depending on Plasma (I > > think) > > http://mail.kde.org/pipermail/kde-frameworks-devel/2015-January/021332.htm > > l > > I said "I'm fine with KDE Applications depending on Plasma to improve > workpsace integration" or something like that. > > BUT libkscreen and libmm-qt don't seem > workpsace-integration-improvement-libs to me but basic libs to access > system stuff. libkscreen is mainly for reading and settings X configuration. That's quite workspace-specific. For use-cases typical for apps, there's way easier API (QScreen, for example). libmm-qt ... I dunno, why would an app use it? (I can construct a weird use- case, but in the end, information about modem setup is a system / workspace- specific feature, not something typically done in apps. There are no hard boundaries, much depends on interpretation, but given it's debatable, I think keeping these things together in kde/workspace makes sense. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Warning: KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated
On Saturday, February 21, 2015 11:02:48 Marco Martin wrote:
> As you may have noticed, right now starting plasma is a big spam of
> the following error:
> Calling KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated,
> use KPluginInfo::pluginName() in "/whatever/plugin.so" instead.
>
> i tried to see where it happens, and seems it's in
> ktradeparsetree.cpp , line 30
> QVariant ParseContext::property(const QString &_key) const
>
> I don't think this "properly" fixable, since from the stack trace it
> seems an appropriate use.. i see two ways to fix it:
>
> 1) in ParseContext::property stuf a very long if.. else.. that makes
> it call the proper KPluginInfo::correctAccessor() .. but is ugly and
> slows it down
>
> 2) since this is an appropriate use, consider it not wrong anymore,
> and just get rid of the warning.
>
> Opinions? ideas?
I've looked at it, too, since the warnings shown are just burying any useful
information during the startup of Plasmashell. I think the warning is rather
useless, and I'd just remove it, so 2).
Cheers,
--
sebas
Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: Review Request 121831: libksysguard: process.h: encapsulate private fields
> On Feb. 21, 2015, 2:46 a.m., Hrvoje Senjan wrote: > > can you check what needs to be adjusted in plasma-workspace? it fails to > > build with your change: > > > > > > > > [ 451s] > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:471:43: > > error: 'proc->KSysGuard::Process::command' does not have class type > > [ 451s] QString cmdline = proc ? proc->command.simplified() : > > QString(); // proc->command has a trailing space??? > > [ 451s]^ > > [ 451s] > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:501:103: > > error: no matching function for call to 'KService::KService( > overloaded function type>, QString&, QString)' > > [ 451s] services << QExplicitlySharedDataPointer(new > > KService(proc->name, cmdline, QString())); > > [ 451s] > > ^ > > [ 451s] > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:501:103: > > note: candidates are: > > [ 451s] In file included from /usr/include/KF5/KService/KService:1:0, > > [ 451s] from > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:32: > > [ 451s] /usr/include/KF5/KService/kservice.h:580:5: note: > > KService::KService(QDataStream&, int) > > [ 451s] KService(QDataStream &str, int offset); > > [ 451s] ^ > > [ 451s] /usr/include/KF5/KService/kservice.h:580:5: note: candidate > > expects 2 arguments, 3 provided > > [ 451s] In file included from /usr/include/KF5/KService/KService:1:0, > > [ 451s] from > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:32: > > [ 451s] /usr/include/KF5/KService/kservice.h:82:14: note: > > KService::KService(const KDesktopFile*, const QString&) > > [ 451s] explicit KService(const KDesktopFile *config, const QString > > &entryPath = QString()); > > [ 451s] ^ > > [ 451s] /usr/include/KF5/KService/kservice.h:82:14: note: candidate > > expects 2 arguments, 3 provided > > [ 451s] /usr/include/KF5/KService/kservice.h:75:14: note: > > KService::KService(const QString&) > > [ 451s] explicit KService(const QString &fullpath); > > [ 451s] ^ > > [ 451s] /usr/include/KF5/KService/kservice.h:75:14: note: candidate > > expects 1 argument, 3 provided > > [ 451s] /usr/include/KF5/KService/kservice.h:68:5: note: > > KService::KService(const QString&, const QString&, const QString&) > > [ 451s] KService(const QString &name, const QString &exec, const > > QString &icon); > > [ 451s] ^ > > [ 451s] /usr/include/KF5/KService/kservice.h:68:5: note: no known > > conversion for argument 1 from '' to > > 'const QString&' > > [ 451s] > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp: > > In function 'QUrl TaskManager::getServiceLauncherUrl(int, const QString&, > > const QStringList&)': > > [ 451s] > > /home/abuild/rpmbuild/BUILD/plasma-workspace-5.2.90git/libtaskmanager/taskitem.cpp:516:43: > > error: 'proc->KSysGuard::Process::command' does not have class type > > [ 451s] QString cmdline = proc ? proc->command.simplified() : > > QString(); // proc->command has a trailing space??? > > [ 451s]^ > > Gregor Mi wrote: > Probably `proc->command` must be replace with `proc->command()`. I'll > check that. > > Gregor Mi wrote: > How can I find out if which branch was compiled? I assume it is the > master branch. > > Bhushan Shah wrote: > > How can I find out if which branch was compiled? I assume it is the > master branch. > > Yes its master branch Aleix and me have fixed plasma-workspace's build. Update the master branch. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121831/#review76358 --- On Feb. 20, 2015, 9:46 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/121831/ > --- > > (Updated Feb. 20, 2015, 9:46 p.m.) > > > Review request for KDE Base Apps, Dominik Haumann, Eike Hein, and John > Tapsell. > > > Repository: libksysguard > > > Description > --- > > This is a follow-up to https://git.reviewboard.kde.org/r/121717/: > > In process.h there are several public fields which easily trigger BIC > changes. This RR introduces a d-ptr. > > (In a separate commit I would add the .reviewboardrc file) > > > Diffs > - > > processui/scripting.h 2445c0ab0d81af3283c0f6e9c5f34
Re: Warning: KPluginInfo::property("X-KDE-PluginInfo-Name") is deprecated
On Saturday, February 21, 2015 17:19:02 Alexander Richardson wrote:
> 2015-02-21 14:43 GMT+00:00 Marco Martin :
> > On Sat, Feb 21, 2015 at 1:34 PM, Alexander Richardson
> >
> > wrote:
> >> and then we could also have something like
> >> KServiceTypeTrader::findPlugin(serviceType, name) that expands to
> >> KServiceTypeTrader::self()->query(serviceType, [](const KPluginInfo
> >> &info) {>>
> >> return info.pluginName() == name;
> >>
> >> }
> >>
> >> I have been meaning to add this for quite a while, but I am really
> >> busy at the moment.
> >
> > So we would maintain such a warning, but start to port users to that
> > new api instead?
>
> Yes, that would be my suggestion. I won't be able to work on it before
> Thursday though. Ideally there shouldn't be many changes required to
> make it work for KMimeTypeTrader aswell, so then in KF5 we can get rid
> of all the generated parsing code.
That's completely fine. We're not too much in a hurry, it's not a showstopper
by any means, just some janitorial work to make Plasma a bit easier to debug.
Currently, about 2/3 of its console output consists of these messages.
Thanks, Alex!
--
sebas
Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: The Future or KDE PIM Releases
Hey PIMsters, On Sunday, April 12, 2015 11:31:26 Daniel Vrátil wrote: > Greetings from Toulouse! > > We've been discussing the plans for releases of Akonadi(Next) and KDE PIM as > a whole on the PIM sprint, because the current situation is kinda unclear > and harmful for the project. > > Now that we have a better idea of what Akonadi Next will be like, we > decided that we don't want to just basically stop working on PIM and focus > all our efforts towards Akonadi Next because that would cause the entire > PIM to be in sort of a limbo for who-knows-how-long and that would not be > good for our users and for the project in general. We are already losing > users so freezing the development of the project does not sound like a good > idea. > > Instead we will aim towards releasing KF5-based KDE PIM with "Akonadi 1" in > the next release of KDE Applications in August. That means we now have > about 4 months to make sure that there are no regressions caused by changes > in Qt behavior - this should be manageable and not much effort really. This > is an internal change more or less, users won't notice anything. This sounds awesome. I've been having a bit of doubt about the earlier plans to bet everything on Akonadi Next and not release a Qt5/KF5 port first -- from experience with many projects in the KDE4 migration, but also from a users' point of view, who would in that case be missing a properly integrated PIM in Plasma 5 for quite a while. Thanks for revisiting these plans, from what I can see, the revised strategy seems very good. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KF5-QT5 branchgroup - jobs that need developeer attention
Hi Scarlett, On Wednesday, April 15, 2015 00:44:14 Scarlett Clark wrote: > Here is a list of mostly compile failures and other tid bits that need to be > resolved by the respective developers. If you know the developer of a > project and they are not on this list please forward this. All jobs can be > viewed at : https://build-sandbox.kde.org/ > Most of these are osx failures. If osx is not to be supported, I need to > know that too. Questions - concerns - just ask. > Thanks, > Scarlett > kdeplasma-addons - osx - compile failure Should be fixed with ec2992a97b905c8. Thanks for the note! -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: KSyCoca, Thread safety, and Cache invalidation
On Saturday, June 13, 2015 02:04:03 Vishesh Handa wrote: [...] > 3. The gui thread on receiving the dbus signal updates its db as well > as the database of all other threads. This is slightly complex and > would require locking code similar to (2) since the other threads > could be in the process of using KSycoca. [...] > I'm not quite sure on how to go about this. Do you have any > suggestions? I'm leaning towards (3), but the locking code is scary. 7. the gui thread listens to dbus and sends a signal to the other threads? -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: KScreenGenie moved to KDE Review
On Tuesday, June 16, 2015 02:45:56 Boudhayan Gupta wrote: > The other thing I'd like to mention here is that there was talk on IRC > and the kde-community list a few months back that if KScreenGenie does > end up passing review and replacing KSnapshot, that it should take the > KSnapshot name and just become KSnapshot 2.0. I'd be grateful if > someone could tell me how to proceed for this. Perhaps you could point us all to some screenshots? One requirement for passing review and an eventual replacement of ksnapshot should be a successful review by our usability crew, maybe it can also be made prettier with some help from the VDG. Since not everybody is able to, or has the time to compile kscreengenie's sources, screenshots would be really helpful. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: Plasma Applet for Audio Volume for kdereview
On Thursday, August 06, 2015 00:40:41 Albert Astals Cid wrote: > Missing or not so good i18n > > > ./src/kcm/package/contents/ui/VolumeSlider.qml:84:text: > Math.floor(slider.value / slider.maximumValue * 100.0) + "%" > ./src/kcm/package/contents/ui/VolumeSlider.qml:90:text: "100%" > ./src/kcm/package/contents/ui/StreamListItem.qml:55:tex > t: PulseObject.client.name + ": " + PulseObject.name > ./src/kcm/package/contents/ui/main.qml:33:ConfigModule.quickHelp: > "((UNKNOWN))" > ./applet/contents/ui/ListItemBase.qml:208:text: > Math.floor(slider.value / slider.maximumValue * 100.0) + "%" > ./applet/contents/ui/ListItemBase.qml:230:text: "100%" > ./applet/contents/ui/StreamListItemBase.qml:28:label: > PulseObject.client.name + ": " + PulseObject.name Thanks, I'll fix these. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Sunday, August 09, 2015 14:59:59 Dāvis Mosāns wrote: > 2015-08-05 15:45 GMT+03:00 Jonathan Riddell : > > plasma-pa is a new volume manager and is intended to be a replacement for > > KMix in Plasma. > > > > We plan to ship it as a beta in Plasma 5.4 and it's currently in kdereview > > for your reviewing attention. > > > > https://projects.kde.org/projects/kdereview/plasma-pa > > I can't find how to move specific application to different output like > you can in KMix, it's not implemented? > This is very important feature for me. Also I think it would be handy > if in tray would be another tab > for changing volume for applications too and wouldn't need to open settings. You can do that from the KCM, but not from the Plasmoid. Whether that's a usecase we want to support at this point, I'm not sure (I personally would like to see switching outputs per source easily). It's not material for its first release, anyway. We're past feature freeze and the goal was to get a basic first version released rather than having it lingering for a long time. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Thursday, August 06, 2015 12:25:32 Burkhard Lück wrote:
> Am Donnerstag, 6. August 2015, 00:40:41 schrieb Albert Astals Cid:
> > Missing or not so good i18n
> >
> > ./src/kcm/package/contents/ui/VolumeSlider.qml:84:text:
> > Math.floor(slider.value / slider.maximumValue * 100.0) + "%"
> > ./src/kcm/package/contents/ui/VolumeSlider.qml:90:text: "100%"
> > ./src/kcm/package/contents/ui/StreamListItem.qml:55:
> > text: PulseObject.client.name + ": " + PulseObject.name
> > ./src/kcm/package/contents/ui/main.qml:33:ConfigModule.quickHelp:
> > "((UNKNOWN))"
> > ./applet/contents/ui/ListItemBase.qml:208:
> > text: Math.floor(slider.value / slider.maximumValue * 100.0) + "%"
> > ./applet/contents/ui/ListItemBase.qml:230:text: "100%"
> > ./applet/contents/ui/StreamListItemBase.qml:28:label:
> > PulseObject.client.name + ": " + PulseObject.name
>
> Please keep in mind that some langs show the "%" sign before the value, so
> it should be i18n("%1%", value) for percent values
All i18n issues pointed out have been fixed.
Thanks for the review,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Thursday, August 06, 2015 22:56:09 Luigi Toscano wrote: > Jonathan Riddell ha scritto: > > plasma-pa is a new volume manager and is intended to be a replacement for > > KMix in Plasma.> > > > > We plan to ship it as a beta in Plasma 5.4 and it's currently in kdereview > > for your reviewing attention.> > > > > https://projects.kde.org/projects/kdereview/plasma-pa > > > > Please check over it and consider if it passes review. > > No documentation? Is this a hard requirement? (I'm asking because we have many components like this without documentation, and I personally haven't used that feature in years.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Monday, August 10, 2015 20:37:26 Albert Astals Cid wrote: > El Dilluns, 10 d'agost de 2015, a les 10:35:48, Sebastian Kügler va escriure: > > On Thursday, August 06, 2015 22:56:09 Luigi Toscano wrote: > > > Jonathan Riddell ha scritto: > > > > > > No documentation? > > > > Is this a hard requirement? (I'm asking because we have many components > > like this without documentation, and I personally haven't used that > > feature in years.) > > We've had it marked as hard requirement for a long time in > https://techbase.kde.org/Policies/Application_Lifecycle > > But it's true that Plasma has been specially good in not following the rule. Thanks. I'll try to come up with at least a minimal docbook-based piece of documentation. It may take a few days to materialize. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Monday, August 10, 2015 19:40:34 Sebastian Kügler wrote: > On Monday, August 10, 2015 20:37:26 Albert Astals Cid wrote: > > El Dilluns, 10 d'agost de 2015, a les 10:35:48, Sebastian Kügler va > > escriure: > > > On Thursday, August 06, 2015 22:56:09 Luigi Toscano wrote: > > > > > > Is this a hard requirement? (I'm asking because we have many components > > > like this without documentation, and I personally haven't used that > > > feature in years.) > > > > We've had it marked as hard requirement for a long time in > > https://techbase.kde.org/Policies/Application_Lifecycle > > > > But it's true that Plasma has been specially good in not following the > > rule. > Thanks. I'll try to come up with at least a minimal docbook-based piece of > documentation. It may take a few days to materialize. Pushed, though I've disabled the docs/ subdirectory for now, since it requires new entities in KDocTools, and I want to wait a few days as to not break people's builds for this. Will be in the 5.4.0 release, though. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
On Wednesday, August 12, 2015 21:49:43 Ben Cooksley wrote: > On Wed, Aug 12, 2015 at 12:02 PM, David Edmundson > > wrote: > >> We've had it marked as hard requirement for a long time in > >> https://techbase.kde.org/Policies/Application_Lifecycle > >> > >> But it's true that Plasma has been specially good in not following the > >> rule. > > > > Plasma is not an application. > > I think he was referring to Plasma as a project there. Also, the Evolve survey was pretty clear that we utterly suck in the documentation arena. Playing with words doesn't solve that, writing documentation and maintaining it does. We may change the rules, and that's perhaps what we should do, but that doesn't begin with "let's ship a new module without docbook", that should begin with a cunning plan to move to online docs, the wiki, etc. and integrate that into the help function of applications. Right now the help button is a sort-of catch22, docs are usually useless, so I don't see the necessity to write them, so they're more useless (or not present). Anyway, discussion in this thread is moot, since I've committed a docbook which is hopefully helpful for those who know to find it. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Documentation (was Re: Plasma Applet for Audio Volume for kdereview)
On Wednesday, August 12, 2015 12:20:29 Luigi Toscano wrote: > On Wednesday 12 of August 2015 10:05:34 Sebastian Kügler wrote: > > Also, the Evolve survey was pretty clear that we utterly suck in the > > documentation arena. Playing with words doesn't solve that, writing > > documentation and maintaining it does. > > > > > > We may change the rules, and that's perhaps what we should do, but that > > doesn't begin with "let's ship a new module without docbook", that should > > begin with a cunning plan to move to online docs, the wiki, etc. and > > integrate that into the help function of applications. Right now the help > > button is a sort-of catch22, docs are usually useless, so I don't see the > > necessity to write them, so they're more useless (or not present). > > I've seen many review requests from Burkhard to review tons of > documentation. He is doing a big work on many modules (few applications > receives some hel p from the maintainers). I know, I reviewed many of them. > Thanks to maintainers who checked and approved the reviews, but I didn't > see any request for changing them or updating them before this effort, > regardless of the format (reading the generated documentation is possible > without dealing with DocBook). To be clear, I didn't mean to diminish Burkhard's work, the opposite is true. Documentation is important, and people who care about it are doing important work. Simple as that. That's why I sat down and wrote the plasma-pa doc, instead of lamenting whether it's really needed. > If you think that the documentation is useless, please report it, just for > any bug. I don't see why it can't be improved, again regardless of the > format. Even without thinking about future formats, a simple document in > any format with the updates is always more than welcome. > > About the format, personally speaking, a system which relies only on online > docs is not going to work, both ways should be possible (offline and > online). Yes and no, but it's offtopic here, so let's not get into this. > > Anyway, discussion in this thread is moot, since I've committed a docbook > > which is hopefully helpful for those who know to find it. > > So let's change the thread. Indeed. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Plasma Applet for Audio Volume for kdereview
I think we should be peachy now. Can plasma-pa be moved from kdereview to kde/workspace? On Wednesday, August 05, 2015 12:45:01 Jonathan Riddell wrote: > plasma-pa is a new volume manager and is intended to be a replacement for > KMix in Plasma. > > We plan to ship it as a beta in Plasma 5.4 and it's currently in kdereview > for your reviewing attention. > > https://projects.kde.org/projects/kdereview/plasma-pa > > Please check over it and consider if it passes review. > > Jonathan -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Modular startkde proof of concept
On Thursday, August 20, 2015 11:31:57 Helio Chissini de Castro wrote: > We ( aka's distros ) been patching startkde for years due obvious > particular things oriented to the specific distro. > Believe or not, is always an issue, since systems changes, and changed a > lot in this years. > > So, in a quick talk on Fedora KDE irc channel, i propose some old idea on > how to pursue the modularization of startkde, in some way easy to whitelist > / blacklist / cutomize everything. > > The idea is pretty simple, startkde do onthing more than source a numbered > scripts, following the ordefr under /etc/startkde.d > > If some distribution want to blcklist or modify the script, it can add te > same one in /etc/startkde.d/custom and the custom script will be read > instead of the regular one. > > It can be found on startkde_refactoring branch in plasma-workspace and is > in a rough state to be used. The bare metal tests worked, but not the > proper install part checked. > Quick link: > http://commits.kde.org/plasma-workspace/d9ddd44e8ecc28617d11a799416871b7d276 > 17a6 > > Since this is really distribution oriented, i would like to ask if we can > pursue this solution and what can be done to be better. On thing that would need further thinking is how this would work in a wayland work. Our current startup procedure is based on X11 behaviour, so X is started, then some stuff, then kwin, then some more stuff. The start of a wayland session is quite different though, as it's KWin that brings up the wayland server, so it has to be started first. That means that we need at least two ways to start a session. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [kde-community] Phabricator: Make it happen already!
On Wednesday, August 26, 2015 20:57:25 Jaroslaw Staniek wrote: > +1 > (I am using it as if it was official) Same here. The Plasma team is in the process of migrating to phaaab! already. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced
On Friday, December 04, 2015 11:28:03 AM Jan Kundrát wrote: > On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote: > > Note that in the long run with DMARC looming you will need to switch > > to #2 anyway, and keeping your current behaviour will likely lead to > > mail from people who use Yahoo / AOL / etc ending up in the spam > > folder with many mailing list members. I'll be starting a discussion > > regarding taking this step on KDE systems at some point in the near > > future (switching to DMARC compatible policies). > > > > For more information, please see http://wiki.list.org/DEV/DMARC > > Do I understand your plan correctly? The following projects appear to not > re-sign their ML traffic, and they mangle headers at the same time. If I > understand your plan correctly, this means that I won't be able to use my > @kde.org addresses on mailing lists of these projects, for example: > > - Qt, > - Debian, > - Gentoo, > - OpenStack, > - anything hosted at SourceForge, > - and many, many more, essentially anybody who were ignoring DKIM. > > Please, change your plans, this is obviously a huge no-go. I cannot see how this would not hurt development. IMO, we can only enforce DMARC once all of our stakeholders support it or for those that do. We're not living in an isolated environment. We can be very strict and religious about standards and enforcing them, but in the end it's going to hurt us, and I don't think that's worth it at all. We'd simply be wasting energy we're putting into KDE, and that's not reasonable dealing with our resources. I think the lack of objections to this plan stems from almost nobody understanding what these plans actually mean for our development processes. The discussion happening around it is therefore not representative, and I think many who would have objected, haven't, for that reason. I can't say that I fully understand it myself. Please reconsider. Cheers, -- sebas http://www.kde.org | http://vizZzion.org
Re: KDE Geolocation Services
[Copying Henri in, he does know] On Wednesday, November 03, 2010 23:27:11 Aaron J. Seigo wrote: > On Wednesday, November 3, 2010, Kevin Krammer wrote: > > On Wednesday, 2010-11-03, John Layt wrote: > > > The obvious backend solution is Geoclue, a freedesktop.org project > > > which is available on almost all distro's now, is used by Gnome, and > > > is an official part of the Meego platform. The problem comes in the > > > api to access Geoclue, which is a DBus based service with C bindings, > > > as we would obviously prefer a Qt-ish C++ wrapper for convenience. > > > > What kind of problem do you have in mind regarding a service with a D-Bus > > API? There are already tons of these and they are using D-Bus as the > > primary API exactly because it allows developers on different technology > > stacks to use their preferred way of handling the protocol. > > a) annoyance of using DBus directly > b) changes in the DBus API are out of our control. > > that said, what dependencies does Geoclue have these days? it used to > depend on gconf, which would be a highly unfortunate dependency for > kdelibs to acquire. it was said a few years (!) back that this dependency > would be easy to remove and would likely be. has it been? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDE Geolocation Services
On Thursday, November 04, 2010 16:04:33 John Layt wrote: > Which kind-of makes the whole GConf usage moot? No, it doesn't. If that stuff is still needed for actually using it, we're still effectively depending on whateverlibgconfisin, and that, as Aaron points out would be rather unfortunate. But maybe there is not gconf dep anymore anyway, let's hear from Henri first. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDE Geolocation Services
On Thursday, November 04, 2010 16:56:54 Kevin Krammer wrote: > On Thursday, 2010-11-04, Sebastian Kügler wrote: > > On Thursday, November 04, 2010 16:04:33 John Layt wrote: > > > Which kind-of makes the whole GConf usage moot? > > > > No, it doesn't. If that stuff is still needed for actually using it, > > we're still effectively depending on whateverlibgconfisin, and that, as > > Aaron points out would be rather unfortunate. > > We don't get any additional dependency, nor do we have to track them. A runtime dependency is still a dependency. I find the attitude of "as long as it's not a buildtime dependency" pretty short-sighted. > It is a system service like NetworkManager, Samba, CUPS, etc. If people > don't want it, they don't install it. > If they want to use a different implementation due to personal politcal > agenda against the other implementation's choice of technology, they are > free to do so. However you turn my words around, a geoclue that does not depend on gconf is preferable to a geoclue that does. Realistically, distros will have to put geoclue as a dependency in order to make the geolocation API useful, and that will pull in libs that are duplicating what we already have in kdelibs -- clearly not desirable as it makes our software fatter without real gain. Apart from that, maybe the geoclue DBus API is not meant as "public API", in that case I'd recommend using the C library. In fact: whatever is likely to remain more stable should be used. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Feature Plan for 4.7
Hi all, In order to create good release notes for the next release (yes, we're early), we need a good overview of new features and improvements. Traditionally, we keep a list on techbase, which we then base the release notes on. That list can be found at: http://techbase.kde.org/Schedules/KDE4/4.7_Feature_Plan We do need some help here from everybody -- kde-promo people are awesome, but not omnisavant (is that a word, even?). So please go ahead and edit the feature plan above: - add features you're planning to work on (also helps coordination with others) - also add important bugfixes (it's easier to have them in one place), but only if you're not backporting them (otherwise they're not new in 4.7). In that case, add them to the relevant XML changelog - remove those that are done for <=4.7 - remove those that will never get done, or fell of the table completely - update the status of items you know of - keep the message human-understandable, it's not a personal scratchpad, but others need to know what you're talking about - bonus points if you add a link to further information, such as a blog entry - if you doubt if something's interesting enough, put it in anyway. It's way easier to just skip an entry than to miss out on something cool. (We developers tend to err on the side of "less cool" rather than "ow wow, this kicks some serious ass" - Do edit it and add your plans, you can always change something later if it doesn't work out as you planned and nobody will come after you with sticks, stones, or the Wrath of the Release Manager Thanks everybody for the assistance! It will pay off by having good and complete release notes. Thanks for the attention :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Feature Plan for 4.7
On Thursday, January 27, 2011 12:05:34 Nikos Chantziaras wrote: > On 01/27/2011 12:18 PM, Sebastian Kügler wrote: > > In order to create good release notes for the next release (yes, we're > > early), we need a good overview of new features and improvements. > > I'm just a user, but how about focusing on making what you have achieved > already as rock-solid and stable as possible, fixing all glitches, bugs > and annoyances, and then thinking about adding more features? We do that all the time. (You saw that coming, no?) This email was not meant as an invitation to suggest to developers what you want them to work on (for that, we have wishlist items on bugzilla and the brainstorm section on the KDE forums), but as coordination tool among developers and between developers and the promo team. If you feel that KDE should be fixing more bugs, you're very welcome to join our bugsquad and help in that process. (You do not need to be a coder for that, but it makes a big difference.) In any case, please don't hi-jack a thread in order to promote your personal agenda. That's neither respectful to those spending their time on KDE software, nor does it scale. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request: Add support for building libplasma with GLES2
On Friday, February 25, 2011 04:29:36 Jammy Zhou wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/100705/ > --- > Update the patch to remove direct OpenGL dependency for libplasma. The > OpenGL usage in libplasma should better go through libQtOpenGL,which can > be enabled for desktop OpenGL or OpenGL ES2.0 > > Summary > --- > > After build kwin with GLES2 code path, the kwin binary still has dependency > on libGL.so, which is introduced by libplasma.so. Then we also need to add > GLES2 support to libplasma, so that kwin/plasma only has dependency on > libGLESv2.so in this case. > > The new option "BUILD_PLASMA_WITH_OPENGLES" added in attached patch is > disabled by default, and distributions can turn it on when do packaging > for OpenGL ES2.0 support. Shouldn't that option cover both, kwin and plasma? Or are there serious cases where you'd want one, but not the other on opengl-es? If not, let's merge them to prevent building and packaging headaches. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request: Add a GUI to configure window's title bar blend colours
On Tuesday, March 08, 2011 13:18:25 Jonathan Marten wrote: > http://git.reviewboard.kde.org/r/100821/ > Some of the still available window decorations (KDE2, Keramik, Modern > System, Quartz, Redmond) use two colours for the title bar, either as a > blend or for different parts of the bar. This patch extends the GUI in > System Settings to allow the blend colour to be configured. > > This addresses bug 225837. > http://bugs.kde.org/show_bug.cgi?id=225837 Please provide a screenshot with review requests that change UI. Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
new kdevelop sessions runner for review
Hi all, I've just committed a branch of kdeplasma-addons containing a new runner plugin. It reads kdevelop sessions and makes them available via their name to krunner. You just pull up krunner, enter your session name, and start it. The code is adapted from the kate session runner, also in kdeplasma-addons. The code is in kde:kdeplasma-addons in abranch sebas/kdevelopsessions, and up on RB at https://git.reviewboard.kde.org/r/100903/ Thanks for your kind review :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 --- Begin Message --- --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100903/ --- Review request for Plasma. Summary --- New KRunner plugin listing kdevelop sessions. Based on the same code for kate, only changed the reading of the sessions. Diffs - runners/CMakeLists.txt 7bcb05f runners/kdevelopsessions/CMakeLists.txt PRE-CREATION runners/kdevelopsessions/Messages.sh PRE-CREATION runners/kdevelopsessions/README PRE-CREATION runners/kdevelopsessions/kdevelopsessions.cpp PRE-CREATION runners/kdevelopsessions/kdevelopsessions.desktop PRE-CREATION runners/kdevelopsessions/kdevelopsessions.h PRE-CREATION Diff: http://git.reviewboard.kde.org/r/100903/diff Testing --- Started different sessions of kdevelop from KRunner, works just fine. Thanks, Sebastian --- End Message ---
Re: new kdevelop sessions runner for review
Hej, On Monday, March 21, 2011 14:16:37 Pino Toscano wrote: > Alle lunedì 21 marzo 2011, Sebastian Kügler ha scritto: > > I've just committed a branch of kdeplasma-addons containing a new > > runner plugin. It reads kdevelop sessions and makes them available > > via their name to krunner. You just pull up krunner, enter your > > session name, and start it. > > Shouldn't this be shipped aside kdevelop, instead of kdeplasma-addons? > I see various reasons for this: > a) a normal user has no use for it > b) even a developer would not have much to do with it if not installing > kdevelop (hence kdevelop could just ship it) > c) it manually parses the kdevelop session files and watches for their > changes, so if in the future kdevelop changes its storage of sessions, > this runner would break (while having it shipped with kdevelop would > allow it to be always up-to-date with it, independently from the KDE SC > version) All valid points, I'm fine if the kdevelop developers would want to ship this runner as part of kdevelop. What do you think? > Aside from those, I've left some review in RB. I'll address those, thanks for taking the time to look at the code! -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Season of KDE project on speed optimization
On Friday, April 29, 2011 14:55:01 Markus Slopianka wrote: > Am Freitag 29 April 2011, 12:52:18 schrieb Lydia Pintscher: > > Aaditya applied for a Season of KDE slot. He wants to work on speed > > optimization. Do we have a nice project for him? > > Depends what he finds slow. > A possibility would be to either help the Platform modulation effort to cut > down dependencies (if helping hands are still needed there). > Another could be to reduce the number of dependencies that are loaded during > startup (if he finds startup slow). > A third possibility would be to utilize kdelibs-mobile for desktop use and > maybe work downstream in OBS to offer a SC based on kdelibs-mobile. Profiles are not meant to be used that way. They're cutting out features that might already be on a given platform or don't make sense for mobile and embedded use cases at all, but these features are still needed by many applications. There is no magic silver bullet :) That said, I think startup performance would be a very nice project, with high impact. The way to go here would to use bootchart and a profiler to find out where most of the time is spent, and then making that code faster. Should be quite fun :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Upcoming freezes KDE 4.7
Hi, On Tuesday, May 10, 2011 17:17:04 Allen Winter wrote: > I'm not so sure that this is a new feature -- more like an improvement to an > existing feature. > > BTW: exception requests should be sent to the Release Team (who I've CC'd) > > Speaking as a Release Team member, I have no problem with your exception > request. More problematic would be the need for new translatable strings > past the string freeze. So you may also need to coordinate with the > translators. Yep, if it contains new strings, translators would need notification of the new strings. If it's getting too close to release time, it would be good to ask if there are problems with the translations then. > On Tuesday, May 10, 2011 01:49:01 pm Dawit A wrote: > > The KDE 4.7 Hard Freeze date is still a couple of days away, but I am > > going to ask for an exception. I have pending UI changes for the proxy > > configuration dialog that will not make that date and it cannot be > > pushed until 4.8. This item is already on the features list, but I get > > held up fixing rather critical bugs and was not able to get around to > > completing it. It is critical that these changes be in the 4.7 ; so I > > am asking for an exception. They should be in place for the Beta 2 > > tagging... I also do not see a problem with that. Just to get a better understanding, why are these changes important? Thanks for working on this, btw. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
The Future of our Frameworks
Hi all, You've probably been aware that a rather sizable group of KDE developers and stakeholders in our development platform is meeting in Randa, Switzerland to discuss the future of our development frameworks, with the big topic being "modularization of kdelibs". We've had a number of great discussions here about various technical and process-related topics. We are still in the process of making the results digestable, transforming our notes into something that is understandable for those that haven't been able to participate in these -- very productive -- sessions in person. Let me already give you some information on the bigger picture we came up with here, as you are all probably very curious about that. The overall theme was the modularization of kdelibs, kde-runtime, kdepimlibs, kdepim-runtine and kdesupport. With Qt5 -- a change in binary interface -- having been announced, it is a good point in time to introduce some changes to our frameworks that are only possible if we change the ABI -- which Qt5 will do for us anyway. What is the scope? Instead of Platform, we want to consistently use the term "Frameworks", this includes what we currently refer to as kdelibs, kdepimlibs, kde-runtime, kdepim-runtime and kdesupport. We explicitely are not talking about our apps and workspaces, but read on. What do we want to achieve, and why? We want to make it possible to use our frameworks in Qt projects without significant additional dependencies. This means: * We reach out to the Qt development community in a more focused way * We make it easier to use our frameworks * We lower the barrier for contributions * We make our frameworks more suitable for mobile and device-spectrum use cases * We make it possible to select a specific set of features developers would like to use * We improve our QA processes, leading to better quality apps and frameworks We want this to happen with ... * ... no disruption for our users * ... little to no source incompatibilities * ... most apps not needing any significant changes * ... changes, if at all necessary being kept to a minimum What does it mean for users? * No disruption * Most probably invisible * Short term: Iit becomes easier to run kDE apps outside of the Plasma workspaces, including other operating systems * Longer term: We will probably see more apps using KDE technology What does it mean for developers? * We will maintain source compabitility as much as possible * The impact for existing apps will be minimal * We will provide a compabitility library as additional measure to reduce the impact of these changes What does it mean for packagers? * We make it possible to ship our frameworks in a more modular way * We also plan to provide "monolithic tarballs" much as we do now, depending on the needs and preferences of downstreams Please note that this is *not* KDE5, as it doesn't refer to our community, but about our development frameworks. At this point there is also no benefit in talking about KDE 5, since that just opens the door to misinformation. This is also clearly not about our workspaces, or applications. (See http://vizzzion.org/blog/2011/06/there-is-no-kde5/ for a quick explanation.) In order to prevent this thread from growing into an unmanageable load of hundreds of emails, please post specific questions as separate threads. (You can of course reply with praise to this, but anything that is likely to spark a more detailed discussion is probably better off in a separate thread.) Thanks for your attention, and cheers from a wonderful Switzerland, -- sebas, on behalf of the KDE Frameworks team http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Releases of the thing that was KDE
Hi Scott, On Tuesday, June 07, 2011 03:13:43 Scott Kitterman wrote: > It may be that there was more to the release implications of the git > transition than "we're sure it'll get figured out by people who actually > care about releases", but if there was it's not apparent to me. I don't think there was, which lead to the screw-ups. It is something we took as a central issue into the discussions during the platform11 sprint, so at least we learnt from that. The short answer to your question is: We will also release backwards- compabitle, monolithic tarballs. That process can largely be automated on our side. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KDM plans and lightDM
Hi Alex, On Monday, June 13, 2011 21:10:36 Alex Fiestas wrote: > Today something happened to me again, I turn on my laptop at the begining of > a meeting and when I needed it the battery was over because the laptop > didn't went to suspension (as I'm used). > > That makes me wonder what are the plans for KDM in this and other regards > since I haven't seen much activity on it (apart from bugfixing). > > Also, since the last Ubuntu Development Summit I started to look into > lightDM[1] as a possible alternative (at least for my use), I event managed > to patch kdisplaymanager.cpp to play nice with it. > > I'm not an expert on Display Managers so I can't really tell if lightDM is > good enough (or will be good enough) to replace KDM. When I asked to some > distribution people the first thing they told me is: "Does it support > XDMCP?" and I don't know even what XDMCP is... > > So, what are the plans for KDM? can we expect some power management > integration? and plymouth? > > For the experts: Does lightDM feel nice as a cross-desktop solution? is it > good enough? I don't think it's a solution to the problem. LightDM doesn't have any integration with powermanagement agents, so it doesn't solve the problem. Goes a bit like this: - "Hm, KDM doesn't have power management support" - "Let's think about LightDM then!" - "LightDM doesn't have it either" I think it's nice that someone's working on a replacement, but it seems to be kind of chicken-headed. What are the problems with KDM right now? 1 bit arcane UI, litlle themes 2 takes long to start 3 no PM integration 4 no touch input support (Note that the above comes from the top of my head, possibly you can do even one or more, but the default roughly looks like the above. Correct me if I'm wrong, please.) I think lightdm solves (2), but does so by cutting features, features which we probably need (some asked for XDMCP as an example). So lightDM might be useful for a specific situation where you need only the feature set that lightDM offers, On the other hand, KDM is rock-stable, secure and maintained. It's not shiny, and hasn't been built with "devices" in mind. As a result, I'm quite skeptical. But let code decide, not assumptions. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request: [PATCH] Change HTML thumbnail generator to use kdewebkit to fix bug 248478
On Friday, June 03, 2011 20:53:43 Dawit A wrote: > Do you have any plans for pushing this into git master/KDE 4.6 branch > ? Either your patch or mine needs to make it into KDE 4.7. I'd prefer Dawit's patch, since it will also work with the leaner mobile build profile, and HTML thumbnail generation is especially useful (and wanted) in those cases. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request: Add a FindQtMobility.cmake file
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101568/#review3926 --- Ship it! I'm obviously fine with it, once the changes Alex suggested are in, please ship it :) - Sebastian On June 10, 2011, 7:18 p.m., Arjen Hiemstra wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101568/ > --- > > (Updated June 10, 2011, 7:18 p.m.) > > > Review request for kdelibs and Sebastian Kügler. > > > Summary > --- > > As requested by Sebas, this patch adds a FindQtMobililty.cmake that can be > used to find QtMobility related files. It has support for minimum versions > and searching for individual components. > > > Diffs > - > > cmake/modules-tests/QtMobility/CMakeLists.txt PRE-CREATION > cmake/modules/FindQtMobility.cmake PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/101568/diff > > > Testing > --- > > There is a simple testcase included. Furthermore I have tested the minimum > version and component related options with a local test file. > > > Thanks, > > Arjen > >
Re: Review Request: Make “No multiscreen configuration” message prettier
On Thursday, June 30, 2011 19:48:08 Kai Uwe Broulik wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101810/ > --- > > Review request for KDE Base Apps. > > Summary > --- > > I always found Bluedevil’s notifications so nice, so I patched the Multi > monitor configuration KCM to use something similar to indicate that this > configuration is not available on the respective machine. > > Comparison screenshot: http://privat.broulik.de/xineramapatch.png This warning only applies to Xinerama setups (one Screen (in the X sense)) across multiple monitors. So just calling it "multiple monitor setup" is wrong in at least some case. (I don't think that Plasma does support this case, though, which is I think one X server per physical display. Also, I'm not sure about the (i) icon, shouldn't that be a warning, or something like that? The layout (huge icon, small text underneath) also looks a bit non-standard to me. In KDialog, they're next to each other, no? I agree that the warning could be improved, but the new implementation is IMO not a lot better, just exposes a different set of problems. Maybe the term "Xinerama" should even be used in this message, as it makes finding a solution on the web a lot easier. Otherwise people would go "WTF, there's definitely two monitors attached!" and assume a bug in software, not the exact configuration difference this message is pointing at. I know Aurelien has done some good work lately on error messages, maybe he could weigh in here (though it's a different usage scenario here). Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: My Plans, Your Plans: Berlin Desktop Summit
On Wednesday, July 27, 2011 15:40:11 Aaron J. Seigo wrote: > so .. here are my primary goals: [...] One of my goals is to take steps to make the release team more scalable, and reduce its bus numbers. While we really bring out a lot of release, and nearly all of them in time as planned, I think we need to work on two things: * Make Dirk and me replacable -- we have no plans to stop with release team duties, but since it's such a critical task, and ever getting bigger, we need more people we can fall back onto. * The Git migration wasn't exactly a walk in the park, there was lots of last- minute futzing, not everything was clear and I think we put more work than necessary onto various downstreams by changing layout of our tarballs I think overall we're doing pretty well, just that we can do better here and there. > * have an enjoyable time with everyone who shows up :) ...and that. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: My Plans, Your Plans: Berlin Desktop Summit
On Thursday, July 28, 2011 00:54:50 Nicolas Alvarez wrote: > Sebastian Kügler wrote: > > One of my goals is to take steps to make the release team more scalable, > > and reduce its bus numbers. > > Surely you mean increase :) A bus number of 1 means the team has a single > point of failure. Ah, yes of course. Increase bus number, reduce risk. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KWallet/KSecretsService & GIT workflow
Hi Valentino, On Monday, August 01, 2011 17:13:18 Valentin Rusu wrote: > KSecretsService API is now nearing the finished state. But this would be > confirmed by starting using it as a KWallet API backend. Naturally, I'll > do this on my system but I'd like to do it such that: Very cool :-) > One more component should be the KWallet backend, an implementation of > the current KWallet class based on the new "Client API". KWallet code is > actually spread inside several GIT repositories: kdelibs, kdeutils and > kde-runtime. I think that I should do a branch named "ksecretsservice" > inside each of these repositories, then start using the new "Client API" > and do the switch to the new infrastructure. When this might become > "showable", I might push these branches to each of thses repositories, > along with an appropriate announcement to this list. > > Any thoughts about this process? How does it fit with current kdelibs > modularization process? How would the switch work, is it runtime-choosable, compile-time, or do you need to change the code from kwallet to ksecretservice, so there's not other means to go back, short of reverting? This question does affect how we introduce ksecretservice all over KDE. Cheer, and thanks for your work on ksecretservice! -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: KWallet/KSecretsService & GIT workflow
Thanks, Valentin. That answers all my questions. It sounds like a decent migration strategy. :) On Thursday, August 04, 2011 12:17:36 Valentin Rusu wrote: > On 08/04/2011 09:51 AM, Sebastian Kügler wrote: > > Hi Valentino, > > > > [snip] > > Cheer, and thanks for your work on ksecretservice! > > Welcome :-) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: git workflow draft
On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote: > >> Was this decided upon at some point? I got conflicting stories from > >> sysadmin and other developers. Yesterday after migrating > >> kdeaccessibility to git I was asked by a sysadmin to rename the X.Y > >> branches to KDE/X.Y I think concensus and consistency are important > >> here. Was there a decision that the official branches should be named > >> X.Y? > > > > My vote goes to "KDE/X.Y", it is clearer what it means. > > When the frameworks get split out into multiple repos, will they still use > branch names KDE/5.0? What will that mean? Or will we come up with another > scheme then? I think they should, here's my reasoning: The KDE part of the branch name means it's our "official" branch, i.e. it's done by KDE (not by individuals acting on their own), so basically our official namespace. We use $name/feature elsewhere, and I think KDE/5.37 would blend in nicely here. On top of that, it gives some continuity. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: QML support in kde.org services
On Sunday, September 04, 2011 14:18:30 Stefan Majewsky wrote: > By the way, the immediate issue I'm having is that I would like to > have a look at the implementation of the org.kde.kdewebkit.WebView > element, but I cannot find it. Can someone point me, please? That's kdeclarativewebview.* in plasma-mobile/applications/webbrowser/src Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Cursor Theme Settings
On Wednesday, September 07, 2011 17:08:36 Steven Sroka wrote: > Where are the cursor theme settings saved in KDE as well as the > wallpaper slideshow settings? kcminputrc and plasma-desktop-appletsrc. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Proposal to use QIcon in APIs in KF5.
On Thursday, September 08, 2011 09:17:00 Jaime wrote: > We should assume that Qt5 will have some kind of global icon cache, > valid for every Qt application run in one machine, like KIcon has now. > Am I Right? Per application, it seems. That's probably still a bit behind KIcon's KSharedDataCache (which works across processes), but I don't really know the details here. > Then, without removing KIcon, it could be a thin layer (~1Kb) over > QIcon. Why do not call QIcon::fromTheme() in KIcon constructors, and > then nothing changes in the KDE land. I think that's the idea of kde4support. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Cursor Theme Settings
On Wednesday, September 07, 2011 19:04:39 Steven Sroka wrote: > >On 7 September 2011 12:49, Steven Sroka wrote: > >>On 7 September 2011 11:22, Sebastian Kügler wrote: > >> On Wednesday, September 07, 2011 17:08:36 Steven Sroka wrote: > >>> Where are the cursor theme settings saved in KDE as well as the > >>> wallpaper slideshow settings? > >> > >> kcminputrc and plasma-desktop-appletsrc. > > For the slideshow settings, I only found plasma-desktoprc which > doesn't contain the time settings. Could it be listed elsewhere? Wallpapers are per containment, and those settings are in plasma-desktop- appletsrc. Not sure why you don't have this file, maybe you didn't change any of its setup? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
