WIP, probably doesn't compile.
Working to introduce the RenCache object as an argument to the renderer.draw_*
operations from the Lua side.
To not disrupt the existing code the first argument, the RenCache, is added optionally.
If not given the global window's RenCache object is used.
Work in progress, do not compile and it is largely incomplete.
The idea is to implement a new command into the rencache, DRAW_IMAGE.
The command should blit into the rendering surface a rectangular
portion of a given image.
We should have a "repository" of images to be used for this operations.
Each image should be identified by an image ID. The image ID in turn
should have three components:
- the node the image belongs to (each node can potentially produce
multiple images).
- an identifier of a specific rect withing a specific image of the node.
For example
for a DocView we may divide the document in pages and draw each
page in a different image. We should in addition divide the image in
rects so that an update in the image does not trigger the update
of the whole image but only of a pert of it.
The page and the rect within would provide a way to index
the image.
- an identifier of the "revision" of the image. The idea is that to
trigger an update upon a DRAW_IMAGE command the image_id has to
change. If the image is always the same the "revision" number will
track updates within an existing image.
In turn we should allow the views to render into an image and then
issue rencache commands to draw parts of the image (rects) using
the DRAW_IMAGE command. This part is not yet implemented.
Previously rencache was always implicitly performing rendering in
the application's window. Now by using RenSurface the rencache
is explicit about where the rendering operations should be done.
In turn the RenSurface object can point to the surface underlying
a RenWindow object or to an offline surface. In the first case
the rendering operations are done in an active window while in the
second case are done into an intermediary surface.
Currently RenSurface is only used pointing to a RenWindow. The plan
is to let some Views write into offline surface and let them perform
a new rencache command to copy the surface into the final output.
Now we put all the data needed by rencache into a struct and pass a pointer to
the struct to all the rencache functions to make it reentrant.
A global rencache struct is declared now in main.c so all the
operations will work in the same way except we always pass the
pointer to rencache struct.
This work is meant to transition into a system where the rencache
machinery can be used to render and update a part of the window.
Currently the rencache performs all the drawing operations into the
implicit window's surface. Future work may change this so that rencache
can write into an arbitrary surface.
* allow nested directories to be created
* fix / be turned into //
* refactor error handling
* refactor path splitting and mkdir calls
If a path exists it will now return immediately.
* fix typo
* remove possible trailing empty string
* fix bugs with path check
* Retrieve scale plugin from lite-plugins
* New implementation of scale plugin and font C API
Introduce two new C API functions, renderer.font.get_size and set_size
respectively to get the font size and to set the size to a new value.
Using these functions we don't need to know the name of the font but
we can just change their size.
Adapt the scale plugin to use the new C API function with minor adaptations
in the logic.
Use smaller step to scale fonts.
Rename font_desc_free function, previous name was misleading as only the cached
resources are freed.
* Add contextmenu plugin from takase
From https://github.com/takase1121/lite-contextmenu
Adapted to show font scaling commands and find/replace commands.
i# testing.lua
* Fix the cursor flickering with contextmenu
To avoid flickering of the cursor when using the context menu
we add a new function `core.request_cursor` that just take note
of the cursor requested.
The cursor will be actually changed only in root_view:draw() method
only when all the drawing operations are done. This means the cursor
will be changed only once per frame and only the most recent cursor
change request will take effect.
* Remove unneeded scale plugin return functions
On macos 11.2.3 with sdl 2.0.14 the keyup handler for cmd+w was not
enough. Maybe the quit event started to be triggered from the keydown
handler? In any case, flushing the quit event there too helped.
Use resolved executablePath instead of resourcePath to allow lanching
the lite-xl binary via a symlink, like typically done by Homebrew:
/usr/local/bin/lite-xl -> /Applications/lite-xl.app/Contents/MacOS/lite-xl
The resourcePath returns /usr/local in this case instead of
/Applications/lite-xl.app/Contents/Resources, which makes later
access to the resource files fail. Resolving the symlink to the
executable and then the relative path to the expected directory
Resources is a workaround for starting the application from both
the launcher directly and the command line via the symlink.
Use regular expressions instead of Lua patterns for find and replace editor commands.
Syntax files can now use regex or Lua patterns as before keeping backward compatibility for plugins.
In order to stay simple and closer to the lite's design principles we
deprecate the core.add_save_hook function and the related mechanism.
Instead we now directly override the Doc:save() method.
The method is already overrided from core.init to add the automatic
reloading of style when user's module is saved.
The cleanup is related to the discussion in issue #229.
The bug was actually due to a presence of a ghost tab scrolling button
in all the views.
We need to check if the node has multiple views, if not there are no tabs
and therefore no scrolling button areas so we return nothing from the
method Node:get_scroll_button_index().
Close#216
When the number of files in a project directory is above the max
limit switch back to a mechanism to read directory content only
when the corresponding folder is expanded in the treeview.
When the command core:find-file is invoked the command core:open-file
is executed instead because the complete list of the project's
files is not available.
When a project search is done we search through all the files within
the project dir without indexing them.
Address issues #217#203#183.
* Indent enhancements.
* Fixed to match style guidelines.
* Added in useful explanatory comment.
* Changed which selection we're using, as we don't want this kind of wrapping to happen.
* Fixed bug involving lines full of whitespace.
* Removed unecessary commit.
* Actually reverted function, so that we don't screw up commenting.
* Fixed hard tab issue.