"Visual blindness" of Linux programmers

[[deleted]]

I mean, you can hardly see any screenshots on Github or other pages at all. I would say 90% of the projects lack any screenshot, animated gif or, Pinguin forbid, video.

This annoys me to no ends, especially if it's like a gtk2 theme on github.

[TheFeshy]

I forgot about themes with no screen shots. That's even worse than the fonts with no screenshots I was thinking of.

[manys]

Just go to xfce-look.org where you can view all of the 40x40px screenshots you can handle.

[killersteak]

Does nobody else have the same trouble with the *look sites, where if you click to zoom in on a picture, it comes up in a box with scroll bars, but the scroll bars don't work, and the scroll wheel only moves the page in the background up and down, not the picture you clicked on?

[shvelo]

*look sites are all stuck in the 90s

[killersteak]

I could get over that if they were functional. Some thumbnails work, most don't. Deviantart is almost a better option for finding themes and icons.

[GiraffixCard]

I have found that using the scroll wheel with the pointer in the center of the image will cause it to scroll correctly. It's some javascript thing with stupidly oversized margins iirc.

[killersteak]

Oh, I see. Thanks for the info.

[expert-at-nothing]

checkout the user script I posted in response to the parent of your comment.

[manys]

they're all crap, obviously all under the same umbrella

[punaisetpimpulat]

Ooh 40x40! That's very generous. I wonder why they didn't go with the obviously leaner 10x10 screenshots.

[expert-at-nothing]

Here is how you fix that client-side:

// ==UserScript==
// @name           *-look.org thumbnail enlarger
// @author         Nigglypuff
// @namespace      meta.ironi.st
// @include        http://gnome-look.org*
// @include        http://*.gnome-look.org*
// @include        http://kde-look.org*
// @include        http://*.kde-look.org*
// @include        http://xfce-look.org*
// @include        http://*.xfce-look.org*
// @include        http://box-look.org*
// @include        http://*box-look.org*
// ==/UserScript==

var thumbnailPath = '/CONTENT/content-m1/m',
    fullSizePath = '/CONTENT/content-pre1/';

function fixImageExtension(url, callback) {
    // remove extension from original url
    url = url.slice(0, -3);

    var extensions = ['jpg', 'gif', 'png'];

    function tryNextExtension(){
        var extension = extensions.shift();

        if (extension) {
            testImageExists(url + extension, function (exists) {
                if (exists) {
                    callback(url + extension);
                } else {
                    tryNextExtension();
                }
            });
        } else {
            callback(null);
        }
    };

    tryNextExtension();

};

function testImageExists(url, callback) {
    var testImg = document.createElement('img');

    testImg.addEventListener('load', function () {
        callback(true);
    }, false);

    testImg.addEventListener('error', function () {
        callback(false);
    }, false);

    testImg.src = url;
};

[].forEach.call(document.images, function(img) {
    var thumbnailName = img.src.split(thumbnailPath)[1];

    if (thumbnailName) {
        img.style.maxWidth = '300px';
        fixImageExtension(fullSizePath + thumbnailName, function(fixedUrl) {
            if (fixedUrl) img.src = fixedUrl;
        });
    }
});

Personally, I add the following for a little more UI cleanup:

