News aggregator

Aq: Thoughts on Planet Ubuntu

Planet WolvesLUG - Wed, 29/01/2014 - 01:43

Recently, Randall Ross has been laying out thoughts on Planet Ubuntu after analysing a survey he did. His conclusions are strong and wide-ranging: that Planet Ubuntu should be the place for authoritative goings-on from those who are passionate about making Ubuntu; that it’s currently full of random titbits of unrelated content; that staying “on topic” should be baked into the system.

I really, really do not agree.

You see, the thing that Ubuntu has that everything else does not is our community. I read Planet Ubuntu because I care about us, the people who make this thing. Years ago, back when Planet Gnome was the place where all the innovation relevant to Ubuntu was happening, they used to have this argument: that Planet Gnome should only be about Gnome, not about Gnome people. To their credit, they always resisted this push.

The thing that Ubuntu has that everything else does not is our *community*. I care about the people more than I care about the technology. I care that Tony from the Ubuntu UK podcast worked for someone who raised funds for the Philippines. I care that Sam took a break from the Moka icon project to make cheesecake from tofu. I care that Mako rides pink bikes and that Elizabeth likes pink keyboards as well as marketing Xubuntu. Because we’re a community. Because we’re more than just what we do for Ubuntu.

Your Ubuntu news does not come solely from Planet Ubuntu. If I want to see every detail of how the sausage is made, every aspect of how Ubuntu comes from the minds of our people to the disk on my laptop, I’ll read the ubuntu-phone and ubuntu-devel mailing lists. Mostly, I want curated news. I want someone else to choose what’s worthy of my attention and highlight it for me. And Joey does a fantastic job of that at OMG Ubuntu, followed up by ILU or Web Upd8 or Softpedia. I love reading the in-depth writeups that appear on Planet Ubuntu, whether it’s popey summarising the Ubuntu core apps hack days or Kees going into deep detail on gcc security, but there’s more to life, there’s more to our community, than just the techie details. When Ubuntu gets something large and new from Canonical it’ll be on The Verge and Engadget and Forbes; when there are important announcements they’ll be on the Fridge; when there’s a cool hack it’ll be on the mailing lists and IRC. What I want is a place where we are one. Where the Ubuntu community can come together to be one family. I am what I am because of what we all are. Not because of what we all do. Because of what we all are. That means that Lyz is more than just PLUG, that Sam is more than just an icon designer, that Joey is more than just a reporter. We’re together. Don’t let that go. Don’t let Planet Ubuntu, don’t let our thing, be changed to be a place where you have to be “authoritative”, where “random titbits” are forbidden, where being “on-topic” is more important than being friends. Let’s let other places do press releases, let other places enforce rules about being technical, let other places insist that you mustn’t talk “off-topic”. And keep Planet Ubuntu being a place where our community comes together.

Categories: LUG Community Blogs

Debian Bits: Debian.org enabled for SIP federation and WebRTC, XMPP/Jabber to follow

Planet HantsLUG - Tue, 28/01/2014 - 17:45

Debian System Administrators working in conjunction with pkg-voip team member Daniel Pocock have set up a SIP proxy and TURN server for debian.org.

Specifically, the SIP proxy provides a way for Debian Developers to use their Debian email ID as a SIP address for making calls to other project members and exchanging calls with any other domain that is enabled for SIP. The repro SIP proxy from reSIProcate has been chosen for this project.

The TURN server provides a mechanism for users of SIP or XMPP (Jabber) to relay audio and video streams through a public IP address when necessary, eliminating many of the quality issues that arise when NAT devices block the media streams in one or both directions.

The service allows the users to connect directly with the SIP device or softphone of their choosing, including many of those packaged in Debian such as Jitsi and Empathy or third party solutions like Lumicall or CSipSimple on Android. The SIP proxy also includes a WebRTC interface, allowing Debian Developers to immediately try WebRTC voice and video calls without installing or configuring any software of their own other than a web browser.

A second stage of the project involves providing an XMPP (Jabber) server with similar capabilities for federated communications between debian.org users and other domains. Further details will be announced in the weeks ahead.

