27th August 2006by Danny Allen
The problem is that big libraries like GStreamer or Xine reimplement a lot of stuff we already handle in Qt or KDE, object management, IO-slaves, threading etc.
My hope with avKode was that when combining a powerfull decoding library like FFMPEG with the powers of KDE and Qt there wouldn't be much code missing to get a good decent media backend. I've implemented a QWidget for XVideo output, an audio-video synchronization class, a KIO stream wrapper and a FFMPEG decoder wrapper. This is really all that was needed. But there have been some ugly things as well.
The hardest part has been fixing and working around bugs in FFMPEG. The timings FFMPEG reports varies from always 0 to mostly bogus, and length of MPEG files is always reported as being 40ms; just to mention a few huge FFMPEG bugs. Fixing or working around this stuff is really duplicating work already done in the other libraries, and I am really hoping I will soon have most of the major problems nailed, otherwise avkode might turn out to have been a less good idea.
Fortunately the other part of my SoC project, implementing random KIO access, seems to be working fine and have already been commited to trunk.
I think it's important because I'm especially bored of using full-screen calendaring applications. They pretend to be like a calendar on your desk, but aren't really as they aren't as static (unless you have a second display and leave Kontact or something maximized). In my experience, people in offices would either have their calendar memorized anyways, or be at the mercy of reminder dialogs, which may appear after the subject had left to go get coffee :)
My answer is to have this information, which is exceptionally important, to be always visible while allowing the person give as much focus to the job they should be doing. Then I could probably take down the huge whiteboard calendar I have on my wall.
In practice this appears as a nifty linear clock on any edge of your screen. Very simple, yet different and full of information. You may find you view your day differently as it makes you acutely aware of how much of it is gone already ;)
It doesn't aspire to replace KOrganizer, as KOrganizer is always going to be better at a lot of things. The aim is to complement its capabilities.
The stuff in SVN is kind of old, and after talking to many people about the things it does I'm going to be changing a lot of stuff in the near future.
Here is a mockup of some projected capabilities, and an actual screenshot of the Sleek bar in use - i've been experimenting with different things to make the visuals match the name.
I started coding, but there is nothing worth showing yet. Most of my time is currently spent in discussions with the tapioca (which nowadays implements the telepathy spec, which I consider to be great news!) and telepathy people. There are still some areas that are somewhat hazy to me (or just not properly spec'd out ;-). The existing tapioca Qt4 bindings are mostly defunct, so that is another area that I need to spend more time on than originally estimated.
Near term goals:
Give a presentation about decibel at Akademy in Dublin and have a somewhat-working prototype of Houston, the platform-independent part of Decibel, by then. I am not yet sure whether I'll really make it, but I have high hopes.
Long term goals:
To provide a framework that makes integration of communication and collaboration features into applications as easy as possible. Wow, that is a sentence full of buzzwords, but I do not know how to explain it better ;-)
Basically I'd love to see things like whiteboards that are accessible form many applications so that people can share ideas over the network. Simpler things like better integration of real time communication features into existing applications.
Think about better integration of your real time communication mechanisms into existing applications. Having real-time communication integrated into your mail client springs to mind here: In your list of received mails there could be an icon representing the presence state of the mail senders on networks like ICQ, Jabber or whatever and you can start a chat session with them with one click.
We would like to simplify the way accounts on real-time communication services are handled. A user wants to do things like "chat with my friend X". This does not include subtasks like figuring out which of the installed programs can actually speak the protocol used by the service X frequents, etc. What we envision is that the user selects a contact to talk to (or chat with or video-stream to) and then Houston selects a protocol to use, helps the user with creating an account on the service (if required), puts the user online on the service and fires up the preferred application to handle the protocol used.
What it will bring to the developers:
Not having to worry about the low level details of real-time communications, thus reducing the number of lines of code to integrate features based on that technology into their code.
We strive to provide a framework that people can connect to over D-Bus, implementing only those components that they need to implement to set them apart from their competitors while relying on those provided by Decibel for the rest of them. The Telepathy spec at freedesktop.org already reaches that goal for the low level components of the framework (the Connection Managers that implement the wire protocols, etc.), but there is no framework yet for high level components like chat windows, VOIP dial windows, etc. to plug into Decibel will provide that.
What it will bring to the users:
We hope it will bring better integration of communication and collaboration features into applications :-)
Besides that we hope to improve on the stability of real-time communication software by subdividing the functionality in easy to test parts that communicate over D-Bus. D-Bus isolates the different parts of the system from each other. If for example the IRC Connection Manager dies then the rest of the application will be notified of that event, but the ICQ and SIP streams handled by the same application will not get interrupted.
Then we want to allow the user to centrally manage his communication settings and accounts. This allows him to do things like set his presence information to "away" for all his accounts on all the communications networks he uses.
Sponsorship for my KDE work has never been something that I've sought. KDE is one of my hobbies and I'm fine with it staying that way. (Not to mention that I have to have normal full-time employment to remain in Germany where I've been for several years.)
So, then what's with Tenor?
Like I said above, KDE is my hobby. Sometimes I feel like working on it, sometimes I don't. (My life has also been really busy in the last few months, but really it's more of a matter of motivation than time.) When I don't feel like working on it, I don't. It's really that simple.
The desire to work on Tenor for me comes in waves. A couple months back I spent a few weeks hacking on it again. I haven't touched it since then.
So, will Tenor be in KDE 4?
Maybe. Really it depends on if and when I feel like hacking on it or if someone else decides to pick it up and run with it. Think of it as a surprise. ;)
|Commits||2813 by 224 developers, 6435 lines modified, 2445 new files|
|Bugs Opened||304 in the last 7 days|
|Bugs Closed||291 in the last 7 days|
||Rinse de Vries||
Internationalization (i18n) Status
Bug Killers and Buzz
|Aaron J. Seigo||
There are 79 selections this week
More stability - this time, allow the user to close a project and/or
kdevelop while background parsing is progressing.
Add mutexes to KDevLanguageSupport which can be locked to protect
language support resources while processing continues. This is a
per-thread mutex because otherwise all the background threads sit around
while one executes (which kind of defeats the point).
Extend abort + lock support to c# and java parse jobs.
Lock the smart interface mutex before it is deleted (thus preventing the
editor from disappearing)
Instead of dequeueing pending jobs (which doesn't give you a definitive
dequeued signal... yet?), abort them all. Not 100% right because the
progress bar gets stuck.
Fix the smart interface in the editor integrator so that
1) the smart interface doesn't suddenly appear while parsing
2) the lookup doesn't have to happen all the time.
Remove queue policies from jobs which haven't executed. This is in an
attempt to stop access to deleted policies in job destructors.. Didn't
work initally, but might actually be working now (will have to test).
For the moment the policy deletion is commented out.
Add projectClosing() signal to KDevProjectManager, so that you can do
stuff before the project has closed.
Maybe now I can get back to some features...
Obey the transparancy setting in the custom image dialog. Note that it changes the opacity of the initial layer, not the fill color of it (just like it used to do before, iirc).
Maybe fixes this crash on startup. I can't reproduce so I can't be sure.
RC2 will be released tomorrow or today if I have time.
* Display classes, members etc. with access policy and modifiers
* Add support for constants
That's it, people - so much for the C# SoC!
Of course, there's still a million things to improve,
so don't expect me to disappear too soon :D
Maybe with less time invested though.
Thanks for everyone's support and welcoming attitude!
Add top-level UI mode and docked window mode to kdevelop 4.
This should be roughly analagous to what designer 4 does. Right
now, the top-level UI mode does not place the top-level windows
in any kind of smart manner, but everything in time... Top-level
UI mode should be good for Xinerama users and those who want a UI
similar to designer or XCode.
This patch completely changes the API for KDevMainWindow and how plugins
are inserted into the UI. The API has been simplified and I've modified
all the plugins to use this new API. Individual plugins that inherit
KDevPlugin no longer need to worry about adding themselves and removing
themselves from KDevMainWindow as this is accomplished by the plugin
However, individual plugins that inherit KDevPlugin and wish to have some
sort of UI need to override a couple of new virtual functions in KDevPlugin.
1) virtual Qt::DockWidgetArea dockWidgetAreaHint() const;
2) virtual bool isCentralPlugin() const;
3) virtual QWidget *pluginView() const;
The docs for these methods can be found in KDevPlugin. The quanta devs
will want to modify their plugins to use this new API.
In order to switch between UI modes, I've created a new KCM. In the future,
this KCM might hold other UI options, like whether a taskbar entry should
appear for plugin windows in top-level mode or whether the mainwindow should
always stay on top... etc, etc.
This is all still very rough, but you have to start somewhere, right?
digikam from trunk : albums gui : New menu option to force the refresh of album contents. The thumbnails will be recomputed by digikam kio-slave.
Note: The keyboard shorcut for this action is F5
Implementing choose-connection-by-url, instead of hardcoding it.
I used a syntax similar to existing obex:/ ioslave from kdebluetooth, and i also used bluetooth as a fallback when transport is not specified, so now our kioslave can replace kdebluetooth one.
Thanks martirc for his good work here.
Added support for status information to PIM::AgentInstanceModel
and make use of it in AgentInstanceView.
Furthermore added nice icons for the ical and knut resource.
To test the live status information update, just start akonadi_control
and akonadiconsole, then add a new knut agent instance and see...
do not hardcode colors in article list. Make them configurable now with hardcoded defaults, as soon as the new extended color scheme with colors for unread and new is in place, these defaults will be used.
This is KDE4 only, I will request to add it for 3.5.5, too.
show error messages in the htmlpart instead of using annoying popups
Initial import of kspread kexi import filter.
Import selected tables/queries + custom sql statement from a .kexi (file based) database.
Each table/query is a seperate sheet
Field names on top row in bold/ligh gray bg
Hope the commit works!
Due to popular request: allow freehand painting strokes to start outside the image area. This would be especially handy together with wishlist item 132759
*Now I'm using Mongrel <a href="http://mongrel.rubyforge.org/">http://mongrel.rubyforge.org/</a> instead of WEBrick
to provide HTTP functionality to the DAAP server due to some blocking bugs of the latter.
*So is now the server is now known to work with both Banshee and Amarok as clients!
*I've imported Mongrel (which has a small C extension) into Amarok and quickly descended into Makefile.am hell. So I could use some help again. :) The first mongrel directory is currently not in SUBDIRS.
Added support for multi AudioOutput on each AudioPath. GraphHandler has been refactored. GraphHandler needs fixes in nodes deallocation and on sink nodes connection to the rest of the branch. The graph is constructed for the first sink, then the other sinks are connect without caring about different formats (needs to be fixed addind a node lookup in stage3 to add a converter node before the sinks with different input formats)
Robert Wadley had a very cool idea: he created a K3b theme with transparent widgets that adjusts to the selected KDE color scheme.
It turned out to be very simple to adjust K3b to fully support this. In doing so I also improved the design of all the K3b themed windows and made sure they reacted properly on KDE color scheme changes.
Introduces a number of new things:
1) A transactional algorithm to safely modify files (with either complete success or complete failure) has been implemented to make saving tags safe(r?). This is contained in the new helper class MetaBundleSaver. Class usage is easy: create an instance, call prepareToSave() to get a taglib fileref pointer, do you work on that fileref, call doSave(), then cleanupSave(). Cleanup is separate in case you decide not to do the doSave()
call after all, for instance if you encounter an error when working with the fileref.
2) MetaBundle gets a new method: safeSave(). Call safeSave() in place of save() to transparently use this transactional save method. This will update the same tag fields as a call to save() does.
Note there are some minor bugs to be worked out with MetaBundleSaver, namely that it seems to sometimes miss KIO's signals, but other than that it seems to work well.
Implement a new method of breaking up texts that are too long to send in one message.
- text displayed in the window matches what is sent to the server
- works only for channels and queries
- should work with all supported encodings, but this will need heavy testing - multibyte especially
- patch includes lots of debugging lines, change the KV macros to kdDebug to enable
Added support for passing an URL via the command line.
- add support for notications on tooltip requests. X11 only and makes it
possible to implement dynamic tooltips. Requested at http://lists.kde.org/?l=kde-core-devel&m=115420977227759&w=2
Reduce the time on one of my test cases by 40%... thanks to
Valgrind/Callgrind/KCachegrind. It was spending lots of time comparing
Whoever came up with this cursor + url scheme anyway... oh, that was me. It's not
needed now like it was before, because I've decided not to actually
#include sources in the preprocess stage, but to parse each file
Major speedup brought about by removing QTextStream.
I knew that QTextStream would be a bit of a compromise, but I had no
idea how much it actually was.
This shaves 50% off the time to fully parse a file, so the old code must
be at least an order of magnitude worse.
Anyway, in total I've taken 80% off the time to parse a file... woohoo!
1.1 branch, memory optimisations. A depressing 2MB in 19MB, by using
vectors instead of double-linked lists. Can I save more memory and put
the "bloated" crowd wrong? I'll try, but I expected this saving to do
better! Maybe I should gzip the memory, that would shut them up :-/
Alarm Class Cleanup:
- beginnings of a unit test
- full d-pointer implementation
- complete doxyification
- kdepim styling
- kdepim indenting
- eliminate all krazy issues
Note: this was a non-trivial amount of work for a moderate size class.
In particular, you can go nuts writing apidox. But I hope to use it
as a "template" for further cleaning in kcal and elsewhere in kdepimlibs.
Drop me a line if you are interested in my style checker perl program.
I doubt the style checker will ever be integrated with krazy but I might
put it into kdesdk/scripts if there is enough interest.
Re-activated the KSpread scripting plugin.
* Well, in fact only _one_ single scripting.(h|cpp) is needed now since we are reusing transparently the dbus-adaptor classes to access the whole KSpread functionality on the fly.
* We are not limited to the dbus-functionality since we are also able to manipulate e.g. the Document or the View class direct.
* Arguments as well as returnvalues are just working. Also not limited to the types dbus knows. We are able to pass QVariant's, QMetaType's as well as e.g. QObject instances.
* The unittest.py contains some first examples to demonstrate that. To see the unittest.py in the "Script Manager" it's for now needed tpo add following lines by hand to your ~/.kde4/share/config/kspreadrc file;
unittest_file=/opt/kde4/share/apps/kspread/scripts/unittest/unittest.py (or wherever you have the python-file)
Enabled parts of Krita's scripting-plugin again.
* merged things together
* provide ScriptingModule as with KSpread to have a "Krita" main-/root-module.
* Moved scripting-menuitems to Tools to be more consistent with KSpread and Kexi.
* scripting/kritacore/* is disabled for now. Will be ported later.