D5186: Add a widget style chooser to oxygen-demo

rjvbb updated this revision to Diff 13755. rjvbb added a comment. Final version. Most of the forward declarations were actually redundant. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5186?vs=13702=13755 REVISION DETAIL https://phabricator.kde.org/D5186 AFFECTED FILES

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

D5186: Add a widget style chooser to oxygen-demo

rjvbb updated this revision to Diff 13702. rjvbb added a comment. Simplified style selector widget that just shows the available styles and "ticks" the currently active style. CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D5186?vs=12832=13702 REVISION DETAIL

D5186: Add a widget style chooser to oxygen-demo

rjvbb added a comment. In https://phabricator.kde.org/D5186#99745, @hpereiradacosta wrote: > In any case, none of this is really necessary here: IMHO the menu should just have the list of available styles (StyleFactory::keys()) and the "correct" radiobox selected at startup. > Wdyt ?

Re: proper use of QFlags

Marco Martin wrote: > can you do a phab review about it? https://phabricator.kde.org/D5470

Re: proper use of QFlags

Marco Martin wrote: >> Am I right that the argument `QFlags state` should simply be `State >> state`? > > can you do a phab review about it? Of course, but that seemed a bit overkill if this is an evident error, or if ultimately the runtime behaviour remains the same. I understand from a

proper use of QFlags

Hi, The QtCurve style fails to build against Qt 5.9.0: it triggers a compile-time assert in the QFlags class on the function below. Am I right that the argument `QFlags state` should simply be `State state`? It seems logical given that the `State` type is already a `QFlags` but I find it

[Plasma4]: session no longer restores to chosen (virtual) desktop

Hi, Please allow a question that apparently requires intimate knowledge of implementation details: All of a sudden my Plasma4 session is being restored to a single desktop instead of to the desktops on which windows were open when I saved the session. What's more, the windows of my standard

D5186: Add a widget style chooser to oxygen-demo

rjvbb created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This adds the widget style chooser evoked during the colour scheme chooser review (https://phabricator.kde.org/D5113). REPOSITORY R113

Re: Styles & KWin contextmenus: how to detect when a window/app uses a different palette?

PS: I don't really have an opinion about this: is it wrong for a window manager to ignore the fact that a window/application uses a different palette? I don't know any other WM (*) that adapts its decoration palette automatically to each decorated window's palette. I could easily image a

Styles & KWin contextmenus: how to detect when a window/app uses a different palette?

Hi, What's the best way to detect >at the level of a style's menu rendering methods< whether or not the application or even the widget in question uses a different palette than the current desktop colour palette? I have a draft method which works fine where I want it to but tends to trigger in

Re: style not drawing menu section/separator if 1st in menu

Christoph Feck wrote: > On 21.03.2017 16:36, René J. V. Bertin wrote: >> FWIW the same thing happens with both Breeze and Oxygen in their Qt4 >> versions. > > Expected, since QMenu:addSection() is new in Qt 5. True, but not the possibility to set a text hint on a sep

Re: style not drawing menu section/separator if 1st in menu

René J. V. Bertin wrote: >> Always test with Fusion style. If it works there, the bug is in QtCurve. > > FWIW the same thing happens with both Breeze and Oxygen in their Qt4 versions. For future reference: In the end I got out the debugger and traced the issue into Qt, realising th

Re: style not drawing menu section/separator if 1st in menu

Christoph Feck wrote: > Always test with Fusion style. If it works there, the bug is in QtCurve. FWIW the same thing happens with both Breeze and Oxygen in their Qt4 versions. R.

Re: KWin contextmenus usability and window/app specific palettes

Martin Gräßlin wrote: Oops, this reply sat unsent in the background for a few days as I went off on another hunt for something more urgent. KWin5 turns out to have a tendency to become unstable on my system, resulting in visual glitches with screen contents not being updated properly when I

Re: style not drawing menu section/separator if 1st in menu

Christoph Feck wrote: > Always test with Fusion style. If it works there, the bug is in QtCurve. Evidently, but that was never the question. I'm trying to find the bug or whatever it is in QtCurve...

Re: style not drawing menu section/separator if 1st in menu

Kai Uwe Broulik wrote: > Separators cannot be at the beginning or end of a menu and there can't be two > next to each other. Section is what you want to use for labeled entries but > for styles that don't implement that they'll be regular separators. I know, those are the functional differences.

style not drawing menu section/separator if 1st in menu

Hello, I just noticed that my usual widget style fails to draw menu sections and separators if they're the 1st item in a menu. Not a big deal for regular separators, more so for texted separators aka menu sections. It seems that Style::sizeFromContents() and Style::drawControl() aren't even

D5113: add colour scheme chooser to oxygen-demo

rjvbb created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This is a split-off of https://phabricator.kde.org/D5111 , proposing the addition of a colour scheme chooser to the Oxygen demo application.

D5111: Provide demo/preview for checkable menu items and colour scheme comparison

rjvbb created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY This is a continuation/transfer of https://git.reviewboard.kde.org/r/128109/ (which still has a few screenshots) There currently is no

Re: KWin contextmenus usability and window/app specific palettes

Martin Gräßlin wrote: Hi, > KWin is only involved starting in point 4. 1-3 are in the application. I think I'm beginning to grasp what's going on, thanks. QtCurve has a feature that allows to specify a modification of the menu background shade, which I have to set to 100% lighter. That would

Re: KWin contextmenus usability and window/app specific palettes

Martin Gräßlin wrote: Thanks for the info. > I need to explain the whole interaction: > 1. Applications can use KColorSchemeManager to set a color scheme. > 2. This gets installed as a dynamic property in the QGuiApplication This happens in KColorSchemeManager or at a lower level? > 3.

Re: KWin contextmenus usability and window/app specific palettes

subsidiary question: QtCurve connects to certain signals that I think come from KWin: bus.connect("org.kde.kwin", "/KWin", "org.kde.KWin", "compositingToggled", this, SLOT(compositingToggled())); QString arg0 = qApp? qApp->arguments()[0] : QString(); if (!qApp ||

KWin contextmenus usability and window/app specific palettes

Hi, I've mentioned an issue where the window context menus drawn by QtCurve do not adopt a new colour palette correctly when I change a window's or application's palette from the session default. This happens both when I use a window or app KWin rule and when I change the application palette

Re: KWin5 and colour scheme special application setting (the case of the WM menus)

On Friday March 17 2017 05:48:36 Duncan wrote: Replying with CC to the plasma-devel list as this appears to be relevant: >> Something I didn't yet notice: KWin doesn't seem to respect the setting >> when I restart the application. It's still there, and applied when I >> click through the app

D4929: DrKonqi : lldb support

rjvbb updated this revision to Diff 12368. rjvbb added a comment. platform-specific data/debuggers/external *rc files and installation of the AppleTerminal script. gdb and lldb are now both started via that script on Mac and via konsole elsewhere. CHANGES SINCE LAST UPDATE

D4929: DrKonqi : lldb support

rjvbb added inline comments. INLINE COMMENTS > kfunk wrote in backtracegenerator.h:87 > Looks pretty unclean to have a backend-specific variable around here. I suppose I could replace m_lldbDetached with something like bool Debugger::isDetached(const QString =QString()) { if

D4929: DrKonqi : lldb support

rjvbb added inline comments. INLINE COMMENTS > kfunk wrote in backtracegenerator.h:87 > Looks pretty unclean to have a backend-specific variable around here. I missed this one. I don't think it's possible to detect detaching (from the debugger output!) elsewhere but in the bt. generator. Not

D4929: DrKonqi : lldb support

rjvbb updated this revision to Diff 12360. rjvbb added a comment. This new version incorporates most of the changes Kevin requested. Quitting lldb through 1. a python "lambda" 2. the quit command seems to work reliably enough on Mac. It still uses AppleTerminal.sh

D4929: DrKonqi : lldb support

rjvbb marked 8 inline comments as done. rjvbb added inline comments. INLINE COMMENTS > kfunk wrote in backtracegenerator.cpp:62 > Please do this only if `lldb` is used then. No need to change code which > apparently worked fine for years. Also, did you try `QProcess::terminate` > instead? >

D4929: DrKonqi : lldb support

rjvbb marked 4 inline comments as done. rjvbb added inline comments. INLINE COMMENTS > kfunk wrote in backtracegenerator.cpp:62 > Please do this only if `lldb` is used then. No need to change code which > apparently worked fine for years. Also, did you try `QProcess::terminate` > instead? >

QtCurve window theme

Hi, I've started to use KWin5 on my FranKDEn 4+5 desktop, running it on KUbuntu 14.04 from the parallel prefix where I install my home-built Qt5 and KF5 software. This works pretty (surprisingly?) good with the current v5.9.3 and at least feels faster than KWin4. It also makes porting

Re: drawing on the X11 root window with Qt5

Kai Uwe Broulik wrote: > Note that KWIN doesn't render the X11 root window when compositing is enabled > so this would be of little use. ‎ Who says this is for use when KWin is active too? :) Even with KWin 5.9.3 running applications like xscreensaver somehow manage to make the root window

drawing on the X11 root window with Qt5

Hello, May I ask a question not directly related to Plasma but that hopefully concerns a trick used in some Plasma component? Basically, is it still possible to get a QWidget corresponding to the X11 root window and draw on it as on any other QWidget, and if so, how does one do that? A few

D4929: DrKonqi : lldb support

rjvbb added a comment. In https://phabricator.kde.org/D4929#93093, @mart wrote: > hmm, frameworksintegration? (but still in frameworks side) Bundling with, you mean? That could work too. It's not really the topic of this review request, but I discussed the idea of bundling

D4929: DrKonqi : lldb support

rjvbb retitled this revision from "DrKonqi : lldb support (and cross-platform adaptation)" to "DrKonqi : lldb support". rjvbb edited the summary of this revision. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D4929 To: rjvbb, #plasma_workspaces Cc: broulik,

Re: [KDE4] what component does the screenlocking?

Kai Uwe Broulik wrote: > Turn the screen off. Problem solved. Sure, that's why I use computers, to have to remember myself to do everything by hand... I'd suggest to remove all current hooks into power management too if that's the prevalent mindset - just turn the computer off. Problem

Re: [KDE4] what component does the screenlocking?

Kai Uwe Broulik wrote: > You can disable automatic locking in System Settings -> Workspace Behavior -> > Lock Screen‎ I know, but the checkbox next to "ask password after" is gone so you can no longer disable locking while keeping a screensaver feature. As if no one would want to prevent

plasma-desktop 5.9.3 : "no return value" compile failure in boost functions

Hello, I'm building plasma-desktop 5.9.3 on Linux and am seeing compiler failures because of -Werror=return-type, in boost functions. See below for an example. I'm using boost 1.59.0, gcc 6.3 and Qt 5.8.0 (all installed in /opt/local). I've included one of the warnings I also see, in case

Re: [KDE4] what component does the screenlocking?

Luca Beltrame wrote: > Support for screensavers has been removed even in 4.x times when the new lock > screen architecture was introduced. ? It's still there in 4.14 and not as the result of patching it back in (and I'm running the most recent kde-workspace code). > That said, the

D4929: DrKonqi : lldb support (and cross-platform adaptation)

rjvbb added a comment. Not currently, but DrKonqi ought *really* be elsewhere. There's nothing Plasma-specific to it. On the contrary, it should be easily available on every platform for which KDE applications are available so that every KDE user can contribute to KDE improvement by

D4929: DrKonqi : lldb support (and cross-platform adaptation)

rjvbb created this revision. rjvbb added a project: Plasma: Workspaces. Restricted Application edited projects, added Plasma; removed Plasma: Workspaces. REVISION SUMMARY As touched upon previously, DrKonqi is a utility that can be very useful outside of Plasma desktop environments too, and

Re: [KDE4] what component does the screenlocking?

To come back to the original topic: I have been tinkering with other display managers, and think now that the claim that kscreenlocker_greet uses the DM greeter for unlocking (on Plasma4) is unsubstantiated. When I switch to Ubuntu's LightDM I still get the same unlock dialog. I've built and

Re: [KDE4] what component does the screenlocking?

On Thursday March 2 2017 10:31:54 Duncan wrote: >others will still have those one or two X-based apps they want/need to >continue to run on a modern Linux/Wayland-based desktop a decade, even >two, from now. If you have picked up the clamour not so long ago when a rumour made the rounds that

Re: [KDE4] what component does the screenlocking?

Luca Beltrame wrote: > With the exception of "loginctl unlock-sessions" as root or "loginctl unlock- > session" as the same user, none. It's the whole point of the screenlocker > architecture (that is, you can't just kill it and unlock the screen). And is that loginctl command supposed to work

Re: [KDE4] what component does the screenlocking?

On Wednesday March 1 2017 06:32:45 Duncan wrote: >Without kdm or similar installed, kde4/plasma4 didn't have a greeter >available and I had to be careful not to lock the screen, etc, because >there was no way to unlock it as I had no greeter. So you are saying that despite what the resident

Re: [KDE4] what component does the screenlocking?

Please allow me a few follow-up questions Given that apparently the KDE4 screensaving/locking mechanism is too old to work correctly with whatever component is now too new: 1) can I prevent locking entirely, including at suspend/wake? I thought I'd seen an option that controls this in

Re: [KDE4] what component does the screenlocking?

On Tuesday February 28 2017 18:35:59 Martin Gräßlin wrote: > Erm you count translations as commits? If not then trust the maintainer Please, I can read: > commit 46f1055ffdcd2e068296576a7824012f42e9b9a8 > Author: Wolfgang Bauer > Date: Tue Aug 4 19:51:05 2015 +0200 > >

Re: [KDE4] what component does the screenlocking?

On Tuesday February 28 2017 16:48:25 Martin Gräßlin wrote: >As you should be aware of: kde4 has been unmaintained for years and is >EOL. Yeah, I know that KDE no longer maintains most of KDE4. Fortunately some distributions have a slightly different take on concepts like continuity and

[KDE4] what component does the screenlocking?

Hi, Sorry for cross-posting, I'm hoping it'll increase my chances of reaching someone who has an answer to the following. After upgrading my hardware to an N3150-based notebook, my KUbuntu 14.04 install has developed an annoying quirk. From time to time, the screensaver fails to start (= I

Re: KDM5?

Security issues in KDM, seriously? Maybe if it's configured to serve incoming remote connections, but for local security I don't think it can be a big concern given how easily one can get at a virtual console anyway. Unless KDM is also responsible for locking a session once you're logged in?

KDM5?

Hello, I get the impression I'm not the only one who hates the looks of SDDM (to put it bluntly). How difficult/impossible would it be to port KDM, presuming that hasn't been done already? Evidently I wouldn't expect Wayland support. R.

Re: Review Request 128109: Provide demo/preview for checkable menu items too [WIP]

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128109/ --- (Updated Feb. 8, 2017, 3:53 p.m.) Status -- This change has been

Re: Phabricator: All repositories registered - upcoming workflow changes

On Thursday February 2 2017 21:50:38 Nicolás Alvarez wrote: >You missed the point. This "bit rot" is not about disk damage but >about software incompatibility. ZFS doesn't help with that... You mean diffs that no longer apply cleanly? In that case you missed our point. Being able to consult

Re: Phabricator: All repositories registered - upcoming workflow changes

Could this be of any help? https://www.cloudpipes.com/integrations/phabricator/reviewboard A paying service, but if the integration allows migration of existing ReviewBoard stuff into Phabricator a well-timed 2-month trial (or multiple thereof ;)) might suffice? There's also this:

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 01 2017 23:03:53 Albert Astals Cid wrote: > You'd be surprised (yes i have a script that actually applies the MRs and > lots > of them even very old apply). Old also doesn't mean unmaintained. I have a number of RRs that I keep rebasing because I'm still waiting for a

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 1 2017 22:16:50 Ben Cooksley wrote: >We'd still have to keep the software running, and up to date (to avoid >it becoming a security risk). Running yes, but if log-in is disabled at the core and not linked to the central LDAP service or whatever it is you use, what

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 1 2017 20:59:46 Ben Cooksley wrote: Hi > >While I have yet to test it, Reviewboard does use quite a bit of AJAX >and other dynamic resources - so I won't be surprised to find out that >the usual mechanisms for creating static copies of sites don't produce >a workable

Re: Phabricator: All repositories registered - upcoming workflow changes

On Tuesday January 31 2017 20:10:42 Luigi Toscano wrote: >> It will be a complete shutdown of Reviewboard - we'll be archiving it >> in the event for some reason it becomes necessary to access the data >> it stores. > >Isn't it a way to change the site in static website and keep it alive?

Re: Phabricator: All repositories registered - upcoming workflow changes

On Sunday January 29 2017 08:32:21 Ben Cooksley wrote: Hi, >From this point forward, communities should be moving away from >Reviewboard to Phabricator for conducting code review. Sysadmin will >be announcing a timeline for the shutdown of Reviewboard in the near >future. I hope that shutdown

Re: KDE 4 vs 5, regional settings and dolphin

Christoph Feck wrote: > http://www.ivoras.net/blog/tree/2010-12-20.the-wonderful-en_dk-locale.html Heh, more or less what I thought it was. The weird thing is that both Ireland and Malta are English-speaking EU countries that use the € and metric system. Anyway ... :)

Re: KaOS locale KCM (KDE 4 vs 5, regional settings and dolphin)

René J. V. Bertin wrote: > I just played with a full Plasma5 desktop (KaOS) and noticed that it has a > Regional Settings/Locale KCM I don't have on my own install, for as yet > unclear reasons. It seems it gives an additional step in the right direction Clear now: https://github.com/K

Re: KDE 4 vs 5, regional settings and dolphin

Christoph Feck wrote: > See bug 340982. > > KF5 applications do not use the customizable KLocale class, but use what > Qt offers (QLocale), which we hoped would soon get support for > customizations, but progress is slow, so no code has surfaced. I just played with a full Plasma5 desktop

Review Request 129615: (WIP) QtCurve-specific XCB client messages

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129615/ --- Review request for Plasma and Yichao Yu. Repository: qtcurve

Re: KDE 4 vs 5, regional settings and dolphin

Christoph Feck wrote: > On 04.12.2016 11:17, René J.V. Bertin wrote: >> Under KDE4, the translations KCM had detailed settings for just about every >> aspect > > See bug 340982. Thanks, I suppose I could have found that ticket myself ... > customizations, but progress is slow, so no code has

KDE 4 vs 5, regional settings and dolphin

Hi, Not sure whether this is the best place to ask but here goes: I'm running a selection of KF5 applications installed in a parallel prefix (/opt/local) on a Kubuntu 14.04 system. Mostly this works fine; "Konsole5" is just a bit better than Konsole4, KDevelop5 quite a bit more by now than

Re: DrKonqi and BKO

Martin Klapetek wrote: >> Bug trackers are not trace trackers. Spending time on solving the >> actual problem is the best thing https://retrace.fedoraproject.org/ >> https://errors.ubuntu.com/ > > > They're not, yet we're using it as one. So might as well improve > the experience at least a

Re: DrKonqi and BKO

Martin Klapetek wrote: > For improving readability, there is bugzilla-traceparser plugin, that can > dynamically > hide long backtraces with a bit of JS magic to expand them and much > more > like finding duplicates and also auto-dupe. I still think this would help > tremendously to >

Re: DrKonqi and BKO

David Edmundson wrote: > As attachments is awful. You cannot search if it's in an attachment. > Searching is ridiculously important. True. FWIW, the bug I tried to report this morning (which led to this mail) came up with 0 possibly related reports, while it turned out I'd already reported

Re: DrKonqi and BKO

FYI: https://bugs.kde.org/show_bug.cgi?id=371934 R.

DrKonqi and BKO

Hi, Sorry if this has already been answered somewhere where I've missed it: DrKonqi has lost much of its interest (in v5.8.2) due to recent changes in BKO. Most of the crashes I've been trying to report via the tool have led to rejection because of an overzealous spam filter, and now because

Re: macro_bool_to_01 macro in plasma-workspace/ConfigureChecks.cmake

On Friday October 28 2016 20:24:10 Martin Gräßlin wrote: >Am 2016-10-28 19:25, schrieb René J.V. Bertin: >Sorry, I think there was a misunderstanding. I checked all the variables >set by macro_bool_to_01 in ConfigureChecks.cmake. In other files it's >not used. Indeed, and no, that wasn't what

Re: macro_bool_to_01 macro in plasma-workspace/ConfigureChecks.cmake

On Friday October 28 2016 14:00:54 Martin Graesslin wrote: Hi, >>I wouldn't exclude the possibility that this is old and dead/non-functional >code. I just did a git grep for every of the CMake variables se through the >macro_bool_to_01 and only found: >dataengines/mouse/CMakeLists.txt:if

macro_bool_to_01 macro in plasma-workspace/ConfigureChecks.cmake

Hi, Where exactly is plasma-workspace's build system supposed to find the macro_bool_to_01 macro? Apparently it's been obsolete for quite some time and it doesn't seem to be provided by any of the listed dependencies (= I get a not-found error). Thanks, René

unexpected "show desktop" shortcut (KDE4)

Hi, I hit an accidental and as yet unidentified shortcut and am now seeing a "Show Desktop" entry in the task switcher. I'm 95% sure I deactivated the "Show Desktop Icon" option in the task switcher settings. Is there a shortcut to activate this option? To give an idea what keys I may have

Re: translucent moving windows

Ivan Čukić wrote: Hi, > It is called Translucency, and works as it did in 4.x days. > > No clue whether it depends on your graphics system though. IIRC, the > list now hides effects that are unsupported by your hardware / > compositing mechanism. Well, indeed. It's there again after my

language selection not respected throughout

Hi, As you may know I've been building KF5 libraries and applications for installation into /opt/local, on both Linux and OS X. I had already noticed that my en_GB language setting wasn't respected systematically and throughout, which at first I put off on missing/incompete/imperfect

translucent moving windows

Hi, I was playing around with KWin5 (X11) instead of my usual KWin4 and realised I couldn't find the desktop effect that makes windows translucent while they're being moved. I find that a great mix between moving only outlines (what I usually prefer) and moving solid windows. If that effect

Re: porting the QtCurve kwin theme

On Saturday July 02 2016 20:13:49 René J.V. Bertin wrote: >That at least sounds like something I could start looking at. I just hope >there isn't too much in the code that will make QtCurve hard if not impossible >to port without sacrificing its individuality. FWIW, the kwin4 plugin doesnt

Re: porting the QtCurve kwin theme

On Saturday July 02 2016 15:55:22 Martin Graesslin wrote: >One cannot have a wrapper/proxy. KDecoration was modelled around QWidget with >KCommonDecoration using QPushButtons for the buttons. KDecoration2 doesn't >depend on QWidgets any more and all it has is a QPainter based API for

Re: porting the QtCurve kwin theme

Hi, Rather than example minimal from-scratch KDecoration2 examples, is/are there examples showing how to write a sort of minimal KDecoration2->legacy wrapper/proxy (and then work from there modernising the code)? I presume that's not unlike how Oxygen was adapted? R.

Re: Fonts rendering in titlebars with KDecoration2

On Monday June 20 2016 04:16:14 Christoph Feck wrote: > >No. Oxygen and Breeze use QPainter, not Qt Quick. Then we're back to my original question: why do their window titles look so off? R. ___ Plasma-devel mailing list Plasma-devel@kde.org

Re: Fonts rendering in titlebars with KDecoration2

On Friday June 17 2016 18:01:42 Christoph Feck wrote: Hi, >Is your decoration Qt Quick/QML based? If yes, see >http://blog.qt.io/blog/2012/08/08/native-looking-text-in-qml-2/ Should one be able to see any effect of DESKTOPCOMPONENTS_USE_NATIVE_TEXT through kdecorationviewer, in the Oxygen

Re: porting the QtCurve kwin theme

On Friday June 17 2016 21:55:15 Christoph Feck wrote: Hi, >Last year I created the "Skeleton" KWin 5 decoration to test KWin 5 >decorations: http://developer.kde.org/~cfeck/skeleton-0.1.tar.xz I built and installed your skeleton in my closet :) but it's not showing up among the window themes,

Re: porting the QtCurve kwin theme

On Friday June 17 2016 21:55:15 Christoph Feck wrote: Thanks, I'll take a look. > Last year I created the "Skeleton" KWin 5 decoration to test KWin 5 > decorations: http://developer.kde.org/~cfeck/skeleton-0.1.tar.xz > > The documentation in the KDecoration2 header files is quite extensive. >

Re: Fonts rendering in titlebars with KDecoration2

On Friday June 17 2016 18:01:42 Christoph Feck wrote: > Is your decoration Qt Quick/QML based? If yes, see > http://blog.qt.io/blog/2012/08/08/native-looking-text-in-qml-2/ Not mine: Breeze and Oxygen. The Aurorae/Plastik decoration appears to be less affected. R.

Fonts rendering in titlebars with KDecoration2

Hi, Trying out kdecoration-viewer confirmed something I already noticed when I ran KWin5 from a parallel prefix, replacing my usual KWin4. The font in the window titlebars is the same, but looks different. I have the Infinality Freetype and FontConfig patches installed, so any form or font

Re: porting the QtCurve kwin theme

On Friday June 17 2016 07:54:48 Martin Graesslin wrote: >Yes, a port to KDecoration2 is required. No, there is no guidebook for that. >The required effort is difficult to estimate as it depends on the actual >implementation. Whether it uses KCommonDecoration or KDecoration. I see that both

porting the QtCurve kwin theme

Hi, It was pointed out to me by an OpenSuse maintainer that the QtCurve Qt5 implementation doesn't contain a (functional) window theme. I'm not exactly the most likely candidate to address this as I don't currently have a system running a Plasma5 desktop, but I do now have KWin5 installed in

Re: Review Request 128109: Provide demo/preview for checkable menu items too [WIP]

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128109/ --- (Updated June 6, 2016, 2:08 p.m.) Review request for Plasma. Changes

Review Request 128109: Provide demo/preview for checkable menu items too [WIP]

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128109/ --- Review request for Plasma. Repository: oxygen Description ---

Re: about those config UIs

On Sunday June 05 2016 20:47:31 Thomas Pfeiffer wrote: Hi > > I guess that it'd be up to individual styles to provide a menu preview or > > not? > > I've gotten a preview of a menubar with a couple of menu items added to the > > stylepreview UI resource, but I haven't yet found a way to add a

Re: Review Request 128097: optional mode to draw checked menu items with only a check mark

> On June 5, 2016, 2:11 p.m., Thomas Pfeiffer wrote: > > First of all, as for any visual changes: Please provide before/after > > screenshots so that designers can do visual reviews. > > > > Second: I am strictly against making this an option. Either it's an > > improvement, then it should

Re: Review Request 128097: optional mode to draw checked menu items with only a check mark

> On June 4, 2016, 10:02 p.m., Yichao Yu wrote: > > LGTM, this should be added to the configure UI. The tab for popup menu > > should work. The .ui file needs to be updated to include the checkbox for > > this and a corresponding rule should be added to the .cpp file (There > > should already

Re: Review Request 128097: optional mode to draw checked menu items with only a check mark

> On June 4, 2016, 5:52 p.m., Yichao Yu wrote: > > qt4/style/qtcurve.cpp, line 6171 > > > > > > Hm? Shouldn't this use the option? Of course it should, thanks, missed that one. - René J.V.

Re: Review Request 128097: optional mode to draw checked menu items with only a check mark

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128097/ --- (Updated June 4, 2016, 9:53 p.m.) Review request for KDE Software on Mac

Review Request 128097: optional mode to draw checked menu items with only a check mark

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128097/ --- Review request for KDE Software on Mac OS X, Plasma and Yichao Yu.

page-title frame drawing

Hi, Splitting this off from the "plasma-desktop on other environments" thread. What can you tell me about the "draw frame around page titles" option, more precisely when this frame is drawn? I'm seeing this kind of frame when I use the native OS X widget style, but as far as I know it doesn't

Re: plasma-desktop on other environments (bis)

Here's another question, side-ways related: Qt 5.6.1+ are likely to remove DBus support from the Mac platformsupport module. That's fine, but the change breaks my build of the qgenericunixtheme unless I deactivate DBus support in there too. That's mostly my problem of course, but can anyone

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: > It's gone completely, everything happens in KNotification > at runtime. Great. That's 1 daemon less, and also 1 less source of focus loss (and 1 less patch I can now really forget about) :) I'd completely forgotten about the thing, until earlier today when apparently

<    1   2   3   >