Planet Ubuntu
Subscribe to Planet Ubuntu feed
Planet Ubuntu - http://planet.ubuntu.com/
Updated: 3 hours 29 min ago

Sam Hewitt: Display Servers or: How I Learned to Stop Caring and Love the Experience

Tue, 2014-03-25 10:00
i.e. The Display Server Doesn't Really Matter

I'll keep it brief while I throw my hat into this over-hatted ring while it's still in the the limelight –I prefer lemon light myself.

Since the display server makes no obvious impact to a user's experience therefore they're oblivious to itl I only learnt what Surfaceflinger was when the whole display server thing started.

It's only nerds like us that even know about it or care about how it works (I'll exclude myself from the latter condition) since we follow or are involved in the goings-on of open source.

So, can we take the display server down off it's pedestal, move on and continue to make awesome things? Pretty please? You can have some chocolate cake. :)

Also, points if you get my title reference.

The Fridge: Ubuntu Weekly Newsletter Issue 360

Mon, 2014-03-24 23:43

Welcome to the Ubuntu Weekly Newsletter. This is issue #360 for the week March 17 – 23, 2014, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

  • Elizabeth Krumbach Joseph
  • Paul White
  • Jim Connett
  • And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

Lubuntu Blog: PCManFM actions

Mon, 2014-03-24 19:21
PCManFM is the default file & desktop manager for Lubuntu. It's a simple and fast file manager, but its simplicity is now enhanced by providing us the unlimited power of customized actions, like other file managers (Nautilus, Thunar, etc). For that purpose I made another Trips and Tricks section, called Actions. This feature (available on recent versions of PCManFM and Lubuntu 14.04) will

Luis de Bethencourt: Resilience

Mon, 2014-03-24 19:03
"It always seems impossible until its done."
Nelson Mandela



My first Soyuz simulator! Summer 1964, nearly 5 years old."
Chris Hadfield

Daniel Holbach: Teaching Ubuntu App Development

Mon, 2014-03-24 17:34

At the vUDS in November we talked about having events where local communities could learn more about app development for Ubuntu for the first time. Since then we have come a long way:

  • We have some really nice materials set up.
  • The first events were held in a number of places around the world.
  • We got feedback and improved our docs.
  • Before the Ubuntu Global Jam and the release parties for 14.04 LTS we will have two Q&A sessions where you can ask all organisational and technical questions you might have.

You don’t have to do everything yourself!

When we started the initiative, we first talked to members of the Ubuntu community who knew a bit of app development already. Many of them liked the idea, but didn’t quite know how to set up an event or how to organise everything. We tried to address this by bringing them in touch with some of the LoCo teams which helped in a bunch of cases where events have already happened or are going to happen quite soon. We want more of this to happen.

It’s only understandable that you can’t do everything yourself, or that one person’s skills lie in a more organisational field and somebody else has some more experience with app development. Bringing the two together, we are going to have more interesting events, more people introduced to writing apps for Ubuntu, which will be great for everyone involved.

Getting started

Sounds good so far? Here’s what you can do to get more folks exposed to how sweet and easy it is to write apps for Ubuntu.

As somebody who can organise events, but might need to find a speaker: Ask in #ubuntu-app-devel on Freenode or on the ubuntu-app-devel@ mailing list, to see if anyone is in your area to give a talk. Ask on your LoCo’s or LUG’s mailing list as well. Even if somebody who’s into programming hasn’t developed using Ubuntu’s SDK yet, they should be able to familiarise themselves with the technologies quite easily.

As somebody who has written code before and didn’t find the Ubuntu app development materials too challenging, but might need to find some help with organising the event: Ask on the loco-contacts@ mailing list. There are LoCos all around the world and most of them will be happy to see somebody give a talk at an event.

Whichever camp you’re in:

Let’s make this happen together. Writing apps for Ubuntu and publishing them has never been easier, and they’ll make Ubuntu on phones/tablets much more interesting, and will run on the desktop as well.

Michael Hall: My phone is lonely, let’s fix that

Mon, 2014-03-24 08:00

I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.

That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.

But the community wasn’t on my phone. Their work was, but not the people.  I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.

