Thursday, 10 September 2009

A Thing I love: #1 Musical Genre

I love musical genres.

Every time I hear a band boasting of how they can't be categorised I groan. Musical genres are no longer something to rail against, if they ever were, they are a creative stimulus and no one expects you to fit into just one.

Monday, 31 August 2009

The BBC is too awesome for cake

...and I like cake. I'm not going to attempt to be coherent or tackle all of the issues, that would take an essay and this is just a midiblogsplurge.

Anyone who claims that the BBC is an extension of the state has (a) not understood the structure of the organisation and (b) never listened critically to it's output.

The BBC aims to be politically impartial. My impression is that it holds those with power (or "in power") under more scrutiny than other parties, individuals or organisations, which is the way it should be. BBC interviews are the toughest, since it is the most respected forum of public political debate and so does not need to court interviewees with favourable treatment.

For those who worry about the dangers of so much power in a single organisation, the governance of the BBC is set up specifically to counter any such dangers. It has a mission to benefit it's viewers. It is not working in the interests of profit or of any individual or organisation.

Seriously, it's great idea to keep an eye on the BBC and hold it firmly to account but to-date the concerns have been pretty minor. The BBC is really a beacon of virtue in a world of quite scary media organisations. It is set up with a public service mission and that's what it does; what am I supposed to be scared of?

Anyone who complains that it is unfair that the BBC is funded by the licence fee. We aren't handing out cake at a birthday party! Why should it be "fair"? What matters is that we have a healthy broadcast media. I might be concerned if the BBC made it impossible for any other broadcasters to operate but I don't see any reason why all broadcasters must operate under the same set of conditions. BBC is different to ITV and Five which are different again from Channel 4. For all the griping the UK has a very healthy and creative TV and radio ecosystem.

Finally the output of the BBC is tremendous. I doubt any other organisation could have created The Blue Planet. That is just one example of the many cultural masterpieces the organisation has and will continue to create. The BBC sponsors musicians and cultural events and development of all kinds. It is free to criticise itself and often does. Since the BBC is not "working for the BBC" there is no hesitation in broadcasting criticism of the BBC on the BBC, whether that be in the news, discussion programmes, in the Feedback programme on radio 4 or in the form of incidental content on other programmes such as comedy programmes mocking BBC output or organisation.

I must stop there, I could go on indefinitely if I allowed myself to enumerate all of the great stuff the BBC produces.

Tuesday, 3 February 2009

a crappy schematic

Here it is, this isn't a proper mock-up but it should give you an idea what I mean:



The point is that the pop-out looks and acts just like the taskbar. Same highlighting, draggable items etc.

Tuesday, 9 December 2008

KRunner and "the new command interface"

I use KRunner for launching most of my apps, it's very flexible when it comes to reading user input but it needs to match this with richer feedback to the user if it is to fulfil it's potential and be more than just an application launcher.

La Nouvelle Interface de Commande has been popping up all over the place. And it's not a regression to terminal computing; it's not about remembering lots of commands and syntax. It's about you starting typing what you want and your desktop letting you know what it thinks you might mean, you narrowing down your description and reaching the desired action in a hand-full of keystrokes. The key here is constant feedback: parsing, matching and displaying information as you type.

Because KRunner uses a plug-in architecture and gives the individual plug-ins ("runners") complete control in parsing the input, it allows them to perform tasks such as spell-checking or evaluating arithmetic expressions as well as simply executing commands. However when it comes to displaying information, all a runner can do is add an item to the list of actions, which in practise means an icon and about 10-characters of visible text. Lets have a look:



This is OK if you are simply launching applications (and KRunner is foremostly an application launcher) but not great for anything else. Lets see how another app, actually a firefox plugin, Ubiquity, makes it much easier for the user to find what he wants.

Ubiquity uses scripted "commands" rather than compiled plug-ins, but the principle is similar.

Start typing and a list of matching operations appear:
Some points to note: The first section contains a list of commands with syntax hints which make it easy for me to input the correct information, the second section contains output from the highlighted command, in many cases this information is sufficient and there is no need to "execute" the command at all.

I can use the arrow keys to navigate the list of commands but it is usually easier simply to narrow down my search by typing a couple more characters.

Now that I have the command I wanted I can start typing an argument. Here returning a list of results from wikipedia.

Ubiquity can do all sorts of things.

KRunner has the potential to be more powerful than this but it needs richer feedback. How to integrate this into KRunner is not obvious. My own thoughts for now summarised below.

