| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 16 17 18 19 20 21 22 23 24 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90
| XCB out, GTK in | |
|---|---|
|
Date: 19/3/2010 | So I've removed all traces of XCB from the Linux build of Lgi and replaced it with Gtk2. I found that the Xcb library too under-documented, the community / mailing list helpful but not to the point of resolving issues I had and most of all, the end result was much slower than xlib, for reasons I don't fully understand. So I give up.
The Gtk build of Lgi boots a blank window in LgiIde so far, which is a good sign. A few hours of hacking and I have something to look at already. I expect adding some basic sub-views, menus etc will actually take relatively little time, although that said I already have no time to work on code so maybe they cancel out! And yes, this does mean I may be moving away from Lgi as a "to the metal API" and it might morph into a wrapper around something else as a half way house for my apps. I may not be using C++ in 5 years time, the world is changing and the web is taking over everything, and I have less and less time to work on fun projects. Maybe even the Mac port might become a wrapper around Gtk... who knows. But it does give me options. My plan with the Gtk stuff is to use as little as possible of the Gtk layout stuff and have it as a very thin layer between Lgi and the underlying OS. That way hopefully the apps look and feel like an Lgi app still, and not Gtk like at all. I generally feel Gtk has the lowest look and feel index of all the xp-libs, but it runs everywhere and the license is compatible. The other option in my mind was Qt, but the slots system pissed me off no end when I used it 6-7 years ago. So I really didn't want to use that. And Wx is a wrapper around Gtk anyway, so why bother with that? Unless there is a compelling alternative to Gtk that I should know about? |
| (0) Comments | Add Comment | |
| Scribe v2 Final | |
|---|---|
|
Date: 9/3/2010 | What would be a good line in the sand for Scribe v2 Final?
Its an interesting question to some. But I think I'm going to fix all the P1, P2 and P3 bugs and then call it good enough. So if there is some glaring issue that's not in the bug db... well you better go and put it in there. And if you disagree with any of the priority ratings then let me know (I wouldn't advise just changing them yourself). Make your case for why it is or isn't a priority and I'll think about it. Anyway, now I think I have a goal. Squash all the high priority bugs ASAP. New release tonight (hopefully) fixes 10 more bugs. |
| (0) Comments | Add Comment | |
| Gamma correct scaling... | |
|---|---|
|
Date: 25/2/2010 | Seems that scaling isn't as simple as I thought... apparently there are non-trivial issues with gamma involved.
I took some time today to revise the standard LGI scaling algorithm (most visible in i.Mage) to use 16 bits/component linear RGB internally using lookup tables (8.8 precision) into and out of sRGB. This fixes the scaler for these types of images and I keep the integer only internal loops for speed. Nice. |
| (4) Comments | Add Comment | |
| Scribe Folder Migration | |
|---|---|
|
Date: 20/2/2010 | In the release of Scribe I'm preparing today, there is a functional replication feature that can actually copy your mail2 file into a mail3 store. Well at least all your email and contacts. Other types will follow in later releases. But that is a great start.
Once that is stable (your feedback would be welcome), then I will build a little wizard over the top of it to help people upgrade their folders semi-automatically when they install Scribe v2 over v1. The process at the moment, given you have a mail2 folder, is to:
So far I've only tested it with Mail2 -> Mail3. However in theory it should work in the opposite direction as well. And in the future it'll handle IMAP as well. So one will be able to seamlessly go from Mail2 <-> Mail3 <-> IMAP <-> whatever... |
| (0) Comments | Add Comment | |
| Webscheduler Quirk | |
|---|---|
|
Date: 19/2/2010 | If your WebScheduler install starts writing .bin files instead of .ts and you check in the System settings and under Capture.deftype all you have is "error" then you need to restart the DVB Web Scheduler service. And everything will go back to normal.
This has been a community announcement for the edification of those who use google. This is one of those every few years of so problems I get with the saintly WebScheduler. |
| (0) Comments | Add Comment | |
| Thoughts on Lgi | |
|---|---|
|
Date: 10/2/2010 | Well it's been some years now since a decent build of Scribe or i.Ftp has been done for Linux or Mac, and I'm beginning to rethink my strategy with regards to Lgi and it's cross platform nature. One option that is increasingly attractive to me is making a "port" of Lgi to something like GTK. It's kinda cheating and it won't be pretty or super fast. But it would give my a leg up to making the apps run without huge issues on the platforms that I want to target. I think it especially makes sense for Linux because it's a standard library thats already installed and the current XCB codebase is likely going down the wrong track performance wise. I think XCB on the surface is a great idea, but in practice there is too little documentation, examples and community to help you through. I suspect the larger widget libraries are using a single X window at the top level and then managing all their own widgets as "virtual" sub-windows that X doesn't know about directly. Thats good for performance and good for visual flexibility, but a lot of work. If I was to retrofit my XCB codebase for that it would only mean I'll never finish anything.
So it's 2010, and I have a limited amount of coding time.. so what works for me is getting the most bang for buck. That means leveraging what I can to get the software running and stable even if it means making sacrifices in some areas with regards to speed and dependencies. The 2 target API's I have in mind are GTK and Qt, both of which are LGPL like Lgi, so I think license wise I'm ok. When I started Lgi, GTK and Qt weren't widely known or used, and I wouldn't have written Lgi if there was an obvious alternative. But now there are lots of obvious alternatives and I'm think I should maybe transition away from maintaining this large codebase I've built up over the years. I do have reservations with GTK, the unholy amount of whitespace it seems to use everywhere for one, but I have a lot of custom controls that I could use instead of the GTK controls. So maybe all I have to do is write a really thin layer that uses a bare minimum of GTK for a drawable custom control that gets reused by all the native Lgi controls. And I can still override the file open dialogs with the native ones etc. |
| (0) Comments | Add Comment | |