Text::Editor::Easy::Abstract - The module that manages everything that is displayed.
This is an internal module. It implements the graphical part in an abstract way : it should be compatible with different user interfaces, but at present, it works only with 'Tk'.
This module is used only by the graphical thread, with tid 0. All other threads that want to make graphic actions have to use the object interface : calling graphical methods on "Text::Editor::Easy" instances will be redirected here, in this module, and will allways be executed by the graphical thread.
Have a look at Text::Editor::Easy::Comm if you want more explanations about thread communications.
There are 2 (or 3 if we include the Text::Editor::Easy::File_manager module) complex modules in the "Text::Editor::Easy" tree. This module and the Text::Editor::Easy::Comm which handles communication between threads.
If you create a "Text::Editor::Easy" object, this 'Abstract' module will be called very often. Lots of methods are redirected here (but you don't even have to know that this module exists).
At the beginning (in 2006), there was only this "module-program". Little by little, this module has grown and has soon become an ugly mess (well, it still is !). When I decided to access the "text data" to be displayed in an another module, it became much simpler. At this very moment, I began to use more than one thread, and the number of different modules grew rapidly. This was the very good thing threads have brougth me : simplification by partition.
This module has only limited knowledge of what is in the file. It knows only what it has to display according to the police size and to the screen size.
When there is space to fill up, it asks "File_manager" for data. "File_manager" can provide data before or after a referenced line. When the user modify something, this module informs "File_manager".
As soon a line is no more on the screen, this module forgets it (destroy it for speed reason) : it relies entirely on "File_manager" to memorize what should be.
This trick has a big advantage. In fact, with my module, you can Edit text file of unlimited size with the same speed as little file. Not much Editors can do that. For huge file, my perl Editor is still usable whereas most C Editors are not. Of course, you could develop a C Editor with the same principle, ... good luck. With perl, it's just funny. In C, it's hard work.
Affectation of code to a specific key for a specific instance (initial instance call "bind_key")
Affectation of code to a specific key for all instances (initial class call "bind_key")
Retrieve the content of the clipboard (for paste operation)
Set the content of the clipboard (for copy operation)
Test for future use of motion event according to position (borders of Text::Editor::Easy::Zone to resize them, for instance).
What is on the screen according to Abstract... ?
Return the middle ordinate of a displayed line.
Selection of visible text that matches the search.
When an Text::Editor::Easy instance is created, data is created in several modules and for several threads. Destruction is not properly done at the moment.
Deselection of a single line.
Set the content of a line.
A zone event called when an editor has been closed : useful to change the tab state.
Event used to update Text::Editor::Easy configuration.
Returns the reference of the Text::Editor::Easy instance that is above the other.
Copy the clipboard content to the cursor position.
Prevent space to appear at the bottom (after the last line) or at the top (before the first line).
Copyright 2008 - 2009 Sebastien Grommier, all rights reserved.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.