KDE Custom Shortcuts broken, problem's id'd as in khotkeys

This is https://bugreports.qt.io/browse/QTBUG-48795 Qt5 builds it's internal events as combination of (synthetic) keys and HW modifiers. That is *clearly* a fucking bug in Qt: either it ignores synthetic events (a regression compared to Qt4) or not, but just creating random events out of

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

> On März 21, 2016, 8:42 nachm., Dominik Haumann wrote: > > ping > > Marco Martin wrote: > +1, to me the latest version could be fine, would like a last word from > windowmanager people tough As mentioned, I ceased to care. I'm providing input while phasing out (and promise it to be on

Re: Error buildin KDE (KF5)

At least the QtCore and KF5/KGlobalAccel include paths are not added (or mislocated) The key is again the cmake log. On a sidenote: your cmake is terribly outdated. It's listed as minimum for kf5, but even that was wrong (see before issue) and I would not bet even your right arm that it's

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

? _NET_WM_WINDOW_TYPE_COMBO should be used on the windows that are popped up by combo boxes. An example is a window that appears below a text field with a list of suggested completions. This property is typically used on override-redirect windows. - Thomas Lübking On März 20, 2016, 12:06 nachm., Dominik

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

> On März 20, 2016, 4:22 vorm., Anthony Fieroni wrote: > > src/kcompletionbox.cpp, line 282 > > > > > > After show, call activateWindow(), even you can call raise() The window shall *not* be activated. One

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

> On März 19, 2016, 1:22 nachm., Thomas Lübking wrote: > > "Loose focus" is the complete wrong concept anyway. > > It makes kickoff and various other plasmashell elements barely usable w/ > > any but the click-to-focus policy (implicit hide) > > >

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

> On März 19, 2016, 1:22 nachm., Thomas Lübking wrote: > > "Loose focus" is the complete wrong concept anyway. > > It makes kickoff and various other plasmashell elements barely usable w/ > > any but the click-to-focus policy (implicit hide) > > >

Re: Review Request 127424: KCompletionBox popup gets full window decoration on Windows

t *is* set for the QComboBox dropdown. May point an implementation weakeness/bug in this class. - Thomas Lübking On März 19, 2016, Mittag, Dominik Haumann wrote: > > --- > This is an automatically generated e-mail. To re

Re: Review Request 127191: KCompletionBox should *not* be a tooltip

> On Feb. 26, 2016, 2:14 p.m., Thomas Lübking wrote: > > src/kcompletionbox.cpp, line 66 > > <https://git.reviewboard.kde.org/r/127191/diff/1/?file=445519#file445519line66> > > > > q->setAttribute(Qt::WA_X11NetWmWindowTypeCombo); // broken?? > >

Re: Review Request 127191: KCompletionBox should *not* be a tooltip

tps://git.reviewboard.kde.org/r/127191/#comment63580> I doubt this is still required on top, but other than this it's oc. fine from my POV, tooltip has been the wrong type for a combo dropdown to begin with. - Thomas Lübking On Feb. 26, 2016, 2:18 p.m., Marco Martin

Re: KDE file dialog

On Sonntag, 6. März 2016 11:34:32 CEST, Martin Graesslin wrote: I don't know how often we have heard over the last decade that Plasma's look and feel is terribly because of fonts. I'd have assumed that'd be because of the freetype rasterizers being, errr ummm... shit (almost as shit as

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

> On March 3, 2016, 10:16 p.m., Thomas Lübking wrote: > > src/kstatusnotifieritem.cpp, line 934 > > <https://git.reviewboard.kde.org/r/127216/diff/2/?file=446044#file446044line934> > > > > append > > asso

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

> On March 3, 2016, 10:16 p.m., Thomas Lübking wrote: > > src/kstatusnotifieritem.cpp, line 934 > > <https://git.reviewboard.kde.org/r/127216/diff/2/?file=446044#file446044line934> > > > > append > > asso

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

> On March 3, 2016, 10:16 p.m., Thomas Lübking wrote: > > src/kstatusnotifieritem.cpp, line 934 > > <https://git.reviewboard.kde.org/r/127216/diff/2/?file=446044#file446044line934> > > > > append > > asso

Re: KConfig - setStandardButtons() breaks Help button?

On Samstag, 5. März 2016 08:34:27 CEST, Frederik Schwarzer wrote: Since in my use case, some of the values in the dialog are calculated and (to my understanding) cannot be handled correctly by Kcfg, I want to get rif of the "Restore Defaults" button. So I add this line:

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

> On March 3, 2016, 10:16 p.m., Thomas Lübking wrote: > > src/kstatusnotifieritem.cpp, line 934 > > <https://git.reviewboard.kde.org/r/127216/diff/2/?file=446044#file446044line934> > > > > append > > asso

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

() unless the point is invalid, so you might want to "qDebug() << associatedWidgetPos;" to check whether it's invalid for the failing clients. - Thomas Lübking On Feb. 29, 2016, 5:18 a.m., Anthony Fieroni wrote: > > ---

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127216/ > --- > > (Updated Feb. 29, 2016, 5:18 a.m.) > > > Review request for KDE Frameworks, Martin Gräßlin, Thomas Lübking

Re: KDE file dialog

On Mittwoch, 2. März 2016 12:51:28 CEST, Martin Graesslin wrote: On Wednesday, March 2, 2016 12:09:17 PM CET Sven Brauch wrote: On 03/02/2016 11:56 AM, Thomas Lübking wrote: ... Just saying: I wrote that SNI integration and I have never heard of that problem before Sven mentioned it here

Re: KDE file dialog

On Mittwoch, 2. März 2016 11:19:42 CEST, Martin Graesslin wrote: On Wednesday, March 2, 2016 11:08:30 AM CET Mark Gaiser wrote: On Wed, Mar 2, 2016 at 9:42 AM, Martin Graesslin wrote: ... What is that "kf5" plugin you talk of? The origin of this thread was that the

Re: KDE file dialog

On Dienstag, 1. März 2016 19:42:58 CEST, Sven Brauch wrote: Otherwise I agree with your reasoning. I'm just not sure what we can effectively do about it. Build option to build the kde/plasma QPA into a strict "KF5" (tier 1) QPA? Forking sucks terribly and a tier 1 QPA might be interesting for

Re: Review Request 127216: [KStatusNotifierItem] MinimizeRestore does not "run" over the desktop on X11

(ie. in the else branch) and avoid walkign across the window system to figure the restore position. The patch will fail miserably if there's no WM, the SNI window becomes unmanaged (again) and half a dozen other occasions. - Thomas Lübking On Feb. 29, 2016, 5:18 a.m., Anthony Fieroni wrote

Re: mailing list archive gone ?

On Samstag, 27. Februar 2016 16:09:00 CEST, Martin Koller wrote: Hi, https://mail.kde.org/pipermail/kde-core-devel/ shows only 3 mails from the year 2000. Where are the other archives gone ? No idea, but it's still on https://marc.info/?l=kde-core-devel=1=2 Cheers, Thomas

Re: Review Request 127191: KCompletionBox should *not* be a tooltip

tps://git.reviewboard.kde.org/r/127191/#comment63235> q->setAttribute(Qt::WA_X11NetWmWindowTypeCombo); // broken?? - Thomas Lübking On Feb. 26, 2016, 1:23 p.m., Marco Martin wrote: > > --- > This is an automatically generated e-mai

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

+ i) + ", minute: " + (i*10 + i) + " -> " > + str); > } > > qml: hour: 0, minute: 0 -> 00:00 > qml: hour: 11, minute: 11 -> 11:11 > qml: hour: 22, minute: 22 -> 22:22 > qml: hour: 33, minute: 33 -> 09:33 > q

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

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

Re: License of the Breeze style

On Mittwoch, 17. Februar 2016 07:58:46 CEST, Martin Graesslin wrote: On Tuesday, February 16, 2016 8:15:57 PM CET Александр Волков wrote: I've noticed that the Breeze style is released under GPL-2+ license: Why not LGPL? It's a library after all. The style is not a library, it's a plugin.

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

Remove the parts on right-clicking and what-if. > Users will visit help if they need it, and right-clicking is common > functionality. Instead of adding mroe to make thing visible, we remove noise. > - Leave it as-is. *This is an option.* There are lots of places we could > be temp

Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut

> On Jan. 23, 2016, 5:31 p.m., Gregor Mi wrote: > > > If someone has changed the shortcut, they should know what shortcut they > > > set it to, right? So having the tooltip just say "To kill a specific > > > window, press the "Kill Window" shortcut (Ctrl-Alt-Esc by default)" > > > should do

Re: Review Request 126403: Get rid of QApplication dependency

marked as submitted. Review request for KDE Frameworks, kwin and Albert Astals Cid. Changes --- Submitted with commit 46c525f8fe77a10923eb2d604bf0f71bf59b5d1d by Thomas Lübking to branch master. Bugs: 354811 https://bugs.kde.org/show_bug.cgi?id=354811 Repository: kwindowsystem

Re: Widget style and color theme problems

Don't allow or set custom palettes w/ the gtk style. GtK+ isn't colorable (and if you try to write a bright on dark style, you'll figure that this isn't suported in real gtk applications either) No idea whether that's a problem in kf5 (or your application supports custom palettes) but if the

