On 10/29/11 00:44, Carsten Haitzler (The Rasterman) wrote: > On Sat, 29 Oct 2011 00:25:55 -0400 Christopher Michael<cpmicha...@comcast.net> > said: > >> On 10/28/11 22:23, Carsten Haitzler (The Rasterman) wrote: >>> On Fri, 28 Oct 2011 22:46:55 +0200 Cedric BAIL<cedric.b...@free.fr> said: >>> >>> i'll post here as a summary. what k-s wants is to just release e17-as is >>> after fixing some efm bugs. who agrees with that? everything stays as-is. >>> >> Sorry, cannot say that I agree. While e17 may be Close to release, to >> put it 'out' now is premature imo. There are still a few things that >> need fixing and/or ironing out. >> >>> the reason xrandr is on the todo is that there are many complaints and >>> questions about how to get multi screen to work and we have no solution. >>> >>> the reason taskbar is there is because engage is compositing based >>> realistically and we have to work without, and we again have had enough >>> users complain and ask for a way to switch tasks. >>> >> What about the taskbar module ? Anyone know it's current 'status' ? Is >> it usable for the average person ? Are there some issues remaining ? Are >> they simple bug fixes ?? I'd lean more toward including it (rather than >> engage) for the simple fact that taskbar does not 'require' compositing, >> and severs the purpose for the 'average joe'. > > i actually read its code - it's mostly ok, but it has lurking bugs like not > reffing e border objects. i've already begun a new tb code in my e tree but i > also need to revamp its horizontal (and vertical) layout as well as add a > feature to gadcon to make it work sensibly and not make shelf expand beyond > the > bounds of the screen. i've already started here and my only goal is to make a > workable taskbar that isnt going to fall over in cases and then move on. > Well mate, slap it into svn somewhere and we can all jump into the fun ;) (time permitting of course).
>>> the reason efm is on the list is its mostly working and usable as a simple >>> filemanager - that was its point. it needs some bugs fixed. >>> >>> the reason keymap config is there is for all those europeans (and a few >>> others) with odd keymaps and people have no clue how to configure this on a >>> command-line or in config files. the other todo items could get dropped, >>> though theme does need to be polished. >>> >>> this wasnt unilaterally decided by me. i believe in making a good attempt >>> at a quality release. gustavo just believes in dumping out whatever we have. >> This is where gustavo and I disagree. I'm w/ you raster...would rather >> have a quality product to release, rather than taking the >> short/quick/easy way out and just 'release what we have'. If we take the >> later route and just release things 'as they are', then we could end up >> getting a reputation of premature release (gnome3, unity, and other such >> junk)...which I (for one) would rather avoid. Better to take the extra >> time and get things right. Oh I know I will get the "He's just in >> raster's camp anyway" people/complaints...and I'm fine with that simply >> because it's the right way to go about it. Why release something that is >> incomplete/half-arsed ?? > > that's indeed my point - and we are so CLOSE to being "done". it's impatience > at the last leg of the race. > Agreed. But to 'jump the gun' and release early (read: earlier than ready) at this stage is just silly. Take a little more time, finish the work properly and have a Good release !! rather than a half-arsed one. Hell, we've hammered on this for more years than I care to count...what's a few more months ?? ;) dh >> dh >> >> >> all the >>> bitching about gnome and others will happen to us if we don't provide these >>> basics that gnome etc. already DO. to many people we are useless. these are >>> not new fangled ideas or standards - this is old hat that we haven't >>> covered. so how do u expect to make those people happy and try or stay with >>> e when we are not functional in some key aspects? >>> >>> get these above done and we can do an alpha. >>> >>>> On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz<m...@zentific.com> >>>> wrote: >>>>> On Fri, 28 Oct 2011 11:07:45 -0200 >>>>> Gustavo Sverzut Barbieri<barbi...@profusion.mobi> wrote: >>>>>> I'm writing this mail so it's unified and everyone can opine without >>>>>> being in one place at one time (IRC/#edevelop). >>>>>> >>>>>> Recently I've talked to people and while I tried to express it at IRC, >>>>>> raster just got pissed and left. Later people would join and agree >>>>>> with me... so while I'm looking like a jerk I guess I'm not alone in >>>>>> there. I'll try to be as clear and short as possible. >>>>>> >>>>>> WHY RELEASE? >>>>>> 1. to clarify we know some snapshot is usable. This will get us in >>>>>> more distributions by default. >>>>> good >>>>>> 2. to remove that stupid karma over the 17 number if e. Will help >>>>>> people that do not track us closely to know we're reasonable serious. >>>>> people will probably still call it e17 even when we're on e20 >>>>>> 3. we can start to bring in new technology without delaying it even >>>>>> further (ie: elm and scripting language - js/elev8) >>>>> not really a valid reason to release, you can see it did wonders for gnome >>>> >>>> http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1 >>>> >>>> I don't really see the link with what you are saying. >>>> >>>>>> WHY NOT RELEASE? >>>>>> 1. there are both bugs (eg: efm) >>>>> cedric has said a number of times that he'll be working on efm after he >>>>> finishes emotion soon, and I'll likely disable eeze mounting entirely for >>>>> the release since libmount is not widely deployed and I was unable to get >>>>> widespread testing until now. >>>>>> 2. missing features (xrandr, taskbar, ...) >>>>> * xrandr patches have been made and are on the list waiting for testing >>>>> and review, so I'm not really sure why this is a "missing" feature. >>>>> * New users will not be able to deal with E17 if it doesn't have a >>>>> taskbar, end of story. Engage is in SVN now, it's usable and widely used >>>>> already, it can be merged. >>>> >>>> No you can't ! Doesn't solve the problem for non composite use case >>>> and as long as we don't make the compositer the only possible choice >>>> we can't say that engage is the answer to that problem. >>>> >>>>> * I don't care about keymap config since I'm american, but it seems >>>>> important for users to be able to type in their own language >>>>> * b&w is awful, we should switch to and iron out detourious for release >>>> >>>> Yes, that's something we should do as soon as possible. As a side >>>> question, what is the status of that theme for elementary ? Because it >>>> would make sense to also do the switch for elementary at some point. >>>> >>>>> * Improved connman support is a big sticking point for me. I strongly >>>>> believe that if the module does not improve now while it is actually a >>>>> blocker for release, it never will. To this end, it's missing 3 big >>>>> features that I can see people using: hidden network support, static ip >>>>> setting, and enterprise encryption. It's likely that this is not actually >>>>> a 6 month project as you have implied. >>>> >>>> Well, I have been using connman module since now one year and there is >>>> only one place in the world where I would have liked to have a UI to >>>> set static IP and a VPN... I am sure that's raster is in that place >>>> most of the time like some of our user base :-) So not a strong >>>> requirement from my point of view, but maybe some people at Samsung >>>> could take over that item as of course you are all using E17 ! >>>> >>>>>> EXTRA DISCUSSIONS >>>>>> * e_widgets is amazingly boring and gets in the way, people expect >>>>>> something like Elementary to help them. Or even better, for rarely >>>>>> used features like a mixer control dialog, xrandr dialog, connection >>>>>> manager configuration these things could be done with a high level >>>>>> language such as elev8. Thus lots of people would be motivated to help >>>>>> get more features in. But introducing this now would delay e17 even >>>>>> more, thus a no go. (Personal note I'm highly demotivated to hack e17 >>>>>> due this exact reason. Doing a mixer dialog in e_widget is like few >>>>>> days, in elev8 it should take me few hours -- easier to find than few >>>>>> days) >>>>> No argument here, though I think it's more an issue that e_widgets lacks >>>>> documentation. It works fine and is actually easier/faster to use than elm >>>>> in a lot of cases once you get the hang of it. >>>> >>>> Well, I think we both are doing hugly UI, maybe we should not comment >>>> on that part. >>>> >>>>>> * we'd like to have an officially supported and widely accepted >>>>>> high level language. While I've created and maintained Python, seems >>>>>> it's hatted and going nowhere. So if it's Python, Lua or JS it >>>>>> doesn't matter, but we need one for most boring things like >>>>>> configuration dialogs and non-critical paths... (READ: I don't want it >>>>>> to be in composite manager, eborder, etc -- tho I'm open to have them >>>>>> in gadcon) >>>>> This is going to be a pain for those that don't know the scripting >>>>> language chosen, but I suppose the onslaught of progress must not be >>>>> stopped. >>>> >>>> You know what, you can code in JS like you do in C. You just need to >>>> remove all that useless typing. So any one of us that know C, will be >>>> able to understand and patch JS as soon as you use it. >>>> >>>>>> AFTER RELEASE: I propose time-based releases, every 3 months we cook a >>>>>> snap and put it out. Seems to work well for everyone out there, can't >>>>>> see why it wouldn't work. IMO we can't have feature based snaps >>>>>> because we don't have enough manpower to do this promises. >>>>>> Longer release cycles are problematic as "wait my nice feature to get >>>>>> in, it's one more week! Otherwise I'll have to wait 6+ months to get >>>>>> it in!" and then this repeats forever as we see now. >>>>> reasonable >>>>>> >>>>>> >>>>>> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for >>>>>> xrandr, keyboard languages, taskbar. Users will complain, period. >>>>>> We'll never be able to cope with minimum features, as this changes >>>>>> from person to person. Moreover, the more we wait, the more we have to >>>>>> do. Right now all other desktops implement the new systray and >>>>>> application menu protocols, really soon this will be "a bare minimum" >>>>>> for some users. There is proper PulseAudio mixer. Proper >>>>>> ConnMan/NetworkManager. Soon we'll have the user-session and seat >>>>>> management that GNOME is doing with systemd... This list is lways >>>>>> growing. But we're short on human resources. Having a release and >>>>>> getting Elev8 into E would help bringing more people to help. >>>>> If we cared about user opinions so much, we probably wouldn't be working >>>>> on E17 at all anymore. As for new minimum features, let's be realistic: >>>>> nobody is ever going to implement that stuff before E17 release even if >>>>> it's a requirement. We got pulseaudio support (the newest "desktop" >>>>> feature) because I had fun abusing the native protocol, and that's not >>>>> even cutting edge. >>>> >>>> That's the point of increasing the size of our community, so that >>>> people that think it's funny to implement that kind of stuff do it. >>>> >>>>>> MY PROPOSAL: just fix the remaining efm bugs and other outstanding >>>>>> crashes and do a release as is. Remove the e17 karma and get back to >>>>>> normal life, get e18, e19... and things go into them as fast as we >>>>>> can. >>>> >>>>> End result: VETOED. >>>>> The items in http://trac.enlightenment.org/e/wiki/Release were discussed >>>>> and agreed upon for a reason. Your personal lack of desire to complete >>>>> them should not influence the release date, and others are actively >>>>> working on them. >>>> >>>> As stated in my previous mail, I am for jumping on releasing an alpha >>>> as soon as we have our main bug gone and try to target to do that at >>>> the same time as 1.1. It will just be a benefit, driving developer >>>> attention and maybe gather some help to finish the last round of work. >>>> Because face it, we have very few people motivated to fix the last >>>> item right now. But we have people that would have been helping if a >>>> few technological limitation where removed. So we need to shorten the >>>> painful path as much as we can. >>>> -- >>>> Cedric BAIL >>>> ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
