Difference between revisions of "Feature Ideas"
(→A small tutorial of the Object Oriented Programming)
(→A small tutorial for Object Oriented Programming)
|Line 81:||Line 81:|
===A small tutorial for Object Oriented Programming===
===A small tutorial for Object Oriented Programming===
I to have in Lazarus as in Eclipse in the Help menu a Tutorial for Object Oriented Programming.
Revision as of 07:51, 30 May 2008
This Page is intended to collect ideas for features that could be included in Lazarus. Putting an idea here does not mean it WILL be put into Lazarus. It's just a place to gather ideas. Think of this as more of a wishlist.
Also another place to log feature requests is here: Lazarus Bugtracker
- 1 IDE
- 1.1 Common
- 1.2 Object Inspector
- 1.3 Refactoring
- 1.4 I have a dream of components : Jedi
- 1.5 Code completion
- 1.6 Visual Form Inheritance
- 1.7 Conditional Compiler Options
- 1.8 Help
- 2 LCL
- 3 Other
Features that could be included in the IDE
Open files in the same folder as the current tab editor, like SCite does, it's a bit annoying to navigate from folder to folder every time you need open a file related to the one we are editing at the moment.
enable menu access through access keys like under windows (i hate mouse sessions :o) example: <alt>-<f> for file menu
- to allow final-user customisation
- to obtain more styled menu (similar as Shagrouni xp-menu style)
add a "search" text box at the top or bottom (preferred, maybe user settable) of Object Inspector to be able to search for a name or value (maybe with right click menu checkable options on whether Name or Value or both are searched) in the properties/events list
add a "Recent" tab to Object Inspector apart from the "Favorites" one, would be more useful than the Favorites one since it's automatic (would keep all properties/events that have been edited [fields that have either been changed or ENTER was pressed to CONFIRM/REset their current value - focus lost events shouldn't be considered editing if value of property/event field didn't change])
Add a field in the object inspector to allow specify the real class that will be instantiated, with that will allow to uses derived classes without remake/link the IDE, of course the new fields for the real class will not be available to edit in designer. An example: We place a TEdit in a form, but we want to use a derived class we made that add a new field/property/method to TEdit and we will use that new field/property/method programming but in design time it's enough to work with TEdit, actually there is an option to change the class but only to another one that's already linked on the IDE.
Global Variable/Method renaming
Proper renaming (as in if I rename a field in an object it can change everything that uses it but NOT other stuff that happens to have the same name) -Plugwash
- Already implemented: See Source Editor -> popup menu -> refactoring -> rename identifier
Parameter Renaming in Methods
adding a parameter to a method (and updating everything that uses it) -Plugwash
- How should that work? What should the IDE/codetools put as parameter at the places?
- You specify that when you ask for the parameter to be added. Plugwash 05:09, 30 September 2006 (CEST)
- For example, you add a parameter "b: boolean". The method is used a 100 times.
- Possibility 1: You add a default parameter too. No change to the using methods is needed.
- Possibility 2: You press compile and the compiler will jump to every occurence and you can decide, what to do.
- Possibility 3: A new dialog is added to the IDE, where you can specify to insert a ",false" at every occurence.
- Possibility 4: ?
Do you have 3 in mind or 4?
though thats not really needed in object pascal because object pascal has properties but its vital in cleaning up thrown together java. -Plugwash
- Please give an example.
Improvement of the IDE as GExperts for Delphi
- Multi lines tabs for the components palette.
- Editor tool bar. <I'm working on this>
- Procedures list. <I've already done this. It's part of Lazarus>
- Backup tool...
- Comment/uncomment selection: comment/uncomment the current line when no selection made...
- Indent/unindent selection: Indent/unindent the current line when no selection made...
- Tab : provision to set Tab spacing
I have a dream of components : Jedi
Sure I switch immediatly from Delphi to Lazarus.
Declare an object myObj:TMyClass into a TForm class an type some Ctrl-Shift-Key, then the IDE adds a line myObj:=TMyClass.Create in FormCreate and myObj.Free in FormDestroy. -Rednaxel
Add list properties
Declaring an indexed property like 'property Items[i: integer]: TAType' and using this feature (Ctrl-Shift-Key, Menu), should popup a dialog to setup some parameters and then it should add a private variable fItems: TFPList; (or 'array of' or TList or ^AType), create code in the constructor, destroy code in the destructor and access methods GetItems, SetItems.
Visual Form Inheritance
VFI (Visual From Inheritane) works in Lazarus but there are some missing features:
- When ancestor and descendant are open in the IDE and a property of the ancestor is changed, then change the descendant too.
- A dialog to easily create decendants.
[A bounty was created for this and accepted by Mattias.]
Conditional Compiler Options
A small tutorial for Object Oriented Programming
I wish to have in Lazarus as in Eclipse in the Help menu a Tutorial for Object Oriented Programming.
Components that are possible to make that will work across all platforms supported by Lazarus
- Already implemented: Help system for apps created by Laz! It is a plugin system. That's why it supports cross-platform help system and using the OS's native help system.
- The current LCL TStringGrid is a nice improvement over Delphi's feeble control with the same name. Would be great if it could be improved even more!
- Support for data validation event handler, similar to Orpheus grid's OnUserValidation event. There are many events, for example OnEditing todo this. Please be more specific, what this OnUserValidation is.
- Support for retrieving, displaying, editing and storing data that are stored in an existing memory structure or in a file rather than in grid itself, similar to the Orpheus grid's OnGetCellData and OnGetCellAttributes events. There is the TTIGrid, that can show TCollection, TList and TFPList of TPersistent. What else do you need?
- An TImage Component wich support transparent winxp alpha 32 bit icon images
- Add a TImageList property in TTrayIcon to change TrayIcon icon or animate it
- Clipboard and TTimer that don't depend on LCL. If you use these in a library or console app, the compiler drags in a lot of unused and unneeded LCL code. If you have multiple DLL's, this code is duplicated in each. Current implementations appear to follow the Delphi design approach, where Clipboard and TTimer have dependencies on the VCL - this probably wasn't necessary.
- This may be true on Windows, but it´s False for Linux. I recently implemented TTimer for qt interface and the implementation calls Qt API. I think the same applies to Clipboard, since the clipboard depends on the widgetset used too (gtk or qt for example), not only on the operating system. --Sekelsenmat 20:40, 5 Mar 2006 (CET)
- The LCL is a visual component library. None visual components are provided by the FCL.
- Lazarus will only provide components based on the LCL.
Something that currently does not exist is a complete multiplatform solution for PDAs. If we can implement this, Lazarus will become the first multiplatform RAD for PDAs ever created. Some devices work with Java, some work with c++ and Qtopia, some work with their particular APIs, there is no single solution currently that can embrace a large portion of PDAs. Application have to be redone for every PDA or simply just run on one of them (what most people do).
The LCL implements many things. It is not necessary to implement them all to have a reasonably working Lazarus PDA widgetset. The most important things to be implementeded for PDAs are:
- TCanvas and painting
- Most Events (onClick and OnPaint at least)
- Basic widgets like: TButton, TLabel, TEdit, TMemo.
- Only minimum nessary LCLIntf functions to make TCanvas work. (GetDC, ReleaseDC, BeginPaint, EndPaint and some painting functions)
Others can be easely implemented by people who need them after those are ready.
Here is a list of some PDAs and the status of their support on Free Pascal / Lazarus:
- Windows CE - The compiler already works really well cross compiling for Windows CE. The Windows CE Interface is under implementation.
- Symbian OS - Possible for their ARM devices. Requires first adding a new Runtime Library for this OS to the Compiler. This OS has it's own API. There are open source projects for python and c to work on Symbian OS, so Free Pascal should work as well when a RTL is written.
- Qtopia - For Zaurus and other linux-based PDAs. This is much easier now that basic Qt4 widgetset has being implemented, because Qtopia is very similar to Qt4. Some magick on the bindings is expected to make the same widgetset code to run for both Qtopia and Qt4.
- Java - Some handheld devices, specially phones, only support java bytecode. May seam a little odd, but there is a Pascal Compiler capable of compiling the source into a jar and then into bytecode. It's name is Midlet Pascal http://www.midletpascal.com/ It may be possible to develop a similar technology that adds a java bytecode target for Free Pascal.
- Palm OS - PalmOS 5 Garnet support requires that first the 68k compiler is working (runs on ARM processor with a kind of emulation) and then a RTL for palmos needs to be written. Only Free Pascal 1.0 supports 68k, this wasn't updated and the new compiler 2.0 doesn't support it yet (work in progress by fpc:User:Chain-Q), so will be a problem.
PalmOS 6 Cobalt is fully arm, so it only requires a rtl, but it has zero devices working on it currently and won't be on the market until 2007 at least.
Other compilers that support this target: Pascal & Palm Compiler and HsPascal. Unfortunately those compilers are not open source, so we can't use their code, we need to implement PalmOS RTL from zero.
- Cocoa - Requires that first OpenSTEP bindings are created for Free Pascal.
- BeAPI - interface for Haiku, ZetaOS and BeOS. There is no powerful RAD on this OS.
- SDL - something like what was done in Pixel Image Editor.
- MacApp 2.0 - For 68k-based Mac computers. MacApp was Apple Computer's primary object oriented application framework for the Mac OS for much of the 1990s. First released in 1985, it is arguably the first such system to be widely used, notably on a microcomputer platform. Microsoft's MFC and Borland's OWL were both based directly on MacApp concepts. This framework was completely written on Object Pascal, so it should integrate really nicely with Free Pascal and Lazarus. When Apple moved to PowerPC it also dropped Object Pascal support, but that's another story. A emulator for 68k-Mac can be easely set up with BasiliskII. There is also a project called MacApp2PPC that upgraded MacApp pascal code to run on Power PCs.
- OS/2 native - Free Pascal works well with OS/2, so this should be quite possible.
- Solaris - OpenSolaris versions exist and it's quite similiar to Linux so why not ?
- Web Interface - Application compiles to an embedded HTTP Server who serves forms in ajax pages (or compiles it to an Apache Module), like Intraweb in Delphi. Discussion in http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=viewtopic&t=2489
- fpGUI - A widget set written in Free Pascal without any large library requirements. fpGUI talks directly to the underlying graphics library and is very easy to port to new platforms. Currently it supports Linux, Windows and WinCE. - Under development here: fpGUI_Interface
- Support for Lua interfacing. (Binary moduals?)
- What is Lua interfacing? Is it a graphical widgetset? What is the difference between what you want and is supplied by the lua units of fpc: http://svn.freepascal.org/svn/fpc/trunk/packages/extra/lua/