Jump to content

Project Elegance/Calendar: Difference between revisions

From KDE Community Wiki
Alexmerry (talk | contribs)
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
{{Proposed_deletion|reason=this project seems dead, and didn't get a long way in the first place, by the looks of these pages}}
Calendar
Calendar



Latest revision as of 14:18, 9 March 2016

Proposed for Deletion

This page has been proposed for deletion for the following reason:

this project seems dead, and didn't get a long way in the first place, by the looks of these pages

Please use the discussion section of this page to voice your opinion on this.

Calendar

Problem Statement

What is our code /user interface/ providing This code provides a way to see events and orient in time and select dates. . This functionality diverges at ::level


Think of the problem you are trying to solve, and what interface and use scenarios are appropriate

Affected Modules

Where is this used


User Customization

How will you let users customize behavior

global options

Which options should be changed for all instances of this, regardless of program

per application options

when should a program manage an option, what should default behavior be, should an application turn something off, or turn it on.

per instance options

when should a developer be able to force specific behavior


Research

Dependencies

When adding features, can you do so without increasing dependancies? can you use a macro to turn off functionality if a dependancy is net met?


Case studies

Feature rich
Sparsity needed

Perhaps in the application that creates events, when editing the event itself, it would be useful to not see other events? Or it could be sufficient to have selected date stand out sufficiently from other events, and use existing events as referance when navigating calendar.

Locking
Problems may arise when editing two date events at a time.

Participants

give your WikiSignature and your application