On Thu, 1 Oct 2009 03:22:39 -0300 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> no need to write such a huge mail... it's being removed for good. But
> functionality is not going away, nice guys are working on dbus-based
> replacement, to be loaded as optional module (so those like you can
> load and be happy).
>
> the replacement provides a shell script around dbus-send and accepts
> the same parameters as enlightenment_remote
indeed. if you want more configurability - we've made it possible via modules.
you can extend e any way you like without patching its source. modules can
expose any part of e you want as dbus remote calls. there are gui and cmd-line
dbus tools to access methods, browse them and call them (as gustavo said -
dbus-send, there's d-feet as a python gui to explore dbus and see whats there).
as for making e more kbd friendly - patches accepted. it's a lot of WORK making
something work well with the kbd and mouse. its EXTRA work. you're going to
have to help and provide patches and code. the priority is to make e usable
even for those who haven;'t seen a cmd-line before. it doesnt have to be
perfect, but usable. that means primary focus is in the gui. gui config.
everything gui. frankly its easier for ME (developer of e) to use the gui than
cmd-line. i prefer it. so you'll see a gui long before you see help in obscure
ipc tools. the ipc tool and the handelrs are an awful nightmare of code that we
just dont want to maintain. hell - it ISNT maintained. it has segv bugs in
there. no new config items have been added to e_remote for years. it's already
quite incomplete. its effectively dead weight floating about we really just
dont want on our hands anymore. it's not a primary focus....
but we haven't made it impossible. we have had demo dbus extension modules now
for years showing how to extend configuration via dbus. dbus has been used now
for years. it's fairly mature. we can now farm off the extra work we DONT want
to do (e_remote) to dbus and moduels supplied by the people who really care
about such access. if you REALLY must have it... then get up and write a module
to expose what you need. dbus is usable from the cmd-line. you can happily
explore all of e's dbus api via something like d-feet. you can call methods
from here too. e-dbus provides all the introspection apis of dbus needed for
this to work. we've handed the work over to those that really care about it and
taken it off the plates of those who don't. thats how good software development
works.
as for the future. core e provides dbus methods just enough to control the
core. nothing more. it's enough dbus api there to load a module - via dbus,
enable it via dbus, and have this module then extend e's dbus api more. it's
enough to bootstrap entirely via dbus and dbus-send (if u are willing to write
or help write or find a module to extend 's dbus api).
as for seeing the widget focused with tab in windows.. thats simply a theme
matter. adding a "focused" state. to be honest.. it just is a painful luimp of
extra work to add it to every single widget in the theme and i didn't bother
doing it. it also makes it look less nice. right now i'm just not bothering as
it's a low priority matter, but its all entirely up to the theme. the code is
there.
> On Thu, Oct 1, 2009 at 3:04 AM, Joe(theWordy)Philbrook <jtw...@ttlc.net>
> wrote:
> >
> > It would appear that on Sep 30, P Purkayastha did say:
> >
> >> Well, I am not so sure that the e17_setup.sh script is of much use
> >> now. enlightenment_remote has been "retired" and now things are being
> >> moved over to dbus based commands. The current enlightenment_remote is
> >> just a scripted wrapper to dbus and supports only a small subset of
> >> the commands of the earlier enlightenment_remote.
> >>
> >> That said, feel free to forward the link,- it will remain as long as
> >> google does not remove it.
> >
> > Now I'm depressed. I originally found enlightenment because when it began
> > to seem inevitable that (yuck) kde4 was going to grind kde3 under it's
> > treads I started looking for an alternative. Then I found a review of
> > enlightenment (that was based I think on e16) that mentioned it could be
> > configured to run almost exclusively with the keyboard. Since I have great
> > personal difficulty with pointing devices I then started looking into if I
> > could get enlightenment via the various package management systems of the
> > linux versions I currently run (Sabayon [gentoo based], Kubuntu [debian
> > based], & OpenSuSE ) And after I was able to install e16 on ALL THREE I
> > started to try to learn to live with it. As soon as I discovered how easy
> > it was to edit ~/.e16/bindings.cfg to get my primary user interface all
> > configured without resorting to the pain generating rodent, I feel in love
> > with it. I wasn't real happy with the gui tools I had to use to configure
> > the rest of it, but they were no more painful than kde4 had become, and
> > since the keybindings themselves were quick and easy to set-up, I felt like
> > I could make the other configuration changes a little at a time, which
> > helped avoid over stressing my wrists...
> >
> > I thought I was happy again. Then I discovered that there was a newer
> > version of enlightenment in the works called E17. I thought, "Oh NO!
> > Did I just jump out of kde4's frying pan to land in another skillet?"
> > I feared that this e17 would sooner or later do to e16 what kde4 is doing
> > to kde3. So I thought I better check it out to see if I was going to have
> > to keep an eye out for yet another Window Manager/Desktop Environment, Or
> > could I really afford to get hooked on 'E'.
> >
> > My first look at e17 wasn't encouraging until some nice person introduced
> > me to enlightenment_remote AND a marvelous script that made it relatively
> > easy to use called e17_setup.sh... (thanks again ppurka) And I began to
> > believe that I could afford to get used to the up and coming version of
> > enlightenment. Now It's almost as rare that I use e16 as that I would load
> > kde anymore. Especially since the new kde4 versions of some of the programs
> > I'm addicted to cause it to lock up more often than e17 (I hate it when I've
> > got several different kinds of documents open, some with unsaved changes,
> > and something suddenly causes the gui to stop listening to either the
> > keyboard or the mouse...)
> >
> > But now you tell me that they are in the process of throwing away the only
> > keyboard based configuration tool there is...
> >
> > ---------<({ whimper, sniffle, ARGGHA!, sigh, whimper... })>---------
> >
> > You know I don't mind things being designed to make things easier for point
> > n click methods, (some of it is a good thing) But I get really frustrated
> > when the programmers don't bother to include good keyboard support.
> > Especially when it used to be there.
> >
> > I don't suppose this dbus stuff is scriptable in any meaningful human
> > readable way... (IE by someone who isn't a source code programmer)
> > Or to put it another way, Who do I gotta kill to get them to keep something
> > like enlightenment_remote around, even if it's really just a wrapper
> > written to keep as many things scriptable as possible...
> >
> > [rant-mode]
> > Otherwise is there a way to convince them to make the gui more keyboard
> > friendly. (Yeah I know it's *_usually_* possible to use the tab, arrow, and
> > enter keys. But I've noticed that it's not easy to see where the enter
> > key's "focus" is. {Except when it's inside an editable text field.} IE to
> > use the "alarm" gadget to set a quick one time reminder, I first have to
> > fight with the mouse long enough to give it a right click, WHICH, if I'm
> > lucky enough to be able to let go of the mouse without the pointer
> > winding up inside the pop-up menu, AND if I didn't accidentally hold
> > the click too long so that the pop-up disappears when I release the mouse
> > button... Then I can use the keyboard to select 'add an alarm...' At which
> > point it takes 2 tabs to reach the alarm name field, the next tab gets me
> > the description field. The next two tabs are for the time sliders which
> > can be moved with arrows (God how I wish I could just type the time into
> > the text display window next to the sliders...) Then it's a clue how
> > painful the gui is for a keyboard centric user that I actually know it
> > takes 10 more tabs to get to where I could type in the date, But at that
> > point I'm only one tab away from the today button (two from the one I
> > need to set an alarm for tomorrow) then another 4 tabs away from the ok
> > button, (3 if counting from the tomorrow button) I know how many tabs it
> > takes because I sure can't see which button, checkbox, or radio selection
> > would be made by tapping either the enter key or the spacebar without
> > blindly tapping on the enter key or spacebar to see what changes... God
> > forbid that I should get interrupted and lose count. Cause then I have to
> > tab, squint at the three editable text fields to see of that skinny
> > cursor line has appeared yet, and keep tabbing till I know where it is, so
> > that I can again count the tabs to the button (etc...) I want.
> >
> > I hate to borrow from Microsoft, But I suspect they stole the idea from
> > somebody else anyway... Why can't the label for each field, button,
> > etc... have an underscored letter that in combination with the alt key
> > will select the appropriate button, field, etc... so that navigating the
> > gui with the keyboard wouldn't be so much of a pain???
> > [/rant-mode]
> >
> > Seriously though, I thank you again for your kindness. And e17_setup.sh
> > even if it's days are numbered. Actually, though, the good news is that the
> > fact that I'm dependent on distro-based package management (and associated
> > repos) means that it will probably be a while before the versions of e17
> > I wind up with will have done away with enlightenment_remote...
> >
> > --
> > |
> > | ^^^ ^^^
> > | <o> <o> Joe (theWordy) Philbrook
> > | ^ ` J(tWdy)P
> > | ___ <<jtw...@ttlc.net>>
> > | ' `
> >
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry® Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > enlightenment-users mailing list
> > enlightenment-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >
>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> 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) ras...@rasterman.com
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
