Eu gostaria de propor que façamos isso com alguns scripts muito fáceis de encontrar. Nomeadamente:
$ ./mycroft-start.sh
$ ./mycroft-stop.sh

Ao apenas navegar no sistema de arquivos, eles irão saltar para um novato - "oh, é assim que você começa!"

Então, opcionalmente, ofereceria suporte a nomes de serviços específicos como parâmetros. Por exemplo
mycroft-start.sh [todos | voz | habilidades | ...]
mycroft-stop.sh [todos | voz | habilidades | ...]

Não há necessidade de reiniciar, "start" deve interromper tudo o que já está em execução (não podemos permitir a execução de serviços duplicados). Nenhum serviço tem parâmetros, então também não precisamos disso.

Isso faz muito sentido - desculpas, minha opinião inicial sobre isso não estava muito certa.

Proponho uma interface de usuário simples. Eu era (sou) um programador do Windows .NET, WPF, etc, então minha resposta inicial é fazer uma IU. Que tal algo simples que mostra o status dos vários estados e, em seguida, tem um lugar para inserir texto e mostra o texto de saída. Também pode começar, parar, o que for. Isso não funcionaria no picroft, mas o que eu poderia fazer é ter um back-end que pudesse ter parâmetros de linha de comando que a IU iria ler. Eu sei que todos os tipos de Linux adoram linhas de comando, mas para os artistas, designers, etc., eles gostariam de uma IU. Python tem um monte de estruturas de interface do usuário e se nós apenas começássemos pequeno e fizéssemos as coisas fáceis, ele poderia progredir e, eventualmente, ser uma loucura. Que tal? Quer que eu desenhe um protótipo? Tenho procurado algo para começar. Isso pode ser divertido.

O mycroft deseja interromper à força qualquer serviço que encontrar que corresponda ao que quer que esteja tentando iniciar? Isso seria problemático com algum dos serviços?

Também votaria nas mudanças de nome para remover start.sh (dobrar em mycroft.sh, para todas as suas necessidades granulares?), Adicionando start-mycroft.sh e stop-mycroft.sh.

@ highjinx411 Acho que você estava falando comigo sobre isso no Mattermost outro dia. Uma GUI é uma boa ideia, mas não fará parte do mycroft-core, que se destina a ser multiplataforma e (consequentemente) o mais independente possível de coisas como sistemas de gerenciamento de janelas. Uma GUI como a que você está propondo seria um gabinete, muito parecido com "gabinete-picroft", por exemplo, "gabinete-janelas".

Se você puder criar uma GUI verdadeiramente multiplataforma, também estaria interessado em vê-la!

PS Eu mesmo sou um velho cara do Windows - fiz a maior parte do desenvolvimento de GUI para AutoSketch 4 a AutoSketch 10 naquela época. Eu amo uma boa interface de usuário!

Uma interface gráfica de plataforma cruzada poderia ser possível, mas provavelmente seria limitada, pois abriria mão de quaisquer benefícios que você obteria ao torná-la dependente da plataforma. Portanto, você pode perder chamadas específicas do Windows, por exemplo, que podem ser uma vantagem se o aplicativo estiver no Windows. Concordo que deve fazer parte do recinto para garantir que seja o mais rico possível. Mesmo desenvolvendo aplicativos de plataforma "cruzada" com Xamarin para telefones móveis, por exemplo, tem partes que são dependentes da plataforma e no final constroem um executável específico para cada sistema operacional de qualquer maneira. A única coisa que deve estar disponível para todas as GUIs é algo no núcleo que expõe iniciar, parar, obter status etc. Assim, todas as GUIs podem chamar os mesmos métodos, independentemente da plataforma em que o núcleo está instalado. Na verdade, até mesmo apenas dizendo isso agora não tenho certeza, pois o Linux se sai bem com scripts bash, mas o Windows poderia se sair bem por meio de algum outro método. Então a questão é. A GUI examinará a instância do núcleo mycroft para sua plataforma? A GUI do Windows apenas olha para o núcleo do Windows e a GUI do Linux apenas olha para o núcleo do Linux? Ou poderia ser o Windows gui poderia ter um IP como uma entrada e acessa o núcleo onde quer que o IP esteja instalado, independentemente do sistema operacional?

Acredito que PR # 1107 deve resolver o problema. O que você acha, @KathyReid , feche este?

@Penrods acordado, encerrando este problema.