View mode: basic / threaded / horizontal-split · Log in · Help
May 28, 2005
Re: Harmonia way. sort of resume
I thought you weren't willing to five harmonia up to being in the standard D
library?

Weren't we trying to come up with soemthing for that?

However, harmonia sounds awesome and I am really enthousaiastic about it's
development, as it will provide D programers with a solid option.

I don't know, maybe D should NEVER have a GUI toolkit that is more assocated
with the core language than any other. Maybe doing so would be disasterous, just
as Glut became a dinosour as soon as OpenGL leveled off. Now with OpenGL
flourishing again Glut seems like a bad joke.

And yes, I have used Glut before, thats how I know. As well as Native Win32,
SDL, FLTK, GLFW, and Cpw. None of which satisfy me, so I am writing me own.

If you want  something done right you have to do it youself.. Usually.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com
May 28, 2005
Re: Native Windows Support
Carlos Santander wrote:

| Carlos Santander escribió:
|
|> TechnoZeus escribió:
|>
|>>
|>> No, that's actually not correct, although the way the API
|>> documentation is written I can understand how it may lead people
|>> to such a conclusion.
|>>
|>> Over the years, many languages have been involved in the writing
|>> of Windows, and I'm not sure what it's primarily written in now,
|>> but I would guess C# is probably being used for most of the new
|>> stuff.  (Anyone from Microsoft care to jump in here?)
|>>
|>
|> C# compiles to MSIL. Windows runs Win32 applications. MSIL
|> applications are not Win32 applications. So C# is as native as
|> Java, for example. I'm sorry, but I disagree with you here.
|>
|
| Small correction: Java doesn't use native controls but MSIL does.
| Still, they both run on a virtual machine, and that makes them not
| native.

That is a strict definition of "native".

Lax definition form a user's point of view:
The UI element is native, if all accessibility tools, input methods,
dictionary-lookup tools etc. are working properly.

Thomas
May 29, 2005
Re: Harmonia way. sort of resume
Andrew,
I just checked out Harmonia today and so far it looks very interesting.  I'm
intrigued by the idea of using HTML for the make-work GUI building that seems to
plague other API's.   I have some questions, but I was unable to find your
proper email address any place.  If you want to reply offline that's okay by me,
but I figured that folks here might have similar questions.

I spent over an hour pouring over the code and I was stumped as how to bind data
to a control declared in HTML.  Ideally, I would expect to be able to ask the
Doc or HtmlView what Widget named 'x' was and then ask the returned Widget what
it's 'value' property was.  

Also, I sort of get what the event plumbing is trying to do, but I'm not sure
how to get any useful information from events.  How does one translate an event
to a Widget?  Where should I add my custom event handlers to the application
(extend Application, or View, or something else?)

- EricAnderton at yahoo
May 29, 2005
Re: Native Windows Support
"Brad Beveridge" <brad@somewhere.net> wrote in message 
news:d77ots$20ms$1@digitaldaemon.com...
> I would suggest that either wxWindows or Gtk+ would make good backends for 
> a D UI wrapper.
>

Speaking of wxWidgets (wxWindows), as soon as I discovered D, I thought how 
great it would be to use D together with wxWidgets. Unfortunately, wxWidgets 
is written in C++.

