#feonix ccd

[likebluesky]

Feonix CCDで収録するフォントのリスト

デフォルトで収録されるであろうフォントリスト：

Takao明朝、Takaoゴシック（角ゴシック・丸ゴシック）

Takao Condenced：インターフェイス用、画面領域が狭くても表示可能、棒幅を保ちながら横幅収縮

Takao Cleartype：視覚認識しやすい、文字大が小さくても判別可能、密集を拡散し過疎を収縮

Takao Business（明朝・ゴシック）：ビジネス文書用で無機質な字体

Takao 行書体・楷書体・隷書体

青柳衡山フォント：書道フォント（これは要らないか）

あくあフォント：まる文字

OpenSans：エンジニアリング文書向け、ソリッドな英文フォント

Adobe SourceCode Pro（Monospace＝等幅）：ターミナル、ソースコード用

源ノ角ゴシック：Web用明文用フォント

（Maniackers Design：デザインフォント）

（梅フォント：昔のLinux向け、品質は悪いが必要だった）

英字フォントの収録基準はWindowsの収録を採用にする

有料でユーザーが購入判断のフォント：

ヒラギノフォント（商業雑誌向け、涼しげでモダン）

AXISフォント（ソリッドでクリアな感じ）

小塚明朝（味のある感じ、古風な感じ）

白舟書体のフォント：様々な日本語デザインフォント（桜花、鯨海酔侯、侍、京円など）

DF金文体：上質でリッチな感じ

DFP勘亭流：江戸風書体

HG創英角ゴシック：極太の角のゴシック体

ウェイトの数は多すぎなくて良い、使い分けに合わせていくらか用意すればいい＝Light、Boldくらい、Italicなどのバリエーションは揃える

[likebluesky]

Visualizer Top Development Theory (page3)

プロプライエタリ

結局のところJamられていれば改造はできないし自由に扱えないのでプロプライエタリには良い、ソースコードを取得すればいくらでも改造可能、モジュールになっていれば自由に再利用可能、自由な環境ではDRMは意味ない、鍵の購入は認証できるがキャプチャは防げない

GUIアプリケーションもいくらかは再設計できる、GUIのAPIを新しいインタフェースに連結させればいい、ウィジェット、ファイルダイアログ、連打、フォルダアクション、内部は改造できないが外部の連結は接続できるのでモジュールのようにWinやMacアプリケーションを扱える面もある

Feonix CCDは商用のライブラリも販売提供してもらえればプロの編集ユースにも耐えることになる、プロプライエタリなモジュールもAPIの情報が提供されていればシステムに組み込んで利用可能

アルゴリズム

抽象化というものは移植性や記述性やメンテナンス性を考えるなら常に必要、環境によっては最適化は行って良い

低レベルな書き方をするなら、抽象化されたレイヤーを意識して変換して記述すべき

仕組みや説明書は学んだほうが良いようだが、空としてのメリットとどう両立するのが最適か、使い方を学ばなくても使えるのが最善であり、その外側の詳細な使用法は学んだほうが良い

オブジェクト指向だとクラッシュに強くなる、動的に処理できるしホットプラグなども実装しやすくなるのだろう

Lightと同様に最終の確実な実装のみではなく代替的な実装も安定した実行には役立つのでこれも含んで開発する

ClearTypeのように文字のレンダリング部分だけ通常のベクトル描画系とは違う高速なレンダラを使えば高速・軽量に文字をレンダリングすることが可能なので、スペックの低いマシンでデスクトップの画面描画を行うときに向いている手法と思われる

インターフェイス・デザイン

オブジェクト指向が開発効率が良いが、手順使いのための環境ならインターフェイスはDiagramで作る、LXDEなど軽量な環境が要るなら手順の開発言語を使う

ただしObjectiveな操作環境にしたいならオブジェクト指向で作るべき、二種類作る

パッケージング

CCD Application PackagerはFeonix CCD Visualizerで開発したPlasmaおよびCCDアプリケーションを他の環境で実行可能にパッケージングできる、実行用のフレームワークとアーキテクチャを提供

CCD Application Packagerを利用すればVisualizerでWinのバイナリをApple OS Xや他のバージョンのWinなどで動作可能にパッケージング出来る、Wineが実体でそこからWinのバイナリを読み込み動作する、APIはライブラリとして実体から呼び出され、OSに適合するようにライブラリに依って動作する

ソフトウェアに署名って要らないんじゃないか、認証さえされていれば、でもサイト上で自由に頒布するなら有用か

ポート（移植）

LinuxプログラムをFeonix CCD Plasmaに移植したいならVisualizerでパスを書き換えるか、内包するLinuxシステム上に配置されたグルーコードから参照して、Feonix CCDのトンネルモジュールライブラリに通せばいい、システムを混ぜたくないなら仮想化ファイルシステム内に構築

XQuartz的な互換性的な手法を用いればもっと移植が容易、グラフィックサーバーとオーディオサーバーとファイルシステムさえトンネルすれば良い

ファイルシステムを仮想化して配置して、（システムの必要な一部を仮想化マシン内で実行し、）外のシステムと協調動作する

環境用の最適化は可能、作成時にプラットフォームのバージョンのチェックを付ければ自動的にAPIの参照バージョンを構成可能

組織運営

Feonix Developer CenterはCrowdsが提供する開発用のインターネット上のプラットフォーム及びコミュニティー、Bugzilla、リリースノート、仕様書、ソースコードのCentral、リポジトリ、サーバーベースの自動コンパイル、バージョン管理システムなどの開発用プラットフォーム及びFaceBookやWikiやチャットやブログ、掲示板などのコミュニケーションプラットフォームを提供する、必要なら開発用のプラットフォームはローカルにインストールして個人用のツールとしても利用できる

カテドラル方式とバザール方式はカテドラルのほうが優れている、結局のところ全体の統制があったほうが良い、開発リソースをうまく割り当てられる、しかしさらに望ましいのはカテドラル的な大局的望遠をすべての開発者が把握してバザール的に役割を自身に割り振り自認することである

慈悲深い独裁者もこれにあたるもの、開発者の個性を活かして適切なポジションに割り当てるべき、需要があるところに供給を割り当てなければいけない

バージョン管理システムは閲覧限定のゲストアカウントを用意すべき、匿名の多数のユーザーがソースコードを閲覧できる

APPENDIX

サブディスプレイはあったほうが開発しやすいだろう、特にPlaygroundを動かしやすい

Rosettaは実行時の変換実行だけでなく、同様のアルゴリズムでバイナリ自体をファイルとして変換できるようにすべき、Rosetta ConverterはインストールされたPPCバイナリを自動でネイティブなアーキテクチャのバイナリに変換してそのバッファをバックグラウンドで常時利用するようにする

プログラミング言語には記法ごとの質感と特徴とその見分け方がある、言語の特徴を記法から読み取って質感として捉えるための能力

VNCで画面共有しながら遠隔で開発も場合によっては出来るだろう

エラーは基本的に手動で回復処理するが、良くあるエラーや予期できるエラーならマクロで処理できれば良い、エラーが起きたらマクロをトリガーすれば良い

設定を記述するための実行プログラムというものもある、基本的にPref記法で書かれる、普通はユーザーが設定する設定を自動で一括設定するために使われる

Data Link Table及びBinary Link Tableでパッチをつなぐのにトラックパッドを使うのなら（マスクキーがあってもいいが）ドラッグしなくてもカーソルにパッチラインがスティックすべき、トラックパッドでもパッチが繋ぎやすい、ESCキーでスティック解除か

CCDm：VisualizerではデバイスもData Link Tableで扱える、宇宙から空を構築してモジュール化する、type-dのほうが扱いやすいのでオブジェクトとメソッド変換器を開発、空からインターフェイスを提供してユーザーの領域から操作する、例えば工場用アームはtype-d的に絶対位置で指定してそれまでの動きをCore Animationで決め、加速度を操作してモーターの回り方を決める

F-ScriptはRubyとXBLとVisualizerの役割を兼ね備えたソフト、これもFeonix CCDに統合する

TexはMathematicaから書き出して関連付ける、生のデータがMathematicaであり、Texは文書用といえる

Clangで可能な限りコンパイルし、提供されない機能分はGCCを使うと良いだろう

クイックヘルプは有効か？空のインタフェースなのか宇宙の開発なのか、手軽にヘルプを見られると思うが

テキスト的な開発とIDE的な開発とVisualizer的な開発ではやっている事自体は同じ、表示方法が違う

Plasmaは開発性が重要視される、CUIコマンド、空のインタフェースのVisualizer、依存のFramework、メディア処理系、シェルスクリプトで構成される、宇宙として理解して使うもの

GIMPの拡張機能はRubyで書き直したいが現状のScript-Fuのリソースも活用する、他のアプリケーションの拡張言語も同じ

スプラッシュスクリーンも起動に時間がかかるソフトでは必要、プログレスバーも付ける、が読込中のモジュールの名前は表示しない、ユーザーに処理待ちを知らせるためだけにつけるので、モジュール名はユーザーには関係ないので、ただしフォントキャッシュなどで特別に重くなる場合は表示しても良い、となると文字列を表示しうるスペースは予め必要

Independent Systemも開発できるようにする、依存独立でアプリケーションバンドル

G5 Optimizationを利用することに依ってpycをよりCPUネイティブに近い形で記述し、処理の効率化と高速化を狙う、チップ独自の命令を利用できる、これはVisualizerでソースコードからコンパイルするかそれともシステムで標準からpycから変換するか

現状のApple Xcodeは複数にわけられるべきインタフェースを一つのウィンドウにまとめすぎているきらいがある、例えばInterface Builder、XcodeはCCD Visualizerをアプリケーションバンドルに割り振ったもので構成されていると思われる、GCCとかLLVMも含まれている（た？）みたいなので、（ただし最新のXcodeは事情が少し違うかも）XcodeはLinuxコマンドをバックエンドにネイティブなフレームワークを装備、GUIアプリケーションを用意してテンプレートを使い、モジュール化での機能追加を入れて、CUIの助力を含み、CCD Visualizerをアプリケーションバンドルに割り振ったもので構成されていると思われる

[likebluesky]

Visualizer Top Development Theory (page2)

Objectiveな記法

3DCGはGL Shader言語で記述する、直接C++などでは書かない、これは3Dモデリング用の記法の言語、ちなみにWebGLはブラウザ上で動くOpenGLのインターフェイス

Perl記法、文字列をプログラミング言語上で処理する記法およびライブラリ、正規記法なども連携する、Webモジュールは別でありPerlはローカルプログラムでも利用できる、XMLのDOM記法を使ったほうがXML-XSLT的には洗練されている

ClangのLLVMで可能な限り効率よくコンパイルし、提供されない汎用的な機能分はGCCを使うと良いだろう、コンパイラの実装からインタプリタのパーサーを開発する

SageMathはNoteBookインタフェースは使い易いと思う、Mathematica Scriptの機能はこのモジュールで実現する

Core Animation相当の機能はアニメーションカーブを関数で記述してオブジェクトにビヘイビアとして設定する、エフェクトに組み合わせる、オブジェクトに割り当てることにより記述がObjectiveに簡易になる

Help記法とそれへのリンクを用いればウィジェットからHUDヘルプに表示させるヘルプ内容を特定した上でヘルプを表示できる

Objectiveな記法は開発者が自分で作れる、パーサーを設計する

Visualizerのバージョン記法はgettextのような挙動、標準的なメソッドをメインのソースコード内に書いて、別のファイルに環境適応用の記述を書く

