Re: Which GUI toolkit should I learn so that I can "Hack the UI"

2024-05-06 Thread Pierre Vacher
I have extensions which display dialog windows in LibreOffice and which use
neither GTK nor QT but only the UNO API.

see: https://prrvchr.github.io/

One of the advantages is that the UNO API allows me to manage all my
dialogs in Python...

Le lundi 6 mai 2024, Michael Weghorn  a écrit :
> On 2024-05-03 19:15, Printf Debugging wrote:
>>
>> **Opinions invited**: I want to work on the UI, beyond small issues,
like creating custom widgets, notebookbar, tabbed UI etc. I feel that I
need to know a GUI toolkit well, like gtk or qt for that. So some days ago,
I started playing around with GTK. My question is that which toolkit will
be more useful? I picked GTK because we use .ui files for the UI, and being
good at GTK will somehow help when working on LO UI, but again I don't
know, that's just an idea.
>
> Starting with GTK generally sounds reasonable to me.
> Concepts are usually very similar in other toolkits (like Qt), so
learning GTK will also help understanding those better.
>
> In any case, I recommend explicitly testing the non-GTK case when doing
UI changes (with SAL_USE_VCLPLUGIN=gen and qt5/qt6/kf5/kf6 on Linux or by
testing on a different platform).
>


Fix 165948

2024-04-15 Thread Pierre Vacher
Hi all,

I need your help. I would like cherry pick tdf#156471
 to 7.6.7

So I created Fix#165948 ,
however there are only a few days left to validate it.

Thank you if you can validate it.

Pierre.


Re: ERROR: Published UNO API must not be changed incompatibly! tdf#51779

2024-04-13 Thread Pierre Vacher
I manage DateTimeWithTimezone

in jdbcDriverOOo .
I haven't touched the idl but I use the getter and setter getObject()

and setObject()

with as object the Struct corresponding to the data type.
I think you can make same with a DateTimeRange


Le sam. 13 avr. 2024 à 19:47, Devansh Varshney <
varshney.devansh...@gmail.com> a écrit :

> Hi,
> Currently I have made changes regarding the support of the SQL INTERVAL
> and now working to get it fit with the XRow and the XColumn in the
> https://github.com/LibreOffice/core/blob/4695d84b78d04af6682961732ae92655e03f49eb/connectivity/source/commontools/FValue.cxx#L2133
> (PatchSet 5 - https://gerrit.libreoffice.org/c/core/+/165012/5 is related
> to this)
>
> But, I am now at this page -
> https://wiki.documentfoundation.org/Development/Incompatible_UNO_API_Changes
>
> As after making the entry in the offapi/com/sun/star/sdb/XColumn.idl and
> the offapi/com/sun/star/sdbc/XRow.idl  I got this after running the make -
>
>  [~/libreoffice]
>  devansh   51779_support_for_sql_interval   make
> mkdir -p /home/devansh/libreoffice/instdir
> /home/devansh/libreoffice/solenv/bin/install-gdb-printers -a
> /home/devansh/libreoffice/instdir -c
> make -j 3  -rs -f /home/devansh/libreoffice/Makefile.gbuild build
> [UNO] offapi
> [DBc] offapi
> [ECH] CustomTarget/instsetoo_native/setup/setuprc
> [ECH] CustomTarget/instsetoo_native/setup/versionrc
> [LOC] top level modules: libreoffice
> interface type com.sun.star.sdb.XColumn number of direct methods changed
> from 20 to 21
> ERROR: Published UNO API must not be changed incompatibly!
> (If published UNO API shall be changed incompatibly after all, see
> <
> https://wiki.documentfoundation.org/Development/Incompatible_UNO_API_Changes
> >.)
> make[1]: *** [/home/devansh/libreoffice/solenv/gbuild/UnoApiTarget.mk:48:
> /home/devansh/libreoffice/workdir/UnoApiTarget/offapi.rdb] Error 1
> make[1]: *** Deleting file
> '/home/devansh/libreoffice/workdir/UnoApiTarget/offapi.rdb'
> make: *** [Makefile:290: build] Error 2
>
> BugZilla -https://bugs.documentfoundation.org/show_bug.cgi?id=51779
> Gerrit -https://gerrit.libreoffice.org/c/core/+/165012
>
> So, my question is should I go and make changes after the consensus or
> should I not make these changes as this will disrupt the backward
> compatibility and prevent disruptions for existing users and extensions.
>
> This is what I have added in the offapi/com/sun/star/sdb/XRow.idl
>
> /** gets the value of a column in the current row as an SQLINTERVAL value.
> @param columnIndex
> the first column is 1, the second is 2,
> @returns
> the column value; if the value is SQL NULL, the result is a
> default-constructed SqlInterval
> @throws SQLException
> if a database access error occurs.
> */
> com::sun::star::util::SqlInterval getSqlInterval([in]long columnIndex)
> raises (SQLException);
>
>
>
> and the offapi/com/sun/star/sdbc/XColumn.idl
>
> /** gets the value of a column in the current row as an SQL INTERVAL value.
> @returns
> the column value; if the value is SQL NULL, the result is a
> default-constructed SqlInterval
> @throws SQLException
> if a database access error occurs.
> */
> com::sun::star::util::SqlInterval getSqlInterval()
> raises (com::sun::star::sdbc::SQLException);
>
>
>
> Thanks and Regards,
> Devansh
>


