emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GTK scroll bar question


From: Dmitry Antipov
Subject: Re: GTK scroll bar question
Date: Thu, 31 Jul 2014 14:19:17 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 07/31/2014 10:52 AM, Jan D. wrote:

No, it never is.  BTW, there may be many scroll bars on the same
parent (many windows in a frame), so the mapping is not unique.

But in case of Emacs, we have a container (event box) widget for
each scroll bar, isn't it?  And the container widget is guaranteed
to have its own window (well, at least with current GTK2/3).

You should at all possible cost avoid map a Gtk+ widget to some X window.

In theory, this makes sense for pure Gtk+ application (to get it work
out-of-the-box on MS-Windows, for example). In practice, Emacs is not
Gtk+ application and have the very little chance to be in foreseeable future.

IMHO tight integration with native window system looks impossible if you're
limited by using high-level Gtk+ interfaces only.  How would you redesign
handle_one_xevent in terms of Gtk+?  And why?

It might have an X window now, but that might change.  Also, porting to
stuff like Cairo or other Gtk+ backends is so much
more difficult (Cairo is a possibility, other backends less so).

Well, switching to Gtk+ with Cairo backend targeted to X pixmaps instead
of X windows will break everything anyway.  In particular, this will require
new redisplay interface to replace x_redisplay_interface and so a lot of
new stuff to replace X-specific code in xterm.c.

Why do you insist in changing stuff that work?

I just found id_to_widget stuff too ugly and looking for some way
to a more elegant solution.

Stop that.

With all possible respect, we can't direct each other to do or not to do
something.  And we shouldn't, isn't it?

Dmitry





reply via email to

[Prev in Thread] Current Thread [Next in Thread]