Hi team

I though I would start a seperate thread focusing specifically on chatter about the new NTUI framework
that emerged from this thread Amiga(oid)Community / Suggestion - Common API Dev team as it is making the original thread hard to follow but is still really interesting in it's own right.

Regards
Darren

@team

I cannot find anything to link for NTUI, the nearest I've come is this http://www.hd-rec.de/A/ntui.html

Hopefully more details will become available soon

darren

@newbee

There's nothing more substantial about NTUI? This is one toolkit that I hadn't heard of until now.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

There was a lot of discussion and some code samples in the other thread which I have not duplicated here, perhaps heading back to that thread for a read may be worthwhile.

But, no... unfortunately no more information appears to be available {yet}.

Darren

@newbee

Well.... It doesn't seem as though Wanderer who is writing HDRec is ready to release anything.
HDRec looks great and the author is familiar with modern software architectures, so the API library might look like it is from this century.
The thread this was spawned from was about creating a cross-platform API supporting all Amiga&alike platforms.

edit: Later in thread the discussion mentioned Linux, Windows, Mac etc. support. I am for the creation of an API that can support platforms outside of Amiga&alike platforms as well. Que common rant.

[rant name="Creating a Viable Software Market for Amiga Developers" mode="ON"]
API Compatibility with non-Amiga systems would go a long way in allowing commercial Amiga software developers access to a larger and therefore more viable market, increasing the likely-hood of a return on their investment. It may even attract developers who have never considered Amiga before, but would be interested in cross-platform development anyway.
[/rant]

Last edited by BigBentheAussie on 04-Mar-2010 at 05:28 AM.
Last edited by BigBentheAussie on 04-Mar-2010 at 05:19 AM.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

Info provided by Wanderer that I have lifted to aid the discussion in this thread. I hope no-one minds.

Quote:

Now here is an updated chart. NTUI is not read for use yet. So there is no docu and no source. I have written the basic engine and most of the widgets, still doing finishing touches on TextEditor, ListView an Menu, as well as the Skin functionality. Currently all widgets are rendered with lines, boxes and dots. This is the default look if there is no skin or the resources to low. So NTUI can run just if the library is there, without additional files, assigns etc. * fix layout means pixel accurate positioning of GUI elements, which might be desired for skinned GUIs like WinAMP or games. * auto layout means, you describe only relations betweens widgets and the acutal pixel-position is calculated on-the-fly. This makes re-sizable GUIs much easier and ensures a consistant look. * added "sync refresh", as often criticised in MUI. This means the refresh happens not instantly when you hit the button, but when the application is polling the message loop, which might be delayed because the app is doing some lengthy calculations. Platform --------------------------------------------------------------------- Toolkit GTool NTUI TUI RAOS3 RAOS4 MUI3 MUI4 Zune Feelin OS3.x * * * * - * - - * AfAOS * * * * - * - * * OS4.x * * * * * * - - * MOS * * * * - * * - * AROS * - - - - - - * * Features --------------------------------------------------------------------- FontSensitive - * * * * * * * * FontSensImages - * - - - - - - - ARGB Images - * * - * - * * * 8Bit Support * * * * * * * - - 24bit Support - * * ? * - * * * AutoLayout - * * ? ? * * * * FixLayout * * - ? ? - - - ? AREXX - * - ? ? * * * ? ScreenNotify - * - ? ? * * ? ? AppIcon - * - ? ? * * * ? BubbleHelp - * * ? ? * * * ? MoverFX - * * ? ? - - - ? FlickerFree - * - - ? - ? - ? XML - * - - - - - - * UserThemes - * - - ? * * * * Skinnable - * - - * - * * ? TextEditor - * * * * * * * ? Async Refresh * * ~ * * - - - ? Status --------------------------------------------------------------------- Developed - * - - * - * * - Available * - * * * * * * * OpenSource - * * - - - - * * Portability low hi low ? ? mid mid mid ?

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

Part of the discussion in the last thread was about library version compatibility problems with various current APIs.
Can this hell be avoided somehow? If the library is small enough could we not consider static compilation or single library files?

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

A pertinent post from Wanderer.
Quote:

Hard to say. Whatever I would post here, people will say "Toolkit XYZ can do this too". But NTUI tries to combine the "good" features while being simple, foolproof and fast for developement. I have experience with toolkits from other platforms and try get the best ideas across. There might also some unique features like on-the-fly image re-scaling, which is a very nice feature if you use a lot of decoration images. In NTUI, you tell the size of an image in logic sizes, e.g. "native" (image as is 1:1) or "inline" (font size) or "button" (size suitable for a button). So even if you use a very small or big font, images (can be AISS, Icons or whatever) appear in adequate size. The algorithm is sepcialized on GUI elements, so they look almost as if painted for this resolution. Another really cool thing is the "9-patch" format of stretchable images from Android. This enables to do really high quality and scalable skins very easily.

_________________
Leo Nigro, CTO Commodore USA, LLC
Opinions expressed are my own and not those of C= USA.
Commodore/AMIGA "Beautiful, High-Performance, Home Computers for Creativity and Entertainment."

@Team

What license will NTUI be under? This may have been discussed before, but I think it is relevant to the present discussion.

@Samurai_Crow

I dont really care about licenses if the software is free and open.

People should be allowed to do anything with it.

The screenshot above shows only the scaling algorithm.

Here are some more WIP screenshots (real, working GUIs, no fakes):
(note how well the scaling works, almost none of the images have their "native" size).
This is the build in widget rendering. Skins are being added at the moment making the look completely changable.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

It sounds like you're leaning toward the ZLib/LibPNG License. Pretty much anything goes as long as you get credit for writing the original.

@Wanderer
So, is NTUI totally cross-platform? (I mean between Amiga-like OSes. I guess a Windows/Linux port would be too much to hope for.)
EDIT: I should read the thread more carefully. Looks like it supports all Amigas except AROS (why not AROS?!?). Would have been awesome if it supported Windows/etc, as then it'd be the perfect fit for PortablE.
EDIT 2: OK, read the parent thread. Looks like AROS is not supported because NTUI is currently written in AmiBlitz for 'prototyping' purposes. At some point it'll be converted to C, and thus should support AROS.

