Created attachment 123176 [details] research side panels in MS Office and Google Docs This sidebar deck will allow a user to not have to leave LibreOffice interface in order to do research, which a user would normally turn to their browser for. It will contain research and reference tools like encyclopedias (e.g. wikipedia), dictionaries (e.g. wiktionary), thesaurus, translators (e.g. google translate), etc. The deck can feature both built-in and online services, but would primarily be for online services. The sidebar deck should ideally have support to render html content, so webview control (e.g. WebKitGtk+, MozView) would be needed, as it will allow online services to provide a suitable webpage that would only need to be displayed in order to get full search functionality (e.g. http://www.thefreedictionary.com/lookup.htm#searchbox).
There is a large collection of searchable reference sources. https://en.wikipedia.org/wiki/List_of_online_databases https://en.wikipedia.org/wiki/List_of_online_encyclopedias https://en.wikipedia.org/wiki/List_of_online_dictionaries https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applications
@Jay, oh my goodness! Is that you? We don't actually need to do this as a LibreOffice core feature. Especially as the Sidebar Deck is a perfect container to encourage extension developers to build content panels against. The API needs to be cleaned up and published, but the Zotero plug-in comes immediately to mind. As well some of the Latex extensions and MathML extensions. I could see this research content panel might be a good prototype feature/SDK example of a cmplex Sidebar Deck/Content panel extension.
(In reply to V Stuart Foote from comment #2) > @Jay, oh my goodness! Is that you? @Stuart: Yep its me. :D > We don't actually need to do this as a LibreOffice core feature. Especially > as the Sidebar Deck is a perfect container to encourage extension developers > to build content panels against. I guess i'd have to disagree, as extension imagine if each provider created their own extension, what would the sidebar turn into. It is better that we create the core functionality and let providers (most of which wouldnt spend the time to create their own extension) create just the minimum needed integration to enable their service to function within it. We are doing the same thing with the GSoC project to revamp the gallery sidebar tab so that it can search online providers like openclipart, which used to be its own dedicated panel until the sidebar arrived. https://wiki.documentfoundation.org/Development/GSoC/Ideas#Revamp_the_gallery_tool
Created attachment 123340 [details] Sidebar mockup To get the ball rolling, here is how a wikipedia service could be implemented. API References: https://www.mediawiki.org/wiki/API:Main_page https://www.mediawiki.org/wiki/API:Tutorial https://en.wikipedia.org/w/api.php Autocomplete Query Example: https://en.wikipedia.org/w/api.php?action=query&list=allpages&apfrom=OpenO&aplimit=5&format=xml Search Query Example: https://en.wikipedia.org/w/api.php?action=query&list=search&srwhat=text&srsearch=libreoffice&format=xml Page Content Example: https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&redirects=1&titles=Libreoffice&format=xml
Mock-up looks like a good start, you forgot to insert a Tab bar button for switching to the Deck. --Network connectivity-- When this Research/Reference content panel(s) be implemented as a core feature of LibreOffice--it will be important to be able to completely disable any external connection. That is, the mock-up should be clear to provide a "Not Active" mode, with no Encyclopedia "selected". And any network hooks must be silent when in that mode. Pushing this enhancement over to the UX-advise side for design and implementation. Otherwise if these core content panels are effective for Writer, they would be equally effective in Impress, Calc and Draw (possibly even Math if you connect to the right journal services). (In reply to Yousuf (Jay) Philips from comment #3) > > We don't actually need to do this as a LibreOffice core feature. Especially > > as the Sidebar Deck is a perfect container to encourage extension developers > > to build content panels against. > > I guess i'd have to disagree, as extension imagine if each provider created > their own extension, what would the sidebar turn into. It is better that we > create the core functionality and let providers (most of which wouldnt spend > the time to create their own extension) create just the minimum needed > integration to enable their service to function within it. > ... @Jay, still believe the flexibility is needed and will attract interesting projects to implement Sidebar based extensions. Where most extensions now provide Toolbar or Dialog based interface, they could provide richer Sidebar Deck held content panels of various function. Much like the work Jan-Marek is investigating to host the WollMuxBar in a set of Sidebar content panels with dedicated deck and tab bar launcher. Our goal for Sidebar should be publishing an API and IDL in the SDK for control and layout of Sidebar Deck, Tabbar and Content panels--and continuing to develop the internal framework needed for holding state in profile (per module, per user) and in extending ODF to carry any needed content to make the document portable. Another discussion and subject of Design & UX preliminary survey. Stuart
(In reply to V Stuart Foote from comment #5) > Mock-up looks like a good start, you forgot to insert a Tab bar button for > switching to the Deck. Yep forgot about that part as i didnt have an icon for it. :D > --Network connectivity-- > When this Research/Reference content panel(s) be implemented as a core > feature of LibreOffice--it will be important to be able to completely > disable any external connection. That is, the mock-up should be clear to > provide a "Not Active" mode, with no Encyclopedia "selected". And any > network hooks must be silent when in that mode. Yes it would need to check if the internet is available once a user switches to it, and if not, then it would disable all the entries that require internet in the drop down menu. > Pushing this enhancement over to the UX-advise side for design and > implementation. Otherwise if these core content panels are effective for > Writer, they would be equally effective in Impress, Calc and Draw (possibly > even Math if you connect to the right journal services). Yep i would expect we'd have a design session maybe after the design meeting to talk about it once heiko gets back to iron out the UX part. If it would be useful in other modules, it should definitely be. I would assume the dictionary, thesaurus, and translator would likely be useful in Calc and Impress. > (In reply to Yousuf (Jay) Philips from comment #3) > @Jay, still believe the flexibility is needed and will attract interesting > projects to implement Sidebar based extensions. Where most extensions now > provide Toolbar or Dialog based interface, they could provide richer Sidebar > Deck held content panels of various function. Much like the work Jan-Marek > is investigating to host the WollMuxBar in a set of Sidebar content panels > with dedicated deck and tab bar launcher. Would never say that we shouldnt encourage sidebar extensions, but believe this functionality shouldnt be left to out of core where 1) it would likely not seen by all users because its not part of the default install or 2) the extension wasnt design and developed in the best manner, which results in a bad user experience or 3) the extension isnt maintained and possible changes to the sidebar API would make it no longer functional (QA doesnt cater to questions regarding broken extensions). This it being part of core, we the design team can properly plan the correct UI and UX for implementation and can work with the dev who wishes to implement it. > Our goal for Sidebar should be publishing an API and IDL in the SDK for > control and layout of Sidebar Deck, Tabbar and Content panels--and > continuing to develop the internal framework needed for holding state in > profile (per module, per user) and in extending ODF to carry any needed > content to make the document portable. Another discussion and subject of > Design & UX preliminary survey. We could always have the developer who will implement this do it as a built-in sidebar extension, and use that as a means of showcasing the ability of the sidebar api and have it as a reference example those who want to build extensions. I'm hoping that infra could provide a dedicated server that could be used as the powering backend for this implementation. Where in a user would easily be able to install additional services as the service list is found on the server and queries would would be routed through the server, so that if there is any breakage in service, the fix can be done on the dedicated server and users wouldnt have to upgrade to the latest version to get a fixed version of the service.
Stumbled on this today, so adding it as design references. So for Office for Mac, they have an accordion styled reference tools panel. http://www.indezine.com/products/powerpoint/learn/interface/images/referencetools2011mac_04.jpg No access to internet error - http://www.scrubly.com/blog/wp-content/uploads/2014/06/june17_5.jpg http://www.dummies.com/how-to/content/using-word-2008-for-mac-online-reference-tools.html http://media.wiley.com/Lux/77/111177.image0.jpg http://media.wiley.com/Lux/78/111178.image1.jpg
*** Bug 98858 has been marked as a duplicate of this bug. ***
Wiktionary Queries: Autocomplete Example: https://en.wiktionary.org/w/api.php?action=query&list=allpages&apfrom=off&aplimit=5&format=xml Search Example: https://en.wiktionary.org/w/api.php?action=opensearch&limit=10&namespace=0&format=xml&search=office Page Content Example 1 [Print Version]: https://en.wiktionary.org/w/index.php?title=office&printable=yes Page Content Example 2 [Mobile Version]: https://en.m.wiktionary.org/wiki/office
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
*** This bug has been marked as a duplicate of bug 87078 ***
Adolfo, why is this not true anymore? When you reopen a ticket at least a short comment is needed. > *** This bug has been marked as a duplicate of bug 87078 ***
I wrote some sample Python code to fetch definitions from Wiktionary, and then filter it via Beautiful Soup to be shorter and more relevant: https://gist.github.com/KeithCu/29f6a2131a7dcad7de9a270c9d11b62c Is there an easy way to put the text into the research sidebar?
*** Bug 108627 has been marked as a duplicate of this bug. ***
(In reply to Keith Curtis from comment #13) > I wrote some sample Python code to fetch definitions from Wiktionary, and > then filter it via Beautiful Soup to be shorter and more relevant: > > https://gist.github.com/KeithCu/29f6a2131a7dcad7de9a270c9d11b62c > > Is there an easy way to put the text into the research sidebar? I'm not sure if this is supposed to be done as an extension, or core feature. If extension, you can surely use the python code and create a sidebar deck using the api. See wollmux code for a full example. If this is supposed to be a core feature, this needs to be implemented with C++ as any other sidebar deck. Let me know if you need more code pointers (and for which approach).
The wizards ship as a core feature and run in Python, why couldn't this? It is good to use a more productive language in LibreOffice whenever possible, and a research tab seems like a great example of something that would be good enough in Python. It is becoming the language of choice for neural networks, data science, etc. I hope that LibreOffice one day will have PyTorch inside for the grammar checker, and other places: http://document-foundation-mail-archive.969070.n3.nabble.com/Fwd-AI-in-Microsoft-Office-td4231071.html I wrote that code because it was an interesting little task for me. I think the Beautiful Soup filter is a good start to taking the default output of Wiktionary and making it reasonable enough to fit in a dialog box. There could be other solutions such as requesting a mobile version. I might try to figure that out next. Also, it should have an LRU cache to not hit their servers too much. I'll put that in, as it's just one line of code ;-) I could investigate how to create a simple UI, or figure out how to create / update a research tab on the sidebar, but I've not done any LibreOffice UI stuff yet. If someone else has more knowledge or time to learn, they could take this Python and keep going. It should be possible to quickly build a very good extension, and then people can decide what to do with it. Thanks for the Wollmux reference. I may find their source and go through it. Lightproof could also be another good starting point: https://cgit.freedesktop.org/libreoffice/lightproof/tree
I figured out how get a mobile view from Wiktionary, but it had just as many sections. i.e, it will also need filtering. It might be possible to tell it what sections you want, but I'm not sure if it's possible to tell it sections you *don't* want. I'll look around. If LibreOffice knew that the word was a noun, it could request just that section for example, and get the minimal amount of data, but that requires looking the word up elsewhere first. Another possibility is to get all the sections, filter out the ones LibreOffice wouldn't want, and then request just that content. That requires more API calls, and might not be faster, but it could be worth trying.
I tried to have Wiktionary filter the text it sends, and was able to turn off the table of contents, and edit sections, but not the translation table, for example. I don't fully understand the Wikipedia API: https://en.wikipedia.org/w/api.php?action=help&modules=parse I've updated the code.
I've tweaked the Wiktionary code to work with some more languages, but eventually it would need to handle langids. I see a useful C++ routine: https://docs.libreoffice.org/setup_native/html/sellang_8cxx_source.html Is that information available via UNO? I discovered that Wiktionary links show up as local URLs, and wasn't able to fix this via the API, so I changed it on the client side. It's not rocket science to get data from Wiktionary. Let's add this and other online features asap. It turns out to be 1 line of code (using a PIP package) to have Google translate a string of text and I added that to the file. I also got Azure translation working. It's not 1 line, but it's not bad. I'll go through this: https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applications and find another FOSS one to talk to. It seems like LibreOffice could hook up to a number of online services, and have a dialog box which let you configure what is enabled via the right-click menu. The Azure API needs a key, for example.
(In reply to Keith Curtis from comment #19) > Is that information available via UNO? Here is a automatically updated list of UNO commands https://wiki.documentfoundation.org/Development/DispatchCommands You can grep the code with http://opengrok.libreoffice.org/ If the questions go more into detail it's better to ask the developers on IRC #libreoffice-dev (see also https://wiki.documentfoundation.org/Development)