On Mon, 27 Aug 2007 11:39:15 +0200 Toby Cubitt <[EMAIL PROTECTED]> babbled:
> Michael Jennings wrote: > > On Monday, 27 August 2007, at 07:45:08 (+0900), > > Carsten Haitzler wrote: > > > >> yes - and the bad bit is - this conflicts with code for the config > >> gui. the fact is that almost every app on the planet provides a GUI > >> (built in) to configure itself - preferences dialogs for firefox, > >> settings dialogs for gimp. almost NONE provide "remote > >> control". most of the time people don't care - and don't need it. > > I'm amazed to hear this attitude on the enlightenment mailing list, let > alone from Carsten! I've always been an enlightenment fan primarily > because of its incredible flexibility and customizability, not because > of its flashy eye candy (that's nice too, but I'd rather ditch that than > the flexibility). Of all the window managers out there, I always thought > that enlightenment did the best job of combining a beautiful interface > with the Unix tradition of plain-text configuration files and > scriptability. Enlightenment was always more than just eye-candy: it was > the wm of choice for serious hackers who also appreciated a beautiful > desktop. see my latest mail on eet - you want to hack config files - you get it. but you get no safety net. i do want to get rid of the ipc handler ugliness. no one maintains that code - it's missing lots of config options that have been added - LOTS. > It's impossible to predict every weird and wonderful thing users might > want to do with E, and I guarantee you won't want to add all of them as that's why instead of working around things by screwing with the config, tell us what it is you need. > extra configuration options! (Many of them will be requested by just one > person, and useful only to them. Assuming they would even bother > requesting them. Most likely they'd realise there's no hope of getting almost every time someone asks for something - they are asking for the wrong thing. they actually want Y, not X, but they only see X as the way of getting it. > what they want included, and give up.) By using plain-text config files > (or at least allowing binary config files to be manipulated by > command-line tools) and opening up E IPC via a command-line tool, E done. note - e will re-write its own config files regularly, so hacking at them behind e's back may not help much :) > makes it possible to do amazing things using nothing but simple shell > scripts. Things that in another window manager couldn't be done without > hacking the source code. For example, when I was using E16, I had a > whole collection of scripts that automatically opened and closed pagers > when I changed virtual desktop, that unshaded my IM client when a > message arrived, that let me manipulate enlightenment from within Emacs > etc. etc., all done using bash and eesh (the enlightenment_remote > equivalent for those who never knew it - I would give E17 examples, but > I'm stuck using Windows at the moment so haven't had a chance to play > with E17 as much). the current code for the ipc stuff is ugly - i tried to put it all in 1 place and make it friendly to extend for 3rd party tools by having proper well defined data structures, but it's become a fairly large wad of rarely used code that no one is maintaining or doing anything to - it's falling behind the features and abilities of e daily as we just dont bother adding more ipc calls. > > This is, of course, not true. Most systems, including firefox > > (prefs.js) and GIMP (gimprc, et al.), use text-based configurations > > which do not require specialized "remote control" tools beyond a > > simple text editor. But even they provide mechanisms for controlling > > program behavior from afar, from JavaScript and Script-Fu to special > > command line parameters. > > Exactly. The great thing about Unix is that it doesn't insult your > intelligence by assuming it knows what you want better than you do, but > instead makes it easy to combine tools in novel ways to do things that > the developers would never have dreamed of. I'd be very sad to see > enlightenment turn its back on this philosophy. we have different ways of doing things - instead we are going for a plugin method -a much more formalised and incredibly more powerful way of doing things. it lets you plug in and then access ANYTHING in the code - ANYWHERE. it doesn't need to wait for us to add ipc or even make a config option for it. unfortunately for you it's in C. if you can hack around and make bash + eesh to exec from emacs to do things - you can do the little C needed to do a module to do the same things. there has been a start in a python module - to allow python scripts to run and extend e - don't say that we aren't giving the control- we just aren't doing it the way you want or are used to. we are offering better and finer-grained control than ever. what i want to get rid of is monster lumps of dormant and unmaintained code in the core - shorne's work on dbus controls and putting the onus on modules to extend the ipc as people need is much better than what we have now. > > An automated way of manipulating program configuration is both wanted > > and needed. > > > > The current implementation of E IPC is pretty ugly, yes. That doesn't > > mean IPC is bad. It means the IPC code was not designed properly. > > Maybe I'm hallucinating, but I thought that a while back there was some > discussion on enlightenment-user about how some new code (gadcon?) would > make it much easier to add new actions to enlightenment_remote at the nup- gadcon and e_remote had nothing to do with eachother. > same time as adding the corresponding GUI elements. Was I dreaming? This > sounded great to me at the time, because it seemed to suggest that > pretty much *everything* would automatically be made scriptable via > enlightenment_remote, without much extra coding effort. no. not at all. that may have been dbus + modules extending the ipc and allowing you to use standard dbus tools to send messages and get replies. > Toby > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
