tde-devels

devels@trinitydesktop.org

3854 discussions

kmix mixer_backend.cpp
by deloptes 23 May '18

23 May '18

Hi, I looked yesterday in kmix code and I see this, which I think is a bit wrong, or I do not understand why close() is called even if open fails - we just want to know if mixer is valid. bool Mixer_Backend::isValid() { bool valid = false; int ret = open(); if ( ret == 0 && m_mixDevices.count() > 0) { valid = true; } close(); return valid; } regards

2 1

[ Re-send ] Explaining the process of adding bugs to next TDE release
by Michele Calgaro 22 May '18

22 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear all, re-sending without autocrypt option. There has been some reports of problems with SPAM filters discarding the previous email. If you already received the first message yesterday, please ignore this one and accept our apologies for the double sending. If you didn't get the original email, please read below. Cheers Michele, Slavek - -------------------- Dear all, we would like to explain the process of how bug reports get added to the next release bug list. As many of you probably know, there are some bug reports (that we call meta bugs) that serve as an index for bugs to fix or already fixed for the next maintenance and minor release. For example bug 2247 for R14.1.0, bug 2696 for R14.0.5 and bug 2885 for R14.0.6. These meta bugs are intended to list bugs that have been selected by the developers for the mentioned coming release, so we would like to invite all of you to refrain from directly adding bugs to those lists on your own. Instead you should first discuss with one of the developers (say Tim, Slavek or Michele) and if agreed, you can then add the bug to the discussed list. The reason for this logic (and limitation) is that if anyone just add bugs indiscriminately based on their own needs, those lists would grow out of control and out of what is physically possible to achieve with the development workforce that TDE has at the moment. We encourage all of you to participate in making TDE better, but please take note of the above procedure and try sticking to it as much as possible. On a side note, R14.0.5 bug list has been frozen and no other bugs will go into it unless critical of blockers. Of course, if a working patch is provided before the release of R14.0.5, we will consider that for inclusion. Feel free to provide your feedback on the process explain above Cheers Michele, Slavek -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEjhl1z5vbYB3YbFTiKnW3yore1c8FAlsD2uwACgkQKnW3yore 1c9tjw/9GTvzkZULvstj5VBBWjdJgfbkFQ+hDq8c7cRleKDqDwwK89uSdWshe6G7 VU5fwH82CScdF4itYr8GxZvwmZPcLtPvy83WLsEPL4pvC8oNoUZtHkqNniL8CP14 wfiUZcFuQvMa251i2KP0a1QBREd8xJhbj09obfz8YFa9sRQq0cauMgMDqxVOR+6U 0MU8CgTNplh49XWAjX9e5upwsgvqEb58e53h0XsYOn9aM+tvUOnCaKA83eIlICUe R6qt5807sKPbd2fXlpSNmtprPllwo/OKse/KUrCq0a3hifG64xapwub/S+ylGFpf Q2RfHxvKVUnSOyElNe7wYYjVhBv5qCcGO4mE7uR8TwsN3ta2vL226aw5rNv8Oarb nNKrjBO5Ey3F4wxhFI5ZNOmQqU6eqSvqwiT2lN2nVZ0CCuXGDScXcHo8gLM3j6la 9hSE/R8KouLtef2NyrFB1ObWtn2p4geAbQKVTyr9sQyS2K07Fyub2qeamdJeOyEV 1HtCzK+ot3QwD+jrTfQEigJGUitW4DPfy6iVLHBJz+B5kkOspYJq8Ks9EQh/Zya0 BNRKpqettm6RlOchuNHa7NWuPOyQUyyPnBI371+EsBAohZdgm0Nuis9RYVnoXII0 YO9F31g8dfY9rCTJ9CkFV4GpA6879uswTcxEf/AEod/m4ZdhnR8= =lSLn -----END PGP SIGNATURE-----

1 0

Explaining the process of adding bugs to next TDE release
by Michele Calgaro 21 May '18

21 May '18

