4. HSB and Gray color slider(s) cannot be dragged - is it ROUND 3 now...?

HSB and Gray color slider(s) cannot be dragged - is it ROUND 3 now...?

  • P

    Dear fellow VectorStyler users,

    I didn't have much time to do any "vectoring" in the past few days. Now just installed v1.1.105 and immediately everything went down the drain.

    How many times the problem with the broken HSB and Gray color sliders have been reported so far? I can tell you I reported this at least 2 (if not 3) times so far. And every time it was fixed it got broken again.

    And now it is broken AGAIN in v1.1.105!

    1. Draw a shape and assign a background color to it.
    2. Open the Color Palette and switch to HSB or Gray color mode.
    3. Select the shape and drag the H, S, or B color sliders (or the Gray one) to change the fill color of the shape.

    You will see that there's a problem with dragging the sliders. Furthermore...

    1. Select one of the H, S, or B color values (or the Gray) and try to enter a two digit value (eg 36). Once you type the 1st digit, you no longer can type the 2nd digit because the value field will get deactivated.

    Sadly, this project will take YEARS to fix and I'm willing to bet that unless it will be rewritten from ground up, things will get fixed and with another release or two they will be broken again.

    With great sadness, I have to say goodbye to VectorStyler. I am pretty sure this project is doomed. The underlying problems have nothing to do with "regression". It has to do with spaghetti code. With a clean underlying code structure, there's simply no such thing that you keep fixing a particular feature that only gets broken over and over and over again after every X release.

    It's a great initiative and I hope in a few years down the road VectorStyler can come to the point where at least basic features will be stable. Good luck!

    0 2 Replies

  • @pentool I think version 1.1.105 was released as quickly as possible to fix the regression with 'Paste Inside'.

    Fixes for the issues you report here are already in the works if I understood correctly.

    (Btw, changing the slider value works by clicking).

    0
    _
     1 Reply
  • administrators

    @pentool Yes this regression can be replicated and the fix will be in the next build.

    0
  • _

    @b77 What you are saying confirms pentool's main gripe. When fixing errors ends up like a game of Whac-A-Mole, with other bugs and regressions popping up elsewhere, it is a sure sign of architectural design flaws. This usually spells disaster for any software project with over a few thousand lines of code.

    0 1 Reply
  • administrators

    @_NM_ said in HSB and Gray color slider(s) cannot be dragged - is it ROUND 3 now...?:

    it is a sure sign of architectural design flaws

    I do not think that it is worth diving into technicalities based on speculation.
    Without knowing the actual code and architecture, this is of course a rather speculative statement.

    The error in this case was a single line of code in the color panel controller.

    The original cause of this was a request to have the color panel select colors in the document color mode.
    Yes, I did release the initial change without sufficient testing, and that impacted less than 10 lines of code.

    But concluding from this to all sorts of adjectives, like spaghetti code or whatnot, is somewhat counterproductive.

    I'm trying to consider as much as possible any user feedback, but it seems that this has increasing downsides as well.

    1
    _
     2 Replies
  • _

    @VectorStyler You are certainly correct and please accept my apologies if it offended you in any way. However, my statement was of a general analytic nature referring to the semantics of previous statements, while making no specific reference to any software.

    0
  • _

    @VectorStyler I think it's best to use this opportunity and strike a more positive tone. Clearly, everyone is interested in the best quality and the fewest bugs.

    I doubt that anyone has any misconceptions about the difficulties and complexities of maintaining such a complex software product. At the same time, users invest time and money and expect a certain level of carefree functionality.

    As it currently stands, users upgrade to a new build, go about their usual business, and randomly stumble into bugs.  Speaking for myself, I have come across too many bugs to continue using VS. Paying customers should be entitled to expressions of dissatisfaction.

    Perhaps some form of organizational structure could better test potential releases before distribution. The entire program's functionality could be broken into function areas for individuals to test. One person would test all aspects of the pen tool, another would test all the shapes, etc.

    Each tool category would have a list of tasks to accomplish. For example, the instructions would read, create a rectangle, apply a red fill, apply stroke, change stroke width, and so on.  As such, there would be bite-sized tests to performed repetitively by the same individuals, who would become proficient at the task, and expand the tests if needed based on results and features.

    Setting this up, of course, would be a major headache, but with enough testers and effort, it could prove invaluable. Or perhaps even such a structure already exists, but could be improved. Correct me if I am wrong, but based on my experience, It does not appear that there currently exist mechanisms for adequate testing here, especially when there is so much user interaction involved.

    1