hi all,
today is a good day to code I think. Almost no critical work for
customers so I had some time for
a) opensource
b) beer tasting (I'm really proud of my current beer batch, an
american/british pale ale with lots of intensive taste)
okay, okay, back to the topic...
I had to rework almost all qtermwidget structure. Its functionality is
unaffected, only the infrastructure has been fixed.
I'm afraid it will affect packagers mostly. And I'm really sorry about
it. But I believe this change is mandatory.
Changes:
- full Qt5 support (tested on Linux/X11 Qt5.1, OS X Qt 5.2)
- full Qt4 support (4.8.5 on all my machines)
- qtermwidget is fully "versioned" to allow parallel installation for
both qt versions
- 3rd party application developers are unaffected except little changes
in build toolchain, Basically only first 2 files in this commit are
affected with this change:
https://github.com/qterminal/qterminal/commit/50d8e22e44582a78b8cec9c279dd61dd1a85c604
- both Qt version use the same source code (/me praises Qt team!)
- only USE_QT5 cmake option makes difference (it's off by default -> Qt4)
- libqtermwidget.*.so (or dylib) is now renamed to libqtermwidget4.* or
libqtermwidget5.* for appropriate Qt version
- includes are stored in <prefix>/qtermwidget<qt-main-version>/
- data files are stored in <prefix>/share/qtermwidget<<qt-main-version>/
- all cmake support has been reworked (using great lxqt implementation
as an example) so only one change for user is to change
FIND_PACKAGE(qtermwidget) to FIND_PACKAGE(qtermwidget<4|5>) and add
"include(${QTERMWIDGET_USE_FILE})" line (for both versions). Then there
is no need to make ifdefs for qt4/qt5 versions of qtermwidget.
- pkg-config support for both versions is there too
- designer support only for Qt4
- example app "test" is built on demand only (-DBUILD_TEST=1)
- qterminal git has been updated to work with these changes, but it's
still Qt4 app only due 3rd party dependencies.
I'm pretty sure I screwed many things in many distros but I believe it's
a must to move forward...
cheers!
p.
On 04/11/2014 02:10 PM, Jerome Leclanche wrote:
> This is great. Thanks for picking it up Petr! I love qterminal and
> it's the software I use the most next to Chromium.
>
> I've updated the packages on the AUR.
> I filed https://github.com/qterminal/qterminal/issues/43. For some
> reason I thought I had already filed it but i can't find it. It's the
> bug I hit the most and is quite frustrating.
>
> I definitely think of qterminal as a lxterminal replacement - in fact,
> when I first found qterminal, my previous one *was* lxterminal.
> "Reduce memory footprint" is too vague of a request to actually be
> useful, really. We should definitely strive for low footprint, but
> there is no magic bullet to it and it's not something that can simply
> be "fixed". Being lightweight doesn't have to be incompatible with
> providing useful features, and bookmarks are a great idea imho. Since
> they can be disabled, I don't see the problem.
> J. Leclanche
>
>
> On Fri, Apr 11, 2014 at 12:13 PM, PCMan <pcman...@gmail.com> wrote:
>> On Fri, Apr 11, 2014 at 6:35 PM, Petr Vanek <p...@yarpen.cz> wrote:
>>> hi gang,
>>>
>>> I found some free time to work on qterminal/qtermwidget again. Some long
>>> standing defects are fixed, some minor features implemented, and one
>>> bigger and unique feature included too.
>>>
>>> I want to make some release of qterminal finally before I'll start to
>>> work fully on lxde (in free time of course;)).
>> That's great! If you have time, please also review my previous
>> proposals on the ML.
>> Some comments are needed so we can continue.
>>
>>> Let me introduce changes to you first.
>>>
>>> qtermwidget:
>>> - some API fixes (missing const in arguments)
>>> - current working directory API created. To get current process cwd.
>>> Only for linux 3.x now. Methods for other OS would be more than appreciated.
>> I'll look into this part later to see if I can make a patch for this.
>>
>>> qterminal:
>>> - Ctrl+Shift+M toogles menu bar
>>> - improved xterm compatibility with -e argument (execute command)
>>> - option: open tab with the same working directory
>>> - fixed preferences saving on app exit
>>> - dropdown mode display fix for DE with panel on top
>>> - and finally quite cool bookmarks.
>>>
>>> More about bookmarks. I think it's (with terminal splitting) one of the
>>> key feature now. At least for me.
>>> Please look at the screenshot:
>>> https://dl.dropboxusercontent.com/u/7865279/qterminal-bookmarks.png
>> Really looks cool! I like bookmarks.
>>
>>> As you can see there are some "Local Bookmarks" which are based on
>>> environment variables and system info.
>>> And much more interesting custom bookmarks saved in file. The file can
>>> be anywhere - ~/.config/qterminal by default but it can be saved eg. in
>>> OwnCloud/Dropbox directory and synchronized between all your machines.
>>> Yes, it's my usecase.
>>>
>>> Bookmark can hold almost anything. From simple "ssh machine.com" over
>>> "cd ~/workdir; sftp machine.com" to complex script snippets settings
>>> env, calling almost any commands (oracle sqlplus handling over various
>>> vpn connections in my case).
>>> That's fine. And I like it ;)
>>>
>>> But it brings another topic. I have various requests in my mailbox and
>>> qterminal issue tracker. One for all:
>>> https://github.com/qterminal/qterminal/issues/42
>>> Summarized into sentence: "If I have understood correct QTerminal is the
>>> replacement (to be) of LXTerminal, QTerminal currently has about 3x the
>>> memory footprint of LXTerminal."
>> I think the bug report is incorrect.
>> Qterminal is quite light compared with other Qt-based software.
>> On my box they have similar memory usage.
>> It's true that the resident memory of qterminal is more than that of
>> lxterminal.
>> However, most parts of the used memory are shared which is the same
>> among all Qt programs.
>> So running qterminal in a Qt-based environment does not significantly
>> increase resource usage (only 6mb on my box).
>> To prove that, I did profiling with valgrind's massif tool. It only
>> used 2.9 MB of heap memory, which is acceptable.
>> For a relatively feature-rich terminal emu, it's acceptable.
>> Besides, most parts of the memory are used by freetype and the screen
>> buffer during the profiling, which is reasonable.
>> When it really becomes a bottleneck, let's optimize it.
>> For now, I'd say qterminal is good enough for a default terminal emulator.
>> Let's use it and avoid something like lxqt-terminal. :-)
>> Removing tab support won't improve memory usage at all.
>> The memory is mainly used by buffer and font rendering.
>>
>>> That's correct. I've never thought about qterminal as lxterminal
>>> replacement. On the other side - it's quite easy to create a really
>>> light "xterm" clone with limited set of features (no tabs, no search, no
>>> bookmarks, no menu...) as a part of lxqt project.
>>>
>>> Do you think it's a good idea?
>>>
>>>
>>> thanks,
>>> petr
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Put Bad Developers to Shame
>>> Dominate Development with Jenkins Continuous Integration
>>> Continuously Automate Build, Test & Deployment
>>> Start a new project now. Try Jenkins in the cloud.
>>> http://p.sf.net/sfu/13600_Cloudbees
>>> _______________________________________________
>>> Lxde-list mailing list
>>> Lxde-list@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/lxde-list
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>> _______________________________________________
>> Lxde-list mailing list
>> Lxde-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lxde-list
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