Dear all, we would like to explain the process of how bug reports get added to the next release bug list. As many of you probably know, there are some bug reports (that we call meta bugs) that serve as an index for bugs to fix or already fixed for the next maintenance and minor release. For example bug 2247 for R14.1.0, bug 2696 for R14.0.5 and bug 2885 for R14.0.6. These meta bugs are intended to list bugs that have been selected by the developers for the mentioned coming release, so we would like to invite all of you to refrain from directly adding bugs to those lists on your own. Instead you should first discuss with one of the developers (say Tim, Slavek or Michele) and if agreed, you can then add the bug to the discussed list. The reason for this logic (and limitation) is that if anyone just add bugs indiscriminately based on their own needs, those lists would grow out of control and out of what is physically possible to achieve with the development workforce that TDE has at the moment. We encourage all of you to participate in making TDE better, but please take note of the above procedure and try sticking to it as much as possible. On a side note, R14.0.5 bug list has been frozen and no other bugs will go into it unless critical of blockers. Of course, if a working patch is provided before the release of R14.0.5, we will consider that for inclusion. Feel free to provide your feedback on the process explain above Cheers Michele, Slavek

1 0

Re: [trinity-users] konqueror freezing temporarily
by wo 16 May '18

16 May '18

On Wednesday 16 May 2018 08:15:56 Michele Calgaro wrote: > On 2018/05/15 01:54 AM, wofgdkncxojef(a)gmail.com wrote: > > On Monday 14 May 2018 18:57:49 Kate Draven wrote: > >>> On Monday 14 May 2018 11:38:57 Dr. Nikolaus Klepp wrote: > >>>> Am Montag, 14. Mai 2018 schrieb wofgdkncxojef(a)gmail.com: > >>>>> When the bug starts, it keeps freezing for several seconds when > >>>>> opening new folders. Then some how it goes away. Restarting konqueror > >>>>> doesn't help. > >>>>> > >>>>> Actually, i think if i try to select the url, it does the same thing. > >>>>> I didn't figure out what triggers it, it happens rarely, but when it > >> > >> does > >> > >>>>> it's very annoying, it takes many seconds to unfreeze. > >>>>> > >>>>> Anyone knows what triggers it and how to make it stop when it starts > >>>>> freezing up. > >>>> > >>>> Are you sure your hdd is OK? > >>>> > >>>> Nik > >>> > >>> No, it's not a hardware issue. > >>> The shell and the rest of the PC works fine. > >>> This happens if i simply try to select the url > >>> This is not all the time, just rarely. > >>> > >>> --------------------------------------------------------------------- > > > > no, it's not a hardware problem. > > the whole UI of konqueror freezes up. > > > > anyway, i reduced preloaded instances of konqueror to 0 > > so i just restart konqueror when this happens, and it goes away. > > I think.... I'll be sure when this happens again.... > > Given that this happens rarely, that's ok. > > It could be that i messed up the config somehow, or just hit a bug.... > > Occasionally I have seen something similar, with Konqueror becoming very > slow when changing folder (1-2 seconds waiting time, even for folders with > very few files inside). But I am often compiling and installing mod > versions for testing, so I always thought that could be a consequence of my > work. Usually closing/reopening Konqueror or reboot the PC always solved > the problem, as well as reinstalling a pristine Konqueror. > Perhaps something to keep in mind. If you see this again and you can find a > way to reproduce it systematically, please open a bug report and list how > to reproduce the bug. > > Cheers > Michele you send it to me, not the list :P There was a problem in the configuration. Now it's gone.

2 1

TQt buildkey with GCC >= 7
by Slávek Banko 16 May '18

16 May '18

