Jump to page: 1 2
Thread overview
Indigo library 0.93
Jul 10, 2005
Uwe Salomon
Jul 10, 2005
Uwe Salomon
Jul 18, 2005
license
Jul 18, 2005
Uwe Salomon
Jul 18, 2005
Uwe Salomon
Jul 14, 2005
Stewart Gordon
Jul 14, 2005
Uwe Salomon
Jul 19, 2005
Stewart Gordon
Jul 19, 2005
Uwe Salomon
Jul 19, 2005
Stewart Gordon
Jul 19, 2005
Uwe Salomon
Jul 20, 2005
Uwe Salomon
Jul 20, 2005
Stewart Gordon
Jul 20, 2005
Uwe Salomon
Jul 22, 2005
Stewart Gordon
Jul 22, 2005
Uwe Salomon
Jul 19, 2005
Uwe Salomon
July 10, 2005
Indigo is a project to provide a platform-independent non-GUI library that accomplishes some of the tasks of the Qt library for C++. Everything is designed to behave as equal to its Qt equivalent as possible, but also to take advantage of D specialties. Everything should be fast and simple. Currently it includes almost all Qt containers, a clean signals&slots implementation, I/O with IODevice, File and DataStream, and internationalisation basics with fast UTF conversion and message translation (including 2 helper programs imupdate and imrelease).

The new message translation module is very easy to use, and the helper program imupdate produces TS files like lupdate from Qt. Use linguist or KBabel to translate, and run imrelease (equivalent to lrelease) afterwards. Message translation is heavily optimized, and imupdate has a sophisticated algorithm to find similar older translations for new/changed strings. I would be happy to receive comments on the API and the programs.

You reach the docs under:
  http://www.uwesalomon.de/code/indigo/index.html
And the source under:
  http://www.uwesalomon.de/code/indigo/indigo.tar.gz

Ciao
uwe
July 10, 2005
Ah, and i forgot: The whole library is now LGPL-licensed. Thanks to Stewart for pointing this out to me. License is included as well, and the zip file now also contains the HTML docs.

Ciao
uwe
July 10, 2005
On Mon, 11 Jul 2005 01:05:05 +0200, Uwe Salomon <post@uwesalomon.de> wrote:
> You reach the docs under:
>    http://www.uwesalomon.de/code/indigo/index.html
> And the source under:
>    http://www.uwesalomon.de/code/indigo/indigo.tar.gz

Are there any screenshots available? I'm very interested in a matter of "look & feel" of indigo. Does it use (will use?) pure XServer / WindowsAPI or some frontend (gtk or smth).
-- 
Dawid Ciężarkiewicz
July 11, 2005
On Mon, 11 Jul 2005 01:50:05 +0200, Dawid Ciężarkiewicz <arael@asn.pl> wrote:

> On Mon, 11 Jul 2005 01:05:05 +0200, Uwe Salomon <post@uwesalomon.de> wrote:
>> You reach the docs under:
>>    http://www.uwesalomon.de/code/indigo/index.html
>> And the source under:
>>    http://www.uwesalomon.de/code/indigo/indigo.tar.gz
>
> Are there any screenshots available? I'm very interested in a matter of "look & feel" of indigo. Does it use (will use?) pure XServer / WindowsAPI or some frontend (gtk or smth).

Sorry. Now I see _non_ -GUI word. Late here - I need a sleep ... dreaming about the library with Qt frontend. :)
-- 
Dawid Ciężarkiewicz
July 14, 2005
Uwe Salomon wrote:
<snip>
> You reach the docs under:
>   http://www.uwesalomon.de/code/indigo/index.html
> And the source under:
>   http://www.uwesalomon.de/code/indigo/indigo.tar.gz

I can compile the modules into a library using a home-made makefile. However, when I try to use it, the linker complains that the symbol _lstat is undefined.

Is there some undocumented library requirement?  Or has it just not been tested under Windows in a while?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
July 14, 2005
> I can compile the modules into a library using a home-made makefile. However, when I try to use it, the linker complains that the symbol _lstat is undefined.
>
> Is there some undocumented library requirement?  Or has it just not been tested under Windows in a while?

The I/O modules have been tested under Windows as well, but obviously not after adding the lstat() function (needed by File.exists). I have fixed the error, and uploaded a new indigo.tar.gz.

Thanks for the report.

Ciao
uwe
July 18, 2005
In article <op.stpzurmn6yjbe6@sandmann.maerchenwald.net>, Uwe Salomon says...
>
>Ah, and i forgot: The whole library is now LGPL-licensed.

How about LGPL with exception allow static linking?

Like the wxWidgets Licence:

http://www.wxwidgets.org/newlicen.htm http://www.wxwidgets.org/licence3.txt


July 18, 2005
> How about LGPL with exception allow static linking?

Arrggh this licensing stuff eats more time than programming. :)  Well, of couse you can link the library to your program statically. There is no way beyond it anyways, as all the templates must be instantiated "freshly". I'll add a notice to the license.

Thanks & ciao
uwe
July 18, 2005
> Arrggh this licensing stuff eats more time than programming. :)  Well, of couse you can link the library to your program statically. There is no way beyond it anyways, as all the templates must be instantiated "freshly". I'll add a notice to the license.

Well, i changed my mind. I will leave the license unchanged. There are enough options specified in section 6 of the LGPL that permit binary distributions of works using the library. If someone needs an exception for his commercial application, he can still contact me.

Ciao
uwe
July 19, 2005
Uwe Salomon wrote:
>> I can compile the modules into a library using a home-made makefile.  However, when I try to use it, the linker complains that the symbol _lstat is undefined.
>>
>> Is there some undocumented library requirement?  Or has it just not been tested under Windows in a while?
> 
> The I/O modules have been tested under Windows as well, but obviously not after adding the lstat() function (needed by File.exists). I have fixed the error, and uploaded a new indigo.tar.gz.

I've now got it installed and running.  Just a few issues drop it short
of perfect.  For example, it's a step behind std.stream in that it only detects EOF after trying to read past the end.  My thought is that an I/O library should be able to detect EOF when it gets there, and that one should also be able to rely on exceptions to catch a premature end of file.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/4085
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24322

This would be simple to implement for File.  It might take a bit of work for other IODevice types but it would be worth it IMO.

But I believe a TextStream is a feasible addition to this library, with the help of a few more IODevice members to help with UTF detection and the like.  I'll see what I can do....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y?
PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
« First   ‹ Prev
1 2