Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32192 > unrolled thread

Projektowanie dla pluginów

Back to article view | Back to pl.comp.programming

Contents

  Projektowanie dla pluginów Borneq <borneq@antyspam.hidden.pl> - 2018-12-31 14:28 +0100
    Re: Projektowanie dla pluginów Mateusz Bogusz <mabakay@o2.pl> - 2018-12-31 14:47 +0100
    Re: Projektowanie dla pluginów szykcech@gmail.com - 2018-12-31 12:00 -0800
      Re: Projektowanie dla pluginów Borneq <borneq@antyspam.hidden.pl> - 2018-12-31 21:36 +0100
        Re: Projektowanie dla pluginów Borneq <borneq@antyspam.hidden.pl> - 2018-12-31 22:08 +0100
          Re: Projektowanie dla pluginów Mateusz Bogusz <mabakay@o2.pl> - 2019-01-01 20:16 +0100

#32192 — Projektowanie dla pluginów

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.

[toc] | [next] | [standalone]

#32193

> 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

[toc] | [prev] | [next] | [standalone]

#32194

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++.

[toc] | [prev] | [next] | [standalone]

#32195

W dniu 31.12.2018 o 21:00, szykcech@gmail.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?

[toc] | [prev] | [next] | [standalone]

#32196

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 ?

[toc] | [prev] | [next] | [standalone]

#32198

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web