Motosu v0.9-beta released (new application)

[GokMasE]

In the very last hour of the very last day of the year, the time has come to share some news on a GEM utility that I have been tinkering with:

Motosu is a taskbar written for Atari GEM and it was initially started as a proof of concept to allow an older project of mine to display application data on screen. It has since snowballed into a project of its own and while it is still in beta I strongly feel that the time has come to introduce it to a wider audience to allow for a larger base of testers.

20231230_screenshot32bit_texture_tn.png

The program sets out to offer things you'd expect, like maintaining a list of running processes and hosting a start menu as well as acting DHST-server. Having said that, I must also stress that this is a first public beta and Motosu is not to be considered feature complete at this stage. Amongst the things you are likely to miss is the ability to configure icon associations within the GUI.
(It can be done by hacking the config file, but the format of that is perhaps not instantly obvious.)

While that is indeed a missing feature, there is quite a lot you can do to tweak the visual experience. From the very early days my mind has been set to supply a bit of a "hands on" approach to how the TAB components can be tweaked visually. You can ALT+click a TAB to change its folding state and SHIFT+click/hold a TAB to move it. To me however, the most imptactful feature when it comes to everyday use is the ability to anchor tabs - other systems would refer to it as "pin to taskbar" I guess.

There, I will leave it at that. If you like, download it and play around with it and let me know what you think.


I have prepared a basic website with some additional information at this URL:

http://motosu.gokmase.com


Happy new year!

/Joakim

[Mikerochip]

It looks great!!

[Cyprian]

looks cool

[ragnar76]

Cool! Looks great!

[marss]

Looks great

[jfl]

Great to see something new from you, Gok! I'm definitely trying this one out as soon as I get some time. And happy new year to all, by the way.

[stormy]

Very cool!!!

[ldv-01]

Great ! Is the name from the Motosu lake (near Mount Fuji) ?

[cb]

Excellent tool! For Taskbar users who want to have a look at it without losing their menu, just copy Motosu.prg and the 2 resource files in Taskbar folder (where index.grp should be) and start Motosu from there.

A little issue I have is that I use unusual characters in my Taskbar menu, they are not displayed correctly in Motosu as you will see on the screenshots I attached.

[wongck]

great !!! nice program for my CT63.
keep up the good work.

[GokMasE]

Hiya,

Thanks so much for the kind words on the beta so far. Many nice, positive remarks so cheers for that!
I am certainly thrilled by the thought of the program being liked and put to some use

Great ! Is the name from the Motosu lake (near Mount Fuji) ?

That is correct. I found it an appealing reference when trying to settle a name for the application
(Although probably not entirely obvious, the icon on top of the website is intended as a discrete nod to that reference)

Excellent tool! For Taskbar users who want to have a look at it without losing their menu, just copy Motosu.prg and the 2 resource files in Taskbar folder (where index.grp should be) and start Motosu from there.

A little issue I have is that I use unusual characters in my Taskbar menu, they are not displayed correctly in Motosu as you will see on the screenshots I attached.

Noted, thanks for reporting it.
I will have a look at trying to reproduce and hopefully fix that.

There are already some other minor issues regarding both start menu (separators not handled correctly, and possible UPPER/lower mixup) and some other non-fatal problems reported on Discord. I hope to be able to look into those (and any issues that may be reported in near future) and get back with an updated beta before too long.

I really appreciate both general and specific feedback, it will for sure allow me to polish off some of the roughness that is still lingering
Regards,

/Joakim

http://motosu.gokmase.com

[shoggoth]

Definitely a huge enhancement for a modern Atari desktop experience. Hats off and a big thanks to GokMasE for this one.

[ragnar76]

Havent tried it yet, will it run an a firebee or will be there a native Port?

[GokMasE]

Havent tried it yet, will it run an a firebee or will be there a native Port?

Chances are there will be a binary compiled specifically for Coldfire, I will get back on that topic as soon as I have news for you.

[ragnar76]

Cool! I wait

[robv]

Nice! Love to see new stuff like this emerging.

[cb]

For those who want to change default icons from the settings file, open your $HOME/Motosu/motosu.inf file in a text editor, you can change many settings from there, apps that where running when the settings were saved are displayed near the end of the file, like:

Code: Select all

proc_setting		|ST-GUIDE,249,39,0

This means ST-Guide is displayed with icon 248 in 'big' mode, icon 38 in 'tiny' mode, the last number is the hidden/visible flag (0= visible, 1=hidden).
It's easy to figure out icon numbers by opening tb_icons.rsc in Resource Master but remember the icon number in motosu.inf is the one displayed in Resource Master +1.

Program names are the standard XaAES 'nice' names, they must be 8 characters long (no file extension needed, spaces allowed), like this for Olga:

Code: Select all

proc_setting		|OLGA    ,246,247,1

Which I have of course hidden.

You can even mix big icons in tiny mode (but it will obviously look bad) and vice versa.

[joska]

Looks good! I'm not using Thing! so I'm unable to test the "transparent" background. I actually experimented with this in Taskbar some 20 years ago, but ended up abandoning it because at that time it was not possible to get rid of the window border (was using N.AES). I did it slightly differently from you, instead of loading a texture I made sure that the background was clean (temporarily hide all apps) before the Taskbar window was opened the first time and then copied the window background. Maybe this is something you should consider, as it would be compatible with all wallpaper solutions including the one built-in to XaAES.

I would also be interested in hearing more about the $TAPIRSERVER functionality. IIRC something like this was discussed some 25 years ago - and I believe you were one of the participants It never materialized though.

Btw you have inspired me to continue my work on Taskbar. I have 10+ years of unreleased changes, some quite significant. But as usual most of it is unfinished.

[GokMasE]

Looks good! I'm not using Thing! so I'm unable to test the "transparent" background. I actually experimented with this in Taskbar some 20 years ago, but ended up abandoning it because at that time it was not possible to get rid of the window border (was using N.AES). I did it slightly differently from you, instead of loading a texture I made sure that the background was clean (temporarily hide all apps) before the Taskbar window was opened the first time and then copied the window background. Maybe this is something you should consider, as it would be compatible with all wallpaper solutions including the one built-in to XaAES.

Thanks! The "background grabbing" is a clever idea as well. It might well be something to explore further down the line. Since the code that creates the texture cache is a separate module, it would be possible to play around with ideas at least. Within a shorter timeframe I might however look into a way to define a background image without having to use Thing desktop explicitly.

I would also be interested in hearing more about the $TAPIRSERVER functionality. IIRC something like this was discussed some 25 years ago - and I believe you were one of the participants It never materialized though.

Yes, I fully intend to share full details on this. A very, very rough explanation of the current implementation:

A client to $TAPIRSERVER starts by registering as client, obtaining a session-id.
When a session-id has been received, a client can:

• Display a custom icon for its TAB in Motosu (Icons referenced by path to RSC-file)
• Install a custom menu (will show up in the client TAB, under /menu. Menu events will be forwarded to client)
• Change its visibility and folding status in Motosu
• Create one or more tray objects (every created object is referenced by an object-id)
• Update a tray object (icon index, text strings, level/meter)
• Delete a tray object
• Delete/end session

A tray object is more or less a small "display panel"
Visually it offers:

• 1 icon (referenced by path to RSC-file)
• 2 text objects (which can optionally display a leve/meter in background. See "RAMses", included in distribution archive.)

The tray object can be right clicked. This opens a popup menu where the bottom alternatives are generic, but user can add his own alternatives to the top. Menu events will be forwarded to client.
The tray object can be left clicked. This sends a msg to the client/"parent app", that user has asked for its services. The client then typically responds by opening a GEM dialog (modal or windowed) that offers a functionality/setting of some kind. The client informs the server when the task has been finished.

This is how the scheme is laid out so far, sort of fulfilling the original ideas and needs I had for my own program projects.
In short, I guess what I aimed for was a display area + a simple "remote access" link to the owner of the display. While the concept could certainly be extended to offer custom types of Tray objects with other visual references in the future, I really needed to scale it down to the core essentials in order to ensure I could actually get any results.

The aim right now is to clean up and share some example code and write some more detailed docuementation on the API for it. If it will appeal to someone, I would be thrilled. If I end up being the only one using it, it has still served my original purpose

Btw you have inspired me to continue my work on Taskbar. I have 10+ years of unreleased changes, some quite significant. But as usual most of it is unfinished.

