Re: KSvg in kdereview

[Marco Martin]

I fixed CI, passes now

On Tue, Jun 20, 2023 at 8:44 PM Ben Cooksley  wrote:
>
> Hi all,
>
> Sysadmin has just received a request to move this repository to Frameworks, 
> however after seeing some of the comments raised here regarding the 
> repository I took a look myself to see if they had been corrected.
>
> At this time CI is still broken in KSvg, for both platforms - something that 
> was mentioned in an earlier email here.
> This does not inspire confidence that the code is up to scratch.
>
> I've therefore declined to move it to Frameworks at this time.
>
> Would be appreciated, given this is looking to be promoted to Frameworks, if 
> people could please have a further look at this repository and comment as 
> appropriate.
>
> Thanks,
> Ben
>
> On Wed, Jun 14, 2023 at 9:12 PM Marco Martin  wrote:
>>
>> Hi all,
>> Some time has passes, and changes have been done in the repo to
>> address some of the points.
>> Now there are review requests in plasma-framework which depends on
>> this repo (and accompanying plasma-workspace, plasma-desktop etc)
>> It would probably be better to have this in frameworks to have the
>> rest depending from it?
>>
>> On Thu, Apr 20, 2023 at 10:25 AM Marco Martin  wrote:
>> >
>> > Hi all,
>> > A part of plasma-framewrok, which is the one to do SVG-based themes,
>> > has now been splitted in a standalone library which is intended to be
>> > a new framework in KF6 (all usages of the plasma-framework version
>> > will be ported once this officially lands, and then those classes will
>> > be removed)
>> > The repo for now lives in
>> > https://invent.kde.org/libraries/plasmasvg
>> >
>> > In the end it will be renamed in ksvg
>> >
>> > Comments? reviews?
>> >
>> >
>> > --
>> > Marco Martin
>>
>> --
>> Marco Martin

Re: KSvg in kdereview

[Marco Martin]

Hi all,
Some time has passes, and changes have been done in the repo to
address some of the points.
Now there are review requests in plasma-framework which depends on
this repo (and accompanying plasma-workspace, plasma-desktop etc)
It would probably be better to have this in frameworks to have the
rest depending from it?

On Thu, Apr 20, 2023 at 10:25 AM Marco Martin  wrote:
>
> Hi all,
> A part of plasma-framewrok, which is the one to do SVG-based themes,
> has now been splitted in a standalone library which is intended to be
> a new framework in KF6 (all usages of the plasma-framework version
> will be ported once this officially lands, and then those classes will
> be removed)
> The repo for now lives in
> https://invent.kde.org/libraries/plasmasvg
>
> In the end it will be renamed in ksvg
>
> Comments? reviews?
>
>
> --
> Marco Martin

-- 
Marco Martin

Re: KSvg in kdereview

[Marco Martin]

On Fri, May 12, 2023 at 3:41 PM Friedrich W. H. Kossebau
 wrote:
> Did some small fixes (library e.g. was installed with literal ".SOVERSION" as
> suffix...), but the more I did and more I saw... IMHO this should not have yet
> been passed to kdereview, being in alpha state for my taste.

ouch, sorry :/ and thanks
one thing that will make the landing even longer is that at the plasma
sprint we decided it was the case
 for making it depend from a new (also not yet landed) framework (the
new home for KColorScheme) so
it will still take more time.

> E.g. "TODO KF6" ideally would not be handled during the review phase, but
> before.

there was still one todo kf6 which after some tought and discussion
was then removed
as doing that it would cause a regression in themes we don't want.

> And the README and other docs not (yet) mentioning what the scope & purpose of
> the library, but being dead copies from Plasma Framwworks also makes things
> harder to assess.

ok, i'll write a more comprehensive introduction there

> Builds on CI all failing ever since and before also looks a bit unattractive.
> Currently still with FreeBSD.

fixed it now

> For the name, "KSvg" sounds very unspecifc to me, ideally the name would
> reflect the purpose & scope of the library some more (but then that is not
> defined somewhere also, so... ;) ). Something with SVG, but what exactly?
> Perhaps "KSvgTheme" (proposed by Sune on irc) or similar might make it more
> clear?

I'm not sure, compared to the plasma version the "theming" part has
been scaled down a bit
(so that the "theme" class becaume "imageset" as most of the
kcolorscheme wrapping api is gone)
I'm not opposed to changing the name again, but not sure what other
names could actually be more clear.
so, basically the things that does over qsvg (the why for using qtsvg
not directly) are:

* disk caching of the rendered pixmaps to have things faster
* stylesheet based recoloring
* the fact that svgs can come in bundles (the theming part, tough is
not the main thing, so i would not give the name of the whole library
after that)
* the 9 patch framesvg for doing rectangular things
* qml bindings

> Also using "KSvg" as namespace results in class names like KSvg::;Svg,
> KSvg::SvgItem, etc. which looks a bit strange to my eyes on consumer side due
> to the duplication. In my perfect world the naming would see some overhaul
> given this is a new library. Yes, some one-time porting pain, but sanity
> afterwards, for a certain type of sustainability ;)

one thing is that the library is really about svgs and nothing else,
and the Svg class is about rendering one single svg,
so I don't see many ways around about both contianing "svg" ? (I was
aware there was an old kde3 ksvg library,
 though talking about it in some tuesday meeting didn't seem to be an issue)
Open to ideas :)

-- 
Marco Martin

Re: KSvg in kdereview

[Marco Martin]

On Sun, Apr 23, 2023 at 11:05 AM Albert Astals Cid  wrote:
> > Comments? reviews?
>
> There's a few "TODO KF6" in the code, should those be addressed?

ok, I'll go over all of them in the review period

> Is the plan to make it less plasma-specific with the rename?
>
> i.e. the ImageSet constructor says
>
> Default constructor. It will be the global theme configured in plasmarc
>
> Is that wanted or not (i've no opinion, just asking to make sure since the
> rename seems to want to make it "less plasma").

hm, it looks like there is still some stray documentation which
doesn't completely  reflect truth anymore
(right now it doesn't use that config file anymore, it's up tp the
user's code) will correct

-- 
Marco Martin

KSvg in kdereview

[Marco Martin]

Hi all,
A part of plasma-framewrok, which is the one to do SVG-based themes,
has now been splitted in a standalone library which is intended to be
a new framework in KF6 (all usages of the plasma-framework version
will be ported once this officially lands, and then those classes will
be removed)
The repo for now lives in
https://invent.kde.org/libraries/plasmasvg

In the end it will be renamed in ksvg

Comments? reviews?


-- 
Marco Martin

Re: Plasma Bigscreen in Kdereview

[Marco Martin]

On Mon, Jan 25, 2021 at 10:51 PM Albert Astals Cid  wrote:

> > like all those in plasma-desktop do as well
>
>   kcms/audio-device-chooser/CMakeLists.txt:25 (kpackage_install_package)
>   kcms/wifi/CMakeLists.txt:25 (kpackage_install_package)
>   kcms/kdeconnect/CMakeLists.txt:25 (kpackage_install_package)

yes, is exactly like kcms in plasma-desktop, where all the package
names are all library name, so kcm_foo i would prefer to keep that
consistent with those? (then, is definitely possible to do
kcm_org.kde.foo ir required, for both package and library)

--
Marco Martin

Re: Plasma Bigscreen in Kdereview

[Marco Martin]

On Sun, Jan 24, 2021 at 10:19 PM Albert Astals Cid  wrote:
>
> > we just converted license headers to SPDX, the code should be in
> > fairly good shape by now
>
> The ATTRIBUTION file on the root feels like it would need some qualification 
> over to which files it applies.
>
> There's a few
>  KPackage components should be specified in reverse domain notation.
> on cmake time, not sure how bad those are.

What are those that are not ok? i can only see it in kcms, which need
to have same package name as the kcm library name, so usually kcm_foo
like all those in plasma-desktop do as well

> Your cmake deps says you support Qt 5.9, but your QML imports say otherwise. 
> Given that you seem to require Plasma 5.19, I would suggest to increase your 
> cmake/KF5/Qt5 deps to that of what Plasma 5.19 requires.
>
> files in ./kcms/plasma-settings-shell have i18n calls but as far as I can see 
> not included in any Message.sh

those are fixed

> files in ./shell/contents/configuration have i18n calls but as far as I can 
> see not included in any Message.sh

those are "special" and can't really be translatable, but none of
those qml files have strings anymore

-- 
Marco Martin

Re: Plasma Bigscreen in Kdereview

[Marco Martin]

On Fri, Jan 22, 2021 at 12:38 PM Yuri Chornoivan  wrote:
>
> пʼятниця, 22 січня 2021 р. 12:48:07 EET Marco Martin написано:
> > Hi all,
> > We would like a release of the Plasma Bigscreen project
> > which has been moved to kdereview, its repo is:
> > https://invent.kde.org/plasma/plasma-bigscreen
> >
> > It's a Plasma shell intended to use on smart tv kind of devices (ideal
> > is a setup like a raspberry pi4 attached to a tv) It's pretty much a
> > big tiles grid launcher for apps (which can be media-related apps,
> > clients for streaming services and what not)
> > It is also integrated with the Mycroft voice assistant open source
> > project, so supports voice commands and some apps like the youtube
> > client are done as internal mycroft skills.
> >
> > we just converted license headers to SPDX, the code should be in
> > fairly good shape by now
>
> Hi,
>
> 1. Translatable messages from /shell and /kcms/plasma-settings-shell are not
> extracted (no Messages.sh).

that should be fixed for shell. /kcms/plasma-settings-shell actually
can't be extracted (is going to be installed inside another package
and going to use the same domain of this other thing. in the end there
was a single message that wasn't even shown, so removed the message
and the whole folder shouldn't have any user visible labels now.

> 2. i18nd() usage in QMLs is at least inconsistent.

now the pieces that do need a domain to be translatable should include
the correct one.



-- 
Marco Martin

Plasma Bigscreen in Kdereview

[Marco Martin]

Hi all,
We would like a release of the Plasma Bigscreen project
which has been moved to kdereview, its repo is:
https://invent.kde.org/plasma/plasma-bigscreen

It's a Plasma shell intended to use on smart tv kind of devices (ideal
is a setup like a raspberry pi4 attached to a tv) It's pretty much a
big tiles grid launcher for apps (which can be media-related apps,
clients for streaming services and what not)
It is also integrated with the Mycroft voice assistant open source
project, so supports voice commands and some apps like the youtube
client are done as internal mycroft skills.

we just converted license headers to SPDX, the code should be in
fairly good shape by now

-- 
Marco Martin

Re: KDE Frameworks 5.58.0 released

[Marco Martin]

On martedì 14 maggio 2019 11:52:53 CEST Marco Martin wrote:
> On Mon, May 13, 2019 at 9:50 PM David Faure  wrote:
> > 13th May 2019. KDE today announces the release of KDE Frameworks 5.58.0.
> 
> Hi, unfortunately there was a regression in gethotnewstuff, making
> installation fail for several types (look and feel themes, plasma
> themes and possibly some others)

Sorry David,
unfortunately after some user report it turns out the fix that got in 5.58.1 
for frameworkintegration wasn't actually covering all cases (and now old 
plasma workspace with new frameworks has gethotnewstuff broken again)
the last commit
134d1ebd0e8ebe74496c43697741fea79fb25933
now fixes the situation for both plasma workspace 5.15 and prior and 5.16
It would be needed (ouch) a 5.58.2 for frameworkintegration

-- 
Marco Martin

Re: KDE Frameworks 5.58.0 released

[Marco Martin]

On Mon, May 13, 2019 at 9:50 PM David Faure  wrote:
>
> 13th May 2019. KDE today announces the release of KDE Frameworks 5.58.0.
Hi, unfortunately there was a regression in gethotnewstuff, making
installation fail for several types (look and feel themes, plasma
themes and possibly some others)
It has been fixed yesterday, but unfortunately too late to make it
into the release.
The repo is frameworkintegration and the commit is
e0df1f28231c54d0f92213b2a62428df578e581a

--
Marco Martin