I was wondering if it would be possible to build a translator to port the 
C++ code to D. I don't even think you would have to port it to "D style". 
Instead use non-GC memory allocation, C-style declaration where possible, 
etc. But I guess that is not practical based on was was said in the thread 
titled "inner classes".  :-(

Jim
May 29, 2005
wxWidgets (was Re: Native Windows Support)
In article <d7bc31$1pj7$1@digitaldaemon.com>, Jim H says...
>
>"Brad Beveridge" <brad@somewhere.net> wrote in message 
>news:d77ots$20ms$1@digitaldaemon.com...
>> I would suggest that either wxWindows or Gtk+ would make good backends for 
>> a D UI wrapper.
>>
>
>Speaking of wxWidgets (wxWindows), as soon as I discovered D, I thought how 
>great it would be to use D together with wxWidgets. Unfortunately, wxWidgets 
>is written in C++.

I don't know how they did it, but there's a project called wxD that attempts to
bridge wxWidgets and D: http://wxd.sourceforge.net/

This might also be interesting to you:
http://www.prowiki.org/wiki4d/wiki.cgi?wxD

jcc7
May 29, 2005
Re: Harmonia way. sort of resume
"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message 
news:d7alnm$1ain$1@digitaldaemon.com...
>I thought you weren't willing to five harmonia up to being in the standard 
>D
> library?
>
> Weren't we trying to come up with soemthing for that?

D as a platform should support/have following:

* Harmonia (as a type) - universal toolkit for
those cases when you need what is described in my
statement in previous message.
* WinGUI - Windows GUI toolkit using
native widgets.
* MacGUI - Mac GUI toolkit using
native widgets.
* LinuxGUI - (GTK?) toolkit.

Idealy all of them should share basic
primitives e.g. something similar to
harmonia.gx.* package and
use similar vocabularies: Application, Window,
Widget. In this case developers can share
most of the code of custom widgets.

Platform specific packages must be designed
to be as close as possible to existing
technologies of UI design on target platform
to reduce learning curves, be able to produce as
compact as possible applications, etc.
For example on Windows (WinGUI)
should be made as a thin layer similar
to WTL. And no global and universal
abstractions please - just pure wrappers around
existing HWND set. On Linux - it just follows
GTK as close as possible, etc.

>
> However, harmonia sounds awesome and I am really enthousaiastic about it's
> development, as it will provide D programers with a solid option.

Yes it is. And we are doing couple of projects
were Harmonia approach is exactly what we need thus
highly probable that we will not sing the song
"Sic transit gloria mundi..." in the nearest future.

>
> I don't know, maybe D should NEVER have a GUI toolkit that is more 
> assocated
> with the core language than any other. Maybe doing so would be 
> disasterous, just
> as Glut became a dinosour as soon as OpenGL leveled off. Now with OpenGL
> flourishing again Glut seems like a bad joke.

I agree, language is language - not more not less.
But something named as D platform should have some
foundation. For GUI part see my four IMHOs above.

>
> And yes, I have used Glut before, thats how I know. As well as Native 
> Win32,
> SDL, FLTK, GLFW, and Cpw. None of which satisfy me, so I am writing me 
> own.
>

I am familiar with pretty much all from the list:
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html
(know architecture, etc.)

> If you want  something done right you have to do it youself.. Usually.

Usually you just have no time for that. Sigh.

Andrew.
May 29, 2005
Re: Harmonia way. sort of resume
"pragma" <pragma_member@pathlink.com> wrote in message 
news:d7b4im$1k5m$1@digitaldaemon.com...
> Andrew,
> I just checked out Harmonia today and so far it looks very interesting. 
> I'm
> intrigued by the idea of using HTML for the make-work GUI building that 
> seems to
> plague other API's.   I have some questions, but I was unable to find your
> proper email address any place.  If you want to reply offline that's okay 
> by me,
> but I figured that folks here might have similar questions.

Eric, news@terrainformatica.com is valid email address. You may write there.
For the reasons we all know too well I am not publishing other addresses.

> I spent over an hour pouring over the code and I was stumped as how to 
> bind data
> to a control declared in HTML.  Ideally, I would expect to be able to ask 
> the
> Doc or HtmlView what Widget named 'x' was and then ask the returned Widget 
> what
> it's 'value' property was.

Thanks for the question. I am dup'ing it in Q&A in Harmonia Wiki.

Idea is simple: HtmlPanel is a template taking one parameter:
HtmlPanel(W)
where W is any type derived from Widgets - container of ... Widgets.
Thus in Harmonia HTML is not an external entity. Being applied
to the container it behaves as its layout manager capable
to layout referred widgets (<input>) and render HTML.

Consider it as drawable layout manager.

Example:
HtmlPanel!(Widgets)  myhtmlpanel = new HtmlPanel!(Widgets);

When you will load in it some html having <input>'s like:

myhtmlpanel.html = "<html><input type=mytype /></html>";

then while parsing it will call method:

Widget   HtmlPanel(W).createWidget(char[] widgetType)

where widgetType in this case will be string "mytype".

Default implementation (createWidget per se) create
widgets of known HTML types
('text', 'radio', 'checkbox') and does

 this ~= w; // ~= defined in Widgets class

adding newly created widget to the container.
Thus all HTML widgets will be just children of
your container and to retrieve all of them use:

foreach( Widget w; myhtmlpanel. forward ) // ascending Z order
or
foreach( Widget w; myhtmlpanel. backward ) // descending Z order
or
Widget w = myhtmlpanel[n];

There is also helper method - Widgets.values:

NamedBoxes values(Widgets container)

It allows you to gather all control values from any
container in one shot. NamedBoxes is declared
as
alias box[wchar[]] NamedBoxes; // module harmonia.ui.widgets;

This is useful if your form's html is coming e.g. from DB and
you would like to store values in DB also. Just declare
in html <input>'s with proper names and types.
I've found that DataBinding is almost unusable.
In most cases pair of 'values' getter/setter is just enough.

>
> Also, I sort of get what the event plumbing is trying to do, but I'm not 
> sure
> how to get any useful information from events.  How does one translate an 
> event
> to a Widget?  Where should I add my custom event handlers to the 
> application
> (extend Application, or View, or something else?)

What do you mean by 'translate an event' - to send an event?
If you mean just some command (EventCommand) then use:

Window.sendCommand(Command cmd, Widget target, bool doIt = true /* 
otherwise - poll */)

It will send (traverse the event) using sinking/bubbling mechanism:
http://catcode.com/domcontent/events/capture.html

First EventCommand will arrive to the window with SINKING flag set then
it will walk through chain parent-child until it will reach the target.
Then without SINKING flag it will 'bubble' from the target up to the window
and Application.
Any widget in the chain can stop event propagation by
returning 'true' from its
bool Widget.on(EventCommand) { ... }
So at any time Application and any container of your widget know
that event is routing to your widget. Any container in the parent/child 
chain
can handle non-processed events.
Thus if you need to create a compound control consisting of
multiple exisiting widgets/components you will be able to handle
*any* event routed to its children without any modifications of
existing components. Cool, eh? :)

