Re: New(ish) Framework review: kstatusnotifieritem

t > > - They negatively affect each other's dependencies > > I've now created https://invent.kde.org/frameworks/kstatusnotifieritem > and started porting users of KStatusNotifierItem to it. > > Given that this is 100% pre-existing Frameworks code I don't think an

New(ish) Framework review: kstatusnotifieritem

tifieritem and started porting users of KStatusNotifierItem to it. Given that this is 100% pre-existing Frameworks code I don't think an in-depth "new framework review" is really appropriate, but if you have important and/or actionable points then we can of course discuss them. Cheers Nico

New CI workers - node1 and node2

Hi all, Over the last 2 days i've been busy connecting two new CI workers to GitLab, which are the beginning of long overdue improvements to our CI arrangements needed to support the final retirement of the Binary Factory. While developers shouldn't notice much in the way of changes,

Re: These frameworks need new maintainers

On 2023-08-01 16:23, Nicolas Fella wrote: Am 01.08.23 um 15:48 schrieb David Faure: In order to reflect reality, I have removed my name as maintainer for the following frameworks (in master). Don't hesitate to step up and write yours instead. kapidox karchive kcrash kdbusaddons kded kinit - but

Re: These frameworks need new maintainers

Am 01.08.23 um 15:48 schrieb David Faure: In order to reflect reality, I have removed my name as maintainer for the following frameworks (in master). Don't hesitate to step up and write yours instead. kapidox karchive kcrash kdbusaddons kded kinit - but that's dead I think kio kitemmodels kparts

These frameworks need new maintainers

In order to reflect reality, I have removed my name as maintainer for the following frameworks (in master). Don't hesitate to step up and write yours instead. kapidox karchive kcrash kdbusaddons kded kinit - but that's dead I think kio kitemmodels kparts kservice kxmlgui -- David Faure, fa...@kd

Re: New Framework Review: KTextTemplate

On Donnerstag, 11. Mai 2023 18:32:23 CEST Volker Krause wrote: > let's get the process for getting KTextTemplate (https://invent.kde.org/ > libraries/ktexttemplate) into KF6 going. This is the library formerly known > as Grantlee and implements Django-style text templates. It's in use in PIM > and

Re: New Framework Review: KTextTemplate

On Freitag, 12. Mai 2023 11:14:29 CEST Albert Astals Cid wrote: > El dijous, 11 de maig de 2023, a les 18:32:23 (CEST), Volker Krause va > > escriure: > > Hi, > > > > let's get the process for getting KTextTemplate (https://invent.kde.org/ > > libraries/ktexttemplate) into KF6 going. This is the

Re: New Framework Review: KTextTemplate

El dijous, 11 de maig de 2023, a les 18:32:23 (CEST), Volker Krause va escriure: > Hi, > > let's get the process for getting KTextTemplate (https://invent.kde.org/ > libraries/ktexttemplate) into KF6 going. This is the library formerly known > as Grantlee and implements Django-style text template

New Framework Review: KTextTemplate

Hi, let's get the process for getting KTextTemplate (https://invent.kde.org/ libraries/ktexttemplate) into KF6 going. This is the library formerly known as Grantlee and implements Django-style text templates. It's in use in PIM and KDevelop, among others. In the 5 era it was released stand-alon

Re: New

On 11/17/22 02:08, David Faure wrote> Done: kconfig v5.100.1 f4dcf631e9f22e25c768c323762672716ddbdd02 8bbb7951d74e8e289f7b0599887ef328b2726fdbdaae18effda2c9d7f18a82da sources/kconfig-5.100.1.tar.xz plasma-framework v5.100.1 0435ec52c76092bc8a8e2703fa0acbbb63484dfe 53940a920773a105df0af9dd3dbf

Re: New

kde.org/frameworks/plasma-framework/-/merge_requests/652 > > These are significant enough that I'd like to recommend we make new > releases of the kconfig and plasma-framework frameworks so we can get > the fixes to users as quickly as possible. Done: kconfig v5.100.1 f4dcf

New

that I'd like to recommend we make new releases of the kconfig and plasma-framework frameworks so we can get the fixes to users as quickly as possible. Would that be possible to do? Nate

Re: Challenge: adding new method overloads when existing consumers use {} with args

t; void foo(A a); > }; > --- 8< --- > > Now you want to add an overload, to serve further use-cases as requested by > API consumers: > --- 8< --- > void foo(B b); > --- 8< --- > > > But there is existing consumer code, making use of C++17, which calls > ---

Re: Challenge: adding new method overloads when existing consumers use {} with args

void foo(A a); > }; > --- 8< --- > > Now you want to add an overload, to serve further use-cases as requested by > API consumers: > --- 8< --- > void foo(B b); > --- 8< --- > > > But there is existing consumer code, making use of C++17, which

Challenge: adding new method overloads when existing consumers use {} with args

--- 8< --- void foo(B b); --- 8< --- But there is existing consumer code, making use of C++17, which calls --- 8< --- C c; c.foo({}); --- 8< --- So the new overload will not be source-compatible and break existing code, for what my WE mood brain tells me. Wh

D7929: [WIP] Add new Column View option to KDirOperator

Herald added a subscriber: kde-frameworks-devel. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D7929 To: fvogt, #frameworks Cc: kde-frameworks-devel, Coelacanthus, dfaure, cfeck, dhaumann, ngraham, elvisangelaccio, lbeltrame, #frameworks, LeGast00n, cblack, michaelh, ahma

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

kossebau added a comment. In D19565#678804 , @alex wrote: > However the option seems pretty unused, even from a github search: https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l= In comparison to

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

alex added a comment. However the option seems pretty unused, even from a github search: https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l= > KF targets also consumers outside of KDE spheres Also I think there are currently quite a lot of k

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

ng something else than `.cpp`, not sure where the others are coming from. https://en.wikipedia.org/wiki/C++ lists these suffixes being more widely used: .C, .cc, .cpp, .cxx, .c++, .h, .H, .hh, .hpp, .hxx, .h++. And while the C++ Core guidelines these days recommend .h and .cpp f

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

alex added a comment. I am wondering if there is really a need for it. SourceExtension seems completely unused and HeaderExtension is only used in okteta. Though in KDE code, Qt code (and most other that I know of) it is the ".h" extension is the most common one for headers. Are th

D19338: New location for KNSRC files

asturmlechner added a comment. In D19338#676682 <https://phabricator.kde.org/D19338#676682>, @kossebau wrote: > In D19338#676680 <https://phabricator.kde.org/D19338#676680>, @asturmlechner wrote: > > > Hm, why was this new variable KDE_INSTALL_KNSRCDIR not

D19338: New location for KNSRC files

kossebau added a comment. In D19338#676680 <https://phabricator.kde.org/D19338#676680>, @asturmlechner wrote: > Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into KDEInstallDirs? On the other hand it makes sense that module-specific variables are provide

D19338: New location for KNSRC files

asturmlechner added a comment. Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into KDEInstallDirs? REPOSITORY R304 KNewStuff REVISION DETAIL https://phabricator.kde.org/D19338 To: leinir, #knewstuff, apol, ngraham, fvogt Cc: asturmlechner, kossebau, kde-frameworks-devel

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

dfaure added a comment. Only if you can find a way to change BatchRenameJob in a binary and behaviour compatible way. And then it will be a dual-headed thing with two modes of operations, awful. All this sounds to me like much more trouble than writing a different job. REPOSITORY R241 KIO

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

luco added a comment. @emateli Thank you, I do understand that `BatchMoveJob` could be more versatile for a various kind of operations, but couldn't it be easier to just edit the `BatchRenameJob`'s hardcoded logic and make it more parametric? If I understand correctly you're referring to t

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

