In this week's KDE CVS-Digest (all-in-one version):
Beginnings of Subversion support in Cervisia.
Cleanup of initial application sizing.
KDevelop adds Qt Designer support for Python.
IDN issues fixed in Konqueror.
Digikam adds more plugins: Insert Text, Channel Mixer, Infrared, Blur, Distortion, and a new ratio crop tool.
KMail adds an account setup wizard.
Dot Categories:
Comments
From the digest: "Notice all the bugs that were backported."
Why the hell did they do this?
Probably for compatibility reasons. You don't want KDE behaving differently because a bug was inadvertently fixed. Such major changes require a new major version number.
:-)
It should read bug*fixes*, not bugs.
Probably for testing purposes.
No, it's because of the sun spots and the American national debt. And global warming, of course.
Your sarcasm is uncalled for. The man asked a legitimate question.
What legitimate question? Especially, what question that hasn't been cleared up yet?
He stumbled over a little inaccuracy in the digest as I've already explained above. If you had read and understood my comment you wouldn't have tried to find a rationale for something that didn't happen.
I can't believe we're having this discussion...
...the only major bugs still left were:
1) More often than not the new tooltips remained partly on screen
after closing and they were always painted with a black background
so I finally had to disable them. No problem though since they
werent really important
2) Logging in on SSH servers from the remote protocol resulted
in KWallet showing completely wrong user credentials I had to
correct everytime.
Otherwise: Thanks for the most stable release ever AFAICT!
KPDF with disabled DRM by default??
Not that I wouldnt support to leave out this stupid stuff
and this would certainly make KPDF a killer-app for PDF viewing BUT:
I wonder how will Adobes legal team will react on this?
They already sued elcomsoft. They lost AFAIK but who wants to
go through a legal battle with them.
Anyway, if it comes back in there's still "Advanced PDF Password Recovery" ;-)
The statements in the PDF spec about "copyrighted" data structures are pure legal BS. Adobe cannot sue you under copyright law for ignoring their DRM, no matter what their lawyers want you to think.
It is possible that Adobe has patents on ways of implementing the PDF spec, which is a completely different story. If KPDF infringes any Adobe patents, then they could sue. But in this case KPDF is already violating the patents, so removing the DRM wouldn't put KPDF in a worse legal position. Also, the patents probably only apply in the US (at least for now), so many KPDF developers and users would not be affected anyway.
Also, it is possible that the DMCA could make it illegal to use KPDF to remove the DRM from PDFs. However, I don't think it would make KPDF itself illegal (since KPDF is very useful apart from this feature), and I don't think the KPDF developers could conceivably be charged with any crime under the DMCA.
Finally, if it did go to court, I'll bet the EFF would be happy to represent the KPDF developers.
> More often than not the new tooltips remained partly on screen
> after closing and they were always painted with a black background
> so I finally had to disable them.
using a buggy composite manager?
there is one known bug left in 3.4.0 for the new mouse overs. it has to do with the "show desktop" functionality. it's fixed in 3.4.1 though.
Thanks for answering.
No composite manager - just plain SuSE 9.2.
Dont know why the tooltips are black and sometimes remain
on screen but it's not a big problem. I disabled them and do
not really miss them ;-)
do they remain on screen when using the show/hide desktop button?
and would it be possible to get a screenshot of the black ones?
even if you don't use it, i can use this information to make it better for those who do =)
There is also an X11 priority issue.
In some cases, the popup windows have a lower priority than the panel that they pop up from.
--
JRT
KPDF still has DRM enabled by default, the thing is that you can disable it now via a GUI option instead of a ./configure option
From the amarok changelog for 1.2.1:
CHG: Replaced "Blue Wolf" icon with Nenad Grujicic's amaroK 1.1
icon, due to legal issues.
Anyone know what legal issues there were? They replaced the new icon from the kde look contest with the old one?
Seems the creator of the icon has sold the copyright on it before putting it up to the contest. Bad idea.
That's not true, nobody sold anything.
The icon was inspired by some clipart that was found on the web and this clipart happened to be very similar to the logo of a certain company. As the copyright holder, that company had not given permission for the distribution of the clipart in the first place and considered it a violation of its copyrights and trademark. Since the amaroK icon and the clipart were rather similar as well, the company held the same position wrt the amaroK icon.
The lesson that can be learned from this is that you shouldn't _EVER_ contribute artwork to a free software project that isn't totally original and completely made by you. It can bring the project in real problems and result in embarrassing situations for everyone involved, you may also be left with a substantial bill from your laywer.
Then they really should use the second place from the contest, I thought it was better than the winner anyway:-)
It's a pity. The wolf looked great. The current one looks like nothing.
1.3 should have a new icon. The current icon scales and looks professional enough to be used until then.
its a bloody shame, i was quite fond of the new icon. not that it matters, amarok will continue to be an excellent media player regardless of what icon they use.
Didn't knew that KHTML development is still this strong. I counted seven developers that contributed to khtml in some way in this cvs-digest (btw thanks Derek!). Thanks to
Koos Vriezen
Dirk Mueller
Allan Sandfeld Jensen
Harri Porten
Germain Garand
Leo Savernik
David Faure
for their improvements to the best html rendering engine :-)
In case you can, could you inform an ignorant KDE user why this site http://www.toronto.ca/ttc/schedules/index.htm renders poorly/badly in KDE's latest Konqueror release (3.4rc1). When one selects a route and clicks "GO" there should be stations/stops on the left, which when clicked, times show on the right. There is no problem with it in Firefox. Should this be filed as a bug to the developers? Changing the browser identification does not help either.
Thanx.
File a bug to the Toronto transit people.
Derek
Two words: BLAME CANADA
--
Oh my God they killed Kenny! :D
I am using 3.3.2, and everything works except when you click on the station, the times show on the right in a really small frame. About 100 pixels in height. However, I can "grab" the bottom of that frame with my mouse--it's a little tricky because the frame border is invisible. Once you grab the frame border, you can drag it down to the bottom of your browser and now everything looks normal. It seems either Konqueror isn't respecting their frame sizes correctly or the damn Canadian's have a bug in their frame's definitions.
Works for me konqueror 3.4.
No problems at all.
Is there any plan to put all the cool plugins into a shared library so that every KDE application (Krita comes to my mind, but there may be others too) can make use of them? That would be really great.
i believe that's what KIPI* is.
* KDE Image Plugin Interface
No no no :
Kipi multi-images traitements like batch processes using by photo management programs like digiKam, kimdaba, showimg, gwenview.
DigikamImagePlugins: tools to transform/correct/improve a single photograph at the same time (like in gimp for example). It's used only in digiKam image editor !
There no plan to export this tools from digiKam project. There is too depencies with digiKam core and this is a non sence (for me) to put these parts in a shared lib (I won't destroy digiKam project !!!).
A nice day
Gilles Caulier
if other projects could use the digikam plugins (in digikam only used to improve photo's, isnt it?) they would only become better (tested, and they might send patches and write new plugins). digikam's power is not in its plugins (I still use the gimp or kolourpaint, or krita) but in its great interface, search-and-meta-data capabillities. I'd prefer to see you working on these (example: please, let me be able to use the name of the file as meta-data if there is no metadata yet) instead of the plugins. I'd say let digiKam work with krita/kolourpaint/gwenview/etc to create a great pictureviewer with a plugin structure to enhance pictures, and concentrate on digikam itself...
Well, there are some kind of plugins/filters that are really useful to have at hand while using digikam cause they are strictly related to photos management. If I should have to open a particular image app only to sharp a too blurred photo I'm viewing in digikam it would be really uncomfortable.
well, he really shouldn't remove the photomanagement tools, as they are cool. b ut would it not be possible to use eg kolourpaint embedded as a kpart? or gwennview? and as far as these aren't good enough, I'm sure their authors would accept some patches ;-)
Sorry for losing track of this thread -- I'm been down with influenza at the moment. I thought that Kolourpaint also used the Digikam plugins to a certain extent? I must admit that I get confused by all this stuff myself...
In theory, yes, and I've been looking at it quite closely, as has Cyrille. There are a few problems, though. Many kipi plugins are more oriented to batch edits, which doesn't fit Krita. Then, the digikam image plugins seem to work on QImages only, which would mean that Krita would have to convert every layer to a QImage, filter it, and convert it back to its internal representation. It would have been easier to feed pixels to the filter pixel by pixel, but of course, some types of filter don't work on single pixels.
In any case, I think a Krita kipi/digikam ueber-plugin that loads and makes available all relevant plugins would be easy to do and will probably happen some day. It just means that if you use those filters on you cmyk image of 16-bit rgba image you're going to lose some precision.
have you had a look at ksquirrel.sf.net and its squirrel-libs?
I had the impression that kipi is more batch-filters, print-dialogs and other "features", while ksquirrel-libs is just plain image-codecs.
... and another image viewer using openGL... We don't need to use opengl to pay with photographs...
digiKam include now an imagefilter in a core dedicaced to improve/transform/correct photographs.
A nice day.
Gilles Caulier
AmaroK does not like the gstreamer engine. It crashes everytime I select it for use. What I do not like about aRts is the enormous delay between the equalizer display and the music out of the speakers. The display seems to be doing its thing at random! XMMS does not show this. I heard gstreamer would solve this problem.
Read the documenation of amaroK, it explains why the analyser is not in sync when using aRts
GStreamer works here, in fact it's the only one that does =). That's the advantage of multiple backends, you can never tell which one will be borked on any particular machine...
Try Xine.
I can recommend xine. It works perfectly here.
Arts is always skipping and sometimes outputs garbled sound
and GStreamer does not work at all - even on the command line.
I found out on the web that this is a known issue and already fixed
in CVS but I didnt really want to go through all the hassles of
recompiling GStreamer.
The multiple backend thing is really cool because now I still
can listen to my music collection comfortably without using
command-line tools.
Sticked with xine, too. gstreamer, akode and arts are buggy OR are too cpu intensive.
Indeed, arts is very cpu hungry, gstreamer is very laggy (I hit play/pause/stop and it doesn't actually play/pause/stop until 0.5 to 1 second later).
Xine is the only one with acceptable performance.. Xmms with OSS is still much more responsive, but I can deal with the short lag of Xine in trade for all the awesome amaroK features.
If you like Xine, you'll love mplayer. mplayer plays pretty much *any* video or audio codec you can throw at it and it's much less hassle than even on Windows once you install the right packages. =)
MPlayer isn't a back-end for amaroK AFAIK...
They're talking about xine-lib as a backend to amaroK, not xine the video player.
> mplayer plays pretty much *any* video or audio codec you can throw at it
Nowadays, xine does pretty well in that department, too. Kaffeine (using the xine-libs) just works for me in most cases.
In response to the laggy gstreamer thing, consider voting for this bug: http://bugs.kde.org/show_bug.cgi?id=96680
The old layout contained a table with the icons which allowed fast access and a very good overview.
Why was it removed?