On Sun, 26 Aug 2007 18:01:45 -0300 Jorge Peixoto de Morais Neto <[EMAIL PROTECTED]> babbled:
> > > To be able to script the lock screen timeout is specially important. Am > > > I supposed to follow menus each time I want to watch TV? If it was > > > scriptable, I could bind a key to it, so I would just press a key > > > combination when I wanted to increase the timeout. I could even write > > > a script that did this before calling the TV-viewing program, and > > > restored the default configuration after the TV-viewing program ended. > > > > actually this could be implemented if we provided actions to change config - > > enlightenment_remote is an extreme inefficient and round-about way to do > > this. enlightenment_remote is a pain to maintain - it is a large lump of > > code that most people tend to never use. we are going to get rid of it. > > > > your "stop blanking while watching tv" problem is the fact that your tv > > app... is "stupid". it does not suspend the screensaver (blanking) while > > watching tv. this is an easy thing to do in x (if you use the xscreensaver > > extension) and it should just do it automatically - WITHOUT you nbeeding to > > go bind keybindings to run a program that then connects back to the wm that > > then changes a setting (permanently) that then tells x to turn off dpms > > blanking (and then you need to remember to turn it back on again too when > > done - you might forget and then not get blanking). > My TV viewing app (Mplayer) *does* seem to disable the X server standby > timeout, but it still does not disable the Enlightenment screen > locking. e's screen locking kicks in when the screen blanker kicks in. > > most cases for "i need scriptability" are simply work-arounds for bugs/lack > > of features or lack of knowledge on how things work. for us maintaing > > enlightenment_remote is a burden - it is a gateway for bugs and crashes - > > already. if there is genuine need - we will have some remote control > > ability - but only if there is need. we are looking to dump e_ipc and move > > control via dbus and allow modules to extend dbus remote control. > That reminds me of the GNOME mentality "wee don't need > customizability because customizability is a work-around for lack > of good defaults and lack of smartness on the computer". I don't > personally agree with that. have you SEEN ipc_handlers.h ? > In any event, I never thought that enlightenment_remote was complex... > But I imagine that what makes it complex is the fact that it can > perform actions; it can immediately alter the behaviour of > Enlightenment. I imagine that if it only changed configuration, it would 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. > be very simple. So, if you are telling me that unfortunately I cannot > have all the features of enlightenment_remote, can at least we have a > tool to edit Enlightenment's binary configuration files via the command > line? Most Unix application (including window > managers) can be configured by editing text files. And I don't think > that's just tradition, I think it is very useful. it's a vector for screwing the config, making e's job harder in parsing it and sanitising it. this is possible - but in the end - i don't see myself spending time on it. you have everything you need or want via gui controls. we are going to extend remote control via dbus so we don't need to write a client, and allow modules to extend remote control as they see fit. basically put in place the ability to have what you want, but we just don't want to sink the time into all the code. > One quick example: suppose I decide to make a big change in my > keybindings. Am I supposed to use the GUI and change them one by one? yes. > If I could configure the keybindings through a text file* , > changing dozens of keybindings would probably be as simple as a query > replace. like what? i hope you know by heart all the x keysym names then! what about the modifier your press? do you know if its Meta? Hyper? Super? What's the Keysym or Keycode for the play/pause button on your keyboard? what about the "Shuffle" button? E manages to remove needing to know any of this - it takes it from INPUT. if you need a feature (like having a universal modifier and changing it for all bindings) then say so and we can add it to the UI. simply relying on text editing as a crutch is a bad thing. > * I can do that now by telling enlightenment_remote to dump the > keybindings, then edit the resulting file, then tell enlightenment_remote to > delete the current keybindings, and then tell enlightenment_remote to add the > keybindings from the edited dump. Sounds like it takes some time, but is far > quickier than it would be to use the Enlighenment's GUI and click on each > keybinding that needs changing. I do it all the time. i really don't believe that. if you are doing this all the time - something is deeply wrong. you are literally en-masse changing keybindings all the time? why? i might touch them once on setup to add a few (eg my media keys), then not know or see the bindings for weeks or months - then need to add another to launch some app or whatever. why do you need to keep changing them? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
