It’s been a while since I’ve used the web IDE here and I’m… kinda shocked.
The project rename bug is still there. Rename project by adding a character to the end of the name. Watch it have zero effect. Rinse, repeat, til you remove an original character, retype it, then add or change whatever else. ONLY then will it work.
You still can’t search in any normal way (if you hunt around you’ll learn Ctrl-F finds, and Ctrl-K finds… next. Ctrl-H is supposed to replace but it doesn’t do anything at all on Windows anything with Chrome.
But now I see that if you include a library only to find you need to modify it, then remove it and painstakingly add it by hand (why does pasting the cpp file data paste it to the header file as well???) you get bizarre compilation problems - particularly “multiple declarations”.
Surprise! the hidden file you cannot modify called project.properties retains that original library dependency apparently until the end of time. You deleted it, it’s clearly Not There in the project settings you can see, but it’s hidden and untouchable and ready to waste hours of your time.
And so apparently the solution is, don’t use the web ide, or at least if you ever EVER try to use a library that ends up not working right and you need to copy its files by hand into your project, know you should just download what you have, DELETE the project, and try it again because it may never work quite right.
The project.properties bug appears to be new but the rest of these bugs, as a start, are old, old, old… like almost two years old, at least. Is anyone maintaining the web IDE? Was it abandoned and we didn’t get the memo?
True, the Web IDE would need a major overhaul and the advent of Particle Workbench is leading the way there. Original plans were that an online version of that should replace the current Web IDE but with PWB being a work-in-progress and the new mesh initiative time to invest in this has been limited.
However, I can’t replicate the renaming issue
What browser are you using? (I’m using Chrome 70.0.x 64bit on Win10)
The library issues are often not actually a problem with the IDE but with the contributor abandoning the library. If you can raise an issue on the contributores repo they might respond. Or if not, you can bring it to Particle’s attention and/or here.
I’m using the same setup, but it’s been a problem for a very long time.
Create a new app and name it something like Test_foo_bar. Save it. Then try to add a character to the end of the name. Watch it appear… click anywhere else on the screen and watch it revert to the original name.
As for the library, it’s not about the library. The problem is I included a library and realized I needed to modify it, so I copied it into my project (same filenames and all). But despite removing the original community library and making sure it was gone, it nonetheless persisted in the (hidden) project.properties file like so:
dependencies.Adafruit_SSD1306=0.0.2
That said, I can’t seem to reproduce it, though it was certainly there and I could find no way to remove the dependency from that properties file. If I find a reliable way to repro it I’ll let you know.
In short, whatever manages that hidden project.properties is a bit flakey.
Edit - and fwiw the main reason to edit that library was to fix the header guards, the screen height, and the unnecessary random() definition. But none of that should bear on the project.properties file…
It might be unmaintained here, but the library is designed to be hand-edited if you use a 128x32 device (it’s littered with #ifdefs for that). So you end up having to copy it out… and while that may not be optimal, it shouldn’t lead to side effects in the IDE.
As for the test, did you save first (Ctrl-S or click the “save” folder icon) after creating the project and before trying to rename it? If you don’t save, you can rename easily, but the first time you save it is the last time it’s at all easy to edit.
Yes, I did save. I have even built the project and then changed the name multiple times in a row.
BTW, when you change the name and leave the input box the save icon changes into a spinner and I get the message “Firmware was saved successfully.” in the status bar.
As I started writing to insist I still see it and on multiple machines, I just realized I am doing something so unconscious I didn’t notice I was doing it even after consciously trying to avoid while testing this! Maybe it explains the difference (though there shouldn’t be one really).
Click on filename, add char, click somewhere in the grey area (removes focus from the name box). Name reverts, no save occurs
Click on filename, add char, press ctrl-S - it saves with the new name
Click on filename, add char, press Enter - it saves with the new name
Click on filename, add char, click within the file editor to the right - it saves with the new name
Why would backspace have mattered? Because whenever I backspaced I was invariably hitting Enter, causing it to work. And why was that? Because my right hand went from the mouse to the keyboard to press backspace, and going back to the mouse is more work than just pressing enter apparently. When I forced myself to not hit enter and go back to the mouse, it was surprisingly awkward.
It’s one of those individual subtleties when it comes to UI interaction… Basically I’m used to editing something form-like, clicking just outside the edit box, and having the edit stick. Here, you could edit the filename with your left hand, click on the word “Current App” above it (or other grey space near it) with the mouse in your right hand, and see the change revert without saving as I described.
I expected it to work like any other form - you type something, click away, and what you typed stays put (though it may need to be ultimately saved.) Here, if you type something to change the name and (not pressing enter or save) click slightly away from it, it simply reverts immediately.
Now, if you can’t get that to reproduce I’ll be surprised, but I didn’t know til now just how specific the interaction is. If you are used to hitting enter after such a change you would likely never see it. Much ado about something, but something surprisingly specific. I’m just not used to a form field reverting if you don’t explicitly press return after editing its value.
Yup, with clicking on the light gray areay of the project drawer I can now reproduce the behaviour.
That might be something to file a issue here and/or tag @stefanmoraru.
Since I’m mainly keyboard focused and hence hitting Enter or Tab automatically when done. For me this feels just that much more productive than having to move between mouse and keyboard - but so everybody has a preference
Ironically, the library issue I had is exactly like what was described in this old bug report. It’s even the same problem I had to deal with by copying the library I was using (hardcoded screen height).
Small world, eh?
I copied your shared app and downloaded the source. Sure enough, there’s a project.properties file in there with dependencies.Adafruit_SSD1351_Photon=0.0.6 in it.
Your redefinition errors (of the form multiple definition of "Adafruit_SSD1351...)? That’s why those are happening - same. exact. problem.
You reported that issue in March… they do not appear to have even looked at it.
changes into a spinner and I get the message “Firmware was saved successfully.” in the status bar.