PureBasic Forums - English

Here are a couple things I would like to see changed/added with the IDE.


1)Allow Code Templates to be saved and imported into newer versions of PB.

2)Move the Executable Icon setting from Compiler Options, to Project Options where it really belongs.

3)Change the way "Add file to Project" works. We should have an option to simply create a new file that is added to the project instead of having to create a new blank file, save it in the proper directory with a name, and then add it to the Project.

4) Make Color Themes easier to manage. Allow creation of custom Themes and save/load them from appropriate files.

5) Allow general IDE settings to be exported/imported into new version of PB. i.e Your Toolbar setup on the right side, and window splitter positions. You could also include other things such as settings from the general Preferences Menu having to do with Font settings, Code Folding, and other various options that can be ticked/unticked/modified.

6) I'm sure many people would appreciate having things like their compiler paths, etc migrated too.

In general I'd like to see most everything that would not interfere with an upgrade from one Version to the Next, be able to be Imported/Exported. Perhaps this means writing a simple Migration Tool that we can run, during the installation of a new PB, or manually?

Items 1 - 4 I consider personally important. #1 especially

1) You can simply copy the Templates.prefs file to the new version.

2) A project can contain more than one executable with different icons. So the setting is correct where it is.

3) A new menu item for this could be useful indeed.

4) You just have to put the images in a zip file and place it in the 'Themes' folder. I don't see how it can be any simpler.

5/6) You can copy the PureBasic.prefs to the new version and it will use all the old settings. Newer versions can read the settings of older versions without problems.

For 4) I think he's referring to custom color sets rather than icons. Custom color sets you could save to be choosable along with the default ones. For now you can only tweak the colors and save the one custom set in your .prefs file and import them later.

netmaestro wrote:For 4) I think he's referring to custom color sets rather than icons. Custom color sets you could save to be choosable along with the default ones. For now you can only tweak the colors and save the one custom set in your .prefs file and import them later.

+This. If I was talking about Icons I would have said "Icons" not Colors.


Anyway... Since multiple projects can have multiple EXEs, are you supposed to change the Compiler icon each and every time you compile an EXE? I'm not even sure how to compile two different EXE's under the same project, based on the current screens.

*Maybe that whole system should be simplified as well.. I see that falls under the Compile Targets after checking real quick..

But do Targets stay with the Global Compiler Options, or do they stay with individual projects?? See what I mean some of it is confusing.. I think it would really clarify and make some things simpler to Separate out the actual, essential compilers options needed for any project globally. Then store all those other things, such as Target Profiles, etc within the Projects Options /project settings file (if not already there)... The practicalities could be argued on. I just think it would make for a more intuitive Interface, especially for new users.

One last note: If the .prefs file is forward compatible, can we at least get an option in the Installer Setup to copy that file over? I don't think that's too much to ask, at least.

But this is all just my opinion. I am glad you have answers to most of my concerns and liked at least one of them.

freak wrote:5/6) You can copy the PureBasic.prefs to the new version and it will use all the old settings. Newer versions can read the settings of older versions without problems.

I don't use dual boot or virtual machines.
Instead I have low end XP, win7 x86, win7 x64 machines to troubleshoot on.

Are the *.prefs files aligned across all platforms?
The location of procedures and several other IDE items are never in the same place when I export and then import the prefs.
I never tried copying the *.prefs files directly.

My bad for mixing up Colors and Icons.

Zach wrote: I think it would really clarify and make some things simpler to Separate out the actual, essential compilers options needed for any project globally. Then store all those other things, such as Target Profiles, etc within the Projects Options /project settings file (if not already there)... The practicalities could be argued on. I just think it would make for a more intuitive Interface, especially for new users.

This is exactly how it works right now. The icon is a setting specific to the created executable, not the entire project. Why force all executables in the project to have the same icon?

Zach wrote:One last note: If the .prefs file is forward compatible, can we at least get an option in the Installer Setup to copy that file over? I don't think that's too much to ask, at least.

By default the preference files are stored in a shared location (the application data folder). So if you install a new version it will use the previous preferences by default. You have to explicitly tell the IDE to use a different location (with /LOCAL or /P) to change this behavior. So by default you get the previous settings after an update.