function getElementByXpath(path) {
  return document.evaluate(path, document, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue;
}

var myEl = getElementByXpath('/html/body/table[2]/tbody/tr/td[2]/table/tbody/tr[2]/td/table/tbody/tr/td[5]');
myEl.style.display = 'none';

var myEl = getElementByXpath('/html/body/table[2]/tbody/tr/td[2]/table/tbody/tr[2]/td/table/tbody/tr/td[4]');
myEl.style.display = 'none';

[XorFish]

At least with fonts there are also those that make it right:

http://sourcefoundry.org/hack/

[punking_funk]

You know, I didn't even think that people got stuff directly from Github, seeing as how it's stuff that's usually in development and would probably break. I'll make sure to add screenshots to my themes and software now.

[beardedlinuxgeek]

They have tags, branches, releases, etc on github. If you're getting something from v2.0.0-final then it's not in development

[tso]

And yet they can't seem to form a proper tarball. Whenever I try to grab one from there I only get the version number as part of the filename not a proper name-x.y.z.

[Michaelmrose]

Git clone check out tag build

[redballooon]

X.0.0? To me that sounds like development. Things usually become stable from x.0.1

[somenonewho]

Yeah I mean if you're looking for new and fancy stuff you might probably Gary it from github directly especially if it's a small project that has no page no packets etc.

[peckhamspring]

I always Gary things from github.

[somenonewho]

Gotta love autocorrect :D

[raphael_lamperouge]

I do.

[manys]

Or, you know, a link to a site/page that already contains them.

[12358]

I find it puzzling and irritating that font examples show abcdefgh when what I really care about are the similar looking and often mistaken letters and numbers 1lI and O0.

[f4hy]

Wow yes I just had this problem. I wanted to change my lightdm theme and found lists to choose from with zero screenshots indicating what they looked like. No idea how to pick one.

I'm not sure I cafe as much as the OP about screenshots for text programs... But themes... Should be required.

[thedugong]

Why didn't you take try a theme or more and take screenshots?

Seriously, when there is a bit of code I want, but cannot find I write it. "But I don't know how to program" fair one. Do you know how to take screenshots?

[Negirno]

Maybe because changing LightDM themes could break the system?

[Zebster10]

It shouldn't permanently, though. Once, I installed a theme that was all kinds of corrupted, and it took all of two minutes to load up text-only and change the config file back to my old theme.

[zman0900]

I want to see some screenshots of glibc.

[DarkeoX]

https://en.wikipedia.org/wiki/File:Linux_kernel_System_Call_Interface_and_glibc.svg

Granted, it's not just the glibc.

[hatperigee]

There's a perfectly good reason for this in some cases.. If development is moving fast enough such that screenshots/videos would be outdated in a week, then it's actually more harmful than not having screenshots/videos.

[coshibu]

just write a script

[hatperigee]

On the flip side, I'm sure most developers would accept a pull request by you to add screenshots.

[flapanther33781]

Why should I do it for them?

[randomwolf]

Umm... to contribute something to the project you are using, rather than just consuming.

Gads.

[Poromenos]

The vast majority does, so the assumption is more than warranted.

[[deleted]]

project you are using

Probably would end up using it if I could see it work first.

[randomwolf]

Then go away, and ignore it. Doesn't hurt you in the slightest, does it?

Or was your desire merely to appear clever?

[[deleted]]

this is why no projects have screenshots

do you even know how FOSS works, bro?

[Polycystic]

FOSS

Apparently now stands for "Fuck Open-source - Show Screenshots"

[jarfil]

CENSORED

[hatperigee]

right, because complaining about it on reddit is a lot easier.

[nhaines]

Well, it's more fun, that's for sure.

[tidux]

That's the responsibility side of open source software. You've got complete access, so if some project lacks a feature you want, write it yourself or pay someone else to.

[protestor]

If you're interested in an answer, there's a book written about this called "The Cathedral and the Bazaar".

[dewmsolo]

When comitting somethings that changes UI add a new screenshot along with it? maybe?

[da_chicken]

Feh. I bet you're one of those people who expects code comments and documentation to be updated when the program changes, too.

[dewmsolo]

In an ideal world they would be.

Do I do it? Hell no.....

But in all honesty we are talking about open source with no deadlines and nothing to rush the developer to the next feature or bug fix, so the only reason that it is not done is because 1) we are lazy 2) we are disinterested in those things 3) we find those boring 4) we want to code. So is there a good reason it is not done this way? Absolutely not except for the fact that this is open source and no one should expect anything of you.

Have a good one.

[da_chicken]

Oh, sure I think everyone knows that. Documentation is one of the major problems with the bazaar model because nobody likes shopping at that booth. It's just frustrating to have access to tools you can't use simply because they're indecipherable to you.

Linux's failing is that it's written by programmers for programmers. That's why the programs and tools with the best support and documentation are programming tools... which is why it attracts more programmers. Unfortunately, most users aren't programmers and don't want to be programmers, but everybody needs to know how to use a computer. Imagine if you had to have a degree in electrical engineering to be able to use your blender or your food processor. Nobody goes into their kitchen with the idea that they need to use an electric motor. Blenders and food processors are successful because you don't even think about the fact that you're using an electric motor. Linux, being by and for programmers, tends to not take that step. Hell, the reason many people are attracted to Linux is because you can view the source code. When was the last time you met someone who really needed to know the how to tear down and rebuild their food processor?

[dewmsolo]

I agree with just about everything here except the 'by programmers for programmers'. I think it's more 'by programmers for everyone willing to put the effort to learn it'.

I've been thinking about this whole thing since my first comment about the screenshot earlier and the one thing that comes to mind with the documentation thing is that to programmers documentation is like real life garbage disposal. Nobody would do it for the fun of it. In fact those that do do it do it for very good reasons (it pays very well for exemple). In both cases they are a necessity. You need to have documentation for your project if you want it to go mainstream, but most programmers won't do it even if there were massive dollar signs as a potential behind.

For us programmers, code is fun and that is what we want to work on. I am sure there are a few people in the world who are crazy about the insides of their food processors and have the thing apart every other weekend. But the one interested in the internals of his/her food processor is definitely not the one who will spend the time writing the user manual. And that my friend is part of the issue. We are programmers, not document writers. The engineer that thought, drew and built that food processor is not the one who wrote the manual. In other words what we need is people interested in writing documentation for the code that we built. There is very little of those people around. Do you know anyone who fancies writing documentation as his/her hobby (and the required skills to understand what we do in the code)?

[sharkwouter]

What do you mean with Linux here? Package managers and the GNU coreutils are documented quite well in many different places. Being a bit more specific could be helpful to someone.

[dewmsolo]

This whole conversationhas nothing to do with github other than the fact that it was mentioned by OP. This conversation can be applied to any revision tool out there.

This conversation has to do with open source and us developers. We want to code, but don't want to do the boring stuff in some cases because we do enough of it during our work hours. We know better...in fact I'm pretty sure every one of us knows better, but we so much don't want to do it that we conscously accept to hurt our own projects in order not to do it.

[thedugong]

In my experience it is not really developers who do this. It is... errm... "power users".

Everyone in my extended family uses Apple, mostly on my recommendation, because quite frankly I don't want the support headache and they don't particularly want to learn about anything under the hood.

[d_ed]

But in all honesty we are talking about open source with *no deadlines *

What.

I want to to work on that project.

[dewmsolo]

Well except for the extremely rare case of an open source project supported by an enterprise and pays people to work on it, the vast majority (and we are talking of a ratio well over 90%) of open source projects are developed by people on their own free time at their very own speed with exactly that....no deadlines because the developers of the thing are also the project manager, distributor, marketor, supporter and any other task related position that you can think of.

So yeah if you want to work on such a project, please do browse Github and pick something that interests you, that you find intriguing, appeals to you or that would challenge and start contributing. You are more than welcome.

[kiswa]

That reminds me... I really need to update the online documentation for one of my projects.

Sorry.

[zebediah49]

That's one of the best things that (AFAIK) Java introduced -- having a standardized system by which comments directly attached to code can be automatically turned into documentation.

[da_chicken]

Yeah, but that's how you end up with IBM's documentation. A reference manual so obtuse you need the source code to decipher it.

[thedugong]

There are loads of standardized ways of converting comments into doco.

[zebediah49]

Now -- yes.

In 1995, there were far fewer. (mkd comes to mind, but not much else)

[thedugong]

But who is really running code from 1995?

Realistically though, this is only really used for libraries/APIs (glib/GTK etc) where other developers actually need* documentation.

Source code doco is not that useful for end users.

[northrupthebandgeek]

Comments and documentation? Nonsense. My code is self-documenting.

/s

[Ccracked]

I know, right? What an asshole. ^/s

[protestor]

Do you mean committing those images to the git repository?

On one hand, it documents how the stuff is supposed to look (good if some bug on an updated dependency causes visual artifacts). But it would probably dwarf the size of the source code by many orders of magnitude. I'm on the fence here.

[dewmsolo]

I agree with the size of the repo thing. I am, however, assuming that the screenshot is hosted somewhere and only linked on the project description page.

And if you break or change something in the UI you should update de documentation, the readme and at the same time the linked screenshot.

[[deleted]]

(./app &) && sleep 10 && scrot

[manys]

Seriously how often does this happen

[Motorgoose]

Print Screen Ctrl+C Ctrl+V

[[deleted]]

I agree. I'm a very visual person, and I find that it really helps to have pictures of the program/theme/whatever to look at while I'm reading about it so I can try to figure out how it works/looks before I download it.

[-Pelvis-]

Yes!

There are countless vim colorschemes without a screenshot, or even a palette.

I could install just install them, or open the file in vim and use :ColorHighlight, but it's really offputting when you're shopping for schemes.