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

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

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

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

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

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

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

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

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

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