On Sunday, April 27, 2014 05:25:24 PM Bruno Friedmann wrote:

On Sunday 27 April 2014 09.40:15 Rick Chung wrote:

...

...

What is good: the network-management and the functionality of it are finally usable, nice and easy even for non Linux users. The choices of being able to show or unshow Mac address etc. and other features are IMO useful. VPN presence and connection status are now shown throughout all personalities which is safe. Thank you for that.

The convenient Default Gateway info is now missing.

You can change what informations you want by using a right click on the plasmoid network management settings

I'm confident in the fact you will find all what you're looking for.

Bruno, Woah! That's AWESOME!!! Thank you for leading me that way. It provides plenty information we could customize on Networks. Regard, Rick Chung -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Dne Po 28. dubna 2014 07:01:47, Anton Aylward napsal(a):

On 04/28/2014 03:53 AM, Raymond Wooninck wrote:

...

On Sunday 27 April 2014 07:51:27 stakanov@freenet.de wrote: [...] Having just lost all my knotes, which I use quite a lot, and having no way to import then back from my archives, and having a new and undocumented config which, it appears, still doesn't let me override the export format!!!, I am pretty annoyed.

The lost data, is what really annoys me. New features are meaningless in the face of lost data.

This phase of upgrade seems to be displaying what I think of as a 'over-maturity' on the part of the KDE team, gratuitous featureism.

The shift with baloo from "index only what I say" to "index everything except what I say" seems nasty minded and out of touch with users.

Breaking some thing as essential as kmail is another example.

But though all this is the obsession with indexing. The code for this is hard coded into so many components. I think that is very wrong-minded and backward.

I'm not OCD but I don't need this search; I organise my files sensibly, isn't that what a hierarchical file system and long names is for? Have these guys never heard of the term 'taxonomy'?

part of the attraction of the old knotes was that I could arrange my notes in a heairarchy. Have we now lost that? The help fcility is more useless than normal and seems to think that we deal in just one note at a time. More 'out of touch with users'.

Yes I know how to disable indexing. My point is that I don't want the code; it adds complexity and hence the potential for flaws to many situations where its not needed.

If you are going to make use of it then at least make it a plugin.

Fixing the problem of knotes incompatibility and getting my lost data back is all well and good, but why the **** did you produce code that cause it to be lost?

Regular readers will know that I've supported KDE4 though its infancy when many others decried it, and was great to have it mature, but now, well there are terms like "jumped the shark" or "nuked the refrigerator" which apply.

I completely agree. I like KDE, but it has strange custom to break things on upgrade (often related to PIM, which is... ehm... making users very angry) and to release important software too early before they are ready. Why? Why, oh why? I also have to say, that several at least 4 upgrades of KDE and openSUSE were perfectly smooth, so that I didn't expect big issues with this one... All the best, Vojtěch -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/

Luca, I think Anton means that he want to uninstall Baloo compeltely from his system, just like I do. He doesn't want any Baloo code on his machine. If you're not subscribed to the openSUSE user support list, I just sent the email I've copied below. Keep in mind how many people may be having issues with Baloo and aren't saying anything. Either they don't know they're having problems with it when they are, or they are and they aren't taking the time to report it. Not everybody is a computer scientist, but this new "feature" should not be forced down everybody's throat just because the KDE team thinks that this is way people should be using their computers. In prior version of KDE, Nepomuk's indexing feature was disabled by default, so I never used it. Just for testing purposes, I once tried switching indexing on through the Nepomuk GUI and a process or two started, yet my hard drive didn't seem to be doing anything. Either Nepomuk was broken, or it was unobtrusively indexing my files and didn't hog system resources. It's hard for me to compare Baloo to Nepomuk when, from my impression, Nepomuk wasn't doing anything even when the indexing feature was turned on. Baloo is a whole different story, and I had to turn it off because it was giving me performance problems. I didn't like that by default it's switched on, so the second you log into KDE it starts indexing. I hadn't kept up with any of the changes that were coming with KDE 4.13, and trusted that it would be an improvement over 4.11.4. Therefore, when I was having all types of performance issues related to disk I/O and CPU utilization, it took me time to track down how to finagle with Baloo and stop it. I was surprised that the GUI offers barely any options, and that it's opt-out and not opt-in. I looked around the internet some, and I found a funny post on the Kubuntu forum: "After a few days baloo settled down on my system but on my wife's laptop baloo kept going and going for days making it really difficult to do anything. I found a message that ~/.kde/share/config/ baloofilerc has a line in it under [Basic Settings] Indexing-Enabled=true I changed that to Indexing-Enabled=false and the laptop was useable again, but lost a few search items. It's nice when it works but hell when it hogs the system." I love the beginning where he says: "After a few days", and keep in mind that the 2.5" hard drive on his wife's laptop isn't exactly an icon for longevity. I can only imagine the wear and tear the first iteration of Baloo is doing to SSD's. Baloo shouldn't start automatically the first time a user logs into KDE, but I hate when OS's ask you questions through a dialogue box when you just want to get stuff done. I don't have an answer to how this should be done correctly, but I want to reaffirm that Baloo should _not_ start indexing anything without the user's permission. They're already talking about allowing it to be uninstalled by having the Baloo package be split. I want this, because I want to uninstall it. And if my supposition is correct, I don't think I'll ever be installing it again -- not that I don't think it can become better. I just don't need it. On Mon, Apr 28, 2014 at 4:48 AM, Luca Beltrame wrote:

In data lunedì 28 aprile 2014 07:01:47, Anton Aylward ha scritto:

...

Yes I know how to disable indexing. My point is that I don't want the code; it adds complexity and hence the potential for flaws to many

Sorry, but this argument doesn't make sense. This is Free Software. How are you going to prevent people from writing code?

There are a lot of things one can do to improve FOSS, including even harsh criticism. But saying "I don't want the code" isn't, sorry.

-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

There is no "KDE team". Unless you're referring to the openSUSE KDE team here, and in this case you're doing a great disservice to the (*volounteers*, every one of them) who package the software *you* are using.

As far as there being a KDE team, this is right off the KDE website: "The KDE® Community is an international technology team" You are extremely out of touch with reality. I'm not doing a disservice; I'm doing a service. It's people like me that make FOSS better by reporting problems. I guess if you had it your way, you would have everybody be sheep and report how excellent everything is working and praise all the new bells and whistles which in actually are garbage.

This is FOSS, not a professional organization.

Thanks for the lecture.

If Baloo was that toxic to everyone's computer, why people did not test it in advance? I can understand that not everyone is supposed to test beta software, but the fact that *zero* people, or close to zero did it tells me something about how much the FOSS community knows about being good citizens.

That's not my problem. I, like many other people, have other things going on in my life and throughout my day. I wasn't aware that KDE 4.13 was going to have a shitty new indexing system that completely sucked, and is causing all types of people to get mad, not to mention that it's sucking their system resources dry. Maybe if I would have known about it I would have tested it, but the KDE website is poorly organized and it's hard to find anything on it. Is this the global push for worldwide Linux adoption on the desktop? It's not working very well.

It really makes me bitter to think that all that it was tried to do to ensure that reports could be caught in time to ensure a better user experience was all for *nothing*, and only later the complaints (and nothing else, almost) arrived. It makes me wonder at times why do I *bother* to give support on the KDE Community Forums.

Here's a word of advice: If you can't handle critisism (you obviously are an overly sensitive person), then it would probably wise to take a hike. When there's problems, i report them, and I report my experiences. And guess what -- I'm not changing, nor am I going to change the way that I communicate.

You could have spared a rant: there is a clear mention of the "baloo-file" message in the announcement we made regarding 4.13 availability in KDE:Current.

Again, you are out of touch with what the problem is, what the users are saying, and this just shows exactly why Baloo is there in the first place. Have a nice day. On Mon, Apr 28, 2014 at 5:36 AM, Luca Beltrame wrote:

In data lunedì 28 aprile 2014 05:22:25, Sam M ha scritto:

Hello,

...

I think Anton means that he want to uninstall Baloo compeltely from his system, just like I do. He doesn't want any Baloo code on his

If you remove baloo-file, it won't touch your hard disk at all.

...

everybody's throat just because the KDE team thinks that this is way people should be using their computers.

There is no "KDE team". Unless you're referring to the openSUSE KDE team here, and in this case you're doing a great disservice to the (*volounteers*, every one of them) who package the software *you* are using.

And even in the KDE community at large, of which I am part of, there is no such team. This is FOSS, not a professional organization.

If Baloo was that toxic to everyone's computer, why people did not test it in advance? I can understand that not everyone is supposed to test beta software, but the fact that *zero* people, or close to zero did it tells me something about how much the FOSS community knows about being good citizens.

Since the new search system was introduced, in the first beta, I wrote to the mailing list asking the brave to test it to ensure we had a smooth experience later on. Aside the openSUSE KDE team and a few others, no one did. How can you fix something that you do *not* know it's broken?

It really makes me bitter to think that all that it was tried to do to ensure that reports could be caught in time to ensure a better user experience was all for *nothing*, and only later the complaints (and nothing else, almost) arrived. It makes me wonder at times why do I *bother* to give support on the KDE Community Forums.

...

was surprised that the GUI offers barely any options, and that it's opt-out and not opt-in.

Again, this GUI change was in since beta 1.

...

package be split. I want this, because I want to uninstall it. And if

You could have spared a rant: there is a clear mention of the "baloo-file" message in the announcement we made regarding 4.13 availability in KDE:Current.

-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Monday 28 April 2014 05:52:13 Sam M wrote:

...

There is no "KDE team". Unless you're referring to the openSUSE KDE team here, and in this case you're doing a great disservice to the (*volounteers*, every one of them) who package the software *you* are using.

As far as there being a KDE team, this is right off the KDE website: "The KDE® Community is an international technology team"

You are extremely out of touch with reality. I'm not doing a disservice; I'm doing a service. It's people like me that make FOSS better by reporting problems. I guess if you had it your way, you would have everybody be sheep and report how excellent everything is working and praise all the new bells and whistles which in actually are garbage.

You didn't report these problems in the RC, so - you're too late. You're complaining when it is already released. So, yeah, little thanks from us as you didn't bother to help test. That is fine, but then don't complain loudly that it breaks. File a bug and accept that because YOU didn't test, we didn't catch this issue.

...

This is FOSS, not a professional organization.

Thanks for the lecture.

...

If Baloo was that toxic to everyone's computer, why people did not test it in advance? I can understand that not everyone is supposed to test beta software, but the fact that *zero* people, or close to zero did it tells me something about how much the FOSS community knows about being good citizens. That's not my problem. I, like many other people, have other things going on in my life and throughout my day. I wasn't aware that KDE 4.13 was going to have a shitty new indexing system that completely sucked, and is causing all types of people to get mad, not to mention that it's sucking their system resources dry. Maybe if I would have known about it I would have tested it, but the KDE website is poorly organized and it's hard to find anything on it. Is this the global push for worldwide Linux adoption on the desktop? It's not working very well.

...

It really makes me bitter to think that all that it was tried to do to ensure that reports could be caught in time to ensure a better user experience was all for *nothing*, and only later the complaints (and nothing else, almost) arrived. It makes me wonder at times why do I *bother* to give support on the KDE Community Forums.

Here's a word of advice: If you can't handle critisism (you obviously are an overly sensitive person), then it would probably wise to take a hike. When there's problems, i report them, and I report my experiences. And guess what -- I'm not changing, nor am I going to change the way that I communicate.

...

You could have spared a rant: there is a clear mention of the "baloo-file" message in the announcement we made regarding 4.13 availability in KDE:Current.

Again, you are out of touch with what the problem is, what the users are saying, and this just shows exactly why Baloo is there in the first place. Have a nice day.

On Mon, Apr 28, 2014 at 5:36 AM, Luca Beltrame wrote:

...

In data lunedì 28 aprile 2014 05:22:25, Sam M ha scritto:

Hello,

...

I think Anton means that he want to uninstall Baloo compeltely from his system, just like I do. He doesn't want any Baloo code on his

If you remove baloo-file, it won't touch your hard disk at all.

...

everybody's throat just because the KDE team thinks that this is way people should be using their computers.

There is no "KDE team". Unless you're referring to the openSUSE KDE team here, and in this case you're doing a great disservice to the (*volounteers*, every one of them) who package the software *you* are using.

And even in the KDE community at large, of which I am part of, there is no such team. This is FOSS, not a professional organization.

If Baloo was that toxic to everyone's computer, why people did not test it in advance? I can understand that not everyone is supposed to test beta software, but the fact that *zero* people, or close to zero did it tells me something about how much the FOSS community knows about being good citizens.

Since the new search system was introduced, in the first beta, I wrote to the mailing list asking the brave to test it to ensure we had a smooth experience later on. Aside the openSUSE KDE team and a few others, no one did. How can you fix something that you do *not* know it's broken?

It really makes me bitter to think that all that it was tried to do to ensure that reports could be caught in time to ensure a better user experience was all for *nothing*, and only later the complaints (and nothing else, almost) arrived. It makes me wonder at times why do I *bother* to give support on the KDE Community Forums.

...

was surprised that the GUI offers barely any options, and that it's opt-out and not opt-in.

Again, this GUI change was in since beta 1.

...

package be split. I want this, because I want to uninstall it. And if

You could have spared a rant: there is a clear mention of the "baloo-file" message in the announcement we made regarding 4.13 availability in KDE:Current.

-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 08:36 AM, Luca Beltrame wrote:

...

How can you fix something that you do *not* know it's broken?

The impression I get is one of "Broken By Design". There was a fundamental design change, that from "only index what I tell you" to "index everything except what you tell not to". I now get the impression that this results from us having to trust the developers who "know better" what we want. I don't recall being asked.

Theres there 'Broken by design" which has lost me all my knotes. No, that is called a bug, and it was not found because while people on this

On Monday 28 April 2014 09:03:50 Anton Aylward wrote: list have no problem spending hours complaining that others did not test the functionality they use, they do NOT want to bother testing themselves. Well, if you don't want to test, than you can file a bug, but don't complain. This is a meritocracy: you have as much right to complain as you put in work. You don't put in work? Then don't complain. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Mon, Apr 28, 2014 at 2:36 PM, Luca Beltrame wrote:

If Baloo was that toxic to everyone's computer, why people did not test it in advance? I can understand that not everyone is supposed to test beta software,

I test things with KDE on an isolated test machine.... when I can. I don't test every release. The 4.12.99 release did land on my test machine for a day or two, but... I never noticed Baloo. I had not realized that the former search... Nepomuk... was being 100% replaced now that it was... you know, working OK. The info about Baloo may have been posted on the ML, but it's clear most of us missed it. Lots of excuses... persona life, too many emails etc etc.

Since the new search system was introduced, in the first beta, I wrote to the mailing list asking the brave to test it to ensure we had a smooth experience later on. Aside the openSUSE KDE team and a few others, no one did. How can you fix something that you do *not* know it's broken?

Why was Nepomuk removed? Was was Baloo invented? I still haven't quite figured this one out. If I test something, I test it on an isolated system on my LAN. It doesn't touch my NAS. It doesn't touch my internal data storage on my main machine. So... any indexing Baloo did was on an empty home, with no additional external drive mounts. Basically.. nothing to index. That said... when Baloo was enabled on my primary system, it indexed a 2TB NAS, a 1 TB mechanical and a 250GB SSD in just a few minutes. That's photos, videos, documents, VM images etc etc. The only I/O hit I had was to the NAS, but that's not unreasonable given the network speed and the hopelessly slow NAS I've got. Hardware is an AMD Quad core (965), 16GB RAM on a Gigabye MB. On my particular setup, there was next to zero I/O impact. Why would that be the case on one install, but the next just falls over flat?

It really makes me bitter to think that all that it was tried to do to ensure that reports could be caught in time to ensure a better user experience was all for *nothing*, and only later the complaints (and nothing else, almost) arrived.

On that point... one.. just one single addition to Baloo would have alleviated 99% of the kerfuffle (or.. is it hullabaloo?). A simple on/off toggle that set the true/false option in the baloorc file would have been all that was necessary here. The people who don't want indexing could have simply went click and it would have not been an issue. Or better yet... make it an opt-in with a first start popup that says hey, cool new feature can be enabled here. C. -- openSUSE 13.1 x86_64, KDE 4.13 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 08:22 AM, Sam M wrote:

Luca,

I think Anton means that he want to uninstall Baloo compeltely from his system, just like I do. He doesn't want any Baloo code on his machine.

That's about it. Removing baloo-file doesn't remove baloo-core baloo-kioslaves baloo-tools and more The real problem is that the specific search engine is HARD CODED into various other applications and I have no choice about it. Compare this with, for example, the option I have in systemsettings -> Default applications. * I can choose to use Kmail or I can specify some other mailer * I can choose the file manager I want from among the KDE options OR chose something else, from Gnome for example * I can chose which application to use for an IM * I can choose what to use as a terminal emulator * I can chose what web browser to use * I can chose what windows manager to use But I can't chose what indexer to use. Perhaps I think the one from Gnome is more to my linking. I'm stuck, Perhaps I want to experiment and write my own. Rather than have it selected in systemsettings and applied to all the components I'm going to have to recode all the components to make use of my experimental version. Its not that I don't want Baloo, it's that I don't want Baloo HARD CODED. Please understand the difference. -- "Terrorism isn't about what you can do to a group of people; it's about what you can make a group of people do to themselves." -- Larry Niven, "Draco Tavern" -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Monday 28 April 2014 09:21:45 Anton Aylward wrote:

That's about it. Removing baloo-file doesn't remove

baloo-core

This package provides the main baloo libraries. There are no executables in there nor are does it do any harm if it remains.

baloo-kioslaves This one you can remove as that it only provides the kio slaves for baloosearch, tagging and the dolphin timeline stuff. Without this package it is no longer possible to rate or create tags for any file. It does not index anything, however this provides the interface to the extended attributes. baloo-tools This is just the tools and the krunner for searching with baloo and can be easily removed.

and more

But it stops completely the file indexing from happening. The same goes for removing baloo-pim which removed the baloo akonadi agent and will stop the indexing of emails.

The real problem is that the specific search engine is HARD CODED into various other applications and I have no choice about it.

Then I am afraid that you have to write your own desktop system to make sure that it only uses what you want it to. There are a lot more libraries, etc installed on each system that are required by the desktop environment of our choice. Maybe I want to remove Qt, because I don't need it. But Qt is HARD CODED in KDE without any choice. And there are a lot more of these HARD CODED dependencies.

* I can choose to use Kmail or I can specify some other mailer * I can choose the file manager I want from among the KDE options OR chose something else, from Gnome for example * I can chose which application to use for an IM * I can choose what to use as a terminal emulator * I can chose what web browser to use * I can chose what windows manager to use

But will these choices also remove EVERYTHING that is related to the thing that you do not want to have ? As you indicated you can choose which web browser to use. You can choose to not use Konqueror and use FireFox, Rekonq, Chrome, Chromium, etc. But you can't delete libkonq (which is part of konqueror) as part of KDE have a HARD CODED dependency on this library.

But I can't chose what indexer to use.

Yes you can. Removing baloo-file and baloo-pim will remove the active indexing programs and baloo will stop to work. Nothing will be indexed, nor any activity will be done with baloo. Exactly the same way as that you can remove konqueror, but you can't remove libkonq.

Perhaps I think the one from Gnome is more to my linking. I'm stuck,

You are not stuck. As indicated you can completely disable baloo by removing 4 packages and baloo will no longer bother you. If you want to go further than this, then I guess you have to start building KDE by yourself from the source code so that you can omit whatever you do not want to have. We are building here packages that are used by a lot of people with all different requirements. This would mean that we have additional library requirements that are pulled in during the build phase of KDE. This delivers a KDE environment with a big amount of functionality that can be utilised depending on additional packages that are being installed by the user. But particular libraries are being pulled in regardless of the choice of the user. However the libraries on itself do not perform any activity. It is just there waiting for a program that activates it. And this is exactly the same state that you can achieve by removing the 4 indicated baloo packages.

Please understand the difference.

Well, I hope that you understand that there is a difference between HARD CODED and HARD CODED. As stated above KDE pulls in a lot of libraries to satisfy HARD CODED functionality. However this functionality is not activated until other programs are being installed that can utilise that functionality. And this is not different from Baloo. This does not mean that I do not agree with you regarding the enable/disable functionality in systemsettings and if you really followed the discussions then you know that there are a lot more people that think that way. However we can not always have it our way unless we decide to act and contribute this functionality. Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 09:50 AM, Raymond Wooninck wrote:

On Monday 28 April 2014 09:21:45 Anton Aylward wrote:

...

The real problem is that the specific search engine is HARD CODED into various other applications and I have no choice about it.

Then I am afraid that you have to write your own desktop system to make sure that it only uses what you want it to.

Now you seem to be trying to make this into a personal issue rather than addressing technical merits and shortcoming and design preferences.

There are a lot more libraries, etc installed on each system that are required by the desktop environment of our choice. Maybe I want to remove Qt, because I don't need it. But Qt is HARD CODED in KDE without any choice. And there are a lot more of these HARD CODED dependencies.

As I said, you are being ridiculous. Its not an analogous situation as you well know. I do on to give some examples of how systemsettings makes it clear that some utilities KDE uses which are external programs are optional, we can chose, for example, to use Evolution or Thunderbird instead of Kmail. I try to bring to the attention of readers that these things are not HARD CODED into KDE. Neither are they UI infrastructure libraries like Qt.

...

But I can't chose what indexer to use.

Yes you can. Removing baloo-file and baloo-pim will remove the active indexing programs and baloo will stop to work. Nothing will be indexed, nor any activity will be done with baloo. Exactly the same way as that you can remove konqueror, but you can't remove libkonq.

