[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Guidance porting to KDE 4
From:       Nicolas Ternisien <nicolas.ternisien () gmail ! com>
Date:       2009-07-02 20:09:40
Message-ID: ccba71b50907021309i429e989ejb9c46efb6c573ee6 () mail ! gmail ! com
[Download RAW message or body]

Hi Yuriy,

Ouch, I've just received this mail (lost in GMail labels....). So, I
did not have so much time to continue this task (new job,...), but
this is still on my huge TODO list!

I will give more information about my feelings and time in the KDE 4.4
Features Plan.

Thanks for keeping informed about this project, that is, in my
opinion, something really important to energize the KDE Admin module.

Nicolas Ternisien



On Sat, May 23, 2009 at 5:27 AM, Yuriy Kozlov<yuriy-kozlov@kubuntu.org> wrote:
> Hi Nicolas,
>
> I'm wondering what is the status of this project?  It'd be useful to
> know for the Ubuntu Developer Summit this upcoming week.
>
> ~ Yuriy
>
> On Mon, Nov 17, 2008 at 9:22 AM, Nicolas Ternisien
> <nicolas.ternisien@gmail.com> wrote:
>> For information, the branch has been started here :
>>
>> http://websvn.kde.org/branches/guidance/guidance-kde4/
>>
>> Nicolas
>>
>> On Mon, Nov 17, 2008 at 10:39 AM, Nicolas Ternisien
>> <nicolas.ternisien@gmail.com> wrote:
>>> Hi and thanks for your answers,
>>>
>>> The main goal of porting Guidance to KDE 4 is not to blindly integrate
>>> all of its sub applications to the KDE Admin. The goal is to port the
>>> applications that do not already cover something that the KDE main
>>> tree don't do actually.
>>>
>>> Here is my opinion on each sub applications :
>>>
>>> displayconfig :
>>> You are right, the displayconfig for example don't need to be ported,
>>> as another project already do this in KDE.
>>>
>>> userconfig :
>>> KUser and userconfig both look like a graphical editor for /etc/group
>>> and /etc/passwd. In my opinion, userconfig misses only 2/3 features
>>> that KUser has before being able to replace it. In my opinion,
>>> userconfig could only be the start of an application that could be
>>> improved, and it will be integrated only if KDE core developers think
>>> it is sufficently powerful and have an interest. If the Fedora tool
>>> has a backend and that's this backend is providen to any distribution,
>>> then userconfig will be improved to use it. As I said previously, it's
>>> only a start (or restart in this case, as KUser exists).
>>>
>>> serviceconfig :
>>> Serviceconfig has pratically the same history than userconfig, but the
>>> main difference is that KSysV is really old and not really good, so
>>> its replacing will be easier and earlier.
>>>
>>> mountconfig :
>>> If mountconfig has issues, they will need to be fixed before
>>> integrating it to KDE Admin. I've maybe not specifying that each sub
>>> applications will have to follow the KDE application process
>>> (http://techbase.kde.org/Policies/SVN_Guidelines)
>>>
>>> wineconfig :
>>> If a D-Bus interface has been started in the Wine project, maybe we
>>> could wait its release to see if the porting is necessary, or if it
>>> could be better to rewrite it from scratch.
>>>
>>> guidance-power-manager :
>>> It seems that power-devil will be the next application that will take
>>> care about battery management, so, the Guidance one is not
>>> particularly needed.
>>>
>>> To conclude, there are 3 applications of the Guidance project that
>>> could be used, and that could be ported to KDE 4 (userconfig port is
>>> already started). Those applications will have to follow the KDE
>>> application integration policy one by one, to be sure there are enough
>>> mature to be part of KDE.
>>>
>>> The guidance-kde4 branch will contain only those 3 applications, to
>>> reflect what we said here.
>>>
>>> Do you agree with this ?
>>>
>>> Nicolas Ternisien
>>>
>>> On Sun, Nov 16, 2008 at 8:10 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
>>>> On Sun, 16 Nov 2008 13:35:27 -0500 "Yuriy Kozlov"
>>>> <yuriy-kozlov@kubuntu.org> wrote:
>>>> ...
>>>>>displayconfig is now replaced by kcmrandr, hopefully.  (Is that using
>>>>>this Kephal library?)  The latter still needs work, and taking some of
>>>>>the interface from displayconfig might be a good idea, but the backend
>>>>>of displayconfig is outdated now, as ScottK can attest to after trying
>>>>>to fix it up for Hardy.  However, there are also some features in
>>>>>displayconfig other than resolution setting and such that are
>>>>>currently not covered in KDE modules AFAIK, like gamma settings.
>>>>>displayconfig also had display power settings, which system settings
>>>>>already has, but is that taken care of by powerdevil now (in 4.2)?
>>>>>
>>>>
>>>> Redoing the displayconfig back end to work with xrandr and modern
>>>> xorg.conf'less systems is a critical piece.  I don't see significant value
>>>> in a KDE4 port of displayconfig.
>>>>
>>>> From what I've been reading, it sounds like many of the currently missing
>>>> bits in the kcmrandr tool have been added in 4.2.
>>>>
>>>> Guidance power manager still works pretty well (that's been ported
>>>> already).  It could stand some re-enginnering on the back end as I don't
>>>> think it's entirely in synch with modern hal/dbus magic.
>>>>
>>>> AFAIK, the Kubuntu plan for 9.04 is to switch to powerdevil.
>>>>
>>>> Scott K
>>>>
>>>
>>
>> --
>> kubuntu-devel mailing list
>> kubuntu-devel@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>>
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]