Andrew.
May 29, 2005
Re: Native Windows Support
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message 
news:d79cpe$dil$1@digitaldaemon.com...
> "Trevor Parscal" <Trevor_member@pathlink.com> wrote in message 
> news:d77ute$24uf$1@digitaldaemon.com...
>>
>> >As it stands now, I know of no way to write even the simplest Windows 
>> >program without
>> >having to fall back on the use of some other "language" to do it. 
>> >That's not to say that it cant't be done...
>> >just that I don't know of a way.
>> >
>>
>> Windows was written in C, so anything you do with native windows is going 
>> to
>> have to interface with C code. Correct me if I am wrong...
>>
>> >I have been trying for some time now to write a simple file utinity for 
>> >GenePool4 entirely in the D language,
>> >but I can't even figure out how to do something simple like open a file 
>> >dialog to get a filename.
>> >
>>
>> Native controls like that require the use of the native C headers, like
>> windows.h and winuser.h. Luckily we have people who made windows bindings 
>> in D.
>>
>> Check out Core32 on dsource.org
>>
>> Thanks,
>> Trevor Parscal
>> www.trevorparscal.com
>> trevorparscal@hotmail.com
>
> No, that's actually not correct, although the way the API documentation is 
> written I can
> understand how it may lead people to such a conclusion.
>
> Over the years, many languages have been involved in the writing of 
> Windows,
> and I'm not sure what it's primarily written in now, but I would guess C# 
> is probably being
> used for most of the new stuff.  (Anyone from Microsoft care to jump in 
> here?)

Surely it doesn't matter what language Windows is written in, only what 
language the public API is. And that's C. Even those parts of Windows not 
written in C (COM/ActiveX, GDI+) have a C API.

Microsoft's Raymond Chen blogs frequently about the internals of Windows 
http://blogs.msdn.com/oldnewthing/

C# is only relevant when programming for the Common Language Runtime (CLR). 
None of the Win32 API accesses CLR bits. Microsoft's forthcoming Avalon and 
Indigo are only relevant in a CLR environment. Perhaps this is what you 
meant by "the new stuff". The next version of Windows, for example, will not 
be primarily written in C# (or any other CLR-targeting language).

>
> The question here is mainly one of whether D is to be considered a
> fully functional programming language in it's own right,
> or merely a tool to augment programming in the C language.

Any language that needs to access operating system functionality has to 
interface with a public API. For Windows, that's generally C, as I've said 
above. It makes no difference if that language is C++, D, Delphi, Visual 
Basic or Eiffel. You're going to need to call down to C.