The scheme I envisage is the following: Runners would publish matching commands to KRunner as they do now, however the selected command item would then be communicated back to it's parent runner which would then be able to publish further information to KRunner. A possible format for this further information is to allow a single JSON (allowing the definition of lists, tables etc without specific layout markup) information widget and/or a list of JSON formatted sub-command widgets (or nothing at all). OK So to the mock-ups:


More space for text makes identifying commands easier and allows for those vital syntax hints which allow the user efficiently execute the intended command. Hints in the top-right corner of tthe command widgets tell you which runner produced them.


Some "command items" may display an information widget when they are selected...


...or may display a list of sub-command widgets. Here the search command performs an incremental search and displays a list of results in a table form. Each of the results is a runnable command.


Unlike Ubiquity, KRunner is not limited to using keywords to activate commands, here, for longer text entries activate the search and spell runners without the use of a keyword.


A command can display an information widget and a list of sub-command widgets at the same time.


Another use of the both information and sub-command widgets.


Filtering down the sub-commands.


mmmm Akonadi




Well there you go, it's a starting point for discussion at least. Comments welcome.

Wednesday, 3 December 2008

Wednesday, 4 June 2008

glogger

glogger, it's not blogger but I like it

Monday, 2 June 2008

KWin window groups

The more I think about it the stranger it seems that modern window managers can only "manage" one window at a time. Usually when dealing with apps that beget multiple windows it makes much more sense to manage them not as individual windows but as a group. Sometimes it is even desirable for several applications or different instances of the same application to behave as one within your window manager. The Compiz plugin "group and tab" tries to solve this problem but, not being built-in to the window-manager, it doesn't quite deliver the functionality.

So why is this? I have set about thinking how useful window-group functionality might be integrated into KWin. N.B. I'm not going to say anything here about tabbed windows.

Before I go any further, I'd like to make it clear that I am no kind of expert, my hope with this post is to get some feedback, to change what I've got wrong, fill in the blanks and hopefully come up with a workable proposal.

So to it, and lets start with the basics: What are my design principles? Window grouping should
  1. not interfere with current functionality
  2. have a simple, intuitive and transparent interface/behaviour
  3. be fully integrated into window manager (i.e. not a compositor plugin)
  4. be work-saving
OK, and what essential functionality should it provide?
  1. The ability to select and group multiple windows
  2. To keep track of these groups
  3. The ability to "act on" groups of windows, for example moving, closing or minimising the whole group.

1. group semantics


I want to keep this as simple as possible, at least unless and until use suggests the need for something more sophisticated. A window may belong to one group or no groups at all. There should be only level of grouping (i.e. you cannot have groups of groups).

These simple semantics facilitate the interface that I will describe below.

2. interface


There are four core components to managing grouped windows
  1. selecting and grouping windows
  2. performing actions (close, move, shade, etc.) on groups
  3. performing actions on single windows
  4. persistent settings and configuration

2.1 selecting groups: Point 1 can be solved by the usual point and click process: hold [GSMK] (group-selection modifier key or key combination) and click on windows to select and press, say, [GSMK] + "g" to group the selected windows. We can also add options to the window operations menu (the one that comes up when you right-click in the titlebar), more on that later.

Transient groups: While a set of windows is selected it should be possible to act on them as if they were grouped without actually grouping them.

2.2 acting on windows and groups: In order to perform actions on single windows and groups of windows I suggest using the existing interfaces (buttons on the toolbar, window operations menu, key shortcuts) but if the window is a member of a group, by default apply the actions to the group rather than the single window. We then use another modifier key(combo), which we'll call [IGMK] (ignore-groups modifier key) which allows the user to move, resize etc. the window individually as though it were not a member of a group.

In section 3 we'll look at what it means to apply the actions [close, move, no border, to desktop n, minimise/restore, keep above, keep below, send to all desktops, resize, maximise, shade] to a group but first to the window operations menu.

We could extend the current window operations menu to include all of the window-group functions but it makes more sense to have two different menus. In the same way that minimising a grouped window will minimise the whole group, right-clicking in the titlebar of a grouped window will open the window-group operations menu (and holding [IGMK] allows the user to access the single-window menu).

The window-group operations menu might look something like this:

::::::: This window
:::::::
::::::: Advanced >>
::::::: ::::::: Keep above
::::::: ::::::: Keep below
::::::: ::::::: Fullscreen
::::::: ::::::: No boarder
::::::: ::::::: Group shortcuts
::::::: ::::::: Special group settings
::::::: ::::::: Special application settings
:::::::
::::::: To desktop >>
::::::: ::::::: All desktops
::::::: ::::::: Dektop 1
::::::: ::::::: Dektop 2
::::::: ::::::: ...
:::::::
::::::: Move
::::::: Minimise
::::::: Maximise
::::::: Shade
:::::::
::::::: Group with... >>
::::::: ::::::: lists all groups and single windows that can be added
:::::::
::::::: Remove window from group (removes this window from the group)
::::::: Ungroup (disbands whole group)
:::::::
::::::: Configure group behaviour...
:::::::
::::::: Close

