In this week's KDE-CVS-Digest:
KStars adds more telescopic devices.
KAddressBook adds custom field support.
Krita gets working brush and new patterns.
CSS code from Safari added to KHTML.
Dot Categories:
In this week's KDE-CVS-Digest:
KStars adds more telescopic devices.
KAddressBook adds custom field support.
Krita gets working brush and new patterns.
CSS code from Safari added to KHTML.
Comments
Well, yes and no. I'm personally fine with the interface and the exporting approach, but I can also see why it might be only us. ;) The import button is easy to find so for starters I'll just refer to that and offer some prepared sets of mouse gestures. Thanks. =)
Ok, for those interested, http://seli.webz.cz/khotkeys/ has some actions already, I'll more as they're done.
I've posted some as well yesterday at http://datschge.gmxhome.de/khotkeys.html
Thanks for the very polite answer :-)
For some reason I didn't think of typing the name of the key combination I wanted. I must have deleted the examples group by accident or something, because I didn't see it. That would definitely have helped me understand the meaning of that text box.
I've been meaning to get around to contributing to KDE for some time, but I always seem to have some excuse. If I'm going to keep complaining about these things, I should put my money where my mouth is and start fixing them. In fact, it could be that I am really bad at creating GUIs as well, and only good at criticizing them ;-)
OK, the GUI is a little bit complicated to use, but it works perfectly! I just created gestures for JuK and Konqueror and am amazed how much fun it is! Thank you very much!
Hi
Do you know how to open a particular url in a new tab instead of new window
using dcop call.
If I go to kdcop it lists I have 3 konq processes running but only one is visible to me. I can open a url using
dcop konqueror-18193 konqueror-mainwindow#1 newTab http://www.hotmail.com
but I have no idea how to select the active konq process
Any ideas?
Anil
> I'm sorry, this is proabably a very powerful application, but it's so hard to use and arcane =(
i agree, see bug #69912 ( http://bugs.kde.org/show_bug.cgi?id=69912 ).. I'll probably have a go at polishing/making it easier to use for 3.3. The problem with khotkeys2 is that it started off as a seperate project, and was being developed on and off for more than three years.
> NOBODY BUT COMPUTER EXPERTS WILL USE THIS UNLESS ITS SIMPLIFIED
Well, I don't think many normal users would need mouse gestures anyways, and not very would even choose different keyboard shortcuts, but that's besides the point, having a bad UI is bad for computer experts as well.
> Well, I don't think many normal users would need mouse gestures anyways, and not
> very would even choose different keyboard shortcuts, but that's besides the point,
> having a bad UI is bad for computer experts as well.
i think mouse gesture rocks! it s a big comfort, not to click on a window butoon if you want that1 closed, or you can start your most used apps simply by a gesture... plz make it easier to use, pal!
Actually kudos to Lubos for releasing it. It seemed it would never happen and noone would have been able to complain: which would have been bad. Now it's finally getting some attention. Maybe some curious 3.2.0 users will participate in creation of rules/new interface/addition to the regular "Configure Shortcut" interface for "3.2.1".
I totally agree with you.
Not only is the UI bad from a usability point of view but it also doesn't conform to the UI layout that most other control modules have. As far as I know, no other modules have their titles in big bold letters.
I also think that it should be renamed.
But admittedly although the UI has some bad points khotkeys is REALLY configurable and useful.
Full ACK!
KHotkeys is really confusing.
And it doesn't seem to work BTW.
Don't know if I don't use it right or it's a
bug though. I unchecked "Deactivate" for
"Konqi gestures" and all parent groups.
Now I switch to Konqeror, press the middle
mouse button, and do a gesture.
Nothing happens.
???
Mouse gestures working here with kde-cvs
I have implemented the basic forward and back in the khotkeys2
You will have to type the "Alt+Right" or "Alt+Left" on the keyboard input field
Restart konqi. Because of preloading your konqi. might not have the new capability. From kde System guard kill all konqui and start a new instance now you should have mouse gesture working
Anil
Same over here. I followed the procedure provided by Spy Hunter
(without it, I would not have been able to configure it at all!).
After that no reaction on any of the 2 gestures I configured
(ctrl+a and alt+left).
However, it is good that this is now part of kde, so we can at least
complain about it :))
Note that KHotKeys is quite picky on the key names, and it has to be most probably "Ctrl+A" and "Alt+Left", not "ctrl+a" or "alt+left". Since this faked keyboard input is fed to the application as the normal keyboard input using fake XKeyEvent's, these events have to be synthetized back from your input. In other words, you also need "Shift+H" for capital "H", and for simple typing of "Hello", it has to be "Shift+H:E:L:L:O". I haven't found yet a way how to let people simply enter "Hello" to get that. There's also no error checking yet :(.
http://bugs.kde.org/show_bug.cgi?id=24143
I've reported this but it got closed at that point of time.
Now that some time has passed maybe it should be reconsidered, because
it would really be a nice feature for konqueror.
In terms of slowdown, I bet it takes more time to calculate the
number of items + their total size in the current directory than it would
take to get the diskfree information... (which should be no more than 2 calls)
and... windows users have it since win95 :-|
That probably means that you need to find a volunteer to code your wanted change.
With code, you would have more change to get what you want.
Have a nice day!
One of the commits to khtml:
> following the trend for more test cases, here is an import of
> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/
>
> 44 out of 166 tests fail (mostly bizare stuff I never saw on web pages :)
Why are tests from CSS3 used? IIRC CSS3 is not even officialy finished yet (though it would be pretty cool if khtml already supports it ;)).
To support it before Mozilla? ;-)
Why not?
KHTML has not a huge manpower, so starting early is not wrong. Also it avoids to make choice that would later reveal to be incompatible with CSS3 (for example CSS3 includes syntax changes to CSS.)
Have a nice day!
CSS 3 is broken up into modules, some of which (e.g. the selectors module) are very near completion. You'll find quite a few people implementing "unfinished" W3C specifications, as there needs to be two independent implementations before a specification can reach full recommendation status (i.e. "finished").
I'm a little confused. Will the big CSS changes added to KHTML from Safari make it to KDE 3.2?
No. It appears to have been committed to HEAD, which is on track for 3.3 right now.
You had better release that software now.
Judging from the screenshots, it can do a lot.
Well... It can paint, and combine images, but there's no eraser, no support for gradients, for patterns, no fill, only rectangular select, no airbrush, no fancy filters nor scriptable plugins... Take a look at the TODO:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/krita/TODO?rev=1.25&con....
I'm working on the eraser tool now; when that's done I think it'll be easy to bring Krita to the level of powertools like KPaint, and from there it should be plain sailing. And I want the layer combine effects working -- for that I need to add a few more composition methods.
But it's fun, and an educational experience :-).
Wow, the drawings in those screenshots are great. Did you draw those? Did that charcoal effect come from GIMP or is that Krita-specific?
Which one? On the Krita homepage or on my blog? If the former, well... The sketch of the girl is one I made with pencil and eraser on plain old paper and scanned. The effects on the screenshots on my blog are made with the Gimp's brushes, but I apparently didn't understand some finer points of the way the Gimp handles its pipeline brushes, and I added scaling with pressure sensitivity, which the Gimp doesn't have for those brushes.
>I added scaling with pressure sensitivity, which the Gimp doesn't have for those brushes.
If you have ideas about how to implement such a functionality, feel free to discuss it with the gimp developers:
http://bugzilla.gnome.org/show_bug.cgi?id=127785
They are at present in RC stage for 2.0, but it could be added to the next version (2.2).
oliv
Well... One of the advantages of the Krita source is that it is fairly simple at the moment, which means that even someone like me who doesn't know anything particularly relevant can grasp the source and hack away. I've been poring over the Gimp's source for months to find out how they do their nice anti-aliased brush strokes, and I still don't understand it. It's really hard to find ones way in the maze of optimizations and special cases -- and advanced algorithms. So I kind of understand Sven when he says it's not trivial for the Gimp.
With Krita, most fun things are still trivial... Later, when we've got all those nice optimized brush mask placements and things, then it'll be hard for us, too.
Will the new krita support higher colour depths (16/12/10 bits per component for instance, instead of the usual 8)? This is the most important feature missing from the Gimp, and cinepaint is quite poor in comparison (feature wise).
Yes. Or at least -- yes, that's the intention. It should be a simple redefine of QUANTUM from Q_UINT8 to, for instance Q_UINT32, and a recompile, to give 32 bits per channel. However... I've been messing with Krita since about October, I haven't ever tried to do that, and I don't know the first thing about computer graphics programming, so it's entirely possible that I've messed up somewhere and made it harder to support higher colour depths.
Of course, if I did so, I'll have to fix it :-). And it's also the intention, and nothing in Krita's core makes that hard, to support images with different colour depths at the same time. But these things take time, and, well, Cinepaint really shines feature-wise, compared to Krita at the moment.
Okay, I made the experiment; it seems that the first problem, if increasing QUANTUM from 8 bits to 32 bits is creating the QImage that is necessary to create the QPixmap that is shown on screen -- QImage doesn't have a constructor that takes wide image data. Of course, that was to be expected, and it would be fairly easy to work around, I just have to down-thingy the data for display on screen I guess, except that I don't know the correct algorithm for doing that.
This where it gets problematic, most graphics cards seem to have trouble with colour > 10bit and i have no idea what the support in X is like. At least we know cinepaint does it so it is _possible_, just might be dirty. Does krita build against kde 3.1.5? If so i might find time to take a look myself, im really busy with college at the moment though so dont get your hopes up ;)
Tom
I guess it just means you don't get to see the complete range of colours or so on you display. Photogenics (http://www.idruna.com/) says it can handle images with 32 bit per channel, too. I guess it is -- in Krita terms -- just doing another colour strategy. Krita doesn't directly show the image data anyway, it always renders it into a QImage, so it's just a matter of finding out how to effectively render 32 bits of channel data in 8 bits of video :-).
As for your other question: Krita still compiles against 3.1.5. I develop Krita on two computers: a SuSE 8.2 AMD with 3.2 and an old Powerbook G3 with Debian and 3.1.5. I'm not sure for how long you'll still be able to compile all of KOffice against 3.1.5, though.
rtfm
Does anyone know if KDE is going to support FLAC Audio files?
It would be nice if this would/could be included in 3.2.x.
--
JRT
There is an artsplugin for FLAC in kdenonbeta (kdenonbeta/flac_artsplugin).
Couldn't find anything else (except a kfile_plugin) so you might have to wait for KDE 3.3.