It is a significant feature of the Debian Project philosophy that we can operate the entire project using free software, specifically, using software available in Debian packages running on our own infrastructure and without a dependency on third party cloud solutions.These new services for project members fulfill those expectations. It is particularly relevant for situations where real-time communication (voice or video) collaboration takes place with third parties such as applicants for Google Summer of Code, Outreach Program for Women, sponsors, media and other free software projects.

Project specific details and a user guide are available now on the Debian Wiki at http://wiki.debian.org/UnifiedCommunications/DebianDevelopers

Categories: LUG Community Blogs

Alan Pope: January 2014 Core Apps Hack Day Three – File Manager and Calculator

Planet HantsLUG - Tue, 28/01/2014 - 10:50

See also January 2014 Core Apps Hack Day One – Reminders and Music and January 2014 Core Apps Hack Day Two – Calendar and RSS Reader

Day three of the January 2014 Core Apps Hack Days brings focus to File Manager and Calculator but as I keep saying we welcome contributions to any app on any day of the week!

In order to get started we’ve come up with some suggestions for new developers.

First off get your development environment setup as documented at http://developer.ubuntu.com/apps/create/get-the-sdk/ which you can do either natively on Ubuntu 13.10 or 14.04 or in a Virtual Machine if you prefer.
If you have a Nexus device, you could either replace the legacy OS with Ubuntu using either of these guides – https://wiki.ubuntu.com/Touch/Install or https://wiki.ubuntu.com/Touch/DualBootInstallation.

Next up take a look at some of these suggestions based on your area of interest and skill level.

We welcome translations for all our Core Apps. If that’s if interest you can find everything you need at https://translations.launchpad.net/ubuntu-filemanager-app and https://translations.launchpad.net/ubuntu-calculator-app.

If you find bugs in the apps you can look for existing bugs to confirm or fix at https://bugs.launchpad.net/ubuntu-filemanager-app/+bugs and https://bugs.launchpad.net/ubuntu-calculator-app/+bugs, or file new bugs at https://bugs.launchpad.net/ubuntu-filemanager-app/+filebug and https://bugs.launchpad.net/ubuntu-calculator-app/+filebug

You may find some bugs which have yet to be confirmed or triaged, we’d love your help there too.

You’ll find out-standing merge proposals on launchpad at https://code.launchpad.net/ubuntu-filemanager-app/+activereviews and https://code.launchpad.net/ubuntu-calculator-app/+activereviews.

If you’d like to take on a task then we have some work items in the blueprints which you can assign to yourself and get cracking on at https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/coreapps-1404-filemanager-dev and https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/coreapps-1404-calculator-dev

You can find out more about the Core Apps Hack Days at the links at the top, and you’ll find all of us hanging out on #ubuntu-app-devel on freenode.

Categories: LUG Community Blogs

Steve Kemp: It is unfortunate that many companies need the same sysadmin jobs carried out

Planet HantsLUG - Tue, 28/01/2014 - 00:01

It is unfortunate that I've been exposed to several companies that all need the same kind of problems solving, again and again:

  • Imaging systems. Quickly.
  • Configuring MySQL & Postgres replication and fail-over.
  • Configuring local users.
  • Solving the problem of distributing usernames/passwords to 500+ client-systems within a team.

A lot of these are solved problems, yet they seem to keep cropping up. I guess the fact I've done some of these things more than once means I'm the local-expert, so that's why I get asked. But still..

There was a time when I thought my Debian Administration site would help solve these kind of problems; that writing documentation would encourage people to do things properly. Certainly it has helped me, and some other people are greatful, but it didn't do enough to help.

I'm not sure if the problem is that my documentation is a little ideosyncratic, isn't good enough, or isn't reaching the right kind of people. I suspect a combination of that and scale - You can't walk somebody though the idea of setting up a ten-node database-cluster, they need to suffer, they need to break things, they need to sweat on Christmas Day, at 5AM, as everything goes to hell. Then the next time they'll do it properly.

I'd love to take the time to write out recipes in Salt, Ansible, Puppet, Chef, CFengine, Slaughter, whatever, and support them.

Remote. Automated. System management.

Throw in monitoring of metrics, security fixes, and reporting and there's probably a valuable service there.

It probably can't happen though, for three main reasons:

  • The people that need it don't know they need it. They're fighting fires, they know it is important and they will fix things "soon", but other work takes priority.
  • The people that are tempted will baulk at the idea of unknown code from an external source running on their system(s).
  • Companies managed by one sysadmin will wonder why they need more help, because "everything is working, right?".

