www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GUI libraries as part of compiler

reply Bill <Bill_member pathlink.com> writes:
Hi, this might be a totally stupid question, but anyway...

Is there a special reason why the GUI toolkits for the D language are developed
as add-ons to the compiler, instead of making them part of the compiler where
they IMHO should belong?

If, for example I call some function like CreateWindow then the *compiler*
should decide which Windows, Linux, OSX, etc. function it uses. Wouldn't that be
better than doing a translation at *run-time*? (WRT performance and exe size?).

I'm sure there are good reasons, I just don't know them.

Bill
Apr 22 2005
next sibling parent Brad Beveridge <brad somewhere.net> writes:
Bill wrote:

 Hi, this might be a totally stupid question, but anyway...
 
 Is there a special reason why the GUI toolkits for the D language are developed
 as add-ons to the compiler, instead of making them part of the compiler where
 they IMHO should belong?
 
 If, for example I call some function like CreateWindow then the *compiler*
 should decide which Windows, Linux, OSX, etc. function it uses. Wouldn't that
be
 better than doing a translation at *run-time*? (WRT performance and exe size?).
 
 I'm sure there are good reasons, I just don't know them.
 
 Bill
 
 


Surely this completely depends on what GUI library you are using?  In 
fact I would think that no cross platform GUI library actually does the 
underlying OS call translation at runtime, because none of the OSes 
share a compatible binary format - ie, you need to target the library to 
an OS at compile time.
No C/C++ compiler that I know of has built-in GUI elements - perhaps I 
am misunderstanding your question?

Cheers
Brad
Apr 22 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
If you use version, then it is at compile time.  Example:

version (Windows)
   blah();
version (linux)
   blah2();

Which version is used will depend on what platform it is compiled on 
(this ain't bytecode, so it does have to be recompiled for each 
platform, which is - yes - faster, because it's not runtime as you say.)

If a GUI library were added as part of D, it would in the greatest 
likelyhood just be implemented as D code, in phobos or similar.  It 
would be no different from the add-ons currently available, except that 
it would come with D.

-[Unknown]



 Hi, this might be a totally stupid question, but anyway...
 
 Is there a special reason why the GUI toolkits for the D language are developed
 as add-ons to the compiler, instead of making them part of the compiler where
 they IMHO should belong?
 
 If, for example I call some function like CreateWindow then the *compiler*
 should decide which Windows, Linux, OSX, etc. function it uses. Wouldn't that
be
 better than doing a translation at *run-time*? (WRT performance and exe size?).
 
 I'm sure there are good reasons, I just don't know them.
 
 Bill
Apr 22 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I like the idea of one coming with D.
Particularly, because it would save people who are
short on time (like me) having to find what all is out there,
sift through it, figure out how to install it, test it,
uninstall it (in every case I've tried so far) and
eventually choose one to go with that is satisfactory.

Unfortunately, the majority of what I have found out there
assumes a C or C++ development system environment,
complete with "make" and so on, set up
in a configuration similar to the one in which the tools were
developed. I wanted to set up a "pure D" environment,
so I have avoided just that sort of setup...
and as a result, almost nothing works.

TZ

"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:d4bnmi$520$1 digitaldaemon.com...

 If you use version, then it is at compile time.  Example:

 version (Windows)
    blah();
 version (linux)
    blah2();

 Which version is used will depend on what platform it is compiled on
 (this ain't bytecode, so it does have to be recompiled for each
 platform, which is - yes - faster, because it's not runtime as you say.)

 If a GUI library were added as part of D, it would in the greatest
 likelyhood just be implemented as D code, in phobos or similar.  It
 would be no different from the add-ons currently available, except that
 it would come with D.

 -[Unknown]



 Hi, this might be a totally stupid question, but anyway...

 Is there a special reason why the GUI toolkits for the D language are developed
 as add-ons to the compiler, instead of making them part of the compiler where
 they IMHO should belong?

 If, for example I call some function like CreateWindow then the *compiler*
 should decide which Windows, Linux, OSX, etc. function it uses. Wouldn't that
be
 better than doing a translation at *run-time*? (WRT performance and exe size?).

 I'm sure there are good reasons, I just don't know them.

 Bill
Apr 25 2005
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
In fact it doesn't and shouldn't be done at run time in these GUI
libraries.  Most will implement themselves as follows:

version(Win32) {
	extern (C) ... // Windows functions here
	void CreateWindow() {
		//Win32 Gui code
	}
} else {
	extern (C) ... //GTK functions
	void CreateWindow() {
		//Create a GTK window
	}
}

Or something like that.  Then, when the program is compiled, either the
Win32 version is selected, or the GTK one is.  Of course, this is just
one possible way for it to be done, but with the version blocks, it's
done at compile time... There's no reason for the compiler to get
involved!

John Demme


On Fri, 2005-04-22 at 20:39 +0000, Bill wrote:

 Hi, this might be a totally stupid question, but anyway...
 
 Is there a special reason why the GUI toolkits for the D language are developed
 as add-ons to the compiler, instead of making them part of the compiler where
 they IMHO should belong?
 
 If, for example I call some function like CreateWindow then the *compiler*
 should decide which Windows, Linux, OSX, etc. function it uses. Wouldn't that
be
 better than doing a translation at *run-time*? (WRT performance and exe size?).
 
 I'm sure there are good reasons, I just don't know them.
 
 Bill
Apr 22 2005
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Bill wrote:

 Hi, this might be a totally stupid question, but anyway...
 
 Is there a special reason why the GUI toolkits for the D language are developed
 as add-ons to the compiler, instead of making them part of the compiler where
 they IMHO should belong?


It's Walter's philosphy. It makes sense to me.


 From http://www.digitalmars.com/drn-bin/wwwnews?D/8218:

[Sat, 7 Sep 2002 10:00:33 -0700 "Walter"]

"I'd like to make the point that there will be no gui as part of D. 
There may be plenty of gui toolkits for D, and some may even ship with D 
compiler packages, but D itself should not be tied to any particular gui 
ideas.

"Anyone who believes strongly that a gui should be done a certain way 
won't get any argument from me, other than encouragement to implement it 
in D! D will be better off having a rich assortment of gui toolkits 
available."



-- 
jcc7
http://jcc_7.tripod.com/d/
Apr 22 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
Bill, I agree with You - D should have IMHO one, standard GUI. Sure there

- but the one, standard GUI there is used widely - SWF, not others. Same
with JAVA).

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
Apr 23 2005
next sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
I happen to agree also.

In fact, this is part of what I had hoped for when I mentioned implicit imports.
As long as the calling conventions and return values are kept consistant,
such a GUI could be updated, modified, extended, etc...
and re-compiling a program with the new implementation would
update that program.

I expect those of us who think this way to be the
minority though, so I doubt it will happen in D.

Still, it's only by voicing our opinions that we may change it from
not possible to remotely possible.  :)


"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:d4d8ps$1ev2$1 digitaldaemon.com...

 Bill, I agree with You - D should have IMHO one, standard GUI. Sure there

 - but the one, standard GUI there is used widely - SWF, not others. Same
 with JAVA).

 -- 
 ...........
 Dejan Lekic
   http://dejan.lekic.org
Apr 24 2005
next sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
To those of you who can't stand top down posts...
sorry.  Did it again.

TZ
Apr 24 2005
prev sibling parent reply Bill <Bill_member pathlink.com> writes:
The reason I asked was that for example (C++) GUI libraries such as
wxWidgets come with a run-time overhead in executable size. That means
the program grows larger compared to the same program with direct API
calls. For some reason, I thought that were also true for D GUI libs,
but I'm glad it isn't.

Bill

In article <d4gt5c$5es$1 digitaldaemon.com>, TechnoZeus says...


I happen to agree also.

In fact, this is part of what I had hoped for when I mentioned implicit imports.
As long as the calling conventions and return values are kept consistant,
such a GUI could be updated, modified, extended, etc...
and re-compiling a program with the new implementation would
update that program.

I expect those of us who think this way to be the
minority though, so I doubt it will happen in D.

Still, it's only by voicing our opinions that we may change it from
not possible to remotely possible.  :)


"Dejan Lekic" <leka entropy.tmok.com> wrote in message
news:d4d8ps$1ev2$1 digitaldaemon.com...

 Bill, I agree with You - D should have IMHO one, standard GUI. Sure there

 - but the one, standard GUI there is used widely - SWF, not others. Same
 with JAVA).

 -- 
 ...........
 Dejan Lekic
   http://dejan.lekic.org
Apr 24 2005
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Bill wrote:

 The reason I asked was that for example (C++) GUI libraries such as
 wxWidgets come with a run-time overhead in executable size. That means
 the program grows larger compared to the same program with direct API
 calls. For some reason, I thought that were also true for D GUI libs,
 but I'm glad it isn't.


The overhead in executable size for wxWidgets is *only* for convenience 
and high-level features not included in the native APIs. VCL from 
Borland, completely Windows-specific by original design, is 
approximately same slow and big, and offers a similar level of 
consistency and convenience. wxWidgets excludes everything which is not 
for the target you are compiling it for, your statement on runtime 
selection is completely and utterly false.

There are a few libraries which cut corners and are a thin but fairly 
convenient layer over the native API - however, the cut corners mean 
that interface parts are too much ancohred in the workings of the 
operating system - and by this i mean organization and concepts, not how 
a concrete function is called.

Making provisions in compiler is extremely tedious, and you really won't 
find programmers to take care of it - there are however general compiler 
improvements outstanding which might improve situation, especially in 
connection with whole-program compilation. When i think of it, creating 
a thin but cross-platform library in C++ might be possible, but probably 
quite some piece of a nightmare to implement, though still easier than a 
compiler.

-eye
Apr 28 2005
parent reply Bill <Bill_member pathlink.com> writes:
Ilya, thanks heaps for your answer. By "thin layer", do you mean one that
doesn't produce any overhead compared to directly using the API?

Bill
Apr 29 2005
parent Ilya Minkov <minkov cs.tum.edu> writes:
Bill wrote:

 Ilya, thanks heaps for your answer. By "thin layer", do you mean one that
 doesn't produce any overhead compared to directly using the API?
 
 Bill


They do produce some overhead as well, just not as much. One nice 
example is this one, however i have seen some more very similar ones: 
http://www.codeproject.com/library/classlib.asp .

Perhaps there is something comparable among GTK C++ wrappers - I'm not sure.

One possible way to reduce overhead down to almost zero, is to dump true 
object-orientation from the library. Native type wrappers be structs, 
holding pointers to OS-specific structures, and then there be getters 
and setters and manipulation functions which are to be one-liners and 
always inline.

Unfortunately i don't have the time nor the power to deeply think about 
how to craft a more versatile platform-independant thin layered GUI, and 
what compiler optmizations or additional language features may be 
helpful to implement it, but this is almost certainly an interesting 
question, on which i might pick up whenever i have time - perhaps after 
many years. :> This is not a GUI-only problem, it would be also helpful 
in other fields of software development.

-eye/photoAllergics
Apr 30 2005
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Dejan Lekic wrote:

 Bill, I agree with You - D should have IMHO one, standard GUI. Sure there

 - but the one, standard GUI there is used widely - SWF, not others. Same
 with JAVA).


The problem is that GUI libraries can be designed in many different ways.

If one were to be made a standard part of D, the D programming community 
would need to come to an agreement on which design we should throw in.

Moreover, since D is designed to be compiled to native code and to be 
able to do systems programming work, it makes sense to be able to follow 
easily the conventions and mechanics of each OS.  Do the current 
cross-platform GUI libs facilitate this?  This is certainly a hurdle for 
any cross-platform GUI library on the way to becoming really ready to 
ship with D.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Apr 25 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Maybe instead of picking a "finished" GUI library, it would be better to
include the beginnings of one in such a way that it can be expanded and
improved as time goes by.  That way, it could be written entirely in D, and
constructed as an open source component.

Don't take that as a "well thought out suggestion" but rather as
brainstorming... I would like to see what positive brainstorming can do here,
so perhaps this is a good opportunity to find out.  Looking forward to seeing
what comes up.

TZ

"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d4ie2m$1f0e$1 digitaldaemon.com...

 Dejan Lekic wrote:

 Bill, I agree with You - D should have IMHO one, standard GUI. Sure there

 - but the one, standard GUI there is used widely - SWF, not others. Same
 with JAVA).


 The problem is that GUI libraries can be designed in many different ways.

 If one were to be made a standard part of D, the D programming community
 would need to come to an agreement on which design we should throw in.

 Moreover, since D is designed to be compiled to native code and to be
 able to do systems programming work, it makes sense to be able to follow
 easily the conventions and mechanics of each OS.  Do the current
 cross-platform GUI libs facilitate this?  This is certainly a hurdle for
 any cross-platform GUI library on the way to becoming really ready to
 ship with D.

 Stewart.

 -- 
 My e-mail is valid but not my primary mailbox.  Please keep replies on
 the 'group where everyone may benefit.
Apr 28 2005