Thread overview
[ot] D and graphics on Linux
Apr 12, 2006
Georg Wrede
Apr 12, 2006
BCS
Apr 13, 2006
Georg Wrede
Apr 12, 2006
John Demme
Apr 13, 2006
Georg Wrede
Apr 13, 2006
Lars Ivar Igesund
Apr 13, 2006
Ant
April 12, 2006
Slightly off-topic, but:

I may be in a position to make the first Processing Plant Production Line Control Software in D. To my knowledge, at least. :-)

That would include, among other things, a display of some of the vital parameters of the process as real-time graphs. (Temperatures, wattages, production speed, etc.)

The choice of language and operating system is mine, and being a D bigot, I really would like to do the stuff in D. And Windows is excluded because the plant can't afford an unstable OS for 24/7 operation. Since D is (more or less) a Win/Lin language, it'll be Linux.


Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)

The graphs will be on X (as opposed to Linux console graphics), so that they can be viewed off-shopfloor too.

Does anybody have experience on this kind of stuff?
April 12, 2006
Georg Wrede wrote:
> Slightly off-topic, but:
> 
> 
> Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)
> 

Is that only your man hours? With this crowd you might be able to get it mostly written while you are out fishing (or waterer). On the other hand, I'm sure you have some kind of deadline calender wise so letting us dink around with parts might no be a good idea (as it might get done using DMD v2.0).   :P

I'm glad to here this and hope to hear good results.
April 12, 2006
Georg Wrede wrote:

> Slightly off-topic, but:
> 
> I may be in a position to make the first Processing Plant Production Line Control Software in D. To my knowledge, at least. :-)
> 
> That would include, among other things, a display of some of the vital parameters of the process as real-time graphs. (Temperatures, wattages, production speed, etc.)
> 
> The choice of language and operating system is mine, and being a D bigot, I really would like to do the stuff in D. And Windows is excluded because the plant can't afford an unstable OS for 24/7 operation. Since D is (more or less) a Win/Lin language, it'll be Linux.
> 
> 
> Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)
> 
> The graphs will be on X (as opposed to Linux console graphics), so that they can be viewed off-shopfloor too.
> 
> Does anybody have experience on this kind of stuff?

There's Ant's D OO frontend for GTK, but I've found it to be pretty incomplete.

I ported the GTK headers to D some time ago (they're close to correct) and they're on dsource.org... I'd recommend using GTK and the GTK headers, this way you can use all the existing GTK stuff.  I also posted headers for Glade, which allows you to design the UI graphically, save it to an XML format, and load the UI from the XML when the program loads.  It's pretty cool, but it's another library you need.  Alternatively, Glade can generate C code to create your interface, and since D works with C....  I haven't made any attempts as using Qt since Qt is c++ based, whereas GTK is pure C.

There's also a D header for ncurses, but I haven't used it.

Personally, I don't like GUI programming in D (it's only slightly better in Java.)  I'm waiting for full shared object support so we can integrate D with python and I can write the GUI stuff in python and everything else in D.

$.02

~John Demme
April 13, 2006
BCS wrote:
> Georg Wrede wrote:
> 
>> Slightly off-topic, but:
>>
>> Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)
>>
> Is that only your man hours? With this crowd you might be able to get it mostly written while you are out fishing (or waterer).

Sure. But not paying everybody while I'm getting paid myself is embarrassing. :-)

OTOH, we're all here doing free work for Walter, so maybe I shouldn't be that embarrassed. :-P Besides, in my own mind I probably should think I'm charging for consultation and delivery (just as if I were delivering an OSS thing), and not for programming as such.

Then the code would be in the Public Domain, and so help other folks too.

> On the other hand, I'm sure you have some kind of deadline calender wise so letting us dink around with parts might no be a good idea (as it might get done using DMD v2.0).   :P

I can always blame the guys doing the welding and stuff!

> I'm glad to here this and hope to hear good results.

