Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 152463 times)

Description:

0 Members and 8 Guests are viewing this topic.

Offline asymetrix

  • Full Member
  • ***
  • Join Date: May 2007
  • Posts: 118
    • Show all replies
Re: Os 3.2 development preview
« on: September 21, 2019, 03:00:21 AM »

Even TODAY there are angry theme makers for other platforms because they cannot keep a compatible and easy system for people who enjoy making themes.

Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
History *could* be a cli version of installer - simulate/test/undo/redo commands, then comit changes.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.

virtual-path = URI
One could have virtual paths EG Workbench:virtual-path\test


Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.

The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries

At times I select a file and hit DEL expecting it to just delete. lol.

Unique ideas make for interesting and exciting times.
 

Offline asymetrix

  • Full Member
  • ***
  • Join Date: May 2007
  • Posts: 118
    • Show all replies
Re: Os 3.2 development preview
« Reply #1 on: December 04, 2019, 03:23:51 PM »

@Thomas Richter

Quote
Anyhow, developers have now freedom: Either choose the simple gadtools "fixed width fonts raster based" gadtools layout, or the flexible reaction "layout.class" engine.

Would be nice to have developers have less work to do with similar apis.
This way One may just use GUI.Layout = GADTOOLS

One day the system could detect low resource and allow a user to switch layout in realtime.
Devs always reinvent the wheel, we must endeavour to do the work once, and allow APIs to make changes + add features.

Devs should only see and use generic UI components, the UI engine(s) should be detachable in case someone want to develop a different UI, with pre associated automation/script and shortcut assignments made default.

One day we might get templates eg UI.paint or UI.wordprocess etc

Maybe even attach Client/server comms like in windows inter apps communications protocols.