I did recently write some policies for setting up a two-node Master-Slave MySQL setup, with reporting, monitoring, and custom SMS-based alerts. I guess I'm wondering if I can be cheeky and sell the same work twice. ;)

Categories: LUG Community Blogs

Tony Whitmore: Helen Thompson

Planet HantsLUG - Mon, 27/01/2014 - 19:30

This isn’t my usual sort of blog post, so please bear with me.

Last summer I worked for Neil Thomas Douglas as second photographer at a wedding in Oxfordshire. James and Helen had put a lot of thought and effort into their day. From the outdoor ceremony where Helen’s pupils sang, through the meal cooked by family members and served to guests seated on hay bales, and onto the evening with live bands, swings and tug-of-war, the whole day was alive with their personalities. It was clear just how much Helen loved James. Her short, powerful speech sent shivers down my spine.

Helen died suddenly last month.

Even though I only knew her for a day, it was clear that Helen was a caring, lively and compassionate person. Someone who wanted to make the world a better place to live in. It was a privilege to be a part of Helen and James’ wedding day.

The fundraising campaign that Helen had set up to raise just £200 for voluntary aid workers in the Philippines has been flooded with donations and is currently at over 9000% of the target. This immense response shows just how loved and respected Helen was. If you can give anything in Helen’s memory, please do.

Thanks to James and Neil for letting me write this post.

Pin It
Categories: LUG Community Blogs

Alan Pope: January 2014 Core Apps Hack Day Two – Calendar and RSS Reader

Planet HantsLUG - Mon, 27/01/2014 - 11:19

See also January 2014 Core Apps Hack Day One – Reminders and Music.

Day two of the January 2014 Core Apps Hack Days brings focus to Calendar and RSS Reader (a.k.a. ‘Shorts’), but as always we welcome contributions to any app on any day of the week!

In order to get started we’ve come up with some suggestions for new developers.

First off get your development environment setup as documented at http://developer.ubuntu.com/apps/create/get-the-sdk/ which you can do either natively on Ubuntu 13.10 or 14.04 or in a Virtual Machine if you prefer.
If you have a Nexus device, you could either replace the legacy OS with Ubuntu using either of these guides – https://wiki.ubuntu.com/Touch/Install or https://wiki.ubuntu.com/Touch/DualBootInstallation.

Next up take a look at some of these suggestions based on your area of interest and skill level.

We welcome translations for all our Core Apps. If that’s if interest you can find everything you need at https://translations.launchpad.net/ubuntu-calendar-app and https://translations.launchpad.net/ubuntu-rssreader-app.

If you find bugs in the apps you can look for existing bugs to confirm or fix at https://bugs.launchpad.net/ubuntu-calendar-app/+bugs and https://bugs.launchpad.net/ubuntu-rssreader-app/+bugs, or file new bugs at https://bugs.launchpad.net/ubuntu-calendar-app/+filebug and https://bugs.launchpad.net/ubuntu-rssreader-app/+filebug

You may find some bugs which have yet to be confirmed or triaged, we’d love your help there too.

You’ll find out-standing merge proposals on launchpad at https://code.launchpad.net/ubuntu-calendar-app/+activereviews and https://code.launchpad.net/ubuntu-rssreader-app/+activereviews.

If you’d like to take on a task then we have some work items in the blueprints which you can assign to yourself and get cracking on at https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/coreapps-1404-calendar-dev and https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/coreapps-1404-rssreader-dev

You can find out more about the Core Apps Hack Days at the links at the top, and you’ll find all of us hanging out on #ubuntu-app-devel on freenode.

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Diet?

Planet ALUG - Sun, 26/01/2014 - 13:34

One of my new year's resolutions is to lose a stone. After some consideration of how I might do that, I decided some sort of diet would be in order. Fairly obvious, I suppose, but I did toy with the idea of seeing if I could do it just by exercising more; I don't think it would even be possible to practically exercise enough to burn off half of what I like to eat.

Before Christmas, I had been thinking about reducing my carbohydrate intake as it seemed that every meal I was eating centred around bread or potatoes. Curry, for example, was all about mopping up the sauce with the naan bread :)

