I want to reduce the minimum height of the status area / window - the bit at the bottom which is useful for seeing messages when I try to compile or upload, but a huge waste of screen space the rest of the time.
Can I do that?
I assumed it would be in preferences.txt. Maybe a setting like:
status.min-height= far_too_big;
Is there a way of reducing it? I can drag it bigger, and have all status panel but no room at all to edit my program, but I can't drag it any smaller than it was initially.
Ideally, I'd like to hide it all together, except when I'm actually using it. Is that an option I've somehow missed?
I use a 1360x768 display, and after the space taken up by the window title bar, edges and so on, that status pane / panel, and my own Windows task bar, I only get about two thirds of the screen to see what I'm editing.
It's claustrophobic. I can see much better if I paste the code into a text editor, but then, what's the point of having an IDE?
and the Arduino developer has recently implemented a solution:
Test builds are available here:
if you want to give it a try. Be aware that these are intended for beta testing and may not be stable. However, by taking the time to test and reporting any issues you may encounter you will help to get the feature merged, maybe by the next IDE release.
I use the console so frequently that I usually am making it larger than the default but it would be nice to be able to hide/unhide easily.
Andy2No:
what's the point of having an IDE?
The IDE is much more than just an editor. iI fact the editor is probably the least impressive feature of the IDE and many people prefer to use a more capable external editor, which the IDE does support (File > Preferences > Use external editor). It's possible to do without the IDE but much less user friendly.
Originally, I looked in preferences.txt and thought it might be console.lines, but changing that from 4 to 2 did nothing, so I thought that must be for something else. All the googling I did suggested it was called the status pane or panel, or maybe window.
It does work - at least so far, after changing that setting. It doesn't remember how I left the window if I close the program and re-open it - it starts with it hidden. That seems a bit wrong, but I'm fine with it.
I'm not very familiar with Github - or to put it another way, it confuses the crap out of me. I wouldn't know how to find either of those threads from the other, for example. Which is the best one to comment in?
On your last point; I'm aware of what the IDE does, but if I feel the need to use an external editor (rather than just prefer to, because it's what I'm used to), then it stops being truly Integrated, as far as I'm concerned. I've tried that in earlier versions and it seemed quite cumbersome. I haven't tried it recently though, I just assume it would be a similar experience.
If you have comments specific to the fix the Arduino developer wrote after using the test builds, such as reporting a bug, then you should post it to the pull request thread:
If you have comments regarding the feature request then it should be done on the issue report thread:
Keep in mind that hundreds of people get an email for every comment made on that GitHub repository. That's not to discourage you from commenting, just make sure it adds something of value to the discussion. If you just want to vote up or down a comment, etc you can click the little smiley face on the top right corner and chose from thumbs up, thumbs down, smiley, frowney, heart, etc., which will not result in emails sent but can be seen on the bottom of the comment. GitHub is focused on getting work done, whereas the forum is better for just having conversations. The developers have a limited amount of time so it's better if they can spend that doing things that benefit the whole community (such as adding this feature) rather than reading irrelevant comments. On the other hand, with a little effort and care we can help them out. Even if we all just make a little contribution as we are able it adds up to a lot when multiplied by the many thousands of members of this community.
Pull requests are proposals of code to add to a repository. Issues are a report of a bug or a feature request. You have a variety of options for effectively searching through them. Even so, with 5000 issues and 1000 pull requests it can be a bit difficult. Often I know what I'm looking for but I don't know the correct technical term. Luckily GitHub does a good job of linking things together. You can see on that issue report there is a link to the pull request as well as a previous similar issue. The pull request has a link to the issue. So often if you can find something somewhat relevant you can follow the links to others.
I also use the Arduino IDE's editor. I do greatly prefer Notepad++ but I've been holding out with using the IDE solely because it makes me a more effective beta tester. I am tempted to jump ship from time to time though.
I'll resist the urge to clutter up Github with thankyou notes, and wait til I have something more negative to say - i.e. another bug report.
I almost got involved in a Github project once. I made some changes I thought were useful, discussed it briefly with the programmer, then tried to figure out what I was supposed to do to submit my changes... It seemed like more effort than the actual programming part, and I have to admit, I gave up in the end.
It was partly because I started thinking that, really, the programmer whose project it was preferred to just do it all himself, which I can understand, but a big part of it was the learning curve of how to operate Github.
Git and GitHub is confusing at first but once you understand the basics it a very powerful tool for collaboration and contributing to open source projects. Before GitHub came along I would run across bugs but not bother to report them or submit a fix because it was too much trouble to send an email that would probably just end up in a spam filter or have been reported 20 times already. Now it's so easy for me to open an issue report or submit a pull request that I always take the time and it's a really good feeling to give back to these projects that benefit all of us so much. Especially in the Arduino world, you don't need to be a programming genius to contribute. Every little bit helps, even if it's just fixing a typo or suggesting how a reference page could be made easier for a beginner to understand.
I started with GitHub because I wanted to submit a fix for a bug in an Arduino library that I used. Eventually that led me to use Git version control on all of my own projects. It took a while to figure this out but it has been so worth the effort.
I've had to revisit this page, after losing all my settings - after trying the portable mode, due to suddenly not being able to compile anything, any more, after updating the main AVR boards...
To return to the point; this page didn't contain enough information for me to put the console back how I wanted it, so here's what I eventually tracked down:
Find the preferences.txt file, via Files->Preferences (near the bottom of the dialog box, click the link to get to the folder).
EXIT the IDE - close all windows.
Now edit the line in that file which says:
console.lines=4
(or similar)
and change it to:
console.lines=0
and save the file, then start the IDE again.
the top of the console section can now be dragged down until it's completely hidden, freeing the extra screen space.
If you have a 16:9 screen, and especially if you need fonts enlarged, as I do, this is an important setting. It's still not the default, even in 1.8.9, and it's still not obvious what to do to change it, so here it is.
I found this page by googling in seconds, then I spent a lot longer working out how the hell I changed it last time.
- i.e. another bug report.