Re: Breeze and ECM are incompatible for installing icons

[David Jarvie]

On 4 November 2023 14:53:42 GMT, Sune Vuorela  wrote:
> On 2023-11-03, David Jarvie  wrote:
> > I wanted to provide an icon that is visually compatible with the Breeze 
> > theme, and Breeze doesn't supply it.
> 
> Did you consider submitting it to breeze ?
> 
> I have heard they don't bite that much ...

Thanks, Sune, I'll try that. It is one solution to my specific issue, but the 
general issue still remains.
--
David Jarvie
KAlarm author, KDE developer

Re: Breeze and ECM are incompatible for installing icons

[David Jarvie]

On 3 November 2023 22:47:55 GMT, Albert Astals Cid  wrote:
> El divendres, 3 de novembre de 2023, a les 13:15:37 (CET), David Jarvie va 
> escriure:
> > On 3 November 2023 09:13:15 GMT, Carl Schwan  wrote:
> > > On Friday, November 3, 2023 12:46:20 AM CET Albert Astals Cid wrote:
> > > > El dijous, 2 de novembre de 2023, a les 14:36:16 (CET), David Jarvie va
> > > > 
> > > > escriure:
> > > > > Breeze installs its icons in a different directory structure from
> > > > > other
> > > > > icon themes, with the result that the ECM cmake command
> > > > > ecm_install_icons
> > > > > doesn't work for Breeze icons. The only way to install an application
> > > > > specific Breeze icon is to hard code its location, for example
> > > > > "${KDE_INSTALL_ICONDIR}/breeze/actions/22/".
> > > > 
> > > > Why are you installing icons in breeze icon theme if you're not the
> > > > breeze
> > > > icon theme?
> > 
> > I wanted to provide an icon that is visually compatible with the Breeze
> > theme, and Breeze doesn't supply it.
> 
> What if another application wants to supply an icon with the same name that 
> is 
> also visually compatible with the Breeze theme?
> 
> Should it overwrite the one that your application provides?

Perhaps I should rename the icon to include the application name to avoid 
possible conflicts.

There is always the potential for name conflicts, but that doesn't change the 
issue, which is that applications (KDE or third party) should be able to 
correctly install icons for any icon theme which is known to KDE, at least, 
using ecm_install_icons.

> > > > Seems wrong to me.
> > > 
> > > Yes, it's wrong. We made the same mistake in Tokodon and the correct way
> > > to do it is to install in the hicolor theme. This allow the theme to
> > > overwrite the icon if they want and don't force you to hardcode the
> > > breeze icon theme.
> > Third party applications are quite entitled to install their own icons in
> > the Breeze theme, and currently this won't work using the ECM function.
> > This issue doesn't just apply to applications which are part of KDE.

--
David Jarvie
KAlarm author, KDE developer

Re: Breeze and ECM are incompatible for installing icons

[David Jarvie]

On 3 November 2023 09:13:15 GMT, Carl Schwan  wrote:
> On Friday, November 3, 2023 12:46:20 AM CET Albert Astals Cid wrote:
> > El dijous, 2 de novembre de 2023, a les 14:36:16 (CET), David Jarvie va
> > 
> > escriure:
> > > Breeze installs its icons in a different directory structure from other
> > > icon themes, with the result that the ECM cmake command ecm_install_icons
> > > doesn't work for Breeze icons. The only way to install an application
> > > specific Breeze icon is to hard code its location, for example
> > > "${KDE_INSTALL_ICONDIR}/breeze/actions/22/".
> > 
> > Why are you installing icons in breeze icon theme if you're not the breeze
> > icon theme?

I wanted to provide an icon that is visually compatible with the Breeze theme, 
and Breeze doesn't supply it.

> > Seems wrong to me.
> 
> Yes, it's wrong. We made the same mistake in Tokodon and the correct way to 
> do 
> it is to install in the hicolor theme. This allow the theme to overwrite the 
> icon if they want and don't force you to hardcode the breeze icon theme.

Third party applications are quite entitled to install their own icons in the 
Breeze theme, and currently this won't work using the ECM function. This issue 
doesn't just apply to applications which are part of KDE.

--
David Jarvie
KAlarm author, KDE developer

Breeze and ECM are incompatible for installing icons

[David Jarvie]

