Half-baked ideas: View source button for Fedora

For more half-baked ideas, see my ideas tag.

I’ll mention first that this isn’t my idea, and it’s not new or original. OLPC already implemented a View Source button.

Why can’t we have the same for Fedora? This is how it would work …

The View Source button would hover in your task bar. When pressed it opens up this dialog:

View source dialog

Like xkill and xwininfo, pressing the “point at a window” button changes your mouse so you click on the program you want to view the source of. X sort of makes it possible to find out (with a bit of effort) which binary is behind each program (see for example the xprop command).

You do an rpm -qf on this binary (or use a yum search) to locate the source.

Use yumdownloader --source to download the source. Unpack it into a standard rpmbuild location, and open up the user’s preferred editor.

With experience, and many custom rules and heuristics, you can extend this idea. For example, if they pointed at a dialog box, search the source for strings from the dialog box to try to locate the exact lines of code.

Or have some debuginfo-like metadata packages which are generated when packages are built, to allow very precise file/line locations to be determined.

Combine the whole thing with LXR so we can browse source intuitively.

This is a great way to encourage contributions to Fedora and Free software in general, because I think it would really make code much more accessible to casual programmers, tinkerers and children. Even experienced programmers would find it useful when tracking down bugs in random applications.

About these ads

13 Comments

Filed under Uncategorized

13 responses to “Half-baked ideas: View source button for Fedora

  1. pankaj

    Wow a great idea. Wish someone would fully bake it :-)

  2. AnonymousCoward

    Great idea. I’d use it all the time.

  3. This is a great idea, but I don’t know of a way to get process information from a window. xwininfo and xwinprop display most of the information that the X server knows about a window, but I don’t see information that can be tracked back to a process ID (even through connection information). Any ideas?

    • rich

      No, I don’t think it’s directly available. This program is going to involve a lot of special cases and heuristics.

      FWIW here is some random xprop output from a gnome-terminal:

      WM_WINDOW_ROLE(STRING) = "gnome-terminal-window-2306-1307612918-1258827193"
      _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 20413421
      _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
      _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1377bec
      WM_CLIENT_LEADER(WINDOW): window id # 0x1200001
      _NET_WM_PID(CARDINAL) = 2306
      WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
      WM_CLIENT_MACHINE(STRING) = "trick.home.annexia.org"
      WM_NORMAL_HINTS(WM_SIZE_HINTS):
                      program specified minimum size: 48 by 36
                      program specified resize increment: 8 by 17
                      program specified base size: 16 by 2
                      window gravity: NorthWest
      WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
      WM_CLASS(STRING) = "gnome-terminal", "Gnome-terminal"
      WM_ICON_NAME(STRING) = "rjones@trick:~"
      _NET_WM_ICON_NAME(UTF8_STRING) = 0x72, 0x6a, 0x6f, 0x6e, 0x65, 0x73, 0x40, 0x74, 0x72, 0x69, 0x63, 0x6b, 0x3a, 0x7e
      WM_NAME(STRING) = "rjones@trick:~"
      _NET_WM_NAME(UTF8_STRING) = 0x72, 0x6a, 0x6f, 0x6e, 0x65, 0x73, 0x40, 0x74, 0x72, 0x69, 0x63, 0x6b, 0x3a, 0x7e
      
  4. This is a neat idea for encouraging more people to prowl around code, though I don’t think the mechanism is quite in place to find the exact location of /upstream/ source, which is *usually* what you want to look at, not the source of what is packaged if you want to contribute to the package. If someone creates a patch based on an old version, the likelihood is high that it would not be applicable.

    • rich

      Michael, I think there are arguments both ways. For contributing, certainly the uptream package is what you want to be looking at. On the other hand to discover the causes of bugs, you really need to see the code after any distro patches have been applied.

      Fedora is in a good position here with our usual stance on reducing the number of ways we differ from upstream.

      • Yeah, I was thinking more as in upstream being some few versions back, most likely, rather than patched.

        Definitely not a reason to keep from doing it… I know I *would* use that to explore more random codebases if it was just a click away.

  5. This tool could provide a choice of actions (perhaps in a checklist, so you could select multiple ones):

    (1) Take me to a code browser (such as LXR or the upcoming DXR)

    (2) Take me to the web page for this project (from the URL field in the package)

    (3) Get the .src.rpm for this package (like yumdownloader –source foo; rpm -i foo*src.rpm)

    (4) Take me to the pkgdb page for this package

    (5) Do a bugzilla search for all bugs on this package (e.g., so I can see if my RFE is already created)

  6. Pingback: La tecla «Mostrar el código fuente» | Bitelia

  7. Pingback: fedpkg recipes | Richard WM Jones

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s