AuthorTopic: Hackable pixel editors?  (Read 10638 times)

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #10 on: August 03, 2017, 01:27:26 pm
Not sure where this thread is going, but I guess we may as well have some conversation.



I've dealt with plenty of platform specific bugs. If you rely on multi-platform frameworks that abstract from specific hosts, you can avoid a lot of this,
but even so there can still be problems. At any case, I guess that the overall number of bugs in the actual program core is usually higher, though.

Your program is of course embedded in a greater host system.
And each host may have different logic behaviour, in two ways:

Either it is obviously different in the interface.
So the part of your code that deals only with that host may have bugs that the software doesn't have on another host.

Or there are unspecified differences in the behaviour of the host implementation underneath.
An example I encountered were graphics driver problems I had on one system, that I didn't have on another.
The code was the same for both, and although valid in principle, needed additional provisions on the other.

I still have to deal with some such issues. Unfortunately, this time with the open source drivers on Linux.



There is a lot of things I like about open source projects, even though I don't see in it the greatest solution to every problem.



The Open Source movement is sometimes percieved as counter to proprietary industry.
But much more often it's complementary forces of something greater.

In reality, the industry has been very supportive to Open Source projects.
Many of the best projects have a good involvement with various companies.

Linux would not be where it is now, without it.
Some might say, it should be more, so they're bad.
But in many ways it's been plenty enough in my opinion.

The reason is simple: there is a need for Open Standards.
Open source software is part of the industry infrastructure.
At least with that code, you can bet it works pretty well.

However, agreement and compromise among many people is difficult to achieve,
and the need for that in a greater community project can also stifle development.
So it's not about what is the ultimate development pradigm.

Cooperative behaviour is not exclusive to just one side. And there are many ways of going about it.
At the same time, open source projects also have to compete for public interest, because it is voluntary.

And while this is great, that's also a challenge for Open Source development, as it is for anyone.
But it hits Open Source especially hard, because of its pronounced freedom, while limiting ownership.
This is not simply about greed. The question of ownership already starts with who directs the project which way.
And the often inconclusive answer to that has many difficult consequences.
The usual answer is forking development, so everyone can be happy in their own way.
But that too has caused many problems with splintered and weakened projects.

And that makes for weird contradictions. In theory, OS on average should be much more stable and save and service friendly, since anyone can look into it.
In practice it often isn't. Because not enough people are motivated to look into it, and there are big problems from a lack of accountable hierarchy structures.

So there have been several huge security holes that lasted more than a decade, and were a total embarrassment when discovered,
of a kind so bad you never saw happen on equivalent proprietary solutions in the first place.
Or terrible legacy constructs difficult to get rid of because of community politics.

The most important factors to good software is the combination of developer engagement with user feedback. That's the sort of Open that matters most.
And the idea of voluntary community service for the greater good is thousands of years old and was not invented by radical neckbeards on the internet.

Having said that, I'm glad these projects exist.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #11 on: August 03, 2017, 02:44:44 pm
I also have lots of experience with porting programs by now, and I want to say, at some point you just don't care "who is wrong and who is right" : You just want to find one acceptable way to bridge the differences, and move on to the next incompatibility.

For example one OS which can compile Grafx2 only provides a very old version of GCC, and won't compile code where variable declarations occur after instructions. I weighted the arguments :
- Are there many users ? no
- Is it the only thing preventing Grafx2 from being perfectly usable on that OS ? yes
- Is it a big change for Grafx2 ? No, because the MS-DOS code was made on Borland C where it was mandatory anyway
- Is it difficult to maintain this restriction from now on ? No, because with compiler option "-Wdeclaration-after-statement", all coders on all platforms can see immediately if an incompatibility appears, and they can fix it immediately.

And thus there was another easy port, and a few users which can use Grafx2 now, instead of having to wait for a more modern GCC.

Offline Crow

  • 0011
  • **
  • Posts: 647
  • Karma: +0/-0
  • Technicanimal
    • View Profile

Re: Hackable pixel editors?

Reply #12 on: August 03, 2017, 03:42:28 pm
There is no such thing as "Windows-specific" bugs.

What? :huh:
Discord: Ennea#9999