Hello to all developers, following the arrival of GCC 8.x, I began to address the build key update in TQt. See the patch that was pushed for GCC 7.x: https://mirror.git.trinitydesktop.org/cgit/tqt3/commit/?id=71d8f1c4 Now I noticed that starting with GCC7, the compiler reports the version in a different way. Previously, gcc -dumpversion returned for example: 6.3.0. Now, regardless of the specific version of GCC 7.x or 8.x, it simply return: 7 or 8. Because the binary programs are compatible, the expression "7.*|6.*|5.*| 4.*)" in the configuration assured that for the GCC from 4.x to 6.x the build key was generated as follows: #define TQT_BUILD_KEY "x86_64 Linux g++-4.* full-config" But the gcc -dumpversion behavior change in GCC >= 7 has caused that the expression in the configuration not to be applied to GCC versions >= 7 and the build key is generated as follows: #define TQT_BUILD_KEY "x86_64 Linux g++-7 full-config" I believe that when binary programs are still compatible, we want to keep the build key identical (x86_64 Linux g++-4.* full-config), and I suggest modifying the expression in the configuration as follows: --- a/configure +++ b/configure @@ -2818,7 +2818,7 @@ g++*) 3.*) COMPILER_VERSION="3.*" ;; - 7.*|6.*|5.*|4.*) + [7-8]|[4-6].*) COMPILER_VERSION="4.*" ;; *) Please, what is your opinion? Cheers -- Slávek

3 3

ACPIAC k(t)control module in TDE?
by David C. Rankin 16 May '18

16 May '18

Tim, all, This is a tangential question on whether TDE has included an acpiac configuration module for specifying event-handling for say laptop power-button (suspend or off) as well as lid closed, etc. This is prompted by the trend away from acpi (with the configuration for event handling in /etc/acpi/handlers.sh) to acpiac which has a dearth of documentation and limited user-information. Evidently, plasma, gnome and xfce have configuration widgets for it. K3 has none (aside from the monitor DPMS control -- which isn't related). If TDE has an implementation, I'd love to see the commit and see how you did it, and where you put the interface. If TDE doesn't have an interface yet, well throw it on the wishlist heap -- as it looks like we will all have to deal with this power-interface in the near future -- it's code feeds into the kernel -- so it's coming. Short list of info links: https://www.acpica.org/documentation what it is: https://acpica.org/sites/acpica/files/ACPI-Introduction.pdf or the API/Programming Reference: https://acpica.org/sites/acpica/files/acpica-reference_18.pdf OS-Dev wisdom: https://wiki.osdev.org/ACPICA -- David C. Rankin, J.D.,P.E.

1 1

TDE for Ubuntu 18.04 LTS - Bionic Beaver
by MLR 15 May '18

15 May '18

Hi. I am still using 12.4 and would like to upgrade to 18.4 in a few weeks. Will there be a TDE release for 18.4 soon? I still mourn the great KDE 3 and love TDE. :) Best regards Tom

2 2

Donation to TDE
by Alexandre Couture 28 Apr '18

28 Apr '18

Hi, I've just made a donation to the TDE project, but I am however concerned about a detail: I see that most commits are from Michele Calgaro and Slavek Banko, but I am not sure if they receive a part of these donations, to thank them for their time. I do understand that Timothy Pearson is providing some infrastructure for TDE, and has problably less time to work on TDE or interest nowadays, but I think that it would make sense to have some parts of the donations directed to the active developers. Can someone clarify this please? (Of course, by them way, don't forget to do a little donation to TDE, to see it up and running) Thank you and have a great day! -Alexandre

1 0

tde-open
by wofgdkncxojef＠gmail.com 21 Apr '18

21 Apr '18

what about my simple proposal for tde-open "what about having an alias for "kfmclient exec" to tde-open? There is kde-open, mate-open, gnome-open... tde-open would be a logical expectation." https://bugs.trinitydesktop.org/show_bug.cgi?id=2816 a simple wrapper script #!/bin/bash kfmclient exec "@" in /opt/trinity/bin named tde-open should do the trick.....

1 0

older bugs
by deloptes 20 Apr '18

20 Apr '18

Can you look into those bugs and why we do not clean up a bit? https://bugs.trinitydesktop.org/show_bug.cgi?id=267 https://bugs.trinitydesktop.org/show_bug.cgi?id=630 This is definitely solved through the upgrade to gnupg2 https://bugs.trinitydesktop.org/show_bug.cgi?id=1090 And what happened to my request https://bugs.trinitydesktop.org/show_bug.cgi?id=2691 I need to learn managing git branches to be able to follow :) regards

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels