Re: GTK scroll bar question

["Jan Djärv" <jan.h.d@swipnet.se>]

31 jul 2014 kl. 12:19 skrev Dmitry Antipov <dmantipov@yandex.ru>:

> 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).

We want to get rid of those as they are a performance hit.

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

The first Gtk+ version I made did not use handle_one_xevent, but it was desided that the code in handle_one_xevent should be reused.  So it is a no-brainer to replace it, it is just a lot of work.

The reason is that we have a lot of code in other places to handle timers and other things (the whole xg_select.c file for example) that only comes from not running the Gtk+ event loop.

> 
>> 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.

It is true that Cairo don't use pixmaps, but it will not "break everything".  The only things that uses pixmaps are toolbars and image display.  This is easily overcome by defining a cairo-image.c, like nsimage.c and such.

>  In particular, this will require
> new redisplay interface to replace x_redisplay_interface

No it will not.

> and so a lot of
> new stuff to replace X-specific code in xterm.c.

The work has mostly been done by YAMAMOTO Mitsuharu.  His patch is a bit out of date, but I have been updating it.

> 
>> 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.

From what was contained in the Gtk+ port only, you now distribute to three files, and enlarge a struct for no good reason.  That is not elegant IMHO.

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


So when you can checkin to the Emacs tree, you feel you are in your right to break code and generally change it so that the people that try to maintain it can't recognize anymore?

	Jan D.