1. you have no idea what you are doing, and you copied it from somewhere else
2. you have a target that needs to be built after another target, and you don't know any better

TEMPLATE = subdirs
SUBDIRS = src plugins tests docs
plugins.depends = src
tests.depends = src plugins

TEMPLATE = subdirs
src_lib.subdir = src/lib
src_lib.target = sub-src-lib

src_plugins.subdir = src/plugins
src_plugins.target = sub-plugins
src_plugins.depends = sub-src-lib

SUBDIRS = src_lib src_plugins

1 0

import QtQuick 2.0

Item {
    id: layout

    property bool ready: false

    onChildrenChanged: performLayout()
    onWidthChanged: performLayout()
    onHeightChanged: performLayout()

    /* the meat of the layout */
    function performLayout() {
        /* nothing to layout? don't bother then */
        if (layout.children.length == 0)
            return

        var currentX = 0

        console.log("DOING LAYOUT FOR " + layout.children.length + " ITEMS")

        /* first real step of doing anything: go over all the children */
        for (var i = 0; i < layout.children.length; ++i) {
            var obj = layout.children[i]

            /* in the real world, we'd probably do something a lot more complex,
             * but let's just position our children along a row.
             */
            console.log("Positioning at " + currentX + " to " + (currentX + obj.width))
            obj.x = currentX
            currentX += obj.width
        }

        console.log("LAYOUT DONE")
    }
}

import QtQuick 2.0

Rectangle {
    width: 100
    height: 50
    color: "black"

    Rectangle {
       width: 90
       height: 40
       anchors.centerIn: parent

       color: "red"
    }
}

import QtQuick 2.0

Rectangle {
    width: 1000
    height: 100

    MyLayout {
        MyItem { }
        MyItem { }
        MyItem { }
        MyItem { }
        MyItem { }
        MyItem { }
        MyItem { }
    }
}

• it omits things like margins, wrapping
• it will break if MyItem is ever anchored
• it doesn't use anchoring (which might make for a more optimal implementation in this particular case - at the least, it wouldn't have to relayout if the width/height of the layout changed)
• it doesn't relayout if the geometry of the children change
• it relayouts whenever properties changes, which isn't optimal if e.g. the layout is animating a change, instead, it should delay a relayout using a Timer

7 0

#include <QtCore>
#include <qtest.h>
#include <qcoreapplication.h>
#include <qdatetime.h>

class MallocBenchmark : public QObject
{
Q_OBJECT
private slots:
    void qtMalloc();
    void qtMalloc_data();
    void regularMalloc();
    void regularMalloc_data();
};

void MallocBenchmark::qtMalloc_data()
{
    QTest::addColumn<int>("size");
    QTest::newRow("1") << 1;
    QTest::newRow("10") << 1;
    QTest::newRow("100") << 100;
    QTest::newRow("10000") << 10000;
    QTest::newRow("1000000") << 1000000;
    QTest::newRow("10000000") << 10000000;
}

void MallocBenchmark::qtMalloc()
{
    QFETCH(int, size);

    QBENCHMARK {
        void *p = ::qMalloc(size);
        ::qFree(p);
    }
}

void MallocBenchmark::regularMalloc_data()
{
    qtMalloc_data();
}

void MallocBenchmark::regularMalloc()
{
    QFETCH(int, size);

    QBENCHMARK {
        void *p = malloc(size);
        free(p);
    }
}

QTEST_MAIN(MallocBenchmark)

#include "main.moc"

********* Start testing of MallocBenchmark *********
Config: Using QTest library 5.0.0, Qt 5.0.0
PASS   : MallocBenchmark::initTestCase()
RESULT : MallocBenchmark::qtMalloc():"1":
     0.000059 msecs per iteration (total: 62, iterations: 1048576)
RESULT : MallocBenchmark::qtMalloc():"10":
     0.000062 msecs per iteration (total: 66, iterations: 1048576)
RESULT : MallocBenchmark::qtMalloc():"100":
     0.000087 msecs per iteration (total: 92, iterations: 1048576)