No, its not analagous. Systemsettings lets me chose which file manager I want. If I want to use Thunar I can. Its not about what I have to delete in order to disable. And I can use so other external program. While I can fiddle with the rc file to disable baloo (as opposed to disabling it in systemsettings) I can, for example, write a nifty one in Perl and use the options in systemsetting to use that external program instead (or the one offered by Gnome whatever that is). I can't tell kmail to use the indexing available via Dovecot or some other external program. Its HARD CODED and its all or nothing. I can't tell dolphin/konqueror to use one indexer and kmail another, no matter how good the indexer in Dovecot is, not matter how well integrated that indexer is with the mail store and how much better suited it is that that very specific task than a general purpose file indexer. In fact its running on a remote machine, my mail hub, so the "desktop indexer" can't see the files... All this is just an example of how determining options at run time rather than compile time gives more flexibility.

...

Perhaps I think the one from Gnome is more to my linking. I'm stuck,

You are not stuck. As indicated you can completely disable baloo by removing 4 packages and baloo will no longer bother you. If you want to go further than this, then I guess you have to start building KDE by yourself from the source code so that you can omit whatever you do not want to have.

You are so missing the point. In fact you are missing very many points. There are dozens of editors I can select as my editor of choice using systemsettings. Similarly there are many other external program options I can select there since they are not hard coded into KDE. But when it comes to indexing you are telling me I can either use baloo or nothing. Superficially baloo is an external program (otherwise one couldn't remove it) but the reality is the interface to it is hard coded into KDE applications.

We are building here packages that are used by a lot of people with all different requirements. This would mean that we have additional library requirements that are pulled in during the build phase of KDE. This delivers a KDE environment with a big amount of functionality that can be utilised depending on additional packages that are being installed by the user.

Obviously not. Read the above. What I describe, what is previously in KDE to address editor, mailer, file manager and others is determined at run time according to the settings in systemsettings and make use of additional packages. This is not the case with the indexer. It is baloo or nothing.

...

Please understand the difference.

Well, I hope that you understand that there is a difference between HARD CODED and HARD CODED. As stated above KDE pulls in a lot of libraries to satisfy HARD CODED functionality. However this functionality is not activated until other programs are being installed that can utilise that functionality. And this is not different from Baloo.

Not so. The interface that invokes, for example, the web browser, can invoke any web browser: Konqueror, firefox, opera, Chrome ... The interface that invokes baloo invokes baloo, if it find it. It can't invoke anything else. Its not a configuration option. There is an analogy here with networking. We use symbolic names and DNS to map those names to whatever IP address is registered. We don't hard code IP addresses into programmes. What you've done is hard coded the address and what you are saying is that we can chose not to have the site present. This is not consistent with the way other parts of KDE work. -- The state can't give you free speech, and the state can't take it away. You're born with it, like your eyes, like your ears. Freedom is something you assume, then you wait for someone to try to take it away. The degree to which you resist is the degree to which you are free... --Utah Phillips -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 11:56 AM, šumski wrote:

On Monday 28 of April 2014 10:37:44 Anton Aylward wrote: ...

...

...

All this is just an example of how determining options at run time rather than compile time gives more flexibility. Indeed. And also creates a maintenance nightmare.

If it does then there is something very wrong with the coding. The wrappers around what amounts to a "system" (3) call are all well documented. In addition, the code already exists in KDE to do that with those other external programs I mentioned. Are you saying that the KDE coders are so inept that they had to code each of those instances separately? That they never factored the code to a common routine? -- Everything comes to him who hustles while he waits. Thomas A. Edison -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 12:45 PM, šumski wrote:

On Monday 28 of April 2014 12:32:50 Anton Aylward wrote:

...

The wrappers around what amounts to a "system" (3) call are all well documented. In addition, the code already exists in KDE to do that with those other external programs I mentioned.

Are you saying that the KDE coders are so inept that they had to code each of those instances separately? That they never factored the code to a common routine?

Sorry, i fail to grasp what you said above has anything to do with library choices. What instances?

You seem terribly hung up on libraries, as if that's the only way to implement anything. I'm sure most people following this have by now looked at systemsettings -> Default Applications and seen that it is possible in other contexts to chose what external program to use. They see that these choices are made at run time and not at compile time, and that they are under the selection of the user, not hard coded by the developers.

Also, you can use whatever browser you like, but only with those that use KDELibs,

Pardon me. I use firefox as my browser. Or do you mean file manager? Once again the systemsetting interface lets me select something other than Konqueror or Gwenview. You seem terribly hung up on libraries as the only way and in doing so are missing the point. All those other options, email, file manager, browser, terminal emulator, let me chose any one I want, regardless of what libraries KDE may have hardwired in or what external libraries those external programs may require. If I want to download an experimental one or write one of my own )perhaps in Perl or Ruby), I can. As for the windowing side, that's an option too; there are some interesting things with the E17 world :-) -- Call 226682779489712859637199678587902423107 for a good prime! -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 11:56 AM, šumski wrote:

Since you're already pulling the GNOME comparison, situation is not different there. You'll either use Tracker, or nothing. And is not different how it was <= 4.12 and Nepomuk.

You are missing the point I'm making. While what you say is true, it presumes I'm using the Gnome Desktop Environment. I don't need to do that to use a program from the Gnome side of the world. Example: I can use Gimp, which is gnomish rather than kdeish. I can use OpenOffice rather than Calligra And I can use those while running the KDE rather than that Gnome. As I've said before, many of these options are selectable in systemsettings -> Default Applications. Elsewhere we have the MIME settings, configuration of programs to run as part of loing and logout and more. In fact so much of the rest of KDE (and Linux in general) is about the setting of run-time options that decouple away from compile-in choices. -- Five exclamation marks, the sure sign of an insane mind. -- Terry Pratchett _Reaper Man_ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 01:01 PM, šumski wrote:

...

As I've said before, many of these options are selectable in systemsettings -> Default Applications. Yes. Many, not every single one.

There are many other indexing applications out there and there are the Perl and Ruby tookits that are built around things like Plucine. Making the indexing tool one of them should be an option.

...

In fact so much of the rest of KDE (and Linux in general) is about the setting of run-time options that decouple away from compile-in choices.

Well yes, and i am again repeating the same sentence: you can remove baloo-file and be done with it. Or disable it via config key/placing $HOME as blacklisted location. As with 4.13, and in the past, and also with other DE's, wrt metadata/searching, there is one or none. I am sure KDE devs would welcome suggestions, and especially code how to do it differently.

What you are saying is that "if it isn't there it can't run" Big deal. All or nothing. The other stuff John has discussed, the change that now needs positive intervention by the user to disable whereas before disabled was the default. I doubt very much that the developers are incapable or need an old Perl/Ruby hack like me to point them to code fragments that already exist in the KDE suite. As I keep saying, there are already examples in systemsettings and already exmples of how to invoke an external application that has been set in systemsettings. -- When languishing for solutions, don't ask "Have I got the correct answer?" The correct question is "Have I got the correct question?" -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 06:17 AM, Jos Poortvliet wrote:

Go, code it. Stop telling others what to do without doing anything other than complain or even bother to find out the reasons behind the new search.

