In this week's KDE Commit-Digest: Umbrello gets a code generator for the D programming language. Further work in Plasma. Initial work to allow the Dolphin file view component to be embedded into Konqueror. More work in the KOrganizer Calendar and KRDC Summer of Code projects, with the start of the Icon Cache, TextTool Plugins in KOffice and Kopete Messenger update projects. Start of a Solid interface in Amarok, with breakthroughs in support for the Jamendo music service. KDevelop begins to be ported to the KDevPlatform structure. A return to progress on the Cokoon SVG window decoration engine, with the addition of PyQt4 bindings. A streamlined command-line screenshot utility, kbackgroundsnaphot, is created. The Gwenview image viewer moves to the kdegraphics module, whilst KPF, KWifiManager and KDict are removed from the kdenetwork module for KDE 4.
Comments
He's not trolling. He wasn't referring to e17, but to the general, overall negativity of certain posts. In the past weeks there have been way too many.
i didn't say that e17 was bad, just that the reason is probably that most people don't like its style. being hard to procure doesn't help, either. who was it that said that real products ship?
if you like it, that's GREAT. i like a lot of things that most people don't like. i've gotten comfortable with that fact.
what i'm trying to get across to some of the people in our community is that you really ought to try openning your mind to a vision that is bigger than just you. why? because when we have a wider view we include more people. that includes you.
the downside is that when we do that we also tend to find solutions that work for most people by default while providing for the minority through options and customization.
you talk about e17. what about those who don't or can't appreciate its stylings? yes, they are SOL. for the e team, that's no big deal. they have a focus point that is pretty constrained and are comfortable with that.
but kde isn't e. the goal many of us have is to allow for things like e (as well as in the other direction), but provide defaults that work for more people. this is an amazing engineering challenge, but one that we are getting closer to achieving year over year.
sadly, it means we take flack from time to time from those who concentrate on their own needs. be they people who love e or people who think the world should be painted in simplified brown.
personally, i'm after world domination. e and simpleBrown are just customizations of that. ;)
You're answering me something I didn't say.
You said this:
"probably because so few people actually like it"
That's not true, people dosen't know it, but you can't say they don't like it, if I am wrong and you made an experiment with people to see what they think about e, ok, then you can speak with facts, otherwise, it's trolling as far as I can see.
By the way, I didn't try to tell KDE to follow enlightenment look, that will be terrible. KDE it's KDE and shouldn't follow anyone else, it have his own style, so as e17, gnome, fluxbox (etc.) have their own.
In fact KDE 4 is one of the most exciting projects out there, I'll hate it if it just was some new e17, or GNOME.
I apologize in advance for my bad enligsh.
Have we developed a plan to rename the icons in KDEArtWork-4?
Yes, I will volunteer to work on it.
Useless reply : I just love the new iconset :)
> They are not icons. They are Mac wanna be
You know most toolbar icons in the mac don't have colors??
Only the application icons have realistic colors.
I agree.
For instance, at 16x16:
A) up and down arrows for webcamrecieve and webcamsend are unrecognizable;
B) the mic in the headset for voicecall blends in with the shadow;
C) the tag for available looks more like an old mouse.
I'd rather there not be tag/door knob hanger/whatever in the available icon.
The set status message icon seems pretty clear, though.
agreed as well. So many of these look terrible at 16x16. 22x22 isn't much better.
I partially agree for the Kopete available icon. It's not very easy to recognize. And the "lock" or whatever it is doesn't symbolize "available" to me. A light bulb or just a green check mark or sth. like that would be better IMO. But beyond that: I've been very critical of Oxygen in its infancy and didn't like most of the icons. After many revisions of these icons that has changed a lot. You can see that lots of work has gone into these icons and especially on higher resolution screens which are more and more common these days they're just superb barring some minor exceptions like this one.
Yep same here!
I forgot to say that I really like most of new revisions on Oxygen.
They just have to think a little less like Apple in some cases, and use something more representative.
I would LOVE a operating system with a style like google talk: clean, easy and very intuitive.
I think each icon should have an option to rate any individual revision of it, so the most popular ones could get into an 'extended' version of Oxygen packing in alternative icon subsets.. like 'I want to have all my folder icons have *that* kind of folder, but all my media player buttons like *that*... I think this would be the one solution to please them alll.. and no as sorry I am I cannot code it, busy with soc---- anyways regards
Yes, some kind of democracy for icons.
At least some kind of voting for icons HIG would be VERY welcome. :)
There are some icons in Oxygen that are really good, but a few just dosen't follow the quality or just don't transmit the idea they should.
Can we expect to see an integration with Umbrello and KDevelop? What would be nice is starting a KDevelop project, where an Umbrello view opens first. You then design your model there. When you build your project, KDevelop causes Umbrello to do a code generation.
Even nicer, is if in KDevelop, you edit the generated source files, Umbrello "sees" the changes, and incorporates them into the model.
Usually, when I open a project my idea is not to design it, I already have my idea and I want to put it in code.
The second idea is nice, maybe could be a kdevelop plugin of software (they have import from C++ I think, shouldn't be that difficult).
Integration? Better good cooperation. That is no integration on the userinterface level. Netscape comes to my mind. that was in the days on the integration fashion. You get overcomplex applications which confuse people and are buggy.
Does someone think it will be possible to provide the IM informations (state, avatars...) through a dataengine in plasma (in order to make some cool plasmoid to interact with my contacts (as a picture of my girlfriend in a buble on my desktop which become grey or colored according when she is connected, etc...)
well, maybe not, I'm not sure to understand what a dataengine can do :p
This is a nice ideia for a data engine, no aseigo?
maybe for a 4.1 version?
Why not? Maybe something with Decibel?
I think there is technically no problem of implementing something like that. However, someone has to write the DataEngine and the Plasmoid.
To me, one obvious future path for Konqueror is to start a new browser-only project, from scratch and based on Webkit, with a similar philosphy to Dolphin but strictly orientated towards rendering web pages, and then create a new Konqueror4 project that simply uses this Webkit project and Dolphin togerther as kparts (or whatever the KDE4 equiv is) as the new NG Konqueror. The current Konqueror code remains in the 3.5 branch. The new Konqueror looks and behaves like the current one but is really only a simple wrapper around the Webkit engine and Dolphin. No need to "pollute" KDE4 with ancient Konqueror code and half the new Konqueror is already done. We'd also end up with a Dolphinesque trimmed down dedicated web browser. KDE4 Konqueror users would be happy, webkit browser-only users would be happy, Dolphin-only advocates would be happy.
No, even if other people agreed with this approach, I have no skills to implement something like this. I do wish I could though.
i think this idea was around for some time, but currently there are no developers left do start yet another project. everyone is busy getting kde4.0 ready.
though i think a dedicated kde-based webbrowser with more plugin/extension support would rock. maybe for kde 4.2 =).
That's what KHTML already is. I assume the Unity project (which is porting changes in from WebKit) would produce a KPart for Konqueror and whoever else needs it.
khtml is no webbrowser. you can't use it without konqueror as an application.
It's available as a KPart, though. You can build a functional web-browser around it with the bare minimum of effort.
developing a _good_ webbrowser is no bare minimum effort. even when getting the content and displaying it is allready done for you...
Why should it be a great deal? Just create an application with the absolut minimal necessary of features, add a extension-interface (via kross) and let the community create the rest, and let the user decide what bookmark-system they want, if there need a wallet, and so on... In the end, 2-3 years later, the kde-project can bundle the most useful extensions and add them to the default-installation.
Or something like that...
yeah! that will get us a completely unusable mess! why didn't i think of that before?!
usability is very important for a webbrowser. you can't just "attach" every feature somehow to the app. currently kde doesn't even have a real tdi-widget. a tabbed webbrowser without drag'n'drop hardly qualifies for the attribute good...
Gossip. Firefox proofs that it's possible.
nice try ;).
ever looked at the firefox code? if you call that "bare minimum effort", than i finally understand Anons post. though someone of us should look that up in a dictionary :P.
also, firefox doesn't bundle any extensions (well, the javascript debugger is one, but...). they simple reimplement cool features of extensions.
You miss the important points. What Firefox has in there code, is unimportant. Firefox' extensions are mostly working, despite the unholy plattform. So, why should an clean environment, which brings the most features for free, be inferior ? And at least, there is already an KDE-Browser, which must only charged up, and lose some functions.
ac is correct. KHTML is a great renderer, and obviously good for a real browser, but a renderer/page retriever is pretty much all it is. It can almost certainly render forms, but until you add code to make KHTML do it, there are no forms. There's no history, no bookmarks, no drag and drop, no loading images or movies using other KParts, etc. For real utility in apps, we could use a much higherlevel KonqiPart, not just KHTML.
History = Strigi + cached page URLs, bookmarks = technorati et al, drag n drop is only needed for the Dolphin kpart, image and form rendering needs adding, and launching other kparts when needed shouldn't that hard using plasmoid concepts. Carving out a KonqiPart, from what's available now and for where a "WebUI" wrapper concept could lead, shouldn't be all that hard in general. The sort of KonquerorNG functionality I would like to see is something like a RMB menu edit option on any image in a web page and it's instantly inside a Krita kpart (if such a thing exists, just an example) ready to edit and auto upload the changed image (if appropriate) etc. This WebUI interface could perhaps wrap around and manage *anything* that one would want to do on the net and, to me, rethinking Konqueror along these lines could eventually lead to much more powerful and usable interface than the kurrent Konqueror+Quanta.
The basic point is that a potential WebUI wrapper interface could make use of almost otherwise standalone parts rather than a single separate codebase... and, because there is no obvious Konqueror4 devel then it might be possible to end up with a WebUI wrapper instead, which could end up a lot more powerful than the current single codebase Konqueror ever could be... if the right framework is put in place right about now.
If i set "Statistics in Each Section" = 20 in "Number Of Entities Displayed" from Options panel, i can see:
Program Buzz
digiKam (kdegraphics) 1443
digiKam is not in kdegraphics, but in extragear...
Gilles Caulier
I'll fix it ;)
Danny
Is there any commandline tool to find out what windows are up and running and where?
It's quite sad to see kpf go away. It was a nice way to quickly make files available to friends. (Especially since I've often hat problems with kopete's filesharing abilities.)
Unmaintained and abandoned, there was no other choice possible.
Especially that is was a panel applet, thus it would had required some major effort in porting to the plasma API, not just some occasional porting.
I must suggest organizing by file types in KListView. So in the words used in video, we should have categories by file type as mp3, avi, etc... we could even expand this and also have by multimedia, office types, simple types... that would be great and very usable!
As to kopete, I really hope they could make a switch to enable/disable video capture as I don't use it right now because when I'm watching TV, kopete messes my signal!
http://dot.kde.org/1181568739/1181571377/1181580671/1181591195/
:)
I really do hope that efforts are being put into the window manager. I really want tabbed window managing and other features in ion3 for Kwin.
Also notice how Vista has sorting by selection on it's column header in a detail file list view. For example you can mask using the the file type header. Select a few file types and the rest of the file formats are masked out of the view. That sorta stuff is the quirks I really want in Dolphin.
KDE 3 is already there; I'm not nearly as interested in the new technology (although I am; particularly Solid and Phonon) as I am in the intricate details and polishing of KDE 4.
That reminds me of a question; will Phonon have intelligence to fade out amarok or any music program when say a system notification is played (or vice versa)? Say if I switch between VOIP and the music player will their relative volumes adjust accordingly.