Community Cast

Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all.  It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet).  That’s it, that’s all.

As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.

Server

The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use.  I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that.  I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised.  Like I said, it’s not production ready.  But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.

Client

The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance.  If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.

Screenshots

There isn’t much to show, but here’s what it looks like right now.  I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.

Not bad for a few hours of work.  I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.

 

Nizar Kerkeni: Computers in the post-Snowden era: choose before paying!

Mon, 2014-03-24 07:42

The revelations from Edward Snowden concerning massive surveillance of communications demonstrates the need for each person to be able to control their computers and phones.

Yet computer and telephone manufacturers and retailers typically impose on users programs that jeopardise their privacy.

Each person should therefore have the opportunity to refuse to pay for non-Free software, and be allowed to choose the programs that run on their telephone and computer.

Today, Association for the free digital culture – CLibre joins other organisations throughout the world in requesting an unfettered choice of the operating system on telephones, laptops and other computing devices.

Sign the international petition! http://no.more.racketware.info/petition/click/en

Further information. http://no.more.racketware.info/en/index

Do you want help in promoting this petition? Visit http://no.more.racketware.info/petition/index

Seif Lotfy: Marconi love :)

Mon, 2014-03-24 02:23

I have lots of positive things to say about the OpenStack community. They managed to create a great mixture of professional yet agile and FLOSSy. Amazing CI/CD and devstack is just an awesome way to kickstart development on OpenStack.

