Comments for …for the adult in you

Comment on Moving to GSettings by Milan Bouchet-Valat

Milan Bouchet-Valat — Sun, 26 Sep 2010 15:08:40 +0000

As I noted on the bug, we can potentially choose option (3), which is the one I implemented in the patch, and ensure migration of old settings if we’re motivated enough to write a script for that. There’s already a migration tool (gsettings-data-convert) that could be improved to be able to merge two keys into a single list.

Comment on Moving to GSettings by Simon

Simon — Sun, 26 Sep 2010 03:07:01 +0000

I think the migration to GSettings should be seen as the opportunity to do things right, regardless of backward compatibility. Given that, option 3 seems to be the sensible choice – older versions can keep the complexity in talking to GConf, while newer version can throw it away. The user may have to set up their keybindings again, but that’s a one-off event at worst…

Comment on Moving to GSettings by Spider

Spider — Sat, 25 Sep 2010 11:04:33 +0000

I’d say that making every setting a list of strings is the right way to do. Since we are already migrating, might as well migrate to the scalable.

And please, do not make a list of lists in a single setting, it’s _Hell_ to work with, unportable, and is just as likely to break in the future.

For example of how not to do it, look at evolution, storing settings as a string of xml inside the gconf keys. Please avoid that kind of crack.

Comment on Moving to GSettings by John Stowers

John Stowers — Fri, 24 Sep 2010 21:27:04 +0000

(3) Sounds the most sensible to me.

It would also be great if you could blog about the metacity policy of porting/applying patches that land in Mutter. In addition to some interesting looking bug fixes, some nice stuff has gone in there recently, that I would like to use in metacity;
* side-by-side tiling/aero snap
* cairo/gtk3 compatibility
* allow breaking out from tiling during a mouse resize (i.e. alt resize on tiled windows too)

Comment on Moving to GSettings by Patryk "patrys" Zawadzki

Patryk "patrys" Zawadzki — Fri, 24 Sep 2010 17:17:46 +0000

(1) sounds like voluntarily breaking stuff at the very point when it can be fixed.
(2) sounds like fixing the wrong thing (getting rid of the problem by removing a feature that introduced it).
(3) seems to be a solution
(4) smells like that database table you saw once. It only had two columns, one for ID and one for anything serializable to XML.

Comment on Come calm content serene and sweet by DeeJay1

DeeJay1 — Tue, 01 Jun 2010 15:11:37 +0000

Window matching by position ? (hint geouri and remote shells ;)

Comment on The order of windows in alt-tab by frizzle

frizzle — Fri, 28 May 2010 13:57:33 +0000

wouldn’t it make sense to take the thought even further and to create an overlayed widget-layer-like interface for application switching upon alt-tab?

Comment on Are there any SDL people out there? by Thomas Thurman

Thomas Thurman — Fri, 21 May 2010 01:41:07 +0000

Woot. Thanks.

Comment on Are there any SDL people out there? by Dave Ahlswede

Dave Ahlswede — Fri, 21 May 2010 01:15:18 +0000

Original reporter here. It works fine now. (I couldn’t tell you at what point it did; i’ve used compiz for some time now, only having pulled up metacity to test this)

Comment on Justified and ancient by shlomil

shlomil — Mon, 17 May 2010 09:46:25 +0000

As RTL user I would vote for option 3 but there may be some issues with this option:

Suppose the theme contains image that has some “water-marked” text in the backgroud or some kind of assymetrical Logo. displaying such image as mirrored would look funny.
Another example: In a Theme that displays the face of Cindy Crawford in the background – her mole would appear on the wrong side!

Best solution IMO is to provide theme authors with the ability control it (so they can select to provide alternative images for RTL theme or just use a plain flipping algorithm)

Until that happen, I think I would rather the current patch to be committed (option 2). I think in most common cases it will be more useable this way.