Offline 0xDB

  • 0011
  • **
  • Posts: 873
  • Karma: +0/-0
  • Dennis inter-is.
    • dennisbusch_de
    • http://pixeljoint.com/p/1287.htm
    • 0xdb
    • View Profile
    • 0xDB

Re: Hackable pixel editors?

Reply #13 on: August 03, 2017, 03:56:24 pm
at some point you just don't care "who is wrong and who is right" : You just want to find one acceptable way to bridge the differences, and move on to the next incompatibility
That. Also, the situation is rarely that binary that one may say Alice is completely right and Bob is completely wrong. No two developers are the same, everyone comes with different experience levels and different points of view(which can change over time with experience) onto a field that is highly complex and extremely few(if any at all) should be able to claim to have a full understanding of everything involved and who would be right with that claim at the same time. I don't think anyone like that exists or will ever exist.

From my (own) experience (used to act like that myself 20 years ago) and also from countless discussions with other developers, the one who claims to know it all, know it all better even is usually the one with the least experience and thus has the most limited, narrow-minded point of view, sitting so high on top of Mt. Stupid (see graphic in spoiler below) that they are looking down upon a thick layer of clouds, unable to see the vastness and the complexity of the whole field below that layer.


Happy on their mountain, they think they know the one true way, the one ultimate eternal truth, smoking on the Dunning Kruger pipe everyday. It's a powerful, glorious feeling and it's perfectly understandable if one wants to linger and keep that grandiose feeling of superiority. But... it is an illusion.

They should keep digging, should learn more facts, keep exploring, descend from that mountain, seek other mountains, wade through the endless swamps and seas and forests and wastes, stay humble, practice, learn, never assume to know everything except maybe the "fact" that there is always more to learn and that there are a million different ways to do things and a million different tools to take along the paths.

This concludes the zenny part of this post.

the practical part:
For playing with stuff which originated in the GNU/Linux world under Windows, it helps to install a largely POSIX compliant subsystem like MSYS2 or Cygwin.
Regarding GIMP in particular, MSYS2 appears to be the way to go: https://wiki.gimp.org/wiki/Hacking:Building/Windows

Peace.

Offline yrizoud

  • 0010
  • *
  • Posts: 330
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #14 on: August 03, 2017, 04:58:01 pm
My point was rather: you can argue all day long about "Vendor B should have adopted Vendor A's choice, and made his product compatible", or the opposite. It will have no effect on how you adapt your software to work on both situations.

The worst case I have in mind is browsers and the CSS standards for not blurring zoomed images. The problem has started, like, 10 years ago, and ALL browsers are guilty of doing stupid stuff, starting standards, implementing in betas, arguing with other browsers , changing the standard, removing the first implementation without providing the new one, etc.
The result ? Users don't understand why a browser fixes the problem (when web designer takes into account new version of one browser) then breaks again (when browser update removes it) etc. Web designers run in circles every time a browser changes behavior, and in the end, 10 years later, website have to implement 8 frigging CSS fixes to allow sharp zoom, and it still can't work on every browser. The one who loses is the user.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #15 on: August 03, 2017, 05:50:02 pm
The few moments you appreciate a monopoly setting standards. :p But yeah, I also think it's just part of life. Part of a coder's job. Dealing with different systems. So get used to it, painful as it may be. Many of these problems are pretty much unavoidable, no matter the paradigm, because that's just how humans do things. Unless someone makes it their business to bridge these differences for you with their middleware, engines, libraries, frameworks, etc. But even so, you could say Browser were meant to be like that with their standards, and see what chaos we got anyway. This is just what happens when you got all these people doing their thing. At some point you think about "how can we make something more interesting? How can we set ourselves apart from the others?" and there you go, doing things differently, "better". Kinda funny how this discussion meets with questions of Pixel Art definition. You could also describe that as a problem of standards. And just like artists seek to make something special, so do technicians. And then others have headaches how you can connect all that in one place.

Offline RAV

  • 0010
  • *
  • Posts: 293
  • Karma: +0/-0
    • View Profile
    • Blackbox Voxel Tool

Re: Hackable pixel editors?