I decided, in the interests of science or summat, to go the whole hog and drop my carbs completely. Well, almost completely. I've been on this very-low-carb diet for about three weeks now and I've already lost half a stone. It's probably not sustainable but here's why I think I've lost weight already when previous attempts at eating less have failed:

  1. The general advice on the intertubes seems to be that, when eating low carbs, one should eat more fat to feel sated. That seems to bear out so far; I've been having things like omelette cooked with butter for breakfast and I don't get hungry until lunch time easily.

  2. Having a very simple rule to stick to has made it easier to stick to. Simply telling myself "try to eat a bit less" or "eat more healthily" may have been a little too wishy-washy for my probably-slightly-autistic brain to deal with. "Has it got a carbohydrate content of greater than 5%? Then no, you can't have it." is a hard and fast - and therefore simple - rule to adhere to.

  3. Carbs seem easier to gorge on than other foods. I can devour a massive portion of chips without pausing for breath but I simply can't do the same with steak or vegetables.

  4. Every meal feels like a treat. When I can bust out home-made salads with various exciting meats and "naughty" cheeses for lunch, it feels like I'm having something special every time I eat. Dinners consisting of some sort of meat plus some nicely cooked (this likely means with butter) vegetables are fantastic.

  5. There is almost no way to eat any kind of snack food, so I don't. Fruit is quite high in carbs so I don't eat too much of it. Crisps, biscuits, and sweets are right out and I'm not even tempted any more.

  6. I don't need to count anything or keep a tally in my head.

All of which makes me sound a right wanker.

This morning, I just proved to myself the main reason this diet is working for me. I have forbidden myself carbs and I have just about enough willpower to follow that rule because it is just one, unambiguous rule. I haven't been following it completely strictly; I allow myself a beer every now and then. Today, I decided to have a cheat breakfast and included some home-made chips. Without even thinking about it, I ate an absolute ton of them and now I feel slightly sad and very, very full.

Lesson learnt; back to the diet. With any luck, I'm looking forward to being 13 stone by my birthday.

What a wanker.

Categories: LUG Community Blogs

Andrew Savory: Super markets

Planet ALUG - Sat, 25/01/2014 - 11:11

I’ve been using our local Lidl recently, because their policy of regularly baking throughout the day means I can pick up fresh croissants and pains au chocolat whenever I go, whereas the local Tesco, Sainsburys, and Waitrose have usually run out by mid-morning. Are the so-called discount supermarkets really cheaper than the mainstream supermarkets? Here’s the result of one unscientific survey.

This morning I checked my till receipt against Tesco online. There are some items that cost the same regardless of which supermarket (fabric softener, fresh orange juice). There are some items that don’t have direct equivalents across stores, so price comparisons aren’t possible. And there are some items where the price is not significantly different (fresh milk, toilet paper). On today’s basket of comparable items, Lidl was £10.62 cheaper (costing £18.46 instead of £29.08). There are some real eye-openers. Eggs are 1.5x more expensive at Tesco. Fresh vegetables were often almost twice the price at Tesco. And what about my fresh croissants and pains au chocolat? £0.29 and £0.39 at Lidl, vs £0.80 each at Tesco. Over twice the price — on today’s shop, buying just these alone saved me £4.70. And they were fresh from the oven, still warm when I got them home.
Categories: LUG Community Blogs

Alan Pope: January 2014 Core Apps Hack Day One – Reminders and Music

Planet HantsLUG - Fri, 24/01/2014 - 11:58

As David blogged yesterday, we’re having another round of Core Apps Hack Days for our Ubuntu Phone Core Apps

Each day we’re focussing on two apps, today that’s Reminders and Music, but as always we welcome contributions to any app on any day of the week!

In order to get started we’ve come up with some suggestions for new developers.

First off get your development environment setup as documented at http://developer.ubuntu.com/apps/create/get-the-sdk/ which you can do either natively on Ubuntu 13.10 or 14.04 or in a Virtual Machine if you prefer.
If you have a Nexus device, you could either replace the legacy OS with Ubuntu using either of these guides – https://wiki.ubuntu.com/Touch/Install or https://wiki.ubuntu.com/Touch/DualBootInstallation.

Next up take a look at some of these suggestions based on your area of interest and skill level.

