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