- Having a "blessed" KDE scripting language for writing complete KDE applications is a good thing and allowing applications written in that language
- A tangent to the main thread is adding scriptability to KDE applications
- For the first sort of scripting, there's something of a concensus that Python or Ruby are the primary candidate languages
- There hasn't been much language flaming between Ruby and Python; it seems most folks agree that they're both acceptable OO scripting languages, though there have been plugs a bit for one language or the other
8th October 2006by Danny Allen
- Blessing the use of scripting languages for writing complete applications is important. Equally important is not to bless a single language. Let's first see in which languages applications actually will be written. The really important thing is that among the set of tarballs that comprises a complete kde release can be applications completely written in a scripting language. Of course, apart from Python and Ruby there are no serious candidates.
- There are still people who think that the current bindings to Qt and KDE of, for instance Python, are not completely mature and stable and that the maintenance of those bindings will cost kde-core hackers time. Come on, guys! Living under a rock is not healthy. We've had stable scripting language bindings for more than half a decade. They just didn't take off because kde doesn't package scripted applications, relegating them to the whims of distribution packagers.
- I'm fine with no, or just one, or two scripting languages allowed for extending or implementing kde-base and kde-core bits. I still think that Kross is better than just mandating kjsembed. Look at how cool Kross is: Kross 2.0 and DBus. Kross really is the definitive solution to scripting KDE, on a par with what BeOS had, maybe even better.
I've been doing more work with QDBus in QtRuby. I've translated all the Qt4 dbus examples, and they all work except 'complexpingpong'. One nice thing I've added to Qt::DBusMessage is the ability to call methods on them as proxies, instead of having to invoke the call() method, with the target method name as a string. For example, you can call a method called 'query()' like this:
reply = iface.call("query", Qt::Variant.new(line))
Or call it more simply like this:
reply = iface.query(line)
In the first case 'reply' will be a Qt::DBusMessage, and you can check if it is ok with 'reply.valid?', and then extract the value with 'reply.value'. In the second case 'reply' is the return value of the method (a Ruby String in this example). So it works just as if it was a local method call.
|Commits||2675 by 219 developers, 5294 lines modified, 1338 new files|
|Bugs Opened||269 in the last 7 days|
|Bugs Closed||184 in the last 7 days|
||Adriaan de Groot||
Internationalization (i18n) Status
Bug Killers and Buzz
|Alexandre Pereira de Oliveira||
|Adriaan de Groot||
|Aaron J. Seigo||
There are 57 selections this week
- Fixed bug in advanced choke algorithm
- Deselecting files without deleting data is now possible
- Deselecting files without deleting data is now the default action when you uncheck a file in the infowdiget
- Deselecting existing files at torrent load time, will not delete the file
- Allright, after two days I've finally tracked down this bug. The loadconfig did not get the correct value for the slider interval. By re-setting the config group it magically works again. If any guru can tell me why this is needed, you get a beer.
- Change default slider interval from 2 sec to 10 sec. Draining your system resources by default is not very friendly...
Add initial support for namespace-aliases and namespace-imports. They are both stored into the code-repository and code-model now, and used through the namespace-aliasing system. Create facilities for efficient management and comparison of include-files for future header-parsing. Make the namespace-system aware of those facilities.
Together with some simple header-parsing (included headers need to be collected), and with a little work on making the resolution-system aware of those header-sets, that will allow near-perfect code-completion. A few other fixes.
Allow views to be removed from a session. Better handling of terminal emulation size when a view is resized - Konsole looks through all of the visible views on a session and selects the largest number of lines and columns which can be displayed on all views.
lower the time the tip shows except for taskbar, pager and clock where it makes sense to have extended times (4s in this case) re-increase the time between tip reshows because too many reshows sucks on low powered cpus and also looks a bit stupid on the pager and taskbar (among other places, i'm sure) the idea is that the tip should show only on items that the user settles on, not to follow their mouse around randomly. yes, this is not how things like tooltips work but that's because those items do something differently and do it, quite honestly, rather poorly anyways.
the design of the kicker mouse overs is quite intentional and based on a fair amount of actual research, testing and reaching stated goals.
if you think there's something wrong in it, perhaps talk to me first because it may be your assumptions that are wrong rather than the code in kickerTip.cpp.
Implement top quoting support for signatures. There's a new config option to include signatures before quoted text, and a new entry in the composer's edit menu to prepend the current signature. Identity switching tries to remove the signature, if it finds it anywhere in the body, which has some risk, but I guess that's not a real issue. In top quote mode the signatures are added without -- seperator, as seems to be the convention.
(Kolab Issue 1385)
"Favorite tracks" default smart playlist now obeys "Use Scores" and "Use Ratings" setting.
Added feature to remove torrent and data in context menu of view.
fixed a lot of memleaks... (from 42,084 to 536 bytes definitely lost)
thanks valgrind people, i could not figure it out without...
thanks coolo, for pointing it out to me...
thanks annma for putting it on my agenda...
the remaining memleaks seem out of my control
Performance improvement when scrolling - especially with large terminal windows. The emulation now gives hints to the display about how the image has scrolled since the last update, which allows the display to scroll using QWidget::scroll() and avoid redrawing lots of text. Unfortunately it seems that Vim and terminal emacs don't use the terminal facilities to scroll the display, so it doesn't help those particular programs.