Re: Review Request 126738: Remove external dependencies from svgs

[Dirk Hohndel]

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

(Updated July 6, 2016, 12:12 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks, Andreas Kainz and Uri Herrera.


Repository: breeze-icons


Description
---

I don't know what I'm doing here. But when using the icons in a QML app I
get a lot of warnings like this one:

Could not resolve property : linearGradient4548

Running the svgs through inkscape and using the "clean up document"
function results in this commit (and the warnings are gone).

This may not be the right thing to do but it would be nice to get rid of
all these warnings when using the icons.

Signed-off-by: Dirk Hohndel 


Diffs
-

  icons/actions/24/dialog-cancel.svg a2b022a9dc7b7cf97e4c3391b87e7800355d2dcb 
  icons/actions/24/distribute-horizontal-x.svg 
262fcaca937cb72d8393fd5dff9c59651367fe36 
  icons/actions/24/document-edit.svg afb37ca9624b37d6ac5aa9c94f1b2cef620faff6 
  icons/actions/24/document-save.svg cee0a3521deb7eb1fcb79266afaa8951f4984b20 

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


Testing
---


Thanks,

Dirk Hohndel

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

Re: KMessageBox runtime dependency on FrameworkIntegrationPlugin makes it useless

[David Faure]

On mercredi 6 juillet 2016 00:26:39 CEST Albert Astals Cid wrote:
> > I'm wondering if the best option wouldn't to ask all packagers to make
> > kwidgetsaddons depend on frameworkintegration. Everything else leads to
> > breakage.
> 
> That effectively breaks the tier of kwidgetsaddons to be "Tier a lot", no?

On a Linux distro, yes.
On a reduced (e.g. embedded) system where DontShowAgain isn't used, no.

> Also there's "a lot of packagers" it's hard to reach them all even by using
> the list we have for it :D

I don't have a better solution to suggest.

> > My ideal solution (kmessagebox in a higher tier) can't be done anymore
> > either, because that would break SC (apps using it, might not link to that
> > other lib).
> 
> KF6 you said? ;)

Yeah -- when Qt6 is out :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Where to put kwayland integration plugins

[Martin Graesslin]

On Wednesday, July 6, 2016 12:16:09 AM CEST Albert Astals Cid wrote:
> El dissabte, 2 de juliol de 2016, a les 15:25:39 CEST, Martin Graesslin va
> 
> escriure:
> > On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote:
> > > On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote:
> > > > On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin 
> > 
> > wrote:
> > > > > Hi framework-developers,
> > > > > 
> > > > > in Plasma we have a repository called kwayland-integration. It
> > > > > provides
> > > > > a
> > > > > plugin for:
> > > > > * KWindowSystem
> > > > > * KIdleTime
> > > > > 
> > > > > using the KWayland client API. Thus it makes these frameworks
> > > > > functional
> > > > > on
> > > > > windowing system Wayland.
> > > > > 
> > > > > I want to move the plugins into frameworks and are wondering how to
> > > > > do
> > > > > that
> > > > > and where to move them to.
> > > > > 
> > > > > I see the following options:
> > > > > 1. Integrate directly into kwindowsystem and kidletime
> > > > > 2. Merge them into frameworks-integration
> > > > > 3. Create a new framework kwayland-integration
> > > > > 4. create a new framework "kwindowsystem-wayland" and
> > > > > "kidletime-wayland"
> > > > > 
> > > > > Option 1 is I think an absolute no-no as it would turn kwindowsystem
> > > > > and
> > > > > kidletime from tier 1 to tier 2 and that would affect a huge amount
> > > > > of
> > > > > other frameworks. For everything which is not in tier 1, I think
> > > > > it's
> > > > > the
> > > > > way to go.
> > > > > 
> > > > > Option 2 is something I don't want to do as that would combine
> > > > > windowing
> > > > > system integration code with random other stuff and would result in
> > > > > weird
> > > > > dependencies. (To use KIdleTime on Wayland one needs X11 and
> > > > > Phonon?)
> > > > > 
> > > > > The same actually also applies to Option 3, though it is just two
> > > > > frameworks and all dependencies would be tier 1.
> > > > > 
> > > > > So personally I think option 3 or option 4 are the way to go.
> > > > > 
> > > > > What do you think? Better ideas?
> > > > 
> > > > I agree ideally it's 3 or 4. Where do you have it now? Are they
> > > > already separate repositories? If so, just moving them to frameworks
> > > > could make sense.
> > > > 
> > > > In Purpose I have a similar problem (and I know the discussion is also
> > > > relevant for other frameworks). We usually don't want plugins to raise
> > > > the tier of your base framework, but you still need them to be
> > > > distributed together and either way you need to make sure the plugins
> > > > will be available when the system is deployed (which is actually much
> > > > easier in option 1).
> > > 
> > > The alternative is to use option 1 with a cmake option to disable the
> > > kwayland-based plugin. This offers benefits because
> > > - on systems with wayland enabled, you are sure the plugin is present
> > > (no
> > > bug report like "idle detection doesn't work" (because of a missing
> > > package)) - on systems where dependencies should be kept to a minimum
> > > (e.g.
> > > an X11-based embedded system) one can easily compile without the
> > > kwayland
> > > dependency
> > > 
> > > Application developers using KIdleTime or KWindowSystem do expect it to
> > > work on all platforms where the application works, so surely a
> > > dependency
> > > on kwayland can't be a problem on wayland.
> > 
> > That's actually not the case. Both KIdleTime and KWindowSystem (runtime)
> > depend on additional Wayland protocols currently only provided in KWin/
> > Wayland. That means your KIdleTime based application won't work in e.g.
> > GNOME.
> > 
> > Given that the real world benefit of option 1 is not that large.
> 
> I'm confused by this, rsibreak uses "KIdleTime::instance()->idleTime()" when
> you say it won't work in GNOME, you mean "GNOME Wayland" or "any GNOME at
> all"?

GNOME Wayland.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel