I created packages for the nice KDM and ksplash theme Steampunk. For this theme a matching color scheme, wallpaper and mouse theme exist and those are packed in the same rpm. Youtube shows the theme in action for Kubuntu, the version in the rpm is distribution neutral. The rpm can be obtained from the home:rbos repository, I hope you enjoy the theme.
Posts Tagged ‘KDE’
So in my head there’s a little Walter Sobchak beating on my conscience and shouting “This is what you get when you trust Facebook with your data, Will”.
The reason is that I upload photos to Facebook using KDE’s shared uploader and this has fallen victim to the whims of FB’s purge of its app biosphere. Unless the original developer can convince them that the app is not spammy, offering a bad experience or having the wrong attitude, the app, my photos (all archived elsewhere of course), but most importantly, all the kind comments from my friends and contacts that represent FB’s only value, get sent to the farm.
This is what you get when you trust one company with stuff you care about. Will.
With the release of GNOME3 I would assume that people are interested in seeing how YaST2 (suggestion: rename it to YaST3 !!) is going to take form with GTK3. Of course this means eventually writing another application in GTK3, hopefully different from the old gnome-control-panel ‘style’ which was actually pretty confusion from the user point of view as it was far too close to gnome-control-center, thus confusing new comers.
My suggestion (unaware if it’s possible or not) was probably to explore GNOME3 features to serve YaST integrated already with GNOME3. This could be an interesting approach as it would offer integration and some advantages:
* Better integration with GNOME3 without having to write(/maintain another application;
* Take advantage of YaST2 modular structure;
* Present YaST in a prime space in GNOME3, thus offering a openSUSE differentiation point;
* No conflicts with possible KDE existing front-ends for YaST2;
* Improve users experience.
My proposal would be something like (maybe to be served as an extension for gnome-shell). Please neglect my ‘lame’ photo manipulation skills:
I’m blatantly abusing GSoC for a project that I would like to see in openSUSE but that I’ve never had time to work on. But really it’s a worthwhile thing to have: a set of Plasma widgets that users and developers can add to their workspace to make it easy to see what’s going on in OBS in the projects that matter to them. If you want to work on a fun project with cutting edge technologies such as Qt, QML, Plasma then head on over to the GSoC 2011 Ideas Page.
Its Hackweek number six at SUSE as you might have heard. Hackweek is great as employees are encouraged to work on a free software project they want. I work on my project Kraft and really appreciate the time that I can spend on it.
What I intend to do can be summarized with Share your Kraft. Up to now, Kraft is working fine for a single user. But what if a team wants to use Kraft and share number cycles (which are base for the document numbering like invoice number), documents and template catalogs? Well, as long as they share the same database, it might work (I didn’t test deeply) but if they happen to be on different locations it becomes difficult. I try to make that possible.
My development target for Kraft is simplicity. For the user of course, but also for the setup. The server to share data, which is obviously needed, must work on a cheap hosting offer, and it must work with a weak internet line. So a database connect via internet is not possible.
I decided to investigate in ownCloud and enhance it with a plug-in called KitoC. ownCloud is a project started by Frank Karlitschek and implements a handy but scalable WebDAV Server beside more. Seems to fit my needs perfectly. Yesterday I implemented the number server function in KitoC after good conversation with Cornelius at breakfast in the office. Not very much achieved yet, but had to learn a bit of ownCloud first. I keep you posted.
Universidad Latina, Facultad de Ingeniería. “LibreSoft”. July 1st., 2010 from 6:00 p.m. To 10:30 p.m. (- 5 EST) several FOSS individual representatives held a meeting on 3rd floor of the main building, gave some talks about FOSS, software developments, open source, licensing, sharing code, community contributions, and applications to the general public, Telecommunications and Industrial Engineering students, professors, dean and lawyers. OpenSUSE Ambassador, Ricardo Chung, shared the space with Diego Tejera (Ubuntu LoCo Team), Alejandro Perez ( Fedora Ambassador ), Abdel Martinez ( Fedora Campus Ambassador), Adrien Scott ( www.fosdev.com) and others. Ricardo gave a talk about openSUSE 11.2 features and some sneak preview features on openSUSE 11.3 ( http://en.opensuse.org/Product_highlights_11.3), the openSUSE Build Service 2.0 ( http://en.opensuse.org/Build_Service) as software development and colaboration platform useful for any Linux distribution, SUSE Studio to customize our distribution on different enviroments, and KIWI to make an operating system image available on physical media ( http://en.opensuse.org/Kiwi ). Ricardo also, answer some questions about openSUSE community and local users group, installation, as well as some questions about Novell and Microsoft alliances were clarified. After the talk an openSUSE and Novell trivia was given and the winners got some openSUSE 11.2 CDs with Gnome Desktop by default.
Make a click on http://picasaweb.google.com/RICARDO.A.CHUNG/OpenSUSEAtLibreSoft# to watch some photos
A little more than two weeks ago we released Kraft version 0.40, the first version of Kraft based on KDE 4 software platform. The release went fine as far as I can tell, no terrible bugs were reported yet. Some work went into the new website since then, but in general I need a few weeks break from Kraft and spend my evenings outside enjoying spring time.
Today, Sourceforge posted a blog about Kraft after they kind of mail-interviewed me. It’s nice, it really focuses on the things also important to me. This might be another step towards a broader user base for Kraft. I say that because one could have the impression that the number of people actually really using Kraft could be larger. A high number of users is one of the fundamental criteria for a successful free software project and thus I am constantly trying to understand whats the reason for the impression or the fact.
The first idea is that the Kraft project simply does something wrong in the way a project should be driven. But there are releases, there is a so far ok website, there are communication channels with information on it and people answering questions. Of course, it always could be done better, but I hope and believe we are not doing too bad. Marketing could be more, that’s granted.
The next thing could be that nobody needs this kind of software. But there are quite some companies doing this kind of software in the commercial space. So there must be a market. Actually I think the market is huge. People are writing invoices all over the world and I bet many of them are not really satisfied with the way they do it usually which makes Kraft at least an option to try for them.
And this might lead to better path: Probably these people do not know that the option exists. They simply haven’t heard about Kraft yet and if they would there is a good chance that they would not believe that it is free etc pp. And this is probably not specific to Kraft but also applies, of course much more weaker, to larger projects like openSUSE or KDE: A lot of people from the ‘real world’ don’t know about free software communities, the ideas behind and the benefits for users of the software. That sounds strange to us, as this is our daily reality, but start with asking your parents or non computer related friends if they really understand what it is about. Imagine what people know who have no computer job nor -hobby nor know you!
What consequences can that have for us? Well, we could decide to skip this group of people. That would mean, beside some other effects, that Kraft would not make sense any more and I don’t like that. It probably should influence the way we see the ‘product management’ aspect of our projects. For me, ‘product management’ is often equivalent to “take care that the result is especially useful to non computer scientists” (which is probably not what PM really is about) and the focus on that is very important and the precondition for the next point.
We might have to take our projects even more out of the geek niche and go to places where the ‘real world’ happens. That is difficult for various reasons. First, it means that we have to start to explain again from start, and maybe also get questions where the answer is not obvious. Furthermore it might have practical issues, because for example fairs for handcrafter utilities charge seriously for software boothes which is not the case if we present projects on FOSS events.
On the other hand its easy because we all just have to spread the word even more and tell everybody about free software, our projects and free culture. And try to think as if we weren’t free software people. I know, most of us do already what they can and that’s great
For the last seven days we were hosting the KDE Plasma Team doing their developer meeting called Tokamak4 here in at the Nuremberg offices of Novell. It was great for SUSE to see the twentyfife KDE enthusiasts hacking on one of the most important parts of the KDE software compilation.
On monday we had the pleasure of a public event with four highly interesting talks given by the Plasmas in our allhands area in Maxtorhof. Will Stephenson was sheding some light on the old days where SuSE already was hosting a sprint for KDE. I guess in that days we still called it “developer meeting”, but it was basically the same concept. It happened in an office building called Schanz which was still SuSEs but not in use these days. Will had some cool photos of well known KDE developers, partly with more hair and less bally than nowadays, hacking on KDE3. I think the meeting was in 2003, so it is great to see how many people are still around in the community.For me that was the first KDE meeting I participated, working on my scan application called Kooka. Fun.
After that Aaron Seigo was talking about Plasma as a cross device and cross form factor concept, Marco Martin was presenting very interesting stuff about KDEs Netbook shell and finally Sebastian Kügler was introducing Silk, the project to free the web from the browser. It was a very inspiring evening which closed with good discussion over some drinks. I like to thank the KDE guys for giving the presentations and our guests for showing up.
The rest of the week was full of concentrated work for the Plasmas, watch out on planetkde for various posts.
From the openSUSE perspective it was a pleasure to host the meeting, it was very nice to meet you all again. Thank you all for being our guests. It was fun and as a result we really want to continue the idea.
openSUSE is upstreams friend and we are convinced that personal meetings are the most effective way to make progress. So if your community is watching out for a place to meet, innovate and hack, let us know, I am sure we can arrange something.
One of the most important objectives for Kraft is to create business documents of perfect quality. The docs are an important face to the customer and represent the business, so best is just good enough. The old times where invoices got printed on a 24 needle printer in ascii mode should finally be gone
Documents should represent the ‘coorperate identity’, which in small size firms probably comes down to printed stationary with a company logo and some other information on it. Kraft has to print nicely on it. For that it is important that the layout can be configured at all and without compiling Kraft if the customer address should be printed fife millimeters higher for example.
Currently Kraft uses a document template written in RML for the layout. RML is a XML format which can be converted to PDF utilizing a python based command line tool which is called by Kraft. RML is a open source toolkit, quite powerful and mature. However, it does not solve all problems with flexible document creation and sometimes comes a bit unhandy. As a result our eyes are always open for alternatives.
Here are some requirements a template system must provide:
- There is a document template in the file system. It can be changed by the user without recompiling Kraft. Kraft picks it up, fills the document values in and processes it to PDF. Other output formats are optional.
- Layout: Areas where parts of the document are printed can be freely specified, ie. where the address, the date etc. is printed.
- Graphical elements like lines, fixed text, boxes, colors and images can be placed everywhere.
- The system knows at least different layouts for the first page, middle pages and the last page.
- All pages have page header and footer.
- Loops: Since an invoice for example has an unknown amount of items the system must be able to handle that, including clever space management with pagebreaks. Nested loops are possible.
- Maintain areas which must not be split, i.e. an invoice item should be printed completely on one page and not be split by a pagebreak.
- Text faces, paragraph alignment, width, spacing and these kind of things must be configurable in the template.
- Some variables are available such as a page counter.
- Really great would be if the system provides carryover of calculations, like on the top and bottom of each page the so far accumulated sum is printed.
Which free layouting and PDF generating system is able to provide that, preferably Qt/KDE based? Kugar was striving to solve it but when I tested it it did not work out.
Another idea is to use the ability of KWord to work with templates. If Kraft could read KWord templates, fill them and automatically generate a KWord doc from it, that would be a great solution, because in addition to automatic PDF generation documents could easily be exported as KWord docs and changed manually if needed. A great ‘template editor’ also would be available. This would in the direction of office suit integration that commercial Kraft competitors nowadays have.
I am not sure how far we are away from that. Something to investigate.