[Top][All Lists]

[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?


reply via email to

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