Vector screenshots for the manuals: better quality and more visually attractive
Hello,
You may already know that with Gtk 3, it is possible to take vector
screenshots
from a GUI. The utility created by Joachim Breitner (nomeata) takes care of
the
job:
https://github.com/nomeata/gtk-vector-screenshot
But, this does not work out of the box. I have tried to take vector
screenshots
from LibreOffice gtk3 gui, and it led to an immediate crash. I have
debugged the
soffice binary, and I came across several assertions that are checked and
some
aborts in case of specific threading situations. I have temporarily disabled
these assertions and aborts, and by further disabling the autosave,
everything
was fine, and I could take vector screenshots. The tiny patch is attached.
I have created a proof of concept document from "LibreOffice Writer Guide",
section titled “20. Customizing Writer”, and created vector screenshots in
SVG
format for almost all of the previously raster screenshots. The quality of
the
PDF output is much better, the file is more visually attractive and it is
better
for print and display.
Vector ODT:
https://wiki.documentfoundation.org/images/7/79/WG7120-CustomizingWriter-vector.odt
Vector PDF:
https://wiki.documentfoundation.org/images/4/4b/WG7120-CustomizingWriter-vector.pdf
There are few remaining things:
1. Vector screenshot does not add window decorations, so some workaround is
needed. For example, some toplevel Gtk widgets contain decorations in the
screenshots, so these can be used for containing the window contents.
2. Trying to take screenshots closes menus, etc, and this can be handled by
creating a delay in taking screenshots.
3. Not everything is vector. For example, document contents in LibreOffice
and
also toolbar and status bar icons are not vectors. This is because of the
way
text and images are rendered in LibreOffice. If you take screenshots from
other
applications, the output is different. Try Glade and Gedit for the
comparison.
On the development side, I doubt that having these aborts will be useful at
runtime. There are hundreds of aborts and thousands of asserts in the code
in which I
think should be revised. Crashing the application in case of some problem is
usually a bad idea.
Assertions in C++, and Why Not to Use assert()
https://web.archive.org/web/20191110223903/https://www.softwariness.com/articles/assertions-in-cpp/
Regards,
Hossein
diff --git a/comphelper/source/misc/solarmutex.cxx b/comphelper/source/misc/solarmutex.cxx
index 5d1052327154..8a35daa5c4bf 100644
--- a/comphelper/source/misc/solarmutex.cxx
+++ b/comphelper/source/misc/solarmutex.cxx
@@ -60,10 +60,10 @@ void SolarMutex::doAcquire( const sal_uInt32 nLockCount )
sal_uInt32 SolarMutex::doRelease( bool bUnlockAll )
{
-if ( !IsCurrentThread() )
-std::abort();
-if ( m_nCount == 0 )
-std::abort();
+//if ( !IsCurrentThread() )
+//std::abort();
+//if ( m_nCount == 0 )
+//std::abort();
const sal_uInt32 nCount = bUnlockAll ? m_nCount : 1;
m_nCount -= nCount;
diff --git a/framework/source/services/autorecovery.cxx b/framework/source/services/autorecovery.cxx
index 495d22cee201..1ff139785808 100644
--- a/framework/source/services/autorecovery.cxx
+++ b/framework/source/services/autorecovery.cxx
@@ -1467,7 +1467,7 @@ void AutoRecovery::implts_dispatch(const DispatchParams& aParams)
}
catch(const css::uno::RuntimeException&)
{
-throw;
+//throw;
}
catch(const css::uno::Exception&)
{
diff --git a/vcl/unx/gtk3/gtkinst.cxx b/vcl/unx/gtk3/gtkinst.cxx
index a60f33790505..6cb7f4abec62 100644
--- a/vcl/unx/gtk3/gtkinst.cxx
+++ b/vcl/unx/gtk3/gtkinst.cxx
@@ -342,8 +342,9 @@ void GtkYieldMutex::ThreadsEnter()
if (!yieldCounts.empty()) {
auto n = yieldCounts.top();
yieldCounts.pop();
-assert(n > 0);
-n--;
+//assert(n > 0);
+if(n>0)
+n--;
if (n > 0)
acquire(n);
}
@@ -351,7 +352,7 @@ void GtkYieldMutex::ThreadsEnter()
void GtkYieldMutex::ThreadsLeave()
{
-assert(m_nCount != 0);
+//assert(m_nCount != 0);
yieldCounts.push(m_nCount);
release(true);
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Hossein Noorikhah license statement
Hi, All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license. Regards, Hossein Noorikhah ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Updating LibreOffice API documentation at api.libreoffice.org
Hi, I am using the LibreOffice API website for C++ development using LO SDK: https://api.libreoffice.org/ I was wondering why it is stuck at LibreOffice 6.4. Also, the LibreOffice SDK C/C++ API Reference is also stuck at 6.4: https://api.libreoffice.org/docs/cpp/ref/index.html the same true is for the IDL Reference: https://api.libreoffice.org/docs/idl/ref/index.html A good choice would be generating such documents for different versions, keeping all versions on the website, while using the latest version as the default choice. Regards, Hossein ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi, You're right. Using .pro files for different directories is better than a single file. A single .pro file has problems caused from the overlap of include folders, in situations where things like this: #include and #include exist in two different files, in which the first "a" folder is different from the second "a", so that only one of these includes work. Performance can also be an issue. I cleaned up everything, built the project and re-generated the Qt Creator project files, and now everything seems to be fine. I am happy with the current qt integration, but I will try creating a per folder .pro files from all cxx/hxx files. Thanks, Hossein On Mon, Mar 1, 2021 at 11:50 AM Michael Weghorn wrote: > Hi, > > On 26/02/2021 16.02, Hossein Noorikhah wrote: > > On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn > wrote: > >> > >> > >> On 26/02/2021 13.05, Hossein Noorikhah wrote: > >>> workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code > >>> project has all the .cxx and .h files. > >> > >> Looking at 'vs-code-template.code-workspace', it seems to just include > >> the whole source tree as a directory, so I suspect that there's no > >> problem since simply all header and source files in there will be > included: > > > > So, why not do the same for the Qt Creator? It can cause no harm, since > > the build system is separate. Finding source files, adding them to a > single > > lo.pro file, and that's all. What do you think about such an approach? > > Maybe other useful file types can also be included. > > > > $ find -iname "*.cxx" -o -iname "*.hxx"|wc > >21243 21243 901070 > > Different modules can be built with different parameters (like defines, > include paths, compiler/linker flags), s.a. the .pro files. Mixing all > of them together and setting all of them for all source files wouldn't > really be "correct" in a strict sense. If I remember correctly, even > with the current approach, the flags for all libraries/executables in > one subdirectory are already "merged together". As long as there are no > conflicting options, this should be no problem in practice, though, and > *might* be no problem when doing everything it similarly in the > top-level lo.pro either. > > While those parameters in the .pro files are not relevant for the actual > build (since Qt Creator just calls 'make' anyway and that one does not > rely on what is set in the .pro files), Qt Creator uses the information > from the .pro files for its Clang Code Model, which provides e.g. > autocompletion, code navigation, displaying compiler warnings and errors. > > So I *guess* (but haven't tried) that just adding all the sources and > headers to lo.pro wouldn't give you a nice setup with the > '--enable-mergelibs' autogen option set either, since the code model > wouldn't work properly due to missing parameters (assuming that they are > not properly propagated to workdir/GbuildToJson, as it seems). > > > Conceptually, it would probably be "most correct" from a build system > perspective to have a separate .pro file for each library/executable > (e.g. to generate a single .pro file for each of the > 'workdir/GbuildToJson/Library/libvclplug_*' files instead of merging > them into 'vcl/vcl.pro'). > > > However, I'd say it makes sense to be pragmatic, so IMHO, it's a > question of what the practical advantages/disadvantages of changing the > current approach would be. > Since the current approach is working fine for me (and it has been like > that since I've been using it; I'm not the original author of > qtcreator-ide-integration), I didn't see a real "need" to further > evaluate changing the way of how this aspect is handled so far. > If there are practical advantages of changing that (to either just have > a single top-level .pro file or further split the current ones), I see > no reason not to do so. > > Two more thoughts on the current handling came to my mind: > > 1) You can also just build a single module by e.g. right-clicking on the > "vcl" directory in Qt Creator and selecting "build vcl".). It's also > possible to just load e.g. vcl.pro as a project instead of the whole > lo.pro. I've never really used that myself, since loading the full > project is reasonably fast and I build from command line most times > anyway, but it might be something to keep in mind when evaluating what > pros/cons different approaches have. > > 2) With the current approach, you just see those source files in the > project view that are actually compiled (e.g. don't see Windows-specific > files when building on Linux). That can be seen as either an advantage > or a disadvantage. > > > Regards, > Michael > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi, On Fri, Feb 26, 2021 at 3:34 PM Michael Weghorn wrote: > In a previous email, you had mentioned: > > > I had issues with other IDE integration outputs which need separate > > discussions. > > I'm wondering whether those might all have the same root cause. > > In any case, can you try again using e.g. the build params I had > mentioned earlier or those recommended in the wiki for development to > see whether that works for you as well? > It's probably best to run 'git clean -dxf' first for a fresh start. I could have cleaned the "core" folder, but I decided to remove it all, and clone again. I am using the exact same "autogen.input" you have provided, and now I am waiting for a complete rebuild. On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn wrote: > > > On 26/02/2021 13.05, Hossein Noorikhah wrote: > > workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code > > project has all the .cxx and .h files. > > Looking at 'vs-code-template.code-workspace', it seems to just include > the whole source tree as a directory, so I suspect that there's no > problem since simply all header and source files in there will be included: So, why not do the same for the Qt Creator? It can cause no harm, since the build system is separate. Finding source files, adding them to a single lo.pro file, and that's all. What do you think about such an approach? Maybe other useful file types can also be included. $ find -iname "*.cxx" -o -iname "*.hxx"|wc 21243 21243 901070 Regards, Hossein ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi, > qtcreator-ide-integration (and the other IDE integrations as well) uses > information from gbuild (the LO build system). > Does 'workdir/GbuildToJson/Library/libvcllo.so' have an entry > 'source/window/menu'? > > You can check e.g. by using > > grep -E --color 'source/window/menu( |$)' > workdir/GbuildToJson/Library/libvcllo.so > workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code project has all the .cxx and .h files. > It's weird that it tries to create a 'core/core.pro' and > 'core/core.pro.shared', I don't have any such files here. > Is it correct that directory > '/home/hossein/Projects/libreoffice/core/core/' does not exist? No, I don't have any directory named core/core. I'm going to remove the whole source directory and try building again. Regards, Hossein On Fri, Feb 26, 2021 at 1:57 PM Michael Weghorn wrote: > > On 26/02/2021 10.33, Hossein Noorikhah wrote: > > I am using the latest Ubuntu LTS. > > There is no autogen.input here, I usually run ./autogen.sh without any > > parameters, but I have this in autogen.lastrun: > > > > ./autogen.sh --with-distro=LibreOfficeLinux > > > > Although I think the last run of autogen.sh was without any parameters. > > If run without any parameters, './autogen.sh' will use the params set in > 'autogen.input', and if that's not present, those from > 'autogen.lastrun', so that's OK. > > My current autogen.input contains these params: > > --enable-ccache > --enable-dbgutil > --enable-werror > --enable-gtk3-kde5 > --enable-qt5 > --enable-kf5 > --without-doxygen > --with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/ > --enable-python=fully-internal > --with-valgrind > --enable-split-debug > --enable-ld=gold > --enable-gdb-index > --enable-online-update > > Not sure whether it's related to the qtcreator issue we're discussing, > but in case you should want to debug LO, you'll probably want > '--enable-debug' or '--enable-dbgutil'. > > > > > The vcl.pro file is also attached. Look at these results: > > > > hossein@linux:~/Projects/libreoffice/core/vcl$ find -iname "*.cxx"|wc > > 830 830 26203 > > hossein@linux:~/Projects/libreoffice/core/vcl$ find -iname "*.hxx"|wc > > 388 388 10798 > > hossein@linux:~/Projects/libreoffice/core/vcl$ wc vcl.pro > >816 1631 56830 vcl.pro > > hossein@linux:~/Projects/libreoffice/core/vcl$ grep .cxx vcl.pro | wc > > 202 405 15719 > > hossein@linux:~/Projects/libreoffice/core/vcl$ grep .hxx vcl.pro | wc > > 294 589 20919 > > > > A lot of files are missing in the vcl.pro > > qtcreator-ide-integration (and the other IDE integrations as well) uses > information from gbuild (the LO build system). > Does 'workdir/GbuildToJson/Library/libvcllo.so' have an entry > 'source/window/menu'? > > You can check e.g. by using > > grep -E --color 'source/window/menu( |$)' > workdir/GbuildToJson/Library/libvcllo.so ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi, I am using the latest git master, and here is the result of the command. The same error is shown when I set the paths and run "gbuild-to-ide" manually. - hossein@linux:~/Projects/libreoffice/core$ make qtcreator-ide-integration make -j 8 -rs -f /home/hossein/Projects/libreoffice/core/Makefile.gbuild gbuildtojson cd /home/hossein/Projects/libreoffice/core && /home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide --ide qtcreator --make make ERROR : creating pro file=/home/hossein/Projects/libreoffice/core/core/core.pro [Errno 2] No such file or directory: '/home/hossein/Projects/libreoffice/core/core/core.pro' Traceback (most recent call last): File "/home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide", line 1773, in emit with open(qt_pro_file, mode) as fpro: FileNotFoundError: [Errno 2] No such file or directory: '/home/hossein/Projects/libreoffice/core/core/core.pro' ERROR : creating pro.shared file=/home/hossein/Projects/libreoffice/core/core/core.pro.shared [Errno 2] No such file or directory: '/home/hossein/Projects/libreoffice/core/core/core.pro.shared' Traceback (most recent call last): File "/home/hossein/Projects/libreoffice/core/bin/gbuild-to-ide", line 1787, in emit with open(qt_pro_shared_file, mode) as fproshared: FileNotFoundError: [Errno 2] No such file or directory: '/home/hossein/Projects/libreoffice/core/core/core.pro.shared' Successfully created the project files. - Please note that I have cloned LibreOffice core in the ~/Projects/libreoffice folder, and then built it. sudo apt-get build-dep libreoffice cd ~/Projects/libreoffice git clone git://anongit.freedesktop.org/libreoffice/core cd core ./autogen.sh make Regards, Hossein On Fri, Feb 26, 2021 at 11:28 AM Michael Weghorn wrote: > > > On 26/02/2021 08.53, Michael Weghorn wrote: > > This is on Debian testing and I've checked that on Windows as well. > > Can you share your autogen.input (if present) and share your vcl.pro via > > pastebin (or send by email)? > > Now that the Jenkins CI builds have finished, I have merged the pending > patches. It may be worth trying again with current master first, in case > any of the changes might already have fixed the issue for your setup... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi Michael,
Not all sources are included in the project. Look at vcl/source/window/menu.cxx
https://opengrok.libreoffice.org/xref/core/vcl/source/window/menu.cxx
I can not find this file in vcl.pro or any other .pro file. Is it intentional?
Regards,
Hossein
On Thu, Feb 25, 2021 at 8:40 PM Hossein Noorikhah wrote:
>
> Hi Michael,
>
> Thank you for spending time to improve Qt Creator IDE support.
>
> Now I am using the latest LibreOffice master build which uses .pro.shared
> files.
> Everything works just fine, except that 'Replacement for "Desktop"' Qt kit,
> which does not cause harm to the build process. If this is unavoidable at this
> point, I am ok with it.
>
> I see these build configurations:
>
> 01-Global Build
> 02-Global tests -- quick tests (unitcheck)
> 03-Global tests -- slow tests (unitcheck, slowcheck, screenshot)
> 04-Global tests -- integration tests (unitcheck, slowcheck, screenshot,
> subsequentcheck)
> 05-Global tests -- performance tests (perfcheck)
> 06-Global tests -- tests (check)
> 07-Global build -- nocheck
> 08-Global build -- build-l10n-only
> 09-Global build -- build-non-l10n-only
> 10-Global build -- clean
> 11-Global build -- clean-build
> 12-Global build -- clean-host
>
> with the run settings as expected, having the correct executable and path in
> place.
>
> And, I am not using a separate build dir, but I thank you for adding support
> for
> that build configuration.
>
> I try to update the wiki entry "Development/IDE" according to your changes,
> and
> I appreciate your help in adding any relevant information.
>
> Regards,
> Hossein
>
>
> On Thu, Feb 25, 2021 at 5:58 PM Michael Weghorn wrote:
> >
> >
> > On 15/02/2021 12.26, Michael Weghorn wrote:
> > > In order to directly match an actual kit, one could try to retrieve the
> > > UUID for a valid kit from the settings in the Qt Creator profile and use
> > > that one when generating the *.pro.user files, but that's not ideal
> > > either in my opinion (e.g. one would have to "guess" what kit is the
> > > right one, rely on a specific Qt Creator profile path,...).
> > >
> > > I just recently read about *.pro.shared files [1] which are actually
> > > meant to share project settings. Those might actually be a better way to
> > > handle all of this.
> > > I'll probably take a closer look at some point in time.
> >
> > From commit e827cb144ee9886134a946c7a3b316f9eeb83168 ("qtcreator:
> > Create *.pro.shared files instead of *.pro.user") on, *.pro.shared files
> > will be generated.
> > If you still don't want to use the autogenerated and autoselected kit
> > with build/run settings, this will at least make sure you don't have to
> > configure your custom settings every time, since the *.pro.user file
> > holding the settings is no longer overwritten every time that
> > 'make qtcreator-ide-integration' is run.
> >
> > >> And for the contents of lo.pro, I still get "." as the first
> > >> subdirectory. I have to
> > >> manually change it to "../core".
> > >
> > > As mentioned in my previous email, I can take a quick look whether I can
> > > see anything obvious if you upload your generated files somewhere or
> > > send them by email and tell me the paths used in your case (and whether
> > > you use a separate build dir).
> >
> > I've seen a similar error message to yours when testing with a separate
> > build dir that is not on the same "hierarchy level" in the file system
> > as the source dir (srcdir: ~/development/git/libreoffice, builddir:
> > ~/temp/lobuild):
> >
> > ~/development/git/libreoffice/lo.pro:-1: error: Could not find .pro
> > file for subdirectory "../../development/git/libreoffice/UnoControls" in
> > "~/development/git/libreoffice/../../development/git/libreoffice/UnoControls".
> >
> > Pending Gerrit change [1] ("qtcreator: Create *.pro and *.pro.shared
> > files in builddir, not srcdir") (and its ancestors) should fix cases
> > where builddir != srcdir, hopefully fixing your problem as well (for
> > which I don't know the details, so can't explicitly test that).
> >
> > I'll update the wiki entry [2] later, once everything has been merged.
> >
> >
> > [1] https://gerrit.libreoffice.org/c/core/+/111553
> > [2] https://wiki.documentfoundation.org/Development/IDE#Qt_Creator
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi Michael,
Thank you for spending time to improve Qt Creator IDE support.
Now I am using the latest LibreOffice master build which uses .pro.shared files.
Everything works just fine, except that 'Replacement for "Desktop"' Qt kit,
which does not cause harm to the build process. If this is unavoidable at this
point, I am ok with it.
I see these build configurations:
01-Global Build
02-Global tests -- quick tests (unitcheck)
03-Global tests -- slow tests (unitcheck, slowcheck, screenshot)
04-Global tests -- integration tests (unitcheck, slowcheck, screenshot,
subsequentcheck)
05-Global tests -- performance tests (perfcheck)
06-Global tests -- tests (check)
07-Global build -- nocheck
08-Global build -- build-l10n-only
09-Global build -- build-non-l10n-only
10-Global build -- clean
11-Global build -- clean-build
12-Global build -- clean-host
with the run settings as expected, having the correct executable and path in
place.
And, I am not using a separate build dir, but I thank you for adding support for
that build configuration.
I try to update the wiki entry "Development/IDE" according to your changes, and
I appreciate your help in adding any relevant information.
Regards,
Hossein
On Thu, Feb 25, 2021 at 5:58 PM Michael Weghorn wrote:
>
>
> On 15/02/2021 12.26, Michael Weghorn wrote:
> > In order to directly match an actual kit, one could try to retrieve the
> > UUID for a valid kit from the settings in the Qt Creator profile and use
> > that one when generating the *.pro.user files, but that's not ideal
> > either in my opinion (e.g. one would have to "guess" what kit is the
> > right one, rely on a specific Qt Creator profile path,...).
> >
> > I just recently read about *.pro.shared files [1] which are actually
> > meant to share project settings. Those might actually be a better way to
> > handle all of this.
> > I'll probably take a closer look at some point in time.
>
> From commit e827cb144ee9886134a946c7a3b316f9eeb83168 ("qtcreator:
> Create *.pro.shared files instead of *.pro.user") on, *.pro.shared files
> will be generated.
> If you still don't want to use the autogenerated and autoselected kit
> with build/run settings, this will at least make sure you don't have to
> configure your custom settings every time, since the *.pro.user file
> holding the settings is no longer overwritten every time that
> 'make qtcreator-ide-integration' is run.
>
> >> And for the contents of lo.pro, I still get "." as the first
> >> subdirectory. I have to
> >> manually change it to "../core".
> >
> > As mentioned in my previous email, I can take a quick look whether I can
> > see anything obvious if you upload your generated files somewhere or
> > send them by email and tell me the paths used in your case (and whether
> > you use a separate build dir).
>
> I've seen a similar error message to yours when testing with a separate
> build dir that is not on the same "hierarchy level" in the file system
> as the source dir (srcdir: ~/development/git/libreoffice, builddir:
> ~/temp/lobuild):
>
> ~/development/git/libreoffice/lo.pro:-1: error: Could not find .pro
> file for subdirectory "../../development/git/libreoffice/UnoControls" in
> "~/development/git/libreoffice/../../development/git/libreoffice/UnoControls".
>
> Pending Gerrit change [1] ("qtcreator: Create *.pro and *.pro.shared
> files in builddir, not srcdir") (and its ancestors) should fix cases
> where builddir != srcdir, hopefully fixing your problem as well (for
> which I don't know the details, so can't explicitly test that).
>
> I'll update the wiki entry [2] later, once everything has been merged.
>
>
> [1] https://gerrit.libreoffice.org/c/core/+/111553
> [2] https://wiki.documentfoundation.org/Development/IDE#Qt_Creator
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: FOSDEM 2021 Video Archives?
Hi, Please look at this message from FOSDEM website: Videos on video.fosdem.org 2021-02-11 All talks have been recorded and they will be made available on video.fosdem.org/2021 as soon as the presenter reviews their talk. For FOSDEM 2021, we make a mix of the original recording submitted by the presenter and the Q happening in the main room. To make sure that the result is up to our quality standards, we request that the original presenter reviews the video so the result contains no errors or mistakes. This can take a while. We expect that it will take some days to some weeks for all videos to become available at video.fosdem.org/2021. See our FAQ and video.fosdem.org/2021 for more information. https://fosdem.org/2021/news/2021-02-11-videos-on-fosdem/ On Wed, Feb 10, 2021 at 7:26 PM Ilmari Lauhakangas wrote: > > On 10.2.2021 17.54, Hossein Noorikhah wrote: > > I was searching for the FOSDEM 2021 video archives, but rather than a > > few videos from stands* and 2 youtube videos, I could not find > > anything else. Is there a chance that we can see the video archive any > > time soon? As the videos were pre-recorded**, I think It's a good idea > > to share them independent of what FOSDEM website does. Currently, > > live.fosdem.org is also down. > > > > * https://video.fosdem.org/2021/ > > ** https://research-fosdem.github.io/ > > Let's give FOSDEM staff a moment to get them up. I think they also have > a system, where the presenters are allowed to make edits to the videos > for a certain period. > > Ilmari > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi, On Thu, Feb 11, 2021 at 11:49 AM Michael Weghorn wrote: > I just double-checked it works for me with newly generated files and a > fresh Qt Creator profile taking these steps: > > 1. make sure Qt Creator is not running > > 2. Generate the IDE integration files: > > make qtcreator-ide-integration > I went through the sequence, and nothing has changed. It's a question for me: why do we need a fresh Qt Creator profile? In very rare situations, I had to clean up this profile. Also, I usually do not re-run ./autogen.sh because I didn't have any changes in the libs/configurations, and I only pulled the latest master from the git repository. This time, I re-ran autogen.sh again, and again nothing has changed. But, now I know what you're doing. I thought that only lo.pro is generated, but now I see that lo.pro.user is also being generated. That didn't help me, because the used Qt kit was not ok. I saw a manual Qt kit which is used for the configuration. It was called 'Replacement for "Desktop"', so I removed it and reconfigured the project using the appropriate kit. In this case, I had to add the previously discussed configurations manually. To create a viable solution that lasts even when you re-configure the project, I think it is needed to put all the configuration in .pro files, and not in .pro.user files, because they can be removed/changed at any time. And for the contents of lo.pro, I still get "." as the first subdirectory. I have to manually change it to "../core". I think these manual tweaks are necessary, at least for now. Regards, Hossein ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Added some information about Qt Creator IDE integration to the wiki
Hi,
Thanks for your attention.
I am also using "Qt Creator 4.14.0", and I am using the up-to-date git master. I
removed all the .pro.user and .pro files generated by the invocation of
"bin/gbuild-to-ide --ide qtcreator", using this tiny script:
for f in `find -name "*.pro.user"`
do
pro=${f/\.user/}
echo $f
rm $pro
rm $f
done
then regenerated .pro files using:
make qtcreator-ide-integration
and then loaded lo.pro in Qt Creator. In this stage, I had to:
1. Disable shadow build, otherwise I was getting several errors when I wanted to
build the project.
2. Remove qmake build step, otherwise I was also getting several errors when I
wanted to build the project.
3. Change "SUBDIRS = . \" to "SUBDIRS = ../core \", otherwise I wasn't able to
see core.pro get loaded and I was getting this error message:
/path/to/libreoffice/core/lo.pro: Could not find .pro file for subdirectory
"." in "/path/to/libreoffice/core/.".
4. Manually add the executable "instdir/program/soffice.bin", otherwise I was
getting this error message:
You need to set an executable in the custom run configuration.
After doing all these steps, things were fine. So, I think all these steps are
currently necessary, unless the "bin/gbuild-to-ide" script is further tuned.
I had issues with other IDE integration outputs which need separate discussions.
Regards,
Hossein
On Wed, Feb 10, 2021 at 7:51 PM Ilmari Lauhakangas
wrote:
>
> On 10.2.2021 18.13, Michael Weghorn wrote:
> > Hi Hossein,
> >
> > thanks! Could you possibly recheck whether all of the custom steps for
> > Qt Creator setup are still necessary with an up-to-date git master?
> >
> > Those 3 commits from Sunday were meant to simplify the setup a bit
> > (automatically set up run + build configurations), so it'd be
> > interesting to hear whether that actually works for you as well (I just
> > tested with Qt Creator 4.14 myself):
> >
> > *
> > https://git.libreoffice.org/core/+/77d5383c6e83fdcb268138f71601fa39c95a62aa%5E!
> > ("qtcreator: Don't create useless run configurations for subdirs")
>
> Gitiles has some weird glitch and shows the wrong commit for two of
> these. Working link:
>
> https://git.libreoffice.org/core/commit/77d5383c6e83fdcb268138f71601fa39c95a62aa
>
> > *
> > https://git.libreoffice.org/core/+/fdd9b20572435842bde076e3c35ef94d26f13b30%5E!
> > ("qtcreator: Drop some extra whitespace in .pro.user template")
> >
> > *
> > https://git.libreoffice.org/core/+/d2d6e5c235f35bf3f2137e8dab4b9b32b72430a8%5E!
> > ("qtcreator: Show actual names for build configurations")
>
> Working link:
> https://git.libreoffice.org/core/commit/d2d6e5c235f35bf3f2137e8dab4b9b32b72430a8
>
> Ilmari
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
FOSDEM 2021 Video Archives?
Hi, I was searching for the FOSDEM 2021 video archives, but rather than a few videos from stands* and 2 youtube videos, I could not find anything else. Is there a chance that we can see the video archive any time soon? As the videos were pre-recorded**, I think It's a good idea to share them independent of what FOSDEM website does. Currently, live.fosdem.org is also down. * https://video.fosdem.org/2021/ ** https://research-fosdem.github.io/ Regards, Hossein ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Added some information about Qt Creator IDE integration to the wiki
Hi, I have added some information about how to use Qt Creator for building, running and debugging LibreOffice in the appropriate section of the wiki: https://wiki.documentfoundation.org/Development/IDE#Qt_Creator I think other sections related to other IDEs also need to be revised and improved, because not everything works out of the box in the IDEs. Regards, Hossein ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Serious problems with Arabic text rendering
Hi, These problems are still there in today builds of latest LibreOffice pre-release (4.4.0~rc2). I'm using Ubuntu Linux with official prerelease PPA. The most problematic problem is the justification bug, reported here: https://bugs.freedesktop.org/show_bug.cgi?id=35320 The attached ODT file is a simple minimal working sample to show visible justification bug in Libreoffice. Is there a chance than someone can help fixing this issue? Please note that this bug existed in OpenOffice and it was fixed, and now OpenOffice works just fine with this sample, but Libreoffice creates bad results. 2013-10-29 15:48 GMT+03:30 Hossein Noorikhah hossein...@gmail.com: Hi, Starting with version LibreOffice 3.6, we had some issues with Arabic text rendering in LibreOffice. These issues got worse starting LO 4.0. I hoped that patches which some developers provided [1], may fix the bugs. But right now I'm using LO v4.1.2.3 and nearly most of the problems that have been fixed in OpenOffice versions prior to 3.0 are now visible again. For example these are serious and were all fixed prior to OpenOffice 3.0: 1. Text rendering cuts and continues out of the border. (attached picture 1) 2. Kashida placement in wrong position, in the free space between words (attached picture 2) 3. Losing paragraph direction, making RTL paragraph LTR. (attached picture 2) These not happen for every font, but using some popular fonts, these issues are visible, for example using Droid Arabic Naskh. Some users reported that they were forced to downgrade LibreOffice to avoid these issuses. We were working on localization before these problems, but right now it is very important to have a correct rendering engine before continuing UI translation. Considering the fact that many languages like Persian and Urdu use Arabic script, I think fixing bugs related to Arabic text rendering is important. Thanks Hossein [1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c4b9db8bbaed7acd064a4015fabe784c4fbca21 Test.odt Description: application/vnd.oasis.opendocument.text Test-ooo.pdf Description: Adobe PDF document Test-libreoffice.pdf Description: Adobe PDF document ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Serious problems with Arabic text rendering
Salaam, I'm using Microsoft Windows 7, but other users using Ubuntu Linux reported similar problems. Hossein 2013/10/29 Khaled Hosny khaledho...@eglug.org On Tue, Oct 29, 2013 at 03:48:01PM +0330, Hossein Noorikhah wrote: Hi, Starting with version LibreOffice 3.6, we had some issues with Arabic text rendering in LibreOffice. These issues got worse starting LO 4.0. I hoped that patches which some developers provided [1], may fix the bugs. But right now I'm using LO v4.1.2.3 and nearly most of the problems that have been fixed in OpenOffice versions prior to 3.0 are now visible again. For example these are serious and were all fixed prior to OpenOffice 3.0: 1. Text rendering cuts and continues out of the border. (attached picture 1) On what OS is that? Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] update service
Sounds great. I think it's a good assumption that updating is only needed on Windows. Look at Mozilla Firedox update. Update mechanism is available for Linux, but most distros disable it because they have their own update mechanism. I don't know exactly about Mac, but most of its uers have NeoOffice installed. On 4/14/11, Ryan Jendoubi ryan.jendo...@gmail.com wrote: On 13/04/11 21:20, Arnaud Versini wrote: Hello, I've found this library for Windows http://winsparkle.org/ . I think It could easier to implement this feature with. Arnaud That looks cool. Just to ask for even more, do you know of a library that's basically this but cross-platform? :) My own perfunctory Googling hasn't turned up anything. -r ___ 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
Re: [Libreoffice] update service
And I should metion that winsparkle is a port of sparkle from Mac OS to Windows. http://sparkle.andymatuschak.org/ So update mechanism for Mac OS can be created in somehow similar way. On 4/14/11, Hossein Noorikhah hossein...@gmail.com wrote: Sounds great. I think it's a good assumption that updating is only needed on Windows. Look at Mozilla Firedox update. Update mechanism is available for Linux, but most distros disable it because they have their own update mechanism. I don't know exactly about Mac, but most of its uers have NeoOffice installed. On 4/14/11, Ryan Jendoubi ryan.jendo...@gmail.com wrote: On 13/04/11 21:20, Arnaud Versini wrote: Hello, I've found this library for Windows http://winsparkle.org/ . I think It could easier to implement this feature with. Arnaud That looks cool. Just to ask for even more, do you know of a library that's basically this but cross-platform? :) My own perfunctory Googling hasn't turned up anything. -r ___ 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
