[Lxde-list] LXDE-Qt preview

[PCMan]

On Thu, Jul 4, 2013 at 3:41 PM, Jerome Leclanche <adys.wh at gmail.com> wrote:
> Really awesome.
>
> And holy hell, the screenshot looks like it could have been Razor-qt.
>
> I'm really glad we have an actively developped file manager and image viewer
> in Qt as those were two apps that were seriously missing.
>
> What is the desktop+file widget on the screenshot? Is it another lxde app,
> or pcmanfm taking care of it?
>
> Have you had a look at the code from razor-panel and razor-desktop?
> I strongly feel the panel would be better off merged with its razor
> counterpart. We've actually had a fair bit of work+cleanup recently on it.
> Let me know what you think.
>
> J. Leclanche

Thank you for the rapid response.
1. PCManFM-Qt and LxImage-Qt are designed with razor-qt in mind. When
running under razor-qt session, they load razor-qt config and applies
your icon theme. So they can blend well with razor-qt natively.

2. The desktop wallpaper and file icons are managed by PCManFM-Qt, not
another program. The benefit of this approach is obvious. The behavior
will be consistent with the file manager. Besides, because the file
manager is constantly running (as the desktop manager), subsequent
launches of pcmanfm actually calls the existing process via IPC and
ask for a new window. So opening other file manager windows becomes
very fast and share the resources such as QPixmap caches for QIcon
with the desktop manager part, reducing total memory usage of the
whole desktop.

3. Lxpanel-qt uses some code from razor-panel, especially the systray
and Xfitman code. I did my own panel instead of just improving
razor-panel because I already have an gtk+3 based lxpanel port written
in Vala. Since Vala syntax is very similar to C++ (actually C#), it's
natural to port it to C++. In addition, razor-panel and its plugins
currently relies on other razor libs and cannot be built outside the
source tree of razor-qt. If the razor libs can be more modular it's
possible for us to use them in the future. The layout and geometry of
lxpanel is different from that of razpr-panel, too. Another problem
is, we use glib inside lxpanel-qt and I want to use libfm in it, too.
They're not dependencies of razor-qt. So I'm not able to do this with
razor-panel. Hence I try to do lxpanel-qt.

For future cooperation, I think we can share applications or libraries first.
I'll ensure that other programs, such as the file manager and image
viewer work as well in razor-qt and applies your configuration, such
as the icon theme. In addition, I'll try to do what's lacking in both
camps first, so both of us can share it. The panel is the only
exception, which is currently a duplicate for the above reasons.

The other way is through share of code and libs. I'll use some code
from razor whenever possible. I actually read your code to learn Qt
sometimes. :-) The quality of razor-qt code is good and I'm impressed.
Some parts are even modular so can be used alone outside razor-qt with
minimal modifications (for example, replacing signals with G_SIGNALS).
Code reusability of your project is really good. Awesome!

The remaining problem is hard to solve. Razor qt has many good c++
base libraries, such as that for xdg specs while we like to use C
glib/gobject implementation from Gnome in some places. The reason is
obvious. We're from the gtk+ world and are more familiar with the G
libraries. In addition, since glib is installed by default in nearly
every Linux distro and Qt are mostly compiled with glib integration,
why not use it? Even if you don't use glib, it's still in the hard
disk and memory. Reusing xdg implementation in glib/gio saves a lot of
work and we get the implementation for free since it's already there.
I'm not sure if using glib is OK for razor-qt. The other issue is,
your code is modular, but these parts are finally compiled into one
librazor-qt library. Using the libraries outside razor-qt source tree
is not very easy, either. Otherwise I want to use razor-power much.
:-)
Will razor-qt source tree be separated into different modules in the future?

Thanks