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

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

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

"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

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

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

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

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 ]

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

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