Ah, yes, all my years of supporting KDE from 4.0 count for naught when I make one criticism .... All this defence emoting on the part a few seems to miss out on a simple fact: we like KDE and we are disappointed when there's a FAIL. That's DISAPPOINTED. Disappointment isn't a reason for abandonment. KDE as a whole has many excellent and superior qualities. Quite honestly I'm sick of the 'coder elite' attitude. There's more to producing a good system than the code. Saying "if you don't like it [this one small part of the while] then go elsewhere, code your own Dm ... " is insulting. Scale this out and you'll expect each of us to build out own houses, cars, kitchen appliances, cell phones, computer chips ... Simply because we don't like some aspect of what has been produced. Its simply not scalable. -- Without friends no one would choose to live, though he had all other goods. -- Aristotle (384 BC - 322 BC), Nichomachean Ethics -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 09:28 AM, Luca Beltrame wrote:

In data giovedì 01 maggio 2014 08:03:51, Anton Aylward ha scritto:

...

Quite honestly I'm sick of the 'coder elite' attitude. There's more to producing a good system than the code.

In this case however, it is not required to code. However, it was required to *report* issues on the bug tracker. That's a fairly lower level of entry, isn't it?

The nature of the bug report system is for addressing coding bugs, not the kind of matters I've been addressing here. -- The art of progress is to preserve order amid change and to preserve change amid order. --Alfred North Whitehead -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

I meant to write "isn't" a very good argument. On Thu, May 1, 2014 at 7:20 AM, Sam M wrote:

I think Baloo should be able to be removed entirely. If I wanted a system where things couldn't be removed I'd be running Windows. I have my opinions which I've already expressed, and I'm not going to invest a whole lot of time reiterating myself and writing numerous emails. If the KDE developers want Baloo to not be able to be removed, then so be it. But I don't think that telling somebody to code their own desktop is a very good argument. It definitely _is_ a bit of an argument, but when you don't understand somebody's use case and you can't 100% put yourself in their brain and thinking patterns, AND understand what is and isn't important to them, then it's 100% impossible to fully understand the differentiation between something that may be important to somebody else and something that is only a run-of-the-mill topic which carries little importance to you. The whole idea is to make the system adaptable, and since Linux and other Unix-like systems are frequently used by people who have more knowledge on average about computers and how computers work, foisted "features" aren't always going to be popular. Is the Linux system going to become one big web of libraries that are all tied together, and nothing can be removed? Is the suggestion going to be to compile everything from source for those people who want minimalism, are purests, and that want free choice?

As far as not testing, I had been using Windows more than Linux up until recently. Plus, I like XFCE in some regards, and it's not like KDE is the be-all and end-all in desktop environments. However, it's definitely a great system. Please at least offer a GUI switch for users to easily turn indexing off. How about a system notification that slides up and gives the user an option to begin indexing, postpone it, opt-out, or let them know what the hell is going on? I want to see KDE get more modular, more customizable, less bloated, etc. Not a one size fits all methodology, where the developers decide that it's either black or white, and if they choose white, then white is _the_ color, and that's the end of the discussion. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Thu, 1 May 2014 19:14:34 Jos Poortvliet wrote:

[...] You HAVE free choice. Unlike on windows you can compile all the KDE software yourself and not include baloo. And you can adjust the code to take it out.

Here we go again with the attitude. Not everyone who uses KDE and who doesn't want desktop search is a programmer. Some of us choose to use Linux/KDE precisely because it ISN'T Windows. If I wanted Windows, I'd USE Windows.

There isn't a single reasonable reason to not have baloo installed so there

You mean, "I can think of no reason that seems reasonable to me..."; there are PLENTY of reasons which are completely reasonable to those who hold those opinions. For example, if I was running KDE on a Raspberry Pi (which is not a ridiculous use case and it is - or was - entirely possible) then I definitely would NOT want Baloo installed simply because of the limitations of the platform (e.g. running off an SD card) and the need for a minimal but functional installation. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data venerdì 02 maggio 2014 03:19:21, Rodney Baker ha scritto:

Here we go again with the attitude. Not everyone who uses KDE and who doesn't want desktop search is a programmer. Some of us choose to use

Most of the people in the openSUSE Community KDE teams aren't programmers, FYI. While I know how to code, I certainly can't call myself one. ;) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 04/28/2014 11:56 AM, šumski wrote:

You'll find also that for dealing with SVG plasma theme's, you can't escape QtSvg. For using KMail, you cannot not use akonadi. With using KWin, you'll need to have libGL library installed. etc. So, i do not see a difference, except that ranting is pointed towards baloo, which as mentioned, you can just remove, and be done with it.

There is a bit difference between an external program that does the work and an intrinsic UI library. Even so, the idea of run-time binding rather than compile time binding is what makes Thundebird and Firefox so powerful. -- Only one absolute certainty is possible to man, namely that at any given moment the feeling which he has exists. Thomas H. Huxley -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Monday 28 April 2014 19:58:27 Daniele wrote:

Il 28/04/2014 17:56, šumski ha scritto:

...

On Monday 28 of April 2014 10:37:44 Anton Aylward wrote: ...

...

All this is just an example of how determining options at run time rather than compile time gives more flexibility.

Indeed. And also creates a maintenance nightmare.

Why ? I think that only basic widely used features should be hardcoded, everything else should be a runtime dep, maybe plugin based.

Funny thing is: Baloo and Akonadi are exactly what you want: modular, super complex. That is why they have been so problematic for so long: it is very hard to get such a flexible, plugin based technology stable and performant. Making everything runtime/plugin based increases complexity. If you want it simple, fast and stable (but not flexible and everything hard coded) use GNOME. Or accept that it takes a bit longer and that it takes more testing (did you help test?) to get it right the way KDE is doing it.

Daniele.

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 06:20 AM, Jos Poortvliet wrote:

...

On Monday 28 April 2014 19:58:27 Daniele wrote:

...

Il 28/04/2014 17:56, šumski ha scritto:

...

On Monday 28 of April 2014 10:37:44 Anton Aylward wrote: ...

...

All this is just an example of how determining options at run time rather than compile time gives more flexibility.

Indeed. And also creates a maintenance nightmare.

Why ? I think that only basic widely used features should be hardcoded, everything else should be a runtime dep, maybe plugin based.

Funny thing is: Baloo and Akonadi are exactly what you want: modular, super complex. That is why they have been so problematic for so long: it is very hard to get such a flexible, plugin based technology stable and performant. Perhaps if what I wrote was what you were criticising things would be easier.

Modular in the sense of 'lots of parts' is NOT what I'm talking about.

Modular in the sense of being able to pull out any part and replace it with another that meets the same interface, including a part that is 'NULL'. Why wouldn't that be possible? Go, write a baloo alternative that offers the same API. No problem, except that it is a lot of work of course... In this regard, all of KDE software is incredibly flexible, it's just that usually we don't waste time creating 3 versions of the same thing. But feel free to

On Thursday 01 May 2014 11:20:45 Anton Aylward wrote: prove you can build a better search&index tech. Insisting on removing something that is needed to, say, get information about files (something quite core to an application like dolphin, yes?) is, well, let's just say you don't know what you are talking about. In KDE PIM you can actually live without search, it just isn't very useful.

Yes I realise that such an approach is 'old school' attitude toward development, straight out of Yourdon et all of the 1970s, but it led to reliable and easily testable code. Yourdon also talked of 'Big Bang" delivery, things that were not testable in modular form but only when complete, when fully built and integrated. It strikes me that the testing we're being asked to do is that latter case.

