On Fri, 28 Dec 2012 13:10:32 -0200 Gustavo Sverzut Barbieri <[email protected]> said:
> 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. it's not fixed. it's variable. :) check the code. :) > > 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? no - as efm_op never was a "daemon". e17 was the daemon - it connected back to e and then provided status updates. :) dbus would not change that. > 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. only one owner can get the socket. you won't get two. only one will succeed in gaining the server socket. > 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. i disagree. as above. enough cases where there is no session bus where i want multi-instance to work. > 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). it also sends back input - every key, touch and mouse event goves via that channel. > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 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_122912 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
