Category Archives: JuK
I know I was hardly working on JuK lately (not at all to be true), due to other favoured projects as building a own agent based system monitoring framework. I’ve given up that task though, it’s a lot of quite complex work doing this cross-platform (all flavours of unix and windows, mainframe interfaces etc).
Also, I completely underestimated the “pro-active monitoring” suites, which is basically easy if you do it protocol based, but a lot of harder concept-wise.
Besides that it’s a lot of work, I proved my current concepts quite wrong, and have no intention to start over from the start there again.
I decided I’ll work some on JuK again. I was using Amarok lately, because all people say it “rocks”. Maybe it “rocks”, because on my desktop it does play rock (metal) music. But the application itself? I don’t know. I have not succeeded yet getting Amarok to play my playlist randomly, and repeat the playlist. I can just “sort” it randomly by clicking, what’s not too nice in my eyes, while I couldn’t find the “repeat playlist” at all, not even after spending 30 minutes looking + using google. I’m pretty disappointed about that.
So – what’s next? I’ll move on now, no, not away of KDE, but back to JuK. I’ve plans spending some time again there, and I’ll definitely start out porting the last parts of JuK to Qt4 before messing around with other stuff (playlist management in example). I’d also like to make some changes to the UI, especially the playlist / collection management, but I’m not sure how many guys would disagree with that :-).
Anyway, I decided I’ll take the task of finishing the port, to get it pushed by mpyne again, and will apply for an SVN account then. I’ll go on porting first to see if I really have enough time contributing to KDE.
I won’t continue developing / porting JuK for now. The reason is quite obvious, and a very sad one. Michael has some personal difficulties, and stepped down (for now) as a Maintainer, not contributing for some time to KDE – for now. No other member of the kde-multimedia community answered my request for reviewing my patches. This most likely means, nobody is interested at all. Since I have no intentions to step in as maintainer, until Michael is back, I’ll simply wait for his return (hopefully he will be back one day).
This means, in favour of my current new playground project, I’ll drop continueing the development of JuK – at least until Michael is back.
Last but not least, Michael: Take the time you and your family need. We’re all with you with our mind, soul and heart.
For QTiNT: I didn’t get along too well. At work, I’m missing the time, due to the reason that a colleague of mine is in holidays (which causes a huge amount of workload to me *grr* – start doing things right Markus!).
I’ve been busy with getting my ubuntu 32bit kvm running for oracle-xe (couldn’t get oracle installed on arch linux, and oracle-xe which I prefer for playgrounds has no 64 bit version), and getting the server side of TiNT running on my laptop, so I can continue working at home.
I’m done so far, but it seems as if the first data import failed at some parts (views), which causes some problems which I hope to solve tomorrow, so I can work on that this weekend.
Since I don’t feel too well (I’m a bit ill), I’ll spend a lot of time at home this weekend, and should have a lot of time to get something done.
@Lore: <wave> ;-).
Sometimes, bad things happen. Most likely, it’s yourself making mistakes. Yesterday, Michael told me that for the covermanager patch there were missing two files – covermanagermodel.h and covermanagermodel.cpp – in one of the reviews I published. Obviously I forgot to add them to svn before doing a svn diff.
Even worse than that was, that I deleted the branch already (why did I do this? Am I insane? to save some mb space?). Anyway, due to that, I lost the two files. The good part was that they’ve only about 80 lines of code together, so not much to rewrite. But what did you think, about two month ago, when you wrote this lines? Since I couldn’t remember I had to rewrite the covermanager patch from scratch. I bet it’s better now anyway :D.
This is a warning, ALWAYS backup the branches until they’re commited to SVN by the maintainers. That can save you some time, in my case just about an hour, but what if it was a larger patch?
Woooho, back from my vacations. It was a great time in Croatia – I love that country, the people, the sea – just everything. I’ve been on the island Hvar (2nd time already) which has been very nice.
I did some deep water soloing, and plan to do so again next year. It’s just great, a lot of fun. Next to that, I really relaxed a lot, read several books (NON technical ones, except the python book which I wanted to finish for over a year now). Pictures of my vacations will be uploaded later, as soon as I got them. I was intelligent enough to buy a water protection for my camera, sadly, it broke on the cliffs, and by jumping into the water, my camera broke as well. A friend of us made some more pictures, which I’ll get some time. As soon as I receive them there will be picture time here.
All the holiday and relaxing thing means – I’m back, with new power, and intentions to get my last tasks done.
I’ve not gotten any step further in my holidays on removing k3support in JuK. Even though, I had my laptop with me and a bunch of time, I simply didn’t have any intention to work at all (to be true, I didn’t even take the laptop out of the car), but rather enjoyed the sea, spare time, and people and beer there.
Sadly it seems as if the version for the next major release of KDE has been reached, at least I guess so, since Michael wrote that in his svn commit, and I’m not really aware of all the release politics in KDE – and I’m not really interested in those things (thanks Michael for caring :D).
The good point, he finally pushed my patches, means I don’t have to work on 4 different versions of JuK (having no local branches in this case is hard, and for some reason I’m not really satisfied with git-svn :D), and I really want to work on the last huge patch of JuK, removing all remaining k3support. It’s pushing me that I want to work on features instead of porting, so I’m very motivated finishing this one.
Did you ever wonder “Why the heck there is JuK? Why are there guys working on it?”? I’ve been asked this question some times now when I told somebody I’m spending time on JuK. But what is the reason for this? Basically nobody bothers using JuK.
Of course, we know that there is Amarok around. We know it has a lot of more features, and is a better MP3 Player than JuK will ever be. Maybe, Amarok will replace JuK one day in KDE, even though, I don’t know why it is not replaced already. I think the Amarok team doesn’t want to handle with the KDE release management, but have their own.
Well, I’ve my reasons to develop JuK. First of all, I use it as a MP3 player. It’s my favorite for NOT having a lot of options, it just works, and just plays music. That’s important to me, allthough, I also have Amarok installed, using it when I can’t use JuK because I work on it at this time.
The second reason is, that JuK needs quite a lot of work. It needs to be ported to KDE4 (remove k3support, which I have pretty much now). Also it would be needed rewriting the JuK backends, the interface could need some love as well, an options dialog would be great and so on. So you see, there’s a lot of interesting stuff to do. Stuff, I’ve never done before, never bothered with, things I don’t know, new things.
Even when I’m not getting along as I’d like to (my social life is time hungry), I can learn a lot of stuff working some on JuK. Even when nobody bothers using the program, I’ve fun developing it, I like it, and I want to learn by working with people as Michael (who’s a really great guy, as the rest of the KDE community).
As you can see, mostly selfish reasons. Yea, I’m a selfish person from this point of view, because I probably could help somewhere what really matters. The thing is, it’s my free time, I can do what ever I want, and I currently like what I’m spending the little spare time I can enjoy in front of the PC on.
Not said, that I won’t move on one day. If JuK gets replaced as the “default”, I probably will be looking for something else to do, or I keep with JuK. But until then, I enjoy my free time on what I want.
And now please stop asking “why the heck are you wasting your time?”. I don’t waste it, I enjoy it, and can learn within that, and I’m learning Qt and some KDE development (and Qt is a great framework). Just because I’ve developed much more complex things in the past, doesn’t mean I enjoyed it nor it means that I always want to keep on with projects I’ve been working on for almost 7 years now. Yes, I had a lot of fun writing the firewire drivers for industrial cameras, yes I had a lot of fun in image manipulation and cascade calculation, object recognition, AI systems and so on. It was just time to move on, to do something different. I enjoyed working with you, all of you (no names). You’re a great bunch of guys, but please consider that you’re paid for that, I am not. I spend my spare time on what ever I want, and my personal interests changed.
None! Yea, I’m a bit lazy lately. I’ve started two new things in JuK development.
First of all, I’m still on removing k3support of the playlist. This is a quite huge task, and even needs a little part of refactoring the playlist down even to the core playlist.cpp which uses klistviewitems.
Secondly, I started refactoring the backend to something more modular. The current layout not existing abstraction of the playlist from the caching backend (not providing a clean api to use) is blocker for implementing mutiple backend interfaces as a QSLITE or MySQL interface, or even other data storage caches.
Also it makes it nearly impossible to thread the playlist reading, or to make the playlist “fetchmore” compatible. The first step on this which I’ll take is to split the data backends clearly from the main playlist handling code of JuK Also, it must be considered how to handle playlists in the future. Different data backends provide different posisblities.
I hope one day, as soon as those basic things are solved, we can move on improving JuK in a visible way.