-
1. Data: 2018-12-31 14:28:23
Temat: Projektowanie dla pluginów
Od: Borneq <b...@a...hidden.pl>
Chodzi mi w tym wątku o ogólny przypadek a nie tylko C++ i Qt.
Przykładami mogą być pluginy Eclipse w Javie czy chyba w Javascripcie
dla Firefoksa i Chrome.
Mamy edytor i plugin pozwalający na pracę z zaszyfrowanymi plikami.
Bez pluginu edytor otwiera wszystkie pliki jednakowo, jakby były plikami
tekstowymi w UTF8, otwierając binarne widzi się śmiecie z długimi liniami.
Teraz gdy w podkatalogu plugins będzie odpowiedni plugin, pliki o
wyróżnionym rozszerzeniu będą traktowane jako zaszyfrowane.
Będzie sprawdzany nagłówek, gdy się zgadza, będzie użytkownika pytał o
hasło i konwertował potem zaszyfrowaną wiadomość aby a pamięci była
zdeszyfrowana.
Jak to zrobić? W module głównym powinna być metoda filtru która dla tego
pluginu filtrowała by zawartość. Jednak dla wielu innych pluginów metoda
ta była by nie wykorzystana, oraz byłby konflikt, gdyby inny plugin ją
wykorzystywał. Na przykład zabawkowy plugin konwertujący duże litery na
małe i odwrotnie. Wtedy byśmy mieli dwa filtry dla plików zaszyfrowanych
oraz musiała by być zachowana kolejność: najpierw deszyfracja, potem
zmiana wielkości liter a nie odwrotnie.
Pluginy dopisywały by coś do menu, tworząc submena. Jak w pluginach
określić miejsce dopisywania do menu?
Ogólnie, niezbyt to widzę, bo moduł główny musiałby przewidywać akcje,
gdzie będą rozszerzone przez pluginy, nie wiem jak można by
zaprojektować by plugin mógł rozszerzać coś dowolnego, o czym nie
pomyślał twórca modułu głównego.
-
2. Data: 2018-12-31 14:47:49
Temat: Re: Projektowanie dla pluginów
Od: Mateusz Bogusz <m...@o...pl>
> Ogólnie, niezbyt to widzę, bo moduł główny musiałby przewidywać akcje,
> gdzie będą rozszerzone przez pluginy, nie wiem jak można by
> zaprojektować by plugin mógł rozszerzać coś dowolnego, o czym nie
> pomyślał twórca modułu głównego.
Musisz założyć w jakich miejscach aplikacji chcesz umożliwić dodawanie
wtyczek i zaprojektować dla tych miejsc interfejsy do komunikacji z
pluginami. Na starce aplikacji, wczytać wtyczki, dać im szansę się
"zarejestrować" przekazując jakiś obiekt "kontekstu", który np. umożliwi
podpięcie się wtyczki w "pipeline" wczytywania pliku o zadanym
rozszerzeniu (jeżeli tego nie zrobi np. sama definicja interfejsu).
--
Pozdrawiam,
Mateusz Bogusz
-
3. Data: 2018-12-31 21:00:33
Temat: Re: Projektowanie dla pluginów
Od: s...@g...com
Proponuję ściągnąć źródła Qt Creatora (są na Git hubie:
https://github.com/qt-creator/qt-creator ), otworzyć je w Qt Creatorze (skompilowanym
- z pakietu biblioteki Qt). To bardzo inspirujące działanie.
Ja wzorując się na tym zrobiłem w swoim programie coś takiego jak fabrykę pluginów
Plugins. Zajmuje się ona ładowaniem pluginów (z uwzględnieniem zależności i wersji -
tak jak w Qt Creator), ale najważniejsze jest to, że ta fabryka pełni również rolę
zwrotnicy: pluginy rejestrują w niej swoje zdarzenia (std::function - zobacz sobie
przykłady w dokumentacji: https://en.cppreference.com/w/cpp/utility/functional
/function , w stosowaniu upierdliwe jak diabli, ale za to intuicyjne w użyciu i
bardzo szybkie w działaniu), a okno główne i edytory wywołują na nich swoje kluczowe
zdarzenia (np po otwarciu pliku, przed zamknięciem, przed wyświetleniem menu
kontekstowego, przy tworzeniu paska nawigacyjnego (przyciski, zakładki i dowolne inne
kontrolki), przy tworzeniu paska menu, tworzenie kart opcji itp.). Oczywiście
parametry funkcji się zmieniają w każdym przypadku i to wymusza utrzymanie wielu list
tych funkcji, ale nie znam lepszego rozwiązania w C++.
-
4. Data: 2018-12-31 21:36:52
Temat: Re: Projektowanie dla pluginów
Od: Borneq <b...@a...hidden.pl>
W dniu 31.12.2018 o 21:00, s...@g...com pisze:
> Proponuję ściągnąć źródła Qt Creatora (są na Git hubie:
https://github.com/qt-creator/qt-creator ), otworzyć je w Qt Creatorze (skompilowanym
- z pakietu biblioteki Qt). To bardzo inspirujące działanie.
Tak, ale sam katalog src/ to 57 mega
>
> Ja wzorując się na tym zrobiłem w swoim programie coś takiego jak fabrykę pluginów
Plugins. Zajmuje się ona ładowaniem pluginów (z uwzględnieniem zależności i wersji -
tak jak w Qt Creator), ale najważniejsze jest to, że ta fabryka pełni również rolę
zwrotnicy: pluginy rejestrują w niej swoje zdarzenia (std::function - zobacz sobie
przykłady w dokumentacji: https://en.cppreference.com/w/cpp/utility/functional
/function , w stosowaniu upierdliwe jak diabli, ale za to intuicyjne w użyciu i
bardzo szybkie w działaniu), a okno główne i edytory wywołują na nich swoje kluczowe
zdarzenia (np po otwarciu pliku, przed zamknięciem, przed wyświetleniem menu
kontekstowego, przy tworzeniu paska nawigacyjnego (przyciski, zakładki i dowolne inne
kontrolki), przy tworzeniu paska menu, tworzenie kart opcji itp.). Oczywiście
parametry funkcji się zmieniają w każdym przypadku i to wymusza utrzymanie wielu list
tych funkcji, ale nie znam lepszego rozwiązania w C++.
>
Moduł główny to m.in. fabryka pluginów, bez edytora, który też jest w
pluginie?
czy da się wykonać taką rzecz, by plugin zmieniał kolejność
przechodzenia tabów przez control+tab?
Normalnie bez plugina przechodzenie jest kolejne, plugin miałby
przesuwać tab na początek przy zwolnieniu klawisza control.
Wtedy jednak jak w pluginie podczepić filtr zdarzeń, który teraz jest
metodą w głównym oknie oraz jak plugin miałby mieć dostęp do widgetu z
tabami?
-
5. Data: 2018-12-31 22:08:56
Temat: Re: Projektowanie dla pluginów
Od: Borneq <b...@a...hidden.pl>
W dniu 31.12.2018 o 21:36, Borneq pisze:
> Moduł główny to m.in. fabryka pluginów, bez edytora, który też jest w
> pluginie?
Tak było by źle, bo co gdyby był plugin syntaxHighlighter a nie było
plugina TextEditor ?
-
6. Data: 2019-01-01 20:16:09
Temat: Re: Projektowanie dla pluginów
Od: Mateusz Bogusz <m...@o...pl>
> Tak było by źle, bo co gdyby był plugin syntaxHighlighter a nie było
> plugina TextEditor ?
A co by było gdyby nie było plugina Main?!
MSPANC :-P
--
Pozdrawiam,
Mateusz Bogusz