Re: liquidshell in kdereview

[Marco Martin]

On Fri, Mar 15, 2019 at 7:59 AM Ivan Čukić  wrote:
> Anyhow, while I do find it strange to market a non-feature in the features
> list, I don't have anything against it.

I have a bit of a problem about putting doesn't use activities as a
feature, because it's a bit confrontational towards other KDE products
(and as you point out, often not 100% true as kactivitymanagerd will
be very probably started anyways)
That said, i don't have problems of having a competing shell as a KDE
project, choice is usually good.

Marco Martin

Adding Kirigami Gallery to kde-sdk

[Marco Martin]

Hi all,
in the kirigami framework repo, there is a little gallery application which 
outgrew the point of being a small example.
It's now becoming a tutorial app: on each page an example and documentation on 
how to use a particular component and when with links on the relevant source 
code and HIG page about  such component (if available) becoming a developing 
aide while writing a Kirigami application.

Also, since it's planned to add more graphics and heavy media files, makes it 
not particularly ideal to still use the framework repository.
If no objections, it will be moved as a standalone repo as part of kde-sdk as 
developing aide.

-- 
Marco Martin

Re: KDE and Google Summer of Code 2018

[Marco Martin]

On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham <pointedst...@zoho.com> wrote:
> I've submitted an idea for System Settings: Improve handling for touchpads
> and mice with Libinput

Speaking of systemsettings, would be a good fit porting to qml some
medium-to-big kcm?
--
Marco Martin

Re: Plasma-Mycroft is in kdereview

[Marco Martin]

On mercoledì 17 gennaio 2018 06:46:16 CET Aditya Mehra wrote:
> Hi all,
> 
> Plasma-Mycroft has been in KDE review over a month, there have been a few
> additions and bug fixes to the plasmoid but nothing major, all fixes have
> also been made to the build system which were mentioned by Christophe
> Giboudeaux, I am hoping plasma-mycroft can complete its review soon as I am
> looking forward to making a stable release. As there haven't also been any
> other objections currently can this review process move ahead / moved to
> extra gears.

 +1

-- 
Marco Martin

Re: Plasma-Mycroft is in kdereview

[Marco Martin]

On martedì 5 dicembre 2017 08:52:18 CET Aditya Mehra wrote:
> Hi all,
> 
> This is a request email for the review process of the mycroft plasmoid, the
> plasma-mycroft project has been moved to kdereview
> 
> The repository url: https://cgit.kde.org/plasma-mycroft.git/

I have no objections about this moving forward

-- 
Marco Martin

Re: qqc2-desktop-style as framework

[Marco Martin]

On Fri, Sep 1, 2017 at 3:02 PM, Marco Martin <notm...@gmail.com> wrote:
> On Thu, Aug 31, 2017 at 5:06 PM, Marco Martin <notm...@gmail.com> wrote:
>> any objection into pulling it into a framework? anything particular for the
>> procedure?
>
> as an update to that, i've update its cmake files and metadata files
> to be coherent with other frameworks, at this point i'll wait a couple
> of weeks if there are complaints, then if not it can be merged in
> frameworks? ideal would be aiming for october release

any update on this? is there anything i have to change there?

--
Marco Martin

Re: qqc2-desktop-style as framework

[Marco Martin]

On Thu, Aug 31, 2017 at 5:06 PM, Marco Martin <notm...@gmail.com> wrote:
> any objection into pulling it into a framework? anything particular for the
> procedure?

as an update to that, i've update its cmake files and metadata files
to be coherent with other frameworks, at this point i'll wait a couple
of weeks if there are complaints, then if not it can be merged in
frameworks? ideal would be aiming for october release

--
Marco Martin

Re: Kirigami in Frameworks

[Marco Martin]

On Wed, Jun 21, 2017 at 6:22 PM, Jonathan Riddell <j...@jriddell.org> wrote:
> On 21 June 2017 at 15:00, Marco Martin <notm...@gmail.com> wrote:
>> As there were no replies for quite a while, i assume there are no
>> particular objections.
>>
>> so, how to proceed? what needs to be doe to do the actual move?
>
> Does it comply with the policies (as much as they are relevant for QML)?
> https://community.kde.org/Frameworks/Policies

yeah, it should for pretty much all rules

> Get David Faure to give his approval then see what the reponse to my
> "who is authorised to move repos around?" thead is.
> https://marc.info/?l=kde-core-devel=149806172721190=2



ok, waiting David's comment on it.

--
Marco Martin

Re: Kirigami in Frameworks

[Marco Martin]

As there were no replies for quite a while, i assume there are no
particular objections.

so, how to proceed? what needs to be doe to do the actual move?

On Mon, Jun 5, 2017 at 2:42 PM, Marco Martin <notm...@gmail.com> wrote:
> Hi all,
> The Kirigami component set always was targeted to be eventually released as a
> framework, ideally tier 1. since a framework must depend at most from 2 Qt
> releases before the current one, it couldn't be released there yet.
> Now that Qt 5.9 is released, i would like to propose to move Kirigami in
> frameworks, to be relased in the main release cycle, and stop standalone
> releases from extragear.
>
> It strictly depends just from Qt stuff, so should be tier 1 (at runtime it can
> use optional styles that use features from Plasma, tough not having plasma
> installed doesn't touch its functionality in any part, if this ends up being a
> problem, i can move that style into plasma-integration)
>
> --
> Marco Martin

Re: kdereview: qqc2-desktop-style

[Marco Martin]

On Thu, May 18, 2017 at 11:08 AM, Marco Martin <notm...@gmail.com> wrote:
> Hi all,
> I'm anouncing the QtQuickControls2 desktop style in kdereview, repo name is
> qqc2-desktop-style
>
> It is intended to be a small style written in QML for QtQuickControls2 that is
> intended to be used by default in QQC2-based apps when used in the Plasma
> desktop (it shouldn't have any user-visible message, anywhere), its final
> intended location is kde/workspace to be released together with Plasma 5.11

as there don't seem to be complaints, the project should move now into workspace

--
Marco Martin

Kirigami in Frameworks

[Marco Martin]

Hi all,
The Kirigami component set always was targeted to be eventually released as a 
framework, ideally tier 1. since a framework must depend at most from 2 Qt 
releases before the current one, it couldn't be released there yet.
Now that Qt 5.9 is released, i would like to propose to move Kirigami in 
frameworks, to be relased in the main release cycle, and stop standalone 
releases from extragear.

It strictly depends just from Qt stuff, so should be tier 1 (at runtime it can 
use optional styles that use features from Plasma, tough not having plasma 
installed doesn't touch its functionality in any part, if this ends up being a 
problem, i can move that style into plasma-integration)

-- 
Marco Martin

Re: kdereview: qqc2-desktop-style

[Marco Martin]

On Sun, May 21, 2017 at 7:16 PM, Albert Astals Cid <aa...@kde.org> wrote:
> if("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
>message(FATAL_ERROR "climbinggrades bla bla bla.")
> endif()
>
> This is not climbinggrades ;)



thanks, fixed

--
Marco Martin

kdereview: qqc2-desktop-style

[Marco Martin]

Hi all,
I'm anouncing the QtQuickControls2 desktop style in kdereview, repo name is 
qqc2-desktop-style

It is intended to be a small style written in QML for QtQuickControls2 that is 
intended to be used by default in QQC2-based apps when used in the Plasma 
desktop (it shouldn't have any user-visible message, anywhere), its final 
intended location is kde/workspace to be released together with Plasma 5.11

-- 
Marco Martin

Re: Review Request 122653: Set permissions for links in remote:, necessary for correct visualization

[Marco Martin]

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



kde4 patch, not valid anymore

- Marco Martin


On March 17, 2015, 4:49 p.m., Stefan Brüns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122653/
> ---
> 
> (Updated March 17, 2015, 4:49 p.m.)
> 
> 
> Review request for kdelibs, Plasma and Christoph Feck.
> 
> 
> Bugs: 339193
> http://bugs.kde.org/show_bug.cgi?id=339193
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> KFileItem uses UDS_ACCESS to determine permissions. Readability is
> subsequently used to create the list of overlay icons.
> 
> CCBUG: 339193
> 
> 
> Diffs
> -
> 
>   kioslave/remote/remoteimpl.cpp 5d973c6c1b6c31b7f3107d0d15805ef04bfdd661 
> 
> Diff: https://git.reviewboard.kde.org/r/122653/diff/
> 
> 
> Testing
> ---
> 
> dolphin remote:
> -> no lock icon on smb:, mtp:, ... links
> 
> 
> Thanks,
> 
> Stefan Brüns
> 
>

Re: Review Request 121584: Make the webapp manager run again.

[Marco Martin]

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



closing, project sadly abandoned

- Marco Martin


On Feb. 8, 2017, 1:25 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121584/
> ---
> 
> (Updated Feb. 8, 2017, 1:25 p.m.)
> 
> 
> Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.
> 
> 
> Repository: bodega-webapp-manager
> 
> 
> Description
> ---
> 
> Make the webapp manager run again.
> 
> 
> Diffs
> -
> 
>   app.js ceede62c192451f2ac2bba8848a97f9bcc4a2f4a 
>   package.json 715d01c3fa9e9f3a890ee9e047093fdfb528095f 
>   public/favicon.ico PRE-CREATION 
>   routes.js 891660f7fb3d036b5907114c58bd17f1128b1efe 
>   views/layout.jade 423a37493acac482369693168cce32886a71f0bb 
> 
> Diff: https://git.reviewboard.kde.org/r/121584/diff/
> 
> 
> Testing
> ---
> 
> It runs now, and gives 200 or 304 responses, though the browser currently 
> shows "Page Not Found"
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner "system tray"

[Marco Martin]

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



this is a kdelibs4 patch, not relevant anymore

- Marco Martin


On Sept. 25, 2014, 2:03 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120149/
> ---
> 
> (Updated Sept. 25, 2014, 2:03 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, KDEPIM, Qt KDE, Marco 
> Martin, and Olivier Goffart.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This review is for 2 sets of changes; an initial one to the way "system tray" 
> are rendered, and a newer set that protects the Preferences menu from getting 
> linked to any action with an appropriate title.
> 
> -- the system tray:
> Until now, "system tray" menus had some rendering issues on Mac OS X:
> 
> - The menu title, the 1st menu item that on Linux shows the application name, 
> remained empty
> - Menu items that can (in principle, potentially) show an icon always showed 
> the icon
> 
> Point 1 was resolved by emulating the Linux addTitle/setTitle action in 
> `KStatusNotifierItemPrivate::init()` : the menu title is implemented as a 
> deactive standard menuitem followed by a separator. This makes the item stand 
> out on a GUI that doesn't support the kind of formatting in menus as used in 
> the Linux implementation.
> 
> Point 2 was identified as a Qt issue: `isIconVisibleInMenu` is ignored for 
> systray menus. It was resolved by adding `KMenu::addAction` methods that 
> overload the ones from QMenu that were hitherto inherited unchanged by KMenu. 
> The only different method is `addAction(QAction*)` which removes the icon 
> from the `QAction` if `isIconVisibleInMenu()` is false. The other `addAction` 
> methods are "overloaded with themselves" with `using QMenu::addAction;` in 
> the header file.
> 
> -- the Preferences menu item
> This is a menu item living in the Application menu, a menu that sits in the 
> menubar between the Apple (?) menu and the File menu. This menu also contains 
> the Quit command.
> KDE and Qt applications typically do not set up their menus in this fashion, 
> so Qt provides an automatic way to put relevant menu items (actions) in the 
> Application menu, using Apple's naming. The algorithm is described under 
> QMenuBar in the Qt documentation: for the Preferences action, it will 
> consider any action that has a text containing `config`, `options`, 
> `settings` or `preferences`, and put it under the Preferences label if its 
> menu role is set to `heuristic` (which appears to be the default).
> In practice, many applications provide a series of menu actions with names 
> that trigger this method, and they do not always create their own 
> preferences/settings/configuration menu first. Yet it is the first menu 
> action that matches that will be installed under the Preferences menu, with 
> the Command-, shortcut. A good example is KDevelop: it will have a 
> Preferences menu that activates the `Configure Selection` action - which does 
> not open a settings dialog but launches the configure or cmake procedure for 
> the selected project ...
> 
> My proposed solution overrides this Qt behaviour. On OS X, the `KAction(const 
> QString , QObject *parent)` constructor calls a modified (static) 
> function `setTextWithCorrectMenuRole` which checks the text against the 
> patterns Qt will consider for `PreferencesRole`. If it finds a match, it will 
> force the role to `NoRole`, unless it is a perfect match with the standard 
> KDE configuration action for the application (`" appName..."`) 
> in which case it sets the role to `PreferencesRole`. This latter 
> consideration allows kdelibs to "catch" the configuration menu for 
> applications like KMail, which appear not to be created using 
> KStandardActions.
> This approach can be extended to other menu actions that end up incorrectly 
> in the OS X Application menu.
> 
> Applications that create menu actions using QAction or a different KAction 
> constructor will see no change (and should use `setMenuRole` selectively on 
> OS X).
> 
> 
> Diffs
> -
> 
>   kdeui/actions/kaction.cpp 9e8f7fb 
>   kdeui/notifications/kstatusnotifieritem.cpp 1b15d40 
> 
> Diff: https://git.reviewboard.kde.org/r/120149/diff/
> 
> 
> Testing
> ---
> 
> Testing was done with kdelibs git/master and KD

Re: CI Requirements - Lessons Not Learnt?

[Marco Martin]

On Friday 13 January 2017 17:23:20 Martin Gräßlin wrote:
> > Please chime in with suggestions for how the text needs to be refined
> > and expanded to meet your and our needs. Updated versions of specific
> > paragraphs are the preferred format for doing so: The thread so far
> > has shown that free-form conversation is prone to mudslinging, so
> > let's try to keep to the lingo fo a formal, dry document.
> 
> Thanks for stepping up to write this!
> 
> A few notes from my side:
> 
> * "Subscribing the sysadmin team to these code reviews is mandatory." -
> How? What are the team names one has to add as reviewers?

just the sysadmin group added to reviewers i guess, so any of them can answer.

> * This drastically changes the way KDE works. It requires mandatory code
> review and gives kind of veto power to sysadmins. It's something the
> larger KDE community might need to discuss as it removes one of the core
> principles of KDE that anybody can commit to anything and code review is
> only optional.

would make mandatory code review for that kind of change that yes, is 
significant (but arguably the lesser evil in this particular case?), but i 
don't think it would give sysadmins significant veto power, as  after 2 weeks 
the change would be able to go in anyways even if the corresponding measures 
for updating the deps wouldn't have been taken already

> * I would like to see a link to where developers can check whether a
> dependency is available. Reasoning: I want to check whether it's a
> no-brainer to not have to add sysadmins if it's already available. E.g.
> if I add a new dep in KWin, which is already used by Krita I wouldn't
> know that and ask sysadmins. That would be a waste of sysadmin's time.

+1

> * I would like to add another exception: last minute dependency requests
> prior to a feature freeze should be allowed under certain conditions
> even if sysadmins had not two weeks to respond. Reasoning: shit happens
> ;-)

yeah, should have a long written reason on what is the problem they fix, like 
if is a frequent crash with X version of the dep.

-- 
Marco Martin

Re: CI Requirements - Lessons Not Learnt?

[Marco Martin]

On Friday 13 January 2017 21:21:16 Eike Hein wrote:
> Ok, here we go. My draft of a formal policy for dep changes and the CI:
> 
> https://community.kde.org/Policies/Dependency_Changes_and_CI
> 

very happy to see this!
in general i agree with Adriaan about swapping a) and c)

