On Fri, Dec 28, 2012 at 11:07 AM, Carsten Haitzler <[email protected]>wrote:
> On Fri, 28 Dec 2012 10:16:15 -0200 Gustavo Sverzut Barbieri > <[email protected]> said: > > > On Friday, December 28, 2012, Carsten Haitzler wrote: > > > > > On Fri, 28 Dec 2012 01:58:49 -0200 Lucas De Marchi > > > <[email protected] <javascript:;>> said: > > > > > > > On Fri, Dec 28, 2012 at 12:28 AM, Enlightenment SVN > > > > <[email protected] <javascript:;>> wrote: > > > > > Log: > > > > > work around edbus issues by forcing the mainloop to run at least > one > > > > > cycle with some dummy things... in ipc launch mode. > > > > > > > > > > also make selection jump to end if a newline is there - as > disussed > > > on > > > > > ml. > > > > > > > > could you detail a little bit what is the issue. Looking at the code, > > > > I couldn't understand why you put all this ipc stuff, instead of > doing > > > > something like eve does. > > > > > > i put this in to: > > > > > > 1. avoid relying on dbus (not going to have a session bus when you are > in > > > the > > > fb... for example :))... with e_dbus vs edbus at least for now this > would > > > make > > > it hard to have terminology work with stable efl. > > > 2. avoid relying on a lower level windowing system (this can work in > > > wayland, > > > windows, framebuffer itself etc... tho fb means we cant do > 1 > window... > > > if we > > > had "tabs"...)... > > > > > > dbus *IS* ipc... it just happens to be ipc with the added raised bar > of a > > > dbus > > > daemon broker. i chose to do it the simple way - a simple unix socket. > > > > > > Let the mess begin. What an awful argument. Is that just being lazy or if > > we convert it you'll block the patch? > > how is it being lazy? it is actually a bit more work than using edbus. or > e_dbus. > > edbus is not released and depending on it will be a problem until a > release of > edbus is out. > > e_dbus is being deprecated so adding e_dbus code now is silly. > > dbus wont EXIST as a session if you use terminology in the fb and that > happens > to be an awesome selling point of it. the ability to just run terminology > even > from inside of itself and get another "tab" even withni a single vt is a > really > nice thing. > > if dbus were used, this would tie multi-instance launch to a dbus session > environment. efreet already now has created a mess by using a session > bus... > because now entrance is SCREWED. sure - terminology wont be in entrances > bucket, but it has a different bucket... and working in the fb without any > dbus > around AND having this feature work is important to me. > indeed this is a problem with many distros setup that launch dbus session from Xsession rather from PAM session, then you just have a session per X, not per user. but bashrc could do that very easily anyways. Note: the only different here from your ecore_con approach is that you fixed the name path, while the dbus one is variable. > dbus - let the mess begin. if you want to go to such extremes and just > blanket > decide that if you don't use dbus you obviously have a mess. i'll take the > opposide view - if you use dbus you open a can of worms of a mess as per > the above. the atitude of using a specific named technology for the sake of > using it is going to guarantee a mess. i made a judgement call on this. it > just > doesn't happen to include your favorite technology. > the thing is that you end with more problems to solve: handle with stale socket files, simultaneous activation, etc.. remember the mess with efm_op daemon that would race when multiple processes were started at the same time? i thought about using dbus. i chose against it for various reasons. part of > it > is transitional, part is that terminology needs to work and have its > multi-instance stuff work in a non-dbus environment. i dont see how this > is a > mess. it is not a source of any issues at all right now, and is unlikely > to in > the future. we have a whole hulking infra for EXACTLY this reason. it's > there to > be used when the situation is right. it's called ecore-ipc. it exists for > this > purpose. it's an alternative communications channel. it's not a mess. it > means > this works regardless of dbus being there or not. i see no *BENEFIT* to > making > it use dbus (edbus or e_dbus). i see only downsides. there are other > situations > for other people and needs. dbus may be appropriate and the best solution. > in > this case it's not. > ecore-ipc is a thin wrapper over pure socket and doesn't solve the leaving stale sockets on death, neither it helps with single instance and races during starts. other situations where dbus is a poor choice: high volume data traffic or > where > latency is highly important (implementing x protcol via dbus would be one > of the > most braindamaged things you could ever due to it it having high volume and > being very latency sensitive). you didn't complain that ecore-evas-extn > uses > ecore-ipc? is that a mess because it doesn't? it transport update region > commands and input events via ipc... DIRECt from process a to process b. > it's > another situation where dbus would be a poor choice. a different reason to > terminology, but, a reason. i'm not saying it was an answer for everything, but terminology's case is one it fits well. as for extn, it could do or not with that, it's not the best example of implementation anyways, you send one command with one update rectangle for every update, even if you had the list of all updates beforehand and could send as an array (and it was leaking, I just fixed that). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