emateli added a comment. You're completely right in the sense that for a batch rename files will be in the same folder. However, rename really is just a move operation. The current BatchRenameJob has a hardcoded logic about placeholders and extensions which make it unusable outside of its cu

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

luco added a comment. @emateli Thank you for your response, I saw that patch and I sincerely don't understand the reason why you're writing a completely different job (`BatchMoveJob`) when the required operation is exactly a `BatchRenameJob`. I'm asking this because I've never used a "batc

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

What this needs to be fully implemented is support from KIO for a "proper" batch move operation. I've submitted a patch for that at D27760 <https://phabricator.kde.org/D27760> but am still waiting for a review. I'm completely open to new ideas though. REPOSIT

D14631: Adds a new RenameDialog to KIO with more options for batch renaming

luco added a comment. @emateli Are you still working on this? I'd love to see this feature implemented, I wanted to start by myself then on the Matrix Dolphin channel they suggested seeing this patch and it's awesome! Could you use some help? REPOSITORY R241 KIO REVISION DETAIL https://

Re: New Framework Review: KDAV

> > > > > > To avoid the last minute invasive changes we ended up doing for > > > > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > > > > > > > - identify and implement all necessary changes to the API a

Re: New Framework Review: KDAV

On Friday, 19 June 2020 01:16:20 CEST Friedrich W. H. Kossebau wrote: > Am Samstag, 4. April 2020, 16:20:21 CEST schrieb Kevin Ottens: > > Overall apidox would likely need a big pass of cleanups as well. > > I locally prepared the addition of ECMAddQch usage for KDAV tonight, and > while testing t

Re: New Framework Review: KDAV

Am Freitag, 19. Juni 2020, 01:16:20 CEST schrieb Friedrich W. H. Kossebau: > Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/ > merge_requests/1 is in, to not block this more due to resulting new merge > conflicts. And while I was typing & sending, that got

Re: New Framework Review: KDAV

(simply grep for the string to find those). That needs more context, or better some generalization what is meant there (seems something-Akonadi specific?). Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/ merge_requests/1 is in, to not block this more due to result

Re: New Framework Review: KDAV

nute invasive changes we ended up doing for > > > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > > > > > - identify and implement all necessary changes to the API and ABI > > > > > > until > >

Re: New Framework Review: KDAV

t; KF5 library namespace). > > > > > > > > I'm likely late to the party, but here is what I found by looking at > > > > KDAV > > > > > > > > master today (first day of the KDE PIM sprint): > > > > * There's a few

Re: New Framework Review: KDAV

to > > > > the > > > > KF5 library namespace). > > > > > > I'm likely late to the party, but here is what I found by looking at > > > KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's

D29017: WIP: Introduce three new methods that return all "entries" in a folder

ahmadsamir abandoned this revision. REPOSITORY R311 KWallet REVISION DETAIL https://phabricator.kde.org/D29017 To: ahmadsamir, #frameworks, dfaure Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29017: WIP: Introduce three new methods that return all "entries" in a folder

ahmadsamir reopened this revision. ahmadsamir marked an inline comment as done. ahmadsamir added a comment. Move to gitlab https://invent.kde.org/frameworks/kwallet/-/merge_requests/2 REPOSITORY R311 KWallet REVISION DETAIL https://phabricator.kde.org/D29017 To: ahmadsamir, #frameworks,

D29017: WIP: Introduce three new methods that return all "entries" in a folder

