-11

Hi All!

My main problem with KDE is the applications it provides. There is a tendency in bloating things up with new features untill it becomes to complex, to be useabel.

Konqueror was a web browser. Then it become the browser for all things, has a builtin kwrite, image viewer and soo on. Kate is becoming the next kdevelop with all it's features, and Kommander's builtin editor is becoming the next Kate. And there is also a tendency of "and let's put a terminal window in the application, just in case"

What is this good for? Sometimes less is more. Kate doesn't need a builtin file browser. The file browser should be a separate application that works together closely with Kate.

I think we should go back to the roots: The console doesn't have all purpose tools just simple well working ones, that can be chained and bind together. I think this is how this should work in the graphical environment too.
Instead of a monster like kdeveleop:
I have a good source editor, a debugger, a build environment and a browser, maybe they run in the same window as tabs, but I can run the separately if I will.

So I can create new "applications" on the fly. Putting a filesystem browser panel and a picture viewer panel in the same window, I can create a picture browser application.

I can save my setup, so the next time I want to fire up the same app, I don't need to do it all over again. There are couple of setups saved by default: Like Kate, or similar applications.

I agree that this is a wild idea. But hey, this is a Brainstorm forum right?

Brain

I think the fact that there are so many features is hardly a problem: most users won't use all of them, but all of them will be used by some users. In the end, you show what you want and hide what you don't - it's not that hard for the user.

Besides, if some of these features were turned off by default, the people that would like and use them may not ever know they're there

There's the Windows philosophy of large all-purpose applications, and the philosophy of small single-purpose tools. KDE is trying to strike a balance in the middle.

More features means more bugs, but fewer features means more work for the user. Imagine the user workflow if you needed one app to play MP3s, another to play OGGs, a third for streaming radio, etc. It makes sense to create an all-in-one music player. The danger comes when you have so many features in one app that it becomes too complicated to use. Look at Word's overflowing menus, toolbars and ribbons for an example.

I do lean your way, however. I would rather see twice the effort on bug fixing and half on new features. I probably won't need the next latest feature, but I will definitely get annoyed the next time plasma crashes.

One KDE application possibility that has significant approval and support is a "good" auto dealership program for small to medium businesses here in USA - covering repair service and body shop service, accounting and CRM.

Three existing software applications that tie these functions together "perfectly" are:
(1) Autohouse II - already listed in KDE-Apps.

(2) PostBooks - the extracted (complete) Accounting/CRM portion of X-Tuple, an internationally recognized Manufacturing application.

(3) Fisterra Garaga - an application originally developed for Auto bodyshop/auto glass service.

*** All three are licensed under GLP.

*** All three are based on PostgresSQL database.

*** One and two are developed with QT, third with GTK+.

KOffice and Kontact integration capabilities would make this resulting program formidable and the star KDE application available.

There are "tens of thousands" of auto dealers in USA looking for this type od solution, that is based on Open Standards/FOSS (Free/Open Source Software), and with the KDE front-end would be about 90% percent competitive with "all" the popular Windows based similar programs that can cost up to $10,000 with all "upgrades/fixes contracts, and still only works with (separately purchased) QuickBooks.

Each of the thirty three plus (33) Auto shops interviewed, indicate a difficult integration of Quickbooks with the services program and cannot integrate well with Microsoft Office or bank software. They all were excited about this new KDE program prospect.

W. Anderson
wanderson@nac.net
NJ, USA

1-973-729-1007

I was thinking of a similar idea to this.
I think that's what plasma in apps is trying to achieve.
I'm not really sure. But I like the idea of build-it-your-self app.
But I'm not sure what exactly is that you wish to propose.

Totally agree regarding the 'simplification' - each part could become a module. The aim could be to then have these easily reused (plugged into) other apps as they are required...

Win-win: Can keep as many 'features' as you want, while making the code simpler and more easily maintainable? Pity it has been voted down so badly...

Vroomfondle wrote:Totally agree regarding the 'simplification' - each part could become a module. The aim could be to then have these easily reused (plugged into) other apps as they are required...

That's what kparts are for. I.e. Konqueror has no support for viewing pdf-files by itself. It uses Okular for that. Digikam has not a built-in desktop globe. It uses marble.

