-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Just as a heads up, TDE has permanently lost LibreOffice integration due to the decisions of the upstream LibreOffice devs:
http://anzwix.com/a/LibreOffice/Remove%20TDE%20Integration%20(vclplug,%20Add...
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice. I'd like to schedule a community meeting on #trinity-desktop for this weekend, Saturday, at 2:00PM CST to discuss further.
Thanks!
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On 06/14/2017 05:35 PM, Timothy Pearson wrote: Just as a heads up, TDE has permanently lost LibreOffice
integration due to the decisions of the upstream LibreOffice devs:
http://anzwix.com/a/LibreOffice/Remove%20TDE%20Integration%20(vclplug,%20Add... Forgive my ignorance, but does this mean that Libre Office will not run on TDE or just that certain integrations will be removed? Thanks for the clarification.
Uwe Brauer
All LibreOffice integrations for TDE were removed. That means no native file pickers, the default "ugly" widgets, etc.
On Wednesday 14 June 2017 20.07:20 Timothy Pearson wrote:
Forgive my ignorance, but does this mean that Libre Office will not run on TDE or just that certain integrations will be removed? Thanks for the clarification.
Uwe Brauer
All LibreOffice integrations for TDE were removed. That means no native file pickers, the default "ugly" widgets, etc.
As far as I now I have not been using any integration ("Use LibreOffice dialog boxes") as an other choice resulted in unusable dialogs. As long as LO runs I don't care much for integration.
Thierry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Wednesday 14 June 2017 20.07:20 Timothy Pearson wrote:
Forgive my ignorance, but does this mean that Libre Office will not run on TDE or just that certain integrations will be removed? Thanks for the
clarification.
Uwe Brauer
All LibreOffice integrations for TDE were removed. That means no native file pickers, the default "ugly" widgets, etc.
As far as I now I have not been using any integration ("Use LibreOffice dialog boxes") as an other choice resulted in unusable dialogs. As long as LO runs I don't care much for integration.
Thierry
The biggest issue I have with LO is that their file picker is quite horrible, especially when one is used to the powerful TDE file picker. I find myself having to launch LO from the *command line* since I can select the file I want from a *shell* faster than their file picker. :-/
I wonder if we should all just file a bug report on their picker?
On Wednesday 14 Jun 2017 13:43:50 Timothy Pearson wrote:
On Wednesday 14 June 2017 20.07:20 Timothy Pearson wrote:
Forgive my ignorance, but does this mean that Libre
Office will not run on TDE or just that
certain integrations will be removed? Thanks for the
clarification.
Uwe Brauer
All LibreOffice integrations for TDE were removed. That means no native file pickers, the default "ugly" widgets, etc.
As far as I now I have not been using any integration ("Use LibreOffice dialog boxes") as an other choice resulted in unusable dialogs. As long as LO runs I don't care much for integration.
Thierry
The biggest issue I have with LO is that their file picker is quite horrible, especially when one is used to the powerful TDE file picker. I find myself having to launch LO from the *command line* since I can select the file I want from a *shell* faster than their file picker. :-/
I wonder if we should all just file a bug report on their picker?
I am regularly using Libreoffice Calc, (the spreadsheet), in TDE R14.0.4 in Debian 8.7, with no problems at all. Their file picker is perhaps not perfect, but it is FAR faster than the KDE4 file picker that I used for 6 years, before switching to TDE. I have also used LibreOffice Writer, (the word processor), in TDE with no problems at all.
I am not certain about this, because I very rarely use GTK programs now, but the LibreOffice file picker seems to me to be rather similar to the file picker on a GTK based program that I did use a lot some years ago, (that was the old GUI for Cadabra, a computer algebra program).
Chris
LO-TDE integration never worked for me. Indeed, that file picker in LO is horrible. Filing a bug report on LO bug tracker sounds like a good idea.
Janek
Dnia czwartek, 15 czerwca 2017, Chris Austin napisał:
On Wednesday 14 Jun 2017 13:43:50 Timothy Pearson wrote:
On Wednesday 14 June 2017 20.07:20 Timothy Pearson wrote:
Forgive my ignorance, but does this mean that Libre
Office will not run on TDE or just that
certain integrations will be removed? Thanks for the
clarification.
Uwe Brauer
All LibreOffice integrations for TDE were removed. That means no native file pickers, the default "ugly" widgets, etc.
As far as I now I have not been using any integration ("Use LibreOffice dialog boxes") as an other choice resulted in unusable dialogs. As long as LO runs I don't care much for integration.
Thierry
The biggest issue I have with LO is that their file picker is quite horrible, especially when one is used to the powerful TDE file picker. I find myself having to launch LO from the *command line* since I can select the file I want from a *shell* faster than their file picker. :-/
I wonder if we should all just file a bug report on their picker?
I am regularly using Libreoffice Calc, (the spreadsheet), in TDE R14.0.4 in Debian 8.7, with no problems at all. Their file picker is perhaps not perfect, but it is FAR faster than the KDE4 file picker that I used for 6 years, before switching to TDE. I have also used LibreOffice Writer, (the word processor), in TDE with no problems at all.
I am not certain about this, because I very rarely use GTK programs now, but the LibreOffice file picker seems to me to be rather similar to the file picker on a GTK based program that I did use a lot some years ago, (that was the old GUI for Cadabra, a computer algebra program).
Chris
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
--- Politechnika Łódzka Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.
On Wednesday 14 Jun 2017 13:43:50 Timothy Pearson wrote:
The biggest issue I have with LO is that their file picker is quite horrible, especially when one is used to the powerful TDE file picker. I find myself having to launch LO from the *command line* since I can select the file I want from a *shell* faster than their file picker. :-/
A trick to open a file rapidly in LibreOffice Calc: In a Konsole window, enter ls <filename>, (which can be done rapidly using Konsole's excellent tab partial auto completion), or else ls *.ods. Double click on the required file, click the file open toolbar icon in LibreOffice Calc, and middle click to paste the filename into the LibreOffice file picker. The required file opens instantly. I have just tested this several times for spreadsheets in my home directory, which has 8804 files and directories, (as determined by ls -1 | wc -l).
On Wed, Jun 14, 2017 at 1:35 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Just as a heads up, TDE has permanently lost LibreOffice integration due to the decisions of the upstream LibreOffice devs:
http://anzwix.com/a/LibreOffice/Remove%20TDE%20Integration%20(vclplug,%20Add...
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice. I'd like to schedule a community meeting on #trinity-desktop for this weekend, Saturday, at 2:00PM CST to discuss further.
WOW:
"It has ~no users, can't even be built on modern Linuxes, and it annoys folks who want to refactor VCL."
Nice to know how they think of our community.
Personally, the only gtk app I use is Firefox. I've used KOffice since KDE1 and prefer it over LibreOffice, but my needs are very light. I use Wordpad on WinDoZe.
My concern is benefit versus reward. TDE's focus, in my not so honest opinion, should be on making it work and work well, with integration with other program dependencies second. I also plan on moving to Devuan before too long due to my dislike of systemd's feature creep. Like many, I find zero use for KDE4, PulseAudio, systemd and a lot of the "new way of doing things" and just want my desktop to work and get out of my way. I still have no idea what the whole Semantic Desktop was for and WHY I need it.
Then again, my main system is a Thinkpad T60p with a Core2, 3GB RAM, and a 4x3 screen that's 11 years old and which is something I'm sure those dev's wouldn't touch due to it's age and "underpowerness".
It's always annoying to me that devs feel the need to code for 32GB RAM when so many systems barely have 4GB. Maybe if some of these guys would work toward fixing stuff instead of re-inventing the wheel every other year, we might have good stuff. Heck, we went to the moon on almost nothing almost 50 years ago.
Just my 2 cents.
On Wednesday 14 Jun 2017 12:35:12 Timothy Pearson wrote:
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice.
I would recommend avoiding the use of any version of GTK, (if TDE R14.0.4 does not depend on GTK), because it might cause more problems than it solves. I have just done a test of GEdit from Debian 8.7, (as a representative gtk+3.0 application), in TDE R14.0.4, and there are several issues.
I expected to see the very clumsy and awkward Gnome/GTK system for resizing windows by dragging their borders, but instead, I saw the nice KDE/TDE system. This appears to be because TDE puts its own border right round the GEdit window. But this comes at a price. The GEdit window now has two title bars: the TDE title bar, and below that, what is presumably the GEdit title bar, which takes a lot of space to repeat the filename, for no useful purpose. This GEdit title bar is about twice the height of the TDE title bar.
I very often tile two windows one above the other, for example a spreadsheet and a text file, in order to note down results from the spreadsheet in the text file. For speed and convenience, the data areas of both windows need to be as high as possible, and wasting window height with the GEdit title bar would be a significant nuisance if I used GEdit.
GEdit has no menu bar and no toolbar! In contrast to that, in KEdit, the menu bar and toolbar fit in a vertical space that is only slightly larger than the GEdit title bar, and in KEdit, I can hide or show the toolbar and/or statusbar in a moment from the Settings menu, if I need more vertical space.
Instead of a menu bar and toolbar, the GEdit title bar has a button for a file open dialogue, a peculiar button that a tooltip indicates is to create a new file, a Save button, and a button with three horizontal lines on it, which drops down a primitive menu, which looks roughly like a truncated or merged form of some of the items from the menus in the KEdit menu bar.
The GEdit file open dialogue initially shows no files at all, and you have to click on the Other Documents ... button at the bottom, to get a file picker. And if you don't like the file picker in LibreOffice, this one is far worse. It is basically the same as the LibreOffice file picker, but WITHOUT the field where you can paste in the name of the required file, as in the trick to open a file fast in LibreOffice, which I described in another message in this thread. So in my home directory with 8804 files and directories, I just get those 8804 files and directories in a vertical list, which I have to comb through to find the required file, and there is no short cut.
So I would strongly recommend continuing the present TDE policy, (if I understand it correctly), of maintaining support for important third party programs, by wrapping new versions of Qt as they appear. Or of using the TQt layer to enable Qt 3 and Qt 4 both to be installed on the same system without symbol conflicts, if that is how it works. If TDE R14.0.4 does not depend on GTK, I think introducing some sort of dependence on GTK would be unlikely to provide any net benefits, and it might introduce a lot of trouble.
I don't think there's any need for a TDE backend and common interface to third party programs. The important ones, such as LibreOffice and Firefox, work perfectly without any help. That's also true for other programs I use a lot, such as TeXmacs.
As a general comment, in my installation of TDE R14.0.4 in Debian 8.7, everything important seems to work extremely well. I can use the best of KDE4, (such as Okular, the pdf viewer), alongside favourites from KDE 3.5, such as KEdit and Kasablanca, all in the very nice TDE desktop. And third party programs like LibreOffice and Firefox work perfectly. It's great.
Do I understand correctly, that in my installation of TDE R14.0.4 in Debian 8.7, what is really happening is that I have Qt version 4.8.6 running in the background, and Trinity Qt (TQt) is wrapping that, so that it looks like Qt 3 to the Trinity desktop and the KDE 3.5 apps?
Or do I actually have BOTH Qt 3 and Qt 4 installed, and the main benefit of the TQt layer is to resolve the Qt3 and Qt4 symbol collisions when Qt4 is installed alongside Qt3? (That is what https://wiki.trinitydesktop.org/Understanding_the_TQT_Interface seems to say.)
Is being able to use Qt4 applications in TDE, like I am, something that was not actually planned, but works anyway, due to the TQt layer?
Whichever way it works, it is great at the moment, and I hope it will continue. I'm a bit afraid that introducing dependence on GTK could damage TDE, and provide no real benefits.
Chris
On Friday 16 June 2017 14:06:14 Chris Austin wrote:
On Wednesday 14 Jun 2017 12:35:12 Timothy Pearson wrote:
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice.
I would recommend avoiding the use of any version of GTK, (if TDE R14.0.4 does not depend on GTK), because it might cause more problems than it solves. I have just done a test of GEdit from Debian 8.7, (as a representative gtk+3.0 application), in TDE R14.0.4, and there are several issues.
I expected to see the very clumsy and awkward Gnome/GTK system for resizing windows by dragging their borders, but instead, I saw the nice KDE/TDE system. This appears to be because TDE puts its own border right round the GEdit window. But this comes at a price. The GEdit window now has two title bars: the TDE title bar, and below that, what is presumably the GEdit title bar, which takes a lot of space to repeat the filename, for no useful purpose. This GEdit title bar is about twice the height of the TDE title bar.
I very often tile two windows one above the other, for example a spreadsheet and a text file, in order to note down results from the spreadsheet in the text file. For speed and convenience, the data areas of both windows need to be as high as possible, and wasting window height with the GEdit title bar would be a significant nuisance if I used GEdit.
GEdit has no menu bar and no toolbar! In contrast to that, in KEdit, the menu bar and toolbar fit in a vertical space that is only slightly larger than the GEdit title bar, and in KEdit, I can hide or show the toolbar and/or statusbar in a moment from the Settings menu, if I need more vertical space.
Instead of a menu bar and toolbar, the GEdit title bar has a button for a file open dialogue, a peculiar button that a tooltip indicates is to create a new file, a Save button, and a button with three horizontal lines on it, which drops down a primitive menu, which looks roughly like a truncated or merged form of some of the items from the menus in the KEdit menu bar.
The GEdit file open dialogue initially shows no files at all, and you have to click on the Other Documents ... button at the bottom, to get a file picker. And if you don't like the file picker in LibreOffice, this one is far worse. It is basically the same as the LibreOffice file picker, but WITHOUT the field where you can paste in the name of the required file, as in the trick to open a file fast in LibreOffice, which I described in another message in this thread. So in my home directory with 8804 files and directories, I just get those 8804 files and directories in a vertical list, which I have to comb through to find the required file, and there is no short cut.
So I would strongly recommend continuing the present TDE policy, (if I understand it correctly), of maintaining support for important third party programs, by wrapping new versions of Qt as they appear. Or of using the TQt layer to enable Qt 3 and Qt 4 both to be installed on the same system without symbol conflicts, if that is how it works. If TDE R14.0.4 does not depend on GTK, I think introducing some sort of dependence on GTK would be unlikely to provide any net benefits, and it might introduce a lot of trouble.
I don't think there's any need for a TDE backend and common interface to third party programs. The important ones, such as LibreOffice and Firefox, work perfectly without any help. That's also true for other programs I use a lot, such as TeXmacs.
As a general comment, in my installation of TDE R14.0.4 in Debian 8.7, everything important seems to work extremely well. I can use the best of KDE4, (such as Okular, the pdf viewer), alongside favourites from KDE 3.5, such as KEdit and Kasablanca, all in the very nice TDE desktop. And third party programs like LibreOffice and Firefox work perfectly. It's great.
Do I understand correctly, that in my installation of TDE R14.0.4 in Debian 8.7, what is really happening is that I have Qt version 4.8.6 running in the background, and Trinity Qt (TQt) is wrapping that, so that it looks like Qt 3 to the Trinity desktop and the KDE 3.5 apps?
Or do I actually have BOTH Qt 3 and Qt 4 installed, and the main benefit of the TQt layer is to resolve the Qt3 and Qt4 symbol collisions when Qt4 is installed alongside Qt3? (That is what https://wiki.trinitydesktop.org/Understanding_the_TQT_Interface seems to say.)
Is being able to use Qt4 applications in TDE, like I am, something that was not actually planned, but works anyway, due to the TQt layer?
Whichever way it works, it is great at the moment, and I hope it will continue. I'm a bit afraid that introducing dependence on GTK could damage TDE, and provide no real benefits.
Chris
One final thing about gedit people:
Do not, under any circumstances, edit an important file, it will play 52 pickup with it on the following save a bout 10% of the time, throwing away whole pages of code, and then pickup a random page in the middle of a word, and divide it by 4 or so, and scatter it repeatedly thru the code you've spent weeks fine tuning.
geany has yet to so scramble a file for me, it Just Works(TM) like nano, but with a prettier face by far.
Cheers, Gene Heskett
On Friday 16 Jun 2017 19:06:14 Chris Austin wrote:
On Wednesday 14 Jun 2017 12:35:12 Timothy Pearson wrote:
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice.
I would recommend avoiding the use of any version of GTK, (if TDE R14.0.4 does not depend on GTK), because it might cause more problems than it solves. I have just done a test of GEdit from Debian 8.7, (as a representative gtk+3.0 application), in TDE R14.0.4, and there are several issues.
In addition to the other issues, I forgot to mention that although I have set the Cursor Flash Time to No blinking in Interface tab in TQt Configuration, and this successfully stops the cursor from blinking in KWrite and KEdit, the cursor still blinks, sometimes, in GEdit. Specifically, it is blinking when you open GEdit, or return focus to GEdit after looking at another window, but if you don't type anything, it stops blinking after about 9 seconds, (9 blinks). Then if you type something, the cursor blinks for about 9 seconds after you stop typing, then it stops blinking. I would certainly find this behaviour a nuisance, if I used GEdit.
On Fri, 16 Jun 2017 19:06:14 +0100 Chris Austin chris@chrisaustin.info wrote:
On Wednesday 14 Jun 2017 12:35:12 Timothy Pearson wrote:
We need to plan out a roadmap to determine whether or not we should be trying to get e.g. GTK3 into a form we can use as the backend and common interface to third party programs like LibreOffice.
I expected to see the very clumsy and awkward Gnome/GTK system for resizing windows by dragging their borders, but instead, I saw the nice KDE/TDE system. This appears to be because TDE puts its own border right round the GEdit window.
That's because that functionality is (or should be) controlled by the window manager, not the widget set.
But this comes at a price. The GEdit window now has two title bars: the TDE title bar, and below that, what is presumably the GEdit title bar, which takes a lot of space to repeat the filename, for no useful purpose. This GEdit title bar is about twice the height of the TDE title bar.
That's a problem with your distro, your GTK3 style, or GEdit itself--I just tested a recent Abiword on Gentoo with my homerolled GTK3 style, and got no such doubling.
Instead of a menu bar and toolbar, the GEdit title bar has a button for a file open dialogue, a peculiar button that a tooltip indicates is to create a new file, a Save button, and a button with three horizontal lines on it, which drops down a primitive menu, which looks roughly like a truncated or merged form of some of the items from the menus in the KEdit menu bar.
Also a style- or application-specific thing--Abiword gives me a normal menu, not a hamburger button.
The GEdit file open dialogue initially shows no files at all, and you have to click on the Other Documents ... button at the bottom, to get a file picker. And if you don't like the file picker in LibreOffice, this one is far worse. It is basically the same as the LibreOffice file picker, but WITHOUT the field where you can paste in the name of the required file, as in the trick to open a file fast in LibreOffice, which I described in another message in this thread. So in my home directory with 8804 files and directories, I just get those 8804 files and directories in a vertical list, which I have to comb through to find the required file, and there is no short cut.
Yes, the default file dialog is bad--no argument there! It could be reimplemented starting from basic widgets, although I'm not sure if it's worth it.
Do I understand correctly, that in my installation of TDE R14.0.4 in Debian 8.7, what is really happening is that I have Qt version 4.8.6 running in the background, and Trinity Qt (TQt) is wrapping that, so that it looks like Qt 3 to the Trinity desktop and the KDE 3.5 apps?
Or do I actually have BOTH Qt 3 and Qt 4 installed, and the main benefit of the TQt layer is to resolve the Qt3 and Qt4 symbol collisions when Qt4 is installed alongside Qt3? (That is what https://wiki.trinitydesktop.org/Understanding_the_TQT_Interface seems to say.)
TQT was an attempt to prevent symbol collisions when using Qt3 and Qt4 widgets in the same program. This would have allowed (in theory and at the time) things like relatively easy embedding of modern WebKit into Qt3 applications. The development team was just never big enough to take advantage of the idea. Trinity is still using Qt3, just with TQT as an intermediate layer.
Is being able to use Qt4 applications in TDE, like I am, something that was not actually planned, but works anyway, due to the TQt layer?
You can run any program using any widget set under any desktop environment. The underlying X server doesn't care. Trinity makes some attempt to integrate Qt4 applications a little better visually with the desktop default, that's all. It's just theming support.
E. Liddell
Chris Austin chris@chrisaustin.info :
So I would strongly recommend continuing the present TDE policy, (if I understand it correctly), of maintaining support for important third party programs, by wrapping new versions of Qt as they appear. Or of using the TQt layer to enable Qt 3 and Qt 4 both to be installed on the same system without symbol conflicts, if that is how it works. If TDE R14.0.4 does not depend on GTK, I think introducing some sort of dependence on GTK would be unlikely to provide any net benefits, and it might introduce a lot of trouble.
If it's possible to make it just using newer version of Qt, this is IMHO a good way. Of courtse Qt, not pulling a whole KDE4 or 5 with it. Now sorry about my rant about GTK, but I think that some devs there have an internal contest "how to ruin the file picker dialog". Last time (I'm using Debian, my definition of Last time is according to Debian timeline :) ) they removed... path bar. There is of course some keyboar dcombo to blink it for a moment, but it sometimes works, sometimes doesn't, and it goes to end with clicking through >20 directories. Thinking that user is too dumb to have directories is good if we're substituting Web 2.0 community with Web 3.0 profile harvesting service, but not when it comes to productivity applications. MCbx