News
Analyzed about 1 month
ago based on code collected about 1 month ago.
|
Posted
10 months
ago
by
Mark Gaiser (markg)
Hi,
In previous posts i completely ignored all things other then the Calendar part, but this app will do a lot more then just calendar stuff. In that regards the name might need to be changed? QML Calendar will actually use all (or ... [More] as much as possible) of the KDE KCalCore library. Or in a more abstract manner, QML Calendar will be able to use all of the iCalendar core “objects“. To sum that up: To-Do I don’t have any designs ready for adding to-do entries. They probably will be visible in the calendar as well. In time, this will get more clearly defined. Calendar This is the one that you’ve probably all seen by now. Journal A journal is just attached to any other event (todo, calendar …) that adds the possibility for you to make a longer description. This will obviously be added. Alarm Perhaps a bit unknown, but the iCalendar spec also talks about alarms. KCalCore has support for it and i will add it in. The only issue here is that i don’t quite know how to integrate alarms in this application without taking over functionality from KAlarm. On the other hand, it might be time to drop apps that are – in terms of spec – defined in one spec, but in terms of apps divided over multiple apps. So that would mean the QML Calendar is going to take over functionality from KAlarm and also replace that app. This is all unknown and just pure speculation. All i do know for now is that QML Calendar will have the ability to set an alarm like the spec describes. How it will be visually implemented (IF it will be visually implemented) is unknown. More on this as the app is being developed. Progress Update, QML issue. There hasn’t been a lot of updated in the public git repository (please note that it’s all highly WIP code! Even proof of concept!), but i am working hard on getting more stuff working. I am however hitting very annoying and hard to fix/workaround QML limitations! I hope that some people on planetkde have some suggestions for me here. What i’m working on right now is making entered events resizable. In reality that means making an event take longer or shorter. This task alone has a few very difficult QML issues to resolve. One is making resize handles. In QML 2 i could simply use the cursorShape property on 2 new mousearea’s (on anchored to the bottom of the event, one anchored to the top) and that would be it for the visual part. In QML 1 that property simply does not exist so i had to make it through C++. While it’s annoying, it’s fairly easy to do and not an issue anymore. Just a pain to see something that useful in QML 2 while i can’t use it in QML 1. Right now i’m planning to make QML Calendar in QML 1 so that it can be used for KDE 4.x. In time it will be ported to QML 2. The issue i have right now where i haven’t found a solution yet is when actually increasing/decreasing the height of an event. In a treeview the structure would probably look as follows: |- root |- – … lots of stuff |- – - Flickable — This is where all events in a day are contained. |- – - – Column — This is where the list for the events is being drawn, NOT the events themselves! |- – - – Repeater — This is actually putting the events on the right places. This is done dynamically! That’s important to know because they don’t have an ID! |- – - – … |- – - – Event .. No ID! |- – - – - Top mousearea (handle for resizing the event) |- – - – - Bottom mousearea (handle for resizing the event) |- – - – … |- – - – MouseArea — Yes, at the same level of the column with the width/height of the flickable content Now you see the rough structure that is in place. The actual issue is – as always – with the overlapping mouseareas! The way this works is that i need 2 mouseareas to work. The last MouseArea for the position and the top/bottom one for the pressed state. The last MouseArea has the full width/height of a complete day so i can directly use it’s y position to calculate where something needs to be placed. That works like a charm and nothing is wrong there. The issue is with resizing. If i want to resize the event i need to listen to the top/bottom mousearea which then changes the cursor to a resize shape. That also works, but in order to get that working i have to temporary disable the last mousearea as long as i’m hovering the top/bottom one thus i lose the real positions that i need to use to calculate where the event should be placed (or be resized to). That’s the conflicting issue i have right now where i don’t know any solution yet. So what i need to have is the mouse y position of the last MouseArea while i’m hovering/listening to the top/bottom mousearea. I can’t use the y position from the top/bottom mousearea since they are relative to their parent and only as high as i make them, which is 5px right now. Also, i don’t seem to have any way of translating the position of that relative mousearea to the last MouseArea. I thought of defining a list of Y positions where resize handles are positioned and checking against that list in the last MouseArea. That would probably work and prevent the sub mouseareas, but would be very easy to contain an error and difficult to make and maintain therefore i didn’t even bother trying that out yet. Be careful with making suggestions, anything that requires an ID is impossible to use because the events are placed dynamically and thus don’t have an ID. Not my choice, but a QML choice. I rather had ID’s since that would make things a lot less complicated. If you have a suggestion, please do share :) Cheers Mark [Less] |
||||||
|
Posted
10 months
ago
by
kallecarl
KDE has announced its Version 4.9 Releases to KDE Plasma Workspaces, KDE Applications, and the KDE Development Platform, dedicated to the memory of KDE contributor Claire Lotion. The full announcement has details.
These releases got special ... [More] attention to the general levels of quality and stability. In particular, there was a focus on eliminating any regressions from previous releases. Thanks to the efforts of the KDE Quality Team and its new contributors, the 4.9 Releases are the best ever. read more [Less] |
||||||
|
Posted
10 months
ago
by
Matěj Laitl (strohel)
Are you waiting impatiently for KDE 4.9? Warm-up your compilers with Amarok 2.6-RC that has been released just now! There have been a couple of bigger fixes since Beta 1, so we want to make sure that nothing hits your grandma in 2.6 final. Give it a good testing and report possible bugs to Bugzilla as usual. Thanks!
|
||||||
|
Posted
10 months
ago
by
Rolf Eike Beer (Dakon)
I was playing around with some content tags in CSS. Looks like I have been wrong recently when I said that Firefox still doesn't support it at all. In fact it looks like it is the only browser that does it all right.
So I created a test page ... [More] and loaded it in 4 browsers. You see on the picture on top left Konqueror from KDE SC 4.8.4, Chromium 21.0.1145.0 (svn138062) to the right, bottom left Opera 11.64 (build 1403), and finally Firefox 12.0. Just in case anybody complains: I upgraded to Chromium 22.0.1190.0 (144885), Opera 12.00 (build 1467), and Firefox 14.0.1, but the rendering is still exactly the same. So, what's up there? If you download the file and comment out the display:none for h1 you will see explanations what happens in the different versions of the test. I will just talk about the bugs here. Konqueror The width calculation is slightly wrong when the content is set to "", which is done right when it is set to none (the first 2 boxes). This leads to a spurious linebreak. (Bug K1 (#304357)) When there is no content at all there is also the spurious linebreak. (Bug K2, example #4). When there is no content at all the first elemtent shows a content that I have no idea where it comes from, possibly from invalid memory read? (Bug K3, example #4) When there are 2 consecutive elements of the same classes that differ in their text Konqueror will completely ignore the text content of the second one and use the one of the previous (Bug K4, example #5 and last element of example #6) CSS 2.1 spec says content applies to :before and :after pseudo elements. Konqueror nevertheless applies it to the main element also if it is specified there. Which is fine as it is allowed in CSS3 (K5 (#304355), example #1 and #2). Chromium if the elements have no contents element 2 is drawn on top of element 1, while the width of the ul that I use to hold the elements is big enough to hold both (bug C1, example #4). Only supports CSS2.1 (examples #1 and #2) Opera shares bug K4. I assume this is also the reason why example #4 is rendered wrong here, the "T" text that should be there is just dropped because the previous example didn't have it, but the rest is rendered correctly. (Reported by Martin Riethmayer as Opera bug DSK-371115) shares bug K5Also supports CSS3. Firefox Pass. Only supports CSS2.1 (examples #1 and #2) What's missing? I have not seen what Internet Explorer and Safari do. I assume Safari will be more or less the same as Chromium. And I have not reported all of these bugs yet. I'll do myself for the Konqueror bugs eventually, but will not do for any of the other browsers. If you would like to report any of these bugs anywhere please drop me a note so I can add links to the bug reports. Edit: K5 was actually E1: Opera and Konqueror support CSS3 generated content where this is allowed. [Less] |
||||||
|
Posted
10 months
ago
by
Anne Wilson (annew)
When we added Questy Capture to our wikis the amount of spam dropped dramatically, but to be efficient we need many questions, used randomly. We do have a few, but it would help to have a few more. Today a single spammer hit both UserBase
... [More]
and TechBase. Of course a determined human spammer is hard to defeat, but bots find this method quite difficult to beat.
A simple definition of a good question - the answer must be simple enough for any interested person to know AND not language or culture dependent OR the question must refer to something actually on the registration page display (which can include sidebar or footer) Send your suggestions (including answers, multiple if appropriate) to kde-www AT kde DOT org [Less] |
||||||
|
Posted
10 months
ago
by
Krita News
The contract signed, Arjen Hiemstra and I have started good and well on Krita Sketch, the touch-enabled version of Krita. We're developing mostly on Windows, for Windows. All our code is in the krita-sketch-rempt branch in the
... [More]
projects.kde.org/calligra git repository. Arjen created a mockup for the touch gui, and this week the real work begins: coding on the QML gui, the new canvas, the multi-touch interaction system, the psd import/export. The works!
There is one skill badly missing in our team, though, and that is graphics design. We, that is KO GmbH, is looking for a graphics designer to work with us to create the look of Krita Sketch. That's icons, welcome page, buttons, everything that's needed to make Krita Sketch look right. This is QML, so we're hardly bound to any platform standards. This is the goal: Krita Sketch is going to be the touch paint application for people who want to really create, not a gimmick like Microsoft's FreshPaint. It has to have a cool, inviting, understated, professional, productive, smooth look and feel. There will be lots of stuff happening, since we will allow people to work with layers, filters, selections, transform tool and so on. If you want to work with us on this, please mail an application with your ideas, some examples of previous work, your rate and so on to boudewijn.rempt@kogmh.com. Experience with QML would be a good thing, but is not an absolute necessity. It's a freelance job. Working remotely is no problem at all, though a modicum of timezone compatibility with CEST would be nice. (In other news, Sven Langkamp is an absolute big fixing hero, while I've found time to fix some rather bad bugs in our color management, thanks to the work of Elle Stone, who figured out some discrepancies in the results of Krita and other applications. That work will soon be merged to master, in time for the Krita 2.6 release, as well as work done on the OpenColorIO integration.) [Less] |
||||||
|
Posted
10 months
ago
by
Dario Freddi (drf__)
Howdy,
welcome back! Preamble about this series This series will be structured in 3 posts: The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in ... [More] KDE. The status – what have been others up to in this topic. The solution – a proposed solution to improve our system, based on the previous posts. This is, guess what, part 2. About the previous post It was great to see interested comments and most of all actual replies to my questions. I want to clarify a couple things before moving on: Some of you mentioned the existence of indicators, Colibrì and such. No worries: I know about them and of course they played a big role in my analysis. Though, I intentionally left them out of my problem analysis since they’re not a part of the stock KDE framework, and we want to aim for a solution which somehow “integrates” everything in one single place and API I got some great answers to the “more than one action question”. Especially, several people agree on the “invitation” (I really like the name, credits to TheBlackCat) to A/V calls. We’ll see how they scale as we go Also, Celeste pointed me out a usability study she is promoting targeted towards finding out how to make the notification system better. Needless to say this is also very helpful for the project you’re reading about, so I encourage you to spend some minutes of your spare time to help out. The link is above, but in case you read through it, here it is in its full glory: http://community.kde.org/Projects/Usability/KDE_Notification_User_Experience_Study Preamble about this post Those of you who might have come here getting ready to read a comparison between GNOME, Windows, Mac OS, etc. will probably be partially disappointed in seeing that my primary case studies actually do not belong to a desktop environment. Why, would you say, since this is what we’re trying to address? The first and obvious answer is that KDE is no longer “only” desktop, and needs a concept which scales. The second one is that (not even that) surprisingly, completely different appliances have the same needs and the same problems to address. After all, when you come to think about it, a notification is just… a notification. WARNING: Long post is long. We will start by analyzing Facebook first. It is a great example in many ways, and a bad example in other ways, and we will now see why. First of all, let’s take a look at the basics. I guess all of you know the system fairly well, but I found a couple pictures which are especially valid for showing you what I want to show you: Let’s start analyzing the picture. First thing we notice, Facebook is split in 3 areas: friend requests, messages, and other. First question – why the heck do I have a friend confirmation on my “other” stream? I’d expect all friendship-related activities would go in the “friend” area. There is a reason for that, though, and it makes sense to me. Also, you might have noticed that this screenshot is from an old version of the system – intentionally. I want to try to focus on the differences and on the evolution. Now, notice the left bar. We see that we have Messages and Friends again. Does it make sense? Why is that? To be honest this is a part I don’t like, since it’s a duplication of information, but it helps in proving a point: friends and messages are stuff on which you want to take an action, which might be delayed, but still needs to be undertaken. On the other hand, you can disregard and not be reminded of the fact that $GUY is stalking your pictures. This is a child of the “transient vs. persistent” issue. In the web world, the concept of transient notifications almost doesn’t exist after all, but here we stepped over a similar principle: prioritization. Facebook clearly tells us that some events are more important than others, and should be considered in a different way. Coming to think about it, isn’t that also partly true for your desktop? But the reader might now think: then maybe the whole transient deal is just bul^Wcrap. Not really – the reason is that a web application such as Facebook cannot really have such a concept since it acts in a disconnected way most of the time. But in that list, for example, I’d rather not have a persistent notification everytime someone “likes” my post. Ok, it sets my ego on fire, but it can become annoying. That’s a case where probably a transient notification would have cut it better. But, let’s move on with our analysis. Ok, that’s something more recent. What changed? The first impact would say “The picture on the left”, which is correct. But to me there is something much more important: grouping. Notice how before we had a notification about “X commented Y”, whereas now we have “X,Y,Z and other stalkers commented W”. There is also something else which gives grouping even more sense, you can notice it on your account: a small “x” icon on the top right of every notification. I understand it’s not really discoverable, and also its purpose is weird: if you hover on it, you’ll see a label “Unfollow”. In fact, clicking that button will simply stop giving you notifications about that specific post. This is quite awesome in my opinion – not really for the feature itself, which I consider quite undiscoverable and barely useful for most of the audience (probably the reason of its discoverability), but for showcasing the power of grouping. Not only I will get one single notification for any event happened in a particular stream, but I also have a single entry point for deciding not to be notified of a particular stream anymore. In particular, there is something really significant here if you compare this approach with messaging: we are now used (thanks to mobile phones which now find fancy to arrange SMSs by conversation [yes I know threads existed before that but I'm considering what IMHO made them mainstream</hipsterism>]) to consider messages in the context of a thread. Slowly, we are starting to consider events in a thread as well, where a starting point (in this case, a post) leads to a chain of events belonging to the same thread. To counter the obvious “posts can be considered behaving as messages”, sharing notifications and like notifications work in the very same (threaded, grouped) way. Also, this leads to a MUCH lower number of notifications, and *uh oh* introduced somehow transient notifications in Facebook! If you notice, now everytime a notification enters your stream, you get a nice bubble on the bottom left, sitting there a couple seconds. The behavior of this thing is really interesting and worth a study. This picture is good enough for showing you what I am talking about, but not for proving my point in its entirety. Suppose a new event happens, $GUY comments a picture of yours. The bubble will appear and a notification stacked. You can directly take the action by clicking on the bubble itself, including discarding (the X is much more discoverable here, imho). In this case, the notification will disappear. But there’s more to that, and here comes the concept of a transient notification. Suppose you weren’t at your PC, you come back and you see a “1″ in your “other stream”. Now, another guy comments. The same bubble appears, the notification is grouped, but “1″ remains “1″. This is as close as a transient notification can get, since you will just notice 1 notification if you weren’t in front at your PC, but you would have witnessed a whole stream of comments if you were sitting right there, and you could have taken action on any of them. Instead, the “root” notification will just bring you to the first unread comment. Also, the “x” in the bubble behaves in a very different way: instead of unfollowing the related stream of events, it simply “silences” the notification. Enough with Facebook? Not yet, there is one last thing. I am sorry I couldn’t find a better picture, but as you know the notification area looks exactly the same as this screen. What is weird? Yes, interaction. We’ve seen how Facebook is keen on having us clicking the notification to pursue an action, but here we have 3 choices: Look at his profile Accept Reject I think it’s bad. It’s really inconsistent with the rest of the interface, and kind of breaks the paradigm we’ve seen in the rest of the system, which in my opinion remains really good. Google+ Google+ notifications are a very good case study for tackling the two weird things we found in Facebook: the separation between events (G+ has a single notification area) and the interaction. Let’s see why. First of all we notice two obvious things: the grouping is even more aggressive: the “Friend” area of Facebook has been shrinked to a single grouped notification (this is closely related to how interaction works). Secondly, the layout helps the impression of grouping by showing a visual feedback of roughly how many events the notification refers to (by showing a set of pictures, or a “stacked” set of pictures). But the way one interacts with notifications is probably the most interesting part of G+: Clicking on a notification brings up a full interface to the event that notification would have led to. This solves in a very interesting way the issue with interaction. Usually, the chain of arguments is that you need more than one action, you need a lot of them since otherwise the problem would be made worse, as instead of having one clear thing to do, you would have to cope with a downscaled interface for making your choice. There I fixed it: now you simply have your whole interface to deal with. But when we port this to our case (KDE), we should ask ourselves: is this that much different than opening a new window? My answer is: not that much. The reason why people like this approach is that their workflow is not interrupted in any way – they can check out the event, maybe even reply to a message, then they can close the notification area and – bang – back to where they were. In a way, we can say that every G+ notification has one single action: “interact”. Bored with all this social crap? Time for… The N9, or: the mobile world I am intentionally considering only the N9 since it’s the only smartphone I know really well (since I use it daily). I won’t be as long as before, since many things are just the same as before: The N9 groups events: you get a single notification about having 5 sms incoming The N9 does something very close to Facebook about transient/persistent notifications: you get the equivalent of the “bubble” which is instead a small banner on the top of the screen. The behavior upon clicking/stacking is exactly the same The N9 allows a single action a-la-G+: when you act on a notification, a full interface is brought up for you to choose how to interact with it. There are, though, a couple really interesting things in the N9. Let’s have a look at them. Oh, how much I love this. The notifications on the lock screen really just cut it when I check my phone for events. And what about swiping on them to activate the notification itself? Just amazing. This really shows how it is possible to make notifications an integral part of your experience when you are “offline”. I am really sorry I couldn’t really find a picture for the next thing I want to show you. Some of you might know the N9 integrates its notifications with Facebook ones, basically showing notifications from Facebook as native. The interesting part here is that the grouping happens in a completely different way. A typical example of notification you might get is: 3 new notifications 4 new messages 15 new friend requests Whereas for the “global notifications” it doesn’t really make sense, it is really interesting to see that the “new friend requests” grouping is incredibly close to G+ as a concept, and acts in the same way. Differences Those three cases quite cut it in my opinion, and really help in showing mutual similarities and differences. In particular, we’ve seen how G+ tackled the concept of notifications in a way which is really close to the mobile world: a notification opens an application. Sure, the interface is different, but the principle remains – instead of giving the choice of taking a stock action, it leads you to a richer interface in case it’s obvious that you might want to undertake more than one choice. Facebook does this when it comes to messages and posts, but fails in applying this concept to friend requests – probably on purpose. Recap So what did we learn today? That the outer world already found several possible solutions to the problems we have previously outlined, and somehow faced most of the challenges we are up to. The circle is about to close with the next blog post, where I’ll try to gather what we learned up to now and try to come up with a concept which might, eventually, become the guideline for a new notification system in KDE. While you’re waiting, are there any other existing notification examples you’d like to point out? And thanks for reading until here, that was indeed a long run. [Less] |
||||||
|
Posted
10 months
ago
by
Cezar Mocan (CezarMocan)
Hello again Marble fans! As August approaches, the process of replacing the Atlas map is progressing and producing pretty good results. Last time I posted, I managed to open SHP and make them work with filtering. Right now, Marble has a fully
... [More]
functional Topographic Map (same as the old Plain Map, just that vector layers are replaced with geodata layers).
The first step needed in order to get here was to create a new DGML file, for the new Topographic map, that loads the SHP and KML files which create the map. After this, i had to manually create an Ocean Layer, for making the Earth blue, since the old map had one of its own. After following these steps the Earth looked… a little bit pink (the colors are hardcoded for now, since SHP files do not define colors and styles, as KML’s do) Back to serious business Brush applied, same color as Plain Map, but still hardcoded. Now, for recreating the functionality of the DGML vector style, I had to make the pen and the brush customizable from the DGML file (meaning that the colors of the map can be set from the DGML, using tags, with nothing to change in the code). The basic principle of this action was to take the penStyle and brushStyle obtained by the DGML parsers and assign them to the GeoDataDocuments created from parsing the SHP maps, and I had to deal a lot with four files: MarbleMap.cpp, MarbleModel.cpp, FileManager.cpp and FileLoader.cpp. Briefly, I obtained the style defined in the DGML file inside MarbleModel.cpp and transmitted it up to FileLoader.cpp, where I applied it to the documents. Here’s how the map looks right now (with colors and pen styles customizable yay ): Still, we’ll have to deal with a bug, coming from the SHP parser I believe. If you look carefully in the map below, parts of some border lines do not get displayed… Any ideas why? Next, I have to add the Texture Layers to this map and say bye-bye to the old Atlas Map too [Less] |
||||||
|
Posted
10 months
ago
by
Laurent Montel (mlaurent)
Another new application is BackupMail.
I developed during 4.9 cycle after seeing that there was no application to export/import KMail data in order to transfer the KMail settings from a computer from another, for instance. Until now the ... [More] method (in KMail1) to restore KMail was to create an archive and extract it in the new user home. But with Akonadi it was not possible to do it, because we use numeric identifiers for folders, in the configuration files, rather than folder paths. So all configs will break if we just copy the config file to another computer, where the numeric identifier will be different. What is necessary to backup/restore in KMail application? - The main configuration file, kmail2rc, of course. - Maildir directory structure, mailbox files. - identity settings. - filters settings. - mailtransport settings. - all pop3/imap/maildir/mailbox resources. - ldap server (kabldaprc). - Akonadi database. - and other configs as templatesconfigurationrc, akonadi_archivemail_agentrc. So before saving data in zip file, we must to convert all configs settings which use an akonadi id to a real path. When we restore them, we convert real path to an akonadi id. I developed a piece of code which tests if a real path can be found in akonadi database and returns its id. During restoring we will not just overwrite config files we will merge information when it’s possible. For example we do not overwrite akonadi resources but we create new resources. So it is not conflict with existing setup. Same as for identities and mail transports. We will adapt filters arguments to use new identity or collection folder etc. Future in 4.10: I will continue to improve it, and merge some settings, for example ldap server for the moment it is not merged but I overwrite a file. I will create an expert mode where we will able to specify which resources/settings we want to import. And perhaps I will extend backup to other pim applications. If you have some features to add it send me an email or report it to bugs.kde.org [Less] |
||||||
|
Posted
10 months
ago
by
Tom Albers
KDE has a service known as Commitfilter at commitfilter.kde.org. This is a service allowing you to receive email notifications when someone commits. You could also subscribe to the kde-commits mailing list, but that has mails for all projects, which
... [More]
means a lot of mail. You would have to filter out the things you are not interested in. Commitfilter does this for you.
When KDE switched to git, we tried to keep it compatible, so on each git commit we pass some headers in the commit emails. This way you can still use commitfilter to receive emails coming from commits made to git. But this is not very known and very unintuitive. On the plus side, it keeps filters people setup for svn projects which have now migrated to git working. KDE Sysadmin is now at a point that we want to change all of this. We want to integrate it into projects.kde.org. The idea is that we would like you to login to projects.kde.org, select the projects you are interested in by checking a checkbox and that should be it. You should then receive mails for commits made to git for that project. Of course that will not work for the subversion commits, but that’s covered nicely by commitfilter for now. The subversion era will come to an end some day anyhow. Anyhow, what we are looking for, is a hacker that would like to help us. None of us are capable of writing code for projects.kde.org and we would really like to have a plugin for it. If you are a Ruby on Rails hacker and want to write a plugin for us to integrate into the Chili project software we would really buy you loads of beers. The only thing that we need is a little checkbox on each project saying ‘receive mails for each commit’ for each user, make sure that is saved properly and give a nice XML-file as output with a list of users and projects. We will take care of the rest. If you are interested in all that beer, just drop in #kde-sysadmin channel, or send a mail to sysadmin@kde.org. photo by: alexeyklyukin [Less] |
||||||
Code Data
SCM Data
Community Data
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.