Consider eliminating buttons.gif #4196
Comments
|
Why? |
|
IMHO, this is a small nuisance (I was struggling with changing the back-color for the dark theme because of the anti-aliasing) that once out of the way leaves some interesting doors open. I don't feel qualified to go into a debate as to which and why, but I just wanted to bring the thought to a place of debate. I do apologize if that is an inconcenience. [NTS] |
|
Please remove me from this email threads Sent from my iPhone
|
|
@jesusbravo38, you probably clicked "watch" in the Arduino repo at https://github.com/arduino Unsubscribing is something only you can do, through your github account, so we can't help you there. @lmihalkovic, your issues really lack motiviation and clarity. In this case, I'm not even sure what you're asking. Are you suggesting to encode a bitmap using java code that draws lines and points? That doesn't really sound like something that is maintainable or easy. You say buttons.gif is a "nuisance", but don't explain what this means or how it is a nuisance. Reporting issues like these will only waste our time and result in them being closed. Please be more thoughtful and complete when reporting issues. If you are not prepared to invest time in properly explaining or motivating things, it might be better to not report them at all (or pick one or two issues that your feel are most important, and direct the available time to those). |
|
@matthijskooijman I see your point, and you may have noticed that I closed the issue myself as I was not prepared to go into a lengthy argument about why and how I thought the gif file was in the way. You will also no doubt have noticed that unlike some of my other suggestions (many are of the form "add xxx", "add yyyy"), this one was formulated as "CONSIDERATION", allowing an early dismissal without opening if there was zero interest for the CONSIDERATION. As for the rational I didn't feel would be of any use, IMHO the presence of this image creates an arbitrary point of contention preventing
I replaced the images with vector graphics code (need a better designer than me), which took care of my skinning issue. To address the maintenance issue, I generate the code from SVG files that I create in a graphical editor. For the other contention point, I introduced a contribute-able menu class that would allow people who know what they want/how to do what they want to contribute their Tool extension to different parts of the UI. This is not the reason for having written the code, but this is a almost-free side-effect of its existence (I use it to populate the outline view with different contribution types depending on the kind of file that is selected: main sketch, image, doc, lib, ... ). Once again, this was offered as food for thoughts. Again, I closed it myself to signify that although I did see enough value to have created it, I was also keenly aware that I might be alone down that path. Should a like minded traveller have said "hey... yeah.. you're there too?! lets ... " I would have happily Hope this clarifies the situation. |
|
@matthijskooijman using svg2java (somewhere here on ghub) on svgs produced as an export from affinity designer (mac). Results are ... good enough to validate the workflow, but will need some tweaking to become pixel perfect. I suspect it is my ignorance that is at fault (improper scaling during export). |
|
@lmihalkovic Thanks for clarifying, I have a much better picture of what you're suggesting now. Incidentally, I've been doing some work that required adding toolbar buttons and also found that the toolbar code isn't particular flexible, partly because all buttons are in a single file. If you have code to render buttons from SVG, and/or apply other cleanups, I'm certainly interested in that. Perhaps you could make a pullrequest, or share your code in a branch on github? Even if you do not have time to provide a proper, ready-to-merge pullrequest, I might have some time to use your code as a base for cleaning up the toolbar. |
|
This is most of the code (still a couple of things to fix, like the hardcoded minWidth): https://gist.github.com/lmihalkovic/999e75a8e32730160680 The list of actions is passed via constructor. at the moment the list is hardcoded, will likely be replaced with discovery via ServiceLoader (java standard). Icon base classes are code generated from SVGs which are exported from this newfangled drawing app I bought - still haven't figured how to do the export properly (i.e. normalized 0/1.0 coordinates). workflow tip: I draw them with stupid color (like RED, BLACK, BLUE) so that when I get the generated Java code, all I have to do is replace setBackground(new Color(255,0,0)) with bg(). bg()/fg()/... are default methods on a ArduinoIcon interface. All they do it Theme.get("asdkjfhasdkfh") to get the right color. so... maintenance of the draw code is dead trivial |
|
@matthijskooijman assuming that by now you have done your cleanup, so i deleted the gist (code was obsolete and still filled with some of the original leftovers). I'm also done with gracefully stopping the compiler, but i am missing an icon for it. guess i will make something like the stop button in processing... |
|
Actually, I hadn't gotten around to looking at the gist yet, so I'm still interested in having it put up again. |
|
[LMDONE] |
@lmihalkovic Thanks! |
|
you guys have limited resources and doing a great job with the hardware, cores, and Create... how about calling this the 2.0 that your resources don't allow you to work on yet? it does many of the things people have been asking for, has a cleaned up codebase, and some extras
[yes, the "stop-compiler" toolbar button could be disabled by default as the compiler is not currently running] |
Previously, it used some complicated internal datastructures to track what buttons were available and manually painted them and handled mouse clicks. This lead to a clunky and hard to extend toolbar. This commit completely rewrites the toolbar. Now, each button is a separate component (new ToolbarButton class deriving from JButton), so painting and handling clicks works out of the box. In previous commits, Action objects have been made available for each of the toolbar buttons, that also had icons set already. These new ToolbarButtons take all of their info from these actions. Most of this was implemented by JButton already, but copying some properties (selected, the selected icon and the rollover icon) is added by ToolbarButton. Before, buttons would be activated (e.g. giving the upload button a color while the upload is in progress) by calling methods on the toolbar. Now, the "selected" state of the Action / JButton is used for this, which automatically changes the icon to the "selected" icon. This removes the coupling between the verify/upload/save processes and the EditorToolbar, leaving them only coupled to the Actions they are run from. This also allows removing the Editor.toolbar instance variable, since nobody needs to reference it anymore after it was created. The `Editor.statusError()` method used to deactivate the run (verify) button on the toolbar, but it seems there are no code paths that activate this button and then go through statusError but not through the regular deactivation, so this call was removed. Because pressing shift changes the effect of some toolbar buttons, each ToolbarButton can contain one or two Action objects. When shift is pressed or released, the active Action object (as kept by JButton) is exchanged for the other one, updating the effect of the button, the tooltip and icon (though all related actions now use the same icon). When one action becomes selected, that action stays active regardless of the shift button, to provide user feedback (until the action is no longer selected, then it listens to the shift key again). By using separate Icon objects and files instead of manually cutting up a single gif with all icons, it will also be easier to replace the icons with vector icons later, to support high DPI screens more cleanly. Define the buttons themselves (e.g. what buttons are present) still happens in the EditorToolbar class, but it might be good to move these elsewhere at some point. References: arduino#4196
Previously, it used some complicated internal datastructures to track what buttons were available and manually painted them and handled mouse clicks. This lead to a clunky and hard to extend toolbar. This commit completely rewrites the toolbar. Now, each button is a separate component (new ToolbarButton class deriving from JButton), so painting and handling clicks works out of the box. In previous commits, Action objects have been made available for each of the toolbar buttons, that also had icons set already. These new ToolbarButtons take all of their info from these actions. Most of this was implemented by JButton already, but copying some properties (selected, the selected icon and the rollover icon) is added by ToolbarButton. Before, buttons would be activated (e.g. giving the upload button a color while the upload is in progress) by calling methods on the toolbar. Now, the "selected" state of the Action / JButton is used for this, which automatically changes the icon to the "selected" icon. This removes the coupling between the verify/upload/save processes and the EditorToolbar, leaving them only coupled to the Actions they are run from. This also allows removing the Editor.toolbar instance variable, since nobody needs to reference it anymore after it was created. The `Editor.statusError()` method used to deactivate the run (verify) button on the toolbar, but it seems there are no code paths that activate this button and then go through statusError but not through the regular deactivation, so this call was removed. Because pressing shift changes the effect of some toolbar buttons, each ToolbarButton can contain one or two Action objects. When shift is pressed or released, the active Action object (as kept by JButton) is exchanged for the other one, updating the effect of the button, the tooltip and icon (though all related actions now use the same icon). When one action becomes selected, that action stays active regardless of the shift button, to provide user feedback (until the action is no longer selected, then it listens to the shift key again). By using separate Icon objects and files instead of manually cutting up a single gif with all icons, it will also be easier to replace the icons with vector icons later, to support high DPI screens more cleanly. Define the buttons themselves (e.g. what buttons are present) still happens in the EditorToolbar class, but it might be good to move these elsewhere at some point. References: arduino#4196
The idea is to replace them with java code
The text was updated successfully, but these errors were encountered: