User talk:Wjjohnst: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Custom Toolbar Enhancements ==
== nsIMailDBView ==
Custom toolbars seem really limited in my opinion. Right now they're limited to a simple toolbox with a palette inside it and a few permanent toolbars defined. Users can add custom toolbars to the box, and settings for those toolbars are stored as preferences. Settings for toolbars are system wide so that one toolbar can not be created that with mode=text and another without it.
I've been trying to get TB to display messages with the subject on one line and the sender on another. Without this ability, a 3-pane vertical view is pretty much useless. I've thought of three ways to do it:


I know I'm getting greedy with unncessary features, but I'm gonna list the things I'd like to see in toolbars from a customization point of view.
# Rewrite the treeview to fill in different data on every other row. This isn't that hard to implement, but it worries me a lot. I also had to write a treeSelection that would select rows in groups of two. I'm not sure who's polling for the selected message though. If they ask, and I tell them that row two is selected, its likely that they'll assume that also means that message two is selected, and possibly display, delete or move the wrong message.
# Write a new tree box object that allows two columns to be put on top of one another, but vertically shifted. I've looked into this. Best I can tell, its the "correct" way to do this, but it looks hard and requires me to build my own Mozilla. I don't even want to try.
# Hide the threadpane and use a richlistbox instead. This gives the prettiest results, but you have to keep the real threadpane and richlistbox in sync so that when, for instance, the delete button is pressed, the right messages are deleted. Also, richlistboxes have horrible performance when compared to a tree. However, its the only option that actually works. Its just a complete hack and a lot of juggling.


==Toolbar Ideas==
Right now most of my confusion comes from the nsIMsgView interface which couples the database backend and the threadpane frontend. Upon first look, I just assumed that the threadpane was filled by an in memory RDF datasource. Instead the DBView houses both access to the real DB and provides a TreeView for showing the DB. I don't want to have to rewrite all those DB access functions just to rewrite the frontend though. I just want to overwrite the tree or treeview and not have to fight anything else.
*Custom toolbars shouldn't be limited to a set at one point in the page.
 
**You should be able to define toolbars at the top of a webbrowser and at the bottom and have both be customizable (same for right and left sides).
So in conclusion, I have no idea what the best way to do this is. I just wanted to rant about how I can't get this stupid thing to work without doing some weird hacks, and to see if anyone else knew an easy (or at least the correct) way to do this.
**Doing this pretty much means removing the toolbox entirely, and so I'd say that applications should be able to just specify a toolbarpalette and toolbars. Toolbars with a customise property=true would be customizable. Toolbars without the property shouldn't be.
**On the same track, toolbars should be draggable to the top, bottom, right, or left of the application if the user wants. I'd suggest this be done through a grabber that appeared only when toolbars were in customize mode. Once again, toolbars that wanted to be draggable should specify it through a property.
*Toolbars should be customisable on a per-toolbar level.
**I'd say this should be doable through the toolbar's context menu. Right clicking on a toolbar should show you:
***a list of toolbars on the page, to easily turn on or off toolbars
***an option to Customize the toolbar widgets you see
***an option to bring up Properties for that particular toolbar. This could be both a generic toolbar properties dialog, or a toolbar specific one if the toolbar specified one.
==Toolbar Customize Dialog==
*The toolbar customize dialog should morph form dramatically, perhaps into some sort of richlistbox. The box could show both descriptions of toolbar items, along with names and icons. This would also clean up a lot of the code in the current implementation.
==Toolbar Palette==
*Pretty much every piece of front UI in the application should be a toolbar item, and should be draggable somewhere else if you wanted.
**I'd like to be able to drag elements from the statusbar somewhere else in the browser if I wanted. Or to drag elements from the nav bar to the status bar. This would be possible if the statusbar was part of the toolbox, but using current model, I don't think it is.
**In a slightly more FF centric point. I'd really like to see the tabbar morphed into a toolbar item too. That would allow users to move it easily to wherever they wanted it in their browser, saving them some extra screen space, and would allow things like the taboverflow button, and newtab button to be easily added or removed to the tabbar, without requiring users who don't need them to see them. Hence why I say, I really wish pretty much every piece of front panel UI was a toolbar item.
*Toolbaritems should be able to specify whether they're reusable or not. Items with reusable=true should be able to be placed on the page multiple times if the user wants. This helps move spacers out of the current custom toolbar implmentation, and cleans up the code somewhat. It also allows for some neat widgets like searchboxes to be setup in more useful ways for power users.
*On the same path, you should be able to specify some types of toolbars as toolbars on toolbars. For instance, the URL bar in FF has been picking up more and more icons as time goes by. These icons should be draggable out of the URL bar if the user wants, or other icons should be draggable into the URLbar.
==Custom User Toolbars==
*I think these are really useless and don't know a single user who uses them by choice. Removing them entirely wouldn't hurt the code. They could be added back via an extension easily.
*However, if they do NEED to be implemented in some fashion, the current pref system just seems... antiquated. We've got a ton of persistant storage services going now, but I'm not sure which one is right for implementing this.

Latest revision as of 16:50, 1 June 2007

nsIMailDBView

I've been trying to get TB to display messages with the subject on one line and the sender on another. Without this ability, a 3-pane vertical view is pretty much useless. I've thought of three ways to do it:

  1. Rewrite the treeview to fill in different data on every other row. This isn't that hard to implement, but it worries me a lot. I also had to write a treeSelection that would select rows in groups of two. I'm not sure who's polling for the selected message though. If they ask, and I tell them that row two is selected, its likely that they'll assume that also means that message two is selected, and possibly display, delete or move the wrong message.
  2. Write a new tree box object that allows two columns to be put on top of one another, but vertically shifted. I've looked into this. Best I can tell, its the "correct" way to do this, but it looks hard and requires me to build my own Mozilla. I don't even want to try.
  3. Hide the threadpane and use a richlistbox instead. This gives the prettiest results, but you have to keep the real threadpane and richlistbox in sync so that when, for instance, the delete button is pressed, the right messages are deleted. Also, richlistboxes have horrible performance when compared to a tree. However, its the only option that actually works. Its just a complete hack and a lot of juggling.

Right now most of my confusion comes from the nsIMsgView interface which couples the database backend and the threadpane frontend. Upon first look, I just assumed that the threadpane was filled by an in memory RDF datasource. Instead the DBView houses both access to the real DB and provides a TreeView for showing the DB. I don't want to have to rewrite all those DB access functions just to rewrite the frontend though. I just want to overwrite the tree or treeview and not have to fight anything else.

So in conclusion, I have no idea what the best way to do this is. I just wanted to rant about how I can't get this stupid thing to work without doing some weird hacks, and to see if anyone else knew an easy (or at least the correct) way to do this.

Retrieved from "https://wiki.mozilla.org/index.php?title=User_talk:Wjjohnst&oldid=58453"