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
 
 

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 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
will be planty of others (same is with C# at the moment - gtk#, wx#, qt#...
- 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
 will be planty of others (same is with C# at the moment - gtk#, wx#, qt#...
 - 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
 will be planty of others (same is with C# at the moment - gtk#, wx#, qt#...
 - 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
 will be planty of others (same is with C# at the moment - gtk#, wx#, qt#...
 - 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
 will be planty of others (same is with C# at the moment - gtk#, wx#, qt#...
 - 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