Closed anatol closed 9 years ago
anatol
commented
10 years ago For the record here are similar vte-2.91 tickets for
sakura: https://bugs.launchpad.net/sakura/+bug/1337962 pantheon-terminal: https://bugs.launchpad.net/pantheon-terminal/+bug/1375346 roxterm: http://sourceforge.net/p/roxterm/bugs/107/
lanoxx
commented
10 years ago Thanks for the bug report. This issue has previously been discussed in #29. The removal of transparency and background options from the latest VTE version is unfortunate but outside of my control. I will prepare a patch to remove the transparency and background settings from Tilda for versions greater or equal to 0.38 in the coming days. If you liked the transparency feature I suggest to write to the current developer of VTE to try to convince him to return the feature.
Never the less it seems that the actual issue which caused the linker to abort is the missing XSetErrorHandler function. I find that curious, can you check if you have the necessary X related libraries installed.
anatol
commented
10 years ago Here is output of ./configure
[anatol@arch tilda]$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for glib-compile-resources... /usr/bin/glib-compile-resources
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTK... yes
checking for VTE... yes
checking for LIBCONFUSE... yes
checking for X11... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for pid_t... yes
checking for size_t... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working strtod... yes
checking for mkdir... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strncasecmp... yes
checking for strstr... yes
checking for strtol... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating tilda-config.h
config.status: tilda-config.h is unchanged
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
tilda 1.2~rc1
=============
prefix: /usr/local
datarootdir: ${prefix}/share
datadir: ${datarootdir}
pkgdatadir: ${datarootdir}/tilda
source code location: .
compiler: gcc
cflags: -std=c99
Maintainer mode: yes
Use *_DISABLE_DEPRECATED: What else can I do to check correct library versions?
anatol
commented
10 years ago [anatol@arch tilda]$ readelf -Ws /usr/lib/libX11.so.6.3.0 | grep XSetErrorHandler
294: 00000000000232a0 124 FUNC GLOBAL DEFAULT 11 XSetErrorHandlerThere must be an issue with linker or incorrectly compiled *.o files. I'll look at the issue once the vte patches be ready and allow to compile the sources.
egmontkob
commented
9 years ago The removal of transparency and background options from the latest VTE version is unfortunate
Just to clarify: Background image support was indeed removed. Transparent background is still available (for compositing WMs): just set a background color that has an alpha component, and set an argb visual for the app (see the unofficial gnome-terminal transparency patch in the Fedora and Ubuntu packages).
egmontkob
commented
9 years ago Note: vte-0.40 (gnome-3.16) is out.
The API is backwards compatible with 0.38. As an addition, it brings back the word-chars support which was dropped in 0.38.
Internally the biggest change is that the scrollback buffer's contents are written to the disk compressed and encrypted rather than in plaintext. This fixes a privacy issue that many people were concerned about, so it'd be great if you could port to the newest vte api (I'm not sure about the current state, I'm just copy-pasting this message :)).
x2b
commented
9 years ago Well, the X11 issue is because someone forgot to add the X11 flags to the linker. You could fix the situation like this: https://gist.github.com/x2b/faabb7e127a38984fd75
Porting the API remains on the TODO list :)
lanoxx
commented
9 years ago That sounds reasonable. I just wonder why this always worked for me before. I could always compile tilda even without those flags.
x2b
commented
9 years ago @lanoxx @egmontkob I have pushed a branch using the new API to my fork: https://github.com/x2b/tilda/tree/wip/vteport
So far I changed the following:
Let me know what you think.
pik
commented
9 years ago @x2b I could be wrong - but I think a lot of people that use Tilda want the original transparency feature. We could add an alpha-spinner for the background (currently color-choice is limited to the auto-calculated presets, and this is a regression for transparency).
I'm not sure if there are other issues, probably for WM's that do not support composite management tilda should compile without those options?
Also I'm getting a new warning:
gtkwidget.c:13153: widget classVteTerminal' has no property named inner-border'
egmontkob
commented
9 years ago "Text Color" / "Background Color" color choosers to accept alpha values.
Technically the text color also accepts an alpha channel (so that the same class is used everywhere), but it's ignored there. The foreground color can't be translucent, only the background.
As for the UI, I guess it'd be better to have a color picker that chooses a solid color, and a separate slider for transparency. But after all it's your choice
For me, transparency doesn't work after I quit and restart tilda. It goes back to the non-transparent version of the same color.
gtkwidget.c:13153: widget class
VteTerminal' has no property namedinner-border'
This was renamed to the 'padding' property with css-like values along with units, e.g. "1px 3px 1px 1px"
pik
commented
9 years ago Here is an update of the vte-port with the transparency regression restored.https://github.com/pik/tilda/commit/9ca26be436b0a46bc6c5c3754bf13f6b1b816268
There are a few things I somewhat don't like - for example vte-2.91 changed their vte_terminal_set_colors_rgba to colors deprecating the old functions. But GTK is still using rgba namespaces for their functions i.e. gtk_color_chooser_get_rgba, this is a confusing inconsistency.
Also since the transparency options were deprecated using vte_terminal_set_color_background requires fetching all the color values from config i.e.
gboolean status = !config_getbool ("enable_transparency");
bg.red = GUINT16_TO_FLOAT(config_getint ("back_red"));
bg.green = GUINT16_TO_FLOAT(config_getint ("back_green"));
bg.blue = GUINT16_TO_FLOAT(config_getint ("back_blue"));
bg.alpha = (status ? GUINT16_TO_FLOAT(config_getint ("back_alpha")) : 1.0);That's four locked reads on the config file when really there should only be one - but vte does not give an option of obtaining the background color or only updating bg.alpha.
@x2b I used your monitor switching-code, but it still needs work, for example the Tilda-window disappears when wizard is called and doesn't reappear when wizard is closed. Also the the pull-down key does not pull-up the tilda window if it looses focus.
Also the tilda_window_set_active function appears to be have been broken.
x2b
commented
9 years ago Regarding tilda_window_set_active: comments say
/* This function will make sure that tilda window becomes active (gains
* the focus) when it is called.
*
* This has to be the worst possible way of making this work, but it was the
* only way to get metacity to play nicely. All the other WM's are so nice,
* why oh why does metacity hate us so?
*/
void tilda_window_set_active (tilda_window *tw)This may have been slightly broken before already...
lanoxx
commented
9 years ago I never really investigated this. That comment was already in the legacy codebase of tilda. Given the recent changes and bugfixes in the metacity code it might not even be valid anymore. Do you think something should be changed here?
pik
commented
9 years ago So I seem to have fixed the bug with tilda_window_set_active hanging https://github.com/pik/tilda/commit/01dd9dc4db79a9041b9eb35f8ec99552b35dc802 -- apparently (from the gdk docs): gdk_x11_get_server_time ()
a GdkWindow, used for communication with the server. The window must have GDK_PROPERTY_CHANGE_MASK in its events mask or a hang will result.
Although I guess no one had that problem before?
Also replaced inner-border border.bottom with margin-bottom for the ypad - https://github.com/pik/tilda/commit/812742bdfa2c4a2fe8aaf12cbcd6e73bdc35a6ac#diff-cb2af9d3deba6ff278bbe00e78fafbc4L891
@lanoxx If you think it better I can PR these changes separate from X2B's patch for porting to newer libvte?
lanoxx
commented
9 years ago @x2b I have added the X11 flags to configure.
lanoxx
commented
9 years ago Hi @pik,
thanks for working on this. However I am not entirely happy with merging this yet. Most importantly this will mean that tilda can no longer be compiled on older systems where only VTE 2.90 is available. Especially the current Ubuntu LTS, I would like to stay at least compatible with 14.04, because I am sure some people are compiling from source and want to run tilda on older systems.
I think there are two options to go forward with this:
In any case given the uncertainty about terminal transparency and other options I do not want to completely remove support for VTE 2.90 any time soon. Also note that it is possible to install VTE 2.90 and 2.91 at the same time on a system, so it is possible to continue to use tilda even on newer systems.
pik
commented
9 years ago @lanoxx Yes that makes sense, options 2) or 3) are definitely preferable. Is it okay to remove features lacking in 2.91 from the 2.90 compatible version as well?
In any case given the uncertainty about terminal transparency
It seems to work okay with background.alpha, but idk if there are other reasons to be worried?
I guess my main concern overall would be taking time to setup cross-compatibility between 2.90/2.91 and then have more breaking changes in 2.92 or in the nearer future.
lanoxx
commented
9 years ago Is it okay to remove features lacking in 2.91 from the 2.90 compatible version as well?
No. Add a condition and keep them available in 2.90.
It seems to work okay with background.alpha, but idk if there are other reasons to be worried?
Yes, right now. But the developer also made it clear to me that he will remove features if they make the code too complex and he thinks they are not necessary, and he has clearly stated to me that he thinks transparency is very unnecessary. So I am just not convinced that it will stay that way. I am also not very fond of the fact that features which people are actually using are just removed because the developer finds them not useful. I am also not very fond of the fact that features are removed just to bring them back in the next version, for example note that the word_chars feature which was removed in 0.38 is actually back in version 0.40 as far as I know.
egmontkob
commented
9 years ago Yet another option could be to maintain two branches of tilda: work actively for vte-2.91 (let's say tilda 1.3.x) and keep backporting the more important changes to the vte-2.90 based branch (tilda-1.2.x). I guess you could abadon the old branch in about a year from now when the next Ubuntu LTS is released.
Re option 3: It's probably way too complicated and I can't see the point in it.
Re option 2: I'm quite certain no distribution will want to ship two versions of tilda in parallel, and that if they can choose, they'd probably choose to link against newer vte.
Newest vte is in almost all aspects superior to the old ones (maybe background image being the only notable exception), just look at the changelog how many significant improvements it has received, and it's still actively being worked on. I see no point in you preferring 2.90 over 2.91. IMO the default should be 2.91, falling back to 2.90 for compatibility on systems where the new one is not yet available.
Justinzobel
commented
9 years ago Any update on this issue? Trying to package for Solus but we have 2.91, not 2.90
anatol
commented
9 years ago I am an Arch developer and we would like to see a few remaining packages (like tilda) moved to the latest stable vte release (2.91). Is there any chance to see the fix merged/released?
lanoxx
commented
9 years ago Yes its actually mostly finished, I just did not have the time to merge it into master and a few last changes that I have in mind. Maybe I can find some spare time this weekend or next.
anatol
commented
9 years ago Great, thanks you for doing this. Looking forward for a new release with the latest VTE support.
Gnome 3.14 has been released recently and it brought a new version of vte library (0.38). Some Linux distros are bringing this library version to their repos. This issue will track progress of porting to the new vte version.
I tried compiled tilda with new vte version and here is its output: