Planet WolvesLUG

Syndicate content
Planet Wolves - http://www.wolveslug.org.uk/planet/
Updated: 1 hour 29 min ago

Peter Cannon: Hot Scripts

Wed, 29/01/2014 - 16:52

Hot Scripts Hot Scripts is a comprehensive Web directory of more than 41,000 web development and programming-related resources.

Categories: LUG Community Blogs

Peter Cannon: Computer Stupidities

Wed, 29/01/2014 - 16:51

Computer Stupidities The following is a large collection of stories and anecdotes about clueless computer users.

Categories: LUG Community Blogs

Peter Cannon: Best Windows Software

Wed, 29/01/2014 - 16:48

Best Windows Software is a simple list of the best ‘Free’ applications available for Windows.

Categories: LUG Community Blogs

Peter Cannon: Firefox TV

Wed, 29/01/2014 - 16:25

“I see Firefox as a Media Presentation Company to be honest rather than just a browser developer.” EP67 Let me lick your custard. #tdtrs

Categories: LUG Community Blogs

Jono Bacon: On Planet Ubuntu

Wed, 29/01/2014 - 02:56

Recently Randall did some research into what people want to see on Planet Ubuntu. This has been followed up by Stuart with a set of concerns.

I agree with both of them.

I think the gist of Randall’s view is that he would like to encourage more fun, interesting, and diverse Ubuntu-related content. I think Randall wants to see fun stories of LoCo events, interesting Ubuntu work going on, cool Ubuntu apps, details of new features, and more. I agree with Randall here, and would love to see the same.

I think the gist of Stuart’s view is that the personal stories on Planet Ubuntu is a wonderful part of being in a community. Ubuntu is not just about Ubuntu, it is about the stories and the lives of the people who contribute to our community. I agree with Stuart here too.

I think we need a mix. Ideally we want to see interesting posts about people’s contributions to Ubuntu, but also about their non-Ubuntu lives too.

I would like to see Planet Ubuntu stick to its core goal: to be a place where you can look into the lives of Ubuntu members and explore their Ubuntu work as well as their non-Ubuntu thoughts and views.

The problem here is really with Ubuntu membership. Some people are still Ubuntu members who haven’t contributed to Ubuntu for a long time and thus we see lots of non-Ubuntu content, but rarely hear about their contributions. I would recommend we deactivate membership for those who are not actively contributing (active being significant and sustained contributions, as per our charter); this will then tighten up which feeds appear on planet and we will get a nice mix of both Ubuntu and person content.

Categories: LUG Community Blogs

Aq: Thoughts on Planet Ubuntu

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

Aq: Thoughts on Planet Ubuntu

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

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

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

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

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

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

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

Aq: A simple U1DB example for Ubuntu SDK apps

Thu, 23/01/2014 - 12:42

On Reddit, Aaron Hastings said:

One of the features I’d really like to implement is for the app [a timetable viewer for trains] to save state upon exit. In other words, if a user selected the “Abbey Street” stop, then exited, the app should remember to load Abbey Street on next launch. I’ll have to look into how that’s implemented in Ubuntu.

I’d use U1DB to do that. A simple example:

import QtQuick 2.0 import Ubuntu.Components 0.1 import U1db 1.0 as U1db MainView { width: units.gu(40) height: units.gu(71) /* ---------------------------------------------------- Set up the U1DB database Declare a named document ---------------------------------------------------- */ U1db.Database { id: db; path: "simpleu1dbdemo.u1db" } U1db.Document { id: lastPlace database: db docId: "lastPlace" create: true defaults: { placename: "" } } Page { title: "Simple U1DB demo" Column { width: parent.width spacing: units.gu(1) Label { width: parent.width text: "Enter a place" horizontalAlignment: Text.AlignHCenter } Rectangle { 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 /* ---------------------------------------------------- Important part number one Retrieve the value from the declared U1DB document ---------------------------------------------------- */ text: lastPlace.contents.placename || "" /* ---------------------------------------------------- Important part number two Save a changed value back to the U1DB document ---------------------------------------------------- */ onTextChanged: lastPlace.contents = {placename: text} } } } } }

This mechanism fulfils about 80% of my data storage needs for Ubuntu SDK apps. You declare a database and a named document; you use the values in that document (documentQMLid.contents.fieldname) declaratively, and to save values, just set documentQMLid.contents.

