I've just started going through the Harmonia source (can't try it, unfortunately, as I don't use Windows) and I've got a few notes that would help porting.

It seems like you've been going for a relatively easy porting process,
but there are a few more steps you can take:
	-Create interfaces for all of the classes in harmonia.ui.native.win32*
	-Don't import harmonia.ui.native.win32* in anything outside of that
package.  Instead, for all of these create another file without the
win32 that has public imports.  For instance, create
harmonia.ui.native.application, and have it contain something like:
version (Windows) {
	public import harmonia.ui.native.win32application;
}
else
{
	static assert(0);
}

This way, when a port is made, one really only has to implement the aforementioned interfaces, and modify some 4 files in ui.native to import them in the linux version.

Documentation.  (You probably know about this one.) Since I've never done any Windows GUI programming, I don't know what a lot of this stuff is or does.  Should you create those interfaces, it's important to give details as to what each method does.  Right now, many are almost direct windows calls, but wouldn't be on a Linux port, so the exact behavior must be noted.

On a non-technical note: the license.  In order for me to use Harmonia, it's license would need to be GPL-compatible.  And of course if I can't use it, I'm definately not going to contribute code. (But don't take that to mean that if it is, I will.)  I'm not sure if your license is GPL-compatible, but I would recommend simply choosing a license from this list: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses choosing one that's close, and noting that your are using this license. It's much more simple for everyone else if you use a "standard" one.

Back to technical stuff: Unix guys: from the little bit of browsing I've done through the native modules, it looks like a Unix port could either use the plain and simple X11 libs, or GDK.  I'm not familiar with either, however.  Does this sound about right?

That's it for me, for now.
John Demme

Hi, John, see inline:

"John Demme" <me@teqdruid.com> wrote in message news:1116091945.19794.50.camel@localhost.localdomain...
> I've just started going through the Harmonia source (can't try it, unfortunately, as I don't use Windows) and I've got a few notes that would help porting.
>
> It seems like you've been going for a relatively easy porting process,
> but there are a few more steps you can take:
> -Create interfaces for all of the classes in harmonia.ui.native.win32*

In harmonia.ui.native.win32.* package
I am using simple naming convention instead:

all functions with names starting with 'native...' needs to be ported as they seen from generic packages. The same is valid for class names: e.g. NativeImage is a class visible and used by generic code.

I understand motivation but don't think that interfaces is an effective
solution.
Interfaces are heavy a bit and they always needs some class instance....
If we will treat 'interface' as an API then I think it would be just enough
to define/list
native functions in porting.txt file in the distribution.
I' ll try to write such file today.

> -Don't import harmonia.ui.native.win32* in anything outside of that
> package.  Instead, for all of these create another file without the
> win32 that has public imports.  For instance, create
> harmonia.ui.native.application, and have it contain something like:
> version (Windows) {
> public import harmonia.ui.native.win32application;
> }
> else
> {
> static assert(0);
> }
>
> This way, when a port is made, one really only has to implement the aforementioned interfaces, and modify some 4 files in ui.native to import them in the linux version.

Exactly, that was my intention too,

There are four native modules and six and only six generic modules importing them.

harmonia.ui.window -> harmonia.ui.native.win32window
harmonia.ui.graphics -> harmonia.ui.native.win32graphics
harmonia.ui.images -> harmonia.ui.native.win32graphics
harmonia.ui.application -> harmonia.ui.native.win32application
harmonia.ui.exchange.clipboard -> harmonia.ui.native.win32exchange
harmonia.ui.exchange.dnd ->  -> harmonia.ui.native.win32exchange (planned,
not in distribution)

This list is frozen and highly probable will not be changed in future.

All other modules do not use any native* functions nor classes now and beyond.

So for porting it is just enough to update version sections in those six files.

Let me know if you think this is still the problem.

>
> Documentation.  (You probably know about this one.) Since I've never done any Windows GUI programming, I don't know what a lot of this stuff is or does.  Should you create those interfaces, it's important to give details as to what each method does.  Right now, many are almost direct windows calls, but wouldn't be on a Linux port, so the exact behavior must be noted.

Agreed.

>
> On a non-technical note: the license.  In order for me to use Harmonia, it's license would need to be GPL-compatible.  And of course if I can't use it, I'm definately not going to contribute code. (But don't take that to mean that if it is, I will.)  I'm not sure if your license is GPL-compatible, but I would recommend simply choosing a license from this list: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses choosing one that's close, and noting that your are using this license. It's much more simple for everyone else if you use a "standard" one.

Harmonia license is close to http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5
which by itself is compatible with GPL.
If you think that it is not close enough then let me know, I'll update it.

>
> Back to technical stuff: Unix guys: from the little bit of browsing I've done through the native modules, it looks like a Unix port could either use the plain and simple X11 libs, or GDK.  I'm not familiar with either, however.  Does this sound about right?

As to my knowledge: Harmonia can use only X11 libs without any
additional layer like GDK.
Only one:
I am going to make a bridge to standard OS Shell dialogs like OpenFile,
SaveFileAs
and SelectPrinter. These may require interaction with OS Shell.
But as a zero level porting these dialogs can be implemented in Harmonia
using its own
Dialog facility and Phobos file objects.

As Harmonia does not use system widgets (like editbox, etc.)  then I think porting could be made more or less flawlessly and compact.

