| mwcampbell | Is there a way to programmatically adjust the CPU's clock speed? | 00:22 |
|---|---|---|
| pcercuei | yes, through the sysfs interface | 00:24 |
| mwcampbell | On the Ben, is there any reason why an SDL-based UI would be much more efficient than a Qt-based one? | 01:40 |
| vignesh885 | hi i have a seagate 1tb external harddisk and it is not being detected by the computer | 08:57 |
| vignesh885 | anoyne there?? | 08:59 |
| valhalla | vignesh885: which computer? is it related to the nanonote, milkymist or other projects from http://qi-hardware.com ? | 09:12 |
| valhalla | (which is what this channel is about) | 09:14 |
| kristianpaul | mwcampbell: i think QT one could be more efficient | 16:54 |
| kristianpaul | in terms of UI and such, also more responsive i think | 16:54 |
| larsc | well qt is not that lightweight | 16:55 |
| lekernel | qt is mega bloat | 16:57 |
| lekernel | use efl | 16:57 |
| lekernel | it's the least sucky toolkit around imo | 16:57 |
| mwcampbell | Can EFL use the framebuffer device directly? | 16:59 |
| lekernel | theoretically yes | 16:59 |
| lekernel | there is code for this, don't know about its bug rate | 17:00 |
| whitequark | lekernel: please, don't spread fud | 17:02 |
| whitequark | qt embedded is very lightweight for such an advanced framework | 17:03 |
| lekernel | oh yeah, it's advanced: it has lists, threads, networking, and what not | 17:03 |
| lekernel | so you end up very easily with code having 2 or more implementations of lists, threads, sockets, etc. | 17:03 |
| whitequark | yes, it's better to write your own shims for various components which were never intended to be used together in each application from scratch | 17:05 |
| whitequark | honestly, I'm not even going to discuss this | 17:05 |
| lekernel | a GUI toolkit should not have threads, networking, etc. - period! | 17:05 |
| whitequark | though I do agree that the set of abstractions provided by UNIX-like OSes is exceptionally shitty | 17:05 |
| whitequark | lekernel: well, it doesn't have an alternative. | 17:05 |
| lekernel | and face it, a statically linked hello world application using qt is over 20MB, lol | 17:06 |
| whitequark | lekernel: um, no, I don't think it is (if you don't link everything there is in Qt, including QtWebkit), or that this even matters | 17:07 |
| lekernel | besides, qt looks ugly, takes times to refresh stuff which causes flashes and transient visual chaos, and uses c++ | 17:07 |
| whitequark | my builds of Qt Embedded have had about 8 MB of shared code, which was not duplicated between the applets | 17:07 |
| lekernel | look at the ipad... and then look at qt | 17:07 |
| whitequark | um, you mean look at Cocoa, a gui toolkit which has threads, networking, etc. ? | 17:08 |
| lekernel | can't comment on the internal APIs since I have never tried to use them, but it looks good and it's responsive | 17:09 |
| lekernel | much better than anything else | 17:09 |
| whitequark | this is a bullshit argument, honestly | 17:10 |
| whitequark | do you know the single trick which is required for your app to be that responsible on touchscreen devices? | 17:10 |
| whitequark | do everything GUI-related on a dedicated thread and give it the highest priority. | 17:10 |
| lekernel | and especially qt, gtk and let's not mention crap designed specifically for x-windows (eg http://www.opengroup.org/openmotif/banner3.jpg) | 17:10 |
| whitequark | this is why android 2.x was slow. this is why android 3/4 isn't anymore. this is the sole reason iOS feels responsive. | 17:11 |
| whitequark | it has absolutely zero things to do with framework design and whatnot | 17:11 |
| whitequark | (ugliness is subjective. I'd rather not touch the glossy shit ever in my life.) | 17:12 |
| mwcampbell | whitequark: Your rebuttal makes sense. | 17:16 |
| whitequark | hehe thanks | 17:17 |
| mwcampbell | So is Qt a reasonable choice for a UI that will be usable on a device with no mouse or touchscreen, like the NanoNote? | 17:17 |
| whitequark | mwcampbell: considering the most recent qt snapshot still fits in the RAM of NN and leaves enough space to run the applications, yes | 17:18 |
| lekernel | if you want to make a shitty GUI "open source always get a second class seat" yes | 17:18 |
| whitequark | lekernel: besides, what do you think one should use instead of C++? | 17:20 |
| whitequark | (please don't say python. for the love of everything good in this world. for kittens.) | 17:21 |
| mwcampbell | lekernel: I don't care about surface aesthetics, as long as I can make the UI responsive. My only concern in that area is whether a framebuffer without GPU acceleration is going to be too inefficient. | 17:21 |
| lekernel | well, lua looks interesting | 17:21 |
| whitequark | mwcampbell: Qt Embedded was originally designed for devices without GPU, well, because when it was designed, there were no such devices. | 17:21 |
| lekernel | and btw "surface" aesthetics is the purpose of a GUI, otherwise use command line | 17:22 |
| whitequark | aestethics has nothing to do with usability. taking your ipad, I can make every corner straight and paint it black&white. it won't get less convenient. | 17:24 |
| mwcampbell | lekernel: The purpose of a GUI is usability. Gradients versus solid backgrounds, 3D versus flat UI, is only skin-deep, and isn't something worth considering IMO when choosing a foundational technology. | 17:24 |
| whitequark | that being said, open source guis probably have the most shitty usability of all software ever written | 17:24 |
| whitequark | be it KDE, GNOME with snake-oil HIG, or whatever | 17:25 |
| lekernel | why should the UI toolkit be a "foundational" technology? they should not have threads, database access, networking, etc. | 17:26 |
| whitequark | lekernel: because it had, and mostly, still has, nothing to be based on. | 17:27 |
| whitequark | pthreads is not a sensible API, BSD sockets is not a sensible API, and so on. | 17:27 |
| whitequark | just as string.h is not a sensible API. | 17:27 |
| lekernel | http://qt-project.org/search/tag/qmysql what the hell, seriously :) | 17:27 |
| lekernel | yes, right | 17:28 |
| whitequark | lekernel: do you know what ODBC is? | 17:28 |
| lekernel | but how about decoupling the rendering part from sockets, threads, etc.? | 17:28 |
| whitequark | lekernel: it's not coupled? | 17:28 |
| lekernel | well it is: you have QThread, QMYSQL ... | 17:29 |
| whitequark | so? | 17:29 |
| lekernel | why should you need any of this to define what a button looks like, and how it responds to a given event? | 17:29 |
| whitequark | you don't need that? | 17:29 |
| mwcampbell | lekernel: Those are separate libraries. | 17:29 |
| whitequark | don't link QMySQL, don't get it | 17:29 |
| mwcampbell | And if you're linking statically, modern toolchains can even eliminate dead code on a per-function basis | 17:29 |
| lekernel | last time I checked, gcc/binutils still didn't - but don't get me started on that ... | 17:30 |
| whitequark | gcc is not modern :p | 17:30 |
| whitequark | gold has some support for LTO but it never really worked for me | 17:30 |
| larsc | you can put each function in it's own section with gcc | 17:30 |
| whitequark | MSVC can do that, LLVM can do that, ICC can do that, IAR can do that... | 17:30 |
| lekernel | yeah there's -ffunction-sections, but it's a bit messy | 17:31 |
| mwcampbell | combine that with the -gc-sections linker option, and there you have it, dead-code elimination | 17:31 |
| mwcampbell | LTO is better still, of course, since then you can have cross-module inlining | 17:33 |
| whitequark | IPSCCP also | 17:33 |
| whitequark | and DAE | 17:34 |
| lekernel | -ffunction-sections/-gc-sections take forever on a moderately sized program, which I guess is why those options aren't turned on by default | 17:34 |
| mwcampbell | What are IPSCCP and DAE? | 17:34 |
| whitequark | interprocedural sparse conditional constant propagation and dead argument elimination | 17:34 |
| whitequark | well, linking webkit with LTO takes ~8 hours on a 12-core desktop i7, or that's what I've been told | 17:35 |
| whitequark | webkit is also enourmous | 17:35 |
| whitequark | (that was MSVC IIRC) | 17:35 |
| mwcampbell | but apparently the Chrome project considers it worthwhile to do so | 17:36 |
| whitequark | it is. | 17:36 |
| whitequark | especially for Webkit, which is a huge C++ codebase with lots of small, often hot functions. | 17:36 |
| mwcampbell | whitequark: I know I'm getting a bit off-topic here, but can current LTO implementations also detect virtual functions that only have one implementation and turn them into plain functions, to avoid the indirection of a vtable dispatch? | 17:38 |
| whitequark | mwcampbell: no, because you might load alternative implementations at runtime | 17:38 |
| larsc | well, you probably wouldn't do this during development, but for release binaries it makes sense. since you only compile once, but run it quite often | 17:38 |
| whitequark | mwcampbell: though if they're module-internal, then yes, LLVM can do that in some cases | 17:39 |
| mwcampbell | I wonder if the Linux kernel would benefit much from LTO. Of course, that would only be effective if one disabled loadable modules. | 17:42 |
| larsc | there are some people experimenting with lto for the kernel | 17:43 |
| whitequark | mwcampbell: not necessarily | 17:43 |
| whitequark | unless you override existing functions, you still can keep the uninlined version and export the same symbol for modules | 17:43 |
| whitequark | trading off size for performance, of course | 17:43 |
| larsc | http://lwn.net/Articles/512335/ | 17:45 |
| mwcampbell | I imagine one could achieve another performance boost by combining the application and the OS in one binary, as some RTOSes do, and applying LTO to that. But of course such a system is much less hackable than a general-purpose OS like Linux. | 17:49 |
| mwcampbell | I vaguely remember Qt Embedded having its own windowing system of sorts, so one could at least flip between applications without having to run each one on its own virtual console. | 17:53 |
| whitequark | mwcampbell: yeah it has its own framebuffer compositor | 17:54 |
| whitequark | there isn't a way to share a framebuffer otherwise. DFB has its own, GTK... I've no idea but probably the same | 17:54 |
| mwcampbell | Does the version of Qt on the NanoNote have that compositor? | 17:54 |
| paul_boddie | If you want to reduce the "bloat" in Qt, configure it without WebKit. | 17:55 |
| lekernel | well there's this | 17:55 |
| lekernel | http://en.wikipedia.org/wiki/OPIE_user_interface | 17:55 |
| mwcampbell | ah yes, I remember OPIE | 17:55 |
| paul_boddie | Besides, the whole reason for providing threading, database stuff in Qt is because somebody has to: C++ doesn't have high-level libraries for that stuff out of the box. Also, the data types in Qt date from a time when the STL wasn't ready for prime time, and I think they're trying to reconcile all that in Qt 5. | 17:57 |
| paul_boddie | Of course, Qt should be more modular and that was a goal of the developers, but they got carried away and made Qt larger and often more reliant on the peripheral libraries because they didn't finish the job (as far as I understand it). | 17:58 |
| paul_boddie | And then some bright spark decided to suck in WebKit and duplicate half the stack (multiple JavaScript, XML libraries), but that may have been in the Nokia era where targeting Symbian was seen as a "good idea". | 17:59 |
| mwcampbell | I observe that the version of Qt in the NanoNote image doesn't have WebKit, so that's not an issue. | 18:01 |
| paul_boddie | You'd have to leave WebKit out of any build for the NanoNote purely for memory exhaustion reasons. I guess you could try and configure it aggressively to only have the fundamental UI stuff. In fact, this is one of the things that Python developers found weird about Qt: that it "duplicated" libraries that you'd normally use instead in Python. | 18:03 |
| mwcampbell | I have no interest in trying to port WebKit to the NanoNote. | 18:03 |
| paul_boddie | Then again, there were benefits to wrapping qtxml or KHTML in Python and having a proper DOM, the latter even with support for stuff like ranges, mostly because of the continuous whining in the Python community about the DOM and their scorched earth retreat from the interactive Web. | 18:04 |
| paul_boddie | s/the interactive Web/supporting and developing client technology for the Web/ | 18:06 |
| paul_boddie | BTW, I read on LWN today that in the Raspberry Pi talk at PyCon, Eben Upton says that they use Python to develop and verify their opaque Broadcom silicon. | 18:07 |
| paul_boddie | What about QtMoko? http://qtmoko.sourceforge.net/ | 18:18 |
| HoytCorkins | hello | 20:16 |
| HoytCorkins | someone here? | 20:17 |
| pcercuei | yep | 20:22 |
| --- Fri Mar 22 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
