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? 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. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

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

On 2011-06-29 Martin wrote:

Tirsdag den 28. juni 2011 15:14:58 skrev Ilya Chernykh:

...

I first discussed this issue with coolo in private but possible a wider range of ideas may be beneficial.

All of us know that is is sometimes confusing to find a package which belongs to your desktop environment, whether Gnome or KDE. Sometimes you have to look into package's dependencies to find out whether it is written in GTK or Qt.

As the number of desktops increases, the problem only becomes worser.

Currently the packages are classifies using the RPM groups. But for the most packages this groupping only reflects the package's purpose, i.e. network, game or office. This groupping is organized as a tree, and there is no possibility to add another categorization.

An obvious solution is to add a desktop environment name to the package's name such as prefixing all KDE apps with "kde-" or simple "k". But this is also confusing and may require much of work as renaming is not an easy task.

So are there any ideas on how to organize this better?

If people don't know the underlying technologies of the apps they're installing, they prolly don't care - and why should they.

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.

Agreed. While Ilya has a point that some apps don't honour the desktop settings very well there are quite a few ways around that these days. With Oxygen-GTK, GTK apps follow 90% of the relevant settings in KDE and I'd much rather see work in finishing the last 10% (like using native file dialogs etc) than separating the two further... I would even propose to use the upcoming oxygen-gtk 2.0 as default style in GNOME to ensure a consistent look if one uses KDE apps in it. Oxygen- gtk 2.0 will have native (gtk) configuration etc so that would be a nice step forward for the integration. Next up would be using native file dialogs in each desktop, I suppose. Of course, when a Gnome or KDE dev develops a KDE/Qt style which fits in with the default GNOME 3 theme, we could go the other way. Or patch Qt to pick the GNOME style when running in GNOME and GTK to pick oxygen-gtk when running in KDE. Actually, the first thing is supposed to work but doesn't for me.

Btw., afaik the Ubuntu Software Center installs dependencies without even informing the user about them. Which makes a lot of sense. Unless you have a 8GB SSD, the 40-odd mb KDE or GNOME libraries would add to a system are pretty darn irrelevant.

Anyway. The artificial split between KDE/Qt and GNOME/GTK is an annoyance which probably won't go away because many ppl still have an irrational hate for one of the other, which is why Ubuntu (of all distro's) has already surpassed the "We proudly ship both" distro (us) by having Qt in the default installation despite being oh so GTK based and having a crappy KDE version. Should've been us... Instead, we re-create GTK or Qt tools/apps in the other toolkit because 'it offers better integration' and 'saves 40 mb of room for the libs from the other side'. We should follow mandriva and ship the 'best of both worlds' on our liveCD's. Both CD's should have Krita, digiKam, the Gimp, Cheese, etc. Just the best in their respective fields... That way we re-inforce the good apps & don't encourage silly rewrites of apps from 'the other camp'. /me dreams on Sorry for the sudden rant... I know it won't happen.

On 30 June 2011 09:24, jdd <jdd@dodin.org> wrote:

Le 30/06/2011 08:14, Rob OpenSuSE a écrit :

...

Wouldn't simple "tags" be better than RPM groups?

isn't that what Pattern are used for? kde pattern, gnome pattern...

I think Patterns select a group of packages that tend to be used together, like KDE4 Desktop, or LAMP server; which is a very different purpose. What I thought the OP is wanting is labelling of applications, so someone can browse in other ways than RPM group. Having gone through the whole rpm list a fair amount this last week (in SuSE Studio & Software Manager), frankly it does not seem "optimal" as is at present. I actually discovered today I have this installed on an old LXDE laptop, but have never ran it. For instance I found "Beaver" in SuSE Studio has this description : Repository: openSUSE 11.4 OSS Version: 0.4.1-4.4 Groups: System GUI GNOME Size: 537 KB License: GPLv2 Beaver starts up fast and doesn't use a lot of memory. Beaver's only dependency is GTK+2, so no need to install other libraries eating your disk space. These things make Beaver very suitable for old computers and use in small Linux distributions. That left me wondering what it actually did without the YaST summary :) beaver - Beaver is an Early AdVanced EditoR But that actually shows even if you do not care whether something is "GNOME" or "GUI" but was just looking for "Editors" then Productivity->Text->Edfitors does not include the application. It was installed as part of the LXDE pattern AFAIK of OS-11.3. Beaver Tags : Application, GTK+2, X, Text, Lean, Editor Which could allow a useful package browser to be created that allows discovering what applications might suit a box. Then may be initial installs could slim down a bit, rather than tending to begin with a complete Desktop Environment suite fully installed; much of it which then needs immediate upgrade (from Packman or other repos). Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 30 June 2011 12:30, jdd <jdd@dodin.org> wrote:

Le 30/06/2011 12:25, Rob OpenSuSE a écrit :

...

On 30 June 2011 09:24, jdd<jdd@dodin.org>  wrote:

...

...

isn't that what Pattern are used for? kde pattern, gnome pattern...

I think Patterns select a group of packages that tend to be used together, like KDE4 Desktop, or LAMP server; which is a very different purpose.

you can create any kind of pattern (AFAIk), and there are default selected package in pattern and also non default selected ones.

That's interesting, patterns would seem basically lists of packages then, that are in effect "tagging". There's Package groups to, which seem smilar only without the "Intall" options. However the Software Manager only has a very limited browsing & selection on patterns at present, there's no simple way either for the end user to add their own tags to reuse later.

the problem of your system tags is that this needs to be manually tagged. or is it possible in OBS to ask maintainers to clik in a tag list?

Very definitely but as I understood it, this was an ideas and requirements discussion, for something that would need development, perhaps I misunderstood. I really hate a restricted hierarchy for organisation, for problems mentioned. Altering package names would be impractical; and once we consider additional repos likely to be unworkeable. Nevermind that using the name to signal attributes, will limit the info's presentation eg) fixed alphabetic sort order of name, rather than Function, Implementation Technology, Philosophy Features v Compactness which become doable in a more general framework. Browsers offer "Tags" for Book Marks & web applications like Gmail have "Labels", so it seems like a fairly common DataBase type application, with extensions needed to browse & generate queries in the Software Catalogue. There must be code around already, that perhaps could be recycled and integrated? Perhaps the community could help create the information, outside of the package build system; rather than all of the categorisations being another task for package maintainer's to complete. On 28 June 2011 14:14, Ilya Chernykh <anixxsus@gmail.com> wrote:

I first discussed this issue with coolo in private but possible a wider range of ideas may be beneficial.

All of us know that is is sometimes confusing to find a package which belongs to your desktop environment, whether Gnome or KDE. Sometimes you have to look into package's dependencies to find out whether it is written in GTK or Qt.

As the number of desktops increases, the problem only becomes worser.

Currently the packages are classifies using the RPM groups. But for the most packages this groupping only reflects the package's purpose, i.e. network, game or office. This groupping is organized as a tree, and there is no possibility to add another categorization.

An obvious solution is to add a desktop environment name to the package's name such as prefixing all KDE apps with "kde-" or simple "k". But this is also confusing and may require much of work as renaming is not an easy task.

So are there any ideas on how to organize this better?

Well I really think package renaming, won't solve the problem for end users, who want to select a package based on rational criteria, to find what suits them. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 30 June 2011 12:24:32 jdd wrote:

...

Wouldn't simple "tags" be better than RPM groups?

isn't that what Pattern are used for? kde pattern, gnome pattern...

Pattern is like a metapackage: a set of packages, installed by default with a given DE. It does not include additional or optional packages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

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? 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. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

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