tde-devels

devels@trinitydesktop.org

1 participants
3754 discussions

by Darrell Anderson

>Same on my laptops. Last time I remember it working was on debian >kernel 2.6.32. Thank you. Bug report 1615 filed and added to the R14 etherpad road map. Darrell

11 years, 5 months

TDEPowersave

by Darrell Anderson

Anybody using TDEPowersave? I can't seem to get the app to send the laptop to sleep mode (suspend-to-ram). The screen blanks but the laptop does not enter sleep mode when the sleep/suspend timer expires. The moment I execute any user event, such as move the mouse or touch the keyboard, then TDEPowersave goes into sleep mode. Darrell

11 years, 5 months

Re: [trinity-devel] TDEPowersave

by Darrell Anderson

>Anybody using TDEPowersave? > >I can't seem to get the app to send the laptop to sleep mode >(suspend-to-ram). The screen blanks but the laptop does not enter >sleep mode when the sleep/suspend timer expires. The moment I >execute any user event, such as move the mouse or touch the >keyboard, then TDEPowersave goes into sleep mode. I should have added that I can send the laptop to sleep mode using Fn-F4, closing the lid, and even with the TDEPowersave popup menu option. Darrell

11 years, 5 months

Re: [trinity-devel] Moving tdehwlib to a standalone library

by Darrell Anderson

>Otherwise, I am fully in agreement with splitting up the >monolithic >tdehardwaredevices.cpp file into a number of smaller files (this >could be >theoretically be done for R14.0.0 as it is a cosmetic change), and >also >adding pluggable module support (this will likely have to wait for >R14.1.0 >though). If you split tdehardwaredevices.cpp please post a note here in the list so we are aware during rebuilds. :-) Darrell

11 years, 6 months

Re: [trinity-devel] Moving tdehwlib to a standalone library

by Darrell Anderson

>Hi, as I claimed just now on the neighbor thread, I'm working on >the move >tdehwlib out of tdecore. >why so: >1. it provides specific functionality. >2. Only few apps are using it. >3. It's not integrated into tdecore except of couple unnecessary >and ugly >hacks to KInstace. >4. It's code is too robust while it's located in a single file. > >What changes are introduced: >1. TDEHW namespace for all exported classes. >2. Some specific macros. >3. Move includes to tdehw directory. >4. Strip TDE prefix from classes and file names. > >What is already done: >1-4. >5. Split tdehardwaredevices.{h,cpp} into several headers >6. repair tdebase according to the changes > >What is to be done before merging the changes: >1. Repair any other modules. (Is there any?) >2. Some repair is needed to tdenetworkconnections.{cpp,h} and to >modules >which use it. >3. Testing. > >Further plans: >1. Introduce the backend framework. On first stage in the most >basic way. >2. Split tdenetworkconnections.cpp in the same way it was done for >tdehardwaredevices. > >The repositories are here: >https://github.com/Fat-Zer/tdelibs.git >https://github.com/Fat-Zer/tdebase.git >See libtdehw branch. >!WARNING! It supposed to be built and work but my be broken in >some options. > >Some questions: >Is there any ather modules outside tdebase which use tdehw? >Is there anything what uses tdenetworkconnections? >Any other thoughts? I don't pretend to understand the programming reasons cited above. Yet seems to me this topic needs to be discussed here. I've probably done the most user testing with Tim. I've been using GIT pre-R14 for many months and I am not seeing any serious problems with tdehwlib. Whether the sources need to be moved to a separate module ultimately gets decided by Tim as he is the owner of that code. Even if Tim wants to move tdehwlib to a separate module, I vote not to do that until after R14.0.0 is officialy released. Simply because we have enough on our plate right now to get R14.0.0 out the door. Although we are planning regular maintenance updates for R14.0.0 (R14.0.1, R14.0.2, etc.), ABI changes mean a bump in the second part of the version number: R14.1.0. There is no reason we can't do that as long as there is consensus that is what we want to do. Just my two cents. :-) Darrell

11 years, 6 months

Re: [trinity-devel] Re: Building from GIT source & tde-packaging

by Darrell Anderson

>Hi there, >a few days have gone by since my original post, so I think it >should be ok >to ask again. >Is there any place where I can find the updated packaging files >for building >TDE for Debian/Jessie, other than extracting those from each >package in the >nightly build website? I'm not a Debian user, but try this; http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/ Darrell

11 years, 6 months

Re: [trinity-devel] about pmount and R14 new backends

by Darrell Anderson