Re: Review Request 126403: Get rid of QApplication dependency

k. Stray junk indeed. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126403/#review90863 --- On Jan. 10, 2016

Re: Review Request 126403: Get rid of QApplication dependency

) - src/platforms/xcb/kwindowsystem.cpp 9d28704 Diff: https://git.reviewboard.kde.org/r/126403/diff/ Testing --- Albert performed a successful test on the bug. Thanks, Thomas Lübking ___ Kde-frameworks-devel mailing list Kde-frameworks-devel

Re: Review Request 126403: Get rid of QApplication dependency

adable. > > > > qApp should work too. It expands to exactly that, when #including > > QGuiApplication. I've no idea how that ended up there. Seriously not. On Jan. 10, 2016, 9:55 a.m., Thomas Lübking wrote: > > The commit log also needs to be updated, assuming it's stil

Re: Review Request 126403: Get rid of QApplication dependency

/platforms/xcb/kwindowsystem.cpp 9d28704 Diff: https://git.reviewboard.kde.org/r/126403/diff/ Testing (updated) --- Albert performed a successful test on the bug. Thanks, Thomas Lübking ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org

Re: Review Request 126403: Get rid of QApplication dependency

too simple" :-P > (I'm not sure whether we can/should that right now - while you should > explicitly link stuff you need, we don't live in a should-land) > > => If you can, give it a try (compiz isn't provided by my distro) > > Albert Astals Cid wrote: > I

Re: Review Request 118909: Imply SkipTaskbar and SkipPager depending on Window Type

> On June 23, 2014, 8:08 p.m., Thomas Lübking wrote: > > What about (non override) utility windows (eg. assume Qt would not set > > floating dock override to bring its own titlebar)? > > While kwin (iirc by default) hides them for inactive windows, that's

Re: Review Request 126403: Get rid of QApplication dependency

22 ------- On Jan. 2, 2016, 9:57 a.m., Thomas Lübking wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126403/

Re: Review Request 126403: Get rid of QApplication dependency

) - src/platforms/xcb/kwindowsystem.cpp 9d28704 Diff: https://git.reviewboard.kde.org/r/126403/diff/ Testing --- no, not the least. esp. not on the bug. Thanks, Thomas Lübking ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https

Re: Review Request 126403: Get rid of QApplication dependency

tter clone the combined screen area approach. Thanks for the catch. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126403/#review90395 --------

Re: robots.txt in quickgit.kde.org

On Montag, 28. Dezember 2015 18:09:32 CEST, Kevin Funk wrote: Are you aware that not even every KDE developer knows about LXR? I constantly have to tell people about it. Yes, and I'm as well aware of the "if it's not in google, it doesn't exist" phenomenon, BUT: that's not gonna work. If

Re: robots.txt in quickgit.kde.org

On Sonntag, 27. Dezember 2015 12:35:51 CEST, Ben Cooksley wrote: We could probably make it available by publishing the source trees used by LXR / EBN. Because if it's not in google, it doesn't exist? We've lxr which is a dedicated and *far* superior way to search our code, so what exactly

Re: Policy regarding QtWebKit and QtScript

On Freitag, 25. Dezember 2015 12:42:26 CEST, Milian Wolff wrote: Sorry, but how is "it takes long to compile" and argument for or against a piece of software if there is no feature equivalent alternative that takes less time to compile? How demanding is it exactly? Considering Gentoo users,

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Policy regarding QtWebKit and QtScript

On Dienstag, 22. Dezember 2015 19:44:21 CEST, Aleix Pol wrote: compiling for some time, but that's not a reason to rely on it on our side. Sure, getting rid of it is mandatory. What worries me is that this *break* happens in a *minor* Qt release. Should generally not happen. Period. It

Re: Policy regarding QtWebKit and QtScript

On Dienstag, 22. Dezember 2015 19:05:23 CEST, Ivan Čukić wrote: So, using Kross would mean implementing the kjs backend for it that we had in 4.x times? Isn't the designated successor for QtScript QJSEngine (I even assumed there should be some porting tools?) About QtWebkit - what exactly

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 19, 2015, 10:23 a.m., David Faure wrote: > > src/kdeui/kpushbutton.cpp, line 256 > > > > > > This patch looks wrong because KPushButton can be used outside of > > "dialog button boxes", while the

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 19, 2015, 10:23 a.m., David Faure wrote: > > src/kdeui/kpushbutton.cpp, line 256 > > > > > > This patch looks wrong because KPushButton can be used outside of > > "dialog button boxes", while the

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

