Simplifying Korganizer

[Olivier Churlaud]

OK, I was expecting discussion and search for improving the situation.

But if without any other reason than "it is currently like this" no change is even thinkable, then let it stay the way it is.

I find it sad, but well, you're on charge.

Regards,
Olivier

Le 12 septembre 2017 08:14:58 GMT+02:00, laurent Montel <montel at kde.org> a écrit :
>Le mardi 12 septembre 2017, 07:54:24 CEST Olivier Churlaud a écrit :
>> Hi,
>> 
>> I thought about your answers and I think that the problem is that
>Korganizer
>> adds a level of complexity : Kontact aggregates several applications
>in
>> one. But Korganizer does the same. So if you want to use the journal
>(idem
>> for tasks) you can do: Kontact > Journal or Kontact > Korganizer >
>Journal.
>> 
>> I think the second path is not really relevant and quite complex.
>> 
>> What if we still used the same code for all apps (as it is now) and
>provide
>> 3 separate entry points (understand executable binaries) :
>Korganizer,
>> Tasks, Journal? Names can change of course.
>> 
>> This way a user would now what they are using and what the scope of
>the
>> program is. If a user wants to easily switch between them, Kontact's
>> purposes is exactly that.
>> 
>> What do you think?
>Hi,
>
>So people use korganizer as single apps. He doesn"t want to know 3
>differents 
>program name for it.
>For sure we will not split korganizer in 3 different apps.
>
>Regards
>
>> 
>> Cheers,
>> Olivier
>> 
>> Le 4 septembre 2017 05:49:32 GMT+02:00, "Daniel Vrátil"
><dvratil at kde.org> a 
>écrit :
>> >On Sunday, 3 September 2017 23:35:12 CEST Olivier Churlaud wrote:
>> >> Hello,
>> >> 
>> >> I would like to do a very bold proposition.
>> >> 
>> >> To give some context, Korganizer is the KDE application I use the
>> >
>> >most after
>> >
>> >> KMail. And even though, I have trouble to switch between the views
>> >
>> >that are
>> >
>> >> quite mixed :
>> >>  - Agenda
>> >>  - Month
>> >>  - Timeline
>> >>  - Tasks
>> >>  - Journal
>> >> 
>> >> Korganizer's strenght is in the event management : so I imagine a
>> >
>> >calendar,
>> >
>> >> with 3 views:
>> >>  - all the events in a list,
>> >>  - an agenda (with a focus on a month or a week or a day)
>> >>  - timelines (without focus, just endless lines that loads when
>> >
>> >shown, or
>> >
>> >> based on the 3 agenda focus).
>> >> 
>> >> First comment here : Month shall be a subset of agenda, which is
>> >
>> >currently
>> >
>> >> not the case, and I find it always strange.
>> >
>> >Agenda has some very special features that make no sense in month
>view
>> >- for
>> >example you can display the day's/week's agenda for each calendar
>next
>> >to each
>> >other, rather than mixed into a single view. This makes no sense in
>> >month
>> >view. So code-wise the separation makes sense. UI-wise, there can be
>> >improvements, e.g. just by having "Day", "Week", "Month" buttons in
>the
>> >
>> >toolbar.
>> >
>> >> Tasks: Now that Zanshin is mature, why do we need to have tasks in
>> >> Korganizer? Zanshin beeing well integrated in Kontact, I would
>remove
>> >
>> >that
>> >
>> >> from korganizer, making it easier to use.
>> >
>> >Zanshin can be a good alternative to Tasks, but it lacks lots of the
>> >funcionality and richness that KOrganizer has for tasks, as Zanshin
>is
>> >designed with certain workflow in mind. I'm fairly sure many people,
>> >especially
>> >in enterprise, would not like that.
>> >
>> >It would also requires Zanshin to become a KDE Applications (it's in
>> >Extragear) and start having regular releases, which is up to Kévin.
>> >
>> >> And what is Journal? I have no answer for this, but I think that a
>> >> specialized application integrated in Korganizer would anyway be
>> >
>> >better.
>> >
>> >Journal is like your diary - you can create journal logs for
>specific
>> >dates.
>> >Useful for meeting logs.
>> >
>> >Why do you think that a dedicated application would be better? UX/UI
>> >wise I'm
>> >pretty sure this could be fixed on KOrganizer level - like not
>showing
>> >event-
>> >only calendars in Journal etc.) Code-wise it would not help at all,
>> >since you
>> >would be recreating lots of the code that KOrganizer already has and
>> >shares
>> >between events, tasks and journals....we want less code to maintain,
>> >not more
>> >;)
>> >
>> >> This would drastically simplify the toolbar menu, and the
>Korganizer
>> >
>> >code.
>> >
>> >> In term of UX, currently it's hard to know in which view and which
>> >
>> >content
>> >
>> >> we are : events ? journal ? tasks ? are they the same content ?
>well
>> >
>> >if
>> >
>> >> not, being in the same window with the exact same menus is very
>> >
>> >strange for
>> >
>> >> users....
>> >
>> >On one hand, that's the beauty of it: a uniform UI for everything. I
>> >would
>> >hate it if I would have to toggle visible tasks differently than
>> >visible
>> >events just because they would be different applications...
>> >
>> >> What do you think ? If you think it is relevant and a good idea,
>I'm
>> >
>> >ok to
>> >
>> >> do a patch in this direction. But since it would be quite a
>> >
>> >destructive
>> >
>> >> patch, I think we must talk about this. And I'm open to discussion
>> >
>> >and
>> >
>> >> argumentation, if it is possible.
>> >
>> >I would prefer a constructive patch instead :-) Identify the actual
>> >issues and
>> >create solutions for them (e.g. "Remove 'Agenda' from toolbar",
>"Make
>> >'Day'
>> >and 'Week' actions enabled even if 'Month' is selected", etc.). I'm
>> >sure many
>> >of those issues can be fixed just by having a different KXmlUI rc
>file
>> >for
>> >standalone KOrganizer and for KParts....
>> >
>> >
>> >Dan
>> >
>> >> Cheers,
>> >> Olivier
>
>
>-- 
>Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software
>Engineer 
>KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84
>08 53, 
>www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts -
>Platform-independent 
>software solutions 

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170912/863350cc/attachment.html>