From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Feature change or bug - Emacs server Date: Tue, 14 Jun 2011 11:45:14 +0200 Message-ID: References: <4df63f95.a511440a.7545.ffffce92@mx.google.com> <878vt5645m.fsf@lifelogs.com> <874o3tl2ig.fsf@gmail.com> <87sjrd5iwl.fsf@lifelogs.com> <87boy0df9f.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308044737 12516 80.91.229.12 (14 Jun 2011 09:45:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2011 09:45:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 14 11:45:34 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QWQBh-0002nm-8J for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 11:45:33 +0200 Original-Received: from localhost ([::1]:33491 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWQBg-00066R-Er for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 05:45:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWQBS-00066G-C8 for emacs-devel@gnu.org; Tue, 14 Jun 2011 05:45:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWQBR-0002KK-3d for emacs-devel@gnu.org; Tue, 14 Jun 2011 05:45:18 -0400 Original-Received: from batman.blixtvik.net ([87.96.254.3]:34259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWQBQ-0002K0-QJ for emacs-devel@gnu.org; Tue, 14 Jun 2011 05:45:17 -0400 Original-Received: from www.verona.se (139-210-96-87.cust.blixtvik.se [87.96.210.139]) by batman.blixtvik.net (Postfix) with ESMTP id 646587F9616 for ; Tue, 14 Jun 2011 11:45:14 +0200 (CEST) Original-Received: from chopper (unknown [192.168.201.6]) by www.verona.se (Postfix) with ESMTP id DF0F83406C for ; Tue, 14 Jun 2011 11:45:14 +0200 (CEST) In-Reply-To: <87boy0df9f.fsf@gmail.com> (Antoine Levitt's message of "Tue, 14 Jun 2011 09:49:16 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 87.96.254.3 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:140455 Archived-At: Antoine Levitt writes: > 14/06/11 02:57, Ted Zlatanov >> On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt wrote: >> >> AL> It looks hard and bug-inducing to reimplement the network manager >> AL> applet. >> >> Do you know this for sure? It seems that the interface is entirely >> through D-BUS, which is not a hard protocol to support in ELisp. > > True, but nm-applet has changed substiantially over the last year or so, > and if they keep it up the elisp code might need constant fixing. Plus, > nm-applet does quite a lot of things (wifi authentification, VPN > management, connection configuration, etc.) and has just recently > started to do it well (previous versions were riddled with bugs), so > presumably it's not trivial to implement. Also, if the API is only used > by nm-applet, it might not be as generic as you'd like. But then again I > haven't looked at the spec. > >> AL> In general, having menus (applications, places, system, network >> AL> manager, whatever) pop up from emacs looks like a good compromise, >> AL> as well as a good "compatibility mode". >> >> I'd really prefer to avoid such hacks, though they may work in the short >> term. They tend to make life very difficult over the long term. > > But going for the low-hanging fruit (if it is - I don't know if the > xembed code is mature enough to handle this) is usually good to get It's not. Lately I've come to realise I'm on the wrong track and need to revert the last 10 commits or so and go down another track. Basically I thought composition would be a fantastic fit but it wasn't so I'll use a MVC aproach instead. But GTK doesn't come with a MVC framework out of the box so I need to implement a rudimentary one using signals it seems. For the advanced case of embedding an application that doesn't support MVC and only xembed composition can still be used but that is not robust enough in the general case. Applications like Inkscape that support multiple views can be modified to use xembed and use a separate xembed widgets per view. I think that case can be made to be robust. > things started. Plus, it'd provide compatibility with stuff that doesn't > use dbus. > Also, how are going to implement the apps/places/system menus? (assuming > you want them) Apps should be easy enough (just parse > /usr/share/applications/), but "system" looks hardcoded. > >> AL> I for one would be very happy to be rid of all that gnome nonsense and >> AL> just run emacs and a light fullscreen-oriented wm (that and some kind of >> AL> customizable bidirectional emacs <-> rest of the world notification >> AL> system are the only thing I really need, and I suspect many people as >> AL> well. For notifications, I currently use gnome-osd, which sucks less >> AL> than notify-osd, but not by far.) >> >> Ah, you're my notifications.el beta tester then :) Stay tuned. > > Bring it on! > > My beef with notify-osd is that the ubuntu devs have for some reason > decided that apps should not be free to set whatever timeout they want > for their notification messages, hence making it totally unusable (and > also that their stacking interface does not work over shell commands, > though that's fixable using dbus). My beef with gnome-osd is that it > looks ugly. > >> AL> One of the things preventing me from doing that (aside from >> AL> laziness, obviously) is the traybar (where apps can put their little >> AL> icons, and, on ubuntu, where system thingies (sound, network, etc.) >> AL> used to be, before they moved to some new fancy buggy framework). >> >> I asked about that and it's unlikely we can support it in Emacs. >> I don't consider that a great loss, though some may want it. Also note >> that on NS/Carbon/Cocoa and W32 this won't be available anyhow. >> >> I think there are standalone apps that can be the icon tray in X. > > Ok, it's probably not that crucial, you're right. > -- Joakim Verona