Verbesserungsvorschläge
91 results found
-
Broadcast /p // /m
Ab und zu möchte man allen Nutzern die gleiche Nachricht schicken. Einzige Alternative bisher in einer each Schleife alle Nutzer durchgehen.
Ich stelle es mir so vor, dass man über UserPersistenceNumbers.getAllUsers(key) alle Benutzer als Array angeben kann und diese dann als Parameter für sendPostMessage oder sendPrivateMessage mit angegeben werden können.
Hinzu wäre es gut, wenn man dann bei sendPrivateMessage nen flag setzen kann, dass die Leute nicht sehen wer alles privat angeschrieben wurde
0 votesAhoi,
wir sind der Meinung, dass beim Versand von Nachrichten sinnvoll darüber nachgedacht werden sollte, wer diese Nachricht erhalten möchte.
Versendet man Newsletter, so sollte man hier einen Opt-Out anbieten.
Insgesamt ist es so einfach diese Funktionalität via UserPersistenceNumbers zu bauen, dass wir diese Funktion in nächster Zeit nicht bedenken werden.
-
Bugfix: DataURI Support im Applet
ich benutze in meiner HTML-UI ein Canvas-Element auf dem ich mit Bild und Text rummale und das Ergebnis dann als Hintergrundbild von <div> elementen verwenden will. Dazu bietet das Canvas-Element auch eine Methode an.
Docs: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURLDas ganze funktioniert im HTMLChat auch wunderbar, im Applet funktioniert es allerdings nicht.
1 voteAhoi,
wir haben dieses Ticket abgelehnt, weil es sich nicht um eine Idee, sondern einen Bug-Request handelt und den Fehler in den Bugtracker eingetragen.
Knuddelige Grüße
Ironist -
Userinformationen auch im HTML-UI einsetzen können
Es wäre schön, wenn gewisse Funktionen auch über die HTML-UI einsetzbar wären. z.B. könnten dies Grundinformationen zu einem User sein (Nickname, Alter, Geschlecht, Verlinkungsmöglichkeit zum Profil (/w od. /m), Bildurl, etc.). Ich denke hierbei würde es reichen, wenn alle Informationen mitgesendet werden würden wie bei der QuickWhois.
Client.loadUser(userid);
1 voteAhoi,
wie Dennis bereits beschrieben hat, ist das Senden dieser Informationen sinnvoll vom Server aus möglich. Bitte nutze diesen Weg.
Knuddelige Grüße
Ironist -
User Abfragefunktionen
Folgende Funktionen wären nett:
lastOnline()
Fragt ab wann der Nutzer das letzte mal Online warisPermanentLocked()
Prüft ob ein Nick permanent gesperrt wurde (ist so oder so für jeden über das NRS einsehbar) - nützlich um Nicks aus z.B. einer Rangliste zu entfernen oder in der Persistenz komplett freizugeben1 voteAhoi,
wir lehnen diese Idee ab, da es sich um zwei Ideen in einem Vorschlag handelt. Bitte schlage die Ideen einzeln vor, sodass sie einzeln bewertet und ggf. realisiert werden können.
-
1 vote
Ahoi,
wir schlagen vor, dass du dir eine eigene Funktion schreibst, die du aufrufst und die zuerst das Event sendet und dann das Fenster schließt.
-
callback für Client.sendEvent()
wie bei $.ajax gewohnt wünsche ich mir, dass man Client.sendEvent() ein callback übergeben kann, dem das ergebnis aus App.onEventReceived übergeben wird sofern eines zurückkommt.
Beispiel:
Client.sendEvent(key, data, function(zufall) {
//Ergebniss ist number 0-9
});App.onEventReceived = function(user, dataKey, data) {
return RandomOperations.nextInt(10);
};function(result){
});
1 voteAhoi,
wir denken, dass dieser Fall ideal ist, um durch ein Framework abgebildet zu werden und schlagen vor, dass du das in euer KFramework integriert.
-
User.isInTeam(team, [subteam]) auch für unsichtbare Teammitgliedschaften
Die User.isInTeam(team, [subteam]) sollte auch für unsichtbare Teammitgliedschaften nutzbar sein (bspw verwenden mehrere Teams wie Events, Knuddels-Wiki oder Bugs unsichtbare Subteams für die Neuzugänge). Selbstverständlich sollte dies (bspw. über ein Teamrecht das man wie 'notignorable' setzt entweder gewhitelistet ('visibleforapps', alle anderen unsichtbaren Subteams verboten) oder alternativ geblacklistet ('hideforapps', alle anderen unsichtbaren Subteams standardmäßig erlaubt) werden um Zugriffe auf Subteams die wirklich intern sind zu untersagen.
1 voteAhoi,
wir glauben, dass die Zielgruppe für diese Funktionalität enorm gering ist und Teams, die solche Apps bauen auch in der Lage wären temporär diese Listen doppelt zu pflegen, sodass Aufwand und Funktionalität nicht im Verhältnis wären. Daher lehnen wir die Idee ab.
-
Apps an Teams binden
Es wäre cool, wenn man Apps nicht nur an Channel sondern auch an Teams binden kann. Das würde es ermöglichen dass sich die Teams Funktionen, die zwar hilfreich wären aber den Aufwand einer Umsetzung durch das Knuddelsteam nicht rechtfertigen können selbst umsetzen zu können. Diese Apps wären dann für die Teamler global nutzbar.
Im folgenden einige Anwendungsbeispiele:
AET: Durchsuchen der Band-Index-Liste via Chatfunktion
APT: Phishingseiten direkt über den Chat eintragen
Help 4 You: Interne FAQ durchsuchen
HZA: Datenbank auf der offiziellen Webseite verwalten, Channel ausschreiben [...]
Intekreafix / KM: Gewinner eintragen
Knuddels-Wiki / Forum: Nahezu komplette administraton via Chat
Spiele:…3 votesHallo Chris,
das ist eine interessante Idee. Wir können uns derzeit nicht vorstellen, dass wir sie mit rentablem Zeitaufwand realisieren könnten und lehnen sie daher ab.
-
3 votes
Hallo,
wir werden die Standard-Funktion von toString für keine nativen Javascript-Objekte verändern, da sich ggf. bestehender Code darauf verlässt.
Eine Formatter-Klasse kann sinnvoll sein, ist aber für die Core-API derzeit zu speziell, sodass wir diesen Wunsch in Gänze ablehnen.
-
KnuddelsServer.chatCommandExists(command);
Prüft ob ein chatCommand bereits durch eine andere App belegt ist um ein Fallback zu ermöglichen.
Beispiel:
var App = (new function() {
this.chatCommands = {};if(KnuddelsServer.chatCommandExists("jackpot")) {
this.chatCommands['jackpot1'] = function(user, params, command) {};
} else {
this.chatCommands['jackpot'] = function(user, params, command) {};
}
}());9 votesAhoi,
wir lehnen diesen Wunsch ab. Eine eigene Implementierung ist jedoch über diese neue Methode möglich: appInstance.getRegisteredChatCommandNames()
Knuddelige Grüße
Ironist -
0 votes
Hallo,
derzeit stoßen keine MyChannel-Besitzer an diese Grenze mit ihren Apps. Mehr als 200 Nutzer pro Channel ist eine Herausforderung für den Appserver. Wir werden das Thema größere Channel oder Apps in Tochterchannels dann angehen, wenn erste Apps regelmäßig an diese Grenzen stoßen.
Bis dahin bleibt dieser Vorschlag abgelehnt.
-
Bilder (GIFs) mit ID-tag im nachhinein manipulieren können
Hi, es wäre schön wenn man Bildern eine ID zuordnen könnte und mithilfe dieser ID diverse befehle an das Bild zurück schicken könnte.
Beispiel:
°>countdown...id_timeleft.gif<° (Ein Bild, welches nur einmal gestartet wird und im Endframe stehen bleibt)Nach klicken eines Buttons wird eine Funktion aufgerufen, die das Bild mit der id "timeleft" im nachhinein so manipuliert und sagt springe zu Endframe, verschwinde,freeze, werde größer, kleiner etc.
Ähnlich wie es bei normalem HTML und Javascript möglich ist. Ich weiß nur nicht, ob dies mit Java überhaupt realisierbar ist.
1 voteHuhu Olli,
wie gerade besprochen kann man dies bereits mit Display-Groups realisieren. Darum lehne ich diese Idee hier ab und freue mich darauf, dass du die Erklärung im internen Forum postest. :-)
-
8 votes
Ahoi,
derzeit planen wir keine Änderung hier.
Knuddelige Grüße
Ironist -
0 votes
Hallo,
wir möchten in der API keine Alias-Methoden anbieten. Dies würde die API in unseren Augen weiter aufblähen und für Anfänger schwieriger machen. Aus diesem Grund lehne ich diesen Vorschlag ab.
-
E-Mail Funktion vom Bot zu User ....
Also eine Funktion die der Bot nutzen kann um E-Mails zu senden
sendMail(user, text);
2 votesAhoi,
die Funktion Emails zu versenden werden wir nicht unterstützen. (weder an den App-Entwickler, Channel-Owner oder spezifische Nutzer) Wir sehen hier weit größere Probleme als beim Punkt “Kommunikation nach aussen” (http://knuddels-api.uservoice.com/forums/281002-general/suggestions/7042672-kommunikation-nach-au%C3%9Fen-hin-erlauben), den wir noch eroieren. Falls wir Kommunikation nach aussen ermöglichen, so ist ab diesem Zeitpunkt der Versand von Emails mit dem eigenen Server automatisch ermöglicht.
-
Neuer App-Hook: onAfterInstall
Dieser Hook soll ermöglichen einmalig Aktionen auszuführen, bevor die App das allererste Mal gestartet wird. Hier könnte man beispielsweise eine Datenbank mit Werten befüllen. (in einem Quizspiel z.b. Fragen)
6 votesAhoi,
diese Idee lehnen wir vorerst ab, da sie mit der AppPersistence sehr leicht selbst realisierbar ist.
Knuddelige Grüße
Ironist -
user.setToolbar()
Zum steuern der Toolbar pro User
1 voteAhoi,
wir starten jetzt mit der Entwicklung für HTML UI und werden in der ersten Version den Typ Overlay anbieten. Derzeit können wir uns nicht vorstellen eine Toolbar zu ermöglichen, die gut auf allen Clients funktioniert und lehnen die Idee daher ab.
-
[Persistenz] EIGENE SQLite-Datenbanken
Eigene SQLite-Datenbanken wäre sinnvoll.
So können erfahrene Nutzer eigene Tabellenstrukturen anlegen und auch viel besser (vielleicht sogar auch performanter) mit den Daten aggieren.
13 votesAhoi,
wir bieten mit der Persistence-API schon gute Möglichkeiten an, Daten persistent zu speichern. Besonders durch die Neuerung mit UserPersistenceNumbers ist ein großes Toolset dazu gekommen, das die Arbeit mit der Persistence erleichtert.
Falls konkrete Dinge fehlen, tragt diese bitte als Wunsch ein.
-
Neuer App-Hook: onAfterUpdate
Dieser Hook soll ermöglichen nach jedem App-Update Aktionen auszuführen, bevor die App das nächste Mal gestartet wird. Hier könnte man beispielsweise eine Datenbank um neue Werten erweitern. (in einem Quizspiel z.b. Fragen)
3 votesAhoi,
dies könnte interessant werden, sobald es ein echtes Versioning auf Serverseite gibt. Vorerst abgelehnt.
Knuddelige Grüße
Ironist -
TLS/FTPS Support for FtpServer
TLS/FTPS Support for FtpServer
1 voteHallo,
wir planen mittelfristig die Einführung eines Versionierungssystems wie GIT/SVN o.Ä. und werden in diesem Zuge den FTP-Server abschaffen. Aus diesem Grund planen wir derzeit keine Änderungen am FTP-Server vorzunehmen.