システムのアーキテクチャ

Javaは高水準でC・C++・Objective-Cは低レベル、Java推奨だがそれよりもパワフルな記法が要るのならC系も使う

runnerはpycを利用するのでもともとアーキテクチャ非依存、runnerの部分だけアーキテクチャごとにコンパイルすれば良い

Feonix CCD Enterprise for Windows/Apple OS Xは環境統合及び環境独立の両方のシステム構成を取る、APIやOSのアーキテクチャを使えるところでは使い、カスタマイズしたいなら依存をぶち込み独自に動作させる、プリントシステムには組み込み、ウィンドウにも組み込み、全画面、ウィンドウモード機能を備える、繋ぐところはトンネルで、汎用的なフレームワークで装備する

realtime remakeは複数のアプリケーションでOLEなデータを同期する（か共有する、この場合分断することが少し難しい）、標準データフォーマットは圧縮されずにメモリ（やハードディスク上）で扱われる、メモリとハードディスクは透過的に扱う

タグとかメタデータとかStore Managerとか顔認識を使えばマクロで一括でコンテンツを処理できるだろう

CCDレイヤーが空であり、Store Manager Scriptがコンテンツの空であり、マクロ共有が手順の空である

Store Managerを使うとライブラリのコンテンツの管理体制をシステム側に記録しておくことが出来る、管理体制をユーザーが忘れてもStore Managerを参照すれば良い、Store Managerを操作することに依って管理体制を自動でマージしたりする機能もある

Display SVGは、KSVGでデータ保存、1ObjectもSVG、インタラクティブ性はJavaScript、エフェクトはCore Image、装飾はCSS、画面描画はGhostScript+Xpdf+cairo、印刷周りはGhostScript＋Xpdfで、canvasで動的描画、Animation SVGでアニメーション表示、libpngでビットマップ表示

TANKおよびBentoのデータベース

WebObjectはASIMOVな抽象レイヤーを活かした再利用性の高い強力なWebアプリケーションサーバー、Linuxのリソースで同様のものを開発したい

WebObjectsやLinuxリソースでそれを再現するFeonix CCDのTANKはデータベースをtype-d的に構築してそこから生成したXMLから切り出したHTMLのインターフェイスを自動で生成する、と言う仕組みになっている、

データベースはリレーショナルデータベースのFirebirdやテーブルレコードのSQLを生のままでなくCoreDataでラッピングしたものになっているだろう、ベクトルデータから切りだされた画像とCSSでテーマを組み、テンプレートで即座にプロトタイプを生成できる、

Linux的には拡張機能でモジュールを追加可能にすればより拡張性が増すだろう、ブログやWikiもテンプレートを追加すれば可能と言える、Webサーバー設定を構築してシステム環境設定でTANK共有をチェックしてデータベースプロジェクトをコミットすれば即座に提供可能だろう

本来は専用のNoteインターフェイスアプリケーションに提供するためのものだろうが、互換性を保つためにWebブラウザにも同様のものをWebページとして提供可能

データベースにはパーミッションがありユーザーは様々なインターフェイスアプリケーション（NS XMLアプリケーションを含む）からそれらのデータベースにアクセスできる、

SSLなどの暗号化もフレームワークを組み込めば利用可能、 WebObjectsのようにJavaで構築されているわけではないが、プラットフォーム移植なので対応するOSではどこでも利用可能

認証機構も当然装備、管理者用のフォームも装備する、Rのデバイスと連携できればより業務用に向いている、

確かにユーザーと管理者がメールなどで投稿をやり取りしてスクリプトを書いてサイトを立てる原始的な方法もあるが、TANKのほうが即座に変更を適用可能なインタラクティブ性がありより効率が良く管理し易く統合されている

TANKはコンテンツとメタデータのtype-dのスポットライト理論

個人用の簡易なサイトやあるいは業務用の大規模なLocal Crowdsおよび大規模なCOMを組むためのソフトウェアと言える、機能はVisualizerでCrystal言語で開発してバックエンドに組み込む

TimeMachineバックアップも込みで、設定などのバックアップファイルを手動で作成する必要性はない、TimeMachineがある場合はRAIDはミラーリングは要らない、

動的なページはCGI的に動的に生成し、静的なページは静的にHTMLのバッファとしてページを生成してサーバー内に配置しておく

HTMLに書き出してWebホストサービスに転送及び投稿することも可能

XMLlib.jsはHTMLのJavaScriptのパーサーを通じて読み込まれたXMLにXSLTを割り当ててHTMLのWebページ表示を実現するもの、xullib.jsと同じ手法、

どちらもサーバー側でHTML要素に書き出し可能であり、Webブラウザ上でもパースによるASIMOVな動作は可能だが、サーバ側でHTMLに変換してから送信するのが軽くて互換性のある最善の方法かもしれない

Plexを開発に使ってPlasmoidアプレットを作成してGnashの実装を使ってFlashに書き出しも可能、VisualizerやTANK、Vivid Editorとも連携する

COMのJavaアプレット部分はTANKをVisualizerと連携させて開発すればいい、と言うか読み込みと連携くらいかも

Noteインターフェイスの構築にはFx Developer Editionの実装を活かし、デバックも行う、ウィジェットインターフェイスでもウィジェットのデバックはあるか？

[likebluesky]

Visualizer Top Development Theory (page1)

Feonix CCDのDeveloper's Packに収録されているVisualizer開発環境を使った開発法について、プログラム開発をする上で有用なエッセンシャルなセオリーを含めながらこの記事で説明したい。

開発の原理

Logical Oceanが原理、つまり実装のラインを組むということ、これが途切れたりズレなければエラーは出ない、組み上げるためにASIMOVを見切り、リファレンスを見てAPIを繋ぎ、プログラムを実行しながらバグ取りをする、ObjectiveにLightを書けば汎用的、ラインが折れ曲がって伸びているのが実装のアルゴリズムであり、特殊な折れ方をしているのがObjectiveな記法である

