From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Feature change or bug - Emacs server Date: Tue, 14 Jun 2011 13:12:32 +1000 Message-ID: References: <4df63f95.a511440a.7545.ffffce92@mx.google.com> <878vt5645m.fsf@lifelogs.com> <874o3tl2ig.fsf@gmail.com> <87sjrd5iwl.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016369f9ac52963ae04a5a368c0 X-Trace: dough.gmane.org 1308024643 6820 80.91.229.12 (14 Jun 2011 04:10:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2011 04:10:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 14 06:10:39 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 1QWKxa-0004FR-V8 for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 06:10:39 +0200 Original-Received: from localhost ([::1]:37228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWKxa-0005ch-0D for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2011 00:10:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWK3Q-0007Ha-VU for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:12:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWK3O-0004Sv-Km for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:12:36 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:56704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWK3O-0004Sh-9m for emacs-devel@gnu.org; Mon, 13 Jun 2011 23:12:34 -0400 Original-Received: by iyl8 with SMTP id 8so6034763iyl.0 for ; Mon, 13 Jun 2011 20:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pW2IIpew0dcgy0MBLlRN69hWMLM+a9ancxoxiHqxFqg=; b=VVlNp5Kv8LnZupS6tCRVSEYeQGtGBf6CbGPohGMVrsnCWGjLQ+KEOiBNTi4ke0M0V7 DwKIXw+RVU5cnX335VvaRi0iLEapkm0pOI+19d6ORHz0/b8GPPA20z3Cp8BkzoxXJtU3 60UbhDrZ8H/1AvjcnptM8Qi/5nRtMl5KeaZBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nNhpm5BKVUXzSoA0i5e1cvBPJP2O+HKgc1l8rKmIvlKkdDPoNB/u8W23aJ8wge1w+C 8hqIwmEVdLfnNw7ZRV0P9DMVhjEogAvZWJEtRgxt+6fBso5QMpz6+rEeYsPsxPOsryYa QyxoKWp4nZYoJuRbULsEBorQvwXlerDBCDgRM= Original-Received: by 10.231.201.81 with SMTP id ez17mr4456236ibb.156.1308021152637; Mon, 13 Jun 2011 20:12:32 -0700 (PDT) Original-Received: by 10.231.32.72 with HTTP; Mon, 13 Jun 2011 20:12:32 -0700 (PDT) In-Reply-To: <87sjrd5iwl.fsf@lifelogs.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:140442 Archived-At: --0016369f9ac52963ae04a5a368c0 Content-Type: text/plain; charset=ISO-8859-1 2011/6/14 Ted Zlatanov > On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt < > antoine.levitt@gmail.com> 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. > > I would tend to agree. D-Bus seems very promising and I have a couple of TODO items to look at D-Bus more closely when time permits (specifically, I'd like to find the time to look at D-Bus for emacspeak speech server communication, but suspect that journey would also provide the necessary knowledge to exploit the protocol for other applications. > 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. > > From an accessibility perspective, I would also have to say that such solutions are not great. > 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. > > 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. > > Yep, thats may feeling as well. Much of this 'essential' stuff is really just what we have gotten use to. Much of it is what has added the complexity which now appears to make many things that were simple much more complicated while making a few rarely required/changing things easier - at least thats how it feels to me. You can survive using a modern Linux distro without having to have all the Gnome stuff and there are alternatives for most of the things it offers. Yes, at this time, it may take a little more effort to setup initially. > AL> I used to file the "move away from gnome and reclaim control on my > AL> desktop" in my "some day" mental TODO list, but ubuntu's plans of > AL> ditching everything that's remotely usable anymore in the next release > AL> might accelerate the process. > > Yeah, I'm really tired of the balkanization of the X desktop. It's as > if everyone is simply racing to mimic the W32 and Mac OS X platforms, > which is not a race worth winning. > > It does seem odd for this tendency to exist. The thing which originally attracted me to the X environment was tts flexibility and potential to create the environment you wanted and to work the way you wanted rather than having something imposed from some large anonymous vendor. It seems now, possibly through desires to reduce support costs, even larger Linux distros are trying to channel as many users into a standard desktop environment - after all, this would make it easier to support. The problem is as you highlight - everyone is converging to the same result and we lose originality and innovation. I miss the days when I'd walk into one of our computer labs running X and see 20 screens, all looking distinct (and I don't just mean different colours and icon themes) with different use of screen real estate, unusual menus, such as spiral menus, mice controlled by foot pedals, innovative embedding of local and remote services etc. I have no idea what the ideal interface will be, but I'd make a bet its unlikely to be the same for everyone and is almost certainly drastically different from what we are currently seeing. Tim --0016369f9ac52963ae04a5a368c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/6/14 Ted Zlatanov <tzz@lifelogs.com>
On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <antoine.levitt@gmail.com> wrote:

AL> It looks hard and bug-inducing to reimplement the network manager AL> applet.

Do you know this for sure? =A0It seems that the interface is entirely
through D-BUS, which is not a hard protocol to support in ELisp.

I would tend to agree. D-Bus seems very promising and= I have a couple of TODO items to look at D-Bus more closely when time perm= its (specifically, I'd like to find the time to look at D-Bus for emacs= peak speech server communication, but suspect that journey would also provi= de the necessary knowledge to exploit the protocol for other applications.= =A0
=A0
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 shor= t
term. =A0They tend to make life very difficult over the long term.

From an accessibility perspective, I would also have = to say that such solutions are not great.=A0
=A0
AL> I for one would be very happy to be rid of all that gnome nonsense a= nd
AL> just run emacs and a light fullscreen-oriented wm (that and some kin= d of
AL> customizable bidirectional emacs <-> rest of the world notific= ation
AL> system are the only thing I really need, and I suspect many people a= s
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 :) =A0Stay tuned.

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.)<= br> 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. =A0Also no= te
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.

Yep, thats may feeling as well. Much of this 'ess= ential' stuff is really just what we have gotten use to. Much of it is = what has added the complexity which now appears to make many things that we= re simple much more complicated while making a few rarely required/changing= things easier - at least thats how it feels to me.

You can survive using a modern Linux distro without hav= ing to have all the Gnome stuff and there are alternatives for most of the = things it offers. Yes, at this time, it may take a little more effort to se= tup initially.=A0
=A0
AL> I used to file the "move away from gnome and reclaim control on= my
AL> desktop" in my "some day" mental TODO list, but ubunt= u's plans of
AL> ditching everything that's remotely usable anymore in the next r= elease
AL> might accelerate the process.

Yeah, I'm really tired of the balkanization of the X desktop. =A0It'= ;s as
if everyone is simply racing to mimic the W32 and Mac OS X platforms,
which is not a race worth winning.

It does seem odd for t= his tendency to exist. The thing which originally attracted me to the X env= ironment was tts flexibility and potential to create the environment you wa= nted and to work the way you wanted rather than having something imposed fr= om some large anonymous vendor. It seems now, possibly through desires to r= educe support costs, even larger Linux distros are trying to channel as man= y users into a standard desktop environment - after all, this would make it= easier to support. =A0The problem is as you highlight - everyone is conver= ging to the same result and we lose originality and innovation. I miss the = days when I'd walk into one of our computer labs running X and see 20 s= creens, all looking distinct (and I don't just mean different colours a= nd icon themes) with different use of screen real estate, unusual menus, su= ch as spiral =A0menus, mice controlled by foot pedals, innovative embedding= of local and remote services etc.=A0

I have no idea what the ideal interface will be, but I&= #39;d make a bet its unlikely to be the same for everyone and is almost cer= tainly drastically different from what we are currently seeing.=A0

Tim

--0016369f9ac52963ae04a5a368c0--