Closed digitalethics closed 4 years ago
Thank you very much for your comment. answer each question point by point.
Planner was designed inspired by the basic design of elementary OS. But with each new update we've been going down a different way.
Window decoration is a bit difficult to implement automatically nowadays due to various technical issues. This is because Planner has a different and non-standardized design line (neither in elementary OS nor in GNOME) The two-window design is an obvious inspiration for applications in macOS. However, in the current version of Planner there is a configuration to solve this.
Currently there are a number of features that do not work properly if you use Planner from a distribution other than elementary OS. But this will be fixed when AppCenter for everyone is released. Planner will adopt flatpak as an official distribution package (which will be compatible with Flathub) and only that one package will need to be supported.
I think changing the name of the project will be difficult. Planner already has a large user base and this would be a radical change. You should also keep in mind that GNOME Planner has not been updated for many years. But if for some reason this happens what name would you give to the application?
I disagree with the first proposal: Planner is Planner, no need for a rename.
But I think there's a problem: I think this app would improve if it starts to support GTK themes apart of Elementary (i.e: Adwaita, Yaru, Arc...), at least the buttons, mainly the window buttons. Another option is to make different themes, apart of light/dark, this would be some work but it's a nice idea imho.
Tips: the app should look in an unique way, but still integrating with GTK themes, in coherence with the GTK theme in the desktop. Flatpak supports lots of themes so it wouldn't be a problem.
Anyways, nice app, the best for using it with Todoist in Linux :smile:
I disagree with the first proposal: Planner is Planner, no need for a rename.
I for one agree that a less generic name would be more helpful, e.g. for searching, and to reduce ambiguity amidst so many planner apps that are out there.
I've packaged this for NixOS and we actually call the package elementary-planner
because it is too ambiguous and could collide with other packages. Even then, it becomes ambiguous with default elementary apps, because we also have them named like elementary-calendar
etc. Other distros also do this.
But if for some reason this happens what name would you give to the application?
I would name it Taskpoint, Salvador or Matador.
I'm actually considering, could distro's just name the package after it's RDDN? (this is what RDDN is actually for)
Though for us in NixOS, we wouldn't be able to do that. (well, do it practically, since each period would denote another scope of attributes) In a general sense, I will admit these are rather difficult requests to make to any project.
I'm going to close this problem because Planner's name can't be changed.
Thank you for your continuous efforts to maintain and improve
planner
.It looks like
planner
is specifically targeting elementary OS. Does your current build allow for standard GNOME 3 Adapta window decorations? More importantly, would you consider making the app more distro-agnostic? This would significantly increase adoption by users from different operating systems, increase the testing surface of your software, and allow for additional funding possibilities beyond the elementary OS AppCenter release model. As long as the app is primarily developed for elementary OS and advertised as such, it most likely will not be eligible for inclusion into the repositories of several Linux-based operating systems, and hence, limit adoption of your software.The second blocker is its current name. There is an application
gnome-planner
which goes by the same name and developing your app under this name will cause confusion for end users as well as complicate naming conventions as can already be seen in Repology. Lastly, it is a disadvantage in developing a more unique branding for your software.Raising this issue is part of a wider effort in improving the quality of software projects.