Pages

Showing posts with label qt. Show all posts
Showing posts with label qt. Show all posts

April 26, 2016

Concerns about Qt's increasing commercial focus


It's not just me. Phoronix is reporting on growing concerns in the Qt community about the project's increasing commercial focus and apparent deprecation of its open source core.

I have said many times in these pages and elsewhere that I really like Qt: it's the right tool for a lot of jobs. But increasingly I've been feeling that any contribution I make in educating users about Qt is benefiting a commercial enterprise and not a community tool. So much so that I am re-surveying other open source multi-platform libraries to use as an alternative to Qt.

If the community no longer has meaningful Qt ownership, a lot of users will no longer be interested.

April 10, 2016

Qt "Demerger"



Phoronix reports that Qt will be "demerged" from parent company Digia soon.

It seems there has always been interesting dynamics around Qt, and this I suppose is the latest chapter. I'm hoping this is more of a good sign than a bad one.

August 21, 2015

Fixing Qt5 themes in Xfce

A lot of my Qt apps (e.g., qpdfview, VLC) recently stopped respecting my GTK theme. I did some checking, and it turns out they are all Qt5 apps. Google led me to the QT5 apps don't obey GTK theme settings post at the Manjaro Linux forum, which has some interesting things to say (generally applicable to all distributions).

What I eventually did was add:

# Workaround for Qt5 app theming.
export QT_STYLE_OVERRIDE=gtk


to the end of my my .profile, logout and log back in. Works now.

February 19, 2013

Qt bug report gets some love

A Qt bug report I submitted almost two years ago finally got a little attention and a status promotion from a Qt dev. Yay! That is all.

October 03, 2012

Penguin meets canine: Firefox OS

I was originally somewhat dismissive of Mozilla's Firefox OS (née Boot to Gecko) as just a Google Chrome OS wannabe, but I've read a few things recently that suggest it's a platform with some good ideas that might actually gain some traction. While there seems to be limited buzz about it in $illyValley, and some are predicting very low penetration next year, I want to be optimistic that it will develop into a platform with some relevance.

I'm attracted to Firefox OS because unlike Google Chrome OS or Android it's all open all over the place, and unlike webOS it actually has institutional backing.*

FfOS's strategy is to target low-end smartphones and featurephones--a place that iOS will likely never go and where Android is going with only limited usability success. In addition to phones, I am wondering if FfOS might also be applicable to general embedded device development. Qt+QML seems to do nicely in this space, but I am more than slightly concerned about the future of Qt since being dumped by Nokia. webOS seems a good candidate for embedded work as well--as long as you subscribe to the webOS UI paradigm.

In any case, it's always nice to have viable alternatives, so I'll be rooting (!) for the ruddy canine.

*Looks like I might be wrong about this.

June 22, 2012

Fixing Qt appearance under XFCE 4.8 (aptosid)

On my aptosid setup running Xfce, Qt apps don't honor the GTK appearance setting without some help. The post at http://forum.xfce.org/viewtopic.php?id=5605 provides a solution that worked for me:
# echo 'export GTK2_RC_FILES="$HOME/.gtkrc-2.0"' >> /etc/profile.d/qgtkstyle.sh
# chmod 755 /etc/profile.d/qgtkstyle.sh
then logout and back in.

With Xfce taking on increasing importance since the introduction of GNOME 3, I hope this will work out-of-the-box in the near future.

December 08, 2011

Lightweight Qt-based DE?

The last couple days, I've been wondering if it might be possible/worthwhile/stupid to build a Qt-centric lightweight desktopish environment. In other words, something to be to KDE what Xfce/Fluxbox/Openbox are to GNOME.

Today, I decided to do a bit of Googling and discovered Egg Window Manager, Qt Window Manager, and R Window Manager. I've yet to try any, but it's nice to know that there are people working on this.

Update [2012-01-12]: Reader CTown points out Razor-qt--a Qt-based desktop environment--is available as well. It's apparently a member of the QtDesktop project. It's worth pointing out that Razor-qt uses Openbox by default, and Openbox, while being a really nice WM, uses GLib--a GTK+ dependence. But maybe in combination with  one of the WMs above ...

July 18, 2011

Fixing ugly Qt fonts in Openbox, Fluxbox, etc.

On Debian Squeeze at least, unless you are using GNOME or Xfce (or ostensibly KDE) or are running the configuration daemons that come with these, fonts rendered by Qt apps look like utter crap.

It seems that Qt honors neither ~/.fonts.conf, nor what's in ~/.fonts.conf.d, nor what's in /etc/fonts/conf.d. This is a problem if you want to run light-and-lean and not use the GNOME or Xfce daemons in Openbox, Fluxbox, and likely many other window managers.