Last month I discovered Marconi (https://wiki.openstack.org/wiki/Marconi)...

Basically its a new MQ written in pure Python and allos different backends. The awesome thing is you can run it without having to run the whole openstack stuff and it works... It is still a young project but the community around it its awesome ans their IRC #openstack-marconi is very responsive. These guys could use a hand so if you are a Python enthusiast or want to hack on something OpenStack related without needing to have the whole stack running, please show some support and try to help out. There is a lot of low hanging fruit (https://bugs.launchpad.net/openstack/marconi) :)

Chris Coulson: Customizing the user agent string in Oxide

Sun, 2014-03-23 20:59

The Ubuntu webbrowser sets its own default user agent string, and also provides a list of overrides which define different user agent strings for specific sites that do broken UA sniffing. This is a concept that we’ve borrowed from Firefox OS.

With QtWebkit, the overriding is performed via the same mechanism that is used for setting the default user agent string – by setting the WebViewExperimental.userAgent property. However, this has a major shortcoming – it provides no means to override the user agent string for specific frames. Say, for example, that you need to provide an override for www.twitter.com, but not for www.example.org. If a page from www.example.org embeds www.twitter.com in an iframe, there isn’t a mechanism to change the user agent string for the child frame.

When overriding the user agent string for a frame, there are 2 places that this needs to happen:

  • navigator.userAgent
  • The User-Agent header in outgoing HTTP requests.

Fortunately, Chromium provides a mechanism by which we can implement the second one – net::NetworkDelegate::OnBeforeSendHeaders(). Unfortunately, this is called on Chromium’s IO thread which makes it difficult to expose as a signal in QML (a QML engine can only execute code on a single thread). The notification is asynchronous, which means we could dispatch an event to the UI thread, emit a signal in QML and then dispatch an event back to Chromium’s IO thread. However, this has shortcomings of its own:

  • A typical page load can generate more than 100 network requests. For example, loading BBC News generated 165 requests when I tested it here. Assuming we have multiple notifications per request, processing all of these on the UI thread in QML could have a noticeable performance impact.
  • Not all notifications we get from net::NetworkDelegate are asynchronous. For example, cookie access permission requests aren’t.
Enter WebContextDelegateWorker

For handling events that happen on Chromium’s IO thread, we have a new class – WebContextDelegateWorker. This is very similar to QML’s WorkerScript – it runs script on a worker thread and provides sendMessage/onMessage API’s for exchanging data with QML on the UI thread. However, it provides a mechanism for scripts to expose entry points that can be called from Chromium’s IO thread (actually, they’re not called from Chromium’s IO thread – they’re called on the worker thread by blocking the IO thread. But, you don’t need to care about that).

To overridethe User-Agent header for specific requests in Oxide, you can do something like the following:

In QML:

WebView { ... context: WebContext { ... networkRequestDelegate: WebContextDelegateWorker { source: Qt.resolvedUrl("worker.js") onMessage: { console.log("We set User-Agent on " + message.url); } } } }

In worker.js:

// Unfortunately the properties of QUrl don't appear to be available in QML, // so provide a simple regex to extract the host var re=/^[^:]+:\/\/([^\/]*)\/.*/; exports.onBeforeSendHeaders = function(event) { if (re.exec(event.url)[1] == "www.twitter.com") { event.setHeader("User-Agent", "Foo"); oxide.sendMessage({url: event.url}); } }

This doesn’t affect navigator.userAgent though. In order to provide an override mechanism for this, we had to apply a small patch to Chromium to give embedders the opportunity to provide an override value when accessed. We did consider exposing a signal in QML for overriding this, based on the assumption that this would run much less frequently than network notifications. However, in the end we decided to reuse WebContextDelegateWorker, based on the assumption that developers who want to override navigator.userAgent will probably also want to use the same overrides for the User-Agent header. Doing this means that you only need the override list in one script context.

To override navigator.userAgent, the above code becomes:

In QML:

WebView { ... context: WebContext { ... networkRequestDelegate: WebContextDelegateWorker { source: Qt.resolvedUrl("worker.js") onMessage: { console.log("We set User-Agent on " + message.url); } } userAgentOverrideDelegate: networkRequestDelegate } }

In worker.js:

// Unfortunately the properties of QUrl don't appear to be available in QML, // so provide a simple regex to extract the host var re=/^[^:]+:\/\/([^\/]*)\/.*/; exports.onBeforeSendHeaders = function(event) { if (re.exec(event.url)[1] == "www.twitter.com") { event.setHeader("User-Agent", "Foo"); oxide.sendMessage({url: event.url}); } } exports.onGetUserAgentOverride = function(data) { if (re.exec(data.url)[1] == "www.twitter.com") { data.userAgentOverride = "Foo"; } }

Setting a default string

Oxide doesn’t have a per-WebView property that’s equivalent to WebViewExperimental.userAgent in QtWebkit, as we decided that this would be redundant with the above override mechanism. Instead, the default user agent string is configured by setting the WebContext.userAgent property.

Other uses for WebContextDelegateWorker

WebContextDelegateWorker is also used for overriding the default storage access policy via WebContext.storageAccessPermissionDelegate (in QML) and exports.onStoragePermissionRequest (in the worker). This is currently only used for cookies, but is due to be expanded to local storage, app cache, indexedDB and WebDB. The default storage access policy is controlled by WebContext.cookiePolicy

Leo Iannacone: Python3 – has_key() regex replace

Sun, 2014-03-23 16:39

dict.has_key() was removed in Python 3.x.

This sed regex could fix them all:

sed -r "s/([a-z,A-Z,0-9,.,_]*)\.has_key\('([^']*)'\)/'\2' in \1/g" \ -i `find -name "*.py"`

Enjoy.

Ubuntu GNOME: Call for Testing Trusty Tahr Final Beta Candidate

Sun, 2014-03-23 15:42

Hi,

Can you believe it? few more days, and Ubuntu GNOME Trusty Tahr Final Beta/Beta 2 will be released.

As always, it is time for some heavy testing and help Ubuntu GNOME Team to decide which image (daily build) could be the final beta (beta 2) for Trusty Tahr.

With the very latest great news – Ubuntu GNOME 14.04 will be an LTS release supported for 3 years – and with the great commitment of Ubuntu GNOME Team and the high quality that everyone showed for the last 5 months, we do need to carry on and keep up the great work. We have achieved a lot and less than a month to go to the final release and the very first LTS version of Ubuntu GNOME. The hard work has just started. Beta 2 or the final beta means this is what Ubuntu GNOME 14.04 LTS final release will look like, at least 90% or even more.

If you take a look at the Release Schedule Wiki Page, you will notice that there will be no more new features or any kind of changes to be done. At this stage/phase, it is mainly heavy testing and bugs fixing.

From today until 17th of April, 2014 (the date of the final release), we do need to make sure that Ubuntu GNOME 14.04 LTS will be solid and stable as a rock. Thus, we do need your help and support.

Final Beta or Beta 2 is not yet released. It will be released in 27th of March, 2014 but we must start testing from now and be ready.

What exactly do I need to test?
Ubuntu GNOME Trusty Tahr Daily Build

Okay, I’m new to this so how can I get started?
HOWTO Test Ubuntu GNOME

How can I get in touch with the Testing Team?
HOWTO Contact Ubuntu GNOME QA/Testing Team

Where else I could ask for some help?
Beside the mailing list of Ubuntu GNOME QA Team and Ubuntu GNOME IRC Channel, you can always post on Ubuntu Forums. There is a dedicated section for testing. However, please pay attention to:

This forum is for the discussion of the development of the next version of Ubuntu. Please Note: Ubuntu Developers do not usually read the forums, If you run into what you think is a bug, please use Launchpad to report it.

For anything else, please feel free to contact us.

Thank you for testing Ubuntu GNOME and helping us. We highly appreciate and respect that.

Ali/amjjawad
Ubuntu GNOME QA Lead

Sergio Meneses: Ubucon LatinAmerica is coming!

Sun, 2014-03-23 02:30

UbuConLA is an international event which happens every year and it is held in different parts of Latin America. This year UbuconLA will be in the beautiful city of  Cartagena / Colombia. With the following objectives:

  • Sharing the experiences and skills acquired in corporate environments by specialists from Latin America in several projects and contexts.
  • Showing the level reached by Ubuntu GNU / Linux and professionals working in business environments, as well as consultants, users or systems managers.
  • Technically and socially integrate users and specialists from Latin America, both for acquisition of new knowledge and skills and taking advantage of the creation business opportunities in the region.
  • Spreading the Ubuntu spirit throughout Latin America.
  • Institutionalizing UbuConLA as “The Annual Ubuntu Event “for Latin America.

The 2014 edition will be held in Cartagena, Colombia, at the Universidad Tecnologica de Bolivar on the 14 and 16 of August 2014.

This edition of the UbuConLA will be having people from, Argentina, Uruguay, Peru, Mexico, Venezuela, Colombia and Spain.

Besides if you want to be an speaker, visit http://ubuconla.org/callforpapers.php

And always is good to see Jono’s messages :D (this for ubuconla2013)

More news and updates on our social networks:

https://twitter.com/ubuconla

https://www.facebook.com/UbuConla

https://plus.google.com/u/0/+UbuconlaOrg/posts

You can get more information on our website http://ubuconla.org/ or contact email the organizers at: ubuconla2013 [AT] ubuconla [DOT] org


Robert Ancell: Why the display server doesn't matter

Sun, 2014-03-23 00:48
Display servers are the component in the display stack that seems to hog a lot of the limelight. I think this is a bit of a mistake, as it's actually probably the least important component, at least to a user.

In the modern display stack there are five main components:
  • Hardware
  • Driver
  • Display Server / Shell
  • Toolkit / Platform API
  • Applications
The hardware we have no control over. We just get to pick which hardware to buy. The driver we have more control over - drivers range from completely closed source to fully open source. There's a tug of war between the hardware manufacturers who are used to being closed (like their hardware) and the open source community which wants to be able to modify / fix the drivers.

For (too) many years we've lived with the X display server in the open source world. But now we are moving into next generation display servers (as Apple and Microsoft did many years ago). At the moment there are two new classes of contender for X replacement, Mir and a set of Wayland based compositors (e.g. weston, mutter-wayland etc).

Applications use toolkits and platform APIs to access graphical functionality. There are plenty of toolkits out there (e.g. GTK+, Qt) and existing libraries are growing more broad, consistent and stable to be considered as a complete platform API (which is great for developers).

If you read the Internet you would think the most important part in this new world is the display server. But actually it's just a detail that doesn't matter that much.
  • Applications access the display server via a toolkit. All the successful toolkits support multiple backends because there's more than one OS out there today. In general you can take a GTK+ application and run it in Windows and everything just works.
  • The hardware and drivers are becoming more and more generic. Video cards used to have very specialised functionality and OpenGL used to provide only a fixed function function. Now video cards are basically massively parallel processors (see OpenCL) and OpenGL is a means of passing shaders and buffer contents.
The result of this is the display server doesn't matter much to applications because we have pretty good toolkits that already hide all this information from us. And it doesn't matter much to drivers as they're providing much the same operations to anything that uses them (i.e. buffer management and passing shaders around).
So what does matter now?
  • It does matter that we have open drivers. Because there will be different things exercising them we need to be able to fix drivers when display server B hits a bug but A doesn't. We saw this working with Mir on Android drivers. Since these drivers are only normally used by SurfaceFlinger there are odd bugs if you do things differently. Filing a bug report is no substitute to being able to read and fix the driver yourself.
  • The shell matters a lot more. We're moving on from the WIMP paradigm. We have multiple form factors now. The shell expresses what an application can do and different shells are likely to vary in what they allow.
I hope I've given some insight into the complex world of display stacks and shown we have plenty of room for innovation in the middle without causing major problems to the bits that matter to users. 

Seif Lotfy: Sc(r)um

Sat, 2014-03-22 20:01

I am entitled to my opinion and in my honest opinion: scrum sucks big time

Here is why (again my opinion).

  • Does not empower developers to become creative. Good way to sell that the developers are doing something (so that failure is not their fault) even if running around in circles ==> plausible deniability

  • Highly motivated developers are limited from jumping out of the “plan” to hack on other project related stuff (even doing so in free time is regarded wrong since you are not sticking to a plan). Thus limiting the personal success story and relying on motivation to come from team achievements. So being a weak link in a team just makes matters worse.

  • The “Daily Stand-up" routine is not productive in its defined structure of:

    • What did I accomplish yesterday? Tried to finish a story. Ran out of time.
    • What will I do today? Will try to finish this story.
    • What obstacles are impeding my progress? This meeting, the circle jerk around legacy code and the dude demanding me to discuss every merge request before submitting it. (Just accept/deny with a comment - thank you ;) )
  • Stories over quality: Developers are keen to finish as much stories as possible which could to take a toll on the quality.

  • Not applicable on a distributed community of volunteers, or when dependency on open source community exist.

  • Time-boxed problem solving does not guarantee best possible outcome.

  • The commitment: One of the reason Scrum fails is its approach on commitment. "Deliver the maximum value of stories in a specific time frame”. As soon as the team can not agree on committing to a story all other stories with lower priority are ignored. And once done with those stories you pick the one out of the backlog that you couldn’t agree on (Since it has the highest priority) and waste time on it. You can’t skip this story since it has the highest priority. To me this is like sitting in an exam and being stuck on a problem. Instead of moving to the next problem with the hope of gathering as much points as possible, one decided to be stubborn and try fucking with that problem. That is just stupid. Now assume I solved the problem. Scrum now forces me to pick something from the backlog. And not anything. But the one with the highest priority and again waste time being stuck on that until the time ends. If would have adapted this style of tackling problems during school I would have never passed.

Don't get me wrong Scrum can work don't know how personally but I do believe it can work with the right team and people, however what are the chances of it succeeding if 2 or more of the following apply:

  • You don't have full control of the stack (dependency on third party)

  • Your developers are not all on the same level of expertise and knowledge.

  • Shoehorned into an ongoing running process and code base.

  • Stories of the team are not focused on a specific topic but on the general delivery of the whole project.

I look at GNOME, Mozilla and the Kernel. They don’t follow this methodology and stuff happens and gets delivered. So much big companies can learn from FLOSS.

Pablo Rubianes: LoCo Teams Update On Air!

Sat, 2014-03-22 17:45

As you read it. From now on, Philip BallewNathan HainesJosé Antonio Rey and I (Pablo Rubianes) will be hosting a monthly LoCo Teams Update session at Ubuntu on Air!.

For these to be a success, we need your help. The updates will have news from the LoCo Council, and will also highlight what LoCo Teams are doing around the world! That means, if your LoCo Team is having an event or wants to be mentioned on the show for something they are going to do or have already done, you need to tell us so we can feature it.

All LoCo Teams are welcome to send their news to us so they can be featured on the show. Just send an email to onair@ubuntu.com, and make sure to start the subject with [LoCo Update]. An example of a subject would be “[LoCo Update] Release party hosted!” (don’t forget to mention which LoCo Team this is coming from!)

