[RHH1095]

It would be nice to be able to change the brush cursor COLOR.  I use a Black background and then have no idea of the location of the cursor until I contact the canvase.

[lucdebeeldhouwer]

I also have this problem.  On some brushes the cursor also gets too small (especially when working at 50% zoom!) and/or it gives a poor indication of real brush size (compared to how it actually paints).
Suggestions:
- paint the cursor in alternating back and white pixels, so it will be visible on both a white and a black background.
- set a minimum limit on the cursor size, so it remains clearly visible on tiny brushes and does not collapse into a dot.  BTW: cursor size already seems to have a maximum limit, but the actual dab size should also have a maximum limit, because the program stalls when painting with dab sizes that get too big.
- improve the cursor shape to better represent the actual brush shape, assuming this can be done without slowing down the painting.  An idea might be to paint a hidden brush stroke in high contrast and apply edge detection on this to create the cursor, but this will need to be done in real time so it seems too expensive.  A more efficient idea for creating a more useful cursor might be to draw the cursor not as a circle but as a single ellipse that corresponds to the current dab (or probably a filtered version of its very recent history) but has both radius-es independently magnified by the current jitter amplitude.
 

[maxy]

Suggestions:
- paint the cursor in alternating back and white pixels, so it will be visible on both a white and a black background.
- set a minimum limit on the cursor size, so it remains clearly visible on tiny brushes and does not collapse into a dot.

We already do both of that. (The minimum size is quite small, though; last time when I increased the minimum cursor size we got requests to make it as small as it is now, to allow precision work. You can edit gui/cursor.py, should be easy to try different minimum size there.) I never managed to reproduce this problem on my PC, my cursor always has both black and white in it no matter what I do... maybe it happens only for Windows users? What exactly do I have to do to see it (what zoom level, brush name and radius)?

Probably a lot could be improved about the cursor... however we have some technical limitations: we cannot draw a cursor bigger than the limit that you see now, or it will break down completely on some systems (disappear and start flickering), and sadly we cannot make it transparent. (We can, of course, if we really want, but it would most likely start to lag behind the actual pen position for many use cases - which would be worse than just displaying the system-default arrow, I think.)

[lucdebeeldhouwer]

Indeed, I'm on windows and herefore using the packaged version, so I can't experiment with the source code (right?).  If a source code installation can be made available on windows that even non-programmers can easily compile (simple as push a button) then I would be willing to experiment.

Reproducing is very easy:
-after installing, change nothing, just draw a (black) color area with the mouse using the default brush, size and color.  Notice how the cursor is small and has no white pixels.
-now move the cursor in this black area.  You can't see it anymore.

btw: if software is advertised as multiplatform then is it not mandatory that it is also tested on windows *by the developers* ? 

Another idea for the cursor: I can see your need for a small cursor on a small brush, and fully agree, but what if you add a crosshair (within the allowed size) only when the pen is up (perhaps after a 2 second delay of lifting it)?

[maxy]

btw: if software is advertised as multiplatform then is it not mandatory that it is also tested on windows *by the developers* ? 

Nope. This is a common missunderstanding. Most open source developers prefer to use an open source operating system (surprise, surprise) so this is what they are testing on. It's not mandatory for us developers to do anything at all, since we are working in our spare time. I don't know why Windows users have such a hard time to understand this concept: it's not much fun to do volunteer work when users take it for granted like this. Especially on Windows, the feedback of users is often in a very demanding tone, so no surprise that few developers want to fix stuff on Windows.

There is a downloadable build environment with instructions how to build MyPaint on Windows. You can thank tumagonx for that, and for all his work he put into the Windows installer so far - without that, you could probably just forget about MyPaint on Windows today. You can also (in the existing installation) unzip the library.zip, edit the python source code in there, and zip it again (no compilation needed).

[lucdebeeldhouwer]

I really understand your viewpoints.  I know programmers prefer linux, and certainly not windows, and that there are very good technical reasons for that.  I'm convinced the future is very bright for linux and/or other open source OS.   I am all for linux (even though I have never used it) and as soon as all the software I need exists on linux (and can be installed by non-programmers) I will start to use linux myself for sure (I already use as much open source multiplatform software as I can, like libreOffice).   

But sadly, today most software is still available only on windows, and so I am still stuck on windows.   And sadly, most regular users (90%) are still on windows, while most of them are not stuck. 
Also sadly, most artists are not programmers.  I guess the Mac takes a bigger share among artists and there will be much less than 90% of them on windows, but probably still the majority will be. 

As developers, you are aware of all this because you do make efforts to write a multiplatform application, which must be applauded.  I dare say that MyPaint is the *best* artistic painting program, certainly among the open source offerings, so please believe me that I am *very* grateful for your work! 
That does not make any of the following untrue or unmentionable however.

No doubt you are concerned with the quality of your program, and with how your users experience it.  So it is disappointing that you neglect your windows users, and defend your right to neglect them.  And it is surprising that you even think it is right to complain when they then feel neglected.
Clearly the right thing to do is to support and test the windows version. You don't *have* to do anything, you don't brake any law if you don't.  It is just the right thing to do.  If you care about the quality of your work and the perceived quality by your users, then you should do it. 

