Re: Has there ever been ...

Nate Graham wrote: > That version is over two years old and is not maintained. Can you maybe On an unrelated note: does the feature to raise and activate a window by scrolling the mousewheel (or doing a 2-finger scroll) still only work on inactive windows - and thus nothing if you use

Re: Has there ever been ...

René J. V. Bertin wrote: > René J. V. Bertin wrote: > > The scrollbar arrows are also not drawn correctly, > the bottom one seems clipped. This particular symptom was due to the Oxygen win-deco theme setting to add a resize handle to borderless windows. I hadn't noticed the hand

Re: Has there ever been ...

Nate Graham wrote: > That version is over two years old and is not maintained. Can you maybe > build the latest version from source? As I said, not easily: too many dependencies that need to be updated, including Qt. Too much work (not to mention, time) for a result I'm just not certain about.

Re: Has there ever been ...

Nate Graham wrote: > What version? 5.15.5 . As mentioned before, I cannot update to a more recent version easily on this system.

Re: Has there ever been ...

René J. V. Bertin wrote: > Update: using OpenGL 2 seems to have cured the glitching I have been > experiencing, apart from the occasional lack of immediate updating of a region > (like just now when I opened the KWin prefs dialog via the titlebar context > menu, which remained pa

Re: Has there ever been ...

René J. V. Bertin wrote: > Marco Martin wrote: > >> It doesn't and it never has. (transparecies and shadows without compositing) > ... > I see that KWin5 also has XRender support; I'll check if that or "lowly" > OpenGL 2.0 are suitable workarounds for me. Updat

Re: Has there ever been ...

Marco Martin wrote: > It doesn't and it never has. (transparecies and shadows without compositing) OK, I made a shortcut, sorry for that. Transparency and shadows do work with XRender compositing so I suppose I should have talked about "OpenGL compositing". I see that KWin5 also has XRender

Re: Has there ever been ...

Jonathan Riddell wrote: > This is pretty insulting, it would be better not to continue with this > thread. > Hah, well, I suppose the truth can hurt but I didn't think I I was writing anything that anyone would take personally. I didn't and don't lay any blame - but I do know I'm not the 1st,

Has there ever been ...

Hi, Has there ever been a KWin version that was just (or predominatly) a straight port of the latest KWin4 to Qt5 and KF5? Lately I find myself using KWin4 again because 1) it doesn't cause any glitching even with (OpenGL 2.0) compositing activated 2) it supports the few effects I find crucial

KWin refuses to start with compositor enabled?!

Hi, I updated my home-built KWin 5.13.3, first to 5.13.3, then to 5.15.5 in hopes of experiencing less compositing glitches (that required me to restart KWin several times a day, ultimately forcing my back to xfwm4). The jury is still out if there are less frequent glitches (and if those that

Qt/XCB drawing on the root window

Hi, I have some old Qt4 code I'm porting to Qt5 that includes this ``` void MyApplication::renderDone() { QPalette palette = desktop()->palette(); palette.setBrush(desktop()->backgroundRole(), QBrush(renderer->pixmap())); desktop()->setPalette(palette);

black screen with mouse cursor under kernel 5.7.14 with i915 driver on Cherrytrail & Baytrail CPUs

Hi, Not a KDE issue in itself (I think) but one that certainly does affect Plasma; I'm posting it here to see if someone has seen this too and found a fix. After installing a home-built 5.7.14 kernel I'm getting an all-black screen with just the mouse cursor visible on my Cherrytrail (N3150)

Re: dipping a toe in waywater? :)

René J. V. Bertin wrote: > And applications that I start with `-platform wayland` aren't decorated, as if > kwin is either a WM or else a wayland compositor, but not the former inside > the latter... Which is actually what I was hoping to get! OK, belay that, apparently was becaus

Re: dipping a toe in waywater? :)

Kai Uwe Broulik wrote: > Is it Mac OS? No, nor a bird, nor a tree ;) Even I wouldn't dream of testing KWin/Wayland on Mac. Just yet - I do dream of Wayland supporting Darwin but there a few too many dependencies on the Linux kernel for that (in KWin too, IIRC) that should be resolved first. A

Re: dipping a toe in waywater? :)

David Redondo wrote: > Hello René, > > maybe this blog post from Aleix can help you. It explains how to started a > nested session or wayland session. > https://www.proli.net/2020/04/03/developing-kwin-wayland/ Thanks David. That does look like things I already tried (and didn't work; starting

Re: K'fusion, or descending Fusion from KStyle

In reply to underwhelming request: github.com/RJVB/qtstyleplugins contains a clone of Qt's 5.12 built-in Fusion style that inherits KStyle, rebaptised KFusion and with a few minor other tweaks. R.

dipping a toe in waywater? :)

Hi, I hope this is the best place to ask: I understand that KWin is its own wayland server/compositor/whatever-you-call it, so it might be possible to use kwin_wayland to get an impression of running a desktop under Wayland instead of X11? If so, is there a succinct tutorial somewhere showing

D13881: oxygen-demo : add KMessage preview

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 R113:ad3cddb5954e: Fix the KDE4 build of the oxygen-demo (authored by rjvbb). CHANGED PRIOR TO COMMIT

D13881: oxygen-demo : add KMessage preview

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R113:d299d6ebc195: add KMessage preview to the demo (authored by rjvbb). CHANGED PRIOR TO COMMIT

KFusion style

Hi, A while back I asked for some guidance in getting the Fusion style to inherit KStyle. Apparently there was no real interest in doing such a thing so in the end I rolled my own implementation, using a private, adapted copy of the KStyle class. Contrary to that I thought, you cannot

K'fusion, or descending Fusion from KStyle

Hi, I had a recent run-in with a style hint that should actually be a platform-specific property (à la AA_DontUseNativeMenuBar; see QTBUG-77928) and then realised it could be useful to have a Fusion override style that inherits KStyle, given that more and more applications seem to adopt this

D22460: DrKonqi: improved lldb integration

rjvbb created this revision. rjvbb added reviewers: kde-frameworks-devel, Plasma. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. rjvbb requested review of this revision. REVISION SUMMARY Since a few versions lldb has had a tendency to remain stuck after the initial

KDE file dialog column resize no longer possible?

Hi, Sorry for cross-posting (initially), I'm not certain which list is the most appropriate. It's often been tricky to trigger column resize mode in the KDE file dialog (when in one of the detailed view modes) but I realise I haven't been able to do this at all for a little while now. I just

freedesktop.notifications daemon - crossplatform alternatives?

Hi, Sorry for a somewhat off-topic question. As far as I can tell the KF5/Plasma5 freedesktop notifications implementation is really not easily isolated even if it probably would be cross-platform. (I can run the systray widget in plasma-windowed, but that isn't really satisfactory.) Why the

D4929: DrKonqi : lldb and Mac support

rjvbb added a comment. > This revision was not accepted when it landed; it landed in state "Needs Review". Because I asked David if he'd seen the very last (=just committed) revision when he accepted this. He'd have infirmed that by now if our posts had crossed so I felt I could push

D4929: DrKonqi : lldb and Mac support

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R871:13121f4a303b: lldb and Mac support (authored by rjvbb). REPOSITORY R871 DrKonqi CHANGES SINCE LAST UPDATE

D4929: DrKonqi : lldb and Mac support

rjvbb marked an inline comment as done. rjvbb added a comment. David, it seems our posts crossed, or did you actually see the new version I just uploaded? REPOSITORY R871 DrKonqi REVISION DETAIL https://phabricator.kde.org/D4929 To: rjvbb, #plasma_workspaces, kfunk, davidedmundson Cc:

D4929: DrKonqi : lldb and Mac support

rjvbb updated this revision to Diff 46309. rjvbb marked 2 inline comments as done. rjvbb added a comment. Fixed the AppleTerminal oversight in the non-Apple lldbrc. Also, I've removed the m_lldbDetached backend-specific member var. Instead, I now use the `m_proc` variable itself, and

D4929: DrKonqi : lldb and Mac support

rjvbb marked 3 inline comments as done. rjvbb added inline comments. INLINE COMMENTS > davidedmundson wrote in lldbrc:7 > Linux has lldb too > > I assumed that's why you also had a "src/data/debuggers/external.mac/lldbrc" > as well as this file. Ah, oops, good catch! Evidently the non-Mac

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps

This revision was automatically updated to reflect the committed changes. Closed by commit R858:1e02355c1786: Support for QGuiApplication-based apps (authored by rjvbb). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D14000?vs=44083=46108#toc REPOSITORY R858 Qt Quick Controls 2:

D4929: DrKonqi : lldb and Mac support

rjvbb added inline comments. INLINE COMMENTS > davidedmundson wrote in backtracegenerator.cpp:140 > Yes > > Also is it worth adding a "break;" there? A break instead of or in addition to the return? I think I'd prefer the return, unless you think that maybe someday there will be some extra

D4929: DrKonqi : lldb and Mac support

rjvbb added a comment. > That'll probably be when we move to Qt6. Which is something I hope will be as far in the future as possible :) but > I doubt it really would make anyone's lives easier. Moving something outside of what I secretly call the Plasma jealousy universe

D4929: DrKonqi : lldb and Mac support

rjvbb updated this revision to Diff 46044. rjvbb added a comment. includes the root cmake file changes. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4929?vs=46025=46044 REVISION DETAIL https://phabricator.kde.org/D4929 AFFECTED FILES CMakeLists.txt src/CMakeLists.txt

D4929: DrKonqi : lldb and Mac support

rjvbb added a comment. > a find_packge for `KF5::WindowSystem` is missing in the root CMakeLists file. Ah, thanks. I have that in my own cmake file of course, but also an unrelated change I thought I could safely keep out by just taking a diff of the `src` directory. I test

D4929: DrKonqi : lldb and Mac support

rjvbb added a comment. > Can you rebase it over the last master branch ? I did that hours ago, or at least I thought I did?! Is there a commit later than 62c33ba3a885106f31706cbfecc75190ca00c70c which I

D4929: DrKonqi : lldb support

rjvbb updated this revision to Diff 46025. rjvbb added a comment. Refactored for the standalone DrKonqi repo and disabled the integration testing on Mac. Making DrKonqi standalone is a good step, I'd strongly suggest to move it to KF5 Applications at the first possible occasion. The

D4929: DrKonqi : lldb support

rjvbb marked an inline comment as done. rjvbb added a comment. Sorry, I had updating this on my list but it drifted to the bottom... I think I've addressed all feedback apart from the `m_lldbDetached` variable Kevin objected to. I'm open to suggestions how to make that aspect less

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

rjvbb updated this revision to Diff 44083. rjvbb added a comment. updated for the current git/head. David: did you perhaps forget to accept the revision (aka, should I have committed this)? CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D14000?vs=37897=44083 REVISION DETAIL

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

rjvbb updated this revision to Diff 37897. rjvbb added a comment. Using QApplication::style() CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D14000?vs=37568=37897 REVISION DETAIL https://phabricator.kde.org/D14000 AFFECTED FILES plugin/kquickstyleitem.cpp

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

rjvbb updated this revision to Diff 37568. rjvbb added a comment. build on Mac too CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D14000?vs=37439=37568 REVISION DETAIL https://phabricator.kde.org/D14000 AFFECTED FILES plugin/kquickstyleitem.cpp plugin/kquickstyleitem_p.h To:

D13881: oxygen-demo : add KMessage preview

rjvbb marked 3 inline comments as done. rjvbb added a comment. Ping? REPOSITORY R113 Oxygen Theme REVISION DETAIL https://phabricator.kde.org/D13881 To: rjvbb, hpereiradacosta Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas,

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

rjvbb updated this revision to Diff 37439. rjvbb edited the summary of this revision. rjvbb edited the test plan for this revision. rjvbb added a comment. Getting the user's desktop style was easier than I thought. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D14000?vs=37437=37439

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

rjvbb created this revision. rjvbb added a reviewer: Framework: Syntax Highlighting. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. rjvbb requested review of this revision. REVISION SUMMARY See https://bugs.kde.org/show_bug.cgi?id=396287

D13881: oxygen-demo : add KMessage preview

rjvbb added a comment. A couple of snapshot (with my current KMessageWidget facelift; styles and themes switched "on-the-fly"): Oxygen with the Oxygen theme: F6014853: image.png Breeze with Breeze-Dark: F6014872: image.png

D13881: oxygen-demo : add KMessage preview

rjvbb updated this revision to Diff 37155. rjvbb added a comment. Updated as (hopefully) requested. I've left the property change event filter, for builds against older than 5.48.0 (or whatever version D13884 will appear in). There is one

D13881: oxygen-demo : add KMessage preview

rjvbb added inline comments. INLINE COMMENTS > broulik wrote in oxygenframedemowidget.cpp:90 > What do you need this for? That's to catch the event sent to the qApp instance when the theme is changed (to be exact: after KColorSchemeManager sets or changes the `KDE_COLOR_SCHEME_PATH` property.

D13881: oxygen-demo : add KMessage preview

rjvbb created this revision. rjvbb added a reviewer: hpereiradacosta. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. rjvbb requested review of this revision. REVISION SUMMARY A recent change to the `KMessageWidget` look has caught my

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. David, Could you please push it for me? I probably won't be able to do so for at least a week and it'd be a pity if the change just misses a release because of that. Thanks. REPOSITORY R135 Integration for Qt applications in Plasma REVISION DETAIL

gtk3 integration?

Hi, I recently came across something called qt-gtk-engine (a bit of LXDE abandonware) which reminded me that I never found a satisfactory way to integrate GTk3 apps with my preferred look and feel, esp. not with more recent GTk3 versions. Oxygen-gtk3 comes closest but that project hasn't seen

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > In the code shown by this patch ;) Line 80. Right. Doh. The line that causes other side-effects when you comment it out :) > But the test you suggested that I do above is further proof anyhow. > > But even without setStyleName call (i.e.

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > Unfortunately, this patch doesn't fix it. The text still isn't bold. No, this patch is written to be as transparent as possible. It won't impose a stylename, but will not remove it either. What happens when you remove the `,Regular`, i.e. [General]

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > Thanks for the info! So if/hen this goes in, what are the next steps? I'd say - decide whether this is an issue you want to solve only for plasma environments, or for all platforms where KF5 applications are supported. - draw up the conditions under

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. A diagonally related anecdote that shows this location is a more central point in the font selection process than I thought first: Applications like Qt's Assistant that call for Helvetica often end up using a font that looks pixelated - because it's actually an

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > Is this change purely a conversation of what developers use in code to call up fonts in their applications? I think so. > Or does this also include a discussion where regular users have interfaces that allow changes to font naming? Let's say, something

D10092: [Examples] Fix build

rjvbb accepted this revision. rjvbb added a comment. This revision is now accepted and ready to land. LGTM. The examples seem to have a circular runtime dependency on (at least) plasma-desktop. Is that just an opportunistic dependency (= they'd work fine you'd only just installed

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

David Edmundson wrote: My previous reply to this seems to have gone missing. > That plugin has it's own system tray handling that uses KNotification, > instead of the platform DBus code you looked at in Qt. > Combined with a getenv check in knotification will be the source of your > issue. I

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

David Edmundson wrote: > You missed reading the code that calls this in > src/widgets/util/qsystemtrayicon_x11.cpp which will make an X system tray > if the platform doesn't. I understand now why this doesn't happen in my case. Out of scope here. > That plugin has it's own system tray handling

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

>>It's not plasma-specific > > It is. Hence the name... Just have a look at what it actually does; nothing requires a plasma environment to be present (with the possible exception of the look-and-feel feature but that's far from crucial). Its goal is to provide theming (visual and

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

David Edmundson wrote: > You missed reading the code that calls this in > src/widgets/util/qsystemtrayicon_x11.cpp which will make an X system tray > if the platform doesn't. Indeed, but that's curious. I see what you mean, but I followed the flow in a debugger and AFAICT the qpa_sys==NULL

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

René J. V. Bertin wrote: > PS: Ah, when I move the platform integration plugin aside I indeed get a > systray icon. Hmmm... Hmmm indeed. Pushing the plugin aside doesn't take down an already running host of course. When I do that too, the error message comes back that tells me that no s

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

Hi, > I think you've only half analysed this. If nothing is really listening on > DBus it will fall back to legacy X which will work on XFCE. Where did I miss this in the code? The createPlatformSystemTrayIcon() functions in qtbase/src/platformsupport/themes/genericunix/qgenericunixthemes.cpp

DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

Hi, I'm running a simple XFCE environment on a Unix rig (not Linux) and thought some dependency was missing because the xfce4-panel notification area remained empty - until I noticed that it works just fine when GTk2 applications try to use it. Following the initialisation I now see that the

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > So this this actually resolve https://bugs.kde.org/show_bug.cgi?id=378523, or just lay the groundwork for resolving it? No, it's more a change similar to proposed fix for that bug (don't set a stylename in KFontRequester). This patch implements the

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. If you read https://bugreports.qt.io/browse/QTBUG-63792?focusedCommentId=381570 the take-home message seems to be that the platform theme plugin (and KDE in general) shouldn't be messing with setStyleName() at all UNLESS asking for a font with properties that cannot

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > On the other hand, calling setBold(true) on a font called "HandwriteCursive" _should_ select "HandwriteBoldCursive", even if the styleName was intended to enforce a specific face. If Qt cannot fix this issue, then we have to clear the styleName() at least for those

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. > IMO that's a feature though and is the expected behaviour. For instance, if we change the default window title to be bold, users with "windowTitle=Comic Sans" will also have a bold title. So how would you "change the default window title to be bold" and more

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb added a comment. It depends a little bit what kind of call you make. But yes, certain "conflicting" attributes can no longer be set. A particular example reported by many is setting bold. If you do `setStyleName("Regular")` on a Qfont, `setBold(true)` will no longer have the intended

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

rjvbb created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Applying the default, hardwired QFont::styleName to one of the standard fonts which then gets changed to a user-selected font can break

Re: KWin5 memory leak?

On Monday November 13 2017 17:20:56 Martin Flöser wrote: Hi, Is it possible that many if not most of the users who might report this kind of issue use (very) fast disks combined with lots of RAM (and possible tiny amounts of swap space) nowadays? (Meaning they never notice anything out of the

KWin5 memory leak?

Hi, This is something I also noticed with KWin4 but which seems to be worse with KWin5 (v5.11.1, FW 5.38.0, Qt 5.8.0 and the Breeze windowtheme): After a big compile job (like building QtWebKit) performed in the background (output redirected to file) with Google Chrome and Kontact running (in

D8307: Make Qt5::X11Extras really optional

rjvbb added inline comments. INLINE COMMENTS > apol wrote in CMakeLists.txt:32 > Is this change needed? I don't understand, since when has DrKonqi been split out of plasma-runtime? Plasma-runtime had a different approach: search for X11Extras only when X11 was found. I think that's the better

D8308: macOS: Don't create bundles for test executables

rjvbb accepted this revision. rjvbb added inline comments. INLINE COMMENTS > apol wrote in CMakeLists.txt:7 > Maybe we could assume tests are non_gui by default? For Mac there is only a theoretical difference in fact; nongui builds are non-bundled but you have to try really hard nowadays to

Re: using KWin's wayland compositor under an X11 session?

Hi, > ​You can run it nested; so you have a wayland session in a window. Like > Xephyr. > > But if you want to play with it, just choose it at the login manager, you > don't need to uninstall X11. Neither is really what I want, or can (my login manager doesn't know about wayland). I do have a

using KWin's wayland compositor under an X11 session?

Hi, Is it possible somehow to use KWin's wayland compositor when it's acting as the window server of an X11 session? I understand that the opposite is possible. I have little idea about the technical feasibility of what I'm asking but that aside it for anyone like me who feels wayland isn't

D7640: QtCurve: reduce progressbar timer overhead

rjvbb added a comment. Implementing on-demand/JIT starting of the timer also allowed to kill the timer when all progressbars stopped animating, in the end. No more need for the idling frequency trick. REPOSITORY R626 QtCurve REVISION DETAIL https://phabricator.kde.org/D7640 To: rjvbb,

D7640: QtCurve: reduce progressbar timer overhead

This revision was automatically updated to reflect the committed changes. Closed by commit R626:d9d2bb0dcb01: reduce progressbar animation timer overhead (authored by rjvbb). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D7640?vs=19073=19096#toc REPOSITORY R626 QtCurve CHANGES SINCE

D7640: QtCurve: reduce progressbar timer overhead

rjvbb added a comment. Never too old to learn, thanks :) REPOSITORY R626 QtCurve REVISION DETAIL https://phabricator.kde.org/D7640 To: rjvbb, yuyichao, #plasma Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart,

D7640: QtCurve: reduce progressbar timer overhead

rjvbb added a comment. > This should not be necessary. You can add `mutable` or do const cast for certain members. Right. Never used that myself it wasn't my 1st reflex. But I don't see how could do either for startTimer()? REPOSITORY R626 QtCurve REVISION DETAIL

D7640: QtCurve: reduce progressbar timer overhead

rjvbb set the repository for this revision to R626 QtCurve. REPOSITORY R626 QtCurve REVISION DETAIL https://phabricator.kde.org/D7640 To: rjvbb, yuyichao, #plasma Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

rjvbb updated this revision to Diff 19073. rjvbb added a comment. Following Breeze's example, we can defer the creation of a timer for the busy/indeterminate state to when we encounter one, i.e. when `Style::drawControl()` is called with `CE_ProgressBarContents`. Determining if the

D7640: QtCurve: reduce progressbar timer overhead

rjvbb added a comment. Actually we do when the last progressbar is hidden, destroyed (or gets a QEvent::Close, testing that now). The reason we need to run a timer when progressbars are visible is how their busy mode is implemented. That does not have a separate state and there's no

D7640: QtCurve: reduce progressbar timer overhead

rjvbb set the repository for this revision to R626 QtCurve. REPOSITORY R626 QtCurve REVISION DETAIL https://phabricator.kde.org/D7640 To: rjvbb, yuyichao, #plasma Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

rjvbb updated this revision to Diff 19044. rjvbb edited the summary of this revision. rjvbb added a comment. cleaned up version that also switches the timer back to idling frequency CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7640?vs=19042=19044 REVISION DETAIL

D7640: QtCurve: reduce progressbar timer overhead

rjvbb created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY Debugging an unrelated timer issue with GammaRay I noticed QtCurve can have multiple progressbar timers active in more complex applications

Re: start menu icon

On Wednesday August 30 2017 05:20:53 Duncan wrote: Echoing this to the plasma-devel list so that at least they're aware of the use-case (with apologies for top-replying to those who take offense). If indeed each launcher is a separate plasmoid and each plasmoid has its own settings one could

Re: querying current mouse state

On Thursday August 10 2017 17:15:20 Martin Flöser wrote: > Point is: if the kernel could read the information from the device, it > would know it. I don't think that the kernel knows it, which means I > don't think that the device driver has that. Hmm. That still might make sense for position

Re: querying current mouse state

Martin Flöser wrote: Hi > of the buttons, but just sends the press events. I'm pretty sure that > not even the kernel knows it, otherwise libinput would expose it. It doesn't need to know it (and probably shouldn't because why would it). All it needs to know is how to read the information

Re: querying current mouse state

David Edmundson wrote: > In wayland you never query anything, only track events. There are applications for which this isn't good enough but I guess there must be other, low-level ways to query the current state of a given input device or sensor. > What actually do you want to do? I'm toying

querying current mouse state

Hi, Is there any class or function available in Qt or KF5 that allows to query the current state of the mouse on X11 and/or Wayland and that is not based on internal event handling? Alternatively, is such a function available in a library that is already used anyway by every application that

Re: KTitleWidget and the native Mac style

On Wednesday July 05 2017 10:58:59 Hugo Pereira Da Costa wrote: >No >the default is false (no frame): > >breeze.kcfg: > > > >false > > Curious, I've always seen Breeze display the frame, and never activated the option as far as I can remember. I did notice yesterday that breezerc doesn't

Re: KTitleWidget and the native Mac style

On Wednesday July 05 2017 09:55:27 Hugo Pereira Da Costa wrote: (CC'ing the plasma-devel ML and thus keeping Hugo's full reply as context.) >On 07/04/2017 11:13 PM, René J.V. Bertin wrote: >> On Tuesday July 04 2017 20:16:55 Sebastian Kügler wrote: >> >> @Kevin: should we continue to CC you? >>

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

rjvbb added a comment. > Nevertheless OS X is not supported by kscreenlocker and will never be. You got it all wrong, OS X doesn't support kscreenlocking, gna! (If I were still a fanboy I'd add that it's way too kool to support running most kinds of plasma O:^) ) REPOSITORY

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

rjvbb added a comment. In https://phabricator.kde.org/D5825#112464, @davidedmundson wrote: > OS X is not a supported Plasma platform, BSD is. Just for future reference: OS X doesn't have sigwaitinfo() (or the cited alternative). REPOSITORY R133 KScreenLocker REVISION DETAIL

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

rjvbb added a comment. Already getting updates through kde-mac, no need to receive everything twice. REPOSITORY R133 KScreenLocker REVISION DETAIL https://phabricator.kde.org/D5825 To: tcberner, #freebsd, graesslin, kde-mac Cc: adridg, davidedmundson, plasma-devel, ZrenBot, spstarr,

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

rjvbb added a comment. In https://phabricator.kde.org/D5825#112442, @tcberner wrote: > > Do you actually intend to test this on Mac? > > Nope, I don't have a Mac :) -- but I hoped, that there were some Mac users who could check it on their end too (as you also have kqueue/kevent) --

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

rjvbb added a comment. In https://phabricator.kde.org/D5825#109698, @tcberner wrote: > I have not yet had time to test it at all :) Do you actually intend to test this on Mac? I laud and applaud the initiative but I see only one way that the package will ever get used on Mac -

Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes

On Saturday May 06 2017 22:01:58 Ben Cooksley wrote: >On Sat, May 6, 2017 at 9:58 PM, René J.V. Bertin wrote: >> On Saturday May 06 2017 21:37:51 Ben Cooksley wrote: >> >>>'Platforms' on which they build. At the moment we have three Platforms >>>available: Ubuntu Xenial Qt

Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes

On Saturday May 06 2017 21:37:51 Ben Cooksley wrote: >'Platforms' on which they build. At the moment we have three Platforms >available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7. >Adding additional Platforms to this mix is fairly easy, as long as the >code can be built there. Qt

D5186: Add a widget style chooser to oxygen-demo

rjvbb abandoned this revision. rjvbb added a comment. Closed with commit https://commits.kde.org/oxygen/3677f75e956e1946cd0ee775ff2969d0b2ecf1c7 REPOSITORY R113 Oxygen Theme REVISION DETAIL https://phabricator.kde.org/D5186 To: rjvbb, hpereiradacosta Cc: plasma-devel, #plasma, spstarr,

D5186: Add a widget style chooser to oxygen-demo

rjvbb set the repository for this revision to R113 Oxygen Theme. REPOSITORY R113 Oxygen Theme REVISION DETAIL https://phabricator.kde.org/D5186 To: rjvbb, hpereiradacosta Cc: plasma-devel, #plasma, spstarr, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

  1   2   3   >