Schedules/KDE4/4.0 Release Beta Goals: Difference between revisions

    From KDE TechBase
    m (→‎Kate: config saving bugfixes)
    ({{Proposed_deletion|reason=Empty page.}})
     
    (41 intermediate revisions by 16 users not shown)
    Line 1: Line 1:
    This page will list all the release goals for the beta cycle of KDE4. It will contain not only the goals, but also the current state and what YOU can do to help out.
    {{Proposed_deletion|reason=Empty page.}}
     
    You can not add new items to this list. Only maintainers should edit their own section. If you wish to add new items, send a mail to [mailto:[email protected] [email protected]]
     
    === Plasma ===
    *''current state:'' <span style="color: red">showstopper</span>
    *''contact:'' [mailto:[email protected] Aaron J. Seigo]
    *''goal:'' panels need to be finished, application launch menu
    *''howto help:'' help is always welcome; there are a number of people contributing to plasma already, however. Unfortunately most are either working on peripheral pieces or find the core pieces too difficult. If you want to help, join the irc channel #plasma or mail to [mailto:[email protected] [email protected]]
    *''expected time of arrival:'' The plan is for a panel and menu to arrive in the next couple of weeks. Polishing will take a bit longer.
     
    === Color configuration ===
    *''current state:'' <span style="color: orange">not pretty, but very nearly usable</span>
    *''contact:'' [mailto:[email protected] Matthew Woehlke]
    *''goal:'' One needs to be able to change the palette.
    **Right now the only serious issue left is configuring the WM colors. This either needs the 'common colors' picker at least partly functional, or else we move them to the kwin config.
    *''howto help:'' We have this pretty well under control. It needs a lot of polish but at this point I think something would have to go horribly wrong for us to not have a functional kcm for 4.0. (Whether or not it will be beautiful I don't know, but functional it mostly is right now. The effects are not hooked up but I don't think that is a showstopper since it is new to 4.0.) However, if someone wants to implement the scheme loading/saving, that might be useful (coordinate with jpwhiting).
    *''expected time of arrival:''  one weeks to two months (depending on how optimistic you are) to polish and implement the last missing bits.
     
    === Oxygen style ===
    *''current state:'' <span style="color: red">showstopper</span>
    *''contact:'' [mailto:[email protected] Matthew Woehlke], [mailto:[email protected] Boemann] #oxygen
    *''goal:'' no obvious glitches, fix all bugs on [[Projects/Oxygen/StyleWinDec]]
    *''howto help:'' ask on #oxygen, help needed for the corners of the windec.
    *''expected time of arrival:'' end of october
     
    === Konqueror ===
    *''current state:'' <span style="color: red">showstopper</span>
    *''contact:'' [mailto:[email protected] David Faure]
    *''goal:'' Konqueror must be able to browse the web and to be used as a file manager again, I'm mostly aiming for "no regressions compared to KDE3"
    *''howto help:''
    **Help is most welcome. [mailto:[email protected] [email protected]] is the place for discussion of both aspects of konqueror development. Web browsing seems in better shape than filemanagement right now, so small tasks are fixing regressions in the webbrowsing-related code in konqueror and its dependencies. For instance there is finally a patch now about fixing the non-working Return key in the location bar URL; I'm sure there's more like that.
    **Bigger tasks include:
    ***defining a future for the sidebar code (*no showstopper if this is the last item on the list*) -- volunteer(s) needed!
    ***finishing the integration of the dolphin part for file management.
    *''expected time of arrival:'' november (if we leave out the sidebar changes), else december.
     
    === Dolphin ===
    *''current state:'' <span style="color: green">no showstopper anymore</span>
    *''contact:'' [mailto:[email protected] Peter Penz]
    *''goal:'' I think Dolphin is in a quite acceptable state now and I'll have a lot of time during the next week to fix the most serious bugs. David Faure and Rafael Fernández López also investigate a lot of time in Dolphin related things so I'm optimistic that Dolphin should be in a good shape for KDE 4.0.
    *''howto help:''
    **I'm concerned a little bit whether the Dolphin KPart is matured enough for getting Konqueror in shape. Maybe David can comment whether some help is  needed in this area (I've set David to CC).
    ***I'm not sure about the state of Nepomuk. Currently the performance is too  slow for sorting items by tags or rating. It would be possible to use an  internal cache in Dolphin for this, but this would only reduce the time from  O(n*log(n)) to O(n) and the problem is n: reading e. g. 30 items takes several seconds... Maybe Sebastian Trüg could need some support. In the worst case I'd suggest to remove the "sort by tags" and "sort by rating" feature in Dolphin for KDE 4.0.
    *''expected time of arrival:'' My plan is that all serious bugs get closed until the end of September. No known showstoppers are left :-)
    === Kate ===
    *''current state:'' <span style="color: orange">some missing features & bugs, but usable</span>
    *''contact:'' [mailto:[email protected] Kate Team]
    *''goal:'' The KDE 4 version of Kate should at least inlude the known KDE 3 features with additions. We have some new stuff around already but some old is lacking correct porting (beside new introduced bugs). There is a massive need for bugfixing and help getting old stuff back to work, like printing.
    *''howto help:''
    ** fix printing
    ** fix shortcut settings
    ** rendering bugfixes
    ** config saving bugfixes
    ** testing
    *''expected time of arrival:''
     
    === Printing ===
    *''current state:'' <span style="color: red">showstopper</span>
    *''contact:'' [mailto:[email protected] Alex Merry]
    *''goal:'' Printing support working in all applications that can currently print, with print preview and customisable dialogs; no applications depending on libkdeprint, except for the printing kcm
    *help needed: Most of the necessary API is in place: KPrintPreview in kutils and KdePrint::createPrintDialog() in kdeui.  All current users of libkdeprint (ie: KPrinter) need porting to QPrinter/QPrintDialog/KPrintPreview.  We currently have no way to print pdf or ps files directly (as used by Okular, for example).  See [http://techbase.kde.org/Projects/KDEPrint/KDE4#Porting the kdeprint porting page]
    *''howto help:'' send e-mail to the [mailto:[email protected] [email protected]] mailing list, or email the maintainer of a program volunteering to port its printing support.
    *''expected time of arrival:'' Waiting on API decisions
     
    === Sound ===
    *''current state:'' <span style="color: red">showstopper</span>
    *''contact:'' [mailto:[email protected] Matthias Kretz]
    *''goal:''
    *# no showstopper: do some more automatic tests that all sound devices work as expected
    *# done.
    *#usable KMix
    *#Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a showstopper for notification sounds. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
    *''howto help:'' I certainly want help. But I don't know how I could label any of the tasks as small because for most things you need quite a good overview... :-( Mailinglists: [mailto:[email protected] [email protected]] or [mailto:[email protected] [email protected]], IRC: #phonon ping Vir
    **Local audio playback is working quite OK, but there are some issues that are still open:
    *** https://bugzilla.redhat.com/show_bug.cgi?id=284171
    *** Sound hardware/ALSA setup
    **** Currently the default list of audio devices to use is in arbitrary order. This needs to be fixed otherwise esd, artsd, jack or S/PDIF output can turn up as most preferred device and make it look like nothing is working. This might need something along the lines of a "hardware database".
    **** There's a report that outputting to a dmix: ALSA device using a hardware mixing capable soundcard made mixing not work at all (don't ask me why), so the ALSA device name choosing algorithm might need to become a bit smarter. I think the safest bet for now is to use the default:CARD=... device string, but with that you can only choose what card you want, not what device on that card (I don't have hardware where this would make a difference, so no idea if it's needed).
    ****  Even though defaults.pcm.ipc_gid is set to audio and defaults.pcm.ipc_perm is set to 0660, dmix does not work for more than one user at the same time (both users are in the audio group). A workaround is to set ipc_perm to 0666, but a real fix would be nicer.
    *** kmix is not in a good state (yet). Also it still does not react on plugged/unplugged soundcard or new/removed software control.
    *** Playing short sound files sometimes only plays the start of the sound (which can be almost nothing). This is a big problem for notifications. Some reported that this is a bug in xine-lib, but I have not looked into the issue.
    *** xine-lib behaves bad wrt. memory allocations. run e.g. mediaobjecttest in valgrind --tool=massif
    *''expected time of arrival:'' For 4. I have no idea because I don't know the cause. 3. is a bit out of my scope, though I might come up with a test app that does what I want soon...

    Latest revision as of 18:56, 11 October 2023

     
    Proposed for Deletion
    This page has been proposed for deletion for the following reason:

    Empty page.