システムを視るためにData Link TableおよびBinary Link Tableを視る、プログラムのASIMOVを組む、Data Link TableでCrystal言語でtype-dのメディア構造を定義（このメディアはライブ反映）、Binary Link Tableのvoid method言語でメソッドを定義、パッチを繋ぐ、プログラムのASIMOVを組む、Chart Composer、ComposerおよびGHashおよびEdgeでパッチを編集、Playgroundで思考実行してInstance Viewでリソース管理及びDebuggerでデバッグ、eBooksの電子書籍とReferenceのAPIなどの開発情報による言語の習得、Binary Link Tableでのデザインパターンおよびアルゴリズム、Ksvnでビジュアル的にパッケージ管理、Testingでガイドライン評価、アルゴリズムからObjective記法がある、CrowdsのFDCでプロジェクト管理、FaceBookでメンバー管理、ガイドラインで使いやすくASIMOVに制限、リリース構成および署名、パッケージ化、ヒューマンインターフェイスガイドラインに制限して使いやすく設計する

プログラムをシステムに組み込んで開発するということは、システムツリーを構築するということに当たる、システムというものは枝分かれした先で一部枝先が接合し、また枝分かれするというツリー状のラインで表すことが可能だが、これはObjective Scriptiveの原理に依るものである、ツリーの一番下は起動ポイントであり、ドライバのラインはそれぞれのデバイスに繋がっている、システム全体でこのツリー全体が協調して動作することにより、システムの挙動が実現される

プログラムの構造体のデザインパターン

Visualizerにおいてはプログラムは構造体として構築するという発想で設計する。つまり手順を実行するという発想ではプログラムは作らない。これらは処理の流れとしてプログラムを視るのではなく、処理を行う機械のような構造体を構築するという非常にObjectiveな発想での開発思想といえる。

基本的にデータ構造体を定義しそのデータを変換して別のデータ構造体に流し込むメソッド変換器を定義する。これはhibrelation-fとして双方向にデータを同期する。トリガーに当たるものはデータ構造体およびデータ構造体のデータの変更であり、手順を実行するという発想でトリガーからイベントを起こすわけではないと思われる。

データ構造体は主にXMLで記述するのが普通だろうが、特殊な記法を用いることもあるかもしれない。普通はXMLでツリー構造を記述し、それを有機的な構造にまとめる手法になるだろう。データ構造体とメソッド変換器は継承を用いて別の原型のオブジェクトから派生して改造して作成することが可能であり、むしろこの継承する方法が推奨される。

データ構造体のデータはバインディングを用いライブ反映で反映され、リソースに負荷がかかりすぎるならflush Editorで反映の程度が制限される。Phoenix Desktopでは更新の頻度が高い場合はメモリ上でそのデータが扱われるため、ライブ反映でも基本的にストレージはシークしない。

モデルに当たるところはバックエンドはFirebirdやSQLであり、データ構造体として保持される。データ構造体にSpotlightを当ててInterface CreatorでGUIを自動生成するか、Interface DesignerでGUIを手動で設計する場合でも、これらのGUIに直結しているViewもデータ構造体としてのニュアンスを持つ。

GUI上のウィジェットのパラメータはユーザーの操作によって変動しても常にValidでなければならない。そうでない場合はライブ反映の性質が危険な挙動を示すだろう。反映させるために確定操作が必要な破壊的な操作の場合は適用ボタンを配置すればよいだろう。

古い言語で書かれたソースコードもアーキテクチャとしてhibrelation-fを適用すれば双方向化はおそらく可能である。（メソッドというものは情報工学的に逆向きにリバースして動作させる概念が原理的に適用できるからである。）ちなみにSTDDCやサービスを設計するなら既存の言語のプログラムではパラメータや標準入出力やファイルの読み込み、AppleScript/Eventなどのデータをやり取りするインターフェイスをこれらに割り当てればいいだろう。データ構造体を設計するならメソッドの引数と返り値をこれらに割り当てればいい。

開発ツールのアーキテクチャ

宇宙のモジュールを作りたいなら仮想ファイルシステムの中で開発する、それと連係してlimiterの中でIDLEで空のアプリケーションを開発する、書き込みはプレイバックで確認

Data Link Table上でパッチからそれぞれのメソッドにラインを繋いで設計する、type-dのData Link TableでもViewもあったほうが良いように思うが、これもInterface Creatorで作成する

Data Link TableはInstance Viewと対応させて実行時の状況表示をする、これを使うとコードの問題箇所を特定しやすい

Instance Viewは履歴も表示できたほうが良い、全体の履歴や一部の履歴を切り替えて表示するか

Tcl/tk改めTcl/xultkはインタフェースを急造するのに有用、履歴機能があった方が良い、ファイル書き出しも有用、Visualizerを起動しなくても良い、内部コマンド方式を使う、ただInterface BuilderやInterface Creatorを利用できるからxultkはあまり有用ではないかも

XPCOMでインターフェイスを作ればシステムに対して破壊的でない空の開発が可能

Policy Layoutはウィジェットの構成や設計をガイドラインに合わせて制約することでユーザーにとってのアプリケーションを使いやすくする機能

Open QuicklyはCUI的なキーボード主体な機能もIDEやVisualizerに取り込むということ

イベントハンドラというかid・action、シグナルとスロットはコードと対応させるラインを表示する、インスタンスごとのスロットとか

テキスト的な開発とIDE的な開発とVisualizer的な開発ではやっている事自体は同じ、表示方法が違う

Automatorやシェルスクリプトはコマンドが完了するのを待って次のアクションに移るべき、こちらのほうが確実に使える

Plasmaは開発性が重要視される、コマンド的なCUIインターフェイス、空のインタフェースのVisualizer、依存のFramework、メディア処理系、シェルスクリプトで構成される、Plasmaは宇宙として理解して使うもの

ガベージコレクションを持っていない言語でもライブラリでそれらの機能を装備すればガベージコレクションを使うことは可能だろう

Chart ComposerやComposerやEdgeだけでなくGHashも使える

オブジェクトの相関関係を表したビヘイビアを登録しまくればGUIのレイアウトはスポットライトさえData Link Tableで割り当てれば自動で生成可能だろう

gitはKsvnのバックエンドか、Ksvnはビジュアル的にバージョンをツリーとして表示できる

Chart Composerも開発する、変数などは宣言に前後がある必要がないし前後があるとASIMOVなやり方でないので、チャートでオブジェクトの処理を書ける機能を作る、純粋に手順の処理系の部分は既出のComposerである、Binary Link Tableと連係してChart Composerの編集画面を展開する

コードの有用性と役割をユーザーから提示して、かつメソッドのインターフェイスを定義することに依って自動でグルーコードを書いて有用な部分のコードを組み合わせる機能を装備する

スポットライト理論はスポットライトの中にスポットライトが入ることもある、データベースからWebページを切り出したり、Data Link TableもCObjectをスポットライトで捉えて切り出す、GUIはテンプレートは選択するか自動割り当てか、データベースからレイアウトを設計する機能を開発する必要がある

基本的にスポットライト理論で当たったイベントハンドラとカスタムエリアからインターフェイスのウィジェットを自動生成する、GUIの設計は必要ない

Composerにはソースコードを埋め込むアクションも用意する、ComposerだけでなくGHashとEdgeも用意する

VisualizerではViewとXUL、Data Link TableとCairo Composerなど、Projectに必要なモジュールはシステムを表すチャートの中で表示部に寄せて強調表示

Playgroundは編集時にコミット必要、コミットされたプログラムの構造体がPlaygroundとして動作する、編集中のままで動作するわけではない、これは保存とは違う

ファイル形式は1Objectを書き込むだけなのでVisualizerでは非常に簡易に書き込み作成できる、Data Link Tableの1Objectをファイルとして書き込むだけ

リリース用のビルド構成というものも作れるようにする、デバッグ用とリリース用は別

基本的にそれぞれの利用形態に応じて画面を切り替える

スニペットパレットも装備、Edgeにテキストを貼り付けるのに役立つ

Instance Viewはアプリケーションバンドルのためにアプリケーション単位でも表示できるようにする

Visualizerで機能を開発する場合は簡易のテスト用のインタフェースがあっても良い、インタフェースを作らなくてもテストできる

VisualizerではコメントのスティッキーにRTFD及び画像を貼れる

Visualizerのインスタンスビューにはファイルリソースの監視機能も欲しい

Edge

Xcode Mini Mapって有用な機能だろうか？Xcode Mini Mapはソースコードのテキストエリアをサムネイルとして表す拡張機能、ソースコードの構成を把握するために役立つか、スクロールナビゲーションもできれば

VisualizerのEdgeではソースコードパネルの背景を暗色にするオプションを用意する、こちらのほうが目が疲れにくい

VisualizerのEdgeではソースコードパネルの並列スプリット表示もあり、ソースコードを比較できる

Edgeのメソッドの名前置き換え機能、メソッド名を特定して一括で修正した名前に置き換える

Fix-itを使えば間違って書かれているコードを優先すべき修正候補から修正できる

VisualizerのEdgeではソースコードパネルの横幅に合わせてグレーアウトの枠を表示する機能があっても良い、コードの一行分の長さを見分けやすくなる

マクロ

マクロは体系化して装備した方がいい、これは自動化、SiriやテキストAIを備えればObs近くのナビゲーションレイヤーにもなる、これは自動化とは別のレイヤー

マクロの操作待ちを使えば間隙の操作はユーザーがこなせる、ここの操作をマクロとして開発してもよいが、これは手間がかかる、汎用的である処理はマクロにすると良い、Ruby/tkとか使えばもっと組みやすくもなるか

手順で書くと単純化できるのでリソースは軽くなる、Darwinのようなハイブリッドカーネルはその目的でモノリシックなアーキテクチャを一部採用している、手順をオブジェクト指向でラッピングするのも有用な手法、本来はオブジェクト指向で構造化して書くべき。手順でオブジェクト指向をラッピングするのはオブジェクト指向なバックエンドモジュールを組み込んで手順の開発者がプログラムを作る時だろう

マクロ機能も有効、type-dかつLight（Firebird）なオブジェクト指向込みの用途別パッケージマネージャに依ってインストールできるマクロ、マクロは組み合わせ可能

[likebluesky]

Phoenix GAI VectorTrace Tutorial

Feonix CCDで提供されるGAIペイントソフトの設計について記述する。

見当のキャンバスの大きさは大体で組んで、キャンバスの外も描けるようにする、実際のキャンバスは最後にトリミングをした時に決まる、キャンバスの線は常時表示して、トリミングする時のキャンバスの外はグレーアウトする

3Dモデリングの機能を使って人物のポーズを取る

下書きは青鉛筆で多重的に線を重ねて書く

ベクトルで線画を描いてインク入れする、筆圧の強弱で線の太さが決まる、全体の線を太くしたり細くしたり後からできるし、必要ならブラシで太くしたり細くしたりも出来る、当然手ブレ補正機能もある

角をつけてペンで描くと角用のアンカーポイントになるので、丸まらない、線の先を付けて角を書いた場合はマスクキーを押しながらだと線先が接続される

線はMEDでブレる場合はマスクキーを押しながら線を複数描けば近似の一本の線が現れることになる

色を塗る時はベクトルで区切られた領域で線の中を塗る、線の太さは関係なく線まで塗る、塗るときは塗りつぶしツールをホバーすると塗る範囲の縁がハイライト表示される

