LÖVE

Darlex wrote: ↑Sun Jun 30, 2019 8:24 pm
THANKS! That's way better than my idea! Your GUI project is one of the only ones that doesnt make my brain explode! Send ya good vibes!

Hey Darlex, appreciate the support! The new version just released now has support for highlighting words as well as getting and setting the cursor position. Hope this helps out in your project.

pgimeno wrote: ↑Sun Jun 30, 2019 8:47 pm

coding.jackalope wrote: ↑Sun Jun 30, 2019 7:13 pm I've had plans to add text highlighting to the Input control. I like the idea of specifying the words to highlight like in your example so I'll have something like:

Code: Select all

Slab.Input("code_input", {
	Text = examplecode,
	MultiLine = true,
	H=500, W=500,
	Highlight = {{"function", {0, 0, 1, 1}}, {"end", {0, 0, 1, 1}}, {"local", {0, 0, 1, 1}}, ...}}

where Highlight is a table that takes in a list of words and what color the word should be highlighted in.

Wouldn't it be better to have the words in a table where the keys are the words to highlight? That would avoid more objects, and the lookup would presumably be faster. Iterating would be slower, though, if it's necessary at all.

To put it explicitly, this is what I mean:

Code: Select all

Highlight = {["function"] = {0, 0, 1, 1}, ["end"] = {0, 0, 1, 1}, ["local"] = {0, 0, 1, 1}, ...}

pgimeno, this is a good idea and I went ahead and implemented passing the highlight option in this way. Thanks!

coding.jackalope wrote: ↑Wed Jul 10, 2019 10:28 pm

Darlex wrote: ↑Sun Jun 30, 2019 8:24 pm
THANKS! That's way better than my idea! Your GUI project is one of the only ones that doesnt make my brain explode! Send ya good vibes!

Hey Darlex, appreciate the support! The new version just released now has support for highlighting words as well as getting and setting the cursor position. Hope this helps out in your project.

pgimeno wrote: ↑Sun Jun 30, 2019 8:47 pm

coding.jackalope wrote: ↑Sun Jun 30, 2019 7:13 pm I've had plans to add text highlighting to the Input control. I like the idea of specifying the words to highlight like in your example so I'll have something like:

Code: Select all

Slab.Input("code_input", {
	Text = examplecode,
	MultiLine = true,
	H=500, W=500,
	Highlight = {{"function", {0, 0, 1, 1}}, {"end", {0, 0, 1, 1}}, {"local", {0, 0, 1, 1}}, ...}}

where Highlight is a table that takes in a list of words and what color the word should be highlighted in.

Wouldn't it be better to have the words in a table where the keys are the words to highlight? That would avoid more objects, and the lookup would presumably be faster. Iterating would be slower, though, if it's necessary at all.

To put it explicitly, this is what I mean:

Code: Select all

Highlight = {["function"] = {0, 0, 1, 1}, ["end"] = {0, 0, 1, 1}, ["local"] = {0, 0, 1, 1}, ...}

pgimeno, this is a good idea and I went ahead and implemented passing the highlight option in this way. Thanks!

Thanks for listening! (more like reading but anyways) and thanks for making my engine possible!

Slab v0.6.0


Hello everyone. Version 0.6.0 has been released. This release adds API functions to allow how controls are organized within a window. Slab now offers users the ability to add project specific stats and can be quickly viewed through the Slab Debug module. The Slab Test module can act as a good reference point for the API. For more information on the update, refer to the wiki page: https://github.com/coding-jackalope/Slab/wiki.

Layout
The layout API allows for controls to be grouped together and aligned to a specific position based on the window. These controls can be aligned to the left, the center, or the right part of a window horizontally. They can also be aligned to the top, the center, or the bottom vertically in a window. Multiple controls can be declared on the same line and the API will properly align the controls on the same line.



Stats
The Slab API offers functions that track the performance of desired sections of code. With these functions coupled together with the debug performance window, end-users will be able to see bottlenecks located within their code base quickly. To display the performance window, call the SlabDebug.Performance function.



Fonts
Fonts can be pushed to a stack to alter the rendering of any text. All controls will use this pushed font until the font is popped from the stack, using the last pushed font or the default font. Below is an example of font being pushed to the stack to render a single text control and then being popped before the next text control.



As always, if anyone has any comments, questions, or suggestions, feel free to reach out and let me know.

Cheers for this, was really interested in imgui but the lack of documentation around it (among other things) was pretty off putting. This is great so far .

twe wrote: ↑Sat Aug 17, 2019 1:24 am Cheers for this, was really interested in imgui but the lack of documentation around it (among other things) was pretty off putting. This is great so far .

Thanks twe! Hope this is helpful for your projects. If you run into any issues or have any questions, let me know.

Thats really smooth and impressive jack. Text and layout based controls have come a long way!

I'm impressed with the evolution of this library. The text editing widgets are the hardest to get right, and they are working pretty smoothly, including multiline. Congrats.

I've found a quoting problem which could become a security problem. The quoting of command-line parameters in commands executed via os.popen is insufficient in Linux and OSX. I've created a patch: https://notabug.org/pgimeno/Slab/pulls/1 together with other Linux&OSX fixes.

However, this method for file list retrieval should be a last resort when every other alternative is exhausted. As I see it, there are at least three alternatives, in order of preference:

1. LoveFS: https://github.com/linux-man/lovefs is probably the best option. It includes Gspöt to offer a LÖVE native file dialog, but you could include a trimmed down version that removes the GUI.
2. Love-FML (Filesystem Mapper Library) by zorg, https://github.com/zorggn/love-fml, but I'm not sure it's ready for production use.
3. lua-filesystem (lfs), https://luarocks.org/modules/hisham/luafilesystem. This is a binary dynamic library, which of course is problematic for cross-platform deployment.

pgimeno wrote: ↑Fri Nov 01, 2019 11:06 pm ...
However, this method for file list retrieval should be a last resort when every other alternative is exhausted. As I see it, there are at least three alternatives, in order of preference:

1. LoveFS: https://github.com/linux-man/lovefs is probably the best option. It includes Gspöt to offer a LÖVE native file dialog, but you could include a trimmed down version that removes the GUI.
2. Love-FML (Filesystem Mapper Library) by zorg, https://github.com/zorggn/love-fml, but I'm not sure it's ready for production use.

Unfortunately, i can't recommend Love-FML as of yet, mostly because of the fact that it can't currently handle multiple active write directories; this is not going to change since it's a limitation of PhysFS that löve uses internally (since the library itself just mounts the real filesystem root(s) into the virtual filesystem), so i'd need to cheat and implement file saving another way (lua io won't work since at least on windows, it fails with non-1byte characters)

I looked into lovefs, maybe i can utilize some of the tricks that uses, that said, from the code i can see that it's not perfect either, in that it only has loading functions for images/audio/fonts and a saving function for images (no generic read/write/append stuff); that said, even those are implemented by temporarily copying things into the save folder, or saving there and moving the file to the wanted directory afterwards... that can be an issue with larger files.

From a security standpoint, i'm not sure whether mine or loveFS is "worse", although directly doing stuff with popen isn't the best either, as pgimeno already said.

zorg wrote: ↑Sat Nov 02, 2019 10:45 am Unfortunately, i can't recommend Love-FML as of yet, mostly because of the fact that it can't currently handle multiple active write directories;

Thanks for chiming in.

The purpose for this library (or a GUI library in general) is usually just to be able to enumerate files and directories in the disk; it's up to the user how to use the returned paths. Therefore, I think that that limitation is not important.

If that's the only problem, I'd say it's suitable for this usage.

Sure, just saying that with my lib's main concern is trying to work around PhysFS limitations while still... promoting, i guess (for me lacking a better word for it) love.filesystem usage instead of anything else (with the one write issue mentioned earlier that i hope to fix in the coming weeks) so it's not exactly something that has an ls/dir functionality apart from the fact that it's not needed since you can always iterate over a specific mounted path with love.filesystem methods (and re-iterate if the actual FS has been changed from the outside).