diff options
| author | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2011-06-16 19:02:47 +0000 |
|---|---|---|
| committer | tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da> | 2011-06-16 19:02:47 +0000 |
| commit | e985f7e545f4739493965aad69bbecb136dc9346 (patch) | |
| tree | 54afd409d8acd6202dd8ab611d24e78c28e4c0a0 /quanta/Quanta-3.3-plan.kno | |
| parent | f7670c198945adc3b95ad69a959fe5f8ae55b493 (diff) | |
| download | tdewebdev-e985f7e545f4739493965aad69bbecb136dc9346.tar.gz tdewebdev-e985f7e545f4739493965aad69bbecb136dc9346.zip | |
TQt4 port kdewebdev
This enables compilation under both Qt3 and Qt4
git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdewebdev@1237029 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'quanta/Quanta-3.3-plan.kno')
| -rw-r--r-- | quanta/Quanta-3.3-plan.kno | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/quanta/Quanta-3.3-plan.kno b/quanta/Quanta-3.3-plan.kno index fc22ca65..eb2837b7 100644 --- a/quanta/Quanta-3.3-plan.kno +++ b/quanta/Quanta-3.3-plan.kno @@ -22,24 +22,24 @@ \NewEntry 1 Toolbars <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:sans-serif"> -<p>Toolbars need serious attention!<br />Phase 1:<br />1) Clean up for current usage<br />2) Create quick "add this tag to a toolbar" RMB function<br />3) Make toolbars abide by tag relationships like auto complete<br /><br />Phase 2:<br />1) Add drop down icon group ability to manage larger sets (like on file folder icons) This will require a new type on the action dialog with a new sub dialog to list tags<br />2) Create toolbar modalities. Allow for recognition of edting type like tables, forms, data, layout and user defined tasks where entering a portion of a document, opening a view or directly selecting the mode changes selected toolbar or even toolbars and groupings. <br /><br />The idea is that the user could teach Quanta how to provide optimal tools for various tasks and instead of a static layout the layout and presentation become dynamic. This will require balance and good icons to be more productive.</p> +<p>Toolbars need serious attention!<br />Phase 1:<br />1) Clean up for current usage<br />2) Create quick "add this tag to a toolbar" RMB function<br />3) Make toolbars abide by tag relationships like auto complete<br /><br />Phase 2:<br />1) Add drop down icon group ability to manage larger sets (like on file folder icons) This will require a new type on the action dialog with a new sub dialog to list tags<br />2) Create toolbar modalities. Allow for recognition of edting type like tables, forms, data, tqlayout and user defined tasks where entering a portion of a document, opening a view or directly selecting the mode changes selected toolbar or even toolbars and groupings. <br /><br />The idea is that the user could teach Quanta how to provide optimal tools for various tasks and instead of a static tqlayout the tqlayout and presentation become dynamic. This will require balance and good icons to be more productive.</p> </body></html> \NewEntry 2 Phase 2 explanation <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:sans-serif"> <p><span style="font-style:italic;color:#3300ff">> - Phase 2/2 sounds a little complicated to me and I'm also not sure that I understood it completely.</span></p> <p>Think of it as personalities. The idea is that Quanta could interpret some aspects of what I am doing and offer toolbar presentations based on that. How to best go about it is not totally clear. Initially I had thought to have Quanta offer the relevent toolbar so the user didn't have to select it, but this is not completely effective it you think about it. Another possibility is to construct a toolbar on the fly from relevent tags... intriguing but probably not very fast or fluid. The advantage to the toolbars we have is that you know where the icons are. The disadvantage is you could end up switching between 3-4 of them building a formatted data form, which is not intuitive.</p> -<p>In balancing these several concepts seem to offer counterpoints.<br />familiar layout <-> specifically applicable actions<br />pre-made toolbars <-> dynamicly created toolbars<br />feature oriented toolbars <-> task oriented toolbars</p> +<p>In balancing these several concepts seem to offer counterpoints.<br />familiar tqlayout <-> specifically applicable actions<br />pre-made toolbars <-> dynamicly created toolbars<br />feature oriented toolbars <-> task oriented toolbars</p> <p>Currently Quanta is solidly to the left and only to the left on all three of these points. I began considering adding task oriented toolbars. Which is better? If you could be certain that the toolbar would do the following you would have perfection:</p> -<p>1) orient correctly to every task<br />2) retain familiarity of layout for variations and segue to next task<br />3) offer only proper tag relationships</p> -<p>Inherently some tasks cannot be discerned from context but could be defined by the user. Selecting a task modality could convert all toolbars to the applicable tagging, not just one. However you may want to be in a standard layout in one situation (certainly in a blank page) but assume modal personalities in others (common data design scenarios).</p> +<p>1) orient correctly to every task<br />2) retain familiarity of tqlayout for variations and segue to next task<br />3) offer only proper tag relationships</p> +<p>Inherently some tasks cannot be discerned from context but could be defined by the user. Selecting a task modality could convert all toolbars to the applicable tagging, not just one. However you may want to be in a standard tqlayout in one situation (certainly in a blank page) but assume modal personalities in others (common data design scenarios).</p> <p>So we can say this about the ultimate solution:</p> <p>1) I don't think anybody is really anal enough to already be doing it.</p> <p>2) If it could be accomplished it would be very very cool and get a lot of press.</p> <p>3) It cannot be a single solution, thus it's multiple "personalities"</p> -<p>4) Basic structure and layout will take experimentation, and user feedback. In fact it would take a fair amount of study and refinement.</p> +<p>4) Basic structure and tqlayout will take experimentation, and user feedback. In fact it would take a fair amount of study and refinement.</p> <p>5) No single solution is possible so it must allow for easy user extensibility</p> -<p>Because we hope to be able to make VPL play a larger role we cannot discount the importance of good toolbar layout. Making toolbars load with a DTEP is a good start as are user toolbars. Extending intelligent context sensitive task extentions will make a big difference, especially when dealing with the huge diversity of tasks and preponderance of tags out there.</p> +<p>Because we hope to be able to make VPL play a larger role we cannot discount the importance of good toolbar tqlayout. Making toolbars load with a DTEP is a good start as are user toolbars. Extending intelligent context sensitive task extentions will make a big difference, especially when dealing with the huge diversity of tasks and preponderance of tags out there.</p> <p>My vision is not just someone saving a toolbar for a task, but saving a whole personality. Imagine these as dowloadable resources. ;-)</p> <p></p> </body></html> @@ -56,7 +56,7 @@ \NewEntry 1 VPL <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:sans-serif"> -<p>Undoubtably there will be many things we want to do here. I'll start the list... This is not really prioritized.<br /><br />1) Visual Table editor<br />2) Integration of visual CSS using our dialogs and tools<br />3) XSLT translation layer for XML<br />4) Script integration edit mode - very tricky but we should conceptually explore being able to interpret and edit elements of PHP in a loop for instance to create a visual mode for editing the layout or CSS visually in data layout. I'm suggesting merely exploring what is possible here as something exceptional if we had any degree of success.</p> +<p>Undoubtably there will be many things we want to do here. I'll start the list... This is not really prioritized.<br /><br />1) Visual Table editor<br />2) Integration of visual CSS using our dialogs and tools<br />3) XSLT translation layer for XML<br />4) Script integration edit mode - very tricky but we should conceptually explore being able to interpret and edit elements of PHP in a loop for instance to create a visual mode for editing the tqlayout or CSS visually in data tqlayout. I'm suggesting merely exploring what is possible here as something exceptional if we had any degree of success.</p> </body></html> \NewEntry 0 New Features @@ -94,7 +94,7 @@ \NewEntry 1 RAD Site <html><head><meta name="qrichtext" content="1" /></head><body style="font-size:10pt;font-family:sans-serif"> -<p>This has largely been under wraps except a few teasers. It's going to be my baby.<br /><br />RAD design has not come to web development because of the diverse approaches. It's rather difficult to even use code other people build in PHP because it's largely built with the assumption that it's the only systematic approach on your site intstead of a good object model as a part of what exists that abstracts well and plays together well. If I build it you won't use it because it's not your style and vice versa. That's where this is different.<br /><br />1) Based on templates - this allows the user to develop the framework in layers<br />2) User defines abstractions - when you have a modular element in your design you define what the public and private interface is to it<br />3) Learning ability - because creating something like this is complex and involved the burden is lessened by enabling the system to assist in creation by learning<br />4) New abstract interface - the key to integrate this is an interface that uses "set"definitions starting with a page and defined elements in the page where the user defines relationships. Then there are the physical aspects in directory relationships (which are tracked) and group set assignments for style or layout which assist in painting an even interface. <br />5) The interface can be viewed panning various levels and perspectives and remembering view arrangements. Perspective would be things such as<br />- physical layout<br />- conceptual group<br />- style grouping<br />- layout grouping<br />Level views would include<br />- overview<br />- concept/style/layout group<br />- page elements/relationships<br />- element definitions<br />- various configuration dialogs<br /><br />The concept here is that extremely anal content management can be done with tight control of abstrated design elements... or you could ease particular elements of a basic site design with nominal effort. Results would be up to the user and their design base.<br /><br />Some aspects:<br />* moving files automatically manages links<br />* Minimal application speeds development and manages framework<br />* Page component templates function dynamically<br />* Would use comment system and or generated file to manage elements<br />* would be able to offer limited functionaliy directly importing existing sites<br />* Extreme application could completely manage an abstracted site where a site manager could request elements from contributors - combined with group projects and versioning a good manager can take skilled crafts people and clueless fools and weave a quality project. ;-)</p> +<p>This has largely been under wraps except a few teasers. It's going to be my baby.<br /><br />RAD design has not come to web development because of the diverse approaches. It's rather difficult to even use code other people build in PHP because it's largely built with the assumption that it's the only systematic approach on your site intstead of a good object model as a part of what exists that abstracts well and plays together well. If I build it you won't use it because it's not your style and vice versa. That's where this is different.<br /><br />1) Based on templates - this allows the user to develop the framework in layers<br />2) User defines abstractions - when you have a modular element in your design you define what the public and private interface is to it<br />3) Learning ability - because creating something like this is complex and involved the burden is lessened by enabling the system to assist in creation by learning<br />4) New abstract interface - the key to integrate this is an interface that uses "set"definitions starting with a page and defined elements in the page where the user defines relationships. Then there are the physical aspects in directory relationships (which are tracked) and group set assignments for style or tqlayout which assist in painting an even interface. <br />5) The interface can be viewed panning various levels and perspectives and remembering view arrangements. Perspective would be things such as<br />- physical tqlayout<br />- conceptual group<br />- style grouping<br />- tqlayout grouping<br />Level views would include<br />- overview<br />- concept/style/tqlayout group<br />- page elements/relationships<br />- element definitions<br />- various configuration dialogs<br /><br />The concept here is that extremely anal content management can be done with tight control of abstrated design elements... or you could ease particular elements of a basic site design with nominal effort. Results would be up to the user and their design base.<br /><br />Some aspects:<br />* moving files automatically manages links<br />* Minimal application speeds development and manages framework<br />* Page component templates function dynamically<br />* Would use comment system and or generated file to manage elements<br />* would be able to offer limited functionaliy directly importing existing sites<br />* Extreme application could completely manage an abstracted site where a site manager could request elements from contributors - combined with group projects and versioning a good manager can take skilled crafts people and clueless fools and weave a quality project. ;-)</p> </body></html> \NewEntry 0 Plug Ins |