tde-devels

devels@trinitydesktop.org

7 participants
3840 discussions

Re: [trinity-devel] 3.5.13.2
by Darrell Anderson 07 May '13

07 May '13

>Bugs that I would like to have resolved: > >1291 some kickoff menu bugs > => patches look good, I'll push them soon >1424 kdegraphics-kfile-plugins-trinity: add ghostscript as >recommended package > => simple packaging issue >1488 kmix: Adjusting the volume (mono) microphone does not work > => I plan to examine this on Wednesday >1493 kio_man does not support XZ compressed manpages > => patch waiting for test > >Less important: > >1146 Build issue: fusion-icon does not install python module in >python_sitelib >1188 Build issue: tde-guidance can not work > => only when I'll find time to try the solutions proposed by >François > >Besides, I need to include and update Debian / Ubuntu metapackages >for >v3.5.13-sru branch. > >I also plan to backport latest patches "Cleanup output clutter." >:) > >Any other suggestions? I don't have a dog in the fight. I am curious after having a discussion with another person about R14. The "priority" bug list for R14 is growing smaller. Originally we targeted an R14 release in late May, although I don't know whether that remains tenable. I am thinking that releasing 3.5.13.2 after R14 might seem a tad awkward, although hardly strange. Conversely, releasing R14 real soon after announcing 3.5.13.2 might seem a tad odd from a public relations perspective. I don't think 3.5.13.2 will ever be "perfect." In any project a "go live" moment is necessary. There always will be unresolved bugs in any large project. Theoretically, patches could be backported to 3.5.13.2 for years, but I suspect none of us want that and prefer to see 3.5.13.2 as the last of that branch. Even the KDE folks don't try to cram as many bug patches as possible into each point release. They stick to their monthly schedule. Seems the sooner we officially release 3.5.13.2 the sooner we get 3.5.13.x behind us and focus energies on R14. That all said, your list looks short and you wrote that patches already exist for some of them. I'm just chattering out loud --- you do what you think best. :-) Darrell

1 0

Re: [trinity-devel] Cleanup output clutter
by Darrell Anderson 06 May '13

06 May '13

>Inspected, I think it looks good :) >Thank you for your efforts. Are you going to push them to GIT or am I? Darrell

2 1

Re: [trinity-devel] Cleanup output clutter
by Darrell Anderson 06 May '13

06 May '13

>From the top of my local repo, I performed the following: > >grep -rn "\\\n\\\r" . | grep printf | grep -v sprintf > >The results are limited to a handful of modules: > >applications/gtk3-tqt-engine >applications/kcmldap >applications/kcmldapcontroller >applications/kcmldapmanager >applications/kgtk-qt3 >applications/knetworkmanager8 >applications/knetworkmanager9 >applications/koffice >applications/qt4-tqt-theme-engine >applications/smartcardauth >libraries/libtdeldap >tdelibs/tderandr >tdenetwork/wifi/kcmwifi >tdepim/tderesources/caldav >tdepim/tderesources/carddav > >I did not want to interfere with any additional work you were >doing, which is why I asked rather than start patching. :-) Slavek, I created some cleanup patches. I only modified printf and tqWarning messages. http://humanreadable.nfshost.com/misc/trinity-cleanup-patches/ Please review them (they are short). If they look okay I'll push to GIT. Darrell

2 1

Superkaramba widgets
by Darrell Anderson 06 May '13

06 May '13

We received an enhancement request to add some superkaramba widgets prepackaged as part of Trinity: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1487 A primary advantage for prepackaging is ease-of-use for end-users. * Should we do this? * If we do this, do we package the widgets separately or merge them into the superkaramba sources in tdeutils? * If we do this, what guidelines do we establish for selecting which widget candidates to prepackage and support? * As there are many such widgets, even for KDE3, should we instead host a wiki page for installing widgets, such as from kde-look.org? Seems many of the older KDE3 widgets still function in Trinity. In addition to generic instructions, a wiki page could include tips for cleaning or massaging problematic widgets to work with Trinity. Comments and suggestions appreciated! :-) Darrell

1 0

Re: [trinity-devel] Updating local GIT repository with switch_all_submodules_to_head_and_clean script
by Darrell Anderson 05 May '13

05 May '13

>No :) Update your git module scripts, you get an updated version >switch_all_submodules_to_head_and_clean. Flag --ignore-submodules >is used inside this script. Yay! Much faster. Thank you! Darrell

1 0

Re: [trinity-devel] Updating local GIT repository with switch_all_submodules_to_head_and_clean script
by Darrell Anderson 05 May '13

05 May '13

>In the scripts I added checking for git ability, so that it can be >returned to >use flag --ignore-submodules (removed in commit c2cf6015, returned >in commit >7e23a1ee). This can significantly speed up the script. Are you saying use the script like this: switch_all_submodules_to_head_and_clean --ignore-submodules Darrell

2 1

Updating local GIT repository with switch_all_submodules_to_head_and_clean script
by Darrell Anderson 05 May '13

05 May '13

I use the switch_all_submodules_to_head_and_clean script to update my local GIT repository. After the script displays the "Preparing $PWD for development use" message, there is an almost four minute delay before the script resumes. Is this delay normal? Darrell

2 1

Re: [trinity-devel] KMail - added NetworkManager support
by Darrell Anderson 04 May '13

04 May '13

>It can be implemented as a KDED service, which pinging to a >predefined IP (or >to gateway) and expose the network state via DCOP. Unfortunately, >is not my >priority, because I use NetworkManager. I detest the idea of anything "phoning home." Therefore pinging a local gateway address is much more palatable. :-) Darrell

1 0

Re: [trinity-devel] KMail - added NetworkManager support
by Darrell Anderson 04 May '13

04 May '13

>> Kmail here is always online, which, for an enterprise type workstation >> is what I lwant. Laptops may benifit from networkmanager, I never have >> and don't need one more thing to deal with in my environment. > >This is one reason why I would like this feature to use the TDE network >system, as that system a.) falls back gracefully when NetworkManager is >not installed and b.) is designed so that other network backends (e.g. >simply reading ifconfig) can be added in the future. In summary, not everyone uses a wireless connection. :-) We have a place to direct this conversation and patching: http://bugs.trinitydesktop.org/show_bug.cgi?id=1105 BTW, this is a healthy enhancement request but is not an R14.0.0 priority. Darrell

2 1

Re: [trinity-devel] KMail - added NetworkManager support
by Darrell Anderson 04 May '13

04 May '13

>> I added NetworkManager support to KMail. This patch will put >KMail in >> offline/online mode, according to current NetworkManager state. >As a side >> effect, KMail will be switched automatically to offline when you >will >> suspend >> the machine, and to online after resume. >> >> https://github.com/serghei/kde3- >kdepim/commit/0577b2e0087d6350a099778300ec3912a0fc1e74 >> >> -- >> Serghei > >It would be interesting to forward-port this to the TDE network >management >system, so that DBUS code is not duplicated in multiple places >within TDE... Does KMail start or default to offline mode when NetworkManager is not installed? Darrell

4 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels