[tekui-devel] x11 input misbehaviour

szbnwer at gmail.com szbnwer at gmail.com
Thu Dec 22 23:58:47 CET 2016


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

sure, many thx for your help! :)

[...]
> 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.

thx, im still feeling myself a bit dumb for this kinda work, but i
really investigated so much time and effort before i asked for help :D

[...]
> 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.

quality comes 1st :) you could use tekui like i do. there is an input
area where i'm editing my codes, i'm exectuting them with ctrl+r and
there is an out() function which collects my output into a table which
is concatenated and putted into an output field. so i'm writing a new
function, calling it with some desired input, out() the results, and i
can see in a very short circumstance if i reached my desired goal.
then i'm putting the final result out from this 'lab'. kinda much
everything is already given in tekui demos for making this, and much
better than re-run a whole application, or single lines in repl and
watch a terminal for output...

[...]
> 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.

i think thats good only for puc lua, and i wanna bring every
development inside my app, and c is not the best for that, even if i
have restart and i can compile via os.execute, everything outside lua
can make my stuff slower only i think... now i have to count with some
bash for install and run my app, the makefiles, c and c
preprocessor...

> 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.

have you tried to measure the difference in luajit? i wouldn't go back
to puc lua, i can see huge additional performance while i succesfully
set up the luajit based environment.

> 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).

thanks for this hint, i'm still just discovering my equipments, i can
see that both are maintained (same versions). this is my 1st project
in the entire world of lua, previously i just played around with
frontend and python for many years. i saw so much codes, languages and
technologies, and i started my project in python with tkinter but
those are slow messy and huge. so i've searched for more powerful
tools and i think i've found the bests. i needed performance,
flexibility and minimalistic handleable background.

> 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.

i don't really want to change from x11 driver til its mainstream on
linux, i want to buid a powertool for making automatizations,
handlers, and the programming easier.

1st i was interested in multiplatform things, but as i'm not using win
and mac (for so many reasons, and i'm even against them) i won't be
abled to keep compatibility with them for my project, and thats also a
huge amount of work, and their world is kinda like mordor for me. i
wanna make linux experience better and easier, but i have so much
plans and it wouldn't fit into a lifetime to make it so for every
platform, so i've just chose the best from everything. anyway its
still just a private project, because i've got serious plans and i
don't wanna let big fishes to just disassemble its values and make my
work trashy, so it's now in its incubation period. now i have a big
fullstack job, and this takes my time away from developing this
project, so this period can be long. i think whenever it gonna be
public you will know, just because i respect your work so much. :)

i still didn't go deep in luajit and tekui to change anything, because
first i need some more tools for manage these works, but i'd like to
give back anything to both of these great projects.

[...]


More information about the tekui-devel mailing list