We welcome translations for all our Core Apps. If that’s if interest you can find everything you need at https://translations.launchpad.net/reminders-app and https://translations.launchpad.net/music-app.

If you find bugs in the apps you can look for existing bugs to confirm or fix at https://bugs.launchpad.net/reminders-app/+bugs and https://bugs.launchpad.net/music-app/+bugs, or file new bugs at https://bugs.launchpad.net/reminders-app/+filebug and https://bugs.launchpad.net/reminders-app/+filebug

You may find some bugs which have yet to be confirmed or triaged, we’d love your help there too.

You’ll find out-standing merge proposals on launchpad at https://code.launchpad.net/reminders-app/+activereviews and https://code.launchpad.net/music-app/+activereviews.

If you’d like to take on a task then we have some work items in the blueprints which you can assign to yourself and get cracking on at https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/reminders-app-development and https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/coreapps-1404-music-dev

You can find out more about the Core Apps Hack Days at the links at the top, and you’ll find all of us hanging out on #ubuntu-app-devel on freenode.

Categories: LUG Community Blogs

Aq: Saving the current state of your Ubuntu SDK app, with no effort

Planet WolvesLUG - Thu, 23/01/2014 - 19:14

Earlier today I gave an example of how to use U1DB to save the state of your Ubuntu app. Now, U1DB is useful for actually storing actual data, right enough. But if you want to save state — which tab was showing, what was being typed into a text field, what was chosen in a dropdown, where a list was scrolled to — then that’s built right in 1 to the Ubuntu SDK.

It’s called StateSaver.

This isn’t used to store data, long term. It’s used to make your app automatically remember what position things were in. So quitting the app and restarting it, or switching to another and then switching back, means the app doesn’t reset to the front screen, doesn’t forget what you were halfway through typing in, doesn’t forget where you’d scrolled to.

To use it, just add StateSaver.properties to the Item you want to save things for. So, for example, if you want your ListView to remember the position it was scrolled to, do this:

ListView { id: mylistview model: someModel delegate: ListItem.Standard { text: "row " + model.index } StateSaver.properties: "contentY" }

Just that one thing. Now your ListView remembers where it was scrolled to after a restart. You can do the same with a set of Tabs (just add StateSaver.properties: "selectedTabIndex") or a TextField (StateSaver.properties: "text").

NB: this isn’t really for data saving. It might, or might not, be appropriate to use it for whether a switch is flipped or not. That’s a setting; when the switch is changed, you ought to be doing something with that information. Ideally you could drive everything, declaratively, off of whether the switch.checked is true, and if you can do that then StateSaver is the ideal place to have that info. But if you run a function when a switch is changed, then don’t use StateSaver to remember its state: use U1DB, and store the other stuff that changed alongside it. It’s about saving state, hence the name.

Saving the state of your app like this is an idea so good that other ideas gather at its feet to pray. I think that this should be turned on automatically for the “relevant” properties of each type of Ubuntu SDK widget, and if for some reason you don’t like it you can turn it off. Not for every single property, but for the ones where state makes sense: the scroll position for a ListView, the entered text for a TextField, the visible tab for Tabs. Small things like this are what make the difference between great apps and merely good ones. Any one individual app isn’t particularly harmed by not remembering this stuff; so many apps do not, on other platforms, that people are used to the idea of having their state thrown away. But if almost all the apps do do this, then the ones that don’t get called out on it and then it gets fixed, and that makes the whole platform better. It’s really important that we create a culture of desire for finished, polished apps for Ubuntu. If your app throws away where I was scrolled to, I want the developer to feel a bit embarrassed about that and immediately go to fix it. That’s what will make our platform feel consistent, feel tight, feel together, feel fun to use; the culture of pushing back on unfinished and unpolished and half-ready apps. Open source has historically not had that culture, but I’d really like to use a platform which does.

Importantly, though, for it to be reasonable for we users to require this of app developers, it has to not be really hard for app developers to do. This, taking complicated things and making them easy for app developers to implement, is what the platform is for. And StateSaver is a great example of it; the platform provides! I’m really impressed that this exists and is part of the SDK. (I’d be even more impressed if it did it automatically, as noted.) Good work, Ubuntu SDK team. This stuff needs more publicity!

Longer code example, which remembers which tab you were looking at, where the list is scrolled to, and what was typed in the text field:

import QtQuick 2.0 import Ubuntu.Components 0.1 import Ubuntu.Components.ListItems 0.1 as ListItem MainView { id: root width: units.gu(40) height: units.gu(70) Tabs { id: tabs StateSaver.properties: "selectedTabIndex" Tab { id: t1 title: "StateSaver, 1" page: Page { id: pg ListView { id: lv model: 40 clip: true anchors.fill: parent StateSaver.properties: "contentY" delegate: ListItem.Standard { text: "This is row " + model.index + ". Scroll to wherever." } } } } Tab { id: t2 title: "StateSaver, 2" Column { width: parent.width id: col2 spacing: units.gu(1) anchors.centerIn: parent Label { text: "Enter your favourite pie" horizontalAlignment: Text.AlignHCenter anchors.horizontalCenter: parent.horizontalCenter } TextField { id: tf width: parent.width - units.gu(2) StateSaver.properties: "text" anchors.horizontalCenter: parent.horizontalCenter } } } } }

Notes:

  1. how did I not know this existed! Big thanks to Florian for cueing me in
Categories: LUG Community Blogs

Aq: Saving the current state of your Ubuntu SDK app, with no effort

Planet WolvesLUG - Thu, 23/01/2014 - 19:14

Earlier today I gave an example of how to use U1DB to save the state of your Ubuntu app. Now, U1DB is useful for actually storing actual data, right enough. But if you want to save state — which tab was showing, what was being typed into a text field, what was chosen in a dropdown, where a list was scrolled to — then that’s built right in1 to the Ubuntu SDK.

It’s called StateSaver.

This isn’t used to store data, long term. It’s used to make your app automatically remember what position things were in. So quitting the app and restarting it, or switching to another and then switching back, means the app doesn’t reset to the front screen, doesn’t forget what you were halfway through typing in, doesn’t forget where you’d scrolled to.

To use it, just add StateSaver.properties to the Item you want to save things for. So, for example, if you want your ListView to remember the position it was scrolled to, do this:

ListView { id: mylistview model: someModel delegate: ListItem.Standard { text: "row " + model.index } StateSaver.properties: "contentY" }

Just that one thing. Now your ListView remembers where it was scrolled to after a restart. You can do the same with a set of Tabs (just add StateSaver.properties: "selectedTabIndex") or a TextField (StateSaver.properties: "text").

NB: this isn’t really for data saving. It might, or might not, be appropriate to use it for whether a switch is flipped or not. That’s a setting; when the switch is changed, you ought to be doing something with that information. Ideally you could drive everything, declaratively, off of whether the switch.checked is true, and if you can do that then StateSaver is the ideal place to have that info. But if you run a function when a switch is changed, then don’t use StateSaver to remember its state: use U1DB, and store the other stuff that changed alongside it. It’s about saving state, hence the name.

Saving the state of your app like this is an idea so good that other ideas gather at its feet to pray. I think that this should be turned on automatically for the “relevant” properties of each type of Ubuntu SDK widget, and if for some reason you don’t like it you can turn it off. Not for every single property, but for the ones where state makes sense: the scroll position for a ListView, the entered text for a TextField, the visible tab for Tabs. Small things like this are what make the difference between great apps and merely good ones. Any one individual app isn’t particularly harmed by not remembering this stuff; so many apps do not, on other platforms, that people are used to the idea of having their state thrown away. But if almost all the apps do do this, then the ones that don’t get called out on it and then it gets fixed, and that makes the whole platform better. It’s really important that we create a culture of desire for finished, polished apps for Ubuntu. If your app throws away where I was scrolled to, I want the developer to feel a bit embarrassed about that and immediately go to fix it. That’s what will make our platform feel consistent, feel tight, feel together, feel fun to use; the culture of pushing back on unfinished and unpolished and half-ready apps. Open source has historically not had that culture, but I’d really like to use a platform which does.

Importantly, though, for it to be reasonable for we users to require this of app developers, it has to not be really hard for app developers to do. This, taking complicated things and making them easy for app developers to implement, is what the platform is for. And StateSaver is a great example of it; the platform provides! I’m really impressed that this exists and is part of the SDK. (I’d be even more impressed if it did it automatically, as noted.) Good work, Ubuntu SDK team. This stuff needs more publicity!

Longer code example, which remembers which tab you were looking at, where the list is scrolled to, and what was typed in the text field:

import QtQuick 2.0 import Ubuntu.Components 0.1 import Ubuntu.Components.ListItems 0.1 as ListItem MainView { id: root width: units.gu(40) height: units.gu(70) Tabs { id: tabs StateSaver.properties: "selectedTabIndex" Tab { id: t1 title: "StateSaver, 1" page: Page { id: pg ListView { id: lv model: 40 clip: true anchors.fill: parent StateSaver.properties: "contentY" delegate: ListItem.Standard { text: "This is row " + model.index + ". Scroll to wherever." } } } } Tab { id: t2 title: "StateSaver, 2" Column { width: parent.width id: col2 spacing: units.gu(1) anchors.centerIn: parent Label { text: "Enter your favourite pie" horizontalAlignment: Text.AlignHCenter anchors.horizontalCenter: parent.horizontalCenter } TextField { id: tf width: parent.width - units.gu(2) StateSaver.properties: "text" anchors.horizontalCenter: parent.horizontalCenter } } } } }
  1. how did I not know this existed! Big thanks to Florian for cueing me in
Categories: LUG Community Blogs

Aq: Using U1DB in ListViews in Ubuntu SDK apps

Planet WolvesLUG - Thu, 23/01/2014 - 17:24

After explaining how to use U1DB to store simple bits of information in Ubuntu SDK apps, and saying that that caters for 80% of my need for data storage, I should explain the other thing I do, which is to store dynamic data; documents created from user data.

To understand more about how to retrieve data from U1DB through Indexes and Queries, you can read the core U1DB documentation. Its code examples are for the Python implementation, and QML works differently for creating documents (as we’ve seen, QML is declarative; there’s no code to write, you just describe a document and it all works), but indexing and querying documents have the same underlying philosophy regardless of implementation, and the core docs explain what an index is, what a query is, and how they work.

First, a simple code example.

import QtQuick 2.0 import Ubuntu.Components 0.1 import U1db 1.0 as U1db import Ubuntu.Components.ListItems 0.1 as ListItem MainView { width: units.gu(40) height: units.gu(71) /* ---------------------------------------------------- Set up the U1DB database Declare a named document ---------------------------------------------------- */ U1db.Database { id: db; path: "simpleu1dbdemo2.u1db" } U1db.Index { database: db id: by_type /* You have to specify in the index all fields you want to retrieve The query should return the whole document, not just indexed fields https://bugs.launchpad.net/u1db-qt/+bug/1271973 */ expression: ["things.type", "things.placename"] } U1db.Query { id: places index: by_type query: ["*", "*"] } Page { title: "U1DB ListModel" Column { id: col width: parent.width spacing: units.gu(1) Label { width: parent.width text: "Enter a place to add to list" horizontalAlignment: Text.AlignHCenter } Rectangle { id: ta width: parent.width - units.gu(2) color: "white" height: inp.height * 2 anchors.horizontalCenter: parent.horizontalCenter radius: 5 TextInput { id: inp width: parent.width - units.gu(2) anchors.centerIn: parent onAccepted: inp.adddoc() function adddoc() { /* Indexes do not work on top-level fields. So put everything in the document in a dict called "things" so that they're not top-level fields any more. https://bugs.launchpad.net/u1db-qt/+bug/1271972 */ db.putDoc({things: {type: "place", placename: inp.text}}) inp.text = "" } } } Button { text: "Add" width: ta.width anchors.horizontalCenter: parent.horizontalCenter onClicked: inp.adddoc() } } ListView { anchors.top: col.bottom anchors.bottom: parent.bottom width: parent.width model: places clip: true delegate: ListItem.Standard { text: model.contents.placename control: Button { text: "x" width: units.gu(4) onClicked: { /* To delete a document, you currently have to set its contents to empty string. There will be db.delete_doc eventually. https://bugs.launchpad.net/u1db-qt/+bug/1243395 */ db.putDoc("", model.docId); } } } } } }

You type in a place name and say “Add”; it gets added to the list. The list is stored in U1DB, so it persists; close the app and open it again and you still have your place names. Click a place to delete it.

