hey, also consider: - mobile view - good for keep updated on ticket reporting and so on... - integrated SQL designer - update option for each app - routes web interface - logging interface
Thank you Best regards On Nov 20, 5:12 pm, Branko Vukelic <bg.bra...@gmail.com> wrote: > This topic is for brainstorming future development of the admin UI. > Please do not report bugs with the current one in this topic, since > its purpose is not fixing the current admin. > > Here are a few ideas. > > 1. Sites section > > 1.1 Workbench > > The workbench would be the space below the current top panel. It would > occupy the entire space below the panel and would contain icons > representing apps, as well as some miscellanous features such as > twitter feed. The admin would be expandable via plugins, and plugins > would provide workbench icons that would appear on the... err... > workbench. :) > > 1.2 Admin bar > > The admin bar would be an extension to the current panel at the top. > It would contain menu items that open modal dialogs containing the > functionality of the items in the current sidebar (web2py update, > creation of new apps, deployment on GAE, etc). The functionality that > is already in the top panel would become part of the admin bar with > the same status (importance) as the ones currently on the sidebar. > > 1.3 Twitter feed > > The twitter feed would be presented as a separate non-modal window > which can be closed (minimized to an icon). This feature will > represent an example of the admin plugin as well, and it should be > developed separately but included by default. > > 1.4 App icons > > The workbench app icons should behave more or less like desktop icons. > Clicking on them opens the design view, and hovering over the icons > opens a toolbar with less commonly used features like packaging and > testing. All apps can have custom 128x128px icons in png format. The > icon can be placed into the app directory as ``appicon.png``. The icon > can also be uploaded at (a) app creation time via the admin bar, or > (b) later via design view, or (c) during creation via the wizard. > > 2.0 Design window > > The design window will be a non-modal window expandable to 100% space > of the workbench. It is has the functionality currently offered by the > design view. The design window will behave much like a desktop IDE. It > will have tabbed edit space, and a file list on the left. The file > list will be a panel that is separated horizontally into two boxes. > The top box (top panel) contains the project tree, and the bottom > panel will contain various information about the file (what method it > exposes, etc). The specific advantage of having a non-modal design > window would be the ability to open multiple design windows at once, > enabling copying of code between projects, etc. > > 2.1 Project tree > > Project tree is a expandable node system. Multiple root nodes > correspond to current design view subsections (Models, Controllers, > etc). Child nodes correspond to the directory/file hierarchy. Clicking > on the root node expands it or collapses it. Right-clicking the root > node offers options like "Expand all children", "Collapse", "Collapse > all sections", etc. By default, all root nodes are expanded. Child > nodes can be either file nodes or directory nodes. Dir node behaves > the same way as root node. File nodes have a context menu that offers > functionality such as testing, editing, or deletion. Clicking on a > file node updates the info panel (bottom panel). Double clicking the > file node opens it in the editor in the edit panel (right panel). > > It would be interesting to see revision control integrated with the > file panel as well. > > 2.2 Editor panel > > The editor panel (edit space) on the right is a tabbed interface > containing the editor of choice. It enables editing of multiple files > and switching between them using the tabs. A tab has an X mark that > allows closing it. > > 2.3 Design bar > > The design bar has the appearance similar to admin bar, but with > options specific to design view. It doesn't replace the admin bar, but > it appears attached to the design window. All design bar functionality > should open non-modal windows of their own. This allows you to, for > example, view the code and the ticket(s) side-by-side, etc. This > philosophy extends to pluigin view as well, so plugin view opens a new > non-modal design window containing the plugin-related functionality. > > That's it for now. I'll keep adding things as I think of them. > > -- > Branko Vukelić > > bg.bra...@gmail.com > stu...@brankovukelic.com > > Check out my blog:http://www.brankovukelic.com/ > Check out my portfolio:http://www.flickr.com/photos/foxbunny/ > Registered Linux user #438078 (http://counter.li.org/) > I hang out on identi.ca:http://identi.ca/foxbunny > > Gimp Brushmakers Guildhttp://bit.ly/gbg-group