This revision was not accepted when it landed; it landed in state "Needs Revision". This revision was automatically updated to reflect the committed changes. Closed by commit R311:1a19afb6a06d: WIP: Introduce three new methods that return all "entries" in a folder (au

D29017: WIP: Introduce three new methods that return all "entries" in a folder

ahmadsamir added a comment. In D29017#664279 , @blaze wrote: > Check this commit message https://phabricator.kde.org/R32:f56cdda54b7f88b119f2c7cfb2f534b4fe74478f Sorry for the delay. We applied a workable hack in https://phabricator.kde.

Re: New Framework Review: KDAV

here is what I found by looking at KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > moving them to the d-pointer, for the slots we're using type safe

Re: New Framework Review: KDAV

arty, but here is what I found by looking at KDAV > > > > master today (first day of the KDE PIM sprint): > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > moving them to the d-pointer, for the slots we're using type

D27989: Add a new set of barcode size functions

a sufficiently new KF5 version to actually do the migration). Both ways can be argued of course, I optimized for "helps me" (the warnings for things I can't change yet don't), and "migration is my problem" rather than "migration is somebody else's problem&

D27989: Add a new set of barcode size functions

he macros from the start, otherwise it will be only forgotten later, as there is no mechanism to remind you. And without compiler warnings all the remaining users might never learn about it. > > I would expect you have prepared patches for some known users already to testdrive the new

D27989: Add a new set of barcode size functions

u. And without compiler warnings all the remaining users might never learn about it. I would expect you have prepared patches for some known users already to testdrive the new API for usefulness, so the set of remaining users (in KDE spheres) should be already small. And those not yet with

D23875: KCoreDirLister: fix crash when creating new folders from kfilewidget

dfaure added a subscriber: chinmoyr. dfaure added a comment. In D23875#532045 , @dhaumann wrote: > @dfaure: D21197 can be closed / abandoned? Yes, but @chinmoyr has disappeared, it seems? REPOSITORY

D29017: WIP: Introduce three new methods that return all "entries" in a folder

blaze added a comment. Check this commit message https://phabricator.kde.org/R32:f56cdda54b7f88b119f2c7cfb2f534b4fe74478f REPOSITORY R311 KWallet REVISION DETAIL https://phabricator.kde.org/D29017 To: ahmadsamir, #frameworks, dfaure Cc: blaze, kde-frameworks-devel, LeGast00n, cblack, mi

2 new repositories: plasma-wayland-protocols and kwayland-server

adding Wayland protocol implementation public interfaces in the cases that will be shared among several users. This then includes 2 new repositories: kdesupport/plasma-wayland-protocols kde/workspace/kwayland-server The first should be released independently whenever we have a new protocol, the

[sysadmin/repo-metadata] projects: projects: move new wayland repos to their final place

Git commit 53d913c3af459024d359c13def87db8913d8ed6b by Bhushan Shah. Committed on 29/04/2020 at 11:09. Pushed by bshah into branch 'master'. projects: move new wayland repos to their final place - plasma-wayland-protocols -> frameworks - kwayland-server -> kde/workspace Ref: T13

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

This revision was automatically updated to reflect the committed changes. Closed by commit R245:c4e8755ac324: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType (authored by ahmadsamir). REPOSITORY R245 Solid CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29221?vs

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R245 Solid BRANCH l-mediumtypes (branched from master) REVISION DETAIL https://phabricator.kde.org/D29221 To: ahmadsamir, #frameworks, dfaure, meven, bruns Cc: kde-frameworks-devel, LeGast00n, cblac

D29221: [FakeCdrom] Add a new UnknownMediumType enumerator to MediumType

a new enumerator to MediumType with value 0 to indicate no-op. Change one for-loop to use the new enumerator with QMap::value(key, defaultValue). TEST PLAN make && ctest REPOSITORY R245 Solid BRANCH l-mediumtypes (branched from master) REVISION DETAIL https://phabricator

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

ahmadsamir added a comment. I forgot to change the commit message about hiding the show only monospaced fonts checkbox when FixedFontsOnly is set... at least the API docs do mention it :/. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D29065 To: ahmadsamir,

D28020: New class ProcessLauncherJob in KIOGui

dfaure added a task: T11549: KIO: remove unneeded QWidget dependencies to set parent windows or display errors. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28020 To: dfaure, apol, davidedmundson, nicolasfella, vkrause, broulik Cc: jbbgameich, kde-frameworks-devel, LeGas

D29095: New much simpler mouse icon that works in both light and dark breeze

ndavis commandeered this revision. ndavis added a reviewer: saligari. ndavis added a comment. Saligari is Ok with me taking over this patch. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: ndavis, #vdg, saligari Cc: bruns, ouwerkerk, ndavis, ngraham, k

D29095: New much simpler mouse icon that works in both light and dark breeze

ndavis added a comment. In D29095#656819 , @saligari wrote: > Oh the shame! I had forgotten to center it (and I do know how to)! > > One thing I don't know is: since I centered it and used the guidelines my 1px line centered sits on a 0,5 to

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 81156. saligari added a comment. Oh the shame! I had forgotten to center it (and I do know how to)! One thing I don't know is: since I centered it and used the guidelines my 1px line centered sits on a 0,5 to 0,5 line. I don't know if that's bad or h

D29095: New much simpler mouse icon that works in both light and dark breeze

ndavis added a comment. It's a bit off center and I'd prefer if lines were more aligned with pixels. That way the icon doesn't change in how it looks when you scale it up. You may need to lighten the colors of your lines to maintain the original appearance. You see what I'm seeing? Do yo

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 81138. saligari added a comment. My search on the internet told me LGTM stands for looks good to me. I added a 32px with 3px margin REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29095?vs=81126&id=81138 BRANCH

D29095: New much simpler mouse icon that works in both light and dark breeze

ngraham added a comment. LGTM now! While you're at it, could you create a 32px version and replace `icons/preferences/32/preferences-desktop-mouse.svg`? REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: saligari, #vdg Cc: bruns, ouwerkerk, ndavis, ngrah

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 81126. saligari added a comment. - a bit darker, with a more pronounced gradient effect REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29095?vs=81041&id=81126 BRANCH input-mouse-patch (branched from master) RE

D29095: New much simpler mouse icon that works in both light and dark breeze

ngraham added a comment. That's much better! I think I'd use a slightly darker shade of gray though. Not much, just a bit. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: saligari, #vdg Cc: bruns, ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGa

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 81041. saligari added a comment. - corrected hard edges - aaand that's it probably for me, I'm reasonably happy with this and I think I've learned quite a bit - Here it is ^_^ REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabri

D29095: New much simpler mouse icon that works in both light and dark breeze

bruns added a comment. > Bruns's comment about right-handed mice (gradient) is due to the quite asymmetrical shape many modern mice use for ergonomic reasons (RSI). No, even for a ball bottom right is darkest. Shapes should be drawn as if there were a light at the top left, i.e. with a s

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 81032. saligari added a comment. - tried to change the shape into something more modern (though I quite like the old-ish look) - changed the gradient as bruns said, can't say I see much difference - removed the middle curve REPOSITORY R266 Breeze I

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. In D29095#655214 , @ngraham wrote: > FWIW all the mice in my house have this exact shape, but they're black, not gray. So I don't think the shape is too old-fashioned per se. It's the gray color that's anacrhonistic pa

D29095: New much simpler mouse icon that works in both light and dark breeze

bruns added a comment. F8255905: bitmap.png REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: saligari, #vdg Cc: bruns, ouwerkerk, ndavis, ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

This revision was automatically updated to reflect the committed changes. Closed by commit R236:0004e5c89a24: [KFontChooser] Add new DisplayFlag; modify how flags are used (authored by ahmadsamir). REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29065

D29095: New much simpler mouse icon that works in both light and dark breeze

bruns added a comment. The new one looks very oldschool. Some ideas how to improve that: - buttons are typically only separated from each other, but not from the body, try removing the horizontal line - the body should be narrower at the center - the gradient does not match the shape

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

