On Wed, 5 Jun 2002, Michael Koziarski wrote:
> Hey all,
>
> Lately I've been thinking about the layout of the GNOME dialogs. My
> goal is to stick as closely as possible to the Gnome-2 Human interface
> Guidelines (http://developer.gnome.org/projects/gup/hig/).
>
> One of the requirements for th
> Same as in the tabular-dialog? Well you don't need a button controler
> if you do that, but what you need is a lot of interaction with the
> main core as the dialogs should update automatically to the new cursor
> position. After that you cannot f.ex. apply a paragraph layout to more
> than one
On 05-Jun-2002 Michael Koziarski wrote:
> Hey all,
>
> Lately I've been thinking about the layout of the GNOME dialogs. My
> goal is to stick as closely as possible to the Gnome-2 Human interface
> Guidelines (http://developer.gnome.org/projects/gup/hig/).
>
> One of the requirements for this
On Mon, 5 Mar 2001, Angus Leeming wrote:
> > Please enlighten me why you think you have to implement it the way you
> > suggest.
>
> Ok, here goes. If I leave out the all important line in
> ButtonController::input():
>
> if (ButtonPolicy::SMI_NOOP == in) return;
>
> then the up,down,add,de
> Please enlighten me why you think you have to implement it the way you
> suggest.
Ok, here goes. If I leave out the all important line in
ButtonController::input():
if (ButtonPolicy::SMI_NOOP == in) return;
then the up,down,add,delete buttons in the Citation dialog become active when
On Fri, 2 Mar 2001, Angus Leeming wrote:
> Allan,
>
> I've implemented your "tri-state output for input()" method exactly as you've
> described it below. (This implementation is in my local tree only).
>
> In order for it to work, (and it works perfectly) I have to modify
> ButtonController::inpu
Allan,
I've implemented your "tri-state output for input()" method exactly as you've
described it below. (This implementation is in my local tree only).
In order for it to work, (and it works perfectly) I have to modify
ButtonController::input() to:
void ButtonControllerBase::input(ButtonPoli
On Mon, 19 Feb 2001, Angus Leeming wrote:
> On Saturday 17 February 2001 05:15, Allan Rae wrote:
[wonderful ideas as always ;-)]
> > Too easy?
>
> I knew I'd be able to trick you into active development! This is a super
> idea. Do you want to code this up, or shall I?
I barely have time to read
On Saturday 17 February 2001 05:15, Allan Rae wrote:
[...]
> The button controller is supposed to be exactly that: the controller.
> Remember the MVC discussions. Either way we have two choices as I see it:
> 1. use input() only for input processing. This is the same as
> your introd
On Fri, 16 Feb 2001, Angus Leeming wrote:
> On Friday 16 February 2001 00:32, Allan Rae wrote:
[...]
> For example, in the citation dialog, clicking on an entry in either browser
> activates the appropriate (up, down, transfer, delete) buttons and displays
You could extend buttoncontroller to do
On Friday 16 February 2001 00:32, Allan Rae wrote:
> Maybe they shouldn't have callbacks at all then?
> The point of input is to do input checking and make changes to interface
> as appropriate.
[snip explanation of how input() should work...]
> In simple terms, for the case you are trying to fi
On Thu, 15 Feb 2001, Angus Leeming wrote:
> Allan,
>
> why have you made ButtonController::valid() a "Passthrough function --
> returns its input value"? It isn't used as such. Can I make it a void
> function please?
It seemed like a good idea at the time. I thought it might be used in a
way si
12 matches
Mail list logo