As I've mentioned, I've moved to working in Perl and Ruby. Both of these make great use of the ability to code systems that can use plugins and the kind of modular approach I've talked about. Between that and what I see when I look under the hood at other products that use dynamic modules such a Thunderbird and Firefox, I dispute the assertions that this is complex, unstable and difficult to code and test.

Creating a plugin structure always adds complexity and requires you to abstract and often simplify functionality. Claiming that it doesn't because it has been done by others is kind'a silly. Do you know how many paid developers work on Firefox?

In the limiting case there is the 'fork/execlv' and pipe mechanism that is employed, with UNIX, and has been for many decades. I've pointed out a couple of times now that KDE makes use of this anyway: systemsettings -> Default Applications. There I can set the editor, browser and many other options for external applications. We have a similar thing with the MIME file type handler so that Dolphin can dispatch the appropriate application for a specific file, as determined at run time.

That's an entirely different thing - just setting the mime type, nothing more. You could also right-click a file and choose 'open with' and get the same. That is VERY far from building a plugin architecture for EVERYTHING, which is what you're claiming we should do. There is already an incredible amount of flexibility in KDE software (just look at Plasma...) and you know what happens? Lots of developers start hacking on the monster that is GNOME Shell because 'it is simpler'. Of course, 'plugins' there break every release as there's no proper API, but at least it is simple... If half that energy (and the complaining) had been put in writing Plasma widgets, we'd be able to build all of GNOME Shell in half an hour of grabbing plasmoids from kde-apps.org. Looks like this modular way of working doesn't work very well, does it?

Other parts of KDE development make use of the ability to run external programs and 'pipe back in' the results. There's BasKets, in which you can define arbitrary external editors for the text body, for editing images, sound and movies. The code is there. It's been done. Its been done in KDE an many other application. Its a well established technique that has been practised for decades.

Oh, come on, that's not even remotely related to this... Now you're just talking nonsense, so I'm going to ignore the rest of what you say.

I'm not going to get into a pizzing match over whether a plugin written in a scripting language is more 'efficient' -- for whatever definition of 'efficient' we can argue about -- than coding in C. There are already many dynamic defined and dynamically bound such things already in use in KDE. We call them 'widgets' and I can see that some of them have been written in things like python and PHP! Their existence, the fact that they can be dynamically bound to the core of KDE rather than just an program in the KDE suite like BasKets, that they do external things, consult external sources, butild their own databases, and feed back the results into KDE and even display the results on the screen tells me something important.

I tells me that what some people here are saying can't be done, is too difficult, is too complex, is not stable, is already being done.

I hope this is simple one part of the development group (or whatever, since its not a team, with all the idea that 'team' implies such as 'teamwork' and 'pulling together'), not communicating with another, one part not seeing that another part has already solved the problem.

Somewhere along the line Jos seems to have got the idea that I think indexing is a bad idea. I didn't say that. I'm far from happy about the way indexing has been done, been invented separately. For example, many of us read email using IMAP from a remote machine. All that local indexing can do is download the headers (or body) and index that. But all this is probably indexed at the remote site. Things like Dovecot are very good at indexing and update the index as soon as new email arrives. Dovecot can also do full text indexing. Downloading all that email so as to duplicate the indexing locally seems redundant. See http://wiki2.dovecot.org/Plugins/FTS/Lucene for example.

The way indexing has been implemented in this version of KDE also precludes, or perhaps makes it very difficult, to deal with the "if you don't like it then build your own".

Suppose I did want to build my own. Suppose I did dream up some spiffy new algorithm. If the indexing was built on a simple plugin or SYSTEM(3) approach, the kind we see elsewhere in the KDE suite, than I could unplug Baloo using systemsettings->DefaultApplciaitons and plugin my own. But that supposes the interface is all in one place. As far as I can tell its hard coded into many other applications, Konq/Dolphin, Gwenview and many others.

Which gets back to what I was saying about 'modular'. Anything that is so insidious in other parts, in other applications, isn't well constrained, well bounded, easily identified module.

So, how do I file a bug that says I can't, despite being told to write my own indexer in the way I can write my own browser, editor, widget, and plug it in to KDE. How do I write a bug report that says the design has gone in the wrong direction, that the assertions about it being too complex are demonstrably unjustified? The bug reporting system is bout coding bugs not architectural bugs.

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 01:26 PM, Jos Poortvliet wrote:

Insisting on removing something that is needed to, say, get information about files (something quite core to an application like dolphin, yes?) is, well, let's just say you don't know what you are talking about.

Actually I do. I've never needed the indexer. I prefer a good taxonomy. The file system and symlinks has always given me that :-) -- Watch your thoughts; they become words. Watch your words; they become actions. Watch your actions; they become habits. Watch your habits; they become character. Watch your character; it becomes your destiny. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 01:26 PM, Jos Poortvliet wrote:

Creating a plugin structure always adds complexity and requires you to abstract and often simplify functionality. Claiming that it doesn't because it has been done by others is kind'a silly. Do you know how many paid developers work on Firefox?

Ah, another straw man argument. No, and its not relevant. The only thing that is relevant is how many came up with the way the plugin system works and I can count that on my thumbs. Sale with RubyonRails. Two guys. How many people have worked on other aspects of those products, on the plugins? Thousands. But that's not what I'm talking about. -- Latte is french for You paid too much for that coffee! -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 05/01/2014 01:26 PM, Jos Poortvliet wrote:

That's an entirely different thing - just setting the mime type, nothing more. You could also right-click a file and choose 'open with' and get the same. That is VERY far from building a plugin architecture for EVERYTHING, which is what you're claiming we should do.

More straw manning on your part. The basic underlying mechanism is there as part of the UNIX/Linux architecture. In the limiting case it is the SYSTEM(2) call. It is the ability to invoke an external program. There are well established code fragments that act as 'wrappers' around the 'fork+exec' which have been there since the 1970s and UNIX V7. It is and always was one of the things that made UNIX so much more powerful as a basis for development and experimentation than anything other computer vendors could offer. Now it is possible that the KDE developers, not working as a coherent team as you've implied, have done every single instance of KDE invoking an external program, be it though MIME settings, be it the editor, mail browser as per systemsettings->DefaultApplications, the screen widgets, each in a different manner with no common code what so ever this side of the system calls. If that is the situation then its a sad, sad case, and yes doing external calls in KDE is proving to be inefficient and a code-bloat. But that's a design decision. It cold all be factored down so that there was just one place where this was handled. That's certainly how its one with Perl in various wikis such as FosWiki and with RubyOnRails. -- "Now look," Forrester said patiently, "progress is an outmoded idea. We've got to be in step with the times. We've got to ask ourselves what progress ever did for us." -- Randall Garett, "Pagan Passions", 1959 -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data giovedì 01 maggio 2014 17:25:27, Daniele ha scritto:

No they are not, I cannot choose an alternative to akonadi/baloo without touching code...