RESULT : MallocBenchmark::qtMalloc():"10000":
     0.000083 msecs per iteration (total: 88, iterations: 1048576)
RESULT : MallocBenchmark::qtMalloc():"1000000":
     0.0043 msecs per iteration (total: 72, iterations: 16384)
RESULT : MallocBenchmark::qtMalloc():"10000000":
     0.0063 msecs per iteration (total: 52, iterations: 8192)
PASS   : MallocBenchmark::qtMalloc()
RESULT : MallocBenchmark::regularMalloc():"1":
     0.000053 msecs per iteration (total: 56, iterations: 1048576)
RESULT : MallocBenchmark::regularMalloc():"10":
     0.000051 msecs per iteration (total: 54, iterations: 1048576)
RESULT : MallocBenchmark::regularMalloc():"100":
     0.000082 msecs per iteration (total: 86, iterations: 1048576)
RESULT : MallocBenchmark::regularMalloc():"10000":
     0.000076 msecs per iteration (total: 80, iterations: 1048576)
RESULT : MallocBenchmark::regularMalloc():"1000000":
     0.0043 msecs per iteration (total: 71, iterations: 16384)
RESULT : MallocBenchmark::regularMalloc():"10000000":
     0.0060 msecs per iteration (total: 99, iterations: 16384)
PASS   : MallocBenchmark::regularMalloc()
PASS   : MallocBenchmark::cleanupTestCase()
Totals: 4 passed, 0 failed, 0 skipped
********* Finished testing of MallocBenchmark *********

6 0

• Norway
• United Kingdom
• Amsterdam (as a stopover)
• Germany
• United States
• Finland

1 2

burchr@virgin:~/code/scripts(master+)% genlibtree.rb /usr/lib/libQtCore.so
Dependency tree for /usr/lib/libQtCore.so
 /usr/lib/libQtCore.so
* /usr/lib/libpthread.so.0
* /usr/lib/libz.so.1
* /usr/lib/libdl.so.2
* /usr/lib/libgthread-2.0.so.0
** /usr/lib/libglib-2.0.so.0
** /usr/lib/librt.so.1
** /usr/lib/libc.so.6
* /usr/lib/libstdc++.so.6
** /usr/lib/libm.so.6
** /usr/lib/ld-linux.so.2
** /usr/lib/libgcc_s.so.1

5 0

• MeeGo is not just Nokia
  
  Intel is also involved in MeeGo, and in addition to that, there are other partners and OEMs.
  
  This will not change.
  
• MeeGo is open
  
  This means that anyone who wants to continue the work and contribute, can. There's no barriers, no licensing fees, and no patent worries. This is attractive to hardware manufacturers. Thanks to (trying) to reuse upstream components, it's also a less expensive alternative than Android.
  
  This will not change.
  
• Nokia did, right at the outset of the announcement say, they are continuing work on it
  
  Yes, it is true that they also announced that they are reducing their R&D spending on it, but perhaps this isn't such a bad thing. Perhaps lower spending will enable them to spend on what really matters, and focus on getting something out the door.

10 1

• Visually appealing
• Nice contrasting colours
• Fairly consistent icons styling
• Appealing widget styling

Good:

• Pervasive search is a useful feature
• Easy to see what windows are open
• Distinctive use of contrast, very visually appealing

Bad:

• Why is there a wifi icon up the top, and another (or at least, what looks like one) down the bottom?
  
• Why does the search box have a caret visible with no text entered? That looks ugly.
  
  Websites get this right: guide text when nothing entered, not explicitly focused - but grab text if needed. Clear guide text when text is grabbed, or when focus is explicitly granted, add caret.
  
• What are the three boxes (two mostly transparent) at the bottom center?
  
  I presume this is some kind of pagination thing but that isn't immediately clear.
  
• Why does the central view have a scrollbar?
  
  Typical users don't have that many windows open; while I understand the need to scale to power users (the people presumably developing the environment), I don't think scrolling is a very nice mechanism to do it with.
  
• The left pane is appalling. So many ellipses.
  
  One thing that many modern UI implementations have done away with is text from the task bar, dock, whatever you want to call it, and this is a very good example of why that isn't such a bad idea.
  
  It's hard enough fitting the text in on a horizontal panel, but a vertical one has even less horizontal real-estate for horizontal text.
  
• "Windows" and "Applications" look like they are made to switch state, but it isn't immediately obvious what they do. Will they function like tabs, and change the content of the center panel?
  
• "Activities" in top left seems to be a state switcher. I'm unsure if the naming is very descriptive of what it does. It could also use some mechanism to stand out more, if it will be used to switch windows a lot as this appears.
  
• The size of the captions of the windows seems to have a bug. Notice "Spiral_by_firas.jpg" has a lot more room on the right hand side than the left.
  
• The bottom right hand icon (next to the wifi icon) is really, really hard to figure out just by looking at.

Next up, instant messaging.

Good:

• I love integrated IM. It is one thing I adore about my Nokia N900, apart from Qt.
• The use of gradients to differentiate sender is intriguing, subtle, and I like it
• The scrollbar is gentle, and beautiful

Bad:

• Why is the icon in Vincent's chat window the same as on the bar at the bottom? Why not use Vincent's avatar, or something.
  
• Why is there a large chunk of empty space on the left side of the chat dialog? I think it's quite unbalancing.
  
• The effect of having a zoomed icon (under "File Manager") still looks weird.
  
• The purpose of the bottom right is now more clear: it's a replacement for the system tray?
  
  Okay, I can go with that. Splitting system and applications makes some sense.
  
  I'm not sure if this is the best way to position and display it, though, and to me, I think IM almost belongs as part of the system, not in the application 'systray'.
  
• Lack of timestamps on the IM dialog is a little anoying.
  
  One interesting effect to minimise effect on dialog space might be to only timestamp conversations after a reasonable (>1-2 minute) delay with no conversation.

And last, but by no means least...

Good:

• Nifty integration of different types of things
• Good demonstration of search

Bad:

• The problem of using text as opposed to icons once again rears its ugly head. This really needs fixing. So many ellipses.
  
• Searching for other things here might be nice. Open windows? A document I've been working on? My web history? People I talk to?
  
• How are items sorted? Alphabetically? Not sure that's a great idea.
  
  Giving them in some form of contextual usage (most often used, most recently used) would be a lot more useful. At least a favourite/'pin' option like the MeeGo netbook UI.
  
• Why on earth is 'wo' matching 'Chess', etc?
  
• Showing the number of items: reasonable.
  
  Displaying them on the right hand side of the screen, as far away from everything else as possible isn't so reasonable.
  
  I'd just not display it at all. It doesn't convey useful information that the user cannot distil by looking at the icons, if they really need to know how many items are in their boxes.

2 4

CONFIG += link_pkgconfig # enable the PKGCONFIG feature
PKGCONFIG += glib-2.0 # link against glib-2.0

$ cat test.pro
CONFIG += link_pkgconfig
PKGCONFIG += foobar

$ qmake test.pro:
Package foobar was not found in the pkg-config search path.
Perhaps you should add the directory containing `foobar.pc'
to the PKG_CONFIG_PATH environment variable
No package 'foobar' found

$ echo $?
0

CONFIG += link_pkgconfig

packagesExist(glib-2.0) {
    DEFINES += HAS_GLIB
    PKGCONFIG += glib-2.0
}

// and in the code:
#ifdef HAS_GLIB
    // use glib here
#endif

8 0

void foo(bool bar, bool lol, bool hax, bool meep)
{
    if (bar) {
        if (lol || hax) {
            if (meep) {
                // do something
            }
        }
    }
}

void foo(bool bar, bool lol, bool hax, bool meep)
{
    if (!bar)
        return;

    if (!lol && !hax)
        return;

    if (!meep)
        return;

    // do something
}

12 0