It would be cool for Walter to be able to brag around that D is already used in Factory Control!!!
April 13, 2006
John Demme wrote:
> Georg Wrede wrote:
> 
>>Slightly off-topic, but:
>>
>>I may be in a position to make the first Processing Plant Production
>>Line Control Software in D. To my knowledge, at least. :-)
>>
>>That would include, among other things, a display of some of the vital
>>parameters of the process as real-time graphs. (Temperatures, wattages,
>>production speed, etc.)
>>
>>The choice of language and operating system is mine, and being a D
>>bigot, I really would like to do the stuff in D. And Windows is excluded
>>because the plant can't afford an unstable OS for 24/7 operation. Since
>>D is (more or less) a Win/Lin language, it'll be Linux.
>>
>>Now, being a pay-project, I need to find a productive choice of
>>libraries and tools to maximise Productivity. (Specified as man-hours to
>>delivery.)
>>
>>The graphs will be on X (as opposed to Linux console graphics), so that
>>they can be viewed off-shopfloor too.
>>
>>Does anybody have experience on this kind of stuff?
> 
> There's Ant's D OO frontend for GTK, but I've found it to be pretty
> incomplete.
> 
> I ported the GTK headers to D some time ago (they're close to correct) and
> they're on dsource.org... I'd recommend using GTK and the GTK headers, this
> way you can use all the existing GTK stuff. 

Yes, this has been one of the alternatives.

> I also posted headers for
> Glade, which allows you to design the UI graphically, save it to an XML
> format, and load the UI from the XML when the program loads.  It's pretty
> cool, but it's another library you need.

This would save a lot of time, I think.

> Alternatively, Glade can generate
> C code to create your interface, and since D works with C.... 

I'd like to do as much as possible in D. But this has been an alternative too.

> I haven't
> made any attempts as using Qt since Qt is c++ based, whereas GTK is pure C.

Yeah, besides, being a pay-project, I don't even know if Qt would be ok.

> There's also a D header for ncurses, but I haven't used it.

Character-block graphics might even be sufficient, but then the users and managers would look down on it. (This is just so typical!)

> Personally, I don't like GUI programming in D (it's only slightly better in
> Java.)  I'm waiting for full shared object support so we can integrate D
> with python and I can write the GUI stuff in python and everything else in
> D.

Yeah, there's so much drudgery and so little interesting things. Ideally a RAD system (Kylix comes to mind, a vast choice Java IDEs, etc) would be the smart thing to use here, but "I wanna do it in D".
April 13, 2006
John Demme wrote:

> Georg Wrede wrote:
> 
>> Slightly off-topic, but:
>> 
>> I may be in a position to make the first Processing Plant Production Line Control Software in D. To my knowledge, at least. :-)
>> 
>> That would include, among other things, a display of some of the vital parameters of the process as real-time graphs. (Temperatures, wattages, production speed, etc.)
>> 
>> The choice of language and operating system is mine, and being a D bigot, I really would like to do the stuff in D. And Windows is excluded because the plant can't afford an unstable OS for 24/7 operation. Since D is (more or less) a Win/Lin language, it'll be Linux.
>> 
>> 
>> Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)
>> 
>> The graphs will be on X (as opposed to Linux console graphics), so that they can be viewed off-shopfloor too.
>> 
>> Does anybody have experience on this kind of stuff?
> 
> There's Ant's D OO frontend for GTK, but I've found it to be pretty incomplete.

Well it's been through a makeover, and I'm finding it quite complete now, although it hasn't been through much testing yet to be totally sure that everything works as it should. Ant is fairly responsive whenever somebody reports an issue though. Of course, I'm currently using it, so I say the more, the merrier :) Whether it's the most productive solution is another question, if you know gtk, it should be quite easy to find the D'ified solution.

April 13, 2006
In article <e1lnfk$2hn5$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>John Demme wrote:
>
>> Georg Wrede wrote:
>> 
>>> Slightly off-topic, but:
>>> 
>>> I may be in a position to make the first Processing Plant Production Line Control Software in D. To my knowledge, at least. :-)
>>> 
>>> That would include, among other things, a display of some of the vital parameters of the process as real-time graphs. (Temperatures, wattages, production speed, etc.)
>>> 
>>> The choice of language and operating system is mine, and being a D bigot, I really would like to do the stuff in D. And Windows is excluded because the plant can't afford an unstable OS for 24/7 operation. Since D is (more or less) a Win/Lin language, it'll be Linux.
>>> 
>>> 
>>> Now, being a pay-project, I need to find a productive choice of libraries and tools to maximise Productivity. (Specified as man-hours to delivery.)
>>> 
>>> The graphs will be on X (as opposed to Linux console graphics), so that they can be viewed off-shopfloor too.
>>> 
>>> Does anybody have experience on this kind of stuff?
>> 
>> There's Ant's D OO frontend for GTK, but I've found it to be pretty incomplete.
>
>Well it's been through a makeover, and I'm finding it quite complete now, although it hasn't been through much testing yet to be totally sure that everything works as it should. Ant is fairly responsive whenever somebody reports an issue though. Of course, I'm currently using it, so I say the more, the merrier :) Whether it's the most productive solution is another question, if you know gtk, it should be quite easy to find the D'ified solution.
>

I'll make a formal announcement of the new version soon.
Before that I'm finising converting leds to the new version and
I need to test and fix the windows version.
The big change is the binding/wrapping is now totally automated.
(I'll also be changing the name from DUI to GtkD (maybe)).

Ant