Shop OBEX P1 Docs P2 Docs Learn Events
PropellerIDE 0.25.0 Released - Now with themes! — Parallax Forums

PropellerIDE 0.25.0 Released - Now with themes!

Brett WeirBrett Weir Posts: 288
edited 2015-05-08 19:52 in Propeller 1
Hello all!

I've released a brand spanking new version of PropellerIDE for you. This version of the editor includes a brand new theming system that allows you to change the editor's look and feel to your heart's content. It comes with several presets to choose from, but you can customize them however you like.

Some examples: The Classic theme uses a modified Parallax font that scales nicely and works well with Unicode. In addition, there's a few new keyboard shortcuts and menu options, a new command-line parser, and the datasheet/manual links now work on all platforms.

Download for Windows, Mac, Linux, and Raspberry Pi on the PropellerIDE home page!

Read all about the changes on the PropellerIDE 0.25.0 release page!

Hope you like it!

UPDATE:

0.25.1 released with loader path fix.
«1345

Comments

  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-01-21 06:34
    Congrats on the theming! That's always a fun feature to play with :)
  • PaulPaul Posts: 263
    edited 2015-01-21 08:45
    I found the download page here: http://www.lamestation.com/propelleride/
  • GadgetoidGadgetoid Posts: 47
    edited 2015-01-21 15:06
    jazzed wrote: »
    Bad news.

    FTDI driver now with trojan.gen.

    This is a false alarm, but it's an irritating one that needs a workaround. Probably unbundling the FTDI driver, although it's then an extra step to locate it.

    That said, the way FTDI go about their business... Their drivers basically are viruses! /burn
  • dgatelydgately Posts: 1,630
    edited 2015-01-21 18:53
    Brett,

    Not to be too picky, but should't the Preferences path fields be a little bit wider? I like being able to see as much of the paths as possible without needing to scroll, extremely left or right. Could you make these wider?


    Prefs.png


    Oh, and congratulations on your work, it's looking great!


    Thanks,
    dgately
    707 x 464 - 62K
  • ozpropdevozpropdev Posts: 2,792
    edited 2015-01-21 20:40
    Looks good Brett.
    I noticed the timing has been changed and the problem of detecting Propeller's when using CP210x USB bridges appears to be Ok now.
    The problem I'm having now is I can't get the loader to start.

    attachment.php?attachmentid=112903&d=1421901028

    in preferences I have the following path/file set
    attachment.php?attachmentid=112902&d=1421901028

    IBTW 'm using Windows 8.1.
    Am I missing something?
    Cheers
    Brian
    581 x 58 - 9K
    253 x 229 - 22K
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-21 21:21
    I don't believe we get such "false alarms" on other packages that provide FTDI drivers.

    Ahh, yes, this has been an ongoing problem. Some combination of packaging the new FTDI driver inside the executable using Inno Setup 5 on Windows 8 has caused the PropellerIDE executable to be flagged by Avira and Avast (this is the first I've seen it on Norton). I've tested on about 4 or 5 different installations so far with the same results every time. Two remote Amazon EC2 Windows instances, on a local VM, and on a native installation. Scanning each of the components by themselves results in no errors, scanning the project results in no errors, I submitted the driver by itself to virustotal.com with no complaints. It's only when the FTDI driver is packaged within the installer that antivirus starts complaining, and I'm at a loss as to why. I've submitted several false positive reports to Avira and Avast with no response from them. I have also wondered if the results would be the same if I packaged PropellerIDE with NSIS instead of Inno Setup, but I haven't looked into it yet.

    I think to prevent more scary messages, I'm just going to remove the driver from the installer for good.
    The problem I'm having now is I can't get the loader to start.

    Hmm. I've been refactoring PropellerIDE to use native paths internally so that I can use Qt's built-in path libraries, and I must have flubbed a couple spots in the actual build code. I'll make a patch build tonight that will resolve this.
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-21 21:23
    Not to be too picky, but should't the Preferences path fields be a little bit wider? I like being able to see as much of the paths as possible without needing to scroll, extremely left or right. Could you make these wider?

    Ah, how frustrating! Qt uses different style policies to comply with Mac style guides. I'll see about using a different policy for this widget on Mac. :)
  • dgatelydgately Posts: 1,630
    edited 2015-01-21 21:55
    Brett Weir wrote: »
    Ah, how frustrating! Qt uses different style policies to comply with Mac style guides. I'll see about using a different policy for this widget on Mac. :)


    One more Qt on Mac glitch:

    Themes.png


    The Themes Combo-box is corrupted a bit with horizontal lines...

    Thanks,
    dgately
    707 x 464 - 62K
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-21 22:24
    dgately wrote: »
    One more Qt on Mac glitch:

    Themes.png


    The Themes Combo-box is corrupted a bit with horizontal lines...

    Thanks,
    dgately

    Huh, that's a little strange. What version of Mac OS X are you using? I have that dialog open on 10.9.5 and it looks the way it should.
  • dgatelydgately Posts: 1,630
    edited 2015-01-22 00:06
    Brett Weir wrote: »
    Huh, that's a little strange. What version of Mac OS X are you using? I have that dialog open on 10.9.5 and it looks the way it should.

    10.10.1...


    dgately
  • RoadsterRoadster Posts: 209
    edited 2015-01-22 04:20
    I tested on windows 7 and here are a few things I noticed:
    1. Like others have said the loader is not working
    2. The file history is not remembered
    3. It no longer automatically opens the last file you where working on when starting up
    4. It looses the theme settings if you use the file exit menu
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-22 06:27
    dgately wrote: »
    10.10.1...

    Hmm... that's very odd. Well, I'm going to be upgraded to the new OS X soon, so I'll let you know if I see anything when I do. If you'd like to know sooner, you can try making the build yourself and letting me know what you find.
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-22 06:52
    Roadster wrote: »
    I tested on windows 7 and here are a few things I noticed:
    1. Like others have said the loader is not working
    2. The file history is not remembered
    3. It no longer automatically opens the last file you where working on when starting up
    4. It looses the theme settings if you use the file exit menu

    2 & 4 are related problems. There's some logic to remove the old configuration file if a new application version is installed, but it behaves differently on Windows than other platforms. It might be best to simply remove that, as the file can still be manually cleared if it causes problems, which is what the logic was for in the first place.

    As for 3: internally, this release represents a large-scale refactoring of how PropellerIDE manages files and preferences to improve overall application maintainability. The new features like themes and tab controls are what you might think of as side effects of this effort. But another side effect is that during this process, some features had to be removed from the project that were poorly implemented and unable to be used as is.

    In the case of this feature, my current plans are to implement session saving and reopening, so you'll be able to reopen all of your tabs. This will be considerably easier to do now that there's a single FileManager class managing the interaction between the editor tabs and the rest of the application.

    As such, this release is a snapshot, and a great deal more work is required to fully realize this project to the level that I require for the LameStation project.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-01-22 08:53
    I'm having the same problem with the loader not working on a Windows machine. The com ports that I'm getting are COM14 and COM15. I know that the P2 loader had problems with higher port numbers. Maybe the P1 loader has the same problem. If so, it might be fixed by increasing the upper limit on the COM number in the source code.

    EDIT: I cleared out my unused COM ports, and now the Prop board connects on COM5. However the loader still fails, so the COM port number isn't the problem.
  • GadgetoidGadgetoid Posts: 47
    edited 2015-01-22 12:38
    I've been following Brett's work on PropellerIDE extremely closely. I picked up and played with the code somewhat myself, with a view for making useful contributions.

    Suffice to say, a lot of "under the hood" refactoring has gone into this version of PropellerIDE, which you can get a feel for by viewing the GitHub commits. This refactoring means that some features basically have to be re-written from scratch to get them back to their previous state. So, the short term solution has been to simply remove them while everything else is fixed.

    I think we're in for a bit of a ride as PropellerIDE is bashed into shape and made fit for another decade of Propeller-programming awesomeness, but on the plus side this is the time to have your say about features/improvements.

    As for the loader- I really hope to see a shiny new replacement for that this year, too. The current solution(s) work, but they're fragmented, poorly documented and not without their problems. Watch this space!

    Sit tight!
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-22 14:41
    Gadgetoid wrote: »
    As for the loader- I really hope to see a shiny new replacement for that this year, too. The current solution(s) work, but they're fragmented, poorly documented and not without their problems. Watch this space!
    What loader does PropellerIDE use? If it is having problems, why not just fix the problems rather than creating a new loader?
  • pjvpjv Posts: 1,903
    edited 2015-01-22 15:10
    Gadgetoid wrote: »

    .........this is the time to have your say about features/improvements.

    So I would much appreciate the addition of live (when mouse is hovering over a label) display of its Cog Address, its Object Address and its Hub Address. And in the case where the label is a constant, its value.

    The first two of these are available in the SpinTool, although not live with hovering, and are of immense assistance when debugging assembler code. The latter two would be a nice improvement.

    Thanks, and

    Cheers,

    Peter (pjv)
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-01-22 19:05
    David Betz wrote: »
    What loader does PropellerIDE use? If it is having problems, why not just fix the problems rather than creating a new loader?
    The problem with the loader might be in the way it's being executed. I replaced my p1load.exe with one that writes the arguments to a log file, and it appears that it never got executed. Maybe it's a path issue, though I tried moving it to a simple pathname, and it still didn't work.
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-22 19:06
    Dave Hein wrote: »
    I'm having the same problem with the loader not working on a Windows machine. The com ports that I'm getting are COM14 and COM15. I know that the P2 loader had problems with higher port numbers. Maybe the P1 loader has the same problem. If so, it might be fixed by increasing the upper limit on the COM number in the source code.

    EDIT: I cleared out my unused COM ports, and now the Prop board connects on COM5. However the loader still fails, so the COM port number isn't the problem.

    What the issue actually was is that I had moved some code around and had a problem with passing the wrong path separators to the loader. It's fixed in my branch in the following commit if anyone is interested in building it before I make another release: https://github.com/bweir/PropellerIDE/commit/5442b0349eb42078487c96239f0b7e00a292be81

    Oh, haha, I just saw your latest post. Looks like you had already figured that out. =P
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-22 21:28
    Dave Hein wrote: »
    The problem with the loader might be in the way it's being executed. I replaced my p1load.exe with one that writes the arguments to a log file, and it appears that it never got executed. Maybe it's a path issue, though I tried moving it to a simple pathname, and it still didn't work.
    At one point I suggested to Steve that I make a loader library that he could call directly rather than trying to invoke an external program. Would that help?
  • Brett WeirBrett Weir Posts: 288
    edited 2015-01-22 21:56
    David Betz wrote: »
    What loader does PropellerIDE use? If it is having problems, why not just fix the problems rather than creating a new loader?

    Hi David, I've tried writing this message a couple of times and lost them due to technical difficulties, so let's try again! =P

    PropellerIDE is using an orphaned version of p1load that lives within the project repo. I don't actually know where it came from or whether it's current.

    I have a few reasons why I wish to rework the loader application.
    1. Being standalone, p1load has to bootstrap its own serial implementation which means lots of extra work for serial I/O routines and porting to new platforms. I'd like to switch to an existing serial library that fully abstracts platform details. Now that PropellerIDE is built against Qt5, QSerialPort comes for free and it makes sense to use that for the loader instead of talking to native APIs directly.
    2. It seems to be impossible to debug in RAM on UNIXes with the serial terminal because the loader has to give up the serial device to the terminal which sends the DTR signal again. Having to write to EEPROM to use the serial terminal is a major pain and I'm willing to go as far as combining the loader and terminal into one application that both loads software and provides a serial terminal in one session.
    3. I want to create a unified library API for downloading to the Propeller that will use the relevant loading strategy for the platform, for using features such as high-speed and wireless downloading. This is a requirement if PropellerIDE is ever to run on iPad, ChromeBook, Android, or other unusual platforms, as well as platforms where a command-line is not supported. In this scenario, the loader application is merely a CLI wrapper around the core loader library.
    4. To improve separation of concerns, I want PropellerIDE to have no knowledge of how to talk to hardware. All of that knowledge should be neatly contained within the loader library.
    5. Using Qt for the loader makes internationalization completely painless.

    I should clarify; my interest is not simply trashing the loader and starting over, but with all the changes I describe, it's unlikely that the loader will look anything like it does now.
  • Heater.Heater. Posts: 21,230
    edited 2015-01-22 22:49
    Brett Weir,

    How many loaders do we have now?

    My guess is that the loader in PropllerIDE has come from SimpleIDE. The loader in SimpleIDE came from prop-gcc.

    In order to be able to program Propellers via the on board UART of of the Raspberry Pi I created my own fork pi-propeller-load https://github.com/ZiCog/pi-propeller-load. Using that UART requires using a GPIO pin for Propeller reset as the UART has no DTR/RTS.

    pi-propeller-load can also be used on other systems like the cheap MIPS based routers and other ARM boards.

    I understand that the changes I made have found their way back into prop-gcc so pi-propeller-load should now be redundant. I have not had a chance to check/test that.

    I like your plans for a loader clean up. Some thoughts:

    1) I always thought the loader should be separated out of prop-gcc and be it's own project with it's own repository. SimpleIDE, PropellerIDE and whatever else would likewise not include a loader of their own but use "the one true loader". Thus avoiding duplication of effort and keeping everyone in sync. The loader project would provide a libraries for others to use as well as a command line loader tool.

    2) Using the Qt5 serial port worries me as it introduces a dependency on Qt which may not always be available. For example on those MIPS based routers or small Linux systems. Or perhaps others want to use the loader from other than Qt based programs. Certainly prop-gcc should not gain a dependency on Qt!

    3) The base loader library should not include any internationalization. That is an overhead it does not need.

    I'm currently tackling the Chrome book issue by creating a loader in JavaScript that can be used from Chrome apps or from Chrome extensions in the Chrome browser.
    With that in place we will have a complete Spin IDE in the browser. Progress is rather slow on that project though.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-01-23 06:02
    Brett, could you please just fix the current problem with p1load in Windows systems? As it is now, PropellerIDE is completely useless under Windows, at least it doesn't work on my Windows machine. Maybe the other enhancements can be done later on.
  • GadgetoidGadgetoid Posts: 47
    edited 2015-01-23 06:09
    Dave Hein wrote: »
    Brett, could you please just fix the current problem with p1load in Windows systems? As it is now, PropellerIDE is completely useless under Windows, at least it doesn't work on my Windows machine. Maybe the other enhancements can be done later on.

    You can always use the previous release.

    However, I think it's already been fixed, it's just not available as a release yet; https://github.com/bweir/PropellerIDE/commit/5442b0349eb42078487c96239f0b7e00a292be81

    In future I will volunteer to test new builds of PropellerIDE on Windows 7/8 to try and curtail any future problems like this one, since I have access to both a variety of Propeller-based boards, and computers running both of these OSes.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-01-23 07:28
    OK, I'll wait for the next release. Thanks.
  • pjvpjv Posts: 1,903
    edited 2015-01-23 08:05
    Dave Hein wrote: »
    ........ As it is now, PropellerIDE is completely useless under Windows, at least it doesn't work on my Windows machine.

    I downloaded it on Wednesday to my XP machine, and at seems just fine.

    Cheers,

    Peter (pjv)
  • PublisonPublison Posts: 12,366
    edited 2015-01-23 08:19
    pjv wrote: »
    I downloaded it on Wednesday to my XP machine, and at seems just fine.

    Cheers,

    Peter (pjv)

    Did you try to load RAM/EEPROM? My XP machine complains "Could not start loader". This is on COM 22

    My Windows 7 does the same.
  • Heater.Heater. Posts: 21,230
    edited 2015-01-23 08:33
    What is with the COM22 thing?

    Surely you don't have so many com ports on your machine?!

    I seem to remember there was an upper limit on the com port numbers PropellerIDE could deal with. Is there a way to get that down to a more sensible number?
  • David BetzDavid Betz Posts: 14,516
    edited 2015-01-23 08:33
    Brett Weir wrote: »
    Hi David, I've tried writing this message a couple of times and lost them due to technical difficulties, so let's try again! =P

    PropellerIDE is using an orphaned version of p1load that lives within the project repo. I don't actually know where it came from or whether it's current.

    I have a few reasons why I wish to rework the loader application.
    1. Being standalone, p1load has to bootstrap its own serial implementation which means lots of extra work for serial I/O routines and porting to new platforms. I'd like to switch to an existing serial library that fully abstracts platform details. Now that PropellerIDE is built against Qt5, QSerialPort comes for free and it makes sense to use that for the loader instead of talking to native APIs directly.
    2. It seems to be impossible to debug in RAM on UNIXes with the serial terminal because the loader has to give up the serial device to the terminal which sends the DTR signal again. Having to write to EEPROM to use the serial terminal is a major pain and I'm willing to go as far as combining the loader and terminal into one application that both loads software and provides a serial terminal in one session.
    3. I want to create a unified library API for downloading to the Propeller that will use the relevant loading strategy for the platform, for using features such as high-speed and wireless downloading. This is a requirement if PropellerIDE is ever to run on iPad, ChromeBook, Android, or other unusual platforms, as well as platforms where a command-line is not supported. In this scenario, the loader application is merely a CLI wrapper around the core loader library.
    4. To improve separation of concerns, I want PropellerIDE to have no knowledge of how to talk to hardware. All of that knowledge should be neatly contained within the loader library.
    5. Using Qt for the loader makes internationalization completely painless.

    I should clarify; my interest is not simply trashing the loader and starting over, but with all the changes I describe, it's unlikely that the loader will look anything like it does now.
    As I mentioned in an earlier, I have been in favor of creating a loader library for a long time. That idea was vetoed by other people on the project. I'm not sure tying it to Qt is a good idea though. Anyway, are you working on this? Shall I pass off the loader work to you? I don't want duplicate efforts going on here. I've been responsible for propeller-load since the start and would like to know if there is a plan to replace it so I know not to put any further time into the loaders I have written (propeller-load, p1load, p2load).
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2015-01-23 08:41
    heater wrote:
    I seem to remember there was an upper limit on the com port numbers PropellerIDE could deal with. Is there a way to get that down to a more sensible number?
    There's nothing "not sensible" about COM22, expecially in a universe where you're using multiple FTDI chips, each wanting its own comport number. The solution lies in the software that opens the port. In Windows, ports above COM9 won't open with COMxx; you have to use \\.\COMxx. It's as simple as that.

    -Phil
Sign In or Register to comment.