Breeze installs its icons in a different directory structure from other icon 
themes, with the result that the ECM cmake command ecm_install_icons doesn't 
work for Breeze icons. The only way to install an application specific Breeze 
icon is to hard code its location, for example 
"${KDE_INSTALL_ICONDIR}/breeze/actions/22/". I raised a bug against ECM about 
this, but not unexpectedly it has been rejected as a Breeze issue (see 
https://bugs.kde.org/show_bug.cgi?id=476208).

Fixing this in Breeze would obviously be a significant change for Breeze, but 
having a non-working ecm_install_icons function isn't really acceptable. This 
should ideally be fixed one way or the other in time for the KF6 release.
--
David Jarvie
KAlarm author, KDE developer

Re: Opening files by mimetype instead of by file extension

[David Jarvie]

On Wednesday 10 Jun 2020 00:52:16 Albert Astals Cid wrote:
> As far as I can see QFileDialog only supports listing by file extension.
> 
> On the other hand it seems in GTK+ land you can get an open file dialog
> listing by mimetype, so I've got one bug about "you're worse than XXX
> because you can't do this"
> 
> Is there something we could do at the KDE Frameworks level to support this
> feature?
> 
> Or should this be done in Qt?

KFileCustomDialog lists by mimetype.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

Re: Updating our coding conventions and coding style for C++11

[David Jarvie]

On Thursday 16 Jan 2020 18:46:06 Kai Uwe Broulik wrote:
> Hi,
> 
> for "auto" I think we should always annotate it with const, *, and/or &
> where appropriate:
> 
> auto *something = new MyCustomType;
> auto *keyEvent = static_cast(event);
> const auto myList = QStringList({QLatin1String("FooThing"),
> QLatin1String("BarThing")});

This is a bad example of the use of auto. It can be more simply written 
without using auto:

const QStringList myList{QLatin1String("FooThing"),
QLatin1String("BarThing")};

> auto  = foo[bar];
> 
> > The common practice used in KDE seems to be:
> >  for (a:b)
> 
> +1
> 
> Cheers
> Kai Uwe

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

Re: New framework: KCalCore

[David Jarvie]

On 15 April 2019 13:25:56 BST, Allen Winter  wrote:
> On Monday, April 15, 2019 6:40:06 AM EDT Daniel Vrátil wrote:
> > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote:
> > > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote:
> > > > On 14 April 2019 12:31:41 BST, David Faure 
> wrote:
> > > > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I'd like to propose KCalCore for review to move from KDE PIM
> to KF5.
> > > > > > 
> > > > > > KCalCore is an implementation of the iCalendar standard
> based on
> > > > > 
> > > > > libical,
> > > > > 
> > > > > I wonder about the name, which doesn't mean much outside the
> circle of
> > > > > PIM people. Shouldn't this be called KCalendar ?
> > > > > 
> > > > > If the "Core" simply means non-GUI, we certainly don't have
> that word
> > > > > in every non-GUI framework.
> > > > 
> > > > Renaming makes sense. KCalendar suggests it could be about
> calendar
> > > > systems,
> > > Indeed.
> > > 
> > > > so to avoid that confusion, perhaps call it KiCalendar?
> > > 
> > > Doesn't read very well
> > > I would want to say KCalendarEvents but I guess the more correct
> generic
> > > term would be KCalendarIncidences ... not convicing either.
> > > 
> > > Maybe KCal is enough? Reminds of iCal.
> > 
> > Wasn't KCal the original name of the library from pre-Akonadi times?
> KCalCore 
> > was a fork of KCal with the pre-Akonadi "Resources" system
> removed...
> > 
> Yep.  Back to the Future.  Let's stay away from "KCal" and "KCalendar"
> 
> commit 6b4c1896211075fcd0b88b2c617eaacd831c9f6d
> Author: Allen Winter 
> Date:   Sat Jul 17 17:00:14 2010 +
> 
> Add the new KCalCore library.
> 
>  The KCalCore library deprecates and mostly replaces the KCal library.
> KCalCore is free of any relation to the old Calendar resources and
> focuses entirely on iCalendar and vCalendar storage and data
> manipulation.
>  KCalCore used QSharedPointers for safe memory access, is free of i18n
>  strings and contains no methods for user interaction: KCalCore is all
> about the calendar data.

Would KCalendarSerialization be a better name? I think that sums up its purpose.

--
David Jarvie
KAlarm author, KDE developer
http://www.astrojar.org.uk/kalarm

Re: New framework: KCalCore

[David Jarvie]

On 14 April 2019 12:31:41 BST, David Faure  wrote:
> On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote:
> > Hi,
> > 
> > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > 
> > KCalCore is an implementation of the iCalendar standard based on
> libical,
> 
> I wonder about the name, which doesn't mean much outside the circle of
> PIM people. Shouldn't this be called KCalendar ?
> 
> If the "Core" simply means non-GUI, we certainly don't have that word
> in every non-GUI framework.

Renaming makes sense. KCalendar suggests it could be about calendar systems, so 
to avoid that confusion, perhaps call it KiCalendar?

--
David Jarvie
KAlarm author, KDE developer
http://www.astrojar.org.uk/kalarm

Re: CI system maintainability

[David Jarvie]

On 28 March 2019 13:33:59 GMT, laurent Montel  wrote:
> Le jeudi 28 mars 2019, 09:29:22 CET Kevin Ottens a écrit :
> > Hello,
> > 
> > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote:
> > > Please note that the commits in this instance were pushed without
> > > review, so restrictions on merge requests wouldn't make a
> difference
> > > in this case unfortunately.
> > 
> > Maybe it's about time to make reviews mandatory... I know it's
> unpopular in
> > KDE, and I advocated for "don't force a tool if you can get someone
> to look
> > at your screen or pair with you" in the past. Clearly this
> compromise gets
> > somewhat exploited and that's especially bad in the case of a
> fragile and
> > central component like KDE PIM.
> > 
> > Regards.
> 
> Hi,
> 
> I am against to force mandatory review, as it will create a lot of
> lose of 
> time, and we will not be sure that review is correct (see comment from
> Volker 
> about "transaction lock regression")
> 
> It's necessary to having a big team for doing it.
> 
> Ok a repo was broken, but it was just that fix was created in master
> not 
> 19.04, I didn't see nobody on IRC told us "this package is always
> broken", 
> when I saw it this morning I just cherry pick (2 seconds for fixing
> it).
> 
> 
> For example I works all days on kde (pim or other) when I wake up, or
> at noon 
> after my lunch or the evening, I will not wait several days for a
> review 
> because nobody has time to do it. (we can see a review from zanshin
> for 
> example https://phabricator.kde.org/D16210 we can see that David
> waited 2 
> months until having an answer...).
> 
> (For example I make ~ 15 commits by days on pim/ruqola/framework, I
> don't want 
> to wait several days/weeks until someone wants to review my patchs)
> 
> I will not lose my time to review some code that I don't understand...
> I never 
> reviewed Akonadi patch as I don't understand this code, and I will
> take time 
> on it just for the pleasure as I prefer fixing bug or adding new
> features in 
> components that I maintain.
> 
> When we have a big team as Qt team it can help but in pim component
> where we 
> don't have any redundant guy, we will lose a lot of time.
> 
> So for each increase version for each package I will wait a review.
> For sure 
> not.
> 
> Each time that I will improve code as coding style I will wait that
> someone 
> wants to review...

I agree. Mandatory reviews might work if there is a team of active people 
working on a project, but if there is only one person with real knowledge of 
the code, or there is nobody else with much time to spare, who is going to do 
the review? It is likely to just sit waiting indefinitely. If getting code 
reviewed is too difficult, the developer may have to give up and abandon the 
project.

Mandatory reviewing could only work if individual projects can decide whether 
to adopt it or not.

--
David Jarvie
KAlarm author, KDE developer
http://www.astrojar.org.uk/kalarm

Re: Review Request 129709: Fix checking for valid date entered

[David Jarvie]

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

(Updated Dec. 31, 2016, 12:13 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and John Layt.


Changes
---

Submitted with commit 1550b2c83f4842eb491b906ff7029fc11fd07d8a by David Jarvie 
to branch master.


Repository: kwidgetsaddons


Description
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, and 
the minimum and maximum dates are not set, it is always considered invalid and 
the date is not changed.
- When the DateKeywords option is set, and the minimum and maximum dates are 
not set, the only date which is displayed in the menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs
-

  autotests/kdatecomboboxtest.cpp c15525a 
  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Updated autotests pass. GUI changes tested with KAlarm, including setting 
DateKeywords. The bugs described above are now fixed.


Thanks,

David Jarvie

Re: Review Request 129709: Fix checking for valid date entered

[David Jarvie]

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

(Updated Dec. 30, 2016, 7:10 p.m.)


Review request for KDE Frameworks and John Layt.


Changes
---

Renamed isValid() to isInDateRange()


Repository: kwidgetsaddons


Description
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, and 
the minimum and maximum dates are not set, it is always considered invalid and 
the date is not changed.
- When the DateKeywords option is set, and the minimum and maximum dates are 
not set, the only date which is displayed in the menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs (updated)
-

  autotests/kdatecomboboxtest.cpp c15525a 
  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Updated autotests pass. GUI changes tested with KAlarm, including setting 
DateKeywords. The bugs described above are now fixed.


Thanks,

David Jarvie

Re: Review Request 129709: Fix checking for valid date entered

[David Jarvie]

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

(Updated Dec. 28, 2016, 5:49 p.m.)


Review request for KDE Frameworks and John Layt.


Changes
---

Extra checks added to autotests


Repository: kwidgetsaddons


Description (updated)
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, and 
the minimum and maximum dates are not set, it is always considered invalid and 
the date is not changed.
- When the DateKeywords option is set, and the minimum and maximum dates are 
not set, the only date which is displayed in the menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs (updated)
-

  autotests/kdatecomboboxtest.cpp c15525a 
  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing (updated)
---

Updated autotests pass. GUI changes tested with KAlarm, including setting 
DateKeywords. The bugs described above are now fixed.


Thanks,

David Jarvie

Re: Review Request 129709: Fix checking for valid date entered

[David Jarvie]

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

(Updated Dec. 27, 2016, 5:46 p.m.)


Review request for KDE Frameworks and John Layt.


Changes
---

Updated to fix (re)setMinimumDate(), (re)setMaximumDate() and to check dates 
for validity if entered via date picker or menu.


Repository: kwidgetsaddons


Description (updated)
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, it 
is always considered invalid and the date is not changed.
- When the DateKeywords option is set, the only date which is displayed in the 
menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs (updated)
-

  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Tested with KAlarm, including setting DateKeywords. The bugs described above 
are now fixed.


Thanks,

David Jarvie

Review Request 129709: Fix checking for valid date entered

[David Jarvie]

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

Review request for KDE Frameworks and John Layt.


Repository: kwidgetsaddons


Description
---

In two places, the checks to determine whether an entered date is valid is 
wrong, due to not testing whether a minimum or maximum date is set before 
comparing to the minimum/maximum date. When a minimum and maximum date is not 
set, this results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, it 
is always considered invalid and the date is not changed.
- When the DateKeywords option is set, the only date which is displayed for 
selection is "No Date".

This fixes the checks so that if a minimum date is not set, the date is always 
treated as complying with the minimum, and the maximum check is similarly fixed.

Documentation comments in the header file are also improved.


Diffs
-

  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Tested with KAlarm, including setting DateKeywords. The bugs described above 
are now fixed.


Thanks,

David Jarvie

Re: Review Request 128595: [KUnitConversion] Add British "stone" unit of mass

[David Jarvie]

> On Aug. 3, 2016, 10:18 p.m., David Edmundson wrote:
> > src/mass.cpp, line 268
> > 
> >
> > one of these should be "%1 stones" (with extra 's')

No, it's normally 'stone' for the plural as well.


- David


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


On Aug. 3, 2016, 7:45 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128595/
> ---
> 
> (Updated Aug. 3, 2016, 7:45 p.m.)
> 
> 
> Review request for KDE Frameworks and David Edmundson.
> 
> 
> Repository: kunitconversion
> 
> 
> Description
> ---
> 
> This weird unit is pretty common in the UK and equal to 6.35029318 kg.
> 
> 
> Diffs
> -
> 
>   src/mass.cpp c7bf147 
>   src/unit.h e440346 
> 
> Diff: https://git.reviewboard.kde.org/r/128595/diff/
> 
> 
> Testing
> ---
> 
> This is the type of stone you use to smash display windows.
> 
> https://en.wikipedia.org/wiki/Stone_(unit)
> 
> Verified that krunner spit out the same result as Google converter did.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126813: Fix build with older polkit

[David Jarvie]

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



Looks good.

- David Jarvie


On Jan. 21, 2016, 4:24 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126813/
> ---
> 
> (Updated Jan. 21, 2016, 4:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: polkit-qt-1
> 
> 
> Description
> ---
> 
> Seems like the function exists, but the header declaration is missing
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt bb91bdedc96b8211eb29a1180c2e451dc60fae18 
>   core/polkitqt1-subject.h 03028f636d7efc154138821419a704b661a7aeac 
>   core/polkitqt1-subject.cpp ecb4c0e216d5bacf5dff5cf100611b941d3e8fbd 
>   polkitqt1-config.h.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126813/diff/
> 
> 
> Testing
> ---
> 
> compiles now
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126813: Fix build with older polkit

[David Jarvie]

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



The symbol `polkit_system_bus_name_get_user_sync` doesn't exist in the Debian 
stable polkit libraries (it doesn't exist in the polkit-1 package sources or 
Debian patches either). The Debian stable package version is 0.105-8.

The patch does allow polkit-qt-1 to build, but presumably it might lead to link 
errors if `SystemBusNameSubject::user()` is referenced. Wouldn't it be better 
to deal with the symbol `polkit_system_bus_name_get_user_sync` in the same 
manner as `polkit_authority_get_sync` and `polkit_agent_listener_register`, 
which if they are missing from the libraries, CMakeLists.txt sets the 
conditional define `POLKIT_QT_1_COMPATIBILITY_MODE`. That could also be used to 
conditionally compile the code referencing 
`polkit_system_bus_name_get_user_sync`.

- David Jarvie


On Jan. 19, 2016, 1:09 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126813/
> ---
> 
> (Updated Jan. 19, 2016, 1:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: polkit-qt-1
> 
> 
> Description
> ---
> 
> Seems like the function exists, but the header declaration is missing
> 
> 
> Diffs
> -
> 
>   core/polkitqt1-subject.cpp ecb4c0e216d5bacf5dff5cf100611b941d3e8fbd 
> 
> Diff: https://git.reviewboard.kde.org/r/126813/diff/
> 
> 
> Testing
> ---
> 
> compiles now
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117604: Fix KDBusServiceStarter::findServiceFor() not returning error string

[David Jarvie]

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

(Updated April 23, 2014, 9:09 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Repository: kservice


Description
---

When KDBusServiceStarter::findServiceFor() fails to start the requested service 
after it is found to not be running, it does not return the error string. This 
patch fixes that and makes it behave as in the apidox.

This is a copy of https://git.reviewboard.kde.org/r/116951/ for KDE 4, except 
that the qDebug line has been uncommented on the grounds that it reports an 
error.


Diffs
-

  src/plugin/kdbusservicestarter.cpp 6f011bd 

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


Testing
---

Tested for review 116951.


Thanks,

David Jarvie

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117604: Fix KDBusServiceStarter::findServiceFor() not returning error string

[David Jarvie]

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

(Updated April 22, 2014, 10:03 p.m.)


Review request for KDE Frameworks and David Faure.


Changes
---

Fixed warning text.


Repository: kservice


Description
---

When KDBusServiceStarter::findServiceFor() fails to start the requested service 
after it is found to not be running, it does not return the error string. This 
patch fixes that and makes it behave as in the apidox.

This is a copy of https://git.reviewboard.kde.org/r/116951/ for KDE 4, except 
that the qDebug line has been uncommented on the grounds that it reports an 
error.


Diffs (updated)
-

  src/plugin/kdbusservicestarter.cpp 6f011bd 

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


Testing
---

Tested for review 116951.


Thanks,

David Jarvie

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 117604: Fix KDBusServiceStarter::findServiceFor() not returning error string

[David Jarvie]

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

Review request for KDE Frameworks and David Faure.


Repository: kservice


Description
---

When KDBusServiceStarter::findServiceFor() fails to start the requested service 
after it is found to not be running, it does not return the error string. This 
patch fixes that and makes it behave as in the apidox.

This is a copy of https://git.reviewboard.kde.org/r/116951/ for KDE 4, except 
that the qDebug line has been uncommented on the grounds that it reports an 
error.


Diffs
-

  src/plugin/kdbusservicestarter.cpp 6f011bd 

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


Testing
---

Tested for review 116951.


Thanks,

David Jarvie

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel