TODO
From Yzis Wiki
You can find here a list of tasks that have to be done for Yzis. The difficulty is indicated. This is a nice way to step into Yzis development. If you want to start one task, just notify us and we will provide some support.
Contents |
Junior Jobs
Junior Jobs are tasks that are not very difficult to perform, and represent a good opportunity to get familiar with Yzis.
Some tests require Lua or CMake skills. Both are very easy to pick up. And the forums are here to support you if you need any help.
Create cursor shape interface
Difficulty: easy
Skills: C++
Assigned: Donald Ephraim Curtis
Status: patch proposed by dcurtis, being evaluated
The problem is in the same spirit as for the status bar. Currently, qyzis manages the cursor shape by calling libyzis during its paint event. It should be libyzis that tells qyzis when the cursor shape changes.
- analyse qyzis use of cursor shape
- add cursor shape enum and methods to YZViewIface
- put the calls in Yzis to change the cursor shape when necessary (mode change, focus change)
run all tests in one row
Difficulty: easy
Skills: shell scripting
Assigned: Waiting for your | seems to be done
We have the current test suites:
- tests/scripts/run_scriptests.sh : tests written in lua
- tests/unit/unittests: unit tests written in C++
The idea is to be able to run them all with one command, to check in one step that everything is working fine. Steps:
- write a shell script that runs both test suites
- get the test suite results (resuls is either success or failure, no need to go into details) in shell
- display the results
- run that command when one types make run_tests
- check under at least : linux, windows, macosX. Even better with different linux distribution, some *BSDs..
More movements commands
Difficulty: easy
Skills: C++, lua
Assigned: David GAYOU, TANGUY Arnaud
- Check that Yzis has all the movement commands that vim has.
- Write lua tests to validate that all the movements commands behave exactly like in vim.
- Implement the missing commands.
More undo/redo tests
Difficulty: easy
Skills: lua
Assigned: Waiting for you
Yzis has undo/redo support but it is not very well tested at the lua level. The goal is to write many lua tests to validate that undo/redo work as expected.
TODO
Better Key Event system
Difficulty: medium
Skills: C++
Assigned: Waiting for you
Currently, key event is half based on a string containing the character, half-based on kind of meta-characters like <TAB> and <UP>. We need a better key event system. QKeyEvent is a good source of inspiration. We can not use QKeyEvent itself because it is part of QtGui and we only depend on QtCore.
YZKeyEvent should:
- support modifier for ALT, CTRL, SHIFT
- store the key being pressed
- support special keys, like <TAB>, <ESC>, <RET>, <UP>, ...
- provide a transformation string to keyevent, that is compatible with vim. The forms <TAB>, <C-A>, <ESC> are to be supported. We probably have more power than vim but we should be compatible in terms of key sequence description for mapping commands, or at least provide a compatibility mode.
- write some unit tests to prove that it works
- modify YZSession::sendKeyEvent()
- modify lua way of sending pseudo key event to yzis
- modify command line way of passing key event strings to yzis
Handle the modified state in the undo/redo
Difficulty: medium
Skills: C++, lua
Assigned: Waiting for you
Currently, the modified state is not restored when undoing or redoing. That means that if your file is unmodified, you do something and then undo it, the modified state will not be restored.
The undo stack should be improved to store the modified state along with an undo items, and set the buffer as unmodified when we return to a an unmodified state. Saving a document should also updated the undo stack so set which is the unmodified state.
A lua function should be added to check for the modified status from lua.
Some lua test scripts should be developed to check that is works in all situations.
Create script output interface
Difficulty: medium
Skills: C++, lua
Assigned: Waiting for you
Currently, Yzis has no way of displaying the output of a running lua script. Yzis lacks an output window for that task. The output window should also be used for displaying the output of running make and of other commands (grep, run_tests, ...)
The first step is to define an interface for this output window. Simplified proposition:
- void YZSession::showOutputView( bool show )
- YZOutputViewIface * YZSession::outputView()
- YZOutputViewIface::clear( const QString & area ) // erase the output view related to area
- YZOutputViewIface::sendOutput( const QString & area, const QString & output, int lineInfo=-1, QString fileInfo="" );
The idea is that the output window can show a list of lines. Each list of lines is associated with an area, so that it is possible to show different output for different areas (grep, build, unittest, ...). The area may be cleared, and shown. Lines can be added to the output view, with the possibility of specifying a file+line information. Later on the output view can be used to jump to areas of code according to the file+line information.
The design needs to be worked out a bit more (focus handling, key handling ?) but the first steps are here.
Check swapfile stuff
Difficulty: medium
Skills: C++
Assigned: Waiting for you
When looking at the log files, it seems that a swap file is created, then a second one is created. This should be sorted out.
Use latest kate engine
Difficulty: challenge
Skills: C++, KDE
Assigned: Waiting for you
The syntax highlighting engine of Yzis has been borrowed from kate. The problem is that it has diverged. Maintaining it against kate is a tedious task.
So we want to use the kate source code as bare as possible.
The goal that may not be achievable is to take the source code of the current syntax highlighting engine of kate and make it compile by providing stubs for things that we do not provide into Yzis. If the changes necessary are minimal and not too intrusive, we can propose a patch to the kate developers. The seemed quite opened about it. Refactoring is probably allowed as a mean to put away the things we do not want to compile.
Write a gtkmm frontend
Skills: C++, gtkmm
Assigned: TANGUY Arnaud
Status : Work in progress. Help is welcome.
Sources are currently here.
KDE TODOs
The yzis_kpart frontend depends on KDE 4, which is currently under development. Since we use the KTextEditor interface and kwrite/kate as our default shells, we should care about problems with these components.
Loading an editor component into kwrite/kate
Difficulty: unknown
Skills: KDE, C++
Assigned: Waiting for you
When you load the yzis_kpart into kwrite/kate via the settings menu, nothing happens. You need to restart the application for the changes to take effect. It is either necessary to load the editor component immediatelly or to give some feedback to the user. See this thread for more information:
http://lists.kde.org/?l=kwrite-devel&m=118069200809508&w=2
KWrite and Kate crash when editor component cannot be loaded
Difficulty: unknown
Skills: KDE, C++
Assigned: Waiting for you
See thread
http://lists.kde.org/?l=kwrite-devel&m=118063885920709&w=2
for more information.
Completed Tasks
Exhibit interface for status bar
Difficulty: easy
Skills: C++
Status: Completed by Adriaan
Currently, libyzis does not control the status bar. What happens is that each frontend fetches information from libyzis to display the frontend. The result is that the frontend fetches more often that necessary, or that libyzis forces a complete redraw just to update the status bar. Another unwanted side effect is that the status bar is not standardised accross frontends.
- analyse qyzis and nyzis use of status bar
- create a statusbariface.h with YZStatusBarIface
- create YZStatusBarIface * YZViewIface::guiStatusBar();
- for each frontend, implement the new status bar interface
- put the calls in Yzis to use the new status bar interface
Extend the KTextEditor interface
Difficulty: unkown
Skills: KDE, C++
Assigned: Bluebird
Status: Completed by Bluebird
The KTextEditor interface does not allow yzis_kpart to create/delete/switch buffers/views. See
http://mail.kde.org/pipermail/ktexteditor-devel/2007-June/000152.html
for more information.
