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
And now K3b 0.11 is out! Woo hoo!
i just tried k3b for the frst time, and it REALLY rocks! Burns CDs and DVDs without problems and looks great at the same time!
If you have a 2.6 kernel, you just have to add -dao to the cdrecord parameters.
Thanks for k3b!
Does this mean it will be easier to support outlook forms? (the kaddressbook type forms)
how to customize the outlook form to show the default profile when sending the reply form.
A bit off-topic. But with 3.2 around the corner, let me ask.
Am I correct in that the next major version will be 3.3, building on
the 3.2 release, and after this KDE 4.0 will be released, based on Qt-4,
and presenting some important integration between different applications of the same kind, and major reorganization with a focus on usability ?
Please enlighten, thanks in advance !
For now, it is starting as KDE 3.3.
However depending on how slow the developement would be and how fast Qt4 Beta would appear, it might be that KDE 3.3 would never be released.
Have a nice day!
Will there be a wholesale conversion to D-BUS in version 4? It would seem that a major version change would be the time to do this.
I hope so.
I think integration will become wery important in the future of linux.
Another thing that would be wonderful is the integration of the gstreamer framework.
Streamer - I heard that Roxio patented sttreamer technology. Wouldn't it be wise to act against the patent before it becomes enforcable.
> Another thing that would be wonderful is the integration of the gstreamer framework.
instead of this, I think we should standardize on the much more stable and cross platform videolan. Or MAS. Or NAS. I suppose there will be a lot of discussion on kdemultimedia before kde4 :-PD
Personally, I'd like to see an implementation of JACK in some form so we can bring professional audio to the desktop. JACK really is a nice piece of work. When you look at the nice audio work going on, it just isn't feasible to keep maintaining aRts.
me too, me too!
go JACK, go JACK, go JACK!
More and more apps are switching to JACK...
I ask myself why we need an 'analog realtime synthesizer' running by default. aRts might be cool as an music making framework though.
I think I heard rumors that for KDE 4 there are plans to support the implementation of different backends, i.e. not arts-only. Of course there have to be people who will implement these backends, i.e. OSS, ALSA, MAS, jack, arts, whatever...
Bye
Alex
IMHO, that would be a real shame. It would create yet another layer of complexity. I hope that there will be a real choice as to what the backend will be in KDE 4, and stick with that.
I think we need to hold off until we see how the politics of freedesktop play out. Look at the X.org/XFree 'merger' announcement by Havoc Pennington. It is all political jousting as far as I am concerned. Perhaps there are parts od D-BUS that KDE can steal from D-BUS for DCOP though. Why not? KDE has had enough of this in the past.
Hi,
I wonder if you are aware how strange the word "steal" in context of Free Software reads.
Rethink.
Yours, Kay
Often (at least in idiomatic American english) the term "steal" is used as a friendly term for taking something. "Nab", "swipe" and "yank" are also used (swipe, like steal, also has a negative connotation in its most common usage).
For instance, somebody in an office might bring in doughnuts and lay them out on their desk for people to take. A coworker who took one, knowing that they are publically available, might say "I swiped it from Rob". A far more common usage for "steal" is as an active verb. At the office again, somebody might say "Wait, we need a stapler, and there isn't one at this desk... I'll go steal Rob's stapler". There is no negative connotation. It simply refers to taking without asking due to implied consent. There is a slight edge to it; usage of "steal" in this manner is an easygoing, slightly sarcastic tone. It implies familiarity with the situation and all involved.
So yes, "steal" is an apt choice of terminology, assuming an American speaker.
In Norway we use 'stjele' in the same way. It's got the same bad or jokingly connotation.
Since people are stealing each others staplers all the time, one of my co-workers has marked his stapler "Stjålet from ", so that he'll get it returned in case the "thief" forgets ;)
Bad artists copy, great artists steal. - Picasso.I think he meant it more that way ;-)
> Look at the X.org/XFree 'merger' announcement by Havoc Pennington.
As I understand it, he was quoted out of context. See http://www.xfree.org/#news - there is no merger.
> Perhaps there are parts od D-BUS that KDE can steal from D-BUS for DCOP though.
DBUS was designed using DCOP as a model, and is designed to be desktop-agnostic. Why bother trying to copy DBUS when you could just use DBUS directly and be compatible with more software?
KDE really should use D-BUS for 4.0, a lot of the work being done on hooking the kernel up to the desktop environments uses D-BUS, and frankly a cross platform, cross desktop solution would be really cool. From what I've heard D-BUS is basically DCOP with a bit of extra stuff thrown in. Other than politics and inertia, why wouldn't you want to use it?
"However depending on how slow the developement would be and how fast Qt4 Beta would appear, it might be that KDE 3.3 would never be released."
BTW, does anybody know if there is some quotable timeframe for a Qt4 release?
I think that the only quotes were at the Kastle conference. So perhaps youc could try to find the old documents.
Have a nice day!
Hi,
I would think that porting KDE to QT4 is not necessarily a quick job. I would recommend a 3.3 release. The most important reasons are in my opinion:
a) It would be a chance to reintegrate the kdepim separate releases.
b) A lot of regression testing is being introduced lately into khtml. With 3.3 we can probably see a khtml that is almost fully standards compliant.
c) Some minor rewrites could be done, like khotkeys2 user interface, or apps like kdevelop and quanta can see consolidation
Yours, Kay
Yes, I also have the feeling that both because Qt-4 is probably going to be released at least a few months down the road, and also because there are several minor improvements that can be done without a major architectural change, that a KDE 3.3 with a short release would be best ...
merging kdevelop and quanta a minor rewrite? what kind of moron are you?
cool down :)
Try reading it this way:
(Some minor rewrites could be done, like khotkeys2 user interface), OR (apps like kdevelop and quanta can see consolidation)
where is people sense of humor?
It disappeared when your smiley did ;) Irony does not convey easily across text-only media, and thus the smiley was invented :)
I fast 3.3 release that includes things like the kdepim stuff that didn't make 3.2 would be nice. This way the 3 series could have a nice unified release to go out on. This would also help buy time for a longer 4.0 development cycle.
Apologies in advance for being off-topic (don't know where to post this) - can we have a bigger or more descriptive link to the KDE Homepage from this kde.news page - there's only a tiny link on the left-hand side which isn't very descriptive - it just says "kde" in very small writing - how about something like "kde homepage" or something in bigger letters and more prominent - just thought I'd mention it.....
There is always mailto:[email protected] to report such cases. (Any email sent there goes to the kde-www mailinglist.)
Have a nice day!
Just wandering is 3.2 going to have any kind of gesture support (for example like opera for going back and forward on web sites).
I've seen a program called KGestures, but it seems its developement has stop for some time now.
yes, kde 3.2 includes khotkeys.. which does what you want, and more.
Nice. I've been using opera lately, and once you get started using gestures its quite hard to go back. I'd really like to use konqueror (as I did up until a few months ago), if this feature was implemented. Can't wait for 3.2 to be released in a week or so.
Good work KDE developers (and that is not for the gestures only but for everything), thanks.
Cirrus
yes, and it is wonderful: maybe little difficult to setup, but since it remaps mouse gesture -> keyboard shortcut, you can use gesture to every ap, not only kde apps
Yes, hopefully a followup release will feature presetup gesture a-l-a Opera / Mozilla and so on. I in fact use the Opera-close-window gesture to close tabs on any application ( CTRL+W ). It is hard to go back to pointing the mouse to an X or using the shortcut itself.
You can find Opera/Mozilla gestures to import here: http://datschge.gmxhome.de/khotkeys.html
Thanks Datschge!
...... actually, there's a link on the right aswell - not very prominent though - my bad - maybe a more prominent one at the top of the page?
Krita looks like it has a very nice architecture now.. it probably needs some GUI designers though :)
Well, I have been thinking on what would make a good interface for a paint application that's supposedly easy enough to sit down at and start work, but I don't think I'm ready for carrying out any great gui redesign. So if anyone wants to go through Krita's interface and make it better (more like Karbon would be if Karbon were like the UI-analysis document you can find in its source tree, or just generally better), I'd be very pleased.
I'll kick out (hoping that the fellow who develops Krita reads this) that there's a nice GPLed Qt art application named DrawPad in the OPIE project (i.e., open qtopia, a Qt based environment for handhelds).
It does a few things that are pretty neat, like rotating the brush perpendicular to the vector of the pointer. Since it's Qt based, it might be worth a look to see if there's any code that is reusable.
--
Evan
Yup, he does...
cvs co opie...
I say, that's a big source tree...
Oh, I see what he's doing to make nice antialiased lines -- he draws at three times the size and then scales down with QImage's smoothscale. That's a nice trick, but you can only do that if you have a small image to start with. I don't see where he does fancy things with the brush, though...
It's not directly useful for what I'm working on now for Krita (I'm trying to implement the various composite modes for layers and painting), but this particular trick might be useful for the author of Kolourpaint, because his Kolourpaint works in general a lot like DrawPad.
The nifty part that I'm referring to is that the brush is a n-pixel wide line, selectable by a dropdown in the toolbar. When the brush is moved across the canvas, the line is drawn 90 degrees from the vector of the pointer. It's sort of hard to describe what the effect does in practice (the theory is simple), but it makes it very very easy to outline complex shapes and also gives you very uniform lines that end in a sharp, flat end (as opposed to using a disk shaped brush, which ends with a rounded end).
It is one of those simple things that quickly becomes very very intuitive.
The paint fill also selects by color and then tints similar colors based on how close they are to the clicked color - i.e., a click of red on yellow will pinken nearby whites and oranges but leaves blues alone. It behaves poorly, IMO, but the idea is interesting and could be reworked with a different or tweaked formula.
DrawPad is the app, by the way. DrawPad is to Opie as Krita is to KDE. Opie uses Qt to build on and create a palmtop interface rather than a desktop interface. Konqueror, Kate, Konsole and other KDE apps are ported and maintained.
--
Evan
HOW DO YOU USE KHOTKETS 2!
I have KDE 3.2 RC 1, I'm at the dialog for Khotkeys under system and I am throughly confused, and I can't find any manual either. NOBODY BUT COMPUTER EXPERTS WILL USE THIS UNLESS ITS SIMPLIFIED! It seems to do anything you need to know locations, paths and stuff from your head, there is no easy to use GUI.
Can someone tell me how to do something simple like make a line with the mouse like this __________________________ and make this gesture select all in Konqueror?
I thought Khotkeys 2 would benefit normal users, I was thinking its an improved version of the "Configure Shortcuts" dialog that I see in all KDE applications, one that would allow me, in addition to using key combinations, to use gestures.
I'm sorry, this is proabably a very powerful application, but it's so hard to use and arcane =(
Here's how to make a "select all" gesture for Konqueror:
Click "New Group." Click the tab "Conditions" at the top right. Click the listbox showing "New" and select "Active Window". In the dialog that appears, click the listbox showing "New" and select "Simple Window...", the only option available. Click the button "Autodetect", then click on an open Konqueror window. Click the listbox labeled "Window Class:" and choose "Is" from the list of predicates. Click OK twice to dismiss the two dialog boxes.
Congratulations! You have now made a group of actions specifically for Konqueror windows. Now for the "select all" action.
Your new action group will be selected in the KHotkeys2 window. Press the button labeled "New Action". From the "Action type:" listbox, choose "Gesture -> Keyboard Input (simple)". Click the Gestures tab. Press the "Edit..." button and define your gesture in the window that pops up. Don't make it too complex because KHotkeys is pretty picky about minor differences and pops up annoying dialog boxes. Once you are done hit OK. Now go to the "Keyboard Input Settings" tab. Click on the "Modify..." button. Realize that the "Modify..." button is broken, making it impossible to send "Ctrl-A" . Look for a DCOP call that will select all text in the active Konqueror window. Realize that every Konqueror window and tab has a unique number in its name, making it impossible for KHotkeys to always call the active tab in the active window. Bang head on wall.
KHotkeys2 has one of the worst user interfaces I have ever seen. So much emphasis has been put on making it super-powerful that ease-of-use has been completely overlooked. KHotKeys2 needs to do two main things:
1. Take gesture support and integrate it into KDE's keyboard shortcut system, so it will be in every application that has a "Configure Shortcuts" dialog. This way most users will avoid having to use the KHotKeys interface at all and can stick with the old familiar shortcuts interface.
2. Completely redesign KControl interface to KHotkeys. Make it really simple to add global actions with no conditions. Make it reasonably simple to add actions that are specific to one application using window class matching. Have an "advanced action" that has all the capabilities of the current KHotkeys2 for people who are shortcut fanatics. Minimize the number of clicks necessary to add shortcuts. Don't ask the user to name each action/condition/etc, generate meaningful names automatically.
Unfortunately, KHotkeys2 is completely unusable by 95% of people in its current state, and it is so much work to use it that the other 5% of people will be discouraged from using it even though they can. It desperately needs fixing. Lots of power is good, but usability is extremely important as well.
Well, thanks at least I understand the way it works, but wow, that is more work than it saves. Only thing that I gound reasonably simple to do that worked was to use Khotkeys to open programs, with gestures.
Also, having a line drawn when drawing the gesture would help. I also agree, that gestures should be integrated into the "Configure Shotcuts" dialog as an alternative to using keyboard only shortcuts. Something simple. Honestly, that's exactly what I was expecting and that's why I was so excited about this, it has a lot of potential, just not yet easy enough for most and I don't see any documentation either.
> Realize that the "Modify..." button is broken, making it impossible to send "Ctrl-A" .
Very well described, till this point. Here it should read: Realize that the "Modify..." button is not implemented yet (and as such it's in fact hidden in 3.2final), but you can type the input directly, so you can manually enter "Ctrl+A", "Shift+H:E:L:L:O", or whatever you want. Also, there's the examples group, which can serve as an inspiration.
As for the GUI, I agree it's not very good. Interesting how I can do technically quite complicated things, and fail to do something seemingly as simple as creating GUI that doesn't suck :(. Apparently this needs somebody else than me. In case you (or somebody else) feel you can do better, and have no problem with extending your "KHotKeys2 needs" to "KHotKeys2 needs and I'm willing to help", feel free to add wizards, fix the GUI or dump it and start from scratch. The GUI is created using Qt Designer and separated from the rest of the code.
I think I should also note that the original plan was to include predefined actions, but 3.2.0 has only the example ones. KHotKeys can import new ones from files, so I'll post the ones that will be added to 3.2.1 also somewhere for download.
I see an "import" button but no way to export the there requested *.khotkeys file. What kind of format is that? Simply the [data] tree from khotkeysrc?
Thanks. =)
Well, yes. Backup your khotkeysrc, delete unwanted actions, arrange the remaining ones in the way you want, save the config, copy your khotkeysrc somewhere and make it e.g. xmms.khotkeys . Only the [Data*] groups and Version field in [Main] are read when it will be imported, so you can manually remove the others. Hmm, this again looks a bit complicated, doesn't it?