In this week's KDE-CVS-Digest:
Many changes in KDE-PIM; gpgme now used in
KMail. KNode integration in Kontact completed. A KPilot plugin for Kontact. IMAP addressbook resources, used in Kolab, is complete. And an initial version of a PIM configuration wizard. In Kexi, read-write queries are supported and dragging relations together now works. A KJSEmbed envelope maker example is available. Filelight can be used in Konqueror. And the usual bugfixes.
Dot Categories:
Comments
Wow! First comment!!
Thanks, Derek, for your precious CVS-Digest!!
Bye
Great digest Derek, Thanks!
amaroK 0.8.1 looks sooo good. i'm compiling it now. it has definitely removed my need for xmms at all.
//standsolid//
A happy customer :-)
Also please use version 0.8.3 which we released yesterday as it addresses a few compile issues for KDE 3.1 users as well as introducing some new features.
well that compile stopped...
0.8.3 is on now in it's way :)
//standsolid//
And regarding amaroK -- is the appropriate place for feature requests at the sourceforge project page?
I think it would be nifty to have a window-shade mode... the one thing i miss from winamp/xmms
//standsolid//
You might just talk to us on IRC, and we'll gladly add any feature requests to TODO. We usually hang out on irc.freenode.net / channel #amarok. If you can't come to IRC, simply send a mail, address is in the program's about dialog.
Concerning window shade mode - yeah we're already looking into that. Sure a nifty feature. Stay tuned =)
... it can't play *.mpc Files or I'm wrong??
amaroK is a frontend for arts (like noatun), so it plays whatever you can get arts to play. To my knowledge arts doesn't support mpc files.
amaroK is being refitted to use a variety of audio-engines (ie GStreamer and others to be disclosed). You may have more luck with future versions.. Out of interest, do you know any OSS media players that support that format?
I have a plugin for xmms that allows me to listen to mpc files.
As usual ;-) : Thanks Derek!!! It's always an interesting read.
About focus stealing prevention:
I'm using KDE 3.2 beta 2 and this thing is driving me nuts.
Even the exec command dlg idoesn't show properly when pressing Alt+F2.
Is this also covered by the mentioned bugfix?
BTW: Is there any way to disable this stuff at all? I never really
liked it on Windows and think it's absolutely superfluous. I'm not
80 years old - I can react properly and don't get a heart attack when
a window shows up suddenly. Especially annoying IMO is that I sometimes
like to run apps which load quite a time from my desktop and until they
come up I sometimes do other stuff. Until now (and in contrast to Windows)
this worked perfectly. Now I have to maximize the window manually again
once it's loaded.
> BTW: Is there any way to disable this stuff at all?
Sure: RMB window decoration, "Configure...", "Advanced", "Focus stealing prevention: None"
Ahh! Thanks a lot!!
I couldn't find it because of its strange German translation.
You could add a bug for the bad german translation, or report it here:
http://www.kde.me.uk/index.php?page=KDE_Typos
> Sure: RMB window decoration, "Configure...", "Advanced", "Focus stealing prevention:...
Cool. Just for those of us not in the know, WTF is an "RMB window"?
RMB window decoration == press the right mousebutton on the window titlebar
And why does not "Print Screen" enforce a snapshot as it is in Windows. this is the only diadavantage in usability of KDE.
My apologies if I completely misunderstand your question, but.. If you're talking about taking a screenshot using the "print screen" button, this is available since a few KDE releases already.
CTRL+PrintSrc - full screen snapshot
ALT+PrintSrc - active window snapshot
The resulting image is put into the clipboard, all you need to do is to paste it somewhere, using an app that understands pasting PNG images. Konqueror does, so all you need to do is to rightclick the desktop (for instance) and chose "paste". (Other apps that supports this is kpaint and kword.)
windows: printscr = screenshot
KDE strg+printscr 0 screenshot
btw: what other usage is made of printscr without strg?
While that is a useful feature, you can always use ksnapshot, which is much more flexible than the print screen key (eg, you can take snapshots of specific window, save, and print the file all from one handy little screen :) ).
Actually I configured the control center's keyboard shortcuts module to launch ksnapshot by pressing PrintSrc which is quite convenient :)
If you have any problems, please report them at the proper place, which is bugs.kde.org and not dot.kde.org. (And, if I might ask, include a better description of the problem, since I don't remember Alt+F2 being broken since a long time, and I really don't see what does maximalization have to do with focus stealing prevention.)
OK. Now I've found this KDE control module thing and have set focus
stealing prevention to "extreme". I still have this accursed application
that thinks it is really, really, really important to let me know every
30 seconds that it thinks something isn't quite right. I do not like
being yanked across multiple virtual desktops to this brainless app,
but I have to use the thing. What is the setting past "extreme"?
I can't find it. What is the "Do not ever under any circumstances
allow any application to steal the focus" setting?
A topper bug http://bugs.kde.org/show_bug.cgi?id=39693 has been marked FIXED.
KDE-CVS reads: ".....makes loading of very large images quite a bit faster"
http://bugs.kde.org/show_bug.cgi?id=39693 mentions: ".....This massively reduces memory footprint and slightly improves performance"
Neither of the two actually clearly says that it totaly fixes the bug. Now is it fixed or not??
a) you missed the "reduce X-server pressure with large images"
b) I'm sure Dirk tested this
c) improve performance in several places does add up
d) Have you even tried it? If it's not fixed for you, you can re-open it.
I guess I'm a little impatient here.. I don't have CVS to try out on. I was 'affraid' this fix was more like a small 'hack around' but not a true fix.
Well if it works, I guess it does, that's great, because this has been a real annoying topper bug for a long time now.
Dirk rules.. ;)
There was more today on that problem. Hopefully fixes it for good.
Derek
I think there are great things in store for KJSEmbed, if only one single thing is done for it: a nice, simple, dedicated IDE with integrated UI builder (not QT Designer running in a separate window, making .ui files to be imported later with extra steps). The integration would make it drop-dead simple to turn out a dinky little app in an hour, even if you don't know much about the process of making a KDE app already. It could be the Visual Basic killer everyone says they want. Would it be hard to extract the UI-editing parts of QT Designer and make that into a KPart for this IDE?
Should be possible to be done in KDE 4, see "Kastle 2003: What to expect from Qt 4" http://dot.kde.org/1061880936/ "Designer split up into components. This makes it possible to create a form editor plugin for KDevelop."
Visual Basic?
What about Hbasic 0.99g?
http://hbasic.sf.net
probibly the fact its basic, and the fact its lacking KDE Support, WidgetFactory support, and just now is getting limited SQL support.
KJSEmbed while limited has very nice SQL support for any driver QtSQL supports.
Since about 6 months we could load UI files perfectly.
So design it in Qt Designer. Name your widgets with meaningful names, and you can call them from javascript.
Last night I added a function to our core JS library that will allow you to load a UI file, and it will add every object in the UI as a property. So if you have a group box called Foo that has a LineEdit called bar you would address it as view.Foo.bar.text to get the text of the lineedit.
So if in fact what you wished for has been there for some time, it just got trivial last night.
Btw, you can access kioslaves and kparts too ;)
Cheers
-ian reinhart geiser
Also im working on KJSEmbed IDE plugin for KDevelop 3.0. Class browser and debugger works. Im trying to get autocompletion to work next. Expect it before Q2 of 2004 here.
Also take a walk arround http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/kjsembed/docs/examp...
There are tons of things we alredy support to make apps in KJSEbmed trival.
DCOP, StandardActions, KParts, KIO, KConfig, StandardDirs, Iconloaders...
Its pretty powerful for doing stuff fast and one off.
Cheers
-ian reinhart geiser
Are any tutorials planned KJSEmbed?
We have a ton of examples now, but we will have plans for some nice howtos.
Cheers
-ian reinhart geiser
Wow, that sounds pretty nice. I still think having the designer integrated into an IDE would be a nice feature, though. Does KJSEmbed make it easy to call C++ code that you write yourself, too?
yes... but the devil is in the details.
you can embed KJSEmbed (hence the name) into an application like i did in the KJSKickerApplet in kdenonbeta. Here I just publish my interface via the publish() funciton. This exposes the published QObjects signals slots and properties. These can be called from KJSEmbed then.
More complexly you can provide a bindings plugin with your custom type and load that at runtime of the script.
at either point we try to mirror the Qt api as much as possible. A great example of this is my buttonmaker in cvs. The UI file is completely designed in Qt Designer. You can then in js connect the slots to the uis signals.
One other option i have not tested is you could in Qt designer connect the signals and slots the normal way. Then in KJSEmbed create functions that match those signatures. At that point those will be called automaticly via Qt Widget factory. Now the curious side effect of this method is that if you later decide that C++ is the way to go take the SAME IDENTICAL UI FILE, and just create a C++ class that contains the same slots as you made in javascript. This is a big plus for those developers who love to prototype the UI first... then dedicate to C++.
Cheers
-ian reinhart geiser
I can see a use for KJSEmbed where the entire application is written in Javascript, and then for the speed-critical drawing/sorting/whatever parts a few C++ functions are written and then called to do the dirty work. I think apps written in this way could be just as fast as current KDE apps but easier to maintain and have fewer bugs. With an open-source project ease of maintenance is key. If most of KDE was written in Javascript with .ui files, the number of people who could contribute to coding would be larger, and KDE would improve faster. Have you considered this type of application for KJSEmbed?
Sort of... Already in my apps ButtonMaker (made buttons for my companies intranet site) and EnvelopeMaker (makes oneoff postscript files for mailing envelopes for my company) KJSEmbed has proven VERY powerfulfor oneoff apps....
...BUT...
We must remember billy g's most important lesson that he tought us "Just because its easy to write a 100 line app in a language dosent mean it will scale well to 100k lines" We can see how on windows many crappy VB apps are the product of programmers thinking that if its easy for 100 lines, then it should make my 100k line program easy. KJSEmbed is no exception. For apps that are less than say 500 lines, where you can see the code pretty easily in a text editor KJSEmbed is awesome. It can provide simple glue between powerful C++ objects to create simple one off applications fast. But for the same reason that KDE is not written in Scheme or Lisp Javascript would become a maintiance nightmare after a while. Remember only rudimentary classes, no virtuals, no real polymorphism... it runs out of power quick once you start building a large OO framework with it :)
That being said, for things like kicker applets, konqi sidebars, and almost any plugin in KDE, KJSEmbed i feel is perfect. For those simple one off apps to keep the company secretary happy under linux its perfect. For web developers who want a simple one off app to script a process again its spot on...
I could argue that kcontrol panels could be redone in KJSEmbed... but im not sure if maintainers are ready for that yet ;)
Cheers
-ian reinhart geiser
I'm glad to see the fix for 71062, but I still see the same bug occasionally, but now it goes away when the page is reloaded. This makes it hard to reproduce and make a good bug report. If anyone can reproduce this, please see bug #66894.
Thanks to Dirk for his khtml fixes for this week. Much appreciated!
I don't like asking questions in the dot, but...
Does this means that a branch has been created? I thought KDE was on freeze, and that features only will be added to HEAD, so that means the KDE_3_2_BRANCH (or something like that) was created.
I don't see anything on kde-devel mailing list :-?
The new features are in either separate development branches, or kdenonbeta. The core kde release is in strict bug fix mode, until next week or so.
There isn't a 3.2 branch yet.
Derek
Nice to see lots of attention on KDE-PIM. I have heard lots of comments about Kontact being a KDE killer app but for commercial businesses Kontact has to work well. For us the other Linux options are: Thunderbird (no organizer or notes, but good mail lists and extra fields), Evolution (no notes, no extra fields but good palm synching and looks polished), and Outlook under Wine (no comment). We see Kontact very close to being best in class. In our business (like most) we need Kontact to have:
a) reliability - Kmail has actually worked very well for us for 2 years but palm synching has been terrible leaving us in a real problem state - maybe the new KPilot integration step is solving that.
b) flexibility - some of the new fields in addressbook will help big-time - with enough fields we can create our own contact manager (heck, we use gnumeric for it right now)
c) security - the announced integration of SpamAssassin is a great, great addition. An easy KMail way to encrypt/decrypt sensitive messages with PGP or VPN would also be good for non-geek types (which managers usually are).
d) completeness - it sadly sounds like many of these changes won't make KDE 3.2 but instead of just having a PIM update later (which many distros or sys admins may put off - I would advocate the changes getting released as a critical KDE upgrade, ie 3.21 so that all users start to get the new fixed Kontact asap. For many buinsesses, it might just be the most important part of KDE.
Which is better? HBasic or Gambas?
1. Hbasic http://hbasic.sourceforge.net/
2. Gambas http://gambas.sourceforge.net/
What's Style Workshop and/or largeimagelib?