Today I want to announce a new Qt application called transqript.
Transqript can be used to bring interviews etc. that have been recorded as an audio file into written text.
Originally I wrote it as a christmas present for my wife since the free-as-in-beer application that was recommended for this task before was only available for Windows (and my wife uses Linux of course). The second point was of course to try out some classes in Qt and have a real life test application for that. Since my wife got a lot of questions regarding transqript I decided to clean the code, add some features and make a real windows installer too. You can download the installer or the sources required to build transqript from the sourceforge page.
Please be aware that transqript is still in a pre-alpha state, that means it looks really ugly and there are bugs in it!.
If you use transqript and you find some bugs, please enter them in the bug tracker. I will try to fix those bugs and I plan to release a new version every 2-3 months.
Have fun with transqript!
Heute möchte ich transqript vorstellen.
Transqript ist gedacht um insbesondere Interviews zu transkribieren die vorher als Audio-Datei vorliegen.
Ursprünglich habe ich es als Weihnachtsgeschenk für meine Frau geschrieben, da die dafür empfohlene Anwendung leider nicht unter Linux verfügbar ist. Da uns viele Fragen nach dieser Anwendung erreicht haben, habe ich sie nun ein bisschen aufgeräumt und stelle sie nun der Allgemeinheit zur Verfügung.
Da transqript noch sehr neu ist, enthält es bestimmt noch einige Fehler die ich aber in kommenden Versionen ausräumen möchte. Falls jemandem Fehler auffallen oder neue Funktionen einfallen, einfach in der Fehlerdatenbank eintragen.
Viel Spaß mit transqript!
Friday, July 13, 2012
Saturday, September 3, 2011
finally 4.7.0
Weeks after we started, we finally managed to get out the KDE 4.7.0 release.
Only after TheOneRing asked me several times about a new release (either a last 4.6 release or the 4.7.0 one), I finally gave in and told him what I know about the KDE on Windows release process... We needed quite a while to get most packages building again, very likely because our buildserver was stopped already some months ago due to lack of maintainance time. Also the splitting of the kdeedu & kdegraphics packages had not been done when we did our last release (KDE SC 4.5). But now we added new buildscripts and fixed our packaging scripts so now we welcome more packages to be split up (kdesdk or kdegames perhaps?).
Since I couldn't put everything into the release announcement, I want to add some more stuff over here:
Since I couldn't put everything into the release announcement, I want to add some more stuff over here:
- Our release contains the latest version of Digikam (which is 2.0.0)
- Also, there are now both skrooge and kmymoney available.
- besides the kdepim package, we also ship a beta version of zanshin, a todo application based on akonadi.
- a small but still nice scanning application is skanlite, which just works...
- also contained are Amarok 2.4.3, Kile, Quassel, Konversation, KRegExpEditor and KRecipes.
Monday, August 8, 2011
Desktop summit midtime summary
Ok, the first 3 days of desktop summit have passed, I met a lot of old friends, met some new people, looked into some issues in several projects, went to the parties....
One of the things that comes to my mind from time to time is software accessibility, so I heart both the talks of Frederik Gladhorn about Qt accessibility and Peter Grasch about simon, a voice recognition software. He already provides a windows installer (based on KDE on Windows), so now I am trying to integrate simon into emerge so that it can be distributed both within the KDE on Windows installer and with a self contained NSIS installer.
The second thing I looked at was skrooge, I fixed some build errors and so I expect that skrooge will be in the next KDE on Windows release. Which actually also brings me to the next point:
The next binary release is near, at the moment we are preparing the release, update the 3rdparty libraries, cleaning up our buildserver etc. (well, it is mostly TheOneRing doing it - a big thank you over here). In a couple of days we will start again the builds, so binaries will be there in some weeks time too. We are not yet sure which software we package, I will probably announce this again, if you have special wishes, please let us know on our mailing list: kde-windows@kde.org or here in the comments.
One of the things that comes to my mind from time to time is software accessibility, so I heart both the talks of Frederik Gladhorn about Qt accessibility and Peter Grasch about simon, a voice recognition software. He already provides a windows installer (based on KDE on Windows), so now I am trying to integrate simon into emerge so that it can be distributed both within the KDE on Windows installer and with a self contained NSIS installer.
The second thing I looked at was skrooge, I fixed some build errors and so I expect that skrooge will be in the next KDE on Windows release. Which actually also brings me to the next point:
The next binary release is near, at the moment we are preparing the release, update the 3rdparty libraries, cleaning up our buildserver etc. (well, it is mostly TheOneRing doing it - a big thank you over here). In a couple of days we will start again the builds, so binaries will be there in some weeks time too. We are not yet sure which software we package, I will probably announce this again, if you have special wishes, please let us know on our mailing list: kde-windows@kde.org or here in the comments.
Thursday, June 23, 2011
update
Nearly half a year after my last blog post I just thought I would share some news with you.
First of all I became father of a cute boy in february - which limits my time (especially for KDE) quite a lot. Because of this I thought about stopping my work for KDE on Windows completely but I couldn't really live without it ;-).
This also means that our build server slowly stopped working in the past months. This is partly due to size constraints (one of the buildprocesses filled its quantum again) and due to a bug in jom which will only happen after quite some time.
One of the questions that comes up quite often is when we will have another binary release. The current plan is to release KDE 4.7.0 more or less together as all the Linux distributions and maybe add another release of KDE 4.7.X later this year.
Another big issue for us is the transition of our emerge build scripts to git. This brings multiple things with it that are no easy-to-solve questions:
At the moment we recommend that you install a svn client (e.g. TortoiseSVN is my personal choice) and checkout emerge. One of the ideas that came up were that we could easily distribute our scripts from now on as a tarballed git repository (and maybe bundle it with git & python executables).
At the moment emerge uses different categories for different minor versions of KDE, e.g. kde-4.X/kdelibs etc. With Git, we want to move that (at least in the future) into branches of emerge; This would make it possible to easily build & develop older versions of KDE without interfering with more up to date KDE builds.
Together with PovAddict, I already started some tests for the git transition (he ran the scripts etc, and I tested it ;-)) but we came across a problem that is probably singular to us:
KDE git repositories do not allow crlf files inside the repo so we need to translate all of our files to lf EOLs on the server. In our checkout, we need to have some files as crlf (think of batch files and patches) and some files as lf only (the python stuff). My guess at the moment is that we should turn
So far for now, more information, especially on our google summer of code project this year (which is about the kdewin-installer). hopefully later.
First of all I became father of a cute boy in february - which limits my time (especially for KDE) quite a lot. Because of this I thought about stopping my work for KDE on Windows completely but I couldn't really live without it ;-).
This also means that our build server slowly stopped working in the past months. This is partly due to size constraints (one of the buildprocesses filled its quantum again) and due to a bug in jom which will only happen after quite some time.
One of the questions that comes up quite often is when we will have another binary release. The current plan is to release KDE 4.7.0 more or less together as all the Linux distributions and maybe add another release of KDE 4.7.X later this year.
Another big issue for us is the transition of our emerge build scripts to git. This brings multiple things with it that are no easy-to-solve questions:
At the moment we recommend that you install a svn client (e.g. TortoiseSVN is my personal choice) and checkout emerge. One of the ideas that came up were that we could easily distribute our scripts from now on as a tarballed git repository (and maybe bundle it with git & python executables).
At the moment emerge uses different categories for different minor versions of KDE, e.g. kde-4.X/kdelibs etc. With Git, we want to move that (at least in the future) into branches of emerge; This would make it possible to easily build & develop older versions of KDE without interfering with more up to date KDE builds.
Together with PovAddict, I already started some tests for the git transition (he ran the scripts etc, and I tested it ;-)) but we came across a problem that is probably singular to us:
KDE git repositories do not allow crlf files inside the repo so we need to translate all of our files to lf EOLs on the server. In our checkout, we need to have some files as crlf (think of batch files and patches) and some files as lf only (the python stuff). My guess at the moment is that we should turn
core.autocrlf=false(which we already do) and at the same time add a .gitattributes file which contains
*.cmd eol=crlfor something like that (if you have more ideas, please let me hear them).
So far for now, more information, especially on our google summer of code project this year (which is about the kdewin-installer). hopefully later.
Wednesday, December 8, 2010
a new compiler error
While I am currently trying to get KDE on Windows up to a releasable state again (nearly done ;-)), I found an interesting compiler error with the new Visual Studio version (2010):
Why could the above fail? Right, because NULL is not of type class Andere. (That works on the other compilers we have...)
...
class Andere;
class Klasse {
public:
Klasse() : bc(NULL, NULL){
}
private:
std::pair<Andere*, Andere*> bc;
};
...
Why could the above fail? Right, because NULL is not of type class Andere. (That works on the other compilers we have...)
Saturday, June 5, 2010
sprint
Ok, long time no blogpost, but now that we speak about it at our KDE Windows sprint in Osnabrück, I'll try to make up a new blogpost.
Lots of discussions are going on here since a lot of time has passed since the last meeting in 2007, I will try to sum them up in a later point in a dot story.
As you can see from the picture below, the very minute we started the sprint, the sun came out.
Finally after bad preparation from my point we still managed to find together:
back: Patrick Spendrin, Ilie Halip, André Heinecke
middle: Patrick von Reth, Ralf Habacker, Romain Pokrzywka
front: Bernhard Reiter, Andreas Holzammer
Lots of discussions are going on here since a lot of time has passed since the last meeting in 2007, I will try to sum them up in a later point in a dot story.
As you can see from the picture below, the very minute we started the sprint, the sun came out.
Finally after bad preparation from my point we still managed to find together:
back: Patrick Spendrin, Ilie Halip, André Heinecke
middle: Patrick von Reth, Ralf Habacker, Romain Pokrzywka
front: Bernhard Reiter, Andreas Holzammer
Thursday, January 7, 2010
Well, since Aaron raised one or two issues, I'll take the time to blog again.
Our primary goal for KDE on Windows is easy installability and a complete and stable KDE on the Windows platform. So the question is - where do we start?
Aaron mentions that our installer seems to be way more complicated than installing Linux and that a simple fire and forget installer is far better for a broader audience.
This is probably true and was already part of some discussions. The task of rewriting the packaging format is also not the biggest part. More tricky is the problem of updating the core package, which would then contain quite a lot of smaller libraries which are now handled by the installer. And the second point is: If you want to install more than one package, you might find a package manager far more convenient (on a side note: it is near to impossible to use the .exe installers as packages from inside the kdewin-installer). This part of course gets less important if you want to install just Amarok or just Digikam.
The second point Aaron brings up is how we see ourselves. Aaron says that it could bring a lot more for KDE if we see ourselves as the ones to deliver the libraries for other application developers and at the same time be our own consumers (in our role as the ones who deliver the applications).
The equivalent model would be the java runtime environment vs. java applications. I have been thinking about this model already for quite a while and it never really has vanished. On the other hand I must say that I think the priority is wrong. Until recently an external KDE application was not compilable out of the box on top of our packages (thanks go to Alex Neundorf for fixing it). A whole lot of shiny new KDE technology has no working backends under Windows (think of solid) or is really unstable (phonon). There are really basic bugs like you cannot copy files from one drive to another (recently fixed in kio_file), and last but not least on a lot of corners you don't have any system integration for your applications (this is somewhat similar problem to the missing backends). Personally I consider those issues far more pressing because I benefit from fixing those issues when using KDE applications.
On a more personal level now as it is already getting late:
One of the funny things is the usage of the word 'we' in and around KDE on Windows. This can have multiple different meanings: All the folks working on Windows (which excludes people not working on Windows), the people that distribute their software via the installer (excluding KDAB which uses a single installer for kontact), and not to forget the 'we' Aaron uses where he includes himself. That there is a difference between the first two has been made obvious here but I think those issues have been solved now more or less. The third 'we' is a general KDE one and sometimes also looks from outside: If 'we' have to change our way of thinking, then it is of course not the 'we' including Aaron who has to do something but the other two 'we'.
Enough ranting for now.
Our primary goal for KDE on Windows is easy installability and a complete and stable KDE on the Windows platform. So the question is - where do we start?
Aaron mentions that our installer seems to be way more complicated than installing Linux and that a simple fire and forget installer is far better for a broader audience.
This is probably true and was already part of some discussions. The task of rewriting the packaging format is also not the biggest part. More tricky is the problem of updating the core package, which would then contain quite a lot of smaller libraries which are now handled by the installer. And the second point is: If you want to install more than one package, you might find a package manager far more convenient (on a side note: it is near to impossible to use the .exe installers as packages from inside the kdewin-installer). This part of course gets less important if you want to install just Amarok or just Digikam.
The second point Aaron brings up is how we see ourselves. Aaron says that it could bring a lot more for KDE if we see ourselves as the ones to deliver the libraries for other application developers and at the same time be our own consumers (in our role as the ones who deliver the applications).
The equivalent model would be the java runtime environment vs. java applications. I have been thinking about this model already for quite a while and it never really has vanished. On the other hand I must say that I think the priority is wrong. Until recently an external KDE application was not compilable out of the box on top of our packages (thanks go to Alex Neundorf for fixing it). A whole lot of shiny new KDE technology has no working backends under Windows (think of solid) or is really unstable (phonon). There are really basic bugs like you cannot copy files from one drive to another (recently fixed in kio_file), and last but not least on a lot of corners you don't have any system integration for your applications (this is somewhat similar problem to the missing backends). Personally I consider those issues far more pressing because I benefit from fixing those issues when using KDE applications.
On a more personal level now as it is already getting late:
One of the funny things is the usage of the word 'we' in and around KDE on Windows. This can have multiple different meanings: All the folks working on Windows (which excludes people not working on Windows), the people that distribute their software via the installer (excluding KDAB which uses a single installer for kontact), and not to forget the 'we' Aaron uses where he includes himself. That there is a difference between the first two has been made obvious here but I think those issues have been solved now more or less. The third 'we' is a general KDE one and sometimes also looks from outside: If 'we' have to change our way of thinking, then it is of course not the 'we' including Aaron who has to do something but the other two 'we'.
Enough ranting for now.
Subscribe to:
Posts (Atom)
Posts
