Re: Feature change or bug - Emacs server

[joakim]

Antoine Levitt <address@hidden> writes:

> 14/06/11 02:57, Ted Zlatanov
>> On Tue, 14 Jun 2011 01:45:11 +0200 Antoine Levitt <address@hidden> 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