Hello. On 08/16/2013 01:45 PM, David Seikel wrote: > On Fri, 16 Aug 2013 09:27:41 +0100 Stefan Schmidt > <[email protected]> wrote: > >> Hello. >> >> On 08/16/2013 09:06 AM, David Seikel wrote: >>> On Fri, 16 Aug 2013 08:50:02 +0900 Carsten Haitzler (The Rasterman) >>> <[email protected]> wrote: >>> >>>> one of those platforms... that efl is shipped on by default, >>>> doesnt use systemd for this (but it should), so abstracting is a >>>> must as we then already have 2 paths. we ALSO have upower... a bit >>>> older than systemd and some distros wont go "systemd"... and then >>>> think bsd. they may have their own things (i have no idea what >>>> they are), but it gives a point for them to plug in and abstract. >>> >>> Then there's things like Windows and Mac OS X. Systemd might not >>> even be an option in some places. As much as I hate it, and would >>> prefer to just ignore it and hope it goes away, Windows counts as >>> one of the "ones that matter". Mac also counts, but at least it's >>> kinda, sorta, Unixy under the hood, and I can live with that. >> >> I curious here. Where does this "counts" come from? It sounds like >> set in stone without given reason. >> >> If we would have a big developer base bringing in patches for Windows >> or Mac I could easily understand that but we don't have that. We have >> a patch here and there but nobody is really looking into that. >> >> There might be a big user base for some apps running efl on these >> platforms but without developers that are interested in it this falls >> apart quickly. Right now we have the situation where people like me >> who are totally uninterested in Windows support fix things to get a >> mingw build working. Which tells me that people that use it with >> windows either keep their patches private or use really old versions >> of efl. >> >> So having something marked as "counts" which is barely supported by >> anyone upstream is kind of funny. > > And there is our problem. TL;DR version - we need to make sure EFL > works on Windows (and other places) so that us non Windows coders don't > have to deal with it. No one wants to, but let's not shoot ourselves > in the foot.
Lets comment on the long version. Old enough to have a attention longer then 140 chars. > Well, they count for me. I want to use EFL for a large existing project > where the Linux users are a very small minority. The Mac users are a > small minority as well, but they are kinda vocal, even if so far none > of them actually offer to help. Quite frankly, if I don't have a > Windows version, no one will be interested in using the results. > > On the other hand, last century I got burnt out doing Windows > development. So I'm rather reluctant to actually do it myself. Stuck > between a rock and a hard place here. It's something that I'd much > rather someone else deal with, so I can keep myself from going any > more crazy than I already am. To be honest this translates for me into: I have a windows and mac userbase for the project I work on but I want efl to cover all the needed bits for me. > I believe in EFL as a cross platform development library. On the > desktop, Windows is still the 900 pound gorilla, which is why any > development library has to work there to be taken seriously. Decisions > like this one boil down to "be Linux specific" vs "try to be generic", > really should err on the generic side of things if at all possible. > Every little decision that locks us closer to a specific platform drives > away people that want or need to do cross platform development. As > much as I don't want to work on Windows, I also don't want to switch to > using Qt, or GTK, or any of those other systems. Generic and abstracted always sound so nice and clean. BUt we have to face that it means duplicating tons of stuff inside efl which is already handled somewhere else. And I think things like systemd or udev are well better suited for handle system level stuff we do in modules like cpu, backlight, etc, etc By having all this covered on the lowest level (like supporting 4 different sysfs layouts for backlight) we have abstraction and are generic but we also have to do ALL the maintenance. And we don't even cover such things on windows. We stuff them into E and not efl. > As dirty as it makes me feel to say it, Windows support is important. > It's a really big pity that our major Windows developer left for > reasons that are a complete mystery to me. It's a dirty job, but > someone has to do it. Who is this someone? I see patches for BSDs coming in from time to time and Vincent did a good job keeping the windows stuff running and expending it. What we really have to face is that we actually nee people doing the work. Its nice that people like you want to serve such a big userbase but if none of the active developers is using such system or has an interest in it this will just not fly. I recently added mingw support to our jenkins continuous integration builds. Which means every push into the efl repo will now get cross compiled with mingw for windows. That will notice us if a commit breaks the build for it. BUt that really is nothing. I never tested the resulting code to actually run and behave. I just don't care enough. And I wait for people that actually do, stand up and doing it regularly over a long period of time. Contributing fixes and maybe extend the support. Without this the code bitrots and is useless anyway. > I really do want to get stuck into serious work on the EFL version of > this large existing project. And for this project, it's gotta be > Linux, Mac, and Windows. I'd love to say "screw you, you non Unix > Windows users, get a real OS", but I can't. > > The one thing that has been holding me back from getting stuck deeply > into the EFL side of things for this project has been lack of a Mac, > since I can't legally do Mac development without one. Damn Apple. So > I have little bits and pieces of this project that only work under > Linux, and no one is using them. Once I get a Mac for development, > then I got no more excuses, I'll just have to actually start serious > work on making sure my EFL version actually works on Linux, Mac, and > Windows. And yes, any thing I need to do to get that to happen I'll > contribute back to EFL. I can fully understand that this gets hard with the fast pace efl is evolving nowadays to keep up with upstream on the one hand and a project which screams for stability on the other hand. But to reiterate this point without some people constantly working on windows and mac support upstream in efl it will just not work. > It sucks, but as much as we want to, we really can't ignore Windows. Maybe you can not but I can do it easily. With a blink of the eye I can ignore it out of my life. Easy as that. :) You have to find a group of people that feel like you to form this we and make progress to work on it regularly. > Yes, I know, just like every one else, I really want someone else to > handle that horrible piece of crap. But I'm passionate about my large > existing project, so eventually I'll have to suck it up and deal with > it. In the mean time, let's try to avoid locking things down to Linux > specific stuff when we don't have to. Let's not make dealing with the > huge stinking pile of garbage that Windows is even harder on those of > us that are forced to. > > Let's hope we can find someone that does not die a little inside each > time they deal with Windows to work with us. This call was not heard for such a long time that I would not hold my breath for it. Its not my call here anyway so it most likely will stay but my personal opinion would be that if nobody stands up to really work with it this things should just go. I already here all the screams coming in for such a statement. (With real work I don't mean a compile run, I mean having the libs running and develop real world applications with it. Digging into bugs and contribute the fixes upstream). regards Stefan Schmidt ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
