In the coming week, Carsten and Benoît will be working on a lattice-viewer which will reuse most of the current moleculeviewer code.
Allowing the development squad to meet in a central location for a continuous amount of time was excellent. This has without a doubt strengthened our bond as co-developers, and fuelled great enthusiasm and motivation to work on the project.
Some of the technical achievements which occured include:
- Substantial optimisations in the Context, Playlist and Media browsers
- Usage of iNotify technology
- Script manager UI changes
- Beginnings of a port to the new Qt4 api
- Major user interface redesigns
- Brainstorming of future, cutting edge technologies
One of the highlights of the meeting was a substantial and thorough hour long discussion about the direction which we, as developers, should take. This forum included past experiences, future developments (Amarok 2.0, and general design methodologies), licensing, plugins, bugs, quality management and a host of further topics. This meeting no doubt exceeded anybody's expectations. Smoothly run, hassle free and productive - surely there could be no better way to create an effective environment for programming!
Right now, i'm attempting to add loadable modules for indexing files. After that, we will be working on GUI improvements, to improve the slightly rough state from a user point of view.
One might wonder how Strigi could implement Tenor concepts. A simple approach is at least to allow users to tag files, just like we have become used to with blogs (e.g. Technorati.com) and websites (e.g. Connotea). This could be easily implemented using extended attributes (xattr), already used by Beagle.
My argument to use this, instead of putting these things in the Strigi database itself, is persistence: data and metadata are kept together. KDE's file properties dialog would be extended with an extra tab that allows editing these fields.
Strigi itself can be embedded in KDE applications to search specific information (e.g. search molecular data within Kalzium using the InChI), and even in the FileOpen dialog. We need patches for KDE 4 that allows this, soon.
|Commits||2404 by 184 developers, 5439 lines modified, 1662 new files|
|Bugs Opened||275 in the last 7 days|
|Bugs Closed||266 in the last 7 days|
|Allan Sandfeld Jensen||
Internationalization (i18n) Status
|British English (en_GB)||
Bug Killers and Buzz
|Alexandre Pereira de Oliveira||
|Allan Sandfeld Jensen||
|Aaron J. Seigo||
There are 51 selections this week
Committing changes from James Bowlin to fix a rendering bug.
Constellation lines were disappearing at high zoom when one of the
endpoints was far off-screen. This patch uses interpolation to truncate
the constellation line at the edge of the visible skymap.
More patches by Markus Kaufhold (Thanks!):
- When playing a CD, show "Starting CD Audio track...", instead of "Connecting to stream source...";
- On Track Information Menu, show "CD Audio" for CD tracks, instead of "Remote Media";
- Disable inline editing for CD Audio Tracks.
A full pre-processor for the C# parser.
There is now a seperate pre-processor parser (csharp_pp) that works together
with the lexer so that the main parser only gets to see real tokens, with
no disruption from the pre-processor.
This commit also throws out the parser class's i/o actions from main.cpp
into a seperate, to-be-adapted-to-the-framework file called csharp-io.cpp.
So much for the foundations, now I can start with the actual C# grammar...
Adding user option to toggle Antialiasing on/off. Eventually, this will
be set via the Options window, in the Advanced tab. However, that tool
is still not functioning, so for now I am binding it to the "A" key.I had said on the mailing list that I was not going to keep the
integer-pixel draw functions, because they weren't much faster than the
floating-pixel equivalents. After looking at it again, the
integer-pixel draw functions are 20-40% faster than their floating-point
So for now I am going to commit the changes that include
using integer draw functions when antialiasing is off.Also, I have fixed the problem where star colors get saturated when
antialiasing is turned off (this was noticeable before while the sky was
in motion). The problem was caused by the fact that the colored rim of
star images cannot be less than 1 pixel wide without antialiasing. I
solved it by keeping the width at 1 pixel, but desaturating the color of
the rim by an appropriate amount. It works pretty well.Related API change: I removed some arguments from fromScreen() and
toScreen(), because we were just passing around things like
Options::useAltAz(), which are already accessible from within any
function. We still need to pass a "bool useRefraction" to toScreen, but
this should almost always be left at its default value (true), which
actually means "adopt whatever Options::useRefraction() is set to". The
exception is the Horizon; these points must never be refracted, so we
pass "false" to the argument, which means "ignore
Options::useRefraction(); don't refract the point".There's also some code in this commit related to adding XYZ support to
SkyPoint, but nothing yet that you'll notice unless you look at the
A new tool, the History Browser.
It's a small dialog you can use to navigate back and forth in the history of the current costruction.
At the moment it's quite simple, just uses the undo/redo texts as descriptions, but the system can be easily expanded to display better descriptions of the construction steps.
This will start to implement the part #3 of bug 121544.
Changes by Benoit:
- implemented highlighting of selected atom (paints it in a blue color that is
influenced by the original color)
- now uses GLColor struct to handle color stuff
- in big-spheres style, use smaller spheres (tell me what you think of this)
- some slotChooseStylePreset reorganization
Get rid of some more embedded XPMs in UI files.
In this case, (the button icons in the data manager) I have not added them back in
with kiconloader because
-I don't really like icons on buttons
-Several of the icons were really tacky in 22x22 mode, though
shrunk to 16x16 for the menues, they look semi-ok.
If anyone has strong feelings that we should keep the icons on the
buttons in the data manager, we can discuss kiconloading them.
Otherwise, they are gone.
FIxing an unnecessary bottleneck in the draw loop: I had been converting
the sky QPixmap to a QImage before calling drawImage() to render it on
the SkyMap widget. However, this conversion takes over 0.1 sec, so now
I simply call drawPixmap() instead.Between this change and making antialiasing optional, KStars should feel
much "snappier" now.The time elapsed for the drawing code is still about a factor of two
longer than it was under 3.5, but we're getting there. I added detailed
feedback messages for timing the various draw functions, but they are
commented out. If you want to enable them, look for "TIMING" labels in
the two files modified by this commit, and uncomment the relevant lines.
Speed up drawing stars. Thanks for the ideas, James.(1) Move color calculation out of draw loop. StarObject now has a
static QMap member that holds QColors for each spectral type. These
colors are updated once per draw cycle, to match the current state:
+ if using Antialiased drawing and map is not slewing, use full
+ if AA is off, or map is slewing, desaturate the color.(2) Draw star labels in a separate loop, so we don't have to reset the
Font and Pen color for each star.(3) Set the QBrush color outside the draw loop.
I guess #55795 is right - there's not much point in using a cache
if it doesn't really work by default. Make the backgrounds cache
size unlimited by default, people low on memory or whatever can
change it manually (or they shouldn't be using multiple wallpapers
at all in the first place).
Attempt at line-per-line loading of PNGs.
Lets me 'load' pippin's huge 31129 x 28957 file (with commented out layer preview and bird's eye). Loading itself takes something like 5 minutes, but doesn't take any memory with good swap settings. Afterwards, Krita consumes memory like a madman, I'm guessing part of it is the display code (changing zoom level takes about 2 minutes,
A couple more optimizations for splitting vectors. One of them makes search
faster in the simple case (no need for Boyer-Moore for a one-character search)
and append a null vector rather than instantiating a new one when we find empty
This gets the reading time down to 6 seconds here for the reported bug, which
still isn't great, but it's starting to get close to acceptable. I'll see if I
can get it a little tighter...
port to the new snapshot. break everything that uses kdialog since I don't feel like fucking porting stuff again after just finishing the other stuff.
What's the point of doing a kdelibs snapshot every two weeks if you're just going to updated it mid-cycle?