From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?windows-1252?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: GTK scroll bar question Date: Thu, 31 Jul 2014 13:53:52 +0200 Message-ID: <258DF241-B761-4DD8-9CDD-278785FC4A39@swipnet.se> References: <53D8D2DE.4090700@yandex.ru> <53D8E765.2030303@gmx.at> <53D91162.9010503@yandex.ru> <53D9CE87.20800@yandex.ru> <53D9E7C0.9040204@swipnet.se> <53DA1825.70301@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1406807663 25943 80.91.229.3 (31 Jul 2014 11:54:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2014 11:54:23 +0000 (UTC) Cc: Emacs development discussions To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 31 13:54:15 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XCovz-0008Ml-Rb for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2014 13:54:11 +0200 Original-Received: from localhost ([::1]:55737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCovz-0006Uc-4E for ged-emacs-devel@m.gmane.org; Thu, 31 Jul 2014 07:54:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCovq-0006UV-Rv for emacs-devel@gnu.org; Thu, 31 Jul 2014 07:54:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCovk-0000Lb-Jr for emacs-devel@gnu.org; Thu, 31 Jul 2014 07:54:02 -0400 Original-Received: from mailfe07.swip.net ([212.247.154.193]:56649 helo=swip.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCovk-0000LI-CU for emacs-devel@gnu.org; Thu, 31 Jul 2014 07:53:56 -0400 X-T2-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 519963737; Thu, 31 Jul 2014 13:53:53 +0200 In-Reply-To: <53DA1825.70301@yandex.ru> X-Mailer: Apple Mail (2.1878.6) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.247.154.193 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173317 Archived-At: 31 jul 2014 kl. 12:19 skrev Dmitry Antipov : > On 07/31/2014 10:52 AM, Jan D. wrote: >=20 >> 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. >=20 > 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. >=20 >> You should at all possible cost avoid map a Gtk+ widget to some X = window. >=20 > 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. >=20 > 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. >=20 >> 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). >=20 > 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. >=20 >> Why do you insist in changing stuff that work? >=20 > I just found id_to_widget stuff too ugly and looking for some way > to a more elegant solution. =46rom 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. >=20 >> Stop that. >=20 > 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.