FLTK (http://fltk.org) use the same approach and it was ported  on
UNIX/Linux (X11), Win32 and MacOS X.
I think that FLTK sources could be used as a manual for Harmonia native
modules porting.

And of course in case of any problems with porting please let me know.

Andrew.

On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:
> >
> > Back to technical stuff: Unix guys: from the little bit of browsing I've done through the native modules, it looks like a Unix port could either use the plain and simple X11 libs, or GDK.  I'm not familiar with either, however.  Does this sound about right?
> 
> As to my knowledge: Harmonia can use only X11 libs without any additional layer like GDK.
The only reason I mention GDK, is because I believe it makes things easier, and look nicer.  It is, after all, the back end for GTK.

> Only one:
> I am going to make a bridge to standard OS Shell dialogs like OpenFile,
> SaveFileAs
> and SelectPrinter. These may require interaction with OS Shell.
> But as a zero level porting these dialogs can be implemented in Harmonia
> using its own
> Dialog facility and Phobos file objects.
> 
Actually, things a high level as these would be specific to the widget system (QT, GTK, etc...)  It'd be much easier to use whatever is already in Harmonia.

John Demme

"John Demme" <me@teqdruid.com> wrote in message news:1116103698.19794.81.camel@localhost.localdomain...
> On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:
>> >
>> > Back to technical stuff: Unix guys: from the little bit of browsing
>> > I've
>> > done through the native modules, it looks like a Unix port could either
>> > use the plain and simple X11 libs, or GDK.  I'm not familiar with
>> > either, however.  Does this sound about right?
>>
>> As to my knowledge: Harmonia can use only X11 libs without any additional layer like GDK.
> The only reason I mention GDK, is because I believe it makes things easier, and look nicer.  It is, after all, the back end for GTK.

If GDK is something standard for all *x'es then why not? if it is easier...

>
>> Only one:
>> I am going to make a bridge to standard OS Shell dialogs like OpenFile,
>> SaveFileAs
>> and SelectPrinter. These may require interaction with OS Shell.
>> But as a zero level porting these dialogs can be implemented in Harmonia
>> using its own
>> Dialog facility and Phobos file objects.
>>
> Actually, things a high level as these would be specific to the widget system (QT, GTK, etc...)  It'd be much easier to use whatever is already in Harmonia.

Probably, yes. Question is just about usability and user preferences.
In Windows such dialogs allow you to select stuff in e.g. Shell Name
Extensions
but this seems so rarely used so we can drop this.

(Shell Name Extensions was one more bright idea trying to give felicity-for-everybody-and-free-of-charge, but people didn't buy it.)

John Demme wrote:

> On Sat, 2005-05-14 at 13:07 -0700, Andrew Fedoniouk wrote:
> 
>>>Back to technical stuff: Unix guys: from the little bit of browsing I've
>>>done through the native modules, it looks like a Unix port could either
>>>use the plain and simple X11 libs, or GDK.  I'm not familiar with
>>>either, however.  Does this sound about right?
>>
>>As to my knowledge: Harmonia can use only X11 libs without any
>>additional layer like GDK.
> 
> The only reason I mention GDK, is because I believe it makes things
> easier, and look nicer.  It is, after all, the back end for GTK.
> 
> 
>>Only one:
>>I am going to make a bridge to standard OS Shell dialogs like OpenFile, SaveFileAs
>>and SelectPrinter. These may require interaction with OS Shell.
>>But as a zero level porting these dialogs can be implemented in Harmonia using its own
>>Dialog facility and Phobos file objects.
>>
> 
> Actually, things a high level as these would be specific to the widget
> system (QT, GTK, etc...)  It'd be much easier to use whatever is already
> in Harmonia.

I wouldn't use the library if it didn't use the native widget (or at least have an option to use it) for file selection - getting this right is not an easy task, as the long-time suckitude of Unix file selectors (and to be fair, Windows file selectors before Windows 98) show.

Just consider how to support a hotplugged pen drive/camera/PSP.  With the default widget you don't have to think about it; it knows how to create the necessary crazy file paths, not just for Windows XP, but for all previous versions of Windows that support hotplugging.

John Demme wrote:
<snip>

> Back to technical stuff: Unix guys: from the little bit of browsing I've
> done through the native modules, it looks like a Unix port could either
> use the plain and simple X11 libs, or GDK.  I'm not familiar with
> either, however.  Does this sound about right?

It would be best to use X11 directly.  Harmonia provides the actual widget drawing.  This further allows for common look/feel between it and the windows port.  GDK is too high level; and as common as GDK/GTK is, it is not available everywhere.  I think the idea of harmonia is to keep the library as simple and independent of platform as possible.

-JJR

Andrew Fedoniouk wrote:

<snip>

> 
>>Back to technical stuff: Unix guys: from the little bit of browsing I've
>>done through the native modules, it looks like a Unix port could either
>>use the plain and simple X11 libs, or GDK.  I'm not familiar with
>>either, however.  Does this sound about right?
> 
> 
> As to my knowledge: Harmonia can use only X11 libs without any
> additional layer like GDK.
> Only one:
> I am going to make a bridge to standard OS Shell dialogs like OpenFile, SaveFileAs
> and SelectPrinter. These may require interaction with OS Shell.
> But as a zero level porting these dialogs can be implemented in Harmonia using its own
> Dialog facility and Phobos file objects.
>

If you do this bridge, be aware that it will make other ports more complicated on other platforms... because all equivalent high-level dialogs are located in GTK or Qt or whatever (on linux for example). This dependency is a pretty big one and acutely changes the original advantage of Harmonia and any discussion of forgoing interaction with GTK/GDK.

> As Harmonia does not use system widgets (like editbox, etc.)  then
> I think porting could be made more or less flawlessly and compact.

I liked the idea of Harmonia because its premise had no reliance on system widgets.

> FLTK (http://fltk.org) use the same approach and it was ported  on
> UNIX/Linux (X11), Win32 and MacOS X.
> I think that FLTK sources could be used as a manual for Harmonia native modules porting.

True, FLTK is a good example of a project with similar goals.  It may very well be a good resource.

I'm working on other projects right now, but I'd like to see this one work too.  I'll see what I can do.

-John

Andrew Fedoniouk wrote:

>>The only reason I mention GDK, is because I believe it makes things
>>easier, and look nicer.  It is, after all, the back end for GTK.
> 
> 
> If GDK is something standard for all *x'es then why not? if it is easier...
> 
>

It's not standard for all x's although it may be ported to the majority of them.  I don't think such a dependency is a good idea.  Of course, if someone is interested in attempting such a port, it can't hurt to try, correct?  The more the merrier:  Harmonia could use X11, opengl, GDK... :)

It would only be an adavantage to have several options.   For now, I think giving X11 a try should be a higher priority.


>>
>>Actually, things a high level as these would be specific to the widget
>>system (QT, GTK, etc...)  It'd be much easier to use whatever is already
>>in Harmonia.
> 
> 
> Probably, yes. Question is just about usability and user preferences.
> In Windows such dialogs allow you to select stuff in e.g. Shell Name Extensions
> but this seems so rarely used so we can drop this.

True, but on unixes these file dialogs are too varied and unreliably disimilar... that is, there is no standard.  On Windows, on the other hand...

-JJR

Burton Radons wrote:

>>
>> Actually, things a high level as these would be specific to the widget
>> system (QT, GTK, etc...)  It'd be much easier to use whatever is already
>> in Harmonia.
> 
> 
> I wouldn't use the library if it didn't use the native widget (or at least have an option to use it) for file selection - getting this right is not an easy task, as the long-time suckitude of Unix file selectors (and to be fair, Windows file selectors before Windows 98) show.

Each to his own.  I think we need a selection of GUI toolkit types. Harmonia is one of them.  People might say the same about the FLTK.  But non-native widget toolkets serve a very useful purpose in many different types of projects, I'm sure.

Other projects are already taking the native widget set design direction.  It's just nice to have a choice; and Harmonia, so far, is hands down one of the most pleasing to look at.  I, for one, welcome it.

> Just consider how to support a hotplugged pen drive/camera/PSP.  With the default widget you don't have to think about it; it knows how to create the necessary crazy file paths, not just for Windows XP, but for all previous versions of Windows that support hotplugging.

Good point.  This is more the case on Windows XP.  On Linux/Unix, compatibility is so unattainable/unreliable as to make the issue moot.

-JJR

>
> If you do this bridge, be aware that it will make other ports more complicated on other platforms... because all equivalent high-level dialogs are located in GTK or Qt or whatever (on linux for example). This dependency is a pretty big one and acutely changes the original advantage of Harmonia and any discussion of forgoing interaction with GTK/GDK.

I any case it will be just standalone functions like Application.selectFile( string defaultFolderPath, fileTypes, flags ) this funtion on win will use nativeSelectFile and on other platforms it could be implemented in Harmonia as modal Dialog.

The idea is simple: Harmonia should allow to write GUI even on
devices without OS in common sense.
Theoretically if we will have a kernel implementation
on some device then Harmonia can work there.
Market of smart devices is here... (idea for Walter).

>
>> As Harmonia does not use system widgets (like editbox, etc.)  then I think porting could be made more or less flawlessly and compact.
>
> I liked the idea of Harmonia because its premise had no reliance on system widgets.

Yes and there is huge class of tasks which does not require system
widgets. Even such things as IDEs in genereal do not strongly require them.
E.g. IDEs in pure Java all made without them.
Eclipse is an exception but they were forced to use SWT because
Sun seems like not interested in Java GUI at all.

Even Microsoft in Avalon is dropping system widgets in favour
of managed ones written from ground up (WinForms.Net is dying) and XAML.

I think that upcoming Harmonia.RichTextBox can be used as a source code editor with not only syntax highlighting but with also inline documentation in WYSIWYG (dream).

>
>> FLTK (http://fltk.org) use the same approach and it was ported  on
>> UNIX/Linux (X11), Win32 and MacOS X.
>> I think that FLTK sources could be used as a manual for Harmonia native
>> modules porting.
>
> True, FLTK is a good example of a project with similar goals.  It may very well be a good resource.
>
> I'm working on other projects right now, but I'd like to see this one work too.  I'll see what I can do.
>
> -John