This is a rant ... at least my idea of it
Posted: Fri May 29, 2015 11:02 pm
Dear community,
there is one thing with Flowstone that makes me angry. It's annoying, it's totally unneccessary, it stops me from progress whenever I stumble upon it (and that's very often), because I then try to find a solution. Without convincing success.
I'm talking about Flowstone not reporting a mouse up event, if this mouse up happens outside of the view, where the mouse down happened. My current workaround is to place a RubyEdit in the top most view's module, sending each incoming mouse up event back to the lower layered modules, while those check on that incoming signal, if a mouse down didn't get a corresponding mouse up and then react.
But that's not very cool. For example, sharing controls would involve people having similar workarounds. Also, it could be done quite similar to my solution from Flowstone already (in compiled C it should be a lot faster than in Ruby). There might be better solutions. Etc.
I thought I found a solution with the hold state of the show cursor prim. But I just saw that it is only faking to hold the position. Instead it hides the cursor and stores the starting position, applying that position when the movement is done. The issue is that Flowstone still registers a mouse up at a position far away from the starting position - problem still not solved. Btw., it also stops when reaching the screen's border, although hidden and hold. Took me some time to see that it is not a bug in my algorithms
After days of work on the multi-functional control (complete re-write), I experienced the issue again and now am very frustrated. Will take a break from programming for a day or two and try to calm down. How annoying!
there is one thing with Flowstone that makes me angry. It's annoying, it's totally unneccessary, it stops me from progress whenever I stumble upon it (and that's very often), because I then try to find a solution. Without convincing success.
I'm talking about Flowstone not reporting a mouse up event, if this mouse up happens outside of the view, where the mouse down happened. My current workaround is to place a RubyEdit in the top most view's module, sending each incoming mouse up event back to the lower layered modules, while those check on that incoming signal, if a mouse down didn't get a corresponding mouse up and then react.
But that's not very cool. For example, sharing controls would involve people having similar workarounds. Also, it could be done quite similar to my solution from Flowstone already (in compiled C it should be a lot faster than in Ruby). There might be better solutions. Etc.
I thought I found a solution with the hold state of the show cursor prim. But I just saw that it is only faking to hold the position. Instead it hides the cursor and stores the starting position, applying that position when the movement is done. The issue is that Flowstone still registers a mouse up at a position far away from the starting position - problem still not solved. Btw., it also stops when reaching the screen's border, although hidden and hold. Took me some time to see that it is not a bug in my algorithms
After days of work on the multi-functional control (complete re-write), I experienced the issue again and now am very frustrated. Will take a break from programming for a day or two and try to calm down. How annoying!