Reply #16 on: August 03, 2017, 08:06:26 pm
But to specifically address a point I think you wanted to make most:
Even with the very best intentions of all parties for establishing a common standard,
there is a high likelyhood of things getting so messed up simply by mistake
and individual problems of execution, it may as well not be standard.

Plenty of examples, yeah. It again is a problem of scale, and we haven't fully figured this out yet.

Because this is not simply a problem of coding, altogether it's a fundemental problem of life.

We haven't really figured this shit out anywhere.

The attempt to create world wide standards that truly work without conflicts, may as well be the attempt to create god.

You shit flinging monkeys.


I don't even know what's worse. At least trying or not even bothering.

And is succeeding not our ultimate doom? The end of life's purpose.

To search. always search, struggle, with your own little life.

You have your peaceful standards when you meet your maker.

Just watch out that you didn't die because of boredom.

Since it's all just the same to you,

sitting there in silence,

until nothing's left,

to live for.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

Re: Hackable pixel editors?

Reply #17 on: August 04, 2017, 05:31:32 am
My point was rather: you can argue all day long about "Vendor B should have adopted Vendor A's choice, and made his product compatible", or the opposite. It will have no effect on how you adapt your software to work on both situations.
If this was intended to counter some of the points I made, then I want to be clear:

It's not that $FOO should have been standardized, though we live in hope ;)

It's not that open source software is necessarily better -- although the code is often less overtly horrifying IME.

It's just that a platform that is made by devs for devs, where you can look into everything and see how it works, is naturally dev-friendly, and becomes more so over time. (the beginning in Linux' case actually being in Unix times -- culture of sharing and the whole cluster of ideas comprising "Unix Philosophy")
;
and conversely, a culture of black-boxing (Windows being the worse offender, but Mac should also be mentioned) - gatekeeping what you can and cannot do / look at - , is hostile to developers.  No amount or quality of tools can compensate for this; it's a systemic problem resulting in the devs simply not using the marginal platform, and thus not noticing the bugs specific to it.

(I also have experienced personally that GIMP and Krita are both a lot more buggy on Windows, so I thought it was relevant that they aren't buggy on Linux.)


Quote
Happy on their mountain, they think they know the one true way, the one ultimate eternal truth, smoking on the Dunning Kruger pipe everyday.
I must admit, I was tempted to just link the wikipedia article on Dunning-Kruger after reading enough of the thread. You have certainly shown more patience than me, being willing to do the research to find whether it's MSYS or Cygwin rather than just implying that part of the toolchain is missing.
« Last Edit: August 04, 2017, 06:34:53 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #18 on: August 04, 2017, 06:35:49 am
The most important factors to good software is the combination of developer engagement with user feedback. That's the sort of Open that matters most.

I find this comment hilarious, because my experience is that open source developers are notoriously bad at listening people. A great example is Blender 3D and so called ngon case. I think we had to ask ngon feature for almost 10 years until the developers finally decided to add it, and after that everyone realized it was a good decision. The "reason" why it was opposed was just because it didn't "fit" to Blender's "style". Another example was when I asked Gimp's developers if they could add line drawing tool in Gimp, but they said no, because it's shift+pen to draw lines.

I think the reason why open source developers refuse to listen user feedback is that they don't have to. It's simple. In most cases they get their money anyway, from donations and other sources. It doesn't matter what they do, in fact some projects must be a dream job, because you don't have any kind of responsibility to provide working solutions and they still get enough money. And they can always throw that "hack it yourself" argument when everything else fails.

Offline Krice

  • 0001
  • *
  • Posts: 33
  • Karma: +0/-0
    • View Profile

Re: Hackable pixel editors?

Reply #19 on: August 04, 2017, 06:53:06 am
It's just that a platform that is made by devs for devs, where you can look into everything and see how it works, is naturally dev-friendly

You don't even know what you are talking about. Linux is based on old, outdated system that was and is a huge mess and that's why we have these bloated open source projects which are developed in incredibly slow pace and they still, after years of development, have long lists of bugs. Programming in linux is unnecessary difficult and unstable, which leads to a "solution" where everything is compiled frequently, because they can't make anything that has a minute of backward or forward compatibility.