Skip to main content

the avatar of Vincent Untz

And here comes a gnome-panel fork...

Last week-end, just before leaving for some travel, I became aware that gnome-panel was being forked into consort-panel (btw, I commented on that post, but I guess it was a bit too late since it's stuck in the moderation queue).

Now, let me start by stating clearly that I have nothing against forks: people are free to go this way, and that's cool with me. However, I quickly got confused for three reasons: I thought it was clear that volunteers are welcome to maintain gnome-panel, I thought I had explained to Ikey in June 2012 why some changes would be blocked from entering fallback mode but could hopefully happen in a not-too-distant future, and I'm getting explicitly blamed here and there for putting roadblocks.

I usually don't mind being blamed, but I prefer when it's for good reasons ;-) Of course, as a maintainer, I reject patches. There are usually good reasons, including the fact that there's a design philosophy that a module like gnome-panel had to follow since it was fully part of GNOME. Rejecting patches is part of the maintainer job. It doesn't mean that contributions are not welcome, but I guess it can be perceived as such... Another task of a maintainer is to enable people to keep the code alive, and in the case of gnome-panel, it was clear to me that having the fallback mode as part of GNOME 3 was a blocker to do so. It took more time than I would have liked, but this is something that got fixed when the fallback mode got dropped of GNOME 3.

