In article <cpa9in$1c4a$1@digitaldaemon.com>, Ben Hinkle says...
>
>- be as small and simple as possible while still being useful

I assume (and hope) that "small and simple" is along the lines of

# /* c-examples/componentlistener.c */
##include <stdio.h>
##include "japi.h"
#
#int main()
#    int frame,obj;
#    int button1,button2,button3;
#    int focuslst;
#
#    if(!j_start())
#
#    /* Generate Graphical Objects */
#    j_setflowlayout(frame,J_HORIZONTAL);
#
#    button1=j_button(frame,"Button 1");
#    button2=j_button(frame,"Button 2");
#    button3=j_button(frame,"Button 3");
#
#    focuslst=j_focuslistener(button3);
#
#    j_pack(frame);
#    j_show(frame);
#    while((obj=j_nextaction())!=frame)
#    {
#        if(obj == focuslst)
#            if(j_hasfocus(focuslst))
#    }
#
#    j_quit();
#    exit(0);
#}

as found on http://www.uni-koblenz.de/~evol/japi/examples/examples.html

(Here I'm not endorsing japi, just the simplicity of UI-lib usage in general we should strive to.)

----

BTW, I happened to stumble upon a quote of James Gosling, where he talks about Swing:

"Swing ... is the most fully featured, flexible,
whatever-way-you-want-to-measure-it UI tool kit
on the planet. You can do the most amazing things
with Swing. It's sort of the 747 cockpit of UI design
tool kits, and flying a 747 is a little intimidating,
and what people really want is a Cessna."

(From a presentation by Ben Galbraith, at
http://www.javalobby.org/eps/galbraith-swing-1
which also strengthened my belief in Nice Little Guis.)

Georg Wrede wrote:

> BTW, I happened to stumble upon a quote of James Gosling,
> where he talks about Swing: 
> 
> "Swing ... is the most fully featured, flexible,
> whatever-way-you-want-to-measure-it UI tool kit on the planet. You can do the most amazing things with Swing. It's sort of the 747 cockpit of UI design tool kits, and flying a 747 is a little intimidating, and what people really want is a Cessna."

And that 747 also happens to be built out of the LEGO
that is Java bytecode, so it's slow and weird as well...

AWT didn't have the best of functionality and APIs, but
at least it was native? Swing improved one, not the other.

Now there is SWT (Standard Widget Toolkit) from Eclipse,
along with this neat API: http://swingwt.sourceforge.net/

Indeed the best of both worlds! (for Java, D is different
since it is not running managed code - and more low-level)

I do think "native" D GUI should be preferred over e.g. Tk ?
(wxWidgets isn't too bad: http://www.wxwidgets.org/hello.htm)

--anders

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:cpk61k$1ndp$1@digitaldaemon.com...
> In article <cpa9in$1c4a$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >- be as small and simple as possible while still being useful
>
> I assume (and hope) that "small and simple" is along the lines of
>
[snip]
>
> as found on http://www.uni-koblenz.de/~evol/japi/examples/examples.html
>
> (Here I'm not endorsing japi, just the simplicity of UI-lib
> usage in general we should strive to.)
[snip]

I hadn't heard of japi before - the examples look interesting. It might be a little too simple for what I have in mind. SWT is closer than I thought to what I have in mind. Or perhaps a simplified wxWindows. Tk is a little too simple. Anyhow, I think I'll give MinWin a shot and see how it unfolds. What I have from the weekend is working Windows and Motif versions (well, most of the Motif version - it ignores the font stuff) of a small app that shows a frame and draws a string into it. There are several ways of actually coding such a thing but I've pasted below a short-n-sweet version:

import minwin.all;
extern (C)
int MinWinMain(Application app) {
  Frame frame = new Frame("Sample");
  frame.paintDelegate ~= void delegate(Component source, PaintContext* pc) {
    FontData fd;
    fd.size = 80;
    fd.weight = FontWeight.Bold;
    Font f = new Font(&fd); // could cache the font, too
    Font oldFont = pc.setFont(f);
    pc.moveTo(100,100);
    pc.drawText("Hello world");
    pc.setFont(oldFont); // shouldn't forget or we'll delete a font in use
    delete f; // if we forget it will eventually be garbage collected
  }
  frame.visible = true;
  app.enterEventLoop();
  return 1;
}

"Ben Hinkle" <bhinkle@mathworks.com> escribió en el mensaje
news:cpkhdv$24q6$1@digitaldaemon.com...
| I hadn't heard of japi before - the examples look interesting. It might be a
| little too simple for what I have in mind. SWT is closer than I thought to
| what I have in mind. Or perhaps a simplified wxWindows. Tk is a little too
| simple. Anyhow, I think I'll give MinWin a shot and see how it unfolds. What
| I have from the weekend is working Windows and Motif versions (well, most of
| the Motif version - it ignores the font stuff) of a small app that shows a
| frame and draws a string into it. There are several ways of actually coding
| such a thing but I've pasted below a short-n-sweet version:
|
| import minwin.all;
| extern (C)
| int MinWinMain(Application app) {
|  Frame frame = new Frame("Sample");
|  frame.paintDelegate ~= void delegate(Component source, PaintContext* pc) {
|    FontData fd;
|    fd.size = 80;
|    fd.weight = FontWeight.Bold;
|    Font f = new Font(&fd); // could cache the font, too
|    Font oldFont = pc.setFont(f);
|    pc.moveTo(100,100);
|    pc.drawText("Hello world");
|    pc.setFont(oldFont); // shouldn't forget or we'll delete a font in use
|    delete f; // if we forget it will eventually be garbage collected
|  }
|  frame.visible = true;
|  app.enterEventLoop();
|  return 1;
| }
|

Since I've seen this a couple of times before, I feel like I should ask. It's
pure curiousity, so don't take it the bad way.
Why do you let "app" decide which Frame to show? What if I define more than one
frame before entering the event loop? How will "app" know which one I want to be
shown before or be the main frame?
Basically, what I'm saying is that, IMHO, somewhere before the loop you should
say something like "app.mainFrame = frame;".
Precise reasons, I don't have. It just feels better for me.

-----------------------
Carlos Santander Bernal

"Carlos Santander B." <csantander619@gmail.com> wrote in message news:cplfsh$5mu$2@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> escribió en el mensaje
> news:cpkhdv$24q6$1@digitaldaemon.com...
> | I hadn't heard of japi before - the examples look interesting. It might
> be a
> | little too simple for what I have in mind. SWT is closer than I thought
> to
> | what I have in mind. Or perhaps a simplified wxWindows. Tk is a little
> too
> | simple. Anyhow, I think I'll give MinWin a shot and see how it unfolds.
> What
> | I have from the weekend is working Windows and Motif versions (well,
> most of
> | the Motif version - it ignores the font stuff) of a small app that shows
> a
> | frame and draws a string into it. There are several ways of actually
> coding
> | such a thing but I've pasted below a short-n-sweet version:
> |
> | import minwin.all;
> | extern (C)
> | int MinWinMain(Application app) {
> |  Frame frame = new Frame("Sample");
> |  frame.paintDelegate ~= void delegate(Component source, PaintContext*
> pc) {
> |    FontData fd;
> |    fd.size = 80;
> |    fd.weight = FontWeight.Bold;
> |    Font f = new Font(&fd); // could cache the font, too
> |    Font oldFont = pc.setFont(f);
> |    pc.moveTo(100,100);
> |    pc.drawText("Hello world");
> |    pc.setFont(oldFont); // shouldn't forget or we'll delete a font in
> use
> |    delete f; // if we forget it will eventually be garbage collected
> |  }
> |  frame.visible = true;
> |  app.enterEventLoop();
> |  return 1;
> | }
> |
>
> Since I've seen this a couple of times before, I feel like I should ask.
> It's
> pure curiousity, so don't take it the bad way.
> Why do you let "app" decide which Frame to show? What if I define more
> than one
> frame before entering the event loop? How will "app" know which one I want
> to be
> shown before or be the main frame?
> Basically, what I'm saying is that, IMHO, somewhere before the loop you
> should
> say something like "app.mainFrame = frame;".
> Precise reasons, I don't have. It just feels better for me.

I am thinking about introducing a concept of main frame - right now it doesn't have one and maybe it should. The current answer to your question is that you can make any number of windows and make any number visible before you enter the event loop and presumably they will be shown on screen in the order they were made visible. One thing I added since posting that example is a frame property called quitOnClose which is false by default but when turned on quits the application (sends a quit message) when the frame closes. So this could be how the "main frame" is chosen - just turn on the quitOnClose property.

> -----------------------
> Carlos Santander Bernal
>
> 

In article <cplkit$a7r$1@digitaldaemon.com>, Ben Hinkle says...
>I am thinking about introducing a concept of main frame - right now it doesn't have one and maybe it should.

One method I've seen is to make the Application class == Main Frame class.

-- Chris Sauls

"Ben Hinkle" <ben.hinkle@gmail.com> escribió en el mensaje
news:cplkit$a7r$1@digitaldaemon.com...
| I am thinking about introducing a concept of main frame - right now it
| doesn't have one and maybe it should. The current answer to your question is
| that you can make any number of windows and make any number visible before
| you enter the event loop and presumably they will be shown on screen in the
| order they were made visible. One thing I added since posting that example
| is a frame property called quitOnClose which is false by default but when
| turned on quits the application (sends a quit message) when the frame
| closes. So this could be how the "main frame" is chosen - just turn on the
| quitOnClose property.
|

Thanks. I hadn't realized it wasn't the final design.

-----------------------
Carlos Santander Bernal

"Carlos Santander B." <csantander619@gmail.com> wrote in message news:cplq07$fne$1@digitaldaemon.com...
> "Ben Hinkle" <ben.hinkle@gmail.com> escribió en el mensaje
> news:cplkit$a7r$1@digitaldaemon.com...
> | I am thinking about introducing a concept of main frame - right now it
> | doesn't have one and maybe it should. The current answer to your
question is
> | that you can make any number of windows and make any number visible
before
> | you enter the event loop and presumably they will be shown on screen in
the
> | order they were made visible. One thing I added since posting that
example
> | is a frame property called quitOnClose which is false by default but
when
> | turned on quits the application (sends a quit message) when the frame | closes. So this could be how the "main frame" is chosen - just turn on
the
> | quitOnClose property.
> |
>
> Thanks. I hadn't realized it wasn't the final design.
>
> -----------------------
> Carlos Santander Bernal
>

No problem. This thing is a weekend old so things are very much in flux. The issue with main windows is that it feels like a pretty strong assumption that the app and OS use the notion of a main window. Here's how the sample looks after introducing the quitOnClose and the proper Windows convention for the first time ShowWindow is called. It also shows what I mean when I say I want MinWin to allow easy access to peers.

import minwin.all;
version (Windows) {
  import minwin.mswindows;
}
extern (C)
int MinWinMain(Application app) {
  Frame frame = new Frame("Sample");
  frame.quitOnClose = true;
  frame.paintDelegate ~= delegate void (Component source, PaintContext* pc)
{
    FontData fd;
    fd.size = 80;
    fd.weight = FontWeight.Bold;
    Font f = new Font(&fd);
    Font oldFont = pc.setFont(f);
    pc.moveTo(100,100);
    pc.drawText("Hello world");
    pc.setFont(oldFont); // shouldn't forget or we'll delete a font in use
    delete f; // if we forget it will eventually be garbage collected
  }
  version(Windows) {
    // Windows wants the first window being shown to be
    // passed the nCmdShow parameter.
    // The nCmdShow property of Application is only defined on Windows
    ShowWindow(frame.peer, app.nCmdShow);
  } else {
    frame.visible = true;
  }
  return app.enterEventLoop();
}

In article <cpn2p7$26f7$1@digitaldaemon.com>, Ben Hinkle says...
>
>

Ben, I wouldn't mind discussion some ideas on this,
the main window thing for example, but I don't feel confortable doing it here
(too specific for this group). Do you have another forum for this?
dsource comes to mind.

BTW I thought dsource would host any D project but they say "Open Source Development for D"...

Ant

"Ant" <Ant_member@pathlink.com> wrote in message news:cpn4b2$28l6$1@digitaldaemon.com...
> In article <cpn2p7$26f7$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >
>
> Ben, I wouldn't mind discussion some ideas on this,
> the main window thing for example, but I don't feel confortable doing it
here
> (too specific for this group). Do you have another forum for this?
> dsource comes to mind.
>
> BTW I thought dsource would host any D project but they say "Open Source Development for D"...
>
> Ant
>
>

good idea. I've posted a request to open a MinWin forum on dsource. Hosting the project there will probably come once I get more organized.