|
| This Week... |
|
Further XMP tag support in Digikam. Beginnings of a Plasma lock/logout applet and a weather applet, to display data from the existing weather data engine. Continued work on the new Plasma-based KNewsTicker applet. Continued work and development ideas in Parley. More various developments and optimisations in KHTML. Jamendo album download support in Amarok 2.0. Interface usability work in Kopete. Shredding functionality removed from KGPG. Fixes in the Sonnet spellchecking solution for KDE 4. Work on the foundations of KChart 2 in KOffice. Lancelot and Raptor develop as alternatives to the Kickoff menu of KDE 4.0. Okteta, a planned successor to KHexEdit, uploaded to playground/utils. KOffice 1.9.95 and KDE 4.0 Beta 4/KDE Platform RC1 are tagged for future release.
|
Ivan Čukić introduces his work on Lancelot, a menu alternative based on Plasma:
|
Lancelot is an experimental launcher menu designed to provide a place from which all your jobs begin. It provides quick access to applications, places, documents, contacts and system information.
The word "experimental" stands for a couple of things:
- The (optional) no-click interface that allows you to navigate through the menu, and start any application just by moving the mouse - without making a single click.
- Arranging the items in the menu depending on the position of the menu button which activates it.
Existing "menu replacements" have, in my opinion, one common weakness - in order to make some things more accessible, sacrifices had to be made. One example would be Kickoff's way of browsing non-favorite applications, which is too slow and hides the "whole picture" from the user by not showing the list of all categories at all times. On the other hand, Tasty Menu does the job of application browsing very well, but it is too large and not well-thought through.
Lancelot is trying to make a compromise between the two approaches - to be relatively small, and to have unimpaired accessibility.
Currently, the vast majority of GUI work is finished. The only thing left to develop is the Passageway component, which will be the responsible for application browsing.
Apart from that, data models need to be made. Currently only models for the "Computer" category are made and can be tested. I hope to finish the basic functions by the time KDE 4.0 appears.
After that, special features will roll in - ability to add Plasma applets into the menu itself, adding parts of the menu to the Plasma desktop, composite effects, and more.
Like the most things related to Plasma, I intend to make Lancelot just-work(TM) for 4.0, and to make it Work-As-I-Think-It-Should(TM) for 4.1.
|
|
Jasem Mutlaq writes about his experiences integrating KStars as the control mechanism for a telescope at an observatory in Kuwait:
|
I've been working on Kuwait Science Club 0.5m telescope for the past few months and what an interesting project it is! It is one of these projects where you have to dwell deep in many disciplines to get things right.
The observatory houses a Swiss-made equatorial fork telescope with two OTA each 0.5m in diameter. It was used to do pretty interesting research up until a few years ago when new cities were build close by and now light pollution degraded its abilities drastically.
Since its commision, it's always been in manual control where the observer uses a keypad to move around in the sky. This is obviously a tedious process but for the few bright objects in the sky. Furthermore, the Swiss company who delivered the system with a computer never really got it to work, or so I'm told since the computer was thrown away long time ago.
What was particularly irritating is the complete lack of documentation. No one knew anything about the telescope save for the diameter of the mirrors and its commission date, it seems that everything else got lost somehow. So this is when I had to 'reverse engineer' the system starting from the keypad up to the servo motors..etc. I had to install new 12 bit absolute encoders for the RA and DEC axis, and design a PCB to act as a 'digital' keypad using optocouplers primary.
Then by using NI 6905 Digital I/O card, which is well supported under Linux, I controlled the new board, and received the encoder data. Then all I had to do was to write the INDI driver to achieve a closed-loop control.
Suffice to say, the hardware took the most time, mostly because I had no docs and I had to find how the electronics work out on a deep level. It was all new to me. Also, since this is a really heavy telescope (I was told 9 tons, but I really doubt it), safety is quite important.
There are minimum allowable altitude safety guards in the driver, auto and emergency park in case something goes wrong, and a watchdog that shuts the telescope even if the whole operating system crashes. But would you bet your life on software alone?
There are also two hardware limits switches for each axis that shuts the telescope down if it goes too far, and if all that fails, I installed an emergency stop button connected directly to mains. If THAT fails, then you probably deserve to die anyway.
The last tricky part of the whole deal was pointing performance. Since we're dealing with a really old mechanical system, the pointing accuracy is limited by numerous factors including index and collimation errors, fork flexture, and a lot more. We had to use TPoint to build a pointing model for the telescope to bring the pointing accuracy down. This is still in progress, but the overall control system is done.
Here is a video showing the telescope and KStars. I used my digital camera so I apologize if it's not clear enough.
|
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes) |
![[*]](/images/standard/features) |
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
![[*]](/images/standard/optimise) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
Development Tools |
|
Oswald Buddenhagen committed changes in /branches/KDE/3.5/kdevelop/lib/widgets:
|
stop chopping up message lines from compiler, etc.
note that lines that were previously chopped up will now come in out of order. while this "regression" could be fixed, there is no guarantee at all that the complete lines arrive in order in the first place, so i see relatively little point in bothering with this. |
|
|
|
|
|
|
Andreas Pakulat committed a change to /branches/KDE/3.5/kdevelop/languages/cpp/cppsupportpart.cpp:
|
This should fix the lag that could be experienced, specially on larger projects. As David pointed out the updatedSourceInfo signal is more like a "the whole code-model changed" thing.
Everybody who experiences short delays when typing normal code, please svn up and test. I couldn't get the delay to work here the last days so I'm not 100% sure it fixes this problem (but I'm pretty confident) |
|
|
|
|
|
|
Educational |
|
Jason Harris committed a change to /trunk/KDE/kdeedu/kstars/kstars/skymapdraw.cpp:
|
Jure: thanks for finding a memory leak in KStars!
Unfortunately, your fix was not correct, because we set "pLast = pThis" prior to your "delete pThis". Therefore, pLast would be a null pointer when we still need it.
Instead, I have made pThis and pLast normal objects, rather than pointers. James, can you review this patch? I am in the midst of a large set of changes ATM, so my local copy is not compilable. |
|
|
|
|
|
|
|
|
Graphics |
|
Albert Astals Cid committed changes in /branches/KDE/3.5/kdegraphics/kpdf/xpdf:
|
Splash rework, check if font is inside clip area before rendering it to a temporary bitmap. Fixes bug 150693
This change is not trivial. What i did is:
It is getGlyph the one that does the intersection between clip area and rendering area of the font instead fillGlyph2
That means some clipRes = state->clip->testRect but we win more robustness against broken pdf that specify HUGE fonts |
|
| | | |
