Re: [Libreoffice-ux-advise] [PATCH] fdo#34772 Word count / statistics in the status bar
Thanks for the help! I created a followup patch that makes the strings as resources: https://bugs.freedesktop.org/attachment.cgi?id=62063 Review: https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=34772attachment=62063 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] [PUSHED] fdo#34772 Word count / statistics in the status bar
I created a patch to update help content: https://bugs.freedesktop.org/attachment.cgi?id=62112 Review: https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=34772attachment=62112 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#34772 Word count / statistics in the status bar
On Sat, May 26, 2012 at 9:27 PM, Ivan Timofeev timofeev@gmail.com wrote: On 26.05.2012 22:06, Ivan Timofeev wrote: this patch makes scrolling in writer impossible :( it always brings the view back to the cursor Oops, wait. That happens only if a document contains the Page Count field (Insert - Fields - Page Count). WTF? Why it causes a recount every second?... I'm hazarding a guess that the page count field updates based on a timer (say, every second), causing a state change, which causes a recount. I didn't know that a recount causes the view to scroll to the cursor, but it might be happening because of trying to count the number of selected words. So this is a bug in Writer, not in this patch... Will file it / poke about in bugzilla. Can you share the bug once you open it? I'd like to investigate this in connection with word counting. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#34772 Word count / statistics in the status bar
I have confirmed that the word counting logic somehow focuses on the cursor, and I'll either fix that or follow a model similar to the word count dialog where we update in response to editing actions only. Unfortunately I'm currently on the road for a couple of days. I'll continue working on it on Saturday most likely. If the regressions are too bad we can revert the change until we have a fix. Sorry for the trouble. On May 31, 2012 4:29 PM, Ivan Timofeev timofeev@gmail.com wrote: Another nasty side-effect: https://bugs.freedesktop.org/**show_bug.cgi?id=50540https://bugs.freedesktop.org/show_bug.cgi?id=50540 Who could have thought! ( *pensive* I hereby confirm that my claims like This patch is safe are not valid anymore.) Regards, Ivan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Bug 50386 - Page count field makes scrolling impossible
Hello. = Bugs = https://bugs.freedesktop.org/show_bug.cgi?id=50386 https://bugs.freedesktop.org/show_bug.cgi?id=50540 = Patch = https://bugs.freedesktop.org/attachment.cgi?id=62532 = Patch review = https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=50386attachment=62532 = Change = This patch fixes a regression caused by my fix for fdo#34772 (adding word count to the status bar). The code used to count words was wrapped in StartAction/EndAction, which seem to be meant for input actions based on keyboard/mouse. EndAction calls UpdateCrsr with the SwCrsrShell::SCROLLWIN flag, resulting in the behavior described in fdo#50386 and fdo#50540. We were calling it directly (Start/EndAction) and indirectly (through SwWrtShell::GetUpdatedDocStat). I removed the direct calls and replaced the SwWrtShell call with SwDoc::GetUpdatedDocStat, which doesn't call Start/EndAction. Can someone advise on whether we need the SwWait? It's there because I initially copied the code from wordcountdialog.cxx, but I'm not sure whether we actually need it (or need it to lock the dispatcher either). Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Re: [PATCH] Bug 50386 - Page count field makes scrolling impossible
On 06/06/2012 12:49 PM, Michael Meeks wrote: Right ! :-) also, any chance of a screenshot of the updated count in the status bar we can add to your nice entry (thanks for adding that) here: https://wiki.documentfoundation.org/ReleaseNotes/3.6 Thanks ! Michael. Done! :) Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#50141: Word Count Characters (with spaces) incorrect with Numbering on
= Bug = https://bugs.freedesktop.org/show_bug.cgi?id=50141 = Patch = https://bugs.freedesktop.org/attachment.cgi?id=62850 = Patch Review = https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=50141attachment=62850 = Changes = There was a typo in the character counting code of text nodes. When a numbered list is detected, the code attempts to add the character count of the item number to the total count, but ends up overwriting it instead (uses '=' instead of '+='). This resulted in the item number strings to be the only ones counted in a numbered list. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#46757 Word/character count incorrect with record changes enabled
= Bug = https://bugs.freedesktop.org/show_bug.cgi?id=46757 = Patch = https://bugs.freedesktop.org/attachment.cgi?id=62967 = Patch Review = https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=46757attachment=62967 = Changes = We were ignoring redlined (deleted) text when counting characters, but not when counting words or characters without spaces. We now mask all redlined/hidden content from the expanded node text before operating on it. = Open Issues = One problem that remains with this patch is document statistics. When you save the document, SwXMLExport::SwXMLExport disables redlining deleted changes (http://cgit.freedesktop.org/libreoffice/core/commit/?id=6af264883910fe31433b4164b1956f4f9ed75ecb), which leads to SwTxtNode::CountWords counting the deleted text instead of masking it. It appears that was done as a bug fix. Unfortunately, it was fixing a bug from 2001, and information on such bugs are not available anymore. The attached patch leaves the broken document statistics behavior as is, and I'll file a separate bug to track it. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#46757 Word/character count incorrect with record changes enabled
On Fri, Jun 15, 2012 at 5:37 PM, Caolán McNamara caol...@redhat.com wrote: Definitely was bogus count before fix, and correct count afterwards. Pushed to master now. Sorry for delay. I should cook up a regression test for this. Thanks for pushing the patch. I can add the regression test myself if you give me a couple of pointers; e.g. where to add it, or the source of a similar test. If you do add it yourself, please share the commit so that I can learn to add tests for my changes in the future. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#46757 Word/character count incorrect with record changes enabled
On Fri, Jun 15, 2012 at 10:54 PM, Caolán McNamara caol...@redhat.com wrote: What we could do with is the addition of a regression test for my fdo#50141 error where we lost the char count for the bullet/numbering :-). SwDoc::SetNumRule might be useful in setting some numbering directly on some part of a SwDoc if you're interesting in having a shot at that. Thanks for the pointer; I'll give it a try. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#44602 Modeless word count window hides when user clicks into note
Hello. = Bug = https://bugs.freedesktop.org/show_bug.cgi?id=44602 = Patch = https://bugs.freedesktop.org/attachment.cgi?id=63423 = Patch Review = https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=44602attachment=63423 = Changes = The word count dialog wasn't registered as a child window in the SwView interface. Now it is. = Testing = make check Ad-hoc testing Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#44602 Modeless word count window hides when user clicks into note
Gerrit change: https://gerrit.libreoffice.org/236 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Can #32260 and 51135 be closed? -- both: Request for account
On 06/25/2012 05:56 PM, Philipp Riemer wrote: (2) Also Muhammad Haggag's request https://bugs.freedesktop.org/show_bug.cgi?id=51135 from 2012-06-15 is in UNCONFIRMED state. But here the situation seems to be different since I can only find three mails in total from him in Feb 2012 on the mailing list (see https://www.google.com/search?q=Muhammad%20Haggagsitesearch=%25%28archive_url%29s%2F#hl=entbs=cdr:1%2Ccd_min%3A1%2F1%2F2010%2Ccd_max%3A6%2F25%2F2012sclient=psy-abq=Muhammad+Haggag+site%3Ahttp%3A%2F%2Flists.freedesktop.org%2Farchives%2Flibreoffice%2Foq=Muhammad+Haggag+site:http%3A%2F%2Flists.freedesktop.org%2Farchives%2Flibreoffice%2Faq=faqi=aql=gs_l=serp.12...9421.9795.0.13069.3.3.0.0.0.0.63.177.3.3.0...0.0.uYm14PDWpJgpbx=1bav=on.2,or.r_gc.r_pw.r_qf.,cf.osbfp=3892739cde4f876ebiw=1440bih=812). Since Muhammad seems to be not interested anymore - can this request be changed into a closed state as well? I'm actually interested :) Michael told me to file the bug and ping him, which I did. He hasn't responded yet, so I didn't want to pester him about it yet in case he's busy (especially with the move to gerrit, I assumed this might not be needed anymore). Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#31005: Table Autoformats does not save/apply all properties
Hello. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=31005 Patch: = https://bugs.freedesktop.org/attachment.cgi?id=60462 Patch review: === https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=31005attachment=60462 Summary: = Extended the number of properties supported in AutoFormats, mainly for Writer. Borders, border styles, table shadow, cell spacing, and text flow options are now part of autoformats. AutoFormat file format was modified so that Writer can use writer-specific types in the format without having to expose them to Calc. Calc treats such data as binary blobs that it can skip over. The same mechanism allows Calc to create autoformats that can be read by Writer, even when they're missing the Writer-specific types. Detailed Changes (copied from patch): This change expands the number of properties supported by autoformats, mainly for Writer. Some improvements affect Calc as well (e.g. border styles are now preserved for Calc). Common: boxitem.hxx, frmitems.cxx * Added a new version for SvxBoxItem serialization that includes border styles. * Updated SvxBoxItem and SvxBorderLine serialization logic accordingly. Writer: fmtornt.hxx, attrfrm.cxx * Added serialization/deserialization logic for SwFmtVertOrient. Writer: tblafmt.hxx, tblafmt.cxx, ndtbl.cxx * Updated file version for autotbl.fmt to be SOFFICE_FILEFORMAT_50. * Autoformats now record the text orientation and vertical alignment of table cells. * Autoformats now record the following table-level properties: - Break - Keep with next paragraph - Repeat heading - Allow table split across pages - Allow rows to break across pages - Merge adjacent line styles - Table shadow Writer: UndoTable.hxx, undtbl.cxx * Undo support for Repeat Heading in autoformat application. Calc: autoform.hxx, autoform.cxx * Added support for reading/writing writer-specific data as binary blobs. * Updated file version for autotbl.fmt to be SOFFICE_FILEFORMAT_50. Known Issues: * The sharing of autotbl.fmt between Calc and Writer is rather annoying, and leads to a lot of duplicate code. It might make more sense to split it into two files, but I'm not sure if autoformat sharing (between Calc and Writer) is an actively used feature. * Table-Text Flow-With Page Style is not applied, even though it's saved as part of the autoformat. I'll have to open a bug to track this. * The newly added properties were not added to AutoFormat preview (e.g. table shadow doesn't show up as part of autoformat preview, even if it's included in the autoformat). * The table properties in the Table, Columns, and Background tabs were untouched. Columns is for manual table layout, and it's not clear to me how it can be generalized as part of an autoformat (i.e. it's highly dependent on the exact number of rows/columns). Background is rather low priority, seeing as that cell background's already working. I ran out of steam for Table-Alignment and Table-Spacing. I'll probably follow up with another patch for those once I work on something other than AutoFormats :) QA === Ideally, I'd like to have someone do some testing to make sure autoformats are working as expected. I did a lot of ad-hoc testing for each newly-supported property, as well as old properties. However, one should not be trusted to test his own code, especially with such big changes :) Pieter, who reported the bug, is willing to do some testing provided he's given a Windows build. He's not a developer, so if there's an easy way to get him a Windows build with the changes, it'd be great. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 3-5] fdo#49208 ridiculous performance on certain .doc
On Tue, May 1, 2012 at 5:43 PM, Caolán McNamara caol...@redhat.com wrote: icu's string compare is very very slow when you just want to check for equality http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccc47b3db3eae25cc11bb709416c0b61747ca89e Is it OK to break Unicode equivalence (http://en.wikipedia.org/wiki/Unicode_equivalence) by doing a memory comparison? (I assume ICU does proper comparisons taking equivalence into account, hence why it's slow). Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Re: [PATCH] fdo#31005: Table Autoformats does not save/apply all properties
Oh - and one more thing :-) as we inch closer to the feature-freeze, it'd be great to update the 3.6 features page: http://wiki.documentfoundation.org/ReleaseNotes/3.6 For any substantial fixes / improvements. I'll update the release notes once I get confirmation from the bug reporter. He'll try the next nightly build on Windows and see if things work as they should. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Re: [PATCH] fdo#31005: Table Autoformats does not save/apply all properties
On Thu, May 3, 2012 at 11:24 AM, Michael Stahl mst...@redhat.com wrote: sorry for taking so long, but i had hoped that somebody else would perhaps be more familiar with table autoformats and review this rather substantial patch :) No problem. I'm improving my knowledge of AutoFormats and documenting it as I go, so hopefully it'll become clearer to anyone who reads the code. couldn't find anything obviously wrong with your patch; other than the email address which was invalid so i've replaced it with your gmail address, perhaps you have not configured git properly, try git config user.email. Ah, thanks for pointing it out. I updated my configuration. i did some trivial tweaks to your patch, to follow our coding standards added an m_ prefix to all new member variables, which makes things much easier to read (because with the implicit this you never know what kind of side-effects an assignment has); also i've split out the Undo thing into a separate commit. Cool. I actually tried to follow the convention that already existed in the code. I prefer member variable prefixes as well. (I have no clue what the 'a' prefix means). Is there an official style guideline somewhere? it is rather surprising and sub-optimal that all this autoformat stuff uses an awful binary format based on direct serialization of implementation details; this is very brittle and it would be nice for example, if i read the autotbl.fmt with your patch in an old LO without the patch, the old version cannot read it at all. a text-based format (e.g. XML) would be much nicer, in case you want to do further work in this area :) Sure, I opened a bug: Writer/Calc: Use XML for serializing table autoformats instead of the current brittle binary format https://bugs.freedesktop.org/show_bug.cgi?id=49437 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#34772 Word count / statistics in the status bar
Hello. (Ux folks, please advise on the UX/Localization section below). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34772 Patch: = https://bugs.freedesktop.org/attachment.cgi?id=61962 Patch review: === https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=34772attachment=61962 Changes (copied from patch): This change adds a new status bar control, SwWordCountStatusBarControl. The control shows the number of words selected as well as the number of words in the whole document. Double-clicking the control launches the modeless word count dialog. Verification: == I tested with small documents (to the tune of 30 pages, ~3500 words). I'd like to try it out on a large/huge document to make sure there's no performance impact. Are there any standard large documents used for LO performance testing? UX/Localization: = Currently the status bar displays counts in the form: Words: number-of-selected-words/total-number-of-words. It's not clear at a glance what the numbers mean. It looks like this: http://imgur.com/3WqVD How do you suggest we go about displaying this information clearly, hopefully without being overly verbose? Also, I'm not sure how localizable string literals are handled in the code base. Does LO use something like gettext, or do I have to explicitly add a string resource and load it? Open Issues/Questions: * What's the point of viewsh.sdi? (compared to _viewsh.sdi). _viewsh.sdi seems to be referencing the methods actually getting invoked for word-count related logic. * swriter.sdi: I based the entry for StateWordCount on StatePageCount. I'm not sure what the fields mean (e.g. StatusBarConfig). * How do I update LO help with material for the new status bar field? I can see that other controls have their own documentation pages (e.g. helpcontent2/source/text/swriter/02/0801.xhp documents the page count control), but I don't know what template the files follow or what the fields mean. This is what I have so far: https://bugs.freedesktop.org/attachment.cgi?id=61963 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#34772 Word count / statistics in the status bar
On Tue, May 22, 2012 at 6:13 PM, Regina Henschel rb.hensc...@t-online.de wrote: Hi Muhammad, [...] I don't know about standard 'large' documents for testing. You can use the document 'part1' of the ODF specification, which has 864 pages. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.odt Thanks! That's exactly what I had in mind. Aside from slow loading (due to having a debug + dbgutil build), runtime performance seems unaffected compared to a vanilla build. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fdo#43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=43398
Cause:
dmapper used to treat the presence of a w:BiDi element in a paragraph's
properties as an indicator of RTL directionality, which is incorrect. A
w:BiDi element may have a value of 0, indicating LTR.
Fix: Inspect the integral value of w:BiDi elements before switching to RTL.
Only switch if it's non-zero.
Regards,
--Muhammad
From ed209e3a36f74f7826616deb24e7000b6216af32 Mon Sep 17 00:00:00 2001
From: Muhammad Haggag mhag...@gmail.com
Date: Wed, 1 Feb 2012 20:56:12 +0200
Subject: [PATCH] dmapper: Switch paragraphs to RTL based on the value of
w:BiDi.
This is a fix for 43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified.
Cause: dmapper used to treat the presence of a w:BiDi element in a paragraph's properties as an indicator of RTL directionality, which is incorrect. A w:BiDi element may have a value of 0, indicating LTR.
Fix: Inspect the integral value of w:BiDi elements before switching to RTL.
---
writerfilter/source/dmapper/DomainMapper.cxx |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/writerfilter/source/dmapper/DomainMapper.cxx b/writerfilter/source/dmapper/DomainMapper.cxx
index 851ded2..34c23f7 100644
--- a/writerfilter/source/dmapper/DomainMapper.cxx
+++ b/writerfilter/source/dmapper/DomainMapper.cxx
@@ -1812,8 +1812,13 @@ void DomainMapper::sprmWithProps( Sprm rSprm, PropertyMapPtr rContext, SprmType
}
break; // sprmPOutLvl
case NS_sprm::LN_PFBiDi:
-rContext-Insert(PROP_WRITING_MODE, false, uno::makeAny( text::WritingMode2::RL_TB ));
-rContext-Insert(PROP_PARA_ADJUST, false, uno::makeAny( style::ParagraphAdjust_RIGHT ));
+{
+if (nIntValue != 0)
+{
+rContext-Insert(PROP_WRITING_MODE, false, uno::makeAny( text::WritingMode2::RL_TB ));
+rContext-Insert(PROP_PARA_ADJUST, false, uno::makeAny( style::ParagraphAdjust_RIGHT ));
+}
+}
break; // sprmPFBiDi
case NS_ooxml::LN_EG_SectPrContents_bidi:
--
1.7.5.4
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified
On Thu, Feb 2, 2012 at 2:01 PM, Noel Power nopo...@suse.com wrote: very nice patch, looking at the spec I agree and this looks like a credible fix for me so pushed to master. Look forward to more like this, thanks Thanks for the review! If you'd pardon my absolute noobiness, do I have access to push to master? I checked out the code from the anongit repository. p.s. I you haven't already can you confirm your contribution is under the MPL 1.1 / GPLv3+ / LGPLv3+ license(s) I can put my contribution is under whichever license would make your lives easier :) Do I need to do anything or write it down in the commit message? I didn't see any mention of license requirements/guidelines under: http://wiki.documentfoundation.org/Development#Preparing_patches Thanks, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified
On Thu, Feb 2, 2012 at 5:13 PM, Muhammad Haggag mhag...@gmail.com wrote: On Thu, Feb 2, 2012 at 2:01 PM, Noel Power nopo...@suse.com wrote: very nice patch, looking at the spec I agree and this looks like a credible fix for me so pushed to master. Look forward to more like this, thanks Thanks for the review! If you'd pardon my absolute noobiness, do I have access to push to master? I checked out the code from the anongit repository. Ah, disregard my question--I thought you were asking me to push. Now I see that you were saying you've already pushed it. Another question though, what to do about the bug? Will you resolve or close it, or should I do that? Or is it the tester(s)? Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bug 37775 - EasyHack: Recent Documents not updated by Save Save As...
Hello, folks. begin quote from bug, comment 4 I'm investigating, and it seems to me that the current behavior is by design. Whether that design is sensible is up for debate. The current behavior is that a document is added to the Recent Documents list when it's closed (OApplicationController::disposing, line 437 in AppController.cxx: http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/app/AppController.cxx). To walk through the repro scenario: 1. Create and save new document A - Current document is A. 2. Modify and Save As document B - Current document is now B. A was not closed, merely renamed. 3. Close Writer - Document B closes, and writes itself to the Recent Documents list. 4. On startup, you only see B, the document that closed. I checked MS Word 2007's behavior, and it updates the list immediately on Open, Save, and Save As. If the current LO behavior is indeed inappropriate, we can modify the all document loading/saving operations (Open, Save, Save As, Save All, etc.) handlers to also update the Recent Documents list. /end quote Any objections to modifying the behavior of: Save, Save As, Save All, and Open (through File-Open or the list of recent documents) to update the recent documents list? Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Bug 37775 - EasyHack: Recent Documents not updated by Save Save As...
Forgot to add bug link: https://bugs.freedesktop.org/show_bug.cgi?id=37775 On Thu, Feb 2, 2012 at 11:04 PM, Muhammad Haggag mhag...@gmail.com wrote: Hello, folks. begin quote from bug, comment 4 I'm investigating, and it seems to me that the current behavior is by design. Whether that design is sensible is up for debate. The current behavior is that a document is added to the Recent Documents list when it's closed (OApplicationController::disposing, line 437 in AppController.cxx: http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/app/AppController.cxx). To walk through the repro scenario: 1. Create and save new document A - Current document is A. 2. Modify and Save As document B - Current document is now B. A was not closed, merely renamed. 3. Close Writer - Document B closes, and writes itself to the Recent Documents list. 4. On startup, you only see B, the document that closed. I checked MS Word 2007's behavior, and it updates the list immediately on Open, Save, and Save As. If the current LO behavior is indeed inappropriate, we can modify the all document loading/saving operations (Open, Save, Save As, Save All, etc.) handlers to also update the Recent Documents list. /end quote Any objections to modifying the behavior of: Save, Save As, Save All, and Open (through File-Open or the list of recent documents) to update the recent documents list? Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#37775 - EasyHack: Recent Documents not updated by Save Save As...
Hello, Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37775 Patch link: https://bugs.freedesktop.org/attachment.cgi?id=56740 Patch Review: https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=37775attachment=56740 Changes (copied from patch): This patch changes LO behavior so that we update recent documents on file open, save, save as, save all, and close. The previous behavior was to only update the list on document close. = Changes = SfxPickList (sfxpicklist.cxx/hxx): . Extracted the logic to add a document to the Recent Documents list into a function of its own: AddDocumentToPickList - Simplified the logic used by removing the check of SfxObjectShell_impl::bWaitingForPickList (see SfxObjectShell_impl::bWaitingForPickList below for details) . Modified SfxPickList::Notify to call the aforementioned function on open, save, save-to, and save-as. SfxObjectShell::APISaveAs_Impl (objserv.cxx): . Modified it to allow picklist entry when doing Save As. SfxObjectShell_impl::bWaitingForPickList (objstor.cxx, objxtor.cxx, objshimp.hxx): . Removed this flag. It was used to indicate that a document wants to be added to the picklist, then cleared after it's added. Since we now always add documents to the picklist on saving, we no longer need it. = Verification = The change is in sfx2, so it should apply to all LO apps. I verified the new behavior in both writer and calc with the following actions: . File-Open . Open through File-Recent Documents-File Entry . File-Save . File-Save As . File-Save All . File-Close I tested saving both odt and docx for writer. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
License statement
Hi, My past and present patches for LibreOffice are contributed under LGPLv3+ / MPL 1.1. My future patches for LibreOffice are contributed under LGPv3+ / MPL 1.1 until further notice. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#37775 - EasyHack: Recent Documents not updated by Save Save As...
Including Ivan and list again. Dropped them accidentally. On Sun, Feb 12, 2012 at 2:12 PM, Muhammad Haggag mhag...@gmail.com wrote: On Sun, Feb 12, 2012 at 12:16 PM, Cor Nouws oo...@nouenoff.nl wrote: Ivan Timofeev wrote (12-02-12 09:21) @ux-team: Do we really need such a feature? I mean, users don't want to open a document from Recent documents, if it is already opened, do they? Indeed, me thinks that the real improvement is the change of the recent documents with all types of saving and closing. File Open does not look useful to me. It's not very useful, but it could be argued that it's logically sound--the Recent Documents list is updated whenever there's document activity, and Open is definitely a document activity. With the patch the way it is, opening a file that is already in the middle of the Recent Documents list will move it to the top of the list immediately. The reason this is not very useful is that Close would've updated it eventually, rendering it redundant except in the case of a LO crash. It's worth noting that this is what MS Word 2007 does, too (if we care about matching behavior). If you're still not in favor, I can remove the update on Open and post another patch. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] [PATCH] fdo#37775 - EasyHack: Recent Documents not updated by Save Save As...
On Sun, Feb 12, 2012 at 3:38 PM, Cor Nouws oo...@nouenoff.nl wrote: Korrawit Pruegsanusak wrote (12-02-12 13:30) IMHO the case which 'file open' would be useful is already described in the bug comment 0 and 4: saving with a new name doesn't get old name into the list. Yes, if that is the technical reason, and can't be (easily) solved different (as suggested below) I do not object to have it in! It's possible to solve that without having to update the list on open. We can intercept the beginning of the Save As operation and update the list with the old document. I uploaded a new patch that does that (and removed the list update on document open). Patch: https://bugs.freedesktop.org/attachment.cgi?id=57016 Patch review: https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=37775attachment=57016 Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] fdo#37775 - EasyHack: Recent Documents not updated by Save Save As...
On Tue, Feb 14, 2012 at 6:31 PM, Michael Meeks michael.me...@suse.com wrote: I've merged it to master, thanks so much for your work here; do you have another easy hack or some cleanup in your sights next ? :-) usually things start to occur to people after they've read around the code for a bit ;-) Thanks for pushing :) I'm currently investigating fdo#31005: https://bugs.freedesktop.org/show_bug.cgi?id=31005 I think I'll be focusing on bug fixing (rather than doing cleanup) for a while, and I'll probably be giving preference to old issues that have been bugging people for years. Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] fdo#48317 - Support jumping to next/previous change
There was another change that added help content, but I seem to have lost it due to the strange way submodules behave :( (committed in helpcontent2 followed by a ./g pull -r in core) I'll re-read the wiki on submodules, redo and re-submit the other change later. If it can be recovered, I'd love to know how. On Sat, Nov 24, 2012 at 2:16 PM, Muhammad Haggag (via Code Review) ger...@gerrit.libreoffice.org wrote: Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1156 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/corerefs/changes/56/1156/1 fdo#48317 - Support jumping to next/previous change Added two new writer commands: NextTrackedChange (FN_REDLINE_NEXT_CHANGE) and PreviousTrackedChange (FN_REDLINE_PREV_CHANGE). Rewrote the logic for Accept/Reject change (FN_REDLINE_ACCEPT_DIRECT and FN_REDLINE_REJECT_DIRECT) to work well with the newly introduced commands. Change-Id: I03d583bef4225409f69934f16db1854564c2db5f --- M officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu M scripting/workben/bindings/writermenubar.xml M sw/inc/cmdid.h M sw/inc/swcommands.h M sw/sdi/_viewsh.sdi M sw/sdi/swriter.sdi M sw/source/ui/app/mn.src M sw/source/ui/uiview/view2.cxx M sw/source/ui/uiview/viewstat.cxx M sw/uiconfig/sglobal/menubar/menubar.xml M sw/uiconfig/swform/menubar/menubar.xml M sw/uiconfig/swreport/menubar/menubar.xml M sw/uiconfig/swriter/menubar/menubar.xml M sw/uiconfig/swxform/menubar/menubar.xml 14 files changed, 180 insertions(+), 20 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1156 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I03d583bef4225409f69934f16db1854564c2db5f Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Muhammad Haggag mhag...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#48317 Help content for next/previous change navigation
https://gerrit.libreoffice.org/#/c/1163/ For some reason, gerrit did not send a review email. This is the help content for this fix: https://gerrit.libreoffice.org/1156 The fix was already submitted by Bosdonnat Cedric. Thanks, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] fdo#48317 Help content for next/previous change navigation
On Wed, Nov 28, 2012 at 1:13 PM, Miklos Vajna vmik...@suse.cz wrote: Also, I had to fix the helpcontent2 build after your patch, did you at least build-test your patch? If not, please always do so (along with runtime testing if possible) before submitting it to gerrit. Sorry for the trouble. I build and test patches before pushing them. I did verify that this one built and ran, and that the help content is showing up correctly. I just double-checked on my development machine (where that change is the last committed to helpcontent2), and it still builds fine. So either the breakage was introduced during merging or afterwards. What was the build error you ran into? Regards, --Muhammad ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] fdo#48317 Help content for next/previous change navigation
Hmm. At first I thought maybe sc help contents were building fine for me because they're being skipped (i.e. they're unchanged), but make helpcontent2.clean make helpcontent2 still succeeds. Perhaps we have different versions of the tools used to build/compile help? In any case, I'll keep the paragraph id limitation in mind for the future. Thanks, and sorry again for the trouble :) On Thu, Nov 29, 2012 at 6:08 PM, Miklos Vajna vmik...@suse.cz wrote: Hi Muhammad, On Thu, Nov 29, 2012 at 05:27:32PM +0200, Muhammad Haggag mhag...@gmail.com wrote: Sorry for the trouble. I build and test patches before pushing them. I did verify that this one built and ran, and that the help content is showing up correctly. I just double-checked on my development machine (where that change is the last committed to helpcontent2), and it still builds fine. So either the breakage was introduced during merging or afterwards. What was the build error you ran into? No problem, different configurations can result in different problems, I just wanted to make sure it at least worked for you. :-) The problem was that at least here the paragraph ids in xhp files are not optional, Stephan had the same problem. For the reference, here is the error: Entering /home/vmiklos/git/libreoffice/master-4git/helpcontent2/source/text/schart/02 Error: Duplicated entry. ID = LANG = en-US in File /home/vmiklos/git/libreoffice/master-4git/helpcontent2/source/text/shared/guide/redlining_navigation.xhp dmake: Error code 255, while making '../../../../unxlngx6.pro/misc/text_shared_guide.done' --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /home/vmiklos/git/libreoffice/master-4git/helpcontent2/source/text/shared/guide it seems that the error is inside '', please re-run build inside this module to isolate the error and/or test your fix: build_error.log should contain the captured output of the failed module(s) --- To rebuild a specific module: make .clean # optional make when the problem is isolated and fixed, re-run 'make' make[1]: *** [helpcontent2] Error 1 make[1]: Leaving directory `/home/vmiklos/git/libreoffice/master-4git' make: *** [helpcontent2] Error 2 05bd6789ba844772f9757fa1196175e9591ccd74 in help.git fixed it. But I have no idea at the moment how it didn't cause a problem at you. ;-) Best, Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice-commits] core.git: Changes to 'refs/changes/53/453/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/11/311/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/57/1157/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/36/236/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] help.git: Changes to 'refs/changes/63/1163/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
[Libreoffice-commits] core.git: Changes to 'refs/changes/56/1156/1'
___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
Re: [Libreoffice-ux-advise] [PATCH] fdo#37775 - EasyHack: Recent Documents not updated by Save Save As...
Including Ivan and list again. Dropped them accidentally. On Sun, Feb 12, 2012 at 2:12 PM, Muhammad Haggag mhag...@gmail.com wrote: On Sun, Feb 12, 2012 at 12:16 PM, Cor Nouws oo...@nouenoff.nl wrote: Ivan Timofeev wrote (12-02-12 09:21) @ux-team: Do we really need such a feature? I mean, users don't want to open a document from Recent documents, if it is already opened, do they? Indeed, me thinks that the real improvement is the change of the recent documents with all types of saving and closing. File Open does not look useful to me. It's not very useful, but it could be argued that it's logically sound--the Recent Documents list is updated whenever there's document activity, and Open is definitely a document activity. With the patch the way it is, opening a file that is already in the middle of the Recent Documents list will move it to the top of the list immediately. The reason this is not very useful is that Close would've updated it eventually, rendering it redundant except in the case of a LO crash. It's worth noting that this is what MS Word 2007 does, too (if we care about matching behavior). If you're still not in favor, I can remove the update on Open and post another patch. Regards, --Muhammad ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [PATCH] fdo#34772 Word count / statistics in the status bar
Hello. (Ux folks, please advise on the UX/Localization section below). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34772 Patch: = https://bugs.freedesktop.org/attachment.cgi?id=61962 Patch review: === https://bugs.freedesktop.org/page.cgi?id=splinter.htmlbug=34772attachment=61962 Changes (copied from patch): This change adds a new status bar control, SwWordCountStatusBarControl. The control shows the number of words selected as well as the number of words in the whole document. Double-clicking the control launches the modeless word count dialog. Verification: == I tested with small documents (to the tune of 30 pages, ~3500 words). I'd like to try it out on a large/huge document to make sure there's no performance impact. Are there any standard large documents used for LO performance testing? UX/Localization: = Currently the status bar displays counts in the form: Words: number-of-selected-words/total-number-of-words. It's not clear at a glance what the numbers mean. It looks like this: http://imgur.com/3WqVD How do you suggest we go about displaying this information clearly, hopefully without being overly verbose? Also, I'm not sure how localizable string literals are handled in the code base. Does LO use something like gettext, or do I have to explicitly add a string resource and load it? Open Issues/Questions: * What's the point of viewsh.sdi? (compared to _viewsh.sdi). _viewsh.sdi seems to be referencing the methods actually getting invoked for word-count related logic. * swriter.sdi: I based the entry for StateWordCount on StatePageCount. I'm not sure what the fields mean (e.g. StatusBarConfig). * How do I update LO help with material for the new status bar field? I can see that other controls have their own documentation pages (e.g. helpcontent2/source/text/swriter/02/0801.xhp documents the page count control), but I don't know what template the files follow or what the fields mean. This is what I have so far: https://bugs.freedesktop.org/attachment.cgi?id=61963 Regards, --Muhammad ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] [PATCH] fdo#34772 Word count / statistics in the status bar
On Tue, May 22, 2012 at 6:13 PM, Regina Henschel rb.hensc...@t-online.de wrote: Hi Muhammad, [...] I don't know about standard 'large' documents for testing. You can use the document 'part1' of the ODF specification, which has 864 pages. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.odt Thanks! That's exactly what I had in mind. Aside from slow loading (due to having a debug + dbgutil build), runtime performance seems unaffected compared to a vanilla build. Regards, --Muhammad ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] Fwd: [PATCH] fdo#48317 - Support jumping to next/previous change
Hello, Can you guys look at this change and advise whether it's OK from a UX perspective? Thanks! -- Forwarded message -- From: Muhammad Haggag (via Code Review) ger...@gerrit.libreoffice.org Date: Sat, Nov 24, 2012 at 2:16 PM Subject: [PATCH] fdo#48317 - Support jumping to next/previous change To: Cc: LibreOffice Developer List libreoff...@lists.freedesktop.org Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1156 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/56/1156/1 fdo#48317 - Support jumping to next/previous change Added two new writer commands: NextTrackedChange (FN_REDLINE_NEXT_CHANGE) and PreviousTrackedChange (FN_REDLINE_PREV_CHANGE). Rewrote the logic for Accept/Reject change (FN_REDLINE_ACCEPT_DIRECT and FN_REDLINE_REJECT_DIRECT) to work well with the newly introduced commands. Change-Id: I03d583bef4225409f69934f16db1854564c2db5f --- M officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu M scripting/workben/bindings/writermenubar.xml M sw/inc/cmdid.h M sw/inc/swcommands.h M sw/sdi/_viewsh.sdi M sw/sdi/swriter.sdi M sw/source/ui/app/mn.src M sw/source/ui/uiview/view2.cxx M sw/source/ui/uiview/viewstat.cxx M sw/uiconfig/sglobal/menubar/menubar.xml M sw/uiconfig/swform/menubar/menubar.xml M sw/uiconfig/swreport/menubar/menubar.xml M sw/uiconfig/swriter/menubar/menubar.xml M sw/uiconfig/swxform/menubar/menubar.xml 14 files changed, 180 insertions(+), 20 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1156 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I03d583bef4225409f69934f16db1854564c2db5f Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Muhammad Haggag mhag...@gmail.com ___ LibreOffice mailing list libreoff...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[PATCH] fdo#48317 - Support jumping to next/previous change
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1156 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/56/1156/1 fdo#48317 - Support jumping to next/previous change Added two new writer commands: NextTrackedChange (FN_REDLINE_NEXT_CHANGE) and PreviousTrackedChange (FN_REDLINE_PREV_CHANGE). Rewrote the logic for Accept/Reject change (FN_REDLINE_ACCEPT_DIRECT and FN_REDLINE_REJECT_DIRECT) to work well with the newly introduced commands. Change-Id: I03d583bef4225409f69934f16db1854564c2db5f --- M officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu M scripting/workben/bindings/writermenubar.xml M sw/inc/cmdid.h M sw/inc/swcommands.h M sw/sdi/_viewsh.sdi M sw/sdi/swriter.sdi M sw/source/ui/app/mn.src M sw/source/ui/uiview/view2.cxx M sw/source/ui/uiview/viewstat.cxx M sw/uiconfig/sglobal/menubar/menubar.xml M sw/uiconfig/swform/menubar/menubar.xml M sw/uiconfig/swreport/menubar/menubar.xml M sw/uiconfig/swriter/menubar/menubar.xml M sw/uiconfig/swxform/menubar/menubar.xml 14 files changed, 180 insertions(+), 20 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1156 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I03d583bef4225409f69934f16db1854564c2db5f Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Muhammad Haggag mhag...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] fdo#48317 Help content for Next/Previous change navigation
Hi, I have submitted a patch for review: https://gerrit.libreoffice.org/1157 To pull it, you can do: git pull ssh://gerrit.libreoffice.org:29418/core refs/changes/57/1157/1 fdo#48317 Help content for Next/Previous change navigation Change-Id: Ia12cea9a3d7dedcd9533de3332e224279e8c3160 --- M helpcontent2 1 file changed, 0 insertions(+), 0 deletions(-) -- To view, visit https://gerrit.libreoffice.org/1157 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ia12cea9a3d7dedcd9533de3332e224279e8c3160 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Muhammad Haggag mhag...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
fdo#48317 Help content for Next/Previous change navigation
Muhammad Haggag has abandoned this change. Change subject: fdo#48317 Help content for Next/Previous change navigation .. Patch Set 1: Abandoned Ignore this. I can't logerrit to submit a proper change in helpcontent2. -- To view, visit https://gerrit.libreoffice.org/1157 To unsubscribe, visit https://gerrit.libreoffice.org/settings Gerrit-MessageType: abandon Gerrit-Change-Id: Ia12cea9a3d7dedcd9533de3332e224279e8c3160 Gerrit-PatchSet: 1 Gerrit-Project: core Gerrit-Branch: master Gerrit-Owner: Muhammad Haggag mhag...@gmail.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