You can send text so we can read, but you can also send us your pictures and photos of the event, so we can show them to the world on this show. These sessions are all about you and your LoCo Team, so we are totally welcome to suggestions about what can be done in the future to improve the show. We may even start having some guests from LoCo Teams! Also, we will be using the #ubuntu-on-air channel on irc.freenode.net (Click here to join from your browser) to host discussion about the session. Anyone is welcome to come!

Our first session is going to be on Saturday, March 22nd, at 19 UTC. From that point on, we will be having sessions on the fourth Saturday each month, at the same time. You will be able to see the sessions at the Ubuntu on Air! calendar.

We hope to see you there, and expect to receive many news to be featured on the show!


Tagged: LoCo Council

Jo Shields: Stephenson’s Rocket – the new name for Ye Olde SteamOSe

Fri, 2014-03-21 23:58

I’ve made a new release of my curiously popular SteamOS derivative, and given it a new name: Stephenson’s Rocket.

You can download the new release from here.

Release highlights:

  • Updated to alchemist_beta 93
  • Support for pre-HD5000 Radeon cards
  • Support for motherboard-based “FakeRAID”
  • Video tutorial series – about an hour of instructional material for all competency levels

Ubuntu Demon(Roald Hopman): You have just found my old blog :)

Fri, 2014-03-21 15:32

You have just found my old blog :)
My future blog : http://www.katanoon.com/blog
About me : http://www.roaldhopman.nl


Alan Pope: Running Core Apps on the Desktop

Fri, 2014-03-21 12:20

One of the (many) challenges with creating a new mobile platform is that of bootstrapping app developers. The Ubuntu SDK – based on well known tools like Qt & QtCreator and supporting HTML5, C++ & GL – we can run our applications both on mobile devices and standard Ubuntu desktops.

With our convergence plans being a core component of Ubuntu over the coming releases, we can take advantage of this when testing mobile apps.

Developers can create & users can test applications without having to commit funds to a dedicated Ubuntu mobile device. Of course in the future Ubuntu mobile devices will be ubiquitous but for now we can support those users, testers and developers right now to use Ubuntu mobile apps on the desktop.

So with the Core Apps Hack Days just around the corner, now is a great time to install the core apps on your desktop and help test them, file bugs and contribute patches!

For users of Ubuntu 13.10 and Trusty (14.04) we have a Core Apps Daily PPA which has builds of all the core apps. Installing them is a cinch on 13.10 and 14.04 via the PPA & touch-coreapps metapackage:-

sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily
sudo apt-get update
sudo apt-get install touch-coreapps

Note: This has been tested on 13.10 and 14.04 but not on previous releases.

If you later wish to remove them simply use sudo ppa-purge ppa:ubuntu-touch-coreapps-drivers/daily or just sudo apt-get autoremove touch-coreapps.

Once installed you should see icons for all the core apps in your dash

We welcome constructive feedback and bug reports about all aspects of the Core Apps. You can find us in #ubuntu-app-devel on freenode and details of where to file bugs can be found on the Core Apps wiki pages.

You can get started with developing apps on Ubuntu via the SDK, the documentation for which is at developer.ubuntu.com.

Chris Coulson: Oxide status

Fri, 2014-03-21 11:45

It’s been a while since I wrote my last blog post – Introducing Oxide. I’ve been quite busy since, so I thought that I should take this opportunity to provide a quick update on progress.

Our overall aim is to have the webapps container using Oxide in Ubuntu 14.04, and we’re also hoping to be able to transition the Ubuntu browser quite soon as well.

Summary of progress

A lot has changed since my last post:

