KOrganizer: Website Update and New Features

The KOrganizer website has a new section covering information about sharing and exchanging iCal calendars. First, we have an overview of calendar sites, websites offering calendars in iCal format. These sites have a huge offering of downloadable iCal calendars covering arts, culture, economics, finance, government, science, sports and many more. The second page offers the so called hot new stuff calendars that are available via the new 'Get Hot New Stuff' feature in KOrganizer. Users of KOrganizer can import these calendars from the 'Help' menu in KOrganizer but we also offer these calendars for download in iCal format. If you feel that something is missing in this new section, feel free to contact Cornelius Schumacher or Klaus Stärk. You're also very welcome to provide us with more iCal calendars to put up on the KOrganizer webserver.

Dot Categories: 

Comments

by Maarten (not verified)

The hot new stuff idea is really nice :-)

by Sinuhe (not verified)

If only the name was different! The word stuff should only be used in very informal writing, which a computer programme is not. Would it not make sense for it to be changed to something more dignified?

by Anonymous George (not verified)

IMHO the name is not appropriate. What is the hot new stuff? Drugs? Warez? MP3?

I certainly do not expect a calendar, even in KOrganizer...

by Charles de Miramon (not verified)

I also would like a new name for this functionality. We had a lot of problem in the French translation team to find an adequate translation for 'hot new stuff'. Colloquial English should be, by all means, avoided in KDE messages because it is unclear for the end user and difficult to translate.

Something like 'find new calendars / screensavers / etc...' would be better

Cheers,
Charles

by Fab (not verified)

You are right ... sometimes developers tend to forget that some "stuff" needs to be translated as well ...

grtz'

Fab

by allen (not verified)

Don't get me wrong, I love the hot stuff idea. Just a few mostly
minor nits:

+ How come if I click on the hot stuff .ics calendars at http://korganizer.kde.org/calendars/hotstuff.html
with konquerer I'm asked if I want to open the calendar
with kwrite instead of korganizer?
However, clicking on a .ics on icalshare asks to
open with korganizer as expected?

+ I'm not sure the Help menu is the best place
for the Get and Load Hot New stuff functions.
Maybe move to Tools menu and rename to
Get/Load Public Calendars?

+ The Get Hot Stuff dialog has an OK and Apply button. Why?

+ Once I select a Hot Stuff calendar I am presented with a list
of all the events. That's a nice feature. But, why am I permitted
to click/highlight each event? I expect to be able to do something
once I highlight the event but I can't see what that would be.

+ I don't always want to merge the new calendar into my current calendar.
Can a new calendar be created for me?

I'm using KDE 3.1.2, btw. Thanks for the great work!

by MIME-Typer (not verified)

Probably MIME type settings on the web server

by uga (not verified)

> I'm not sure the Help menu is the best place
> for the Get and Load Hot New stuff functions.

I agree completely with this. So long time using korganizer, and I didn't see the function until right today when I read this news.

It's plain stupid to put something that is not "Help" related under "Help"

by cloose (not verified)

I also partly agree with the comment. I'm a long time KDE user and haven't found this nice funtionality until now, because I never looked in the help menu (its very rare that I need the help system).

But I don't think that you can win the hearts of the developers by calling something plain stupid. This puts the developer in a defensiv position and will always make it less likely that he listens to your opinion.

Christian

by uga (not verified)

> But I don't think you can win the hearts of the developers by calling something
> plain stupid.

You're right, and I'm very sorry about that. I didn't mean to offend anyone. I just didn't find the correct words to express myself. It's just that whenever I do similar things (which I _have_ done), I call them plain stupid the same way ;)
Sorry again... I think I need to improve my social and english language skills :-P

Actually I've followed some parts of the work of the kdepim developers, and I can really say that the way they usually work is quite smart.

If I really did offend any of you developers, please accept my apologizes.

Unai

taken from the korganizer paragraph of the kde3.2 feature plan
(http://developer.kde.org/development-versions/kde-3.2-features.html):

o pinning of any mime type to an appointment or todo mark

This by far one of the most desired features by me. I'm glad it's in the feature plan. Does anybody know, if work on this is going on already?

by Guenter Schwann (not verified)

This is on the featurelist at least since KDE 3.0. I don't think it will be implemented any soon - sorry.

ciao

I don't quite get this, unless it's unrelated to the server mimetypes being discussed earlier. What would it do?

Basically it means, you'd be able to attach a file (or a link/url to a file) to an appointment. Imagine a situation like this: You're working on several projects and you're using korganizer to keep on schedule with different tasks.

It would be nice, if korganizer reminds you of a certain deadline in advance _and_ presents you e.g. the not yet finished kpresenter-Document as an icon.

This way it is possible to start work on the file again with just one click and without the pain searching it on your local HD...

by Eron Lloyd (not verified)

This would basically extend the concept of virtual folders to all of KDE. Outlook also provides this function; in fact, you can use Outlook as a file manager (and many people do) and present different views of the user's files than a flat filesystem representation. If you have an event where you are doing a presentation, when adding an event to KOrganizer, you could "attach" a directory containing your KOffice files, and possibly annotate them to know if each is complete or still needs work. There are many possibilities here. Are vFolders in the works?

Regards,

Eron

by rjw (not verified)

can we stack calendars, eg a personal calendar, a workgroup, a uk public holidays, an evening class timetable, a travel itinerary from a travel agent, and an exercise schedule provided by another program ( maybe via DCOP)?

Importing is pretty bad compared to dynamic composition of calendars.

by Guenter Schwann (not verified)

This already is possible with current CVS :-) Not perfect yet, but there is some time left until KDE 3.2 final...

ciao

by Anonymous (not verified)

Is it possible to update calendar entries obtained via "Get Hot New Stuff", e.g. if an updated KDE 3.2 release plan is imported will old obsolete entries be deleted? Possible implementation: cache all imported calendars and diff against the newer version.

by pleb (not verified)

But why are the buttons not created with the same width for each button in the following image?
http://korganizer.kde.org/images/screenshots/hotstuff_get02.png

(sigh, and KDE people keep saying that GNOME is inconsistent.. (not meant as a flame))

by Datschge (not verified)

Why should they? The texts for each button are of different lenghts so as a result the buttons having different widths is just consequential, isn't it?

Even if you would like them to be of the same width, what width should that be? And which buttons should comply to that additional rule instead to the current one, and why?

by Eron Lloyd (not verified)

Actually, stuff like this should be covered in the KDE HIG. Sizes and spacing should be specified down to the pixel.

Eron

by Datschge (not verified)

It is: be exactly as wide as necessary for the content to fit in. Nothing more and nothing less.

Please give an explanation for why you think this doesn't do the job and what rules you want to set up instead to ensure that the result is "great" to "alright" in all possible cases.

by Eron Lloyd (not verified)

I should have been more clear. Sizes and spacing layout wise is what I meant. And yes, there are some UI properties that should have a recommended value in the HIG. For example, a QButton has properties for height and margin. What should the recommended values be? Qt Designer can make objects a bit "boxy" by default. In this case pixel-specific recommendations (note recommendation, not rule) could be provided. As far as layout, GNOME and Apple both specify pixel-level spacing recommendations:

developer.apple.com/documentation/UserExperience/Conceptual/AquaHIGuidelines/AHIGLayout/
http://developer.gnome.org/projects/gup/hig/1.0/windows.html#alert-spacing

Of course there has to be accomodizations for language localization and accessibility adjustments...

Cheers,

Eron

by Datschge (not verified)

While I agree that layouts should be standardized I don't think hardcoding some pixel values like it seems to be suggested by both Apple's and Gnome's HIG is really future-proof at all. Layouts should be ideally completely independent from the used screen resolution, instead they should only define some classes for different UI elements/purposes and then let an (exchangeable) style visualize them in KDE wide consistent pixel values. While the current model used in KDE is not that flexible (yet?) many UI elements are already standardized KDE wide on the library level.

by SadEagle (not verified)

We kind of do that already with layouts, see KDialog::spacingHint and KDialog::marginHint;
Ian Geiser recently converted many of .ui files to use those properly; so now it's
possible to change layout spacing in one spot.

by Datschge (not verified)

Thanks for reminding me of that. I guess we need an own HIG just for the sake of documenting these kinds of features. ;)

by Eron Lloyd (not verified)

Is anything truly future-proof? ;-) While perhaps in an ideal world layout would be independant from resolution, but what would you use to specify sizes and spacing--percentages? Of course kdelibs takes care of some of this, but there are many things the developer has to be aware of, too.

by Datschge (not verified)

It strikes me as very odd that in times where pixel artwork for icons is becoming deprecated and to be replaced with vector based artwork which can display fine in all resolutions, that the same systems are even supporting manually hardcoding anything pixel based as part of a HIG. To me this only seem to introduce twice useless work, first manually adding all those pixels everywhere and the removing them all again as soon as it will be obvious that hardcoded pixel values can only break a layout's flexibility to adapt to different resolutions.