This is basically the same as the standard menu except (1) All of the actions refer to the group, not the single window. (2) New menu item, "this window", which brings up the standard window operations menu. (3) No "fullscreen" menu item. (4) No "special application settings" menu item. (5) A section containing options for merging/ungrouping windows etc. Note that the menu item "group with" should also be included in the single-window KWin menu.

2.3 persistent settings and configuration: Here I am entering the realm of guesswork so I will be brief. I don't know about the workings of X-windows and KWin so I can't really speculate too much about this. One useful feature would be the ability to make all windows created by a given process automatically be grouped, to make this the default behaviour and to set up exceptions. We'd also want to facilitate the interaction of other apps and applets, for example the taskbar and the box-switcher effect, with window groups.

3. acting on the group: what does it mean?


This is largely a matter of deciding the balance between the group as an entity that has its own state and a simple service for routing commands to its child windows.

For example for a binary state like 'keep above' a command routing approach would simply allow the user to either change the state of all windows in the group to 'keep above' or change the state of all windows in the group to 'don't keep above'. A group-with-state approach would allow the user to set the state of the group to, for example "keep all windows in the group on top", "dont keep any of the windows in the group on top" or "apply each window's own keep-on-top settings" without modifying the keep-on-top settings of each window.

While the second approach is more powerful, it is also more cumbersome and harder for the user to grasp. In particular there is a tendency for there to be a certain amount of 'hidden state' e.g. the user cannot tell immediately whether a group of windows are on top because of the group settings or because of the individual window settings. For this reason I suggest the first, 'command router' approach, this also has the benefit of being much simpler to implement.

I have divided the window manager actions into groups according to how they should be dealt with when applied to a group:

apply to each window:
The following actions should simply be applied to each window in the group
  • close
  • move
  • no border
  • to desktop n
  • minimise
binary state:
These actions should also be applied to each window, it makes more sense for the first click to synchronise the state of all windows
(e.g. if some windows are minimised and some are not, to restore all windows with the first click) rather than to toggle the state of all windows.
  • toggle minimise/restore
  • keep above
  • keep below
  • send to all desktops
  • shade*
whole group - geometry:
These actions are a little more complicated. It makes sense to keep the relative geometry of the whole group fixed when resizing it and to "shade" a group into a single titlebar.
  • resize
  • maximise
  • shade*
not available:
The following actions cannot be applied to the whole group and should be applied to the single window
.
  • fullscreen
  • "special window settings"/"application settings" - replaced by "group settings"
* from the user's point of view it would make most sense if 'shade group' collapsed all windows into one bar, however this might be tricky to implement.

new functions:
New operations for managing the grouping of windows, these are self-explanatory.
  • group with...
  • remove window from group
  • ungroup (disband group)
4. graphical feedback

The problems here don't appear to be huge but, again, not knowing much about the practicalities I can't say how easy they will be to solve. The following is the situation as I see it.

Despite trying to design a window grouping functionality that is as simple and transparent as possible, it is desirable to have some feedback to the user to communicate some information, namely:
  1. Which windows are currently selected
  2. Is the current window part of a group and which other windows are part of that group
1 and 2 can be seen as part of the same problem. We need only to be able to highlight one set of windows. While a set of windows are selected, highlight that set, else if the active window belongs to a group highlight that group. Holding [IGMK] should turn off the group highlighting since we are telling KWin to ignore grouping.

We would like to be able to use existing window decorators without adding functionality to deal with groups. It would also be rather hackinsh and ugly to try to layer graphical feedback on top of the window manager. So what is the best way to proceed?

5. summary of implementation:

  1. Data structures for storing information about groups, ability to query whether a window belongs to a group, which group etc.
  2. Functions to "act on group" for maximise, minimise, close, open, move etc.
  3. Select and group multiple windows.
  4. Alternate right-click window management menu for group actions.
  5. Graphical highlighting of groups and selected windows.
  6. A KControl module for editing global settings for window groups such as "auto-group windows belonging to a single app" and choosing the shortcut keys.

EDIT: It seems a feature-request exists for this on KDE bug tracker. The feature request doesn't go into details but a reply does note that the feature already exists in Blackbox. Does anyone have experience of this?