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

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? On a side note, BTW: yes, GTK+ is a beast... ! #$%)*!^+_* version 2.4.x and its #&()~!#$%^( dependency hell! :-( 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


 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



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



 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



 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
   collection of C# friendly functions.
 * wx.NET is a .NET assembly written in C# which parallels the
   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

 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 # /* 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.)
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

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

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

 | that you can make any number of windows and make any number visible

 | you enter the event loop and presumably they will be shown on screen in

 | order they were made visible. One thing I added since posting that

 | is a frame property called quitOnClose which is false by default but

 | 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

 | 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

 (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

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

 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