That is really cool, glad to hear that! - you have certainly inspired me with your work


Regards,

/Joakim

[GokMasE]

Cool! I wait

After the release of GBE3.74 I now am able to compile binaries that runs on Coldfire/V4E too.
First tests seems to suggest Motosu runs OK on Firebee. Nice!

There are a few remaining issues to solve from the list of reported bugs after the initial beta release made on 2023-12-23, but once those are sorted I intend to upload a new beta.

Give me a day or two (or three)

[ragnar76]

No hurry! 68k runs fine too (so far, i just started it, played around with it and not have it used it heavily)

[joska]

A tray object is more or less a small "display panel"
Visually it offers:

• 1 icon (referenced by path to RSC-file)
• 2 text objects (which can optionally display a leve/meter in background. See "RAMses", included in distribution archive.)

Suggestion: Create a "redraw" protocol that allows other applications to draw in your window. It could be implemented like this:

Client wants to draw in the tray:

- Client sends a "want to draw in tray #id" message to the server.
- Server gets the rectangle list from the AES, intersects each rectangle with the tray rectangle and sends a "tray redraw" message to the client for each rectangle.

Server asks client to redraw it's tray(s)

- When the AES asks the server to redraw it's window, the server intersects each dirty rectangle with each of the client trays and sends tray redraw messages to the affected clients.

This will allow a client to draw anything in it's tray(s), and is not limited to the objects handled by the server itself.

[GokMasE]

A tray object is more or less a small "display panel"
Visually it offers:

• 1 icon (referenced by path to RSC-file)
• 2 text objects (which can optionally display a leve/meter in background. See "RAMses", included in distribution archive.)

Suggestion: Create a "redraw" protocol that allows other applications to draw in your window. It could be implemented like this:

Client wants to draw in the tray:

- Client sends a "want to draw in tray #id" message to the server.
- Server gets the rectangle list from the AES, intersects each rectangle with the tray rectangle and sends a "tray redraw" message to the client for each rectangle.

Server asks client to redraw it's tray(s)

- When the AES asks the server to redraw it's window, the server intersects each dirty rectangle with each of the client trays and sends tray redraw messages to the affected clients.

This will allow a client to draw anything in it's tray(s), and is not limited to the objects handled by the server itself.

Flexibility is good, and the idea is certainly not bad.

Stuff like this needs some pondering upon though. My first thought is that it could perhaps make sense to do something like this as an extended type of Tray object, for future revisions.
For the "API 1.0" draft however, this is pretty much the type of complexity I was seeking to avoid - lifting responsibility for redraws from the client was certainly intentional for the "standard/basic" Tray object.

For more basic user feedback, like something that a basic system utility would need, I think the current stuff will be sufficient in many cases.
But yes, I can understand that there are occasions when you want to have a (significantly) larger amount of freedom than what is currently up for offer.

I'll work on finalizing/stabilizing current implementation and then extended function could be looked into.

Regards,

/Joakim

[jvas]

An easier method would be if:
- client can regsiter icons, which is then stored by the taskbar internally with index (or short code specified by the client)
- client can set the index (or code) of the desired icon to be displayed on ther taskbar
- client can set the text that should be displayed on the taskbar

This way no client-server communication needed on redraw. Though not as cusomisable as Joska proposed. But keeps the taskbar look uniformised...

[GokMasE]

An easier method would be if:
- client can regsiter icons, which is then stored by the taskbar internally with index (or short code specified by the client)
- client can set the index (or code) of the desired icon to be displayed on ther taskbar
- client can set the text that should be displayed on the taskbar

That is (with one exception*) already possible in "draft v1.0" of the API. A client can indeed:

* set a custom icon for its own process tab
* set a custom icon for any Tray object it creates
* specify text to display in any Tray object it creates

Setting a custom icon works pretty much exactly like you seem to suggest - client registers/submits RSC-path, Motosu stores the icon(s) internally and offers the client to change to any of the icons by referring to icon by its index.

*) At this time, the text in the clients process tab can't be changed through the API, but it can be changed by setting a "fancy name" through a MENU_REGISTER call)

Bear with me as I try to finalize the current implementation, and let's take it from there