>I've seen that the "pmount" utility is used in TDE R14 for >removable >devices. >I've also seen that this utility is NOT provided at all in some >distributions, e.g. Mageia 3. > >Questions: >1) If pmount does not exist, is there any alternative in TDE R14 >to >mount/umount devices ? (I'd say no, because I have an error >message >saying pmount was not found) >2) This utility looks like it is not maintained anymore upstream. >I've >built 0.9.99-alpha, and it works but needs some patches. Could we >import >into our Git to have our own "TDE-certified" pmount utility ? >3) Could'nt udisks2 do the same as pmount ? > >And some more questions about R14 new features ... >1) Is HAL/Halbackend code still entirely present ? (for old distro >NOT >having udisks, upower, etc ... but having HAL out of the box) >2) Do we have a summary of "what libraries are used for" in >tdelibs/tdebase ? For example, if I build with "udisks" but no >"udisks2" >support, what feature will I lose exactly ? And what alternatives >do I >have ? > >Up to 3.5.13.x, the situation seemed clear: without HAL, there was >no >alternative :-) Many months ago when I started testing tdehwlibs with Tim, I too noticed the pmount requirement. The package is not part of the stock Slackware but easily compiled and installed in Slackware. Nonetheless, that pmount is not a standard package in many distros does raise the question of how to best handle that discrepancy. If pmount is no longer maintained upstream, and if pmount is the only palatable method for supporting tdehwlib, then perhaps we ought to slip pmount into our dependencies tree. We have libart_gpl as a precendent for such a move. I'm using pmount 0.93, which is the current stable version. If there are alternatives to pmount, that nonetheless means extensive rewrites and testing. We already have enough on our plate to get R14.0.0 out the door in a timely fashion, and progress toward that has somewhat stalled of late. Replacing pmount also likely means an ABI change and according to our new versioning scheme, would mean such changes should wait until R14.1.0 (and not R14.0.1, which would be a bug-fix and maintenance release). As Alexander noted in another response, Trinity can be compiled with HAL or TDEHWLIB support, but not both. For a couple of months I built both ways as Slackware 13.1 uses HAL and 14.0 uses the udisks framework. I'm no longer using 13.1 and can't say how well we've maintained HAL support. I now only use 14.0 and I am not experiencing any serious problems with tdehwlib. Darrell

11 years, 6 months

Moving tdehwlib to a standalone library

by Fat-Zer

Hi, as I claimed just now on the neighbor thread, I'm working on the move tdehwlib out of tdecore. why so: 1. it provides specific functionality. 2. Only few apps are using it. 3. It's not integrated into tdecore except of couple unnecessary and ugly hacks to KInstace. 4. It's code is too robust while it's located in a single file. What changes are introduced: 1. TDEHW namespace for all exported classes. 2. Some specific macros. 3. Move includes to tdehw directory. 4. Strip TDE prefix from classes and file names. What is already done: 1-4. 5. Split tdehardwaredevices.{h,cpp} into several headers 6. repair tdebase according to the changes What is to be done before merging the changes: 1. Repair any other modules. (Is there any?) 2. Some repair is needed to tdenetworkconnections.{cpp,h} and to modules which use it. 3. Testing. Further plans: 1. Introduce the backend framework. On first stage in the most basic way. 2. Split tdenetworkconnections.cpp in the same way it was done for tdehardwaredevices. The repositories are here: https://github.com/Fat-Zer/tdelibs.git https://github.com/Fat-Zer/tdebase.git See libtdehw branch. !WARNING! It supposed to be built and work but my be broken in some options. Some questions: Is there any ather modules outside tdebase which use tdehw? Is there anything what uses tdenetworkconnections? Any other thoughts?

11 years, 6 months

about pmount and R14 new backends

by François Andriot

Hello, I've seen that the "pmount" utility is used in TDE R14 for removable devices. I've also seen that this utility is NOT provided at all in some distributions, e.g. Mageia 3. Questions: 1) If pmount does not exist, is there any alternative in TDE R14 to mount/umount devices ? (I'd say no, because I have an error message saying pmount was not found) 2) This utility looks like it is not maintained anymore upstream. I've built 0.9.99-alpha, and it works but needs some patches. Could we import into our Git to have our own "TDE-certified" pmount utility ? 3) Could'nt udisks2 do the same as pmount ? And some more questions about R14 new features ... 1) Is HAL/Halbackend code still entirely present ? (for old distro NOT having udisks, upower, etc ... but having HAL out of the box) 2) Do we have a summary of "what libraries are used for" in tdelibs/tdebase ? For example, if I build with "udisks" but no "udisks2" support, what feature will I lose exactly ? And what alternatives do I have ? Up to 3.5.13.x, the situation seemed clear: without HAL, there was no alternative :-) Thanks Francois

11 years, 6 months

Re: [trinity-devel] Artwork branding help needed

by Darrell Anderson

>These should hopefully be what you wanted. > >E. Liddell The look great! Thank you! :-) Darrell

11 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels