Hi all,
I have a problem to discuss:
Before long time I prepared a patch, which is included in the commit 9e3f8a7f.
It was based on a completely broken patch for KDE4 - commit c24ea2b4. Our
patch works correctly, but contains one potential risk - is dependent on DNS
=> on the network delays.
First question is, how big is this risk, because we have a patch incorporated
nearly a year ago and no problems observed. The fact is that if the user will
have a problem with the network, probably will not even be able to open a
remote window. However, this risk actually exists.
In my proposal for the integration of our patch into KDE4 was a risk discussed
by KDE4 team and Martin prepared a solution where the DNS queries is executed
in a separate thread - commit cbb7f575. In comparison with our patch it is
quite big patch. Backport of Martin's patch is hampered by the fact that he
was used QtConcurrent which is included in QT4.7 and higher.
Therefore, I have a question: What next? Martin designed a simple revert our
patch seems to me inappropriate. The second option is to leave our patch
unchanged and also a risk. Third, that someone remakes patch to not use
QtConcurrent (it is beyond my abilities).
Your suggestions?
Thanks for your comments and help
Mentioned commits:
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=c24ea2b4aac214ce29a…http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c7…http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe2a3b4916…
Slavek
--
======================================================================
I have forwarded this message to the list at the request of Mikhail T.
======================================================================
Hello!
As you may have heard, FreeBSD stopped maintaining KDE3 ports ("frozen" at
3.5.10) several years ago. Though they are still available (and the binary
packages are still being built for new OS-releases), the maintainers
switched to
KDE4.
I don't need to explain to you, why I do not think, KDE4 is a good
replacement
for KDE3 (my own primary objection was having to redo all customizations in
~/.kde/), so I'd like to explore creating KDE-Trinity ports alongside with
(and
eventually replacing) KDE-3 ones.
Obviously, the effort will be gradual and I'd like to take advantage of as
much
existing stuff as possible. For example, can TQt3 simply replace the Qt3 --
without breaking the existing ports? For that, TQt3 needs to provide the same
q-symbols alongside the new tq-ones...
How about sub-pieces? For example, FreeBSD has for years maintained the
port of
qmake separately from that of the Qt-library -- to avoid having to rebuild
the
tool completely for every minor update to the latter. Other optional
pieces of
Qt3 (such as, for example, database back-ends) also live as separate ports.
If I were to switch (upgrade?) the main library to TQt3, will these
sub-pieces
continue to build and work, or do I have to ensure, ALL Qt3-users (and that's
hundreds of ports today) are switchedat once?
Beyond the (T)Qt3 foundation, can I switch kdelibs3 to Trinity without
/simultaneously/ switching kdebase3, kdenetworks3, and kdegraphics3?
Obviously,
I'd want to eventually switch them all, but it'd be much easier, if I
could do
it piecemeal, rather than all at once...
I'd also like to ask about the "roadmap" -- there is a Trinity-14 project,
which
warns about "breaking backwards compatibility". Does this simply mean
ABI-changes (if API is preserved, this is easy to deal with)? Or will the
dreaded changes to configuration format (stuff already under user's ~/.kde/)
come and bite me again?
Thanks a lot for suggestions. Yours,
-mi
P.S. I see people have reported running Trinity on their FreeBSD machines
already. Please, let me know of any patches or other tricks still (in
3.5.13.1)
necessary to build on the OS. Collaborators and testers would also be
welcome.
[Not sure of the protocol here: should I have posted to Bug 690? or
sent this email?]
3.5.13 kdm_greet eats lots of CPU.
I see this was marked as fixed (Bug 690) and looking at the source of
Slavek's kdm-trinity, I'm using his ppa on wheezy so the version of
kdm-trinity installed is 4:3.5.13-2debian0~pre26+7~wheezy, the patches
for kgreeter.cpp and sakdlg.cc are in place... but the bug's still
there.
It seems worse when a remote display connects but also happens with just
a display on the machine's console.
This is happening on my little laptop test mule (Intel Core 2) and a
larger 16 core server (AMD Opteron).
A few observations:
/tmp/ksocket-global exists and is mode 0644. Curiously it's owned by
what appears to be a random user-id. If I stop kdm, remove the
/tmp/ksocket-global directory and restart kdm it recreates
ksocket-global mode 0644 but owned by user id 1000... as that's the uid
for the kdm_greet process (eh? why is kdm_greet changing its process
uid? kdm is running as root. can't even see setuid being used in the
kfrontend code).
/tmp/ksocket-global is an empty directory.
An strace on kdm_greet shows the following loop:
read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor)
recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 500000}, NULL) = 0
gettimeofday({1358766636, 578738}, NULL) = 0
recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1358766636, 578825}, NULL) = 0
select(9, [4 5 8], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1358766636, 578940}, NULL) = 0
read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor)
The read from -1 is obviously wrong.
/var/log/kdm.log contains errors as follows:
>Jan 21 11:17:52 kdm_config[30569] info: Cannot open master configuration file /etc/trinity/kdm/kdmdistrc
<fair enough: it doesn't exist>
>
>X.Org X Server 1.12.4
>Release Date: 2012-08-27
>X Protocol Version 11, Revision 0
>Build Operating System: Linux 2.6.32-5-amd64 i686 Debian
>Current Operating System: Linux lapcat 3.2.32lls-rt48 #2 SMP Wed Dec 12
>10:32:35 GMT 2012 i686
>Kernel command line: BOOT_IMAGE=Linux ro
>root=UUID=7b9e9723-c08f-426c-96a6-4ad9aeee1e5d
>Build Date: 29 November 2012 08:52:43PM
>xorg-server 2:1.12.4-4 (Julien Cristau <jcristau(a)debian.org>)
>Current version of pixman: 0.26.0
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
>Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>(==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan 21 11:17:52 2013
>(==) Using system config directory "/usr/share/X11/xorg.conf.d"
>(II) [KMS] Kernel modesetting enabled.
>QWidget::setMinimumSize: The smallest allowed size is (0,0)
>QWidget::setMaximumSize: (unnamed/QDialog) Negative sizes (-1,-1) are not possible
>sh: warning: setlocale: LC_ALL: cannot change locale (en_GB)
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
This file does exist mode 0644 uid root, gid root.
/etc/qt3 is mode 0755, root.root
/etc is 0711, root.root
>QSettings: error creating /tmp/1468675921/.qt
/tmp/1468675921/.qt does exist. Mode 0775, root.root. Nothing in
there though.
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
I'm very happy to test/debug/try code.
Original Bug Ref: http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=690
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
>I recently took some time to evaluate kwin on a TDE system. The
>kwin developers have done excellent work; kwin itself operates
well and
>the configuration dialogs are relatively sane compared to most
modern
>offerings. At this point I agree with Martin that TDE should be
>looking at using kwin as a default instead of our old twin fork as
soon as
>possible.
>
>I have put together an Etherpad
>(http://trinity.etherpad.trinitydesktop.org/61) detailing the
>changes that need to occur before this can be done. Both TDE and
kwin will
>need some modification to ensure that TDE doesn't lose features
after the
>migration is complete.
Based on the etherpad notes, this sounds like a post R14 goal. As
twin->kwin is a significant transition, I'm guessing R15?
Darrell
Hi Trinity developers,
finally I can announce the availability of a patch [1] to build KWin
standalone. That is without building other parts of kde-workspace. The patch
is on top of KDE/4.10 branch [2] as of Friday and available in git branch
"kwin/standalone" of my kde-workspace clone [3].
I hope this patch can help you to provide a tailored version of KWin. Most of
the functionality which is required for this is already part of KWin master
and also used in some KDE projects. E.g. for Plasma Active we use an adjusted
KWin version without window decorations, without KCMs, with a different binary
name and different configuration files. To make it easier to build KWin for
new developers we introduced a build option to disable the Oxygen window
decoration which required to build most parts of kde-workspace. All available
build options are documented in [4].
*Build Options*
For the usage in your project I would suggest the following build options:
* adjust the "KWIN_NAME" variable in CMakeLists.txt
* disable KWIN_BUILD_OXYGEN
* disable KWIN_BUILD_KCMS
* disable KWIN_BUILD_KAPPMENU
* disable KWIN_BUILD_ACTIVITIES
The steps on how to build KWin are probably well known given that it is a
cmake project. If not there is a beginners guide available in [5].
The patch does not reduce the dependency on kdelibs and kde-runtime. We still
have a dependency on kdelibs and that cannot change in the lifetime of KWin on
Qt 4 due to part of KWin being implemented in kdelibs.
*Styling*
Also KWin has a pretty standard Plasma look'n'feel. But this can be easily
changed:
* window decorations can be written in QML since 4.10 - with disabled Oxygen
the default decoration is in fact on QML. Documentation for this is still
missing, but is on my TODO list ;-)
* Alt+Tab window switchers can be written in QML. Documentation for this is
available in [6] and this feature is e.g. used by Plasma Active to have a
customized switcher
* QML scripts can be loaded - e.g. our "Desktop Change OSD" is written in QML.
It would be easy to replace it with one that does not use Plasma Components.
Documentation is available in [7] for the general JavaScript API.
*What are the next steps?*
Development focus is currently on porting KWin to Qt5. Given the strong usage
of XLib this is more work than for most projects. But I hope that this will
soon be finished. With Qt5 and KDE Frameworks 5 the dependencies will go down
to what is really needed and quite some for KWin important functionality from
kdelibs has been upstreamed into Qt.
Other plans are to use KConfigXT for the complete configuration of KWin. This
is already used (since 4.10) for KWin effects and would allow to easily
integrate our configuration interfaces in your available configuration module.
With KConfigXT the configuration modules basically consist of .ui files and an
xml description of the config values. (Note: the KCMs belonging to KWin do not
support a changed binary name.)
Apart from that I want to have everything which is UI to be done in QML.
*Final Remarks*
This patch is a personal service provided by me and is not officially
supported by KDE. I will not update the patch on a regular basis, though I
intend to update it for each release cycle once a new version has been
branched. This also means that I cannot guarantee that everything works
correctly. If you hit a bug related to this patch let me know, but please
don't open a report on bugs.kde.org.
I hope this patch is helpful for you. If you need improvements you are of
course more than welcome to contribute to KWin :-)
A Merry Christmas to you and a happy and successful new year 2013.
Kind Regards
Martin Gräßlin
KWin Maintainer
[1] http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fgraesslin%2Fkde-
workspace.git&a=commitdiff&h=2f23192fe2658b9ecde005db40b2ec366b3e18d4&hp=60844a5744b04483e86bff299713e1e56df52a4a
[2] http://quickgit.kde.org/?p=kde-
workspace.git&a=shortlog&h=60844a5744b04483e86bff299713e1e56df52a4a
[3] http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fgraesslin%2Fkde-
workspace.git
[4] http://techbase.kde.org/Projects/KWin/Build_Options
[5] http://community.kde.org/KWin/Building
[6] http://techbase.kde.org/Development/Tutorials/KWin/WindowSwitcher
[7] http://techbase.kde.org/Development/Tutorials/KWin/Scripting
Just a quick heads up that there are some large updates going int GIT
right now to rename KApplication; you may want to hold off on building TDE
from GIT for a few days while I verify they went in properly.
Tim
Hey all,
Can anyone pitch in ideas for dealing with bug 1290?
Hal is badly outdated and kpowersave is acting up, so debugging it
could be very tricky,
We also have kpowersave-nohal ready for R14...
what should we do?
Calvin
>Developers, please delete and re-download the top-level GIT
supermodule.
>I have temporarily locked out commit access to that top level
supermodule
>to prevent accidental merges of the old history. All other GIT
modules
>continue to have normal read/write permissions for the TDE
development
>team, so the impact of this should be minimal.
Supermodule? Delete exactly what directory in the tree?
Darrell
