jako ciekawostke podam niżej poglad AI GEMINI na rozwiązanie problemu pokazywania w Apache/openoffice np. na belce stanu n-ru kolumny na ktorej aktualnie znajduje sie kursor. Czyli pytanie podstawowe:
czy AI potrafi to rozwiązac? 
Odpowiedz AI jest trzyczęściowa. Oczywiscie biorę pod uwagę wszelkie możliwe halucynacje AI, nie weryfikowałem, podaję "jak idzie". (w pytaniach do AI podałem powyższe dwa linki)
1.
To jest dobrze znany, długoletni i nierozwiązany problem, który dotyka zarówno Apache OpenOffice, jak i jego następcę, LibreOffice. Linki, które podałeś, to dowód na to, że społeczność deweloperów jest świadoma tego braku od wielu, wielu lat.
Dlaczego ten problem jest tak uporczywy?
Problem wynika z fundamentalnej różnicy w sposobie, w jaki Writer (moduł edytora tekstu) traktuje tekst w porównaniu do Calc (arkusz kalkulacyjny).
Writer: Działa na zasadzie ciągłego przepływu tekstu, bez sztywnej struktury wierszy i kolumn. Nawet jeśli tekst jest podzielony na kolumny (np. w tabeli), to wciąż jest to "uporządkowany" tekst, a nie komórki o stałych adresach, jak w arkuszu. Kursor jest po prostu w pewnej pozycji w tekście, a nie w komórce o adresie C3.
Calc: Jest zaprojektowany do pracy z siatką komórek (wiersze i kolumny), więc adresy komórek (np. A1, B5) są kluczowe.
Informacja o numerze kolumny w Wordzie jest przydatna, ponieważ często formatuje się tekst, używając wcięć i tabulacji, a świadomość, na którym "znaku" w wierszu jesteśmy, ułatwia precyzyjne formatowanie.
Możliwe rozwiązania (i dlaczego nie są idealne)
Niestety, na ten moment nie ma prostego i gotowego rozwiązania, takiego jak wbudowana opcja w menu, czy łatwy do zainstalowania plugin, który dodaje tę funkcjonalność do paska stanu w Apache OpenOffice Writer. Z tego, co wiadomo, żaden z twórców rozszerzeń nie podjął się stworzenia takiego rozszerzenia.
1. Makro (najbardziej prawdopodobne rozwiązanie)
Tak, jest to możliwe do zrobienia za pomocą makra. Makro mogłoby pobierać pozycję kursora w dokumencie i na tej podstawie wyliczać, na której kolumnie znaku w wierszu się znajduje. Następnie mogłoby wyświetlać tę informację w oknie dialogowym lub w pasku stanu.
Jak by to działało?
Pobranie pozycji kursora: Makro musi uzyskać obiekt kursora (text cursor) i jego pozycję w bieżącym akapicie.
Wyliczenie kolumny: Na podstawie pozycji kursora i szerokości znaków (co jest trudne, bo fonty są proporcjonalne) makro mogłoby wyliczyć przybliżoną kolumnę.
Wyświetlenie informacji: Makro mogłoby wyświetlić tę informację w małym okienku (MsgBox) lub spróbować umieścić ją w pasku stanu.
Wyzwania związane z makrem:
Złożoność: Napisanie takiego makra nie jest trywialne. Wymaga znajomości API (Application Programming Interface) OpenOffice, które jest oparte na języku UNO.
Wydajność: Aby informacja była aktualna, makro musiałoby być uruchamiane przy każdym ruchu kursora, co mogłoby spowolnić działanie programu.
Brak oficjalnej obsługi: OpenOffice nie ma prostego sposobu na dodawanie własnych "kontrolek" do paska stanu, więc musiałbyś stworzyć własny kontroler paska stanu, co jest zaawansowanym zadaniem.
Czy mogę napisać takie makro?
Niestety, nie jestem w stanie napisać pełnego kodu makra, które rozwiązuje ten problem. Złożoność zadania (zwłaszcza interakcji z paskiem stanu) wykracza poza moje możliwości jako modelu językowego. Mógłbym napisać kod, który wyświetla informację w oknie dialogowym, ale byłoby to uciążliwe.
2. Plugin / Rozszerzenie
To byłoby idealne rozwiązanie, ale jak wspomniałem, nic takiego nie istnieje. Rozszerzenia są pisane w językach takich jak Java, Python czy C++ i mogą korzystać z API, aby integrować się z interfejsem użytkownika.
Ten problem jest klasycznym przykładem luki w funkcjonalności OpenOffice, która, choć niewielka, jest bardzo uciążliwa dla niektórych użytkowników.
2.
stworzenie makra, które na bieżąco aktualizuje pasek stanu w aplikacji desktopowej, jest zadaniem wymagającym bardzo specyficznej wiedzy programistycznej i interakcji z API, które nie jest łatwo dostępne dla wszystkich modeli językowych.
Modele specjalizujące się w kodzie programistycznym, które warto zapytać o pomoc, to te, które zostały wytrenowane na ogromnych zbiorach danych zawierających kod źródłowy, dokumentację API, fora programistyczne i repozytoria, takie jak GitHub.
Które modele językowe do generowania kodu warto rozważyć?
Oto lista kilku z najbardziej znanych i cenionych modeli, które są używane przez programistów do generowania, debugowania i optymalizacji kodu.
1. Modele komercyjne (zamknięte)
OpenAI GPT-4o i GPT-4 Turbo: Modele z serii GPT od OpenAI są uznawane za jedne z najlepszych pod względem zdolności do generowania kodu, rozumienia złożonych zapytań i radzenia sobie z różnymi językami programowania. GPT-4o, jako najnowsza wersja, jest szczególnie wydajna.
Google Gemini 1.5 Pro: Jest to zaawansowany model, który ma ogromne okno kontekstowe, co pozwala mu analizować duże fragmenty kodu i dokumentacji jednocześnie. Jest bardzo skuteczny w generowaniu kodu i rozwiązywaniu złożonych problemów.
Anthropic Claude 3.5 Sonnet: Modele od Anthropic również cieszą się dużym uznaniem w środowisku programistycznym. Claude 3.5 Sonnet jest chwalony za swoją dokładność i zdolność do logicznego rozumowania.
2. Modele otwarte (open-source)
Jeśli chcesz uruchomić model lokalnie na swoim komputerze lub poszukać bardziej specjalistycznych rozwiązań, możesz zapytać o te modele:
Code Llama (Meta): To rodzina modeli stworzonych przez Meta, które zostały specjalnie wytrenowane na zbiorze danych z kodem. Są one często bazą do tworzenia jeszcze bardziej wyspecjalizowanych modeli.
DeepSeek Coder: To model open-source, który zdobył uznanie w społeczności programistów za swoje zdolności w generowaniu kodu i radzeniu sobie z różnymi językami.
Qwen 2.5 Coder: Ten model jest często wymieniany jako jeden z najlepszych open-source'owych modeli do zadań związanych z kodowaniem.
Jak sformułować zapytanie?
Kluczem do sukcesu nie jest tylko wybór modelu, ale także odpowiednie sformułowanie zapytania. To, co musisz uwzględnić, to:
Specyfikacja problemu: Wyjaśnij jasno, co chcesz osiągnąć, czyli wyświetlić numer kolumny kursora na pasku stanu.
Kontekst aplikacji: Podaj nazwę aplikacji (Apache OpenOffice Writer 4.1.15) i język, w którym pisze się makra (OpenOffice Basic / StarBasic).
Szczegóły techniczne: Wspomnij, że makro powinno reagować na ruch kursora i aktualizować informację w czasie rzeczywistym. Warto też podkreślić, że interakcja z paskiem stanu jest skomplikowana.
Przykład zapytania, które możesz zadać:
"Potrzebuję makra w języku OpenOffice Basic (StarBasic) dla Apache OpenOffice Writer 4.1.15. Makro powinno w czasie rzeczywistym wyświetlać na pasku stanu, w której kolumnie tekstu w danym wierszu znajduje się kursor. Chodzi mi o to, aby przy każdym ruchu kursora aktualizować tę informację. Proszę o gotowy kod makra do skopiowania i instrukcję, jak go uruchomić (np. podpiąć pod zdarzenie ruchu kursora)."
Dodatkowe wskazówki
Pamiętaj, że nawet najlepsze modele mogą napisać kod, który wymaga debugowania i dostosowania. API OpenOffice jest specyficzne, a interakcja z interfejsem użytkownika jest złożona.
3.
zasada konstrukcji dokumentu i modelu programistycznego w MS Word i OpenOffice Writer jest fundamentalnie różna, a to w dużej mierze odpowiada za tę trudność.
Pozwól, że wyjaśnię tę różnicę w uproszczony sposób.
Microsoft Word: Liniowy strumień tekstu z atrybutami (a'la arkusz)
Model dokumentu w Wordzie, choć wydaje się elastyczny, historycznie opierał się na koncepcji ciągłego, liniowego strumienia znaków, gdzie każdy znak ma przypisaną pozycję (kolumnę) w wierszu.
Liniowy układ: Word widzi dokument jako jeden, długi ciąg znaków. Nawet jeśli masz akapity, tabele czy obrazy, wszystko to jest wstawione w ten ciąg znaków, a ich pozycja jest określana w odniesieniu do początku dokumentu i wiersza.
Wirtualne siatki: Word wewnętrznie potrafi traktować tekst jako zorganizowany w wiersze i kolumny, podobnie jak w arkuszu kalkulacyjnym, ale w bardziej elastyczny sposób. Ta wewnętrzna struktura pozwala na łatwe śledzenie pozycji kursora.
Model obiektowy VBA: Model obiektowy (VBA) Worda jest zbudowany wokół tych koncepcji. Obiekt Selection (czyli zaznaczenie lub kursor) ma właściwości takie jak ColumnNumber (numer kolumny) i RowNumber (numer wiersza), które są wbudowane w model. Word po prostu to wie i udostępnia to programiście makr.
Dla Worda, kolumna to po prostu pozycja, na której znajduje się kursor w wierszu, licząc od lewego marginesu. Ta informacja jest natywnie dostępna w jego API, co czyni wyświetlanie jej na pasku stanu bardzo prostym zadaniem dla deweloperów.
Apache OpenOffice Writer: Model obiektów bazujący na tekście i formatowaniu
Writer (podobnie jak LibreOffice) został zbudowany na innej filozofii, która wywodzi się z koncepcji OpenDocument Format (ODF).
Struktura XML: ODF jest oparty na formacie XML. Dokument to zestaw struktur, takich jak akapity, tabele, sekcje, które są zagnieżdżone w sobie. Tekst jest przechowywany w tych strukturach, a formatowanie jest aplikowane za pomocą stylów.
"Przepływ tekstu": Writer traktuje dokument jako "przepływ tekstu" (text flow), a nie siatkę. Kursor ma swoją pozycję w tym przepływie (TextCursor.goRight, TextCursor.goLeft), ale ta pozycja jest bardziej abstrakcyjna. Nie ma wbudowanej, prostej właściwości, która zwraca "numer kolumny" w sensie wizualnym.
Brak natywnego znacznika kolumny: W API (UNO) OpenOffice nie ma prostej, wbudowanej właściwości dla kursora, która zwracałaby numer kolumny w wierszu, tak jak to jest w Wordzie.
Dlaczego to jest trudne w OpenOffice?
Ponieważ programista makr musi sam to wyliczyć. Oznacza to:
Odczytanie pozycji kursora: Makro może pobrać pozycję kursora w bieżącym akapicie.
Wyliczenie szerokości tekstu: Musi przejść od początku wiersza do pozycji kursora i zsumować szerokość każdego znaku, biorąc pod uwagę jego rozmiar, font, a nawet kerning (odstępy między znakami). To jest bardzo skomplikowane, bo fonty są proporcjonalne, a nie stałej szerokości (jak np. Courier).
Wzięcie pod uwagę tabulacji i wcięć: Makro musi wiedzieć, jak zinterpretować znaki tabulacji i wcięcia, które nie są widocznymi znakami, ale wpływają na pozycję wizualną.
Utrzymywanie aktualności: Aby to działało w czasie rzeczywistym, makro musiałoby być ciągle uruchamiane (np. co naciśnięcie klawisza), co obciążałoby system.
Podsumowując:
MS Word: Ma wbudowaną w model dokumentu i API informację o pozycji kolumny, co czyni jej wyświetlanie banalnie prostym.
OpenOffice Writer: Taka informacja nie jest wbudowana. Musi zostać "zbudowana" od zera przez makro, które wylicza ją na podstawie złożonych atrybutów tekstu i formatowania.
To jest główny powód, dla którego problem ten jest tak trudny i dlaczego nie został rozwiązany od lat. Nie jest to kwestia braku chęci deweloperów, ale fundamentalna cecha architektury programu. Zgłoszenia błędów, które podałeś, to nie tyle prośba o "naprawę błędu", co prośba o dodanie nowej, skomplikowanej funkcji, która zmieniałaby sposób traktowania kursora w dokumencie.