隙間検出機能もある、検出線を書き足せば実線でない線を使って色を塗れる、例えば目の周りの線がそうであるし、影やハイライトもこれで塗り分ける、この線は太さのない線である、実線にぶつかると切れるようになっている

ブラシを使って塗るときは、描き始め（あるいは選択した）の面の領域の中しか塗られないので、外に色がはみ出る心配がない、透明保護を使わなくてもこの機能は利用できる

クイックフィルタを使えば動的で非破壊的にエフェクトを掛けることが可能

テキストは大抵ドローで埋め込まれ、スタイルを設定してデザイン化するので、これも非破壊的なASIMOVなやり方になる

ビットマップのワークフローが必要なら適宜変換することになる、これは破壊的で非可逆な操作である

簡単な画像編集機能を装備し、詳細な編集ならInkscapeやGIMPにモードあるいは変換で渡せるようにするか

OLEを使えるので他のドキュメントに埋め込んで同期しながら編集できる

投げ縄選択ツールで選択して領域内の絵を拡大・縮小、移動や回転させることが出来る、MEDのある人には役立つだろう

マスクの機能があるので絵の隠したい領域の部分を隠して別の描き方を想像することが出来る

テイクの機能があるので幾つかの描き方で切り替えながら表示して見比べることが出来る

ドローの画像をドローとして埋め込んだり、テクスチャを割り振ることが出来る（Note：gimp-comicerはベクトル・ビットマップ（？）ベースのトーンを貼ったり出来る）

簡易的なプリント機能を装備する、単純に絵をレイアウトしてメタデータと共にプリントする

レイヤーは塗り分けのために使うわけではない、これはオブジェクトの上下関係を配置するために使う

クイックフィルタなどのエフェクトはノードで編集する

当たり前だがキャンバスの外の色は範囲系のエフェクトでも中に入ってこない

キャンバスの紙目を設定すると鉛筆画になったりする、紙目自体を表示させることも可能だし、線画の部分だけ紙目の質感を出す設定もできる

線のベクトルは縁をグラデーションで薄くして滑らかにできる、線の色も変えられる

線は基本的に塗りより前である、乗算ではなく標準である

ペンは乗算などの塗り重ねのためのモードを装備する

ペンはKritaレベルの精度のペンでMyPaintレベルのバリエーションがほしい

MyPaintと違いgimp-painterのようにコントロールツールバーは多用する、収まりきらないところは不安定なポップアップウィジェットを使う

カラースポイトの機能は装備する、スウォッチの機能も装備、色の履歴を残したりよく使う色を登録する、kularの機能も装備してカラーバリエーションを容易に取得できるようにする、カラーバリエーションは共有可能

3Dモデリング物体のキャンバスへの配置が可能で例えば自転車などのモチーフは最初からモデルのライブラリで提供される

3DモデルはBlenderで制作してGAIのキャンバスに埋め込める、線画にするDOMレンダラを装備する

ペンタブレットのペンの設定はパラメータを詳細に設定できるようにして、最も使いやすい筆感を得られるようにする、プリセットも欲しい、ペンの設定はドライバ、システム、アプリケーションの三段階で調節する

シングルショートカットキーを多用してキー操作１つで拡大縮小やブラシの大きさの扱いなどを調節できるようにする、ペンタブレットのファンクションキーにも対応

オブジェクトの背景は自動で塞がれるようになっている、これはレイヤーで後ろのオブジェクトは表示されない、これは実線で囲まれた背景をデフォルトの一時色で塗りつぶして実現する、穴を開けたい場合は削除バケツツールで削除すればいい

線まで塗りつぶす仕組みになっているので、線の太さが変わっても隙間が現れるようなことはない

当たり前だがブラシの線はキャンバスを拡大縮小しても絶対的な太さは変わらない、見た目の太さが変わるだけである

線のベクトルもブラシで上から色を塗れるようにする

オニオンスキンの機能が必要、レイヤーを一時的に薄く表示して、上から描く線を見やすくする

レイヤー選択時に単体のレイヤーを一時的に表示するMyPaintの機能は踏襲、単一のレイヤーだけ表示したままにするソロボタンもあるといいだろう

スクラッチパッドの機能も有用

インターフェイスはNatron Interfaceを採用する、screen modeもこれに含んで装備

オブジェクトは移動ツールで移動可能、これは当然塗りも線も一緒に移動する

追記の追加仕様：

線の補正機能はマスクキーかあるいはサイドスイッチで

線が交差した時は先を切り落とす

ブラシのプリミティヴの周りには輪を表示して筆圧を明示的に表示する

線はブラシで太くすることも可能だし、絵全体で調節したいならコマンドで出来る

線を避けるように歪めて動かすスクイーズブラシも搭載

塗るときはまず領域作成のためのバケツツールを使い領域を作成・追加してマスク表示、あとからバケツツールで一発で色をドロップする

レイヤーパレットの中のオブジェクトのグループの中に塗りつぶし領域のレイヤー相当のものが存在する

ブラシは塗りつぶし領域限りに対して使われることが多く、塗り始め領域限りは必要なとき

ツールボックス、コントロールツールバーおよびそこからポップアップパネル（切り離し可能）、中央にキャンバスを配置したいので、パレットは両サイドに表示（エキスパンド可能）、クイックパレットでパレットを一時表示、パレットは組換可能、カーソルからポップアップパネル、ステータスバーで状態表示、でインターフェイスは配置

OLEや非破壊編集はバッファを生成して変更があった場合のみ更新するためASIMOVにラックで非破壊編集をしても修正をかけてもリソース負荷があまり重くならない

ベクター形式なので塗りつぶしツールで面を塗りつぶしてもジャギーに依る塗り残しがない

[likebluesky]

CCD min System Desktop Environment

