In this week's KDE Commit-Digest: Much work in Amarok, with the implementation of a CoverFlow-esque OpenGL album art visualisation, codenamed "CoverBling", and Service Framework and Plasmification efforts. Sample OpenGL-based applets added to Plasma,, with Plasmoids to watch for changes to files, for browsing files, and to monitor network interfaces. General progress in the 2d projection and KML in Marble, OpenPrinting, and KOrganizer Theming Summer of Code projects. KWallet support in KRDC. KMines essentially rewritten with a QGraphicsView base, with support for multiple background SVG themes in KGoldRunner. More manipulation and view work in Kreative3d. Implementation of Kubelka-Munk paint mixing research in Krita. Internet integration in Kaider, with a WebQuery view and example script to use Google Translate. okular becomes usable as a print preview component. KTrace, a "strace" interface for KDE 4 added to playground/sysadmin. Beginnings of support for ComunIP, a Brazilian IM protocol in Kopete. More progress in the porting of Digikam and KTorrent to KDE 4. The start of a rewrite of the Oxygen widget style. KBFX, an alternate K menu, moves to kdereview.
Comments
That's weird, tasty menu has less bugs just because it's not skinnable,
really simple and lacking the new features. It's also too big for most
users. It would be better to keep the actual kmenu then...
I don't really like tastymenu, but I do think your arguments are bogus:
A menu shouldn't be skinnable, that's stupid. The whole point of themes in KDE is not to need skins. Even Kopete does just use the default KDE look, and so should any menu replacement. Kickoff is weird enough already...
And, what's the problem with a big menu? If you're browsing through the menu, you don't do anything else - a menu could be fullscreen. A larger menu with bigger targets is better than a small one. I don't like the raptor whatever mockups, you're always scrolling, text is small, it has weird themes (just slowing down the system and making it look funny) so it's not usable at all.
The current K-menu (in the 'kubuntu incarnation' is pretty good, indeed. But I support the research going on in new area's. Personally, I'm a big fan of Gimmie, it looks like a much more usable menu replacement:
http://www.beatniksoftware.com/gimmie/Main_Page
1) It's really sad that people puts all their efforts givin some
eyecandies to DE, like the BLACK Kore theme, and then someone say:
"themeable/skinnable things aren't important at all". I already noticed
that most of GPL software is done from programmers to programmers
(just look at those ugly krita tools-icons, it's obvious that there isn't
any real artist using krita....), but we are in year 2007 BC, please try
to keep this in mind.
2) That menu's so big that can't be correctly displayed on minimal displays,
and so big that you have to move the mouse through the whole screen to use it even at 1024x768, that's uncomfortable!!!!
About skins: I don't know the official concept but I think KDE style itself should be nice and skinnable while applications and other elements like menus should smoothly integrate to this look instead of having their own look and skins.
"we are in year 2007 BC"
Are you sure?
They figured if they could take the KDE source code back 4,000 years in the past, that would give people enough time to look at, fix it up, and get it out the door on time for the KDE 4 release.
Or they figured that there are gnome users here trying to give wrong
suggestions just hoping that they can do something to prevent users migration
to kde 4 (for example because all the ugly totem bugs....).
To all them , give a look here, at the last comment, there are also kde users
in gnome spaces (and I laugh for this):
http://www.tux-planet.fr/blog/?2007/07/02/161-gnome-mockup-3
"The start of a rewrite of the Oxygen widget style"
The Oxygen widget set looked quite yummy, last time I saw it, and lots of effort had been put into it - what's the rationale behind the re-write, may I ask? Is the windec also being re-written? Also, given that the corners of the Oxygen windec are curved, will clicking the very top-right pixel of the screen when a window is maximised close that window?
"what's the rationale behind the re-write, may I ask?"
The code is a pain in the ass. Ugly, unmaintainable, not worthy for inclusion into kdelibs. It's so broken that it's better to start over from a clean base, which is the aim of this rewrite. Keep the nice looks while drastically improving the code.
That's the best possible reason for the re-write - glad to hear it, and good luck! :)
Any idea on an ETA for getting the re-write up to the current (functionality + looks) level?
ok.. wish you good look.. if possible keep the current style (or improve it :p).. it looks just great ^^
ups.. look = luck ^^ sry. i'm a bit confused atm ^^
Nice freudian slip ;-)
Good to hear!
I also have a good attitude at writing "write-only" code, at least when i don't care about good design of the program, but i know wery well how other people react when i do (especially Paolo :) )
That doesn't surprise me. QStyle is a bad platform to extend for original styles -- its granularity is meant for wrappers; all styles implementations I have seen are pretty ugly and I can see how the code can get unmanageable if you are just a bit sloppy. I have started doing a layer on top of QStyle that should end in cleaner, smaller styles. If you wanna help out: http://gtk4qt.sourceforge.net/qsimplestyle/
hm.. don't unterstand that too.. i'm following the development of kde4 through the opensuse buildservice and i have to say: it just looks great... only the window decoration doesn't work properly here... it changes but it's completely red (instead of grey).. don't unterstand why..
the plasma widgets are also great.. they perform well for there early state
so.. move on with the great work ^^
I get the red borders too. Also, the oxygen style is really low contrast - makes it very difficult to use. Although I wonder if the colours on my computer are right - everything is light grey except tab bars which are black. And the text on selected tabs is also black. But I can't seem to change this.
The red windecs are caused by debugging code, they're shown when some pixmaps couldn't be loaded (for whatever reason) to make it extremely clear that something's wrong. So it's there on purpose.
how can we locate which pixmaps are missing?
> Also, given that the corners of the Oxygen windec are curved, will clicking the very top-right pixel of the screen when a window is maximised close that window?
In KDE 3, there is an option that controls whether maximized windows can be resized and moved[1]. If that option is disabled, well-written window decorations will enter a mode in which they do not paint borders if a window is maximized, and if they normally have rounded corners, they will morph to either do away with them in that mode, or they will at least expand their mask to accept clicks in the very corner. Of course, as the default window decoration, any Oxygen decoration will eventually be faithful to that option.
1 = KControl -> Desktop -> Window Behavior -> Moving -> Allow moving and resizing of maximized windows
I thought Kopete still had to go through a whole switch to phonon and other new backends (for presence etc.), along with porting all of the old protocols. Has this already happened, or is it possible to add protocols independently of that work? Or has the other stuff been set aside for the moment?
I only ever had three problems with kopete: a) stability, and b) speed of the chat history and some other gui stuff, and c) no audio/video chat support. I still use it over anything else. If that stuff's fixed, I'll be more than happy with "Kopete 4".
I guess you meant decibel instead of phonon, the latter is a multimedia backend. I'd really like to see improved file transfer speed over msn protocol.
I imagine it uses phonon powered dings and beeps
Kopete should Use the Decibel Project which uses Telephaty FD.O Standard.thats Planned for 4.1 I think.
But Kopete has more protocols and better implementations that telepathy has currently. So a switch would be painfull.
Telepathy is just a specification.
Kopete can both offer functionality as Telepathy components as well as use Telepathy components to extend its functionality.
"Using Telepathy" does not reduce Kopete's functionality
"David Vignoni committed changes in /trunk/KDE/kdelibs/pics/oxygen:
Switching arrows to use Pinheiro's Scribus arrows."
Thank you :)
They look very good.
They do look good but the previous/after arrows look just like the up/down rotated (without ajusting the reflection/shadow).
And they haven't got a shadow like all the other icons.
hopefully the shadows all go away. they were an interesting experiment, but didn't really work in practice.
Great! so it was noticed those shadow's didn't work...
How about a pixmap engine where everybody can easily change the appearance without coding skills. Hasn't Mac OS X such thing?
Or even a SVG one (using the same schema of icons that generate pngs for speed) that would allow resizing of the toolbars/widgets without much visual distorsion? :)
http://websvn.kde.org/trunk/playground/artwork/cokoon/
What can I say?
Seems like a awesome work!
The problem with SVG is that it does affline transfomations in the entire canvas, so you can't set some shapes to a fixed size -- which you want for borders; you don't want the border of a button to stretch, just the contents. The upcoming Gimp vectorial-based graphics language would be a better candidate.
KDE3 already allows limited pixmap-based styles (an example being the bundled "RISCOS"). The now unmaintained Detente (http://www.digilanti.org/werks/detente/) exists to facilitate this.
Alright, as a typical person who learnt digital image editting on Photoshop (version 5 or something), I got used to how things were done in it. I've used GIMP several times as well, and although I can usually do the same thing in it, I like Krita a lot more. Starting with KOffice 2.0, I believe that Krita can become a Photoshop competitor someday, and I can finally start recommending something other than the GIMP for people whom want a free photo and image editor that supports lots of professional photography techniques (and is available on Windows and Mac OS X).
About Kopete: it's nice to see more protocols added to it, but I was wondering how far it was in making a rock-solid Jabber implementation. It'd be nice if Kopete could try to promote using Jabber or IRC a bit more over using proprietary protocols, and having support for most of the XMPP standards and proposals could go a long way towards helping that. I can also recommend this over Pidgin to people as well (although Miranda IM for Windows is pretty sweet, it's a total power user sort of application).
Thanks, KDE guys! You rock!
As I said on the last topic on Kopete, Decibel is a new KDE Project for Real Time Communications Managent.since IRC and Jabber are Real time communications, Decibel handles them.
and as I know, Kopete will use Decibel az 4.1. Decibel itself uses Telephaty FD.O standard, so you should ask for better IRC Implementations from Telephaty people.
And...Im not sure...I just said what I tought.
Please note that Krita aims to be a PAINTING APP, not purely a photoeditor. There is a lot of overlap, sure, but I think it should be noted ;-)
well, in the long run it doesn't make much difference. all photo editing stuff is usefull in a painting app too. thats why so many "paintings" are still done in photoshop, even though apps like painter or artrage are around for many years now. its brush engine is weak - but the more complex your painting gets, the more you need all the other stuff.
> ... all photo editing stuff is usefull in a painting app too
Not really. There is a lot of stuff that is specific to photos that is no help at all to creating original work. And The GIMP seems to lack some of these features as well. There is also the question of drawing (I draw but do not paint). xFig is very good at drawing but is rather dated, yet there is no other app I know of with those features. It would be nice to see these features in a new app like The GIMP or Karbon14 (such an app would also need to do SVG to replace the app specific xFig file format).
what should be specific to photos? things like the levels etc. are usefull for painting too. photo editing is about perfecting the final touch of an image. there is no reason not to use the same tools on your own paintings.
> what should be specific to photos?
Everything which is designed for the specific purpose of modifying an existing bitmapped image.
maybe you should read my complete post before responding...
go take a look at places like cgsociety.org and see for yourself how photoshop is used. all features that are meant to be used for enhancing photos greatly boost the flexebility of the artist. and thats why someone paints digitaly, because you can change things with ease.
Things like red-eye removal or correction of lense distortion etc. are not needed by a paint app.
> maybe you should read my complete post before responding...
Perhaps you need to read my post more thoroughly. :-D
Strange, you keep saying enhancing and I keep saying modifying. Perhaps this is a language issue.
IAC, I fully understand that there are paint features that can also be used to enhance photos. I use The GIMP to fix photos. However, the fact that there is a great deal of overlap does not mean that there aren't operations that are specifically designed for photos that are not needed to produce original work of any kind.
You might like InkScape, which replaced XFig for me after many years.
I use InkScape, but it lacks some of the xFig features which I like.
So, I still wind up drawing things with xFig an importing them to other programs.
Are you really able to use Krita in a productive way? Then please
write some tutorials, judging by the lack of scripts and tutorials I was
thinking that nobody was using it (nor pro nor hobbist)...