As for the "many things the developer has to be aware of, too" be sure to make a list of all you can find, so not every single person need to get that idea themselves after some time (yes, I suggest to request additional features in kdelibs in case there's indeed something seriously missing so far).

by uga (not verified)

>Sizes and spacing should be specified down to the pixel.

You can't specify something like button sizes. The required text sizes in the buttons differ a lot from one language to another one and you also need to take into account the font sizes.

Take for example: "Help" in english takes 24px on my screen, so we could set Help buttons to be 30-35 pixels wide. Right? Now go for the Basque translation: "Laguntza". It's 50px wide. It doesn't fit in. That's why it's better to adjust the sizes of the buttons according to the text they contain.

by anon (not verified)

The bigger it is, the more important it is or seems in the UI. It doesn't make sense for something to be more important just because it takes more letters to spell it.

by Datschge (not verified)

Erm, excuse me but when the use of something makes only sense through the letters used in/on it then you just can't rip away them for the sake of keeping all somethings' sizes relatively reflecting their importance. And besides, who decides what's important and what's not?

I guess we better force everyone to learn Chinese where pretty much all text is neutral size wise so we can tweak all the "importance sizing" manually and present everyone the "one and only perfect UI". Other than that I don't see any sane way how this kind of "wishes" can be fulfiled without causing a lot of additional work for everyone with nearly zero benefit at the end.

by pleb (not verified)

They should be because it just looks better, more consistent and more polished.
(KDE isn't just a toy desktop anymore, right?)

ie. GNOME uses button boxes to make sure other buttons are the same width as the button with the largest width.

Now, please compare the following 2 images:

http://korganizer.kde.org/images/screenshots/hotstuff_get02.png
http://gthumb.sourceforge.net/gthumb_1.106_shot3.jpg

Look at the Prev, Next & Close buttons in the latter screenshot (the property dialog).. doesn't that look more consistent to you?

(I'm not talking about themes and toolkits here so please leave that discussion out of here, just in case someone starts blabbing about that)

Oh, and Windows doesn't do it the KDE-way either.. (buttons are as wide as the largest one)

Not sure about how OS X solves the issue.

by Anonymous George (not verified)

Windows does that for technical reasons: they use fixed positioning for everything. You can not do i18n without having extra space...

by Philipp (not verified)

How would you do this with different languages? What if "Cancel" is 3 or 4 times the size of ok and apply in a different language?
Wouldn't this waste space? Wouldn't it look even more ugly then?
I fully agree here, that the buttons are only as wide as the content.

Philipp

by Anonymous George (not verified)

KOrganizer has many promising features, but I think it lacks polishment.

For examples colors, the first thing that you see when you start the app. Compare the following:
http://korganizer.kde.org/images/screenshots/mainshot_big.png
http://www.apple.com/ical/images/index_top12312002.jpg

Or look at the "Get hot new stuff" feature (i try to avoid complaining about the name a second time, but it is hard not to :). The dialog looks pretty lost, like a prototype of a dialog that has not been finished. Or the strange Edit Calendar Filters dialog with that raised frame that I don't understand. Or the 'Publish Free Busy Information' function, which shows a address selector that seems to be completely unrelated to the menu name. No instructions or anything that could tell the user what to do. I could probably go on like that for at least 50% of KOrganizers UI. The most important elements, like creating a new event, is good though. And I also like the date selection.

by Guenter Schwann (not verified)

If you have a nice set of coulors, than let the developers know (kdepim-mailinglist).
For the rest of your suggestions it's the same. Maybe you just create a list of stuff that is wired (in your oppinion) in korganizer's UI, send it to the mailing list, and the developers can try to fix it. Maybe you also add sugestions for solutions of the "broken" stuff (or even some code?).

ciao

by Anonymous George (not verified)

Unfortunately with UI design it is like with literature. I can recognice that I book is bad, but that does not mean that I can write a better book.

by Guenter Schwann (not verified)

So you can at least sum up some UI problems and report then. This would help the developers a lot already.
ciao

by Mathieu Kooiman (not verified)

There is someone on KDE-LOOK who has proposed better looks for Korganizer. I'll paste the link below. I've searched on kdepim archives but haven't been able to find any message refferring to this.

And let's face it. It really does look horrible atm.

http://www.kdelook.org/content/show.php?content=6361

by tuxo (not verified)

I agree with you! The iCal (Apple) shown in your second link is much less cluttered, more accessible and more beautiful than KOrganizer.

Why not learn from Apple instead of reinventing the wheel? It's not about copying exactly the look and feel of Apple applications, but learn from them, what they have done right and improve KOrganizer by adjusting its current interface.

by Datschge (not verified)

> Why not learn from Apple instead of reinventing the wheel?

Because KOrganizer was already there for many years when iCal was introduced perhaps? Because people didn't care until they found something else they can brown-nose with generic stuff like "much less cluttered, more accessible and more beautiful"?

Please contribute your improved color scheme, better wording and suggestions for layout tweaks instead playing to someone else's writing without adding something yourself. Thank you.

by Eron Lloyd (not verified)

One thing that I would like to see is the modification of the calendar views to more closely follow Outlook/Evolution, especially the full-week view. I'm working on a usability report for KOrganizer now, so these issues will be addressed. I think there are many things that KOrganizer can learn from it's predecessors (Outlook, Notes, etc.). Lots of people will just be needed to contribute to make it happen.

Eron

by tuxo (not verified)

> Because KOrganizer was already there for many years when iCal was introduced perhaps?
Ok, but this doesn't mean that there are things that can be learned from a newcomer.

> Because people didn't care until they found something else they can brown-nose with generic stuff like "much less cluttered, more accessible and more beautiful"?
I never really liked the interface of KOrganizer, didn't really know why. My post was not an attempt at brown-nosing as you prefer to refer to it. When I saw iCals screenshot I was simply amazed, thus my words were chosen a bit too generic, I agree. Will list some points that disturb me with the current implementation of KOrganizer further below.

> Please contribute your improved color scheme, better wording and suggestions for layout tweaks instead playing to someone else's writing without adding something yourself. Thank you.
Ok, here are a few suggestions:

Layout:
- Interface clutter: Organization of the icons on the toolbar. Apples toolbar icons are clusterd together according to their function and placed where they are most relevant. This however is probably more a problem with the generic KDE interface guidelines.

- iCal calender on the side shows not only the current month but also the next one. This is very handy as one often has events comming up in a time-frame of a month. It's nice to be able to look ahead. This is the reason also why analog clock interfaces are still popular, you can actually see how much time is in front of you.

- It is a great idea to be able to switch quickly between different calenders: iCal allows this directly via the side panel.

- Search function to search for meetings according to keywords. The search field is provided conveniently on the bottom of the application, see the screeshot of iCal.

Design:
- Current event entries appear with frames that are too blocky, compare e.g. the rounded edges iCal provides.

- I very much like the colors attibuted to the different event entries in the iCal screenshot. The default color(s) of KOrganizer are pretty boring in comparison.

- Event entries have a title bar section that indicates the time. This is useful with many entries in order to immediately grasp when exactly a given event starts.

- The color of the default toolbar icons (Go to today, New event etc), don't fit with Crystall icons. Especially the shade of blue is wrong when compared to the blue color used in other Crystall icons (e.g. the home icon).

- The system tray icon of KOrganizer is outdated, it doesn't fit in well with the default crystall icons (e.g. too sharp edges).

by Eron Lloyd (not verified)

Please send those ideas about 50% of KOrganizer's UI to me ([email protected]), and I will try to include them in my report. You don't have to be a coder to contribute.

Eron

by MandrakeUser (not verified)

I merged the KDE release 3.2 release schedule in my calendar, and I have a little suggestion. Instead of "Alpha 1 release", I would rather write "KDE 3.2 Alpha 1 release", and so on. These public calendars should have descriptive summaries for the events IMHO.

And I agree with the suggestions about the menu location (I discovered this feature in this article, not in the menues) and the feature title. OF course these are humble suggestions, not complains.

Thanks for the great work, please keep going!

Please excuse me for my OT question.

I have recently compiled KDE 3.1.2, and was excited to see the capabilities of KDE. However, there was a wish for Konqueror (the file manager) and the way XIM input was handled.

From what I have been reading on the Dot, it seems as if most people enjoy the single-click to navigate. However, I tend to prefer to double-click on files/directories based on my habit from Windows and Macs.

In the double-click mode, a single-click will highlight the name of the file/directory in Konqueror (FM). When the text is hi-lighted, the hi-light color starts almost exactly on the pixel of the first character (left side for English/Japanese), but the right side has a space worth almost an entire character.

I know this sounds confusing, and if I could be told how I could ask for this to be changed (although it may not be acceptable) like the way Nautilus hi-lghts file/directory names (i.e., equal spacing on both the left and the right margin(?), I would include a screenshot of what I'm trying to explain.

Thank you in advance.

by Guenter Schwann (not verified)

KControl->Peripherals->Mouse->"Icons->Double-click to open files and folders"
I guess that's exactly what you are searching for :-)
Featurerequests and bugs can be reported via http://bugs.kde.org
ciao

Thanks for your reply.

I guess my explanation was just not clear enough.
I'll try again.

I have my setup as exactly how you have instructed me; however,
upon doing so and single-clicking on an icon in the Konqueror the
file manager, the filename/directory name will be hi-lighted.

This hi-lighted color surrounds the name.
On the left side of the hi-light, the hi-lighting color start at the
first character of the name.

On the right side of the hi-light, the hi-lighting color end about a
character space away from the last character of the name.

i.e. something like this...
filename: blah.sh

----------
|blah.sh |
----------

and I was wondering if it's possible to change this to:

-----------
| blah.sh |
-----------
^
| This space is what I wished for.

I guess, with the dotted-line border of the hi-lighted color area,
it makes it difficult to read the first character of the name of
file/directory. Or is it because of the font I'm using?

Best Regards

The right way to make a feature request is to go to bugs.kde.org and create one. But I am not sure whether your request is possible without modifying Qt.

by sjk (not verified)

I'll go try to figure out how to do that on bugs.kde.org now.

Thanks for your replies!

Regards