At Ars Technica, I have put together an article detailing my impressions of KDE 4 Beta 2 (more or less, my source checkout is from within 24 hours of beta 2 being tagged last week). An official beta 2 announcement should be arriving shortly as the distros have been packaging it this last week. I am happy to say that beta 2 has made significant progress since beta 1.
i like them too :-) keep up the good work
I prefer the old oxygen folder. That was great.
Except for the folder, the oxygen icons are great and a huge improvements for kde4.
Except the folder icons, i think the oxygen-icons are stunning.
Congratulations for your good work!
In smaller sizes the folder-icons get a little bit "blurry" and you cannot identify them as folders anymore.
I think the icon needs to look more like a real folder with a better sharpness of edges to give the eye a better chance to resolve it easiely.
Furthermore their bright blue color is too obtrusive. A more unobtrusive blue color woud be important, because the folder icons reign with their extrem colors the whole desktop.
I have a similar opinion. I like subdued colors and while the rest of Oxygen is beautiful, that blue folder icon is still borderline too bright for me. (Several years ago, before the presence of Baghira widgets+borders and OS-L icons and the allure of KIO and KParts drew me back, the fact that KDE hurt my eyes was enough to drive me to GNOME and then to Xfce once I discovered it.)
Oh well, not too difficult to pull it up in an editor and adjust the color a bit. At least it's not a glossy mess.
Now all I need is a window border theme which doesn't play "guess where the border ends" and a widget theme that'll return the widget borders that the one in the screenshots stole/hid/erased.
Of course, for all I know, I may not mind so much once I actually get a chance to test it out. Unlikely though.
Please everyone stop just a moment and look to XP folder icons. Do you think, a part from the colour, that this rapresent a paper folder?
But we are used to them, we identify them with "folders" so we think they are "natural".
Honestly, Oxy's folders are probably a little worse than that (too gloosy, as Morty said) but once you get used to them, it's not that bad.
Hey David, I didn't see the last folder revision, remove everything I said about "too blurry", it's really cool!
Che figata! :)
I saw the new folder icon for the first time with this screenshot http://www.rw-designer.com/res/vista-folder-32.png
In beta1 which I was testing there ware old icons for folders.
I really like new icon. It's much better :)
;/, wrong link, http://arstechnica.com/journals/linux.media/kde4-beta2-programs.png
this one is correct. Folders are nice
new white style is really very nice, especially smooth curves, but i completly agree with man who posted before me, that there is too much waste of space. E.g. screenshot with KWrite dialog, space between buttons and text forms at the bottom of the dialog is really too big. But I think that this will be configurable in some way, or i hope so at least.
it's actually not the whitespace, but the alignment of various elements in that dialog that aren't correct. whitespace is a very useful and important design element, and not to blame for your (understandable) reaction to that dialog.
Either way, it seems like the buttons and toolbar are stealing a good deal of the screen real-estate. If you're juggling multiple windows, or just want as much of your document/data in view as possible, I like to keep buttons and toolbars pretty tight. I imagine it can be changed out with a style, so I'm not sweating it too much, but I think it is the biggest drawback from the default appearance.
UI did a fast mockup, compare okular spacings: (yes it's a bad drawning)
http://protomank.googlepages.com/kde4-beta2-programs.png (new spacing in some parts)
BTW, I think that maybe the problem has to do with artists using good and big LCD screens?
You know, my old 15" CRT dosen't like wasted space, and I belive my girlfriend with hers 14" also dosen't :)
Will the team release also beta2 version of kde-four-live?
Isn't it possible to provide nightly builds?
It would look a lot better if there was no space between the green scrollbar and the content window to its left (in this case, the content window shows the Ars Technica homepage):
Here's how it should look:
In the above example, the Mac OS X application's blue scrollbar actually _touches_ the list of email subjects to its left (ie. the orange highlighting).
I would also suggest to our Oxygen artists and coders that there be _no space_ to the right of the scrollbar either. So if the right side of the window touches the right-most edge of the desktop, the scrollbar itself should be the right-most thing on the screen. This again is shown on the Mac OS X screenshot.
I totally agree.
Apple is doing a great job in getting most out of the screen you have.
The weird thing is that I think in that screenshot he is using KDE 3 and building KDE 4. However on principle, I think the design needs to be tightened up quite a bit with regards to white-space.
I must admit that I do agree here - I always find it a way frustrating if there is space between the scroll bar and the right border because I sometimes click&drag the border instead of the scroll bar :/
As you have said, placing borders everywhere isn't only a visual, but also usability problem.
I must say I really like the way the scrollbars look in Oxygen. They could just ensure the widget reacts on the whole width and keep the look...
You say about the kdelibs: "These libraries include many of the main KDE widgets,".
I was under the impression that all GUI stuff was moved off the kdelibs and into kdebase, so kdelibs can actually be built without linking to QtGui.
Also, I agree that the current Oxygen style isn't really good, but remember that other widget styles are available, after all, this is kde =)
kdelibs is a module in SVN, sometimes resulting in one binary package.
It contains several libraries, including libkdeui, which contains GUI.
You were probably thinking about libkdecore, which is also part of kdelibs
Kwrite is a general-purpose text editor, not a source code editor (that's kate). It is very rare that you have to change the encoding of a text file. Most users have no idea what's the difference between UTF-8 vs ASCII vs who knows what. And even if they do need to change the encoding to support some special character in their language, it would probably have to be done only once, in the configuration dialog and _not_ in the Save As dialog. Once the change has been made it should remain in place until changed later by the user.
One could argue that it is up to the distro installer to choose the right encoding based on what language the user specifies during installation.
In any case, the file encoding type has no place in the Save As dialog.
It's very often that I have to change the encoding in the menu, and be able to specify encoding for document opening and saving. Not every one in the world uses English only - the option is very needed and should be left in the dialog.
> Not every one in the world uses English only - the option is very needed and should be left in the dialog.
Excuse me? That's exactly why we have UTF-8 (and not ASCII, etc.) So it supports just about any language.
And I think there are good reasons for insisting that UTF-8 is used. Would you prefer to choose between CP-1251, KOI8-R, KOI8-U, etc. just to use Cyrillic alphabet? Oh, and what would you do if you needed to use some non-Cyrillic and non-English letter - in someone's name, etc.?
There are cases where you have to deal with old encodings. That's where you need to choose. Obviously we all would prefer UTF-8, but sometimes we can't use it for some reason.
A project I was involved in used Windows-1250 (not Latin-2 for the reason that at least we get proper quotation marks -- this part was in fact the result of me pushing for it), and I had no luck at the time (around 2002-2003, the web was already ready for UTF-8 and that's all we needed) to get the project to use Unicode.
I on the other hand am very glad it is there. I have had to work with some files from other sources in all kinds of encodings, and I was very happy to be able to just Save As them in UTF-8.
> I have had to work with some files from other sources in all
> kinds of encodings, and I was very happy to be able to just
> Save As them in UTF-8.
Well then why not encode all files in UTF-8 and forget about this setting?
Probably more meant like "very happy to be able to just Save As them in UTF-8, or whatever else was needed".
I too am for this option -- but yes, definitely keep it off kwrite, the average user probably doesn't need it; kate on the other hand might benefit of it. I do very appreciate being able to choose (or at the very least see) the files encoding at saving, and I always rely on it on Windows in EditPlus for example.
> Well then why not encode all files in UTF-8 and forget about this setting?
Because not every tool in the world can handle that. If you need to share your data, you can't always insist on a single file format, even if you'd want that.
I also think that ASCII/UTF-8 is very geeky. Most people don't even know what it means. Why not just set UTF-8 as the default encoding everywhere, and have a config option for default.
KWrite is the general text editor. For those who need advanced features of all sorts can have a specialized editor.
try Russian sometimes - we have 4 different encodings. This may change your prospective whether this feature is "geeky" or something you can't survive without. My only complain is it not prominent enough - the combobox just says "UTF-8", it also should have a label "Encoding" with proper keyboard shortcut. KDE5 perhaps?
OK, so if languages with non-Latin alphabets use this option extensively, then leave it in. But I agree with Sergey: at least give the dropdown menu an understandable label, and not just the cryptic UTF-8.
It's not just non-Latin alphabets but rather non-Latin-1 languages. If you use English exclusively, you don't need to care. For Latin-1 languages with diacritics you only need UTF and 8-bit. For Latin-2, you can definitely save all your files in UTF-8, but you absolutely need at least three encodings if you want to be able to exchange text files with others: UTF-8, ISO-8859-2 and WIN-1250. And you can still come across legacy encodings such as CP852 (DOS), MacOS CE, KEYBCS2, KOI-8, UCS-2 ...
Just because average users somewhere never heard about encodings should mean that average users elsewhere should be forced to manually convert most of the files they send or receive with iconv?
It's good that you insist on having and improving this option, I like that. :-)
But does it belong in the save dialog? Why isn't it something that is a (guessed, I think Strigi was said to be able to do that) property of the document once loaded, that can be changed?
I think it was done like that in Emacs.
I don't generally support removing options because end-users are too stupid to understand what they are. That is the primary thing that turns me off in regards to Gnome design. I think the option to select text-encoding should exist within the application, however I'm not sure it needs to be in the "file save" dialog, which I'm assuming is going to be fairly universal in KDE. If it needs to be in the dialog, so each application designer doesn't need to place it elsewhere in the app, then simply tone down the size of that option. If it is smaller, it isn't as likely to confuse or attract people who shouldn't change it, while not removing it completely.
I think it'd only make sense in text editors' save file dialogs -- it should be completely hidden in every other case, including saving anything from Konqueror (who wants to transcode a file when they save it off the web? probably a very small minority who can live just fine with iconv anyway). So I guess it could be an option for the programmer, available inside the API (a simple flag for the save dialog), and a sensible programmer will offer it to its users (or get told to offer it, ehehehhe).
right now this option is present only in text editors - you don't have it in file dialogs of image editors, for example. This feature is very useful, imo. Perhaps, the combobox should be next to the filter combobox, and have a label.
Kwrite is a general-purpose text editor, not a source code editor (that's kate).
Where did you get this? KWrite is SDI and Kate is MDI, but they are pretty much the same in every other aspect.
In any case, the file encoding type has no place in the Save As dialog.
That's your opinion (and I'm guessing you never had to deal with multiple encoding environments). I think encoding has an important place in a general-purpose text editor save dialog and other applications "agree" with me: gEdit and EditPlus (on Windows) have that option... heck, even Notepad has it.
In my not so humble opinion, this is rather official stuff:
KWrite is a simple text editor application, allowing you to edit one file at the time per window.
KWrite is using the KTextEditor interface to let users decide which editor component they want to use. The default text editor component in KDE is the KatePart.
KWrite simply provides the selected editor compoenent with a window frame, and lets you open and save documents. Being a KDE application, KWrite is network transperant you can open files via any protocol supported by your system.
If you use the default KatePart component, KWrite shares all features the KatePart provides, look here to get some overview.
So more or less Kwrite is indeed a single window shell for KatePart, like Kate is one for multiple windows. But projects, etc. cater to developers methinks, not?!
"Automatically select filename extensions"-- this should be a general setting and not displayed. the most important thing is to have a huge main window with all the files.
That just sounds to me like you have nothing to complain, so you're complaining about things which everyone has agreed on for years. What people agreed on for years, can not be that bad.
My very first reaction when seeing that dialog was the opposite; "Yes! That's the way the encoding option should be presented! I'm so glad it is there!"
Then again, I might be a geek. On the other hand, and this is not an attack on the parent poster, I seem to have noticed that, often, suggestions that involve the phrase "most users", are perhaps not as well thought through as they could be?
Full ACK. "Most users" is a myth. My mom wouldnt even notice nor think about an option she doesnt understand. She doesnt understand about 90% of all options, buttons, menus. Nevermind. She opens a file. Writes something. Prints. Closes it. That's all. You could put the whole screen with UTF-8, ASCII, whatever drop-down boxes. She wouldnt even care. That's why it is so exceptionally stupid to remove options for "most users" like Gnome does. This alleged user group doesnt even exist! BTW: I bet a proposal to remove that option can only come from someone who speaks English natively. It's the same people we can thank for having sth. like ASCII, 7-bit-Mails, Win-1252 in the first place. Absolutely beyond their understanding is that someone actually speaks two or more different languages and has to work with files encoded differently every day, in Cyrillic and German for instance. Google now gives different results when querying in German or English BTW. If you understand both languages (like most non-English-speaking-people do at least to some degree) you must now query 2 pages to get all relevant results. Grrrrr.
Well, on one hand, I can see why the Gnomes are trying to clean up the interface. And to a certain extend, I think it really does make a difference. But I think it hurts far more to have a feature NOT there when a user needs it, than to have a feature there and ppl don't need it.
Agree 100%, not just because it makes sense, but also because I see the same thing from my family. If they don't understand something they leave it.
Go to Google (English)/Preferences/Search language
Select the languages you want.
why not add to the preferences dialog the option (as a checkbox) to display the encoding options?
something like this:
* Display character encoding options in the Save As dialog
by default, this would be disabled, cause most users don't need it. those who do need it have the option to turn it on permanently.
add a drop-down menu after that that says:
Default character encoding: <>
the <> mark means a drop-down menu. by default, the default encoding is utf-8.
you could also have
* Remember the last used encoding throughout session
this means that if you change the encoding, it stays the default till the end of the session, making it easier to work with a large number of files that use an exceptional encoding without changing the default. of course, at the end of the session you go back to the "real" default, that is defined in the drop-down list above.
I'm not familiar with KWrite, so I don't know how suitable what I wrote is.
I really hope that this confusing and ugly "all white", mixing Toolbar, menu and title bar is just a work in progress, not the final design.