跳转到内容

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) 
华夏公益教科书