File: view-system.txt

package info (click to toggle)
mlview 0.9.0-1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 6,028 kB
  • ctags: 3,957
  • sloc: cpp: 49,090; sh: 8,393; ansic: 3,262; xml: 361; makefile: 329
file content (105 lines) | stat: -rw-r--r-- 4,909 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
MlView Editing view management System
======================================

I) Overview  
============

In the MlView editor, the view system is in charge of managing the
different views through which the user edits XML documents.

When the user opens an XML document, the editor creates an editing view
for that instance of document. The user also can create several different
editing	views on the same document, close some of those views, open other documents,
create several views on these documents etc ...

The task of the view management system is to provide the editor
with the possibility to do stuffs like create a view on a document, remove a view
from the application, handle the 'layout' of that view (i.e: whether the view
should be put in a tabbed notebook, or in a separate window etc)and  keep the relationships
between views and document.

The View management subsystem is designed with extensibility in mind. In the future,
it should be able to handle complex use cases such as a view that allows editing of several
xml documents at once


II) rough organisation of the view management substem
====================================================

The main components of the view management subsystem
are mlview::IView and mlview::ViewManager .

IView is the interface implemented by all the views in MlView.
From the editor standpoint, ViewManager is the class that does
the job when it comes down to add/remove view, get information
about them etc. Just to have an idea what its real job looks like,
here are some of the methods of ViewManager:

        - IView* ViewManager::create_view_for_document (MlViewXMLDocument *a_doc,
                                                        const UString &a_view_type) ;
        - enum MlViewStatus ViewManager::append_view (const IView*) ; 
        
        - enum MlViewStatus ViewManager::remove_view (const IView*) ;
        
        - enum MlViewStatus ViewManager::remove_all_views_for_document (MlViewXMLDocument *a_doc) ; 

        - enum MlViewStatus ViewManager::get_views_of_document (MlViewXMLDocument *a_doc,
                                                                vector<IView*> &a_views) ;
        - etc ...

Okay, that's for the logic. Now what matters in the end is what the user sees on the screen and
what it can do with it. How will the editing view actually be presented on screen ? Will all
the views of a given document be in the same notebook tab ? Will we use GDL instead ?
They are lots of graphical stuffs that need to be managed too. 

III) The graphical view container
=================================

III.a) organisation
-------------------
When MlView editor asks the view manager to add a new view for a given document,
the later updates view informations (i.e:  "oh, that document already has 10 views opened , I must
acknowledge the fact that now it has 11") and, right after asks another class,
the mlview::GraphicalViewContainer to actually layout that view somewhere, somehow.
Where and how it does it, neither mlview::Editor nor the ViewManager do actually care.

When a ViewManager is instanciated, it instanciates a graphical view container that
will handle all the graphical details. So, one should be able to change the type
of graphical container used by the View Manager to change the graphical layout
of the views.

Talking about code, all the graphical view containers must implement the interface
mlview::GVCIface . This interface is virtual pure and cannot be instanciated directly.
To create instances of mlview::GVCIface, one should invoke the mlview::GVCFactory
factory class, especially the mlview::GVCFactory::create_gvc() method.

III.b) how to write a graphical view container (let's call it mlview::FooGVC)
-----------------------------------------------

	1) make mlview::FooGVC derive from mlvie::GVCIface

	2)implement the pure virtual methods of mlview::GVCIface

	3)complete the method mlview::GVCFactory::create_gvc()

		Add a 'else if' statement in that method to make it
		create an instance of FooGVC and return that instance
		if the type name given in parameter of the method
	        equals "FooGVC"

	4)to make mlview::FooGVC be actually used by the ViewManager,

	  edit Editor::Editor() and set m_priv->view_manager_ptr to
	  new ViewManager (context, "FooGVC") ; Please, comment the previous
	  instruction that was setting m_priv->view_manager_ptr to something
	  else, so that you can rollback your change later easily.

	5)if you need help, you can look at mlview::OldGVC as an example.
		This class is a graphical view container based on a notebook.

IV) The views
================
In MlView, a view is the entity that lets you edit an XML document loaded
in memory. A view is *NOT* a widget. A view is the abstraction of the graphical
interface that lets you edit the document. A view however provides the system with
a widget to let you edit the document.