-- 
Marco Martin

Re: announcement: plymouth-kcm in kdereview

[Marco Martin]

On Thursday 05 January 2017 12:30:38 Jonathan Riddell wrote:
> It should rather follow Plasma practice and set these in the top cmake file
> set(PROJECT_VERSION "5.8.90")
> set(PROJECT_VERSION_MAJOR 5)
> 
> and use PROJECT_VERSION

would this number be automagically updated one this gets into workspace?

> same for const char version[] = "1.0"; src/kplymouththemeinstaller.cpp
> 
> The kcm is LGPL while the helper executables are GPL, probably simpler just
> to make it all GPL.
> 
> The copyright headers should follow current best practice text listed at
>  https://community.kde.org/Policies/Licensing_Policy#GPL_Header
> 
> There's no docs, I don't know if anyone cares about these for kcms any
> more, probably not.  Seems a general System Settings issue, the Help
> button is shown but does nothing when I click it even for
> e.g. kcmshell5 colors. This works again when I install khelpcenter but
> it should have sensible fallback like apps do.  Except the apps launch
> a web page which doesn't exist.  Is it time to just give up on docs
> and accept they're not actually that important?

i get the button disabled here, which i think is fine.

> I get quite a few warnings/errors when running kcmshell5 plymouth:
>  org.kde.kcoreaddons: Error loading plugin "kcm_plymouth" "The shared
> library was not found." Plugin search paths are
> ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") The environment
> variable QT_PLUGIN_PATH might be not correctly set