skywalk wrote:

freak wrote:5/6) You can copy the PureBasic.prefs to the new version and it will use all the old settings. Newer versions can read the settings of older versions without problems.

I don't use dual boot or virtual machines.
Instead I have low end XP, win7 x86, win7 x64 machines to troubleshoot on.

Are the *.prefs files aligned across all platforms?
The location of procedures and several other IDE items are never in the same place when I export and then import the prefs.
I never tried copying the *.prefs files directly.

The export function only covers the things that have a checkbox in the export dialog. Everything else is not exported/imported. The preference files should be compatible among one platform (Window for example), but you cannot copy one from Windows to Linux because they contain platform specific things like paths.

Cool, I will just move the *.prefs to and fro and bypass the import/export altogether.
Would the Windows to Linux conversions be simply path modifications?

This is exactly how it works right now. The icon is a setting specific to the created executable, not the entire project. Why force all executables in the project to have the same icon?

Well just to be sure I understand.. Does PB remember when you assign an icon to an EXE after you compile it, and always use that icon in future compilations? Or do you have to assign it each and every time? - If its each and every time, that would be my main concern, I guess. Just seems like a troublesome extra step. But if it remembers an icon until you decide to change it by assigning a new one, then that's fine I guess.

I wasn't advocating locking down each project so you could only use one icon, though. I guess my main point was to suggest removing certain things from the default compiler options, and have them only show up if you accessed the compiler options with a project open.

But I realize that would not work as some people would prefer to write something out in one code file without using a project and would lose access to those settings.


I will be perfectly happy to see Custom Color Themes saving/loading Slots and the changes to Add File to Project added though

The drag'N'drop feature to move selected code element within the source code.

Best regards.
Guimauve

Zach wrote: 2)Move the Executable Icon setting from Compiler Options, to Project Options where it really belongs.

Besides the fact that this is a compiler option and not a project option as the icon is added to the EXE at compile time, this is a very bad idea as it would force people to use "projects". I do not like the way PureBasic handles projects, so I don't use them. I would move to another programming language before being forced to use PB's projects.

I'm pretty sure I recognized that point in my concession already

Kuron wrote:

Zach wrote: 2)Move the Executable Icon setting from Compiler Options, to Project Options where it really belongs.

Besides the fact that this is a compiler option and not a project option as the icon is added to the EXE at compile time, this is a very bad idea as it would force people to use "projects". I do not like the way PureBasic handles projects, so I don't use them. I would move to another programming language before being forced to use PB's projects.

Would you share what it is that you don't like exactly? Just curious.

....I found PB's Projects very confusing/restrictive and decided not to use them.

My work organisation seems efficient enough for my needs, is there really a huge advantage in using Projects?

Are the none-project coders in the minority? I suspect that we are actually the majority........

freak wrote:

Kuron wrote:

Zach wrote: 2)Move the Executable Icon setting from Compiler Options, to Project Options where it really belongs.

Besides the fact that this is a compiler option and not a project option as the icon is added to the EXE at compile time, this is a very bad idea as it would force people to use "projects". I do not like the way PureBasic handles projects, so I don't use them. I would move to another programming language before being forced to use PB's projects.

Would you share what it is that you don't like exactly? Just curious.

Initially, I liked the Project features, but later found them restrictive and contrary to my work flow.

I love the ability to open a new Tab and paste in a template and then paste in a code tool or problem routine and just hit [F5].
When I had an open project, obviously the IDE wants to compile with those dependencies.
That's where the frustration begins.

This is only me, but with Xincludes and a few well placed Declares, I think the non-project IDE is lightning
What would make it even more fluid is more automation exposed.
I know you mentioned this is coming, and I will use whatever you deliver.

For me the lure to Project mode would be easier if you eliminated the needs for Xincludes and Declares.
But, this brings up the whole multi-pass compiler stuff, so I put that somewhere in the realm of OOP as far as ever coming to PB.

I agree I wish I didn't need to manually include files in Projects. But other than the issue I noted above in changing the Add File to Project behavior, I have to say I think it is pretty decent.
I always use Projects.

Generally if I want to play around with a piece of code, or test an idea before putting it in, I just open another instance of PB..