On 6/30/2011 3:03 AM, Dimstar / Dominique Leuenberger wrote:
On Thu, 2011-06-30 at 03:28 +0400, Ilya Chernykh wrote:
If some people do worry a lot about the frameworks and libraries used by their apps, they need some real concerns in their life. There's no need for openSUSE to spend time feeding into more of this silly toolkit purism nonsense.
If people do not care which applications they install, they will find out that the desktop settings they had set up do not apply everywhere, a disappointing discovery.
I think THIS is the underlying problem that needs to be addressed, and NOT what toolkit an application is written in.
I'm by far not a purist when it comes to the choice of my applications. As long as the app does what I need/want and is appealing, I could really not care less what the dev used as Toolkit to develop it. That's just not my problem. GTK, Qt, Wx... all have their pros and cons.. some devs might love to hack X11 code directly :) Their choice! Who am I to say: nah: you use X11 directly: I don't want to use that app if the app is exactly what I need?
Unless I need the app very badly, like it's for work and there is no sufficient substitute, I absolutely do not want to use an app that unnecessarily pulls in a lot of dependencies. That makes the rest of my box and the rest of my experience crappier in many indirect ways for the sake of that app. Lack of caring about things in general is why so many things are crappy in general. Caring only about the outermost skin of visible symptoms instead of root causes is described by those guilty of it as "being practical" but really it's just why so many things suck. Not just software or other technology but business and politics and everything that people do. By allowing someone to feed you something that seems to look ok on the outside and not caring at all how it works on the inside, you reward the worst kinds of work with success.
Back to the topic: I am aware of a bunch of applications mainly ignoring proxy settings from the desktop. This is indeed very frustrating, as you'd need to configure proxies in various places.
THIS for example has been solved with the introduction of libproxy, which passes the 'right' configuration down to the app.. extracted from the running session, whatever it is. Not to say the solution is perfect, but it goes in the right direction.
Same approaches can be done for similar problems. All that needs to be done to 'sell' this to App devs or even better get it deep nested in the toolkits (happened for example on the GTK side, as libproxy is needed by libsoup and glib-networking). Same should happen with Qt for example.
=> Target the actual problem, don't try to conveniently maneuver around it.
Interesting statement from someone who just said they don't care how an app was developed as long as it looks and works ok from the outside. Actually you raise yet another point for caring how something works rather than merely that it works. Back in '07 there was a nice little thread on the libcurl mail list about having libcurl use libproxy. The libcurl developers and most everyone else except the libproxy developer decided it was a terrible idea and rejected it for various quite good reasons you can read the thread yourself to find out more about. But the curl developer did say it sounded like a good idea for curl the commandline tool to use it. I see that 4 years later and despite the list of libraries used by curl growing rather a lot, libproxy still isn't one of them. I'm glad of it since I don't want that possibly breaking critical EDI transactions on all my production servers or doing unnecessary web calls, or including a damned javascript interpreter to ecxecute pac files searching several local and remote files for _possible_ proxy info that in actuality never ever exists for me so 100% of that overhead is waste not to mention the unecessary added potential to break stuff if it should happen to think it actually found proxy info it should use, perhaps say placed there by an unwitting user or a very witting malicious script. There are countless reasons for caring how a thing works rather than just that it seems to. They are different for different people and in different situations, but they always exist. In some situations I would prefer an app that uses X libs directly, and in others I would prefer it used a standard toolkit even if the raw X app looked just as good and was just as feature rich. In some cases the need for all those gnome and/or other libs would be a problem, in other cases the non-standard code that would be difficult to work on and would not benefit from library updates would be far more of a problem. And we haven't even touched on the whole world of licensing issues. You may not care how some software is licensed but I sure do, and really so do you whether you think so or not. You surely care whether or not some software even exists, or is usable or is affordable, or is 10 years behind the times in features and interoperability. Heck, what about all the developers that only even develop for Windows or iphone? They picked a toolkit that works for them and the resulting app does the job great so what else matters? Android and Linux users sure care what app framework was used for those apps. I sure as heck cared when there was no way to play audible.com books on my palm pre other than breaking their drm. Even after more than a year the $60 palmos emulator never got good enough to really use for that app. If someone chose to use Flash to make a web site or adobe air to make a android app, you'd sure care what toolkit they chose since those either don't work at all in a lot of os's or hardware, or are grossly inefficient battery killers when & where they do work. If someone chose to use c++ or c99 code which isn't even compilable on many systems you'd sure care if you were stuck on such systems. If they used kernel features that don't even exist except on one or a few OS's and only recent versions of those you sure care if you don't happen to be on that same os & version. For instance I sure wish we had _good_ zfs on linux. Oh well. sun developed it on solaris and sun hardware and even the next-best supported platform FreeBSD it isn't production quality, let alone linux. I have a customer that needs to do frequent automated ftp-ssl transactions with one of their customers. The other side is running a terrible ftp-ssl wrapper thing called GlubTech that attempts to grant ssl to a stock Windows iis ftp server. It sucks. None of the common linux utils that can do ftp-ssl works on this server and the GlubTech developers claim it's because curl and ncftp etc all fail to follow the ssl spec correctly. The only thing that works with their server is their own client. They don't suppy a linux client nor is their code open, but luckily they do supply a java client so it's at least possible to run it on linux, and luckily they do supply a (terrible, kludgy) cli mode in that client so it's at least possible possible to run this from non-interactive cron or inotify scripts. Barely. It's ugly as sin and this is the single and only reason I need java even installed on any of my systems and it's inefficient and slow and a cpu hog compared to doing the same exact job with curl or ncftp. I sure as heck cared about the difference in toolkits that curl used vs what GlubTech used even though they both produced a working "ftp-ssl client" The more I think about this the less reasonable that statement sounds to me. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org