So what you propose is already implemented, and have been for quite a while. Not sure when kparts were introduced but they've been a part of KDE for a long time.

Kryten2X4B wrote:So what you propose is already implemented, and have been for quite a while. Not sure when kparts were introduced but they've been a part of KDE for a long time.

While that is good to hear, I don't get the impression that a lot of programs are implementing things quite like this - rather they appear to be 'borrowing' code from others (saves reinventing the wheel) and implementing it directly within themselves (better integration?).

For all I know, they might be... but it would appear to me that a more modular approach could still be an aim - where the user has more control of which modules they want employed within the program they are using.

Obviously each program can make the choice to do this (or not) on their own, however if we are talking high level KDE infrastructure here, then putting some sort of 'best practice' framework in place may help?

Kate allways been almost the same o_o !
And it's not going to be the next KDevelop at all : it's an ALTERNATIVE to KDevelop, for guys like me, who doesn't stands IDEs, and write code only with the console : Kate is the delightfull alternative between a console, which is not allways easy to use when your working on a lot of file, and the IDE, which is quite a mess to use and not very liked by many of those who know how to write a Makefile themselves.

Besides, the power of KDE is to make features you can use only by finding them. They're not well hided, but the end-user who doesn't want to make it more complex will just not see them...
And we, the ones knowing what they're doing, will use those features.

There is nothing to fear : in fact, Konqueror has even less features that his KDE3.5 version !

Primoz wrote:But I'm not sure what exactly is that you wish to propose.

Hi Everyone!

My problem with the current Apps and KParts is that there is way too much glue code, which gets duplicated. Or the problem is that it's not duplicated, but missing at all.

Simple example: Check Kate vs. Kommanders Builtin editor. Embedded text viewer is a widget, which does handle a single document. If you have multiple documents you have to write an app that does that. But then you have to write the handling and closing of multiple tabs. If you want add plugins to you embedded text editor you need to write that also. And if you forget to add the keyboard shortcut setting to your plugins then they can't be set. (Like in Krusader's embedded editor). The worst part of this: This is already written in Kate, no need to do that all over again. Same goes for kate and the File browser plugin.

Ok, here is a more detailed version of the idea:

Create a few AppParts (Some of this are already implemented.) Like:
- Text Editor. (Like embeded text editor, but embeded text editor is only 1 document view)
- File browser (including network)
- Terminal
- Pdf Viewer (Like Okular view)
- Web Browser (Like konqueror)
- Image viewer (Wich can do basic image manipulation)
- etc...


Then create the Runner:
The application that can hold any number of these AppParts as tabs, or splitviews, or on autohiding panels (like kdevelop). And can manipulate these panels on very high level. Extreme example: I drag n drop one of the panels from one Runner to the otherone.

Than create a couple of predefined Runners:
- Kate with a single editor AppPart
- Krusader with a couple of FileBrowser AppPart (Depending on 1 or 2 or more panels)
- Kdevelop: Editor + File Browser + Workspace (project + build) + WebBrowser + Debugger

But any time I need I can create my own application: If I want to browse and preview pdf quickly I fire up okular, and drag n Drop a filebrowser in it.

The AppParts have a global configuration that can be overridden locally. So if I set CTRL+B goes to the matchin bracket, it does that in every editor AppPart, except in kommander's viewer where readonly mode is the default and I explicitely set CTRL+B to toggle bookmark.

Interoperability between the parts is still a question. Because they are separate applications. But hey this is just an idea, not a fully worked out design plan. I leave the details to the designer, if they whish to implement this.

Brain

all purpose swiss army knives, and light fit for task apps... i find that both ends are accomodated very well.

think kate too hefty? jump down a notch or two in simplicity, go for kwrite or kedit.
think konqueror to hefty? there's always dolphin or a lightweight web-browser, depending on your needs.

we're all catered for here.

i wouldnt gut out features of those apps which enable you to do more with opening less apps just to appease those looking for single use apps, when such apps already exist ALSO.

i personally utterly adore the inclusion of the terminal in guis. i dont often use it (use tilda or yakuake most times), but for when i do, it's such a gratitude generator. puts a big big smile on my face.

The example of kate and kwrite is not exactly fitting, since they share the same code...