eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › Projektowanie dla pluginów
Ilość wypowiedzi w tym wątku: 6

  • 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

strony : [ 1 ]



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: