跳轉到內容

Aros/開發者/文件/庫/工作臺

來自華夏公益教科書
導航欄,用於 Aros 華夏公益教科書
Aros 使用者
Aros 使用者文件
Aros 使用者常見問題解答
Aros 使用者應用程式
Aros 使用者 DOS Shell
Aros/使用者/AmigaLegacy
Aros 開發者文件
Aros 開發者文件
從 AmigaOS/SDL 移植軟體
Zune 初學者
Zune .MUI 類
SDL 初學者
Aros 開發者構建系統
特定平臺
Aros x86 完整系統 HCL
Aros x86 音訊/影片支援
Aros x86 網路支援
Aros 英特爾 AMD x86 安裝
Aros 儲存支援 IDE SATA 等
Aros Poseidon USB 支援
x86-64 支援
摩托羅拉 68k Amiga 支援
Linux 和 FreeBSD 支援
Windows Mingw 和 MacOSX 支援
Android 支援
Arm 覆盆子派支援
PPC Power Architecture
雜項
Aros 公共許可證

AOS3 圖示資訊有一個優先順序調整器。想知道優先順序是如何儲存在圖示中的。這些優先順序調整器是 RAWBInfo 的功能。workbench.lib 自己的資訊視窗將把它們顯示為工具型別。正常的“優先順序”設定對應於 TOOLPRI 工具型別,該型別對映到 workbench.library 中 CreateNewProc() 的 NP_Priority 標籤。對於 SYS:WBStartup 中的自動啟動應用程式,RAWBInfo 將顯示啟動序列優先順序 (STARTPRI=<-128..+127>) 和應用程式終止等待的可選延遲 (WAIT=<秒>,秒==0 表示“不要等待”) 的兩個附加元素。所有工具型別預設值為零。

請不要忘記在新增/更改鍵對映名稱時更改檔案“workbench/prefs/input/prefs.c”中的陣列“layout_expansion_table”。

SetFunction

[編輯 | 編輯原始碼]

有人指出,workbench.library 可能可以透過合併 Workbook 和 workbench.library 來更好地實現。Wanderer 將使用它需要覆蓋的例程進行 Exec/SetFunction,而不是使用我們目前擁有的相當有限的訊息傳遞機制。

如果沒有異議,我想透過合併 Workbook 和 workbench.library 以及更新 Wanderer 來實現 SetFunction workbench.library 的必要部分來實現這一點。嗯,這與 AROS 實現的 workbench.library(旨在與“客戶端”無關)的理念背道而馳——但是我已經在我的程式碼中本地使用 SetFunction 了。這意味著我必須重新編寫我的 AppIcon/Menu 程式碼。過去,人們一直在談論 workbench.library 中某種型別的註冊 API。這樣,任何像 Workbook、Wanderer、ScaleOS 這樣的工作臺實現都可以註冊,以便在呼叫 workbench.library 函式時獲得所需的資訊。這樣,也可以同時註冊多個工作臺實現。

我有一個關於 AppIcon 介面的問題。

目前互動看起來像這樣

應用程式 <--A-> workbench.library <-B-> “工作臺替換”

應用程式和 workbench.library 之間的介面 (A) 是公開的,從 2.0 版開始定義。另一方面,我無法找到有關 workbench.library 和“工作臺替換” (B) 之間介面的任何資訊。我檢查了 Amiga Developer CD 2.1 RKMS、AmigaOS 4 SDK 和 MorphOS SDK。

有人知道 Amiga 類作業系統之間是否存在關於此介面的任何標準化嗎?

有人知道經典 Amiga 上的“工作臺替換”應用程式是如何做到的嗎?他們是否提供了自己的 workbench.library 替換/函式補丁?這是正常行為。AROS 的 workbench.library 更像是特例,並且“試圖”保持通用性。通常,工作臺替換需要實現自己的 workbench.library,或者修補原始庫中的函式。

此外,過去是否有過設計和計劃來為 (B) 實現 AROS 特定介面?我檢查了我們的 workbench.library,它有一些 AROS 特定的函式,但這種支援看起來像是進行中的工作,而不是完成/凍結的 API。

這也是你想要將 Scalos 移植到 AROS 的方法嗎?在我看來,每個“工作臺替換”都必須以這種方式攜帶一定量的重複程式碼——例如註冊 appicon 以及與它們的通訊。我想知道是否不應該重新設計當前的 AROS 擴充套件函式,以允許從“工作臺替換”透過 workbench.library 嚮應用程式傳送訊息——API 中已經有一個這樣的函式——SendAppWindowMessage

替代方案

[編輯 | 編輯原始碼]

建立新的 Wanderer 檔案瀏覽器,可能需要使其更加模組化,其中包含一個抽象層,允許在其中顯示不同型別的專案。例如:可以在外掛格式中實現面向物件的圖形程式語言,以建立 AmigaVision 風格的指令碼引擎。由於它是完全圖形化的,並且使用目錄結構的類比,它將吸引許多人進入高階程式設計領域,以貢獻程式碼。

這不是第一次提出這個想法。之前在 AROS-Exec 上討論過一次。

想要讓瀏覽器的方面有點像目錄結構和其他層次資料格式的資料型別。(XML,有人嗎?)也許我們甚至可以將新的 Wanderer 打造成 Multiview 和 Workbench 合二為一的程式。當然,這應該是比 ABI 1.0 更長期的目標,因此它將成為 AROS 2.0 的一個值得的目標。

對於長期的解決方案,我建議對 workbench.library 和 icon.library 進行 AROS 擴充套件,多個應用程式可以註冊、使用並獲得通知。如果我沒記錯的話,workbench.library 中應該已經有了這個功能,或者基礎應該已經可以使用。請參閱 RegisterWorkbench()/UnregisterWorkbench();appicon 支援似乎不可用。應用程式開發人員應該能夠在自己的螢幕上為使用者提供類似工作臺的體驗(例如,開啟一個抽屜並顯示只有 PNG 檔案的圖示,然後讓使用者將其拖放到他們正在處理的文件上),以及允許系統範圍內的工作臺功能在多個公共螢幕上執行,或者讓使用者自由地同時執行多個“工作臺”程式,以決定他們最喜歡哪個,如果他們願意。

Commodore 的 AppMenu、AppIcon、AppWindow 示例可在 Aminet 檔案中找到 http://aminet.net/dev/misc/AmigaMail.lha

解壓縮下載的 lha 檔案中的 lzh 檔案,然後檢視 am_Jul91/AppWorkbench 目錄。

雖然總的來說贊成以通用的方式實現事物——但在開發 Wanderer 的過程中,我得出結論,這樣做毫無意義/過分。

  • 它很可能只會由 Wanderer(也許還有 workbook)完全使用。讓現有工作臺替換重新構建其內部以能夠使用這些特定擴充套件沒有意義。
  • 這意味著將 Wanderer 回溯移植到 amigaos/其他系統也需要特殊的 workbench.library。
  • 它已經有一些硬編碼的 Wanderer 特定和 workbook 特定更改。在我看來,更容易在補丁函式中維護這些更改。
  • 現有的函式只公開 appicon/menu 物件本身,因此“處理程式”無法與應用程式本身進行通訊,需要發明更多 AROS 特定函式。即使是已實現的程式碼也不完整(它缺乏告知處理程式新增新物件的的能力,例如)。在我看來,更容易維護這些東西的處理程式特定實現(因為它與所討論的處理程式的工作方式密切相關)。
  • WorkbenchControlA 將如何執行也未定義。

... + 其他一些原因。

struct AppIcon * AddAppIcon( ULONG id, ULONG userdata, STRPTR text, struct MsgPort * msgport, BPTR lock, struct DiskObject * diskobj, Tag tag1, ... ) __stackparm;

struct AppMenuItem * AddAppMenuItem( ULONG id, ULONG userdata, STRPTR text, struct MsgPort * msgport, Tag tag1, ... ) __stackparm;

struct AppWindow * AddAppWindow( ULONG id, ULONG userdata, struct Window * window, struct MsgPort * msgport, Tag tag1, ... ) __stackparm;

struct AppWindowDropZone * AddAppWindowDropZone( struct AppWindow * aw, ULONG id, ULONG userdata, Tag tag1, ... ) __stackparm;

BOOL CloseWorkbenchObject( STRPTR name, Tag tag1, ... ) __stackparm;

BOOL MakeWorkbenchObjectVisible( STRPTR name, Tag tag1, ... ) __stackparm;

BOOL OpenWorkbenchObject( STRPTR name, Tag tag1, ... ) __stackparm;

BOOL WorkbenchControl( STRPTR name, Tag tag1, ... ) __stackparm;
struct AppWindow *AddAppWindowA(ULONG id, ULONG userdata, struct Window *window, struct MsgPort *msgport, struct TagItem *taglist) 
BOOL RemoveAppWindow(struct AppWindow *appWindow)

struct AppIcon *AddAppIconA(ULONG id, ULONG userdata, char *text, struct MsgPort *msgport, BPTR lock, struct DiskObject *diskobj, struct TagItem *taglist) 
BOOL RemoveAppIcon(struct AppIcon *appIcon)

struct AppMenuItem *AddAppMenuItemA(ULONG id, ULONG userdata, APTR text, struct MsgPort *msgport, struct TagItem *taglist) 
BOOL RemoveAppMenuItem(struct AppMenuItem *appMenuItem)

BOOL WBInfo(BPTR lock, CONST_STRPTR name, struct Screen *screen) 
BOOL OpenWorkbenchObjectA(STRPTR name, struct TagItem *tags) 
BOOL CloseWorkbenchObjectA(STRPTR name, struct TagItem *tags) 
BOOL WorkbenchControlA(STRPTR name, struct TagItem *tags)

struct AppWindowDropZone *AddAppWindowDropZoneA(struct AppWindow *aw, ULONG id, ULONG userdata, struct TagItem *tags) 
BOOL RemoveAppWindowDropZone(struct AppWindow *aw, struct AppWindowDropZone *dropZone)

BOOL ChangeWorkbenchSelectionA(STRPTR name, struct Hook *hook, struct TagItem *tags) 
BOOL MakeWorkbenchObjectVisibleA(STRPTR name, struct TagItem *tags) 
BOOL RegisterWorkbench(struct MsgPort *messageport) 
BOOL UnregisterWorkbench(struct MsgPort *messageport) 
BOOL UpdateWorkbenchObjectA(STRPTR name, LONG type, struct TagItem *tags)

BOOL SendAppWindowMessage(struct Window * win, ULONG numfiles, char ** files, UWORD class, WORD mousex, WORD mousey, ULONG seconds, ULONG micros) 
struct DiskObject *GetNextAppIcon(struct DiskObject *lastdiskobj, char* text) 
華夏公益教科書