1st October 2006by Danny Allen
yesterday we had the last set of lightening talks and again some very cool technologies were shown. it looks like the dream of having a usable, powerful and beautiful universal viewer for kde4 is a reality with okular. it isn't the only "universal viewer" (which is different than a "universal component embedder") out there, but it is the most complete and beautiful one i've seen. it's also pretty damn fast. there are some ui bugs still apparent in it, so thankfully there are some months before kde4 ;)
the global roaming, organs identity ui system and gamefu (think amarok for console emulators) were also fun ...
today those who are left (many are already on their way home) are sitting around mostly quietly hacking. this is interesting because much of the past week was crammed full of BoF's, meetings and what not... we had a lot of communication to do and that cut into the hacking time. as kde takes on bigger problems with more finesse and expands into taking care of things we've neglected more than we should have such as our websites we have more need to coordinate.
This complements the existing "Index from disk" functionality really well, and by giving service developers two primary means of communication with Strigi, there are no excuses for developers not to integrate cool Strigi queries and amaze their users - for documentation and a tutorial on how to connect to Strigi over qt-dbus, see Strigi SVN.
As an example of the environments we envision Krossrunner to be utilised in, we have implemented an invoice application using Krossrunner that starts out from a template and fills it in with customer details such as name and address and the items being invoiced. In this example, the customer details can be provided from a database. Of course, there are a multitude of other use cases, many of which were inquired about at the OpenDocument day at Akademy, where several prominent developers and prospective users discussed the bright future of this open document format.
In regards to current open-source competition to Krossrunner, we believe our solution to be at the forefront - there is basically nothing that can match our capability, lightweight resource requirements and ease-of-use in the open-source world. OpenOffice.org has scripting features, but you need to start the whole application for it. There is no pure command-line way of doing it.
One of the great features of Krossrunner is the relatively tiny amount of code needed to implement a workflow solution. To try out Krossrunner, check out the code from the KOffice SVN at /trunk/koffice/libs/kross/runner/
The WorKflow application combines the advantages of shell scripts and macro recorders, while minimizing the shortcomings of both concepts. A workflow is broken down into single steps, called commands, which, when combined, perform the desired task (Screenshot). The user designs the workflow using only the mouse; no programming skills are required. Each command performs a single task on some input items (such as files, images or address book entries) and provides a list of output items, which are directly fed into the next command. A command can optionally provide some user interface for configuration.
Suppose you want to download a bunch of images from your digital camera, scale them down to 640x480 pixels, rotate some of them, and upload them to your website. Inexperienced users would download the files using Konqueror, start up some image manipulation application and would scale down and rotate each image by hand, which can be very time consuming. A smarter approach would be using the batch processing capabilities of existing applications such as Digikam. However, this doesn't cover uploading the images to your website. Experienced command-line users know that ImageMagick's convert program can do the image manipulation, and that KDE's kfmclient can be user for uploading, so they would write a shell script that automates the task. However, not everyone is comfortable with writing shell scripts. Using WorKflow, users can interactively design a simple workflow, which does exactly this task
- A "Copy Files" command is used to copy the files from the digital camera to the computer.
- Then, the "Scale Images" and "Rotate Images" commands do the image manipulation.
- Finally, another "Copy Files" command is used to upload the images to the website.
Note that the "Copy Files" command is completely network transparent; this is accomplished using KDE's KIO technology.
Another very interesting aspect is automating existing applications using WorKflow. At this point, the Kate editor can be automated using WorKflow (I chose Kate, because it has by far the most comprehensive and well-designed DCOP interface). Examples include:
- Get selected text from Kate, Sort text lines, and Replace selected text in Kate with the sorted text.
- Search a folder for files ending in .txt and open them in Kate.
Right now, the WorKflow application is already usable for certain tasks. About 50 commands are implemented. However, that's not nearly enough for claiming that WorKflow can automate the KDE desktop. Other commands are needed, and this is where I need help from the community: What are your day-to-day tasks that you want to see automated? If you provide feedback, chances are that the next release will feature commands which can automate your tasks.
I also want to use this opportunity to ask for help. First, I need all kinds of feedback, in particular concerning usability. Next, I need developers to help in creating additional commands (which, by the way, is greatly assisted by the "WorKflow designer" and "WorKflow debugger" applications). While the API is probably not completely stable yet, this is an easy way to start developing for KDE. See the documentation of the Command class. Additionally, I need application developers to rethink their DCOP interfaces with WorKflow in mind. As it turns out, almost no application's DCOP interface is at a point where it can be easily used by WorKflow. Contact me at tkadauke at gmx dot de for comments, feedback, questions etc.
|Commits||3049 by 239 developers, 2456 lines modified, 694 new files|
|Bugs Opened||283 in the last 7 days|
|Bugs Closed||255 in the last 7 days|
||Nuno Fernades Pinheiro||
Internationalization (i18n) Status
Bug Killers and Buzz
|Alexandre Pereira de Oliveira||
|Aaron J. Seigo||
There are 114 selections this week
- Each link now has an associated status:
that is clearly set after it being checked, which didn't happen before.
This fixes bug #134373 which was caused by a typo btw.
Also fix some failed assertions; there were some code paths in LinkChecker that weren't properly managed.
Connect to KonqHistoryManager's cleared() signal.
Makes "Clear History" wipe the location bar history permanently instead of just in open Konqueror windows.
Fix performance don't make any app that has a standard bookmarks menu (e.g. konsole, kate, konversation, or any KDE app that opened a file dialog with file dialog menu on) keep track of Konqueror's bookmarks file (as in load it into memory, and reload it every time it changes).
Should make things a bit more bearable for those with an impressive number of bookmarks, though it doesn't fix the issue entirely.
- Make sure we always size the plugin:
- Fixes google videos showing up.
- Fixes acroread in background tab.
- Make sure to notify the plugin directly of size changes:
- Fixes resizing of google videos
- Makes sizing of acroread more reliable
... And potentially a couple others, will double-check.
Affects amazon and freemail.hu
No longer crash if "Open in Addressbook" menu item is selected.
I found some BRs associated with this crash under the KMail product,
but there might be some under KNode too (I was too lazy too look).
The i18n string is re-used from other parts of KMail so it is not new.
Notice I'd like a better message once another string unfreeze happens.
Also note that a better solution is to disable this menu item if
we can precompute that the email address under the mouse is not
in the addressbook. Perhaps for KDE4.
disable collection rescan while transcoding (as the transcoded file might be created in a collection directory)
Show the right filename for dynamic download things
This is the start of smoker tool that aims to replace kalyptus and
generate smoke bindings.
Currently it's only the parser and command line tool - no generation is done.
This tool requires the most recent version of kdevelop4 installed (but uses
only kdevplatform stuff).
There it is, the result of the last couple of weeks of working on qmake buildsupport.
You need to run make -f Makefile.cvs so the buildsystem picks up the new icons
In short the new features are:
- more robust qmake parsing, shouldn't screw up any advanced .pro files
- handling of .pro, .pri and the scopes as tree nodes, you can add/remove files to any of them, change the subproject settings
- Cleaner code, which hopefully can be used as base for kdev4
The drawbacks: Not much tests done yet, so everybody using qmake projects try the support and give feedback via or sent bugreports via bugs.kde.org.
Adding the INDI observer pattern which would allow inter-driver communication when required. This feature is needed when controlling multiple devices in observatories, where drivers may watch the state and value changes of other properties they're interested in to perform their operation.
The classical example of this problem is the Rain Collector and Roof Top (Dome) drivers. The roof top needs to know from the rain collector driver if it's raining or not so it can make decisions on opening or closing the roof top. Therefore, such decisions can be made without an operator present.
Implement "Place divisions in the map" game
Problems which should be fixed:
- placing countries with islands or "globes" is quite hard, because you don't
know where is the center, we should add something to the cursor to indicate
- just now it takes black (0,0,0) as frontier, but there are some maps which
use another color, we can add an extra tag to the XML to tell if some
color should be shown or not in this kind of game or edit the maps and make
sure that all the borders are black
- lots of problems which I haven't thought of :P
implemented a new way to localize the interpreter
now the translater can translate the KTurtle programming language
straight from the .po files, just like the GUI strings! (no more exernal
data files that need to be translated)
this will allow KTurtle to be used in even more languages...
Implement a bit more of the XPS specification - some
basic matrix transformations now work.
Also do a bit of refactoring - see if painting on a QImage
is any faster than painting on a QPixmap. Also move some
of the convenience routines into member functions, so that
they can correctly implement stuff like fill modes.
Restructuring a bit how the text-editor-like selection works:
* putting it in an own view mode
* associating the selection to every page
* using a better algorithm to calculate the selection, even in a page range
* moving its drawing from the page view to the page painter, so it's possibile to draw it just like it's done with eg annotations
Other changes (more or less related):
* moved the annotation popup to a better place, so it won't interfere with annotation drawing
* commented some debug code in TextPage
Give a tooltip in the page view for every kind of lnk we support.
Also improve a bit the one in the presentation mode, and give a message when the link is a "go to the page x" link.
Implements KPDF wish #131361.
kipi-plugins from trunk : GPSSync tool : The GPS location editor dialog now display the Google Maps view like a real widget, without margin and depending of the dialog size. If you reduce or increase dialog size, the world map size will be updated in live.
A few visual cleanups
* Remove tab title from window title - its really not needed imho
* Add tooltip for command to show the command in full
* Add a "this is not an X process" for processes that use no X memory for the x memory column
* Fix the english in a few places
Also, dont load the connect dialog at start up. This will speed up the startup very slightly and slightly reduce X memory consumption. Currently ksysguard uses 5MB of pixmaps!
KDirModel, a directory model for KIO-based directory listings.
Handles files being created, modified and deleted at runtime.
With unit tests and a gui test program (which creates QListViews and a QTreeView to test it)
The model has been tested with 10000 subdirs and the branch opens as fast as it did in kde3 times.
* Remove the Taskmanager profile - we dont use it anymore
* Put the Process list in the first tab since thats what other programs do
* Use Qt::BackgroundRole instead of Qt::BackgroundColorRole since that's now deprecated
* Fix extra heading bug I had from not inserting correctly
* Use the title of the first window that we find for a process - more likely to be correct
* Enable sorting for the processlist - sorting now works!
* Use Qt resize first column in process list instead of our own
* Expand last column now works
* Large improvements on startup time by fixing lots of layout bugs - we save about 40% of the start up time!
* Delay getting new process information for the first couple of times after starting up. This gives us time to draw the app etc
* Filter case insensitively
* Use the new sort by column function in Qt 4.2 to fix some bugs there
After lots of frustration with sqlite add optional PostgreSQL support. Fetching items from the resource actually works now. And it's fast.
This is just for testing currently, but sqlite does neither support useable concurrent access nor does it provide the necessary performance.
Allow starting a new session in the kontact plugin. Thanks to Sergey for
patch and notification.
ODF: Create support for data in rows or columns
Yay! This is the first ODF commit for kchart in a loooong time. Viva aKademy for giving me time to actually do this.
Btw, Bug 134195 is a great testcase because it is simple and yet contains a number of things that don't work yet.
Make AFT emit fileAdded and fileDeleted in manageable ways for both incremental and full rescans. Make the Playlist use these to do really cool and magic
things with files when they're added to and deleted from the Collection and entries already exist in the Playlist, without too much overhead.
To do this I made a change in how PlaylistItems are enabled and disabled, splitting reasons for it. This makes it far more robust but has the side effect
that I may have screwed up Dynamic Playlists a bit. I'll have to do more testing, but as we have no release imminent we have time to catch it.
I'll send an email to the devel list regarding the changes I made, why it was done, and what it means. In a couple of hours. Meanwhile, everything other
than Dynamic Playlists has been tested a bit and seems to be working well.
* Add warning before quitting Konversation. Patch by Stanislav Nikolov.
* Put both the above warning and KSystemTray's under the unified con-
trol of a single entry in the Warning Dialog preferences page's list.
* Bump the lower boundary of the default DCC port range to 1026 to
avoid clashes with the commonly blocked Microsoft RPC port 1025.
[Feature] Zoom with middle-mouse-wheel and ctrl (see request 0000125)
While zooming the region under the mouse cursor stays at its place, when using middle-mouse-wheel.
While zooming with menu or toolbar, the center of the visible region stays at its place.
[Fix] Zoom levels increase by 20% (see request 0000128)
Zooming is now more general, using a QMap instead of an KDisserPart-attribute for each zoom level.
Adding more zoomlevels can be done at one place very easily.
[Change] Zooming an item under the mouse coursor, although it is not selected is *removed*.
This behavior is completely surprising and hence it violates certain usability guidelines.
Wow, wow, wow! :)
Nicer and nicer, curiouser and curiouser ;).
Implemented displaying of svg background created by Mauricio.
Be sure to check it out!
The chips are a bit shifted currently as I still need to find a way to properly calculate playfield rect.
Moreover this rect can vary from one background to another (if we'll support custom backgrounds)...
Perhaps Mauricio can advice me something on common way to determine bounding rect of particular element of svg.
I've seen something like this in QSvgRenderer API.
First step of a big rework of Eigen to make the dynamic-size and fixed-size classes share common code, using a C++ trick known as Curiously Recurring Template Pattern, as described here: <a href="http://www.informit.com/articles/article.asp?p=31473&seqNum=3&rl=1">http://www.informit.com/articles/article.asp?p=31473&seqNum=3&rl=1</a>
Thanks go to the gurus on the kde-devel list, especially Sylvain Joyeux.
This patch adds a new class template VectorBase, and reimplements the dynamic-size VectorX as a derived class template of VectorBase.
TODO: reimplement in the same way all the other classes.
Heavy DHTML optimizations.
Basically avoid to do any layouting work when the style difference only implies
the translation of a layer and nothing more, which is very common.
Makes KHTML fly on a lot of dynamical pages!
Introduce some priority levels when repainting, so we can have rapid repaints
Don't use anymore the overflow properties for storing the layers scroll overflows
as that was terminally boken for any nestig level.
Admittedly leftmost/rightmost and friends can be a tad more
expensive at times, but they do provide correct results which is very much valuable.
SmallIcon can fall back to UserIcon if needed, but this means doing the lookup as a SmallIcon first, every time, which is slow.
This commit makes the "Find Messages" (Key_S) dialog pop up -much- faster in kmail (from 3s to 0, approximately ;).
I'll add a warning in trunk's iconloader when this fallback is being used.
greatly reduce memory leaking, according to valgrind.
Eliminate the dependency on Flex by importing
the FlexLexer.h (normally residing in /usr/include)
into SVN (once for each Flex-based plugin),
and also the generated *_lexer.cpp files.
As a consequence, the lexers are not anymore generated
on building, so if you need to update them, you must
run flex manually.
FlexLexer.h and *_lexer.cpp are the ones from Flex 2.5.31.
If you have a newer version lying around, say, 2.5.33,
you're welcome to get the new FlexLexer.h into SVN
and regenerate the lexer files.
digikam from trunk : prepare to use an embedded dcraw binary version into digiKam
This is want mean that we can remove the external dcraw depency definitivly.
digiKAm will build and install a 'digikamdcraw' binary file witch can be used instead 'dcraw'
This way will solve all bug reported from users about uncompatible dcraw command options.
When we want to update dcraw in digiKam, we just need to update the dcraw.c and test the
compatibility with all options used by digiKAm core.
To digikam team : please let's me here if this way is right for you. Thanks in advance.
Removing the "Test MIDI" button, it's been around for years without actually doing anything.
First draft of the outcome of a discussion between Thomas Zander and me: ideas
about how the KOffice manuals should be restructured / professionalised for 2.0.
The generic structure is quite final, the actual mapping of that structure to the various applications is still to be done.
Also store the new webserver script-package which provides now access to OpenDocument spreadsheets as well in the svn till I've access to my main devel-system again.
btw, the copycenter and the webserver script-packages are now more mature "examples" of some of the use-case examples for the
OpenDocument Developers Kit as described by Rob Weir on <a href="http://opendocument.xml.org/node/154">http://opendocument.xml.org/node/154</a> .
I see an illustration of following points of the 20 use-cases;
1. heavy-weight client-application
2. light-weight web-based application
4. automatic creation in response to a database query (report generation)
9. read-only display of document on machine without the full editor (viewer)
10.conversion of document from one editable format to another
15.Export of data from a non-office application into an office format
16.Application which takes an existing document and outputs a modified version of that presentation
20.Software which packs/unpacks a document into relational database form
Remove the 'kuick' libkonqueror plugin due usability concerns
Kuick is good at copying and moving files quickly. It remembers the last used directories and can be a real powertool.
There are too many downsides though:
- if we want to show too many folders we have many QPopupMenus across the screen
- we have one more way of navigating through the filesystem
- It conflicts with the normal copy and paste.
- For Contacts it is more like a "Send To" instead of Copy To
And last but not least for KDE4 the usability guys are redesigning the Konqueror Userinterface anyway and I'm sure there will be a way to quickly move files around.
E.g. by having the KFileDialog sidebar in Konqueror...
On Monday I will remove this plugin interface from Konqueror as no-one has used it besides kuick.