Open ApostolosB opened 8 years ago
some bindings will certainly not be difficult to fix, other will be harder, especially the help one, which is not simpler, according to what i have in mind :)
Ctrl- with : +, -, 0, 1, 2, home, end are working, here. Note that +, -, 0, 1 and 2 are the ones of the num pad
the wheel : should be fixed, i think
Ctrl-o : i will add an elm file selector F1: harder as edje theme is what i want :-)
Oh. I don't have numpads on any of my keyboards (most laptops don't) and was using the numbers on the top of the letters.
So is it possible to add those?
As for help i would be happy with a popup and text on it with the mouse/keyboard bindings but you probably have something different in mind. Anyway i don't think help is a big deal. At least for me.
The elm file selector seg fault on Windows :( I can add Ctrl-o callback anyway and check on Linux
For the numbers, i can try, indeed
Thanks. I'll test when ready.
I'm going to rewrite the GUI, having something similar to what terminology provides (sliding panel when right click). Your other issues will be impacted by this change
Ok. Do your thing and ping me when ready. It seems to be doing a few weird stuff right now so i don't think there is a point in testing extensively.
indeed, i'm completly rewriting the gui after the redesign of the modules and a few other fixes with PDF module
implemented as today: Ctrl-o Ctrl-q F11/Esc (fullscreen) Left and right arrow
there might be the same problem with the scrollbar. I have a big problem with the focus
I can't test. For quite a while now etui is stuck on showing a file chooser in the middle of the window with no buttons working. Even the top bar window buttons don't work and i am not able to close the app.
Also i just build it and it uses 100% CPU.
can you test with the latest git of the EFL please ? I don't have such problem on Windows, which is strange :)
also, can you try to compile mupdf 1.11 from here : https://github.com/vtorri/mupdf-1.11 please ?
The problem still persists. Compiled etui today after i compiled efl and E from git. Haven't tried with your mupdf. I used 1.11 from the arch repos.
can you anyway try to compile my mupdf repo, please ? mine has shared lib + .pc file. I have to have it for distro which do not have this .pc file. If any problem with my mupdf, please fill an issue in that repo
thanks
as of today, I have removed mupdf from the etui git, so I rely only on an installed mupdf library
on arch, libmupdf might not work as it is only static library
I don't know what your plan is but having -as a dependency- a different version only for your project won't cut it with the distro people since it adds maintenance time. At least for arch they tend to stick to whatever upstream does.
Anyway at the moment -at least in linux/wayland- i see bigger issues than not rendering pdfs. :/ I'll try to get someone else also test it to see where the problem is.
1) compiling Etui with mupdf is a real pain as they don't use shared libraries. Their purpose is only to use mupdf in their tools (mudraw ,etc..) and ghostscript. 2) not using shared libraries will waste memory when rendering several pdf 2 bis) not using shared libraries will not work with autotools and Windows, because of libtool. I don't know how to deal with that 3) recompiling etui is much faster, this is really nicer when developping an application 4) it works on BSD, Mac, Solaris and Windows, I doubt it does not work on Linux (not tried yet) 5) use etui like that : etui file.pdf
just running 'etui' will show the elm_selector, which is just completely buggy. It was a mistake to use it. I plan to write one specifically for Etui
i suspect i am hitting bug number #14 for pdfs. Anyway i tried a djvu file (etui sample.djvu) and get a crash:
(gdb) bt
#0 0xaa5f7380 in () at /usr/lib/libdjvulibre.so.21
#1 0xaa5f8627 in () at /usr/lib/libdjvulibre.so.21
#2 0xaa600d6b in ddjvu_page_render () at /usr/lib/libdjvulibre.so.21
#3 0xaa683f14 in _etui_djvu_page_render (d=0x91c4a70) at src/modules/djvu/etui_module_djvu.c:532
#4 0xb778aae7 in _etui_smart_page_render (data=0x91c4960, thread=0x924de10) at src/lib/etui_smart.c:282
#5 0xb722a343 in _ecore_short_job (thread=2857048896) at lib/ecore/ecore_thread.c:387
#6 0xb722a99d in _ecore_thread_worker (data=0x0) at lib/ecore/ecore_thread.c:501
#7 0xb6efdc16 in _eina_internal_call (context=0x91e5ad8) at lib/eina/eina_thread.c:151
#8 0xb6c740f4 in start_thread () at /usr/lib/libpthread.so.0
#9 0xb6de54a6 in clone () at /usr/lib/libc.so.6
(gdb)
Not sure what is going on.
BTW i got bushman to test it and he also gets stuck on start with the file selector. He said edje is stuck in a resize loop or something like that.
are you somtimes on IRC ?
I am on #e. EU time.
My test setup: wayland efl-git 32bit atom a pdf file.
Results:
Ctrl-q : quit > works Ctrl-o : open file > does nothing F1: help > does nothing
right arrow, down arrow or space : next page > arrows affects both scroll and page move space and bcspace work left arrow, up arrow, backspace : previous page > see above page up : page + 10 > _doesn't move +10 _ page down : page - 10 > same as above F11: toggle fullscreen > works esc : exit fullscreen > works Ctrl-+ : scale * sqrt(2) > does nothing Ctrl-- : scale / sqrt(2) > does nothing Ctrl-0 : zoom to fit height > does nothing Ctrl-1 : zoom to original size > does nothing Ctrl-2 : zoom to fit width > does nothing Ctrl-home : go to first page > works Ctrl-end : go to last page > works
Mouse bindings:
double left click : toggle fullscreen > works wheel up : scale * sqrt(2) > moves scroll wheel down : scale / sqrt(2) > moves scroll
if you ctrl + wheel up or down it zooms out