ahmadsamir marked an inline comment as done. REPOSITORY R236 KWidgetsAddons BRANCH l-kfontchooser-onlyfixed-display-flag (branched from master) REVISION DETAIL https://phabricator.kde.org/D29065 To: ahmadsamir, #frameworks, dfaure, cfeck, bport Cc: kossebau, kde-frameworks-devel, LeGast00

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

ahmadsamir updated this revision to Diff 81007. ahmadsamir marked an inline comment as done. ahmadsamir added a comment. More docs, and a trailing comma in the enum to ease git diff/blame if more flags are added REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

dfaure added a comment. I agree, it's now common practice to have a final comma. REPOSITORY R236 KWidgetsAddons BRANCH l-kfontchooser-onlyfixed-display-flag (branched from master) REVISION DETAIL https://phabricator.kde.org/D29065 To: ahmadsamir, #frameworks, dfaure, cfeck, bport Cc:

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

kossebau added inline comments. INLINE COMMENTS > ahmadsamir wrote in kfontchooser.h:90 > Wouldn't that look a bit weird as if something has been removed or missing? I might perhaps while getting used to if you are coming from old code habits, but the syntax of C++ has been extra extended to al

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

ahmadsamir marked an inline comment as done. ahmadsamir added inline comments. INLINE COMMENTS > dfaure wrote in kfontchooser.h:87 > maybe document that FixedFontsOnly implies NoFixedCheckBox? > > (as in, the widget will behave as if NoFixedCheckBox was set) Yes, will do (less surprises for use

D29095: New much simpler mouse icon that works in both light and dark breeze

ngraham added a comment. Hmm yeah, that gray color is probably too dark. Also a color that dark likely wouldn't need an outline as it would be visible on both light and dark backgrounds. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: saligari, #vdg

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

kossebau added inline comments. INLINE COMMENTS > kfontchooser.h:90 > +ShowDifferences = 4,///< Display the font differences interfaces > +NoFixedCheckBox = 8 ///< Do not Show a checkbox to toggle > showing only fixed fonts > }; I would add a final ",", so you do no

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

dfaure added inline comments. INLINE COMMENTS > kfontchooser.h:87 > +NoDisplayFlags = 0, ///< No flags set > +FixedFontsOnly = 1, ///< Only show fixed fonts, excluding > proportional fonts > +DisplayFrame = 2, ///< Show a visual frame around the chooser may

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R236 KWidgetsAddons BRANCH l-kfontchooser-onlyfixed-display-flag (branched from master) REVISION DETAIL https://phabricator.kde.org/D29065 To: ahmadsamir, #frameworks, dfaure, cfeck, bport Cc: kde-f

D29065: [KFontChooser] Add new DisplayFlag; modify how flags are used

ahmadsamir updated this revision to Diff 80989. ahmadsamir marked 2 inline comments as done. ahmadsamir retitled this revision from "[KFontChooser] Add a DisplayFlag to allow not showing fixedOnly checkbox" to "[KFontChooser] Add new DisplayFlag; modify how flags are used". a

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 80971. saligari added a comment. Changed the icon, with ndavis' help, so that it better fits its 64px place. I also tried joystick's/input gaming colors but didn't like it much, here's a comparison in 64px: REPOSITORY R266 Breeze Icons CHANGES SI

D29095: New much simpler mouse icon that works in both light and dark breeze

ern mice tend to be black: F8254746: Screenshot_20200422_210145.png <https://phabricator.kde.org/F8254746> However that dark color causes visibility problems that this new icon is fixing. Maybe you could use the same color that's used in the joystick/gaming controller icon? That'

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari added a comment. > If on the other hand you really like the old mouse icon as well but just want it to work better for dark themes then another option might be to recolour the old icon to get better contrast out of it against the dark background. I tried modifying the existing

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. In D29095#655060 , @saligari wrote: > > Maybe this is just me but the overall width to height ratio makes it seem that the closest "real" mice are quite dated as well. > > I don't understand what you mean with this,

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 80935. saligari added a comment. Added a better border, it does look better like this. REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29095?vs=80928&id=80935 BRANCH input-mouse-patch (branched from master) REV

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari added a comment. > Maybe this is just me but the overall width to height ratio makes it seem that the closest "real" mice are quite dated as well. I don't understand what you mean with this, do you think it should be slimmer? I kind of followed the old one in this, even if it do

D29095: New much simpler mouse icon that works in both light and dark breeze

ndavis added a comment. Yes, I agree that the mouse should have fairly realistic and modern proportions. My favorite icons in Breeze are the ones that look pretty realistic while still maintaining the soft gradients and shadows. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabr

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. One thing I find really striking about the new icon is how closely it resembles stress balls: F8253927: stress-ball-mice.png <https://phabricator.kde.org/F8253927> I kinda like that... :) REPOSITORY R266 Breeze Icons REVISION DETAIL

D29095: New much simpler mouse icon that works in both light and dark breeze

ouwerkerk added a comment. Hmm, the old icon also has the virtue of looking more like genuine computer mice: it resembles the logi(tech) style of mouse design quite well. This one is rather abstract while at the same time somehow not looking like any "real" mouse would, in particular in its

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 80928. saligari added a comment. - Fixed margins - added *some* perspective, I hope it looks better. I don't know if maybe I should add curvature - used inkscape to optimize it - I really have no idea on how to make it less boring REPOSITORY R266

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari added a comment. In D29095#655030 , @ngraham wrote: > Awesome, that's much nicer. > > I think it needs the outline.border to extend up to the top, or else the top of the icon starts to blend in with the default window color: F8253868

D29095: New much simpler mouse icon that works in both light and dark breeze

ngraham added a comment. Awesome, that's much nicer. I think it needs the outline.border to extend up to the top, or else the top of the icon starts to blend in with the default window color: F8253868: Screenshot_20200422_124714.png REPOSITORY R2

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari added a comment. In D29095#654825 , @ndavis wrote: > Regarding SVG optimization, the main point of it these days is to make the code easier to read, not to get the smallest size possible. Use the settings on this page for your SVG optim

D29095: New much simpler mouse icon that works in both light and dark breeze

ndavis added a comment. Regarding SVG optimization, the main point of it these days is to make the code easier to read, not to get the smallest size possible. Use the settings on this page for your SVG optimizer: https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips REPOSITORY

D29095: New much simpler mouse icon that works in both light and dark breeze

ngraham added a comment. Things I like: - It's lighter and will show up in both light and dark themes - It isn't trying to look like a cool gaming mouse, which always seemed a bit childish to me Things I don't like: - The horizontal line in the center needs some perspective so

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari updated this revision to Diff 80889. saligari added a comment. Used svgcleaner to change the icon from 7.3KiB to 1.6KiB REPOSITORY R266 Breeze Icons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29095?vs=80882&id=80889 BRANCH input-mouse-patch (branched from master)

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari added a comment. Running svgcleaner on this icon turns it from a 7.3 KiB monstrosity to 1.6 KiB beauty. However I don't know how to update this patch :(. The existing icon is something like 7.9KiB but this one is doesn't have that much detail, it shouldn't be such a big file. R

D29017: WIP: Introduce three new methods that return all "entries" in a folder

dfaure requested changes to this revision. dfaure added inline comments. This revision now requires changes to proceed. INLINE COMMENTS > kwallet.cpp:219 > +KSecretsService::ReadItemPropertyJob *readLabelJob = > item->label(); > +if (readLabelJob->exec()) { > +

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari edited the test plan for this revision. saligari added a reviewer: VDG. REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D29095 To: saligari, #vdg Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29095: New much simpler mouse icon that works in both light and dark breeze

saligari created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. saligari requested review of this revision. REVISION SUMMARY A very very simple mouse icon, which hopefully adheres to the general HIG. Most colors are borrowed from the keyboard

  1   2   3   4   5   6   7   8   9   10   >