After much hair pulling, I finally managed to work around the problem by using Xresources. Adding the code below to either ~/.Xresources (for user-only changes) or to a new file /etc/X11/Xresources/fonts-default (for system-wide changes) fixed the issue for me. It also fixes problems with ugly font rendering in OpenOffice.org and LibreOffice.

What I added is:
Xft.dpi: 96
Xft.antialias: true
Xft.hinting: true
Xft.rgba: rgb
Xft.autohint: false
Xft.hintstyle: hintslight
Xft.lcdfilter: lcddefault

The dpi entry is there just for good measure. Change settings as needed according to taste.

April 02, 2011

Installing the Qt SDK

Update: Bits of this have been obsoleted with the 4.7.3 release. I'll try to post an update soon. [09 May 2011]

Because I live fast and loose and on the bleeding edge, I decided to install the Qt SDK using the Nokia download rather than from my distros' package manager. Actually, the real reason is that I was seeing a weird message in the debugger in Qt Creator on Ubuntu 10.10 and hoped the a newer SDK would fix that. But alas it did not--on neither my Ubuntu nor my Debian Squeeze development system. But I will continue to use the downloaded SDK because it will let me update to the latest versions.*

What follows is a brief guide to help you integrate the downloaded SDK into your system should you opt to do so.

The most important difference between installing the downloaded SDK versus installing from the repositories is that the downloaded install will only install for a single user.** The installation itself is pretty straightforward:
  1. Download the installer.
  2. Make the installer executable: In a term open to the directory where you downloaded the installer, enter the command
    $ chmod u+x {the-name-of-the-installer}
    In my case {the-name-of-the-installer} was qt-sdk-linux-x86-opensource-2010.05.1.bin
  3. In the same term, issue
    $ ./{the-name-of-the-installer}
    and follow the resulting directions. The installer will let you pick the directory where the SDK will go. Don't feel obliged to use the default. Because I didn't want another visible directory in my home directory, I installed into ~/.opt/qtsdk.
The above will install all the SDK bits in the specified directory and create two *.desktop entries for the Qt Creator IDE: one on your desktop (drag it to the trash) and the other in your ~/.local/share/applications directory--so that you get a menu entry for it.

Adding some missing bits
The above process gives you a working SDK that's well suited to using the Qt Creator IDE. However, for more general work there are a few things missing:
  1. qmake and other executables will not be available as system commands
  2. There is no menu entry for the Qt Designer GUI layout tool.
The first is required if you plan to do Qt development with another IDE (Netbeans, Eclipse, Monkey Studio, etc.). The second is nice to have in any case. Both are fairly easy to fix.

Making the SDK commands available
To do this we are going to edit your .profile file. Before making changes to your .profile, make a backup of it so you can get back to it easily if you break something! If you have also installed the SDK from the repositories, what follows will cause the repository commands to be overridden by the commands in the local SDK. If you don't want this, then don't do this.

Open ~/.profile in a text editor. Toward the bottom, add the following:
# set PATH so it includes local Qt SDK tools
QTSDK_LOCATION=$HOME/.opt/qtsdk
if [ -d "$QTSDK_LOCATION/qt/bin" ] ; then
    PATH="$QTSDK_LOCATION/qt/bin:$PATH"
fi
if [ -d "$QTSDK_LOCATION/bin" ] ; then
    PATH="$QTSDK_LOCATION/bin:$PATH"
fi
making sure to change QTSDK_LOCATION as needed for your installation. When you logout and log back in, the executables in the two bin directories should be available as commands. Test this by issuing
$ qmake -v
in a term. The output should make sense.

Adding an entry for Qt Designer to the menu
Assuming you have done the stuff in Making the SDK commands available, you can just add the following file as Nokia-QtDesigner.desktop to ~/.local/share/applications
[Desktop Entry]
Value=1.0
Type=Application
Encoding=UTF-8
Exec=designer %F
Name=Qt Designer
GenericName=GUI designer for Qt applications
X-KDE-StartupNotify=true
StartupNotify=true
Icon=Nokia-QtCreator
Terminal=false
Type=Application
Categories=Development

If you have not done the Making the SDK commands available stuff, then change the Exec= line to point directly at the designer executable (which should be in {qtsdk}/qt/bin)

Now I'm going to move on to testing alternatives to Qt Creator. Qt Creator has a very nice feature set, but the UI is a bit quirky. I'll let you know if I find anything I like better.

* A possible consequence of this is that installing extra bits and baubles will no longer be easy. For example, it seems the Qt4 Designer plugin for QScintilla 2 (libqscintilla2-designer in Debian-land) doesn't ship with Nokia's SDK, and I don't know if Qt Designer will pick up libs installed in standard system library locations.
** I'm quite certain that you can install the downloaded SDK for all users, for example by installing as root into /opt. However, doing so may generate *.desktop files on root's desktop and in root's .local/share/applications dir, and I am not sure if that will mess anything up. If you try this, please let me know how it worked for you.