On Fri, May 22, 2015 at 7:42 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 20/05/15 12:55, Simon Lees wrote: > > > > > > On 05/20/2015 08:29 PM, Tom Hacohen wrote: > >> On 20/05/15 03:48, ChunEon Park wrote: > >>> And additionally saying, > >>> > >>> EDC will break app theme compatibility acutally. > >>> > >>> If applications want to develop the system based themeable apps, > >>> they should not touch the edc, they should write the gui with only elm > widgets. > >>> > >>> See the efl applications, the most application may write the layouts > with edc. > >>> they design the layout look&feel compatible with current elm theme. > >>> > >>> Now say, if there new elm theme come? > >>> How they guarantee their edj gui compatbile with new elm theme? > >>> > >>> The application gui will be totally broken or ugly. > >>> > >>> App should not use the edc as possible, > >>> Writing edc is harmful potentially, app should depend on the gui with > elm controls more than edc. > >>> We should not guide using edc in apps as possible. > >> I'll properly reply to the next of the thread soon. However, just to > >> touch what I think is the point of confusion here. > >> > >> While I generally agree with the notion of what you are saying about > >> what developers want. > > I'm just going to comment on this point well for now anyway and i'm > > going to comment on it with my distribution integrator hat on more then > > my theme designer or application developer hat on. If were talking about > > embedded / mobile apps you have a fair point, I have spent a lot of the > > last few years working on a embedded UI which looks nothing like a > > desktop UI as it shouldn't, rather then using a full desktop toolkit all > > you really need is a label images and a layout engine (gradients and the > > ability to draw rounded rectangles are a bonus), this doesn't sound alot > > like elm so elm is probably not the best solution here (we use a very > > small subset of Qt but anyway i'm distracted) > > > > If were talking about desktop apps then there seems to be a fair > > disconnect here between what developers want and what users want (as a > > desktop integrate its my job to interact between the two groups). What > > users want and what i'm often after is a consistent look and feel > > between all there apps so they feel like they have 1 unified system. > > Jeff, Duma and the rest of the bodhi team have put huge amounts of > > effort into getting this right because its what there uses want (on > > openSUSE were still getting there). If designers and developers want to > > there apps to look special like chrome or spotify they are wrong because > > users are always right (they will just stop using your apps) I refuse to > > use apps these days that don't look reasonable against a properly dark > > theme. > > > > The main reason people use Qt is because there apps will fit the system > > regardless of what OS there running (OSX) users seem incredibly fussy to > > the point where most people didn't consider using QML in desktop apps > > until it supported native looking widgets. > > > > Thats all from me for now. > > > > I'm not sure about what users want. If you're asking me, I think users > probably want (or should want) a consistent feel, and maybe a consistent > look, the latter not being a must. If the web and app markets have > taught us anything, is that app discovery is really hard, and devs would > like to do whatever possible to stand out. Also, a platform needs to be > flexible to let developers reach their full creative potential, not > force them to a unified look if they would rather not be forced to do it. > > If users think otherwise, let them vote with their feet and not use > those apps, though I doubt that will ever be the case. > > I think the main reason *developers* use Qt is because it's > cross-platform and actually runs on all of these platforms and doesn't > look butt ugly. I think whatever else there is sugar on top. Not sure > about QML adoption, but if I had to guess, it was just a matter of time > and polish, and we can't really point on a specific feature and claim > it's responsible for everything. > > This is however what I think, not what Elementary does (although > Elementary enables what I want too, which is themeable applications > regardless of the system theme with it being possible to use the default > theme). > > I also believe that developers, and not end-users are our clients, and > we should adjust ourselves to their needs, not the needs of the > end-users, because if developers don't use our software, neither will > end-users. > > -- > Tom. > > I totally agree with Tom at this. *Developers are our clients, not end-users*. You are spot-on. > > Simon Lees > > > > openSUSE Enlightenment Maintainer. > > > >> You are off the point here. Elementary the widget > >> toolkit is themeable and that's one of the visions/promises of it. You > >> don't like it? You probably shouldn't be using elementary. > >> The right place for what you want is not in elementary, it's in a > >> separate toolkit that is not themeable. That's similar to what Daniel > >> Kolesa said (which is in turn a summary of what we talked about on irc), > >> you need a libnon-themeable-elm that does that. > >> > >> Why? Again, because it's not part of Elm's vision, for better or worse > >> that's the promise our users get. > >> > >> -- > >> Tom. > >> > >> > >> > ------------------------------------------------------------------------------ > >> One dashboard for servers and applications across Physical-Virtual-Cloud > >> Widest out-of-the-box monitoring support with 50+ applications > >> Performance metrics, stats and reports that give you Actionable Insights > >> Deep dive visibility with transaction tracing using APM Insight. > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
