==== Cleanup extensions list ==== '''Background:''' Since we now bundle lots of languages, the extension list Tools->Extension manager is stuffed with things that cannoy be removed, which is annoying. We should categorise the extensions, and filter out the built-in ones by default. This means adding a check-button to: desktop/source/deployment/gui/dp_gui_dialog2.src desktop/source/deplyoment/gui/dp_gui_extlistbox.* And adding some simple filtering so people see the extensions they added themselves. '''Skills:''' C++, common sense (.src), build
caolanm->dtardon: didn't you have some ideas around e.g. not showing "bundled" (as opposed to shared and user) extensions in this list ? At least not by default
Created attachment 53698 [details] First mockup for extension filtering First mockup for extension filtering
I gave a try to solve this bug and I have some questions on UX for it. Looking into this first mockup attached. 1) I chose to use checkboxes so that filtering can display none, one, two or three categories. A group of radio buttons will display one category exclusively, and could make the search for an extension more difficult. 2) Either we implement an event upon changing the state of one of the checkboxes or we add a "Filter" button on the right to start the filtering (easier for me). What would be the prefered approach? The Bundled checkbox is unmarked by default.
I wonder if it makes sense to just automatically restrict the extension management dialog to *just* the user extensions, i.e. skip showing the bundled and system ones altogether and not have any toggles to show them and require use of the standlone extension admin tools to list them. Maybe ask the ux design team for their opinion on this ?
A volunteer, excellent! So I am not going to have to do it myself after all :) dtardon->olivier.hallot: I agree with Caolán that there is no need to overdo this. IMHO it makes perfect sense to not display bundled extensions at all (even if Rene disagrees :) In fact, I would argue that they are actually part of the application and it just happened they are distributed as extensions. We do not present config. manager or the internal spell checker in the extension list either, do we? :) But I would prefer that shared extensions remain displayed. One can still manipulate them if one has sufficient rights and I can imagine that some admins might prefer a GUI tool for that. E.g., for removal, unopkg gui , find the extension and click on Remove button vs. unopkg list --shared find the extension in the listing (which might be several pages long and most of it is cruft nobody but developers is interested in), copy or remember an insanely long identifier and run unopkg remove --shared <identifier> :) Last but not least, I suppose there is still a number of Windows boxes where the user does not have separate admin account, so the difference between user and shared extensions is just nominal.
The other possibility is that tools->extensions shows just the users extensions. while the stand alone unopkg gui shows all of them.
HI folks some thoughts 1) There are legions of mouse-movers admins who get scared with a command prompt. I can't expect I'll have a genius administrating a LO deployment.: * leave the GUI for admins 2) OTOH, there are users that are clever and want to see what is going on in their machine (cf René). What if an extension is advertised in a site and happens to be already bundled or shared in his default installation?.... * Show me the bundled and shared extensions as well. 3) One issue that is hurting us in the GUI is that bundled and shared extensions are not easy to distinguish one from other. *Suggestion: bundled extension should have a red padlock icon, or a light red background table entry in GUI 4) I propose to change the label “bundled” to “From Installation” or such, because “bundled” does not say in layman words what is this about. And guys, don't hold your breath, I am no C++ dev, I am lurking at the code and doing my best. If that is urgent, please take over.
Created attachment 53900 [details] patch to clean extensions list
Created attachment 53919 [details] fix for fdo39748, part II Code cleanup and better listbox size calculation
Yeah, the patch(es) looks good, but I thought the main point of this whole excercise was to hide the bundled extensions from user (e.g., do not show them by default)? I will commit it with that one change. Btw, it has not been FIXED yet (i.e., the code is not in git :)
Ah, I see Michael committed it already...
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript ) [NinjaEdit]