Of course, you could do this with QML LocalStorage, but do you really want to be constructing SQL statements all day? I don’t. And if you use U1DB now, it keeps the door open for more complicated things later, such as syncing this data between devices, or storing more dynamic data and then querying it, which I should probably write another blog post about if there’s interest.

Categories: LUG Community Blogs

Aq: A simple U1DB example for Ubuntu SDK apps

Thu, 23/01/2014 - 12:42

On Reddit, Aaron Hastings said:

One of the features I’d really like to implement is for the app [a timetable viewer for trains] to save state upon exit. In other words, if a user selected the “Abbey Street” stop, then exited, the app should remember to load Abbey Street on next launch. I’ll have to look into how that’s implemented in Ubuntu.

I’d use U1DB to do that. A simple example:

import QtQuick 2.0 import Ubuntu.Components 0.1 import U1db 1.0 as U1db MainView { width: units.gu(40) height: units.gu(71) /* ---------------------------------------------------- Set up the U1DB database Declare a named document ---------------------------------------------------- */ U1db.Database { id: db; path: "simpleu1dbdemo.u1db" } U1db.Document { id: lastPlace database: db docId: "lastPlace" create: true defaults: { placename: "" } } Page { title: "Simple U1DB demo" Column { width: parent.width spacing: units.gu(1) Label { width: parent.width text: "Enter a place" horizontalAlignment: Text.AlignHCenter } Rectangle { 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 /* ---------------------------------------------------- Important part number one Retrieve the value from the declared U1DB document ---------------------------------------------------- */ text: lastPlace.contents.placename || "" /* ---------------------------------------------------- Important part number two Save a changed value back to the U1DB document ---------------------------------------------------- */ onTextChanged: lastPlace.contents = {placename: text} } } } } }

This mechanism fulfils about 80% of my data storage needs for Ubuntu SDK apps. You declare a database and a named document; you use the values in that document (documentQMLid.contents.fieldname) declaratively, and to save values, just set documentQMLid.contents.

Of course, you could do this with QML LocalStorage, but do you really want to be constructing SQL statements all day? I don’t. And if you use U1DB now, it keeps the door open for more complicated things later, such as syncing this data between devices, or storing more dynamic data and then querying it, which I should probably write another blog post about if there’s interest.

Categories: LUG Community Blogs

Jono Bacon: On Accountability

Thu, 23/01/2014 - 02:12

Every so often I see a scenario play out that I find rather disappointing.

It works like this: someone posts a topic to their blog that is critical or controversial. This person can either be a community member, commentator, employee or otherwise; it doesn’t matter who the person is. Then what happens is a series of comments are posted to that blog entry from readers that are critical of the post, thus challenging the author on their views. The author then either deletes the blog entry or disables the comments based on the feedback. In other words, a viewpoint is shared, an invitation for comment is provided, but that invitation is then revoked when the author of the blog post is dissatisfied with the response from their readers.

I have seen this happen countless times over the years and I don’t like this.

I believe we should all be accountable for our words. Our words have the ability to inspire, to entertain, to challenge, but to also hurt. Actions have consequences, and so do words.

As such, when I see someone openly share their thoughts on their blog and invite their readers to provide comments, I see that as a wonderful demonstration of accountability and engagement; debate is a beautiful thing when executed with politeness and respect. To then close that door, seemingly because people disagree with you, is in my mind the equivalent of walking out of a room in the middle of a debate. The excuse when folks are criticized of this behavior is typically “it is my blog and I can run it how I like“.

This is true: it is your blog, and you can run it how you like, but the true measure of a person is not just in what they say, but also in the conversation and discourse that follows.

Now, there are two very important caveats to my view here. Firstly, abusive, threatening, or otherwise offensive content is a perfect candidate for removal and the commentator for banning. We should never tolerate this. Secondly, I can understand the removal of a blog post if there is a legal requirement to do so. In the majority of cases where I have seen posts removed or comments disabled though, it has been for neither of these reasons.

Speaking personally, I have never, ever, switched off comments on my blog posts or deleted posts. Even when the Internet has seemingly come to get me, or when the press pick up on something and are critical, or when I have made a mistake and felt embarrassed at the outcome…I have never switched off comments and never deleted a blog post. This is because I feel I should be and I am accountable for my words.

For me, this is an ethical issue; in the same way I won’t go and re-write or edit a blog post if I get criticism for it (outside of minor grammatical/spelling fixes). My posts are a time-capsule of my thinking at that point in my life. For me to go and edit them would be me re-writing history. A blog is not a regularly updated record of your views (like a book), it is chronological diary of your views and progression as a person. Consequently, my blog is filled with moments from my past that don’t reflect my views, experience, or ideas of today. Some of those posts are even embarrassing. But you know what, those posts stay unchanged, and I am proud that I have never compromised on this accountability.

So with this in mind, I have a simple suggestion for those of you who run blogs: either switch your comments off entirely or always leave them on, but don’t turn them off when you don’t like the reaction from your readers. Polite and respectful debate helps us grow as human beings, helps us evolve our ideas and perspectives, and makes us better people. Let history be our record, not our edited version of history.

Categories: LUG Community Blogs

Aq: Notes on footnotes

Wed, 22/01/2014 - 17:53

I use footnotes quite a bit in my posts. Normally for snarky asides, I grant you, but I picked that habit up from Terry Pratchett.

They’re easy to add to WordPress; I use Andrew Nacin’s Simple Footnotes WP plugin, and then all you have to do is drop [ref]footnote text here[/ref] into the text of your post 1 and it takes care of numbering the footnote, displaying it at the bottom of the page, allowing you to link back and forth.

However, as Jake Archibald pointed out on Twitter, footnotes at the bottom of the page feel rather like a print media sort of thing. That’s useful, if someone prints your page out, or if they run it through some sort of “easy reading” service such as Readability or iOS Reader, or if your page gets turned into an ebook — we don’t want to remove that capability. But, as noted, scrolling down to the bottom of the page to read a footnote and then scrolling back up again is stupid. The Simple Footnotes plugin gets half a point for this by making the footnote number (a superscript 1, or whatever) be a link which jumps to the footnote for you, and each footnote has its own “return” link which takes you back to where you were. That’s great on a touch device. If you’ve got a pointer, we have the ability to hover, and this is what tooltips are for, so if we add title="text of the footnote" to the footnote number link, you can see the text of the footnote without having to click and jump around the page at all by just mousing over the number.

Footnotes with a properly-sized hit target

That superscript 1 is a pretty tiny target though, either to click or to hover over. It would be nice if the mouse target were bigger, but we don’t want a bunch of white space around the number. So, a little CSS:

a.simple-footnote { text-decoration: none; position: relative; color: rgba(255,0,0,0.7); /* cater for WP putting too much left spacing in before footnote numbers */ margin-left: -.2em; } a.simple-footnote::after { content: " "; position: absolute; display: inline-block; padding: 1em; margin-left: -1.3em; margin-top: -.3em; border: 1px solid transparent; border-radius: 2px; } a.simple-footnote:hover::after { background: rgba(0,0,0,0.2); border: 1px solid rgba(0,0,0,0.4); }

which I added to Admin > Appearance > Edit CSS in WordPress. Now you get a nice large hit target for your mouse, which lights up when you’re over it, and a tooltip, but your page still contains its footnotes properly when run through Readability or printed (which it might not if you were to use some sort of JavaScript popover library rather than the stuff that’s just built in to the browser and understood by accessibility tools).

Notes:

  1. like this!
Categories: LUG Community Blogs

Aq: Notes on footnotes

Wed, 22/01/2014 - 17:53

I use footnotes quite a bit in my posts. Normally for snarky asides, I grant you, but I picked that habit up from Terry Pratchett.

They’re easy to add to Wordpress; I use Andrew Nacin’s Simple Footnotes WP plugin, and then all you have to do is drop [ref]footnote text here[/ref] into the text of your post1 and it takes care of numbering the footnote, displaying it at the bottom of the page, allowing you to link back and forth.

However, as Jake Archibald pointed out on Twitter, footnotes at the bottom of the page feel rather like a print media sort of thing. That’s useful, if someone prints your page out, or if they run it through some sort of “easy reading” service such as Readability or iOS Reader, or if your page gets turned into an ebook — we don’t want to remove that capability. But, as noted, scrolling down to the bottom of the page to read a footnote and then scrolling back up again is stupid. The Simple Footnotes plugin gets half a point for this by making the footnote number (a superscript 1, or whatever) be a link which jumps to the footnote for you, and each footnote has its own “return” link which takes you back to where you were. That’s great on a touch device. If you’ve got a pointer, we have the ability to hover, and this is what tooltips are for, so if we add title="text of the footnote" to the footnote number link, you can see the text of the footnote without having to click and jump around the page at all by just mousing over the number.

