Ищу желающих поучаствовать в проекте по созданию учетной системы

14:56 < outoftime> I'm thinking about helping to Qt based project that 
                   needs *.ods preview\print functionality. Because 
                   LibreOffice already can do this I'm curious about how 
                   it done. Could you point me to the right place or give 
                   me a short comment about LibreOffice codebase and 
                   where I can find what I'm looking for?
14:57 < outoftime> This qbalance https://github.com/morozovvl/qbalance 
                   and subproject for *.ods preview 
                   https://github.com/morozovvl/odfpreviewlib
14:58 <@noelgrandin> outoftime, your best bet is to run LibreOffice and 
                     make it generate a preview image
14:59 < tml_> you mean, do we have a nicely separate small library that 
              provides an "give me a preview of this ods document" 
              functionality, but nothing more? no.
15:02 <@erAck> tml_: pass the Thumbnails/thumbnail.png to a viewer?
15:03 < mikekaganski> ... which would not fit "print" requirement, and 
                      likewise preview, too
15:03 < tml_> erAck: only that the thumbnail.png is opitional, and 
              ridiculously low resolution, isn't it?
15:04 < outoftime> noelgrandin: this is how it was managed before. 
                   LibreOffice and dependency program. It is good for 
                   quick solution but has bad UX.
15:04 <@cloph> if you can already display pdf, let LibreOffice convert to 
               pdf - that suits printing better than a image..
15:04 < tml_> UX? if you run libreoffice with the command-line option to 
              covert to png, there is no user interface
15:04 < tml_> (or to pdf, indeed)
15:05 < mikekaganski> outoftime: different LibreOffice functions are 
                      interdependent, and there's no "embeddable 
                      library", as tml_ said
15:24 < buovjaga> a user can have an experience without an interface :)
15:25 < outoftime> tml_: I didn't expect to see reusable library. Well, I 
                   had hope. Could you give an estimate if you have need 
                   to separate print\preview in enother lib, how 
                   difficult it would be?
15:25 < tml_> quite difficult and pointless
15:28 < outoftime> cloph: about using LO as command line tool I have read 
                   man and it is one of the possible cases for now, will 
                   test it in the future.
15:29 < outoftime> tml_: UX is user experience, not user interface. It is 
                   more about how comfortable to use it in general, not 
                   about how it looks.
15:30 < tml_> but how does the user even notice if some other software 
              runs libreoffice in the background to provide some 
              functionality?
15:30 < outoftime> tml_: why pointless? I just asked you to assume that 
                   you need it.
15:30 < tml_> unless by "user" you mean the *developer* of that other 
              software
15:30 < tml_> pointless to *us*
15:31 < outoftime> tml_: oh, I see.
15:33 < mikekaganski> ... which in the end might well show that the bas 
                      UX is not because of using LO that way, but becaise 
                      suboptimal implementation
15:36 < mikekaganski> outoftime: in fact, starting LO in listening 
                      headless mode, and controlling it using UNO calls 
                      is very much like using a library
15:36 < outoftime> Ok, I need more time to research how to use LO as 
                   command line tool. I have one more question about UNO
15:37 < outoftime> mikekaganski: yes, this is another way I'm willing to 
                   research: using LO as damon and speak with it using 
                   it's API
15:41 < tml_> just running separate libreoffice processes for each pdf 
              export is must simpler, though
15:47 < outoftime> tml_: yes, for solving single print\preview problem, 
                   but qbalance heavily relies on LO in editing reports, 
                   etc. That is why I'd like to compare all possible 
                   approaches.
15:59 < tml_>  // !!!!! due to old SV-Office Activate/Deactivate handling
16:00 < tml_> what is/was SV-Office?
16:07 < outoftime> The best what I have found about UNO contains a lot of 
                   references to some "SDK Developer's Guide", what is 
                   it? 
https://cgit.freedesktop.org/libreoffice/core/tree/ure/source/README
16:09 < tml_> https://wiki.openoffice.org/w/images/d/d9/DevelopersGuide_OOo3.1.0.pdf ?
16:10 < tml_> or, as HTML, 
https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide
16:10 < tml_> It will help you to write industrial strength UNO programs!
16:11 < tml_> no puny artesan programming!
16:12 < tml_> artisanal*
16:16 <@erAck> tml_: my guess, SV is StarView, the old multi-platform 
               library, so SV-Office would be the same as StarOffice 
               using SV ...
16:17 < tml_> as opposed to StarOffice running on Windows only without 
              any multi-platform library?
16:17 <@erAck> nah, there was no such thing
16:40 < djredaux> tml_: curious as to you opinion regarding the OO.o 3.2 
                  Developers Guide with regards as to how much of it is 
                  no longer valid for LO 6.2 and beyond? Put another way 
                  how important would you think an update to that 
                  particular work? (same question I suppose would hold 
                  for the Administrator Guide last updated for OO.o 3.2) 
                  Thanks.
16:41 < tml_> djredaux: I am the wrong person to reply to that, but if 
              somebody else wants to respond, they will
16:42 < tml_> also, I have no idea what the licensing of that 
              documentation is, whether "we" even could update it, or 
              host an updated version
16:42 < djredaux> I hope so.
16:42 < tml_> in general the UNO basics is the same as in OOo 3.2. that's 
              what the API and ABI stability for extensions that we hold 
              so dear means