In this week's KDE CVS-Digest (experimental layout):
Kicker rewrite merged into HEAD for further testing.
New Kontact summary plugin for dates and holidays.
kttsd adds support for Festival 2.0 MultiSyn voices.
KDevelop has a new Ruby source code debugger.
Dot Categories:
Comments
Optimizations on a global level are always nice :) On the downside, nothing new for Kooka... I don't use the scanner that much, but I know people who do and keep wishing for improvements. If we compare it to how it was one year ago, there are barely any changes.
Indeed, optimizations are very nice.
Windows is getting slower all the time while KDE is getting faster :)
Yeah, kooka must be a paradise for usability experts. Such a powerful program with such a pity UI... :-/
Beyound UI-horror there are still some stange errors in interaction with sane no other scan program has.
Bye
Thorsten
Hi Derek - thanks for reporting about the Ruby Source Code Debugger checkin.
I'm really pleased with how it's turned out. With Qt Designer integration and now the debugger KDevelop is a very powerful ruby programming environment..
For more info, here is the full text of the commit:
* Ruby Source Code Debugger initial checkin
* Based on John Birch's gdb front end, the UI is very similar. There are no
assembly language step options or disassembly viewers, but pretty much
everything else is much the same in ruby as for gdb/C++.
* You can set breakpoints on file/line or file/method, watchpoints to break when
a ruby expression is valid and catchpoints to break when an exception is thrown.
* The Watch variable viewer allows ruby expressions to be watched, and they are
updated on program pause.
* A configuration option was added to enable/disable the debugger floating toolbar.
* The debugger backend is written in pure ruby using the code from the 'debug.rb',
source included with the ruby distribution. It is started via KProcess which handles
redirection of stdout and stderr. The idea came from the way Laurent Julliard
implemented the FreeRIDE ruby debugger - it uses Distributed Ruby (like DCOP)
for messaging. DRuby is ruby-specific and couldn't be used though.
* The debugger communicates with the backend via a Unix domain socket;
commands are sent, and the replies are parsed in KDevelop in much the same way
as the gdb debugger uses stdin and stdout to send and receive.
Hey, I guess it's better to put it nearer the top so that some people see this.
A new wish that I found very interesting:
http://bugs.kde.org/show_bug.cgi?id=93611
Bug 93611: Make Konq a useable image viewer - add "next/previous" function
Right now if you want to look at pictures in Konqueror, you go to a directory in the file-browsing mode, you click on the file, the image loads, you go back, you click on the next file and so on...
Why not make it that - like in Kuickshow or ACDsee for instance - you can move on to the next and previous images?
I'd suggest that when you load an image, you have extra buttons in the main toolbar so that you can go "next/previous" and that some keyboard keys are binded to that function.
This might even be a Junior Job and I think it would be very useful.
Use Gwenview, it's fast and beautiful
Gwenview already has a KPart even. I think Gwenview should be the image viewer in the next KDE.
Though I like kview for viewing one image from the command line.
Unfortunately, you can't watch dark pictures in Gwenview, which degrades it to a viewer for normalized image collections. There's no equivalent for kuickshow's b/B (brightness) and c/C (contrast) shortcut. KIPI plugins are said to eventually bring that functionality, but having to go to a sub-sub-menu isn't really a solution. Kuickshow, on the other hand, has that sick dependency on imlib and doesn't display *.xcf, *.rgb etc., all of which are perfectly supported by the rest of KDE. Oh, well. There's still hope. :-)
KIPI plugins can have shortcuts assigned, and you can fix your dark pictures to have normal colors (what's the point of having dark pictures you cannot watch, anyway?).
You can help your hope by adding more votes to #82979.
> what's the point of having dark pictures you cannot watch, anyway?
Now, that's easy to answer: 1) some picture may be right when viewed in your room, but too dark when viewed in the bright sun on your laptop in the park. To which environment do you suggest I should adapt all my pictures on the harddisk? 2) Some picture may be perfectly OK. But still, when viewing it, I may want to see details in the dark background. 3) I may not have the possibility to change a picture at all, because it's on the internet, and too dark already there. Do you suggest that I save it, open it in gimp and edit it there? (The OP asked for a viewer in konqueror!) 4) If I want to show pictures to someone who is visually handicapped, I will most likely *not* change all the pictures on my harddisk. (Is accessibility just a buzzword in KDE, with nothing behind it?)
What's the point in having an image viewer that only lets me view pictures with perfect contrast and brightness? With the same argument, viewers could refuse to let me zoom-in/out and to rotate. I just don't get why there's so much resistance, and so few viewers get it. kuickshow does, none of gwenview, pixie, showimg do.
1),4) If somebody can't see a picture because they can't see almost anything on the screen for some reason, I don't think it's a problem of the viewer. If you can't see things on the display because of bright sun, there's the contrast control.
2),3) http://sourceforge.net/mailarchive/forum.php?thread_id=6012242&forum_id=...
Wow, thanks! I'll apply that patch right away.
BTW, here's another reason why this feature might be useful: 5) you are viewing images from a read-only medium, a cd-rom. And some of them are too dark for your monitor, maybe even only too dark for your taste. Of course, there are ways to get around this. But an option in the image viewer is the most obvious and effective place.
I have a few directories with aircraft/cockpit photos. All of them seem to be of realistic brightness and contrast, just as I would see them in the real thing. But to be able to recognize some details in the darker areas I need to brighten up the picture, even to extreme values. But, of course, I don't want to store the images like that. kuickshow was very useful for that (and, weirdly, I still have to use it as an external tool from within gwenview). Gimp, in turn, wouldn't be acceptable for browsing these images. Later I added a few SGI and gimp images to the collection, and kuickshow couldn't handle them and popped up annoying messages. I even wrote the SGI kimgio and the XCF kimgio (adaptation from qxcfi) to cure that. Didn't impress kuickshow. So I was left with two half-working (for my requirements!) tools. Hey, didn't I write that there would still be hope? :-)
>you have extra buttons in the main toolbar
Just what we need, more buttons in the toolbar, yay!
A long time ago Konqueror was able to rotate/zoom pictures and such and had neat-o toolbar icons for it.
Unfortunately this disappeared without a trace and never came back.
all these functions simply depends on what viewer you use for the images. remember, konqueror is just an empty shell. you use kview for the pictures, and indeed, thats not really complex. try for example gwennview, it's already much better. and I'm sure there is more... you migt ask the developers of kuickview to add a kpart, I think kuickview whould do great.
I solved this by using Kuickshow, I set it to open in fullscreen, modified shortcuts to Space bar to jump to next image and Backspace for previous, F for full screen toggle an Escape already quits Kuickshow. I am quite happy as I used to do the same with ACDsee. The only drawback in Kuickshow is that it still does not have loop function, like start from the first when I press "Next" on last image in dir.
Why add new buttons to do the job? I too would love Konqueror to be able to page through photos; why cannot the <- be back, the -> be forward, and the ^ (up) mean go back to the folder?
Anyone know why kicker needed a rewrite? What's better about the new kicker?
It's less complex, which means less bugs, better maintainablity, and more features in the long run.
Cheers,
Virgil
http://aseigo.blogspot.com/ for more information
And check out Aaron's bug list if you need more convincing:
http://tinyurl.com/4vcrs
derek, your summary/commentary is really great. always so nice to read through... thanx for the work!
I have to agree... Derek, you're an invaluable resource for KDE!
My weekly cvs-digest reading is a must. Thank you!
Any news about Qt-Mozilla?
Being celebrated so big when in the news, now we don't hear about it anymore :-(
Is the cvs-write access for Lars Knoll still the only problem?
If anybody made a build of Firefox using Qt, could he/she make it available
for download?
Will KDE 3.4 contain the Mozilla kpart?
Will this kpart be able to use an installed Mozilla, or will KDE ship it's
own libgecko.so?
Patience... you must learn patience.
Bah, I'm still waiting for the khtml based firefox.
So...
if we have a khtml-based firefox using qt...
it's basically konqueror without the file management, right? :-\
with support for lots of extensions
"Add multisynk plugin to kontact.
Now we have a userfriendly interface for synchronization of two PCs, a PC and a
handheld or a PC and a bluetooth accessable mobile phone."
Something passed under silence but that deserves a really big THANKS!
:)
OTH we have two sync programs is kde-pim. multisynk and kpilot and I dont think, that you can sync your Palm against a multisync device.
Bye
Thorsten
Well, let's wait for a probably future KPilot integration in multisynk! :)
Just wanted to point out that the actual KDE_EXPORT() patches that were done, didn't come from me afterall.
Back in July when I proposed to send a patch, I didn't get any response to it, so I dropped working on it. Afterwards I noticed that Jaroslaw Staniek had been doing something similar, but his purpose was to get KDE to work on Windows (QKW), see
http://article.gmane.org/gmane.comp.kde.devel.cygwin/1531
So while I did similar work, I can't take credit for the actual fixes to KDE.
Either way, I'm happy the patches went in.
Apart of the slightly reduced size of the binaries, is there any other
advantage (e.g. startupspeed) ?
Yes, startup speed.
Yups.. it also enables gcc to produce better code.
see http://article.gmane.org/gmane.comp.kde.devel.optimize/786