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

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

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

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

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

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

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

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
> 

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

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