Looks very nice anyway, now if we just knew how it worked... (Wonder if we'll get any threads saying "NTUI is vapour" because of that!)

Last edited by ChrisH on 04-Mar-2010 at 09:04 PM.
Last edited by ChrisH on 04-Mar-2010 at 07:55 PM.

_________________

@ChrisH

NTUI is cross platform in that sense that it does not use a lot of functionality from the OS and the API does not expose OS specific things.
In case of MOS/OS4/AROS/OS3/AfA there is no need to change anything. But of course, if you would port it to Windows, the functions for opening a window or drawing a colored line must be ported, but should be pretty straigt forward.
The NTUI API itself hides the OS, similiar to OpenGL or SDL. One of the very view structures that are exposed is the RastPort, as this is mandatory for CustomView.

E.g.

RastPort *rp = ntui_ObtainObjectRastPort(obj);
...
ntui_ReleaseObjectRastPort(obj);


However, this would directly correspond to a DrawContext under Windows.

I see a major benefit to other GUI Toolkits that it supports PNGs with alpha channel on all platforms and all screen depth.
So NTUI can work unchanged from 4 Color OCS screen up to 24bit.

The screenshots that I posted here are the build in look, which one would use on a Classic with 8bit or lower screen. OS4/MOS/AROS/WinUAE users would surly want to have skins. However, regarding this is the really "nacked" look its already ok.
Look at MUI3.8 if you have not pimped it up or on Gadtools. They look way worse.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

Wow, quite impressive what you have cooked up, my friend...

I noticed an "unamigaish" menubar on top of the window, what's up with that?

Any idea, when NTUI will get released?

@Wanderer

Quote:

The NTUI API itself hides the OS, similiar to OpenGL or SDL. One of the very view structures that are exposed is the RastPort, as this is mandatory for CustomView.

Hmm... so it is not possible take an existing widget and modify it? And if one creates a custom widget is it possible change its parameters using ntui_SetAttrs() call?

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@BigBentheAussie

Quote:

edit: Later in thread the discussion mentioned Linux, Windows, Mac etc. support. I am for the creation of an API that can support platforms outside of Amiga&alike platforms as well. Que common rant.

For the time being I'll be sticking to Linux on my laptop - AROS is not mature enough yet for my usage -, so depending on how much work it might be I might be tempted to look at a Linux port once Wanderer releases the source..

The easiest would probably be a port to Cairo, as Cairo is used quite extensively for GUI rendering on Linux these days and is quite flexible. It also has the benefit that it also works on WIndows and OS X, and has experimental support for BeOS, OS/2 and a few others.

Makes me wonder what the overhead would be of using Cairo as the rendering API for custom widgets as well - then user code could be a lot more portable.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@itix

> Hmm... so it is not possible take an existing widget and modify it?
Why one would possibly want to modify an existing widget?
What do you mean by modify?

Of course you can change the look and some aspects of behaviour by SetAttr/GetAttr.

About custom widgets:

There are two possiblities to do a custom widget:

1. You write your own widget. This would be an Amiga Shared Library implementing various functions such as
ntui_Init();
ntui_DeInit();
ntui_Layout();
ntui_UpdateMinSize();
ntui_HandleEvent();
ntui_Draw();
ntui_GetAttr();
ntui_SetAttr();

I don't recommend this for highly specialized widgets such as the HD-Rec Notator.
This should only be used for widgets that are re-usable for other developers too. It is also more complicated since you need to implement all those functions and make a shared library.

2. You use a CustomView.
A CustomView is a NTUI Widget that is not doing anything apart from being there and sending MouseMove/Click/KeyPress/IntuiTick/Refresh messages if you operate it.
So you actually implement whats going on in the widget in your main application context. This is very helpful because those widget usually need to access a lot of data from the application. Eg. the HD-Rec notator must read the MIDI data from HD-Rec and display/manipulate it. This would not be easy if done in a seperate module.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@vidarh

NTUI is not demanding. If you can draw lines, boxes and pixels that is enough.
AlphaBlitting and image stretching is done within NTUI code. To get images to the screen, something like Read/WritePixelArray is needed.

What else needs to be ported is the Code where the Events are fetched from the OS.
On AmigaOS there are three functions that would be replaced entirly by Windows/Linux/MacOS specific code:

ntui_AmigaCollectIDCMPEvents();
ntui_AmigaCollectScreenNotifyEvents();
ntui_AmigaCollectAREXXEvents();
ntui_AmigaCollectAppEvents();


Those "Collect" functions produce NTUI Events. After they are called, everything is OS independent.

You would need to write something like:


ntui_LinuxCollectWindowEvents();
...

Depends what Events are possibly there on Linux.

Plus of course, the open/closing of windows and OS specific things like making an icon for the Workbench (Amiga) or Trayicon (Windows).

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

> I noticed an "unamigaish" menubar on top of the window, what's up with that?
NTUI has a widget called MenuItem. You can place it wherever you want.
it canbe used for Pop-Up Menus, but also for Window Menus.
If you place it into a TitleMenuGroup, it appears on the screentitle OR as the first line in a window, depending on the User Preferences.
This is actually something that needs to be considered when porting other GUI Toolkits too. Do you want to have an App under AmigaOS that just looks like the same App under Windows? Or do you want to preserve the Amiga Look and Feel?

Just because Windows/Linux/MacOS/AmigaOS share the same idea of having windows doesn't mean they have the same features when you look at details. Windows Users would surly be confused if a menu pops up at the screen title (which doesnt even exist).

Last edited by Wanderer on 05-Mar-2010 at 10:38 AM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@Wanderer

Quote:

Why one would possibly want to modify an existing widget? What do you mean by modify?

To add new features to existing widgets. For example in MUI a Text.mui class supports only 8bit encodings. When I needed UTF-8 support I subclassed Text.mui class and overloaded MUIM_Draw method to print UTF-8 using ttengine.library. Now I have got two widgets, the original Text.mui and my modified one, and I dont have to change rest of my code to support new widget.

Another example is slider widget. I needed custom background to display metrics for a slider. So I overloaded background rendering method to draw my own background on top of the original background.

Subclassing is neat even when it is just Basic Object Oriented Programming System for Intuition.

Quote:

A CustomView is a NTUI Widget that is not doing anything apart from being there and sending MouseMove/Click/KeyPress/IntuiTick/Refresh messages if you operate it.

What if I need other IDCMP events like IDCMP_DISKINSERTED? Rarely needed but needed for file managers. And what format KeyPress is using? In MorphOS 2 it is possible get Unicode from IntuiMessages. Rarely needed but MorphOS port of Netsurf is using it. In Windows everything is in UTF-16 of course... lot of minor details to take into account.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook