www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new project MinWin

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
MinTL. The goals are:
- be as small and simple as possible while still being useful
- support cross-platform development where the peers exist and have similar
behavior
- seemlessly integrate with peers and platform-specific code
- minimize the dependencies on other large libraries to avoid complex
install and license issues
- make it public domain (or make the core parts public domain)

So for example layout management isn't typically part of the peer system but
it is very useful so MinWin should have some layout support. Similarly every
windowing system has dialogs and menus and buttons etc so those will be
MinWin, too. Support for trees and tables won't be built-in. I see it being
something like AWT-lite with better native access. The problem with large
cross-platform toolkits is that they never are really cross-platform and
they never really look like native apps. Cross-platform development is very
hard so the MinWin approach will be to only do it where it works and give
easy access to the platform for everything else.

Thoughts? Comments?

-Ben
Dec 09 2004
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 9 Dec 2004 14:37:58 -0500, Ben Hinkle <bhinkle mathworks.com>  
wrote:


 This might be crazy, but I've been mulling over a new project called
 MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
 MinTL. The goals are:
 - be as small and simple as possible while still being useful
 - support cross-platform development where the peers exist and have  
 similar
 behavior
 - seemlessly integrate with peers and platform-specific code
 - minimize the dependencies on other large libraries to avoid complex
 install and license issues
 - make it public domain (or make the core parts public domain)

 So for example layout management isn't typically part of the peer system  
 but
 it is very useful so MinWin should have some layout support. Similarly  
 every
 windowing system has dialogs and menus and buttons etc so those will be
 MinWin, too. Support for trees and tables won't be built-in. I see it  
 being
 something like AWT-lite with better native access. The problem with large
 cross-platform toolkits is that they never are really cross-platform and
 they never really look like native apps. Cross-platform development is  
 very
 hard so the MinWin approach will be to only do it where it works and give
 easy access to the platform for everything else.

 Thoughts? Comments?


Tree's and Tables are awfully useful, what would I have to do if I used  
MinWin and wanted a table, write it myself?  Or.. do you imagine tables  
will eventually be written and added either to all peers or MinWin?

Regan
Dec 09 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Tree's and Tables are awfully useful, what would I have to do if I used
 MinWin and wanted a table, write it myself?  Or.. do you imagine tables
 will eventually be written and added either to all peers or MinWin?


Some options I've been contemplating in order of preference:
1) find peer controls/widgets that share enough basic functionality to make
a MinWin interface reasonable
2) ignore trees/tables completely and make users interface whatever peer
they choose (hence the goal of making it easy to use peers in MinWin)
3) write tree/table widgets completely in MinWin (ugh...) or write
compatible peers (ugh...)

I haven't looked at enough of the controls and widgets out there to decide.
For now I was going to punt.
Dec 09 2004
parent Georg Wrede <Georg_member pathlink.com> writes:
MinWin is an excellent idea!!!!!

A KISS style framework would serve several purposes: 

- quickly hack up solutions for transient office needs
- fast idea prototyping
- easy to teach (or learn) GUI fundamentals
- "more productive to know all about the Volkswagen than 
a tiny part of the 747" = spend more time actually programming 
than reading and searching docs and manuals and howtos!
- would (and could) be exactly the same for all platforms
- become (and stay!) part of the D core library

Being small enough this would not be perceived as a threat to
the Hummers and Mercedeces of the GUI framework scene.

In article <cpagm1$1o8e$1 digitaldaemon.com>, Ben Hinkle says...

 Tree's and Tables are awfully useful, what would I have to do if I used
 MinWin and wanted a table, write it myself?  Or.. do you imagine tables
 will eventually be written and added either to all peers or MinWin?


Some options I've been contemplating in order of preference:
1) find peer controls/widgets that share enough basic functionality to make
a MinWin interface reasonable
2) ignore trees/tables completely and make users interface whatever peer
they choose (hence the goal of making it easy to use peers in MinWin)
3) write tree/table widgets completely in MinWin (ugh...) or write
compatible peers (ugh...)

I haven't looked at enough of the controls and widgets out there to decide.
For now I was going to punt.


Booleans (check boxes, radio buttons), text, lists, and menus are
all a must. And so are graphs (trees) and matrices (tables).

In practice we also need tabbed areas, a drawing canvas, and ability
to show pictures.

"Usable in only 80% of cases, but the programming effort in those
cases should be only 20% of that needed with a Fancy GUI Framework."
Dec 10 2004
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <cpa9in$1c4a$1 digitaldaemon.com>, Ben Hinkle says...

This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
MinTL. The goals are:
- be as small and simple as possible while still being useful
- support cross-platform development where the peers exist and have similar
behavior
- seemlessly integrate with peers and platform-specific code
- minimize the dependencies on other large libraries to avoid complex
install and license issues
- make it public domain (or make the core parts public domain)

So for example layout management isn't typically part of the peer system but
it is very useful so MinWin should have some layout support. Similarly every
windowing system has dialogs and menus and buttons etc so those will be
MinWin, too. Support for trees and tables won't be built-in. I see it being
something like AWT-lite with better native access. The problem with large
cross-platform toolkits is that they never are really cross-platform and
they never really look like native apps. Cross-platform development is very
hard so the MinWin approach will be to only do it where it works and give
easy access to the platform for everything else.

Thoughts? Comments?

-Ben


Ben,

I think this is an /excellent/ idea!! To me, this idea flows well with the 'D'
way of doing things so as to avoid earlier Java UI mis-steps (e.g.: don't force
some LCD on everything to try and make it conform to some x-platform ideal).

The only thing I could add to keep in mind during the design stage is to try and
architect the library with future RAD GUI IDE's in mind (e.g.: run-time & "post
form creation" component manipulation, easy parsing and query of form and
control properties, a form class/code file ratio of 1:1 with a minimal amount of
imports, etc.).