CCD min SystemはCCDコマンドというCCD用のテキストベースのコマンドを所定のテキストフィールド（runnerと言う）に打ち込んで操作するデスクトップ環境である。

発想点はX Window Systemに由来する。通常のLinuxで最も簡素な構成のものは、シングルユーザモードで画面にターミナルを表示するだけのものだが、この完全にCUIなインターフェイスの場合、コピーやペーストなどのテキストをメディアとして扱うための機能を利用できなかったり、メニューがないなど操作性に制限が多くなることになる。そこでターミナルもGUIのデスクトップ上に表示して、GUIのデスクトップ環境からそれのみインストールしたターミナルを利用するという方法が考えられる。この方法の場合実際のプログラムはCUIのコマンドなので、GUIのインターフェイスとしての使い勝手とCUIの簡易性や効率性を両立して軽量な環境を構築できる。これがX min Systemである。X min Systemから通常のバイナリのコマンドでなく、CCDのコマンドを打ち込み空でインターフェイスを操作するように置き換えたものがCCD min Systemである。本来はCUIで操作するものだが、利便性を考えて他にも幾つかのGUIインターフェイス（モジュールと呼ぶ）を提供する。

CCD min SystemはrunnerにCCDコマンドを打ち込むことに依って操作の命令をして、複数のモジュールにGUIの機能を割り振ることに依って本来のGUIアプリケーションの機能を再現していると言える。つまりMisson Controlを利用することに依って複数のデスクトップを表示して、一つのデスクトップごとに一つのアプリケーションを動かしているように扱う。デスクトップのタイトルはCCDコマンドで表される。

CCD min Systemは非常に軽量に動かしたい非力なマシンで利用するのに向いているデスクトップ環境である。重いアプリケーションを非力なマシンで利用する時にシステムのリソースを減らすためにも有用と言える。そこまでリソースを節減しなくてもいいなら通常はCCD min SystemではなくGUIの軽量な環境であるLXDEを使えばいいだろう。LXDEとCCD min System、CCDnを組み合わせて装備する環境も有効と考えられる。

runner：CCDコマンドを打ち込むテキストフィールド。処理が終わった時に通知音を鳴らすためのウィジェットを装備する。処理の経過状況を書いたメールを設定されたユーザーのメールアドレスに送る機能も実行できる。画像などを扱う場合は、ライブラリビューワーからドラッグアンドドロップで項目をドロップすると、トークンが挿入され、これがテキストでの項目の特定の代替になる。トークンをクリックすればポップアップで画像なら画像が表示される。CCDコマンドはコマンドの候補や履歴をプルダウンメニューから選ぶことも出来る

グローバルメニューバー：システムメニューやマクロメニュー、良く使うコマンド、メニュー、常駐アプレットメニュー、RapidSort検索を装備する。runnerもここから呼び出す

ターミナル：ターミナルが完全にキャラクタベースのみだと識別性に問題があり、且つASIMOVでなく無駄な文字表示が必要になってしまうので、ターミナルはテキストではなくNTインターフェースを提供するものになる。つまり見出しや強調表示、書式やシンボルや簡易なGUIウィジェットなどをHTMLの書式としてブロック単位で表示して利用可能なターミナルとなる。これは背景ではHTMLそのままではなくXML-XSLT-HTMLを設計すべきである。ナビゲーションバーを装備することにより今実行中の出力がその用事に対応しているかをスクロールバック無しでユーザーが把握できるように提示できる。ターミナルにはタブも装備して、一つのアプリケーションに当たる複数の出力を表示できるようにしてもいいだろう。これはプロセス次第でタブが新規に開くようになっている。連続した動作の場合はタブは新規には開かれずそのまま使われることになる。ターミナルではシンプルなプログレスバーやボタン、テキストフィールドなどが利用できる。全体的なコマンドボタンはNTインターフェイスとして端末の下端に配置される。ターミナルは通常のデスクトップ環境のユーザーへのダイアログなどの対話の表示の代わりに使われる。runnerで実行した後コマンドが完了するまではターミナルにフォーカスが当たるようになる。

ログビューワー：これはログのリストのサイドバーとログの内容をテキストおよびHTMLエリアで表示するもの。更新された内容に応じて最新の情報を表示するようにスクロールがスナップする

テキストエディタ／HTMLエディタ：これはかなり重要なプロットになるGUIモジュール。CCD min Systemはメディアの殆どをテキストあるいはHTMLに置き換えて表すが、そのためテキストエディタあるいはHTMLエディタは情報編集の要となる。リマインダなどはチェックボックスを四角で表し、チェックマークをUnicode文字で文字として打ち込むことに依ってテキストファイルあるいはHTMLとしてリマインダを実現したりする。テキストエディタでは行削除や行コピー、行ペーストを機能として装備して多用する、HTMLエディタと言ってもこれはスクリプトを書くためのものではなく、ワープロに近いWYSIWYGなエディタである

Plist Editor：設定ファイルを編集するためのモジュール、XML形式のPlistのみでなくiniやconfなどのLinux的な設定ファイルも簡便なGUIで編集できる。GUIとして項目を追加、削除したり、テキストフィールドに文字を打ち込むことに依って元々はテキストである設定ファイルを編集できる。システム環境設定もPlist Editorで実現する

ライブラリビューワー：ライブラリの項目はメディアが多く、テキストでは扱いにくいので、専用のビューワーが存在する。ライブラリビューワーでは最低限のプレイバックおよびサイドバーのアルバム機能、コンテンツのサムネイル表示エリアが配置される。ここからrunnerにトークンをドラッグアンドドロップで追加したり、右クリックで動作を実行したりトークンを追加できる。カラムでメディアをフィルタする機能も備える。動画の再生や画像の表示くらいは通常のクリック操作でも十分に利用できる

イメージビューワー：これは画像や動画を表示するためのビットマップの表示領域ウィンドウ。簡易なウィジェットも備えるか。この画面で簡易な画像編集も出来るかもしれない

