I Use This!
Activity Not Available


Analyzed 8 months ago. based on code collected 9 months ago.
Posted 3 days ago by Jasem Mutlaq (KNRO)
Glad to announce the release of KStars v2.7.4 for Windows 64bit. This version is built a more recent Qt (5.8) and the latest KF5 frameworks for Windows bringing more features and stability. This release brings in many bugs fixes, enhancements for ... [More] limited-resources devices, and improvements, especially to KStars premier astrophotography tool: Ekos. Windows users would be glad to learn that they can now use offline astrometry solver in Windows, thanks to the efforts of the ANSVR Local Astrometry.net solver. The ANSVR mimics the astrometry.net online server on your local computer; thus the internet not required for any astrometry queries.After installing the ANSVR server and downloading the appropriate index files for your setup, you can simply change the API URL to use the ANSVR server as illustrated below: In Ekos align module, keep the solver type to Online so it would use the local ANSVR server for all astrometry queries. Then you can use the align module as you would normally do. This release also features the Ekos Polar Alignment Assistant tool, a very easy to use spot-on tool to polar align your mount.Clear skies! [Less]
Posted 3 days ago by Martin Gräßlin
For years I have told people to not start Kate as root to edit files. The normal response I got was “but I have to edit this file”. The problem with starting GUI applications as root is that X11 is extremely insecure and it’s considerable easy for ... [More] another application to attack this. An application like Kate depends on libraries such as Qt. Qt itself disallows running as an setuid-app: Qt is not an appropriate solution for setuid programs due to its large attack surface. If Qt is not an appropriate solution for command line arguments running as root, it’s also not an appropriate solution for running GUI applications. And Qt is just one of the dependencies of graphical applications. There is obviously also xcb, Xlib, OpenGL, xkbcommon, etc. etc. So how can another application attack an application running as root? A year ago I implemented a simple proof of concept attack against Dolphin. The attack is waiting for dolphin getting started as root. As soon as it starts, it uses the XTest extension to fake input, enable the embedded konsole window and type into it. This is just one example. The elephant in the room is string handling, though. Every X11 window has many window properties and every process can write to it. We just have to accept that string handling is complex and can easily trigger a crash. Luckily there is no need for editing a file to run the editor as root. There is a neat tool called sudoedit. That does the magic of starting the editor as the user and takes care of storing the file as root when you save. Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit. Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure. I am also aware that if you run an application which is malicious you are already owned. I think that we should protect nevertheless. [Less]
Posted 3 days ago by Albert Astals Cid (TSDgeos)
It is available at the usual place https://community.kde.org/Schedules/Applications/17.04_Release_ScheduleDependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!
Posted 3 days ago by Qt Dev Loop
One can have real pain trying to create a demo setup or proof-of-concept for an embedded device. To ease the pain Qt for Device Creation has a list of supported devices where you can flash a “Boot to Qt” image and get your software running on the ... [More] target HW literally within minutes. Background Back in 2014 we introduced a way to make an Android device boot to Qt without the need of a custom OS build. Android has been ported to several devices and the Android injection method made it possible to get all the benefits of native Qt applications on an embedded device with the adaptation already provided by Android. The Android injection was introduced using Qt versions 5.3.1. whereas the supported Android versions were 4.2 and 4.4. It is not in our best interest that anyone would be forced to use older version of Qt, nor does it help if the Android version we support does not support the hardware that the developers are planning to use. I have good news as the situation has now changed. Late last year we realized that there still is demand for Android injection on embedded devices so we checked what it takes to bring the support up to date. The target was to use Qt 5.8 to build Boot to Qt demo application and run it on a device that runs Android 7.0. The device of choice was Nexus 6 smartphone which was one of the supported devices for Android Open Source Project version 7.0.0. The process We first took the Android 7.0 toolchain and updated the Qt 5.4 Boot to Qt Android injection source code to match the updated APIs of Android 7.0. Once we could build Qt 5.4 with the toolchain, it was time to patch the changes all the way to Qt 5.8. Since Qt version 5.4 there has been improved modularity in Qt and it became apparent during the process, e.g. the old Surfaceflinger integration was replaced with a platform plugin. The results can be seen in the videos below. The Boot to Qt Android injection is an excellent way to speed up the development and get your software to run on target hardware as early as possible. If you want to know more about the Boot to Qt and Android injection, don’t hesitate to contact us. The post Boot to Qt on embedded HW using Android 7.0 and Qt 5.8 appeared first on Qt Blog. [Less]
Posted 3 days ago by Kubuntu News
The second point release update to our LTS release 16.04 is out now. This contains all the bugfixes added to 16.04 since its first release in April. Users of 16.04 can run the normal update procedure to get these bugfixes. In addition, we suggest ... [More] adding the Backports PPA to update to Plasma 5.8.5. Read more about it: http://kubuntu.org/news/plasma-5-8-5-bugfix-release-in-xenial-and-yakkety-backports-now/ Warning: 14.04 LTS to 16.04 LTS upgrades are problematic, and should not be attempted by the average user. Please install a fresh copy of 16.04.2 instead. To prevent messages about upgrading, change Prompt=lts with Prompt=normal or Prompt=never in the /etc/update-manager/release-upgrades file. As always, make a thorough backup of your data before upgrading. See the Ubuntu 16.04.2 release announcement and Kubuntu Release Notes. Download 16.04.2 images. [Less]
Posted 3 days ago by Jos van den Oever (vandenoever)
You may have heard of Rust by now. The new programming language that "pursuis the trifecta: safety, concurrency, and speed". You have to admit, even if you don't know what trifecta means, it sounds exciting. I've been toying with Rust for a while and ... [More] have given a presentation at QtCon comparing C++ and Rust. I've been meaning to turn that presentation into a blog post. This is not that blog post. Here I show how you can use QML and Rust together to create graphical applications with elegant code. The example we're building is a very simple file browser. People that are familiar with Rust can ogle and admire the QML snippets. If you're a Qt and QML veteran, I'm sure you can read the Rust snippets here quite well. And if you're new to both QML and Rust, you can learn twice as much. The example here is kept simple and poor in features intentionally. At the end, I'll give suggestions for simple improvements that you can make as an exercise. The code is available as a nice tarball and in a git repo. Command-line Hello, world! First we set up the project. We will need to have QML and Rust installed. If you do not have those yet, just continue reading this post and you'll be all the more motivated to go ahead and install them. Once those two are installed, we can create a new project with Rust's package manager and build tool cargo. [~/src]$ # Create a new project called sousa (it's a kind of dolphin ;-) [~/src]$ cargo new --bin sousa Created binary (application) `sousa` project [~/src]$ cd sousa [~/src/sousa]$ # Add a dependency for the QML bindings version 0.0.9 [~/src/sousa]$ echo 'qml = "0.0.9"' >> Cargo.toml [~/src/sousa]$ # Build, this will download and compile dependencies and the project. [~/src/sousa]$ cargo build Updating registry `https://github.com/rust-lang/crates.io-index` Compiling libc v0.2.20 Compiling qml v0.0.9 Compiling lazy_static v0.2.2 Compiling sousa v0.1.0 (file:///home/oever/src/sousa) Finished debug [unoptimized + debuginfo] target(s) in 25.39 secs [~/src/sousa]$ # Run the program. [~/src/sousa]$ cargo run Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs Running `target/debug/sousa` Hello, world! The same without output: cargo new --bin sousa cd sousa echo 'qml = "0.0.9"' >> Cargo.toml cargo build cargo run The mix of Rust and QML lives! Of course the program is not using any QML yet. Let's fix that. Hello, world! with QML Now that we have a starting point we can start adding some QML. Let's change src/main.rs from a command-line Hello, world to a graphical Hello, world! application. main.rs before fn main() { println!("Hello, world!"); } Some explanation for the people reading Rust code for the first time: things that look like functions but have a name that ends with ! are macros. Forget everything you know about C/C++ macros. Macros in Rust are elegant and powerful. We will see this below when we mock moc. main.rs after extern crate qml; use qml::*; fn main() { // Create a new QML Engine. let mut engine = QmlEngine::new(); // Bind a message to the QML enviroment. let message = QVariant::from("Hello, world!"); engine.set_property("message", &message); // Load some QML engine.load_data(" import QtQuick 2.0 import QtQuick.Controls 1.0 ApplicationWindow { visible: true Text { anchors.fill: parent text: message } } "); engine.exec(); } Modules in Rust are called "crates". This example uses QML bindings that currently have version number 0.0.9. So the API may change. In the example above, the QML is placed literally in the code. Literal strings in Rust can span multiple lines. Usually you do not need to specify the type of a variable, you can just type let (for immutable objects) or let mut for mutable ones. Like in C++, & is used to pass an object by reference. You have to use the & in the function definition, but also when calling the function (unless your variable is a reference already). The QML code has an ApplicationWindow with a Text. The message, Hello, world! is passed to the QML environment as a QVariant. This is the first time in our program that information goes between Rust and QML. Hello, world! Like above, the application can be run with cargo run. Splitting the code Let's make this code a bit more maintainable. The QML is moved to a separate file src/sousa.qml which we load from Rust. import QtQuick 2.0 import QtQuick.Controls 1.0 ApplicationWindow { visible: true Text { anchors.fill: parent text: message } } You can see the adapted Rust code below. In debug mode, the file is read from the file system. In release mode, the file is embedded into the executable to make deployment easier. extern crate qml; use qml::*; fn main() { // Create a new QML Engine. let mut engine = QmlEngine::new(); // Bind a message to the QML enviroment. let text = QVariant::from("Hello, world!"); engine.set_property("message", &text); // Load some QML #[cfg(debug_assertions)] engine.load_file("src/sousa.qml"); #[cfg(not(debug_assertions))] engine.load_data(include_str!("sousa.qml")); engine.exec(); } The statements #[cfg(debug_assertions)] and #[cfg(not(debug_assertions))] are conditional compilation for the next expression. So when you run cargo run, the QML file will be read from disk and with cargo run --release, the QML will be inside the executable. In debug mode it is convenient to avoid recompilation for changes to the QML code. Listing the contents of a folder Now that we've created an application that combines Rust and QML let's go a step further and list the contents of a directory instead of a simple message. QML has a ListView that can display the contents of a ListModel. The ListModel can be filled by the Rust code. First we create a simple Rust structure that contains information about files. Q_LISTMODEL_ITEM!{ pub QDirModel { file_name: String, is_dir: bool, } } Q_LISTMODEL_ITEM! ends on a !, so it's a macro. Rust macros use pattern matching on the content of a macro. The matched values are used to generate code. The macro system is not unlike C++ templates, but with a more flexible sytax and simpler rules. On the QML side, we'd like to show the file names. Directory names should be shown in italic. ApplicationWindow { visible: true ListView { anchors.fill: parent model: dirModel delegate: Text { text: file_name font.italic: is_dir } } } The ListView shows data from a ListModel that we'll define later. The delegate in the ListView is a kind of template. When an entry in the list is visible in the UI, the delegate is the UI component that shows that entry. The delegate that is shown here is very simple. It is just a Text that shows the file name. Next, we need to connect the information on the file_system to the model. That is done in two steps. Instead of binding a Hello, world! message to the QML environment, we create an instance of our QDirModel and bind it to the QML environment. // Create a model with files. let dir_str = "."; let current_dir = fs::canonicalize(dir_str) .expect(&format!("Could not canonicalize {}.", dir_str)); let mut dir_model = QDirModel::new(); list_dir(&current_dir, &mut dir_model).expect("Could not read directory."); engine.set_and_store_property("dirModel", &dir_model); The model is initialized with the current directory. That directory is canonicalized. That means it is made absolute and symbolic links are resolved. This function may fail and Rust forces us to deal with that. If there is an error in fs::canonicalize(dir_str), the returned result is an error instead of a value. The function expect() takes the error and an additional message, prints it and stops the current thread or program in a controlled way. Rust is a safe programming language because of features like this where potential problems are prevented at compile-time. The last missing piece is the function list_dir that reads entries in a directory and places them in the QDirModel. fn list_dir(dir: &Path, model: &mut QDirModel) -> io::Result { // get iterator over readable entries let entry_iter = fs::read_dir(dir)?.filter_map(|e| e.ok()); model.clear(); for entry in entry_iter { if let Ok(metadata) = entry.metadata() { if let Ok(file_name) = entry.file_name().into_string() { model.append_item(FileItem { file_name: file_name, is_dir: metadata.is_dir(), }); } } } Ok(()) } There is a lot happening in the first line of this function. An iterator is taken over the contents of a directory. If the reading of the directory fails, the function stops and returns an Err. This is coded by the ? in fs::read_dir(dir)?. When reading each entry, another error may occur. If that happens the iterator returns an Err. We choose here to skip over the erroneous reads; we filter them out with filter_map(|e| e.ok()). Next, the entries are added to the model in a for loop. Again we see code that deals with possible errors. Reading the metadata for a file may give an error. We choose to skip entries with such errors. Only the entries for which Ok is returned are handled. The UI should display the file name. Rust uses UTF-8 internally and the file name can be be nearly any sequence of bytes. If the entry is not a valid UTF-8 string, we ignore that entry here. Another option would be to keep the byte array (Vec) and use a lossy representation of the file name in the user interface that leaves out the parts that cannot be represented in UTF-8. In other programming languages, it'd be easier to handle these cases sloppily. In Rust we have to be explicit. This explicit code is safer and more understandable for the next programmer reading it. And here is the result of cargo run. A directory listing with two files and two folders. a listing of files A simple file browser Listing only one fixed directory is no fun. We want to navigate to other directories by clicking on them. We'd like to have an object that can receive the name of a folder that it should enter and update the directory listing. To achieve that we need a staple from the Qt stable: QObject. A QObject can send signals and receive signals. Signals are received in slots. When programming in C++, a special step is needed during compilation: the program moc generates code from the C++ headers. Thanks to macroergonomics, Rust has more powerful macros and can skip this extra step. The syntax to define a QObject is simple in Rust and C++. This is our QDirLister: pub struct DirLister { current_dir: PathBuf, model: QDirModel, } Q_OBJECT!{ pub DirLister as QDirLister { signals: slots: fn change_directory(dir_name: String); properties: } } The macro Q_OBJECT takes the struct DirLister and wraps it in another struct QDirLister that has signals, slots and properties. Our simple QDirLister defines only one slot, change_directory, that will receive signals from the QML code when a directory name is clicked. Here is the implementation: impl QDirLister { fn change_directory(&mut self, dir_name: String) -> Option { let new_dir = if dir_name == ".." { // go to parent if there is a parent self.current_dir.parent().unwrap_or(&self.current_dir).to_owned() } else { self.current_dir.join(dir_name) }; if let Err(err) = list_dir(&new_dir, &mut self.model) { println!("Error listing {}: {}", self.current_dir.to_string_lossy(), err)); return None; } // listing the directory succeeded so update the current_dir self.current_dir = new_dir; None } } If the directory is .., we move up one directory with parent(). Again we have to explicitly handle the case that there is no parent directory. We choose to stay on the same directory in that case. If the directory is not .., we join() the directory name to the current_dir. We update the model with a new directory listing and print an error and stay on the current directory if that fails. QDirLister has to be hooked up to the QML code. We add this snippet to the fn main() that we defined earlier. // Create a DirLister and pass it to QML let dir_lister = DirLister { model: dir_model, current_dir: current_dir.into(), }; let q_dir_lister = QDirLister::new(dir_lister); engine.set_and_store_property("dirLister", q_dir_lister.get_qobj()); And this is how we use it from QML: import QtQuick 2.0 import QtQuick.Controls 1.0 ApplicationWindow { visible: true ListView { anchors.fill: parent model: dirModel delegate: Text { text: file_name font.italic: is_dir MouseArea { anchors.fill: parent cursorShape: is_dir ? Qt.PointingHandCursor : Qt.ArrowCursor onClicked: { if (is_dir) { dirLister.change_directory(file_name); } } } } } } To receive mouse input in QML, there needs to be a MouseArea. When it is clicked (onClicked), it calls a bit of Javascript that sends the file_name to the dirLister via the slot change_directory. our file browser Conclusion Hooking up QML and Rust is elegant. We've created a simple file browser with one QML file, sousa.qml, one Rust file, main.rs and one package/build file Cargo.toml. There are many nice QML user interfaces out there that can be repurposed on top of Rust code. QML can be visually edited with QtCreator. QML can be used for mobile and desktop applications. It's very nice that this wonderful method of creating user interfaces can be used with Rust. To the C++ programmers: I hope you enjoyed the Rust code and find some inspiration from it. Because Rust is a new language it can introduce innovative features that cannot be easily added to C++. Rust and C++ can be mixed in one codebase as is done in Firefox. Rust has many more wonderful features than can be covered in this blog. You can read more in the Rust book. Assignments I promised some assignments. Here they are. Show an error dialog when a directory cannot be shown. (Hint: the code is already in the git repo and shows a QML feature that we did not use yet: signals. Show the file size in the file listing. Do not make directories clickable if the user has no permission to open them. Open simple files like pictures and text files when clicked by showing them in a separate pane. [Less]
Posted 3 days ago by Daniel Nicoletti (dantti)
Yes, it’s not a typo. Thanks to the last batch of improvements and with the great help of jemalloc, cutelyst-wsgi can do 100k request per second using a single thread/process on my i5 CPU. Without the use of jemalloc the rate was around 85k req/s. ... [More] This together with the EPoll event loop can really scale your web application, initially I thought that the option to replace the default glib (on Unix) event loop of Qt had no gain, but after increasing the connection number it handle them a lot better. With 256 connections the request per second using glib event loop get’s to 65k req/s while the EPoll one stays at 90k req/s a lot closer to the number when only 32 connections is tested. Beside these lovely numbers Matthias Fehring added a new Session backend memcached and a change to finally get translations to work on Grantlee templates. The cutelyst-wsgi got –socket-timeout, –lazy, many fixes, removal of usage of deprecated Qt API, and Unix signal handling seems to be working properly now. Get it! https://github.com/cutelyst/cutelyst/archive/r1.4.0.tar.gz Hang on FreeNode #cutelyst IRC channel or Google groups: https://groups.google.com/forum/#!forum/cutelyst Have fun! [Less]
Posted 4 days ago by Jasem Mutlaq (KNRO)
When setting up a German Equatorial Mount (GEM) for imaging, a critical aspect of capturing long-exposure images is to ensure a proper polar alignment. A GEM mount has two axis: Right Ascension (RA) axis and Declination (DE) axis. Ideally, the RA ... [More] axis should be aligned with the celestial sphere polar axis. A mount's job is to track the stars motion around the sky, from the moment they rise at the eastern horizon, all the way up across the median, and westward until they set. In long exposure imaging, a camera is attached to the telescope where the image sensor captures incoming photons from a particular area in the sky. The incident photons have to strike the same photo-site over and over again if we are to gather clear and crisp image. Of course, actual photons do not behave in this way: optics, atmosphere, seeing quality all scatter and refract photons in one way or another. Furthermore, photons do not arrive uniformly but follow a Poisson distribution. For point-like sources like stars, a point spread function describes how photons are spatially distributed across the pixels. Nevertheless, the overall idea we want to keep the source photons hitting the same pixels. Otherwise, we might end up with an image plagued with various trail artifacts.Since mounts are not perfect, they cannot perfectly keep track of object as it transits across the sky. This can stem from many factors, one of which is the mis-alignment of the mount's Right Ascension axis with respect to the celestial pole axis. Polar alignment removes one of the biggest sources of tracking errors in the mount, but other sources of error still play a factor. If properly aligned, some mounts can track an object for a few minutes with only deviation of 1-2 arcsec RMS.However, unless you have a fancy top of the line mount, then you'd probably want to use an autoguider to keep the same star locked in the same position over time. Despite all of this, if the axis of the mount is not properly aligned with the celestial pole, then even a mechanically-perfect mount would lose tracking with time. Tracking errors are proportional to the magnitude of the misalignment. It is therefore very important for long exposure imaging to get the mount polar aligned to reduce any residual errors as it spans across the sky.Several polar-alignment aids exist today, including, but not limited to:1. Polar scope built-in your mount.2. Using drift alignment from applications like PHD2.3. Dedicated hardware like QHY's PoleMaster.4. Ekos Legacy Polar Alignment tool: You need to take exposure of two different points in the sky to measure the drift and find out polar error in each axis (Altitude & Azimuth)5. SharpCap Polar Alignment tool.Out of the above, the easiest to use are probably QHY's PoleMaster and SharpCap's Polar alignment tool. However both software are exclusive to Windows OS only. KStars users have long requested support for an easy to use Polar Alignment helper in Ekos leveraging its astrometry.net backend.During the last couple of weeks, I worked on developing Ekos Polar Alignment Assistant Tool (PAA). I started with a simple mathematical model consisting of two images rotated by a an arbitrary degree. A sample illustration of this is below: Given two points, we can calculate the arc length from the rotation angle, and hence the radius. Therefore, it is possible to find two circle solutions that would match this, one of which would be the mount's actual RA axis within the image. Finding out which solution is the correct one turned out to be challenging, and even the mount's own rotation angle cannot be fully trusted. To be able to uniquely draw a circle, you need 3 points. So it was suggested by Gerry Rozema, one of INDI venerable developers, to capture 3 images to uniquely identify the circle without involving a lot of fancy math.Since it relies on astrometry.net, PAA has more relaxed requirements than other tools making it accessible to more users. You can use your own primary or guide camera, given they have wide-enough FOV for the astrometry solver.Moreover, the assistant can automatically capture, solve, and even rotate the mount for you. All you have to do is to make the necessary adjustments to your mount.The new PAA works by capturing and solving three images. It is technically possible to rely on two images only as described above, but three images improves the accuracy of the solution. After capturing each, the mount rotates by a fixed amount and another image is captured and solved. Since the mount's true RA/DE are resolved by astrometry, we can construct a unique circle from the three centers found in the astrometry solutions. The circle's center is where the mount rotates about (RA Axis) and ideally this point should coincide with the celestial pole. However, if there is a mis-alignment, then Ekos draws a correction vector. This correction vector can be placed anywhere in the image. Next the user refreshes the camera feed and applies correction to the mount's Altitude and Azimuth knobs until the star is located in the designated cross-hair. It's that easy!Ekos PAA is now in Beta and tests/feedback are highly appreciated. [Less]
Posted 4 days ago by Lays Rodrigues
Yay! Now we have a logo! What do you think about it? Atelier is making around six months of development, and now is time to give you some updates. AtCore is on it's way to becoming stable, and I'm working on Atelier interface, so we can connect to AtCore and do some magic to everything [...]
Posted 6 days ago by nightrose
The city of Munich is currently considering a move away from Free Software back to Microsoft products. We consider this to be a mistake and urge the decision makers to reconsider. For many years now the City of Munich has been using a mix of ... [More] software by KDE, LibreOffice and Ubuntu, among others. Mayor Dieter Reiter (a self-proclaimed Microsoft-fan who helped Microsoft move offices to Munich) asked Accenture (a Microsoft partner) to produce a report about the situation of the City of Munich's IT infrastructure. That resulted in a 450-page document. This report is now being misused to push for a move away from Free Software. However the main issues listed in the report were identified to be organizational ones and not related to Free Software operating systems and applications. The City of Munich is of course free to decide on their IT infrastructure. Nonetheless we believe the move away from Free Software would be a big mistake and feel compelled to speak up. Specifically the move away from Free Software will not actually fix the issues identified in the report by Accenture remove vendor-independence which was one of the core arguments for moving to Free Software in the first place incur estimated costs of €90 Million to be paid by tax-payer money. Another €15 Million are expected to be spent on replacing or upgrading hardware that cannot cope with the requirements of Windows 10 but runs fine with Linux. The City of Munich has always been a poster child of Free Software in public administrations. It is a showcase of what can be done with Free Software in this setting. The step back by the City of Munich from Free Software would therefore not just be a blow for this particular deployment but also have more far-reaching effects into other similar deployments. That said, we take this opportunity to invite all other administrations to leverage the work done by the City of Munich over the last years and are willing to help resolve remaining issues in the City of Munich related to our software. Lydia Pintscher President, KDE e.V. Please also read the statement by The Document Foundation. Dot Categories: Opinion [Less]