New IDE
The IDE requires Qt 4.6.
Unfortunately, this version is not available yet from a few package repositories but it's merely a matter of time.
As a workaround, in this cases, it's possible to install the current SDK.
Important: This pre-compiled binary build (ide_a11.7z) is only suited for 64 bit architectures. A 32 bit build can be compiled from the sources being included.
Unfortunately, this version is not available yet from a few package repositories but it's merely a matter of time.
As a workaround, in this cases, it's possible to install the current SDK.
Important: This pre-compiled binary build (ide_a11.7z) is only suited for 64 bit architectures. A 32 bit build can be compiled from the sources being included.
New Version
Meanwhile I have extended the IDE significantly. Therefore, I’d like to show my new stage of work here. :-)
Switching to Scintilla as the main text edit control of the IDE
I have decided to switch to Scintilla, which is a very advanced text editing component. This change will permit several improvements and lots of new features in the next releases, as for example
The IDE was given new syntax highlighting routines being able to deal with multi-line comments and preprocessor directives correctly. Moreover, the new highlighting function works much faster than the old implementation. Due to using Scintilla, personal settings concerning font sizes and font faces are possible.
New GUI designer!
A new form designer (RAD) has been integrated in the IDE. At the moment it allows creating Windows-GUI applications but in future it will be able to export GTK-based GUIs also.
The embedded form designer creates XML files as a description of the forms. This approach can be compared to the FRM files known from VB. When compiling your application, the IDE exports temporary FB source code based on the information given in the XML file. The form designer is able to load existing XML GUI definitions. So you’re able to continue your work at the GUI after closing and restarting the IDE / your computer. ;-)
Within the designer, new controls are chosen out of a treeview (widget tree) and not by clicking buttons any more. Using another treeview you can manage the created controls (similar to the project explorer in VB). Furthermore, you can delete existing controls you don’t need any more.
Technical aspects: The GUI designer loads all the controls from control definition files (XML format) dynamically. Also the code (behavior of controls, methods) are stored in these XML files. The relationship between control properties (width, height, ...) and the preview in the design environment is implemented by scripting. Therefore, you can change the way a control looks and behaves in the IDE by editing the XML files.
The approach of XML-based control definitions allows easy adding and modifying of controls. It’s a bit like an open OCX system. ^^
Important notice: Currently only an pre-alpha preview version of the GUI designer is available for download. So please bear with me while I’m working on it. ;-)
New project files
As a result of having restructured the file format of the project files used by the IDE, it’s not possible to open legacy project files any more. But the new project files allow a few improvements. Individual compile profiles (sets of fbc command line parameters for different purposes) are supported (e.g. „Debug“ and „Release“). They can be applied using a ComboBox in the IDE. Moreover, project files now contain relative paths, thereby allowing the user to move project folders without having to edit those files. ;-)
But still all the files belonging to one project have to be in the same directory. This will be changed in future releases.
New configuration dialog
The new configuration dialog doesn’t contain all the settings I’d like it to have, yet. But on the other hand it allows the user to configure the syntaxhighlighter. :-) In the next releases the config dialog will be extended of course.
Many thanks in advance for your opinions!
Kind regards,
Stueber
Switching to Scintilla as the main text edit control of the IDE
I have decided to switch to Scintilla, which is a very advanced text editing component. This change will permit several improvements and lots of new features in the next releases, as for example
- calltips (a syntax-suggest function as known from VB)
- auto-completion of code
- folding of code structures (if-then-else statements, loops etc.)
- live syntax-checking
- zoom-in and zoom-out
- indention
- line numbers
The IDE was given new syntax highlighting routines being able to deal with multi-line comments and preprocessor directives correctly. Moreover, the new highlighting function works much faster than the old implementation. Due to using Scintilla, personal settings concerning font sizes and font faces are possible.
New GUI designer!
A new form designer (RAD) has been integrated in the IDE. At the moment it allows creating Windows-GUI applications but in future it will be able to export GTK-based GUIs also.
The embedded form designer creates XML files as a description of the forms. This approach can be compared to the FRM files known from VB. When compiling your application, the IDE exports temporary FB source code based on the information given in the XML file. The form designer is able to load existing XML GUI definitions. So you’re able to continue your work at the GUI after closing and restarting the IDE / your computer. ;-)
Within the designer, new controls are chosen out of a treeview (widget tree) and not by clicking buttons any more. Using another treeview you can manage the created controls (similar to the project explorer in VB). Furthermore, you can delete existing controls you don’t need any more.
Technical aspects: The GUI designer loads all the controls from control definition files (XML format) dynamically. Also the code (behavior of controls, methods) are stored in these XML files. The relationship between control properties (width, height, ...) and the preview in the design environment is implemented by scripting. Therefore, you can change the way a control looks and behaves in the IDE by editing the XML files.
The approach of XML-based control definitions allows easy adding and modifying of controls. It’s a bit like an open OCX system. ^^
Important notice: Currently only an pre-alpha preview version of the GUI designer is available for download. So please bear with me while I’m working on it. ;-)
New project files
As a result of having restructured the file format of the project files used by the IDE, it’s not possible to open legacy project files any more. But the new project files allow a few improvements. Individual compile profiles (sets of fbc command line parameters for different purposes) are supported (e.g. „Debug“ and „Release“). They can be applied using a ComboBox in the IDE. Moreover, project files now contain relative paths, thereby allowing the user to move project folders without having to edit those files. ;-)
But still all the files belonging to one project have to be in the same directory. This will be changed in future releases.
New configuration dialog
The new configuration dialog doesn’t contain all the settings I’d like it to have, yet. But on the other hand it allows the user to configure the syntaxhighlighter. :-) In the next releases the config dialog will be extended of course.
Many thanks in advance for your opinions!
Kind regards,
Stueber
It's nice to see you making progress. Scintilla is the best choice and RAD for FB is always eagerly awaited :p
Some thoughts:
I see no new or special concepts (compared to existing IDEs).
Please don't forget about possibilities of UI design: Which existing elements will never be used? What's missing?
Avoid making everything configurable.
I don't think including a webbrowser is a good idea: too heavy, everyone has one already.
(biased opinion: I don't like IDEs much, especially the all-in-one monsters)
Some thoughts:
I see no new or special concepts (compared to existing IDEs).
Please don't forget about possibilities of UI design: Which existing elements will never be used? What's missing?
Avoid making everything configurable.
I don't think including a webbrowser is a good idea: too heavy, everyone has one already.
(biased opinion: I don't like IDEs much, especially the all-in-one monsters)
Re: New Version
Ever considered not creating source code to instantiate a form, but stream the form as objects properties to a resource file? And then stream the object back into mem on instantiation.Stueber wrote:
New GUI designer!
A new form designer (RAD) has been integrated in the IDE. At the moment it allows creating Windows-GUI applications but in future it will be able to export GTK-based GUIs also.
The embedded form designer creates XML files as a description of the forms. This approach can be compared to the FRM files known from VB. When compiling your application, the IDE exports temporary FB source code based on the information given in the XML file.
The principle can be tighter(*) (only one load routine for all forms), and can be (minorly) postedited for internationalization purposes. (e.g. make a caption slightly longer, since in many languages phrases are longer than in English)
(*) smaller for large apps (streamed objects are more compact than instantiation code), usually larger for small apps (since RTTI pulls in objects that might not be streamed, unless all GUI widgets are in a dll/so)
If you are German (guestimate on your name), you can mail me directly at marco at freepascal dot org. My German skills are not that great, but maybe better than your English.Stueber wrote:Because QtWebkit. I use QtWebkit for reading the german reference.WOW 10MB 7z package, why is so big?
@marcov: I answer you later, first I have to translate your post. (My englisch skills are weak) :)
If I understood you right, you say that loading at runtime is better than converting the XML to basic sourcecode.
Both have a lot of pros and cons.
Translating the UI of a programm is easier when the XML file is loaded at runtime but converting to basic code is more dynamic and easier to implement for me.
All in all I think converting to code is better but if you know more reasons for loading at runtime I could implement both and give the user the choice.
Both have a lot of pros and cons.
Translating the UI of a programm is easier when the XML file is loaded at runtime but converting to basic code is more dynamic and easier to implement for me.
All in all I think converting to code is better but if you know more reasons for loading at runtime I could implement both and give the user the choice.
No, I asked if you considered it, and named some of the pros.Stueber wrote:If I understood you right, you say that loading at runtime is better than converting the XML to basic sourcecode.
Both correct. The latter is nearly always true, the better, more fundamental approaches need more work, and often backend changes (e.g. in this case higher percentage OS dependant due the need to support resources multiplatfomr)Both have a lot of pros and cons.
Translating the UI of a programm is easier when the XML file is loaded at runtime but converting to basic code is more dynamic and easier to implement for me.
I named the major ones already. (postediting, tighter code). The ability to postedit is btw also a disadvantages (since it is easier to do malicious edits, e.g. removing copyright notices, or making them invisible)All in all I think converting to code is better but if you know more reasons for loading at runtime I could implement both and give the user the choice.
Runtime loading (but not in resources) is of course also important to store form layouts in databases or client server apps. This is mostly useful if the used components in the forms databind automatically, this way fields can be added by db-admins, and client apps need to be updated less often.
The only advantage of codegeneration is that form instantiation can be debugged a bit easier. Stepping through the generic loading code is possible, but a bit more involved. But usually this is fairly uninteresting, except for a developer who can always make an unittest in code, or reduce the impact by choosing breakpoints smartly.
I don't think that XML is good for runtime instantiation though. Better some more tight format. (validating XML parsers are quite bulky or external dependancies, and the forms will be bulkier, while there is not that much benefit compared to a simpler format)