- Dave
Dec 09 2004
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 The only thing I could add to keep in mind during the design stage is to 
 try and
 architect the library with future RAD GUI IDE's in mind (e.g.: run-time & 
 "post
 form creation" component manipulation, easy parsing and query of form and
 control properties, a form class/code file ratio of 1:1 with a minimal 
 amount of
 imports, etc.).


What do you mean by post form creation component manipulation? Personally I 
don't use a RAD IDE so I'm a bit behind the times on the latest features of 
these things. Whenever I used one with Swing, though, it tended to frustrate 
me since I would pretty quickly end up back in emacs editing the code by 
hand.
Dec 10 2004
parent Dave <Dave_member pathlink.com> writes:
In article <cpc6ov$178o$1 digitaldaemon.com>, Ben Hinkle says...

 The only thing I could add to keep in mind during the design stage is to 
 try and
 architect the library with future RAD GUI IDE's in mind (e.g.: run-time & 
 "post
 form creation" component manipulation, easy parsing and query of form and
 control properties, a form class/code file ratio of 1:1 with a minimal 
 amount of
 imports, etc.).


What do you mean by post form creation component manipulation? Personally I 
don't use a RAD IDE so I'm a bit behind the times on the latest features of 
these things. Whenever I used one with Swing, though, it tended to frustrate 
me since I would pretty quickly end up back in emacs editing the code by 
hand. 


I should have written that better..

The components would ideally be designed so that it is easy/straight-forward to
change, apply and retrieve properties after the form and its controls have been
created. This would be nice not only for run-time functionality but also for
WYSIWYG type IDE's.

For example, the framework would ideally make it easy to move/resize a button
object contained by a window object after they have both been instantiated and
also for a parent application (like an IDE) to get and set a list of the button
properties at runtime.

IIRC, VS.Net for example uses WinForms for both runtime and design-time
representation of a form in the IDE. Prior to that the VB IDE basically drew a
picture of a form and then had to place (and keep in sync) a transparent
container over the design-time form to handle the drag'n'drop, etc. because the
runtime objects were not designed to be easily manipulated on the fly and/or
queried at runtime by an IDE.

For the "1:1 form class to file ratio" what I meant is that the developer could
represent one form with one class and that all the code for the components of
the form could be written as objects, methods and property members of the form
class. Then the form class could be contained in one file which would make it
easier for an IDE to represent a WYSIWYG form.

For RAD rationale - one of the reasons I think C/++ is not used as much as it
could be by the general programming public is because there aren't any good RAD
tools. In part, those aren't available because the common x-platform UI
libraries are so darn hard to make WYSIWYG IDE's for.

- Dave
Dec 10 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cpa9in$1c4a$1 digitaldaemon.com>, Ben Hinkle says...

This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit"


I don't get it.
What's the use of a minimal toolkit?
Nobody will make the effort to get use to it if they will need to learn
another full feature toolkit.

Why don't you start a good toolkit and say the the first phase
will not include those features?

don't call it Min, call it Max.

Ant
Dec 09 2004
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message 
news:cpaimr$1rke$1 digitaldaemon.com...

 In article <cpa9in$1c4a$1 digitaldaemon.com>, Ben Hinkle says...

This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit"


 I don't get it.
 What's the use of a minimal toolkit?
 Nobody will make the effort to get use to it if they will need to learn
 another full feature toolkit.

 Why don't you start a good toolkit and say the the first phase
 will not include those features?

 don't call it Min, call it Max.

 Ant


There are several full featured toolkits out there (eg Qt, GTK+, Swing) that 
work just fine for what they are designed to do. I think, though, that they 
all use lightweight widgets to get cross-platform behavior. I'd like to use 
native widgets, like AWT and wxWidgets, in order to get better "native look 
and feel". I think SWT was an attempt to give Java a native widget toolkit, 
too, but I haven't really looked into SWT all that much, to be honest. The 
main problem with toolkit designs is where to draw the line between 
cross-platform behavior and native behavior. On the one hand application 
developers want to write one piece of code and have it work everywhere. On 
the other hand users want applications that behave like the other 
application on their machine. It is hard to balance those two goals. I don't 
think the current toolkits have it solved (and maybe it is unsolvable).
Dec 10 2004
parent Roald Ribe <rr.nospam nospam.teikom.no> writes:
Ben Hinkle wrote:

 "Ant" <Ant_member pathlink.com> wrote in message 
 news:cpaimr$1rke$1 digitaldaemon.com...
 

In article <cpa9in$1c4a$1 digitaldaemon.com>, Ben Hinkle says...


This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit"


I don't get it.
What's the use of a minimal toolkit?
Nobody will make the effort to get use to it if they will need to learn
another full feature toolkit.

Why don't you start a good toolkit and say the the first phase
will not include those features?

don't call it Min, call it Max.

Ant


 
 
 There are several full featured toolkits out there (eg Qt, GTK+, Swing) that 
 work just fine for what they are designed to do. I think, though, that they 
 all use lightweight widgets to get cross-platform behavior. I'd like to use 
 native widgets, like AWT and wxWidgets, in order to get better "native look 
 and feel". I think SWT was an attempt to give Java a native widget toolkit, 
 too, but I haven't really looked into SWT all that much, to be honest. The 
 main problem with toolkit designs is where to draw the line between 
 cross-platform behavior and native behavior. On the one hand application 
 developers want to write one piece of code and have it work everywhere. On 
 the other hand users want applications that behave like the other 
 application on their machine. It is hard to balance those two goals. I don't 
 think the current toolkits have it solved (and maybe it is unsolvable). 


I honestly think that SWT is the closest thing to what you describe.
It lets you reuse the hard work of others, and is free. (IMHO)

Roald
Dec 10 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ben Hinkle schrieb:

 This might be crazy, but I've been mulling over a new project called
 MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
 MinTL. The goals are:
 - be as small and simple as possible while still being useful
 - support cross-platform development where the peers exist and have similar
 behavior


\o/


 - seemlessly integrate with peers and platform-specific code
 - minimize the dependencies on other large libraries to avoid complex
 install and license issues


These 2 seem to be somewhat conflicting to me, looking at what modern 
Unix looks like. You run into:

- Using X directly, that is you come up with your own set of widgets, 
which makes your applications compact and fast but aliens on any desktop.

- Using GTK+. Then, your applications are not really aliens to any of 
the desktops, but GTK is quite some beast.

- Using Qt. Then, your applications are real aliens on GTK-based 
desktops, but you get a fine MacOS(-X) support as bonus, if i'm not very 
misinformed - i don't think anyone here is up to writing real MacOS 
support? You need to go through a C wrapper, which i believe is 
availiable. I don't know how it is now, but back when i looked at Qt it 
seemed to be somewhat more lightweight than GTK.


 - make it public domain (or make the core parts public domain)


\o/

(though i recall some discussion that organizations rather trust 
something with zlib-like license than with no license at all... i don't 
have any knowledge nor opinion on that)


 So for example layout management isn't typically part of the peer system but
 it is very useful so MinWin should have some layout support. Similarly every
 windowing system has dialogs and menus and buttons etc so those will be
 MinWin, too. Support for trees and tables won't be built-in. I see it being
 something like AWT-lite with better native access. The problem with large
 cross-platform toolkits is that they never are really cross-platform and
 they never really look like native apps. Cross-platform development is very
 hard so the MinWin approach will be to only do it where it works and give
 easy access to the platform for everything else.


\o/


 Thoughts? Comments?


I recall someone posted the link to a project which maintains a similar 
C library, generating very compact executables, with Win32 and Qt peers.

http://www.leonardo-vm.org/

One problem, is that it is pure LGPL - which means it cannot be linked 
statically into closed-source application, which is a major restriction. 
It may be that the restriction was not intended, and that one could mail 
them and ask for a linkage exception like in wxWidgets and FLTK, which 
would make it an acceptable and easy target. Or in sublicensing the 
relevant parts of the code under a more liberal license.

-eye
Dec 09 2004
next sibling parent =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ilya Minkov wrote:


 These 2 seem to be somewhat conflicting to me, looking at what modern 
 Unix looks like. You run into:
 
 - Using X directly, that is you come up with your own set of widgets, 
 which makes your applications compact and fast but aliens on any desktop.
 
 - Using GTK+. Then, your applications are not really aliens to any of 
 the desktops, but GTK is quite some beast.


GTK+ on Mac OS X 10.3 consists of a half-working version of GTK+ 1.x....

Unless you use X11, which ends up with something looking/feeling alien ?


 - Using Qt. Then, your applications are real aliens on GTK-based 
 desktops, but you get a fine MacOS(-X) support as bonus, if i'm not very 
 misinformed - i don't think anyone here is up to writing real MacOS 
 support? You need to go through a C wrapper, which i believe is 
 availiable. I don't know how it is now, but back when i looked at Qt it 
 seemed to be somewhat more lightweight than GTK.


(since D won't work on Mac OS 9, everything here is about Mac OS X)
QT/Mac comes in two versions, one commercial and one GPL* version.
Which means that you either open up your source code, or you pay up.
A single developer license costs 1340€/year, so it's quite the step...

Think I would either go with the X11/GTK+ stuff, or just use Carbon ?
(as in http://developer.apple.com/referencelibrary/Carbon/index.html)

--anders

PS. Yes, QT/Mac uses the GPL for Open Source edition, not the LGPL.
     See http://www.trolltech.com/developer/faqs/license_gpl.html
Dec 09 2004
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message 
news:cpal99$2029$1 digitaldaemon.com...

 Ben Hinkle schrieb:

 This might be crazy, but I've been mulling over a new project called
 MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
 MinTL. The goals are:
 - be as small and simple as possible while still being useful
 - support cross-platform development where the peers exist and have 
 similar
 behavior


 \o/


 - seemlessly integrate with peers and platform-specific code
 - minimize the dependencies on other large libraries to avoid complex
 install and license issues


 These 2 seem to be somewhat conflicting to me, looking at what modern Unix 
 looks like. You run into:

 - Using X directly, that is you come up with your own set of widgets, 
 which makes your applications compact and fast but aliens on any desktop.


I was first going to target Xt/Motif. It's cheesy old-school but it's easy. 
I agree working with pure Xlib calls would be trouble.


 - Using GTK+. Then, your applications are not really aliens to any of the 
 desktops, but GTK is quite some beast.


GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to look 
closely at it.


 - Using Qt. Then, your applications are real aliens on GTK-based desktops, 
 but you get a fine MacOS(-X) support as bonus, if i'm not very 
 misinformed - i don't think anyone here is up to writing real MacOS 
 support? You need to go through a C wrapper, which i believe is 
 availiable. I don't know how it is now, but back when i looked at Qt it 
 seemed to be somewhat more lightweight than GTK.


The Mac could be a challenge, which is funny because I grew up on a Mac. It 
shouldn't be too hard, though, if the scope of MinWin is limited.

By "avoid other libraries" I mean that it shouldn't pick one. Mostly I want 
to make the Win32 experience as simple as possible and this means relying on 
Windows controls instead of making users install (or bundling) GTK/Qt/...


 - make it public domain (or make the core parts public domain)


 \o/

 (though i recall some discussion that organizations rather trust something 
 with zlib-like license than with no license at all... i don't have any 
 knowledge nor opinion on that)


interesting. I'll google around. Though I suppose technically "no license at 
all" would make me nervous, too. A public domain license is still a license.


 So for example layout management isn't typically part of the peer system 
 but
 it is very useful so MinWin should have some layout support. Similarly 
 every
 windowing system has dialogs and menus and buttons etc so those will be
 MinWin, too. Support for trees and tables won't be built-in. I see it 
 being
 something like AWT-lite with better native access. The problem with large
 cross-platform toolkits is that they never are really cross-platform and
 they never really look like native apps. Cross-platform development is 
 very
 hard so the MinWin approach will be to only do it where it works and give
 easy access to the platform for everything else.


 \o/


 Thoughts? Comments?


 I recall someone posted the link to a project which maintains a similar C 
 library, generating very compact executables, with Win32 and Qt peers.

 http://www.leonardo-vm.org/

 One problem, is that it is pure LGPL - which means it cannot be linked 
 statically into closed-source application, which is a major restriction. 
 It may be that the restriction was not intended, and that one could mail 
 them and ask for a linkage exception like in wxWidgets and FLTK, which 
 would make it an acceptable and easy target. Or in sublicensing the 
 relevant parts of the code under a more liberal license.


Thanks for the link. I'll check into it. I had heard of FLTK but only 
browsed around the web site a bit so I'll look at it a little more carefully 
now. Where did you hear about FLTK? I just ran into it through goolging.


 -eye
Dec 10 2004
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 The Mac could be a challenge, which is funny because I grew up on a Mac.


Unless you are a lot younger than I think, you will find the Mac
of today (Mac OS X) very different from the Mac of old (Mac OS 9) ?

Now it's all based on NeXTSTEP, but with a "Mac" GUI / Carbon API.


 It shouldn't be too hard, though, if the scope of MinWin is limited.


I have hacked together a simple "macosx.carbon" module which handles
the basics... (the most common from MacTypes.h, and various Carbon.h)

Just assorted selections of "alias" and "extern (C)", nothing fancy.

--anders
Dec 10 2004
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
In article <cpc8mr$1acr$1 digitaldaemon.com>, Ben Hinkle says...

"Ilya Minkov" <minkov cs.tum.edu> wrote in message 
news:cpal99$2029$1 digitaldaemon.com...

 Ben Hinkle schrieb:

 This might be crazy, but I've been mulling over a new project called
 MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
 MinTL. The goals are:
 - be as small and simple as possible while still being useful
 - support cross-platform development where the peers exist and have 
 similar
 behavior


 \o/


 - seemlessly integrate with peers and platform-specific code
 - minimize the dependencies on other large libraries to avoid complex
 install and license issues


 These 2 seem to be somewhat conflicting to me, looking at what modern Unix 
 looks like. You run into:

 - Using X directly, that is you come up with your own set of widgets, 
 which makes your applications compact and fast but aliens on any desktop.


I was first going to target Xt/Motif. It's cheesy old-school but it's easy. 
I agree working with pure Xlib calls would be trouble.


 - Using GTK+. Then, your applications are not really aliens to any of the 
 desktops, but GTK is quite some beast.


GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to look 
closely at it.


 - Using Qt. Then, your applications are real aliens on GTK-based desktops, 
 but you get a fine MacOS(-X) support as bonus, if i'm not very 
 misinformed - i don't think anyone here is up to writing real MacOS 
 support? You need to go through a C wrapper, which i believe is 
 availiable. I don't know how it is now, but back when i looked at Qt it 
 seemed to be somewhat more lightweight than GTK.


The Mac could be a challenge, which is funny because I grew up on a Mac. It 
shouldn't be too hard, though, if the scope of MinWin is limited.

By "avoid other libraries" I mean that it shouldn't pick one. Mostly I want 
to make the Win32 experience as simple as possible and this means relying on 
Windows controls instead of making users install (or bundling) GTK/Qt/...


 - make it public domain (or make the core parts public domain)


 \o/

 (though i recall some discussion that organizations rather trust something 
 with zlib-like license than with no license at all... i don't have any 
 knowledge nor opinion on that)


interesting. I'll google around. Though I suppose technically "no license at 
all" would make me nervous, too. A public domain license is still a license.


 So for example layout management isn't typically part of the peer system 
 but
 it is very useful so MinWin should have some layout support. Similarly 
 every
 windowing system has dialogs and menus and buttons etc so those will be
 MinWin, too. Support for trees and tables won't be built-in. I see it 
 being
 something like AWT-lite with better native access. The problem with large
 cross-platform toolkits is that they never are really cross-platform and
 they never really look like native apps. Cross-platform development is 
 very
 hard so the MinWin approach will be to only do it where it works and give
 easy access to the platform for everything else.


 \o/


 Thoughts? Comments?


 I recall someone posted the link to a project which maintains a similar C 
 library, generating very compact executables, with Win32 and Qt peers.

 http://www.leonardo-vm.org/

 One problem, is that it is pure LGPL - which means it cannot be linked 
 statically into closed-source application, which is a major restriction. 
 It may be that the restriction was not intended, and that one could mail 
 them and ask for a linkage exception like in wxWidgets and FLTK, which 
 would make it an acceptable and easy target. Or in sublicensing the 
 relevant parts of the code under a more liberal license.


Thanks for the link. I'll check into it. I had heard of FLTK but only 
browsed around the web site a bit so I'll look at it a little more carefully 
now. Where did you hear about FLTK? I just ran into it through goolging.


I think FLTK is pretty close to a C/++ model for your MinWin ideas.

The one major weakness of FLTK I think is the event model. For example, it's not
set up to be able to use functors as event handlers - the handlers have to be
static methods which makes accessing parent class members, etc. a PITA. This is
a problem I think may be able to be solved with D delegates for a framework like
FLTK.

- Dave


 -eye
Dec 10 2004
prev sibling next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Argh, reality chases me down. Qt is not much of an option, for licensing 
reason - it is totally infeasible to someone who doesn't want to release 
the source but is not on a high budget either.


 I was first going to target Xt/Motif. It's cheesy old-school but it's easy. 
 I agree working with pure Xlib calls would be trouble.


Motif? No, i think there are some intermediate libraries which simplify 
working with X if you want to draw directly, but Motif is really an 
alien... I'm not much of a UNIX type of being so i don't really know.


- Using GTK+. Then, your applications are not really aliens to any of the 
desktops, but GTK is quite some beast.


 
 GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to look 
 closely at it.


I was going to look closely at it because someone has to bring up enough 
courage to finally fix that damned tablet support under Windows! 
However, MacOS-X support is even worse, although there are experimantal 
groups worklng on that.


I recall someone posted the link to a project which maintains a similar C 
library, generating very compact executables, with Win32 and Qt peers.

http://www.leonardo-vm.org/




Again, with reality chasing me up... Qt is a trouble here.


One problem, is that it is pure LGPL - which means it cannot be linked 
statically into closed-source application, which is a major restriction. 
It may be that the restriction was not intended, and that one could mail 
them and ask for a linkage exception like in wxWidgets and FLTK, which 
would make it an acceptable and easy target. Or in sublicensing the 
relevant parts of the code under a more liberal license.


 
 
 Thanks for the link. I'll check into it. I had heard of FLTK but only 
 browsed around the web site a bit so I'll look at it a little more carefully 
 now. Where did you hear about FLTK? I just ran into it through goolging.


I don't know... I was monitoring cross-platform toolkits for years, so 
perhaps from (http://www.atai.org/guitool/) GUI framework page, like 
everything.

FLTK was developed as a reaction of developers to the fact that they 
were writing just as much code to talk to Motif as it would take them to 
draw directly to X. So, FLTK draws everything in its own style, with 
minor adjustments by OS, but is high performance and moderately sized. 
It has quality surface/window implementations for all 3 targets, and 
looks alien on all of them though quite nice. It might make sense to 
wrap the window/canvas classes from FLTK implementation and remplement 
all the drawing in a similar style atop. FLTK is very simple conceptually.

-eye
Dec 10 2004
parent reply Dave <Dave_member pathlink.com> writes:
In article <cpcv8l$2dbr$1 digitaldaemon.com>, Ilya Minkov says...


[snip]

FLTK was developed as a reaction of developers to the fact that they 
were writing just as much code to talk to Motif as it would take them to 
draw directly to X. So, FLTK draws everything in its own style, with 
minor adjustments by OS, but is high performance and moderately sized. 
It has quality surface/window implementations for all 3 targets, and 
looks alien on all of them though quite nice. It might make sense to 
wrap the window/canvas classes from FLTK implementation and remplement 
all the drawing in a similar style atop. FLTK is very simple conceptually.


I was looking at x-platform toolkits a while back and FLTK really stuck out as
pretty cool, except (as I mentioned before) the event model needs to be
improved, IMHO. FLTK is not only fast and light but coding with its object model
seemed pretty nice also.

IIRC, the general look and feel of apps. built with FLTK v2.0 can be changed
with 'skins'. The default was the 'redmond'/win32 style for all platforms back
when I tried it (FLTK v2 is available through CVS from fltk.org). I suppose a
library modeled on FLTK could default at runtime to a skin that mimicks the
native look of what ever platform launched it, so the MinWin native look'n'feel
of the OP would be met.

FLTK might really be worth a good look for MinWin ideas maybe..



 Dec 10 2004



  parent reply Roald Ribe <rr.nospam nospam.teikom.no>  writes:


Dave wrote:

 In article <cpcv8l$2dbr$1 digitaldaemon.com>, Ilya Minkov says...
 
 [snip]
 

FLTK was developed as a reaction of developers to the fact that they 
were writing just as much code to talk to Motif as it would take them to 
draw directly to X. So, FLTK draws everything in its own style, with 
minor adjustments by OS, but is high performance and moderately sized. 
It has quality surface/window implementations for all 3 targets, and 
looks alien on all of them though quite nice. It might make sense to 
wrap the window/canvas classes from FLTK implementation and remplement 
all the drawing in a similar style atop. FLTK is very simple conceptually.


 
 
 I was looking at x-platform toolkits a while back and FLTK really stuck out as
 pretty cool, except (as I mentioned before) the event model needs to be
 improved, IMHO. FLTK is not only fast and light but coding with its object
model
 seemed pretty nice also.
 
 IIRC, the general look and feel of apps. built with FLTK v2.0 can be changed
 with 'skins'. The default was the 'redmond'/win32 style for all platforms back
 when I tried it (FLTK v2 is available through CVS from fltk.org). I suppose a
 library modeled on FLTK could default at runtime to a skin that mimicks the
 native look of what ever platform launched it, so the MinWin native look'n'feel
 of the OP would be met.
 
 FLTK might really be worth a good look for MinWin ideas maybe..


I do not know FLTK at all, but judging from the work on Swing, Look is
reasonably easy to acheive, Feel is not! Unless you use native widgets.
I am mostly talking with MS-Win experience here.

Roald



 Dec 10 2004



  parent reply Dave <Dave_member pathlink.com>  writes:


In article <cpdhvp$5nj$2 digitaldaemon.com>, Roald Ribe says...

I do not know FLTK at all, but judging from the work on Swing, Look is
reasonably easy to acheive, Feel is not!


Ach! You're right - what the heck was I thinking.. More look, not feel. Again
IIRC, I believe the skins do let you control some things besides color and
shading like button relief (raised, flat, etc..).



 Dec 10 2004



  parent reply "unda dogg" <unda_dogg yahooc.om>  writes:


I do not know FLTK at all, but judging from the work on Swing, Look is
reasonably easy to acheive, Feel is not!




look at idea. it is written in swing, but its feel is pretty much superior
even to native windows apps.



 Dec 17 2004



  parent  Roald Ribe <rr.nospam nospam.teikom.no>  writes:


unda dogg wrote:

I do not know FLTK at all, but judging from the work on Swing, Look is
reasonably easy to acheive, Feel is not!




 
 
 look at idea. it is written in swing, but its feel is pretty much superior
 even to native windows apps.
 


I believe you. But the idea developer team is one among hundreds, and if most
of the others does not achieve good native Windows feel, I think it is the
"feel" implementation in Swing that is lacking. I have not had the time to
look at the newest JDK yet. May be it is better.

Roald



 Dec 18 2004



prev sibling next sibling parent reply Jan Bendtsen <dimon controlREMOVEME.aau.dk>  writes:


Hi,
Ben Hinkle wrote:

 "Ilya Minkov" <minkov cs.tum.edu> wrote in message 
 news:cpal99$2029$1 digitaldaemon.com...
 

Ben Hinkle schrieb:


This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
MinTL. The goals are:
- be as small and simple as possible while still being useful
- support cross-platform development where the peers exist and have 
similar behavior






This looks very, very nice indeed, but...

[snip]

- Using GTK+. Then, your applications are not really aliens to any of the 
desktops, but GTK is quite some beast.


 
 
 GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to look 
 closely at it.


I figure Ant is too polite and modest to mention it himself in this 
forum, but DUI appears to be a very promising step in this direction. 
What about collaborating with him on making DUI even better? It could 
end up being the D equivalent of what Swing has become for Java, 
something everyone can rely on and fall back on. Who knows, maybe 
someday it might even become an equivalent of, or even part of, phobos?




Cheers,
Jan



 Dec 10 2004



  parent reply "Ben Hinkle" <bhinkle mathworks.com>  writes:


 GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to




look

 closely at it.


 I figure Ant is too polite and modest to mention it himself in this
 forum, but DUI appears to be a very promising step in this direction.
 What about collaborating with him on making DUI even better? It could
 end up being the D equivalent of what Swing has become for Java,
 something everyone can rely on and fall back on. Who knows, maybe
 someday it might even become an equivalent of, or even part of, phobos?


My goal isn't to port GTK+ or compete with DUI or Swing. That would be
targeting full-featured cross-platform toolkits. I want to write a small
toolkit that leverages the "native toolkit". On Windows the native toolkit
is clear. On Unix there is no clear choice - and some of the choices like
GTK+ are cross-platform so it starts to get confusing about what one means
by "native toolkit". I suppose taken to extreme someone could take MinWin
and code it to always use GTK+ and then ship that on Windows and Unix - but
that would be silly since that's what DUI is for (and DUI would map to GTK+
much better than MinWin would). So I see DUI and MinWin as being pretty
different beasts with different goals (and both would be very useful IMO).



 Dec 10 2004



  parent reply Roald Ribe <rr.nospam nospam.teikom.no>  writes:


Ben Hinkle wrote:

GTK+ is very tempting. wxWidgets has a wrapper for it so I was going to




 
 look
 

closely at it.


I figure Ant is too polite and modest to mention it himself in this
forum, but DUI appears to be a very promising step in this direction.
What about collaborating with him on making DUI even better? It could
end up being the D equivalent of what Swing has become for Java,
something everyone can rely on and fall back on. Who knows, maybe
someday it might even become an equivalent of, or even part of, phobos?


 
 
 My goal isn't to port GTK+ or compete with DUI or Swing. That would be
 targeting full-featured cross-platform toolkits. I want to write a small
 toolkit that leverages the "native toolkit". On Windows the native toolkit
 is clear. On Unix there is no clear choice - and some of the choices like
 GTK+ are cross-platform so it starts to get confusing about what one means
 by "native toolkit". I suppose taken to extreme someone could take MinWin
 and code it to always use GTK+ and then ship that on Windows and Unix - but
 that would be silly since that's what DUI is for (and DUI would map to GTK+
 much better than MinWin would). So I see DUI and MinWin as being pretty
 different beasts with different goals (and both would be very useful IMO).


I do not want to butt in too much, but I think you should give SWT a really
long hard look before you decide to go another way. Just a personal opinion,
based on my general interest and long lasting research about portable GUI's.

Roald



 Dec 10 2004



 next sibling parent  Brad Anderson <brad dsource.dot.org>  writes:


Roald Ribe wrote:

 
 I do not want to butt in too much, 


please do


 but I think you should give SWT a really
 long hard look before you decide to go another way. 


Maybe you could breathe some life into an SWT port to D.

http://www.dsource.org/projects/dwt

BA


 Just a personal 
 opinion,
 based on my general interest and long lasting research about portable 
 GUI's.
 
 Roald
 





 Dec 10 2004



prev sibling  parent  John Reimer <brk_6502 yahoo.com>  writes:


Roald Ribe wrote:

 Ben Hinkle wrote:
 
 
 I do not want to butt in too much, but I think you should give SWT a really
 long hard look before you decide to go another way. Just a personal 
 opinion,
 based on my general interest and long lasting research about portable 
 GUI's.
 
 Roald
 


SWT is native on windows and uses Gtk+ on Linux.  It uses many of the 
design goals mentioned by Ben .  Yet it is a huge project meant to be 
entirely cross-platform.

DWT attempts to bring this GUI Toolkit over to D.  The port has stalled 
mostly because it had caused some pretty major problems with the dmd 
compiler that were hard to diagnose; also several people seemed 
interested in the idea of the project, but few were willing to put time 
into implementing it.  If someone ever succeeds in troubleshooting those 
problems, then DWT developement can continue.  I'm still keeping my eye 
on it as a solid potential project.  I contribute to it now and then as 
I get up renewed energy to attack the problems.  But I haven't got very 
far with it yet.

 From the application programmer's perspective, SWT is a really slick 
tool, but I find the implementation quite convoluted and the OO part of 
the code quite "spaghetti" like.  Converting it from Java to D is not so 
  straight forward.  DWT has become the master of all stress tests for 
the D module import system.

It would be nice to see some extra hands working on this project.  That 
said, I still understand if Ben prefers to start a smaller, simpler 
project of his own design in D.  One of the disadvantages to porting a 
project the size of SWT is that you have less of a choice in how you use 
the D language to implement it; you end up having to adopt the project's 
design, which means developing in a Java-like style with Java-type 
limitations.  Designing with D from the start opens up a whole new world 
of possibilities.  Not to say a D style can't be worked into SWT, but 
doing so is risky because the more one departs from the java model, the 
less reliable and untested the port becomes, which kind of defeats the 
whole purpose of the port.

Later,

John



 Dec 11 2004



prev sibling  parent  "unda dogg" <unda_dogg yahooc.om>  writes:


gtk and qt are prolly too much to depend on.
maybe using just gdk might solve some platform issues, but still not any
with the codebase.
i think motif should be let die.  and xt more than likely is something that
should be avoided if possible.

if you would use fltk (or swt) as a base, [the issue with macs] prolly
wouldnt be (too much of) an issue.

personally, i'd rather a lgpl with an exception clause than a zlib-like
license. does this make sense?

how much software is really public domain? prolly not many well known
packages, but small libraries, right?


 MinWin, too. Support for trees and tables won't be built-in. I see it
 being
 something like AWT-lite with better native access. The problem with






large

 cross-platform toolkits is that they never are really cross-platform






and

 they never really look like native apps. Cross-platform development is
 very
 hard so the MinWin approach will be to only do it where it works and






give

 easy access to the platform for everything else.






i think swt is rather light, and jface is completely java on top of that
with support for trees on platforms that dont natively support them. plus,
there is plenty of source that could be adapted.

fltk is a good kit, but is rather ugly.  although that is not a good reason
not to use it.

-- alimoe



 Dec 17 2004



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


Excellent idea.  I haven't used it myself, but WxWindows is probably worth
looking at to find a common minima for native UI support.


Sean



 Dec 09 2004



 next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Sean Kelly wrote:


 Excellent idea.  I haven't used it myself, but WxWindows is probably worth
 looking at to find a common minima for native UI support.


The only problem is that wxWidgets (new name!) is written in C++.
This means that one must first wrap it in C, for linking with D.

There was a project to provide a module for D, called "wxD", but it
seems to be missing in action ? Or maybe it's just my bad Japanese...

http://www.prowiki.org/wiki4d/wiki.cgi?wxD


Related projects:

http://wxwindows.sourceforge.net/

 wxWidgets gives you a single, easy-to-use API for writing GUI
 applications on multiple platforms. Link with the appropriate library
 for your platform (Windows/Unix/Mac, others coming shortly) and
 compiler (almost any popular C++ compiler), and your application will
 adopt the look and feel appropriate to that platform.


http://elj.sourceforge.net/projects/gui/ewxw/

 The elj project (sourceforge) is an open source project to facilitate the
 development of open-source libraries and applications for SmartEiffel

 wxEiffel (ewxw) is elj interface to the WxWindows GUI library (version 2.2.9)


http://wxnet.sourceforge.net/

 wx.NET is a .NET Common Language Infrastructure (CLI) wrapper for wxWidgets.

 It is composed of two parts:
 * wx-c is a C++ library which exposes the wxWidgets API as a


   wxWidgets class hierarchy.



So by using wxWidgets and wxC, it should be possible to complete "wxD" ?
Probably a LOT easier than duplicating such cross-platform GUI efforts ?


There's also a couple of native GUI wrappers for D already, such as:
SDWF - Win32, DUI - GTK+ 2.4, "DCarbon"* - Mac OS X Carbon, and more...

But those don't fit the small and simple and cross-platform description.

--anders


PS. Here's wxWidgets screenshots: http://www.wxwidgets.org/screen01.htm

PPS. * OK, maybe there isn't such a DCarbon library. Not yet, anyway ;-)



 Dec 10 2004



prev sibling  parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"Sean Kelly" <sean f4.ca> wrote in message 
news:cpant3$23qv$1 digitaldaemon.com...

 Excellent idea.  I haven't used it myself, but WxWindows is probably worth
 looking at to find a common minima for native UI support.


 Sean


yeah - I looked at wxWidgets (the new name for wxWindows) with an eye to 
just porting it to D but it is full of tons of C preprocessor macros that 
looked nasty to me and I had a hard time figuring out the source code tree - 
it isn't described very well. Plus it has lots of stuff D wouldn't need 
about threading, streams, and other utility classes that are covered by 
phobos. So I figured it would be just as much work to start over (famous 
last words...). I did print out their widget list so I could start with 
that. 



 Dec 10 2004



  parent  "unda dogg" <unda_dogg yahooc.om>  writes:


 yeah - I looked at wxWidgets (the new name for wxWindows) with an eye to
 just porting it to D but it is full of tons of C preprocessor macros that
 looked nasty to me and I had a hard time figuring out the source code


tree -

 it isn't described very well. Plus it has lots of stuff D wouldn't need
 about threading, streams, and other utility classes that are covered by
 phobos. So I figured it would be just as much work to start over (famous
 last words...). I did print out their widget list so I could start with
 that.


porting that lib would take ages.  personally, i think that focusing on swt,
fltk or fox (in that order).

--alimoe



 Dec 17 2004



prev sibling next sibling parent reply pragma <pragma_member pathlink.com>  writes:


A fantastic idea, Ben.  A minimal, flexible and portable windowing library is
just what the doctor ordered.

Now, I come from a primarily web-development background so I tend to lament the
verbosity and complexity imposed by most windowing toolkits.  I think AWT's
GridBagLayout class, for example, embodies exactly the kind of thing that such a
project should avoid.  

To that end, I have a few suggestions for your project.

(These are all strictly in my opinion.  Please take with a grain of salt)

- *Really* flexible event plumbing (Signal-Slot perhaps).  In my experience,
Win32/MFC, wxWindows, AWT, Swing and even DHTML all have severe limitations for
certain event processing tasks.  Keeping things open-ended for creative
solutions, while providing solid default behavior is key.

- Simple controls are all that are needed.  I understand that trees and such are
a hot topic here, and are no doubt useful.  But perhaps a toolkit minimal enough
that a tree control could easily be built from said toolkit might just hit the
sweetspot.  Besides some native tree controls (*coughwin32cough*) are chock-full
of nasty limitations and are tough to use.

- Leave out direct support for dialog resources, ui files, etc.  The best RAD
tools out there, for the exception of .NET, use some kind of external file
format for building GUIs. (.NET manipulates components in a design view, which
would be needlessly complex for this lib IMO)  As long as components can be
moved in real time, and be programatically composed from scratch, you probably
needn't even be concerned with such a thing.  It'll become an exercise for
another developer (maybe even yourself) at a later date.

- Dynamic layout engines are a PITA to write and use.  Perhaps sticking with
static layout only (container+offset at the most), and leaving it to the
developer to handle window/component resizing events 'manually' is the way to
go.  Usually, its only the editor pane or just a handfull of components that
need to be sensitive to a screen resize; not the entire window's layout.  Also,
something like a custom rich-editor control (think: text and images in the same
field) is going to have its own particular layout problems to worry about, so
just leave it up to the developer.

Hope this helps,

- pragma [ ericanderton at yahoo ]



 Dec 10 2004



  parent  Roald Ribe <rr.nospam nospam.teikom.no>  writes:


pragma wrote:

 A fantastic idea, Ben.  A minimal, flexible and portable windowing library is
 just what the doctor ordered.
 
 Now, I come from a primarily web-development background so I tend to lament the
 verbosity and complexity imposed by most windowing toolkits.  I think AWT's
 GridBagLayout class, for example, embodies exactly the kind of thing that such
a
 project should avoid.  
 
 To that end, I have a few suggestions for your project.
 
 (These are all strictly in my opinion.  Please take with a grain of salt)


GridbagLayout layout stinks! I have done a lot of research into Java layout 
managers. The easiest/most flexible/most general/quickest to learn and 
understand is TableLayout. http://www.clearthought.info/software/TableLayout
It is free, and I think a port to SWT already exists.

Roald



 Dec 10 2004



prev sibling next sibling parent  Geoff Hickey <Geoff_member pathlink.com>  writes:


In article <cpa9in$1c4a$1 digitaldaemon.com>, Ben Hinkle says...

This might be crazy, but I've been mulling over a new project called
MinWin - the "Minimal Window Toolkit" with the same basic philosphy as
MinTL. The goals are:
- be as small and simple as possible while still being useful
- support cross-platform development where the peers exist and have similar
behavior
- seemlessly integrate with peers and platform-specific code
- minimize the dependencies on other large libraries to avoid complex
install and license issues
- make it public domain (or make the core parts public domain)


Instead of building a whole thing from scratch, what about building a wrapper
for Tcl/Tk, like Python does with Tkinter? That would give you cross-platform
GUI support without such a large maintenance burden. 

I'm not a GUI programmer, I spend most of my time in kernel and device driver
space, but my small experience with Tk in a few Python projects I've done has
left me with a positive impression. I don't think there would be any licensing
issues - it looks like they use a BSD-style license - but you can check
http://tcl.tk/ for more information. Since D has associative arrays, you could
use something like the named-variable style for function calls that Python uses,
which is one of the reasons the syntax for Tkinter calls in Python is so
readable and can be written quickly.

Tcl/Tk interfaces with C, so I don't imagine that interfacing with D would be
very difficult.

I have no idea how hard it is to mix Tk with native graphical widgets, one of
your requirements. Maybe someone else here can speak to that.

- Geoff



 Dec 10 2004



prev sibling  parent reply Georg Wrede <Georg_member pathlink.com>  writes:


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





#int main()



























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.)



 Dec 13 2004



 next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


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



 Dec 13 2004



  parent reply "unda dogg" <unda_dogg yahooc.om>  writes:


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


* maybe you want an interpreter written in d that would allow easier
translation of java concepts?

* tk is even uglier and more non-functional than anything else
* ... and yes, i think as much code should be in d as possible
(swt/fltk/fox)
* check out ultimate++ as an alternative to qt and wxwin

--alimoe



 Dec 17 2004



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


unda dogg wrote:


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


 
 * maybe you want an interpreter written in d that would allow easier
 translation of java concepts?


Like GCJ you mean ? No thanks :-)

--anders



 Dec 18 2004



prev sibling  parent reply "Ben Hinkle" <bhinkle mathworks.com>  writes:


"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;
}



 Dec 13 2004



 next sibling parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


"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 



 Dec 13 2004



  parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"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

 





 Dec 13 2004



 next sibling parent  Chris Sauls <Chris_member pathlink.com>  writes:


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



 Dec 13 2004



prev sibling  parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


"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 



 Dec 13 2004



  parent reply "Ben Hinkle" <bhinkle mathworks.com>  writes:


"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();
}



 Dec 14 2004



  parent reply Ant <Ant_member pathlink.com>  writes:


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



 Dec 14 2004



  parent reply "Ben Hinkle" <bhinkle mathworks.com>  writes:


"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.



 Dec 14 2004



  parent  "Ben Hinkle" <bhinkle mathworks.com>  writes:


"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:cpn5fj$2a8j$1 digitaldaemon.com...

 "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.


the MinWin forum is open now (thanks Brad!)
http://www.dsource.org/forums/viewforum.php?f=47



 Dec 14 2004



prev sibling  parent reply "unda dogg" <unda_dogg yahooc.om>  writes:


* does `d' have an equivalent to c++'s auto_ptr?

--alimoe



 Dec 17 2004



  parent  "Ben Hinkle" <ben.hinkle gmail.com>  writes:


"unda dogg" <unda_dogg yahooc.om> wrote in message 
news:cq08l5$jqp$1 digitaldaemon.com...

 * does `d' have an equivalent to c++'s auto_ptr?


not exactly. It has an auto attribute for variables which ensures the 
destructor is called when the variable goes out of scope. So if your comment 
was aimed at removing that "delete font" statement I could have written 
"auto Font font =..." I like that better than what I originally posted. 



 Dec 18 2004