==== Web search for UI strings ==== '''Background:''' It is currently difficult and time-consuming for developers to find where in the code a given UI feature comes from. We should provide a database of all the *.?rc files (resource files), and provide a nice search form that allows people to search -only- the resource files. Bonus points for correlating the define eg. SID_FOO with the related string, and then finding its use in all source files. When done we should migrate it to a live server. '''Skills:''' checkout, web / cgi, search etc.
Some questions: Do you plan to have a scheduled script that will feed a db after scanning the git repo, or do you want real-time search ? If you set it in a live server, will it be integrated with something else, meaning you may have a preferred web technology : perl/cgi, php, python/cgi ? If not real-time, when talking about a database, do you plan to have a real one, and which one: mysql, sqlite, xml, postgres ?
> Do you plan to have a scheduled script that will feed a db after scanning the > git repo, or do you want real-time search ? Up to whomever implements it I suppose :-) but a database which could be a flat text file really (all our *.?rc files are only 15Mb concatenated with misc. headers included). > If you set it in a live server, will it be integrated with something else, > meaning you may have a preferred web technology : perl/cgi, php, python/cgi ? Good question; again I think we're flexible here; for a preference I'd poke Cloph, but if you use your favorite (non-haskell/eiffel/erlang type ;-) web language it should be fine I hope. > If not real-time, when talking about a database, do you plan to have a > real one, and which one: mysql, sqlite, xml, postgres ? Whatever comes easily to hand is fine I suppose. I guess something small and simple would be fine; feasibly we could pre-compute and cache the results pretty easily, or just forward to a set of opengrok queries for the SID_FOO_BAA that we map "Set Background Color" to - so the data set is small. I'm personally nervous of big system level databases, with permissions, admin pain, access control issues, etc. etc. ;-) Does that make sense ? - thanks so much for taking an interest !
I put there a discussion from the ML: http://lists.freedesktop.org/archives/libreoffice/2012-September/037946.html From "Michael Meeks" <michael.meeks@suse.com>, on Thu, 06 Sep 2012 14:53:28 +0200 Subject: Re: Bugs 38840+39596: Coverage analysis and static analysis: Whats next ? On Thu, 2012-09-06 at 13:15 +0200, John Smith wrote: > Alright, let me see if I understand this one correctly first. You > basically want people to be able to find out what gets "#define" 'd in > what rc files ? So for example, you want people to search for > "FL_RECORD" to discover that that gets defined in > './sw/source/ui/envelp/mailmrge.hrc" ? Nope it's worse than that; we want to go from "Export" to: String STR_PDF_EXPORT { Text[ en-US ] = "E~xport"; }; and from there to an opengrok query (?) for STR_PDF_EXPORT in the code. Of course; we could do this in shell, in a tool in the code if you're happier with that :-)
Actually, if opengrok *really* supported escaping special chars, one could do it straight with 2 full searches, first with Levenstein distance option. e.g. First Step: search for ID: "Text E~xport"~5 is neat. "Text Export~"~5 is wider but still contains result. We should be able to do "Text \[ * \] Export"~5 that should narrow the search and should not return http://opengrok.libreoffice.org/xref/core/sc/source/filter/inc/xlroot.hxx because of line 126, but it seems opengrok does not escape special chars very well... Also, "Text Passwords for web connections"~5 works. Second step, once you found the right ID, query it. Is it enough ? Or what more do you expect ? If you can provide some examples that are more complex / corner cases, it will be great. PS: I didn't find a way to highlight matched text in OpenGrok when opening file.
Michael or Bjorn, could you answer me ?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
Job's done, finally (my little GSoC :) ) I will submit it to gerrit
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
I managed to deliver the small site to openshift. It was painful but learning as well. So you can test it here: http://lionss-codeornot.rhcloud.com/ Because of all the changes and the inital request, I am not sure this is what you expect. Don't mind to provide use cases so I can improve my work.
Wow: this is awesome ! :-) I entered "Format code" (eg. a string from the Calc format dialog) and it took me straight to the code: That's awesome =) Thanks 1 Cloph may have some idea of how we can host this - perhaps put it on the same machine as OoenGrok ? Is the code hosted somewhere ? Also - I think we should have a small piece of text that says: F_o_o (with the o underlined) is mangled as 'F_oo' to help people search for strings with accelerators. > Because of all the changes and the inital request, I am not sure this is > what you expect. Don't mind to provide use cases so I can improve my work. Looks brilliant to me ! =) There are other cases like menu items that we should prolly handle differently: there we need to search more deeply: in the officecfg to find a string, map that to a .uno:Foo thing, then map that to an SID_FOO_BAA_URL thing and onwards to SID_FOO_BAA into the code ... But this is a great start! Cloph - whom should we poke wrt. hosting it ? [ and thanks Mat ]
(In reply to comment #11) > Wow: this is awesome ! :-) > > I entered "Format code" (eg. a string from the Calc format dialog) and it > took me straight to the code: > > That's awesome =) Thanks 1 Cloph may have some idea of how we can host this > - perhaps put it on the same machine as OoenGrok ? This is python, so I need an apache + wsgi + python2.7 and enough space to put a core repo at hand. > > Is the code hosted somewhere ? > On Openshift for now. I plan to put it in dev-tools. > Also - I think we should have a small piece of text that says: F_o_o (with > the o underlined) is mangled as 'F_oo' to help people search for strings > with accelerators. Well, I always add the accelerator character to the search string, just in case. That was in the specs: Handle accelerator transparently. We could tell the user it can be omitted, though. > There are other cases like menu items that we should prolly handle > differently: there we need to search more deeply: in the officecfg to find a > string, map that to a .uno:Foo thing, then map that to an SID_FOO_BAA_URL > thing and onwards to SID_FOO_BAA into the code ... Not that hard. It looks like the old hrc files system we had for dialogs, which is already coded on the heroku version of the site. (BTW, is there plans to move menu to ui system ?) Anything else after menus and dialogs ? > But this is a great start! Thanks
Adding self to CC if not already on
Ticket moved to Redmine (migrating www component tickets) see https://redmine.documentfoundation.org/issues/1546
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyBeginner SkillScript ) [NinjaEdit]
Remove LibreOffice Dev List from CC on EasyHacks (curtailing excessive email to list) [NinjaEdit]