It….

  • runs independently of X11
  • supports accelerated compositing on both Mir and X11
  • has been running on several devices with Ubuntu Touch – Nexus 4 (mako), Nexus 7 (grouper) and Galaxy Nexus (maguro)
  • has a navigation history API (WebView.navigationHistory)
  • has a WebPreferences API (WebView.preferences)
  • is DPI aware
  • has input method support, and the onscreen keyboard works on Ubuntu Touch
  • has support for touch events and gestures (pinch-to-zoom and fling works)
  • supports third-party cookie blocking
  • has a mechanism for intercepting and modifying outgoing HTTP requests, which can be used for redirecting URL’s or modifying headers (such as User-Agent)
  • has a mechanism for intercepting accesses to navigator.userAgent which allows applications to customize this on a per-frame and per-domain basis (more on this and the above point in another blog post)

In addition to this, I also have the following features in my review queue:

  • Support for JS dialogs (alert, confirm etc)
  • File picker support
  • Cursor change support
  • API for exposing favicons
  • API for delivering console messages to embedders

Oxide also runs WebGL and plays video quite well on both the desktop and the device.

 

Next steps

Here is a list of things we need to tackle quite urgently:

And then, there are some other major tasks which are still important but not complete blockers at the moment:

  • Geolocation support (requires permission request API and an API key for Google’s geolocation service. Eventually, this should use the Ubuntu location service)
  • Device access permission request API (for microphone and webcam)
  • Support window.open() and HTML anchor ‘target=”_blank”‘
  • Add a fullscreen API – the mobile version of Youtube requires this to play videos
  • We need to join Chromium’s release train with the creation of beta and release branches

I also need to clear my review queue

For a more complete list of remaining work, please see the list of open bugs.

Testing Oxide

Builds of Oxide are currently uploaded fairly regularly to the Phablet Team PPA. Feel free to download it, play around with the API and report bugs. Sorry, there’s no documentation yet, so you will need to look at the source code or ask me questions about how it works for now. It is quite easy to use though.

The PPA also contains a build of webbrowser-app that uses Oxide instead of QtWebkit. You can try this out, but if you do, you should be aware of the following caveats:

  • It does replace the current webbrowser-app, which uses QtWebkit
  • Whilst it’s ok for basic browsing, testing and bug reporting, there is still major functionality missing that means you probably don’t want to use it for day-to-day browsing just yet.
Getting involved

If you want to help make Oxide (and our web browser) awesome, please take a look at the list of currently open bugs. If you see anything that you’d like to work on, feel free to come and talk to me on IRC (I’m “chrisccoulson” on irc.freenode.net), and I’ll be glad to help out.

Thanks…

For all the hard work from everyone who has contributed or contributing to Oxide so far: Olivier Tilloy, Alexandre Abreu, Jamie Strandboge, Justin McPherson and Maxim Ermilov.

Also, thanks to Bill Filler, David Barth and Pat McGowan for keeping everybody focused.

And to Parameswaran Sivatharman for his tireless efforts on Continuous Integration.

I’m really excited about this

Alan Pope: March 2014 Core Apps Hack Days!

Fri, 2014-03-21 11:26

Hack Days are back!

On March 25th – 27th 2014 from 09:00 – 21:00U UTC we’re having another round of Core Apps Hack Days as we Sprint towards the final Ubuntu 14.04 release in April.

This time we’re concentrating our focus on 6 main apps, but we welcome new contributions to all the core apps. We’re identifying all the bite-size bugs which would be ideal for new developers, and we have some more chunky work for more experienced developers looking for more of a challenge. Getting involved is really easy and it’s fun and friendly.

Music & Reminders will be the focus on Tuesday 25th.

  

Clock & Calendar on Wednesday 26th.

  

Weather & Calculator on Thursday 27th.

  

That said, we don’t want to limit contributions to just those days, and of course welcome community developers getting involved at any time of day or night!

We’ve detailed on the HackDays wiki page how you can get involved and all the other details. Head over there for more information.

David, Michael & myself will be around on IRC in #ubuntu-app-devel as always to co-ordinate and run the Hack Days. We’ll also be able to test on multiple mobile devices as well as desktops and laptops. We can review code and get completed work landed into trunk and on devices promptly. We’ll also have and other Core Apps community & Canonical platform developers around to consult and mentor where required.

If you’ve ever considered developing on Ubuntu, but not got around to it, now is a great time to join. There’s plenty to do for people of all levels, developing Free Software for a very wide audience. Join us and lets make the Core Apps rock!

Pages