I really wanted to start this by pointing out that Ambient has been stuck at 1.45 for about 20 years, only to find out that it has been upped to 1.47 at some point..... well duh....

Ignoring the version number (which I do think should ge to 2.0 if not equal the MorphOS version it comes with) here are some thoughts about it's future. Some of this may never be done, other parts only as optional 3rd party effords and some may be decided to be bad ideas from the start.....

I am leaving Panel features out of this as there is an extra thread for it already.

- D&D/AppWindow
MUI D&D only works within one app while the existing AppWindow API won't give any feedback on objects being dragged over such a window.
Current (hacky) solution for Panels is setting the userdata to a fixed value and than adding code in Ambient that generate special messages your dragging something over such a window instead of just changing the mousepointer.
Future solution: AddAppWindow() does have a taglist argument that AFAIK isn't yet used anywhere, so defining WBAPPWINDOW_MouseReport and AMCLASS_MOUSEMOVE/AMCLASS_MOUSENTER/AMCLASS_MOUSLEAVE (+AMCLASS_DROP maybe) should do that trick in a proper way.

- Prefs and prefs files
Atm I do have a "panel2.library" in PanelApp that mostly deals with those for the panels, but it might be a good idea to move that into a "Ambient.library" or "prefs.library" giving access to all such files
PanelPrefs has been moved to an mcc like extenal class that will eventually be called from Ambinet (hence the need for handling prefs file via a library) all other pref-panes could also be made into such classes. Would lead to a slight reduction in binary size and memory consumption (when prefs are not used) with no real changes otherwise.

- Listers
These could also get some support for 3rd party extensions/subclasses. Tabbed? With a listtree on the side? Coverflow?

- Search
Make that a proper lister, so you can D&D files out it

One thing that I miss the most from other OS is the last used files thingy that let you quickly access previsouly used files.

Sadly, this probably need that ASL be tweaked to implement some kind of 'recently used files'.

This could probably be implemented as a virtual file system that would just keep track of recently opened/saved file thru ASL (and ambient, and whatever that would use this new API).

Not strictly related to Ambient but well, file related at least ^^

Well you would need a plugin monitoring your movements in Ambient and then an API call to build a fake directory.

Exactly the kind of stuff that should be 3rd party but also pretty much the stuff that would need some groundwork in Ambient.

- Listers: whoverer implements (at least) the above, will be my hero :)

Seriously, I mentioned in the past here that file management / navigation needs an overhaul but feedback wasn't overwhelming :/ Bookmarks (permanent or temporary) isn't an intuisive solution imho. Ultimately, managing thousands of files and hundreds of drawers needs too many clicks and I usually end up with many listers spawing around my Ambient screen. Tree view + Tabs + Split window would solve this issue. - basically just copy the layout of modern DOpus.

1. A sidebar with the most important paths/partitions and quicklinks would be nice.

2. "Shift + /" in an active window will show up a string. It would be nice if this string could be integrated into the normal view or at least combine it with the already present path buttons (f.e. middle mouse click on the button will switch to string view). Or put an extra button next to it (as in Ubuntu/Unity).

3. Network filesystem integration of SMB, NFS and FTP. SMB is already possible, but only accessible through networks icon on the ambient desktop. There should be a "Connect to Server..." option in the sidebar.

4. Prefs for network shares. Right now only accessible through right click on the share icon

5. Creating shares with right click on folder/partition (SMB, NFS and FTP)

6. zoom out and sort all windows on the screen (as in macos) by pressing a hotkey. window should be selectable

7. Listermode with "Source" and "Destination" label as in Dopus Magellan

8. Merge System prefs and Ambient prefs into one Prefs Windows.

9. Have one systemwide MUI prefs (Ambient + apps). Individual application based MUI prefs should only be accessible from the application itself.

10. This is an old feature request, but i'd love to have screen dragging with D&D possibility

[ Edited by Cego 27.08.2024 - 15:57 ]

Quote:

Ambient menu > View > Connect. Already there.

Quote:

Not an Ambient thing, but yes, it's somewhere on the todo.

Quote:

MorphOS would have to ship servers for those first.

Quote:

Nothing to do with Ambient. On the todo, though.

Quote:

Um, why? That only makes sense if you only have 2 listers so that there's a clear source and destination context.

Quote:

A definite no-no. But you can try and create an Ambient.mprefs if you want to.

Quote:

Not sure what you mean. Individual application MUI prefs are only accessible from the applications themselves.

Quote:

Not an Ambient thing and still a no.

Quote:

I'd say this would need some sort of a 'open document' concept in MUI. You wouldn't want just any file opened via ASL to show up on that list. And you would want things that aren't opened via ASL to show up on it too. On macOS this is centralized into a single db, which makes sense, imo.

Quote:

exactly. Thats what i meant. Two listers with source and destination marking.

Quote:

Nope. Wrong adress :)

Quote:

There are two MUI prefs in the Ambient -> Settings menu. "Ambient MUI..." and "MUI..."
My point is, there are too many individual prefs and even as an experienced user i tend to forget where to look for the right settings sometimes. For the sake of better usability and handling i would prefer one prefs programm to access all configuration options of the operating system.


[ Edited by Cego 27.08.2024 - 18:17 ]

>> Listermode with "Source" and "Destination" label as in Dopus Magellan

> Um, why? That only makes sense if you only have 2 listers so that there's
> a clear source and destination context

DOpus Magellan introduced the ability to have more than 2 listers, and kept the need to define source and destination lister at that. After all, if one lister is the source, which of the other two is the destination otherwise? Note that this was essentially pre-copy-via-d&d days (most DOpus users used d&d for dearchiving archive files, not for copying them).

Some ideas:

- The ability to launch several sessionss of Ambient.
- A research tool which also search by date (from, after, inbetween...) and by size (more, less, inbetween...).
- The ability, in the research result list, to select several files at once (like Ambient listers).
- The ability, in the research result list, to delete and rename the selected files.

[ Edited by Daff 28.08.2024 - 08:50 ]

Quote:

I don't really see the point in this as it would be confusing both for the user and Ambient itself.
So maybe tell us what you want to achieve and we could discuss wether that is possible in 1 Ambient

Quote:

All this should work with search being subclassed from a normal lister (as suggested in my 1st post)

Quote:
Actually, I think it's the opposite. In the traditional 2-list filemanager it's quite clear which lister is source and which destination (destination is always the one you're not working on currently). In DOpus5 it became a necessity to have user markable source and destination listers, because there can be more than two listers. Users can have, for example, ten listers open, and then mark which is the source and which are destination(s). You can even copy from one source to several destinations in one go by locking several destinations.

Ambient doesn't offer a way to copy files like DOpus (maybe it should?), but marking listers as source and destination could give some other possibilities. For example, in my Magellan2 configuration I have an action to compare source and destination lister contents recursively with MirrorCheck, but I can't configure Ambient like that... there's no way to get information which listers should be compared because users can't mark them in any way. I have many custom options in Magellan2 that take source and destination lister paths to process files with external shell commands. Makes it much easier than trying to remember and type everything manually in the Shell.


And to the original question, at least some Ambient 2.0 wishes:

1) A "Custom" button for the Ambient toolbar. You could edit its action just like you already can edit custom hotkeys and mimetypes. Freely selectable image file for it.

2) A "Sub Toolbar" button for the Ambient toolbar. Just like the "Sub Panel" button in the Panels already. You could dump some rarely used toolbar buttons there and avoid too wide Ambient windows.

3) Fix multiple actions support for custom hotkeys.

Hmm.. I had something else in my mind just a minute ago, but forgot it :)

Never really cared much about DOpus and even less about Magellan. Had it installed for a short time when the key got available (was it on some old Aminet CD??) and found it confusing (which kinda goes hand in hand with every powerful tool).

Having dedicated source and destination windows sounds weird and would complicate break many things that work just fine for most users.

A dual lister window that is kinda both an Ambient view and a DOpus(4) clone as a 3rd party class seems plausible.

Quote:

Having one prefs program for all apps is already there: it’s the MUI global settings. If you wanted to have all MUI apps listed there, that’d require a standardized way of installing and registering all MUI apps in the OS, which is not feasible - as apps would have to be updated for that - and I don’t believe would be appreciated by most users. My advice? Stick to global settings if per-application ones are confusing.

About Ambient Copy, i copy many files on a new partition and i have a requester show:

Destination 'xxxxxxxxxxxxxxxxxx' is a directory.

And i have only 'Ok', the problem i have many many requesters like this during the copy

It will be fine if we have a 'Ok for all' for this requester.

Quote:
It's not that it would affect to drag&drop and anything already existing. You still can d&d in any lister in DOpus too, but the src/dst concept affects only when you trigger an action by other means (button, menu, keyboard shortcut, popup...). But yeah, I don't know if it could be implemented in a sensible way to Ambient, but for sure it would open a whole new world of possibilities especially if we'd have user configurable buttons, but it could already be used with mimetype configurations.

Actually, Ambient already has the source/destination mechanism implemented in some level. Look at the Ambient's Action Editor (in MimeTypes, for example) and there you can see "Change working directory to source" and "Change working directory to destination", and in the command string you have placeholders for "Source view path", "Source view identifier", and the same for destinations too.

This is just like in DOpus already, the only thing missing is that listers would be marked as Source/Destination for using the same concept for non-drag&drop stuff. To go a bit more into the details, DOpus sets the source/destination automatically so that the currently active lister becomes the source and the previously active lister is set to destination, it works well and in practise you don't have to set these manually ever in normal use. In certain exceptions you can also force other setups. But basically it isn't even necessary to have user selectable src/dst (with a cycle gadget or so), but it would be enough just to indicate the lister state somehow (even with some S and D letters somewhere) and set the state from current and previously active listers automatically.

About Ambient listers, maybe see the source code of Magellan to have similar listers in Ambient (configurable buttons, source - destination window).

Quote:
I don't think it helps, because different programs, different design, different mess. But configurable buttons and src/dst in listers should be quite trivial to add, because basically it all is there already.

Action editor is already in use for mimetypes and keyboard shortcuts and can be recycled for configurable buttons as well, and the src/dst is already used in drag&drop, so just extend it a bit to get that information brought from other actions too.

The most important thing I miss in Ambient is a smart source/destination handling.

For example if your drag a file from A to B and then a second one from A to B. In that case ambient should wait for the first operation to finish and stack up the copy operation like a print server. Maybe with "play/pause/abort" buttons to force start, stop and pause them.

Cinnamon on LinuxMint does this very well, but it could be improved. E.g. when C and D are complete different drives they may start parallel and if there is A->B and A->C and A is a locale SSD it could also launch if the bandwidth is not a problem. E.G an USB SSD should never be prioritized and used by multiple copy processes, but an internal could handle that. Same for a network storage.

Also a smart delete option. If the user wants to delete a file it can be deleted right way UNLESS it is stacked within the copy process file. In that case the deletion can be piled as well, to be performed when the copy process is done. I often forget to delete crap. Sure I can use Cut and Paste, but if a copy process already is half way through, you don't want to interrupt just to change the copy mode. Also you may just want to delete 1 source file, but the stacked copy process includes 10 files.

So the user can drag and drop like mad and the system is optimizing the copy process without causing a physical hard drive to drive crazy or multiple copy processes eat up all time due to limited bandwidth or drive head movements.

Just my 50 cents of Ambient wishful thinking.

Do you have shit in the head or why does your brain fart?

Quote:

Bookmarks are ok for some initial frequently used paths, but I would like to see some improvement to the Directory History popup (RMB over the parent button). Currently it doesn't cache all directories I've visited, and there are some duplicate entries (at least root dir). But it would be handy if it'd work a bit better...

An idea about Source/Destination windows.

This feature will be nice i think:

If you move an Ambient lister on another Ambient lister, the two Ambient lister are "attached" and the second window take the same Width and Height of the Ambient lister moved. The selected window is the source and the other the destination