GTK+ resolution independence

[Avatar] [info]dannipenguin
Previous Entry Add to Memories Tell a Friend Next Entry
I've begun looking at David Z's resolution independence work for GTK+. I imported it into a real GTK+ git repo (from his old git-svn repo) and have rebased it against the latest GTK+.

It mostly works, but it looks like there are a few things that have bitrotten in subtle ways that I need to track down.

For those who want to play along, here's the repo.

wheel in motion
wheels are in motion
Tags: ,
Posted 28/4/09 15:48 — 10 comments

Comments

From:(Anonymous)
Date:2009-04-28 08:33 (UTC)
(Link)
Any reason for rebasing against latest GTK rather than just merging with the latest code?

Unless you test every revision that you rebase, you're effectively changing code that David tested into untested code. Is it really that bad to recognise that the code was developed against an older version of GTK?
From:[info]zharradan
Date:2009-04-28 11:43 (UTC)
(Link)
It's sad to look at the original bugzilla for stuff like this and see it just rotting because nobody's interested in reviewing it :( (not that I'm helping by complaining, either)
From:[info]dannipenguin
Date:2009-04-28 12:27 (UTC)
(Link)
Yeah, there is quite a bit of this. I'm not entirely sure how to avoid it.

You've got a bit of code that requires quite a specialised bit of knowledge to work on that has something that prevents it being merged. Patches and branches can easily rot while they're waiting for someone to review them, dust them off, get it merged, etc.

Fancy VCS tools don't really help either. If someone fundamentally refactors the mainline, you're up the creek, regardless of how smart your VCS tool is. The only solution I'm aware of is good planning and good management; which is not always achievable.
From:(Anonymous)
Date:2009-08-20 23:52 (UTC)

git

(Link)
if the branch as it is now is easy to checkout, test and/or merge to current master, that is a good step in the right direction.

How is this going now? This is important future technology!
From:(Anonymous)
Date:2009-04-28 12:01 (UTC)

Conservative approach

(Link)
About possible breakage, I think the Linux kernel has appropriate insights.
(1) Write the code so that you can switch back and forth between stable and experimental through appropriate compile time options.
(2) Refactor existing code and new code so that they look the same so maintenance is simpler.

If done correctly, breakage should not be a concern.
From:(Anonymous)
Date:2009-04-28 12:40 (UTC)

Important Work

(Link)
Davyd,

This is very important work. Imagine the use case for someone using their 1080p TV from the couch.

--Rob
From:[info]dannipenguin
Date:2009-04-28 12:46 (UTC)

Re: Important Work

(Link)
I'm afraid I'm going to need you to send me one of these TVs for testing.
From:(Anonymous)
Date:2009-04-28 20:12 (UTC)

Re: Important Work

(Link)
I have been laughing all day over this comment. Thanks.
From:[info]schmexygeek
Date:2009-04-28 12:45 (UTC)

Great

(Link)
I was thinking you'd jumped off the face of the gnome planet and weren't working on gnomey stuff davyd. That being said, some of your comments are still hysterical. (you can politely go eat a big bag of ...).

Keep on making gtk a platform worthy of continued use.
From:(Anonymous)
Date:2009-04-28 21:10 (UTC)

I got a 1680x1050 15 inch LCD laptop screen

(Link)
...that just craves for this. wonderful stuff!
Post Comment
© 2002–2009, Danielle Madeley. Some rights reserved.
Creative Commons License