This week's KDE CVS-Digest:
Kolourpaint adds Emboss and dithering effects, more levels of undo.
Digikam adds RGB balance plugin.
KPresenter adds a custom slide show option.
Krita improves input tablet support.
Kexi continues improvement to query editing.
KSpread gets a new formula engine.
Kopete sees beginnings of MSN file transfer support.
KConfigEditor can edit both Gnome and KDE configurations, and export configurations in KJSEmbed JavaScript.
Dot Categories:
Comments
But why don't you want to modify the existing main and (one too many :o) ) extra toolbars. What's the difference between changing and saving one toolbar, and using a completely different one. Except that using a completely different one is silly of course! :o)
You don't want to modify the Main ToolBar because it has things hard coded into it. You need to have the separate Extra ToolBar if you use my configuration with the Main & Extra ToolBars oriented Vertical. If you have too many icons in them, they will stack (side by side) rather than scrolling off the bottom of the screen (which is what happens if you had all of the icons in one toolbar). This is more important if the user chooses a larger icon size for them. As I said, to actually replicate my doctored screen shot, you need an additional toolbar.
--
JRT
Then surely that's a pretty serious design flaw? I understand what you mean, but to me a toolbar is a toolbar is a toolbar. At most I can see the need for ONE extra, if the main toolbar is so seriously hardwired....
I agree with you. Making them one single program makes it more complex than it should be, especially for the newbie. You can only do so much with the view profile. Currently it is problematic to put the location bar at the right of the main toolbar in Konqueror-web because it would double the location bar in the file manager.
> The idea of a home url on the web doesn't really make that much sense; I'm sure you have many URLs you visit regularly and arbitrarily choosing one to be "home" above the others doesn't make that much sense.
I don't think this is true. For example, my "web browsing home page" is a local html page generated from my bookmarks, using a tool like bkmrkconv. To me, this make perfect sense as my "web home", while I obviously want ~ to be my home for file management purposes. I totally agree with Corey here.
This seems to relate closely (or the 'evolution' of it's feedback) with this 'bug' reported in the year ...2000: http://bugs.kde.org/show_bug.cgi?id=8333
It has been reported in the year 2000, only 4 years ago in august.
It frustrates me that konq is different from every other browser in the world that I can't set a 'real' home-page (not so frustrating is that I consider it the best browser around).
Going further with this flaw I also find frustrating is that I can't specify different behavior for file-type handling in web and file-browsing modes. I'd prefer to have text files open in-browser in web mode and in an external editor in file browsing mode.
I have no idea why people always compare apples and oranges and then complain about things not working a certain way. Konqueror unlike any thing else you have used was designed to be a universal information browser. It is neither a file manager, nor a web browser. What that simply means is that Konqueror does not care about the location of a particular information so long as the underlying network handler, KIO, supports it. It uniformly deals with all resources whether they are located locally on your own hard drive or on some remote machine.
If what you want is a separate web-browser and file manager then konqueror is not the right tool for you, period. You can use mozilla/firefox and krusader for filemanagement for example. Do not attempt to make a tool what it is not...
While, as you say: "[Konqueror] is neither a file manager, nor a web browser", and "Konqueror does not care about the location of a particular information..." - may be true, but for Konqueror to not care and not provide a functional differentiation between local and remote browsing, and file and web browsing, is to make itself too generic.
Thus, Konqueror's concept of "Views" - i.e., the default Views of "File Management", and "Web Browsing". If, as your argument indicates, Konqueror doesn't care, why then would it differentiate between its concept of "View Profiles", and why would it have separate configuration dialogs for "Web Behavior" and "Behavior" (i.e. file management behavior)?
So, going further, if Konqueror itself is obviously aware of the different use cases inherent in Web Browsing versus File Browsing/Management via its Views concept/behavior/functionality, why does it then procede to squash 'Home URL' and MIME/File-Type behavior together - regardless of the real and practical differences inherent between the two default View types?
Ergo Konqueror makes itself somewhat of a victim of its own hypocracy, and therefore - to answer your question as to "why people always compare apples and oranges and then complain about things not working a certain way", specificaly when concerning Konqueror's treatment of Home URL and MIME - NO WONDER why people are confused. Additionaly, while you claim that Konqueror "is neither a file manager, nor a web browser", I claim that it is BOTH a file manager AND a web browser! So it should be able to act like both, as it provides the sole means of both these activities under the KDE environment.
Perhaps the most logical solution is to make Home URL and MIME behavior configurable aspects of the _View_, rather than of Konqueror itself. Meaning, in the same manner that within the Profile Management configuration dialog, we currently have 'Save URLs in profile', and 'Save window size in profile' - the Profile Management would also be made to include 'Home URL' and File-Type handling configuration options.
This would keep the idea of 'Konqueror as universal information browser' intact and sound, while still allowing USERS to operate their File Manager and their Web Browser the way they prefer/expect, via the Views paradigm. Not to mention of course the bonus affect of facilitating whatever other "View" ( method/purpose of interacting with Konqueror ) the user might dream up aside from the two main defaults.
Yes to everything. Someone please fix the toolbars. Configuration is a nightmare and the "view profiles" do not respect different toolbar configurations.
Does anyone know if Krita will have support for writing your own filters, and if so, if there is any documentation about it?
Do you mean filters like "putting an effect on an image" or do you mean filters like "load/saving images".
If you mean loading/saving, I think it already can do it. As for image effects, I think that is why the plugins are for (for example the histogram plugin.)
As for documentation, I do not know if the current developers have much time for it. But I think that they would not mind have volunteers, see the Krita's mailing list (named kimageshop):
http://www.kde.org/mailinglists/index.php#krita
Have a nice day!
I meant filters like "putting an effect on an image". I have dabbled with such things in Delphi previously and thought it might be nice to try and do much the same thing in a more mature program than my own attempt. :-)
Not sure about joining the mailinglist, though. Feels like I should be reasonably sure I would actually be able to contribute something. As it is, I am not even sure how to actually install Krita (my cvs knowledge does not extend beyond Konstruct). :-)
Well, you really need to be able to compile Krita from cvs to play with it -- even though you don't need to know much about its internals to write filters. In fact, we could use someone who has knowledge about image manipulation to add a few useful filters.
There's one problem, though. We are currently redesigning the standard way of accessing image data -- there are now two different ways of grabbing pixels and channels, and we want a third, better way. It's probably not much use doing a lot of work with the current code.
However, I really, really want to deliver a first alpha with at least that interface stabilized this autumn, and from that moment you can write plugin filters to your hearts content.