> Of course, the answer may be a matter of opinion, and largely subject to
> the observer's platform of choice. I personally would like to see it 
> succede
> as a full featured programming language on all targeted platforms,
> and then some.
>
> TZ
>
>
May 29, 2005
Re: wxWidgets (was Re: Native Windows Support)
"J C Calvarese" <technocrat7@gmail.com> wrote in message 
news:d7bcuq$1q63$1@digitaldaemon.com...
> In article <d7bc31$1pj7$1@digitaldaemon.com>, Jim H says...
>
> I don't know how they did it, but there's a project called wxD that 
> attempts to
> bridge wxWidgets and D: http://wxd.sourceforge.net/
>
> This might also be interesting to you:
> http://www.prowiki.org/wiki4d/wiki.cgi?wxD
>
> jcc7

I had seen that. But I'm not sure the status or whether it will be actively 
maintained. I assume it's not a full, manual port of the library since it 
says it is "wxWidgets bindings for D language". I'm not sure exactly what 
that involves.



I wonder if it makes sense to talk about a common way to link different 
languages. Of course this was the point of COM on Windows, and it works. But 
it's pretty complicated. You need to read a book in order to really 
understand how to make a COM component. Then there is .NET which is a 
simpler way for different languages to link. But now you need to compile to 
bytecode and run on a virtual machine. Performance suffers. So is there any 
way it makes sense to have a way for different languages to link together, 
which is as simple to use as .NET, but also allows the speed of native 
compilation and no VM? Or does this not make sense?



Jim
May 30, 2005
Re: Native Windows Support
"Carlos Santander" <csantander619@gmail.com> wrote in message news:d79t3k$pbv$1@digitaldaemon.com...
> TechnoZeus escribió:
> >
> > Exactly my point.  Windows has it's problems, and is quite expensive (especially
> > when compared with any free operating system) but it is popular for more reasons than
> > just the fact that it's backed by a big company.  Native support for Windows would be a
> > good step in the right direction in my opinion, especially if a lowest common denominator
> > implementation key Windows style functionality were to be built in as a cross-platform default,
> > and then over-ridden over time in each case where a better solution is found (or made) to be
> > available.  This way, rather than leaving out a functionality becuase it's not fully supported on some
> > platform, the functionality would be made available on that platform even if only in a crude form,
> > helping to shape the future in a positive way.
> >
> > Consider the fact that every version of Microsoft Windows older than Windows 95 was entirely
> > a DOS application, running in an environment that had no native GUI support.  Consider also that
> > almost 100% of the early Windows programs (and most well written modern ones) could be run
> > without a mouse, because functionality such as the menu system was designed to work in several
> > different ways, and acomodate the user's prefered way of doing things.  This concept still works,
> > but has unfortunately not been kept up so much in recent years... but there's no reason D shouldn't
> > be able to have such a concept built in, at least to a reasonable extent.
> >
> > Perhaps in addition to built in assembly language support, there should be built in XML or HTML support,
> > or something similar that would allow a GUI to be built as a native part of the D source code...
> > but there I'm just speculating.  Regardless of how it's done, I do feel that any level of native GUI support, and
> > in turn native Windows support based on that native GUI support, would be a huge plus for
> > the future of the D programming language.
> >
> > In short, I would like to write Windows programs "the D way" in D, rather than "the C way" with D parts.
> >
> > TZ
> >
> >
> > TZ
> >
> >
>
> I really don't understand what you're saying. Can you write native
> looking Windows applications in C? Yes. Can you do it in D? Yes. How?
> The same way you do it in C: use a file with the Win32 headers (Core32
> in dsource, for example) so you can do "CreateWindow(...)" et al, link
> with the appropiate libraries (you could need gdi32.lib and/or others)
> and run it. They have Win2000 look. If you want WinXP theming, you have
> to use a special resource file, just like you would in C. What's not
> native there?
>
> For other platforms, the process is similar, except that IMHO there's no
> native look on linux because you can have X, GTK+, KDE, etc. Native on
> Mac seems to be the same as in Windows, but my experience with it is not
> that much yet. But you get "native" X, or "native" GTK+, etc.
>
> Again, I don't understand what you're saying. I maybe missing something.
>
> -- 
> Carlos Santander Bernal

No, that's not what I mean at all.

C has no native support for Windows, and for that matter to my knowledge
no native support for development of GUI based applications.

Having to use an external header file or library is a good sign that the support is not native to the language,
but rather something that was added as an after-thought...
probably by someone other than the language's developer.
...and as such, is generally neither universally available to everyone using the language
nor included in the language's specification or documentation.

TZ
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home