Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 --- When built as SHARED as in the current code,

Re: Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

On Aug. 25, 2015, 3:41 p.m., David Edmundson wrote: I've got both Gentoo and Arch saying this causes a major problem [1]: libdraganddropplugin.so changes to draganddropplugin.so in /usr/lib/qt/qml/org/kde/draganddrop and then they don't get loaded. any ideas? Otherwise I'll

systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

Hello, This has been pending for a while, ever since we (= KDE/Mac) learned that the kde4-workspace package was split up and integrated into KF5 Plasma, but it may actually be relevant beyond "Plasma vs. the rest of the world" questions. I hope this can be discussed with a sufficient amount of

Re: systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

Aleix Pol wrote: >> kde-cli-tools and systemsettings5 are required to configure >> 1 wallet settings (regardless of whether KWallet uses native KDE wallets or >> an OS X keychain backend) > Makes sense, probably should be moved to KWallet? Probably. >> 2 cookies and other html/browser related

Re: systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

David Edmundson wrote: >> address space of an application other than kcmshell or systemsettings. >> >> They can be run in application space. > There's a class to load them easily as widgets. See KCMUtils framework > (KSettings::Dialog in particular) I take it that's how the Notifications and

Re: systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

Aleix Pol wrote: > It's a matter of what we expose I'd say, though, as you only want to > change application-specific settings within the application. Yes, I guess you're right about that. Some applications provide a palette selector (but no way to edit palettes), most if not all a language

Re: systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

Sebastian Kügler wrote: > Did you check of X11 dependencies? At least some of the font settings depend > on X11. Thanks, will do. Makes sense: hinting and AA settings are moot outside of X11. However: my Linux build should pick up all required X11 deps so something else must be going on too. >

Re: [KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

Out of curiosity: to what extent are things like plasmoids/plasma widgets and other "cool goodies" really tied to the presence of a full-blown Plasma desktop? If they're qml they should be able to run anywhere in principle. I can understand they need some kind of host but with qml it should be

Re: [KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

On Thursday December 24 2015 13:11:44 Ian Wadham wrote: Goodevening Ian, and whatever appropriate to ye'all :) >No, this is a good initiative. René, and a necessary one. Such complex >considerations cannot be dealt with easily in a short exchange of emails, IMHO. Thanks, Ian! I agree... :) >>

Re: [KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

On Thursday December 24 2015 11:43:57 mk-li...@mailbox.org wrote: > Hi Ian and all others interested in DrK, playing postillion d'amour again ... > > Marko was also protesting about the move, I remember. > > Yes, indeed, I did protest back then, but it stayed unheard. > > > So, I'll do it

Re: [KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

On Thursday December 24 2015 12:15:59 John Layt wrote: > Akademy a few years back. The general consensus was that forcing > Mac/Windows/Gnome users to install Systemsettings just to configure their > standalone app was A Bad Thing (TM) and shouldn't be done. It required > specialised knowledge of

Re: Scope of framework integration plugin?

Adding KDE-mac because we're the first concerned (thanks for omitting us ... again). First off: what about splitting off the KdePlatformPlugin from frameworkintegration? I can see the point that it was conceived to allow pure Qt5 applications to integrate with the look KF5 applications have

Re: Scope of framework integration plugin?

On Monday November 30 2015 16:07:50 Jan Kundrát wrote: Hi, >Yes, I think that such a goal is fully in line with Qt's attempt at being >reasonably cross-platform. The keyword here is reasonable - and that's to be interpreted from their point of view. The last time we (including David Faure)

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

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

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

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.

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

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > Renè isn't doing the individual standalone OS X packages, which should have > the tight host integration. Other people are doing that. MacPorts makes it much more straightforward to provide cross-platform homogeneity because all required resources are installed in

Re: plasma-desktop on other environments (bis)

Quick related question: has knotify4 been replaced by a KF5 equivalent, or rather made obsolete? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: > That's not what I'm telling anyone at all. Great. It's not always clear how literally to take statements (or not, apparently :)) I think I don't need convincing for the rest but always agreed with that. > But if you're going to split events out from

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: >> Where and how exactly are the default sounds configured? > .notifyrc files shipped with the application / library. That would mean changing lots of files then... I'm not sure how to do that in an efficient way if there isn't something like a category mechanism in

Re: plasma-desktop on other environments (bis)

Martin Klapetek wrote: So the apparently generic categories that concern application error, crash etc. do not control the way those notifications are delivered if you aren't running a Plasma session? Mind you, we're not only talking about the sounds here. > That's not entirely correct -

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)

I'm continuing to take stock little by little of what KCMs would make sense outside of a Plasma session (or should have a "native" alternative). One which comes to mind is the notifications KCM. Many of its event sources provide a shortcut to configure application-specific notifications that are

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

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

Re: Review Request 126993: drkonqi : fix build errors and build nongui

> On Feb. 5, 2016, 3:57 p.m., Martin Gräßlin wrote: > > drkonqi/drkonqi.cpp, lines 183-188 > > > > > > yes this is possible and there is even a Krazy check for this. The > > QWeakPointer is the proper fix to

Re: Review Request 126993: drkonqi : fix build errors and build nongui

> On Feb. 5, 2016, 3:57 p.m., Martin Gräßlin wrote: > > drkonqi/drkonqi.cpp, lines 183-188 > > > > > > yes this is possible and there is even a Krazy check for this. The > > QWeakPointer is the proper fix to

Re: Review Request 126993: drkonqi : fix build errors and build nongui

> On Feb. 5, 2016, 3:57 p.m., Martin Gräßlin wrote: > > drkonqi/drkonqi.cpp, lines 183-188 > > > > > > yes this is possible and there is even a Krazy check for this. The > > QWeakPointer is the proper fix to

Re: Review Request 126993: drkonqi : fix build errors and build nongui

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126993/ --- (Updated Feb. 5, 2016, 6:18 p.m.) Review request for KDE Software on Mac

Re: Review Request 126993: drkonqi : fix build errors and build nongui

> On Feb. 5, 2016, 7:58 p.m., Aleix Pol Gonzalez wrote: > > It's only on your system because for some reason you are probably not > > including KDELibs4Support. > > > > It should be something like this, but it isn't: > > https://paste.kde.org/pv12ioe89 I indeed removed the reference to

Re: Review Request 126994: Drop usage of Qt4Support

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

Re: Review Request 126993: drkonqi : fix build errors and build nongui

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126993/ --- (Updated Feb. 5, 2016, 9:35 p.m.) Status -- This change has been

Re: Review Request 126994: Drop usage of Qt4Support

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126994/#review92106 --- I suppose that getting rid of KDELibs4Support isn't a bad

Re: QWeakPointer error in DrKonqi

Aleix Pol wrote: > Maybe you can provide the fixes in the shape of a review request? I'm > sure that if somebody found this they would have fixed it before. > > I really have no idea why these issues didn't pop up on my set up but > did on yours anyway. That's weird indeed. I just tried to

Re: Review Request 126993: drkonqi : fix build errors and build nongui

> On Feb. 5, 2016, 2:29 p.m., Bhushan Shah wrote: > > drkonqi/CMakeLists.txt, line 86 > > > > > > Erm wait, drkonqi is gui program, no? Yes, but: - on Linux, that statement does nothing AFAIK (drkonqi continues

Re: Review Request 126993: drkonqi : fix build errors and build nongui

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126993/ --- (Updated Feb. 5, 2016, 3:13 p.m.) Review request for KDE Software on Mac

Re: Review Request 126993: drkonqi : fix build errors and build nongui

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126993/#review92084 --- Not sure if this is related, but when drkonqi is launched

QWeakPointer error in DrKonqi

Hi, Is DrKonqi under active maintenance? I'm in the process of getting it (and a few select other things from plasma-workspace) to build on OS X and I'm seeing errors that should have nothing to do with "Plasma isn't supposed to work here" : 1) an error initialising a QWeakPointer from a

Review Request 126993: drkonqi : fix build errors and build nongui

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

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/#review95726 --- I've tweaked defaults provided by the theme plugin a bit

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126198/ --- (Updated May 23, 2016, 10:23 p.m.) Review request for KDE Software on

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. > > René J.V. Bertin wrote: > I quite like the way things are, but yes, I've played with that idea. > >

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: >> > It then grew to include some GTK settings and backporting stuff to KDE4. >> >> What backporting stuff? >> > > As we have KDE apps using kdelibs4 this also saves some settings to > ~/.kde4/kdeglobals as well as the new place. Ah, yes, indeed. I see that now in the

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > KDE Resource Database. ... > It then grew to include some GTK settings and backporting stuff to KDE4. What backporting stuff? I have a bit of a dilemma here, which results from the fact that MacPorts also provides a whole range of GTk applications, a number of which I

Re: plasma-desktop on other environments (bis)

David Edmundson wrote: > It's invoked by the colours and style KCM - so though I do think there is a > demand for configuring apps on OS X, taking the KCM directly isn't a good > idea because of that. Or the invocation is made optional, skipped on platforms without X11... The thing with not

Re: plasma-desktop on other environments (bis)

René J. V. Bertin wrote: > What Plasma platform theme, the one in plasma-integration? That won't be used > on OS X. It's been a while, but I'm pretty confident that I changed those Indeed: QList KdeMacTheme::keyBindings(QKeySequence::StandardKey key) const { // return a native keyb

Re: plasma-desktop on other environments (bis)

Kai Uwe Broulik wrote: >> No, KDE translations aren't linked in any way to the way the system handles >> these > > That doesn't change the fact that when my system is French I want the > application to be French, too, which is what this kcm is about, choosing a > language. Yes, but without the

Re: plasma-desktop on other environments (bis)

On Monday May 23 2016 07:59:14 Martin Graesslin wrote: >I'm against any patches to plasma-desktop to make it compile on other >platforms. There should not be any need to have anything from plasma-desktop >on non Plasma platforms. If there is indeed a KCM which makes sense to have on >other

Re: plasma-desktop on other environments (bis)

Kai Uwe Broulik wrote: FWIW, a good part of the KCMs you seem to think I include on OS X are in fact excluded because X11 isn't provided. > The following are redundant with the system-provided ones: > * componentchooser As long as KDE code uses its own way (or a Qt-provided method, I don't

plasma-desktop on other environments (bis)

Hi, We've talked about doing something about the various components in plasma-desktop that would make sense outside of full-blown Plasma sessions. I've been keeping that in mind, and the other day my Linux install (which I maintain in a parallel prefix using the same packaging scripts as I use

khelpcentre 5.6.4 tarball contains 5.6.3

Hi, I can hardly believe noone has already noticed this, but: the 5.6.4 release tarball for the help centre contains a directory labelled 5.6.3 . I hope it's just the directory name (and the version number in the CMake file) that have not been updated? If not, that is, if the help centre

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:37 p.m., Martin Gräßlin wrote: > > given that Plasma integration got removed I suggest to create a dedicated > > osx-integration repository for it as well. I quite like the way things are, but yes, I've played with that idea. I guess I can simply fork

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

> On May 17, 2016, 4:36 p.m., Martin Gräßlin wrote: > > > I saw that one of the justifications for the move was a dependency on > > > Plasma library/ies, but I don't see any such dependencies in the latest > > > version before the move (commit 07548ac1fe7a7fb31a941473911e982fb623c07d). > > >

Re: Review Request 126198: [OS X] adaptations for the KdePlatformTheme

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

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

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

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

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

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

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

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

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: DrKonqi and BKO

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

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

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 >

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é

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

  1   2   3   >