[tekui-devel] x11 input misbehaviour

Timm S. Mueller tmueller at neoscientists.org
Thu Dec 22 12:56:29 CET 2016


On Tue, 20 Dec 2016 20:44:31 +0100
"szbnwer at gmail.com" <szbnwer at gmail.com> wrote:

Hello,

please bear with me, I will get back to your mail in due detail.

> i have a problem around input and keycodes, that i can't resolve for a long
> time now
> 
> i'm using newest ubuntu mate x64, with x11 driver, and all default settings
> in tekui, (except for prefix), i'm using luajit, but the same behaviors
> were here previously, when i started with plain lua, where i've tried 5.1,
> 5.2 and 5.3 as well
> 
> so i'm using a hungarian keyboard, and i've got no őűŐŰ characters, and
> even others are misconfigured as shown below (1st line is from tekui, 2nd
> is excepted):
> [..]

Testing with a hungarian keyboard layout should be possible and reveal
the problems to me. On this occasion I should probably test with some
other, e.g. french, spanish, belgian, etc. layouts as well.

> and there are some misbehaviors:
> pressing enter in a multiline input before last letter not dropping the
> letter into the next line
> selection background sometimes breaks, but selection works fine even then,
> its happening, when a multiline input gets focus just when i'm about to
> select text, i think the bug is around the messages
> horizontal scrollbar not works with the multiline input, i didn't try to
> set up messaging between them manually, i think its something around fake
> canvas width or half done implementation
> clipboard working only inside an app or system clipboard can be copied into
> the app, but it can't be copied from app and used system wide

There are shady areas in the multiline input and editing class which
are difficult to trace and correct, this is one of those areas where
90% of the work is spent for the remaining 10% of issues. Life is
miserable with an almost uncompromising insistence on non-overlapping
repaints, this pedantry causes a lot of headaches later.

> it took me a very long time to understand a lot about tekui, it's just
> about to becoming something like clean, but i've read its codes and docs
> much, but i'm still not a c, nor an x11 expert, but i'm still investigating
> into the solution, cuz i really like tekui so much, thx for this great
> stuff, i didnt find anything better out in the wild, and i'm popularizing
> it much all around :D
> 
> anyway what about that plan, that you wanna bring down a lot from lua to c?
> how far, and how this affects luajit? i understood, that i can't lift up
> everything into lua, because of the c libraries like x11. i know, that
> luajit can optimize only codes written in lua, but it will call c functions
> anyway, but i've got no idea about the results of more or less c code where
> some must exists. like complex bigger units with possibly fewer calls into
> c, and less optimalized lua code above, or more smaller c functions, with
> more calls, and more optimizable lua codes above...

We do not regret writing so much code in C, but I wouldn't move much
further into C territory either, but rather focus on features,
completeness and resolving issues.

Drawing the line between Lua and C has been an interesting topic and
constant challenge with tekUI, and this line has been moved far into C
territory during its lifetime, causing a huge amount of work (see for
example tek/ui/class/area.c and tek/ui/layout/default.c), but also huge
performance rewards. With LuaJIT and considering that with FFI you can
call even into foreign C libraries, I think that the project is now at
a sweet spot in this regard.

The Lua versions of certain libraries are still there. In etc/, the
following classes and libraries, which are now written in C, are also
available in Lua: tek/ui/class/frame, tek/ui/class/area,
tek/ui/layout/default, tek/lib/region. If you wish to use their Lua
versions, simply move them to their respective place in the filesystem
hierarchy (and possibly remove the shared object of the same name).

On the other hand, nothing keeps you from writing a display driver in
plain Lua, which may exploit FFI and LuaJIT and redirect its output to
SDL for example. And there is more that can be done. For example, it
should be possible to load Lua into a Javascript interpreter on the
fly. There are probably some caveats, application-specific and
performance issues to be resolved, but it should nevertheless be
possible to run a tekUI application in a browser by "just" using a
Lua-to-Javscript loader, an adapted display driver, and porting a few
missing C libraries (for which there is currently no Lua version) back
to Lua.

> thanks for your time and any help, and all the bests for you! :)

Thank you and kind regards,

-- 
Timm S. Mueller <tmueller at neoscientists.org>


More information about the tekui-devel mailing list