echo/tk：非常に簡易なウィジェットを動的に表示する。これは非常に簡易な記述法の言語で開発者がウィジェットを記述し、必要に応じて表示する手法。例えば端末で扱いにくいGUI的な操作を行うときはこの方法でGUIウィジェットを表示する。他のモジュールに割り振れない特殊なGUIウィジェットを必要とする時使う手法である

ヘルプビューワー：ヘルプを表示するウィンドウ。ターミナルなど通常のモジュールからリンクボタンを張り、このウィンドウを呼び出せる。フロートウィンドウになっているので、他のウィジェットより常に前面に表示されるようになっている

ナビゲーションパネル：CCDコマンドをrunnerに打ち込むたびに、動的にコマンドのナビゲーションをユーザーに提示する。この機能があることに依って、ユーザーはコマンドの使い方を完全にマニュアルを読んで周知しなくても、空のCCDコマンドを対話的に入力・実行できる、HUDで組んでもいいだろう。スクロール可能にして内容を表示することを可能にする。これはmanマニュアルやナビゲーション記法を利用してナビゲーションを生成する

LightWave COMブラウザ：COM用のサイトを表示するための簡易なWebブラウザ。リーダーの機能がデフォルトで有効になっていることにより、COMのサイトを常に見出し、テキスト、リンク、画像のみで表示するように整形できるブラウザになっている。必要な時に応じて、JavaScriptやCSSを無効化したフルブラウザに切り替えたり、さらにJavaScriptやCSSを有効化したフルブラウザにも切り替えられる（モジュールは必要な時しか起動しないのでシステムのリソースは必要以上は圧迫しない）。白色背景か暗色背景かは微妙。COMブラウザなのでWebObjectsのPlaybackを備える

Nortification：通知の機能も装備する。この機能はメールと連係して通知の内容を書いたメールを所定のメールアドレスに送る機能も装備する。この機能を使う場合はメールアカウントをCCD min Systemの環境設定に登録しておく必要がある。他のFeonixシステムに対してはメールでなくネイティブなNortificationイベントとして通知を送ることも出来る

DashBoardウィジェット：DashBoardウィジェットを装備しているが、これはウィジェットごとに小さなrunnerを装備したテキストベースのウィジェットである。

常駐アプレット：常駐するアイコンを表示する領域。アイコンはテキストベースもありではあるが基本的に識別性を取るためにモノクロなアイコンを使う

Misson Control：マルチデスクトップ機能であるMisson ControlはCCDコマンドごとにデスクトップを割り振って利用する。一つのデスクトップごとに一つのアプリケーションを動かしているように扱う。

Expose、Snap Tile、Minimarize：Unityデスクトップと同様に、これらのウィンドウ格納機能を装備する。CCD min Systemはデスクトップ全体で一つのアプリケーションを再現するようになっているので、Exposeは使いやすい機能といえる

アニメーションエフェクト機能は極力控えるが、拡大縮小や半透明などの最低限のエフェクトは備える

暗色背景を標準とする。文字を長時間見る環境なので、たいていのウィジェットは暗色背景のDarkテーマになる、またLXDEと同様にフラットに近いテーマを採用することに依って、簡易なシステムであることをテーマで示すことが出来る

manページの検索機能を備えて、どういったコマンドが求める用法に対応しているのかを調べられるようにする。これを調べることにより多数あるアプリケーションやその組み合わせのパラメータをどう使えばいいかわかるようにする

壁紙はウィジェットが暗色背景なので暗色から少し明るいパターンの軽い壁紙が推奨される。少し明るいことで暗色背景のウィンドウを視認しやすくする

マニュアルブラウザ：XML-XSLT-HTMLで書かれた文書を表示するためのモジュール。ドキュメントの閲覧用やマニュアルの表示に使う。大抵の文書はこのモジュールで表示する

マクロとPlayback：マクロはメニューバーのメニューから実行可能。Playbackの機能はウィジェットを配置して装備する

PlasmaのX min System：通常のPlasmaの環境を実現するため通常のコマンドを実行できるX min Systemのデスクトップも配置できるようにする。これはCCDとは別個に動くだろう

キャレットブラウズモード：この機能を使うことにより全てのデスクトップ上のGUIウィジェットを巡回してキーボード入力だけで簡易に操作できるようになる。特定のグローバルショートカットキーを押すとキャレットブラウズモードが入りになる。キーボードのフォーカスはrunnerを起点にして派生したウィンドウに渡され、Tabキーでウィンドウをフォーカス移動して、さらにウィンドウの中に何らかのキーで入ってTabキーでウィジェットを選択するといいだろう。さらに上位のウィジェットに戻って上がるキーも必要になる。必要な場合はフォーカスが自動で割り当てられることもある。トラックパッドを利用する場合はこの機能はあまり必要ないだろう。

結局のところCCD min SystemとはCUIのアドバンテージを実用性を考えたGUI環境の中で実現している環境である。CCDのパネルとしてライブラリビューワーとCOMブラウザがあり、閲覧用にマニュアルブラウザがあり、編集用にHTMLエディタがあることになる。そしてよく使うGUIはモジュールで再現し、特殊なGUIウィジェットが要るならecho/tkを使うことになる。

CCD min Systemをより簡便に実現したいなら、ライブラリをファイルのディレクトリとしてLibrary Directory（つまりジャンルで分けて、月別に分ける）のフォルダ分けで管理して、履歴を呼び出せる入力フィールドのある端末を開発し、ナビゲーションパネルを装備すればいい。そしてこのCCDに実行型や編集型としてのアプリケーションを登録すればいいだろう。CCDなので通常のバイナリで動かす環境より利便性で優れている。この環境なら開発リソースが欠乏していてもそこまでの時間と労力無しで使いやすいCCD CUI環境が構築できる。