With this in mind, and to clarify why I got confused by the fork announcement, here's a quick timeline of events in 2012, related to the fate of gnome-panel, covering what I was aware of until the blog post from a few days ago:

  • June 24th & 25th: I get a mail from Ikey about some patches he wrote to revert changes that were done in gnome-panel 3.x. I answer that this can't get in at the moment, due to the fact that the fallback mode is an official part of GNOME 3 and has to work the GNOME 3 way. I also mention that this direction of gnome-panel could change if the fallback mode is dropped from GNOME (and that I would step down as maintainer if gnome-panel becomes actively developed again). As far as I know, this mail discussion (six mails) is the only time I've interacted with Ikey until I commented on his blog post a few days ago (no other mail, nothing in bugzilla; there might have been some irc chat, but I don't keep irc logs).
  • June 25th: I start a thread on desktop-devel-list to see if we still need to keep the fallback mode as part of GNOME 3.6, and I invite Ikey to participate in the thread (in the private mail discussion mentioned above). A decision is taken, and it's to keep the fallback mode for now.
  • end of August: I start the DropOrFixFallbackMode feature page for GNOME 3.8, because I feel the fallback mode in GNOME is not getting enough love. This feature page explicitly mentions that some people would like to improve components of the fallback mode to work differently, and that dropping the fallback mode would enable these people to step up and push for what they'd like to do.
  • December 5th: I send a mail to a small group of people who I know might be interested in keeping some fallback components maintained, to help them start on their work. Clearly, I failed to include Ikey in the discussion, but only because I had forgotten about our discussion from June.

The ironic point here, at least to me, is that it's Ikey's mail that triggered my push for the fallback mode to be dropped from official GNOME so people could work on gnome-panel with more freedom. Which is what seems to be wanted.

Anyway, let me take this as an opportunity to remind everyone that people are welcome to become maintainers of gnome-panel. It'd be preferable to maintain it in the GNOME infrastructure, but I guess even just forking it with full history on gitorious/github would work. No need to rename, no need to follow the GNOME 3 design, etc. If full forking+renaming is preferred for some reason, in the end, that's fine; I'd be curious to know what good reason exists, though.

And as usual, you're welcome to blame me for X, Y or Z :-)

the avatar of Han Wen Kam

My openSUSE 12 Journal - 9: Upgrading to Stable Kernel 3.7.4

I took every step and every precaution, with fear and trembling, but I finally took the plunge to upgraded my default kernel (3.4.11) in openSUSE 12.2 to the latest stable kernel (3.7.4).

You know what?  This is the best thing I could have ever done for my laptop!!!

Special Thanks to Mike Veltman, appreciate your guidance and encouragement.

What made me do it?
I have been using openSUSE 12.2 for over 3+ weeks and have noticed some performance issues from a desktop productivity perspective.  This was confirmed when speaking with Mike and also confirmed by a comment from Jack Bauer on my previous blog entry.

Scenario:  Try copying a large amount of files (total file size of say over 1Gb) from your hard disk to an external USB drive.  During the file transfer (doesn't matter if you initiate the transfer via commandline or GUI), the rest of the desktop (except the mouse pointer) is practically dead and unresponsive.  At best, a simple task of opening a new tab on Firefox to surf will take over 10 seconds.  If you want to open LibreOffice to read a doc/spreadsheet, you can forget-about-it.

This was initially tolerated because I would schedule large file backups in the evening after work.  However, it is starting to get to me because I don't recall earlier openSUSE 11.3, 11.4 and 12.1 ever giving me such issues.  The final straw came this week and its my Windows VM... it was running well but I have to put PGP whole disk encryption on the VM.  As expected the Windows VM slowed down but I also noticed its slowing my host as well.

How I did it?

Read more »
the avatar of Andres Silva
a silhouette of a person's head and shoulders, used as a default avatar

Run over by a truck.

As promised I got back in to writing, and pumped out a few articles. You might have noticed a lull in my posting recently. Well, I got hit by a truck. Seriously, not joking. On the 13th I was visiting with friends and went to go get something from the nearby grocery. I crossed one half of the street, then waited on the median to see how the traffic was so I could cross the rest of the way. As typical I step out a bit to make sure drivers can see me, and the two approaching cars slow down. I proceed to cross, and suddenly notice the SUV hasn't stopped and it was too close and too fast to react. After tumbling through the air for some while I landed on my back, in the middle of the street. Assessing the damage I realize that I wasn't too badly hurt... except for the bones protruding from my right leg.

I spent a little over a week in the hospital. They implanted metal rods into the fibula and tibia as opposed to casting it. I prefer the rods since I think that'll make things more usable quicker. So now I have to be pushed around in a wheelchair, or hobble about with a walker. The latter I can't do very much of at this point. I imagine I'll be more mobile in about a week.

I've had some articles brewing. Among them you can anticipate the following:

How to make Gnome 3 act more like Gnome 2 simply using extensions.
Crossover for Linux vs. WINE, is it worth it?
Fluendo DVD player review.
Fluendo Codec Pack review.
Steam on Linux beta review.
the avatar of Klaas Freitag

ownCloud Sync Client 1.2.0 final

1.2.0_final Yesterday, ownCloud Client 1.2.0 was released. You can get it from here. We worked on this since end of november last year, you might have seen my other blogs about the beta versions we had for this release.

What is interesting about the release from a more technical point of view? Here are a couple of examples.

One of the things which often was complained about was the performance of the client. Performance is a very broad term, so we have to examine the details: Many people felt like its a performance problem that former clients polled the local file system for changes on the MacOSX and Windows platform. That was recommended from other projects which have experience with going through large file collections. QFileSystemWatcher seemed not to be designed for this usecase.

Polling was ok for desktop computers with up-to-date hardware, but on devices running from batteries this was a energy drain. Good that we could fix that with 1.2.0 using native implementation of change detectors on Windows and MacOSX. They detect changes within a file system tree. If a change is detected, a sync run is started. But note, this is only for local file systems. Detection of changes on the server is a different story which has to be told as well.

Another performance problem was within the file upload which is done by a HTTP PUT request. Month ago (pretty after my start at ownCloud) I implemented it using a tmp file in between. That means, the source file was copied to a tmp file, and from that it was processed to the request body. Improvement was needed and we changed the code to directly read from the file descriptor of the opened source file.

Another thing that was improved with 1.2.0 is the error reporting to the user. Former versions of the client sometimes provided error messages which were not really accurately describing the problem. The reason for that was that csync uses errnos (yes, the ones from errno.h) to name errors as csync maps everything to a POSIX file interface. That surely works as long as you’re on a kind of file system. But it’s hard to map HTTP communication problems onto that. So we decided to add our own “custom” errnos and enhance the whole idea to use these to describe problems. That works more accurate now.

The next things on the list are for example a more convenient setup dialog for the client. Also we will get away from the kind of hard coded target file name on the cloud. A better network recognition will also be next as well as better handling of big files. And more…

Thanks a lot to all who helped to get 1.2.0 finished! It is big fun to work in such a great community :-)

a silhouette of a person's head and shoulders, used as a default avatar

LibreGraphicsMeeting 2013 coming soon

Once a year all or most of the applications around graphics from the free software world come together and work on new ideas and features for there software. The event where they come together is called LibreGraphicsMeeting. Oyranos participated always the last years in that meeting and got a lot of feedback and ideas from it. This year the LibreGraphicsMeeting will take place in Madrid/Spain and there is still time to submit interesting presentations around free software and graphics. As always the LibreGraphicsMeeting tries to collect some money for travel costs of the participating developers.

But there is more, last year we tried to get Gustav Gonzalez to the LGM and it didnt happen. This year Sirko started an campaign very early, as Gustav needs an visa for Spain he has to show flight tickets and accomodation for get it until 15th of February. Now we have nearly the sum for the flights, we looked for flights and we only need arround 200$ for them and another 150$ for accomodation. In case you dont know who Gustav Gonzalez is….

He is the main developer of Tupi, an cool QT 2D animation tool. Which makes it very easy to draw animations. Tupi is an fork of KToon where nobody works on anymore :( But what he has achieved since he forked it, is amazing. Meeting other developer from graphic applications would surly good for him and bring him new ideas for Tupi. SO it would be definitly a benefit to send him to LGM.

a silhouette of a person's head and shoulders, used as a default avatar

C++ bindings for monotouch using SWIG

cold cold light
(c) S. Delcroix 2013
I love bindings. I've always loved them. Back in the days, I was binding gtk+ and other gobject libs to C# for fun and f-spot usage. Then I bound some obj-C libs to monotouch for a client and some for pleasure.

But last week I faced something new. I wanted to bind (for monotouch) a C++ iPhone lib for which I only received the binaries and the headers files. The component was too large to even think about doing a manual C glue code. I googled about the possible solutions and the only valuable advice was to use SWIG, without any rationale or tutorial. This is then probably a first. An explanation on why SWIG can help you for this, the problem I ran into and the solutions I found.



Mono.Cxxi is sexy, but not all-purpose

I'm not the kind of guy who blindly follows recommendations, so my first try was to use anything but SWIG. I opted for Mono.Cxxi and created a full binding in a few hours. It was really easy after I figured out the gcc-xml installation steps and caveats with clang. But when I first tried to use inside my monotouch project, it was to no avail. A quick reality-check confirmed my fears:


That being said, Mono.Cxxi is great stuff, check it out. But don't count on it for static AOT.

Go SWIG

Miguel was, once again right. SWIG was the only sensible option. I've used SWIG in the 90's for python (iirc), and it looks like the website hasn't left this era. But that's for the surface only. The tool is quite capable, is well suited for .NET and you can customise it to your liking. There's even a tutorial so I won't cover the basics. 
pro-tip: on Mac, install swig with homebrew

 1. Get the DllImports right

The first thing to get right, is the DllImportAttribute for P/Invoke. It has to be like this
[DllImport ("__Internal")]
public static extern void hello ();
You can instruct swig to do that by passing the -dllimport option
swig -c++ -csharp -dllimport __Internal

2.  Generate an obj-c++ wrapper

Swig generates glue code for you in a .cxx file. It turns out that, by simply renaming it to .mm, you get a perfectly valid Obj-C++ file. Create a new (Foo_wrapper) library project with Xcode, link both that .mm file and the includes of the original library, and you'll easily get an iPhone-suited wrapper.

3. Getting rid of the AssemblyLoadExceptions

As is, the generated code compiles with smcs but crashes with an AssemblyLoadException as soon as you try to run it on the device or the simulator. That's because some SWIG generated helpers use reverse callbacks and those callbacks are usually JIT'ed by mono, which is not possible with static AOT. The solution for this is then to tag the (autogenerated) SetPending*Exception() and CreateString() with [MonoPInvokeCallback]. I do that by patching the file after the SWIG step.

4. Putting all the pieces together

So here's a (simplified) Makefile that you can use to turn your SWIG foo.i interface file to a Foo.dll assembly wrapping and embedding your original libFoo.a and the generated libFoo_wrapper.dll

5. One last thing, set IsCxx = true

Don't forget to get your AssemblyInfo.cs right, i.e. setting IsCxx to true in your LinkWithAttribute.


Wrapping up

At this point, you should be all set and you should be able to use your native c++ library directly from within monotouch. Now you have to use your brain, mess with your foo.i file and .NET-ify a bit your API.

Would you have any issue with this, or any other binding or mobile development related stuff, contact me, I'm available for contracting.


a silhouette of a person's head and shoulders, used as a default avatar

KDE Platform, Workspaces, Applications 4.10 RC3: openSUSE packages available

Following up on the announcement from KDE, the openSUSE KDE team is happy to announce the availability of 4.10 RC3 packages.  Remember that they are packages meant for testing and reporting bugs, so that the next release will be as polished as possible.

You will find the packages in the KDE:Distro:Factory repository. An updated live media based on the upcoming openSUSE 12.3 ([see previous post]({{ site.url }}/2013/01/test-the-upcoming-opensuse-12-3-and-kde-workspace-applications-and-platform-4-10-rc2)) is also available (files named KDE4-4.10.RC3) .  The openSUSE 12.2 based version is also available (files named KDE Reloaded) at the same address.

Enjoy!

the avatar of KDE at openSUSE

Replacing kio_sysinfo with kinfocenter

From openSUSE 12.3 on and currently already for the RC packages of KDE SC 4.10, kio_sysinfo will be replaced by kinfocenter. The icon for kinfocenter is still missing in the Kickoff > Computer tab but will be added soon. Until then you can start kinfocenter from the normal Kickoff menu.

The main reason for the replacement is that kio_sysinfo is basically unmaintained and hence bugs do not get fixed.

If you were using kio_sysinfo, please check whether kinfocenter provides all the info and functionality you used with kio_sysinfo. If not, post your suggestions here or to the opensuse-kde mailinglist.

Missing information from kinfocenter’s  summary I noticed so far:

  • temperatures
  • free hard disk space for each partition
  • current CPU frequency

Most info is available, even in more detail than kio_sysinfo did show it, yet not as part of the summary. E.g. graphics info, memory stats etc.

the avatar of Klaas Freitag

ownCloud Client 1.2.0 beta2

Yesterday the ownCloud Client team released the ownCloud Client 1.2.0 beta 2. It includes a couple of improvements compared to beta 1 which was released before Christmas.

The release of version 1.2.0 is planned for the next week if things go smooth.

[caption id=“attachment_219” align=“alignright” width=“595”]New Sync Protocol Dialog New Sync Protocol Dialog[/caption]

In particular, the the following improvements were added:

  • Proxy authentication fixed (Basic auth, NTLM will not yet work)
  • The status dialog now provides statistics on the last sync run (via the info button). It will tell in detail which files have been synced, added or deleted.
  • Client will go offline while the server in in maintenance mode (feature available with ownCoud master only)
  • Improved SSL Certificate acceptance
  • All sizes of the new icons are available.
  • Support files > 2 GB on all platforms for uploading.
  • Fixed some minor memory leaks and again saved some server requests through optimizations.
  • Improved error reporting to the user.
  • Remove legacy theming support.

We would appreciate if you give this release a test ride. Note that because it is beta you should make extra sure to have have backups of your data.

If you want to give feedback, please use our mailing list for general discussion and the issue tracker for bug reports. Please read our new guidelines on bug reporting before!

Download Links:

Sources:

Have fun!