This covers almost all the remaining stuff that I need to do with data storage. There are a few outstanding bugs still with using U1DB from QML, which I’ve annotated in the source above, and at the moment you have to work around those bugs by doing things that you ought not to have to; once they’re fixed, this becomes more intuitive to use.

Categories: LUG Community Blogs

Aq: Using U1DB in ListViews in Ubuntu SDK apps

Planet WolvesLUG - Thu, 23/01/2014 - 17:24

After explaining [how to use U1DB to store simple bits of information in Ubuntu SDK apps][], and saying that that caters for 80% of my need for data storage, I should explain the other thing I do, which is to store dynamic data; documents created from user data.

To understand more about how to retrieve data from U1DB through Indexes and Queries, you can read the core U1DB documentation. Its code examples are for the Python implementation, and QML works differently for creating documents (as we’ve seen, QML is declarative; there’s no code to write, you just describe a document and it all works), but indexing and querying documents have the same underlying philosophy regardless of implementation, and the core docs explain what an index is, what a query is, and how they work.

First, a simple code example.

import QtQuick 2.0 import Ubuntu.Components 0.1 import U1db 1.0 as U1db import Ubuntu.Components.ListItems 0.1 as ListItem MainView { width: units.gu(40) height: units.gu(71) /* ---------------------------------------------------- Set up the U1DB database Declare a named document ---------------------------------------------------- */ U1db.Database { id: db; path: "simpleu1dbdemo2.u1db" } U1db.Index { database: db id: by_type /* You have to specify in the index all fields you want to retrieve The query should return the whole document, not just indexed fields https://bugs.launchpad.net/u1db-qt/+bug/1271973 */ expression: ["things.type", "things.placename"] } U1db.Query { id: places index: by_type query: ["*", "*"] } Page { title: "U1DB ListModel" Column { id: col width: parent.width spacing: units.gu(1) Label { width: parent.width text: "Enter a place to add to list" horizontalAlignment: Text.AlignHCenter } Rectangle { id: ta width: parent.width - units.gu(2) color: "white" height: inp.height * 2 anchors.horizontalCenter: parent.horizontalCenter radius: 5 TextInput { id: inp width: parent.width - units.gu(2) anchors.centerIn: parent onAccepted: inp.adddoc() function adddoc() { /* Indexes do not work on top-level fields. So put everything in the document in a dict called "things" so that they're not top-level fields any more. https://bugs.launchpad.net/u1db-qt/+bug/1271972 */ db.putDoc({things: {type: "place", placename: inp.text}}) inp.text = "" } } } Button { text: "Add" width: ta.width anchors.horizontalCenter: parent.horizontalCenter onClicked: inp.adddoc() } } ListView { anchors.top: col.bottom anchors.bottom: parent.bottom width: parent.width model: places clip: true delegate: ListItem.Standard { text: model.contents.placename control: Button { text: "x" width: units.gu(4) onClicked: { /* To delete a document, you currently have to set its contents to empty string. There will be db.delete_doc eventually. https://bugs.launchpad.net/u1db-qt/+bug/1243395 */ db.putDoc("", model.docId); } } } } } }

You type in a place name and say “Add”; it gets added to the list. The list is stored in U1DB, so it persists; close the app and open it again and you still have your place names. Click a place to delete it.

This covers almost all the remaining stuff that I need to do with data storage. There are a few outstanding bugs still with using U1DB from QML, which I’ve annotated in the source above, and at the moment you have to work around those bugs by doing things that you ought not to have to; once they’re fixed, this becomes more intuitive to use.

[how to use U1DB to store simple bits of information in Ubuntu SDK apps]: http://kryogenix.org/days/2014/01/23/a-simple-u1db-example-for-ubuntu-sdk-apps

Categories: LUG Community Blogs

Dick Turpin: Definition

Planet WolvesLUG - Thu, 23/01/2014 - 13:01
Email #1 "What is the screen definition of the three laptops you are selling?"

Me: "What do you mean by 'definition'? the screen sizes are two @ 14.1" inches and one @ 15.6" inches."

Email #2 "Not size, definition like 1260x800!"

Me: "Oh you mean 'Resolution' here are the links to the spec sheets."

Email #3 "Precisely"

Aye? I knew I should have become a Gibbon trainer.

Categories: LUG Community Blogs
Syndicate content