this warning doesn't make sense and i can't reproduce (it should not work at 
all then, but it's working) sure you don't have a spurious old installation 
left somewhere?

> kf5.kcoreaddons.desktopparser: Could not locate service type file
> kservicetypes5/kpackage-genericqml.desktop, tried ("/home/jr/.local/share",
> "/usr/share/usr/share/xsessions/plasma", "/usr/local/share", "/usr/share",
> "/var/lib/snapd/desktop")

this is probably a kcpackage issue: that type is built in kpackage and doesn't 
have a plugin. i don't know where the warning comes from tough

> file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/Button.qml:100:
> TypeError: Cannot read property of null

qqc1 upstream bug

> When I run kcmshell5 plymouth  and use the corners to resize the window
> larger and smaller after a short while it freezes and gives output of
> file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:48:13:
> QML GridView: Binding loop detected for property "cellWidth"

should be fixed now

> The top text says "Plymouth splash screen". It should be in title case.
> 
> There's no preview pic for my pre-installed splash screens.  Probably none
> is available but there must be some way to make one available for breeze
> themes at least?

yes, the breeze splash screen can get a "preview.png" file in it, it would get 
picked up

> When I click Defaults nothing much happens, what is this button supposed to
> do?

eh, in this case it doesn't really mean anything, but i can't remove it :/

> When I click Reset it resets back to the current setting.  When I then go on
> to select another theme the Reset button does not become enabled again and
> output says
> file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:136:
> ReferenceError: resetCheckbox is not defined

fixed

> No Product in bugzilla
>  https://bugs.kde.org/describecomponents.cgi
> when one is added you'll need to add it to releaseme
> plasma/plasma-add-bugzilla-versions

should be a component in plasmashell being in workspace?

> No Product in Phabricator
> 
> The terminology changes between 'System Splash', 'Plymouth Splash Screen',
> 'global splash screen' and '[Get New] Splash Screens'.  Better to pick one
> I think, I like 'Boot Splash'.
> 
naming should be a tad more consitent now

-- 
Marco Martin

announcement: plymouth-kcm in kdereview

[Marco Martin]

Hi all,
announcing a new KCM module to change the plymouth splash screen
The repository is named plymouth-kcm and is headed for kdereview now.
its final resting place would be the workspace area, to be released in sync 
with the rest of Plasma

-- 
Marco Martin

Re: kirigami moved in kdereview

[Marco Martin]

On Sun, Jul 24, 2016 at 7:51 PM, Burkhard Lück <lu...@hube-lueck.de> wrote:
> Am Sonntag, 24. Juli 2016, 19:32:54 CEST schrieb Marco Martin:
>> Hi all,
>> the kirigami project has been moved to kdereview.
>>
> I see a message extraction into a catalog named libkirigamiplugin with two
> messages, but apparently this catalog is not used in kirigami?

how would translations be done if the Qt translation system is used
instead? I see tier1 frameworks use that, but they don't seem to have
extraction scripts or anything..

--
Marco Martin

Re: kirigami moved in kdereview

[Marco Martin]

On Sunday 24 July 2016, Burkhard Lück wrote:
> Am Sonntag, 24. Juli 2016, 19:32:54 CEST schrieb Marco Martin:
> > Hi all,
> > the kirigami project has been moved to kdereview.
> 
> I see a message extraction into a catalog named libkirigamiplugin with two
> messages, but apparently this catalog is not used in kirigami?

right, i can't really depend from ki18n there, I guess I'll have to make the 
Qt translation system work instead

-- 
Marco Martin

kirigami moved in kdereview

[Marco Martin]

Hi all,
the kirigami project has been moved to kdereview.

kirigami is a QtQuick module aimed in the future to become a framework (it has 
no dependencies by default besides Qt, optional to kdeclarative and plasma)

It can be used to build mobile applications with QtQuick (as well as very 
simple desktop applications)
its main scope is not to provide basic controls (job of QtQuickControls and 
QtQuickControls2) but more high level controls that make easier to implement 
an application conformant to the KDE HIG
https://community.kde.org/KDE_Visual_Design_Group/KirigamiHIG

more info:
https://dot.kde.org/2016/03/30/kde-proudly-presents-kirigami-ui
https://api.kde.org/playground-api/libs-apidocs/kirigami/html/index.html

its destination would be extragear, and when Qt 5.7 will be old enough for 
frameworks to depend from it, would eventually become a framework

-- 
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Saturday 19 March 2016, Albert Astals Cid wrote:
> > 
> > If this is accepted, I will manage the various tickets with sysadmins
> > (and at least move the translations myself).
> 
> No objections from my side, please get a decision+moved tuesday the latest.
> 

ok for us too..
something we need to do from our side?

-- 
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Wed, Mar 9, 2016 at 4:43 PM, Yuri Chornoivan <yurc...@ukr.net> wrote:
> Hi,
>
> Just of curiosity, what is the next thing, after documentation (as Plasma
> almost does not have it), to get rid from Plasma? Is it Okular, Krusader,
> something else? Just to make simple, sleek and unintrusive.
>
> Thanks in advance for your answer.

None of those examples is part of the workspace (is like wondering if
Gwenview is part of K3b), they are excellent applications released on
their own, so the problem does not apply.

--
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Wed, Mar 9, 2016 at 5:05 PM, Luigi Toscano <luigi.tosc...@tiscali.it> wrote:
>
> There is a non-committed work to have search working again, which will cut the
> bug list. You should have probably already noticed a bunch of commits which
> fixes some language related issues.


thanks for stepping up in the maintainership of KHelpCenter

--
Marco Martin

Re: KDE file dialog

[Marco Martin]

On Wednesday 02 March 2016 11:19:42 Martin Graesslin wrote:
> 
> What is that "kf5" plugin you talk of? Sorry this just does not make sense.
> The plugin we have (and soon had) in frameworks is setting the defaults for
> Plasma. There are no generic defaults for frameworks. It just does not make
> sense.
> 
> If you think Qt's fallback is not good enough, then improve it. Don't make
> KDE do that work for Qt. That's thinking like Qt were a closed project.

improve that one, or make a different one, may sound like a project LxQt people 
may be interested into as well, wether is maintained in Qt tree or not.
That shouldn't stop us wanting a QPA more closely integrated with our own 
desktop product

-- 
Marco Martin

Re: KDE file dialog

[Marco Martin]

On Wednesday 02 March 2016 09:42:06 Martin Graesslin wrote:
> If you think Qt's default is too bad, improve Qt. If you think it needs a
> more generic qpt-plugin which can be used outside of Plasma: do it. But
> don't complain to people doing actual work.

^^This

-- 
Marco Martin

Fwd: Plasma Mobile Components -> Kirigami (?)

[Marco Martin]

Hi all,
I'm forwarding this message here, because apparently the discussion on
plasma-de...@kde.org was too narrow, we tought we did reach a
consensus, while in reality we didn't.
What plasma mobile components (or kirigami) is:

* A set of QML imports, aimed to be a Tier1 framework, for help in
creating QML based mobile applications (eventually in the future
becoming not completely limited to mobiole but expanded to the desktop
as well) to have a conformity of toolkit, look and feel for KDE
applications ported to mobile (even tough we already have a notable
3rd party adopter: subsurface https://subsurface-divelog.org )
* higher level components: things like buttons and textboxes are in
the scope of QtQuickControls and QtQuickControls2, we want to
integrate well with them, not step on their toes.
* support for Plasma mobile as well as Android both as first class
citizens (that's why it has to be tier 1)
* A set of User interface and design guidelines for conforming
applications (such as
https://techbase.kde.org/Projects/Usability/HIG/GlobalDrawer)

right now They are called Plasma mobile components, but the concern is
that "it depends on plasma", it's intended just to be used on plasma,
but that's not true.
Another name was proposed: Kirigami, below the rationale by the
proposal first written by Thomas.

I'm asking here because: as developers of Qt application, If you were
to consider things to use to port your applications to a mobile
interface, what would you prefer?

-- Forwarded message --
From: Thomas Pfeiffer 
Date: Tue, Feb 23, 2016 at 12:51 PM
Subject: Plasma Mobile Components -> Kirigami (?)
To: plasma-de...@kde.org


Dear fellow Plasma team members,
about two weeks ago, Marco came to the VDG asking for a new name for Plasma
Mobile Components.
The reasoning behind this request was that with them becoming their own KDE
framework and Subsurface mobile showing that they work very well outside of
Plasma Mobile as well, we don't want people to associate them strongly with
Plasma Mobile (as Martin Gräßlin had pointed out).

With that request, we started brainstorming. What we wanted the name to
express was
- Physicality (because it does have some similarities to Material Design,
while still being quite different in some areas)
- A tool for expressing your creativity in UI design
- Moving layers of things (because of the central role of drawers)

We had ideas like "slide", "paper" or "blocks" flying around, but then Alex
Longo came up with Origami, which in turn led him to "Kirigami".
For those of you who (like the rest of the brainstorming team) don't know what
Kirigami is: It's a technique similar to Origami, which adds cutting to
folding.

It is physical, it is creative, kinda playful without being childish, and it's
far less common than Origami, which helps with searchability.

Now you might think "Won't people make fun of the name because it has a K in
it?". They might, but the cool thing is: Whenever someone does, all we need to
reply with is " http://lmgtfy.com/?q=Kirigami " and they'll feel like the lazy
dumbos that they are.
We could even play with it immediately when announcing the name, saying
something like "You all know how much we love names with a K, but this time,
instead of just randomly replacing Cs with Ks, we found a name that comes with
a built-in K (thank you, Japanese)!"

Like Material Design, Kirigami would be more than just a set of UI components,
it comes with its own design philosophy documented in the HIG.

Since it would in the future encompass not only mobile, but - following the
convergence paradigm - QtQuick-based desktop applications as well, we want all
of the team to be on board with the name.
So, does anybody see potential pitfalls or other problems with the name? If
so, speak up!

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

Re: Review Request 127102: Use fixed width for digital clock applet

[Marco Martin]

> On Feb. 18, 2016, 12:05 a.m., David Edmundson wrote:
> > applets/digital-clock/package/contents/ui/DigitalClock.qml, line 555
> > 
> >
> > rather than looping, can we use FontMetric's maximumCharacterWidth
> > 
> >  * numChars.
> > 
> > Then we could kill sizeHelper competely (FontMetric's didn't exist when 
> > this was written)

hoping maximumCharacterWidth is reliable for all fonts, this loop really needs 
to go


- Marco


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


On Feb. 17, 2016, 4:23 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 4:23 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 127102: Use fixed width for digital clock applet

[Marco Martin]

> On Feb. 17, 2016, 11:59 p.m., David Edmundson wrote:
> > Is this needed after: https://git.reviewboard.kde.org/r/127073/ ?

probably


- Marco


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


On Feb. 17, 2016, 4:23 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127102/
> ---
> 
> (Updated Feb. 17, 2016, 4:23 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Bugs: 347724
> https://bugs.kde.org/show_bug.cgi?id=347724
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Currently the width of the date label is not fixed but changes depending on 
> the text. This causes the entire applet to change its width (if the time is 
> the widest displayed item). This in turn can cause all other applets in the 
> same panel to move whenever the displayed time changes.
> 
> This patch uses FontMetrics to iterate over all possible time strings (with 
> different width) and chooses the widest of them as reference for the fixed 
> width of the time label.
> 
> This way the width of the applet stays the same (unless the date is displayed 
> and changes). The text remains centered though, which means that it can still 
> move within the applet when the time changes.
> 
> 
> Diffs
> -
> 
>   applets/digital-clock/package/contents/ui/DigitalClock.qml 95bb071 
> 
> Diff: https://git.reviewboard.kde.org/r/127102/diff/
> 
> 
> Testing
> ---
> 
> Works with horizontal and vertical panel.
> Also displaying different combinations of "seconds", "date" and "timezone" 
> works.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: apidocs page seems broken

[Marco Martin]

On Monday 08 February 2016, Ben Cooksley wrote:
> Someone fix KDeclarative please (something in the CMake magic
> generates that file), and kapidox needs hardening against improper
> setup of Frameworks.
> This should also have been caught in the review process!
> 
> This is far from the first time that improper metadata has broken the
> API Documentation generation requiring sysadmin to look into this.
> 

what should be changed?
kdeclarative has a metainfo.yaml file 

if i run locally kgenapidox it works correctly

-- 
Marco Martin

Re: Review Request 126851: Places data engine: Rename model role name "index" to "id"

[Marco Martin]

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


Ship it!




on the fence about this.
it's a rename of a semi public thing that may cause problems, but if it breaks 
the qml model uhm, ok

- Marco Martin


On Jan. 23, 2016, 2 p.m., Daniel Faust wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126851/
> ---
> 
> (Updated Jan. 23, 2016, 2 p.m.)
> 
> 
> Review request for kde-workspace and Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I wrote a qml applet using the places data engine and noticed that I can't 
> access the index variable of ListView items because it gets overwritten by 
> the places model.
> This patch renames the "index" role name to "id" in order to avoid this 
> naming conflict.
> 
> 
> Diffs
> -
> 
>   dataengines/places/org.kde.places.operations 98a951d 
>   dataengines/places/placeservice.cpp e0c93c5 
>   dataengines/places/placesproxymodel.h 467fe83 
>   dataengines/places/placesproxymodel.cpp 5ea807b 
> 
> Diff: https://git.reviewboard.kde.org/r/126851/diff/
> 
> 
> Testing
> ---
> 
> I couldn't find any other model that is using the places data engine so I 
> hope renaming the model role is fine.
> The provided model still works and I tested the "Setup Device" and "Teardown 
> Device" operations of the service.
> The operations "Show" and "Hide" don't seem to work anyway and the others 
> were not tested.
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

Re: Review Request 125043: expose the WheelMouseZooms global setting through the input ("mouse") KCM

[Marco Martin]

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


hmm, looks like a feature in a now frozen repo, not sure is a good practiche..

- Marco Martin


On Sept. 4, 2015, 11:51 a.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125043/
> ---
> 
> (Updated Sept. 4, 2015, 11:51 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kde-workspace and kdelibs.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> KDE4 has been providing a setting that (would have) allowed to avoid unwanted 
> text zooming during simulated inertial scrolling (scroll coasting). KDE PIM 
> applications were immune to that issue because certain KDELibs classes use 
> the parameter, which made it all the more annoying that other (e.g. 
> Kate-based) applications weren't. Sadly this setting wasn't published via a 
> GUI.
> 
> This patch adds a checkbox to the input ("mouse") KCM which seemed like the 
> most appropriate place if not only because it also makes sense to provide 
> this KCM on non-X11 platforms like OS X and MS Windows (where settings like 
> "double or single click" are relevant).
> 
> I consider this a fix of an omission bug, but I realise that it could also be 
> considered a new feature, so this RR is also intended to give some public 
> exposure to my patch rather than keeping it to myself.
> 
> 
> Diffs
> -
> 
>   kcontrol/input/kmousedlg.ui b48a606 
>   kcontrol/input/mouse.h d926a99 
>   kcontrol/input/mouse.cpp cebb174 
> 
> Diff: https://git.reviewboard.kde.org/r/125043/diff/
> 
> 
> Testing
> ---
> 
> For now only on OS X with kdelibs 4.14.11 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 123568: Use user-places.xbel instead of bookmarks.xml in places model.

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On April 30, 2015, 7:51 a.m., Emmanuel Pescosta wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123568/
 ---
 
 (Updated April 30, 2015, 7:51 a.m.)
 
 
 Review request for kdelibs and Marco Martin.
 
 
 Bugs: 345174
 http://bugs.kde.org/show_bug.cgi?id=345174
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Use user-places.xbel instead of bookmarks.xml in places model, as discussed 
 on the frameworks ML.
 
 Same as RR 123526 but adjusted to kdelibs4
 
 
 Diffs
 -
 
   kfile/CMakeLists.txt ceae140 
   kfile/kfileplacesmodel.cpp 24f95ad 
   kfile/kfileplacessharedbookmarks.cpp 5385d42 
   kfile/kfileplacessharedbookmarks_p.h 654fe18 
 
 Diff: https://git.reviewboard.kde.org/r/123568/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Emmanuel Pescosta
 

Re: Moving User Manager back to playground

[Marco Martin]

On Thursday 09 April 2015 18:59:23 Vishesh Handa wrote:
 Hey guys
 
 It seems that 'user-manager' was moved into the kde/workspace subdirectory
 a couple of months ago, even though it was clearly blocked during the
 review process in kde-core-devel.
 
 I'm going to ask the system-admin request to move it back there.
 
 If you have any objections please let me know.

uuh, did it end up in the release then?

-- 
Marco Martin

Re: Review Request 122784: Fix 404 result for all api calls.

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On March 3, 2015, 3:21 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122784/
 ---
 
 (Updated March 3, 2015, 3:21 a.m.)
 
 
 Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.
 
 
 Repository: bodega-server
 
 
 Description
 ---
 
 Thanks to Johnathan for this fix.
 
 
 Diffs
 -
 
   server/app.js 76c6f101a29a907a7af465d9f402770d84ab0e01 
 
 Diff: https://git.reviewboard.kde.org/r/122784/diff/
 
 
 Testing
 ---
 
 Tests still fail but the api calls are returning json data now.
 
 
 Thanks,
 
 Jeremy Whiting
 

Warning: KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated

[Marco Martin]

Hi all,
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?

--
Marco Martin

Re: Warning: KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated

[Marco Martin]

On Sat, Feb 21, 2015 at 1:34 PM, Alexander Richardson
arichardson@gmail.com 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?

--
Marco Martin

Re: Warning: KPluginInfo::property(X-KDE-PluginInfo-Name) is deprecated

[Marco Martin]

On Sat, Feb 21, 2015 at 3:43 PM, Marco Martin notm...@gmail.com wrote:
 On Sat, Feb 21, 2015 at 1:34 PM, Alexander Richardson
 arichardson@gmail.com 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;
 }

anyways, absolutely +1 on this new function, I like the idea a lot :)

--
Marco Martin

Re: Review Request 122552: warnings--

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Feb. 13, 2015, 1:49 a.m., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122552/
 ---
 
 (Updated Feb. 13, 2015, 1:49 a.m.)
 
 
 Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.
 
 
 Repository: bodega-server
 
 
 Description
 ---
 
 warnings--
 
 
 Diffs
 -
 
   server/app.js 4217a67735218e6bf1ccb04696a4e650319bb5d0 
 
 Diff: https://git.reviewboard.kde.org/r/122552/diff/
 
 
 Testing
 ---
 
 This fixes a  few more warnings seen at runtime, with this fix browsing to 
 localhost:3000/contact (or any other url in the api) shows the 404 page.
 Without this fix it shows nothing and never responds.
 
 
 Thanks,
 
 Jeremy Whiting
 

Re: Review Request 122552: warnings--

[Marco Martin]

I did some tests.
the correct url is http://localhost:3000/bodega/v1/json/route  even tough
no routes seems to match

I can't figure out why, the only thing seems to be the express module to be
broken in some way.
probably good to make some tests with simple exampl-ish express apps


On Fri, Feb 13, 2015 at 2:17 PM, Jeremy Whiting jpwhit...@kde.org wrote:

This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122552/
   This change has been marked as submitted.
   Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.
 By Jeremy Whiting.

 *Updated Feb. 13, 2015, 1:17 p.m.*
  *Repository: * bodega-server
 Description

 warnings--

   Testing

 This fixes a  few more warnings seen at runtime, with this fix browsing to 
 localhost:3000/contact (or any other url in the api) shows the 404 page.
 Without this fix it shows nothing and never responds.

   Diffs

- server/app.js (4217a67735218e6bf1ccb04696a4e650319bb5d0)

 View Diff https://git.reviewboard.kde.org/r/122552/diff/

Re: Sysadmin report on the modernization of our infrastructure

[Marco Martin]

On Wednesday 21 January 2015 17:12:07 Ben Cooksley wrote:
 Hi all,
 
 As promised in the earlier thread, i'd like to present the sysadmin
 report on the state of the infrastructure surrounding our code.
 
 It contains a detailed summary of what is broken with our existing
 systems, why change is necessary and an evaluation of the options we
 considered. We have also made a proposal based on our evaluations and
 the wishlist of functionality drawn up the community.
 
 Please find it attached - and let us know what you think. Feedback is
 welcome.

thanks for the analysis, work much appreciated :)

as my just two cents, i'm quite happy with gerrit, has an horrible interface, 
but i like what it does.

about phabricator, can't say anything, never tried, if any project want to 
test it as it seems from the thread would be happy to try it.

but in the end, I would be quite happy even if we go with just gerrit.

-- 
Marco Martin

Re: KPackage framework

[Marco Martin]

On Mon, Dec 22, 2014 at 4:01 PM, David Edmundson
da...@davidedmundson.co.uk wrote:
 No objections from me

ok, opened a sysadmin ticket for the move

--
Marco Martin

Re: New framework to review: KPackage

[Marco Martin]

On Wednesday 10 December 2014, David Edmundson wrote:
 ​The binary is called kpackagetool. Given the complications we've had with
 frameworks co-installability does it make sense to call it kpackagetool5?
 
 The class name in kpackagetool/kpackagetool.cpp should probably be renamed
 
 Documentation at the top of PackageLoader should avoid saying Plasma quite
 so much

done.

 commented line at 773 of package.cpp looks concerning. I think it is just
 dead code.

yep, a signal that used to exist in plasma1, removed

 Installation command of plasmoids.knsrc are wrong (in fact they're wrong
 for current plasmapkg)
 Should kpackage even be providing this file? I think it should be with the
 plasmoid definition.

agree, shouldn't be there: removed.

 IMHO PackageJob probably shouldn't set a parent to the packagestructure.
 Otherwise if you create a PackageStructure on the stack then call
 install/uninstall it will delete the job before it's finished.

should be safe to don't have any parent since kjobs shuold delete themselves 
iirc? (changed to that)

  There's a Qt5 TODO on PackageJobThread::removeFolder

changed to just use QDir::removeRecursively()

-- 
Marco Martin

Re: KPackage framework

[Marco Martin]

On Monday 10 November 2014, Marco Martin wrote:
 Hi all,
 since at akademy there seemed the interest in it,
 I have been working on some classes i extracted from libplasma to be on
 their own, those related to Plasma::Package, since several applications
 have the interest of having scriptable or anyways non-binary content
 shippable over ghns.
 you can find them in the kpackage repository.

Since we are around ~2 weeks, I would like to move it, possibly to be released 
with next framework (since we would need it for Plasma (workspace) 5.2 would 
have to go in this frameworks release)

any objections?

-- 
Marco Martin

Re: New framework to review: KPackage

[Marco Martin]

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..

-- 
Marco Martin

Re: New framework to review: KPackage

[Marco Martin]

On Wednesday 10 December 2014, Albert Astals Cid wrote:
  I would like to submit it (kpackage repo) for the usual 2 weeks period of
  review.
 
 Add const 
 void setDefaultMimeTypes(QStringList mimeTypes);
 void setMimeTypes(const char *key, QStringList mimeTypes);
 
 You probably want a Q_DISABLE_COPY or similar in PackageLoader

done

 Add const 
 foreach (QString prefix, d-contentsPrefixPaths) {

done

 
 All those char * params make me a bit unhappy, any reason those are not
 QString or QByteArray?

made them QByteArrays


-- 
Marco Martin

New framework to review: KPackage

[Marco Martin]

Hi all,

In the past weeks I have been working on a new framework, called KPackage.
(during Akademy seemed there was some interest for applications to use it)
It comes from the old classes Plasma::Package, so is actually old and tested 
code.

It can be used by any application that wants to ship any additional non-
binary content, such as extension scripts, extra artwork, or anything that 
for instance can be shipped via get hot new stuff.
It should be a Tier 2 framework, as depends from 
karchive,kcoreaddons,ki18n,kconfig

Plasma::Package will become a simple dumb wrapper around KPackage for 
retrocompatibility (and deprecated)

applications to use it should implement a little plugin for the package 
structure, that tells where it should install stuff, what kind of content 
supplies (for instance javascript files under the code/subdirectory)
and the Package class will offer an api to access files from it 
there is also a simple little tool called kpackagetool that can be used to 
install, remove and list packages.

I would like to submit it (kpackage repo) for the usual 2 weeks period of 
review.

-- 
Marco Martin

Re: Adventures in Bodega

[Marco Martin]

On Monday 24 November 2014, Aaron J. Seigo wrote:
 On Saturday, November 22, 2014 07.56:39 Jeremy Whiting wrote:
  getting an error inside the node redis module as seen below. Is redis
  something that is no longer maintained or something?
 
 redis is a very popular key/value store (in-memory with on-disk
 persistence). you need to have it installed and running. it does not
 require any configuration: just install, start, profit.

I tried to update my node and extensions install and now i get the same error.

what i suspect is that the redis node extension changed its api in an 
incompatible way, so if is the case our code would have to be adapted

-- 
Marco Martin

Re: Adventures in Bodega

[Marco Martin]

On Saturday 22 November 2014, Jeremy Whiting wrote:
 Hello list,
 
 I realize this list will reach many more people than could probably answer,
 but the -active list seems to be dead from what I hear, so I thought I'd
 try here. In looking into bodega as a successor to opendesktop and ocs I've
 tried to setup a local bodega instance on my machine. The documentation is

As I suspected there were some API changes in both the redis module and 
express stuff.
I now pushed a quick port that makes the thing at least start.
Web stuff is always just like that unfortunately :/

-- 
Marco Martin

Gerrit: merging feature branches

[Marco Martin]

Hi all,
Gerrit question: I have a feature branch in plasma-framework 
(mart/basicDeleteUndo), and i wanted to do the review process with gerrit.

now i tried the following 3 approaches, that all fail miserably:
* from my branch: git push gerrit HEAD:refs/for/master gives [remote rejected] 
master - refs/for/master (no new changes)
* from master: git rebase mart/basicDeleteUndo, then git push gerrit 
master:refs/for/master . it complains that a commit doesn't have an id (all of 
my commits in the branch have it)
* from master: git merge mart/basicDeleteUndo: complains as well that a commit 
doesn't have id (may be the merge commit in this case?)

in the end the nearest i could get is 
https://gerrit.vesnicky.cesnet.cz/r/#/c/130

Can the feature branch workflow work at all in gerrit or is better to just use 
master?

-- 
Marco Martin

Re: Using Gerrit for code review in KDE

[Marco Martin]

On Tuesday, September 9, 2014, Jan Kundrát j...@flaska.net wrote:

 If you would like all plasma to go, just give me a list of repos and I
can make it happen.

No, definitely not yet


 In my opinion, the purpose of this test is not to verify that Gerrit
works or that the ACLs are set up properly -- both were done already.

As part of the experiment i would also like to try to have stricter acls
for +2 and submit, like starting from mantainers then slowly adding people
(that's also how i understood it would have worked during the bof)

--
Marco Martin

Re: Review Request 117175: Fix installing new .comic packages from GHNS to appear in the installed packages list in the comic widget.

[Marco Martin]

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

Ship it!


the explicit listing of themes is ok, puts it in line with plasmapkg2.
dead code should be removed before shipping


plasma/tools/plasmapkg/main.cpp
https://git.reviewboard.kde.org/r/117175/#comment45142

never comment dead code, if it should be removed, should just be deleted


- Marco Martin


On Apr. 23, 2014, 11:05 p.m., Andrei Amuraritei wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/117175/
 ---
 
 (Updated Apr. 23, 2014, 11:05 p.m.)
 
 
 Review request for KDE Runtime, Aaron J. Seigo, Ian Monroe, and Lamarque 
 Souza.
 
 
 Bugs: 306279 and 325028
 http://bugs.kde.org/show_bug.cgi?id=306279
 http://bugs.kde.org/show_bug.cgi?id=325028
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 When installing a new .comic provider from GHNS, it doesn't appear in the 
 installed list on the comic widget.
 This fixes it.
 
 
 Diffs
 -
 
   plasma/tools/plasmapkg/main.cpp 61492fe 
 
 Diff: https://git.reviewboard.kde.org/r/117175/diff/
 
 
 Testing
 ---
 
 Compile, add new comic widget, install new comic providers.
 
 
 Thanks,
 
 Andrei Amuraritei
 

Re: Closing the kde-core-devel mailing list

[Marco Martin]

On Monday 04 August 2014, Vishesh Handa wrote:
 Hello people
 
 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.

hmm, I would maybe have seen a reason in doing like the other way around, 
closing kde-frameworks, merge the mails and move all on k-c-d, since 
frameworks is released and is the main target of development now

-- 
Marco Martin

Re: Review Request 114910: Patch for bug 317066 (systray leaves garbage on the panel when resizing )

[Marco Martin]

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


this would require some testing before pushing to 4.x, too delicate to just 
commit

- Marco Martin


On Gen. 8, 2014, 4:25 p.m., Dmitry Ivanov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114910/
 ---
 
 (Updated Gen. 8, 2014, 4:25 p.m.)
 
 
 Review request for kde-workspace and Plasma.
 
 
 Bugs: 317066
 http://bugs.kde.org/show_bug.cgi?id=317066
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 It is a proposed fix for bug 317066. The fix is a very simple one-liner 
 setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware 
 FullViewportUpdate has negative performance impact but I also know it 
 efficiently leaves out any graphical glitches happening due to no repaint of 
 widget when necessary (which is what the bug is about). I have tested my 
 solution for a couple of days: the bug no longer reproduced and I also didn't 
 see any noticeable performance problems. I'm still not sure what I propose is 
 acceptable since it may seem like a hack to more experienced developers, 
 however I just didn't want my patch attempt to get lost and forgotten in the 
 bugzilla. Please have a look and decide whether the patch is good enough to 
 be applied to the next bugfixing release of KDE 4.x series, thank you. 
 
 
 Diffs
 -
 
   plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 
 1baa23d 
 
 Diff: https://git.reviewboard.kde.org/r/114910/diff/
 
 
 Testing
 ---
 
 I rebuilt plasma_applet_systemtray.so with the patch and replaced the package 
 version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can 
 no longer reproduce bug 317066 and I don't see any noticeable performance 
 problems of system tray applet. 
 
 
 Thanks,
 
 Dmitry Ivanov
 

Re: Review Request 114910: Patch for bug 317066 (systray leaves garbage on the panel when resizing )

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Jan. 8, 2014, 4:25 p.m., Dmitry Ivanov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114910/
 ---
 
 (Updated Jan. 8, 2014, 4:25 p.m.)
 
 
 Review request for kde-workspace and Plasma.
 
 
 Bugs: 317066
 http://bugs.kde.org/show_bug.cgi?id=317066
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 It is a proposed fix for bug 317066. The fix is a very simple one-liner 
 setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware 
 FullViewportUpdate has negative performance impact but I also know it 
 efficiently leaves out any graphical glitches happening due to no repaint of 
 widget when necessary (which is what the bug is about). I have tested my 
 solution for a couple of days: the bug no longer reproduced and I also didn't 
 see any noticeable performance problems. I'm still not sure what I propose is 
 acceptable since it may seem like a hack to more experienced developers, 
 however I just didn't want my patch attempt to get lost and forgotten in the 
 bugzilla. Please have a look and decide whether the patch is good enough to 
 be applied to the next bugfixing release of KDE 4.x series, thank you. 
 
 
 Diffs
 -
 
   plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 
 1baa23d 
 
 Diff: https://git.reviewboard.kde.org/r/114910/diff/
 
 
 Testing
 ---
 
 I rebuilt plasma_applet_systemtray.so with the patch and replaced the package 
 version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can 
 no longer reproduce bug 317066 and I don't see any noticeable performance 
 problems of system tray applet. 
 
 
 Thanks,
 
 Dmitry Ivanov
 

Re: Review Request 114910: Patch for bug 317066 (systray leaves garbage on the panel when resizing )

[Marco Martin]

 On July 29, 2014, 10:31 a.m., Marco Martin wrote:
  this would require some testing before pushing to 4.x, too delicate to just 
  commit
 
 Dmitry Ivanov wrote:
 Well, I've been living with this patch for half a year already, since 
 January 8 :) I used it with a number of KDE 4.x versions from 4.11.3 to 
 4.13.1 (coming with Linux Mint updates). Could it be counted as some testing?

ok, let's go for it


- Marco


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


On Jan. 8, 2014, 4:25 p.m., Dmitry Ivanov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114910/
 ---
 
 (Updated Jan. 8, 2014, 4:25 p.m.)
 
 
 Review request for kde-workspace and Plasma.
 
 
 Bugs: 317066
 http://bugs.kde.org/show_bug.cgi?id=317066
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 It is a proposed fix for bug 317066. The fix is a very simple one-liner 
 setting FullViewportUpdate mode for FdoGraphicsWidget. I'm aware 
 FullViewportUpdate has negative performance impact but I also know it 
 efficiently leaves out any graphical glitches happening due to no repaint of 
 widget when necessary (which is what the bug is about). I have tested my 
 solution for a couple of days: the bug no longer reproduced and I also didn't 
 see any noticeable performance problems. I'm still not sure what I propose is 
 acceptable since it may seem like a hack to more experienced developers, 
 however I just didn't want my patch attempt to get lost and forgotten in the 
 bugzilla. Please have a look and decide whether the patch is good enough to 
 be applied to the next bugfixing release of KDE 4.x series, thank you. 
 
 
 Diffs
 -
 
   plasma/generic/applets/systemtray/protocols/fdo/fdographicswidget.cpp 
 1baa23d 
 
 Diff: https://git.reviewboard.kde.org/r/114910/diff/
 
 
 Testing
 ---
 
 I rebuilt plasma_applet_systemtray.so with the patch and replaced the package 
 version with it (I'm on Linux Mint 16 KDE, x86_64, KDE 4.11.3). So far I can 
 no longer reproduce bug 317066 and I don't see any noticeable performance 
 problems of system tray applet. 
 
 
 Thanks,
 
 Dmitry Ivanov
 

Re: Review Request 118180: slideshow BUG patch fix

[Marco Martin]

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


modulo the indentation, it should be ok

- Marco Martin


On Giu. 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 Giu. 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: Review Request 118180: slideshow BUG patch fix

[Marco Martin]

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


seems the patch doesn't apply anymore, at least reviewboard complains about it

- Marco Martin


On Lug. 21, 2014, 1:12 p.m., TOM Harrison wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118180/
 ---
 
 (Updated Lug. 21, 2014, 1:12 p.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: KDE

[Marco Martin]

On Wednesday 02 July 2014, Ben Cooksley wrote:
 SVN commit 1392026 by bcooksley:
 
 Create new plasma-workspace-wallpapers module.
 As requested by Marco Martin in sysadmin ticket #996.
 CCMAIL: notm...@gmail.com
 CCMAIL: kde-core-devel@kde.org
 
  A plasma-workspace-wallpapers (directory)

thanks :)

-- 
Marco Martin

Re: Fwd: default wallpapers

[Marco Martin]

On Monday 30 June 2014, Marco Martin wrote:
 besides the breeze wallpaper, there will be 3 extra wallpapers shipped by
 default, that are the ones that won the contest.
 the real big question, is: *where to put them?* that's one I don't have an
 answer at the moment.
 seems that ideally would have to be a svn repository.. but if they are
 going to live in the future and not be shutdown altogether

I would do if is ok, in SVN
/trunk/KDE/plasma-workspace-wallpapers 

kde-wallpapers would continue to be what's distributed with kde 4.x revisions 
until there are any

is this ok for everybody?
are sysadmin powers needed for creating it?

-- 
Marco Martin

Fwd: default wallpapers

[Marco Martin]

Forwarding here as I was reminded that is more a kde-core-devel topic.

--  Forwarded Message  --

Subject: default wallpapers
Date: Monday 30 June 2014, 19:09:00
From: Marco Martin notm...@gmail.com
To: plasma-de...@kde.org

Hi all,
besides the breeze wallpaper, there will be 3 extra wallpapers shipped by 
default, that are the ones that won the contest.
the real big question, is: *where to put them?* that's one I don't have an 
answer at the moment.
seems that ideally would have to be a svn repository.. but if they are going 
to live in the future and not be shutdown altogether

-
-- 
Marco Martin

Re: Compatibility problems with latest GTK+ applications

[Marco Martin]

On Wednesday 07 May 2014 10:11:37 Martin Gräßlin wrote:

 * A hung window can no longer be closed or moved. Technical explanation:
 there is a ping protocol to detect hung applications. KWin only sends ping
 requests when the window is being closed from the window manager (e.g.
 decoration close button or Alt+F4).
 * quick tiling broken, see [1]. It includes the shadow in calculation.

Is this due to the motif hints?

 * Windows can no longer be put into window tabs
 * Dialogs don't have a close button [5] (unless run without compositing)

I think it's their HIG to not have buttons in dialogs

 * Ignores the configured mouse actions, uses (hard coded?) actions.
 Defaulting to lower window on middle click while we use window tab drag on
 middle click * no visual distinction between active and inactive
 application
 * Broken window snapping: window snaps to shadow [7]
 * Mismatching application window menu [8]. Note our menu could be invoked
 through DBus. I consider this as a big problem as that's the only way to
 e.g. add windows to activities (which is also broken now) or to access the
 advanced window manager features GNOME doesn't know of.
 
 That list I figured out in less than 10 min usage of a new GTK+ application.
 I assume and fear that the list is much longer.
 
 Any advice on how to handle this situation is appreciated.

I'm not really sure what to say..
I see pretty much two options:
* bending and fix the support for csd as much as possible at least on kwin5 
(at least supporting the required hints)
* leaving it as is, giving them a last occasion to fix support for non csd 
windowmanagers, and if this last attempt at communicating fails (likely)
simply exposing and making noise about it, that is sad and will work not much, 
but still..

-- 
Marco Martin

Re: Compatibility problems with latest GTK+ applications

[Marco Martin]

On Wednesday 07 May 2014 10:11:37 Martin Gräßlin wrote:

 * A hung window can no longer be closed or moved. Technical explanation:
 there is a ping protocol to detect hung applications. KWin only sends ping
 requests when the window is being closed from the window manager (e.g.
 decoration close button or Alt+F4).
 * quick tiling broken, see [1]. It includes the shadow in calculation.

Is this due to the motif hints?

 * Windows can no longer be put into window tabs
 * Dialogs don't have a close button [5] (unless run without compositing)

I think it's their HIG to not have buttons in dialogs

 * Ignores the configured mouse actions, uses (hard coded?) actions.
 Defaulting to lower window on middle click while we use window tab drag on
 middle click * no visual distinction between active and inactive
 application
 * Broken window snapping: window snaps to shadow [7]
 * Mismatching application window menu [8]. Note our menu could be invoked
 through DBus. I consider this as a big problem as that's the only way to
 e.g. add windows to activities (which is also broken now) or to access the
 advanced window manager features GNOME doesn't know of.
 
 That list I figured out in less than 10 min usage of a new GTK+ application.
 I assume and fear that the list is much longer.
 
 Any advice on how to handle this situation is appreciated.

I'm not really sure what to say..
I see pretty much two options:
* bending and fix the support for csd as much as possible at least on kwin5 
(at least supporting the required hints)
* leaving it as is, giving them a last occasion to fix support for non csd 
windowmanagers, and if this last attempt at communicating fails (likely)
simply exposing and making noise about it, that is sad and will work not much, 
but still..

-- 
Marco Martin

Re: KDE Frameworks Release Cycle

[Marco Martin]

On Sunday 27 April 2014, Kevin Ottens wrote:
 Of course, going with this type of cycle comes with some price of its own:
  * Features in released modules can only be introduced in a very fine
 grained way so as to not jeopardize the stability;

on one hand I'll probably miss feature branches, on the other hand, I really 
like the discipline that this methos requires, it may well drive to a good 
quality increase

-- 
Marco Martin

Re: KF5 Maintainers: Please get ready for release

[Marco Martin]

On Sunday 27 April 2014, Kevin Ottens wrote:
 Marco Martin:
  - kdeclarative
  - plasma-framework

I think it's pretty fine on my part, i'll take another review on the metadata 
files.
one thing I think i need are toplevel bugzilla products for each framework, 
right?
(if so i'll open a sysadmin request about it)


-- 
Marco Martin

Re: Review Request 113885: 3 types of blur

[Marco Martin]

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

(Updated Jan. 25, 2014, 2:23 p.m.)


Status
--

This change has been discarded.


Review request for kdelibs and kwin.


Repository: kdelibs


Description
---

To enhance readability, not only blur the background, but if the right x 
property is provided, either make the color of the pixels lighter or darker, 
decreasing the contrast a lot.
This is different from just making the window more opaque, since it doesn't 
cover the information about color, but just information about contrast, making 
the end result better looking.
This is the kdelibs facing part of http://git.reviewboard.kde.org/r/113884/


Diffs
-

  tier1/kwindowsystem/src/kwindoweffects.h 78195ac 
  tier1/kwindowsystem/src/kwindoweffects_dummy.cpp ce3b9bf 
  tier1/kwindowsystem/src/kwindoweffects_x11.cpp 9e3fba7 

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


Testing
---


Thanks,

Marco Martin

Re: Splitting kde-workspace and kde-runtime proposal

[Marco Martin]

On Tuesday 21 January 2014 13:04:22 Sebastian Kügler wrote:
  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.

just instinctively i would say that the more splitting the more not my 
problem, i'll ignore this bit scenario it may cause

-- 
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:
 About 2 months ago we started to draft Baloo [1], a metadata solution
 that
 will cover the bare necessities of each use case we have.
 
 I'd like to avoid getting into the technical details of the implementation
 in this thread. Another thread can be started about its different aspects
 once
 you've read the basic ideas behind Baloo [2]

First of all, I'm happy an alternative solution to virtuoso exists and is 
already at such advanced stage. Those days I was playing with nepomuk (among 
the other things) on ARM and the performance was a bit worrying.. however with 
this moving forward, I'm a good deal less worried now :D


That said, I fear there may be features that get lost, especially for active, 
I'll discuss those in the appropriate branch of the thread

Cheers,
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:
 On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote:
   If we all decide to store stuff in sqlite, then it doesn't matter if
   they are separate database files or the same one.
  
  I might be missing a few things here, but asking questions is the road to
  enlightenment :)
  
  - There is no way to query across different stores, which was the main
  appeal of nepomuk? (I concluded this from the last mail)
 
 There isn't one. Not right now. I'm open to ideas on how to do something
 like if it is required. I'm slightly skeptical if it actually is required.

- query attachments saved on disk sent by $person?
- tags or activities  associations
- 

  - When querying, how do I get the properties of the results?
 
 You don't. You just get the identifier and some text. You can do a
 subsequent fetch job to get additional data.

ouch, if i have to display a lot of results that looks very heavy, and a loot 
of jobs, just a bit worried about that


  From my POV, it would be much nicer if you forced a single db (as an
  actual store, not as a cache like nepomuk is for akonadi) on the people,
  with the option to have a few things runtime defined. It would ease the
  development and would allow more fun queries which would be optimized
  unlike the manual client-side joining of different query results.
 
 But what if one doesn't use SQL for storing data? IMO Xapian is much better
 suited that sqlite's FTS support (or mysql).
 

Xapian is just for files indexing, right? (and no, file indexing with sqlite 
would blow up in a nuclear explosion;)

what i would see is a central sqlite db with just relations between stuff.
* tag/anything (being file, email, whatever)
* activity/anything
* anything/anything (so explicit relation between contanct and file for 
instance)

that sqlite db makes sense being sqlite since the amount of data in it would 
probably stay pretty limited (mostly relations hand made, anyways around 
hundreds of items max vs the hundred thousands of the file index for instance)

then the actual file metadata, email metadata etc can be stored wherever

is also important having more flexible queries, like sql directly exposed (in 
plasma active i *need* to have group by, that's the reason we used directly 
sparql in some queries)

Cheers,
Marco Martin

Re: Nepomuk in 4.13 and beyond

[Marco Martin]

On Thursday 12 December 2013, Vishesh Handa wrote:

  what you describe is amazingly similar to the system Wheeler and I came
  up with during the very first Akademy. if you’re ever interested in what
  ever became of that, remind me over a coffee/beer sometime and i’ll put
  on my old-man pants and recount the ol’ days. ;)
 
 Sure. Plasma sprint.

/me will just drop a name that will give a little tear to the oldies..
Tenor ;)

 Disable Nepomuk (System settings) and install Baloo. It should startup on
 boot, otherwise you can run the baloo_file process.
 
 Most of the PIM side is already integrated, but the patches still have to
 be pushed. (I'll push them into a clone) I've started working on porting
 Dolphin, but I need to talk with Frank.
 
 What exactly do you want to integrate?

Most pressing for us is the porting of that nepomuk model in plasma active 
(then depending on how the model may keep external facing api unchanged or not 
may magically port a lot of stuff.. or not)

main things the nepomuk model is used for:
* Activities: showing in the homescreen resources linked to an activity, 
grouped by type
* File browser application:
** show files by type (like all images, all documents..)
** to that, add a filter by tag or by date
** to display tags and dates, we need a group by: to have a kind of tag cloud 
and to quickly compare for instance how many photos were taken in May as 
opposed to April
* SLC: acts of connecting something to an activity, assigning a tag, assigning 
a rating, adding a bookmark (in active bookmarks are stored in nepomuk too)

* Plasma media center: pretty much the same requirements

  what is the Baloo equivalent of the Nepomuk API currently in kdelibs?
  (i’ve looked in the ballo repo, it isn’t clear at first glance)
 
 There isn't a clear Resource API any more. There is a nice query API - take
 a look at baloo/src/core/query.h / term.h. There are some examples in
 the autotests directory.

I would be happy even with just a way to have something that makes very easy 
to access even just a variant map of properties (ugh, i guess that tells I'm 
doing way too much javascript lately :p)

Cheers, 
Marco Martin

Re: Review Request 113885: 3 types of blur

[Marco Martin]

 On Nov. 20, 2013, 12:21 p.m., Fredrik Höglund wrote:
  tier1/kwindowsystem/src/kwindoweffects.h, line 143
  http://git.reviewboard.kde.org/r/113885/diff/1/?file=214306#file214306line143
 
  An unfortunate side effect of this is that this API becomes 
  incompatible with the equivalent API on Windows.
 

so on windows the parameter would have to be a no-op, that yeah, is not 
beautiful


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113885/#review44042
---


On Nov. 15, 2013, 2:54 p.m., Marco Martin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113885/
 ---
 
 (Updated Nov. 15, 2013, 2:54 p.m.)
 
 
 Review request for kdelibs and kwin.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 To enhance readability, not only blur the background, but if the right x 
 property is provided, either make the color of the pixels lighter or darker, 
 decreasing the contrast a lot.
 This is different from just making the window more opaque, since it doesn't 
 cover the information about color, but just information about contrast, 
 making the end result better looking.
 This is the kdelibs facing part of http://git.reviewboard.kde.org/r/113884/
 
 
 Diffs
 -
 
   tier1/kwindowsystem/src/kwindoweffects.h 78195ac 
   tier1/kwindowsystem/src/kwindoweffects_dummy.cpp ce3b9bf 
   tier1/kwindowsystem/src/kwindoweffects_x11.cpp 9e3fba7 
 
 Diff: http://git.reviewboard.kde.org/r/113885/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Marco Martin
 

Review Request 113885: 3 types of blur

[Marco Martin]

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

Review request for kdelibs and kwin.


Repository: kdelibs


Description
---

To enhance readability, not only blur the background, but if the right x 
property is provided, either make the color of the pixels lighter or darker, 
decreasing the contrast a lot.
This is different from just making the window more opaque, since it doesn't 
cover the information about color, but just information about contrast, making 
the end result better looking.
This is the kdelibs facing part of http://git.reviewboard.kde.org/r/113884/


Diffs
-

  tier1/kwindowsystem/src/kwindoweffects.h 78195ac 
  tier1/kwindowsystem/src/kwindoweffects_dummy.cpp ce3b9bf 
  tier1/kwindowsystem/src/kwindoweffects_x11.cpp 9e3fba7 

Diff: http://git.reviewboard.kde.org/r/113885/diff/


Testing
---


Thanks,

Marco Martin

Re: Adopting AppData in KDE?

[Marco Martin]

On Wednesday 06 November 2013 00:04:47 Matthias Klumpp wrote:
 Btw, thinks like Plasmoids might make sense to be only displayed on
 KDE, because they aren't useful on GNOME (same applies for GNOME-Shell
 Extensions on KDE). If these things would be treated as applications
 in software-centers, I could add a type=plasmoid /
 gnome-shell-extension to the AppStream spec (we'd still have to
 solve the icon-source case, but that's rather trivial).

Bodega can have different stores that can be 99% the same except some little 
detail, like a category only present in a store and not the others, this was 
done to give each device its own store.
So stores are done in a way that the definition of a store takes very little 
space in the database and is very fast to clone (and if the same category is 
in multiple stores items in it stay in sync between stores)

cheers,
Marco Martin

Re: Adopting AppData in KDE?

[Marco Martin]

On Saturday 02 November 2013 15:06:26 Aaron J. Seigo wrote:
 On Saturday, November 2, 2013 14:35:10 Matthias Klumpp wrote:
 What I see as truly invaluable in AppStream is standardizing the metadata
 for Free software applications. It is something Bodega will undoubtedly
 benefit from as well.

just to throw in another idea, since assets have pretty much all that data, 
those metatada files could be generated from existing asset data as well, even 
tough for all assets  that aren't a package in a repository becomes kinda a 
pointless exercise at this stage...

   use cases (not to mention more general web based ones) unserviced.
  
  Can you please clarify what AppStream is missing for mobile?
 
 Ignoring the lack of UI (that’s fixable): non-repository  based listings and
 installation, anything that isn’t an application.

on the other hand a bit that may be useful for us is the part of installing 
from repositories and a semi-automated import of assets based on the metadata 
of existing applications

Cheers,
Marco Martin

Re: QML-using app developers: use private.* imports

[Marco Martin]

On Thursday 26 September 2013 02:23:31 Aleix Pol wrote:

 The question would be then, why is it that there's some API that's only
 needed for internal usage? If it's needed internally, it will be most
 likely needed externally, at some point. The fact that you decide to label
 it as private makes frustrated developers.
 
 Either way, I have no idea of what we're talking about here. :D

is the fact that the most feasible way to bridge the c++ of an app and the qml 
part is trough imports.
you once told me you did some imports for use in muon for instance, 
and while there may be some parts of those that does have an use outside that 
application for everybody to use, all of it surely isn't, being its use just 
bridge functionality of that particular application, and that's fine.

However, i would like everything in org.kde.* to be considered a library, with 
all the requirements of api stability for the entire lifecycle, and requiring 
this kind of discipline from all random developers is simply not realistic.

then, of course if an app developer decides that a part of his private.foo may 
make sense for everybody to use can always move it, but by accepting all the 
social contract that maintaining a library means

-- 
Marco Martin

Re: Review Request 112128: Fix plasmapkg -t theme -r ThemeName to actually uninstall the theme.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112128/#review38285
---

Ship it!


looks good to me

- Marco Martin


On Aug. 17, 2013, 3:03 a.m., Jeremy Paul Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/112128/
 ---
 
 (Updated Aug. 17, 2013, 3:03 a.m.)
 
 
 Review request for kde-workspace, Plasma, Aaron J. Seigo, Marco Martin, and 
 Sebastian Kügler.
 
 
 Description
 ---
 
 Currently uninstallation of plasma themes is very broken for a couple of 
 reasons. One reason is that the tar packages downloaded from kde-look and 
 other kns services contain a subfolder with the theme name, that then 
 contains the metadata.desktop file that plasma::PackageStructure looks for in 
 order to uninstall or install a plugin. The other problem is that themes 
 aren't really plugins, so plasmapkg -t theme -r blah fails.  This patch fixes 
 the second issue. I'll upload another patch for review that fixes the first 
 issue.
 
 
 Diffs
 -
 
   plasma/tools/plasmapkg/main.cpp 6a2982b292ec9736710f4b41dcaa0cbff3986c46 
 
 Diff: http://git.reviewboard.kde.org/r/112128/diff/
 
 
 Testing
 ---
 
 Plasma themes correctly uninstall here with this and my other patch.
 
 
 Thanks,
 
 Jeremy Paul Whiting
 

Re: Review Request 112129: Make Plasma::PackageStructure look for metadata.desktop files in only subfolder of extracted plasmapkg archives

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112129/#review38015
---


Hmm, not sure about it, the packages were defined as archives with 
metadata.desktop in the root, this would basically allow a quirks mode, do we 
want to support malformed packages?

- Marco Martin


On Aug. 17, 2013, 3:06 a.m., Jeremy Paul Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/112129/
 ---
 
 (Updated Aug. 17, 2013, 3:06 a.m.)
 
 
 Review request for kde-workspace, Plasma, Aaron J. Seigo, Marco Martin, and 
 Sebastian Kügler.
 
 
 Description
 ---
 
 This is the other half of the fix for the listed bug.  I made 
 Plasma::PackageStructure::metadata look in the only subdirectory of an 
 extracted archive if there's only one subdirectory for the metadata.desktop 
 file.
 
 
 This addresses bug https://bugs.kde.org/show_bug.cgi?id=149479.
 
 http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=149479
 
 
 Diffs
 -
 
   plasma/packagestructure.cpp 71148e1a18227d9ca847cbffe385d9c66c6b 
 
 Diff: http://git.reviewboard.kde.org/r/112129/diff/
 
 
 Testing
 ---
 
 The bug is fixed here with this and my other patch. Any better ideas for 
 getting the only subdirectory are welcome, it feels a bit kludgy as is.
 
 
 Thanks,
 
 Jeremy Paul Whiting
 

Re: Review Request 111992: Activity bar in QML.

[Marco Martin]

 On Aug. 12, 2013, 8:50 a.m., Marco Martin wrote:
  plasma/generic/applets/activitybar/package/contents/ui/main.qml, line 37
  http://git.reviewboard.kde.org/r/111992/diff/5/?file=178116#file178116line37
 
  whitespace s your friend
  
  for (i=0; iactivitySource.sources.length; i++) {

even better, 
for (i = 0; i  activitySource.sources.length; i++) {


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111992/#review37558
---


On Aug. 12, 2013, 3:14 a.m., Bhushan Shah wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/111992/
 ---
 
 (Updated Aug. 12, 2013, 3:14 a.m.)
 
 
 Review request for kde-workspace and Marco Martin.
 
 
 Description
 ---
 
 Activity bar applet ported in QML.
 
 
 Diffs
 -
 
   plasma/generic/applets/activitybar/CMakeLists.txt 51a2edb 
   plasma/generic/applets/activitybar/Messages.sh e73df21 
   plasma/generic/applets/activitybar/activitybar.h b95cb0c 
   plasma/generic/applets/activitybar/activitybar.cpp e66bf04 
   plasma/generic/applets/activitybar/package/contents/ui/main.qml 
 PRE-CREATION 
   plasma/generic/applets/activitybar/package/metadata.desktop PRE-CREATION 
   plasma/generic/applets/activitybar/plasma-applet-activitybar.desktop 
 b7155de 
 
 Diff: http://git.reviewboard.kde.org/r/111992/diff/
 
 
 Testing
 ---
 
 Works, Tested in plasmoidviewer and desktop
 
 
 Thanks,
 
 Bhushan Shah
 

Re: Review Request 111992: Activity bar in QML.

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111992/#review37558
---



plasma/generic/applets/activitybar/package/contents/ui/main.qml
http://git.reviewboard.kde.org/r/111992/#comment27755

should avoid sizes in pixels, using units.gridUnit is preferred



plasma/generic/applets/activitybar/package/contents/ui/main.qml
http://git.reviewboard.kde.org/r/111992/#comment27754

this will break on panels less than 30 px tall



plasma/generic/applets/activitybar/package/contents/ui/main.qml
http://git.reviewboard.kde.org/r/111992/#comment27756

whitespace s your friend

for (i=0; iactivitySource.sources.length; i++) {



plasma/generic/applets/activitybar/package/contents/ui/main.qml
http://git.reviewboard.kde.org/r/111992/#comment27757

Here there is an old issue of TabBar that should be addressed one day or 
another..

it doesn't support vertical formfactors, in a vertical panel will just 
break. For now, even if will look rather terrible in that case the tabbar 
should probably just be rotated 90°


- Marco Martin


On Aug. 12, 2013, 3:14 a.m., Bhushan Shah wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/111992/
 ---
 
 (Updated Aug. 12, 2013, 3:14 a.m.)
 
 
 Review request for kde-workspace and Marco Martin.
 
 
 Description
 ---
 
 Activity bar applet ported in QML.
 
 
 Diffs
 -
 
   plasma/generic/applets/activitybar/CMakeLists.txt 51a2edb 
   plasma/generic/applets/activitybar/Messages.sh e73df21 
   plasma/generic/applets/activitybar/activitybar.h b95cb0c 
   plasma/generic/applets/activitybar/activitybar.cpp e66bf04 
   plasma/generic/applets/activitybar/package/contents/ui/main.qml 
 PRE-CREATION 
   plasma/generic/applets/activitybar/package/metadata.desktop PRE-CREATION 
   plasma/generic/applets/activitybar/plasma-applet-activitybar.desktop 
 b7155de 
 
 Diff: http://git.reviewboard.kde.org/r/111992/diff/
 
 
 Testing
 ---
 
 Works, Tested in plasmoidviewer and desktop
 
 
 Thanks,
 
 Bhushan Shah
 

Review Request 110482: Move KStatusNotifierItem in KNotifications

[Marco Martin]

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

Review request for kdelibs.


Description
---

This implemets a step in the kdeui crumble epic.

moves the classes kstatusnotifieritem and knotificationsrestrictions in the 
knotifiactions library.

The patch works, but there are still several issues:
* porting from kdebug to qdebug loses the area number
* adds some link libraries: the classes add ki18n, kwidgets and KWidgetsAddons
* the test adds ki18n kde4support kdecore
* the KActionCollection becomes a qhash of actions: how should be 
kactioncollections ported?

I guess it should use the qt translation system, and redo the quit dialog to 
not usekstandardgui at all?


Diffs
-

  kdeui/CMakeLists.txt cfa29ef 
  kdeui/tests/CMakeLists.txt cd055d5 
  staging/knotifications/src/CMakeLists.txt 266b67c 
  staging/knotifications/src/knotificationrestrictions.cpp a396fd6 
  staging/knotifications/src/kstatusnotifieritem.h be21882 
  staging/knotifications/src/kstatusnotifieritem.cpp 37abe7e 
  staging/knotifications/src/kstatusnotifieritemdbus_p.cpp 6c9e1da 
  staging/knotifications/src/kstatusnotifieritemprivate_p.h 32e7906 
  staging/knotifications/tests/CMakeLists.txt 2240a69 
  staging/knotifications/tests/kstatusnotifieritemtest.cpp 38e85ac 

Diff: http://git.reviewboard.kde.org/r/110482/diff/


Testing
---


Thanks,

Marco Martin

Re: Review Request 110482: Move KStatusNotifierItem in KNotifications

[Marco Martin]

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

(Updated May 17, 2013, 12:11 p.m.)


Review request for kdelibs.


Description
---

This implemets a step in the kdeui crumble epic.

moves the classes kstatusnotifieritem and knotificationsrestrictions in the 
knotifiactions library.

The patch works, but there are still several issues:
* porting from kdebug to qdebug loses the area number
* adds some link libraries: the classes add ki18n, kwidgets and KWidgetsAddons
* the test adds ki18n kde4support kdecore
* the KActionCollection becomes a qhash of actions: how should be 
kactioncollections ported?

I guess it should use the qt translation system, and redo the quit dialog to 
not usekstandardgui at all?


Diffs
-

  kdeui/CMakeLists.txt cfa29ef 
  kdeui/tests/CMakeLists.txt cd055d5 
  staging/knotifications/src/CMakeLists.txt 266b67c 
  staging/knotifications/src/knotificationrestrictions.cpp a396fd6 
  staging/knotifications/src/kstatusnotifieritem.h be21882 
  staging/knotifications/src/kstatusnotifieritem.cpp 37abe7e 
  staging/knotifications/src/kstatusnotifieritemdbus_p.cpp 6c9e1da 
  staging/knotifications/src/kstatusnotifieritemprivate_p.h 32e7906 
  staging/knotifications/tests/CMakeLists.txt 2240a69 
  staging/knotifications/tests/kstatusnotifieritemtest.cpp 38e85ac 

Diff: http://git.reviewboard.kde.org/r/110482/diff/


Testing
---


Thanks,

Marco Martin

Re: Review Request 110118: wrong path for plugin. ( doubling the plugin address cause the basepath to )

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110118/#review31957
---

Ship it!


Ship It!

- Marco Martin


On April 21, 2013, 6:18 p.m., Ömer Fadıl Usta wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/110118/
 ---
 
 (Updated April 21, 2013, 6:18 p.m.)
 
 
 Review request for kde-workspace, Aaron J. Seigo and Marco Martin.
 
 
 Description
 ---
 
 plasma-desktop(7470)/libplasma Plasma::PackageStructure::setPath: 
 /home/usta/kde/inst/master/share/apps/plasma/packages/org.kde.desktop.activitymanager//org.kde.desktop.activitymanager
  invalid, basePath is 
 
 it resets basePath due to double pluginname at the end of path.
 
 
 Diffs
 -
 
   plasma/desktop/shell/activitymanager/activitymanager.cpp 2ecb30d 
 
 Diff: http://git.reviewboard.kde.org/r/110118/diff/
 
 
 Testing
 ---
 
 After this patch that warning about invalid path is gone. I have checked that 
 package-path() returning correct address now.
 
 
 Thanks,
 
 Ömer Fadıl Usta
 

Re: Review Request 108860: Plasma QML Components: trigger appearAnimation in InlineDialog properly

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108860/#review26966
---

Ship it!


Ship It!

- Marco Martin


On Feb. 8, 2013, 4:01 p.m., Sebastian Gottfried wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/108860/
 ---
 
 (Updated Feb. 8, 2013, 4:01 p.m.)
 
 
 Review request for KDE Runtime and Marco Martin.
 
 
 Description
 ---
 
 Use `appearAnimation.restart()` instead of `appearAnimation.running = true` 
 to trigger the open/close animation. In the old version it is impossible to 
 open or close the dialog while it is still appearing or disappearing since 
 the old animation simply continues to run.
 
 
 Diffs
 -
 
   plasma/declarativeimports/plasmacomponents/qml/private/InlineDialog.qml 
 2b7b832 
 
 Diff: http://git.reviewboard.kde.org/r/108860/diff/
 
 
 Testing
 ---
 
 Tested within KTouch. Works as expected.
 
 
 Thanks,
 
 Sebastian Gottfried
 

Re: Plans for SVN infrastructure shutdown

[Marco Martin]

On Wednesday 02 January 2013, Nicolás Alvarez wrote:
 The initial draft of the SVN shutdown plan is available on the community
 wiki: http://community.kde.org/Sysadmin/SVNInfrastructureShutdown
 
 As you can see this is a long-term plan. None of this is written in
 stone; any feedback is welcome!

Is this still the active plan?
in plasma we have some stuff into svn, kept here because git doesn't work that 
well, basically artwork:
kde-artwork
kde-wallpapers
kde-artwork-active

all of that can be moved, but will probably be among most problematic 
repositories that still have to be migrated.. suggestions for those?

Cheers,
Marco Martin

Re: New lockscreen

[Marco Martin]

On Friday 11 January 2013, Martin Sandsmark wrote:
 On Thu, Jan 10, 2013 at 09:46:11PM +0100, Marco Martin wrote:
  311571 and 312427 should be fixed now
 
 Thanks!
 
  some bugs seems easy, some i can'r reproduce them at all.
 
 Which ones can't you reproduce? I can look at them this evening.

311188 since i don't have a a multiscreen setup at the moment

difference between 312427 and 311033 (but then he confirmed that he had 
xscreensaver enabled as well so they're actually duplicates)

in 36 here works in the case a screensaver is enabled (ie esc shows the 
screensaver again)

this i can reproduce, i don't know much yet how to fix:
310611 (accelerators)
that's probably the only actual serious bug in that list, together focus in 
mukti monitor


  however not all of those are valid i think (the concept is: is a
  screenlocker, not a screensaver anymore, thus makes behavior changes)
 
 Well, the old one managed to be both, so IMHO if we remove features it is a
 regression (though which ones are you talking about?).

the first plan (that i think would still have the better way to go, especially 
in the optic of preparing for wayland) was to remove the screensaver 
altogether, it was re-added afterwards due to many requests

Cheers,
Marco Martin

Re: New lockscreen

[Marco Martin]

On Friday 11 January 2013, Martin Gräßlin wrote:
 On Friday 11 January 2013 09:28:19 Martin Sandsmark wrote:
  Well, the old one managed to be both, so IMHO if we remove features it is
  a regression (though which ones are you talking about?).
 
 no, removing features is not a regression. It is the decision to remove the
 feature. The use case for screen savers does no longer exist or when did
 you last have a screen which needs to be saved? For background reading I
 recommend [1].

for screen health, both a powermanagement timeout, or running xscreensaver as 
a separate daemon are still supported

-- 
Marco Martin

Re: New lockscreen

[Marco Martin]

On Thursday 10 January 2013, Martin Sandsmark wrote:
 Hi!
 
 The new lock screen has some more or less serious regressions, and doesn't
 seem to be maintained by anyone in particular (one of the regression bugs
 filed against it is from november, and I don't really see anyone in
 particular commenting or fixing anything, it only got a handful of commits
 in december).
 
 So, who is supposed maintain this new screenlocker? In its current state it
 provides nothing new over the old lock screen (for users), but has about a
 dozen (12 filed ones, maybe more unreported ones?) regressions.
 
 A list of the current regressions are available here:
 https://bugs.kde.org/buglist.cgi?product=kscreensavercomponent=locker-qml;
 bug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=ASSIGNEDbug_status=
 REOPENEDlist_id=384099

311571 and 312427 should be fixed now

some bugs seems easy, some i can'r reproduce them at all.

however not all of those are valid i think (the concept is: is a screenlocker, 
not a screensaver anymore, thus makes behavior changes)

Cheers, 
Marco Martin