Suppose you support only one windows release per year then will the windows users not be punished enough by not having all the latest features?  And that would not take a huge percentage away from the more interesting development work, would you not agree?

Side note: you can't blame the users for using windows. In general multiplatform support is the key to *enable* users to switch to linux.  They won't start to use the application otherwise, and only when all their application software is multiplatform can they switch.

 

[lucdebeeldhouwer]

"There is a downloadable build environment with instructions how to build MyPaint on Windows. You can thank tumagonx for that, and for all his work he put into the Windows installer so far - without that, you could probably just forget about MyPaint on Windows today. You can also (in the existing installation) unzip the library.zip, edit the python source code in there, and zip it again (no compilation needed)."

A big thank you to tumagonx !!

But it seems this "downloadable build environment"  is for a 32bit version and for an old version?
Also it sounds to me like this is something that is usable only by an experienced programmer, or am I mistaken?
Is there any non-programmer out there who has attempted to use this?

[idragosani]

In general, on Linux, developers for a project typically aren't involved with the packaging of the software beyond providing source code, and usually rely on external maintainers to create binaries (such as for Ubuntu or Fedora packages). The same usually goes for porting to other platforms... nothing is stopping you or anyone else from building the software and maintaining a binary installer. This is especially true for development branches, which are usually *only* distributed as source code via the code repository, since the code could be changing a lot.

BTW, you don't have to be a programmer to compile the software, many Linux users aren't programmers either, there just happen to be a lot of tools available on Linux that make it easy to download, build and install software without ever touching a line of code.

[lucdebeeldhouwer]

So OK, because distributing the source is enough for most Linux users, therefore the developers typically don't provide binaries even if is for windows.  But while this explains the history, it does not explain the rational, it seems to me.  Notice first that those users are all computer enthusiasts who don't mind to put in extra effort and learning time to get things done, and less then 5% of the population sits in this category I would estimate, and probably less than 1% of the artists (the idea of even using a computer is revolting to some, let alone linux).  Windows may be flawed for programmers, but installing software is heaven for users: just download a file an click on it.  Linux won't ever win over those 90% of users that are on windows as long as developers feel they don't need to provide the same service.  If 85% (my estimate) of users fail to get software (in general) working then the balance will never tip over, and users will stick to windows forever.  Guarantied.

Anyway, just because other projects also have poor windows support does not mean that this is as things should be. 

As I pointed out already: only by providing multiplatform applications with good support for windows will windows users eventually be able to switch to linux.  It is only the developers who can enable this.  They should be aware of this and not look down on users for sticking to what they can use best.

On a more technical note: there will always be differences on different platforms (certainly if as different as windows), and if developers don't test for windows then automatically there will be minor "bugs" or inconveniences, that would easily have been avoided, had they noticed them.  So correct me if I'm wrong, but IMO it would be of significant benefit if the developers themselves did the testing...

[savageorange]

So OK, because distributing the source is enough for most Linux users, therefore the developers typically don't provide binaries even if is for windows.  But while this explains the history, it does not explain the rationale

There is no rationale; This is a behaviour of developers as a whole that emerges from the various circumstances involved:

* Windows has the crappiest known support for software development. No matter what MS does, no matter what any third party does, short of opensourcing Windows, this is not going to change.
* Linux has great support for software development. MacOSX has decent support.
* People use what works, especially in OSS where they are not constrained by company licenses, contracts, or policies.
* Therefore : most OSS developers use Linux or MacOSX.
* Therefore : only a small minority of OSS developers use Windows
* Therefore : often nobody spends time on making the Windows port work as well as it could.

IOW: It's not because of a plan or a rationale, and most of us *would* like to see more OSS and Linux...  but it doesn't really seem true that we have the agenda of specifically pushing OSS and Linux. We're not a marketing department -- we're volunteer developers. When we see that the quality of the Windows port is suffering, we can't just produce a competent Windows developer from nowhere and point them at it. We don't -allocate- time at all - this isn't work, it's fun. People do what they want, improve the things they think need improving, test the things they think need testing, and fix the things they think need fixing.

If you want better Windows support, then make it so! You can't get to there by merely explaining why good Windows support is worthwhile -- btw, you did give a good explanation of that. If you think it's broken, then fix it........ or else complain about it and wait for an indefinite period of time, until someone else decides they find it broken and fixes it. Those are the two options available to you here, and for OSS in general. Easy choice, right?

[idragosani]

Anyway, just because other projects also have poor windows support does not mean that this is as things should be. 

This is open source software. If you see something that needs to be done, it is within your power to get involved and make it happen. That's how OSS works. It's community-driven development. You don't have to be a programmer, either! Artists like Ramon Miranda and David Revoy have contributed significantly to MyPaint, and as far as I know they aren't coders.

[drawsattention]

Uh oh, I started a post on same thing...sorry! I do want to mention however that you developers and creators of Mypaint rock and deserve nothing but thanks for everything you have done to make this program usable by Windows users. I know I am not the only one who appreciate all that you do to make this wonderful program accessible to everybody. Hope your day is a great one!!!! 

[f]

I want to bump this topic with a picture. It's comparison of cursor behaviors on win and linux. Maybe someone can give me a hint how to make low size cursor on win look more like the one on linux?