[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More kde4-develop problems



>> Hi,
>>
>> this mail would have been more appropriate for debian-kde@lists.debian.org
>> mailing list.
>
> 2008 m. April 13 d., Sunday, jūs rašėte:
> > If plasma crashes (does do that), will come up again with one (fixed)
> > desktop and with windows missing their frames. This can also occur with
> > simple logout and logon.
>>
>> I really have not had many problems with plasma crashes even with 4.0.66 or
>> 4.0.68. Try running as much default setup as possible (as I do, it works
>> fine 24/7). This is __development__ version of KDE, even alpha has not been
>> released yet and it's in *experimental*. However, we test packages before
>> uploading and you will never left with completely broken software. So if
>> you installed stuff from experimental, you will have to live with bugs,
>> crashes (which fortunately rarely happens) and inconsistencies because
>> you're running __very bleeding edge__ stuff.
>>
>> Another note: do not run a mix. If you still have some KDE 4 components at
>> 4.0.2, upgrade/wait for > 4.0.66 version to be available. This might also
>> be causing problems for you.

>>I wish synaptic or such would track this. I spent a lot of time getting the 
>>4.0.66/68 stuff I have, one by one.
>>
>> I found the "previous session" in kdm set to "kde" rather than "kde4" (I
>> have session file for both, the kde3.5.6 was "konstructed"). Rechoosing
>> "kde4" yielded a correct session but this might not be relevant. I can
>> (used to?) run the kde3.5.6 session by choosing "kde" session.
>
> You explained everything with "kde3.5.6 was konstructed". We can't do
> anything about it. Please cleanup your system. If your system was clean,
> there would be only a single KDE to choose.

>>I purposefully maintain the choice, set up env and such in the startup 
>>scripts. Took some doing at first.

>>Obviously, enjoying the bleeding edge, I still have kde3 stuff I use every 
day 
>>and if things get to broken, I and especially other users in my home, need 
>>the tried and true. I "konstructed" the kde3.* when it was uninstallable 
from 
>>Sid (remember those times)? A lot of compiled apps are in its folder's (I 
>>have in in /opt/kde3.5). They run 100% in the kde4 session but I wonder 
about 
>>the dcop vs dbus. Kmail is a perfect example but knemo, ksensors, kisa, 
>>konqueror from 3.5, 3.5's kget, all get exercised without problems in kde4 
>>sessions. Dolphin and others run without problems from kde3 session..
>>
>> New libraries--observations:
>> 1. Icon backgrounds no longer semi-transparent.
>
> Fine here.
>>I would not mind total transparent backgrounds. I had a startup applet I 
>>used 
>>in Windows to accomplish this. Looks much nicer.

>>
>> 2. Extra title-bar icon to place window on all desktops (I do not think
>> this adds much).
>>
> None here (unless I miss something). Restore default style/theme.
>

>>Top left of title bar, the usual icon box like in windows and another beside 
>>it (*) which places toggles in all desktops. I thought I returned to Oxygen, 
>>however, the theme-handling in kde4 is not totally reliable as of yet so ... 
>>its mostly stays at one of the near-default themes.

>> 3. Separate sub-icon now for resizing and rotation. This is better since
>> the one subicon was confusing. However, the two are not distinct in small
>> sizes (and they must be small) and this functionality to me is of very
>> limit value. Resize, OK, occasionally is worthwhile. When would I really
>> want to rotate them :-) ?
>
> Report these kind of problems upstream (KDE BTS). 4.1 is still in early
> stage though feature freeze is coming quickly.
>>How do I do this? Seem this is asking for (the an option to) remove a 
feature 
>>that the kde authors probably simply love.

Actually, the Oxygen set has distinctive icons for this.

>> 4. Adding (readding) the kget applet from the "widgets" icon will crash
>> plasma. I can run it from a console but that will not restart it on next
>> login.  Since konqueror-4.0.0* (usually) will not work, kget is not
>> useful. Opera has its own download manager but opera must be  kept
>> running to use it. I had problems with copied addresses sporadically in
>> kget truncating the download.
>
> I appreciate you testing things but if you want a stable KDE 4.1 at this
> point, try sticking with defaults. Or better yet report crashes (with
> backtraces when -dbg packages are installed, patches are welcome too) to
> KDE BTS so they can be fixed and you will be able to use the feature when
> the next snapshot hits experimental. We, Debian packagers, rarely fix
> upstream bugs, especially when the code is in such a early development
> state.

>>I USEDTO get the backtraces with plasma crashes. I did NOT get those today. 
Of 
>>course, this stuff should go to kde, not debian.
>
> Why KDE 4.1 development instead of KDE 4.0 you might ask? Well, KDE 4.0 is
> not an option for lenny, but if we are lucky, lenny will be released with
> KDE 4.1. So Debian experimental users can help to make KDE 4.1 the release
> best ever so it will part of lenny. But if you want a stable desktop just
> now, you will have stick with unstable and its KDE 3.5.9 for now.

>>As many have said, 4.0 was a pre-release to get folks like me on to it. 4.1 
>>will be more a finished release so we await it with some impatience.

>>I think what the debian end needs do is make the upgrade paths, be they from 
>>4.0.0.* to 4.06* or to 4.1, orderly and reliable using the tools provided 
>>with debian such as aptitude or synaptic (kpackage stopped working a while 
>>back in 3.5.6 and the version 4 is a different animal entirely but plays by 
>>the same rules). Right now I have to make EVERYTHING experimental, I 
>>suppose, to get a apt upgrade, which obviously I do not wish to do.

I straightened out the dependency problems using:
apt-get -t experimental -f install!

Flakiness such as alternate login problems with pager  and window frames, I 
still do not know. I'll see if the purer 4.0.66/8 system works better.

Flakiness can be caused by path problems in a dual kde system. 
Once-upon-a-time, kdm set a DESKTOP_SESSION to the name in the *.desktop 
chosen. I tested that in my profile to set paths correctly. Alas, I found 
yesterday that this env item was gone. So I set it explicitly in the 
appropriate startkde. Also, both copies of kde.desktop I had that referred to 
the kde3.5 startup were overwritten in all the upgrades.

The new startkde sets an env variable to 4. The kde3.5 version does not set 
anything.

Besides setting paths correctly, certain scripts would like to know what 
desktop is running. A very good example might be a dcop that ran dcopserver 
for kde3 and some interface to the newer dbus system in kde4. Other examples 
that would not be obsolete in a few months could be conceived. Xfce, fluxbox, 
etc., etc.--linux is about freedom to choose and change!--would effect 
various programs and that env variable was there for this purpose.


Reply to: