Re: Question for fellow retro-computers : building kdelibs4 without nepomuk?
On Friday May 24 2024 04:37:39 Duncan wrote: >As I recall, for most of kde4, even with semantic-desktop disabled (to the >degree possible), while the backends (raptor/redland/etc) weren't required >in that case, the frontend libs were still mandatory build-time and run- >time required. Do you happen to have a pointer to the most recent version of the patch you mentioned? AFAICT, the nepomuk library isn't built at all when the raptor/redland soprano backends aren't installed. I had a quick look at what components actually need it (rather than link to it out of habit); possibly kactivities. Which is one of those IDE components that are probably devoid of interest except in a full DE. Soprano itself builds just fine so there's no problem with having the library present. The good news is that in the meantime we've identified that the problem is actually a regression in raptor 2.0.16 that's being addressed as we speak, and that simply downgrading to 2.0.15 allows us to continue the revival adventure. >Tho I suppose the CI would be current-targeted and if you're on Intel-Mac >hardware, Apple haven't yet ditched all support for the Intel architecture (though surely will sooner rather than later given their track record in dropping support for older models). The problem is that this entire effort focusses on models even older than my own 2011 Mac. Many of those don't even run a recent Qt5 version (while Qt 5.15 still supports Win7 from what I hear, which is also older than my Mac and definitely older than the latest OS X it can run). One of the big hurdles with KF5 was that Qt5 introduced their version of KStandardPaths, and gave it a "proper Mac-native implementation". KDE migrated to that class, but never bothered to update their build system. So while the code is perfectly capable to find its runtime resources where Qt says they should be, the build system installs them to the places where the XDG standard says they should go. Except for a handful of applications were, like Kate. KDE have also been pretty strict about "Macs don't have dbus" (they can, it's even an officially supported target) or "Macs/PCs shouldn't have KCMs + systemsettings, widget themes or a platform plugin". One of the more OCD-pedantic Plasma developers even once said that he felt like breaking all possibilities to build "his" code on the "wrong" platform, "just because he could". In short: I spent countless hours patching things including QStandardPaths and other Qt bits just to get a proper UI experience and full-featured KDE applications. Only to find myself blocked at Qt 5.9 which already doesn't officially support the OS version I'm running. In short: starting this all over for [QK]*6 ... no thanks. I never even bothered with KDEPim5, actually. Partly because even test-driving it means you can't go back to KDEPim4, partly because another OCD-pedantic dev decided it'd use QtWebEngine throughout, which is complete overkill for just displaying HTML email. R.
Question for fellow retro-computers : building kdelibs4 without nepomuk?
Hi, A number of people are looking into getting the MacPorts KDE4 ports to build again, using the current versions of the various dependencies. KF5 never made it into the official ports tree for various reasons (and it's definitely not going to happen now) but the KDE4 ports used to work pretty well, so the effort isn't devoid of interest. The current blocker is with Soprano: onto2vocabularyclass segfaults in Raptor v2.0.16 (but not 2.0.15). Of course we could figure out what changed between those Raptor versions and if the problem is a regression or an "official" API change in that library (any pointers would be appreciated). But from what I can tell Soprano is only used as a basis for Nepomuk, which itself has been superseded by Baloo since 4.13 . This is all old history by now, but does anyone remember if anything breaks when the required dependencies for building Nepomuk aren't available (Soprano's Raptor and Redland backends)? The KDElibs build system (CMake files) is set up properly for this case but has 1 comment in it suggesting that libnepomuk is not actually optional even though apparently nothing uses it anymore - except the KDElibs-internal file metadata thingy. But there's an external `kfilemetadata` so I'm not clear on which of the two does what. Thanks, R.
Re: plasma 6 and xrdp
Remind me, do KDE's MLs have ignore/black lists?
Re: How do I get lost windows back?
On Sunday March 03 2024 12:52:33 hw wrote: > Modernity is totally besides the >point here. Sadly no, in my book. But I'm not going to get into a shouting match about this.
Re: plasma 6 and xrdp
On Sunday March 03 2024 05:22:15 Draciron Smith wrote: >Thing is you SHOULD be able to do that. That is kind of the idea that >drives OSS in general. And AFAIK you can. XOrg has a single codebase for every officially supported platform; Xquartz for instance is built from the upstream sources with just a number of patches that are probably intended to be upstreamed. I'm not really familiar enough with all the hairy details of selecting drivers on Linux or the extent to which you could get decent performance without hardware-specific ones, but I do notice they're part of the XOrg sources. >Some of which should be but are not easily ported to Linux and there are >Linux apps I'd love to port to OSX. Apple have tied their (formerly) main programming language way too much to the OS IMHO (Swift exists for Linux but I have no idea if it's more usable there than ObjC is). That hinders porting to other platforms, but they're also the only Unix (I know of) where it's often impossible to even compile recent software on older OS versions (which is all that older hardware will still run, extra maddening since that hardware is so long-lived). >The various splits in the *Nix world are forgetting one of the core >principles. That is the ability to leverage great ideas on other *Nix spits >into your particular flavor of *Nix. I am in fact not certain that was ever really a thing beyond the software you wrote yourself! >The system calls should be fairly standard even if what goes on when >invoked might be substantially different. To the driver calling them they Well, they are, but for one thing there's the big cleavage between BSD and SysV, and Apple have not made things easier by adapting a Mach kernel on their Unix. But if we ignore Darwin it's quite obvious that Linux is the driving force in the Unix universe, and thus also the source of many incompatibilities which often promptly get used because so much software development is being done on Linux... >It's not like performance is even a consideration any more. The modern KDE >and Gnome are as bad or worse than Microsoft windows in terms of useless >bloat. Gnome definitely, KDE5 is still relatively lean in my more or less up-to-date Devuan test install. But I'm leaning very much to using a DE like XFCE or Cinnamon when I finally move on from my current system that's still based in Kubuntu 14.04 . Though part of the reason for that would be to continue to be able to build the KDE5 libs and applications I want with my own patches as I've been doing for the past years. >Text wrangler on the Mac platform would be awesome to run on Linux. Did you try it with Darwine? >from what was run on the common Linux distros. If you upgraded Python on >OSX at the time, it'd break OSX. Backporting the source to a previous It probably still would, but there's a good chance the same thing would happen on Linux distros (at least those that used or still use Python 2.7 for their crucial scripts). Python is designed around the idea of being able to have every single version installed and pick the one you want or need for a particular task (as long as you don't mind installing all add-ons as many times). >All would benefit. OSX would gain a whole lot of free software, Linux & BSD >access to all those drivers written for the Mac, Realistically, not really. Those drivers must often target aspects of the OS that simply aren't Unix despite the fact that the OS is (still?) certified as a Unix variant. Many of the standard Unix APIs on Darwin are in fact wrappers around Mac-specific (usually meaning Mach) APIs, so software that's more concerned about efficiency has more reason to target those APIs directly. That includes development efficiency of your main product is actually the MSWin version (and/or if you intend to provide your products via the platform's official store). It's true that it's sad; back in 2004/5 when I got re-acquainted with the first Macs under what was still called Mac OS X I quickly abandoned the other Unix versions I'd been using (Irix and a bit of Linux) because I thought I'd finally found the perfect "Unix for the desktop". It only took a bit more than 6 years to realise that Apple had other plans with their platform and was more interested in selling expensive serious toys to Starbucks yuppies. R.
Re: How do I get lost windows back?
On Saturday March 02 2024 17:11:48 hw wrote: >This is bad interface design. I guess whoever designed it knew what >they wanted and it escaped them that someone who doesn't know what >they were trying to accomplish is only being confused by this. Oh, you mean *modern* interface design? I wish that were a joke btw...
Re: plasma 6 and xrdp
On Friday March 01 2024 17:20:38 hw wrote: >Yeah, use rpd instead. Unfortunately, you can't seem to change the >resolution when logging into a Gnome or a Wayland or X11 session from >remote like you can with Windows. IIRC krdc has a connection dialog that allows you to chose a resolution. It's probably what I overlooked that one time I almost messed up my remote session. >Oh I mean only KDE and whatever else uses QT. With Qt it's a choice (assuming Qt6 still uses the same QPA architecture; I've stayed away from it until now). Gnome may have moved on to GTk4, but I have no idea if every application that isn't tied to that DE will have moved on from GTk2. And then there are DEs that last I checked were still using good old GTk2 with its extended theming support etc. As a widget library it really works just fine, after all. >That other platforms may keep Xorg alive doesn't mean that it would >still work with Linux. Why wouldn't it, as long as Linux doesn't do anything to prevent it? Linux is not "the distros", after all. This is really no different than puritan distributions refusing to include any non-free software, and then installing applications like Google Chrome on them just because the developers give you a helping hand. >Will the drivers >continue to support Xorg on Linux and/or on other platforms when >Wayland has replaced it? Linux is currently also being used in environments with serious needs for distributed computing, which probably also means being able to do remote advanced (3D) graphics. Think the automobile industry but also research environments. Lots of people providing the momentum to Xquartz alive work in the latter, for instance. I would guess that XOrg and its drivers will remain on sufficient life support to continue working as long as there is demand from end users. In the end that's the big advantage of FOSS: everyone can contribute and decide to keep it alive. Just look at the Trinity DE. >What about adding new features to Xorg? Following the above, not impossible, but best not hold your breath. All that is assuming that Xwayland isn't already on par with XOrg, and won't ever be. If it is, the entire problem is moot already because X11 applications will just see a different server. > X11 forwarding is the worst option. It really is not, at least the version not using SSH isn't. It's an old protocol but really quite clever. It's not X11's fault that Qt5+ (and/or KDE5+ in particular) wasn't designed with optimal performance over remote X11 connections in mind. >Krdc isn't too great, and how do you allow someone to join your KDE >session from remote? Krdc is a remote desktop client (R D C). You need to run some server to enable remote connectivity to your desktop session. You could do that by hand (like I do), but also write a service definition that can be launched at login through the startup manager in KDE's systemsettings. That's probably what Gnome did, and that's also how Apple's remote desktop configuration works.
Re: plasma 6 and xrdp
On Friday March 01 2024 12:16:19 hw wrote: >With xrdp, you can connect with a RDP client just fine if so >configured Connect with an RDP client to what? An MSWin Pro machine? Last time I tried to use RDP to connect to a running X11 session I got a VNC equivalent that didn't look any better than what I get with TightVNC's x0vncserver, plus it actually reconfigured the host session resolution, so that was that :D > Does that also mean that Fedora will compile everything in such a way > that X11 support is entirely omitted? Is that even possible? AFAIK not for anything that requires GTK2, or that uses a Tcl/Tk UI. Omitting X11 support entirely also means a distro-level decision that remote connections can only be done over RDP or VNC. That sounds like it'd require a lot more set-up effort than simply enabling SSH and using X11 forwarding. > In any case, it looks as if sooner or later there will be no more X11 > but only Wayland. And I wonder what the replacement for xrdp will be. I think you'd have to look at Freedesktop's intentions with XOrg, which may be a little less fatalistic than what distros plan to do with it. For one, Wayland is very Linux-centric, so there has to be incentives from other platforms using X11 to keep the server alive. Which may of course mean just that, fixing bugs and security issues, but more than that isn't really needed, is it? As to xrdp: it relies on a protocol that is not X11-specific itself. KDE for instance has krdc, which uses FreeRDP behind the scenes (the binary, from what I understand) to provide RDP connections in a Qt shell. I've used that application on my Mac, which means using neither X11 nor Wayland to display a remote desktop.
Re: plasma 6 and xrdp
>Again KDE has no plans to stop supporting X11. Saw that after replying, our mails must have crossed.
Re: plasma 6 and xrdp
On Thursday February 29 2024 14:04:45 Paul Brown wrote: >Plasma developers are currently working on solutions that will allow to have >RDP functionality working on Wayland. I guess that theoretically this should allow optimal use of the RDP protocol (local rendering IIRC, possibly per-application) instead of the more or less glorified VNC-like implementation xrdp uses currently?
Re: plasma 6 and xrdp
On Thursday February 29 2024 13:33:04 hw wrote: >IIUC xrdp requires Xorg, and Xorg will not be supported in plasma 6. XOrg maybe not (but about the only X11-specific thing in KF5 that I am aware of is kwin_x11, most if not all of the rest comes "for free" via Qt's xcb QPA). It'd be (IMHO) stupidly premature not to provide an X11 server under Wayland if that's even something that KDE has a say over ... Xwayland being provided by ... Xorg). R
Re: How do I get lost windows back?
On Thursday February 22 2024 17:56:17 Richard Troy wrote:
Hi,
>I got it that to unmap I'd need to write a C program using Xlib and call
>XUnmapSubwindows(Display *display, Window w); Not having written an
>Xlib-using program before - or at least not in maybe 30 years! - and not
>feeling a need to get deep into it, is / are there a presumption(s) of
>which window / display is/are the target if they're directly associated
>with the code that's running the unmap call? Same goes for calling
>XMapWindow?
Sorry, I don't get your question?
I'm having difficulties recalling in which context I have encountered unmap
actions in existing applications. Most likely in a window manager I used or
tested at some point, but which...
Either way, with X you need to open the correct display first (a priori just
using the value of the DISPLAY env. variable). For the window things can get a
bit tricky because the window manager and/or the xwininfo command can
(apparently) hide the fact that the actual window you're interested in has been
reparented by the window manager. You can see that easily by using xwininfo
without arguments (and click on a window of interest to see what data that
returns) and then look up the returned window id in the output of `xwininfo
-root -tree -all`.
On my system, I'm seeing something like if 0x6800026 is my window of interest:
xwininfo: Window id: 0xf6 (the root window) (has no name)
Root window id: 0xf6 (the root window) (has no name)
Parent window id: 0x0 (none)
209 children:
SNIP
0x2200054 (has no name): () 832x768+0+0 +0+0
1 child:
0x2200055 (has no name): () 832x742+0+26 +0+26
1 child:
0x6800026 "XXX — Konsole": ("konsole" "konsole") 832x742+0+0 +0+26
As you can see my konsole window has a grandparent that's just a bit higher:
this is the window that includes the titlebar. The intermediate (parent) is
probably there to allow for kwin's fancy rendering through the compositor but
that's just a guess.
I am also guessing that you are thinking of writing a utility that works more
or less like xkill, except that it does an unmap? If so, I'd get the source for
xkill, make those changes and then see what the effect is. In principle the
window manager should react appropriately to unmap/iconify/etc actions on the
client window because the client could invoke those actions itself.
That's all I can think of to help at this time.
R.
Re: How do I get lost windows back?
On Thursday February 22 2024 13:20:40 hw wrote: >Is the konsole window always a child window, and why would it be Under X11 you will normally run a window manager which will "reparent" every window that it is supposed to manage. IOW, every visible window is usually a child, yes. I just brought up the remote possibility that you *might* have managed to unmap your terminal window, somehow. In which case it can be tricky to get it back because the basic purpose of that function is to make a window "disappear". It turns out you probably didn't do this so let's not go deeper down this rabbithole. R.
Re: How do I get lost windows back?
On Wednesday February 21 2024 14:31:16 hw wrote: >Unmapped? One of the X11 ways to make a window disappear without destroying it: https://linux.die.net/man/3/xunmapwindow R
Re: How do I get lost windows back?
On Wednesday February 21 2024 07:58:14 Duncan wrote: >But some people will find it annoying, particularly if they drag windows >around a lot, as if they drag it too close to the top of the screen they Definitely, one of my gripes with Win11! Al(most al)l power to my keyboard for maximising, raising/lowering/iconifying windows and moving them across desktops! The latter works great on Mac (grab a titlebar with the cursor and hit the shortcut to go to the desired desktop) but sometimes kwin's menu to just send a window off is more practical. Anyway, I hope the OP didn't somehow get his window unmapped because that might mean it disappeared from the panel too.
Re: Audio issue - was Re: Starting Wayland-KDE on FC39
On Sunday December 10 2023 10:42:33 Richard Troy wrote: >THIS MADE ME HAPPY AND ANGRY! What had happened?! WHERE DID IT GO?! A wild but educated guess: the file was removed as part of the upgrade an all-wayland and a service to you to prevent issues (hypothetical ones, or xwayland might use the file too?). R
Re: Audio issue - was Re: Starting Wayland-KDE on FC39
On Saturday December 09 2023 10:59:53 Duncan wrote: There are a few writers on this list...! :) >BTW, you're not doing audio via HDMI off the video card, right? I'm not >sure that's an exactly common configuration (but then again I'm more I don't know how common that is on Linux either (esp. not when using PulseAudio that forces one of 2 sampling rates on the output) but AFAIK it's quite common as a means to send "bitperfect" audio to an AV amp under MSWin. I've been doing that for the past 15 years at least, using a lowly Acer netbook as my "content server". Anyway, if ever the OP's sound was indeed configured to go through a digital profile like HDMI there's a potential explanation for not having sound after an upgrade that I experienced myself. Probably unlikely because I can't imagine that F38 using ALSA 1.1x and F39 ALSA 1.2x but somewhere between those versions the "resource directory" was reorganised requiring a change to the system-wide and/or your personal configuration file (if you have the latter). See https://unix.stackexchange.com/questions/763254/pulseaudio-digital-profiles-ports-no-longer-appear-in-pavucontrol/763380#763380 I *suppose* it's not impossible that a personal ALSA configuration might break during a more minor ALSA upgrade, so if you do have one it might be a good idea to double-check it, or see if sound returns when you move that config file aside. R.
Re: Starting Wayland-KDE on FC39
On Tuesday November 21 2023 19:32:19 Dave Close wrote: >Radeon graphics while this one uses an Intel 82Q35 (i915 firmware). So >it certainly looks as though the i915 firmware is the problem. I'll be >watching for updates. Now that you're back up and running you can check if FC38 adds any i915 parameters either to the kernel command line or when the module is loaded (if built as a module). And research if there are any known regressions from the kernel used in FC38 and the one in FC39. I don't know how this works under Fedora but with DebUntu you'd have the possibility to remove the kernel package from the update list so that it won't get replaced during a system update/upgrade. That alone would give you an opportunity to see if you're indeed dealing with an i915 driver issue, but there are of course other methods. Like installing the kernel (version) used in FC39 under FC38 and see if that reintroduces your issue. (Assuming Fedora don't apply patches to the i915 code you could get a generic compatible kernel build of the same version.) R.
Re: Starting Wayland-KDE on FC39
Duncan's suggestion that it could be permissions issue is worth investigating; it could definitely be a reason for errors when launching the GUI from a console. But not, IMHO, for issues with X11 started through a DM as the server should in that case run as root (it does on my system at least.
Re: Starting Wayland-KDE on FC39
On Sunday November 19 2023 22:39:29 Dave Close wrote:
>It seems to me that this is unlikely to be a KDE problem, especially
>since KDE starts great under X11. I'm just hoping someone will be
>able to help me understand why this is failing. There are some online
>references to a problem with the /dev/dri/card0 device but they are
>ancient and don't seem relevant.
DRM: https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure
DRI: https://en.wikipedia.org/wiki/Direct_Rendering_Manager
This sounds like the driver for your GPU is either missing, buggy, or
misconfigured. Starting X11 manually will then probably launch a
"compatibility" mode where the goodies like compositing are disabled (SDDM may
disable that possibility, I don't know). Wayland needs those AFAIK, so it's a
bit strange that SDDM does start.
Note that there are 2 drivers: the one in the kernel and one in
/usr/lib/{,x86_64-linux-gnu/}dri that's probably needed only for video playback
(and hw-accelerated encoding).
Is your GPU one that's embedded on an Intel CPU and that requires the i915
kernel module? That one is known to be buggy enough that it's a good idea to
keep a known-to-work kernel version installed. The notebook I'm typing this on
is running the latest 4.14 LTS kernel at the moment, because every newer
version I've tried to date caused the GPU to hang if I didn't disable a number
of features (via i915.foo= kernel options) that would degrade performance
and/or display quality more than I want.
R.
Re: Display settings on Hi/LoDPI devices?
On Monday November 20 2023 06:30:39 Kristian wrote: >On the other side, it seems at least GNOME somehow manages to handle this >automatically so there apparently seems some way to detect the current >configuration and use the "right" settings when booting the system. I honestly don't know how far X11's support for multi-dpi configs goes, and then of course to what extent KDE has been written with the idea that one could have such a set-up (and support for it). The main components that come to mind where this is crucial are the ones always spanning all screens, so KWin and a number of the Plasma shell components. But really every application faces the question when you move a window from one screen to another (or actually let it span multiple screens). How are you going to handle that? (How) does Gnome "somehow manage" to do something sensible in such situations? And if it does: are you certain it isn't using Wayland? I was surprised to find that gdm3 uses Wayland now, after upgrading one of my systems to Devuan Chimaera (I think that's Debian 11) and I have to assume that an actual Gnome desktop would use that too. One way Gnome might do something sensible is to set the internal hires screen to a "normal" *pixel* resolution with an as close as possible integer scale factor. That would probably allow to treat both screens like they were normal-resolution ones, and let the hardware handle the scaling. This shouldn't be different from playing with the DPI setting, besides of course the lack of antialiasing at a screen-pixel level. I'm guessing that Dell came with (or has) MSWin installed, how does that OS handle this situation? R.
Re: Spectacle badness
On Thursday November 02 2023 13:58:07 pete wrote: >Definate bug to me it completely screws things up Just to illustrate how this can be personal: when I saw you're making hundreds (right?) of screenshots a day using a generic utility my 1st thought was also that there was definitely a bug in your workflow design, that there had to be better ways to obtain those images. R.
Re: Spectacle badness
On Thursday November 02 2023 08:42:21 Ianseeks wrote: >I'm on Wayland and Plasma and it does the same as you. There's probably always the possibility to use the screenshotting utility from another DE, or even a standalone one. Or if you're handy with compiling, building the last known working version yourself (if it's provided as a more or less standalone component). Do I understand correctly that the window has started auto-centring each time it (re)appears? That sounds more like a behaviour that someone considered a feature rather than a bug ... R.
Re: Wifi isn't working WPA2-enterprise
On Tuesday October 10 2023 13:40:24 Sebastian Gödecke wrote: >MY key is up2date, our network settings didn't changed and the only thing i >do in the last 3 month is to install updates. This is most likely not KDE-related; I'd ask the question on unix.stackexchange.com where someone will probably drill you to provide the information required. Do you know what wifi card is in the computer? There are RealTek wifi chipsets that simply don't have very reliable Linux drivers, I think I've seen similar failures to connect with them. And at least 1 Intel wifi adapter (mine...) has or has had an issue where enabling the bluetooth radio interfered with proper wifi operation. First step would be to figure out what software has been updated since the last time you connected successfully, to see if anything in that list might be related. Prime suspects would be the kernel and firmware, or the wifi driver if you have one that's not provided through the kernel but *is* provided by your distribution. Lucky for you it's only about 4 months of updates ;) R
Re: After updating to Debian 11, many problem in KDE
On Thursday October 19 2023 19:09:35 Luca Bertoncello wrote: >After some days without any problem, I can just suppose, that the >problem of ksmserver was a bug to restore the saved session... It is quite possible that the new version isn't perfectly backwards-compatible with session-restore files from previous versions because it's hard to test for such things and many devs consider it sufficient to use "asserts" to protect against unforeseen or non-handled situations. End-users will just see that as a crash. I moved one of the accounts I maintain to another DE for a similar reason: the migration from Plasma4 gave me an empty screen 2x or 3x in a row.
Re: Another strange problem after updating to Debian 11
On Tuesday October 17 2023 12:48:45 Luca Bertoncello wrote: >Any suggestion? Change to Devuan ... that's Debian but without the systemd contraption (I'm not claiming that's the culprit, it's just an additional few layers of complexity plus it may be the reason why you can't find relevant logfiles). Devuan Chimaera is Debian 11. And FWIW, I'm more and more certain that my next DE will not be KDE Plasma. I will continue to use my usual KDE applications and maybe even KWin but there are just too many little annoyances that make me feel I'm not in control. And that's worse in a DE that *used* to put the user in control than in one where you know you have only (very) limited control... I might try to build a Plasma4 desktop shell though 8) R
Re: After updating to Debian 11, many problem in KDE
On Tuesday October 17 2023 09:31:09 Luca Bertoncello wrote: \>It appears a little window from startkde with the message "startkde: >Could not start ksmserver. Check your installation." > >Unfortunately I couldn't find any other detailled error. *Something* launches `startkde`. On my legacy KUbuntu system that's `upstart`, and this keeps a logfile that contains all the terminal output of applications launched through the GUI. I don't know what service Debian 11 uses to bootstrap the desktop environment but my bet is that it must leave a logfile somewhere. If not, there is always the possibility to rename the ksmserver binary to ksmserver.bin (or something like that) and put a shell script at its place that launches this renamed binary and redirects all output to file. But have you checked if ksmserver exists on your system and that `ksmserver --help` executes OK? R.
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Sunday September 24 2023 16:09:57 A. F. Cano wrote: >Maybe the old "System Load Viewer" should be removed? Not everyone run the "latest & supposedly-greatest" KDE version, so no. It would be nice though if the install interface only proposed gadgets that work, or a compatibility selector (let's not forget people who want to download-only something for an older system!). R PS: I have a built-in hardware indicator for system load that doesn't require me to waste CPU cycles on it. It's called fan 8^)
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
Glad to have been of help! R.
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
> This package contains client libraries allowing programs designed for > the ALSA, JACK and PulseAudio APIs to use a PipeWire server for audio > playback and recording. They are not used by default, and are currently > considered to be experimental. >From what I heard they work fine (for everyday use at least). >But it depends on pipewire-alsa which, even after selecting it, aptitude >refuses to install. It fixes the dependency problem by not installing >either. Aptitude does usually (or can) tell you why it won't install something. Have you tried with asking it to install just pipewire-alsa? Strange that that package isn't installed btw! There are alternatives to ALSA but AFAIK they're older and presumable less advanced. R
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Wednesday September 20 2023 13:12:02 A. F. Cano wrote: >ps -aux shows pipewire is running. Kmix, that I had to install as it >didn't come installed by default, only shows the dummy output device. On my system I often have to restart KMix after restarting the PA daemon, but that's mostly to get the volume control buttons to work again. KDE uses Phonon for audio output, preferably with the Phonon VLC backend. This used to give you a choice out of all detected audio devices plus the pulseaudio (PA) daemon, in the version I have installed nowadays it has to be PA. IIRC there is a compatibility layer in PipeWire that makes it visible to applications that only support PA; you'll probably want to install that. If you have already and it still doesn't work ... I'm out of ideas.
Re: batch setting file date from exiv metadata in digikam
I know exiv2 can do it too (`exiv2 -T rename *`) but it would be more convenient if digiKam could do the operation, with a little more control over which files are touched and/or using additional information (like not touching files I modified in dK).
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Wednesday September 20 2023 07:44:15 Michael Eager wrote: >Pipewire is running. And KDE (KMix in particular) knows how to use it (or else you have the PulseAudio compatibility thing configured)? Do non-KDE applications have working audio?
batch setting file date from exiv metadata in digikam
Hi, Probably not the most appropriate place to ask, but is there a feature in digiKam to set the file date of all photos in my collections to their respective exiv date? Oh, and if there's a way to have that date be set during import that'd help too! Thanks, R.
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
>Anything else I could try to figure this out? Thanks. Maybe an open door, but do you have pulseaudio running (or PipeWire, if that's what KDE is supposed to be using)? R
Re: Plasma freezes after login
On Tuesday September 12 2023 17:12:14 Michael Eager wrote: >CTRL-ALT-F1 displays the grub splash screen. I can get a virtual That seems odd, to keep that running after the initial boot step! >console with CTRL-ALT-F3. Oddly enough, I can log in on this virtual >console, run startx, and get a plasma screen. So your initial, frozen session is at console #2? What happens if you switch back to it? I didn't mention that in my previous mail, but that's what the "salvation" process is: switch to another virtual console and then back again. Is your 2nd plasma session fully operational as you'd expect? >/var/log/syslog no longer exists. That's odd too, but there must be a successor. Maybe looking at the timestamps of the *rc and *.ini files in ~/.config refreshes your memory of those last changes you made! R
Re: Plasma freezes after login
On Tuesday September 12 2023 14:35:19 Michael Eager wrote: >I can log in remotely using SSH, into the same account with the locked >screen. There's essentially zero CPU usage. Plasmashell is running. > >Running "killall -u " brings the system back to the login window. It's surprising that you can't get to a virtual console; the shortcuts for that are handled by ConsoleKit, and they have often been my salvation if the X11 mouse or keyboard input/control got messed up. /var/log/syslog may contain something useful, and there must be a logfile that has all the output from the startkde process that bootstraps your desktop and thus from every process that gets launched via the desktop shell. On my Trusty old system those logs live in ~/.cache/upstart, no idea where they are on a more modern system. R.
Re: Plasma freezes after login
>the gear stops rotating, but the screen remains blank and is unresponsive. Can you switch to a virtual terminal (Ctrl-Alt-F1 for instance) or log in via ssh? (there are ssh apps for smartphones, in case you don't have another computer with them installed.) I've seen cases of full lock-out except from SSH as a result of a GPU freeze - the last one of those I had with my i915-driven eGPU was when trying out an Electron-based app that tried something a bit too fancy. (IOW, a modern desktop with all bells and whistles could have that same effect, I fear.) R.
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tuesday September 12 2023 15:57:03 A. F. Cano wrote: >Another data point: On a Mac Pro, Debian 12 (kde-full 5:142) >with 2 Intel(R) Xeon(R) CPUs E5320 @ 1.86GHz, 4 cores each: >"Individual Core Usage" -> "Sensor Details" shows all 8 cores. > >"Individual Core Usage" works fine >"System Load" produces no output. > >Any idea what the problem could be? I'm reluctant to upgrade my main system >if things like this are going to break. Can I provide some spefic data that >might help pinpoint the problem? I don't know what backend your plasmoid uses, but 2 things you could try to see if more traditional utilities also have problems: 1) From a shell, run `sensors-detect` (as root, let it run all the tests it proposes) followed by `sensors`. 2) Also from a shell, run `solid-hardware list details` R.
2FA tribulations (Fwd: Your account has been deactivated)
So I finally had to bite the bullet and enable (that IMHO ridiculous) 2FA requirement ... and a few days later github followed suit. One of these suggested to use a cloud-based 2FA solution, which I didn't investigate immediately but now am curious about. Are there any online apps where you can get those fancy one-time codes? I haven't yet had much luck googling for one (mostly found solutions allowing providers to set up 2FA etc). For now I'm using the browser extension from authenticator.cc which is fine for use around the house and other places where I might have my personal browser. But for github I'd like not to give up the possibility to log in from a "foreign" computer when using my phone is not an option for some reason. Are there any 2FA services you can just log in to the old-fashioned way, and get a code from? I know it partly defeats the purpose but I can't be the only one who doesn't really care about that for some of the things I now need 2FA for (wouldn't use it for my bank, for instance). Thanks, R.
Re: KDE4 pager without outlines?
On Tuesday August 01 2023 04:54:34 Duncan wrote: >What I'm saying is that if you can see them in my message, you /must/ have >at least one font installed that can display them! =:^) Not necessarily if he's using some kind of web interface (in a proper browser) which leverages webfonts for this kind of thing. ;^)
Re: KDE4 pager without outlines?
On Friday July 28 2023 11:09:26 Mun wrote: >not have the appropriate fonts installed. I could not find any >symbols that looked like the ones you have shown. In fact, I could >not find any that were in color. However, I may still try and figure I'm pretty certain that Qt4 doesn't handle coloured fonts but the B version of those symbols should be available in any up-to-date enough Unicode font. Fonts have version numbers too (they're programmes) so don't hesitate to grab and install a recent copy of some free Google or Ubuntu font.
Re: KDE4 pager without outlines?
On Monday July 17 2023 15:00:41 Mun wrote: >> Also, you can install new components via one of the right-click menus. I >> don't know how many there are still available that work with a Plasma4 >> desktop but there might be a 3rd party pager that does what you want. > >I did find a 3rd party pager, but I need to figure out how to compile >it on RHEL7. Right-click on the taskbar that has your pager, select "Panel Options"/"Add Widgets..." then "get new widgets"; search for "Pager" in the window that opens. These should all install without compilation (but as said, no idea which ones will work under Plasma4; some will install but refuse to run). Also no idea how things will behave if you run multiple pagers at the same time... R
Re: KDE4 pager without outlines?
On Monday July 17 2023 11:50:52 Mun wrote: >Unfortunately, I don't think I can talk IT into doing a KDE upgrade on >our RHEL7 systems. I get the impression you're not a programmer/developer, but in case that's wrong: I would hope that "IT" have been accommodating enough to install at least a recent version of the KF5 frameworks so you can run (and build) KDE5 applications? If so you should be able to install liquidshell into your own home directory, and use that as your desktopshell. It's a monolithic application, meaning it has the desktop features, taskbar, pager, etc. all in a single executable. I also do not know if it does what you want. Also, you can install new components via one of the right-click menus. I don't know how many there are still available that work with a Plasma4 desktop but there might be a 3rd party pager that does what you want. R.
Re: KDE4 pager without outlines?
On Monday July 17 2023 11:31:04 Mun wrote: >I tried enabling that setting--even though I'm not actually sure what >it is supposed to do--but I didn't notice any difference in the Pager. It allows you to put a different set of widgets on each desktop. You can surely find a widget that can help to make each desktop visually different. It's a bit strange that the desktop shell itself doesn't have a possibility to show a different background image or colour on each desktop. R.
Re: KDE4 pager without outlines?
On Friday July 14 2023 15:42:40 Mun wrote: >o Highlight the current Virtual Desktop with a unique color or something In the standard KDE4 pager you can select to have different widgets on each virtual desktop, which gives you a way to make the different desktops more recognisable. >o Not have any of the window outlines shown within the Pager You mean the tiny window representations in the taskbar "buttons" representing the different desktops? I'm surprised anyone actually notices those... R
Re: tyran.kde.org
On Monday July 10 2023 14:24:46 Bernd Nachtigall wrote: >I found this in the log of the firewall. >The FW lets only permitted connections pass. >I check the log to see what connections are needed. In this case I do >not know what it does, so I ask ... https://en.wikipedia.org/wiki/Simple_Network_Paging_Protocol For outgoing connections the most likely explanation is that something on your system is configured to send out a pager message, presumably in reaction to some urgent situation. That seems like a valid use case if not a bit surprising because who still uses pagers nowadays... Besides: #> telnet tyran.kde.org 444 Trying 85.10.198.55... Trying 2a01:4f8:a0:600e::5... telnet: Unable to connect to remote host: Connection refused Exit 1 R.
Re: tyran.kde.org
On Monday July 10 2023 11:44:42 Bernd Nachtigall wrote: >What is the reason for Port 444? #> fgrep 444 /etc/services snpp444/tcp # Simple Network Paging Protocol snpp444/udp In what log did you find this hostname? R.
Re: Automatic PSK wifi on boot
On Sunday February 26 2023 09:00:04 Dave Close wrote: >It's possible that the problem stems from the KDE wallet. I haven't >set it up and find it annoying that it seems to be required. You could try setting up only the local wallet. It not storing the password rings a bell for me though, and that never happens when I select the "allow for all users" option. The password is stored elsewhere, presumably in some secure storage managed by the NM and changes are made via a privileged helper launched by the KDE Daemon (kded). That one isn't running when you're not logged in, nor is the KDE wallet daemon, which means a KDE wallet cannot be required for connecting to a WiFi network at boot...
Re: Who has stuck with an older version of Plasma for a while?
On Wednesday February 22 2023 01:54:12 Dave T wrote: I just use Plasma4 for the desktop shell; KDEPIM aside which I've also kept on one of the last 4.1x versions I've built my own updates of the KDE applications I use regularly. Not that those are especially up-to-date :) To think that years ago I picked an Ubuntu derivative because it's based on Debian which I thought would give me rolling updates. I've seen how cumbersome major updates can be (I maintain a Devuan install on my partner's laptop)... >the finger at my hardware (nvidia GPU) plus the the transition from >X.org to wayland. I really hope there's nothing compulsory about that! R.
Re: Who has stuck with an older version of Plasma for a while?
On Tuesday February 21 2023 02:18:25 Dave T wrote: >I'm thinking about sticking with KDE Plasma 5.26 (or maybe one of the >KDE Plasma 5.25 releases) until I'm ready to move to wayland and ... >Who is doing something similar and could offer me some advice? (Or >should I ask on an Arch Linux forum?) Ahhh, the eternal update dance... it gets old, doesn't it? I'm personally still on Kubuntu 14.04 (and so, yes, with Plasma 4), updated myself in part with PPAs containing backports and with locally built software managed through a 3rd party packaging system. Pinning/holding a selection of packages would work but only if you're certain that non of the pinned packages have dependents which also get blocked from being updated; this can lead to a snowball effect. You'd probably be fine though just pinning your entire KDE DE, if the version you have works for you. You'd best ask about that kind of details on an Arch forum or ML. Note that KDE has one or even 2 systems of its own to grab sources and build the entire DE. IIRC Arch is one of the distros that is normally built locally so following that approach wouldn't really be overly new for you or require setting up a dev. environment etc. R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Sunday February 19 2023 21:24:25 Roberto Ragusa wrote: >What I am seeing on older versions is that the desktop is not switched, >the window appears in the taskbar (which is set to only show windows in >the current desktop) and suggests me to click there to switch desktop >and reach the activated window. >So this is now gone away? This is more or less how things always worked for me too, until a recent Firefox update a while back. So not as a result of some change in KDE! I haven't verified if that change has been reverted. R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Wednesday January 18 2023 14:15:08 Frank Steinmetzger wrote: > So I suspect a Firefox problem here, not Kwin. I agree, and you'll notice that my question was whether KWin would be able to prevent such behaviour ;) R.
Re: konsole problems with utf8 characters
On Wednesday January 18 2023 03:50:02 Frank Steinmetzger wrote: > By happy accident I recently discovered that in Konsole profile >settings under Appearance→Advanced, there is an own option for an Emoji >font, which in my case was set to “-1”. So I selected a proper font (the >pre-installed Noto Color Emoji) and with that I got a full list of images >from the sample text.拾 Do you get the colour version? Remember that these fonts evolve, often quicker than distro maintainers update them.
Re: konsole problems with utf8 characters
On Sunday January 08 2023 21:11:05 Patrick Nagel wrote: >Hi René, > >It was an easy fix, once I knew where to look :) You're welcome, glad to have helped! R.
Re: konsole problems with utf8 characters
On Friday January 06 2023 10:48:15 Patrick Nagel wrote: >For me Konsole also doesn't show emojis and also many other characters Attached the little file I use to test emoji rendering. all of which are rendered fine in my older konsole5 version (20.11.70) built against Qt 5.9, using the basic `cat` command to display it (but also in vim). I did have the kind of problem evoked, and as far as I understand it is usually a question of using an outdated or improperly configured emoji font. I do remember updating my emoji font That was in oct. 2021 if file dates are any indication, so I no longer remember the details of what I did. NB: konsole will (of course?!) use the B/outline version of emojis, so if you configure a colour emoji font you'd have to make certain that it contains the B versions too... R.A sample of the emoticons/emojis I find in incoming emails. (SMILING FACE WITH HALO; Unicode: U+1F607 (U+D83D U+DE07), UTF-8: F0 9F 98 87) (SMILING FACE WITH SUNGLASSES; Unicode: U+1F60E (U+D83D U+DE0E), UTF-8: F0 9F 98 8E) (SUN WITH FACE; Unicode: U+1F31E (U+D83C U+DF1E), UTF-8: F0 9F 8C 9E) (SMILING FACE WITH SMILING EYES; Unicode: U+1F60A (U+D83D U+DE0A), UTF-8: F0 9F 98 8A) (CAT FACE WITH WRY SMILE; Unicode: U+1F63C (U+D83D U+DE3C), UTF-8: F0 9F 98 BC) (COLLISION SYMBOL; Unicode: U+1F4A5 (U+D83D U+DCA5), UTF-8: F0 9F 92 A5) (WRAPPED PRESENT; Unicode: U+1F381 (U+D83C U+DF81), UTF-8: F0 9F 8E 81) (HEART WITH RIBBON; Unicode: U+1F49D (U+D83D U+DC9D), UTF-8: F0 9F 92 9D) (MULTIPLE MUSICAL NOTES; Unicode: U+1F3B6 (U+D83C U+DFB6), UTF-8: F0 9F 8E B6) 落 (Unicode: U+1F918 (U+D83E U+DD18), UTF-8: F0 9F A4 98) (Unicode: U+1F326 (U+D83C U+DF26), UTF-8: F0 9F 8C A6) (PUBLIC ADDRESS LOUDSPEAKER; Unicode: U+1F4E2 (U+D83D U+DCE2), UTF-8: F0 9F 93 A2) (FACE WITH STUCK-OUT TONGUE AND WINKING EYE; Unicode: U+1F61C (U+D83D U+DE1C), UTF-8: F0 9F 98 9C) (Unicode: U+1F3CD (U+D83C U+DFCD), UTF-8: F0 9F 8F 8D) (PARTY POPPER; Unicode: U+1F389 (U+D83C U+DF89), UTF-8: F0 9F 8E 89) (TRUMPET; Unicode: U+1F3BA (U+D83C U+DFBA), UTF-8: F0 9F 8E BA) (MONEY BAG;Unicode: U+1F4B0 (U+D83D U+DCB0), UTF-8: F0 9F 92 B0) (DELIVERY TRUCK; Unicode: U+1F69A (U+D83D U+DE9A), UTF-8: F0 9F 9A 9A) (EAR OF RICE; Unicode: U+1F33E (U+D83C U+DF3E), UTF-8: F0 9F 8C BE) (BLOSSOM; Unicode: U+1F33C (U+D83C U+DF3C), UTF-8: F0 9F 8C BC) (WOMANS BOOTS; Unicode: U+1F462 (U+D83D U+DC62), UTF-8: F0 9F 91 A2) (FULL MOON WITH FACE; Unicode: U+1F31D (U+D83C U+DF1D), UTF-8: F0 9F 8C 9D) (LEMON; Unicode: U+1F34B (U+D83C U+DF4B), UTF-8: F0 9F 8D 8B) (FIRE; Unicode: U+1F525 (U+D83D U+DD25), UTF-8: F0 9F 94 A5) 珞 ⏱ (STOPWATCH; Unicode: U+23F1, UTF-8: E2 8F B1) ⚡ (Unicode: U+26A1, UTF-8: E2 9A A1) ⌛ (Unicode: U+231B, UTF-8: E2 8C 9B) ❄ (Unicode: U+2744, UTF-8: E2 9D 84) ⭐ (Unicode: U+2B50, UTF-8: E2 AD 90) ⌛ (Unicode: U+231B, UTF-8: E2 8C 9B) (BACKSPACE; Unicode: U+0008, UTF-8: 08, ISO-8859-1: 8) (NO-BREAK SPACE; Unicode: U+00A0, UTF-8: C2 A0, ISO-8859-1: A0) (ZERO WIDTH JOINER; Unicode: U+200D, UTF-8: E2 80 8D) (ZERO WIDTH NON-JOINER; Unicode: U+200C, UTF-8: E2 80 8C) (ZERO WIDTH SPACE; Unicode: U+200B, UTF-8: E2 80 8B) 语言
Re: Dolphin replace/remove invalid chars in filename when copying to NTFS?
On Thursday January 05 2023 14:18:19 clarjon1 wrote: >Having just an automated autoreplace could result in poor results, esp >if not explained to the user... +++ >"Some files contain characters not allowed by the destination file >system (FilesystemTypeHere) and cannot be copied as-is. Manually >rename the files below, click to allow auto-replacement of characters, >or continue operation without those files Autoreplace is not a good idea, not even when applied to the target files. The safest and simplest solution would be to replace the autoreplace proposal with one to pack the files in some standard archive (zip, 7z, ...) that can be configured via Dolphin's preferences or a popup dialog. Archiving circumvents all possible cross-platform issues, or rather, postpones them to the unpacking stage on the target system where they have been solved already. Users can be expected to be familiar with how that works - and I wouldn't be surprised if MSWin has tricks up its sleeves to make officially invalid characters appear in file names (IIRC the initial support of "long" file names on FAT filesystems also worked with a lookup table). R.
Re: Dolphin replace/remove invalid chars in filename when copying to NTFS?
On Thursday January 05 2023 09:29:43 Alexander Puchmayr wrote: >Hi, > >I just wanted to copy a bunch of files containing various characters like '?' >and ':' in their names to an NTFS drive with dolphin, and got lots of errors >because of that names. Dolphin does not remove those characters (or offer to >do >so), the only option you have is abort. > >Of course, one could do that in a shell using pattern replacement, but the >average user, who is not familiar with those bash/aws/sed tricks, will prefer >a more convenient way. So is there a way of doing that in Dolphin? AFAIK this was always handled at the filesystem driver level, possibly with some kind of mapping trick that would allow the user to see the original filename from the Unix side. But there's also something to say for disallowing this altogether; it's good practice to use file names that are valid on all the (file)systems you want to use them with... R
Re: Long links in konsole, truncated at EOL when hovered or clicked.
On Sunday December 25 2022 08:26:58 A. F. Cano wrote: >I gather this is an old problem that has been looked at before with no >solution found as it depends on ncurses, that mutt uses. Oh well. Maybe configure an external message viewer (even something simple as `less` seems to keep line-wrapped links intact/together, in my quick testing)? R.
Re: Long links in konsole, truncated at EOL when hovered or clicked.
On Saturday December 24 2022 14:33:17 A. F. Cano wrote: >"Open by direct click" enabled, but long links (that go further than one line >in mutt >) stop at EOL. Only the first part is underlined or used on click. Can you confirm that the link detection works correctly in the shell, e.g. when you `cat` a file containing them? If so you'll probably want to look into configuring mutt so it doesn't do any wrapping of the email message bodies. FWIW, this sort of thing is why I stopped using pine after resisting for as long as possible. R.
Re: Performance difference
On Friday December 23 2022 12:38:17 Patrick Nagel wrote:
>(probably 200-300ms of these "real" numbers is me reacting slowly to the
>window popping up and pressing ALT-F4...)
A thought: download the AppImage version of a larger application, like Firefox
on both systems, and do
```
> time /path/to/firefox*.AppImage --version
```
This will unpack the entire appimage contents to a temporary directory and
launch the application, excluding any KDE-specifics and also network activity
but above all the human reaction component. Should be a good test of your disk
subsystem.
NB: the `--version` trick works for KDE apps too of course:
```
> time dolphin5 --version
dolphin 20.07.70
1.074 user_cpu 0.257 kernel_cpu 0:04.02 total_time 32.8%CPU {46064M 898F 4110R
29529I 12O 840w 359c}
> time dolphin5 --version
dolphin 20.07.70
0.759 user_cpu 0.138 kernel_cpu 0:00.87 total_time 101.1%CPU {46068M 0F 4400R
3649I 4O 446w 167c}
> time kate5 --version
kate 19.08.3
0.920 user_cpu 0.249 kernel_cpu 0:02.73 total_time 42.4%CPU {45640M 380F 4320R
11687I 4O 775w 220c}
> time kate5 --version
kate 19.08.3
0.739 user_cpu 0.159 kernel_cpu 0:00.86 total_time 102.3%CPU {45488M 0F 4431R
3639I 4O 498w 185c}
```
Start up delays on my much slower system (that's an Intel N3150 CPU!) sometimes
*feel* like 20 seconds but clearly they're much less, so yeah, you may have an
issue somewhere. Have you checked your syslog and/or checked the SMART health
status of the drive in your slower system? Does the delay depend on how many
other applications you're running (i.e. how much free RAM you have)?
R.
Re: Performance difference
On Thursday December 22 2022 16:40:18 Dave Close wrote: >The only difference I've found thus far is that the slower one does not >have a swap partition. Any suggestions for what else I can check, and >hopefully fix, will be appreciated. Have you tried timing the performance difference of the 2nd time you start that command? KDE apps tend to have a lot of libraries to load with lots of symbols to retrieve (I have the impression that number is only going up with every new C++ standard and Qt version). Provided you have enough RAM those libraries will be in some kind of cache, allowing for a much faster start-up. I see this myself, on my lowly, ageing beater which runs off a ZFS pool on an SSHD. I think the SSD part of that drive is probably toast by now so I no longer have the benefits of that, so loading a command for the first time clearly requires a lot of "disk scraping". I assume your 2 laptops have SSDs (of comparable performance) so that filesystem fragmentation is mostly irrelevant? BTW, you do use the same filesystem (and filesystem settings) on both? R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Monday December 19 2022 06:56:56 Duncan wrote: Was there an answer to my question in that essay (about the version range where KWin had a setting to control raising behaviour)? >But low-Q or not, old computer backing up the fancy if low-q display or >not, how many have such a display "wall" at all? That's /something/. And >it /does/ change the way you work. I also have a Macbook with a big enough external display and even there I wouldn't want to have to work around the fact that a window supposed to be on another virtual desktop might come cover the window I'm working in, be it as a result of something I just did or of some automatic behaviour. That rig runs OS X (sic, because that's what the version in question was called) and desktop-hopping isn't an issue there. Because that's the thing: windows can be raised for multiple reasons, direct user request being just one of them (albeit a priori the most frequent one). AFAIK websites can ask that their window be raised, for instance. R.
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Friday December 16 2022 07:56:11 rhkra...@gmail.com wrote: >Definitely useful / preferred behavior for me. As I'm going through my >emails, >I click on links that I want to read later (usually after getting through some >portion of my emails). Exactly the use-case I tried to describe. FWIW, you don't even have to want to go through a list of links and/or emails. Often enough there is/are link(s) in a longish email that you're reading through that you want to click on when you come across them (so as not to have to go through all that text again) but without stopping to read that email. So you don't want to get another window in your face. It should not be necessary to lock your browser to a different, fixed desktop in that case. In fact this is another instance where a desktop/laptop computer should NOT behave the same as a phone/tablet!! R
Re: Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
On Friday December 16 2022 04:20:50 Duncan wrote: Thanks, but >be the default (or only available behavior as it was before) because it >/is/ confusing. Sorry, your entire answer is a little confusion to read through. >Old and definitely confusing but arguably could-be-useful behavior, now >missing option: Can you tell what version of KWin introduced the setting and in what version range the option is/was present? I'm using KWin 5.12.x (probably ancient but it does the trick for me just fine) and I cannot seem to find the entire setting in the "Window Behaviour" KCM. And, supposing my KWin version only has that "old and [...] arguably could-be-useful behaviour", how come FF manages to get the window to the current desktop - is there a specific call that can be made just to change the desktop a window is displayed on? (AFAIK virtual desktops are not an X11 concept!) > >* Only switch to that desktop if manually activating a window, via alt- >tab, taskbar, etc. If an existing window on a different virtual desktop ... >Of course besides being confusing it's just harder to clearly explain in a >short form similar to the above choices, and it'd certainly be the most >esoteric choice, so I can't really blame them for losing it, but it's >still lost behavior that some people might miss... What's confusing about it? It just means "don't change desktops unless the user really wants it". Or, call the option "don't change desktops" and leave it to change the desktop via one of the actions designated for that particular purpose. It'd be debatable in that case whether clicking on a window representation in the panel could be included *) In theory it sounds fine to switch to the target desktop, but in practice that can be just as annoying as having to switch manually. How often does it happen that you read through an email with a list of some kind of offers and you just want to process that list first, opening the links as a stack that remains in the background? KDE was always great for power users with methods like that ... losing them really feels like laziness on the part of the devs carrying on the torch... R. *) Or not be debatable, once you realise that that too is an action that could well have multiple effects. Already the effect depends on whether or not the widget represents what resumes to a single window or an application with multiple windows open. PS: for anyone wondering about the same FF thing, there may be a workaround in https://bugzilla.mozilla.org/show_bug.cgi?id=1805766 . It works for me, and now I have to dig out the window myself, but that turns out to be much less invasive/production-inhibiting than I thought.
Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?
Hi, Firefox 109 has a new trick up its sleeve: opening an URL from, say, KMail cause the FF window that will host the new tab to raise itself (as before) AND now also to switch to the current virtual desktop. I don't want that; is there a way to disallow this behaviour in KWin? (I haven't found ...). At least I assume that KWin is the application that handles the virtual desktops and either way I'd like to restrict window/desktop changes to KWin. Thanks, R.
Re: encode problem of kmail for Japanese Mail
On Wednesday November 02 2022 16:09:46 Masaru Nomiya wrote: >MN> There exits a bug in kmail, I think. > >I checked again and the problem is only with UTF-8 encoded emails, not >with Shift_JIS encoded e-mails. >There was a problem with the Shift_JIS email used for the check, but >the cause is still unknown. > >Anyway, I think the cause of the garbled characters is that Japanese >UTF-8 encoded e-mails are decoded in ISO-8859-1 (or ISO-Latin-1). You've done a reasonable amount of triaging so you should probably report this directly on BKO (bugs.kde.org). There are also mailinglists specific to KDEPIM where this is much more likely to be seen by someone of the dev team. R.
Re: Fwd: Your account has been deactivated
On Monday October 24 2022 13:44:43 Nekobit wrote: >I'm in a bit of a crunch to setup a proper client on my >mobile device right now. Do I have to understand this requires an additional app and thus a smartphone?! Why not impose one from whichever phonemaker is the largest KDE sponsor, while you're at it (and I'm guessing that won't be Apple)? Also, does this mean you need to jump through additional hoops nowadays to fetch from and/or commit to KDE repos (and I mean in a CLI of course)?! Having to do 2FA on a single device always makes me want to hurl at the sky... R
Re: Fwd: Your account has been deactivated
On Monday October 24 2022 15:37:24 Paul Dann wrote: >2FA really is not hard to set up, and significantly reduces identity theft. The question is not how hard it is to set up or not but rather why anyone would bother to hack the account of a random KDE contributor. When you know you're fooling yourself in thinking this "minor inconvenience" will stop anyone who really does want to do that. If there's somehow a true risk of your identity being stolen via gitlab than 1) I have more reason to dislike the platform and 2) maybe I regret not having done my contributions under an "artist's name" ... R.
Fwd: Your account has been deactivated
Hi, This is probably not the most appropriate mailing list for the rant below, but here goes: I can half understand that inactive accounts get deactivated, but on logging in and reactivating my account I got a message that I was required?! to enable 2-factor auth? What on earth is the point of that on an _open source_ git server, esp. if you use your github credentials to log in?! It's not like there are secret parts to the code or that contributors are vetted to an extent that "we" need to be extra certain it's indeed them who are logging in. I hate 2FA as it incites too much to remain logged in (and to be married to a mobile if not recent enough smartphone). R. --- Forwarded message: Date: Monday October 24 2022 From: KDE Invent To: rjvber...@gmail.com Cc: Subject: Your account has been deactivated Hello René J.V. Bertin, Your account has been deactivated. You will not be able to: - Access Git repositories or the API. - Receive any notifications from GitLab. - Use slash commands. To reactivate your account, sign in to GitLab at https://invent.kde.org/. Please contact your GitLab administrator if you think this is an error. -- You're receiving this email because of your account on invent.kde.org.
Re: Plasma message window text color
On Sunday October 09 2022 01:35:19 Duncan wrote: >The linked image was the notification plasmoid/widget thus plasma (aka >plasmashell and plasmoids/widgets) style. For normal (non-plasmashell) >application message windows it would indeed be the colors kcm. What about the text colour(s)? (There are 2 ways to making these popups more readable...)
Re: Plasma message window text color
On Saturday October 08 2022 00:52:00 Duncan wrote: >I believe that's part of the plasma style settings. Look in kde-plasma's >systemsettings under appearance, plasma style, load it directly with >kcmshell5 desktoptheme Depending on exactly what kind of message window this is you may have more direct luck with `kcmshell5 colors`, where you can select colour themes (or just themes in current k-speak) and edit existing ones. There are many options to chose from so it will be a trial-and error procedure to figure out which one you need to modify but it will probably be in the "window" or "tooltip" sets. R.
Re: Chrome interferes with KDE
On Tuesday October 04 2022 15:36:07 Jerome wrote: >I keep about 20 tabs open across 2 Chrome windows, which doesn't seem like >much Indeed, I have more tabs in more Waterfox windows open. >The Marvellous Suspender will free up RAM, but not X connections. Not just RAM (plus evidently CPU cycles). Your Chrome session counted for more connections to the X server than the number of tab you have open, right? It's very likely that complex pages open multiple connections, for things like overlays, different compositing contexts etc. Before discovering The Great Suspender I would use Chrome's process manager to kill CPU and/or RAM hungry tabs without closing them; TSM works in a very similar way. The process corresponding to the page is killed, and the page replaced with something very simple; I have to assume this also means all "extraneous" connections to the X server are terminated (the ones in the browser process which keeps running; the ones in the killed process are released by definition). R.
Re: Chrome interferes with KDE
On Tuesday October 04 2022 15:00:28 Jerome wrote: >> After 70 days of uptime, Chrome (prior and latest version) is interfering >Closing enough things (like KWrite windows) to get Xorg to 255 or less clears >the problem while I wait for a good time to log out/in again. Have you tried restarting Chrome (and a tab unloader like The Marvellous Suspender, if you keep as many tabs open as I think you must do)? This must be about open files (and AFAIK sockets count to that number) and it wouldn't surprise me at all that something as complex as Chrome doesn't release all its connections to the X server perfectly as soon as they're no longer needed. R.
Re: Chrome interferes with KDE
On Sunday October 02 2022 17:12:58 Jerome wrote: >to somewhere else. Reboot tomorrow morning I guess... 70 days is doing pretty >well for KDE 4... Fedora is still providing a KDE 4 desktop?? My FranKubunto 14.04 with Plasma4 desktop but self-built, parallel-installed KF5 versions of my main KDE apps is now at 69 days uptime. I don't use GChrome; the only reasons for reboots are either because it's about as fast as logging off and back in and will really free all resources, or because a pm-sleep doesn't complete and I have to power-cycle. R
Re: restored konsole sessions broken - no input possible
On Monday August 29 2022 09:14:00 Andreas Gungl wrote: >Well, does anyboday else care of such a behaviour, or is it just me? This seems like exactly the sort of "client facing" feature "they" should care about, but given the goals on which I was just invited to vote (https://phabricator.kde.org/project/view/322/) I am not so certain it is indeed high on the priority list. Mind you, this may have nothing to do with KDE itself; AFAIK the session management stuff is implemented at a lower level, probably through freedesktop.org libraries or at least following their standards/protocols. Your best bet to figure out who's responsible is to look at was got updated/upgraded just before noticed the issue for the 1st time. If you're using X11 you could try to restart KWin to see if that unblocks your Konsole tabs: hit Alt-F2 and type `kwin_x11 --replace` in the popup to appears. Have you tried the "View/Clear scrollback and reset" menu command in Konsole? R
Re: Konsole doublle click
On Tuesday August 23 2022 10:56:29 J Leslie Turriff wrote: > I believe that characters in that list are treated as part of a word, > so token=value >would be interpreted as all one word. That is indeed what the tooltip confirms: characters that are considered part of a word (in addition to the standard alphanumerical characters). R
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Friday August 19 2022 21:43:20 Duncan wrote: >From krunner "killall plasmashell" (without the quotes) should do it. To >get it back, just "plasmashell". You will probably find that this logs you off (or drops you back to the console) ;) R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Tuesday August 16 2022 15:30:23 Koeame wrote: >I probably might figure it out later, because I'm very exhausted right now, >but if I don't, could you help me navigate where to report a bug? Thank >you. There's no hurry, but I forgot to mention this is done on bugs.kde.org . I think it's pretty straightforward but you can always ask if you get stuck. R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Tuesday August 16 2022 14:12:29 Koeame wrote: >May as well try to do this, and it's going slow for me considering I'm >doing other things, but I'm getting through it. Thank you for all your help >into seeing this btw I really appreciate it. You're welcome. This is the sort of thing that could drive me crazy too If going to another DE solves the issue for you, please do consider filing a bug report against plasma-desktop (if there isn't one already). The devs should know that their immature feature drives people away from the Plasma desktop and that they could at least implement a very basic way to disable or configure it (meaning editing a configuration file by hand, if writing a proper GUI is not feasible for now). I forgot to mention: in order to make KDE apps look and behave as much as possible as if they were running on a Plasma desktop session you will probably have to set 2 environment variables at the desktop shell level (in the "global" section of your ~/.bashrc should be fine): KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 If you also chose to use KWin and Dolphin instead of the default window manager and file explorer apps for that DE you will hardly notice the difference except in the look & feel of the panels, desktop icons etc. R. > >On Tue, Aug 16, 2022 at 11:54 AM René J.V. Bertin >wrote: > >> On Tuesday August 16 2022 11:35:44 Koeame wrote: >> >that package was, but it was plasma-touch related), but that did not work. >> >What if I just uninstalled plasma5-workspace as a package? lol >> >> That will probably also uninstall most of what gives you the Plasma DE >> (but I can be wrong). >> >> There's an alternative KDE desktop shell which is purely widget-based (no >> QML like Plasma uses primarily nowadays I think). You can run that as an >> alternative to plasmashell. Last time I checked it probably didn't have an >> "edit mode" at all. So there's that solution. You may have to build it >> yourself though, if no one made a PPA for it. >> >> If the issue is limited to the desktop it would be easier just to log in >> to a different DE. It may not look as fancy, but you could actually find >> your computer more responsive because Plasma isn't exactly low-resource >> anymore (as far as I can tell). >> >> R >>
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Tuesday August 16 2022 11:35:44 Koeame wrote: >that package was, but it was plasma-touch related), but that did not work. >What if I just uninstalled plasma5-workspace as a package? lol That will probably also uninstall most of what gives you the Plasma DE (but I can be wrong). There's an alternative KDE desktop shell which is purely widget-based (no QML like Plasma uses primarily nowadays I think). You can run that as an alternative to plasmashell. Last time I checked it probably didn't have an "edit mode" at all. So there's that solution. You may have to build it yourself though, if no one made a PPA for it. If the issue is limited to the desktop it would be easier just to log in to a different DE. It may not look as fancy, but you could actually find your computer more responsive because Plasma isn't exactly low-resource anymore (as far as I can tell). R
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Tuesday August 16 2022 06:50:26 Duncan wrote: >But because it's a behavior clicking on the desktop itself, not something >in kwin, etc, I'd say it's almost certainly coded in either plasma- >workspace or plasma-desktop. Doesn't it happen in all applications? In a way that wouldn't really make sense if the idea is indeed to implement the traditional tap-and-hold to bring up the context menu (which is what the OP confirmed happens to him, from what I understood). It would make sense to code a plasma-specific implementation as "close to home" as possible (I'd say that would be plasma-shell, or some library used by that application). An implementation that has to be available in any running Qt app can be in very few components, the KDE platform theme plugin being one of them. R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Monday August 15 2022 13:37:38 René J.V. Bertin wrote:
> /*!
>
> Set the timeout, in milliseconds, before the gesture triggers.
>
> The recognizer will detect a touch down and if \a msecs
> later the touch is still down, it will trigger the QTapAndHoldGesture.
> The default value is 700 milliseconds.
>
> */
> void QTapAndHoldGesture::setTimeout(int msecs)
> {
>
> QTapAndHoldGesturePrivate::Timeout = msecs;
>
> }
NB: the timeout appears to be a global parameter, not something that can be
varied so you cannot have different timeouts on tap-and-hold gestures (on
different objects, for instance) in a single application.
That means it *should* be possible to inject an override that sets the timeout
to some sufficiently long duration so you don't trigger the gesture by accident
but can still trigger it if you want to.
That would be done by a simple call to QTapAndHoldGesture::setTimeout(); a good
place to do that would be in a widget style. Those are typically not very
complicated to build (and distros usually make it easy to install the build
dependency of any of their packages).
@Duncan: in what part of the code did you see the implementation? I put my own
implementation in the KdePlatformTheme class which is one of the rare places
where it gets exposed to just about any Qt application with a GUI. If the
Plasma implementation is in a similar package (the plasma-framework isn't the
most complex or expensive to build) it would be almost just as easy to disable
the feature or set that timeout there.
R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Monday August 15 2022 04:46:46 Koeame wrote:
>Alright, is there a way to turn Plasma-Touch off or anything like
>that, assuming the long-clicking is tied to it? That could be a way to
>disable the annoying long-clicking I'm doing. Apologies for the wording,
>I'm not tech-savvy.
Is there is a dedicated touch*screen* configuration panel in
SystemSettings/Input Devices? NB: touch*pad* is the trackpad, if you have one
of those too. If not, or if that panel is of no help:
If Duncan is right and you're running into a Plasma "feature" which cannot at
the moment be configured there are basically 2 options
- your distro packages the touch-interface in an optional package. Uninstall
that. Plasma should lose support for using your panel for its own features but
you still have the device drivers installed so it should still work at the
system level
- set up another DE and use that instead of Plasma. Most environments allow
changing the window manager so if you're fond of KWin and its widget styling
you can still use that. And of course your KDE applications will continue to
work.
FWIW I've written a long-press-for-contextmenu feature myself using Qt's
tap-and-hold gesture, but only on certain widgets. I do think it triggers in
about 1s so that must be a Qt constant. And indeed:
> /*!
>
> Set the timeout, in milliseconds, before the gesture triggers.
>
> The recognizer will detect a touch down and if \a msecs
> later the touch is still down, it will trigger the QTapAndHoldGesture.
> The default value is 700 milliseconds.
>
> */
> void QTapAndHoldGesture::setTimeout(int msecs)
> {
>
> QTapAndHoldGesturePrivate::Timeout = msecs;
>
> }
R
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Sunday August 14 2022 21:28:18 Koeame wrote: >> Long-click is the traditional way to bring up the context menu in touch >> interfaces; it would not surprise me if the tablet handles this >> autonomously. >> > It's not a touchpad for human fingers, it's just a projector tablet that >can only sense the pen that comes with it. That's irrelevant, you're still using it as a touch interface to interact with an application. Now either that goes through support in/by each application, or it goes through the standard HID layers, i.e. your device is going to function as a pointing or a typing device. R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Sunday August 14 2022 12:02:59 Koeame wrote: >Also, if I may ask, why would the Edit Mode long-click be a hardcoded >gesture that I cannot enable or disable if I can just right click and Enter >Edit Mode that way, or Alt + D for my keyboard shortcut? Does a right-click activate edit mode directly or via a context menu? Long-click is the traditional way to bring up the context menu in touch interfaces; it would not surprise me if the tablet handles this autonomously. Pen click: you mean like clicking the mouse cursor on an object to "grab" it? The touch interfaces I am familiar with use a double tap for that. Alternatively: does the unwanted event still occurs if you move the pen a tiny bit before 1s has elapsed? Finally: I see there are Linux drivers for at least some models. Did you install those?! According to the manual I looked at there are many things that can be configured via the driver software. Maybe there is also something like a bios (firmware) settings screen you can call up when booting the tablet? It might be possible there to increase the required long-click duration, or even deactivate the feature altogether. If you find no suitable solution you can always write to the company (serv...@xp-pen.com); I'm guessing you paid enough for this device. Long ago I was interested in a non-standard application of a graphics tablet with pen pressure and tilt detection, to be used from an SGI workstation. I got into contact with a product manager, who was eager and interested to help me write my own driver. R.
Re: A way to disable the long-left mouse click shortcut to enter "Edit Mode" / modifying widgets?
On Saturday August 13 2022 23:44:11 Koeame wrote: >Hi, I've been trying to find a way to disable this feature for about a year >now, and to no avail. I have a XP-PEN projector tablet, counted as a second >monitor, and when I press and hold my pen for no more than a second, I >trigger the "Edit Mode" functionality. This has been an annoying problem NB: this is something for which you may have to ask on the calligra or krita (devel) MLs. Is long-press the normal trigger for edit mode or if not, what is? Some mouse/trackpad drivers (which can be in firmware) have hardcoded gestures which you cannot modify. I had a tablet PC where the trackpad has hide or shade window(s) coupled to a 2-finger gesture I'm used to making for other things. On Linux I was able to avoid that by using xev to determine what events were being generated. I don't remember exactly how I used that info to solve the issue; either via xmodmap or via KDE's global shortcut mechanism. In your case synclient may also offer a solution, or whatever equivalent exists for the touchscreen driver. R.
Re: Black screen on Kubuntu 22 LXD container
On Saturday August 13 2022 02:41:17 Duncan wrote: >Michael Eager posted on Wed, 10 Aug 2022 06:40:46 -0700 as excerpted: > >> I'm running Kubuntu 22.04 in an LXD container. >> >> When I connect using x2go, KDE starts up (I see the splash screen) but >> then the screen goes black with a cursor. After a short time, the lock >> screen is shown, with password field, so I think that x2go is working. >> When I log in, the screen goes black. There is a cursor, but neither >> left nor right clicks have any effect. I suppose this means your session and x2go run on 2 different machines To me it sounds like KDE could be trying to use compositing on a (remote) display channel that doesn't support this. Normally it should turn off the feature if it detects that it isn't supported but maybe there's a miscommunication going on here. One possible way to determine this is to open a terminal emulator or even to ssh in, and replace the KWin window manager with a simple WM that supports the --replace argument (e.g. xfwm4, which can be started with --compositor=off to ensure it won't use this feature). If that gives you more than just a black screen you can then use the GUI to disable the compositor in KWin, or experiment with different backends. The older KWin version I use, for instance, can use (emulate?) compositing with the legacy XRender backend, which happens to work better with my GPU and supports the few GUI effects I find useful. (NB: you can switch back to KWin with `kwin_x11 --replace &`) Are there other ways you can connect to the container, VNC for instance? R.
Re: System Tray icons
On Tuesday July 26 2022 14:48:02 Jerome wrote: >[Fedora 34, Plasma 5.24.4] > >I have my Task Bar/Panel looking pretty decent EXCEPT for the System Tray, >which still has monochrome icons. > >How do I colour those up? You mean greyscale versions of whatever icon they should have, not from a different, flat, B icon theme? I just noticed that the system tray does the same thing on my old Plasma4 desktop so it looks intentional. Maybe that the coloured versions are reserved for when one of the applications/services wants your attention? R
Re: nearly 100% graphics pipe of Rx570 usage when using certain applications
On Monday July 04 2022 10:09:50 Duncan wrote: >Good idea but he tried that, saying fluxbox (X wm) didn't help. And he >tried X and wayland. Doh, yes he did. >It'd be /nice/ to know if say qt 5.14 or 5.10 or whatever didn't have the >problem, while all of qt 5.15 (5.15.0-5.15.5, the latest available on at >least gentoo) does. I was surprised to see the other day that Qt is already at 6.2 or so. Definitely worth checking that version out, too! >The amdgpu (and radeon) driver(s) don't emphasize such parameters as much >as the intel driver does. They generally try to do good defaults that I >(and I suppose most non-gamers at least) have never bothered changing. >There's also amdgpu/radeon configuration for xorg.conf that I used to >tweak, but wayland's more difficult in that regard. FWIW, we have a big HP Pavillon laptop here that's young enough that it came with Win10 installed. It's got an i3 CPU but also an AMD (Radeon I guess) GPU with dedicated RAM. I've tried to address hiccups in browser video replay by forcing that app to use the dedicated GPU, and that always led to more fan noise. Never looked at this under Linux, I must say. BTW, that statement about parameters and default values is true for the i915 driver too. Only there have been so many buggy versions of it that people have had to start tweaking the parameters... (or kept using an "old" kernel, like the 4.14 LTS one I run on my N3150-based notebook that I bought *after* the aforementioned HP). >But dolphin doesn't appear to require them either, and it was a problem... Actually it does: dolphin uses kcmutils, which depends on kdeclarative. Hard to say if QML gets initialised, but check the loaded libraries when you run dolphin and you should see the QML-related ones in the list. R.
Re: nearly 100% graphics pipe of Rx570 usage when using certain applications
On Sunday July 03 2022 05:41:59 Duncan wrote: >My CPU is I think even older, AMD fx6100 so around a decade old now. But >I do have 16 gig of RAM and upgraded to all SSDs (on paired Samsung EVO >SSDs in btrfs raid1 mode), which made quite a difference compared to the >old spinning-rust drives. This is interesting. I wasn't going to chime in because I thought this had to be an issue with too-new hardware. But if Qt and/or Linux now start to cause CPU or GPU burning in hardware they should have perfect support for by now ... something is fishy. Some thoughts for the OP: - does the issue persist if you log in under a non-Qt DE - xfce would be a good, lightweight choice? - see if you can identify a "pure Qt" application, ideally one that come with Qt (ideally the Assistant, Linguist, etc) which shows the issue. Then, install the same Qt version from Qt's own binaries, and as long as the issue reproduces with install older versions. In short, try to identify if this is some kind of regression in Qt. Qt's Creator would be a good candidate for testing except they only ship a build that uses the latest Qt version. - the Intel driver (or at least the i915 one) has a number of parameters you can set at boot or, presumably, before launching the graphic environment. There is a lot of information out there on what parameter settings to use in case of specific performance or stability problems. Have you looked into those? - a bit of a long shot: have you tried different kernels? Newer (or older!!) ones, or a home-build with, say, the ConKolivas patches, or a Liquorix kernel? NB: Qt does seem to be the culprit here; if I had to point fingers I'd look at the WebEngine and QML components which both have their own graphic engines. R.
Re: Kmail "read" status recorded separately in inbox and gmail folders
On Saturday May 14 2022 19:03:41 Nathan Upchurch wrote: >I have several gmail accounts set up in kmail via IMAP. When I click on an >email from one of these IMAP accounts in either: > * Unified Mailboxes > Inbox, or > * IMAP Account Folder > Inbox, >the email is marked as read and the counter beside the folder decrements. The >read status of the email, however, does not apply to the same email in /IMAP >Account Folder > [Gmail] > (All Mail | Important)/, and I have to click on the >email in both /All Mail/ and /Important /for the email status to change to >/Read /in each of those folders. Any idea how to fix this? Ian is right that you should ask on kdepim-users (I am thus cross-posting!), but if I read you correctly you're describing *expected* IMAP behaviour. It's a gmail quirk that their email labels (via the web UI) show up as email folders. A priori you cannot *move* a message from "All Mail" to any other folder (the action will be a *copy* instead). I know that's not a bug in KMail but I would also not consider it a bug if the application had a workaround. Your issue sounds like something similar: someone saw a justification to implement a mechanism through which the *apparent* copies of a message in "All Mail" and wherever else you keep it can have different read statuses. It's also not completely impossible that Google are experimenting with a new feature. The more important question is thus how the message appears in the gmail web UI >in both folders!< . It'd also be interesting to know how the status appears in KMail on another machine (or under a different account). There was a time when I think the *flagged* status did not sync back properly to GMail so a message flagged on one machine would not show up as such on the other. Or maybe KMail simply did not take remote changes to this property into account, so you'd also have to check how your KMail copy reacts to messages being marked un/read via the web interface; does the status change in KMail? R.
Re: KDE Neon and sound
On Tuesday May 03 2022 21:08:12 Patrick Nagel wrote: >Correction: > >> This is how I solved it: I created a file 'audio_disable_powersave.conf' >*in the directory /etc/modprobe.d* >> with the following single line content > >> options snd_hda_intel power_save=0 You can test this out without rebooting by checking (and if necessary modifying) /sys/module/snd_hda_intel/parameters/power_save and/or /sys/module/snd_hda_intel/parameters/power_save_controller . On my system these appear to be off (0 and N, respectively) by default. Or because I already discovered the setting via a control panel at some point and hoped it might decrease the lag between an event and the alert sound it causes. R
Re: Akonadi won't start
On Tuesday April 19 2022 14:50:28 Mike Diehl wrote: >On Tuesday, April 19, 2022 2:37:43 PM EDT Paul Brown wrote: >> On Tuesday, 19 April 2022 18:25:58 CEST Mike Diehl wrote: >> > Hi all, >> > >> > I've been using kde on this machine for several months, now. But >> > suddenly, >> > akonadi won't start: Hi, You may get more insider information if you ask on ; the KDE PIM devs are there too. R.
Re: Question about screen resolution in plasma 5 using x11 and a 4 K monitor arrangement.
On Sunday March 13 2022 09:55:31 Stakanov wrote: >Obviously the problem is not the graphics card, nor the monitor and the >monitor is branched with DP on DP. >The other monitor is a smaller Medion MD20666 which runs with 60 Hz on its >native resolution (1920x1080). Have you tried using each monitor separately? It's my experience that XOrg doesn't always detect OR present the full range of resolutions. A typical one being missing from the list is the quite common 1366x768 resolution of (democratically priced ^^) small screens. The solution is to define the resolution you want via xrandr and then add it to the monitor where it's missing: For instance, to ensure I can run a distro on an external drive in VIrtualBox without messing up my desktop layout: > xrandr --verbose --newmode "1366x768" 85.25 1366 1440 1576 1784 768 771 781 > 798 -hsync +vsync > xrandr --verbose --addmode Virtual1 "1366x768" Note that this apparently works at the screen level, but I presume the resolutions you mentioned were just that, not the union of resolutions of both screens. I also don't know how to obtain the various numbers other than by querying xrandr on a system that does recognise the resolution you're looking for. R.
Re: May 30th 2022, Google and IMAP
On Friday March 04 2022 16:45:04 A. F. Cano wrote: >This assumes that they let you open ports. Obviously for your camera it >worked, but I encountered problems. Then I configured the cable >modem as a bridge and all problems disappeared. Yes, every ISP modem/router I've ever had had the possibility to open specific ports. However I'm not certain any had the possibility to be configured as a bridge, apart from opening all ports or disabling the firewall. Either way this approach is currently not feasible for me but I'll keep the possibility in mind. R.
Re: May 30th 2022, Google and IMAP
On Friday March 04 2022 14:22:27 A. F. Cano wrote: >If you run the FreedomBox in a standalone box as the gateway/firewall, >like I do, and the email server is on it, it is not in your lan. The I don't know where you are, but here internet connectivity is provided through modem/routers that are provided by the ISP, and have the firewall etc. installed. It's their property running a firmware they provide and keep up to date, and that makes updating (and hopefully also breaches and the like) their problem as long as I don't do anything too wild with the configuration. With the default set-up the entire LAN is invisible from the outside world, except for devices that know how to tunnel to the outside (I had a surveillance camera for our puppy that did this). TBH that suits me just fine! It turns out that after activating 2-factor auth you indeed get the possibility to define app-specific passwords. Just like with Apple's iCloud you can use those pws to log in with your username. And as with iCloud, there's nothing app-specific in these passwords; you can define one of them and use it with each and every app you want, from each and every host you have. The only additional security you get is that these are random, strong passwords (but if you define 10 of them that increases the chance to brute-force one by a factor 10, I think). Well, that, and someone who does guess the pw cannot lock you out, I presume. I did not (yet) get a warning email on the account where I had that enabled, so we'll see on May 30th if this continues to work. R
Re: May 30th 2022, Google and IMAP
On Friday March 04 2022 09:31:18 A. F. Cano wrote: >Well, not remote and not managed for you, but the next release >(migrating to stable in a few days) of FreedomBox >(https://www.freedombox.org), is finally adding a mail server. That would mean running a server that you need to be able to access from wherever you want to read your email? Not really what I'm looking for, I'd rather have something that is either provided by a 3rd party or that I can run on my laptop (Mac or Linux). >I am curious, isn't the filtering and sorting into folders a function of >the client? Doesn't Kmail do that? KMail can, but if the server can do it you don't have to set up the filtering rules in every imap client you might use (and having 2 or more running at the same time might be problematic with that). >One of the reasons I'm not using gmail any more is the constant changes >and the collection of information (in the name of security) by google. GMail only gets information from me that I don't mind exposing to them. As I said, email is inherently insecure. Having to expose a server in my LAN is a much bigger potential security risk, I fear. On Friday March 04 2022 16:01:37 Patrick Nagel wrote: >I guess you're referring to Google forcing OAuth instead of username/password >authentication? Care to post a link to that announcement? Activate "insecure access" and you'll get an email... Here are the contents: https://arstechnica.com/civis/viewtopic.php?f=16=1482849=40716726#p40716726 >Pretty sure there is a way to make KMail4 work as well with OAuth. Probably >something like https://github.com/oauth2-proxy/oauth2-proxy should work. But >then again, what's wrong with KMail5? (it can even insert emojis, see? ) There's probably nothing wrong with KMail5 if you're one of the people for whom it never acts up, and if you don't mind the fact it uses QtWebEngine which is vastly overkill for rendering simple html email. When they refused even to consider supporting QtWebkit as well I more or less vowed I would never upgrade (also because going back from an upgrade is basically impossible). There's also the fact that I have a few custom mods in KMail, like an option not to select any message when changing to a new folder, and that I currently build and package all my KF5 stuff myself. Which would be a lot of work for KDEPIM5... I did remember though that I probably disabled the insecure access from a secondary account and configured KMail4 on one of my machines to work with that. Possibly because this was announced a (long) while ago. I'll just have to find which machine and which account, plus remember how I did it. R.
May 30th 2022, Google and IMAP
Hi, [Apologies if you get this twice!] So it appears that on May 30th Google is going to cut off "good old" IMAP access to GMail (as if email is such an inherently secure medium that you really need that additional login security...). If I hadn't come to depend on having around 15Gb of free remote email storage with (remote filtering into) lots of folders I'd jump ship now, but I wouldn't really know where. I suppose KMail5 will continue to work, but not KMail4 which I still vastly prefer. I know some of you use claws as a fallback ... what options will there be to continue to use a traditional imap client with GMail? I suppose it should be possible to write an interface that connects to GMail via a sanctioned method and presents itself as a standard IMAP server to email clients. Maybe such a thing exists already? Thanks, R.
Re: how to autohide the panel?
On Wednesday March 02 2022 10:25:45 Peter Humphrey wrote: >Wouldn't it be easier, and save all this difficulty, if the logic were changed >so that the panel, once hidden, stays that way until ... Simpler maybe, but that would a) require all the devs who ever worked on this to eat their pride and b) assume that everyone appreciates the simpler behaviour. This list isn't very active and already there were a few people who stated that "it works for them"; impossible to tell if they represent the consensus out there, or we. The safe approach would be to add the simpler logic as an option, just like "focus follows mouse" has complexity options in KWin. R.