Re: copy part of text from api

2024-04-13 Thread Pierre Vacher
Otherwise, to insert data into a Writer document, merge fields are used.
It is independent of the content (odt, html) however you need XRowSet or
XResultSet as input...

Le sam. 13 avr. 2024 à 19:29, Andrew Pitonyak  a
écrit :

> I will not have access to check (probably only my phone for a week or
> two), but can you pull xtransferable content from a cursor or range?
>
> Get BlueMail for Android 
> On Apr 13, 2024, at 12:35 PM, Zorg  wrote:
>>
>> Hello
>>
>> Hope some can help us here
>>
>> Here is the  problem
>>
>>
>> We are developing our software using the uno api python (
>> https://github.com/Probesys/lotemplate)
>>
>> We try to copy a text in a odt file and paste it without loosing the
>> format of the text and without using the clipboard
>>
>> We know how to paste html
>>
>> https://github.com/Probesys/lotemplate/blob/master/lotemplate/classes.py
>> (line 165-185)
>>
>> but we don't know how we can't copy a selected text without loosing format
>>
>> Actually we use .insertString
>>
>>
>> https://github.com/Probesys/lotemplate/blob/master/lotemplate/Statement/ForStatement.py
>> (line 286)
>>
>>
>> I know it's possible to do it  using
>> com.sun.star.datatransfer.clipboard.SystemClipboard
>>
>> But in that case we must embed a Xserver inside the docker container what
>> we want to avoid
>>
>> So if anyone wants to give us a solution or a hint on how to do this
>>
>> thanks
>>
>> Zorg
>>
>>
>>


Base relationships management fix

2024-04-13 Thread Pierre Vacher
Hi all,

I am looking for a reviewer to correct the fact that Base cannot create
foreign keys on tables that are not in the default catalog and/or schema.

see: *Bug 160375*
 - Base does
not manage relationships outside the default catalog/schema

I produced a correction and I am looking for a reviewer to be able to
validate this fix.

see: Fix 165469


Thanks for your help

Pierre


Reviewers for Bug 160375 - Base does not manage relationships outside the default catalog/schema

2024-03-28 Thread Pierre Vacher
Hi all,

I would like to fix bug 160375
.
I propose PR 165367 , I am
looking for reviewers to validate it.
Thanks.


Re: Adding an implemented UNO interface

2023-09-05 Thread Pierre Vacher
If I modify TConnection.hxx to derive from XConnection2 instead of
Xconnection, and implement the new XConnection2 methods in all connection
objects relying on TConnection.hxx then the compilation passes but fails in
testing...

I have access in Base to the default schema (ie: XConnection2.getSchema())
with the native LibreOffice JDBC driver, so why are the tests not passing?

Le mar. 5 sept. 2023 à 08:35, Noel Grandin  a écrit :

>
>
> On Mon, 4 Sept 2023 at 21:54, Noel Grandin  wrote:
>
>>
>> On Mon, 4 Sept 2023 at 20:43, Lionel Élie Mamane 
>> wrote:
>>
>>> becomes an ambiguous base of class bar, as it is derived from twice
>>> :-|
>>>
>>> How do we solve that?
>>>
>>>
>> using using
>>
>>
>
> Sorry, could not resist that.
>
> But unfortunately, I'm wrong, I keep forgetting when "using
> Baseclass::foo" will work and when it wont.
>
> Likely you will have to implement disambiguation overrides like:
>
>virtual SAL_CALL void setFoo() override { Baseclass::setFoo(); }
>
>


Pierre Vacher license statement

2023-07-28 Thread Pierre Vacher
All of my past & future contributions to LibreOffice may be licensed
under the MPLv2/LGPLv3+ dual license.

Pierre Vacher