Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tue, Sep 12, 2023 at 10:37:51PM +0200, René J.V. Bertin wrote: > 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. Apparently the "System Load Viewer" is obsolete. I couldn't make it work. But there is a very similar plasmoid called "System Monitor Plasmoid" that works. WHen downloading it the system gave me a choice of versions. I chose the latest: 2.7 and it works. This is the version by Barry Strong (thanks Barry!). Maybe the old "System Load Viewer" should be removed? Augustine
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tue, Sep 12, 2023 at 10:37:51PM +0200, René J.V. Bertin wrote: > 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. Found a bit more: it appears that ksysguard has been obsoleted and is replaced by ksystemstats. Not surprisingly ksystemstats was not installed. As soon as I did "Individual Core Usage" started working. "System Load" and "SysMon" still don't work. Does anyone have some clue as to what additional package might need to be installed? or is this a fundamental incompatibility of those 2 plasmoids and Debian 12 and testing? Thanks. Augustine PS: I don't see my responses in the list. This is the only list I subscribe to where this happens. Does this happen to everybody? Is there a setting that does this? Can I change it?
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Thu, Sep 21, 2023 at 01:09:36PM +0200, René J.V. Bertin wrote: > > > 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? That did it. After I uninstalled pulseaudio and a few other pulseaudio related packages that were producing dependency conflicts. > Strange that that package isn't installed btw! There are alternatives > to ALSA but AFAIK they're older and presumable less advanced. Might be because of the 2 upgrades I did in short order: Debian 11 to 12 and then 12 to testing. Things that should have been cleaned up obviously weren't. Anyway, now KDE sees the audio devices. Thanks for the guidance. Augustine
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Thu, Sep 21, 2023 at 12:40:30AM +0200, René J.V. Bertin wrote: > 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, On Debian testing the PA daemon is not running. What is running is: $ ps aux | grep pipewire afc 1496 0.0 0.3 120476 14592 ?S 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. I see that there is a package called pipewire-audio-client-libraries, whose purpose is: 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. But it depends on pipewire-alsa which, even after selecting it, aptitude refuses to install. It fixes the dependency problem by not installing either. > If you have already and it still doesn't work ... I'm out of ideas. Looks like this is a problem caused by the transition from pulseaudio to pipewire and KDE on Debian still doesn't have it strightened out. Thanks for the info. I'll keep at it. Augustine
Re: UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Wed, Sep 20, 2023 at 05:57:46PM +0200, René J.V. Bertin wrote: > 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? 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. play .wav goes through the motions but no sound comes out. It's probably sending the audio to the dummy device. The audio plasmoid that was installed by default shows a red line through the speaker icon. Kmix doesn't show that, but only shows the dummy device.
UPDATE: After upgrade to Debian testing (trixie/sid): plasmoids still don't work, KDE doesn't find sound devices.
On Tue, Sep 12, 2023 at 10:37:51PM +0200, René J.V. Bertin wrote: > 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. In an attempt to see if this problem disappeared in testing, upgraded this computer to testing (trixie/sid). The plasmoids still don't work and KDE doesn't find the sound devices. The plasmoid only has the dummy device. This is not a matter of the driver (snd_hda_inte). Playing audio files as root from a console works fine. Anything else I could try to figure this out? Thanks. Augustine
Re: After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
On Tue, Sep 12, 2023 at 10:37:51PM +0200, René J.V. Bertin wrote: > 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`. Mmm... This seems geared to temp sensors, but here's the output: $ sudo sensors-detect # sensors-detect version 3.6.0 # System: Gateway NV79 [V1.05] (laptop) # Kernel: 6.1.0-12-amd64 x86_64 # Processor: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz (6/37/2) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): yes Module cpuid loaded successfully. Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors...No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor...No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): yes Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): yes Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): yes Using driver `i2c-i801' for device :00:1f.3: Intel 3400/5 Series (PCH) Module i2c-dev loaded successfully. Next adapter: SMBus I801 adapter at 3000 (i2c-0) Do you want to scan it? (YES/no/selectively): yes Client found at address 0x50 Handled by driver `at24' (already loaded), chip type `spd' (note: this is probably NOT a sensor chip!) Client found at address 0x52 Handled by driver `at24' (already loaded), chip type `spd' (note: this is probably NOT a sensor chip!) Next adap
After upgrade from Debian 11 to Debian 12: plasmoids stopped working.
The problem computer is a Gateway NV79 laptop, with an Intel i3 CPU. lshw: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz 4 cores. Specifically, I'm happily using the "System Load" plasmoid on Debian 11 on another i3 (Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz) and just installed the "Individual Core Usage" plasmoid, which also works fine. But neither work on the NV79 after upgrading from Debian 11 to Debian 12. It seems they can't find the proper sensors. On the working i3, "Individual Core Usage" -> "Sensor Details" show CPU 1 CPU2 CPU3 CPU 4. On the non-working one, no amount of clicking on the "Sensors" field produce anything. On the non-working NV79, neither plasmoid produce any output. Debian 11, per aptitude (kde-full) reports 5:111 Debian 12, per aptitude (kde-full) reports 5:142 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? Thanks. Augustine
Re: Long links in konsole, truncated at EOL when hovered or clicked.
On Sat, Dec 24, 2022 at 09:19:46PM -0800, Dave Close wrote: > "A. F. Cano" wrote: > > >Unfortunately, there seems to be no way to prevent mutt from inserting > >\n between long links, even after using ... > > I understand the objective is to correctly process a received message. > But what does mutt do if the link is contained within angle brackets > (<>)? I've found that some MUAs handle those better. If it works for > you, you could try to get your correspondents to conform. (Good luck.) That was easy to test thanks to the edit function in mutt. Added the < and > but it made no difference. >From this thread: https://www.mail-archive.com/mutt-users@mutt.org/msg55201.html 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. Thanks for the hint. Augustine
Re: Long links in konsole, truncated at EOL when hovered or clicked.
On Sat, Dec 24, 2022 at 09:19:41PM +0100, René J.V. Bertin wrote: > 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. It is the line wrapping that mutt puts in. If I copy/paste the link as displayed by mutt into a file and then cat it, I see the same behavior I see in mutt: incomplete link. If I edit the file and join the 2 lines, cat displays the one-line link and then selecting it works as it should. Unfortunately, there seems to be no way to prevent mutt from inserting \n between long links, even after using set nomarkers set smart_wrap=no which only get rid of the '+' at the befinning of the second line, but the \n remains, as shown by od -c. No combination of reflow_text, reflow_wrap, smart_wrap alters the breaking up of long links, only maximizing the konsole so that the whole link is on one line works. Maybe I haven't found the magic combination of options to achieve this, if it is at all possible. > FWIW, this sort of thing is why I stopped using pine after resisting for as > long as possible. > > R. It would be nice if mutt recognized URLs and didn't add the \n, but I don't see any such option in man muttrc. Thanks for replying. Augustine
Long links in konsole, truncated at EOL when hovered or clicked.
Hello, I have konsole mouse behavior -> Miscellaneous -> "Underline links" and "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. I have tried "Allow escape sequences for links" and in the "Text interaction" tab I have added \n to the "Word characters:" but it doesn't change the behavior. If I maximize the window so that the long link fits in one line, I can click it successfully, but I'm trying to avoid that extra step. What option am I missing so that konsole recognizes the whole link, no matter the number of lines it occupies? Thanks. Augustine
Re: Akonadi won't start
On Thu, Apr 21, 2022 at 04:45:44PM -0400, Mike Diehl wrote: >... >So, what could I be missing? Maybe your FS has been remounted read-only as a result of disk errors? Check with "mount", though I would expect more errors if this were the case.
Re: May 30th 2022, Google and IMAP
On Fri, Mar 04, 2022 at 09:18:42PM +0100, René J.V. Bertin wrote: > 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 Same here. > 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 In router mode, that is the case here too. I ran the FreedomBox "behind router/in NAT mode" (this is a setting in the FreedomBox) for a while, but encountered issues with certain apps. The ISP doesn't always have your flexibility and convenience in mind. I hated it when things wouldn't work as expected and I had to waste time figuring out that they were blocking this or that, and sometimes with an update of their software the behavior would change, and I have no choice about their updates. > 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! 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. Even in this mode, the FreedomBox makes my internal networks invisible to the outside but I can initiate connections from the inside, which is how I use fetchmail for instance. I like the fact that all the configuration (in the FreedomBox) is open source, transparent, with good support from the developers via the mailing list, and not subject to corporate interests that might conflict with what I want to do. > ... A.
Re: May 30th 2022, Google and IMAP
On Fri, Mar 04, 2022 at 05:35:54PM +0100, René J.V. Bertin wrote: > 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, Fair enough. If you wanted to have your server accessible 24/7 you'd have to have it on all the time. For email you'd get warnings or bounces if that weren't the case. > I'd rather have something that is either provided by a 3rd party or that > I can run on my laptop (Mac or Linux). FreedomBox is a bootable Debian on an SD card with a web interface, it can run in a virtual machine on your laptop or stand-alone in a server box. The latter could be in a variety of cheap hardware as can be seen here: https://www.freedombox.org/download/ I run it on a PC engines APU1D4, with 3 network interfaces, so it is also my firewall between the cable modem and my internal networks. Still, if you ran it in a VM on your laptop and turned it off regularly, you'd still get warnings/bounces. > ... > 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. 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 FreedomBox has good secusity and privacy, and many other apps. I use just a subset of the apps available: privoxy, a matrix server for video conferencing, the meta-search-engine searx, the radicale server to sync all contacts/calendars/todo lists with Kaddressbook, Korganizer, phones, ikiwiki blog, chat servers (ejabberd and mumble), the Sharing app to have files accessible for download, syncthing, gobby server for shared editing, and there are many more that I haven't tried yet. >...
Re: May 30th 2022, Google and IMAP
On Fri, Mar 04, 2022 at 12:53:35PM +0100, René J.V. Bertin wrote: > 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. 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. This project is designed to decentralize the internet and provide the usual cloud services on inexpensive hardware with easy setup and no maintenance. It is steadily being improved. I've been running one for years and couldn't do without it. > 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? The filtering into multiple folders I do with xbuffy and procmail. but I don't use Kmail. The server part at least would be handled by the FreedomBox. I am curious, isn't the filtering and sorting into folders a function of the client? Doesn't Kmail do that? > 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? 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. I want to set up something (like email), get it to work and then forget about it. I hope this helps somehow. Once I set up the FreedomBox mail server, I plan to try it with Kmail, in addition to my regular fetchmail/procmail/xbuffy/mutt setup. Augustine
Re: Focus stealing behaviur.
On Sun, Jan 24, 2021 at 09:14:25PM +0100, René J.V. Bertin wrote: > On Sunday January 24 2021 13:48:18 A. F. Cano wrote: > > >The settings page also has a check box under "Multiscreen behavior" to > ... > If you really wanted separate focus on different screens you'd need > separate keyboards and mouses as well. I call that different terminals ;) Ah... Ok. > >What the ideal behavior would be is that an unrelated program could not steal > >focus from the curently active window (the DVR in my case) but yet when a > >program pops up a new window (by mouse click or keyboard shortcut) the new > >window will have focus. > > > >Is this possible? > > It would probably be possible to set a specific window manager hint on > windows that are opened by explicit user actions, which window managers could > then use to ponder focus stealing prevention. Who knows, maybe such a feature > already exists in other window managers. > > There are alternative solutions, like giving back focus explicitly to the > application (and window) that had it; this could be done by charm for its > alerts. Mmm... Charm has limited options, but one is "Enable idle detection", which I unchecked. No more pop-ups that steal focus. > Have you played with focus-follows-mouse; with that you can set things up > such that the window that has the mouse cursor usually (or always) has focus. That is another option, given that mythtv blanks the mouse pointer after about 5 seconds when it's on it, but getting rid of the original problem (the charm pop-up window) seems more elegant. > >Shouldn't there be a difference between totally unrelated > >programs stealing focus and a window that appears in response to a mouse > >click > >in the same program? > > Possibly, but the window manager needs additional information to tell the > 2 apart, and sometimes you don't want that behaviour. A kwallet password > dialog should always open in front, for instance (and those are posted by > the kwallet daemon, so not by the application that needs the password). Ah yes. I have encoutered that issue. It was a long time ago so I don't remember all the details, but a window requesting a password popped up, grabbed focus and wouldn't let go. There was no option to make it go away without entering the proper password, which I didn't remember, and clicking on any other window wouldn't transfer focus, so the system was unusable. I couldn't even go to a konsole to shut down. Not sure how I got out of that. Maybe I remembered the password eventually, and after that the system remembered. It was after some upgrade, possibly, and that behavior might have been corrected soon after. > ... In any case, thank you very much for taking the time to respond. Augustine
Focus stealing behaviur.
Hello, One particular application (Charm time tracker) has an activity time out that pops up a window. This window then becomes the active window and steals focus from any other window on the desktop, which consists of 4 screens, one of which is the tv on which MythTV (DVR) is running. This means that the remote stops working. Quite annoying. I found System Settings -> Window Management -> Window Actions and Behavior -> Focus tab, which provides the "Foxus Stealing Prevention" drop-down menu. None, Low and Medium don't prevent this behavior. High does, but it has an unintended consequence (at least from my point of view): any window opened by any application in response to a mouse click, now doesn't have focus, requiring another mouse click to raise it. Also annoying. The settings page also has a check box under "Multiscreen behavior" to have "Separate screen focus" but it doesn't do what it seems this implies. Even when checked, a popped up window still steals focus, even from another screen. What the ideal behavior would be is that an unrelated program could not steal focus from the curently active window (the DVR in my case) but yet when a program pops up a new window (by mouse click or keyboard shortcut) the new window will have focus. Is this possible? Shouldn't there be a difference between totally unrelated programs stealing focus and a window that appears in response to a mouse click in the same program? This is on a totally up-to-date Debian 10/stable. Thanks for any explanation or hint. Augustine
Re: Top of windows too tall and apparently non-adjustable in kde 5.
On Mon, Apr 30, 2018 at 06:33:02AM +, Duncan wrote: > ... > Keeping in mind that the plasma system settings UI is undergoing some > changes ATM[1], and I'm running the live-git version so what I see and > describe might not /exactly/ match what you see... > > In Window Decorations I see two tabs, theme and buttons. Yes, same here. > On the theme/first tab each installed/available windeco theme is listed. > I know the UI has changed a bit here and can't remember the old one > exactly, but on the new one, there's configuration buttons for each theme > directly in the theme's visual mockup, so it's quite apparent each of > these buttons ONLY configures that specific windeco, not the others. As > I said I don't remember the old UI exactly, but I /think/ it had only one > configure-theme button, located near the top, with a dropdown-selector > for the windeco. Here it's at the bottom left. I had missed it. Thanks for pointing it out. > In any case, however the UI is laid out, the idea is each windeco has its > own separate configuration dialog. The default breeze windeco and the > kde4 default oxygen windeco each have somewhat complicated multi-tab > config dialogs, while plastik's dialog is rather less complicated, and Yes, and in plastik there's no button size like in others, but strangely I managed to reduce the height of the title bar by reducing the font size of the window title (to point size 8 bold). Now the height of the title bar is a lot closer to that of black square. > most of the others including blacksquare only have a single option in > their dialog, the button size option of interest here. > > IOW, all windeco config dialogs have at least the button size option, > with plastik's dialog having a couple other options as well, and breeze In this version, plastic doesn't have a button size option, but as I said above, the height of the title bar is affected by the window title font, up to a point. > and oxygen's dialog having so many options each that the dialog has > multiple tabs. > > But it's this single button size option that all windecos have that's at > interest here. Most windecos appear to have a hard-coded minimum height > configured, with button sizes below that not shrinking the titlebar > further, but those above it increasing the titlebar size. That's what I've observed with plastik. > And while most windecos seem to have that hard-coded minimum height set > to normal/medium, so smaller button sizes don't reduce the titlebar > height further but larger ones increase it... > > For blacksquare at least, either it has no such hard-coded minimum, or > that minimum is set to the smallest "tiny" button size. So it's possible > to get blacksquare's titlebar height far shorter than the others, because > it continues shrinking with the tiny button size, while most won't shrink > below the height at normal/medium button size, even when set to tiny! Blacksquare is still the winner for shortest height. > As for that button you removed, that configured on the second/buttons > tab, and the setting should apply no matter which windeco is chosen. You > should be able to drag buttons between the displayed "fake" titlebar and > the display of all possible buttons below it. To get that button back, > then, you /should/ be able to simply drag it from the lower icon > section, back up to the fake titlebar, which after hitting apply should > have it show up on the real titlebars as well (tho some buttons won't > show up all the time, context help, for instance, only shows up in plasma/ > kde/qt-based app windows with context help available). Thanks for this clarification. I now see the cause of my confusion with this. In the display of all possible buttons I see text for "Menu" "On all desktops" "Minimize" "Maximize" "Close" "Context help" "Shade" "Keep below" and "Keep above" but only "Menu" and "Close" have the associated symbol: "X" for Close and ":>" (but with 3 dots in slight arc instead of the 2 dots/colon). There is no symbol for the others. When I drag any of the others to the fake title bar nothing shows up there but if I drag the mouse over the blank fake title bar the cursor changes to the hand with pointing finger, indicating that there is something to click or drag. Since I presume the fake title bar reflects the real one, I see the hand cursor in 2 blank spots right next to the "X" (Close) which I presume are the Maximize and Minimize buttons. Any other buttons I drag to the fake title bar don't show up but the mouse changes when I go over the invisible button just dragged. I can also drag it back out of the fake title bar, so at some level the system knows the buttons are there even though they're invisible. If you actually see the symbols for all the buttons, it's probably a bug that has been fixed in your version. Maybe I'm missing some font package, but it should have given an error if this is the case. > Also note
Re: Top of windows too tall and apparently non-adjustable in kde 5.
On Mon, Apr 30, 2018 at 06:56:24AM +, Duncan wrote: > Duncan posted on Mon, 30 Apr 2018 06:33:02 + as excerpted: > > >... > Well, since I was already staring at it, I /did/ just modify mine a bit. > > I wanted yellow text for the active titlebar, so (standard 8-bit rgba > values): > > ActiveTextColor=255,255,0,255 Did this too. Much easier to read. Thanks! > ... Augustine
Re: Top of windows too tall and apparently non-adjustable in kde 5.
On Sun, Apr 29, 2018 at 06:49:33AM +, Duncan wrote: > Your reply reminded me... > > Depending on the selected window decoration, icon-button size may > determine titlebar height. > > The breeze window decoration does have a button size option[1], and when > I select it[2], and while setting it "tiny" doesn't seem to do anything, Mmm... Where would this button size option be? The "Buttons" tab in "Window Decorations" only has drag and drop to add/remove buttons. This is true of all the themes I've tried so far: Plastik, Breeze, Air Oxygen and blacksquare. I've managed to remove the round button on the left of the title bar (in blacksquare) by dragging it out and I can't put any buttons in it. Clicking on "Defaults" only switches back to Breeze. > I suppose because my text is then bigger than the icons, setting it > "Large" or "Very Large" *DEFINITELY* increases titlebar height (and > returning it to medium or lower reduces it again). > > So try playing with button size in breeze or oxygen win-deco config, and > see if that helps. > > Of course you can also try some of the windeco options from the kde > store. While it won't be to everybody's liking, one reason I ended up > with BlackSquare after trying a number of others is because it /is/ quite Yea for blacksquare! It has the narrowest title bar I've found so far. Too bad it cannot be configured by color, but then it wouldn't be /black/square :-) > short. The only config option it has is button size, but with that set > to tiny, it really does reduce the titlebar height from normal, giving me > one of the shortest titlebars of any I've tried, which in turn means more > room for actual window content. =:^) That's the idea, but where is this option? From the package manager I gather I have kde-plasma-desktop 5:92 (Debian 9.4) and from the "help" menu in konsole I see that the KDE Frameworks is 5.28, Qt 5.7.1. Maybe in this version the button size doesn't exist yet. > The effect is enough that if I were seriously put off by the color or > other elements of the windeco, I might actually try hand-editing its > config files to change them, or alternatively, try hand-editing other > windeco's files to get the shortness of BlackSquare with tiny buttons, > but as it happens, I'm OK enough with the color and etc not to bother. In what config files could I find these options? Thanks for taking the time to reply. The size of the blacksquare title bar is acceptable. Maybe it's time to get to more important issues. In the grand scheme of things, the height of the title bar is not such tall order (pun intented :-). > --- > [1] Well, the live-git version I built a few days ago does anyway, but > from memory the option has been there in the default windeco since at > least oxygen in kde4, and it's still in oxygen now. > > [2] As I said I've been running BlackSquare, from the kde store aka the > get new decorations button. Augustine
Re: Top of windows too tall and apparently non-adjustable in kde 5.
On Tue, Apr 24, 2018 at 10:48:34AM +0100, Peter Humphrey wrote: > On Sunday, 22 April 2018 21:15:00 BST A. F. Cano wrote: > > > I've been struggling to configure the look of window decorations, > > ... > > I can't help with adjustability, but after a lot of fiddling about I've come > up with a satisfactory arrangement. This is what I've set in system settings: Thanks for confirming that I had essentially reached the same look and feel. > Workspace theme - breeze > Desktop theme - breeze These two match my setup. > Colours - Norway This looks better. Changed from Oxygen to Norway. > Fonts - dejavu, all two point sizes bigger than the default for my ageing eyes Since it seems to be impossible to narrow the title bar, replaced the "Window title" font to "DejaVu Sans 10" bold. At least now the tall title bar doesn't seem as big. > Applilcation widget style - fusion This doesn't seem to affect anything I can see at the moment, still, it's installed. > Window decorations - plastik That's what I had. > Gnome GTK themes - clearlooks and breeze, dejavu sans mono 10 I had breeze. > HTH. You may be able to pick something out of it to suit. Thanks. Now I know it's nothing that I have overlooked. Augustine
Re: Top of windows too tall and apparently non-adjustable in kde 5.
On Tue, Apr 24, 2018 at 09:27:49AM +, Duncan wrote: > A. F. Cano posted on Sun, 22 Apr 2018 16:15:00 -0400 as excerpted: > > > [ about titlebar height ] Thank you for a very informative post. > The size of the titlebar, along with whether it honors the appropriate > color settings, font sizes, etc, is controlled by the window decoration. > Some of them don't use the normal settings, unfortunately, and I know for > sure that the window decoration setting affects titlebar height and color > because I'm using a window decoration (BlackSquare) from the kde store, > that dramatically changes both. Obviously not an easy problem as there is text whose size needs to be taken into account as it can be configured separately. The "Window Decorations" page has a "Border Size" drop-down menu, in which I've selected the smallest option possible: "Tiny". This affects the other 3 sides but not the title bar. Maybe another configuration drop-down menu for "Title Bar Height" with similar options would do the trick, but as that's a new feature and development seems to be going in other directions, I'm not holding my breath. > FWIW, only the plasma5-default breeze and kde4-default oxygen appear to > have significant decoration configuration -- many only have button size. Yes, that's why I'm using breeze. > Also, AFAIK, there's no general option for the (IIRC global) stippled > titlebar effect as there was in kde4, that I see on your kde4 > screenshots. =:^( I was afraid of that. Thanks for confirming. > My /guess/ is that with plasma-on-wayland (which I have yet to personally > try) being the development focus now (tho it's said to still be rather > rough around the edges and there continue to be many changes in live-git, > which I run, to bring plasma-wayland to plasma-x11's functionality and > polish level), and with a "wayland-first" policy, there may be no easy > way to get wayland to do some of these things (at least not yet, keep in > mind how young wayland itself is compared to X), and if they hadn't yet > ported a feature from kde4, it likely won't appear in plasma5, wayland or > X, until wayland supports it. > > Of course the other big issue for may of us, including me, is that > plasma5's breeze default is "flat" everything -- apparently everyone has > jumped on google's flat "material design" and etc bandwagon, and while > the kde4-default oxygen still has /some/ 3-D features, for instance on > the widget style, it's now considered 90s/last-century, and the "flat- > earthers" are running away with things, so some of the 3-D features > simply aren't, and apparently won't, make it to plasma5. Too bad. > FWIW I miss the 2-color-fade windecos, too. Oh, well... Indeed. Thanks again for your detailed reply. Augustine
Top of windows too tall and apparently non-adjustable in kde 5.
Hello everyone: I've been struggling to configure the look of window decorations, specifically the top, on Debian 9/Kde 5.28.0 (current stable) the way I had them on Debian 7/Kde 4.8.4. Unfortunately Kde 5 is so different that I can't figure out what combination of theme, style, color, etc... I need to match what I had. Specifically, I would like the height of the frame at the top of the windows to be less tall, but I can't find any way to do this. I can also not get the font size to change. I also liked the 3-D look that was possible in Kde 4.8.4 that I can't find any way to reproduce on 5.28.0. I include 3 small screen captures: debian-7-kde-4.8.4-top.jpg shows how I would like it to look. debian-8-kde-4.14.2-top.jpg shows the best approximation I could do on Debian 8. debian-9-kde-5.28.0-top.jpg the closest I could come in Debian 9. Note that the latter has no 3-D look and the top is way too tall. The "import " command I used to capture the images generated all kind of garbage lines on Kde 5.28.0 (Debian 9 stable). The same command worked just fine in Kde 4 on the other 2 computers. The different sizes of the images is due to the different resolutions and size of monitors on the 3 computers, the important issue is the relative size of the window frame and the font size in the frame and of the menus. The konsole windows whose tops I captured have the same apparent size on all 3 screens. It seemed that Kde 4 was much more configurable, or Kde 5 is trying to do more auto-magically, with results I don't know how to change. I would like to upgrade the older 2 computers to Debian 9 but first I want the Debian 9 desktop to look like the Debian 7 one. Can anyone tell me what I need to do? Thanks.
KDEconnect on 2 different networks: totally impossible?
Hello, I've been trying to get KDEconnect to work across a router and it appears to be impossible. My internal network, where the linux KDE is, is at 192.168.x.0, the android phone with KDEconnect is at 192.168.y.0. Traceroute reaches the phone so it's not a routing problem. I have found this: https://www.addictivetips.com/ubuntu-linux-tips/install-kde-connect-on-linux/ and it says (in the Configuring KDE Connect section): Note: pairing WILL NOT WORK if your Android device isn’t on the same network as your PC. Be sure that wifi is working before connecting. I have not been able to find any instructions on configuring either the android app or the linux end. At the android app, if I "Add devices by IP": 192.168.x.a it still finds "No devices". Running kdeconnect-cli -l on the linux machine returns "0 devices found". The default route is set properly on the phone. The route to 192.168.y.0 is set properly through the router at the internal network. Is there some configuration file somewhere that I could change so that KDEconnect works across the router? Or is this impossible? For security reasons I don't want wifi on the internal network. Any help will be much appreciated. Thanks! Augustine
Korganizer doesn't show CalDAV calendar. No errors, just no calendar.
Hello, I exported to vcs format from Korganizer 4.4.11 (that does not support CalDAV) and placed the resulting file in a Radicale server. Then, set up multiple versions of Korganizer (5.2.3 - 2 of them, 4.14.1) to access the "DAV groupware resource". Entered the proper user, password, URL (manual configuration) and when I was done all instances fetched the collections and they now report "Ready". After clicking the check mark for the calendar: nothing. If I copy the file manually to ~/.kde/share/apps/korganizer/std.vcs and then add a calendar that "Loads data from an iCal file" all entries show up as they should. I've spent hours searching for answers but all I could find was the standard set-up procedure and no solution to this actual problem. I have also set up the CardDAV file in the Radicale server and Kaddressbook finds it, reads it and displays it just fine. Korganizer 5.2.3 on Debian Stretch/9 (current stable) with KDE Frameworks 5.28.0, Qt 5.7.1 (built against 5.7.1) and the xcb windowing system. Korganizer 4.14.1 on Debian Jessie/8. What am I missing? I have gone over the bugs for Korganizer (at bugs.debian.org) but didn't find any about this problem. Is anyone else uing Korganizer with CalDAV? With Radicale specifically? Any suggestions as to what to try/do to figure what is happening? Thanks. Augustine
Re: Configuring/compiling gbuffy on modern Debian systems.
On Mon, Aug 28, 2017 at 01:24:40AM +, Duncan wrote: > ... > And there's all sorts of other mail notifiers available, so the question > is, why are you trying to install something that old, unsupported, > security-vulnerable and inconvenient to install, when there are so many > other alternatives available? What's so special about gbuffy that you > /must/ use it instead of some other alternative that's still available in > your distro's repo for a far simpler install? It was exactly what I wanted. A simple list of buttons that I can have in a corner of the desktop and when I click the one that represents the list I want to read it launches a konsole window with mutt in it. > FWIW, the gbuffy descriptions I could google said similar to xbiff/ > xbuffy. On gentoo (which I use) simply doing a package search, including I've installed or looked over all the packages you mentioned, but only xbuffy gives me that interface, so it looks like that's what I'll have to go with, even though the font looks horrendous compared to gbuffy, the config file is totally different and I'm still having issues getting it to behave the way gbuffy did. Some of the issues really look like bugs, such as starting mutt in send mode in some cases, even when given a mailbox file or doing the same when what it should do is open the main incoming mailbox. I'll have to make sure it's not an issue with my config file before filing bug reports. > description, on "biff", returns a number of alternatives, some console, > some X-based. Debian is said to have a larger package repo than most > distros so it's likely to have these and more: > > * kbiff (kde-based, making it the actual on-topic one =:^) Interestingly, this one is not in Debian. > * gnubiff (gtk3-based, with a gtk2-based version also available, likely > the most direct actually still available in the repo alternative to > gbuffy) The gnubiff window is way too big and obtrusive to keep open. > * xbiff > * hap (terminal-based biff replacement) > * asmail (similar to xbiff, so X-based) > * wmbiff (windowmaker dock applet) All these don't have the simple one-button-per-mailbox interface I want. > ... In any case, thanks for replying. I'll keep trying to configure xbuffy to behave like gbuffy did. Augustine
Configuring/compiling gbuffy on modern Debian systems.
Hello, Gbuffy was removed from Debian quite a few versions ago, not sure why but I'm still using it on my Debian 7.11 system. To install it I had to manually install gtk 1.2 and whatever other dependencies were needed, from ubuntu packages IIRC. This page explains the old dependencies. The error I'm getting now is missing gtk-config when I run autogen.sh. https://askubuntu.com/questions/27994/installing-gtk-config-and-or-fsv-missing-gtk-dependencies Rather than installiing really old gtk 1.2 libraries and dependencies on the current Debian (9) I'd like to find out what needs to be done to gbuffy to modernize it to run on current Debian. The version of gbuffy that I found is 0.2.6. Is there a newer version out there? It uses autoconf to adapt to the system it will compile on, but running autogen.sh returns this: checking for GTK - version >= 1.1.11... no *** The gtk-config script installed by GTK could not be found *** If GTK was installed in PREFIX, make sure PREFIX/bin is in *** your path, or set the GTK_CONFIG environment variable to the *** full path to gtk-config. It appears that gtk-config disappeared with gtk 1.x. Is there a way to make autoconf/autogen.sh analyze the modern GTK packages and adapt configure.sh to work on modern systems? Or does the code need to be changed manually? After failing to configure properly for the gtk files/locations, it's no surprise that make fails: gbuffy.h:12:21: fatal error: gtk/gtk.h: No such file or directory #include Are the newer versions of the gtk libs compatible? Would code changes be needed in gbuffy? What is the better/least effort way to modernize an old package such as gbuffy for modern gtk/debian? I would think that messing with autoconf/ autogen would be the first option and code modifications to gbuffy proper only if absolutely necessary. Any hints/pointers gratefully appreciated. Thanks.
Problem solved (Qt4 plugin into Qt5 program)
On Sun, May 14, 2017 at 11:10:59PM -0500, Rex Dieter wrote: > A. F. Cano wrote: > > > #16 0xb43c42ed in _dlerror_run (operate=operate@entry=0xb43c3b80 > > #, args=args@entry=0xbff1cc50) at dlerror.c:163 17 0xb43c3c9e > > #in __dlopen (file=0x818e2da0 > > #"/usr/lib/i386-linux-gnu/vlc/plugins/gui/libqt4_plugin.so", mode=1) at > > #dlopen.c:87 18 0xa9c26368 in ?? () from > > #/usr/lib/i386-linux-gnu/libvlccore.so.8 > > it's not a Qt or kde bug, but a problem with your vlc install (I'd suggest > you contact your distro for support about it). > > (trying to load a Qt4 plugin into a Qt5 program is causing this crash). Thank you. It was indeed a conflict with vlc (from deb-multimedia) and the Systemsettings5 application (and the shared libs it uses) from Debian. Removing vlc and its dependencies fixed the problem and Systemsettings5 now works without crashing. Augustine
Tried to send a bug report and it got rejected. What's the problem?
Hi, I just tried to send a bug report and it got rejected. I sent it to the address specified in the automatically-generated bug report. The mail system : host postbox.kde.org[46.4.96.248] said: 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command) Strange... Does anyone know why this happened? Do I have to send it to a different address? Or does one have to be previously registered as a developer for bug reports to be accepted? In such a case, can someone forward this one to the right place? This is the bug report I sent. Application: systemsettings5 (5.8.4) Qt Version: 5.7.1 Frameworks Version: 5.28.0 Operating System: Linux 4.9.0-2-686-pae i686 Distribution: Debian GNU/Linux 9.0 (stretch) -- Information about the crash: Brought up System Settings to change the font size of the Window title. Clicked on "Choose" and then changed the size, then clicked ok. When I clicked "Apply" System Settings closed unexpectedly (segfault). I was trying this to try to figure out why changing the border size from normal to tiny does nothing. Application Style -> Window decorations -> Border size. Actually, changing to Large also does nothing. The widget style is Oxygen, Window Decoration: Plastik, GTK theme: Breeze. The crash can be reproduced every time. The video card is an AMD/ATI Radeon HD (CEDAR) 5450 with 3 outputs: HDMI, DVI and VGA, the video driver is xserver-xorg-video-radeon and there is an oddity that might have a bearing on these problems. [27.146] (II) RADEON(0): Output HDMI-0 using monitor section Viewsonic PT-810 UXGA [27.160] (II) RADEON(0): Output DVI-0 has no monitor section [27.177] (II) RADEON(0): Output VGA-0 has no monitor section [27.178] (II) RADEON(0): EDID for output HDMI-0 [27.196] (II) RADEON(0): EDID for output DVI-0 [27.213] (II) RADEON(0): EDID for output VGA-0 [27.213] (II) RADEON(0): Printing probed modes for output VGA-0 [27.213] (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [27.213] (II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [27.213] (II) RADEON(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [27.213] (II) RADEON(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [27.213] (II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [27.213] (II) RADEON(0): Output HDMI-0 disconnected [27.213] (II) RADEON(0): Output DVI-0 disconnected [27.213] (II) RADEON(0): Output VGA-0 connected As can be seen from this extract of Xorg.0.log the driver appears to think that the monitor is connected to HDMI-0 when in fact it's connected to VGA-0. Perhaps not surprisingly since the monitor connected to VGA-0 is old and dumb the video driver doesn't know that the specified Modeline (in xorg.conf) applies to the monitor connected to VGA-0, and only later does it appear to realize that the only output with something in it is VGA-0. I could only get the proper resolution manually by doing: # cvt 1600 1200 # 1600x1200 59.87 Hz (CVT 1.92M3) hsync: 74.54 kHz; pclk: 161.00 MHz Modeline "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync # xrandr --newmode "1600x1200_60.00" 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync # xrandr --addmode VGA-0 "1600x1200_60.00" # xrandr --output VGA-0 --mode "1600x1200_60.00" This Modeline is what is being specified in xorg.conf and the driver appears to be ignoring. The full xorg.conf is below. After the xrandr commands above, this shows up in Xorg.0.log: [ 2744.359] (II) RADEON(0): Allocate new frame buffer 1600x1200 stride 1600 [ 2744.362] (II) RADEON(0): VRAM usage limit set to 931014K So there are really 2 bugs here: The border size issue and the crash while changing the font size. And possibly a third one about the modeline in xorg.conf not being associated with the proper input. I'll supply more info or test specific things if asked. Thanks! -- Backtrace: Application: System Settings (systemsettings5), signal: Segmentation fault Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0xb230f800 (LWP 2792))] Thread 4 (Thread 0xaba09b40 (LWP 2796)): #0 0xb7739cf9 in __kernel_vsyscall () #1 0xb4a89b9b in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187 #2 0xaeddf51a in ?? () from /usr/lib/i386-linux-gnu/dri/r600_dri.so #3 0xb4a8427a in start_thread (arg=0xaba09b40) at pthread_create.c:333 #4 0xb5c49996 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110 Thread 3 (Thread 0xb0d50b40 (LWP 2795)): #0 0xb7739cf9 in __kernel_vsyscall () #1 0xb5c3fa9f in poll () at ../sysdeps/unix/s