nly in case Thomas > wants to pursue his view on fixing what there is to fix. > > You are right though, it's a workaround for KPushButton which doesn't > depend on fixing QPushButton. And whether or not QPushButton requires fixing > is apparently the big question. What is

Re: Why is C90 enforced in KDE?

On Sonntag, 20. Dezember 2015 04:21:29 CEST, Kevin Kofler wrote: The kdewin team should just point people to a flex.exe that produces files that work with the bitrotten C compiler included with Visual C++. So we only need somebody who forks the hardly maintained flex/yacc tools for

Re: Review Request 126397: [xcb] Safety check whether we have a QApplication in mapViewport

> On Dec. 17, 2015, 12:55 p.m., Thomas Lübking wrote: > > Looks like this boils down to multiple qApp->desktop()->size() calls, ie. > > displayWidth/displayHeight in kwinglobals.h, right? > > > > We could just "borrow" that code and kick the qApp dep

Re: Review Request 126397: [xcb] Safety check whether we have a QApplication in mapViewport

> On Dec. 17, 2015, 12:55 p.m., Thomas Lübking wrote: > > Looks like this boils down to multiple qApp->desktop()->size() calls, ie. > > displayWidth/displayHeight in kwinglobals.h, right? > > > > We could just "borrow" that code and kick the qApp de

Re: Review Request 126397: [xcb] Safety check whether we have a QApplication in mapViewport

t;size() calls, ie. displayWidth/displayHeight in kwinglobals.h, right? We could just "borrow" that code and kick the qApp dep then? - Thomas Lübking On Dec. 17, 2015, 9:21 a.m., Martin Gräßlin wrote: > > --- > This is a

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 11, 2015, 1:55 p.m., Thomas Lübking wrote: > > src/kdeui/kdialogbuttonbox.cpp, line 39 > > <https://git.reviewboard.kde.org/r/126308/diff/5/?file=421661#file421661line39> > > > > QDialogButtonBox::addButton should do correctly anyway, so pl

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 11, 2015, 1:55 p.m., Thomas Lübking wrote: > > src/kdeui/kdialogbuttonbox.cpp, line 39 > > <https://git.reviewboard.kde.org/r/126308/diff/5/?file=421661#file421661line39> > > > > QDialogButtonBox::addButton should do correctly anyway, so pl

Re: Review Request 126397: [xcb] Safety check whether we have a QApplication in mapViewport

> On Dec. 17, 2015, 12:55 p.m., Thomas Lübking wrote: > > Looks like this boils down to multiple qApp->desktop()->size() calls, ie. > > displayWidth/displayHeight in kwinglobals.h, right? > > > > We could just "borrow" that code and kick the qApp de

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 11, 2015, 1:55 p.m., Thomas Lübking wrote: > > src/kdeui/kdialogbuttonbox.cpp, line 39 > > <https://git.reviewboard.kde.org/r/126308/diff/5/?file=421661#file421661line39> > > > > QDialogButtonBox::addButton should do correctly anyway, so pl

Re: "Buttons have icons", round N+1

On Sonntag, 13. Dezember 2015 16:20:19 CEST, René J.V. wrote: There has been some discussion around one of my RRs concerning how to respect KDE's ShowIconsOnPushButtons and Qt's SH_DialogButtonBox_ButtonsHaveIcons style hint. The ultimate way would be in the style that does the actual

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 11, 2015, 1:55 p.m., Thomas Lübking wrote: > > src/kdeui/kdialogbuttonbox.cpp, line 39 > > <https://git.reviewboard.kde.org/r/126308/diff/5/?file=421661#file421661line39> > > > > QDialogButtonBox::addButton should do correctly anyway, so pl

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

/126308/#comment6> still wrong and again, please don't mess with the icon size - you're just tempting DIV zero segfaults. - Thomas Lübking On Dec. 11, 2015, 12:59 p.m., René J.V. Bertin wrote: > > --- > This i

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

n't really fix anything. We'll face the mix we had, just that users of QPushButton were far less prone to pass them an icon in pre-KF5 times. Please also attach Hugo Pereira Da Costa. - Thomas Lübking On Dec. 10, 2015, 9:01 p.m.,

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

n't really fix anything. We'll face the mix we had, just that users of QPushButton were far less prone to pass them an icon in pre-KF5 times. Please also attach Hugo Pereira Da Costa. - Thomas Lübking On Dec. 10, 2015, 9:01 p.m.,

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Review Request 126308: KPushButton: respect SH_DialogButtonBox_ButtonsHaveIcons, also when drawing