Akonadi doesn't even start if you don't use an application that needs it. How is that a hindrance? ("Show events" in the clock plasmoid is disabled by default in openSUSE btw, which means that it won't start unless you tell it to) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 05/01/2014 11:25 AM, Daniele wrote:

I have some hopes in lxqt.

Where might I find a version for suse? -- Any sufficiently advanced technology is undistinguishable from magic. - Arthur Clarke -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Thursday 01 May 2014 18:13:37 Daniele wrote:

Il 01/05/2014 17:57, Anton Aylward ha scritto:

...

On 05/01/2014 11:25 AM, Daniele wrote:

...

I have some hopes in lxqt.

Where might I find a version for suse?

If I remember well there was a post about it in this Ml on in project.. Try search in obs but for sure is not ready. I tested a bit razor-qt non so bad but non ready for prime time.

Lxqt and razor-qt are now the same thing.

Daniele.

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Thursday, May 01, 2014 11:57:31 Anton Aylward wrote:

On 05/01/2014 11:25 AM, Daniele wrote:

...

I have some hopes in lxqt.

Where might I find a version for suse?

devel:cloverleaf:lxqt There is an installable pattern "LXDE-Qt"

On 05/01/2014 01:19 PM, Jos Poortvliet wrote:

I'd rather have one thing work well than 10 things that don't..

Its not an either/or situation. Stop pretending that Linux is that naive. UNIX and Linus has always been about choices, about 'doing it your own way' about ripping out parts and experimenting with new ones. Yes the whole point of experimenting is that sometimes you fail, and often you learn a lot from the failures. -- The early bird gets the worm, but the second mouse gets the cheese. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Go write an alternative then. I described the process to you. Otherwise, >stop claiming other people should drop everything they are working on and do >lots of things for you because somehow, somewhere, it might make something >better.

For F's sake, how hard is it to put in a GUI switch in the playschool Baloo interface? That is, since it seems that the decision has already been made to not have Baloo be an independent set of packages that can be completely removed? Is a GUI options going to make people drop everything they are working on? Please... On Thu, May 1, 2014 at 11:55 AM, Jos Poortvliet wrote:

On Thursday 01 May 2014 14:06:53 Anton Aylward wrote:

...

On 05/01/2014 01:19 PM, Jos Poortvliet wrote:

...

I'd rather have one thing work well than 10 things that don't..

Its not an either/or situation. Stop pretending that Linux is that naive.

UNIX and Linus has always been about choices, about 'doing it your own way' about ripping out parts and experimenting with new ones.

Yes the whole point of experimenting is that sometimes you fail, and often you learn a lot from the failures.

Go write an alternative then. I described the process to you. Otherwise, stop claiming other people should drop everything they are working on and do lots of things for you because somehow, somewhere, it might make something better. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Thursday 01 May 2014 11:52:07 Sam M wrote:

For F's sake, how hard is it to put in a GUI switch in the playschool Baloo interface? That is, since it seems that the decision has already been made to not have Baloo be an independent set of packages that can be completely removed? Is a GUI options going to make people drop everything they are working on? Please...

If you would have read the other emails in the thread, then you would have noticed the following indication:

...

...

An alternative control panel is being developed, addressing exactly these issues, in cooperation with the main developer.

Fantastic, thank You very much, I'm looking forward it. Hi Vojtěch, the current state of the KCM can be found in KDE:Unstable:Extra repository, under baloo_kcm name. I'd advise just grabbing the package instead of adding the whole repo

A volunteer from the community has started to write an advanced Control Panel that replaces the current baloo one. There we see more functionality coming back similar to what could be defined with the previous nepomuk one. Also it contains the famous enable/disable switch. As indicate the package is currently in the KDE:Unstable:Extra repository as that we do not have an official release for it and it is still being developed further. But people are more than welcome to grab it, install it and try it. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 2014-05-01 22:17 (GMT+0200) Raymond Wooninck composed:

A volunteer from the community has started to write an advanced Control Panel that replaces the current baloo one. There we see more functionality coming back similar to what could be defined with the previous nepomuk one. Also it contains the famous enable/disable switch.

As indicate the package is currently in the KDE:Unstable:Extra repository as that we do not have an official release for it and it is still being developed further. But people are more than welcome to grab it, install it and try it.

Which package is "it"? Does this development have an associated upstream bug to read and/or comment in? I'm having no luck finding one, and would like to mention issues I see in http://fm.no-ip.com/SS/KDE/baloo413-120.png if they haven't already been addressed. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data venerdì 02 maggio 2014 07:43:57, Raymond Wooninck ha scritto:

However it addresses a lot of the issues indicated in the threads with regards to the configuration of baloo. So I don't expect there to be any bug, nor a possibility to report bugs on. At least not yet.

If time permits, I'll try to talk with the author to see this is properly moved to KDE infrastructure for obvious added benefits. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On Monday 28 of April 2014 09:21:45 Anton Aylward wrote: ....

Its not that I don't want Baloo, it's that I don't want Baloo HARD CODED.

'Hard-code' wise, Baloo is not different than Nepomuk was. Actually, it is, but in a 'good way', as you're now able to remove parts of if, which do the actual indexing. This was never the case with Nepomuk. Cheers, Hrvoje

On Monday 28 of April 2014 05:22:25 Sam M wrote: ....

In prior version of KDE, Nepomuk's indexing feature was disabled by default, so I never used it. This was the case if you used openSUSE branding. By default, indexing was enabled otherwise.

They're already talking about allowing it to be uninstalled by having the Baloo package be split. I want this, because I want to uninstall it. And if my supposition is correct, I don't think I'll ever be installing it again -- not that I don't think it can become better. I just don't need it.

Only way to resolve issues is to report them first. There are many use-cases, and setups, so they all can't be spotted before the final .0 release. Also, yelling about untested crap is very much out of line. There was a dot story about new search engine, Luca announced the entrance of Baloo in KUSC, Raymond pulled in every beta and rc in KDF, so there where *a lot* off opportunities to test and read how Baloo, and rest of 4.13 behave. Additionally, we also made it possible to remove the indexers, so really ranting helps nothing and no-one. Cheers, Hrvoje

On Monday 28 April 2014 05:22:25 Sam M wrote:

Luca,

I think Anton means that he want to uninstall Baloo compeltely from his system, just like I do. He doesn't want any Baloo code on his machine.

That is just crazy. Don't blame the developers for not taking the usecase "I hate baloo" in mind when developing software. They take all use cases that are sane in mind: using search; NOT using search. Most people use search so it is enabled by default; you can add your home folder to the 'ignore' list so it gets disabled automatically. That there are people who just don't want the code on their computer for some 'purity' sake, well, though luck. There's no logical reason for that so nobody put in extra effort to support that. Or would you rather have a few MORE bugs in KMail so you can not only have useful things but also crazy stuff? Welcome to reality...

If you're not subscribed to the openSUSE user support list, I just sent the email I've copied below. Keep in mind how many people may be having issues with Baloo and aren't saying anything. Either they don't know they're having problems with it when they are, or they are and they aren't taking the time to report it. Not everybody is a computer scientist, but this new "feature" should not be forced down everybody's throat just because the KDE team thinks that this is way people should be using their computers.

The vast majority of computer users uses search. Sorry if that hasn't landed for some, but you ARE the exception. Win, Mac, Linux (yes, GNOME has it, too) all use that. 99% of computers can handle it just fine. Baloo indexes ~1000 times faster than Nepomuk and uses ~20 times less memory, putting it on par with the Mac, Windows and other Linux solutions. No reason to not enable it by default, thus. And those few who don't want it can disable it.

In prior version of KDE, Nepomuk's indexing feature was disabled by default, so I never used it. Just for testing purposes, I once tried switching indexing on through the Nepomuk GUI and a process or two started, yet my hard drive didn't seem to be doing anything. Either Nepomuk was broken, or it was unobtrusively indexing my files and didn't hog system resources. It's hard for me to compare Baloo to Nepomuk when, from my impression, Nepomuk wasn't doing anything even when the indexing feature was turned on. Baloo is a whole different story, and I had to turn it off because it was giving me performance problems. I didn't like that by default it's switched on, so the second you log into KDE it starts indexing. I hadn't kept up with any of the changes that were coming with KDE 4.13, and trusted that it would be an improvement over 4.11.4. Therefore, when I was having all types of performance issues related to disk I/O and CPU utilization, it took me time to track down how to finagle with Baloo and stop it. I was surprised that the GUI offers barely any options, and that it's opt-out and not opt-in.

Yes, baloo generates quite a bit of I/O, they've added a patch to throttle that now, I believe. It is actually a kernel issue (anything before 3.14 can not deal well with high I/O). This I/O problem shouldn't take long as Search indexes very fast - thousands of files per second. In case it bumps into files which can't be indexed, it will try to determine what file is un-indexable and then disable indexing for that file for the future. Unfortunately, determining what file is hard to index takes a while - about 30 minutes of full cpu and IO at most, per broken file. This has been decreased for 3.14.1 to about 5 minutes at most and will stop/not happen on battery power. Yes, Nepomuk never had this issue because it simply as so slow that it wouldn't eat the entire I/O of a system and I guess the devs use newer kernels that deal with it better so they didn't notice. It's fixed and I think these patches are now in openSUSE Current.

I looked around the internet some, and I found a funny post on the Kubuntu forum:

"After a few days baloo settled down on my system but on my wife's laptop baloo kept going and going for days making it really difficult to do anything. I found a message that ~/.kde/share/config/ baloofilerc has a line in it under [Basic Settings] Indexing-Enabled=true I changed that to Indexing-Enabled=false and the laptop was useable again, but lost a few search items. It's nice when it works but hell when it hogs the system."

I love the beginning where he says: "After a few days", and keep in mind that the 2.5" hard drive on his wife's laptop isn't exactly an icon for longevity. I can only imagine the wear and tear the first iteration of Baloo is doing to SSD's. Baloo shouldn't start automatically the first time a user logs into KDE, but I hate when OS's ask you questions through a dialogue box when you just want to get stuff done. I don't have an answer to how this should be done correctly, but I want to reaffirm that Baloo should _not_ start indexing anything without the user's permission. They're already talking about allowing it to be uninstalled by having the Baloo package be split. I want this, because I want to uninstall it. And if my supposition is correct, I don't think I'll ever be installing it again -- not that I don't think it can become better. I just don't need it.

It is easy to disable (add your home folder to the 'do not index' list in the GUI and it disables itself automatically) and as I said before, the vast majority of the computer users on this planet is already used to using search, both on the internet and on their home computers. The fact that you KNOW what it is in the first place makes you an exception (like me, yes). Don't force openSUSE developers or KDE developers to optimize for YOUR use case and ignore the normal users, please. Bugs and issues should be fixed, we shouldn't optimize for geeks like ourselves.

On Mon, Apr 28, 2014 at 4:48 AM, Luca Beltrame wrote:

...

In data lunedì 28 aprile 2014 07:01:47, Anton Aylward ha scritto:

...

Yes I know how to disable indexing. My point is that I don't want the code; it adds complexity and hence the potential for flaws to many

Sorry, but this argument doesn't make sense. This is Free Software. How are you going to prevent people from writing code?

There are a lot of things one can do to improve FOSS, including even harsh criticism. But saying "I don't want the code" isn't, sorry.

-- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data giovedì 01 maggio 2014 12:31:30, Vojtěch Zeisek ha scritto:

From my experience, its performance is much worst than of Nepomuk... And it seems I'm not the only one. There are some bug reports about that.

To be honest, we seem to live in dfferent planets. While I can't say the new search is perfect, I can say, since I was a heavy Nepomuk user (activities, tags, search PIM) that the difference is quite noticeable, even on a low end system (Atom dual core) I explicitly set up to be stressed. The Atom, with Nepomuk, would get straight *unusable* due to the combined CPU / IO usage. Now, while there are still issues wrt performance, I can safely say that the difference is like day and night there (less so on higher-tier machines). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 05/01/2014 06:07 AM, Jos Poortvliet wrote:

That is just crazy. Don't blame the developers for not taking the usecase "I hate baloo" in mind when developing software.

Ah, a straw man if ever I zaw one. Who here "hates" baloo? Hands up? No, what we're objecting to is the CHANGE. It comes across as arrogance on the part of the developers, a 'we know what's best for you' attitude. We had nepomuk and then everything changed. All the defaults were reversed from 'only what I tell you" to "everything unless you tell me otherwise".

They take all use cases that are sane in mind: using search; NOT using search. Most people use search so it is enabled by default;

There is an assumption there which is unjustified. The search facilities came as part of the package, a part the can't be unplugged. I can unplug VIM and plug in EMACS. I can unplug Firefox and plug in Opera. I can't unplug Baloo and plug in a indexer I've developed. Its too tightly integrated. Yes I need an editor. If I'm "on the internet" I need an email client and web browser (at the minimum). I don't NEED a file indexer.

you can add your home folder to the 'ignore' list so it gets disabled automatically.

There's no 'automatically' about it. You have to do this explicitly. And you have to know to do it. And there isn't a user-friendly i/f as part of systemsettings to do this. So we geeks can do it, but the poor Joe Sixpack user who doesn't subscribe to this list, who is a simple "well I gave up on Windows because Microsoft isn't supporting XP any more an everyone said that Suse was the best Linux..." won't know how to disable it.

That there are people who just don't want the code on their computer for some 'purity' sake, well, though luck. There's no logical reason for that so nobody put in extra effort to support that.

Another straw man! Its not about Purity, no Dr Stranglove here. Its about foisting on us things we don't have options to deal with. As I keep saying, there are plenty of things in KDE that are configurable, where I have a choice of how I want some facilty to work. I can even choose not to install kmail and use systemsettings->DefaultApplications to use Thunderbird instead. But I can't choose not to install Baloo and use AntonsOwnIndexier instead. The code for the indexer that the KDE not-a-team have chose is hard-wired in to a variety of KDE components. Its not modular as are so many other aspects of KDE. Please leave off the ridiculous straw man examples. They don't do you any credit. -- HTML has followed nature's example... Bright, sometimes flashing, colors are a sign of indigestiblility. -- Rob Hartill -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 04/28/2014 07:48 AM, Luca Beltrame wrote:

In data lunedì 28 aprile 2014 07:01:47, Anton Aylward ha scritto:

...

Yes I know how to disable indexing. My point is that I don't want the code; it adds complexity and hence the potential for flaws to many

Sorry, but this argument doesn't make sense. This is Free Software. How are you going to prevent people from writing code?

There are a lot of things one can do to improve FOSS, including even harsh criticism. But saying "I don't want the code" isn't, sorry.

It does make sense. Look to what the BSD people are doing with openssh. We've said "I don't want the code to deal with fringe cases", as in "I don't want the code that deals with VAX/VMS" and "I don't want the code that deal with Microsoft Windows", soi they are taking it out. Any yes it is reducing the complexity and yes it is increasing the reliability and the security, And yes it is FOSS. -- "If you spend more on coffee than on IT security, then you will be hacked. What's more, you deserve to be hacked." -- Richard Clarke, the special adviser to the president on cybersecurity -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org