[caption id=”attachment_2310” align=”aligncenter” width=”250”][]Footnotes with a properly-sized hit target Footnotes with a properly-sized hit target[/caption]

That superscript 1 is a pretty tiny target though, either to click or to hover over. It would be nice if the mouse target were bigger, but we don’t want a bunch of white space around the number. So, a little CSS:

a.simple-footnote { text-decoration: none; position: relative; color: rgba(255,0,0,0.7); /* cater for WP putting too much left spacing in before footnote numbers */ margin-left: -.2em; } a.simple-footnote::after { content: " "; position: absolute; display: inline-block; padding: 1em; margin-left: -1.3em; margin-top: -.3em; border: 1px solid transparent; border-radius: 2px; } a.simple-footnote:hover::after { background: rgba(0,0,0,0.2); border: 1px solid rgba(0,0,0,0.4); }

which I added to Admin > Appearance > Edit CSS in Wordpress. Now you get a nice large hit target for your mouse, which lights up when you’re over it, and a tooltip, but your page still contains its footnotes properly when run through Readability or printed (which it might not if you were to use some sort of JavaScript popover library rather than the stuff that’s just built in to the browser and understood by accessibility tools).

  1. like this!
Categories: LUG Community Blogs

Dick Turpin: Let me guess.

Wed, 22/01/2014 - 12:16
Why do people ring without the most basic of information?

Customer: "Hi have you got an internal fan for a Dell Server?"
Me: "Tower or Rackmount?"
Customer: "Rackmount."
Me: "Which model?"
Customer: "Oh, I'll have to come back to you."
Categories: LUG Community Blogs

Dick Turpin: Back(up) to basics

Mon, 20/01/2014 - 11:15
Customer: "I haven't had an email to say that its failed but I don't think the server backed up. The tape was out the drive and I don't know if that was because nobody pushed it in or if it was ejected?"
Engineer: "Have you tried pushing the tape in to see what's on it?"
Customer: "Oh"

Welcome to Monday morning.
Categories: LUG Community Blogs

Jono Bacon: Bad Voltage in 2014

Sun, 19/01/2014 - 17:44

In 2013 we kicked off Bad Voltage, a fun and irreverent podcast about technology, Open Source, gaming, politics, and anything else we find interesting. The show includes a veritable bounty of presenters including Stuart Langridge (LugRadio, Show Of Jaq), Bryan Lunduke (Linux Action Show), Jeremy Garcia (LinuxQuestions Podcast), and myself (LugRadio, Shot Of Jaq).

We have all podcasted quite a bit before and we know it takes a little while to really get into the groove, but things are really starting to gel in the show. We are all having a blast doing it, and it seems people are enjoying it.

If you haven’t given the show a whirl, I would love to encourage you to check out our most episode. In it we feature:

  • An interview with Sam Hulick who writes music for video games (Mass Effect, Baldur’s Gate) as well as some of the Ubuntu sounds.
  • We discuss the Mars One project and whether it absolutely madness or vague possibility.
  • We evaluate how Open Source app devs can make money, different approaches, and whether someone could support a family with it.
  • Part One of our 2014 predictions. We will review them at the end of the year to see how we did. Be sure to share your predictions too!

Go and download the show in either MP3 or Ogg format and subscribe to the podcast feeds!

We also have a new community forum that is starting to get into its groove too. The forum is based on Discourse, so is a pleasure to use, and a really nice community is forming. We would love to welcome you too!

In 2014 we want to grow the show, refine our format, and grow our community around the world. Our goal here is that Bad Voltage becomes the perfect combination of informative but really fun to listen to. I have no doubt that our format and approach will continue to improve with each show. We also want to grow an awesome, inclusive, and diverse community of listeners too. Our goal is that people associate the Bad Voltage community as a fun, like-minded set of folks who chat together, play together, collaborate together, and enjoy the show together.

Here’s to a fun year with Bad Voltage and we hope you come and be a part of it.

Categories: LUG Community Blogs