> On Dec. 10, 2015, 10:11 p.m., Thomas Lübking wrote: > > 1. What tells you that this is a dialog buttonbox pushbutton? > > 2. What happens if the button has no text? > > > > > > The bug is in QDialogButtonBox (or rather the K variant, > > QDialo

Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced

> It is irrelevant what our personal preference is. The fact of life is that there *are* mailing lists out there which perform these modifications, and these MLs won't change their config despite changes on our side. If we start rejecting these e-mails, well, our addresses will be unsubscribed

Re: Why is C90 enforced in KDE?

On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: Given you've said this multiple times, with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. I actually don't think this related at all.

Re: Why is C90 enforced in KDE?

On Montag, 7. Dezember 2015 03:14:05 CEST, Kevin Kofler wrote: not surprised that they are now using C99 comments (which ARE compliant to the current C standard, and have been for 16 years (!)). Sure, but since it seems it's the only C99 feature used(?, stdint is more a library thing, at

Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)

On Montag, 7. Dezember 2015 01:08:31 CEST, Nicolás Alvarez wrote: It will look better to stick my app logo into the real-artist-designed piece-of-paper-with-shadow than to draw an icon from scratch... Afaiu, one should have asked the oxygen team to avoid this kind of patched icons. I

Re: Why is C90 enforced in KDE?

On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a

Re: Why is C90 enforced in KDE?

On Sonntag, 6. Dezember 2015 16:08:04 CEST, Antonio Rojas wrote: C90. Adding -std=c99 to the CFLAGS at compile time doesn't have any effect, since it is overriden by kdelibs (and by extra-cmake-modules in KF5). What is the reason for this? I guess because of poor compiler support. One needs

Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)

On Sonntag, 6. Dezember 2015 22:23:01 CEST, Nicolás Alvarez wrote: I am aware that Nuno manually chose rendering engine and scaling method for every individual Oxygen icon based on seeing which one gave (subjectively) better results. That is not documented anywhere Seriously? I mean, are you

Re: Why is C90 enforced in KDE?

On Sonntag, 6. Dezember 2015 17:41:07 CEST, Nicolás Alvarez wrote: Then we ignore warnings about // comments and pay attention to others Wtf does flex/yacc produce incompliant comments? Seriously, COMMENTS! That's a convenience thing. int foo = bar; // bar defined in wherever is simpler than

Re: MacPorts Patches

On Montag, 30. November 2015 17:03:01 CEST, Martin Graesslin wrote: There have been various OSX patches being created against the kde-workspace repository in the past. So yeah, it seems to be part of what they want to achieve. I doubt it makes sense to run plasma-desktop/kwin/plasmashell on

Re: Causes of session management problems in Plasma 5

On Dienstag, 24. November 2015 02:02:46 CEST, Andreas Hartmetz wrote: - The session manager not "locking down" or better copying the list of clients *while* logging out. This would arguably only help buggy clients, but may still be a net positive. It would falsely restore clients that do

Re: Causes of session management problems in Plasma 5

On Donnerstag, 26. November 2015 05:19:34 CEST, Nicolás Alvarez wrote: What do you mean with "konsole asks"? Things like "You have multiple tabs open, are you sure you want to quit?" and "You have unsaved changes"? Yes. If so, the scenario you describe is bad regardless of session

Re: Causes of session management problems in Plasma 5

On Donnerstag, 26. November 2015 00:37:35 CEST, Andreas Hartmetz wrote: First, by copy I mean a temporary copy that is never merged back into the main list, it's kept around only to know which processes have already agreed to have their session saved and submitted the corresponding data.

Re: Kubuntu 15.04 Graphics Driver Issue

On Montag, 23. November 2015 07:50:43 CEST, gokul krishna wrote: ensure to blacklist the nouveau kernel module, drop the framebuffer from GRUB [1] and notice that only the most recent nvidia drivers are ABI compatible w/ Xorg 1.18 Also remove "nomodeset" and "splash" from your config (the

Re: [Kde-hardware-devel] Review Request 126146: [XRandRBrightness] Don't call for xrandr if it's not available

is not gonna mystically show up, one may wish to cache extension status validity in a tenary member (iff this constructor is called more often) Can't tell about "unrelated changes policy" in the component ;-) - Thomas Lübking On Nov. 23, 2015, 4 nachm., Kai Uwe Bro

Re: Review Request 126105: Fix yet another crash in Dolphin when Baloo isn't running

some file is present?? Please fix the actual bug instead of such workaround, got a backtrace? - Thomas Lübking On Nov. 18, 2015, 7:40 nachm., Boudhayan Gupta wrote: > > --- > This is an automatically generated e-mail. To rep

  1   2   3   4   5   6   7   8   9   10   >