Thank you @Peter2121.. I had to modify one header that was linux specific in order to make VNC server work:
Jun 21 2020
Jun 16 2020
May 26 2020
May 17 2020
May 15 2020
It seems that has_header meson function is not recursive.
I could reproduce your problem creating symlinks of epoll.h in /usr/local/include/sys or in /usr/include/sys
I don't know why do you have such links (or strange CFLAGS=I/usr/local/include/libepoll-shim) but anyway it is not a standard situation. So I think that libepoll-shim package installed would not prevent correct building of EFL without epoll.
I cannot reproduce your problem on my test PC under FreeBSD 12.1.
I have libepoll-shim package installed, but during the configuration of EFL meson does not detect sys/epoll.h header. I have it installed in /usr/local/include/libepoll-shim/sys/epoll.h and I have CFLAGS=-I/usr/local/include exported, but meson does not detect it. Don't you have a symlink of this file in /usr/include for any reason?
I can confirm that this is the EFL build time configuration issue. Older EFL build works fine with Terminology 1.7.0. I will looks into that epoll stuff in a free moment. Thank you!! :-)
epoll-shim is required by other packages and cannot be removed from the system. If presence of that package impacts Terminology then terminology build scripts need fix.
May 14 2020
Thank you for your feedback that it works for you, this is valuable input.
Try to build EFL and Terminology in jail with the strict minimum of other software installed. Terminology and Enlightenment from Git work fine here with EFL 1.24 on FreeBSD 11.3.
Your terminology 1.6.0 is probably linked with an other version of efl, one that was compiled when epoll-shim wasn't installed.
You cannot build a port package with all this other software installed.
Did you build EFL with those flags?
The problem with Terminology 1.7.0 is not fixed, exactly the same setup and 1.6.0 works fine, I cannot remove libepoll-shim from system because other applications depend on it. Will report a working solution if I find one. Thanks for your quick response :-)
meson build -Dsystemd=false -Deeze=false
Well, it looks like I am updating the port, because no one did that so far ;-)
Please advise the FreeBSD port maintainers not to build with wayland support . It does not work, it merely builds.
Follow that guide - remove the libepoll-shim package as suggested by @arrowdodger
These goes the port updates tickets and whole ports sources / patches are there too:
That sounds about right @arrowdodger
@cederom Are you building in unclean environment? It might be that build system picks stuff from libepoll-shim FreeBSD package.
I'm runnning E 24.0 and EFL 1.24 and Terminology 1.7.0 on FreeBSD 12.1 and OpenBSD 6.7-beta
Hey @netstar :-) Which version of Terminology on which E and EFL?
I'm running terminology fine here on OpenBSD and FreeBSD.
Can you show the build options for EFL? There should be no reference to epoll
There are some changes in src/bin/termpty.c but I don't see why it should fail.
Sure thing, I am porting EFL+E to FreeBSD so no problem with building and patching :-)
Would it be possible for you to compile terminology 1.6.0 with the same efl version?
Hello @billiob and thank you for quick response :-)
If you create a new terminal from the menu, is it better?
What if you focus/unfocus the window?
May 7 2020
No update in more than a year
May 5 2020
Should be fixed by 38e4935427939d21f9c545935e3a0e2ffa674a0b
May 2 2020
Apr 26 2020
For now I patched the last release version so it is not the clone from git, but thanks for the tip. 🙇
Are you using terminology from git? Because there was a bug and pasting stuff might not have worked as expected. It was fixed in
Apr 20 2020
that's not transparency. first it's an implied protocol where whoever sets a pixmap; on root window sets a property that gives that's pixmap id. it's a hack. it's also got wonderful side effects like the client has to track it's x,y relative to root and redraw every time it's moved - this doesn't sync. it'll always be a bit out-of sync as yoiu get the events that the window moved after it happened. in the age of real compositing this hack is no longer valid or desirable. as the person who came up with the hack in the first place over 20 years ago... i think i get to call it dead when it is dead. :) move on and use a compositor. :)
I was expecting something like using the picture from the root window of the wm and just use that as background.
I'm using feh to set the background picture.
how is this broken? to be transparent you create a window with an argb visual and fill it with alpha channel pixels... efl actually doesnt have any special different code-path per wm. there is a code path to detect a if the composite extension exists (and xrender and xfixes) etc. and falls back to shaped if it doesn't... it also checks to see if the parent window is argb or not on creation to ensure it matches a parent if done that way - for root window it's special and doesn't enforce it but if it's requested it'll work fine..
The line set termguicolors makes vim use truecolor escape sequences.
Terminology uses color approximation in that case and that's the reason it uses that dark color for the background.
I've blogged a bit about it in https://fau.re/blog/20180313_terminology_encircled.html .
If the background was #073642, you'd have more luck.
I'm just going to close this then...
I agree here also. I didn't realise it had been broken outwith E since 1.22. With it working in E, I'm personally happy.
I do agree with you. It's been broken on too many stable releases to be considered a broken on that one.
Hmm, so the part where Terminology is running in E is fixed in terminology, right?
And we we have it broken for Terminology running outside E since efl version 1.22 onwards.
It still does not work for me outside e.
I couldn't find a release of efl, with a meson build, that had this to be working.
Apr 18 2020
Apr 17 2020
@billiob seems fixed due to changes in terminology. In E at least. Tested on 3 machines.
Apr 8 2020
filetype off " required
Plug 'mhinz/vim-startify' " Nice start screen (COW)
call plug#end() "
Apr 7 2020
And you're using the default theme in Terminology, right?
There's something we've not tried: have you set Set TERM to xterm-256color in Settings → Behavior? Should be the default.
Could you please point me to the exact colorscheme your using and/or minimal vimrc you tested?
Thx for your time. I give up.
Any settings different colorschemes.
Guake, Kitty, Terminator and terminology (on the left):
Terminology still black no matter what I do. Papercolor obviously looks as expected since it doesn't contain background.
blueish colorschemes which look like this: OceanNext, solarized8
things in my .vimrc that could be relevant:
set t_Co=256 set background=light "set background=dark "let g:solarized_termcolors=256 colorscheme PaperColor hi Search ctermbg=LightBlue hi Search ctermfg=White
snap run terminology
Since you're on ubuntu, could you try that: https://snapcraft.io/terminology ? and tell me if it's better?
OS: Ubuntu 19.04 Disco
Vim 8.2 (2019 Dec 12)
Which version of terminology are you using?
Apr 5 2020
It's working for me on Enlightenment v1.22.0 on X. I'm using efl and terminology on their respective master branch.
Mar 30 2020
This isn't going to happen. We don't do sub pixel rendering.
Feb 27 2020
Feb 9 2020
Feb 6 2020
oh I see. well, This same issue exists when you install using sudo apt-get install terminology on elementaryOS. It installs version 0.7 though. which is very old.
I have spent the past 3 days trying to figure out how to solve this issue, have installed and uninstalled many versions.
I also downloaded the package directly from enlightenment.org website and thought to build and install it myself but I hit a snag there as well. I faced some dependency issues there.
That's when I install snap specially for terminology and then installed it using snap. ?
I guess I will try to resolve those dependency issues from the enlightenment.org package. :))
Feb 5 2020
This is with the snap version of Terminology.
I'm aware of that issue but I don't know yet how to fix it.
Feb 4 2020
Jan 16 2020
Thanks. I will be using Tmux inside Terminology while 1.7+ get released. :-)
I'm working on tab management and splits at the moment. It should be nice for Terminology 1.7 but I won't add yet support for what you ask.
So far tabs are like that and the fact that tabs are integrated with the underlying terminal makes it not easy to put splits in there.
For example, the background of a terminal goes "into" the tab.
I confirm this feature works fine in 1.5.0 (I rebuilt that terminology version to test). So it definitely got broken in some commit between release 1.5 and 1.6.
Jan 14 2020
Jan 13 2020
I think this has been fixed.
Dec 18 2019
move to here - i can't reproduce any of the above issues. works perfectly for me. what os AND video drivers?
Dec 5 2019
If you ever find a way, please reopen.
Dec 4 2019
Dec 2 2019
Nov 4 2019
So, I did give your thoughts a chance and a bit of hacking (See https://github.com/billiob/terminology/commit/3892e3eb87be33809f0df5d64a167aca8b9ebaa5 ).
I won't finish that as I consider it to be too difficult/impossible to do it correctly.
1/ It is not writing to the terminal's fd as that would create a security issue.
2/ It is only writing text to the terminal, but that might create issues because it moves the cursor and writes stuff that the application underneath does not know about.